Knowledge Management - education.nsw.gov.au · knowledge management framework called Knowledge...

Purpose The purpose of this document is to outline, at a high level, the process together with the roles and responsibilities to execute, manage and govern the DoE Knowledge Management Process underpinned by the Knowledge Centred

Support (KCS) methodology. This document will also summarise how KCS will integrate and facilitate improvement

to the support processes performed by DoE support operational functions in order to:

• Ensure knowledge activities are embedded, consistent, and repeatable to improve the overall quality of

IT services provided to our business and end-users.

• Provide an understanding of the Knowledge Management Process

• Provide a reference point for process queries and discussion.

• Detail the scope of Knowledge Management.

Audience & applicability The intended audience are those stakeholders throughout DoE that have a role to play in the Knowledge Management process either directly or indirectly as dependent stakeholders, as well as those stakeholders who

are interested in the process for execution and governance reasons.

This process document inherits the definitions contained in the SMO Glossary for Managing Services.

Context This document is created to provide a framework that underpins the execution and governance of the Knowledge

Management process. It is the definitive reference material for this process.

Document Approval List Version Endorsed by Role How approved Date

V6.0 IT Executive

Team

IT Governance

authority -

Endorsed at Ops Meeting 26/06/2017

V6.1 IT Executive Team

IT Governance authority -

Endorsed at Ops Meeting 31/07/2018

Document Change Control Version Date Authors Description of changes V3.0 18/08/2015 Sam Lambropoulos Change of background colour and DoE logo. V4.0 01/08/2015 Sam Lambropoulos Inclusion of Self Service Portal elements. V5.0 20/05/2015 Sam Lambropoulos Annual Review. Replace references from DEC to DoE.

Knowledge Management Process document

Version Date Authors Description of changes V6.0 07/07/2017 Stuart Owen Updated most recent approver and change of process owner.

Endorsed at Ops Meeting.

V6.1 16/05/2018 Stuart Owen Corrected spelling, removed references to TAFE and specific

technology, clarified location of document and training materials and updated alt text for accessibility.

V6.2 29/05/2019 Sam Lambropoulos Updated process ownership details

Document Information Details Name Email/Link

Process Owner Sam Lambropoulos [email protected]

Location Technology Site – Service Management

Guides

https://education.nsw.gov.au/technology/guides-

and-forms/service-management-guides

https://education.nsw.gov.au/technology/guides-and-forms/service-management-guides

https://education.nsw.gov.au/technology/guides-and-forms/service-management-guides

NSW DoE | IT Commercial & Services | Process – Knowledge Management 1 | P a g e

Table of content

1. Overview and purpose ................................................................................................... 2

1.1. Process overview .................................................................................................... 2

1.2. Process purpose ..................................................................................................... 2

1.3. DoE Knowledge Management goal ......................................................................... 2

1.4. Guiding principles ................................................................................................... 3

1.5. Process Objectives ................................................................................................. 3

1.6. Scope ..................................................................................................................... 4

2. Standards statements .................................................................................................... 5

2.1. Single Process Standard ......................................................................................... 5

2.2. Process Ownership ................................................................................................. 5

2.3. KCS Process Design .............................................................................................. 5

2.4. Knowledge management process stakeholders ...................................................... 9

3. When to use this Process ............................................................................................ 15

3.1. Process Triggers ................................................................................................... 16

3.2. Knowledge Process Support Model ...................................................................... 16


1. Overview and purpose 1.1. Process overview This process document articulates what practices are required for the DoE Knowledge

Management Process (KM) to operate and why. Detailed procedures and work instructions

describing how to apply this process are available via the Knowledge Management

Procedures document, the Service Management Essentials online training course (Accessible

via the DoE Staff Portal below the “My Training” section) and via the Information Technology

Service Management (ITSM) Toolset Knowledge base.

DoE has traditionally used SharePoint team sites and various shared network folders to store

knowledge. While there is a recognised dependence on knowledge, nevertheless knowledge

was created and used in isolation to the incident process. Knowledge prior to Knowledge

Centred Support (KCS) was produced by specialists and was static in nature which means

that only planned periodic reviewed partially kept content up to date and of use.

KCS differs to traditional knowledge in that it is ‘dynamic’ in nature where each individual within

each support team that utilises KCS has an opportunity to interact with Knowledge as a by-

product of the Incident Management process and at minimal overhead.

