Why do so Many KM Initiatives Fail in Technical Support (TS) Operations?

Posted by Srinivasa Rao in

 Infrastructure Management

Nov 30, 2009 | Total views: 60

6

Srinivasa Rao
Head - Technical Support
More articles by the author

Knowledge management (KM) has enormous potential to improve operational efficiencies and customer satisfaction in a TS setup. But, far too many KM initiatives fail at various stages of implementation. Let us take a closer look at some of the reasons:

Lack of organizational leadership to encourage collaborative culture: Effective implementation of KM involves introducing sizeable changes to the way support teams work. Absence of a KM champion, acting as a catalytic change agent, makes it difficult for the KM initiative to take off. You need someone who evangelizes (read: thinks, dreams, breathes) KM passionately.

Knowledge has limited shelf-life: Delay in capturing or sharing knowledge base (KB) substantially reduces its utility. You may be losing valuable time in your efforts to review and sanitize the knowledge. In the absence of a published KB article, your support engineers are sharing their solutions with the customers anyway.

KB does not capture the customer’s context: KB articles mostly talk about the root cause of a problem and the solution, but leave out the customer context. Customers do not call in saying, “IMAP proxy server crashes when the TCP packet size is XXX.” When you record the customer’s context, your frontline engineers can find the relevant KB article based on how customers describe their problem.

Knowledge is not captured based on demand: Unless you keep a watchful eye on what your customers are searching for (indicator of demand), you would not know what topics your new KB articles should cover.

Case management and KM are not integrated: This is the most common situation when you have a legacy case management system that does not support sophisticated KM workflow and you bring in a separate application for KM. This further de-motivates the support engineers as they now have to work with multiple systems

Knowledge is not searchable and usable: Knowledge needs to be captured using well designed templates during the support workflow. If these templates do not clearly separate the problem and solution from the general administrative information (Eg: “I have promised Jim that I will install the probe patch at 11PM.”) captured knowledge becomes less useful.

Vitality of knowledge is not maintained continuously: If your customer searches KB a few times and does not find useful articles or worse, finds some outdated/obsolete knowledge, you can be sure that she is not going try again. Responsibility of keeping KB current should lie with every support engineer and the triggers for edits/deletions should be integrated into the support workflow.

Using wrong parameters for measuring performance: If you measure the activities performed by engineers to reward them for their KM contributions, you will soon see false superstars emerge with loads of KM activity, but very little business results. You should also measure desired outcome of KM activities (first call resolution, number of useful solutions created, quality of solution etc.)

Lack of effective communication: However great your vision is and lofty your goals are for KM, unless the benefits are effectively communicated to all the stakeholders (customers, engineers, management), your adoption rate will leave a lot to desire.

Do let me know your experiences.