Open Orbit Lean Six Sigma Forum

We need to understand the logical flow of the process to get a clear view of the steps and process as a whole. We should describe the process using a structure called the happy path of hand offs. A Happy path is a set of steps performed on a transaction when everything goes right. A step is the largest possible set of activities before a hand-off is required to another person or team.

Add a new Process. Name the process as per your requirement.

A new line item gets added.

Best Practice Tip:

• Process names should be brief and yet easy to understand for your colleagues. Use acronyms and jargon only if widely prevalent in your organisation. A longer description can always be added in the Description field. In some cases, your organisation may have issued guidelines on nomenclature, and if so we highly recommend you follow them. Everyone following those simple rules can make a significant impact on how easily people can find knowledge and lessons embedded in each other’s work. .

Click on the Diagnostic Map button to start adding the process steps:

You will get redirected to a blank Diagnostic Map page. Click on the ‘+’ sign to add a step. Click on the ‘>’ to show / hide the left panel

Use the edit icon on the top left of the step to add comments or to modify the step entered.

The delete link allows you to delete that particular step. The left and right arrows can be used to shift steps around.

Best Practice Tip:

• Step names should be brief and yet easy to understand for your colleagues. Use acronyms and jargon only if widely prevalent in your organisation. A longer description can always be added in the Comment field. In some cases, your organisation may have issued guidelines on nomenclature, and if so we highly recommend you follow them. Everyone following those simple rules can make a significant impact on how easily people can find knowledge and lessons embedded in each other’s work. .
• A step is defined as the largest set of activities that does not involve a hand-off (say from one person to the next). A hand off suggests you should separate the subsequent activities into another step.
• Aim to have between 5 and 8 steps. This is not a hard and fast rule, but less than 4 may point to a problem that is too simplistically framed, and needs some extension of scope (either upstream or downstream or both) to provide actionable insights. A common mistake is to miss analysing an upstream step of triage, queue allocation or a quick “pre-validation” even before work begins. Specifying that as an explicit step can help weed out subsequent wasteful activity.
• Similarly more than 8 can become very complex to analyse and to articulate to your stakeholders, and you should consider breaking it down into multiple processes. .
• Some times, you may want to split a step into two, even without a hand off. This can be useful if the systems used in the remaining activities is different, or if the dependencies and data requirements are different. Especially if you have too few steps, then it is quite alright to split them up and make the analysis more granular.
• The steps when put together should form a “Happy Path”. This means they represent what happens when everything goes right with a particular transaction. All other paths and diversions should be modelled as exceptions or defects from the Happy Path.
• Your process may contain a branch or a fork, resulting in parallel steps. If the branch or branches converge back into a common step at a later stage, you have three options: either model that entire group of branches as one step in an end to end process, and then model each branch as a Happy Path process in itself separately; or pick the most commonly occurring branch as the happy path and model the rest as exceptions; or pick the most preferred branch as the happy path and model the rest as exceptions.
• If the branches never converge back, you again have three options – pick the most commonly occurring branch as the main branch; or pick the most preferred branch as the main branch; or it if is really very difficult to make this choice then you may well have a case of fundamentally different processes, where the first few preparatory steps happen to be common. Consider splitting up into separate processes, even if the first few steps are repeated across multiple processes.
• A step can be classified as “Value Adding” or not, or partially so. Value should ideally be defined from the end customer’s perspective, as in “would they be concerned about why you are doing this and how well you are doing it”. At times, it is quite ok to consider an “internal customer” if the process is totally inside the enterprise and a strict application of the rule of value to an external customer results in everything becoming non-value-adding. Read about Lean
• At times, it may be useful to split a “partially value adding” step into separate value-adding and wasteful steps, especially if the two aspects are not totally comingled AND you don’t already have too many steps.

Reviewer's Tip: This is the most important section of project on Open Orbit, so it is critical that users understand how to model it. It would be a good idea to spend some time with a new user to they understand the concept of happy path. Users also tend to get lost in trying to replicate the complex visio structure. The idea is to keep the happy path simple and diagnose the process in simple large chunks rather than complex visio steps, where the crux of the problems tends to get lost .