Knowledge Centred Support (KCS) is a methodology for capturing, authoring, refining, and

publishing information that is relevant to the support processes for DEC. When corporate

knowledge is structured and processed in a methodical manner it can have positive effects on

each support team, individual staff and most importantly our customers.

1.2. Process purpose

The purpose of the knowledge management process is to share perspectives, ideas,

experience and information; to ensure that these are available in the right place at the right

time to enable informed decisions; and to improve efficiency by reducing the need to

rediscover knowledge.

1.3. DoE Knowledge Management goal The goal of the Knowledge Management Process is to:

• Create Knowledge content as a by-product of solving issues (support events).

• Evolve Knowledge content based on demand and usage

• Develop a Knowledge base of the support organisation’s experience to date

• Reward learning, collaboration, sharing and improving Knowledge


1.4. Guiding principles In designing this process, the following guiding principles were applied:

• The Knowledge Management Process should align with the globally recognised

knowledge management framework called Knowledge Centred Support (KCS).

• Knowledge Management objectives should be defined, aligned and traceable to

Business Objectives, and be able to demonstrate business value via a balanced

scorecard.

• The Knowledge Management Process should be endorsed, resourced and funded at

all levels of the IT Support Organisation.

• Leadership and Management should actively plan for the rollout and embedding of

the Knowledge Management process.

• The Knowledge Management Process should be formalised, documented, approved,

published, reviewed and updated.

• Knowledge Management process shall be implemented using Project Management

methods and techniques.

• Knowledge Management Roles and Responsibilities should be defined and assigned

to teams and their individuals.

• The Knowledge Management Process should clearly state the Critical Success

Factors (CFS), Risks, Issues, KPIs and Metrics required to measure successful

knowledge outcomes.

1.5. Process Objectives The objectives of the Knowledge Management Process are to:

• Standardise knowledge management processes across the support organisation.

• Provide staff with a common understanding of how the knowledge management

process tightly integrates into the operational support processes implemented at DoE,

• To enable service strategy to provide customers with self-service; self-manage

capability.

• To improve Incident Management core metrics:

o Time to resolution

o First Point Resolution (FPR)

• To aid the reduction of errors in the infrastructure due to root cause removal,

• To improve SRM (Service Request Management) core metrics that show end-to-end

efficiencies:

o Time to locate and submit a request


o Time to approve a request

o Time to fulfil a request

• To optimise resources by reducing rework and improve efficiency of support teams,

• To improve the customer experience via reduced resolution times, improved quality

and consistence levels of service,

• To reduce resource single point sensitivity, encourage knowledge sharing and

collaboration,

• To reduce re-work by leveraging organisational experience

• To reduce the high volumes of low complexity ‘like for like’ support events by moving

support capabilities as close to the customer as possible (Shift-Left),

• To reduce the time to productivity of new staff members across DoE.

• To enable customers to self-help where appropriate to self help

1.6. Scope The scope of this process includes:

• Support teams across DoE that resolve Incidents and fulfil Requests. These teams can

now leverage Knowledge to the benefit of their team members and supported

customers

• Support teams across DoE that resolve Incidents using the ITSM Toolset.

• Support teams across DoE that leverage Knowledge to support other established

processes, such as Problem Management, Change Management and Service

Request Management

• Support teams across DoE that leverage KCS as the Knowledge Management

standard

• Customers at various sites that choose to consume Knowledge through the Self

Service Portal

1.6.1. Service requests escalated to DoE Suppliers Requests directed to DoE suppliers must be managed in accordance with the DoE KCS

Process. Where support is provided by a DoE supplier, and related to services

underpinning the DoE production environment, then requests must be:

• Updated and resolved by the supplier interacting with KCS – if access is available

to the Knowledge Management section of the ITSM Toolset;


2. Standards statements DoE ITD service and support functions shall integrate the Knowledge Management (KM)

process as a core activity to deliver and support the DoE Services. The Knowledge

Management process shall be aligned to the global knowledge framework called Knowledge

Centred Support (KCS) which allows leveraging of industry experience.

The Knowledge Management process while holding to the KCS process fundamentals, will be

configured and aligned to:

• Support Organisational objectives and focus across DoE

• Support workflows, interfacing processes, procedures and work instructions

• Team and Individual roles and responsibilities

• Performance assessment and measurements systems,

• Business Intelligence systems (Monitors, dashboards, reports)

