Prologue
As stated in the first installment of my Fire and Ice cycle, its ultimate objective is to facilitate preparation of EPCs for BPMN-based automation. However, I strongly believe a different architectural approach to process modeling is needed, too. Here is why.
Process Classification Framework
Bruce Silver’s book BPMN Method and Style is an excellent treatment of best practices related to this standard. In the 2nd edition, he looks at the relationship between business process architectures and BPMNi. Specifically, he analyzes the popular Process Classification Framework (PCF) and is not very happy about it.
The Process Classification Framework was introduced in 1992 by American Productivity and Quality Center (APQC). PCF was originally envisioned as taxonomy of cross-functional business processes, intended to facilitate benchmarking of performance within and among organizations. The framework defines process categories, divided into groups of processes, processes and activitiesii Let’s follow one of PCF’s paths to illustrate the classification schema:
- All what is happening inside an enterprise is partitioned into two broad areas of “operating processes” and “management/support processes”.
- The operating processes are divided into categories, such as “Market and sell”.
- The Market and sell category includes the “Develop & manage sales plans” process group.
- The Develop & manage sales plans group encompasses the “Manage sales orders process”.
- The Manage sales orders process includes the “Accept and validate sales orders” activity.
PCF encompasses hundreds of activities and covers all work one can imagine in a service or product company. The framework could be definitely improved by partitioning some of the lowest level activities. It resembles also a generic organizational structure in most of its parts and processes are hardly cross-functional. Nevertheless, PCF is probably the most widely known and used process taxonomy nowadays. Therefore, I use it frequently to illustrate process decomposition principles and will do so here as well.
Processes and Activities
What is the basic problem with PCF and similar architectures? In the first place, as Bruce Silver notes, it is the concept of an activity and a process. Please recall the official BPMN activity and process definition. A BPMN activity is a unit of work, performed by somebody or something within a process. In addition, a BPMN activity is a discrete action with a well-defined start and end, performed repeatedlyiii. As for a BPMN process, it is a sequence or flow of activities in an organization, with the objective of carrying out work.
Let’s have a look at a sample PCF process, namely “Manage sales orders” (please see the picture below). PCF does not include process maps, so I derived one for experimental purpose. Four of the activities can be wired together to form a nice sequence, but this cannot be done with the remaining ones. Processing of back orders and updates should be split into two activities, but that does not help much. Back orders are processed in the same way as regular ones, while order update can happen at any time. Ditto for Handle order inquiries and Maintain Customer account information, as they also can happen independently of order processing progress.
Does it mean such random, parallel activities are redundant and unnecessary? Absolutely not! Although difficult to coordinate with other ones, such activities are essential for execution of processes. The fact they cannot be inserted into process structures, i.e. cannot be depicted on a process map, means simply just that and nothing more.
Functional Decomposition
As my simple experiment indicates, the Manage sales orders PCF process includes one “true” process and several autonomous activities. It does not matter whether we talk about a BPMN-like process or not. Most definitions of a process stress its internal structure, logic or sequence of activities. In my sample, some of them are clearly not related to others in this sense. In a nutshell, many PCF processes are really no processes at all.
The other problem I see with the PCF framework resides in the second word of its name. PCF is not really based on classification, as lower level elements are not subtypes of the element aboveiv. Instead, it is based on functional decomposition method. A function is usually defined as a set of related activities that supports a particular aspect of an enterprise. Each higher level parent function is partitioned into many lower level child functions, until a satisfactory level of detail is reached. The relationships between child functions are not considered. Simultaneously, all child functions and only those functions are required collectively to realize their parent.
The objective of any functional decomposition is to arrive at a set of lowest level, detailed elements, called leaves. They are what really counts in the end, while all the levels above have secondary importance. PCF is no exception and it is essentially an inventory, a hierarchically organized catalogue of what is or should be done in an enterprise. On its lowest level, it encompasses activities of various types, such as:
1. Discrete, repetitive and structured activities related to each other
2. Discrete, repetitive and structured activities executed randomly
3. Continuous activities without clear beginning or end
4. Relatively infrequent activities without predetermined structures
End-to-End Processes
PCF provides generic building blocks, i.e. activities, required to produce goods or deliver services, to take care of requisite resources and to manage work within an enterprise. Therefore, it is a valuable tool to support allocation of responsibilities and design of organizational structures. At the same time, its constituent discrete activities can be used to configure truly cross-functional, End-To-End (E2E) processes in a bottom-up manner. The next picture illustrates how PCF hierarchy can be used for that purpose.
The sample Order-To-Cash process is assembled out of activities picked from overall pool and located in several branches of the PCF hierarchy. It begins with Accept sales order and ends with Post receivable entry activity. Each of the discrete activities within its scope is a mini-process and can be partitioned further into tasks, glued together by process logic.
Other E2E processes, such as Idea-To-Market, Market-To-Order or Source-To-Pay, can be also assembled in the same way. If this is done for the whole enterprise, the end result would be a set of E2E processes, surrounded by parallel, auxiliary activities; much like a bunch of sharks is flanked by pilot fishes. Obviously, E2E processes would be portrayed on process maps, but the ad-hoc, random activities do not belong there. The only model where such activities can be defined, together with their more fortunate brothers and sisters, is the decomposition hierarchy.
Epilogue
Decomposition hierarchies lost favor with business process analysts long time ago. Business process analysts preferred to use hierarchies of process maps instead and functional decomposition became a forgotten art of managing complexity. Nevertheless, I am convinced functional decomposition and activity hierarchies, such as PCF or other ones, are the missing link between BPMN and enterprise-level BPM, as well as Enterprise Architectures. Moreover, they are also indispensable for proper structuring of BPMN processes in larger-scale efforts. I shall provide proof in the next installment.
See also my other posts on BPMN topic:
- Fire and Ice. Part 1. BPMN 2.0 Today
- Fire and Ice. Part 2. BPMN Conversations
- Fire and Ice. Part 3. BPMN Collaboration
- Fire and Ice. Part 4. BPMN Process Models
References
- i - See Bruce Silver, BPMN Method and Style, 2nd Edition, Cody-Cassidy Press, 2011
- ii - The most well known is a generic, industry-neutral PCF framework. In 2008, APQC and IBM worked together to enhance the cross-industry PCF and developed a number of industry-specific process classification frameworks.
- iii - Bruce Silver, ibid, p. 10
- iv - Top levels of a framework such as SCOR (Supply Chain Operations Reference model) or VRM (Value Reference Model) are truly based on classification.
Thank you for calling attention to this issue. I have long been dismayed both by the lack of precise definition of BPMN's most fundamental concepts in the specification, and by BPM architects' refusal to recognize when their terms 'activity' and 'process' mean something different from BPMN's meaning. The key thing is the notion of the instance of an activity or process, and instance alignment of all activities in a BPMN process.
Bruce, many thanks for your comment. We are indeed in a conceptual trouble. On one hand, BPMN specifications are devoid of precise process and activity definitions. On the other, there is a big diversity of such definitions elsewhere around us. In general though, I think every process belongs to a continuum between a predefined process type and an improvised one. For a pure predefined process one can specify its detailed structure in advance, i.e. it is possible to define its content and logic ex ante. In case of a pure improvised process, one can discover its detailed structure ex post, i.e. only after completion.
Depending on its mission, a process architecture should include either processes of all imaginable types or just a required subset. If a process architecture exists to support a broad range of process and organizational change projects, then it should include all processes. If it exists to support process automation, then only processes of the predefined type should be there.
As for the instance alignment concept, I will use it extensively in the next installment.
Thanks for the insightful post. You mention the link to Enterprise Architecture (EA). Recently, in many IT-driven EA-approaches the concept of business capabilities has become very popular. In my view, a hierarchy of business capabilities is also just a kind of functional decomposition - and therefore not really new. An interesting question is how you decompose functions. You can use different criteria for that, such as decomposition according to processed objects or activity types. For example, if you have an activity "Manage insurances", you could decompose it into "Manage car insurance", "Manage life insurance" etc., or you could decompose it into "Handle insurance application", "Claims processing" etc. It can even be useful to have several functional decompositions in one company, each for a different purpose. If you strictly follow a specific criterion, activities may appear more than once in the hierarchy. The activity "Post receivable entry" may not only be required in "Invoice customer", but also in a reverse charge procedure. For capabilities, is is usually required that each capability only appears once. Each capability then "belongs" to exactly one parent domain or high-level capability. This has the advantage that there are unique ownerships and responsibilities, which is important when you implement low-level capabilities as automated services. Obviously only one team should be responsible for implementing and supporting a specific service. This means, that you usually mix decomposition criteria when you create a hierarchy of capabilities.
I agree that the PCF is not consistent in its breakdown but nevertheless it has some advantages to standardize on an existing framework - first of all, not every company is unique and has unique processes (even if customers tell you something different of course ;-) and you might "tweak" the assembly of lower-level processes here and there, but in a nutshell a grocery chain is a grocery chain is a grocery chain. In my opinion you will have to combine the some lower level processes and normalize the structure to a consistent leveling.
This, and this is the second point, allows to benchmark and compare. APQC also includes KPI definitions and that -combined with other sources- allows you to define the measurement your performance. We (and I mean our famous Dave Brooks) did this with the SCOR KPIs in a Mashup for different industries and it is always and eye opener when clients see themselves compared to their competition ... and the underlying SCOR data is available from the Supply Chain Council.
These two reasons alone are a good enough to think hard about using a reference framework as the starting point for your process development effort. Our friends from Accenture and Nimbus do have a white paper of a study they did with APQC out there where you can read more reasons to do so (unfortunately I lost the URL, but Google is your friend here).
In reply to There is an online shop where by sstein
Roland, many thanks for another valuable comment. I had a look into the Best Practices Report you mentioned, very useful. Please note however my remarks on PCF referred only to some of its technical properties, troubling a bit particularly when process automation is the target use case.
I am sure PCF is a very valuable tool, particularly when coupled with KPIs and benchmarks. I use it during my lectures to illustrate basic properties of process architectures, I also promote PCF to students and encourage its use. I see also a great potential for PCF as a foundation for organization design on strategic and operational levels alike. As a matter of fact, I think it is the most complete, widely available generic inventory of all types of activities. Therefore, PCF could be used to support virtually any type of organizational and process change projects.
Professor, your comment is appreciated very much. You are right, there are many ways to perform a functional decomposition. Nevertheless, if it is done deep enough and in a consistent manner, one should always arrive at the same set of elementary lowest level elements. These can be assembled later in a bottom-up fashion, aggregated if you will, to form different hierarchies. This technique is used extensively in IPR reference models at Software AG.
Now for business capabilities. Indeed, they are en vogue nowadays. However, the discussions and ideas on this subject in EA community are similar to reinvention of the wheel in my eyes. The concept of capabilities has a long tradition and a large following in strategic management discipline. Actually, it is a whole academic field, based on a premise of capabilities as a strategic resource, required for a long-term survival or sustained competitive advantage.
The subject is covered at length in my article The Process-based View of A Company - Principles and Applications, published by BPTrends. In a nutshell, a particular capability refers to the capacity of an organization to perform a coordinated set of tasks, for the purpose of achieving a particular end result. Capabilities constitute a collective know-how and are combinations of complementary skills and knowledge. Operational capabilities are required to produce products and deliver services, i.e. to execute processes, using consumable and resident resources. Dynamic capabilities, which represent a company’s collective know-how in adapting to change, are required to change processes and to modify or expand their resources. I think it is better to use those concepts, due to advantages of inter-discipline consistency.
