<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

12 Principles to Follow When Balancing Process Management

12 Principles to Follow When Balancing Process Management 1

We need Balanced Process Management.

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:

  • Organizations exist to deliver value to customers and other stakeholders. That’s strategy.
  • They do this via a series of coordinated activities across a number of functional elements of the organization. That’s a process.
  •  It makes sense to optimize these processes so that they satisfy the requirements of customers and other stakeholders. That’s process improvement.
  • Taking a coordinated view of the performance of the processes by which an organization delivers value optimizes performance. That’s process management.
  • Process management allows organizations to focus on processes that create the market differentiation described by the strategy. That’s execution.

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.

Points of Balance

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.

Customers and Other Stakeholders

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.

Internal and External Customers

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.

Modeling and Management

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.

As Is and To Be

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.

Watch 7 Enablers of BPM Video

People and Automation (IT and Non-IT)

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.

Static and Dynamic

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.

Process and Function

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.

Management and Improvement

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.

Measure and Measurement Method

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.

Mindset and Toolset

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

Problems and Opportunities

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.

Common Processes and Variations

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?

In Summary ...

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.

New Call-to-action\

This was orginally published on www.bptrends.com

 

Roger Tregear
Roger Tregear
Roger is a Consulting Associate with Leonardo. He delivers consulting and education assignments around the world. This work has involved many industry sectors, diverse cultures, and organization types. Roger briefs executives, coach managers, and support project teams to develop process-based management. Several thousand people have attended Roger's training courses and seminars in many countries - and Roger frequently presents at international business conferences. Roger has been writing a column on BPTrends called Practical Process for over 10 years. This led to the 2013 book of the same name. In 2011, he co-authored Establishing the Office of Business Process Management. He contributed a chapter in The International Handbook on Business Process Management (2010, 2015). With Paul Harmon in 2016, Roger co-edited Questioning BPM?, a book discussing key BPM questions. Roger's own book, Reimagining Management, was published in 2016.

Related Posts

10 Common Problems in Container Adoption - And How to Fix It

The Compelling Origins of Containers A number of years ago, it become clear that the rise of container platforms was more than just a passing technology trend.  A genuine technology shift was taking place that would undoubtedly change the IT industry forever. Early indicators were everywhere.  Investment by the largest software industry giants was significant, as was their marketing positioning.  Pivotal and IBM were aggressive with Cloud Foundry and Blue Mix.  Red Hat was progressive with Openshift and receiving industry praise.  Docker Inc stormed onto the scene.  Then Google started the Kubernetes opensource project with immediate impact. Locally, there were also strong indicators.  MeetUp groups were started and quickly became well-attended - especially the Docker meetups based in Australia.  In the early days, the meetings were sold-out, and eager attendees weren't able to secure a spot.   After a humble start, the Kubernetes MeetUp was became very popular and continues to be so to this day. There was something brewing, and everyone wanted to be a part of it.

The Process Life — What's It All About?

What's it all about? If you google "what's it all about" you get 4.5 billion results. Seems that we are keen to answer that question. Of course, it would be much more useful if there were just one answer. I have a similar experience when I ask people what they understand by "business process management" and related phrases. [2.5 billion, in case you were wondering.] It would be of significant benefit if there were just one answer here also. Good news! There is just one answer. The bad news is we all agree with that but have a different version. The great news is that we can solve this problem — if you all repent and agree with me!

Why BPM Maturity is an Untapped Organisational Superpower

  Processes deliver Every organization makes promises to customers and other stakeholders. Such promises are its reason for existence and are shaped as value propositions in the organizational strategy. Traditional management follows the organization chart with most management activity directed up and down that chart. But how do we get work done? How do we deliver on those promises? We work in collaboration across the organization, not up and down. Is there any box on that chart that can, by itself, deliver products or services externally? No there is not, that’s not the way it works. Processes deliver on our promises.