Introduction

7:00 AM is a miserable time of the morning to have to start work; it is an even more miserable time to begin a presentation on a difficult job to an even more difficult audience, only to have it end by nearly being booed off the platform about 15 minutes later. I know this because it happened to me a long time ago, when I first tried to present a complex diagram of a flow of work to a meeting of the Common Automatic Test Equipment Integrated Logistics Support Management Team (CATE/ILSMT, to insiders) in San Diego one beautiful summer morning in 1980. Out of this experience, in some ways, grew the procedure I am going to share in this small volume. This technique, called workflow mapping and analysis (WFMA), is a way of visually capturing a flow of work by using a small set of symbols in a very consistent way; it was born from a need to visually portray a challenging flow of work in the maintenance of aviation electronics (“avionics”) for the U.S. Naval air force (“NAVAIR”) during the Cold War. This is a method that was developed from a need to communicate important information about that workflow to military and civilian navy personnel who needed to know it, and not get booed off the platform before that communication could be accomplished.

Within a few years, I had developed a revised approach to WFMA which met with a much better reception, and hence was much more effective in helping me and several colleagues meet our objectives in our research with the CATE/ILSMT. A large part of this had to do with mapping a hugely diverse range of workflow activities and procedures, along with their supporting flows of information. This required a technique which was flexible and robust enough to capture everything that happened in that flow of work. I refined this technique even further when I began working on an article for the academic journal Administrative Science Quarterly that was published in 1984. By that time, I had come to realize that while WFMA used a small set of standard flowcharting symbols that I had learned in my college programming courses, WFMA was not “flowcharting” by any stretch of the imagination; that was one of the things I had to unlearn to really make this technique work. Of much greater importance was the realization that WFMA was a potent tool to capture all kinds of knowledge embedded in a workflow.

Among the chief lessons I had also learned was that the symbol set necessary to communicate graphically about flows of work and information could also be the greatest obstacle to success. The symbols are necessary, but they must be as simple and unobtrusive as possible if they are not to smother the information they provide. The particular symbols and the disciplined approach to WFMA that I present here may seem overly simple at first, and overly rigid at other times; I argue that neither of these is true, but rather that my approach has been developed through many years in the infamous school of hard knocks, and what has emerged is what works. Some of my experience tends to support an old, somewhat cynical definition: “‘Experience’ is that which makes you wonder how it ever got a reputation for being the best teacher.” But it was, and what I learned in those years is one of the principal influences in shaping my approach to WFMA.

My experiences in the NAVAIR environment were given another challenge in the early 1990s, when I was asked to examine the avionics maintenance processes used by the royal canadian air force (RCAF). In 1980, the Canadians purchased a new wing of CF-18 Hornets from McDonnell-Douglas (now Boeing) to replace an aging mix of various aircraft in the RCAF. The CF-18 is an export model of the U.S. Navy’s F/A-18, and is supported by a similar type of automatic avionics tester, which was the subject of my studies in the U.S. Navy; within a few years, the Canadians had begun to experience the same kinds of avionics maintenance workflow problems as had the U.S. Navy, and similarly suspected the automatic tester to be the culprit. They came to the tester manufacturer for help with solving the problem; I was asked to take this on, and I found that analyzing their workflow through WFMA was again the necessary first step, just as it had been for NAVAIR. The end result was a 1991 management manual that helped the RCAF deal with the challenges of this workflow.

By the early 1990s, I had begun to develop this approach into a course which I still offer, and applied it in a number of companies and non-profit organizations. I found that my approach functioned just as well in service workflows as it did in maintenance or manufacturing environments. This is not very surprising in retrospect, since the original NAVAIR workflow was a repair process; while it handled physical materials, it was really a knowledge-intensive service activity that required the diagnosis of faults and the replacement of parts, with follow-up testing to be sure a repair was successful. All of the major issues in that workflow, we came to find, were issues of information and the processing of it, and not issues with the hardware or software; the avionics maintenance process is really an excellent example of “knowledge workers” at work.

A final realization from these years of experience and investigation was that one of the principal benefits of WFMA is that it makes many aspects of the knowledge embedded in a workflow explicit, even when these involve information processing and decision making that are the results of many cycles of trial and error, perhaps involving many people and long periods of time. In today’s discussion of “knowledge management” this has been recognized as a principal form of “tacit knowledge.” WFMA is capable of capturing both formal and tacit knowledge and making it accessible to a company or organization. In the case of NAVAIR, it became an absolute necessity for resolving a very serious problem of Cold War readiness for the fleet’s carrier aircraft.

Knowledge management (KM) is one of the most challenging tasks facing many companies today, and is often one of the most frustrating. WFMA can not only make both formal and tacit knowledge visible and accessible, it can provide a repository for storing both types of information. Thus, it can be a tool for creating and storing job descriptions; it can serve as a training tool; it can be a key tool in personnel accession planning; and, of course, it is a fundamental requirement for Six Sigma programs, quality management, and process improvement.