HCL RF GBP Knowledge Management Process - v1.0 - New

HCL Technologies
HCL Gold Blue Print Process

KnowledgeManagement Process
HCL Technologies Limited (Confidential)
HCL Gold Blue Print Knowledge Management Process
Date of Release: October 28
th
, 2013
Version: 1.0

Page 2

COPYRIGHT HCL Technologies Limited, 806, Siddharth, 96 Nehru Place, New Delhi, 110019.

This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or
reduced to any electronic medium or machine-readable form without prior consent in writing from
HCL Technologies. Every effort has been made to ensure the accuracy of this document. However,
HCL Technologies makes no warranties with respect to this document and disclaims any implied
warranties of merchantability and fitness for a particular purpose. HCL Technologies shall not be
liable for any error or for incidental or consequential damages in connection with the furnishing,
performance, or use of this document or examples herein. The information in this document is
subject to change without notice.

th
, 2013
Version: 1.0

Page 3

Table of Content
1 POLICIES CONFIGURED FOR REMEDYFORCE ......................................................................................................... 4
1.1 KNOWLEDGE ARTICLE AUTO REJECTION POLICY ...................................................................................................................... 4
1.2 KNOWLEDGE ARTICLE DEACTIVATION POLICY........................................................................................................................... 4
1.3 KNOWLEDGE ARTICLE REVIEW POLICY ....................................................................................................................................... 4
1.4 KNOWLEDGE ARTICLE VIEWERSHIP POLICY .............................................................................................................................. 4
1.5 KNOWLEDGE ARTICLE SEARCH AND RELATE POLICY ................................................................................................................ 4
1.6 KNOWLEDGE ARTICLE PUBLISHING POLICY ................................................................................................................................ 5
2 KNOWLEDGE CONSOLE IN REMEDYFORCE ............................................................................................................. 5
2.1 NEW KNOWLEDGE ARTICLE CREATION ...................................................................................................................................... 5
2.2 ARTICLE TYPES ................................................................................................................................................................................ 7
3 ARTICLE CREATION STEPS ........................................................................................................................................... 9
3.1 BUILD APPROVAL PROCESS ......................................................................................................................................................... 10
3.2 EDITORIAL REVIEW PROCESS ..................................................................................................................................................... 10
3.3 PUBLISHED ..................................................................................................................................................................................... 11
4 CATEGORIES AND SUB-CATEGORY VALUES ........................................................................................................ 11
5 POST CREATION OF KNOWLEDGE ARTICLE ........................................................................................................ 15
5.1 RELATED LISTS .............................................................................................................................................................................. 16
6 INTERFACES WITH OTHER CONSOLES/OBJECTS .............................................................................................. 17
6.1 INTERFACE WITH INCIDENT CONSOLE ....................................................................................................................................... 17
6.1.1 Referring or Resolving any Incident through Knowledge Articles................................................................... 17
6.1.2 Proposing any Knowledge article through Incident Console ............................................................................. 18
6.2 INTERFACES WITH PROBLEM MANAGEMENT........................................................................................................................... 19
6.2.1 Referring any Problem through Knowledge Article .............................................................................................. 19
6.2.2 Proposing any Knowledge article through Problem Console ............................................................................ 19
6.2.3 Status Dependency with Problem Management ..................................................................................................... 23
6.3 INTERFACES WITH CHANGE MANAGEMENT ............................................................................................................................. 25
7 STATUS TRANSITIONS ................................................................................................................................................ 25
7.1 BUTTONS IN KNOWLEDGE CONSOLE .......................................................................................................................................... 27
8 NOTIFICATIONS, AUDIT AND REPORTING ........................................................................................................... 29
8.1 NOTIFICATIONS ............................................................................................................................................................................. 29
8.2 ATTACHMENT AND DOWNLOAD OPTION .................................................................................................................................. 30
8.3 ROLES AND PERMISSIONS ............................................................................................................................................................ 31
8.4 KNOWLEDGE FEEDBACK AND RATING ...................................................................................................................................... 32
8.4.1 Through Self Service console .......................................................................................................................................... 32
8.4.2 Through Global search option ........................................................................................................................................ 32
8.4.3 From Other Consoles .......................................................................................................................................................... 32
9 REPORTING ..................................................................................................................................................................... 33
th
, 2013
Version: 1.0

Page 4

