The formal development of my own process view was greatly shaped by the first four books that I read on the topic: Reengineering the Corporation (Michael Hammer & James Champy), Business Process Management is a Team Sport (Andrew Spanyi), Workflow Modelling (Alec Sharp & Patrick McDermott), and The Principles of Scientific Management (Frederick Taylor). An eclectic set that was the result of fairly random circumstances. I’ve read many more since but I’m glad I started with those four because they left me with a very broad process view that can be summarized, as I have noted previously as follows:
Business processes are the conduits through which organizations deliver value to external customers, themselves, and other stakeholders. There is no other way to deliver such value. Functional areas alone are not able to deliver such value. It also follows, therefore, that every organization executes its strategic intent via its business processes.
The profound sequence from strategy to execution is:
For me, being process-centric is not just about modeling, it’s not about being inside or outside, it’s not about IT. BPM is a holistic management philosophy that seeks to deliver appropriate products/services to customers in a way that is sustainably beneficial to all involved.
All processes exist in a complex ecosystem. Being process centric means achieving the equilibrium to optimize value for all stakeholders. We need balance in both rhetoric and actions.
I discuss below some of the more important “points of balance.” We must think carefully about, and act on, the practical realities of these balance points if we are to optimize the delivery of value to all stakeholders. This is Balanced Process Management.
In discussing these points of balance I am not suggesting a contest to determine whether we have A or B. It is clear we need A and B. It’s a question of balance, not choice.
Cross-functional business processes are the only way any organization delivers value to its customers and other stakeholders (including itself). There is no other way. Individual functional entities cannot, by themselves, deliver value to an external customer. The point of process management is to actively and thoughtfully manage the delivery of value to those customers and other stakeholders.
Fiddling about with the Manage Accounts Payable process is unlikely to cause a massive breakthrough in business performance. Way too many people are content to focus internally where it feels safe and warm. However, it is the customer’s assessment of value delivered that is the real – albeit not the only – measure of performance. Any organization that doesn’t have enough happy customers is going to disappear or have radical change imposed on it. This is true whether you are in the public, private, or NFP sectors.
Nevertheless, it’s not just about the customer, but the customer “and other stakeholders.” Certainly the customer is the most important class of stakeholder, but they aren’t the only ones. Every organization has many groups that it needs to satisfy. An airline that has happy customers but unhappy regulators or shareholders is soon out of business.
Every process has a customer, some internal and some external. Some would deny the relevance, even the existence, of internal customers. I believe they are real and important.
Clearly, there are processes, or subprocesses if you prefer, that are internal. Not every process is customer facing. At the highest levels of a process architecture there is direct interaction with the external customer(s). As we go down through the hierarchy we find very important processes that have no direct relationship to the customer. Manage Accounts Payable might be considered mundane and boring and unable to create positive differentiation in the marketplace, but try running without it. The purpose of every process is to deliver value to customers and other stakeholders, and this applies at all levels. Therefore, internal processes (subprocesses) also have customers, which may be other processes or stakeholders. Satisfying those internal customers is vital to the operation of the higher order processes and value chains.
Satisfying, indeed delighting, external customers is vital, but it’s not the complete picture. We must look at the whole process. It is a great idea to start performance analysis at the external customer end of a value chain, but it would be dumb to stop there.
The M in BPM is for Management, not Modeling. No organization has a problem called “we don’t have enough process models.” Process Models are an important element in building shared understanding about how processes work and how they might work better. They are a tool of, not a substitute for, effective management. Much of the criticism that is offered of BPM is based on the incorrect assumption that BPM is about endless (and mindless) modeling. To make that criticism of the BPM concept, you have to first misunderstand what it is about.
There is a point of view that time spent analyzing the current state of a process is wasted; indeed, it might be counter-productive as it entrenches the status quo in the minds of those analyzing the process. Advocates of this view suggest we move quickly to the To Be, perhaps bypassing analysis of the As Is completely, calling on no less a thinker than Einstein who tells us still that "No problem can be solved from the same level of consciousness that created it.” Obviously there is some truth in this and again it is a matter of balance. The As Is cannot be ignored as we need to know where we are starting. A common mistake is to spend more time there than is necessary, leaving the active redesign phase short on time and long on guesswork.
Large-scale process change inevitably requires IT change. Michael Hammer once noted that process change and IT were “joined at the hip.” However, it is a mistake to think that “process change” equals “IT change.” IT systems are just one tool for executing processes, albeit an important one. In contemplating the improvement of a particular process it is useful to consider how improvement might be achieved without IT change. There are many things that contribute to poor performance that are not IT related: staff skills, management, expectations, service level agreements, measurement, and workplace layout, to name just a few. For many processes a major handicap to good performance is in how the process is managed rather than how it is designed and executed. Balancing the role if IT and non-IT process change can uncover effective low cost redesign options.
I’ve used the terms “static” and “dynamic,” but we might also say “predictable” and “unpredictable,” or we might say that this is the difference between knowledge work processes and routine processes. Whatever terminology we use, we need to balance our process modeling and management approaches to support three different types of work: work that is entirely predictable, work where the component pieces (subprocesses) are well known but the sequence is not, and work that is shaped by the dynamic acquisition of information.
A factory process that cuts a piece of metal to length, drills a hole in it, bends it, and paints it might execute many times a day. We don’t want variation. Don’t think about it, just do it.
In a hotel we can define in some detail the processes involved in checking in and out and in using services related to restaurants, bars, room services, gym, car parking, and many more. What we cannot know is which of those processes a particular guest will invoke. The guest’s overall process is emergent. There are common scenarios that we can model and anticipate, but the details of each execution of the process Deliver Guest Experience can only be confirmed after it has completed.
There is a third category, like the hotel but with a demand for much greater resequencing velocity and drawing on changing information from many sources in real-time. Think about basketball. There are well-defined processes like Receive Ball, Pass Ball, Intercept Throw, Shoot Goal, etc. You need to be able to execute those processes well, but overall success is also critically dependent on agile (re)sequencing of processes in a context sensitive environment. This is qualitatively and quantitatively different to the comparatively relaxed pace of the hotel.
We need to balance our need to document and optimize with the reality that not all processes are open to traditional modeling and management, particularly at lower levels.
The essential message of Business Process Management, and a key reason why implementation can be complicated, is this: We (mainly) design, manage, and reward our organizations by functional performance, yet we deliver value to customers and other stakeholders via cross- functional processes. Getting the right balance between functional management and process delivery is at the heart of organizational performance.
Where the emphasis is on functional performance alone we create silos that optimize functional outcomes, perhaps at the expense of end-to-end process performance. Neither is organizational performance optimized by focusing on process tunnels at the expense of functional operations. We don’t want to replace functional silos with process tunnels.
Most organizations do some sort of process improvement. Fewer do process management.
Process improvement (PI) projects focus on particular process problems, more or less in isolation. Processes are analyzed and redesigned with no particular commitment to an ongoing process view of management. Significant improvements can be made in terms of customer service and operational efficiency. Process improvement is a good thing – but it is not process management.
Process management (PM) is a management mindset, a philosophy that results in process-based management. It is not a project. PM delivers a premium benefit by integrating the PI projects and providing an overall context where the dominant view of the organization is process-centric.
Starting with a PM commitment and initiating PI projects in that context, i.e., top down, is undoubtedly the preferred pathway. Where that is not possible, start with PI projects and then “join the dots” to effect PM. Although a longer and probably more arduous journey, this PI2PM pathway can be very effective, resulting in a robust state of natural balance between whole-of- enterprise management and particular process improvement.
Process performance measures are critically important. Without meaningful process performance measures, you can’t be doing process management, and how would you know if you are making process improvements? Whenever we are documenting process performance measures, we need also to describe the measurement method. It might be easy to conclude that a useful measure may be, say, “99% on-time delivery,” but can we easily get that data? Maybe there is already a digital time and date stamp created by an IT system. What if there isn’t?
In every case, consider not just the measure, but also the measurement method.
Modeling, analysis, and presentation tools are important, but they are useless without a sympathetic audience for their outputs. If you have the right mindset, it’s a reasonably simple matter to choose the right toolset. The right mindset means that key stakeholders, especially senior decision makers, are convinced that process-based management is a compelling approach and that there is an urgent need to make it happen. To achieve a truly process-centric organization you need to balance mindset and toolset. This is not to say they get equal time. To get this right, you might spend 90% of your efforts on “mindset” and 10% on “toolset.”
In looking for process improvements, the terminology, and perhaps the mindset, is about finding and resolving problems. It is important to balance that dominant view with the idea that a process without any obvious failure points might still be greatly improved. It’s not just about fixing problems; it’s also about realizing opportunities.
Every organization would like to avoid uncoordinated business process activity with isolated business units constantly re-inventing the wheel. The arguments for standardization are compelling. So are those for variation in response to particular local requirements. As in many of life’s dilemmas, the question is one of balance. The idea of the “one true process” executed consistently throughout the organization is persuasive. The conflicting argument for a primary focus on particular needs at the customer interface is compelling.
We must balance the tensions between the competing cases for standardized global processes versus locally tailored processes? To what extent should organizational energy be expended in enforcing compliance with standards or in managing the variability that is inevitable in complex organizations? Will we achieve standardization at the expense of agility, or do common processes increase the ability to safely and quickly achieve meaningful change?
The purpose of any process is to deliver value to customers and other stakeholders. The purpose of managing the process is to optimize the value delivered to everyone. That’s a multi-variant task to be achieved in a dynamic environment. We need a multi-variant balance of responses.
We need Balanced Process Management.
This was orginally published on www.bptrends.com