Problem Analysis and Process Enablement
(Steps One & Six of the Cavi Method)
As we discussed in earlier posts, deriving the value chain from the observed workflow is the secret to process improvement mastery. Once the value chain is understood, process improvement is simply about aligning the physical work more closely with the ideal process design, which aligns as closely as possible with the value chain. (If you need a refresher on our definitions of value and the value chain, read those blog posts before continuing.)
The Cavi Method: Universal Process Improvement Flow
In this post, we will focus on two steps of the Cavi Method: Step One (analyzing the problem, or Problem Analysis) and Step Six (configuring the to-be workflow, also known as Process Enablement). Why are we going out of order? Because these steps are interrelated. Much of your ability to enable new process starts with analyzing the original problem correctly.
Step One: Problem Analysis
At Cavi, we hold a controversial business view: Not all problems should be solved.
Everyone has problems. However, only those problems which are rooted in the value chain should be solved. Formal problem analysis enables us to validate whether a problem legitimately impacts the value chain and, therefore, should be addressed at all.
The world “problem” itself can be broad and subjective. There are three layers to problems: symptoms, context, and root causes. These associate exactly with the CPIF because they are built on similar tactile and conceptual dimensions.
Symptoms are the manifestations of the problem which you experience in the physical world, whereas context defines the measurable thresholds and conditions in which the symptom exists that could qualify it as a negative issue. Context is theoretical (based on a process’s design and intent), and is subjective. Managers often set contextual measures that are arbitrary, or intuited without value-based qualification. For example, a manager could say that any customer complaint is unacceptable, when in reality, improving quality to reduce defects to “0” may not be financially feasible for that industry. A root cause represents the rationale that associates the established context to negative value creation – it validates the subjectivity established by the problem context against the objectivity of the market demand, i.e. does the context criteria that describes something as bad accurately reflect something in opposition to what the market has defined as value?
Let’s take the airline industry as an example. At an airline company, a single error may not be a problem. However, if the process context says a single error could cause a crash, that could be a huge problem. We know this intuitively. Intuition aside, though, how can we objectively conclude this is a negative event?
In this case, the symptom would be the error itself and the context would be measurable thresholds that make the error require attention (e.g. one error of this kind is unacceptable in this industry where the threshold for this type of error is 0). To conclude that an event is negative, you must validate whether the established context correctly correlates to “negative value” creation. Within the airline industry, any step that causes a plane to crash creates negative value in the context of a value chain that exists to fly passengers safely from one location to another. With this logic, you can clearly explain why the context: certain errors cannot be above 1, relates to negative value creation: error values above 0 cause a known, % chance of plane crashes, which creates an unacceptable magnitude of negative value based on the objective characteristics of this market and value chain demanded.
Problem analysis is about understanding the three problem layers and validating that the problem has a root cause impacting the value chain. Consider a simple example where someone says internal bill approval is taking too long. The symptom is people complaining about approvals taking too long, and the context is that you have measured time and volume expectations for bill approval that are not being met. However, when you look at the value chain, you may have trouble articulating negative value creation, because there is actually no value creation associated with this step. Approving bills faster actually provides no more value than approving bills at any speed, because from the customer’s perspective, all internal bill approval is waste (they wouldn’t pay for you to approve your own bills). This is a typical example, and the better solution is usually to redesign the process to appropriately remove bill approval steps entirely, not attempting to fix any problems associated with it.
If we can validate that a root cause exists, and value creation is being impacted, we can proceed with process improvement. There will be many instances where the stated business problem will not be a problem within context, and further, will not impact value creation. When those types of problems surface, they become distracting. Solving them will cost resources but ultimately yields no impact on value creation. The key is to discuss problems until you can formally document each layer. If at any point you can’t do it (typically because there is no measurable context or association with value creation) there is no need to go any further. You can think of this as a more focused iteration of SixSigma’s “5 Why” model in the sense that it is a “2 Why” model that focuses on clear criteria at each why. The following visual summarizes this logic:
Confirming a value-impacting root cause to validate a problem is the objective of problem analysis, because it serves two purposes. The first we just covered: it provides the insight to avoid work that doesn’t need to be done. The second purpose is that a problem with a root cause in the value chain will supply the attention and energy to itself required to successfully complete process enablement.
Step Six: Process Enablement
Process Enablement means to physically configure a process by altering the behavior of the technical and human resources in the workflow environment, so that the process they are executing matches the process design as closely as possible (remember, process workflow enables process design). Compared to making a new process design on paper, enablement takes a large amount of energy and is where most process improvement fails.
Process enablement follows the same mechanics of chemical reactions, in that processes are always trying to get to a more efficient, lower energy state, but they require surges of energy to get from one state to another. The higher energy state as-is process is your target operating process which has a problem, and the lower energy to-be state is your operation with improved processes. The energy needed to go through the transition will momentarily put the operation into a higher-energy transition state, with the activation energy to do so coming from your project. You can visualize this concept in the following way:
Relationship between Step One and Step Six
Why is it so important to discuss these two steps together? If the goal is to enable new process, a “good” problem to address is one that, without being resolved, will continue to cause consumers of the affected value chain to put pressure on people to fix it. For example, the problem could be causing unacceptable costs to be passed down to customers, or causing quality issues enough to reduce demand. Ultimately, whatever the problem is should boil down to an ongoing, measurable impact or risk to profitability that has become tangible enough to be on somebody’s agenda.
Without a root cause in the value chain, most problems will eventually lose attention or pressure over time and the sponsorship to allocate resources to it will disappear. In this case, you will be left without the activation energy you need to get through the transition, and the project will fail. This is why problem analysis is the first step of the Cavi Method, and everything we do in process improvement revolves around the root-cause problem (which supplies the energy to keep the work moving forward).
If you think of a problem as an oil vein that powers the project, structuring the rig (sponsorship, project charter, etc) directly on top of it is the only way to set yourself up for success. If you can’t find a clear root cause impacting the value chain during problem analysis, reconsider proceeding.
A process improvement project’s success through Process Enablement is largely dependent on the initial Problem Analysis and validation of a root cause. Being able to listen, analyze, and structure problems is the first step to properly identify which value chain needs to be formally derived as the next step. Doing so correctly also ensures that the project will have enough energy and resources to transition through the various stages needed to enable new processes. The Cavi Method allows you to derive the target value chain by first capturing the As-Is Workflow and then visualizing the To-Be Process.
This will be covered in our next post, which addresses process capture and process visualization.
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!