The figure shows the major steps for business process design. In practice these steps are executed iteratively while results are directly implemented. This enables agile process development, while design quality is maintained (and even improved). Using these steps helps delivering quality, because it assures that the business process design:
- is focused on the purpose of the design, involving relevant stakeholders and with a clear scope and techniques (step 1);
- will meet the proper requirements for quality and performance of the process as well as for organisational goals and policies. Performance is driven by the Voice of the Customer, either external or internal (step 2). During the rest of the design process regular evaluations of the process against the requirements are documented;
- creates a lean business process, since the design starts from a logical or functional process model and is built with focus on the output and custormer journey (step 3);
- creates an autonomous and self-controlling business process, by integrating control loops starting within the process itself, extending this to existing or new business processes for control and support. This assures that the process requirements are met during operation through a risk-based design of control and support (step 4);
- a realistic and implementable process is created, because the desing includes the organisation of the process with people, information and other means. This enables the alignment with supporting departments such as IT, HR and Facilities during the design process.
The rest of this page summarizes the design steps. A more detailed method map is presented in the figure at the bottom of the page. In the Dutch book "Grip op processen in organisaties" (Getting a grip on Business Processes) the method is explained in detail, including relevant techniques and knowledge. We are still looking for an opportunity to publish the book in English....
1. Define the Design contract
Before starting the design it should be perfectly clear why the design is made, since the design artefacts, scope, participants and level of detail of the design are derived from this goal. Without a clear goal for the design its quality (Duran: Fitness for use) cannot be evaluated. The design contract is the agreement between the (internal) client or responsible manager and the design team. It can be written in a formal (separate) document or as part of a larger plan, for instance for the realisation of improvements or the development or purchase of a new software application. The format should be adapted to the common standards used, as long as all topics are properly addressed.
Besides the goal for the design effort (Why) will also be agreed on What will be designed and How this will be done. The 'contract' avoids discussions during the design en larifies for all participants what is being achieved and how. The Why includes context for the design, such as the change goals and change approach. What includes beside the scope of the design also the level of detail and the modelling language and tooling that will be used. How describes which steps are taken for the design, who participates in the design and what roles are played by every participant.
The contract may change during the design due to new insights from the design or changes in the context of the design work. Although a scope creep should be avoided, it is necessary to address all issues that arise when trying to construct a process that meets the process requirements necessary to achieve the goals that were set for the design.
2. Establish Process requirements
The process requirements are both performance requirements and organisational requirements.
The performance requirements are derived from the external or internal customers wishes and demands and the custormer journey that suits best (within given constraints). Examples of performance requirements are product quality, % completeness, maximum lead time, customer waiting time and production costs. For each work process the end-to-end processes that it makes part of together determine the performance requirements. When a Business Process Architecture is available, this may already contain part of the (high level) requirements. When insufficient information is available on customers wishes, additional techniques such as the Quality Function Deployment technique may be used to determine the performance requirements.
The organisational requirements address the way the process is organised and determine some of the constraints for the process design. Examples of organisational requirements are: the mandatory use of a certain information system, staff function descriptions, or the building and floor that are available for the department executing the process. The organisational requirements can be obtained from policies and regulations, or just by asking the proper (support) departments and staff.
The total set of process requirements normally contains requirements that are difficult to combine or seem conflicting. Here lies the design challenge for the process design(er)! The requirements may be revisited during the design process when they are impossible to be met.
3. Design the Process flow
The design of the process flow is the central step in process design ans is made using four (iterative) steps:
3-1 Model the context diagram: The context diagram shows all inputs and outputs of physical products and information products of the work process. If a Business Process Architecture is available it will contain the basic information for the context diagram. Make sure that input/output relationships for all end-to-end processes is taken into account and also relations with control and support processes.
3-2 Model the logical process flow: The logical process flow contains activities and their sequence independent from the (current and future) organisation of the work process. The process steps can be retrieved from a detailed business function model or by 'de-organising' the current business process. Only formal and logical sequence of activities is taken into account. The scope of activities may differ from the actual execution of the work process.
3-3 Design the operational process flow: The key question here is how do we effectively and efficiently meet the process requirements (or how doe we create a lean work process). The balance between automated and human activities is determined, resulting in the scope, organisation and flow of activities, including logistical information such as buffers. It is important to do this independent from the current execution of the work process. The result of this step is a business process map with proper descriptions for each activity. Design and modeling decisions are explicitly written down.
3-4 Verify the process requirements: When the operational process flow is completed you fill the checklist Process Requirements, verifying if all requirements are met. This can be done with a group of (operational) experts and with support of physical and softwarte supported simulation of the work process. For certain customer driven requirements it is helpfull to (re)draw the customer journey for the entire end-to-end business process.
For a "Complex-dynamic Business Process" (with too many possible flows and too many changes over time) it is impossible to draw the actual business process map. Here we use a different design approach with activities and business (process) rules.
4. Design Process Control and Support
The approach for the design of control (and support) process elements is based on the analysis of potential risks that the process flow will not meet the requirements. For each risk that occurs measures are taken by adding operations or activities to the designed process flow (step 4-1) or by addressing these with existing or new control and support processes (step 4-2). This is based on the theoretical concept of control loops, which may mitigate the risk beforehand (e.g. by planning workload and resources) or at occurance (by repairing the mistake or by taking other actions, such as prioritizing work).
The design of control and support comprises two steps:
4-1 Incorporate Process Control: We investigate which events create a risk for not meeting the process (performance) requirements. For each event or risk we evaluate which measures can be taken in the work process, based on control loops or avoidance of the event. Measures may contain changes in the organisation of certain activities (e.g. with better tooling or information systems support), additional operations or additional activities in the process. For example, the risk of not meeting leed time requirements can be solved by adding a prioritization step (operation or activity) in the business process. As a result for this step new information is added to the process design and the checklist with process requirements is reviewed and updated.
4-2 Identify Control and Support Processes: After completion of the previous steps some risks remain that cannot be mitigated within the work process itself. An example is a sick employee or a workload that requires additional staff in order to meet leadtime requirements. Calling in additional staff or changes in work planning require a separate business process, either within de executing department and roles or a specialized department or role. For each risk that cannot be resolved within the work process we investigate which existing control and support processes may solve the issue(s). This may result in additional operations or activities and/or new inputs and outputs for the work process. When insufficient solutions can be found the design of a new (end-to-end) control or support process can be initiated.
The design process steps are summarized in the visual below. The practical organisation of the design process can vary. Very often a series of workshops is held with in each workshop an iteration (or a part of) the design process. One can view te steps as a framework for structuring not only the design work, but the thinking and logical reasoning as well. The quality of the design will benefit, resulting in satifsfied customers after implementing the work processes (improvements).
