Hi, Can anyone tell me how they go about using process decomposition in a project or function decomposition .

Thank you,

Mike.

Hi:

First point (and from your question, you may already be aware of this, but bare with me):  A common misconception goes something like this: Business tasks are described using process diagrams, and functions are used to described what systems do (where it is assumed that a system is a computer system).  Reality:  A system can consist of entirely manual functions (no computers at all) accomplished by business people.

Second point:  Decomposition is most applicable for larger scale efforts.   Indeed, decomposition is a means of handling complexity.   And at higher levels, especially for complex systems, systems are what Data Flow Diagramers refer to as asychronous.  That is functions (or processes, or whatever you want to call them) can happen in any sequence, and, in fact, often can happen symultaneously.  In other words, at higher levels of abstraction, there is almost always no defineable sequence, so sequence based modeling techniques are not appropriate.   This is a huge defect with BPMN.  

Understanding that, at higher levels of abstraction, decomposition needs to be via a non-sequential modeling technique is by far the most important thing to remember, as proper decomposition at the higher levels is the key to success.

Tony

Hi Kimbo:

I am currently working on project to standardize operations between engineering and manufacturing groups.

It is extremely important not to think that functional decomposition and process decomposition are two seperate things.  Again, data flow diagrams can be used to model entirely manual processes accomplished by business people - totally without the aid of computers.

You are right in saying that structuring random requirements into a structured, concise set of functions is what BAs do.   And with Data Flow Diagrams, at the lower levels of a decomposition, we transition from none-sequential diagrams (i.e., data flow diagrams) into sequtial diagrams (i.e., BPM like diagrams).  At the more detailed level, a sequential process exists.   But, especially for larger scale systems, at the higher levels of a decomposition, systems are characterized as having processes that can occur in any order or even all at the same time - there is no identifiable sequence.

For an example of what I am referring to, look at the BABOK 2.0.   The BABOK 2.0 is essentially a functional spec on how to create a functional spec.  It has the signoff of the "experts" (the people who lay claim to setting a gobal certification for BAs).  As is discussed in the first parts of the BABOK 2.0, the handbook is organized around sequence independent input/process/output diagrams because the processes that it talks about can occur in any order - that is there is no identifiable sequence for them.  (An obvious question is why did they use poor-man's data flow diagrams (i.e., non-integrated data flow diagrams), but that is an entirely different thing.)

And the scope of processes that the BABOK 2.0 covers is really not all that extensive.   For an larger scale systems effort, the non-sequential nature of the systems processes/functions at higher levels of abstraction is much, much more evident.

Analysts often say that UML techniques can be used to accomplish a decomposition just as easy as with Data Flow Diagrams.   That is saying that a forced, artifical decomposition is just as good as a logical, natural decomposition.   I strongly disagree.

Tony