1 POLICIES CONFIGURED FOR REMEDYFORCE
1.1 Knowledge Article Auto Rejection policy
If any article lies without approval at Build stage for more than 30 calendar days then it would get
Auto Rejected automatically. A reminder e-mail notifying the pending approval of an article would
be triggered to the approver reminding him/her about the status of the article. If not approved for
30 calendar days, the final status for Knowledge article would be Closed- Auto Rejected
1.2 Knowledge Article deactivation policy
Validity of any Knowledge article would by default set for 15 months from the date of publication of
article, after which the article would be Closed Validity Expired. However, before the validity of
any article expires, both the Builder and KM group would be notified, so that the validity of the
article could be extended, in case required. If no response would be received and the current date
exceeds the validity date then the status of the article would be Closed Validity expired, the
article then would not be available in Knowledge base
1.3 Knowledge Article review policy
Any knowledge article created in the environment would require an approval by the Builder from
technical standpoint and then the Knowledge editor/manager from linguistic, Intellectual Property
and overall details point of view for a chosen category & sub-category. However, if any Knowledge
article would be triggered from Problem Management console, then it would only require an
approval from Knowledge Manager before it moves to Published status since it would open up in
Editorial Review status only and bypass Builder approval.
1.4 Knowledge Article Viewership policy
1. Any Knowledge article once created would be viewed by all the users, while viewing an article
the users would be having an option to provide a rating and feedback to an article
2. The final rights to decide the target audience of an article would be with the Knowledge
Manager/Knowledge Management Group.
1.5 Knowledge Article search and relate policy
1. A knowledge article could be searched and related from Incident Management, Problem
Management and Change Management consoles in the tool
2. Any knowledge article could be searched on the basis of the tagged information/Keywords or
summary provided in the article
3. Articles in Published status would only be available for search and can be related with any
Incident, Problem and Change tickets respectively
th
, 2013
Version: 1.0

Page 5

1.6 Knowledge Article publishing policy
1. A knowledge article would only be published by any member of the Knowledge Management
group; the article would be in Editorial Review status before it gets Published.
2. Before publishing, a knowledge article would be checked for linguistic errors, IP & copyrights
conflicts, appropriate tags, tiers selection and the overall technical relevance of an article with
respect to its subject.
2 KNOWLEDGE CONSOLE IN REMEDYFORCE
Clicking on Knowledge Article tab would take the user to a new window which would show a
list of recently viewed Knowledge articles with default fields of a Knowledge article as shown
below. These would be admin level configurable fields which once configured would be visible
to all irrespective of their level of access.
Knowledge ID
Article type
Category
Sub-Category
Short Description
Status

Besides this, the features that would be available on Knowledge page are given below:
1. An option would be available on the main pageto check Recently viewed/Recently
modified/Recently created articles.
2. A global search option which would bring the search result from all the available objects
based on the short description.
3. There would be an option available with the support users to create their own new view of
Knowledge articles according to the Article type, category, sub-category etc.
2.1 New Knowledge Article creation
All support users can login into the console and create a new knowledge article by clicking on New
button which would redirect the user to a page comprising of a pick list asking to fill the Article
type, this page would also have the details of each article type to guide the user, selecting any
article type would then redirect the user to the Knowledge form comprising following features:
1. There would be certain fields which would be mandatory to fill, while submitting a
Knowledge article and would be marked in Red
2. The assignment group field would be defaulted as Knowledge Management Group and would
be read only
3. Some fields would be optional for which the information may/may not be provided by the
contributor
th
, 2013
Version: 1.0

Page 6

4. Knowledge article form would consist of below fields:
Field Field Description Mandatory(Yes/No)
Category Concerned Technology based categorization would be
done for all the Knowledge Articles
Yes
Sub Category Concerned Technology based sub categorization would be
done for all Knowledge Articles and this would be
dependent upon the category field
Yes
Short
Description
Provides a brief description about the Knowledge Article
being created
Yes
Status This field depicts the information about Status of an
article at any point of time during its lifecycle
No
Article Type This field provides the details of the nature of article
being created; there would be different layouts of
Knowledge form based on the input in this field.
NA
Assigned To This field defines the name of the person from Knowledge
Management group to which the article is assigned
No
Display in
Self- Service

This field defines whether the article should visible in the
Self-Service console whenever it has been searched
No
Subject* This field defines the subject of the article being created No

Symptom
Text*
This defines the symptoms of the issue for which the
Knowledge article is being created
No
Cause* This defines the cause of the issue for which the
Knowledge article is being created
No
Workaround
Text*
This defines the workaround given to any issue for which
the Knowledge article is being created
No
Associated
CI/Service
This fields defines the CI/Service name for which the
Knowledge article is opened
No
th
, 2013
Version: 1.0

Page 7

Keyword This field specifies the Keyword/Tag with which the
article would be denoted in order to improve its search
efficiency
No
Resolution
Notes*
This field defines the resolution given to any issue for
which the Knowledge article is created
No
Details* This field provides the complete details about the topic
for which the article is created
No
Available for
Group
This field would consist of the assignment group look up
to whom the editor would want the article to be visible, if
this field is left blank for an article then the article would
be visible to all
No
Question This field defines the information about the Question
when the article type is a FAQ
No
Answer This field defines the information about the Answer when
the article type is a FAQ
No
Initiator
Group
This field specifies the name of the initiator group as
specified by the contributor while submitting a
Knowledge Article(The user in created by field would be a
part of the group chosen in this field)
Yes
Note: *Visibility of these fields would vary based on the input given in Article Type field as
mentioned in section 2 of this document
2.2 Article Types
Every article in Knowledge Management Console has an Article Type associated with it; these
articles would be pre-defined in the console and depicts the nature of the article created.
Note: The mandatory fields mentioned in Section 2.1 would be available in all the article types
while some of the optional fields would be available depending upon the article type as described in
below table:
Article
Type
Description Exceptions Optional Fields
Available
General This type is used for the articles
which are not of any specific
category and consists of generic
information which would be helpful
NA Subject
Details
Cause
Workaround
th
, 2013
Version: 1.0

