Process Mapping Logo

Process Mapping - Methodology

Track Record. Trustworthiness. Competence.

Business Process Management

This methodology is primarily focused on Business Process Management development projects. Although, on evaluation, we believe that the approach is quite easy to apply to any software development, Business Process Management is our main area of focus. There are also a great many other perfectly valid methodologies for software development in general, so we wanted to focus on this particular area.

The main differences between Business Process Management development projects and most other software development are the Rapid Development aspects, and the typical lack of technical depth required, thus allowing business users to become involved in the design and even development processes.

Since this is a particular focus of the methodology, and of ourselves, we thought a description of Business Process Management would be useful. Essentially, the name itself is the most accurate description of the topic, which is unusual in our technical world.

It must be stated that what we are describing here is Business Process Management Automation using Business Process Management Software. The field of Business Process Management is itself a large one, and automation is not necessarily a part of a Business Process Management initiative. In larger organisations, it will usually be the culmination of any Business Process Management initiative, however, and this is where we get involved.

A very good question to ask is "Why automate our processes?" The best answer is from the description below:

Imagine having to explain to 200 employees that when condition 'x' occurs, they now need to fill out form Z76YH instead of Z75YH and be sent to the accounting department, otherwise they have to now fill out form UY6P and send it to their supervisor. Imagine having to go through all of that every time the requirements or regulations change. It is quite a large task, and very prone to error.

Because of this, Business Process Management Automation is what our methodology is focused on, and what we describe here.


Business Process Management is primarily about 'Business'. This is not just a misleading or promotional term within this context. Business Process Management is actually the first time a software design approach was designed from the ground up to be both understandable to, and accessible to, business users. Ideally, little or no technical expertise should be required to design processes in a manner which can be easily interpreted and used by technicians. To copy a well-known phrase, it is Software Design 'of the Business, for the Business, and by the Business'.

Why is this important? Well, the main problem that has been created by many software design methodologies is an almost complete opacity for Business users. Any stakeholders in software systems not having a certain degree of technical ability, and often quite a high degree, mostly had no idea what any software design or specification actually meant.

Effectively this means that the business users are almost completely shut out of the specification process once their requirements had been written. Given the almost certainty that at least some of the requirements would be misinterpreted by technicians, the results were almost certainly bound to fail to some extent. This is, I believe, the primary cause of the failure of software projects, and it comes down to a lack of communication. That itself can probably be reduced to a lack of a common terminology, or language.

Business Process Management was 'invented' (or at least composed), in order to solve this primary problem.


The second word is all about how people work. It sounds simple, but we just do not work the way computer systems used to be built. The reason for this is historical. When computers were first introduced, they had no real application. People literally didn't know what to do with them. When the concept of the spreadsheet was introduced (in a very basic form), it made computers 'useful'. We could calculate very large mathematical formulae, and even multiple formulae. More importantly, we could change one calculation parameter or formula, and recalculate the entire model. This was then extrapolated to allow very large batch processing of simple mathematical calculations, and then financial institutions such as banks were revolutionised.

It is sobering to recall that even when I was young, almost all calculations were performed with a slide-rule (I actually learnt to use one at school), all large complex mathematical formulae were drawn and maintained by hand on rooms lines with blackboards by teams of mathematicians, and bank transactions were essentially run by rooms full of people with very basic mechanical adding machines. Because of this, the initial usages of computers able to make extreme savings in processing time were mostly in specific business functional areas. The most common of these was the Finance Department, and accounting software.

Unfortunately, the result of this was that we created 'silos' of functionality and data. Systems became essentially isolated from the real activity of the business, and business users were forced to adapt to their use. Business Process Management was designed to break that model, and make systems able to support and adapt to the way business work. This in itself was a revolution.

How does this work? The main approach is to recognise that people work in a specific manner. They have inputs (the 'in tray'), outputs (the 'out tray'), and things they do. The best Business Process Management software I have ever seen uses this exact paradigm to define the processes that people perform. It also allows the process to be defined and built using this simple layout.

