Business Process Management: The Seven Deadly Sins

You thought Business Process Management was a comparatively safe field. Think again! Stay clear of these seven deadly sins of BPM - to avoid eternal condemnation or the need to beg forgiveness. I should add it’s a personal view and apologies for any of you who were hoping for more on lust or gluttony!

Woe unto he who uses the term ‘management’ when they really mean automating.

Business process management means many things to many people. Just take the words ‘process’ and ‘management’ alone – different people see these quite differently according to their perspective⁽¹⁾. For many BPM vendors and practitioners alike process management has come to mean process automation. Automation is important but it doesn’t constitute Management. From my perspective Management implies good governance,; each process should be seen as an important asset and therefore owned, understood, correctly applied and improved continuously.

The end goal is improved performance. That improvement may involve automation, but not in all cases. After all – if you look at the activities in your business the vast majority are performed by humans not machines and that’s not going to change any time soon. What irritates me is that so many of the automation focused tools which purport to offer BPM, offer little capability with respect to Management as I define it above. The result can easily be the automation of processes which are suboptimal, not properly understood, not properly applied and not continuously improved.

⁽¹⁾ Perspectives: An earlier paper "What BPM Hat are you wearing?" explores the different process perspectives of four main stakeholder groups: End Users, IT, System providers and Risk / Compliance. Access the paper here.

Verily I say unto you that work shall be end-to-end lest ye be functionally silo’d.

In reality, processes start and end in very different places in the enterprise, often spanning multiple functional areas. There is a risk therefore that process improvement efforts are too narrowly silo’d. The effect? Different departments fix just their part of a larger process.

It’s difficult to influence what happens either upstream or downstream from that part. And yet improvement of the full end-to-end flow requires collaboration along the full path. The failure to achieve such consensus could result in worsened performance, as a fix in one silo could be a retrograde step for another.

A similar challenge is that different specialist projects spring up all the time that duplicate each other’s process discovery efforts because the organization lacks a central repository for process knowledge. Take a typical ERP or CRM project as a good example. A team of consultants from a system integrator create a bunch of Visio diagrams. Their use is temporary. Once the system has gone live or the upgrade is complete – typically the content sits in a forgotten network folder and is never referred to again. Five years on – time for an upgrade. The content - if found - is regarded with suspicion. It’s out of date. The next SI (often a different company) does exactly the same – recreating a bunch of content that has little or no residual value.

Meanwhile, there are all sorts of other projects going on, that all aim to understand and improve process. For example: Compliance, Quality, Risk Management, Shared Services, Outsourcing, Lean, Six Sigma, Merger / Acquisition, perhaps others as well.

In a typical business few of these projects share a common source of process truth. Just imagine how much duplicated effort and waste could be eliminated if all of these projects started off with a single source of process truth…a repository of process knowledge that was commonly understood and trusted as up-to-date. It would not only speed up progress for each project, it would enable new ways to demonstrate or enable:

• Regulatory compliance (such as FDA, EPA, SOx)
• Compliance to quality standards (such as ISO, TCF)
• Employee training and task performance support
• Performance Management where scorecards and metrics are tied to relevant processes activities
• Customer journeys
• Alignment to frameworks (SCOR, APQC’s PCF), and more.

Moving process management efforts from multiple silos to a shared enterprise asset creates the opportunity for huge efficiency gains, and the capability to start leveraging that asset far more powerfully for all manner of business initiatives.

Ezekiel saw the wheel, but he didn’t reinvent it.

If starting a BPM initiative means starting with a blank slate on which you draw, you’re likely reinventing the wheel. Process frameworks were developed to avoid exactly this issue. Through the use of frameworks like APQC’s PCF, ITIL, or the Supply Chain Council’s SCOR Model, process can be arranged in a hierarchy that has the benefit of thousands of contributing voices and is vetted by use in many industries.

Seeing a standardized structure and language for process activities gives the following quick benefits:

