- About Us
Diagnosis is the process of determining the system health from observed effects. Typically, over 50% of the cases, the corrective action can be diagnosed unambiguously by reasoning on the presence and absence of error codes. For those cases, troubleshooting can be completely eliminated. For the rest, the diagnosis from observed effects reduces the list of suspects to a small set, and the reasoner can generate an optimized sequence of (troubleshooting) steps to identify the corrective action.
This is contrast to the traditional troubleshooting practice, which relies on past case history to identify a list of possible corrective actions that the service agent should try until problem appears to be fixed.
With TEAMS, even an inexperienced service agent can find and fix problems as good as an expert!
Most service organizations do not make optimal use of available information to diagnose the problem. For example, presence of multiple error codes can actually help narrow down the set of possible suspects, and the absence of an error code can be used to downplay or eliminate many suspects. The power in TEAMS comes when you use all available information (both passing and failing test results or error codes) to isolate the cause. The reasoned uses all this information to determine which components are good, bad or suspect.
Guided troubleshooting is an optimized set of steps dynamically generated by the reasoner that the Service Agent follows to identify, correct and resolve a reported problem. This can begin by querying the operator of the system and continue with the field service agent. By querying the operator you minimize the task of the field service agent by quickly narrowing in on the problem, thus reducing his troubleshooting time and parts dispatched.
A malfunction in a systems (the cause) will generate one or more manifestations (the effects). The reasoner is an algorithm that uses the many-to-many relationship between causes and effects (as captured in a TEAMS model) to identify the root cause(s) that best fits the observed effects. If the observed effects are not sufficient to pinpoint the root cause, the reasoner can identify the troubleshooting steps required to gather additional information and identify the root cause. This process of identifying what’s wrong in the system is very similar to what your smartest experts will use to troubleshoot complex problems.
A TEAMS model captures the many-to-many mapping between causes (things that fail, i.e., faults) and effects (things that detect failures, i.e., tests and symptoms). If you know these relationships, you can import them in as a spreadsheet. Otherwise, you lay out the system and its interconnections, and TEAMS will propagate the faults along those paths to generate the mapping.
QSI TEAMS is a model based approach, as opposed to knowledge, history or case based (all of which require accurate legacy data). QSI TEAMS does not require legacy data. It can produce accurate results immediately. It excels when an error or symptom has many causes or faults manifest into many symptoms. It can be deployed at the machine level, the call center, the field or automatically from machine to machine (M2M).