Are Service and Service Offerings redundant on articles

[RogueFader]

Hi.

Apologies in advance for asking yet another question, it's a case of a process handed to me with no shadowing, real training, so I'm keeping the lights on and learning as I go.

So I'm looking at how our articles have been mapped when people have created these articles, one immediate note is that people have created categories on the fly, resulting in categories that can be about four levels deep, E.G Public Knowledge Base>Technology>Software>0365-Teams.

I plan to have this option removed and ideally I'd like it to be three levels deep, so above would look like

Public Knowledge Base>Technology>Software

What I would like to ask, is if others have Service and Service Offerings on their articles along with Category?

To me, apart from reporting, I can't see the benefit of having SO and Service along with category.

Anything that may have been used as a Service offering can be used within the Metatag field, so for this example, I'd use 0365-Teams within the meta to make it searchable.

Is there something I'm missing if by removing Service and SO and keeping only category, will result in chaos?

Thanks in advance...again. 🙂

 

[Pam Calvey]

We use configuration item name rather than Service or Service Offering. Is that what yours corresponds to? If you have it in one, you don't need it in the other. We also automagically add the TLA (Three letter acronym) for the configuration name to the meta field if it has one.  So we have the CI name and TLA in every article. 

[RogueFader · Accepted solution]

Hi Pam

We have Service and Service offering and also Config Item. It is only Category and Service Offering that is mandatory, although Service is populated automatically once the Service Offering has been selected, so in effect it's only CI that's an optional. Running a report today it seems we've also a pile of articles where one of those three fields have a retired SO/Service or CI. Looking today, it seem to have inherited a process where there's not been much quality control around these knowledge bases. Maybe I can win the lottery and run away from it all.

[Pam Calvey]

That's interesting. 99% of the time the document owner of the article aligns to the CI owner for us, so it's important to us to make that our key denominator. We do not use domain analysis, if we did maybe the service offering and service would be more important to us. I too run a monthly report looking for retired CIs. It seems like a lot now, but in time you will have a nice, streamlined knowledge base. 

[jonasgersbo]

For my previous assignment we did use them, as it’s an easy way of keeping track of “belonging and ownership”. From within the Service Catalogue, you’ll find all articles related to a Service/Offering (as set by the author). When sh*t hits the fan, it’s easier to find someone knowing the contents, even though the article might not mention the actual Service or acronyms. 

one CI might have multiple related Services, where it’s easier for a Service Desk coworker to find content based on a user saying “Service X failed”.