ABSTRACT

Author:	Eugeny Brychkov, Ph.D. in Computer Science
		HP Services, EMEA Wintel Storage Competency Center Engineer
		Moscow, Russia

Title: Qualification Checklists methodology development: problem resolution time and cost reduction and customer satisfaction improvement

Summary:
Developed methodology allows to create product/solution oriented qualification checklists, raise customer satisfaction and loyalty, improve Response Center Engineers' problem resolution effectiveness, strengthen HP entities cooperation and optimize problem resolution costs

I. Problem description / Target setting

Situation:
1.	In most cases RC (response center) qualification (or pre-qualification) errors occur because of the following factors: lack of engineering training; lack of concentration by the engineer on the problem; complex problem; unclear technical qualification process workflow; information on the product/solution can't be found in acceptable timeframe (on the web, in manuals etc).
2.	There were complaints from divisions that local RC or field engineers do not provide informative failure reports, and so the division is not able to find defect in returned "defective" part and can not detect global (class) issues with its products in time. This usually causes defective NTF (No Trouble Found) parts sent back to the field and they return to the division shortly again with "defective" status. This is not cost- and time- effective and need to be improved.

Target setting:
Methodology should be developed which will address issues mentioned above, optimize local RC workflow and help divisions to get valuable information from RCs in time. It should:

1.	Supply support personnel with easily located and accessed checklists to help collect information from customer site on specific product(s);
2.	Generate readable (by human and machine) uniform output text to be able to place it to call tracking system;
3.	Supply divisions with feedback on product and solution;
4.	Offer simple 'quick' troubleshooting workflow, provide direct links to another troubleshooting tools and documents.

II. Solution methodology development

2.1. Methodology development

As qualification process is complex task and it depends on the product, there should be individual workflow documents for each supported product. Let's name this workflow document as "Qualification Checklist". All these Checklists should be based on the following principles:

(1)	Single point of knowledge: all information or information sources references RC engineer may need is included within the Checklist;
(2)	Online help: Checklist should provide help on all its components to keep RCE clear about their meanings and what he/she should do;
(3)	Interactive: Checklist should detect possible qualification mistakes or possible workflow directions and notify RCE about them;
(4)	Easiness of usage: allowing RC engineer navigating quickly through the Checklist’s contents, choosing desired customer polling and problem troubleshooting sequence. It will be much easier for engineer working on one Checklist represented in one source than jumping many pages and links looking for necessary information;
(5)	Global management: one (or a few known) source(s) for all Checklists. It will allow changes to be implemented almost immediately w/o forcing clients to download and upgrade application on each PC;
(6)	RCE Feedback gathering: provides information to pass to right contacts in the divisions on product/qualification issues;
(7)	Cross-platform functionality: to be able to use checklists on PCs with different OSes and hardware configurations;
(8)	Report-capable: at the end of qualification generates comprehensive output text, which can be inserted into call tracking application for future reference;
(9)	Uses progressive technology: for easiness of implementation and long life cycle;
(10)	Wide application: ability to implement Checklist for wide range of supported products.

2.2. Existing systems overview

Consider some existing tools:

•	Text Formatter: it is available as a windows-OS-based executable, which runs locally on the RCE's PC. Although it's well made and very useful, it does not comply with items (1), (5)-(7), and (9). New version 2 of Text Formatter (TF2) is expected as web-based tool. TF2 is designed for 95% use by Nearline (former DIT) Storage Teams. This supposes limited implementation and limited supported number of products so TF2 does not comply with item (10). It does not comply with item (4) offering fixed workflow process and not showing necessary information in one document;
•	Web-based troubleshooting trees: these trees are designed to help RCE to make decision and understand where the root cause of issue can be found. They only comply with items (3), (5), (7), (9) and (10). These trees are very useful when information about customer/product/issue is already gathered, so troubleshooting trees can be used to troubleshoot issue just after filling Checklist;
•	There was a new feature implemented recently in Workflow Manager (Clarify) called "Issue Path". It complies with items (3), (5) and (6). But as soon as Clarify is call tracking system it is not product-specific and do not offer technical qualification workflow process. In addition, it can only be run on windows-OS-based PCs.

