Open Orbit Diagnostic Methodology

Data Model

The Open Orbit diagnostic data model is based on a patent-pending approach that encourages a sharp and crisp diagnostic. The data model has over 60 entities and a set of sophisticated relationships between them, but for the purpose of understanding the diagnostic method, a few core entities are explained here.
 Diagnostic Methodology Data Model
 Diagnostic Methodology Data Model
 Diagnostic Methodology Data Model
 Diagnostic Methodology Data Model
 Diagnostic Methodology Data Model
 Diagnostic Methodology Data Model
  • A Project has ideally one but possibly more than one core objective which defines success, e.g. reducing cost or improving customer experience
  • It can be tagged with industry vertical(s) and process horizontal(s) to enable knowledge content matching and searching
  • It uses Permissions to control data confidentiality and visibility across multiple users
  • It goes through Stages starting with Scoping and finishing with Benefits Tracking, and has defined Start and End dates
Think VSM Not Process Flow DiagramDo note the absence of decision boxes, swim lanes and other such elements often found in process maps. This is deliberate, and meant to encourage a model of the process that is more like a Value Stream Map – a set of stations through which the transaction moves, with only one “right” way and all other outcomes being a “defect”.
Transaction Types signify the type of work being performed at the Step. They should be used to represent various kinds of transactions within an overall category. If unrelated work types happen to go through the same Step (for example at a Triage) then this is better modelled as separate processes rather than just Transaction Types.
Metrics are categorised into 7 Metric Types, which are meant to be mutually exclusive and collectively exhaustive groups with two key characteristics – units of measure for a given metric type are very similar if not the same, and it may occasionally make sense to make relative comparisons within them but never across them. The Types and example metrics within each Type are given below:
Metric Type :
Wait Time :
Queue wait time, Lead time
Touch Time :
Transaction touch time, call handle time
Cost :
Cost per operator per hour
Accuracy :
%First Time Right
Capacity :
Scheduled capacity, Present capacity
Volume :
Calls per hour, Transactions per day
Revenue :
Conversion, Ticket size

Open Orbit Concept Overview

Diagnostic chain and “Mentored Thinking” – The workbench is powered by an algorithm which makes recommendations on where to focus effort when it comes to measurement, causes and solutions.
Diagnostic chain and Mentored Thinking


Guidance and suggestions from the Mentored Thinking algorithm

"Read more" links from the Workbench to the Wiki

Links within the Wiki pages (also based on the same algorithms)

A chain of recommendations guides the diagnostic process as follows: (*)
– Given a Process and an Objective, it recommends Metrics
– Given a Metric, it highlights possible Causes
– Given a Cause, it suggests potential Solutions

The suggestions for the multiple Metrics Types, and the software decodes the non-MECE (mutually exclusive and collective exhaustive ) list of options for the project objective, into the MECE-set of Metric Types. This is one of the fundamental building blocks of the successful projects and OO’s ability to guide the user to success – knowing which metrics are relevant in which circumstances. OO encourages the use of this list to ensure the optimum level of divergent thinking (looking where experience says one may find the root cause; as well as not wasting time on areas that experience says are not insightful) during the building of the data collection plan, followed by relatively convergent thinking later when it comes to Causes and Solutions.

This chain is the core of the diagnostic method, and is accessible in the workbench (with “suggested” metrics, causes and solutions) as well as via the “read more” links from the workbench to the wiki pages. On the workbench, one can traverse from metric to cause to solution, and at each stage look up the relevant wiki page. On the wiki site, one can traverse in either direction between all three.

The business process may have a gap in performance (a symptom) for a given metric, with the baseline being different from the target. Each such gap in a metric may be explained by one or more root causes, each of which in turn may have one or more potential solutions. The solutions finally get tracked by a metric, very often the same as the metric which helped expose the symptom in the first place. But on occasion, a different metric may also need to be tracked for the solution to be sustained. Thus, metrics, causes and solutions work in a circular chain of interdependence.

(*) There is another step prior to processes and objectives which has its own “suggestions” feature highlighting key processes for a given industry – to be used only if need be. However most projects already have processes identified.

Analysis Aids and Status Reports

Open Orbit provides a set of reports which are useful to analyse the implications of data entered, and decide on next steps. They also double up as a useful way of reporting progress. This is a fundamental shift in the approach to status reporting – away from being based on input or effort expended, and towards being based on outcomes and insights generated.
Data Collection Plan
Based on entries in the data values screen, this report pulls together all the processes, steps and data values in any given project into one spreadsheet-like structure allowing for rapid data entry, visual comparison of gaps, and hence prioritisation. One cannot create new rows in this spreadsheet, since that should be done on the main workbench with all it’s guidance features. However, targets and actuals (before the project, as a baseline) are entered in this module.
Performance Gap Analysis
Based on the same data as above, this is a combination graph and spreadsheet which pulls together all entries for a given “metric type”, say Touch Time. This is a better way to visually analyse, and where required annotate / comment on where the biggest gaps are. For example, with this report, one can easily answer questions like “where is the biggest bottleneck on Wait Time?” or “where is the biggest source of defects?”. It is recommended that this be used to inform status reporting during the Data Collection phase.
Benefits Tracking Report
This report is similar to the data collection plan in its structure, but instead of expecting data entry of “before” and “target” numbers, it allows for tracking of “after” data. This helps complete the picture of the project and its impact on key metrics, by bring together the before, the target and the after picture. It is recommended that this be used to inform status reporting during the Benefits Tracking phase.
Solution Roadmap
This report gives an overview of all the relevant metrics, causes and solutions selected for the particular project. The user can prioritize the solution and plan ahead. One can revisit this report to track the solution stage and its status, It is recommended to use this report during the Solution Hypothesis as well as Prioritisation and Benefits Case phases.
Date Tracking (Within Project)
The Date Tracking report helps users track start and end dates by each stage of their project. It can be useful for self reporting and tracking compliance to schedule.
Historical Performance
This report can be used to to track and record process metric performance of past 12 cycles. This would benefit in reviewing trends of a given metric. This report acts a repository of project data summary at one glance. One can download this data into spreadsheets to review past trends visually.
Value Stream Mapping
A graphical representation of the process steps and connections, to identify where the waste and cause of the problem is. The report pulls together the key issues, their causes and data points for the entire process. It enables you to identify where & why a process isn’t working and where to focus your solution effort.
This visual helps you to validate if all causes are covered under the five factors.
Solution Checklist

Use the recently introduced ‘Solution Checklist’ feature on Open Orbit to give you an insight on how a problem or solution has been managed and rated by another user in your team. It is recommended to feed in Actions taken and rate each action as well to make a repository for a future user to use it as a reference for upcoming projects.

Let us show you how Open Orbit can really crank up every dimension of your transformation project.

Pin It on Pinterest

Share This