Page 8

to the user at any given point of time. Text
Resolution
Notes
FAQ This article type is used for the
articles which are referred
frequently and are helpful to resolve
any instant query
NA Question
Answer
Known
Error
This article type is used when the
workaround along-with the root
cause for any problem is identified
however the Permanent fix for it is
still pending or not known
NA Subject
Symptoms
Cause
Workaround
Text
Patch
review
This article categorically specifies the
details pertaining to any technology
update or details about any release
information
Attachment is
mandatory for this
article type
without which this
could not be
saved/submitted
for Build phase
Subject
Symptoms
Cause
Resolution
Notes
Process
and Policy
This article type is used for articles
consisting of information regarding
process and policies that applies to a
specific area, group or technology
NA Subject
Details
Technical
SOP
which consists of details about
leveraging any technology using
already defined procedures
NA Subject
Details
Technical
Tip
which defines best practices or
opinions about any support item
from technical standpoint
NA Subject
Details
Temporary
Fix
which gives the information about
workaround to a Problem but not its
root cause.
NA Subject
Symptoms
Cause
Workaround
Text
th
, 2013
Version: 1.0

Page 9

Permanent
Fix
which give the information about the
permanent resolution provided for
any issue along-with its root cause
NA Subject
Symptoms
Cause
Workaround
Text
Resolution
Notes
Error

which gives the information about
the root cause of any issue but has no
details of workaround or permanent
fix
NA Subject
Symptoms
Cause

3 ARTICLE CREATION STEPS
1. If a contributor wants to confirm if there is any duplicate article that exists for the current
article then he/she would click on search for duplicate button, the console would then open up
the entire duplicate articles available based on the information provided in Short description,
category and sub-category fields, this could be done even without submitting the article in the
console
2. Once a Search for Duplicate operation would be performed then a list of articles opens up that
are found to be duplicate of the information provided and the details including Knowledge ID,
Short description, Status , View Count and Use Count would be highlighted, this action could be
completed by the following ways :
a. If a contributor finds out that if an article already exists in the Knowledge base and is
showing up in the search results then he would click on Cancel Knowledge Article
button so as to maintain the consistency of records in the Knowledge base
b. However if a contributor finds out that no matching article exists in the Knowledge Base
then the user would proceed with the already created Knowledge record
3. An article could also be created from Incident, Problem and Change consoles, the details of
which are mentioned in section 4 of this document
4. Any article would be cancelled manually in Draft stage only. The status of Knowledge article in
this case would be Closed-Cancelled and the action history would also get updated
5. Any article would also be deleted permanently by tool at Build, Editorial Review and
Published status if it would be linked to any problem ticket and getting updated from the
problem ticket itself
6. The contributor before submitting the article to Build phase could restrict the visibility of a
Knowledge article by clicking on Available for Group button and choosing the groups to whom
the article should be visible, this button would be visible till Editorial Review phase of
Knowledge article lifecycle and access to it would depend on the status of the article
th
, 2013
Version: 1.0

Page 10

7. The contributor would click on Submit for Approval to move the article to next status for
approval and an email notification would be triggered to the assigned approver
3.1 Build Approval Process
1. Once the Knowledge article is submitted for build approval process, a notification would be
triggered to the approver based on the category and sub category chosen while submitting the
article
2. At this stage an assigned approver or any member of the Knowledge Management group would
be having the rights to edit the article
3. The approver would review the article from technical point of view and would be having the
rights to approve/reject it
4. An approver during build phase can approve a Knowledge article by the following ways:
An assigned approver can approve an article by going to the Self Service page and in
Manage Approvals section by clicking on approve/reject link against a Knowledge
article
An assigned approver can also approve an article by clicking on the link provided in the
automatically triggered mail notification from the tool to the approver, once clicked the
link would redirect the user to approve/reject page
An assigned approver can also approve/reject an article by opening a knowledge record
and going to the Approval History section of an article by clicking on approve/reject
link provided against the Knowledge ID
5. While rejecting the article it is mandatory for approver to provide rejection comments and the
status of article would move to Closed Rejected
6. Once approved the status of the article would change to Editorial review and would be
assigned to the Knowledge Management Group for review
7. An article apart from getting approved/ rejected could also be referred back to the contributor,
this could be done by mentioning the reason for referring back an article and would be
mandatory to fill, the status of the article once referred back would move from Build to Draft
8. A knowledge article not approved in build phase for more than 30 calendar days would get
Closed -Auto Rejected; a notification to this effect would be triggered during certain pre-
defined intervals mentioned in the Section 6.1 below
9. Category/Sub category, article type of any article can only be changed till Build status, once
approved it would freeze for any editing
3.2 Editorial Review Process
1. Once a Knowledge article would be approved at the build phase, an email would be sent to all
the members of the Knowledge Management group
2. Any member of the Knowledge Management group would be able to assign the article on his
name
th
, 2013
Version: 1.0