2.1. Single Process Standard A single Knowledge Management process will be used to manage support of the Incident

Management process and other relevant ITIL processes. The single Knowledge Management

process will leverage the KCS methodology.

2.2. Process Ownership The Knowledge Management process is owned by the ITD Service Management Office, who

is functionally accountable for the process. The Process Owner is the role titled Knowledge

Management Process Owner.

2.3. KCS Process Design KCS is a double loop process:

• With the right hand side being the operational/support or ‘Solve’ side which are the

activities support staff at DoE perform to solve problems

• The left hand side being the proactive or ‘Evolve’ side. These ensure the support side

functions optimally.


Capture

Structure

Reuse

ImproveContent health

Processintegration

Performance assessment

Leadership & communication

Knowledge

KSC

Evolve

Solve

There are four key Practices that make up the Solve Loop & Evolve Loop:

The solve loop (A loop) is based on operational activities, driven by the support process

performed by individuals on a per transaction basis. These activities are ongoing and

performed constantly.

The solve practice include;

1. How and when to capture knowledge,

2. Structuring for reuse,

3. Highlights the importance of search at the beginning of the support process,

4. Ensuring that knowledge quality increases as its used.

The evolve loop (B loop) systemically looks at the content created across the many solve loop

events or transactions. It’s an organisation level processes which is intended to enable

efficiencies in the solve loop.

The evolve practices include;

5. Reviewing and improving the KCS workflow,

6. How knowledge evolves, article lifecycles, content standards, quality measures &

metrics,

7. Performance assessment,

8. Leadership.


2.3.1. Knowledge article lifecycle The Knowledge Article Life Cycle relates to the different states or statuses a Knowledge

Article progresses through. Each status alerts a potential consumer of the Knowledge

Article to the level of trust they should have when using it to resolve an Incident or fulfil a

Service Request.

Cancelled

Draft

WIP

Retired

Published

Approved

WORK IN PROGRESS (WIP)

This is a knowledge article that does not yet include a resolution, it should contain at a

minimum;

• the problem or question

• some information that is captured in the context of the customer, and

• the environment details

A WIP article is sometimes referred to as a “framed” article. WIPs are temporary in nature

and should move through to “draft” or “cancelled” by the time an incident is resolved the first

time. The WIP state helps notify other Support Analysts of pending ‘in progress’ issues. This

reduces the likelihood of duplicate effort, and promotes collaboration

DRAFT

Draft Knowledge articles are articles that have a resolution, but the required level of confidence

is yet to be achieved, it may still :

• Lack structure or content due to lack of customer feedback

• Lack other Support Analyst’s validation through reuse

• Not fully comply with the content standard


APPROVED

The KCS article is considered complete and reusable. It has high levels of confidence in the

resolution and it complies with the content standard. The article has been created by a

licenced KCS user (KCS Contributor [KCS2], Publisher [KCS3], KDE or Coach) or it has been

reviewed by a Coach. Approved knowledge articles can sometimes be referred to as

‘Published Internally’

PUBLISHED

The KCS article is ready for use outside of the support organisation, typically by customers or

end-users via a web portal. Published articles must be compliant with the content standard,

written in the context of the audience are visible to, and have a high level of confidence in the

resolution.

RETIRED

The KCS article is no longer required due to obsolete technology, problem elimination, or

simply lack of use. Knowledge is obsolete when it’s no longer used and should be then retired.

Retired knowledge articles are still stored in the Knowledgebase, but they do not display in

the search results within the daily support workflow.

CANCELLED

The knowledge base article is cancelled before the approval state. This can be due to the

customer cancelling the incident before a resolution is known or when an escalation group

receives escalated ticket which has a WIP Knowledge Article attached that is identified and

validated as a duplicate of an existing Draft, Approved or Published Knowledge Article.

2.3.2. Knowledge Quality Ratings Support analysts should rate every piece of knowledge they interact with, with the exception

of when a support analyst uses a knowledge article that they themselves have authored

(this is not mandatory, but is common practice). This is because the author already has the

rights to edit and improve their own knowledge immediately. It also removes the risk of

author bias, or stacking of the quality ratings.

End Customers will also have the opportunity to rate and comment on Knowledge Articles

that they interact with. These ratings will be reviewed as part of the KCS ‘Evolve’ part of

the process in order to continuously improve the quality of Knowledge made available to

