-- Mark Geljon (email)

I recently started working on a quality program in my company called six sigma. Process mapping is one of the exercises/tools we use in the discipline & there are many sites that have mapping tool discussions (isixsigma.com). I have my own summary (2minute viewlet) of the key things to identify in a process map & how to actually run such an exercise if you are interested. The key items that the example here are missing are players & phases. In any process (natural or "business") problems in can be more easily identified when the process has "linearity", that is, is as chronological as possible (i.e. the starting circle should be at the top and the ending circle should be at the bottom). Let me know if this helps or not! Take good care. Joel Mackall

-- Joel Mackall (email)

Rarely are processes -- business or otherwise -- truly linear. The more complex the process, the more dependencies and other constraints become evident. The method depicted earlier in this thread, then, seems a bit oversimplified (but maybe that's because this example didn't use real data?).

Generally speaking, to diagram a process, I use a data flow diagram (in acronym-ese, that's a DFD). This kind of design shows a process from the point of view of the data. There are just a few basic shapes: - circles, which represent processes - arrows, which represent data flows - boxes, which represent external entities - open-ended boxes, which represent internal/temporary data stores.

The method is to first create a "context-level" diagram showing all the external entities (i.e., the "actors" or users or other systems), and how the data flows between those entities and the process to be diagrammed, which is shown as a single circle. Further decompositions of that context-level diagram break the high-level process into lower-levels, and each of those can be further delineated on a separate page. Often a small-scale version of the first-level decomposition is included on the "drill-down" layers to help lend context to that particular layer. If I have some time, I can try to find a non-proprietary example.

Of course, this method is well suited to designing software to run systems, but not as useful when designing an interface. The best it can do in that case is to point out where the interfaces are and what data needs to be captured/communicated at that point (actually, that's probably a large part of interface design).

I've seen other diagrams similar to the method I use that add "swim lanes" -- processes are placed in rows depending on the person/system performing them.

-- Scott Zetlan (email)

I would suggest taking a look at UML (Unified Modeling Language) activity diagrams. This notation supports the use of swimlanes to show roles, as well as conditional decision points and parallel processing, which are not supported in standard data flow diagram (DFD). A very simple example of the UML activity diagram can be found on my company's site at http://www.tankainc.com/pages/projectprofiles01.html.

One of my few gripes about UML is its lack of support for diagramming data flow and entity relations for data modeling. In some cases, activity diagrams can be used to suggest data flow. However, activity diagrams, by their nature, express sequence and cause and effect, which may not necessarily be the intent when mapping data flow. Since the UML notation is designed to illustrate process, it also lacks representation for data stores. For this reason, I'm currently using DFDs for mapping data flow and UML activity diagrams for showing process in my work.

-- Brian McGurgan (email)

The design issues here are similar to those in the thread on project management charts. Redesign strategies for the chart above (eliminate heavy boxes, etc.) can be derived from the project charts posted on our thread

https://www.edwardtufte.com/1825116291/bboard/q-and-a-fetch-msg?usca_p=t&msg_id=000076&topic_id=1&topic=Ask%20E%2eT%2e

-- Edward Tufte