Page 11

3. A Knowledge manager in this phase would review an article from linguistic, IP and copyrights
point of view, an article would be reviewed for relevance and completeness of the information
provided into it
4. Any member of the Knowledge management group can publish a Knowledge article irrespective
of the person whose name is mentioned in the assigned to field
5. Knowledge Manager would publish this article using Publish button and then this article
would be available for use by target audience
3.3 Published
1. Once a Knowledge article is Published then, two buttons would be available to the Knowledge
Manager and Builder of that article namely Copy and Copy and Replace
2. Once a user clicks on Copy button then a new Knowledge article would be created and would
get related with the existing article in Linked Knowledge Articles related list, in this case the
existing or parent article would remain as-is while the new article thus created would be in
Draft stage, while all the data from the existing Knowledge article would be copied to the new
article with same Article Type value
3. Once a user clicks on Copy and Replace button then a new Knowledge article would be created
in Draft stage, however in this case the status/sub - status of the existing Knowledge article
would change to Closed Rejected as soon as the Copy and Replace button is clicked,while all
the data from the fields of existing Knowledge article would be copied to the new article with
same Article Type value. In this case no relation would be made in the related list of the
existing article or the new article
4. In both the cases as specified in points 2&3 above,the field mapping would take place between
all the fields based on the article type value as mentioned insection 2.2 of this document
Note That the layout of the new knowledge article created would be based on its Article Type
value, which would be same as that of the existing Knowledge Article
4 CATEGORIES AND SUB-CATEGORY VALUES
Below mentioned values would be mapped with the Category and Sub-category field.
Category Sub Category
Application Management Tools Not Applicable
Business Application Not Applicable
Cabling System Cabling System
Cluster Cluster
Communication and Collaboration Application Not Applicable
th
, 2013
Version: 1.0

Page 12

Data Link Data Link
Database DB2 Instance
Database MySQL Instance
Database Oracle Instance
Database SQL Server Instance
Database Sybase Instance
End User and Client Application Not Applicable
End User Asset Cell Phone
End User Asset Data cards
End User Asset Desktop
End User Asset Handheld tablet
End User Asset IP Phone
End User Asset Laptop
End User Asset Peripherals
End User Asset Smartphone
End User Asset VPN Access Token
ERP application Not Applicable
File System File System
Infrastructure Management Tools Not Applicable
IP address IP Address
Middleware Database Middleware
Middleware Message Oriented Middleware
Middleware Object Middleware
Middleware Portal
th
, 2013
Version: 1.0

Page 13

Middleware RPC Middleware
Middleware Transaction Middleware
Middleware Web server
Network & Zones DMZ
Network & Zones Public Network
Network & Zones Subnets
Network & Zones VLAN
Network & Zones VPN
Network and Zones DMZ
Network and Zones Public Network
Network and Zones Subnets
Network and Zones VLAN
Network and Zones VPN
Network Gear/Appliance Access Point
Network Gear/Appliance Firewall
Network Gear/Appliance IDS/IPS
Network Gear/Appliance Load Balancer
Network Gear/Appliance Router
Network Gear/Appliance Switch
Network Gear/Appliance UCS
Network Gear/Appliance VPN Concentrators
Peripheral System Multifunction Device
Peripheral System Network Printer
Peripheral System Scanner/Photocopier
th
, 2013
Version: 1.0

Page 14

Physical Server AS/400
Physical Server Linux Server
Physical Server Mac Server
Physical Server Mainframe
Physical Server Unix Server
Physical Server Virtual Machine Host
Physical Server Windows Server
Rack Rack
Service Business Service
Service Enabling IT
Service Management Applications Not Applicable
Software Email
Software OS
Storage Device LUN/NAS Client
Storage Device NAS
Storage Device SAN
Storage Device Storage Host
Storage Device Tape Library
System Software System Software
Virtual Server Linux Server
Virtual Server Mac Server
Virtual Server Unix Server
Virtual Server Windows Server

th
, 2013
Version: 1.0

Page 15

5 POST CREATION OF KNOWLEDGE ARTICLE
Once an article would be submitted by the contributor below are the fields that would be visible
and auto populated.
Field Name Description
Knowledge ID A unique number assigned to that particular article, this nomenclature would be
incremental in nature. Each unique number would be prefixed with KB.
Article Source

Would be filled only in case if the Knowledge article would be created through
any other console namely Incident, Problem or Change.
Created date Specifies the date when the Knowledge article is created.
Created By This would be populated with User ID who has created this article.
Last Modified
By
The support user who has last modified the article.
Work Info
Notes
This would consist of the details filled by the user at any point of time during the
Knowledge Article lifecycle

Following fields would be included as a part of article publication:
Field Description
Published
date
Specifies the date and time at which the article is published.
Valid till Specifies the date until when the article would be active and would remain in
Published status. As per policy it would be 15 months but it is configurable also
View Count This defines as to how many times the current article is reviewed and view count
would increase by 1 every time the article is viewed.
Use count This defines as to how many times any article is referred/ used and would increase
the use count by 1 every time an article is related to a ticket or if the user clicks on
Yes checkbox in Did this Article meet your Need field
Rating This field would show the average of all the rating given by the user, An article
could be rated between 1 to 5
th
, 2013
Version: 1.0

