What does your Knowledge "Data Governance" look like?

[nebula]

I’m looking to understand what everyone’s Knowledge Governance looks like at their company — or if that even exists? Does ServiceNow provide any guidance on how to best maintain article integrity, lifecycle, and process for authors?

For example, we have Ownership Groups set up so that articles are approved by the appropriate team before reaching the Knowledge Manager. However, we’re running into cases where the app owner writes documentation, but others outside the team also contribute articles. These external contributors often aren’t aware of updates and don’t maintain their content, especially after upgrades. Their articles also don’t include the app’s ownership group, so the original team isn’t aware of new content unless they run a report.

This brings up a few questions:

• What’s the best way to handle documentation ownership between an application and a team’s process?
• If a team needs the app team's input or collaboration, how can that be reflected in the knowledge ownership process?
• Since ServiceNow only allows one Ownership Group per article, is there another way to connect two separate groups for visibility and accountability?

Would love to hear how others are managing this.

[nebula]

Hi @Rafael Batistot - I did see this and replied to Allan to see his thoughts. Thank you though!

[Rafael Batistot]

@nebula 

Great!

[PAWANK]

If I have understood this challenge correctly:

Three groups involved -

1. Product/Application Owners
2. Knowledge Contributors outside the Product/Application Owners/team e.g. Application support teams
3. Knowledge Manager

They all have privileges to capture, improve and approve-publish knowledge with a review.

Q1. What’s the best way to handle documentation ownership between an application and a team’s process?

A. Product/Application Owners - They must focus on product documentation knowledge that would mainly focus on product release guides, policy, security guides best practices, feature/functionality <how to>, FAQ, installation, configuration and licensing etc.

External/Application support teams - They must focus on product user assistance <self-service> and internal product support knowledge. That's support & troubleshooting knowledge that they learn and experience during the problem solving processes i.e. incident/request/problem mgt.

Of course, both must search before create any new knowledge and collaborate to learn from each other's experiences. E.g. product owners to review and update knowledge in the events of product enhancements, or upgrades. And, support knowledge owning group to consult product owners if "critical" knowledge needs to be validated before publish.

Q.2 If a team needs the app team's input or collaboration, how can that be reflected in the knowledge ownership process?

A. The knowledge form should reflect <fields>:

1. Application Name as a "reference field."

Meaning, when you click on the information icon, it typically opens the Application record, allowing users to view more detailed information about the associated item, such as the product name, owner, owning group, knowledge approvers/publishers etc.

2. A Workflow that allows to "submit the article" for review to the knowledge approvers/publishers from the application owning team.

This should trigger a notification to the application owning team/group.

This does not require App "Owning Group" be displayed on the knowledge article form.

Of course, support team must be provided with such a process & workflow to request specific input from Apps team/Owning group.

Q.3 Since ServiceNow only allows one Ownership Group per article, is there another way to connect two separate groups for visibility and accountability?

A. As said above, your solution consultant / developer will help you to customize. He will expand the "Article Approver" field. So a contributor or article updater from Support Team will be able to add "approver-publisher/s" from the Apps team/Owning group.

I hope it helps. Otherwise, please apologize me for incorrect understanding of the challenge. 

[nebula]

Thank you for your thoughtful feedback on the process!