There has been a noticeable return in the past decade toward process in improvement work…a focus on improving and managing business processes. It is a general understanding that the business processes are the work we do. And, if we want to be better at what we do, we need to look at our processes. Without a method and good tools, good intent is often squandered. We need to look at our processes in more than a cursory fashion. We need to look at them in detail and understand the details. When we don't understand the details, it is easy to miss inefficiencies. When we don't understand the details, we may be enabling subversive or counterproductive activity. On the other hand, when our processes become transparent, it is difficult to not see the problems.

If we want to improve our processes, we need to understand them IN DETAIL - by reviewing and analyzing detail process charts. Simply talking about processes won't cut it. Looking at them from 10,000 feet isn't going to cut it -- If we read through procedures and talk to the managers and supervisors about the processes, we are gaining an understanding that is at least one step from reality. If we document processes using this information, the documentation will not reflect reality. We need two things to make useful detail process charts…the right information and a good tool.

The right information
The right information is NOT captured on any document. The best you can hope for in a document is a snapshot of a point in time. The longer the documentation sits around, the greater the likelihood that it has become outdated. Processes change and the documentation that supports them (if any exists) necessarily lags behind. Even detail process charts become dated the longer they sit.

The right information is NOT in the heads of the managers and supervisors. Managers and supervisors should be managing and supervising. They should not be getting involved in the details of the work they are managing. The right information IS in the heads of the PEOPLE WHO DO THE WORK - the people who, day in and day out, are living the process that you want to document. It is the accumulated experience specific to the process that you want to chart. These people know WHAT HAPPENS in their part of the process better than anyone else because it is what they do. They know what appears to make sense in the process and what appears to be nonsense in the process. They know how to make their piece of the process work and how to get around it when it doesn't work.

