A process map, as might be expected, is a visual representation of work being done – as with the use of flow-charting within the traditional Organisation and Methods (O&M) approach to improvement. The objective of documenting a process in this way is to help create an understanding of the work being carried out by creating clearer visibility of the process. The elements of a process can be simply listed – as in a job description – but drawing them in some form of map showing the sequence and inter-dependence of the elements makes it much easier to comprehend the whole.

It also serves to highlight failings. In some cases, the first failing is immediately apparent. In Michael Hammer’s ‘Reengineering Revolution’ (1996, ISBN-13: 978-0006387275) he describes an airline drawing a map of the administrative steps needed to get an aircraft and its passengers into the air. Senior management could immediately see that, whatever else had to be done, simplicity had to be a key goal.

So, in what way do process maps of the twenty-first century differ from flow charts of the nineteen-fifties? They use very similar techniques in terms of documenting physical movements, the creation of reports, and so on. They generally map activities moving across (or sometimes down) the page. They may be divided horizontally by department within the business to provide an indication of who does what (despite some claims that this is a feature of reengineering and never happened with earlier improvement methodologies). 

  • The difference is quite simple. They map processes. Prior to this term becoming the buzzword of the ‘nineties, improvement activities were focused on procedures, or functions. We may have seen a flowchart, for example, on Goods Receiving or Credit Checking when the exercise should have been based around ‘Procurement’ or ‘Order Acceptance’ These should perhaps have been:
    • Procurement = getting raw materials from being a glimmer on a designer’s CAD screen to something ready for use on the shop floor
    • Order Acceptance = a customer’s purchase order arriving in the post being entered to the in-house system in a way that the Manufacturing or Warehousing operation could pick it up and run with it.

