Business Process Modeling
Business Modeling can take many forms. The choice to use business modeling, and the choice of the type of modeling to use, require a clear understanding of the objectives of the modeling exercise. Business modeling is an area where excessive effort and cost can be expended for little benefit if those objectives are not properly understood.
Business Process Modeling is used to create an understanding of business processes and to assist in their the design and implementation.
- Objective: Create a common understanding of a business process amongst the participants and external stakeholders.
- Objective: Gain agreement amongst the stakeholders as to how a new/improved business process should operate.
- Objective: Design a new business process with enough detail to support the implementation of the process.
Objective: Create a common understanding of a business process amongst the participants and external stakeholders.
This objective implies that there is no documentation, or inadequate documentaton, of the existing process. In this case, it is usual to find that the existing process is not only poorly understood, but is also inconsistently performed, executing differently every time. It may even be the case that there is no real process at all, but rather a collection of tasks that get performed on demand. When attempting to document an existing process, it is common to find that there are so many exceptions or special cases that to accurately document the "as is" process is a waste of time.
In this case, it is very helpful to document an idealised version of the process that is simpler and more consistent. Then you are no longer documenting the existing process, but in fact designing a new one. If the intention is to improve the existing process, then this may in fact be the first draft upon which further process improvments are made. Such changes, of course, need to be made in collaboration with the stakeholders in the process.
Often, the dependencies between the various activities in the process are not well understood. In this case, it can be helpful to create a list of the activities, their outputs, and their required inputs. The inputs and outputs can be collectively referred to as "deliverables" or "handoffs". Every activity's output should either be an input to another activity, or a required output from the process. Where an activity has one or more inputs, this indicates dependencies upon the activities that generate those handoffs.
Once you have your list of activities, and their handoffs and dependencies, showing them with a diagram is an excellent step towards a better understanding of the process. In all but the most trivial processes, it is helpful to arrange closely related activities into high-level activites, showing them on one diagram, and the details of each high-level activity on a separate diagram. There can be multiple layers of this approach. It is generally best to make a first cut of this grouping prior to commencing diagramming, and then to refine it as the diagramming proceeds. I find that the most clean, compact, and understandable notation for these diagrams is an IDEF0 diagram. For organisations that have a UML culture, a UML Activity diagram can be used, with object flows showing the handoffs. However, this is less compact, more cluttered, and hence less useful for this objective than IDEF0. A PERT or Network Diagram can also be used, although most tools limit the layout options and these diagrams can become very big and ugly. Another view that is very useful is a Gantt chart. You can choose to omit the handoffs, and just create dependencies between the activities, or, if you wish to show the handoffs, you can represent them as milestones. A Gantt chart allows you to assign costs and durations and understand the time and cost impacts of any potential changes to the process.
Combining these diagrams in a document with some supporting explanatory text, you should find you have an excellent vehicle for discussing the process with the stakeholders and generating the common understanding which is your objective.
The key to the success of this approach is to limit the detail. Keep the activities at a level of detail that the audience is interested in. If in doubt, it is usually best to err on the less-detailed side, and then elaborate if the stakeholders ask for more information.
Objective: Gain agreement amongst the stakeholders as to how a new/improved business process should operate.
The approach here is very similar to the above objective (Document a business process to enable a common understanding of the process by the participants and external stakeholders). If there is an exiting process that is being improved or replaced, then the approach described above starting with the list of activities, inputs, and outputs will be a good approach. However, in this case, there is more emphasis on questioning why an activity or input is required and eliminating them where possible.
If there is no existing process to use as a starting point, or if you desire to not let the new process design be influenced by the old one, then you should start with nothing but the objectives and required outputs of the proposed process. Then means-end analysis is used to build a list of activites, inputs and outputs.
The means-end analysis takes the following form:
- For each required output or objective, determine the activity required to produce/achieve it.
- For each activity, identify the inputs that are required.
- For each input, if it is not already available from outside the process, determine the activity required to produce it. Repeat steps 2-3 until no further inputs are required.
From this point, the approach is the same as for the above objective.
Objective: Design a new business process with enough detail to support the implementation of the process.
Often, the process model produced in response to the objective Gain agreement amongst the stakeholders as to how a new/improved business process should operate is not detailed enough to support the implementation of the new process. Having obtained the agreement to this broad process outline, you now need to identify the necessary resources (people and tools), and business entities, and their responsibilities.
The people (more precisely the roles the people play), and the tools that are responsible for performing some task(s) in the process are referred to as business workers.
The things (real or conceptual) that the process manages and manipulates (such as accounts, requisitions, assets, equipment, etc) are referred to as business entities.
Business entities usually have properties that may or may not be changed by the process (referred to as attributes). They may occasionally have responsibilties of their own.An very good way to model a process to satisfy this objective is as a UML Collaboration. Collaborations are described by collaboration diagrams and sequence diagrams. Sequence diagrams show the sequence of tasks the proces participants (business workers and business entities) perform. Collaboration diagrams provide a summary of the interactions between participants.
Having modelled a process as a UML collaboration, a UML modeling tool (as opposed to a drawing tool) will allow you to list the full set of responsibilities of each business worker and business entity involved. For people, this provides a good checklist for their position descriptions, work instructions, and competency-based training. For tools (forms, templates, software), it provides a good checklist for the features that need to be provided.
If you have modeled your business requirements as use-cases, then your may choose to realise those use cases as your highest-level UML collaborations.
Additional Resources
Online
- Heumann, J. 2001, 'Introduction to Business Modeling Using the Unified Modeling Language (UML)', The Rational Edge, March 2001
- Wardley, J. 2001, 'Tighten Business Processes Before You Automate', The Rational Edge, April 2001
Other
- Eriksson, H. & Penker, M. 2000, Business Modeling With UML: Business Patterns at Work, John Wiley & Sons.