Page 16

Feedback This field would show the feedback given by the user, this field would be
mandatory to fill in case the user choses the rating value as Needs Update
Did this
Article meet
your Need
This would be a field which would increase the use count of an article when a Yes
checkbox is clicked on the Knowledge Feedback Page, this field would only be
visible when a person views an article

Following fields would be applicable as and when required
Field Description
Comments Specifies the information due to which the Knowledge article would
be rejected by the Builder or any other comments
Reason for Referring
back
Specifies the reason to refer back an article to the previous stage
Resolution through
Knowledge Article
Field which defines whether the resolution of any incident comes
through any knowledge article

5.1 Related Lists
Related List section would provide an option to check if there are any related tickets for this
particular Knowledge article, if found appropriate relationship can be defined between them.
Multiple relationships could be made between Knowledge article and incident, problem and change
tickets and the support user would be able to view all the relationships. Following are the kind of
relationship that may be used:
Type Details
Linked Problems Manual relationship with any Problem ticket can be made using Link with
Problem Ticket section in related list however if a knowledge article is
triggered directly from a Problem ticket the relationship would automatically
be created in this section
Linked Incident Any knowledge article proposed through Incident at the time of Incident
resolution would get linked automatically in related list section
Linked Change
Requests
Any Knowledge article proposed through Change request at the time of
closing the request would get linked automatically in related list section
th
, 2013
Version: 1.0

Page 17

Linked CIs There would be an option to relate CI with an existing Knowledge article; here
we can relate multiple CIs to a particular knowledge article
Linked
Knowledge
Articles
This would be used to relate any knowledge article with another one
Knowledge
Article Feedback
This would give the details of the Knowledge article Feedback provided for an
already Published article and would comprise of User, Rating, Comments,
Did this article meet your need? fields
Approval History This would have the details about the approval history of a Knowledge article
Knowledge
Action History
This would be having the details of all the actions taken on a Knowledge
Record
Knowledge
History
This would comprise of the details of all the fields on which the auditing is
enabled
6 INTERFACES WITH OTHER CONSOLES/OBJECTS
6.1 Interface with Incident console
6.1.1 Referring or Resolving any Incident through Knowledge Articles
1. The user can search for knowledge articles using Knowledge Search button on the incident
form. Search would be done based on the content in the Incident summary field and it
would search the entire Knowledge base for the related content else on the search page user
would be having an option to mention the content to be searched and search would be done
on the basis of mentioned content.
2. An article once clicked would have two options available with it namely Mark as Solution
and Mark as Attachment.
3. If the user clicks on Mark as Solution button, its workaround/Resolution Notes field
would be copied to the Resolution Notes of the incident ticket along with the hyperlink
ofthe same Knowledge article appended in the Resolution Notes field, also the Knowledge
ID of the article would get updated in Incident Work Info Notes and Assignee has to
manually update the Incident status to Resolved. The knowledge article in this case would
automatically get related with the incident and its View Count and Use count would
increase by 1, the field Resolution through a Knowledge Article check box in this case
would automatically get updated with the value as True otherwise the value of this field
would remain as False
4. If the user clicks on Mark as Attachment button, the Knowledge ID as well as article link
would be copied to the Work info field of the incident ticket and would be saved in the
th
, 2013
Version: 1.0

Page 18

Action history of the ticket. This option would be used in case user is referring the article for
knowledge purpose only and not resolution. Here View Count of the article would increase
by 1
The field mapping between Knowledge form and Incident form for various article typesin case of
Mark as Solution option would work as follows:
Article Type Knowledge Field Incident Field
Known Error Workaround Text Resolution Notes
Permanent Fix Resolution Notes Resolution Notes
Temporary Fix Workaround Text Resolution Notes
General Resolution Notes Resolution Notes
Patch Review Resolution Notes Resolution Notes
6.1.2 Proposing any Knowledge article through Incident Console
If the user thinks that there should be a new Knowledge article for the subjected incident then he or
she need to click on Propose a Knowledge article button at the time of Incident resolution. Upon
saving a new Knowledge form would pop up with some of the fields already pre populated from the
Incident Ticket and this new knowledge ID would be related with the existing incident in the
related list section. The status of the knowledge article thus created from incident console would be
Draft, however the Article Type may vary in accordance with the sub-status of the Incident at the
time of its resolution please refer the table below for more details
Incident Ticket Status Knowledge article
Status Sub-Status Status Article Type
Resolved Workaround Draft Known Error
Resolved Permanently Resolved Draft Permanent Fix
Resolved Working as Designed Draft General
Note: Propose a Knowledge Article option would only be available if the sub status of the incident
at the time of its resolution is
1. Workaround
2. Permanently Resolved
3. Working as Designed
Field mapping between the Incident Ticket and Knowledge form would work as follows:
th
, 2013
Version: 1.0

Page 19