• Content management – like a ‘Dewey Decimal System’
• Benchmarking and metrics
• Sidestepping personalities and political motivations (‘inconveniencing everyone equally’)
• Scoping of effort and gap analysis
• Preventing duplication

When you see this list, you can see that not taking advantage of these benefits considerably slows process discovery and documentation.

As an added bonus, there are likely process ‘snippets’ in disparate databases all across your enterprise, and getting them together in a meaningful way is very challenging if you don’t have a central framework on which to hang them.

Seek and you should be able to find very easily.

All too often, users are asked to navigate process content on crude websites, intranets or in directory/folder structures to find the key information needed to perform their work. If the worker sees much more than is relevant to their position, the likelihood that they’ll come back to the repository as a knowledge source or work aid becomes more and more remote with each frustrated effort. On the other hand, if the system is role-based, it offers each user personalized, easy access to the process content relevant to their role in the organization. In that way the process repository can become a useful performance support system, like an electronic mentor.

Personalization means more than having login credentials. People have compound roles – serving more than one role in their organization. At one moment, I may be a hiring manager, under the guidance of an HR-owned process, and in another I am a rank-and-file employee that must perform safety procedures in a prescribed, approved manner.

Rather like context sensitive help available from most application software, the process repository should offer me easy access to the process information I require in relation to a task or my role. The absence of such personalization and effective search capabilities leads to information obfuscation and organizational confusion.

Thou shalt assign an owner and that owner shall be accountable.

For any information to be trustworthy, someone who can authorize its initial use and any subsequent changes must own it. Assigning ownership to process is the key to making sure that the people accountable for the success of a process have the proper authority to approve and change what they own. While it seems straightforward, this capability is all too often missing from BPM applications.

Once ownership is assigned, there should to be a systematic way for people to suggest changes, and for that owner to approve or reject those suggestions. If this capability is lacking, you’re going to have a hard time engaging your workforce in continuous improvement, and the tendency will be for content review to become a sporadic and inconsistent effort.

Providing access to out of date information will quickly discredit your process repository, causing users to defect to the old ways of getting work done.

Yea, do not confuse thine followers with strange tongues.

Process diagrams need context to give meaning to their symbols and lines. For process to be understood by the end users, it needs to be expressed in symbols that are intuitive and easy to follow. The documents, forms, links and other information that supports those symbols and lines needs to be available at the time the diagram is viewed. What’s more, the documentation needs to be owned and managed by its owner to be relevant and trustworthy. My favorite example of why this matters is the "Interview Candidate" activity.

Figure 1: Ownership and Execution Model

The figure shows how the owner and executor of a process step are often different. And yet they must share a consistent and up-to-date understanding of the approved process. That information will often need to be localized, (according to regional regulations and company practices,) at the time the activity is executed.

Another example is the procurement process, which is often owned by the global supply chain manager at a macro level and executed by someone elsewhere in the value chain using the services of a procurement resource. To get these disparate functions to operate in a coherent fashion requires that the process is not just centrally managed but delivered with localized documentation that is targeted to the specific process consumer.

"Shout your BPM achievements to the heavens and earth so that your BPM system may prosper on the land"

Some of the best systems I’ve encountered have been the ones that had titles that captured the meaning of their existence…"How2", "Pathfinder", "How We Work". These names don’t evoke the image of an expert system used only by a small clique of process experts. They are the names given to systems that meet the needs of all employees across the business. You’ll find the names emblazoned on promotional posters, web pages and mouse mats, with attractive logos that promote adoption by all employees. There are launch campaigns and continuing efforts to raise awareness and ensure that the resulting resource becomes part of day-to-day operations for all employees.

Ultimately, you can’t drive adoption of a new way of doing business process unless you do the following:

• Provide a single source of truth instead of multiple process silos
• Use frameworks to accelerate discovery and adoption
• Make it easy for every employee to find what they need
• Keep it all up to date
• Make it easy to understand

This may seem like a large challenge to any organization trying to undergo change, but the reality is that everyone starts somewhere. Start with a pain point, ‘hang’ it on a framework and use a methodology that makes sense for your workplace.