Imagine a manila folder, for example containing a mortgage application. Before computers were used to manage this, a folder was created. People would assess the application, make calculations, determine eligibility, check regulations and policy, and then eventually the application might be approved or declined. Throughout this process, many different employees would process the application. Some would fill in more details (like the 'office use only' parts of most forms), add additional forms, and sometimes request more forms, information and supporting evidence.

All of this would become a large manila folder containing several forms, a few attached documents, and the cover would typically contain a history of the processing of that folder. This Business Process Management software, one of the originals of the genre, mimicked this exact model to define and build a process that could work in this way. Even the icons were images of these events, such as a person sitting at a desk, a hand moving a piece of paper from one stage in the process to another and a group of people in a discussion.

BPM Examaple
BPM Examaple

As can be seen, the model itself should be clearly understandable by a business user as it stands without additional documentation. This could then become the common 'language' between business users and the technicians that were to implement the system. Although this tool was to become one of many, in my opinion it was then, and remains today, the most obvious and clear model to describe a process in business terms.

One of the key characteristics of a Business Process Management solution is that it crosses functional boundaries and incorporates a number of functional areas of the business. It may well interact with several systems isolated inside functional areas of an organisation, and this create a way to merge the functionality of various previously isolated systems.

This is one of the reasons Business Process Management is differentiated from what became termed Workflow. Many systems attempted to add workflow functionality into their existing functionally isolated systems, such as accounting systems. While this may have seemed like a good idea, all it did was improve a single functional area without crossing any functional borders. As such, it is generally of severely limited benefit. The concept of the broader organisation-wide initiative that Business Process Management systems aim for led their differentiation from 'Workflow' itself by creating a new term. This term is more focussed and more descriptive.


We have now described Business Process Management as a Business tool, and how it achieves this by designing a human-centric Process rather than any functional area.

Before computers were ubiquitous, what used to occur was that paperwork came in, something was added to it in some way, and then paperwork went out. Certain people were responsible for making sure the 'paperwork' got to the right person, but generally this was the responsibility of each person doing the work or perhaps their immediate manager. People were essentially tiny cogs in a larger machine, and all they knew of was their own responsibilities.

Although this worked, there were huge problems. The main one was the difficulty in changing any of this. It could involve a huge 'reorganisation' to achieve even a small change in the process. For most software systems, before the concepts of Business Process Management were adopted, similar problems existed. If the accounting system changed, for example, there was a considerable chance that the way ordinary business users interacted with it would have to change. This could involve extensive changes to documentation (if you were lucky enough to have any), and or training (ditto).

Imagine having to explain to 200 employees that when condition 'x' occurs, they now need to fill out form Z76YH instead of Z75YH and be sent to the accounting department, otherwise they have to now fill out form UY6P and send it to their supervisor. Imagine having to go through all of that every time the requirements or regulations change. It is quite a large task, and very prone to error.

Now imagine merely presenting the user with the appropriate form, given the specific conditions, ensuring that each field that is required if filled, even dynamically depending on data input into other fields, and subsequently routing the folder to the correct user for the next step. That is what Business Process Management software allows us to do very easily, and with comparatively little effort.


Imagine a system that allows business managers to define the way their staff work, or should work, in a manner that is understandable to themselves, their staff, and the technicians who need to implement any business rules.

Imagine that the definition of this system is, form a business perspective, entirely stored in a process diagram with associated forms that call all be defined and controlled by these business managers and expert users.

Imagine a system that allows them to continuously change these rules, define additional steps, forms and rules, and allows them to test, or prototype, the solution thoroughly before implementation.

Imagine it has the ability to provide timed escalations, email alerts, reference an update data in other systems, and give sophisticated role privileges and security based on Active Directory details and data inputs.

Imagine it also automatically keeps a complete record of who did what and when, and records metrics to determine the time taken, effort and cost of each step, as well as any other required metrics built into the process, all allowing the performance of the process to be assessed, refined, and redeployed to provide continuous improvement.

What you have then imagined is a complete Business Process Management System in a nutshell. Fortunately, you no longer need a good imagination, as these systems exist.