Download the latest version here:
(21 day demo)



"A process-based management system should be a simple description of what an organisation does".

"Business processes have always existed because that is how an organisation operates from day to day".

"Processes have not replaced procedures".

Some Questions

Do not be put off by the fact that most computer spellcheckers reject "MandOS" and suggest "Madness" as an alternative.
Nor by the fact that MandOS is a character from Tolkien's Third Earth - "the Speaker of Doom", in fact. "MandOS" is a concise way to encapsulate the essentials of "Management & Operational Systems" - just the approach we want to promote.

The following questions are often asked when people are trying to come to terms with what business processes mean.

What is a business process?
A common definition of a process is "a sequence of related tasks and decisions which act on inputs to add value to create outputs. It uses resources and is subject to controls".

We believe that this definition is not clear, and the explanation of the terms used (such as "inputs") which often accompanies it is plain wrong.

Whatever the precise definition, the concept can be extended to mean a process which either creates value or supports a process which creates value.

For example, "manufacturing to order" is the process of receiving a customer order, through manufacturing and packaging, to delivery of the goods. The process of "managing suppliers" supports the purchasing process.

Is a production process different from a business process?
No. Production processes (or as ISO9001:2000 would - unfortunately - have it, "product realisation processes") are just a subset of your business processes.

When people describe the two as being separate, they are prolonging the (unhelpful and misleading) view that quality standards and management systems relate principally to a manufacturing environment and that supporting functions - and other sectors - are second class citizens.

Think of "production" as "creation". If your organisation creates training courses or cleaning services, your production processes are how you generate a course or how you plan and deliver your service - all just part of "running the business".

Why is it so difficult for many managers to understand business processes?
The "traditional" way to define how a business operates is to define a set of "procedures", narrative descriptions of related sequences of events within a department or work area (for example, in Stores or Purchasing). And the existing management structure often reflects and reinforces this.

Often, a company will generate one set of procedures for its quality system, another for how it deals with environmental matters, and another for how it addresses health and safety issues.

It can be difficult for those who are steeped in narrative procedures suddenly to change their thinking sufficiently radically to allow them to "see" their processes.

Often they think of what their department does as a series of disjointed tasks, rather than identifying what initiates an action and how it is followed through to completion.

What is the best way to define a business process?
There is more to a process than just the tasks and decisions which define the flow of information or material. You also need to define the resources and skills required and the influences which affect the operation of the process.

But even to describe the process flow clearly and in a format which staff can understand and use easily can be a challenge.

The best way to show (or "map") a process flow is now widely accepted to be as a flowchart. A process flowchart shows "what has to be done", and a deployment flowchart, also shows the departments and job functions involved - "who should do it".

The deployment flowchart is a matrix, often presented with job functions along the x-axis and tasks or activities down the y-axis.

There are other types and formats of flowchart. Some are little more than a diagram with indeterminate "objects" linked by lines which suggest connections back and forward, up and down and occasionally round in a circle. Some would say that the attempt in ISO9001:2000 to illustrate the process-based approach promoted by the standard is a prime example of this (!)

What is the "correct" level of detail to use when defining a business process?
As little as you need! Be clear about why are you doing it and who will use the resultant definitions. But do it for yourself and your staff - a management system is not for your external auditor.

Two pages of a flowchart should be sufficient for a process. Assume competence in the people allocated to work on the process - or train them!

Why are so many management systems built around the requirements of an external standard?
Because managers are often "happy" to manage by the seat of their pants and to sort out problems as they happen (it helps them to feel as though they have achieved something!) And they only document how they work when they are forced to adopt an external standard as a means of staying on tender lists, for example.

Many then work around the system and find it an overhead rather than an asset. And it has until now been difficult to find an approach to describing what the organisation does, and how it does it, which people can understand and are happy to use.

Where should I start when designing a process-based management system?
Understand the concepts - such as processes / systems / flowcharting / procedures. Be clear about your objectives.

Typically, people gain two principal benefits from this type of system: a better understanding of what is done now (this makes it easier to identify possible improvements) and a means of training new staff. Remember - most people will read flowcharts no more readily than they will read narrative procedures.

Then plan the structure. Always work from the top down - do not convert a collection of unrelated procedures and then try to fit them together.

Next (Procedures ...)