What BPM Hat are You Wearing? Part I of II

BPM



A quick search on Google for BPM got exactly 15,900,000 hits. There are a huge range of definitions or perspectives on what those three letters mean. Business Process Management, Business Process Modeling (with 1 or 2 ‘L’s), Business Process Mapping. A couple of interesting finds were that BPM is the national time clock in China, and possibly more relevant, BPM-Focus is an energy drink sold exclusively in Ireland by Coca Cola.

These different interpretations of BPM are not wrong – they are just different. This could account for some miscommunication and ambiguity between people who genuinely mean the same thing. But there are very different interpretations based on the need or use of the 'process model.' Incidentally, the term 'process model' means just as many different things to different people.

Different Strokes for Different Folks

Processes are clearly critical to the running of an operation so it is important that end users, IT developers, systems integrators as well as risk & compliance managers have a consistent, aligned view of how the business operates. To achieve that alignment it would be ideal if these stakeholders could collaborate over a single source of the truth as regards process. The way to achieve that would presumably be to have one integrated process model, which includes all of their requirements. Is this possible? A short conversation with each of them will quickly reveal that their interpretations of what should be in a process model and how they’d use it are quite divergent.

The risk is that when these individuals discuss processes and process models they naturally assume that the others in the conversation have exactly the same understanding. Everyone leaves the meeting thinking that they are in complete agreement, but then are horribly confused when they act differently.

I’m reminded of the HSBC different points of view advertising at airports:

"The more you look at the world, the more you realize that people look at things from a different perspective."

These confused and confusing conversations occur frequently at organizations large and small, with process efficiency, process governance and adoption suffering as a result. It’s vital therefore, to take the time to understand the root cause of the confusion and help people understand the needs and perspective of the other stakeholder groups.

What color is your hat?

After considerable discussion with a number of different companies, it became clear that there were four main audiences who need to share an organization’s business processes model. To make this simpler to articulate we decided to give each audience group a different colored hat – green, white, blue and red. Here’s how it goes.

End users (or business users) want to use the process model for staff training and point-of-need support when they are unsure how to conduct a task. The process model needs to include (or link to) detailed work instructions, forms, templates, systems and performance metrics. In this respect the process model acts as a powerful knowledge management resource. The process model is the starting point for all manner of business performance improvement initiatives.

This is the Green Hat perspective.

Now that hat may be on 'sideways,' as in service based organizations the average age of employees is under-30 – Gen Y or the iPod generation. These are the frontline staff who touch the customers day in day out. It may be important to bear this in mind before deciding what kind of process content to inflict on this audience.

The IT department wants to understand the business users’ view of the operation to ensure that the IT systems they build and maintain truly support the business users, at minimum cost. They want to ensure that there is integrity of information as it flows around the systems.

This is the White Hat perspective.

The IT system providers such as SAP, Oracle or Salesforce.com and the project teams who implement such systems want to ensure that the configuration of their system is managed accurately and that it hangs together end-to-end i.e. passes System Testing and User Acceptance Testing. In short, that it meets the users’ needs.

This is the Blue Hat perspective.

The risk and compliance officers want to be able to demonstrate to auditors that end users are following a documented process and that the correct risk control points have been identified and are effectively managed from a governance, ownership and auditing standpoint.

This is the Red Hat perspective.

Process is Important, but Context is More Important

It is generally accepted that not every activity in a company can be automated. Manual activities are open to the free will and inconsistencies of the individuals performing them. What may be surprising is the relative percentage of automated vs. manual. SAP’s own research suggest 80/20 – 80% manual. This figure is consistent with Microsoft’s findings. And these are companies who would like to see the automation percentage higher. Consistently other organizations agree that these proportions are roughly correct for their enterprises.

Those in IT realize that processes are critical to understanding how to support the operation. However process documentation created from an IT perspective is generally too complicated and unpopular with end users. What end users want is to have 'guided walkthroughs' with the relevant screens, documents or work instructions fed to them in the right sequence and context. That is represented by the diagram with the 'wiggly' red line. For an end user a process flows between manual as well as automated activities. Automation (provided by ERP transactions and other systems) are most easily understood when explained in the context of the full end-to-end business process. But why is the line broken?

Because most process mapping exercises are IT orientated, the detailed process descriptions are of the automation, but the descriptions of the manual activities are sketchy and incomplete. Worse, the process content is not normally published in such as way that end users can easily find process and related information relevant to their role. As a consequence end users often don’t find or don’t understand process information which can help them in their job.

In any case, most have in the past found the process content hard to understand, so now they do not even bother to look. As a consequence the most common cause of process breakdown is human, though people are usually very willing to lay the blame for poor performance on the "new IT system."

Why Should We Worry?

"Process models are only some arcane definition of the business described in boxes and lines on a hopelessly complicated diagram," may be the opinion of many business users, probably because they had imposed on them a process model designed by and principally for the IT function.

An alternative view is that the process knowledge of the organization is the most valuable intellectual asset, which should be captured, nurtured and governed to maximize corporate performance. Think of it as the "DNA of the organization."

If you were a Store Manager in the high street and admitted to your Area Manager that you had no idea what stock you had in the store, how much was damaged or out of date – what would your career plan look like? Pretty short. Treating your business processes as a critical asset should demand that you safeguard, nurture and use that information. But independent research shows that information workers typically spend over 20% of their time looking for accurate information (documents, systems, work instructions) to be able to execute a task.

This can result in systems being used incorrectly, manual workarounds and out of date documents or forms being used – all resulting in waste, frustration and a risk of compliance failure. These manual activities present many challenges including standardization, enforcement, control and performance monitoring because people do not work with the untiring consistency of a computer. They have free will and initiative.

About the Author

Ian Gotts is the CEO of Nimbus, which develops Nimbus Control, a business process management software product. Before founding Nimbus, Gotts was an associate partner with Accenture. For more information on Nimbus, visit the company's Web site at www.nimbuspartners.com.

More by Ian Gotts