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.
|