Knowledge management

Process

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 department's 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.

The intended audience are those stakeholders throughout the department 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 Service Management Office (SMO) glossary for managing services.

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.

1.1. Process overview

This process document articulates the why and what practices are required for the department’s Knowledge Management Process to operate. Detailed procedures and work instructions describing how to apply this process are available within the SMO portal and Remedy knowledge base.

The department 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 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.

KCS is a methodology for capturing, authoring, refining, and publishing information that is relevant to the support processes for the department. 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 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. The department’s 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 process should align with the globally recognised Knowledge Management Framework called 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 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 process should be formalised, documented, approved, published, reviewed and updated.
  • The 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 process should clearly state the critical success factors, risks, issues, KPIs and metrics required to measure successful knowledge outcomes.

1.5. Process objectives

The objectives of the 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 within the department.
  • To enable the eservices strategy to provide customers with self-service and self-management capability.
  • To improve incident management core metrics:
    • time to resolution
    • first point resolution.
  • Aid the reduction of errors in the infrastructure, due to root cause removal.
  • Improve service request management core metrics that show end-to-end efficiencies in the time to:
    • locate and submit a request
    • approve a request
    • fulfil a request
  • Optimise resources by reducing re-work and improve efficiency of support teams.
  • Improve the customer experience via reduced resolution times, improved quality and consistence levels of service.
  • Reduce resource single point sensitivity, encourage knowledge sharing and collaboration.
  • Reduce re-work by leveraging organisational experience.
  • 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).
  • Reduce the time to productivity of new staff members across the department.
  • Enable customers to self-help where appropriate to do so.

1.6. Scope

The scope of this process includes:

  • Support teams that resolve incidents and fulfil requests. These teams can now leverage knowledge to the benefit of their team members and supported customers.
  • Support teams that leverage knowledge to support other established processes, such as problem management, change management and service request management.
  • Support teams that leverage KCS as the knowledge management standard
  • End customers at various customer sites that choose to consume knowledge through the self-service portal.

1.6.1. Service requests escalated to department suppliers

Requests directed to department suppliers must be managed in accordance with the KCS process. Where support is provided by a supplier and related to services underpinning the department’s production environment, then requests must be:

  • updated and resolved by the supplier interacting with KCS: if access is available to Remedy knowledge management.

The department’s ITD service and support functions shall integrate the KM process as a core activity to deliver and support departmental 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 the department.
  • Support workflows, interfacing processes, procedures and work instructions.
  • Team and Individual roles and responsibilities.
  • Performance assessment and measurements systems.
  • Business Intelligence systems (monitors, dashboards and reports).

2.1. Single process standard

A single Knowledge Management Process will be used to manage support of the Incident and other relevant ITI processes. The single Knowledge Management Process will leverage the KCS methodology.

2.2. Process ownership

The process is owned by the ITD Service Management Office, who is functionally accountable for the process, referred to as the ‘process owner’. 

2.3. Knowledge Centred Support process design

KCS is a double loop process:

Solve

The right hand side being the operational/support or ‘solve’ side which are the activities support staff at DoE perform to solve problems

Evolve

The left hand side being the proactive or ‘evolve’ side. These ensure the support side functions optimally.

Refer to the KCS Process diagram (JPG, 168KB) for further information.

Key practices 

There are 4 key practices that make up the solve loop and evolve loop:

The solve loop (A loop) is based on operational activities, drive 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 it’s 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:

  1. Reviewing and improving the KCS workflow.
  2. How knowledge evolves, article lifecycles, content standards, quality measures and metrics.
  3. Performance assessment.
  4. Leadership.

2.3.1. Knowledge article lifecycle

The knowledge article lifecycle 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.

Refer to the knowledge article lifecycle diagram (JPG, 43KB) for further information.

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
  • environment details.

A WIP article is sometimes referred to as a “framed” article. WIPs are temporary in nature and should move through to draft 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 may lack:

  • structure or content due to lack of customer feedback
  • other support analysts validation through reuse
  • may not fully comply with the content standard.
Approved

The KCS article is considered complete and reusable. 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 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 knowledge base, but they do not display in the search results within the daily support workflow.

Cancelled

The knowledge base is cancelled before the approval state. This can be due to the customer cancelling the incident before a resolution is known.

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.

Please refer to the knowledge article rating page for further information.  

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

Refer to the Knowledge Management process Stakeholder page for further information.

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 and 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 lifecycle states: as defined in the section ‘knowledge article lifecycle’.
  • 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 and versions etc.

