What's your KnoweldgeBase creation policy?

[Mark Greenwood2]

I am looking to establish a policy for what conditions warrant creation of a new KnowledgeBase.  I am trying to balance accommodating the needs of the knowledge users with the concerns of having too many KnowledgeBases that it becomes counterproductive.  

Anyone have any best practices that have served them well?  Or perhaps cautionary tales on what to avoid?

[Eoghan Sinnott]

One of the main things that I take into account is the intended audience. If there are strict Can Read User Criteria being put in place then I don't see an issue with a new knowledge base being created (also taking into account the volume of articles that will eventually reside there).

If the intended audience is more of a 'global' or open to a large part of the organization, then the content should be house in a 'public' or Self Serve Knowledge Base.

We currently have more than 40 Knowledge Bases but over 90% of the company would see only 2 or 3 knowledge bases at most. Majority of them are specific to internal teams/processes.

[Pam Calvey]

We are considering that as well. We are about to pull one category out of a knowledge base and create its own KB. The topic is narrow and at a high level, but the titles come up in general searches too often for the Service Desk, negatively impacting their search and response time. The new KB will have a much smaller audience and can read parameters, so it won't appear to many people on the service portal. So, searchability and security are two factors to consider. 

[mbernste]

We created a catalog request on the self-service portal for knowledge base onboarding.  We ask some basic questions like who should be able to contribute, approvals, who should read, location of legacy knowledge (i.e. Confluence, Jira, OneNote, etc.), audience (i.e. self-help, level 1, etc.).  The form also asks what categories the knowledge should fall into to get the requester to think about categorization.  I then create the KB in UAT and review it with them and iterate from there.

[Leri Andrews]

Moved from hundreds to just 3 for each functional area.  They had been being used to hold translations instead of making use of the child>parent functionality. As others have said, I'd consider a new knowledge base under only a few circumstances.  1. Restricting editing 2. Different workflow. 3. Restricting visibility to the end user 4. Enhancing filtering in search results (view all policies in a policy knowledge base for example).