our Customers.


Rating Description

5 – Excellent Complete compliance to standards, captured all perspectives and closes all incidents applied to.

4 – Good High compliance to content standards, covers almost all of the customer queries, but could be

a little more precise.

3 – Sufficient Sufficient to solve, clear instructions, but needs some work to meet the content standards.

2 – Poor Out-date, duplicate knowledge.

1 – Redundant Needs to be reviewed by someone with sufficient knowledge of the subject matter.

Flag for Review Needs to be reviewed by someone with sufficient knowledge privileges or a domain expert for technical accuracy.

2.3.3. Knowledge Licences

KCS licenses are aligned to Knowledge Roles. Licenses are granted to Support Analysts

based on the combination of experience and adherence to the KCS process and the Content

Standards.

Knowledge licenses are granted to Support Analysts by KCS Coaches when they feel that a

level of maturity has been reached and maintained. The KCS coach will upgrade or downgrade

knowledge licenses to reflect current performance.

2.4. Knowledge management process stakeholders

Description

Process stakeholders are comprised of both business and IT personnel who either:

1. Have direct effect, through contributions of specific inputs

2. Depend on specific outputs of the Incident and Knowledge processes.

Role Responsibilities

KCS Candidate (KCS 1)

The KCS Candidate should:

• Interact with the knowledgebase as part of the normal support workflow.

• Understand the Structured Problem Solving process outlined in the KCS framework.

• Accurately and consistently capture the customer’s context in the workflow.

• Search for and find existing KCS articles.

• Review and either link or flag articles in the support workflow.

• Rate the quality of KCS Articles.

• Modify their own KCS articles.

• Frame new KCS articles (work-in-progress or draft) that will be reviewed or finished

(approved) by a KCS Contributor (KCS 2) or KCS Coach.


Description





KCS Contributor (KCS 2)

• The KCS Contributor (KCS 2) performs all of the duties of the KCS Candidate (KCS 1).

• The KCS Contributor review knowledge Article as they reuse them, or

• Complete (Publish Internally) KCS articles that are framed by themselves or others,

• making sure the articles adhere to the content standard.

• Create, modify, or validate articles in their product area without review by a Coach.

• They may also author and approve articles for broad audience visibility.

• Update the knowledge state from ‘Work-In-Progress (WIP)’ or ‘Draft’ state to Approved

Internally.

• The KCS Contributor should have a detailed understanding of the;

o Importance of the context of the audience,

o Content standard, o KCS article quality index, and

o The KCS processes.

KCS Publisher (KCS 3)

• The KCS Publisher (KCS 3) is authorized to publish content to an external audience

(partners or customers), typically on the web.

• Compared to a KCS Contributor, the KCS Publisher takes a more global, outward

• view of the audience and the content.

• Understands the technical implications of the knowledge being published,

• Has an understanding of what material is priority information.

• Has an understanding of copyrights and trademarks.

• Responsible for understanding the external audience and publishing requirements

outlined in the content standard.

• KCS Publisher should have a good reputation for knowledge contribution, and receive

consistently high scores on their KCS article quality index. Have positive feedback on and high reuse of their article content.

• They should reliably focus on the success of the team and the customer over individual

success.

Knowledge Coach • KCS Specialists

• Be integrated into each team to ensure they don’t lose touch with the operational

environment.

• Become change agents for KCS adoption

• Communicate team progress

• Reporting and monitoring

• Help improve individual and team KCS competencies

• Develop KCS community through the licensing cycle.

• Identify training needs.

• On the Job support and review of knowledge activity.


Description





• Promote user skill development through effective skills coaching.

• Help the KCS Candidates (KCS 1) understand the problem solving workflow and how

the KCS article management process is integrated with the thinking process.

• Influence users to practice good knowledge management.

• Influence users to apply standards for creating and improving knowledge within the

knowledgebase.

• Review KCS articles framed by the KCS Candidates until they reach required levels of

competency.

• Perform internal validation of KCS articles to ensure accuracy for the described context

and adherence to the quality standards set by the organizational unit.

• Provide ongoing feedback to users and management about organizational KCS skill

development.

• Provide feedback to the knowledge developing organization, within the define

processes, to improve KCS article management.

• Develop and monitor their own coaching skills through work with head Coaches.

• Participation in the KCS Council.

Knowledge Domain Expert (KDE)

• Ensure problems are resolved effectively and efficiently

