(Steps Two & Three of the Cavi Method)
Problem Analysis (Step one of the Cavi Method) helps us to define a root cause for the problem we have identified, and subsequently to pinpoint which process scope is negatively impacting the value chain. At this point, a process consultant is equipped to derive the value chain of the scoped process by accurately capturing and visualizing the relevant process information. These are the next two steps in the Cavi Method: Process Capture and Process Visualization. This phase does not require much technical knowledge of process. It is an exercise in observation, documentation, and communication. Capture happens at the observable workflow layer where one can see and experience things, whereas visualization frames the captured physical process information at the process layer via documentation (typically process maps).
The primary objective of this phase is to build a visual to share with stakeholders. Each stakeholder may have a different interest in, and familiarity with, the business problem. It’s important that the process visual is transparent, accurate, and intuitive enough for all stakeholders to easily interpret.
Process Capture: Step Two of the Cavi Method
‘Capture’ in this context represents the strategies one would use to collect and formalize process information. It is important to note that ‘capture’ encompasses only what already exists. Process information is retrieved from various sources, distilled and then formalized for structured future use in communication regarding the project.
An essential yet tricky stage, capture becomes difficult when a significant portion of the workflow and underlying process is digital, rather than in a physical space that humans can easily experience. So, how does one properly capture workflow that cannot be seen? With the technique known as the “gemba walk”. From the Japanese word gemba, meaning ‘the real place’, the gemba walk is a concept from Lean that reminds us to always observe ‘the real place the value is created’ when studying process. The gemba walk encourages a process consultant to go down to the proverbial ‘factory floor’ and watch the workflow happening in real time. In other words, we must navigate to the point of value generation and capture the workflow from that vantage point directly.
In highly digitized services, performing the gemba walk often entails shadowing an employee, or watching the employee’s computer in cases where technology does the heavy lifting. One may question the need for this method if everything is digital; however, even the most digital processes are still driven by humans. It is at this human interaction level that observers understand how a workflow enables a process and creates value. This allows us to experience the process as a ‘story’ which can be communicated to others.
To understand the process storytelling model, a process consultant must first differentiate between the physical and non-physical aspects of the workflow layer. The physical elements are the human-driven, observable behavior whereas the non-physical elements are the automated, non-observable system behavior. To put this into practice, one must go back to the core of storytelling – The “5 W’s” method.
The “5 W’s” are the basic questions one must answer in order to research and write a good story. Derived from journalism, the “5 W’s” can be thought of as a standard interviewing or observation methodology, and will optimize time spent capturing process information during the gemba walk.
The 5 W’s are as follows:
- What happened?
- Who was involved?
- Where did it take place?
- When did it take place?
- Why did it happen?
From a process perspective, when observing the workflow layer, the following questions must be asked:
- What (action/step) happened (or is being observed)? The steps should all fall within the scope of the process being captured.
- Who (which role/resource) was involved? This is the person performing the actions that tie the process together.
- Note that if there are several automated steps which happen between human interaction, that should be noted as commentary rather than as a discrete step in the process.
- Where (which system, tool, or space) did it (the process action/step) take place?
- When (sequentially compared to other actions/steps) did it take place?
- Why did it (process step) happen? The ‘why’ context is required more so for later-stage analysis than visualization of the As-Is process. However, it is important to pen this detail in the beginning stage for later use.
Process Visualization: Step Three of the Cavi Method
Visualization can be defined as any technique for creating images, diagrams, or animations in order to communicate a message. Visual imagery has been used to communicate both abstract and concrete ideas since the dawn of humanity since the human brain processes images faster than any other form of information. Process consultants understand that visuals are often the most effective way to communicate the workings of a process; however, if the visual is more of a puzzle than a depiction, there is no value in creating it. This is where the Cavi Mapping Language (CML) comes in. Unlike many process mapping languages, which can become cumbersome and complex, the CML allows practitioners to visualize any process using just a few shapes and conventions. This enables greater ease of communication and consistency in outputs.
The Cavi Mapping Language (CML)
Once an existing process has been accurately captured in notes form, visualization simply entails structuring the notes from the “5 W’s” model and depicting them visually. This can be done in any graphic design tool
At Cavi, we refer to an accurately visualized process as a process map. In the Cavi Process Improvement Framework (CPIF) terminology, process maps are used to translate captured workflow observations into an accurate and representative process design. An example of how we can depict the “5 W’s” as a process map using the Cavi language is displayed in the following figure:
The logical organization of the “5 W’s” can be represented as a single picture, with limited conventions. In fact, in the Cavi language there are only three shapes, explained below:
The square represents a set of uninterrupted actions that collectively constitute a process “step”. Any action or combination of actions that complete a single step can be added in this shape. A process consultant can use the language of their choice, the only rules being:
(i) Lead with a verb to explain ‘what’ action is being performed for each respective action (if a set of actions).
(ii) Indicate the ‘where’ aspect of the information, i.e., the systems or tools used to accomplish the step indicated within the shape.
The diamond represents a decision that must be made from based on information in the previous step. Rules for the decision diamond include:
(i) Frame the content in this shape as a question.
(ii) List the criteria in different lines connected to the shape to clearly demonstrate the path to take depending on the answer to the posed question.
The oval represents a process ‘terminal’. This functions in a manner similar to the square, in the sense that it is a verb-led, uninterrupted step containing the ‘where.’ The major difference is that the oval defines the beginning or end of a process sequence (e.g. a directionally oriented series of steps). A page of a process map will typically contain only one start terminal, but if a decision diamond is used and results in two alternative process paths, the page would then contain two end terminals that represent the end of each of those two process paths.
With only three shapes in the CML, a process consultant can map any process, regardless of complexity. Other ‘compliant’ yet limited conventions include connectors (lines with arrows) that sequence and connect the shapes, a line call out for commentary, the swim lane (left-hand column) construct that represents the human roles (each step within a particular ‘lane’ is done by the role indicated in the swim lane), and a functional object that helps navigate between pages to enhance the reader’s ability to read a large map. (In case this seems a little confusing, we’ve created a template to help you get started with this approach to process mapping. Download the free template here.)
For complex processes, wherein all the information cannot fit in a single visual frame, layers of detail must be used so that each frame (page) of the map contains an entire process with a logical start and endpoint.
Once process maps are created that represent the ‘As-Is’ (current) process informed by captured workflow observations, a process consultant is ready to move to the next step and topic of our subsequent post: Analyzing the process for improvement and redesign.
Are you enjoying our blog? If so, please subscribe to our mailing list where you will get updates about free and/or beta knowledge products as they become available. Thank you for reading!