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

The Leonardo Blog

5 Key Elements to BPM Governance

All Posts

5 Key Elements to BPM Governance

2019 Blog Images (3)-1

The ultimate outcome of effective BPM governance is the proactive, efficient management and continuous improvement of the set of processes (and their sub--processes) by which an organization delivers value to its customers and other stakeholders.

Here are five key elements to BPM governance:

1. Measurement

Measuring process performance is fundamental. Whatever else we are doing, if we are not doing effective process performance measurement, and responding to those measurements, then we certainly aren’t doing process management, and how would we know if we are doing process improvement? Without agreed process measures (and measurement methods), the concept of BPM governance is meaningless.

2. Ownership

A Process Owner should be appointed to every process in an organization. Yes, every one of them. Assign Process Owners starting from the top, i.e., from the highest level of process or value chain. A Process Owner always “owns” all of the subprocesses of that process as well. There may be specific other people who are the Process Owners for the subprocesses, but there doesn't have to be, and, in any case, that doesn't change the higher level ownership. Processes at any level are assigned specific Process Owners when some aspect of that process requires closer management and control. Ownership of subprocesses might only be required for a time and then ownership at that level is dissolved (higher level ownership remaining).

So although every process needs to be owned, we want to have as few Process Owners as is reasonable to cover the higher levels of a process architecture. Remember Einstien’s advice to make things as simple as possible, but not simpler.

As we move down through a hierarchy of processes (subprocesses), we eventually reach a point where processes are bounded by a single functional area. These intra-functional processes still need to be managed, but this becomes indistinguishable from functional management. Process ownership is materially different to functional management only when the process is cross- functional.

I'm less engaged with the question of what to call the Process Owner position – coordinator, sponsor, manager, steward, guardian, supervisor, controller, director, custodian, principal – than with what people do in those positions and how they are held accountable. You need a title that works in the organization, but there's a danger that we will argue about the title to  avoid discussing the core issue of accountability. Much more important than the title is  clarity of purpose and the consequences of failure.

3. Accountability

The role of Process Owner is about leadership not administration. It is not a clerical position. Accountability for a process essentially means being tasked to respond appropriately to the current and forecast performance measurement data. Being accountable for a process does not mean you are the one who is taken out and shot when the performance deteriorates. It does mean though that you are the one who needs to care about and understand the cause of cross- functional process performance variation and propose a corrective course of action.

The owner of a cross-functional process is unlikely to be the functional manager for all parts of the process, perhaps for none. Because of the cross-functional aspects, the Process Owner role is more about influence than authority. Process Owners should not be asked to influence “up” in the organization; their active targets of influence should be peers or subordinates. Especially for higher level processes, therefore, Process Owners need to be senior staff. Not only does this give them more chance of exercising influence, it means that they are people with authority, capability, and resources.

4. Control

This can be the most difficult bit. How much control should a Process Owner be required to exercise? There is a balance to be struck between being the “process police” and a collaborative leader. The key things that need to be controlled are these:

  1. the “process of process.” i.e., the framework for process management and improvement
  2. modeling conventions
  3. process model change control

For an organization to have a consistent approach to process-based management there needs to be a consistent framework and methodology. Like all other processes, this should be subject to continuous review – but in a controlled way. Building organization-wide BPM capability requires a consistent approach.

All process modeling activity throughout an organization should be contributing material to a central repository of process. This provides a valuable resource for use and reuse by all. It builds breadth and depth of understanding about the mosaic of processes that form the organization. Consistent modeling is mandatory to achieve these ends. Implicit in this requirement is that a detailed enterprise process architecture shapes the repository.

Perhaps most difficult of all is the requirement to exercise change control over business processes and their models and other documentation. Process Owners need to be involved in the formal approval of process changes. Even in the steady state condition of an organization with a high level of BPM maturity, this can be the most time consuming activity. Continuous improvement means continuous change. The process by which process change is controlled needs to be efficient!

