Knowledge Bases in ServiceNow

[Diane22]

I am looking for guidance on making a decision

- modify / customize current Knowledge base

- create new knowledge base

A resource stated (without supporting documentation) that ServiceNow recommends one KB for all IT.  Well ... that doesn't work well for me based on considerations such as:  who owns the data, what is the audience, what is the intended use.  I get that we can integrate Known Errors in the same database, the modifications needed to make that work were minimal. 

But what if the workflow (process), the managed by, the domain experts (approvers), the contributors and the audience are different.  Then we increase the technical debt because of heavy customization if we leverage a different category only and access permissions and then modify the workflow as well.  So where is the balance.  I can certainly understand that we wouldn't want to have 10+ knowledge bases to manage, but again, looking for considerations to have a good balance and sound decision making.

Is there something to provide guidance for such a decision?  Factors to consider?

[Peter Bodelier]

Hi @Diane22,

It is perfectly fine to use multiple Knowledge bases. Not sure what the rationale was to advice against it, but other than making sure every knowledge base is maintained, there is really no objection to use multiple.

[Patrick Laroch1]

As @Peter Bodelier mentionned, it is completely fine on a technical aspect to have multiple KBs. It really comes down to governance. Your Knowledge Management Process Owner should be the one to make a decision on whether another KB is necessary and main reason that would drive that need is the workflow.

Steps to Structure the knowledge base

With the participation of the different service/business Stakeholders:

• Determine the number and name of Knowledge bases, what content will be in each, and who will have access to each.
•    The primary manager of a knowledge base is the owner of that knowledge base. Each knowledge base must have one owner. There may be any number of additional managers for each knowledge base.
•    Each knowledge base can have a publish and retire workflow specified appropriate to the required approval levels. These may differ depending on the type of content e.g. HR vs Marketing vs technical.
•    Determine content ownership, security, and access rights.
• Determine how the knowledge base content will be organized by topic and category to facilitate easiest access and use by all users.  Each knowledge base can have its own multi-level taxonomy that is independent of the other knowledge bases.
•    When considering the taxonomy and number of knowledge bases consider also the use case of search which is likely to be the majority use case.
• Determine the various views that will be needed (for example, end users, service desk, network support, others).
• Determine the various configurable aspects
•    Use Templates to aid knowledge creation. There are 4 templates available out-of-the-box through the Knowledge Management Advanced plugin: How To, What Is, KCS Article, FAQ
•    Use UI extension points to customize knowledge article headers and footers
•    Differing types of feedback are available for articles.  It’s important that there is a process in place to take this feedback and action it.  This will help develop the knowledge base based on collective experience.
•    If the Group Ownership system property is enabled, User Groups can be created and listed on individual knowledge articles to define a group of people who are responsible for maintaining specific articles.