Even with the right people, it is not enough to just ask them what they do. If you want your charts to reflect reality, then watch reality. Observe the process. See the person in action. It simply makes good sense to collect the process information - gather the facts - at the workplace. There are many reasons why it makes sense to gather the facts at the workplace. You can see how the work starts and how it is finished. If you observe the work being done, the information sources and reports become apparent. You have access to forms, source documents, logs and system applications that are involved in the process. (It's a good idea to collect copies along the way. They will be helpful during analysis and may be useful when you are preparing the process chart.) You can observe the physical layout and see if the process causes the person to leave the workspace for any reason (to pick up or drop off work, make copies, pick up printouts, gather source information…). If you try to document the process with a group of the right folks gathered together in a room, you will miss things. The focus will be on the "value-added" steps (filling in the forms). While this information may be correct, you will likely overlook the non-value-added steps that account for the majority of the processing time.

The right tool
The right tool must provide useful information that helps people do their jobs better. It should be easy to use and easy to understand. There are a lot of tools available that provide symbol sets. But if the symbols are not wrapped in a methodology, then the charter has to invent one. (Collecting the data, stringing the symbols together, handling rework…unusual situations…) Fortunately, the work simplification charting method has made this easy with a small, well thought out symbol set and methodology that provides elegant structure to the ominous task of process charting. The fact that the work simplification symbol set was adopted as the ANSI and ASME standards for Process Charting fifty years ago is testimony to its fundamental simplicity. It has flowed through a half century of new technologies and constantly changing processes with the grace of an alphabet…because it is fundamental. It is basic. It gets to the roots of our processes. It speaks the language of process.

Four basic symbols represent doing work, checking work, moving work from one location to another and nothing happening.

Four additional symbols represent variations of doing work. The four variations of doing work include three variations of value-added work and a symbol representing destruction or termination. The value-added symbols are the Do symbol for manufacturing processes and the Originate and Add/Alter symbols for information processes. That's it! Eight symbols.

It is just as easy to document the drafting of a letter whether it is handwritten or prepared electronically - the letter is CREATED.

It is just as easy to document the transport of the letter if it is hand carried, delivered by a postal carrier or sent electronically - it is MOVED from one location to another.

The beauty lies in its genuine problem-solving format. It breaks down the work to INDIVIDUAL elements. The processing of each item (document, form, letter, log, record, file, email…) is represented as a horizontal line. The name of the item is identified in a label at the beginning of the line and the activities (AND periods of non-activity) that occur are represented with symbols laid along the line in sequence.

Most information processes include the processing of several items. Any relationship between two items, where the information on one item causes something to happen to another item is clearly represented. (The receipt of an item is entered on a log, an order form is transcribed into the Order System, the receipt of an item causes a project file to be pulled, a photocopy is made, an electronic document is printed, an account number is checked against a bad account list…) The relationship is displayed with vee-shape line that points from the item providing the information (the open end of the vee) into a symbol that represents the activity that happens to the other item.

These relationships between items are what tie many items together as a single process. This is arguably the most difficult concept to grasp for a person preparing multi-flow process charts. However, with little explanation, most people can read and understand a properly prepared chart.

With a single line process flowchart, what happens when the work divides? At best, the multiple items are described in the activity. With a multi-flow chart, when the work divides or separates, the chart separates. What was a single flow line becomes multiple flow lines.

This takes us back to our fundamental concept of breaking the work down into individual elements.

Even at a bird's-eye view, the number of items in this simple process stands out.

Delays are apparent. Movement between work areas is apparent. Value-added work is apparent. The amount of non-value-added work is apparent.

Most business processes that are mapped are mapped at a high level with single-line process maps. This type of mapping is derived from the programming flowcharting technique that was introduced by IBM in the late 60s. It is a useful tool for following the flow of a program. The flow is the program. The focus is on the program. Processing is shown in a Process rectangle and Alternatives are presented with a decision diamond. Inputs can be identified as parallelograms with a line into the program line and outputs are identified as parallelograms with a line coming out of the program line.

Applying this method to business processes is difficult. People don't normally think in terms of inputs and outputs. They understand the work they do - documents, forms, application screens… The method is not intended to follow multiple flows. The single flow is a program. Business processes rarely involve only a single item. They may include multiple documents and involve interfaces with several programs. Adapting the documentation of business process flow to the structure of program flowcharting necessitates grouping blocks of work into process or activity boxes. Individual items get buried in the activity boxes or overlooked. The concept of value-added is not employed. Delays are typically not identified. Every single step invites assumption.

Still, good people who understand parts of the process can get some value using high-level charts for improvement. Some modify the method to incorporate genuine detail process symbols (or steps) to denote delay, transportation… This is a testimony to capable people who manage to be successful despite having inadequate or inferior tools. High-level charts may provide enough structure to help an analysis team stay focused on the process and challenge the process blocks in sequence. HOWEVER, the team will have to dig into details to make good decisions about the process.

Since the value of high-level charting is limited, it is often given cursory attention or is even ignored reinforcing a self-fulfilling prophecy - process charts don't provide much value, therefore we won't use them (thereby ensuring that there will be no value provided!). WE SHOULD NOT BE USING HIGH-LEVEL CHARTS FOR IMPROVEMENT! We should use detail charts and capitalize on the true value of process charting. The process represented in the previously displayed high-level chart was also captured in a detail process. The detail chart stretched over fifteen feet long. While daunting from a distance, when you focus in on the steps, each step is clear. As you move from one step to the next, each step makes sense, the workflow becomes clearer and the process becomes understandable.

Detail charts may be intimidating at first glance. However, the chart is a reflection of the process. If the chart is complicated, the process is complicated. It is a challenge to understand a complicated detail process chart that flows through several workstations, passes through departmental boundaries, causes the origination and dissemination of dozens of forms, logs and reports, requires access and manipulation of data in multiple systems by many users. Imagine a team of people trying to sort out and make decisions about the details of a process with several hundred or even thousands of steps without the benefit of a detail chart.

We wouldn't consider building an automobile, an aircraft, a home, an office building… without the benefit of a blueprint. Business processes, on the other hand, are often built on the fly, then parts of the process are modified in isolation. In a short time, a process can evolve into a convoluted, inflated mess that nobody understands completely.

An experienced charter can often produce a detail chart more quickly than a high-level chart simply because there is a structured methodology to support it (the charter doesn't have to figure out what to include and exclude from each step).

Many improvement methodologies state the importance of identifying the current process, yet don't specify how to do it. It would be to the advantage of anyone promoting an improvement methodology (or certification requirements) to offer guidelines that will help people accomplish this essential first step successfully.

Tools for building and maintaining good business processes have been around for a long time. Chances are there are people in your organization that have worked with or at least seen detail process charts some time in their career.
While there are organizations benefiting from the use of detail process charts around the globe, there are many more that are not. We need to instill into our organizations a discipline to become masters of our processes and not slaves to them. Building and maintaining a library of detail process charts is the first step.