This is an interview that never happened. Something like this was supposed to take place in connection with my appearance at the HDI annual conference in 2008. The organizers typically publish interviews with some of the presenters in the run-up to the conference, but this one never actually occurred. I made it up. It’s what I’d have wanted to say.
Question. You’ve been involved in Knowledge Management for 18 years, as a software vendor, a process consultant, an author, an analyst and a conference speaker. We’ve talked about this a lot. Has KM panned out the way you anticipated it would in Customer Support?
Dorfman. Nope.
[pause]
Q. Nope? I think you have more on your mind than “nope.”
Dorfman. Well, for the entire decade of the 1990s, we made the excuse that organizations were working their way through the process of Customer Relationship Management adoption, which was a huge, six- or seven-figure investment for a lot of companies, and once they were out the other side of that, then they would get around to KM. It worked out that way to a degree, but not the degree we anticipated. Knowledge bases were supposed to be everywhere by 2004, 2005. They’re not.
Q. This isn’t like you.
Dorfman. I’m exaggerating a little. KM’s not a bust. Lots of organizations have deployed self-help knowledge bases to enable customers, and internal end users, in the IT service desk context, to solve some of their own issues, and thereby lower the cost for support by diverting incidents from the phone to the web or intranet site. Companies have gotten a lot of value from those. There are success anecdotes, certainly, in implementing knowledge bases for use by service desk analysts in the Incident Management and Problem Management processes. I wouldn’t be doing KM any more if I hadn’t had successes and didn’t believe knowledge management adds big value to customer support.
But there were some articles of faith, especially back when I was on the vendor side, that have not panned out. I wrote a book about knowledge-based problem resolution tools in 2005. At the time, vendors were still suggesting that differences in search and retrieval technology were critical differentiators between these systems. From a technologist point of view, the distinctions are very interesting, and there are meaningful differences for a small segment of the market. But from the end user perspective, for the vast majority of adopters, those aren’t the differences that matter.
The differences that matter are much simpler, more pragmatic things: Will the system integrate smoothly with our call management platform – the version we have in place today – at anything like a reasonable cost? Will it really help us make sense of all this documentation we have and that people care about? Will using the knowledge base get in our analysts’ way, and will they really be more productive if they’re now spending time searching and creating content? And even if they are more productive, how is this worth an additional $5000 a seat to my service desk?
Q. That’s a real number – $5000 a seat?
Dorfman. I’ve seen it in RFP responses, if you do the math. Of course it gets worse when you add in the cost of integration. I know running a software company is an expensive proposition. But a lot of prospective KM adopters are deciding that the price of tools is far in excess of the value they will get from the knowledge base, and on the whole I agree with them.
There used to be a low end to the KM tools market, where you could license a system with surprisingly strong functionality, at quite reasonable cost. But the low end has been very unstable. Those vendors have been acquired and their tools absorbed into higher-end CRM or IT service management platforms, or they have just not made it.
The other interesting question in 2005 was whether there was a genuine, sustainable market for vendors of pure problem resolution systems – at the time they were positioning themselves as “Service Resolution Management” vendors, and promoting this concept as if it were a full-fledged IT service management process, like Problem Management or Change Management. The subtext of course was that SRM should be a line item in the service desk budget.
I expressed some doubt about this in the book – in my mind, it remained to be seen whether buying a “best of breed” problem resolution system from a separate vendor would really make more sense than buying the knowledge base add-on from your incident management system vendor. I never questioned whether the best of breed tools were really technically superior – they have been and they are. But does that difference make up for the headaches of maintaining a separate vendor contract and relationship, and the cost of integration? Any vendor can make that case in certain marquee accounts, but my sense is that for the majority of cases, that is a very tough proposition to prove.
Q. So where can you make the case for best of breed?
Dorfman. Where you’re going to have a very large, sprawling knowledge base with tens of thousands of distinct solutions, especially when the people searching for solutions are relatively unsophisticated and may have a very unclear picture of what they’re looking for. But most knowledge bases are much smaller than that; in the real world, a knowledge base with 300 or 500 well crafted solutions covering issues that actually happen to your end users (as opposed to being things that obviously could happen but virtually never do) can be hugely valuable. And it doesn’t, or shouldn’t, cost you a king’s ransom to build and maintain it. Then again, if you’re, say, Cisco Systems, and the scope of the knowledge base is everything you sell, you probably should be looking at best of breed. The issue for the vendors is, how many Ciscos are there, really?
The other place where best of breed probably is worth the expense is where it really, really matters whether the answer you get from the knowledge base is correct. Let’s say you support a medical device, a blood glucose meter or a CAT scanner. You can easily imagine scenarios where providing the wrong solution to a technical question could really hurt someone, and put you at big liability risk. One way best of breed solutions justify their cost is by minimizing the likelihood of an answer being wrong, and by providing very sophisticated audit trails for content authoring and maintenance.
Q. OK. So here we are again, talking about knowledge tools. It’s ironic, since you’re no longer a tools guy. You’re really a process consultant.
Dorfman. True. Once people associate you with technology, it’s really hard to shake that. Hence the book.
Q. So let’s move to process. Are you a proponent of the Knowledge-Centered Support best practices?
Dorfman. Sure. There are some very profound things in the KCS framework – for example, the idea that the most valuable knowledge base content is generated in a bottom-up fashion, in the workflow, through actual customer interactions. The idea that you should only invest time and effort in generating content that real experience proves is relevant to your end users – common sense, really, but it’s a KCS principle. The evolved scheme for evaluating and controlling content quality is a valuable part of KCS.
I teach KCS and help organizations to adopt it. Or, rather, we borrow from KCS what makes sense in each specific case. The framework is good; it evolves and is getting better. But it isn’t necessarily complete, and I’ve seen some groups decide that parts of it are too formal to be realistic for them.
The most valuable thing about KCS, and this goes generally for best practices, is that it exists and is branded. KM adoption is a big deal. Its ultimate sponsor is likely to be someone remote from the actual processes in which it is going to be applied and who may have little personal involvement in its implementation. You need to convince the sponsor that funding the KM project will provide a benefit to the business and reflect well on him or her. The existence of a widely adopted Best Practice supporting KM helps to make the case that there is a proven and documented “right way” to do KM, and that the proposed project has a high probability of success because Best Practice will be adopted. Honestly, this probably has as much value as anything KCS actually says.
Q. You’re now an IT Service Management/ITIL® practitioner.
Dorfman. Thanks for noticing.
Q. Yes. Well. The whole ITIL framework has been refreshed, and ITIL Version 3 has a lot to say about KM. Is that significant?
Dorfman. Yes.
[pause]
Q. You’re doing it again.
Dorfman. Dramatic pause for emphasis. Don’t mind me. I’m actually very intrigued by this.
ITIL has not been particularly helpful in clarifying or setting objectives for KM – until Version 3. The refresh finally puts knowledge management on the IT executive’s map – but not in the way KM proponents might have expected.
ITIL 2 was filled with glancing references to KM as focused on problem resolution. ITIL 3 establishes a context and a roadmap for the management of institutional knowledge – KM as a metaprocess for IT service management, beyond the everyday business of managing incidents, rooting out errors in the infrastructure and resolving recurring problems.
KM can offer significant productivity gains beyond the service desk. Knowledge sharing enables more informed decision-making, and the people who manage IT services are always making critical decisions, about changes to the infrastructure, organization of projects and teams, adoption of new technologies, protection of IT assets from disaster or hacking, and other relatively strategic issues remote from routine, tactical PC support.
So ITIL 3 is good for proponents of KM – especially process consultants. It’s unclear what the impact will be on the current vendors of KM software tools, most of which are narrowly focused on problem resolution. Many of them are scrambling to be seen as embracing ITIL 3. The visionary vendors will build collaboration and community-building tools onto the ITSM platforms of their clients, and some of what works for problem resolution will have a place in the larger ITIL 3 context. The vendors of the ITSM platforms themselves, the largest of which already provide their own KM solutions, are positioned best.
ITIL 3 raises the profile of KM among executives who provide the sponsorship and funding for IT. For the first time, recognition of the strategic value of institutional knowledge is elevated to a basic Best Practice.
Q. What’s really new in ITIL 3?
Dorfman. The framework recognizes and accounts for the fact that IT evolves. After seven years of ITIL 2, the organizations responsible for ITIL recognized that building out the framework would still bring the enterprise to a static endpoint, in which the dozen distinct processes are often owned by separate teams and isolated in silos. ITIL 3 is intended to take the adopting organization to a higher level of process maturity. Among the explicit goals of the refresh are to remove the process silos; to more closely integrate service management processes with the processes of the business; and to create a framework that recognizes that businesses, and IT infrastructures, constantly change. ITIL 3 embraces the concept of the IT service lifecycle, and the need to manage services through recurring cycles of design, implementation, adoption, operation, feedback and improvement.
Q. Did you memorize that?
Dorfman. Yes.
Now, ITIL never explicitly advocated development of a knowledge base, although the Known Error Database, in Problem Management a repository for infrastructure errors and Solutions to those errors, certainly sounds like a knowledge base. ITIL never said how a Known Error Database should be built – it could be something as simple as a spreadsheet, or it could be a complex, enterprise knowledge management system.
The Incident Management process includes a step called Matching, where the analyst compares a new incident to past incidents, to classify it and identify it against known errors, and to suggest appropriate workarounds or fixes. If you’re conditioned to see this as an occasion to consult a knowledge base, you can, but ITIL never proposes a specific way of going about Matching.
KM can be a pervasive sub-process throughout IT service management, and ITIL finally offers some guidelines in version 3.
ITIL 3 proposes a “Service Knowledge Management System” – a solution intended to capture knowledge from sources ranging from one end of the service management process life cycle to the other. ITIL is vague about what an SKMS looks like. But it clearly envisions an enterprise knowledge platform, as opposed to a point solution for problem resolution.
Knowledge assets flow into the SKMS from a variety of sources and directions, including data, housed in the Configuration Management Database. Configuration data passes from the CMDB through a higher level logical repository called the Configuration Management System (CMS). At the top level, the Presentation Level, the SMKS is supposed to provide multiple views into the end results of knowledge processing that happens at lower levels. There’s a general, portal view, as well as specific dashboards for business functions such as governance, quality management, asset and configuration management, and the service desk. A customer view, for self-service, also is proposed. Obviously, this is different from a knowledge base where you ask a specific question and you get a list of possible answers.
Benefits include many of the conventional things vendors talk about in reference to problem resolution tools deployed in service desks: Better, faster, more accurate problem-solving; higher first-call resolution rates or lower rates of escalation to higher level subject matter experts; reduced analyst training and the like. But the ITIL conception of successful KM includes broader metrics such as successful adoption of new or changed services; greater responsiveness to changing business demands; and improved adoption of standards and policies.
Q. ITIL 3 is new. Has anyone actually built an SKMS?
Dorfman: Correct – it’s brand new, and no, I haven’t seen one yet. But I believe there are big opportunities here.
I don’t think any one vendor can provide all of the components at all layers of the architecture, and there are opportunities for narrowly-focused vendors to create high-value “snap-in” components, such as ready-made dashboard components for specific IT and business functions, to drop in at the Presentation Layer; SKMS-tailored business intelligence, query and monitoring tools for the Knowledge Processing Layer (where technologies commonly used in conventional service desk problem resolution could be applied as plug-ins); and other components.
If the SKMS is broadly accepted by the ITIL community as Version 3 takes the place of Version 2, Service Knowledge Management represents a huge opportunity for systems integrators.
Q. And for the companies who have tried to do KM?
Dorfman. ITIL 3 is an opportunity to get KM onto executive radar screens, maybe for the first time. Managers who have tried to promote KM adoption may see this as a golden moment to advance a personal objective, and they may be right.
But one piece of objective counsel in KM adoption does not change as a result of ITIL 3. The framework calls for a strategic vision for enterprise knowledge. But the best roadmap for success in knowledge management will get the adopter there in small increments. An effective KM adoption is a big win, and the way to win big is by repeatedly winning small.
So have a long term vision for the SKMS, but have a plan that gets you there by building it in bite-sized chunks. That will greatly reduce the risk of failure for you and for your executive sponsor.
Peter W. Dorfman 