Incident Form Knowledge Form
Category Category
Sub-category Sub-category
Summary Subject
Summary Short Description
Description Symptoms
Resolution Notes Workaround Text
Incident Number Article Source
Assigned To Created by
Affected CI/Service Affected CI/Service
Created By Created By

6.2 Interfaces with Problem Management
Knowledge Management shares a strong interface with Problem Management, the details are stated
below:
6.2.1 Referring any Problem through Knowledge Article
The user can search for knowledge articles using Knowledge search option Problem form. Search
would be done based on the content in the Problem summary field and it would search the entire
Knowledge base for the related content
An article once clicked would have an option to Mark as attachment. If the user clicks on Mark as
Attachment button, the Knowledge ID would be copied to the Work Info Notes of the problem
ticket and it would be saved in the Action history of the ticket. This option would be used in case
user is referring the article for knowledge purpose only and not resolution. Here View Count of the
article would increase by 1
The article would be linked in the Linked Knowledge Article list of the Problem form.
6.2.2 Proposing any Knowledge article through Problem Console
A new article would be triggered from Problem console when the Status/Sub-Status of the Problem
Ticket changes from

Under Investigation - Problem Investigation - Under Investigation Workaround
Identification

th
, 2013
Version: 1.0

Page 20

However knowledge article would keep on updating as the problem ticket proceeds with below
status/sub status:
From Status Sub Status To Status To Sub Status
Under Investigation Workaround
Identification
Under Investigation Solution Identification
Under Investigation Problem Investigation Under Investigation Solution Identification
Implementation Review Closed Successful

The Article type field of the article would vary based on status of the Problem Ticket please refer
section 6.2.3 below to find the appropriate Article Type value for a particular status.
6.2.2.1 Field Mapping From Problem Form

1. When the Sub - Status of a Problem Ticket would move from Problem Investigation to
Workaround Identification then the following fields from the Problem Ticket would be
mapped with the fields of New Knowledge Form
Problem Ticket Knowledge Form
Category Category
Summary Subject
Known Error Notes Cause
Problem Investigation Lead Created by
Problem Number Article source
Associated CI/Service Associated CI/Service

2. When the Sub - Status of a Problem Ticket would move from Workaround Identification to
Solution Identification then the following fields from the Problem Ticket would be mapped
with the fields of New Knowledge Form
Workaround Workaround Text
th
, 2013
Version: 1.0

Page 21

The following fields from the earlier related Knowledge form would be mapped with the fields of
New Knowledge Form
Previous Knowledge Form New Knowledge Form
Category Category
Subject Subject
Symptom Symptom
Cause Cause

3. When the Sub- Status of a Problem Ticket changes from Problem Investigation to Solution
Identification then the following fields from the Problem Ticket would be mapped with the
fields of New Knowledge Form
Category Category
Summary Subject
Known Error Notes Cause
th
, 2013
Version: 1.0

Page 22

Workaround Workaround Text
Problem Lead Created By

4. When the Status of a Problem Ticket changes from Implementation Review to Closed -
Successful then the following fields from the Problem Ticket would be mapped with the fields
of New Knowledge Form
Resolution Notes Resolution Notes

The following fields from the earlier related Knowledge form would be mapped with the fields of
New Knowledge Form
Previous Knowledge Form New Knowledge Form
Category Category
Subject Subject
Symptom Symptom
Cause Cause
Workaround Text Workaround Text

Note: For articles proposed through Problem ticket, the various article types would be:
Article Type Scenario
Error When only the root cause of issue is known and no fix is available
Known Error When both the root cause and work around of the issue is known but no
th
, 2013
Version: 1.0

Page 23

permanent solution is available
Permanent Fix When the root cause of any issue along with its permanent fix is available

6.2.3 Status Dependency with Problem Management
In some cases status of a Knowledge article would share an interface with other modules; where the
status of a Knowledge article would change in consonance with the status of other related tickets,
the description of such cases is as follows:
S.
N
o
Problem Ticket Status Knowledge Article Comments
From Sub-
Status
To Sub-
Status
Status Article
Type

1 Problem
Investigation
Error
Investigatio
n
Withdrawn
Published Same as
earlier
Scenario - Article already related to a
Problem Ticket
Article would remain be
unchanged
2 Problem
Investigation
Workaround
Identificatio
n
Draft Error A new Knowledge Article would
be created at this stage and its
status would be Draft
Article this created would copy
few of the fields from the Problem
Ticket as per details given in
Section 6.2.2.1
A notification would go to the KM
Group to review the article
3 Workaround
Identification
Solution
Identificatio
n
Draft Known
Error
A new Knowledge Article would
be created at this stage, and
would get related with the
existing Knowledge record
copying some of its information to
the fields mapped with the old
Knowledge Article as mentioned
in section 6.2.2.1
Group to review the changes
Once the newly created article is
createdthen, the existingrelated
th
, 2013
Version: 1.0

Page 24

