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)
Mark