• Must have both technical depth and a thorough understanding of KCS

• Responsible for the health of a collection or domain of knowledge for their technical

expertise.

• Focus on both quality and technical accuracy

• Assist colleagues in collection, storage and distribution of domain knowledge internally

and externally (Technical SME)

• Assess patterns and trends within their knowledge domain

• Work closely with coaches, product management and development

• Quality review, standards, workflow, procedures, policy.

• Knowledge Domain (Virtual Collection of Articles)

• Interface with other domain experts , Business Service Owners, IT Service Owners and

IT Support Owners to create holistic solutions from multiple interfaces, dependencies

and services.

Knowledge Process Manager/ Coordinator

The Knowledge Manager, Coordinator, has the overall responsibility for the health of the knowledge management practice. The Knowledge Manager leads the KCS Council and

works closely with the KCS Coaches, Knowledge Domain Experts (Implemented as part of

Phase 2), and management. The Knowledge Manager is responsible for:

• Knowledge base quality including the knowledge monitoring process, content

standards, and knowledge management processes.


Description





• Promoting KCS I to a KCS II and KCS II to KCS III based on the recommendation of

the KCS Coach

• Monitoring the progress of the KCS Coaches,

• Development and analysis of reports on metrics related to the knowledge management

initiative,

• Monitoring processes, resources, and technology—making recommendations to

management,

• Recommending and implementing adjustments, and rollout and Improvement

initiatives,

• Ensuring the appropriate resources are in place to Administer and configure technology,

• Defining and managing the visibility matrix,

• Involved with Vendor relations for the Knowledge toolset,

• Define Knowledge Policy &Processes,

• Define and run Knowledge Reports & Monitors,

• Branding & Marketing Knowledge Management throughout the organisation,

• Organising & Facilitation of informal Training and formal Certification,

• Ensuring that new staff induction programmes include knowledge management criteria,

• Provide Governance framework for Knowledge by establishing the KCS Council,

• Process Maturity Measurement & benchmarking.

KCS Adoption Team

Adoption Team Strategic and Design Roles KCS Exec Sponsor • To define the Vision of what success looks like,

• Define Objectives and requirements,

• Set priorities and timeframes,

• Provide resources and funding, support and endorsement,

• Communicate and Influence the Organization to adopt KCS.

KCS Program Manager • Champion KCS,

• Evangelize the KCS Practices,

• Co-coordinator of the Adoption Team,

• Help foster a sense of ownership and accountability for KCS with the directors, and

managers who lead the support teams,

• To plan and execute the Adoption of KCS using Project Methods,

• To define deliverables and milestones,

• To define stakeholders,

• To provide comms on the project progress,

• To alert the Exec Sponsor of any constraints and propose mitigation strategies.


Description





IT Liaison The IT Liaison is responsible for the technology requirements which includes;

• Infrastructure capabilities and response times,

• Tool functionality,

• The integration of applications,

• The user interface, and,

• Reporting requirements.

Web Liaison • The Web Liaison is responsible for ensuring the organization's website's standards and

protocol is included in the content standard.

Adoption Team Transition and Operation Roles • KNOWLEDGE DEVELOPERS—Support Analyst are the knowledge developers.

o KCS Candidate - basic user of the knowledge base, familiar with capturing and

o searching techniques and the basic concepts of KCS.

o KCS Contributor - creates, modifies, and reviews KCS articles for publishing to a defined audience. Usually internal users only.

o KCS Publisher - empowered to publish to an external audience.

• KCS COACHES—change agent and KCS practice expert who supports the

development of the KCS competencies and the proficiency development of KCS staff

from KCS Candidate to KCS Publisher. Generally, an analyst working part time as a Coach.

• KNOWLEDGE DOMAIN EXPERTS—responsible for identifying Evolve Loop content

based on KCS articles created in the Solve Loop workflow, looks after the health of the

knowledge base, usually focused on a collection or domain of content, has both

technical expertise in the domain and profound understanding of KCS processes.

KCS Council • The KCS Council is a cross functional group with global representation to tune the KCS

process to the organizational experience.

• The KCS Council provides the forum for continuous improvement to the content

standard, the workflow, tool functionality and integration, and the feedback and reporting systems.

• Attend a bi-weekly meeting to discuss issues and improvements.

• The council includes the KCS Coaches, the Knowledge Domain Experts, and