2.3. Economic consequences

Implementation of this methodology will:

•	Improve qualification quality and raise customer satisfaction;
•	Improve remote resolution rate;
•	Reduce costs of defective parts ping-ponging between division and field;
•	Shorten time/allow divisions to receive valuable information on their products;
•	Shorten qualification time;
•	Decrease RCE to customer calls for more data;

2.4. Conclusion

There should be new application(s) developed which comply with all items mentioned in 2.1.

III. Application / Process development

3.1. Application development

Let's group items in 2.1 and identify which technology to use and how Checklists should look like.

Group 1: technology to use: items (5)-(7) and (9) point us to web-technology. Indeed, if we implement Checklists as web pages then (5): they will reside in a few known number of web-servers; (6): RCE feedback will be logged to centralized database and sent to contacts in divisions via e-mail; (7): there are web-browsers developed for almost all operating systems; (9): web-technology is quite new, fast-developing information technology.

Group 2: Checklists' appearance/functionality: items (1)-(4), (8) and (10). Single point of knowledge (1) can be achieved by inserting links to HTML document which allows to view technical documents, download files on the desired topic; (4) means that Checklist should be one complete document with direct links to additional information; (2), (3) and (8) can be achieved by inserting forms and Java-scripts (or applets) to HTML source code; (10) supposes to create Checklists using uniform document layout with embedded product-oriented items.

3.2. Technical qualification workflow / Process development

1.	Call received by CCC, case opened and placed to appropriate queue for technical qualification;
2.	HP RCE makes first call to the customer;
3.	Using the Checklist he/she gathers all information about customer, his situation and affected HP product(s), filling the Checklist in. Although the Checklist provides all possible questions customer can be asked it's up to the Engineer to decide which questions to ask;
4.	Just after all answers received on questions the Engineer decided to ask, he/she follows Checklist's basic tips and tricks, and asks the customer to try some immediate actions and checks what customer have already tried;
5.	The Engineer ends call;
6.	Using Checklist's built-in report function, the Engineer generates a report and saves it to call tracking system;
7.	Following direct links in "Troubleshooting" Section of the Checklist, the Engineer troubleshoots the problem. He/she adds comments to Checklist's "Comments" fields, and saves Checklist's contents to WW database;
8.	Problem fix research/implementation:
•	if it was decided to replace part(s), CE is dispatched;
•	if the problem can be resolved remotely, the Engineer makes one more call to the customer;
•	if there are not enough resources, data or knowledge, raise support priority (transfer to CC, WTEC, etc), involve management (if needed) and pass Checklist's contents (or its reference designator) to all people involved;
•	if needed Kepner-Tregoe Technical Advanced Troubleshooting (KT-ATS form) is used;
9.	After root cause was found / system fixed (or customer refuses support) the Engineer fills Checklist’s division feedback form and sends it to the division.

3.3. Conclusion

Checklists' implementation will be individual for each supported product HTML page(s) with Java-scripts (or applets) embedded objects, residing in finite known number of servers and accessing one global qualification database and notifying division contacts if needed.
Checklists will contain all possible questions Engineer can ask customer on his situation, product, system configuration and provide Engineer with actions he/she can ask customer to do immediately (tips and tricks).
To improve troubleshooting efficiency Kepner-Tregoe Technical Advanced Troubleshooting form will be created using same principles mentioned in (2.1).

IV. Results

The project was started on November 2001. Checklist prototypes were implemented on Greeley Optical Libraries (dated February 15, 2002), Greeley Galactica products (dated March 1, 2002) and NSAS Virtual Array products (dated March 14, 2002) and can be found at http://******.hp.com. In addition there are VA Examples page and Kepner-Tregoe Technical Advanced Troubleshooting form (it's permitted to HP internal use by Kepner-Tregoe Inc.) available (dated February 15, 2002).

4.1. Business application

Methodology and results were not applied into HP business.

4.2. Next steps

Next steps will be to work on product-orienting Checklists contents.