Once all steps are created, the next stage is to make “connections” from these steps to the metrics, causes and solutions shortlisted earlier with the help of the algorithm.It also important to connect the Attributes to each step along with the Metric , Cause and Solutions. This dataset determines the owner , software application used , exposure to a possible adversity in the step and the possibility a failure in the otherwise ideal scenario. It helps complete the diagnostic map amongst the other connections we are going to make.

This will enable the creation of the diagnostic map, as well as the Fishbone diagram. Also, we will be able to gather a visual representation of the bottlenecks and root causes at each step.

Let us connect the corresponding metrics, causes and solutions to the relevant step by a simple drag and drop method. Click on the Diagnostic Map button and expand the Metric-Cause-Solution to show the list selected earlier in the Diagnostics section.

Click on the highlighted area to expand and collapse the list.

Simply drag and drop from this list to the main panel to build connections with steps or to the panel below the main section to create connections with the whole process.

These connections can be edited to capture additional data like priorities, actual & target values and whether the causes are controllable or not. Click on the edit box in the tile highlighted below to add more data against the selected Metric / Cause or Solution.

Now this diagnostic map provides a complete picture of the process steps, and metrics, causes and solutions of interest, in just one snapshot.

Best Practice Tip:

• Each step should typically have at least one metric, or at the very least be covered by the fact that you have connected a metric to the whole process. Each step need not always have a cause and a solution, but if it does have a cause, and it is rated as High Priority, then it should have a solution too! .
• Sometimes the same step will have a large proportion of the metrics, causes and solutions all crowded into it. While this is not an indicator of something being wrong, you may want to consider if that step deserves to be analysed separately as its own Happy Path and be drilled down to the next level. .
• Metrics, causes and solutions that are measured, validated and implemented at the entire process level should be connected to the entire process, and not repeated at each step. For example, customer satisfaction, end to end workflow implementation etc. .
• However, metrics that are measured at step level, even if relevant to each step, should be connected separately to each step, for example Accuracy or Touch Time. Similarly causes that may well occur at each step, but need to be managed separately for each step, should be connected separately to each step. For example, Capacity. The same goes for Solutions. .
• Most metric connections should be categorised as “input metric” which is the default setting. Some very selected metric connections, which are representative of the overall objective of the project, should be set to be an Output Metric. For example, in a Timeliness project, the end to end Cycle Time, or % On Time, can be an Output Metric, and everything else is an Input Metric. .
• Causes should be categorised as Controllable or Not, considering the scope of the project. Just because the step is outside your immediate team does not make it not controllable, and vice versa. For example, input quality from the upstream party that provides you information, can be influenced and should be considered as controllable. But the pressure of market forces, say through impractical expectations of customers because of competition, may well be considered as non-controllable. .
• Solutions should start life as Hypothesis, and then be taken through the life cycle of being validated, prioritised etc. as the project progresses..
• All connections should ideally be rated on their priority. This is a subjective rating, informed by the analysis you are performing. For example, a large deviation from target would suggest a higher rating for a metric. Significant impact from a cause would suggest a higher rating. And the same goes for solutions. .
• Use the comments fields in each of the connections (Metrics, Causes and Solutions) to tell the story behind that element. For metrics, document where you got the data from, who helped validate it etc. You can also add a URL to the file on your intranet shared drive where the source data is kept. This way, anyone with authority to access your project gets the full picture in one place minimising the need to seek clarifications. Use the Cause Comments to document evidence and who helped you validate it. Use Solution Comments to document who needs to or already has approved it. Avoid detailing the action plan for that solution in the Comments section, as this may duplicate what should ideally be covered in the Solution Actions section. .

Reviewer's Tip: It is critical that the reviewer verifies the logic of connections of Metrics / Causes and Solutions. For example metrics like Touch Time should ideally be measured at a step level, however overall out metric like Customer Satisfaction can be measured at a process level. This will completely depend on the project and the process being modelled. Same is applicable for the Causes and Solutions. Reviewer should also ensure that all connections have priorities selected, these can be changed at a stage if required and most importantly detailed comments are recorded for each connection. This is important as Causes and Solutions are deliberately high level and therefore critical that the project records their thinking on why the particular tile has been selected and connected.There should be a good balance between step-level and process-level connections. Connections and data against each of these connection will play an important role in the output artefacts like Fishbone / Performance Gap report etc..

• 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