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.