We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

BPM: Theory to Practice

Tim Huenemann

Process Models - Aligning the High and the Low (Part 1)

Vote 0 Votes

It can be a difficult task to create end-to-end process models that communicate effectively across an organization. When discussing an organization's overall value chain, and providing a big picture process architecture from the top down, it is best to stay at a high level, perhaps at level 1 or 2 of process decomposition. At this point, you might have processes such as "develop marketing strategies," "procure materials," or "deliver products." Obviously, at this high level, we are still abstract. You can put the processes in sequence, but you can't really flow from one into the other. They are more function or capability-oriented (no, function isn't a dirty word!) and don't represent actual workflow. This is more a process architecture or value chain-style model as opposed to how work gets done.

High-Level Example
For example, in an overall end-to-end view of a manufacturing company, R&D processes indeed occur before the supply chain processes that procure materials to make the products. And in a high-level model, "design products" will lead to "procure materials." But at the lower level, such as where you are start to do flowcharting or BPMN diagramming, R&D processes are independent of supply chain processes. They start and end in their own scope and their own cycles. There is not necessarily any workflow at all that connects "design products" to "procure materials." The same scenario occurs even within a particular process area, such as supply chain. A level 2 model for supply chain may show "establish supplier relationships" and "procure materials" back-to-back in sequence. This makes sense when presenting a company's overall operations in a high-level model. But when you get down into the workflow, they are actually independently initiated in an unsynchronized manner.

The Transition from High to Low
I'm a firm believer in top-down process architecture work, whether for strategic, future-state purposes, or just to provide a structure for understanding how an organization currently operates. Having said that, when drilling down, how does a high-level model transition from the abstract, architectural perspective into the concrete, workflow perspective? Do you find that at level 3 or so, there is an abrupt transition into process flows that don't nicely fit into the structure that exists one level above? I regularly see this occur. Sometimes it is caused by the difference in perspectives and motivation. At the high level, people want things to be simple to understand, and easy to organize and diagram. An executive summary view, if you will. Processes are generalized and alternate paths are ignored. And as described above, similar to the value chain concept, sequence is instituted among unsynchronized processes. Obviously this sort of model is not going to decompose nicely into lower-level workflow models.

Disconnect between High and Low
Another cause of a disconnect between high and low-level models is that different people/projects create the models. For example, project A creates a high-level process model of your sales and service processes, as part of a compliance initiative. But then project B creates low-level models of sales and service for a training effort. And never the twain shall meet!

For Next Time
In summary, there are lots of forces that hinder the alignment of high-level models with lower-level work. What can be done about it? And why should it matter, anyway? In my next post, I will cover some techniques to improve this alignment and some reasons why it's worth caring about it.

Continued in Part 2

Leave a comment

This blog offers a true “practitioner’s perspective,” with issues and commentary based on real-world experience across many industries.

Tim Huenemann

Tim Huenemann is the senior principal for business architecture and process management at Trexin Consulting. He has more than 20 years of experience in process management and business-focused IT. In his consulting work, he helps organizations execute business strategy by implementing effective process management and IT solutions. He regularly translates BPM theory into practice, and practice, and more practice. Contact Tim at tim.huenemann[at]trexin.com.

Recently Commented On

Recent Webinars

    Monthly Archives