Tying Knowledge Ownership through CSDM

[Juan Osorio]

My approach leverages the power of the CSDM model for ownership and accountability. Allowing you to scale to any team, dept, line of business into Enterprise Knowledge Management. while minimizing knowledge mgmt overhead.

The idea is that all items in the CSDM framework have ownership. It does not matter where in the stack the CI is. Because all CI's roll up to a "Managed by", "Owned by" or even a Support Group for ticket routing. It does not matter if the CI is operational or not.  This approach works for my organization, but you can choose what field to use for your knowledge workflow.  Out of the box you can associate knowledge articles to Configuration Items and Service Catalog items. All of which are owned in one way or another.

You can design you workflow to use knowledge templates in order to minimize manual work for knowledge mgmt.

Additionally, you need to decide what field in the CI record to use ("Managed by", "Owned by" or even a Support Group) in order to trigger workflow notification and review accountability\ownership.

Below is a high level of this in action.

[ebroc]

Totally agree. I've been saying it for years, associate the KA with a CI and have either the CI owner group (or even put a custom "KM group" field on the CI looking only at groups with Type: Knowledge Approvers). Thanks for the post and image.

[Matthew_13]

@Juan Osorio - 

This is a smart, scalable way to tie knowledge ownership directly to CSDM instead of managing it as a separate process. By leveraging CI ownership fields (Owned by, Managed by, Support Group), you naturally enforce accountability and reduce manual knowledge overhead while scaling across teams and domains. It’s a practical example of using ServiceNow CSDM to make Enterprise Knowledge Management sustainable—not heavier.

[Aerin]

We are just implementing CSDM and I'm working to make sure we tie in Knowledge from the beginning.

[Andrew64]

Although I agree that the management of the 'owner' of the article would be easier, the content wouldn't be updated any faster. 

We tried this approach back in 2016, where anything that was created by another group was assigned to the CI group. The CI groups are so overloaded with work that they don't care to review Knowledge this way. So we moved to a more KCS methodology in 2020. Where the groups make the update and the CI groups receive a report of what Knowledge has been updated and created for their CIs. They love this because most, if not all, of the knowledge was being approved, and they didn't want to click approve on everything.  

To keep it simple, I agree with the thought, but it doesn't work everywhere.