Open Orbit Lean Six Sigma Forum

After setting context we move to diagnosis. A process transformation problem on Open Orbit has three elements to it:

• Symptom-cause-remedy analysis
• Happy path of hand-offs
• Connections between the above two

We will now learn about each of these aspects, as well as how to perform the relevant steps in Open Orbit. We will start with the “symptom-cause-remedy” analysis. Lets start with symptoms or metrics:

We now have the foundation in place to begin our Symptom Cause Remedy analysis. A visit to the physician starts with a purpose to resolve an illness. You are experiencing symptoms, which need to be then assessed by the physician. In our case, the symptoms are the business metrics, and how close or far they are from target values.

The tool has a repository of metrics. Ask the tool for the relevant metrics for your hypothesis by clicking on “Ask OO”. This will show you a list of symptoms to check for. The list of metrics is arranged into groups in multiple layers. You can expand and collapse these lists as you browse through the suggestions. Use the “+” / “-“buttons to expand and collapse the structured set of question. These questions help you frame your thinking process and guide you through every possible option that might be relevant in the business problem that you are trying to solve. Use the “Add” button to select the metric and “info” button to read more about the topic:

Best Practice Tip:

• Aim to have between 5 and 10 metrics. This is not a hard and fast rule, but too few metrics may result in a very narrow scope of analysis, and too many can risk spreading your efforts too thinly. .
• The metrics are grouped into a 2 level hierarchy, and if you are selecting either, none or too many, from one category, that can also reduce the insightfulness of the analysis.
• Some of the metrics within one sub-category can be seen as aliases, synonyms or proxies of each other – for example % On Time and % Provisioned On Time. In such cases, pick the term that is more familiar to you and your stakeholders, and avoid picking both, since it will not add to the root cause analysis.
• Continuous metrics, where data is available, are more insightful than discrete metrics. For example, Provisioning Time is a richer source of insights than % Provisioned on Time. While SLAs are often managed by using the latter, root cause analysis is better informed by the former. If you measure it, use it.
• Each process has some commonly found vital signs, quite like the human body. They can tell you if it is worth digging further at all – if all 5 vital signs are “green” then there may not be a problem worth solving at all, and if there still is, then the targets behind the “green” assessment could be wrong!
• The vital signs are in two groups: those impacting the customer – Accuracy, Touch Time and Wait Time; and in addition those impacting the business – Volume and Capacity. The most commonly found holistic analysis will have as many as possible of these 5 vital signs represented. In fact, if you are struggling to narrow down from a vast array of challenges with the process, and feel like you can’t decide where to begin, a first round analysis of these 5 metrics for the end to end process is a good start.

Reviewer's Tip: While metrics can be added/deleted at a later stage, as a reviewer please consider that all relevant metrics are selected - check for aliases and ensure that the list is not too long and at the same time covers all important aspects of the project. It is wise to select the metrics that are currently not measured but should be measured potentially. This should be captured in the Solution Check list. Also redirect users to the “info” button to read more about the metrics. the Wiki page on these topics are handy and help practitioner to clear his thinking and understanding about the particular topic.

Now that we have selected the symptoms, the next step is to quickly learn about the possible causes and explore remedies or solutions. You can always come back to the list of metrics and make additions or deletions as you learn more about the process. Coming back to our medical analogy, it is now time for the doctor to investigate the possible causes of your symptoms.

Open Orbit shortlists some causes for you when you click the ‘Ask OO’ button. The tool can also help you to analyse causes more effectively by breaking them down into the following categories; Environment, Process, People, Measurement, Policies and Systems. You can expand and collapse these groups as you browse through the suggestions. Use the “+” / “-“buttons to expand and collapse. The lists can be sorted by either Cause type or Metric. Use the “Add” button to select the cause and “info” button to read more about the topic. Once selected, the cause will appear on the right hand side panel of the screen. You can also delete if need be from this list of Causes

Open Orbit’s algorithm uses a comprehensive database of root causes and it will make sure you haven’t missed anything. It will reduce the effort and time needed to identify causes thereby maximising your capacity to do more. These recommendations can help you come up with probing questions that you can ask during workshops and stakeholder meetings. You can also use your own judgement and knowledge of the specific business situation to filter the recommendations from the algorithm.

Best Practice Tip:

• Aim to have between 8 and 15 causes. This is not a hard and fast rule, but too few causes may result in a very narrow scope of analysis, and too many can risk spreading your efforts too thinly. .

Reviewer's Tip: While causes can be added/deleted at a later stage, as a reviewer please consider that all relevant type of causes are selected, usually people tend to get inclined towards people / system related causes, therefore it is important that the causes are selected keeping the broad spectrum in mind. A good idea is to conduct a brain storming session with the project team and Subject matter experts using the AsK OO list, which will help users ensure that they shine the torch in each corner of the room. In case you have a customised cause, particular to the project, please get the Super User of your account to add it to the “Private List”. Also another point to make note here is that the causes are a deliberate high level expression and thus it gives the user flexibility to set context and record the particular issue in the comments in the Diagnostic Map.

So far we shortlisted symptoms and then we selected possible causes. We are nearly at the end of our diagnostic cycle. It is now time for the physician to recommend treatment. A solution is initially set up as a hypothesis that must be validated before being taken up for implementation. Like Metrics and Causes, the list of Solutions in the project evolves during the life of the project. Also some of these solutions are high level phrases to act a placeholder to build an action plan at a later stage.

The tool will provide a list of remedies or solutions to solve for the problem at hand. The tool enables you to sort the solutions suggested based on the cause. It also categorises them by Environment, Process, People, Policies, Measurement and Systems. Just like we selected metrics and causes you can use “Ask OO” button to recommend possible solution against the selected causes. You can expand and collapse these groups as you browse through the suggestions. Use the “+” / “-“buttons to expand and collapse. The lists can be sorted by either Solution Type or Cause. Use the “Add” button to select the Solution and “info” button to read more about the topic. Once selected, the solution will appear on the right hand side panel of the screen

This full cycle of symptom, cause and remedy should be used continuously and iteratively throughout the project to provide probing questions for workshops and to capture insights as your understanding of the problem evolves.

Best Practice Tip:

• Aim to have between 5 and 10 solutions. This is not a hard and fast rule, but too few solutions may result in a very narrow scope of analysis, and too many can risk spreading your efforts too thinly. .

Reviewer's Tip: Solutions typically will be the reverse of the cause and you need to elaborate particular actions for the recommended solution in the “Solution Check List” in Open Orbit. In case you have a customised solution, particular to the project, please get the Super User of your account to add it to the “Private List”. Also a detailed “How to” step is available in the Wiki - Info button of the Solution section, so it is worth a read to get some tangible actions. .

remember the Metric-Cause-Solution diagnostic cycle is a working hypothesis and the user is expected to come back to this section multiple times during the project lifecycle. Typically diagnose the problem in the define/measure phase and as the project matures, do keep evolving the hypothesis..

In the first iteration, all of this is just a working hypothesis. You haven’t actually validated the shortlist with people who perform the process. That will be the next step. The purpose of this first iteration is to build a working hypothesis that significantly speeds up the diagnosis compared with starting with a blank sheet. It will be refined over multiple iterations. Also you can first start with drawing out your process and then come back to diagnosing the issue. See process model

• User Guide: Getting started
• Context Setting: Intro and framing the problem
• Diagnostics: Metrics/Cause and Solutions
• Process Model: Diagnostic Map
• Reports and Tracking: Gap Report/Fish Bone Project Tracking
• Presenting your project: Real time governance and Conclusion
• Using Open Orbit for RPA study: Diagnosing your process for RPA