Guideline: Decomposing Business Processes
This guideline provides tips regarding decomposing business processes.
Relationships
Main Description

The level of business process detail that is initially created by a team of business analysts might be insufficient for follow-on work that focuses on realizing the business process.  In that case, the process must be further decomposed until it is fit for the required purpose.  This guideline provides some advice regarding approaches to process decomposition.

As is discussed in Concept: Business Process Decomposition, business process decomposition can result in a hierarchy of processes and sub-processes, which eventually end in leaf-level sub-processes that leave us dealing with fine-grained user actions.  The following figure is duplicated from that concept to illustrate a possible process hierarchy.

                        

Each level of process decomposition can involve a drill-down through the organizational functional structure that was used to describe the previous level of the process.  So, a process description might involve the interaction between business domains, which are the largest concepts used to describe business functional structure.   At the next level, the sub-process that is the responsibility of a given domain might be analyzed in terms of the interactions between the functional areas/business systems that comprise the domain.  Yet another round of decomposition might find us examining how the sub-sub-process which is the responsibility of a given business system might be realized by interactions between the business workers the business system owns.

The recursive nature of the process decompositional drill-down calls out for a system-of-systems approach, where the behaviors (processes) at each level of the overall system (that is, the business) are discovered using a consistent method.  Further, the transition from one level of the process to the next needs to be managed consistently.  Rational's Model Driven Systems Development (MDSD) method is a useful approach for achieving a high degree of consistency in representation and technique as you progress through your process decomposition.

As we decompose the business processes, there are several things to consider and document:

Actors -- Each level of process description potentially will have a different set of actors.  At the top-most level, the actors are the actors which interact with the enterprise as a whole.  At the next level down, as we isolate (for example) a given domain to understand how its functional areas interact to realize the sub-process for which it is responsible, the enterprise actors remain -- but the other domains also become actors!  Upon isolating a functional area for the next round of process analysis, the actors (for that specific analysis) become the actors the domain dealt with -- plus the other functional areas within the domain! 

Events -- We need to identify the events that trigger a process or sub-process.  Identifying a process (or certain of its steps) as being event-driven can provide hints regarding requirements that any automated implementation support (for example) publish-and-subscribe event notification. 

Business entities that are involved in, or transformed by, the business process.  This knowledge is important for subsequent specification of service messages and service operation signatures.

Opportunities for automation.   All steps in a business process are not well-suited for automation, and others certainly are.  Be focused on discriminating between these two.  Lack of discrimination can lead to wasted effort on the one hand, and missed opportunity on the other.  One caution, though -- be aware that what might not be a good candidate for automation today, might be a great candidate later.  Be sure to flag manual process steps that are particularly costly or error-prone.  They might be good candidates for consideration at a later time.

Geographical distribution among the entities that are involved in executing a process.  Spatial distribution of processing elements can impose more taxing non-functional requirements on process elements.  The sooner this is realized, the better.


More Information