Knowledge Ownership Groups vs Knowledge Bases

[clktester]

Total newbie question. 

The organization I work for doesn't have a centralized IT department. There's about five different IT related departments. Plus there are groups that handle IT related tasks like the telecom group or developer groups. 

The organization setup two main bases more geared towards audiences. The end user base shows on the portal. The fulfiller base shows in the Fulfiller view. In these bases, they setup Knowledge Ownership Groups. Now the help desk wants to control any article from any group, mainly to get specific details about support in the article. 

Each article has 'end user defined' sections and 'fulfiller defined sections'. In the Fulfiller defined section, it's a mishmash of notes for the help desk and notes for the fulfillers for that product or service. Sometimes the fulfiller group won't even have notes for the help desk. 

My question is...which is better...having multiple bases for the groups that want to manage articles or having a few bases and having lots of ownership groups. 

I am suggesting multiple bases because then those groups have more control over features for that base. And since everyone just searches, they don't usually start at a 'base' level so to speak, there's no net loss. the Help desk can start searching and still search across bases. Users may find it easier to find a base suited to their department, etc. 

What is the best way to handle an organization that doesn't have a traditional hierarchy / department approach?

[Dave Littlejohn]

The way we implemented knowledge was about the settings for the knowledge base and if it warranted its own configuration. For example, a different approval or retirement workflow or target audience.

Some of our fulfillers needed different approval workflows (business signoff required or not) and so we have a few knowledge bases for our fulfillers.

We also have an end user facing knowledge base and the reason for that separation between the fulfiller's knowledge base was it made it very easy to see if it was self-serviceable (was the answer in the end user facing knowledge base or not). We do leverage knowledge blocks to have information tailored to the end users (depending on region/access) but ultimately if it was something the end user could have done, it would go in that knowledge base.

[Per-Kristian BM]

Good day to you!

I second your suggestions, having multiple bases. Like you say, this makes it easy to handle the attributes on the base level, like  valid to, knowledge artile templates, access, read, publishing- &retire workflows etc per base. 

I would also strongly advice to look into the KCS framework on how to deal with knowledge management. this might turbo charge your output on self-service as well as service desk services

[Holly H_]

Based on my experience (in a large organization), I agree with your idea to have multiple KBs. And over time, the Help Desk can author their own articles based on metrics from the tickets, tailoring their version to an HD analyst. They will still be able to search the other KBs for updated articles. Reporting on article changes could help them with maintaining their own Help Desk content.