knowledge management - education.nsw.gov.au · knowledge management framework called knowledge...
TRANSCRIPT
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
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
NSW DoE | IT Commercial & Services | Process – Knowledge Management 2 | P a g e
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
NSW DoE | IT Commercial & Services | Process – Knowledge Management 3 | P a g e
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
NSW DoE | IT Commercial & Services | Process – Knowledge Management 4 | P a g e
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;
NSW DoE | IT Commercial & Services | Process – Knowledge Management 5 | P a g e
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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 6 | P a g e
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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 7 | P a g e
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
NSW DoE | IT Commercial & Services | Process – Knowledge Management 8 | P a g e
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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 9 | P a g e
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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 10 | P a g e
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 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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 11 | P a g e
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
• 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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 12 | P a g e
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
• 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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 13 | P a g e
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
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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 14 | P a g e
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
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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 15 | P a g e
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
NSW DoE | IT Commercial & Services | Process – Knowledge Management 16 | P a g e
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
NSW DoE | IT Commercial & Services | Process – Knowledge Management 17 | P a g e
• 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.
NSW DoE | IT Commercial & Services | Process – Knowledge Management 18 | P a g e
• 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
NSW DoE | IT Commercial & Services | Process – Knowledge Management 19 | P a g e
rated 2 (poor) or 1 (redundant) should form a very small percentage of the overall
Knowledge Base of a particular team.