About  |  Benefits  |  Join  |  Online Training  |  Training Courses  |  Certification  |  Wiki  |  Contact
Don Smith
Director, International Process and Performance Institute (IPAPI)

Process Modeling and Levels of Abstraction

 

I recently received an email query from a member in regard to Process Activity Lists (PALs) I would like to share because it was an outstanding question and one I think a lot of members might have.   The query was:

 

Hello,

I am puzzled how PALs (Process Activity Lists) can be used to fully represent Processes. I am used to working with BPMN and divergent paths based on decisions (e.g. if product is IN STOCK follow one path, otherwise follow another). I am not clear how PALs represent this. In the CEM Optimize method, sequential activities, allotted to an actor, are joined by a line ... if a decision point were reached, then the line would surely split. For example, suppose that the case study referred to provision of internet services and a diagnostic revealed a line problem versus a router problem or a customer configuration problem. Further suppose that each diagnosis required different subsequent flow... How would a PAL represent this?

 

To appropriately answer this question, we need to start by putting anything we might use to represent a process in proper perspective.  No mapping tool or map can "fully represent" a process as anything we develop to represent the process is an abstraction (i.e. the map at some level represents the thing but is NOT the thing).  What we need to consider is what level of abstraction is relevant to any given process related activity or objective. 

 

One of the best examples of this principle is the use of mapping or GPS software for creating a travel route.  When our objective is to see the overall route and/or our relative position on the route, it often requires a higher level of abstraction (the big picture).  However, when we are trying to navigate at the street level, a much lower level of abstraction is required.  The original high level view is of no help at that point and visa-versa. 

 

When it comes to process, if our objective is to provide detailed documentation of a process for system development or other detail oriented reasons, a PAL is not the right level of abstraction.  However, when performing Optimization or Alignment analysis, it is exactly the right level of abstraction because it keeps us from the detail which does not help us in those activities.  In fact, it is often a high level of process detail that gets process improvement activities mired and "lost in the weeds."