Kathy Long is leading a tutorial on business processes.
A process is a repeatable series of activities that produces value for one or more stakeholders. It is more an art than a science. We need to understand inputs, outputs, guides and enablers.
Questions to answer to help us identify “What we do” (IGOE method):
- What we need to do it?
- What we produce or deliver
- Why, When and How we do what we do?
- Where we do it and What and Who we do it with?
Example: “To make Coffee”:
- Hot Water
- Ground coffee beans
- Coffee Machine
- Coffee Filter
- Coffee Cup
- Documented experiences
How to decide between input and enabler? What is more important? For example the filter can be consumable but it can be an enabler.
We also need to decide where the exact start and end is. Otherwise, do we know if we have to also include sweetener, milk and cream, etc? The “boundaries” will be our guide to decide if this process needs to include that information. Also, try and limit the number of details (the need for electricity for example) because it would clutter the process being documented.
In a process box, the label should be and action and an object. Avoid ambiguous words such as “process” or “Manage”.
To help us do the analysis, start from the top and perform a “Process – Activity – Task – Step Decomposition”. break down processes in activities all the way to the task level. Don’t go too deep because you may end up documenting parts of the workflow that has a tendency to change (unless automated).
She then covered different methods with pros and cons
- IGOE (based on IDEF)
- Process Decomposition
- BPMN Light
- IGOE Flow
- BPMN Full
She took some time to detail how to document the Guides from IGOE since this will be the link between the business process and the business rules. Business Processes can be broken down to Business Activities and then to Business Tasks. Business Rules will be defined as part for the Business Tasks. We walked through a “story” to show how to apply the “Guides” decomposition to it.
We would obviously need to do this exercise for Input or Outputs.
People have been trying to separate process and rules when they actually need to be worked on at the same time.
A lot of the presentation was explaining IGOE and how to use it. It is very interesting and made me realize that I may have been documenting things at a level of detail that may have been inappropriate.
My key takeaways from that tutorial
- Standardization does not mean use only one notation, each notation has an audience that it applies better to
- Stay at a higher level, don’t go all the way to the workflow level. Workflows are rarely accurate for very long (unless automated)
- In a Business Process Model don’t model: Rules or Events