Too many times I’ve talked to both clients and service providers and discovered that they are not focused on the root cause, and simply deal with the symptoms. I’m sure you would agree if you are suffering from pain perhaps internally, and the Doctor prescribed only painkillers to keep you up and moving, you would be initially happy until things got worse. You could carry on that way for quite some time, until eventually your appendix burst and then there is a real life-threatening emergency to deal with. Now had the Doctor carried out a full root cause analysis to start with and determined that it was appendicitis he could have used a known error record or knowledge to deal with the problem before it became life-threatening.
All too often I see service desks simply taking each Incident as it comes in and dealing with the initial symptoms with pain killers and rarely progressing it into problem management to investigate the Root Cause for full eradication of the problem. Many don’t elect these answers into the Known Error Database (KEDB) or Knowledge Base (KB) and so end up re-solving the same problem over and over again, wasting time, resources and effort. Just imagine if Doctors and Surgeons did not share their solutions with others in each region, area and practice and they had to re-discover the solution for themselves!
Even clients tend to focus on measure the wrong thing. Many set up contracts with their suppliers to measure the reduction in time spent on resolving incidents, and the number of incidents. This is fine, if at the same time they measure and correlate this with the number of linked problems raised and resolved. Without this you find that the supplier and agent are simply focused on issuing pain killers to all as quickly as possible. How many measure solved problems that are migrated into the KEDB or KB? How often is the KB utilized in Incident management to permanently resolve them, preventing more being raised in the future? How many solved Problems are progressed into Change Management to enable preventative medication and prevent Incidents in the first place?
I mentioned before that I’m working with a client on Service Request Management (SRM) in a Multi-supplier environment, and I still fail to see proper integration into Incident and Problem management to handle SRM exceptions. Many tell me that Incident management is not meant to handle Service Request exceptions! Is the Service Desk not there to deal with all Services, including Service Requests?
Let’s suppose a supplier keeps rejecting the approved service request because they do not have all the information necessary to complete the request. If this exception gets recorded as an Incident (as it’s impacting the requestor with a delay or failure in the service) then the agent can investigate the cause. Yes, they can obtain the information from the requestor, fill in the details and then re-send the request to the supplier. However this is only dealing with the immediate pain.
Root cause analysis would highlight that the SRM form of that item needs changing to either have a mandatory field added, better integration with master data or pull down choice lists etc. So that when this root cause is determined, a change is raised and the system improved, we then find none or a few rejections from the suppliers. I could go on, with more examples, but I’m sure you get the point. Yes, we need to address the immediate pain, but we also must investigate the root cause and make every effort to prevent something more critical.
Any feedback and comments are always welcome!