- About Us
QSI is pleased to offer a limited time promotion for small to medium field service organizations: now you can have all the software you need to develop and deploy the TEAMS Guided Troubleshooting solution for up to 50 named users for $99K. Additional named users are $2K/user/year.
With this plain and simple pricing, you no longer have to worry about how many servers and laptop/smartphone/tablet licenses you need — TEAMS-RDS, TEAMATE and TEAMS-PackNGo are all included. You also do not need to buy TEAMS-Designer separately for knowledge capture or serviceability analysis. Simply put, you will have licenses to all our software to develop and deploy guided troubleshooting solutions and improve serviceability of your products. And, it is not a teaser offer – just renew in time, and price is locked-in for up to 5 years!
Are you the service innovator who is ready to elevate the performance of every service agent to that of an expert? Let us provide you with the software and work with you all the way to fully leverage the TEAMS technology so that all of your service objectives are exceeded within time and within budget. With this technology, Quality of Service will no longer vary widely based on the expertise of the technician performing the job. You will be in control! You will achieve a consistently high Quality of Service (QoS) at a lower Cost of Service (CoS)!
For additional information, please contact QSI by filling out this form or by calling +1.866.934.8187 . This is a limited time fixed price offer, and no further discounts or alteration of bundles will be allowed. Orders must be received by December 20, 2019 to avail of this special promotional price.
The minimum system requirements are as follows:
|Operating System||Microsoft Windows 8 and later|
|Processor||2 GHz or faster processor with multiple cores|
|Physical Memory||4 GB|
|Disk Space||10 GB plus storage for models|
|Display||1280 x 800|
*Note: Additional memory may be required for working with larger models.
**Note: ODBC drivers are required to connected to a TEAMS-RDS database.
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!
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.
While the system experts may be good at solving problems, they are not necessarily the best choice to model. They tend to model solutions (to specific problems or symptoms) and not the problem space (i.e., what fails, how you detect failures and their relationships). Someone who is knowledgeable with how the system works is usually a better candidate to model. We can supply you with a good job description if needed.
QSI TEAMS is a model based approach, as opposed to experience, 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).
To understand how TEAMS works, think of your GPS navigation system. It is great for visiting places you never been before! And it is also great at finding the optimal route for that day, given the road and traffic conditions. The GPS and TEAMS solution share two important attributes: it applies algorithms or logic to solve new problems (instead of trying to utilize past experience or solutions), and it recognizes yesterday’s solution might not be the best solution today.
Taking the analogy further, think of the GPS software as the TEAMS reasoner, and the maps are the cause-effect relationships – i.e., which faults trigger with error code or test failure – in your system. The TEAMS reasoner applies logic and optimization algorithms to rule-in and rule-out possible causes and guides the technician through additional information gathering, until it determines the root cause. It then guides the service agent through the corrective action and the verification steps, all the while logging each of the steps automatically, and learning from it. Just like the GPS can route you through various options (e.g., avoid toll roads or ferries), the TEAMS reasoner can guide service agents with different levels of skills, certifications, support equipment — generating a different troubleshooting path based in his or her ability.
Simply put, it is the kind of technology that helps a 19 year old kid fix a F16!
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.
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, but trying to document all such combinations is nearly impossible due to its combinatoric complexity. Likewise, the absence of an error code can be used to de-emphasize or eliminate many suspects, but most service software only captures the failed error codes. The power in TEAMS comes from using machine reasoning to use all available information (both passing and failing test results or error codes) to isolate the cause. The reasoner uses all this information to determine which components are good, bad or suspect.
Tests can only detect failures, and can declare something as good only by elimination — i.e., when it did not find anything bad. Therefore, by definition, the PASS outcome cannot declare something GOOD that the FAIL outcome cannot declare as BAD
Before 11.6, we did not enforce this constraint, and that got modelers into trouble. For example, before you could model a TEST T as follows:
PASS outcome detection A and B, and
FAIL outcome detecting ONLY A
Well, not only is this contrary to the basic definition of a test — it also leads to some very illogical outcomes — B will be eliminated from the list of SUSPECTS, no matter what the outcome of the TEST T! Here is why — if Test T PASSes, you would declare A and B as GOOD, that is fine! However, if test T FAILS, then also you would declare B as GOOD (under single fault assumption) since A is faulty, and therefore B cannot be faulty! So, you do not have to see the outcome of TEST T, you can eliminate B!! So, why bother running TEST T, just eliminate B:-)
This promo emphasizes Guided Troubleshooting, and is therefore aimed at field service organizations. Please contact QSI (email@example.com) to discuss your specific needs.