The ITD knowledge management process must be used (within a team that has adopted KCS) when:

  • A level 1 support analyst raises an Incident within remedy. Typically, the support analyst would search for existing knowledge and use the knowledge article (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, 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 remedy and perform more quality activities. They may also may complete an incomplete ‘framed’ article and promote it to a more trusted status.

3.1. Process triggers

The process is triggered through the following means:

3.1.1. Incident being logged in remedy

Where an incident is logged in remedy, 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

Refer to the knowledge process support model for further information.

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 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 remedy incidents or requests raised 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.
  • Add it
    If after searching there is no knowledge that is suitable, adding a knowledge article by creating within remedy 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.
  • 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 linked knowledge article to a remedy record.

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.

Print version for process knowledge management (PDF, 268KB).

Procedure

To document the procedures required to execute, manage and govern the department's Knowledge Management Process.

The intended audience are those stakeholders throughout the department that have a role to play in this 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 procedure document inherits the definitions contained in the SMO glossary for managing services.

1.1. Procedure and overview

This procedure document articulates by what means the department’s Knowledge Management Process will operate. It describes where, who and when activities will be managed through the process lifecycle. Detailed work instructions describing how to execute this process are available within the SMO portal and Remedy knowledge base.

1.2. Procedures overview

The KM process, together with the Remedy KM technology, underpins how knowledge and incident procedures integrate with benefit to the departments supported customers.

The KM process supports the ITD adoption and standardisation on the industry best practice Knowledge Centered Support (KCS) process framework. This framework gives the necessary standard foundations to search, view, use or add knowledge as a by-product of the established support process.

There are 4 key concepts of the KCS which are:

  • Create ‘just-in-time’ content as a by-product of solving problems.
  • Evolve content based on demand and usage.
  • Develop a Knowledge Base (KB) of the organisation’s collective experience to-date.
  • Reward learning, collaboration, sharing and improving.

The process consists of the following two loops which are known as the ‘solve’ and ‘evolve’ loops.  The right loop which is the ‘solve’ loop relates to the support activities in relation to both incidents and service requests and the left loop which is the ‘evolve’ loop relates to the proactive activities that are periodically conducted to ensure that the ‘Solve’ side maximises in value

Refer to the KCS Process diagram (JPG, 168KB) for further information.  

Capture

  • Capture in the moment
    • Real time, capture and share
    • Just in time, not just in case
  • Capture in the context
    • Seek to understand, not solve
    • Customer’s words and experiences
  • Capture relevant content
    • Relevant information
    • Distinguishing information
  • Capture knowledge as it becomes explicit

1.2.2. Structure

  • Keep it simple
    • Consistent, crisp and simple
    • Improved readability
    • Quick and clear instructions
    • Information to act on
  • Complete thoughts, not complete sentences
    • Not word for word (makes searching for knowledge less targeted)
    • Short and succinct
    • Driven by leading questions

1.2.3. Reuse

  • Search early, search often
    • Search the KB before solving
    • Real time during problem solving
  • Seek to understand what we collectively know
    • Leverage off others experiences (captured in the KB)
  • Search words are candidate knowledge
    • The search becomes a KA
    • Highlights opportunity for KA linking

1.2.4. Improve

  • Reuse is review
    • Knowledge validated by use
    • Re-use indicates value in the KA
    • If not in KB, we don’t know about it
  • Flag it or fix it
    • If you cannot fix it, flag it for someone else to fix it
    • If you can fix it, fix it
    • The KB is everyone’s responsibility involved in the support process
  • Licence to modify
    • Licence model drives trust
    • Licences linked to capability

1.2.5. Content health, process integration, performance assessment, leadership and communication

These are the ‘evolve’ loop activities and all aim at having great content health in order to enhance the use of Knowledge throughout the support process. Key activities within the evolve side of the process are:

  • Moving ‘framed’ (very basic or incomplete KA’s) to more trusted states, such as draft and published.
  • Reviewing ‘in review’, also known as ‘flagged’ KA’s and following the review of the KA, then placing it in an appropriate status, such as draft, published, or if it is obsolete knowledge that is no longer of benefit, retiring the KA.
  • Search for duplicates.
  • Using existing knowledge reports and data extracts to give you visibility of focus areas.
  • Ensure that the knowledge procedures integrate seamlessly with other process/procedures such as incident.
  • Communicate to your team regarding opportunities and where possible communicate through the Remedy tool by performing activities such as ‘assigning’ KA’s to others that can further enhance the knowledge for future use.

1.3. Key process interfaces

The main interfaces between knowledge management and other SMO information technology service management processes are:

1.3.1. Incident management

Triggers Knowledge Management Process through the core principles of use it, fix it, flag it, add it.

Staff must first seek to find and use an existing knowledge article before they seek to solve the issue and create a new knowledge article. Seeking and finding existing, known articles will increase the consistency of resolutions and workarounds, decrease downtime for the organization, and decrease overall support costs.

If the knowledge article is incorrect or could be improved, staff must take ownership for the improvement. If they have the rights to modify the article, they are responsible to fix it (update the knowledge article). If they do not have the rights to modify the knowledge article, they must flag it. As part of flag it, they are also responsible for commenting on the article (including the reason why it was flagged). Someone who has the authority to fix it completes the knowledge article modification.

If they do not find an existing knowledge article, then they should continue to follow the steps in the incident (request, event) process: investigate, diagnose, resolve, and recover. Once the resolution (or workaround) has been identified, they add the new knowledge article so it is available for others to reuse.

1.3.2. Service request management

The highest volume of contacts for most service desks is requests—providing advice or guidance—and KCS enhances the processes used by the service desk to document, track, and understand the type of work generated by requests. These requests can be for common, repetitive questions, business process advice, or questions on standard operating procedures (SOPs).

KCS supports request management processes by making relevant knowledge articles available through self-service, which enables users to better manage their time and achieve their goals by removing assisted support as a step in the path toward accomplishing their tasks.

1.3.3. Problem management

Problem management trending and analysis is often constrained by the quality of the incident records. With KCS, trend analysis shifts from incident classification to the reuse of knowledge articles, as each article is linked to the incidents that were closed using that article. In a typical enterprise organization (without KCS), trend analysis involves analysing the classification structure within the incident record, which often isn’t appropriate for either incident or problem reporting.

The result is that analysing incident records can be a complex task, and too often the classification data is inaccurate or incomplete for the needs of problem management. Knowledge article reuse can increase the efficiency and effectiveness of trend analysis, allowing problem management to spend more time identifying root causes, developing fixes and preparing changes.

2.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 a customer Incident or complete a customer Service Request

2.1.1. Work in progress – also known as a ‘Framed’ knowledge articles

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 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
  • Other support analyst’s validation through reuse, or may not fully comply with the content standard
Approved

The KCS article is considered complete and reusable. 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 they are visible to, and we 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 knowledge base, but they do not display in the search results within the daily support workflow.

Cancelled

The knowledge base is cancelled before the approval state. This can be due to the customer cancelling the incident before a resolution is known.

2.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.

Please refer to the knowledge article ratings page for further information.

2.3. Licenced based roles

  • Day- to-day operational management of the process
  • End-to-end governance oversight across the ‘evolve’ Cycle

Please refer to knowledge management process stakeholders for further information.

2.4. KCS user development cycle

KCS1 moves into a KCS2 role and then into KCS3. The higher the KCS number the more activities can be performed in relation to Knowledge Articles. KCS coaches have a people focus, and a knowledge domain expert have full access to edit knowledge articles, however only in relation to pre-defined areas of expertise.

Refer to the KCS user development cycle diagram (JPG, 104KB) for further information.

The procedures used to drive the use of knowledge are broken into 2 main areas:

3.1. Level 1 incident management

You will find a detailed description of each step and illustrates the activities that run parallel between the Incident Management process (L1) and the supporting activities of Knowledge.

Refer to the incident management level 1 workflow/activities (DOCX, 113KB) and knowledge management activity descriptions for further information.

3.2. Level 2/3 knowledge management – high level activity descriptions

Refer to the knowledge management level 2/3 activity descriptions (DOCX, 148KB) and knowledge management activity descriptions for further information.

3.3. Knowledge management review and modification procedure (V0.2)

Refer to the knowledge management review (DOCX, 78KB) and knowledge management activity descriptions for further information.

3.4. Publishing context to external customers through the self-service portal

Just like any other part of the process, the below process relating to publishing content to end customers is subject to frequent reviews and improvements to the process as required.

It is vital that the content that is published to customers is of the highest quality in terms of the structure, the language used and also the answers it provides.

Interim ‘day 1’ process guiding principles:

  • SMO process owner visibility of all KAs being published to customers.
  • Single point of approval checkpoint for each of IDT, P&S and SS.
  • All content is published by the SMO process owner once approving manager & team communication manager have approved the publishing of the knowledge article.
  • Ongoing process to be reviewed by the SMO process owner in consultation with the knowledge community.
  • Identification & engagement of all process stakeholders to take place well before ‘day 1’.

Refer to interim day 1 process (DOCX, 70KB) for further information.  

4.1. KPI and measures

Refer to knowledge management KPI and measures for further information.

4.2. Reporting

Refer to the current endorsed knowledge process reporting specification document for detailed information on measurement and reporting requirements.

Return to top of page Back to top