In all of this, it is important to remember that the individual Process Owner is not the one doing all of this work. The role of the Process Office or BPM Center of Excellence is critical here. They should be doing the heavy lifting, leaving the Process Owner to remain focused on strategic process management and leadership. Process ownership is about management, not modeling.

If all of this control activity sounds a bit too onerous, imagine a future scenario where the business folk hand over process models to their IT colleagues who then arrange for the models to be executed directly?

  1. Will we be quite so relaxed about giving modelers license to make changes on the fly to live business processes?
  2. How will we reconcile the very different objectives of wanting to describe versus needing to control?
  3. If your organization had an F9 (recalculate) button, who would you allow to press it?

5. Support

Process Owners must be supported. It is very likely that people newly appointed to Process Owner roles will need training and coaching. Process management requires a different mindset, and we should not assume that Process Owners arrive fully formed.

The organization must make the mandate of process ownership clear, and support the practical exercise of that mandate. Undermining the authority of a Process Owner with  inconsistent support will kill BPM governance.

Process Owners need performance data about their processes. They need this in an appropriate format and delivered in a timely manner. Whether this is a real time dashboard or a monthly report will depend on the nature of the process. Process business intelligence is the lifeblood of BPM governance.

Having a Process Office is a necessary, but not sufficient, condition for BPM governance. The Process Office should be the main source of support for Process Owners, providing advice and guidance as well as data and logistics assistance.

Another common source of support for Process Owners is a form of “Process Council” that has the group of Process Owners from the same level meeting regularly to share experiences (and resolve inter-process issues).

Much has been written about BPM governance. Apart from the BPTrends website, there are good insights in Paul Harmon’s book Business Process Change and Andrew Spanyi’s book More for Less: The Power of Process Management.

New Call-to-action

This artilce was orginally published at BPTrends.

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

Leonardo wins 2020 Red Hat ANZ Professional Services Partner of the Year

Red Hat announced Leonardo as their 'ANZ Professional Services Partner of the Year'. This is the third year in a row Leonardo has been recognised at these regional awards, and we're extremely honoured again for this acknowledgement. Well done to Team Leonardo for your superb work delivering great outcomes for clients - and to Red Hat Asia Pacific for their amazing partner growth and results over the past year.

Leonardo Invests in Apromore to advance AI-Driven, Open-Source Process Mining Technology

MELBOURNE, AUSTRALIA – 7 July 2020 – Leonardo today announced its investment in Apromore - a leading developer of open-source, AI-driven process mining technology. The investment forms part of a Series A round of funding totalling $A6.8 million, led by German business process management specialist GBTEC, and also included The University of Melbourne, which helped to incubate Apromore prior to spin off.

Leonardo wins 2019 Red Hat Hackathon - Customer Experience with OpenSource

      We're thrilled to share with you that Leonardo has won 2019 Red Hat Hackathon 'ReBoot Customer Experience with Open Source'. Early on Friday morning ( 5am AEDT 13th December 2019),  Leonardo awarded first place from a field that included 320 participants from across the globe.  The Hackathon's brief was to reinvent customer experience using Open Source. Providing an outstanding customer experience that customers actually love is especially challenging in more traditional industries like banking, insurance, telecommunication, public sector/government, healthcare, manufacturing, or transportation. These markets offer great opportunities for change and disruption as has been shown by many examples such as Uber disrupting transportation, Twilio disrupting telcos and Stripe or Transferwise disrupting banking.  We want you to be the next disrupter who creates a customer experience that users actually love.  An Open Source solution - ACE  Airline Customer Experience Our project is an application using a Red Hat Process Automation Manager process-as-microservice developed for "ACE Airlines", our fictional client (see video above for the demo). It communicates personalised, event-driven (gate change, delay, etc.) messages to passengers in the language of their choice, using their preferred communications type (SMS, push notification, email).