- Identify the process. A process captures any repeatable set of steps. It is different from a project which captures a collection of work completed a single time to achieve a specific result. Look for work or activities that happen again and again in your organization.
- Name your process. When naming your process be clear and specific. Most often it makes sense to start with a verb. For example, “Collect Past Due Payments” is much more clear and specific than “Past Due Payment Process.” We have a tendency to use broad names to capture related activities, but as we’ll see in the next step, that leads to all kinds of problems.
- Identify a clear start point and end point for the process. The most common mistake we find while reviewing deliverables from Business Process Analysis participants is that they do not have a clear starting point or ending point. Visually this leads to models that have boxes off to the side and not integrated into the workflow diagram. Ask yourself: What’s the first activity that happens or what must be true before the process can start? What’s the last activity that happens or what signals that the process is complete?
- Identify your purpose for diagramming the workflow. Many of the decisions you’ll make in terms of granularity of detail and workflow scope will be driven by your reason for diagramming the workflow in the first place. You might be looking for the root cause of known errors, preparing for a automation project, or initiating a business process improvement project.
- List or draw out a series of steps that happen between the start point and the end point. Make sure that every step actually integrates into the diagram. Use decision boxes to capture variant flows. I highly suggest using pen and paper or the whiteboard for your first draft and avoiding complex tools, which only slow down your thinking and distract you from capturing the process-related information. (When I diagrammed the Business Analyst Career Roadmap, I created no fewer than 3 rough drafts on paper before capturing the diagram electronically.) In Business Process Analysis we frequently review first drafts that are scanned in from paper drawings. We’re easily able to correct any errors in thinking before the participant has committed the diagram to an electronic tool.
- Look for exceptions or rules that are possible at each step in the process. For example, if your main flow is to receive requests by phone, is email also an option? How is an email request handled differently than a phone request? Add this information to your visual model. Often a simple decision box, will be adequate to capture the variations.
- Refer to the standard elements of the Business Process Model and Notation (BPMN) and leverage any relevant symbols in your model. Don’t feel obligated to use more than 2 or 3 elements. Most BAs do not use the vast quantity of options available in the notation because they find it only confuses their stakeholders. As Adrian Reed mentioned in Avoiding Elitism in Your Business Analysis Techniques and Templates, your SMEs probably don’t care whether you use BPMN or a UML Activity Diagram. They want a flowchart they can easily understand.