As I work with people trying to analyze processes, I increasingly find myself drawn to the importance of distinguishing between the problems associated with
(1) large scale processes, like value chains and level one processes like Manufacture x and Sell x, and
(2) smaller processes, like sets of activities that can be automated by software applications.
In a sense this distinction is rather like the distinction made in physics between Newtonian Mechanics and Quantium Mechanics, or the distinction made in Economics between Macro and Micro Economics. Rules that apply on one level don't apply so well on another level, and its important to keep the distinction clear in our heads.
When one is analyzing large-scale processes, like a value chain to produce autos, or a large scale business process, like sell widgets, one is primarily concerned with determining how the process relates to external stakeholders — to customers, to external regulatory agencies, or to senior manage that is concerned with a specific ROI. If you seek to diagram such large-scale processes, you want to use a swimlane diagram and show the external processes on the top so that viewers can see how the process relates to its stakeholders. Similarly, you want to label the swimlanes so you can see how the major subprocesses that make up the process being diagrammed are managed by various departments within the organization.
When one is analyzing small-scale processes, the output of the process usually feeds into another process. Thus, the criteria for success are derived from the acceptance of outputs by other processes. Small scale processes are often automated and thus are the primary focus of those involved in software development. One isn't so focused on specific decision points when one considers large-scale processes, but one is often very focused on business rules when one analyzes smaller scale processes.
Another way of talking about this distinction is to use the concept, introduced via the Supply Chain Council's SCOR methodology. They defined a supply chain as level 0, and the three core processes within a supply chain as Scorce, Make and Deliver. The three core processes were termed level 1 processes, and the processes that made up Scorce, Make and Deliver were termed level 2 processes. Continuing in this way, processes that were contained within level 2 processes were termed level 3 processes and so on down to specific activities which were the ultimate, atomic processes, which were usually found on level 5 to level 7, depending on the nature of the process. Following this approach, then Macro processes clearly refer to Level 0, 1 and 2 processes. Similarly Micro processes clearly refer to activities and Level 5, 6 and 7 processes. The dividing linie between the two varies depending on the depth of decomposition appropriate to the given industry and supply chain.
Many business people are focused mostly on high-level Micro processes. They are interested in the interactions of employees with business partners, and planning decisions. Many IT developers are primarily focused on Micro processes, and are interested in how decisions are made in very concrete, specific situations. I have participated in several discussioins where the participants were hardly able to talk with one another because each either assumed concepts appropriate to Macro process analysis or Micro process analysis, and hence didn't seem to hear the other side.
If everyone started using the Macro-Micro distinction and we worked together, as a community, to better define the different concerns associated with each, we would probably find our communications improved.
Is there a difference between a really small process unit (level 7+, called a nanoprocess in one presentation I saw at the BPM conference I just attended) and a microservice (what Amazon calls a primitive)?
Might this be a way to bridge between the BPM community (nanoprocess) and the software development community (microservice)?
The software people understand reuse, but I don’t think the BPM people do.
Brad, I’ve never made fine distinctions about the lower end of the process size scale, except to distinguish atomic activities — which refer to things people or systems actually do. In essence, activities can actually be observed. People greet customers, software applications check if a credit card is acceptable. Everything above the level of activity is a name given to one or more activities. As you progress upward, the process names refer to larger and larger groups of activities. The names help us understand how groups of activities work together to accomplish outcomes.
The issue of reuse is more complex. The idea of standardizing processes (activities) is focused on reuse. We want the Record Customer Information to be the same, no matter what process the activity occurs in, so we get the same customer information each time. Similarly we want larger processes to be the same so we can switch employees and managers and support materials from the Support Sales process in the US to the same process in England with a minimum of fuss.
If we are to entertain the idea of nano-process unit, might we as well entertain the idea of pico-, femto-, atto-, zipto-, yocto-, and so on for names for ever smaller process units? The point being, why only the name “nanoprocess unit?”
Similarly, going upward from a nano-process unit, might we also entertain the idea of micro-, mili-, centi-, deci-, deca-, hector-, kilo-, mega-, giga-, tera-, penta-, exa-, zetta-, yotta-, and so on for names for ever bigger process units?
Or, might we just stick with the highly practical and practicable recursive idea that every bigger process comprises two or more smaller processes and ever smaller process is a component of a bigger process? So why have what can only be arbitrarily named “Level 7+, called a nanoprocess,” when a nano-process unit could be the top-level Level 0 process, representing the whole process of interest?
A beautiful aspect of IDEF0 is that it imposes no cut-and-dried names to process levels, except the generically named “Top Level, Context,” at Level 0 (L0), representing the single L0 process and the external environment within which it exists hence constrained. From there, we could have decomposition of the L0 into L1 processes, then each L1 process decomposed into L2 processes, then each L2 process decomposed into L3 processes, then each L3 process decomposed into L4 processes, and on down to whatever levels of greater specificity required for particular purposes.
And, if progress upward is needed so as to expose ever more expansive context for the top-level L0 process, we could go up from the L0 to include L-1 context processes, then from each L-1 context process go up to include L-2 context processes, then from each L-2 context process go up to include L-3 context processes, and on up to whatever more encompassing levels of contextualization required for particular purposes.