Pages

Monday, August 26, 2013

How to Divide a Long Workflow Definition

When you define a flow of an operation, you will need a little skill to set '[S: Start point] and [E: end point] of the Business process'.

For example in an "Inquiry flow", it should start with 'S: Accepting the Inquiry' and should end at 'E: Sending the Answer'.
Also in a 'Billing flow', it should start with 'Inputting Billing data' and should end at 'E: Payment Confirmation'.
Settings on these Workflow are not so controversial.

However there will be a lot of objections, suppose if I define a long process into a 'single Business Process', such as from 'S: Lead corresponding' through 'Estimate, Orders' and 'Manufacturing' then ends at 'E: Payment Confirmation'. Most of all, the flow diagram is complicated, the work process becomes difficult to read. Moreover, the number of items in the "business data" become also large inevitably, data required for processing becomes difficult to see.

The simplest solution is a method that [(A) Managing in Dividing into Phases].

Figuratively speaking a sequence of operations as the "bullet train from Tokyo to Osaka", it is to manage in dividing into '(1) Tokyo to Nagoya' and '(2) Nagoya to Kyoto' and '(3) Kyoto to Osaka'. That is, each designer defines important parts in each phase. It will be easy to imagine if you think about operations that the project itself is prolonged such as "construction work" or "writing a study thesis". Dividing phases at the point where changing the person (departments in charge) involved, would be the royal road.

Another solution is a method that [(B) Managing in Dividing into Simple cycles].

Speaking in the "bullet train from Tokyo to Osaka", to consider this as repetition of a simple Business Process of "Departure and Stop". The general versatility will become quite high, also the operating procedures will be recorded in detail. At the same time (as in the general theory though), it will become difficult to overview the "whole thing".

[Departure-Stopping flow]


[Departure-Stopping flow: '1. Signal of Departure' screen]


  • Business definition based on the concept of (A): "Estimate-Negotiation flow", "Billing- Payment confirmation flow", etc..
  • Business definition based on the concept of (B): "Daily Report flow","General Purpose flow", etc..

As a matter of course, it is nothing to say either is better than another on (A) and (B).
Rather, if trying to visualize the operations progress of the company, it is necessary to define the operational areas of the company by combining well both [(A) Managing in Dividing into Phases] and [(B) Managing in Dividing into Simple cycles]. The CIO must consider the ownership of each Business Process (Appointment of Process Owner), on medium-to long-term perspective in consideration of the business strategy. It might be the work more important than the product selection of BPM systems or Workflow system.

By the way, it is desirable that necessary business data to be passed automatically, of course. Speaking in BPMN, it will be connected by "Message Throwing Intermediate Event" and "Message Start Event". For data delivery settings of Questetra, please see <<Related Articles>> following.

[Workflow for comparison]


[Download]
<Similar Models>

<<Related Articles>>