Desirable Metrics to track

Keeping in mind the reason for doing this line of business study in the first place, the ultimate goal is to be able to maintain a small table of management metrics to document the work being done, and justify requests for more resources if needed.  These include but are not limited to:

• Number of repairs -- by Warranty and by Manufacturer 
• Revenue per Repair -- by Warranty and by Manufacturer
• Cost per Repair -- by Warranty and by Manufacturer
• Time per Repair -- create-to-close elapsed time is all right, as bench time could be too hard to capture.
• all of the above further broken down by Type of Repair (keyboard, display, drive, etc.)
    
   

Findings about financials and process in support of the metrics

Our attempts to trace what is going on in the Hardware Repair area of the service center have revealed some systemic gaps that undermine our ability to actually establish relevant metrics.  The main ones are here:

1. Reconciling RT tickets against SAP financial transactions needs a much better link between SAP and RT records.  SAP DTR transactions generally do not record the respective ticket number.  RT tickets generally do not record the amount of revenue expected to be billed.  The several different ways we can receive payment each create a different kind of documentation trail in SAP, and only two of which indicate the RT ticket.  

There is no field in RT that holds a numerical version of the amount to be billed to the customer or vendor.  The next step is sometimes used to list the line items contributing to the charged, but then the amount is erased as the billing is completed.

1. Staffing model is a muddle.  Payroll expenses in 1637500 are indeed only for Hardware Service, but an uncertain amount of Help Desk staff also contribute effort to tickets that end up in Hardware; that time is difficult to document.   An accurate cost model needs to take into account the sunk effort of everyone involved. 
2. Metadata fields in RT tickets are not used consistently enough.  These fields are the ones that power our reporting and metrics.  They are the only ones that tell us what kind of work is what within the system of record.  One or two additional fields are needed to give a complete picture in RT of the repair lifecycle (see recommendations below).
3. Free text fields sometimes have haphazard entries.  This causes some consternation when exporting data to Excel for analysis, though Excel can also correct for this using lookup functions to convert as-entered text to canonical values then used for reporting.  (For instance,"Apple", "Mac" and "Macintosh" can be converted to the one entry "Apple", which is how it shows up in SAP reimbursements.  "Lenovo" and "IBM" are another common pairing.) 
4. Some record-keeping and reconciliation is on paper only.  All important numbers matching work done to money received need to be electronically available and reportable, not just hand-written on a paper that is then filed.  The number that connects Apple reimbursements to RT warranty work is the case in point.  We need to record some matching number from the SAP transaction into the RT ticket so we can match up reimbursements with their tickets.

draft Recommendations

To be able to make meaningful measurements of the work being done in the Hardware repair area of the service center, some specific fixes need to be made to certain business processes. 

1. Fill in  the existing clarifying fields in RT 100% of the time.  Content in them needs to reliably available and correct.  These are at the heart of the measurement process.  The ones that matter for every ticket are:
   - Warranty Coverage
   - Manufacturer
   Others matter only for tickets of certain types, but need to be there when they apply:
   - PMAT # 
   - Order Repair #
   - Labor Reimbursement
2. Change or Create new custom fields to clarify and document billing and use them 100% of the time:
   1. price of the repair.  This numerical field would hold the amount expected to be paid for by someone, whether a manufacturer warranty reimbursement, cost object billing, credit card payment, etc. 
   2. billing method.  This pulldown text field would specify how the client was expected to pay: warranty reimbursement, cost object, credit card, etc.  This would tell us what kind of SAP transaction we ought to be looking in for the matching revenue event

      On 6/18 Rob noticed two new custom fields: "Hardware Charge" and "Software Charge".  These should be added to the list of have-to-be-there fields.  

   3. "Failed Part" could be converted into a pick list and used to indicate the kind of repair required - "hard disk", "display", "keyboard", etc.  Or it could be left a free text field with an understood list of likely entries, with downstream error-correction. 
3. Establish regular management oversight of the business processes to enable effective RT reporting.  Problems with missing or incorrect data can be identified early in the case closing process, or at billing, and be corrected then.  This needs to be the line responsibility of someone in the shop or in the management hierarchy.  Current case loads are a maximum of 200 cases per month, which is 50 a week, or 10 a day to check up on and correct. 
    
4. Modify the billing processes to generate better SAP to RT tracking.
   1. each SAP transaction needs to get the ticket number on to it somehow.
   2. each RT ticket needs to know how much revenue is expected from it, and in what form of payment.
   3. each RT ticket needs to know the matching SAP document number, if that's possible to obtain.