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 -- Bench Time rather than create-to-close elapsed time.
• 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. Isolating the Hardware Repair business within the SAP cost object is difficult as revenues from the Software side are mixed in as well.   (This would be less of an issue if the RT-ticket-to-SAP-transaction link were more clear and consistent).
2. 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.  
3. 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.   
4. Metadata fields in RT tickets are note used consistently enough.  These fields are the ones that power management reporting and metrics.  They are the only ones that tell us what kind of work is what within the system of record.  Indeed, one or two additional fields are needed to give a complete picture in RT of the repair lifecycle (see recommendations below).
5. Free text fields sometimes have haphazard entries.  This causes some consternation when exporting data to Excel for analysis, but Excel can also correct for this using lookup functions to convert as-entered text to canonical values at analysis time.  (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.) 
6. 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 isthe case in point. 

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
   If the burden of recording these fields is considered too great for the bench staff, then the process manager needs to do this work afterward.  By the time the case is billed out, the fields need to be filled in. It is the role of someone in queue management to look for and correct missing or incorrect data.
    
2. Create new custom fields to clarify and document billing:
   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. 
       
3. Begin using the TimeWorked field to record Bench Time.  When the hardware being repaired is not on the shelf waiting, each time staff works on a machine, the duration of that stage in the repair process needs to be updated into the Timeworked field.   We need to be able to tell if a two-calendar day repair took twenty minutes or twenty hours on the bench. 
    
4. Establish regular management oversight of the business processes including 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 the shop foreman or similar job title.  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. 
    
5. 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.