Plugging the SLA Loophole

This one is for all of the Business Analysts and Reporting Analysts out there, as well as programmers. Although article is about one particular project the circumstances and issues are far from unique. In fact, I have encountered the same issue several times in the intervening years.

I was brought in as a consultant to work on an Excel-based SLA Metrics reporting tool. The existing tool was having performance issues and the group didn’t have the technical expertise or time to dedicate to fixing it. The main problem was that the formulas were getting far too complex due to the original developer’s limited knowledge of Excel and its built-in functions. As it turned out, that was the easy part and we got it up and running in a reasonably short time. It is important to note that we were reporting on the Help Desk’s ability to hit their targets, based upon the severity of the ticket. The Help Desk was, at the time, internal to the company. The ticketing system was Remedy and all of the data was taken from data dumps on a daily basis. The raw data was imported into the spreadsheet, as-is, and the reports generated.

This worked well for a while but then the company decided to outsource the Help Desk. This made the reports far more important because the hired company got paid based upon its performance in relation to the SLA. This went on for a few months when I noticed that one of the metrics seemed to be averaging much higher compliance numbers than previously. This was for the least severe tickets – they only needed to be completed by the date the help desk associate provided to the client. They either hit that date or they didn’t. This seemed odd so I first checked the Excel application to see if it was “broken”. Everything was good! Maybe the structure of the data dump had changed. No, that was good too! I finally opened Remedy and looked at some of the tickets. What an eye-opener that was! When I looked at the “audit trail” for a ticket I noticed that the “Promised Date” had been changed a number of times. In each case, the change was made a day or two before the current promised date. Typically, the last time the date was changed was shortly before the ticket was resolved. When Remedy was compiling the data, it was only exporting the most current “Promised Date”. No wonder they were hitting the mark – they kept moving it! I looked at a few more tickets and noticed that this was a big problem and since the contractor was being paid based upon how well they performed, it was costing the client a small fortune.

I now knew what the problem was and I also knew the solution; I needed to extract the initial promised date and use that in the SLA. Well, talk about easier said than done! I asked for a data dump that included the audit trail for the tickets and discovered that all of the data in the audit trail was in a single field! There might be a hundred or more bits of information in this field and there were no clear delimiters. I had to figure out how to extract the initial promised date but it wasn’t always located in the same position in the data. This was going to take some thought…. I was finally able to write some VBA code in Excel to parse all of the data but running the code took a long time and it wasn’t really that efficient. The answer came in the form of Access. I created an Access database in which I stored all of the data that I needed for the reports and converted my Excel VBA code to run in Access. I then compared the results of the old reporting method with the new method. The difference in the results was far more drastic than I had even anticipated.

It was now time to put the whole process into production – the only problem was that it took about 6 hours for Access to parse all of the data every time we ran the report. I then had to import the data into Excel and create over 100 charts and graphs that were to be pasted into a PowerPoint presentation. This wouldn’t be too bad if it were a weekly report but this had to be done every day! I ultimately had the data dump completed at about 1:00 AM and had the Access parsing process running over night. The Access code started looking for a particular file after 1:00 AM and when it was found, the data was automatically imported and parsed in Access. When this was completed, the code opened Excel, imported the data, created each chart and graph needed for the report and pasted them into a new PowerPoint presentation. The presentation was just about ready for me to mail out when I got to my desk in the morning.

This work used to be done manually every day (except for the audit trail parsing) and took hours. The actual process now took longer but the man hours were reduced to about 20 minutes. The client not only saved in labor costs but now the SLA payout was based on REAL results and the client saved thousands of dollars a day.

About a week after the solution was put into production I started hearing a buzz in the office. I heard it said that it was “impossible” to parse the audit trail and the “experts” didn’t believe it could be done. I made them believers. This entire experience solidified my belief that nothing is impossible. The only time something is impossible is when you think it is – I didn’t know that what I needed to do was “impossible” when I set out to do it and so I didn’t have to deal with that obstacle.

Curiosity is one of the most valuable assets in a programmer’s toolbox. I took it upon myself to pay attention to the reports I was creating and question the results. It wasn’t what the client expected me to do but it is something that I demand of myself.

There were two lessons to be learned; first, the old cliché – “think outside the box” – and second, pay attention to detail. You also need to use all of the tools presented to you to make every minute a productive one. Microsoft Office is a great tool – each application can save you valuable time and give you a competitive edge but its real power lies in the ability of the individual applications to work together seamlessly. The above example used Access, Excel and PowerPoint as a single “solution”. I would have included Outlook in the mix but at the time I wasn’t able to work around the security features that hinder Outlook automation from an outside source.

I have many stories like this one – some using just one Office application, some using them all! If you are interested in learning more or have a situation you would like to discuss – drop me a line and let’s talk. You can reach me at joevalencia32@gmail.com any time.