There are several issues to be considered when setting out to map processes and a number of publications available to act as good guides to the subject. In this page, we have tried to highlight just the major points to stimulate thought and perhaps a little debate.

    What Should We Map?

    Before we can draw maps of our processes we need to decide exactly what our processes are, which is never as easy as it sounds. 

    The definition of a process from Hammer & Champy’s ‘Reengineering the Corporation’ is a collection of activities creating an output of value to a customer. Some definitions talk about input and output being from and to customer – so perhaps in a Building Society this would be everything from mortgage application to funds being transferred to the applicant’s bank account. In a company building ships it might be from customer specification to sign-off following extensive trials of the finished articles. So might ‘order fulfilment’, embracing everything from customer order to completion, be a process in all companies?

    Our view is that this is not the case. It may be appropriate in builders’ merchants, for example, where standard products are sold from stock, but where the customer’s order has to be translated into a specification leading to components and products being sourced from a number of suppliers then perhaps a process of ‘specification’ may be more appropriate. Whether this should go only as far as identifying the items to be ordered or should extend to order placement or even receipt of the items, can be the subject of much debate. Within a provider of mortgages, it may require a detailed assessment of the types of mortgage available and of the credit-worthiness of the applicant so perhaps the first process would be selection of product and confirmation of offer to the potential customer.

    While some time has to be spent on deciding the processes and it is crucial to avoid the fatal mistake of simply considering all of today’s departments to each represent a process, we have to recognise that much time can be spent on semantics. Two similar teams in similar organisations may define processes differently to some extent – because, as in all such things, life is not about one right definition and everything else being wrong. If people have put time into really understanding the aims and constraints then the exercise should commence, especially if the alternative is an ongoing debate lasting a long time and bringing no more of a conclusion.

    How Detailed Should A Process Map Be?

    The MLG view is that we need both high-level visions of the company’s business and detailed maps tracking, for example, an order from receipt to despatch (or possibly, creation of an invoice or even collection of money).

    The high-level map serves the purpose of focussing people on the real aims and activities of the business, which helps in the determination of the areas to be addressed within reengineering or improvement. Within ‘Reengineering The Corporation’ there is a remark from a senior executive within Texas Instruments semi-conductor operations that a map showing only 6 processes for a $4billion corporation helped people realise that the business was not as complicated as they had previously thought.

    The high-level map also helps avoid the danger that always exists in such a situation that people can become so wrapped up in the detail that they lose sight of the ‘big picture’. The MLG team try to make a habit of taking people back to the high-level vision on a periodic basis.

    On the other hand, genuine understanding cannot be reached until a certain level of detail is documented. (Certainly one of the major issues, that of too many steps being required to achieve a process goal, is not apparent until each is presented as a box in the map. A classic example from an MLG assignment was that of sales order change notes in a company designing and making engineered products to order. Every change resulted in 7 copies of the note being circulated to various departments and each department’s staff having to see if there was an action for them arising from the change. When more than 80% of changes where nothing more than overseas customers advising their supplier of the port and name of the ship for delivery this was quickly highlighted as something to be addressed.)

    Is there a rule for the level of detail? Well, no, but there are guidelines. An activity involving two separate departments – one passing information to another for some action to be taken – should be mapped as two steps. An activity involving one person, possibly calling up two separate screens in a computer package and perhaps printing something, is one step (there may be a weakness here that will come to light when the procedures are examined). An activity where two people in one department carry out sequential, or even parallel, tasks may be considered as two steps if the improvement team members consider them to be worthy of separate entries. At the end of the day, this simply requires judgement.

    How Do We Assess The Process?

    As noted above, one mechanism of assessment is actually fairly obvious. An over-complicated map indicates an over-complicated process. This can be highlighted by:

    • Too many steps to complete what should be a straightforward activity. It may be apparent that too little progress within the overall process has been achieved by a significant number of steps.
    • Too many conditional alternatives. For example, a map may show that most sales orders are entered to a computer system by a team within the Sales Department. However, those that relate to export business may be passed to either the “Standard Export Business” team or the “Letter of Credit” section – unless the order was actually placed through the company’s agent in which case somebody else manages the entry process. This highlights the potential for delay and invites simplification.
    • Too many handoffs (responsibility for the activity being passed from one person to another). Obviously some such occurrences are inevitable – if a contract requires the specialist services of a lawyer, for example, then this must happen. On the other hand, if the current process has evolved over a number of years there may be instances of one person handing information to another, who does nothing more than record that something has happened before passing a document to somebody else. The map should highlight such examples.
    • Too many of the handoffs involving physical movement of documents. In these days of integrated systems, this can be kept to a minimum with considerable benefits.

    ‘Brown Paper Fairs’

    This term is an appropriate name for events when people from throughout the business are invited to look at a process map and identify what they consider to be problems. Such an exercise would be carried out using a relatively detailed map – certainly showing all handoffs and all decision points as a minimum. This explains the terminology; such a detailed map would rarely fit on one sheet of paper and would normally be drawn on several sheets of brown paper covering a large wall.

    The invitees are then introduced to the objectives of the process improvement exercise that has led to this event, which would usually include at least some education on the subjects of Business Process Reengineering, Innovation and, in all probability, Lean. The process as documented is then explained and each is given a set of ‘post-it’ notes and asked to document what they see as problems with the process, sticking the notes on the relevant part of the map. Ideally, each problem would be identified within a category (duplication of activity, potential for error, delay, and so on) and this can be addressed using different coloured notes. Sometimes, however, junior staff may misinterpret the nature of the problem and the important point at this stage is to capture that somebody has a concern. The detail can be explored in subsequent discussions.

    In some cases a delegate may question the accuracy of the process as documented and this usually highlights a conditional procedure that had been missed – something like “you’ve shown quotations sent to the customer but where the customer code is prefixed ‘99’ they are actually forwarded to the territory manager”. This can be a very interesting element of any improvement exercise. “Does any one person know this process in full?” can sometimes be heard coming from the lips of managers frustrated by the number of issues that continue to crop up. While such issues may represent problems with the current way of working, our stance is that they are proving that the exercise being undertaken is genuinely worthwhile.

    Comparing Process Mapping With Value Stream Mapping (VSM)

    Value Stream Mapping is described elsewhere on this web site <click here> and is a technique within the set of tools collectively known as ‘Lean’. It reflects the primary objective of Lean, that of eliminating waste, and identifies which steps within a process add value and which don’t – any activity that doesn’t add value is, by definition, waste. If we are doing something then it has a cost, at the very least, in terms of people’s time. If we are getting no return for this investment then the time is being wasted.

    VSM cannot be confused with process mapping since it has to be focussed on a straight-line series of steps, or activities. Like process mapping, it can play a part in helping companies to decide on problem areas and priorities. The two may, on occasions, be used in parallel to review the current way of working.

    Should We Skip ‘Current State’ Maps?

    Mapping the current position is a valuable technique for assessing strengths and weaknesses. On the other hand, in some cases, those strengths and weaknesses are already well known so the question has to be asked whether the mapping exercise will tell us anything we don’t already know. In a business where the current procedures are the result of manual ways of working that are now to be replaced by a modern computer package, or where this package is to replace a bespoke in-house development from twenty years ago, we may be better spending time on defining the future process.

    In such a case, however, the current way of working has to be considered when the migration to the new process is planned. This may require some form of mapping so that the steps required to implement the change can be set out in a logical sequence. This is particularly important where the current way of working is not fully understood by anyone – it is not unheard of for everyone to know their own function and those one step up- and downstream but for no single person to have the full picture.

As with all improvement techniques, process mapping can be very valuable when used properly. Again, as with all techniques, not all options have to be used for all improvement projects. There are many tools available and successful management of change is based largely on selection of those which take the business forward as quickly as possible.