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.
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).
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.
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.
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.