Open Orbit Diagnostic Methodology
- 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
Metric Type :
Wait Time :
|Queue wait time, Lead time|
Touch Time :
|Transaction touch time, call handle time|
|Cost per operator per hour|
|%First Time Right|
|Scheduled capacity, Present capacity|
|Calls per hour, Transactions per day|
|Conversion, Ticket size|
Open Orbit Concept Overview
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
Data Collection Plan
Performance Gap Analysis
Benefits Tracking Report
Date Tracking (Within Project)
Value Stream Mapping
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.