View Figures with Adobe’s SVG Plug-in. Test for SVG
at: http://www.adobe.com/svg/viewer/install/svgtest.html
This article may only be copied in its entirity and with this Copyright statement: David Howard © 2000
This paper introduces, with a typical business example, a simple but very powerful business process mapping technique known as deployment flowcharting (DFC). Deployment flowcharting, sometimes called matrix flowcharting, is increasingly being recognised today as the preferred technique for capturing the operational details of business activities. It's strength lies in it's ability to display process knowledge in a way that facilitates subsequent process improvement and innovation.
All business activities consist of a sequence of related actions and tasks, which use resources to transform inputs into outputs, be they products or services. Such transformations are the source of all value creation for a business. They are also the source of all the added costs that tend to reduce productivity, efficiency and economic-quality. Process mapping based on the DFC technique thus helps identify the sources of both value and cost. Once the sources have been found then costs can be rationalised and value creation optimised. Product and service quality are consequently improved.
The ultimate purpose of all process mapping must be to bring about improvement and innovation. It is therefore most helpful to start mapping processes as they are, not as they could be. Changes to the process can follow once the initial condition is defined. Process mapping can also, of course, be used for planning new processes.
The process manager (owner and leader) is ultimately responsible for improving his or her assigned processes. However, experience shows that without the support of the people who work within the process it is not possible to bring about lasting improvement single-handedly. Contrary to received wisdom in traditional hierarchical organisations, everyone who has a job is part of, or owns, a process. There are no exceptions. Identifying the process may be difficult. But a process will always exist for any acknowledged business activity. The question is whether it is a necessary, value-adding process or one that just adds cost.
When management introduces process mapping they need to ensure that the participants fully understand the concept of process. They should also be clear about the purpose of the mapping exercise as well as the methodology to be used. What is needed is an open mind, a sense of enquiry and the support of workplace neighbours regardless of their rank or position.
Once a candidate process has been identified for mapping agree a clear, short-name for it. It is important that this is done concisely - try to use no more than five or so words. Lack of clarity at this stage - particularly in the opinion of others outside the process - will only result in confusion later on. Avoid loose ends.
A process only flourishes when it is led. Left to itself it becomes inefficient. Whether it be dealing with a product or a service the process will only perform as well as the management provided by it's leader. This leader can be seen as the process owner. The leader will generally be a 'manager' in functional terms (i.e. the person responsible for continual improvement of the process) if not in title. For high level business operations - the core processes of the organisation - the process owner will more likely be a director.
The unambiguous identification of a process by concise title and owner's name constitutes the major first step forward in process mapping. Often allocation of ownership is one of the biggest hurdles to be overcome because the perceived manager is not always the one who carries actual delegated responsibility. Sometimes responsibility may appear shared; sometimes it will apparently not be owned by anyone!
It is also necessary to identify the person who will lead the process mapping exercise - the mapping steward. This person will generally not be the manager, but rather the process supervisor or team leader who has worked within the process and knows about it in detail and has the full support of the process team members. Managers often have not worked in the processes for which they are responsible and thus are not best suited to leading the mapping exercise. Their contribution will be in enabling the overall exercise and removing the barriers to progress which can so easily arise, especially in the early stages of process mapping.
The people involved in the process represent the "cast of characters". Each one has a vital role to play in the transformation which is the focus of their attention. Just as with a troupe of actors who meticulously rehearse their roles so the members of the process team are part of a cast-list which shares the responsibility for ever better performances.
Finally, it is essential to clearly identify who the process customer is. It may be the next work team along the line; it may be another, distant, department; perhaps another factory in the same company or another business. Or, of course it may be that conventional exemplar of the customer, the end-user. It is never the boss!
Process mapping does not take a lot of time so long as it is approached in a carefully planned way with each member of the cast knowing what is expected of them. To ensure that everybody recognises that time is of the essence it is recommended that the time schedule for the mapping exercise be defined carefully.
Process mapping tends to be iterative; the first map is rarely correct, but is a valuable step on the way to a final representation of how the work is done at present - the essential starting point for any programme of steady improve- ment. The benefit of iteration is that it recognises that we do not have perfect recall and that we may need to reflect on our contribution to a process before we have a generally agreed, and operationally correct, baseline definition. One of the many distinctions of deployment flowcharting is that it provides an operational definition of a process. Traditional flowcharting is never so rigorous or powerful since it fails to address the full scope of the inter-relationships that typify all process work. The unique power of DFC is that it orchestrates co-operative teamwork.
Deployment FlowCharts
should be seen as Operational Definitions
A
well-formed ‘flowmap’ serves as an operational definition of the way work gets
done and time gets used. By virtue of
its collaborative origins it uniquely defines how value is created by the
transformation of inputs into outputs and serves as a basis for all subsequent
process improvement.
By setting a reasonably demanding target date - perhaps a week - the intention to complete a process map without loss of momentum is made clear to all. A series of two or more meetings with a day or two between each is probably an ideal pace at which to proceed - neither too rushed nor unduly drawn out. The objective in mapping any process will be to achieve a clear map of how that process is performed currently and as agreed unanimously by each and every member of the "cast of characters". When such an initial process map has been completed it should be defined as 'Revision Zero' and registered by the management steering group that has authorised the mapping activity. It is then available as the baseline reference against which subsequent process improvement can be determined.
This management group will probably decide to nominate one of its members as the registration officer. The task of the registration officer is to determine that the map accords with the agreed standards and terminology, format and symbol-set and that it is an agreed reflection of the way the process is currently executed - in other words that it constitutes a valid presentation of an operational definition of the process. The registration officer is not primarily concerned with judging whether or not the process is correctly mapped. That is the responsibility of the team and the process owner. Obviously business process mapping exercises benefit from having a process map of the organisation's mapping process itself!
As the mapping of processes spreads within an organisation so the linkage of one process with another will become apparent. There will develop a pattern of hierarchical and heterarchical relationships which cumulatively map the organisation's process architecture.
Mapping of business processes has traditionally been carried out by the process team gathered around a sheet of brown paper armed with sticky labels. Magnetic boards with tactile magnetic shapes offer a more dedicated way of working but for convenience and re-usability a laptop computer with an overhead projector offers the most convenience. Each member of the process team (or 'cast of characters') is identified and listed (i.e. deployed) sequentially across the top of the chart (the end-user usually to the right) and the agreed process actions, or steps, are plotted on the chart beneath the appropriate person. The mapping process, in early sessions at least, is facilitated by the mapping steward. In this way the cast jointly develops the script for the process and records it in an agreed manner that minimises misunderstanding and subsequent confusion.
Experience has shown that the most reliable way to surface the details of the process early on is for the process members themselves to interact and negotiate the mapping of the process at a large scale. By using overhead projection to collect the information and then providing print-outs for review over coffee or tea breaks an iterative process gets underway that ensures the final outcome for the day is agreed - signed-off - by all.
Providing process mapping participants with a hard-copy record of the progress made at the end of each session will reinforce the importance of the mapping exercise (how often do minutes of meetings get provided at the end of the meeting?); it also reinforces in the eyes of the participants that the exercise is being taken seriously by management. With each member of the process team able to take away a copy of the draft flowchart they can share a clear basis of understanding for informed reflection before the next mapping session. As the process map takes shape people will see that it is more than a simple linear flowchart. Because of the way each activity is assigned to the responsible person the deployment flowchart becomes an operational definition of how value is created. And rather like sheet music it provides a consistent statement of intent that loses no essential meaning in the interpretation - unlike procedural statements with their loopholes and opportunities for misunderstanding. Figure 1
The symbols used to chart the flow of events within a process are few in number. Simplicity is the key to overcoming the complexity which, through time, has overwhelmed the efficient conduct of many process activities today. Experience has shown that significant progress can be made with just four symbols. Each is linked to the next in sequence by either vertical or horizontal solid lines in the positive (value-adding) direction of the process flow. In the early stage of process mapping restrict yourself to the basic four symbols. Figure 2
Experience
shows that busy, flowmaps are less successful in clearly communicating
information to users than is imagined by their originators. Complexity may
please the creator but is rarely helpful to the end-user. When creating charts
remember the FlowMap ’Rule of Five' to avoid confusing complexity.
Work on
processes at the appropriate level of abstraction. Instead of mapping
everything at once (eg the ‘process’: Satisfying our Customers - which involves
dozens of different people in many interdependent processes) work through the
constituent sub-processes: Capture the Customer; Take the Order; Arrange
Payment/Credit; Deliver the Product; Complete the Transaction. A test for
suitability is: "Does the process selected involve more than five
distinctive participants?" If it does carefully review the process
definition with respect to its surroundings processes and activities.
Likewise
process name, activity descriptions and related tasks should be described as
concisely as possible. Five words is a good working average which testss .
clarity of thought and expression. Overall a typical deployment flowchart
should not be crowded with symbols. A small multiple of five is a useful guide
- between 15 and 25 symbols per A4-sized FlowMap provides a good balance
between detail provided and ease of comprehension. And five levels of mapping
will always be sufficient to take you knowledgeably from core process to work
instruction.
At the start of a business process map using deployment flowcharting the sausage-shaped terminal symbol is used to denote the origin of process activity. It is placed below the member of the cast of characters who actually initiates the process. Similarly wherever the process terminates the symbol denotes the end point of the mapping. The most used flowcharting symbol is the rectangle-shaped task or activity box which is the fundamental component of all processes. This activity or task will form the basis of a work instruction.
As high level business processes are examined in detail it becomes necessary to map lower level, subsidiary processes. The symbol used to indicate such linking of an off-spring to its parent process map is called the drop-chart symbol. This serves as a reminder that further detail is available to support the understanding of the parent process. The drop-chart symbol provides the means to indicate that a separate process map contains the details. By like token the meta-chart symbol indicates the parenthood of the chart on which it appears. Figure 3
Any process will involve decision making. These decisions can be mapped using the diamond shape. An important discipline in the use of this shape is to emphasise the process-positive outcome of the decision by ensuring that the bottom angle is used for the positive output and where possible restrict the neutral or negative output(s) to the two lateral angles. Further, any process-negative flow out of the diamond should be mapped with a dotted or dashed line to highlight any re-work that is involved. Figure 4
This will serve as a reminder for early improvement action to reduce or eliminate the incidence of such process-negative occurrences. Documentation, hard-copy or screen-based, features strongly in most processes and it is necessary to track it with the other activities and decisions.
There are many other symbols that can be used to powerful benefit as skill in process mapping develops, such as the 'judgement' and 'freedom boxes' which form an integral part of The FlowMap System DFC methodology. A 'judgement box' is used to remind readers that this particular task requires a formal (professional) qualification for completion. Figure 5
In contrast the 'freedom box' is useful in preventing a process mapping exercise from stalling when it proves impossible at the first attempt to define the activity - for instance one requiring a special skill that cannot be easily learned by others without practice. While a 'J-box' will specify the qualification required and be a lasting part of a process map the 'F-box' is strictly temporary and must be replaced by an appropriate activity description (or sub-process) within a period of time agreed by the team at the time of it's use.
It is often important that a participant within a process is aware of some action or event although not centrally involved in it. To be aware that a meeting is taking place or a report has been issued may often be sufficient. The use of this symbol showing off-line involvement is a matter of style and choice within the team. It can be a useful means of supporting a need-to-know approach to process management.
In high level processes, such as planning and reviewing work, there is a need to represent meetings of process participants and the sharing of information amongst them. Two composite symbols allow these elements of a process to be mapped clearly and accurately. Each can be constructed to differentiate between members of the cast who are involved in the meeting or sharing the information and those who are not. Figure 6
There is no reason why a group of like-minded people should not devise their own more graphical symbol set if it increases participation and ownership of the improvement process itself. When designing a special symbol set remember that the symbols selected will need to be adopted as a standard by others within the organisation if confusion is to be avoided. Elegant simplicity in communicating should always be the aim. Elegant so as to catch the interest of the reader; simple so as to convey the requisite information quickly, directly and clearly.
It is useful at this point to recall the difference between a 'procedure' and a 'process'. Procedures have conventionally been text-based statements by others (generally superiors) of how work should be done. The procedures file is usually not at the user's fingertips; more often than not it is out-of-date or waiting to have supplements collated into the appropriate sections. It is far from attractive to the routine reader. Accordingly procedures tend not to be used.
By contrast a process map has been prepared by the people themselves and can be an attractive graphical representation of the information to be communicated. By virtue of electronic networks it can be easily accessed, simply explored and because it is centrally maintained it can be relied upon to be up to date. As the library of flowmaps grows so linkages cease being just heirarchical, instead they evolve heterarchically, as individual charts connect to others than just the next in line.
A process map is also a self-evidently auditable document and one which can be used to demonstrate due-diligence as and when required. This latter aspect of deployment flowcharts is of increasing importance in today's demanding and increasingly regulated business environment. However the over-riding purpose of flowcharting a process using DFC is to increase understanding and gain insights about how to improve the process and its output as well as discovering opportunities for process innovation.
A company supplies its customers daily with a range of products. Each week a total of some 45,000 boxes of some 60 different lines is assembled to order for shipment to some 35 different destinations. Each week the company issues appropriate invoices for goods delivered and 21 days later payment is received so long as the delivery exactly matches the order. The weekly revenue is approximately £1 million.
It is noted in a regular review of business performance that trade debtor performance is routinely around five weeks, namely some two weeks behind the nominal value. Top management faced with reducing margins decided that it could no longer tolerate such a continuing loss of potential profit because of late payment (with the consequent borrowing to fund work in progress) and decided to identify and correct the root cause of late payments.
The company managing director at the same time had been looking at how he could develop their early views on quality management and this seemed to be a promising area for further detailed consideration. The finance director was not keen to lead the project - his department considered that it would not be worth the disruption. After all 'late payments' had been the norm for very many months, even years!
Early discussions with the various departmental managers - sales, production, marketing, credit control and distribution - were however more fruitful in not only better defining the issue (order errors spotted by customers who then returned the unpaid invoices with corrections for re-processing) but in also discovering that the warehouse manager wanted to improve his operations but had, until now, no wider basis on which to operate. With this project he would be able to implement some of the paperwork changes that his despatch crews needed but which accounts did not want to bother with.
It is decided to map the Trade Debtor process at high level and then follow it through to the operational sales and distribution processes. By using the deployment flowcharting notation the way the work is done can be carefully examined in full detail. Traditional linear flowcharting would not so precisely define who did what, when and where. It was recognised that the solution to the problem would most likely reside in the small-scale detail; all the normal large-scale solutions had been tried many times before and always failed to win lasting improvement. Suitable training and coaching was provided to the individual members of the various teams involved with the distribution process and early meetings held between them with the sales and order planning teams.
The picture became clearer. The warehouse distribution operation had a long term error rate of some 185 units per week. Expressed as an error rate of 0.4% this seemed 'reasonable' but when expressed in the unit of world-class performance, parts per million, it was an error rate of 4,100 ppm. Further when the previously ignored weekly error figures were examined in a run chart over the past few months the SPC chart showed a very stable system at work.
Only by means of a major change to the way the work was carried out on a daily basis could the situation be improved. The weekly errors were randomly spread across all customer depots and at any one time were holding up payment of about one half of all invoices issued. Only detail re-design of the process could reduce the figure to the long term target of below 100 ppm arbitrarily set by the managing director.
A flowmap of the overall trading process was prepared, initially at high level and then progressively at lower more detailed levels all the way 'down' to individual work instructions. Key sub-processes were identified and their detail was also mapped, such as pallet assembly, credit control etc. During the mapping exercise the cast of characters learned a number of lessons. Firstly the importance of only mapping how the work is actually done at the time. Resist improving the process before you have defined how it really operates. Don't try to capture the definitive process in one session. It inevitably takes two or more iterations to get to Revision Zero. Figure 7
Further, make sure that there is a change control system in place so that any change that is made to the Revision Zero map is made with everyone's knowledge. Enthusiasm can, and does, run away with operators when they discover the power and the joy of doing their job efficiently for, often, the first time in their working life. Good ideas can derail the entire operation if individual members of the cast forget that they are now part of a team based upon co-operative working rather than competitive advantage.
Once Revision Zero had been mapped to the satisfaction of the "cast of characters" the process was followed without change for about ten weeks. During this period the error rate dropped to 2,300 ppm. This was primarily due to the result of the initial process mapping tidying-up the work and removing special causes of variation which are the responsibility of the operators themselves. The result was a more ordered way of working which had been clearly defined, and was fully owned by the operators, not their manager. The manager, whose responsibility is to remove common causes of variation, had made it possible for the supervisor and operators to put their expertise to work by changing the overall system of work to introduce process mapping.
During the settling-in period for Revision Zero the operators began seeing opportunities for further improvements. They also saw that there was a need for a means whereby such suggested improvements could be widely discussed and only incorporated with complete agreement of everybody in the process cast of characters. At the same time the cast decided to set a target for error reduction. They chose the simplest method for agreeing the target - a halving of the current rate within six months, followed by further halvings until they beat the 100 ppm target. In fact when the new changes were mapped and implemented (Revision #1) the process error rate had fallen to 1570 ppm within three months by which time the team decided it was time to move to Revision #2. This in turn, once settled-in, was found to operate with an error rate of 760 ppm after three months.
Subsequent revisions reduced the error rate to 410 ppm and some two years after the improvement programme was implemented the rate stood at less than 150 ppm well on the way to the new target set by the MD of 50 ppm! Needless to say the large reduction in shipping errors resulted in a significant improvement in payment interval leading to a much improved - and stable - figure of 3.25 weeks interval being achieved. Figure 8
Having mapped a process in detail it can now be seen that in the context of the three vectors of DFC analysis (teamwork and collaboration, timing and process detail) quality performance will be achieved economically. Further analysis of the process may now be considered under the three process headings of clarification; acceleration and innovation.
The practice of deployment flowcharting and the creation of process maps is based on answering a succession of questions. In so doing clarification was gained of the way the work gets done and how the time gets used. The precise arrangement of the completed maps enables inspection by informed parties with a view to process simplification based on knowledge rather than intuition or guesswork.
The
mapping of process is more important than the process of mapping.
Select
your software carefully at the outset to prevent it becoming a distraction
later on!
Why not
evaluate FlowMap Professional as recommended by Management-NewStyle?
It is the only
generic business process graphics software suite with a DFC default based on
the above methodology.
See www.flowmap.com for further details.
