History of flowcharting Flowcharts originally were hand-drawn, making changes difficult and messy. As computers became capable of graphic representation, the first flowcharting software was developed, at first just for programmers. Two changes occurred that moved the flowchart into the business arena. Programmers migrated into management positions, bringing their tools with them. Also, the computer industry evolved into a mouse-and-menu driven environment, making graphic programs easier to manipulate. As the business community woke up to flowcharting software's potential, enterprising software developers responded with a variety of packages for desktop computers. Second-generation flowcharts The second generation of desktop flowcharting programs greatly improved upon the old, clunky programming tools, proving more usable by real people. Products such as ABC Flowcharter, CorelFlow and Visio, among many other good programs, allow quick and easy drawing of basic flowcharts. The programs are moderately priced--in the $150-$300 range--and provide all of the basic functions needed to draw common business flowcharts. Figure 1 shows a typical business flowchart representing the first phase of a product-development process. A charge is given to a core team. It responds with a mission statement, which is subsequently approved. Initial work begins of surveying both the market and the current state of the appropriate technology. A product specification is developed and approved. At this point, the company has amassed enough information to decide whether to proceed with the new-product development. 
A flowchart, even this simple one, draws a picture of a process that can be readily understood in seconds. The logic flow moves from the process's beginning through all the branching and recombining decision paths to its several possible end points. Not only does the flowchart show the process, it provides a tool for communicating that process in a clear and concise way. Specialized flowcharting tools As business requirements become more sophisticated, the need has emerged for more specialized flowcharting tools, and companies have developed several new classes of software. Project management, workflow and dataflow diagramming, dynamic process modeling and deployment flowcharting are all offshoots of basic flowcharting, each designed to solve a different business problem. Project managers--The need to attach start and finish dates to each process step, thereby creating a project schedule, has engendered such project management software as Microsoft Project and Primavera Project Planner. Strictly speaking, project managers are not an outgrowth of flowcharting programs. The roots of today's project managers, the project evaluation and review technique and the critical path method, took shape in the 1950s during the Polaris nuclear submarine program. Nevertheless, PERT and CPM diagrams are essentially flowcharts with dates attached. For managing large construction projects requiring resource-constrained scheduling and Monte Carlo risk analysis, project management systems prove indispensable. However, they are not simple tools and can require a clerk whose entire job entails feeding data into the project management program. Workflow and dataflow diagramming--"Workflow" refers to task automation, not process. Dataflow diagramming techniques such as the Air Force-developed IDEF0 methodology focus on the flow of data, or information, through a system. The workflow version of the process shown in Figure 1 would show the team members receiving the forms to be filled out and indicate how the completed forms move to the person responsible for reading and processing them. Lotus Notes and BPwin are good representatives of Workflow and IDEF0 products, respectively. Dynamic process modeling--Some applications that include real-time or time-critical processes require dynamic process modeling. Programs such as ProcessCharter and Optima! allow users to create complex interactive models and observe how they perform over time. Usually, this is a multistep process. First, a process flowchart is created in the same way as a simple flowchart program. Then resources and calendars are added to the project; this step is similar to setting up a project management system for resource-constrained scheduling. The simulator will then run the process, indicating how information moves through it. In modeling an order-entry system, for instance, a test case could be set up where many orders were received in a short time to see where bottlenecks occurred and where more resources might profitably be used. Deployment flowcharting-- During the 1980s, the emerging quality movement brought its own special requirements to flowcharting. The movement's team focus required flowcharting programs to model how the team fit into the process. Several unsuccessful attempts were made to develop relevant software before someone finally turned to the father of the quality movement himself, W. Edwards Deming. Deming's work at Komatsu Tractor Co. inspired a new flowchart that depicted team members across the top, with each process step aligned vertically under the team member or members working on it. Process steps were connected by arrows, as in ordinary flowcharts, to indicate process flow. The Japanese term for this concept, which roughly translates into "management across the functions" was Anglicized into "cross-functional management." Myron Tribus, former dean of Dartmouth College Thayer School of Engineering and a Deming disciple, popularized the method in the United States and coined the term deployment flowcharting.  The "simple" innovation of adding the team to the process flowchart has dramatically changed the amount of information conveyed by the picture. Figure 2 represents a product-development process as depicted by TeamFlow, a deployment flowcharting program. This flowchart shows who on the team is involved in each step and where team members must work together.
The information flow between team members also is shown. The horizontal data branching from each arrow indicates an information hand-off from one team member to another. These microcustomer/supplier relationships lie at the heart of team-based quality. They answer the questions "Who is my customer?" and "Who will use the work I am doing?" for each team member at every step of the process. Flowcharting the future Flowchart software, like much of the rest of the software industry, is moving in two general directions: integrated and Internet. Integrated software combines all related information into the same document, whereas Internet software distributes it. What formerly sat on an executive desktop now must be distributed, in some cases worldwide, as teams disperse and become virtual. As products move toward integration and the Internet, programs must be capable of directly linking flowcharts with other applications and stored data such as schedules, costs and personnel information. A well-designed flowchart program should allow the user to attach an online document, created by any application within the system, to any process step, and then open and view that document directly from the process flowchart. Think of this in the context of an ISO 9000 process, which requires that team members have access to the latest revision of the appropriate standards and support documents. Thanks to flowcharting software, this cumbersome ongoing ISO 9000 requirement has become almost trivial. The other significant trend is distribution--of both people and information. These days a project team rarely works as an entirely co-located unit. Even the definition of "co-located" is changing. In their excellent book, Virtual Teams (John Wiley & Sons, 1997), Jessica Lipnack and Jeffrey Stamps define co-located as a radius of only 50 feet! Teams that are not co-located--i.e., virtual teams--require constant, reliable electronic communication to support their teamwork. The Internet has become the communications medium of choice for virtual teams because of its widespread availability and relatively insignificant cost. In order to support this dispersed work force, flowchart programs must support the Internet. Publishing your flowchart to an intranet or the Internet represents a good first step. All team members, including customers and external suppliers, can then easily access the information. Teams that read and write process models across the Internet can be more productive regardless of location or time issues. Flowcharters that allow users to attach Internet-resident HTML documents to process steps and view them from within the model give the greatest flexibility to virtual teams and external customers. Used in this way, your process flowchart and all the documents attached to it become both planning and communications tools and serve as the knowledge base for any project. About the author Ronald M. Cordes has spent most of his career developing software to help people manage their work. He was a key developer of PROJECT/2 during the 1970s and the MAXIMO maintenance management system during the 1980s. He founded CFM Inc. in 1989 to develop and market TeamFlow, the first deployment flowcharting system. He may be reached at telephone (781) 275-5258, fax (781) 275-7008 or e-mail rcordes@teamflow.com. |