representatives from management.


Description





Business Service Owner

• The Business Owner of the business service supported by IT.

• Provides input to assist in the improvement of Knowledge Capture.

• Ensures that knowledge is captured as part of the Strategy and Design phase of the

business service.

• Coordinates resources to assist in the building of functional knowledge of specific

domains.

• Allocates resources to audit and vet knowledge published on the web for partners or

customers.

IT Service Owner • The IT Service Owner of the technology and/or systems that support and deliver the

business service.

• Ensure that knowledge is captured and improved for underlying IT Services as part of

the Transition and Operational phases.

• Coordinates resources to build domain based technical knowledge and schedule time

to improve the knowledgebase health.

Team Leaders (Senior Support Analysts)

• Schedule knowledge management time for their team members.

• Ensure that KCS Coaches are allocated extra time to perform their additional

knowledge duties like reporting, quality checks, training and coaching.

• Participate in the knowledge management process when required to provide support

(eg: Take calls off the queue and manage escalations).

• Ensure that knowledge KPIs and targets are met.

• Daily review of team and individual knowledge statistics.

• Identify and rectify breaches of the Knowledge Management Process.

• Conduct one on one meetings with support analysts to review knowledge metrics.

Managers • Ensure knowledge management process adherence.

• Monitor KPIs and metrics daily, weekly, monthly and quarterly (As specified above),

early detection and rectifications of knowledge process breaches.

• Ensure sufficient succession planning for key knowledge management roles in their

teams.

• Providing the required leadership and support to help entrench and improve the

knowledge management process.

• Provide required funding, training and tools to enable the knowledge management

process requirements.

• Management of Knowledge Process Breaches.

• Ensure that Knowledge KPIs are included in individual performance appraisals.


2.4.1. Content Standards Guide

A content standard sets expectations for Analysts by defining specific components that

enable consistency and high quality Knowledge. A good content standard defines the

content structure and purpose of each required field, the quality criteria for a good KCS

article and the visibility of the Knowledge.

Specific elements to look for in a good content standard are:

• Quick Reference Guide: documents the KCS article quality criteria in a one-page

sheet that can be kept on the Analyst’s desk.

• KCS Article Structure Definitions: list of basic elements with definitions including

problem, resolution, cause and metadata.

• Good & Bad KCS article examples: measured against the criteria specified in the

content standard.

• Metadata Definitions: what metadata should be set and how they should be used.

• Article Life Cycle States: as defined in the section ‘Knowledge Article Life Cycle’.

• Visibility Matrix: which role can view what Knowledge Article.

• Templates: list of templates available and directions for completing them.

• Vocabulary: preferred terms for the potential audience level of expertise, product

names, releases & versions etc.

3. When to use this Process The DoE Knowledge Management process must be used (within a team that has adopted

KCS) when:

• A Level 1 Support Analyst raises an Incident within the ITSM Toolset. Typically, the

Support Analyst would search for existing knowledge and use the KA if suitable. As

well, they perform other quality activities such as rate the article or request an update

if it needs updating.

• If there is no suitable Knowledge Article, the Support Analyst would typically ‘frame’ a

new Knowledge Article (AKA – WIP), which can be promoted at that point, or reviewed

and promoted at a later point in time in accordance with the KCS process.

• A Level 2 or Level 3 Support Analyst will typically review Knowledge Articles that are

linked within an Incident by the Level 1 Support Analyst. Typically, they will launch the

Knowledge Article from within the ITSM Toolset and perform more quality activities.

They may also complete an incomplete ‘framed’ article and promote it to a more trusted


status or set it to a “Cancelled” status where a duplicate article has been validated as

existing.

3.1. Process Triggers The process is triggered through the following means:

3.1.1. Incident being logged in ITSM Toolset Where an incident is logged within the ITSM Toolset, the Knowledge Management process

is triggered by searching for related Knowledge. In the event that no existing Knowledge

is found, a Knowledge Article is created from the resolved Incident

3.1.2. Level 2 and Level 3 Support Teams Where a Knowledge Article is linked to an Incident and assigned to a Level 2 or 3 support

team, these teams will interact with Knowledge to elevate its effectiveness for future use.

3.2. Knowledge Process Support Model The following support model illustrates a high level workflow of how Incident and Knowledge

integrate within a common workflow:

Article found?

Create incident

Search knowledge base

Research or escalate

