Knowledge success stories

[CasandraGB]

Hello everyone! I am the knowledge SME for a company that has a decentralized knowledge creation/maintenance model, with a knowledge database of 5k+ articles.

Here, the different teams/groups create and maintain their own knowledge articles that can be meant for internal use or for end users.

The challenge I'm encountering is to keep this model and yet implement a series of knowledge reports that would show how each group/team is doing so they reach the main goal of having articles up to date and no knowledge tasks pending.

The ultimate goal is that the VA provides those articles to end users and stops incidents from being created.

Do you have any success stories about companies having a similar decentralized model? Or that maybe started like this but opted for a centralized model where the knowledge is created and maintained by a dedicated team of people?

Thanks in advance for your help!

Regards

Casandra

[David Kay · Accepted solution]

Casandra - absolutely.  Because Avaya was (is?) a KCS shop, they used the normal KCS mechanism of "every use is a review."  What that means is that any time their engineers attempted to use a KB article, they evaluated if it was "sufficient to solve"--good enough to resolve the issue to their and the customer's satisfaction.  If not, for example if the user interface had changed, the engineer updated the article then and there.  So if an article is used 100 times this quarter, it's effectively reviewed 100 times.

In most KCS shops, you have to earn the right to update these articles by demonstrating your proficiency and becoming a Contributor or Publisher.  If you're not able to update the articles, you can flag them with the changes that are required...but ideally that's a corner case in a mature implementation.  Fortunately, this flagging process is supported by ServiceNow.

[David Kay]

KCS (Knowledge-Centered Service) is a highly decentralized model that we've been working on for about thirty years.  Here's a collection of case studies that you might find useful.  (Disclaimer: I wrote a number of them).  Measures for providing individuals with visibility into the value they're creating, to manage the program, and to demonstrate business value are all important parts of the practice...let me know if you're looking for something specific.  Here's a guide that addresses metrics in the context of where you are on the KCS journey...

In my experience with well over a hundred companies doing KCS, they sometimes find it necessary to reboot or refresh their KCS programs...but I don't recall a case in which they've gone back to a centralized model.

[CasandraGB]

Hello David!

Thanks a lot for this information. I can see that the Avaya case is pretty similar to the setup we have and I since you wrote some of those reports, I was wondering if you have information on how they handled the maintenance (life-cycle) of the articles.

Thank you in advance for your reply!

Regards

Casandra

[David Kay · Accepted solution]

Casandra - absolutely.  Because Avaya was (is?) a KCS shop, they used the normal KCS mechanism of "every use is a review."  What that means is that any time their engineers attempted to use a KB article, they evaluated if it was "sufficient to solve"--good enough to resolve the issue to their and the customer's satisfaction.  If not, for example if the user interface had changed, the engineer updated the article then and there.  So if an article is used 100 times this quarter, it's effectively reviewed 100 times.

In most KCS shops, you have to earn the right to update these articles by demonstrating your proficiency and becoming a Contributor or Publisher.  If you're not able to update the articles, you can flag them with the changes that are required...but ideally that's a corner case in a mature implementation.  Fortunately, this flagging process is supported by ServiceNow.

[David Kay · Accepted solution]

Oh, since you asked about the life cycle, I should also mention that most KCS shops automatically archive content that hasn't been used (much) recently, where the exact definition of "hasn't been used (much) recently" depends on the specific product and business.  It has been many years since I worked with Avaya, and I don't remember if this was part of their process, but it's a good general practice.