Knowledge Article(s) would be
deleted
4 Problem
Investigation
Solution
Identificatio
n
Draft Known
Error
be created at this stage,
The new article hence created
would copyfew of its fields from
the Problem Ticket as per details
given in section 6.2.2.1
group to review the article
5 Implementatio
n Review
Closed
Unsuccessful
Published Known
Error
NA
6 Implementatio
n Review
Closed
Successful
Editorial
Review
Permane
nt Fix
be created at this stage, and
would get related with the
existing Knowledge record
Few of the fields would be copied
from the earlier related article to
the new article please refer
section 6.2.2.1for details
group to review the article
Once the newly created article is
created then all the old
Knowledge record would be
deleted irrespective of their
Article Type value including the
article initially related with the
Problem Ticket
7 Solution
Identification
Solution
Investigatio
n
Withdrawn
Editorial
Review/
Published
Known
Error
A notification would go the KM group

Please refer to the mapping figure below for more clarity on above:
th
, 2013
Version: 1.0

Page 25

6.3 Interfaces with Change Management
If the user thinks that there should be a new Knowledge article for the subjected Change Request
then he or she can click on Propose a Knowledge Article checkbox at the time of Change
completion. Upon saving a new Knowledge form would pop up and the knowledge ID would be
related with the existing Change Request in the related list section. The status of the knowledge
article thus created from change console would be Draft with Article Type value as General.
A link for new article creation would also be provided in the email notification that would get
triggered to the Initiator after Change completion.
7 STATUS TRANSITIONS
Status defines the current state of an article, various status that would be available are Draft, Build,
Editorial review, Published, Closed

th
, 2013
Version: 1.0

Page 26

Draft
Build
Editorial Review
Retired Closed
Published
7
6
1 3
4
Closed Closed
5
2
Rejected Auto - Rejected Validity Expired Cancelled
8
9

Status
Transition
From
Status
To Status Status Transition Scenario
1 Draft Build When the contributor submits an article for build
status.
2 Draft Closed-
cancelled
When the contributor cancels the article.
3 Build Draft When the approver refers back the article to
contributor citing his comments.
4 Build Closed- Auto
Rejected
When the approver doesnt approves the Knowledge
article pending for his approval for more than 30
calendar days.
5 Build Closed
Rejected
When the approver rejects the Article mentioning the
reason for rejection.
6 Build Editorial When the approver approves the article from
th
, 2013
Version: 1.0

Page 27

Review technical point of view
7 Editorial
Review
Publish When a member of Knowledge management group
publishes that article post review
8 Published Retired -
Validity
Expired
When the current date exceeds the valid till date of a
Knowledge Article, however default validity would be
15 months
9 Published Closed -
Rejected
When the status of an article is Published and Copy
and Replace button is pressed then the status of the
article would change to Closed Rejected and the
article would freeze for any editing

7.1 Buttons in Knowledge console
Following are the buttons that would be used in the Knowledge console during the traversal of a
Knowledge article.
Status
Button
Draft Build Editorial
Review
Published
Submit for
Approval
Y
Mark public Y Y
Refer back Y
Publish Y
Search for
Duplicate
Y
Save Y Y Y
View Article Y Y Y
Mark Internal Y Y Y
Cancel Record Y
Download Y
th
, 2013
Version: 1.0

Page 28

Edit Y Y Y Y
New Knowledge
Feedback Link
Y Y Y Y
New Knowledge
Incident Link
Y Y Y Y
Link CI to
Knowledge
Article
Y Y Y Y
Link change to
Knowledge
Article
Y Y Y Y
New Note Y Y Y Y
Attach File Y Y Y Y
Edit Y Y Y Y
Available for
Group
Y Y Y

Mark Internal button would be used where we define roles or limit the target audience for that
article
Note- The visibility of the button in the above table may vary based on the permission level of the
user
Additional Buttons that would be available separately in the Knowledge Feedback form
Button Form
Accept Knowledge Feedback form
Reject Knowledge feedback form

th
, 2013
Version: 1.0

Page 29

8 NOTIFICATIONS, AUDIT AND REPORTING
8.1 Notifications
Transition Contributor KM
Group
Approver/Builder PM
Group
When the Knowledge article is submit
for Approval phase
Y
When the Knowledge article is
rejected by the approver in Build
phase
Y
referred back to the contributor from
Build phase
Y
When the Knowledge article comes to
Editorial Review stage
Y
published
Y Y
30 calendar days before the Validity of
a Knowledge article expires
Y Y
15 days before the Validity of
Knowledge Article expires
Y Y
7 days before the Validity of a
Y Y
1 Day before the Validity of a
Y Y
When the article comes in Closed-
Auto Reject due to no approvals for
more than 30 calendar days
Y Y
pending for Builders approval in
build phase for more than 10 calendar
days
Y
th
, 2013
Version: 1.0

Page 30

days
Y
days
Y
build phase for more than 29
calendar days
Y
When the article comes in Retired
Validity Expired
Y Y
When any article is rated as 'Needs
Update'

Y Y

8.2 Attachment and Download option
An option that would be provided in the Knowledge form is to attach any supporting
documents/mails in the article and it would be saved with following function:
1. There would be an attachment option provided in the form which would allow a maximum
attachment size limit of 5 MB but no limit on the no of attachments that can be made
2. Once attached an entry would be created in the action history and a copy of the article could
be seen in the work info notes of the article
There would also be an option to download an existing article for reference purpose to the user; the
user in this case would have to click on Download button which would be visible only when the
article is in Published status.
The downloaded copy of an article would consist of the following fields:
Knowledge ID
Created date
Category
Sub-category
Article source
th
, 2013
Version: 1.0