Solve it

Add itFlag it/ fix it

Article correct?

Use it

Close incident

No

Yes

No

Yes

Key elements of the model include:

• Create an Incident

• Search for Knowledge

• If Article found and it is correct use it and close Incident

• If Article found, however it needs updating, fix it or flag it for an update


• If Article not found, one is created and either completed by the same person or

escalated as part of the incident for Level 2 support to resolve the Incident and

complete the Knowledge solution

3.2.1. Knowledge Escalation Knowledge Articles can be escalated from within an Incident or can also be escalated

independently through the support chain. Types of Knowledge Articles that would escalate

through the support chain Include:

• Framed Knowledge Articles pending a solution

• Procedural based Knowledge Articles where multiple teams participate in the

resolution or fulfilment

• Flagged (for review) Knowledge Articles where the proposed solution needs

updating, possibly because the solution was not effective

3.2.2. Governing Metrics

Capturing meaningful metrics will assist in assessing the participation in Knowledge, the

maturity of the Knowledge process and the quality of Knowledge.

The below measurements are meaningful when measured to assess the Knowledge

effectiveness of both teams and individuals within each team.

Key metrics to be captured in the Solve Loop of the process include:

• Participation – All support analysts who provide support should participate in the

Knowledge process. Participating with the Knowledge process can include activities

such as rating, requesting reviews or creating a Knowledge Article.

• Search Early Search Often – Search the Knowledge base at least once for every call

that is received (incident, service request etc). The total searches should be equal to

or greater than the total number of new call records.

• Capture in the workflow – this relates to the number of ‘framed’ Knowledge Articles in

relation to Incidents or Requests raised via the ITSM Toolset where a Knowledge

Article did not exist.

• Just-in-Time Solution Quality:

• Use it – Use Knowledge when resolving call records. The measurement can be the

number of closed records with a Knowledge Article linked

• Fix it – Knowledge articles that have been modified with the purpose of improving

them.


• Flag it – These are the Knowledge Articles where there has been a request for an

update due to a lack of skill or capability by an individual. The number of ‘flagged’

Knowledge Articles should be presented along-side the number of Incidents that were

unable to be resolved at first point. o Add it – If after searching there is no Knowledge that is suitable, adding a

Knowledge Article by creating it within the ITSM Toolset is an activity that is

desirable and should also be measured. This measurement should be in

conjunction with the number of Incidents resolved that could not be matched

up with an existing Knowledge Article o Rate it – Rating the quality of each Knowledge Article as you use it is a high

value and very low overhead activity. This measurement can be used in

conjunction with the number of Knowledge Articles linked to a record within

the ITSM Toolset.

Key metrics to be captured in the Evolve Loop of the process include:

• Promoting WIP Knowledge Articles to Draft or Published – The best

measurement would be in relation to the low % of WiP Articles expressed as a

percentage of the overall Knowledge Base owned by the team

• Removing Duplicates – Having duplicate Knowledge Articles increases the risk of

one of the two being dated. It is best for the duplicates to be merged into one article

or one of the two to be retired. This measurement can be expressed as the number

of duplicates expressed as a percentage of the overall Knowledge Base for that

team.

• Process Flagged for Review Knowledge Articles – Each team should endeavour

to action the ‘flagged for review’ Knowledge Articles in a timely manner so that the

article’s quality increases in time for when the next support analyst needs to use it.

Appropriate measurements would be the aging of ‘flagged’ Knowledge Articles as

well as the number of ‘flagged’ Knowledge Articles expressed as a % of the overall

Knowledge Base for that team

• Retiring Unused Knowledge Articles – The more redundant Knowledge Articles

that exist within a team’s Knowledge Base, the higher the probability that their

searches will be cluttered unnecessarily. A good measurement of the team

effectiveness in regards to retirement should be related to the number of Knowledge

Articles that have not been used for over 12 months

• Rectify Poor Ratings/Fixing highly viewed and poorly rated Knowledge Articles – Reviewing articles where support analysts have rated poorly, especially

the ones that have high view counts is a very valuable activity. Articles that are


rated 2 (poor) or 1 (redundant) should form a very small percentage of the overall

Knowledge Base of a particular team.

Knowledge Management - education.nsw.gov.au · knowledge management framework called Knowledge...

Documents

Transcript of Knowledge Management - education.nsw.gov.au · knowledge management framework called Knowledge...