"Everything should be made as simple as possible, but not simpler" is the advice that Albert Einstein gave to the Process Management Special Interest Group at the Swiss Patent Office in Bern on the afternoon of Wednesday, 2 July 1902.

Or he would have … if he hadn't been busy thinking about photons, atoms, the speed of light, energy, and the fourth dimension.

He absolutely meant to say to all process practitioners that his aphorism about simplicity should be actively applied to our work as well.

If we are to maximize our impact on organizational performance, we must help make management simpler, not more complex. If we are to have a positive impact on organizational management, we must be a solution, not a new problem.

Too often it doesn't seem to work like that. We illustrate complex ideas with even more complex diagrams. We draw intricate process models that few find intelligible, let alone useful. We design complicated governance systems that bring more chaos than order.

The 3^rd circle and the 8^th enabler?

A lot of my process thinking, writing, speaking, consulting, and recording is shaped by concepts I developed and call the 7Enablers of BPM and the Tregear Circles. You can check the links if you aren't familiar with those ideas, but suffice to say here that there are seven enablers and two circles.

I have lovely conversations with people suggesting the eighth enabler or the third circle. None have convinced me yet, and I don't expect they ever will. I started out (two decades ago!) with 10 enablers and worked that back to seven. If I was to make a change I'd like fewer enablers, not more. Keep it simple.

It is simple. Or at least it should be. The purpose of process is performance. Useful process work delivers proven, valued improvement in organizational performance. I discussed this in more details in my previous column about the delivery of proven, valued, business benefits.

How do we stay in the sweet spot of the trivial-simple-complex spectrum?

Take it from the top

To manage our processes, we need to know what they are. Call that set of processes whatever you like. I prefer the term enterprise process architecture, or its variations EPA or process architecture.

Organizational strategy is executed via processes, so it makes sense to start with strategy (value proposition(s)) and describe the process set from there. In that way all named processes have a 'line-of-sight' relationship to strategy.

You can start bottom-up, i.e., define processes by department or team (functional unit) and then try to amalgamate them into a coherent hierarchy. The problems with that are it's hard to do, takes too long, and it doesn't work. Don't do that. Start from the top and decompose down as far as you need to.

Keep it simple — define a logical, flexible, expandable, and coherent model of all the processes of your organization, top-down from strategy, as a platform for all process work.

Focus, focus, focus

The three most important ideas in process-based management are focus, focus, and focus. Depending how deep you go into the process hierarchy there are hundreds, thousands, even tens of thousands of processes in an organization.

Obviously, you can't usefully manage all of those processes. And by "manage" I don't mean model. I mean to set, track, analyze, improve, and predict process performance to deliver proven and valued organizational performance improvement.

We need to make wise choices about which process should get our attention, time, and money to give the best return. Another way to say that is we need to choose which processes to ignore, at least for now.

Does that seem harsh? Does it feel a bit uncomfortable to identify processes that are to be ignored? Aren't all our processes important? Can we really abandon some, indeed most of them? Well, you are doing it already.

Since you can't be working on all your processes, you have already prioritized some over the others. How are those decisions made? It would be much better to make well-informed choices about where the best return-on-process can be found.

We want to focus on our high-impact processes (HIPs). These are processes that can have a significant impact — positive and/or negative — on organizational performance. Large and complex organizations might be able to focus on just 20–30 HPIs, and when starting on this journey we might initially choose just 3, not 30.

There is no magic formula for the selection of HIPs. The common criteria include customer and other stakeholder impacts, regulation imperatives, number of staff involved, cost of execution, current performance level, strategic impact, major project impacts, resilience demands, etc. HIPs will often be from the set of core processes but may also be found in management and support processes.

For more discussion of the use and selection of HIPs see my YouTube channel and the short video on this topic.

Keep it simple — don't try to manage all the processes but make wise choices about which high-impacts processes to focus on.

PKPIs

We need process KPIs (PKPIs) because if we aren't measuring, we aren't managing, and we can't know if we are improving.

The biggest complicating mistake I see is assuming that PKPIs need to be defined for every process named in a process architecture. Defining PKPIs and targets for processes that are not going to be actively managed is pointless.

Define PKPIs just in time, not just in case.

Keep it simple — only create PKPIs and targets for processes you choose to actively manage, and make sure you have effective PKPIs for which you can get performance data.

Modeling simplicity

In process management and improvement, the least important thing we do is modeling.

I didn't say it was unimportant, but a clear perspective is needed. The purpose of process is performance. The M in BPM is for management, not modeling.

A common and unnecessary complication is the idea that we should "model all our processes." There needs to be a compelling reason for modeling and documenting any process — there must be clear need for the models and the documentation.

For a well-managed process, we should have a clear view of how it should perform, how it is performing, how it could perform, and how it will perform. We can do that with little, if any, process modeling.

Keep it simple — model just in time, not just in case.

Who's in charge?

Another way to complicate our process life is to create continuous argument rather than continuous improvement. A common contentious issue arises around the question "Who's in charge?"

The organization chart and related documentation clearly defines responsibility for the various functional units. Now we create a new cross-functional role of Process Owner (or whatever term you prefer). Who's in charge? Does everyone now report to the new Process Owner? Who controls the budget? How can we get anything done?!

There is a simple solution. Give the Process Owner no authority, i.e., in implementing process-based management make no changes at all to authority structures defined by the org chart. Also, give Process Owners, and all the functional managers, the ability to escalate issues so there can be a resolution when collaboration fails or formal changes are needed.

More information about effective process governance here and here.

Keep it simple — give Process Owners influence and access, but no authority.

Create capability

It is a common and understandable consequence of process evangelization by the process team that everyone is so impressed that they now assume that all process work will be done by that process team!

Process support teams also often feel the need to exercise tight control of the quality of process work by insisting on being involved in every aspect of it.

The inevitable consequence of this centralization of effort is a bottleneck. The process team has created a poorly-performing process designed to fail. Ooops!

Keep it simple — the key role of a central process support team is to build capability across the organization, removing the need for them to be involved in every initiative.

The process of process

Process management and improvement is a process. As process practitioners we can't be promoting the process view and simultaneously not taking our own advice.

The 'process of process' needs to be documented, measured, analyzed, managed, and improved just like every other high-impact process.

Keep it simple — the process of process management and improvement should be the best performing process in the organization. Imagine what that would mean!

Keep it simple

Achieving sustainable process-based management is not easy, but sometimes we seem to go out of our way to make it much more complex than it needs to be.

Anyone can create complexity. Simplicity is the harder, and more worthwhile, goal.

# # #