Blueworks Live

IBM Blueworks Live is your front door to digital transformation with the IBM Cloud Pak for Business Automation. The digital transformation journey starts with the Gather phase, where the focus is on identifying a sponsor and business goals, building your team of business and technical subject matter experts (SMEs), and capturing the model of the current business operations and pain points. In the fifth posting of this series of articles we introduced some guidance for initial discovery and documenting of the current state. In this posting, we will expand upon that topic to discuss best practices for modeling the current state  As-Is processes for your digital transformation initiative. This article explains how to structure the discovery by using multiple passes through process modeling; each pass will be focused on a different objective, such as the happy path, the  exception paths, and the process properties: supplier, input, process, output, and customer (SIPOC) and responsible, accountable, consulted, and informed (RACI) parties.  

It is encouraged and recommended to take multiple review and discovery passes over the process when modeling. Each pass will be focused on a different, but specific, topic and possibly involve different participants and stakeholders. Part of discovery is aligning different perspectives of the process and arriving at a common consensus view of current state.  It is through these multiple passes and an iterative approach to discovery that the most comprehensive, consistent, and complete model can be captured through collaborative sessions.  

Happy Path  

When starting to model current state, it is recommended to begin with an As-Is process depicting the happy path. Initially focus on how the process should be conducted, and how it is actually conducted in the most common, normal or frequent scenario. This means, capture the process as it is today, the good, the bad and the ugly; it is all important. Also, while modeling the current state, it is important to resist the urge to solution. Focus on discovery and modeling how things are done today. 

Most processes have numerous varying flows, with frequent routes and exception cases that deviate from the process happy path. Initial modeling and discovery efforts need to stay focused on the happy path, though. Wait until a first iteration is complete before moving on to capture alternative flows or exception paths, as discussed in the next section. 

The happy path should contain milestones, activities, and decision gateways to properly model the current state as it is most commonly executed today. The decision gateways will create additional flows, which can be discussed and modeled as long as they still apply to the happy path. Anything that is less common, less frequent, or an exception to how the process should execute as currently designed can be quickly captured for future discussion, but these alternative paths should not be thoroughly reviewed during the initial iteration to capture the happy path; don’t worry, this is an iterative approach, you will come back. 

Exception Path(s) 

After modeling the happy path, adding exception paths and less common flows are important to fully discovering and documenting the process. The exception paths should be prioritized based on frequency and severity. The more frequent and more severe an exception is, the higher its modeling priority. The 80 /20 rule can be applied here where enough exceptions are modeled to understand the flow, activity attributes, frequency, and severity with sufficient detail to arrive at a baseline that can be used to identify opportunities from, improve upon, and compare future opportunities against. The key is to understand the exception paths enough to transform the process to both minimize exception frequency and severity, and design a solution that quickly remediates any issues or deviations from the happy path. Again, keep in mind this is iterative, so not everything has to be captured at once. Each pass helps validate previous discovery, uncover new attributes and provide more details. 

Remember that the current state model with the happy path and exception paths captures the good, the bad, and the ugly. The future state aims to keep the good, remove the bad, and improve the ugly. 

Once you have a good depiction of the process flows, both happy and execution paths, you can start layering on process attributes into the process activities with SIPOC and RACI. 

SIPOC 

SIPOC stands for supplier, input, process, output, and customer. Suppliers, inputs, outputs, and customers are key parameters used in process modeling to ensure a comprehensive understanding and baseline for the process. For the process itself, and then for each activity in the process, prioritizing happy path activities first and then exception path activities, edit the details and add the SIPOC information as exemplified in Figure 1. Gathering the SIPOC information can take multiple passes over the process, as you may require different subject matter experts (SMEs) to provide the details for individual activities.  This documentation can even be performed as an off-line activity where each SME captures the details of their expertise individually in the relevant process activities. Once the documentation is complete, the SMEs can then come back together for a collaborative workshop to review the details as a group. 

Figure 1: SIPOC Activity Attributes

RACI 

RACI stands for responsible, accountable, consulted, and informed. These process attributes are key components in process modeling to ensure all participants and stakeholders are properly identified. The mapping to Blueworks Live attributes is provided in the process activity details as follows in Table 1. 

Note that the Informed attribute is less commonly captured, but if your team does want to document this attribute, you can define a custom property for this purpose in your Blueworks Live account as described in this posting. 

The RACI attributes should be captured in a similar manner to the SIPOC attributes, first at the process level itself, and then for each activity in the process. The RACI attributes are documented by editing the details as shown in Figure 2.  

Figure 2: RACI Activity Attributes


Gathering the RACI information can take multiple passes over the process with different SMEs, like the approach for capturing the SIPOC attributes.  This documentation can also be performed off-line and then reviewed together in a collaborative workshop. 

With the completion of modeling happy and exception paths and capturing the SIPOC and RACI details, you will have a strong current state baseline representing your As-Is process. You can then add additional details, as relevant, to each of the process activities to capture other attributes, such as Cost, Cycle Time, and Systems. 

In this article we introduced some guidance and best practices to document and model the current state As-Is processes, capturing happy and exception path scenarios, as well as SIPOC and RACI details needed to establish a baseline to transform and improve upon. In our next posting, we’ll discuss how to get started with identifying, understanding and quantifying pain points and problems in your process.