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]