Page 31

Subject
Symptom Text
Cause Text
Workaround Text
8.3 Roles and Permissions
Permissions would be defined at the level of access that each of the stakeholders would have during
the complete lifecycle of a Knowledge article; it would allow or restrict the user to access certain
features at any point of time during the Knowledge articles lifecycle. Below are the roles and their
permission sets:

1. Contributor
All the Support Users would be allowed to submit a Knowledge article
Contributor would also be having access to view all the published articles
Contributor would be able to check the submitted article from content point of view
The contributor would be able to cancel the Knowledge article in Draft stage of the
Knowledge Article
Identifying new content which can be incorporated into the knowledge base
2. Knowledge Builder -

Support users who are mapped as an approver against a Product/Technology would be
mapped here
They would only have the rights to approve/reject or edit the Knowledge article from
technical point of view which are pending for their approval
The Builder can verify content of existing articles for continued currency and relevance on a
periodic basis and give his feedback by updating the article accordingly
He would be having rights to refer back any article back to contributor

3. Knowledge Manager

Knowledge Manager would be the owner throughout the Knowledge Article lifecycle.
Support users who are mapped as Knowledge Manager would have the permissions to
review and publish the article from Editorial Review phase
The Knowledge Manager would also be having rights to edit the Published articles

4. Consumer/User

Consumer would be having rights to view all published articles
Both support users and end users would play the role of consumer/user
Consumer may provide feedback to any article
Consumer would also rate any article based on its usefulness

th
, 2013
Version: 1.0

Page 32

8.4 Knowledge Feedback and Rating
Following are the sources to provide feedback to any of the knowledge article
8.4.1 Through Self Service console
An article would be searched from the Self Service console based on the text written in the search
field of the Self Service page, a list of all the published Knowledge Articles would be displayed with
their Short Description. Upon clicking a particular Knowledge Article a new page consisting of the
fields based on the Knowledge Article type as mentioned in section 2.2 would open up along with
the following fields
1. Feedback
2. Rating
3. Did this Article meet your Need?
Once the user would enter the details and click on the submit button, the feedback would be saved
and all the corresponding fields would be updated in the Knowledge Article Feedback related list
of the Knowledge Article
8.4.2 Through Global search option
Feedback to a Knowledge Article could also be given by searching the Knowledge Article though
Global Search option available in the tool; this would be done by providing the keywords in the text
field and clicking on search option would display the search results. User would then click on the
Knowledge ID to access an article. Once a user would click on Knowledge ID, a Knowledge form
would open up which would have all the details of the Knowledge Article along-with a Knowledge
Feedback button
Once a user would click on Knowledge Feedback button a new page would open up,this new page
would be called as Knowledge Feedback Page and would consists of the following fields
1. Feedback
2. Rating
4.
Once the user would enter the details and click on the submit button the Feedback would be saved
8.4.3 From Other Consoles
A feedback to the Knowledge article could also be provided by clicking on Knowledge Search
button available on the Incident and Problem form, this would open a new page which would
consist of all the Knowledge articles based on the information given in the summary of the incident
or Problem Ticket.
th
, 2013
Version: 1.0

Page 33

The user would then choose a Knowledge article from the search results available by clicking on the
article number which would open a new page comprising of certain fields based on article type as
mentioned in section 2.2 of this document; this new page consists of the following fields
1. Feedback
2. Rating
Once the user would enter the details and click on the submit button the Feedback would be saved
In all the above cases
1. If a user clicks on Yes checkbox in Did this Article meet your Need? then the use count
of an article would increase by 1
2. If a user clicks on any Knowledge article link or Knowledge Feedback button to give the
Knowledge Feedback then the View count of an article would increase by 1
9 REPORTING
Below are the default reports that would be configured in the tool in relation to Process KPIs
defined:
S. No. Report Logic to be confirmed
1 View Count Report Number of times the article is viewed.
2 Use Count Report Number of times the article is referred or used.
3 Number of published
articles report
Count of articles that have been published in a given time
period
4 Article feedback Articles for which feedback has been provided by the
consumer/user
5 Knowledge articles by
status
Articles based on their status values
6 Most Used Knowledge
article
Count the maximum available increase in the value of use
count for the given period
7 Articles to be Retired
report
Articles that are about to be retired within the defined time
frame
th
, 2013
Version: 1.0

Page 34

8 Article Type wise
Knowledge Article
Report based on Article Type value of articles
9 Category Wise report Report based on category of the Knowledge Article
10 Top Rated Articles
Report
Displays the average rating of the Knowledge Articles

HCL RF GBP Knowledge Management Process - v1.0 - New

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

HCL RF GBP Knowledge Management Process - v1.0 - New

Hochgeladen von

Copyright:

Verfügbare Formate

HCL Technologies

HCL Gold Blue Print Process

Das könnte Ihnen auch gefallen