hcl rf gbp knowledge management process_v1.0_new (2)

HCL Gold Blue Print Incident Management Process

HCL Technologies Limited (Confidential)

HCL Gold Blue Print Knowledge Management ProcessDate of Release: October 28th , 2013Version: 1.0

HCL Technologies

HCL Gold Blue Print Process

KnowledgeManagement Process

HCL Gold Blue Print Knowledge Management Process 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.

Table of Content1Policies configured for Remedyforce41.1Knowledge Article Auto Rejection policy41.2Knowledge Article deactivation policy41.3Knowledge Article review policy41.4Knowledge Article Viewership policy41.5Knowledge Article search and relate policy41.6Knowledge Article publishing policy52Knowledge console in Remedyforce52.1New Knowledge Article creation52.2Article Types73Article creation Steps93.1Build Approval Process103.2Editorial Review Process103.3Published114Categories and Sub-Category Values115Post Creation of Knowledge Article155.1Related Lists166Interfaces with other Consoles/Objects176.1Interface with Incident console176.1.1Referring or Resolving any Incident through Knowledge Articles176.1.2Proposing any Knowledge article through Incident Console186.2Interfaces with Problem Management196.2.1Referring any Problem through Knowledge Article196.2.2Proposing any Knowledge article through Problem Console196.2.3Status Dependency with Problem Management236.3Interfaces with Change Management257Status Transitions257.1Buttons in Knowledge console278Notifications, Audit and Reporting298.1Notifications298.2Attachment and Download option308.3Roles and Permissions318.4Knowledge Feedback and Rating328.4.1Through Self Service console328.4.2Through Global search option328.4.3From Other Consoles329Reporting33

Policies configured for RemedyforceKnowledge Article Auto Rejection policyIf 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 Knowledge Article deactivation policyValidity 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 Knowledge Article review policyAny 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. Knowledge Article Viewership policy1. 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 article2. The final rights to decide the target audience of an article would be with the Knowledge Manager/Knowledge Management Group.Knowledge Article search and relate policy1. A knowledge article could be searched and related from Incident Management, Problem Management and Change Management consoles in the tool2. Any knowledge article could be searched on the basis of the tagged information/Keywords or summary provided in the article3. Articles in Published status would only be available for search and can be related with any Incident, Problem and Change tickets respectivelyKnowledge Article publishing policy1. 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.1. 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.Knowledge console in RemedyforceClicking 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.New Knowledge Article creationAll 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 Red2. The assignment group field would be defaulted as Knowledge Management Group and would be read only3. Some fields would be optional for which the information may/may not be provided by the contributor4. Knowledge article form would consist of below fields:FieldField DescriptionMandatory(Yes/No)

CategoryConcerned Technology based categorization would be done for all the Knowledge ArticlesYes

Sub CategoryConcerned Technology based sub categorization would be done for all Knowledge Articles and this would be dependent upon the category fieldYes

Short DescriptionProvides a brief description about the Knowledge Article being createdYes

Status This field depicts the information about Status of an article at any point of time during its lifecycleNo

Article TypeThis 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 ToThis field defines the name of the person from Knowledge Management group to which the article is assignedNo

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 createdNo

Symptom Text*This defines the symptoms of the issue for which the Knowledge article is being createdNo

Cause*This defines the cause of the issue for which the Knowledge article is being createdNo

Workaround Text*This defines the workaround given to any issue for which the Knowledge article is being createdNo

Associated CI/ServiceThis fields defines the CI/Service name for which the Knowledge article is openedNo

KeywordThis field specifies the Keyword/Tag with which the article would be denoted in order to improve its search efficiencyNo

Resolution Notes*This field defines the resolution given to any issue for which the Knowledge article is createdNo

Details*This field provides the complete details about the topic for which the article is createdNo

Available for GroupThis 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

QuestionThis field defines the information about the Question when the article type is a FAQNo

AnswerThis field defines the information about the Answer when the article type is a FAQNo

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 documentArticle TypesEvery 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 TypeDescriptionExceptionsOptional Fields Available

GeneralThis type is used for the articles which are not of any specific category and consists of generic information which would be helpful to the user at any given point of time.NA Subject Details Cause Workaround Text Resolution Notes

FAQThis article type is used for the articles which are referred frequently and are helpful to resolve any instant queryNA Question Answer

Known ErrorThis 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 knownNA Subject Symptoms Cause Workaround Text

Patch reviewThis article categorically specifies the details pertaining to any technology update or details about any release informationAttachment is mandatory for this article type without which this could not be saved/submitted for Build phase Subject Symptoms Cause Resolution Notes

Process and PolicyThis article type is used for articles consisting of information regarding process and policies that applies to a specific area, group or technologyNA Subject Details

Technical SOPThis article type is used for articles which consists of details about leveraging any technology using already defined proceduresNA Subject Details

Technical TipThis article type is used for articles which defines best practices or opinions about any support item from technical standpointNA Subject Details

Temporary FixThis article type is used for articles which gives the information about workaround to a Problem but not its root cause.NA Subject Symptoms Cause Workaround Text

Permanent FixThis article type is used for articles which give the information about the permanent resolution provided for any issue along-with its root causeNA Subject Symptoms Cause Workaround Text Resolution Notes

Error

This article type is used for articles which gives the information about the root cause of any issue but has no details of workaround or permanent fixNA Subject Symptoms Cause

Article creation Steps1. 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 console2. 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 baseb. 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 record3. An article could also be created from Incident, Problem and Change consoles, the details of which are mentioned in section 4 of this document4. 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 updated5. 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 itself6. 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 article7. 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 approverBuild Approval Process1. 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 article2. At this stage an assigned approver or any member of the Knowledge Management group would be having the rights to edit the article3. The approver would review the article from technical point of view and would be having the rights to approve/reject it4. 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 ID5. While rejecting the article it is mandatory for approver to provide rejection comments and the status of article would move to Closed Rejected6. Once approved the status of the article would change to Editorial review and would be assigned to the Knowledge Management Group for review7. 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 Draft8. 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 below9. Category/Sub category, article type of any article can only be changed till Build status, once approved it would freeze for any editingEditorial Review Process1. Once a Knowledge article would be approved at the build phase, an email would be sent to all the members of the Knowledge Management group2. Any member of the Knowledge Management group would be able to assign the article on his name3. 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 it4. Any member of the Knowledge management group can publish a Knowledge article irrespective of the person whose name is mentioned in the assigned to field5. Knowledge Manager would publish this article using Publish button and then this article would be available for use by target audiencePublished1. 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 Replace2. 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 value3. 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 article4. 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 documentNote 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 ArticleCategories and Sub-Category ValuesBelow mentioned values would be mapped with the Category and Sub-category field.Category Sub Category

Application Management ToolsNot Applicable

Business ApplicationNot Applicable

Cabling SystemCabling System

ClusterCluster

Communication and Collaboration ApplicationNot Applicable

Data LinkData Link

DatabaseDB2 Instance

DatabaseMySQL Instance

DatabaseOracle Instance

DatabaseSQL Server Instance

DatabaseSybase Instance

End User and Client ApplicationNot Applicable

End User AssetCell Phone

End User AssetData cards

End User AssetDesktop

End User AssetHandheld tablet

End User AssetIP Phone

End User AssetLaptop

End User AssetPeripherals

End User AssetSmartphone

End User AssetVPN Access Token

ERP applicationNot Applicable

File SystemFile System

Infrastructure Management ToolsNot Applicable

IP addressIP Address

MiddlewareDatabase Middleware

MiddlewareMessage Oriented Middleware

MiddlewareObject Middleware

MiddlewarePortal

MiddlewareRPC Middleware

MiddlewareTransaction Middleware

MiddlewareWeb server

Network & ZonesDMZ

Network & ZonesPublic Network

Network & ZonesSubnets

Network & ZonesVLAN

Network & ZonesVPN

Network and ZonesDMZ

Network and ZonesPublic Network

Network and ZonesSubnets

Network and ZonesVLAN

Network and ZonesVPN

Network Gear/ApplianceAccess Point

Network Gear/ApplianceFirewall

Network Gear/ApplianceIDS/IPS

Network Gear/ApplianceLoad Balancer

Network Gear/ApplianceRouter

Network Gear/ApplianceSwitch

Network Gear/ApplianceUCS

Network Gear/ApplianceVPN Concentrators

Peripheral SystemMultifunction Device

Peripheral SystemNetwork Printer

Peripheral SystemScanner/Photocopier

Physical ServerAS/400

Physical ServerLinux Server

Physical ServerMac Server

Physical ServerMainframe

Physical ServerUnix Server

Physical ServerVirtual Machine Host

Physical ServerWindows Server

RackRack

ServiceBusiness Service

ServiceEnabling IT

Service Management ApplicationsNot Applicable

SoftwareEmail

SoftwareOS

Storage DeviceLUN/NAS Client

Storage DeviceNAS

Storage DeviceSAN

Storage DeviceStorage Host

Storage DeviceTape Library

System SoftwareSystem Software

Virtual ServerLinux Server

Virtual ServerMac Server

Virtual ServerUnix Server

Virtual ServerWindows Server

Post Creation of Knowledge ArticleOnce an article would be submitted by the contributor below are the fields that would be visible and auto populated.Field NameDescription

Knowledge IDA 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 dateSpecifies the date when the Knowledge article is created.

Created ByThis would be populated with User ID who has created this article.

Last Modified ByThe support user who has last modified the article.

Work Info NotesThis 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:FieldDescription

Published dateSpecifies the date and time at which the article is published.

Valid tillSpecifies 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 CountThis 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 countThis 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

RatingThis field would show the average of all the rating given by the user, An article could be rated between 1 to 5

FeedbackThis 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 NeedThis 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 requiredField Description

CommentsSpecifies 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 ArticleField which defines whether the resolution of any incident comes through any knowledge article

Related ListsRelated 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:TypeDetails

Linked ProblemsManual 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 IncidentAny knowledge article proposed through Incident at the time of Incident resolution would get linked automatically in related list section

Linked Change RequestsAny Knowledge article proposed through Change request at the time of closing the request would get linked automatically in related list section

Linked CIsThere 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 ArticlesThis would be used to relate any knowledge article with another one

Knowledge Article FeedbackThis 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 HistoryThis would have the details about the approval history of a Knowledge article

Knowledge Action HistoryThis would be having the details of all the actions taken on a Knowledge Record

Knowledge HistoryThis would comprise of the details of all the fields on which the auditing is enabled

Interfaces with other Consoles/ObjectsInterface with Incident consoleReferring or Resolving any Incident through Knowledge Articles1. 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 False4. 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 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 1The field mapping between Knowledge form and Incident form for various article typesin case of Mark as Solution option would work as follows:Article TypeKnowledge FieldIncident Field

Known ErrorWorkaround TextResolution Notes

Permanent FixResolution NotesResolution Notes

Temporary FixWorkaround TextResolution Notes

GeneralResolution NotesResolution Notes

Patch ReviewResolution NotesResolution Notes

Proposing any Knowledge article through Incident ConsoleIf 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 detailsIncident Ticket StatusKnowledge article

StatusSub-StatusStatusArticle Type

ResolvedWorkaroundDraftKnown Error

ResolvedPermanently ResolvedDraftPermanent Fix

ResolvedWorking as DesignedDraftGeneral

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. Workaround2. Permanently Resolved3. Working as DesignedField mapping between the Incident Ticket and Knowledge form would work as follows:Incident FormKnowledge Form

CategoryCategory

Sub-categorySub-category

SummarySubject

SummaryShort Description

DescriptionSymptoms

Resolution NotesWorkaround Text

Incident NumberArticle Source

Assigned To Created by

Affected CI/ServiceAffected CI/Service

Created ByCreated By

Interfaces with Problem ManagementKnowledge Management shares a strong interface with Problem Management, the details are stated below:Referring any Problem through Knowledge ArticleThe 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 contentAn 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 1The article would be linked in the Linked Knowledge Article list of the Problem form.Proposing any Knowledge article through Problem ConsoleA 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

However knowledge article would keep on updating as the problem ticket proceeds with below status/sub status:From StatusSub StatusTo StatusTo Sub Status

Under InvestigationWorkaround IdentificationUnder InvestigationSolution Identification

Under InvestigationProblem InvestigationUnder InvestigationSolution Identification

Implementation ReviewClosedSuccessful

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.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 FormProblem TicketKnowledge Form

CategoryCategory


SummarySubject


DescriptionSymptoms

Known Error NotesCause

Problem Investigation LeadCreated by

Problem NumberArticle source

Associated CI/ServiceAssociated 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 FormProblem TicketKnowledge Form

Workaround Workaround Text

The following fields from the earlier related Knowledge form would be mapped with the fields of New Knowledge FormPrevious Knowledge FormNew Knowledge Form

CategoryCategory






SubjectSubject

SymptomSymptom

CauseCause


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 FormProblem TicketKnowledge Form

CategoryCategory


SummarySubject


DescriptionSymptoms

Known Error NotesCause




Workaround Workaround Text

Problem LeadCreated 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 FormProblem TicketKnowledge Form

Resolution NotesResolution Notes

The following fields from the earlier related Knowledge form would be mapped with the fields of New Knowledge FormPrevious Knowledge FormNew Knowledge Form

CategoryCategory






SubjectSubject

SymptomSymptom

CauseCause

Workaround TextWorkaround Text


Note: For articles proposed through Problem ticket, the various article types would be:Article TypeScenario

ErrorWhen only the root cause of issue is known and no fix is available

Known ErrorWhen both the root cause and work around of the issue is known but no permanent solution is available

Permanent FixWhen the root cause of any issue along with its permanent fix is available

Status Dependency with Problem ManagementIn 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. NoProblem Ticket StatusKnowledge ArticleComments

From Sub-StatusTo Sub-StatusStatusArticle Type

1Problem InvestigationError Investigation WithdrawnPublished Same as earlierScenario - Article already related to a Problem Ticket Article would remain be unchanged

2Problem InvestigationWorkaround IdentificationDraftError 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

3Workaround IdentificationSolution IdentificationDraftKnown 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 A notification would go to the KM Group to review the changes Once the newly created article is createdthen, the existingrelated Knowledge Article(s) would be deleted

4Problem InvestigationSolution IdentificationDraftKnown Error A new Knowledge Article would 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 A notification would go to the KM group to review the article

5Implementation ReviewClosed UnsuccessfulPublishedKnown ErrorNA

6Implementation ReviewClosed SuccessfulEditorial ReviewPermanent Fix A new Knowledge Article would 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 A notification would go to the KM 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

7Solution IdentificationSolution Investigation WithdrawnEditorial Review/ PublishedKnown ErrorA notification would go the KM group

Please refer to the mapping figure below for more clarity on above:

Interfaces with Change ManagementIf 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.Status TransitionsStatus defines the current state of an article, various status that would be available are Draft, Build, Editorial review, Published, Closed

Status TransitionFrom StatusTo StatusStatus Transition Scenario

1DraftBuildWhen the contributor submits an article for build status.

2DraftClosed- cancelledWhen the contributor cancels the article.

3BuildDraftWhen the approver refers back the article to contributor citing his comments.

4BuildClosed- Auto RejectedWhen the approver doesnt approves the Knowledge article pending for his approval for more than 30 calendar days.

5BuildClosed RejectedWhen the approver rejects the Article mentioning the reason for rejection.

6BuildEditorial ReviewWhen the approver approves the article from technical point of view

7Editorial ReviewPublishWhen a member of Knowledge management group publishes that article post review

8PublishedRetired -Validity ExpiredWhen the current date exceeds the valid till date of a Knowledge Article, however default validity would be 15 months

9PublishedClosed -RejectedWhen 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

Buttons in Knowledge consoleFollowing are the buttons that would be used in the Knowledge console during the traversal of a Knowledge article.StatusButtonDraftBuildEditorial ReviewPublished

Submit for ApprovalY

Mark publicYY

Refer backY

PublishY

Search for DuplicateY

SaveYYY

View ArticleYYY

Mark InternalYYY

Cancel RecordY

DownloadY

EditYYYY

New Knowledge Feedback LinkYYYY

New Knowledge Incident LinkYYYY

Link CI to Knowledge ArticleYYYY

Link change to Knowledge ArticleYYYY

New NoteYYYY

Attach FileYYYY

EditYYYY

Available for GroupYYY

Mark Internal button would be used where we define roles or limit the target audience for that articleNote- The visibility of the button in the above table may vary based on the permission level of the userAdditional Buttons that would be available separately in the Knowledge Feedback formButtonForm

AcceptKnowledge Feedback form

RejectKnowledge feedback form

Notifications, Audit and ReportingNotificationsTransitionContributor KM GroupApprover/BuilderPM Group

When the Knowledge article is submit for Approval phaseY

When the Knowledge article is rejected by the approver in Build phaseY

When the Knowledge article is referred back to the contributor from Build phaseY

When the Knowledge article comes to Editorial Review stageY

When the Knowledge article is publishedYY

30 calendar days before the Validity of a Knowledge article expiresYY

15 days before the Validity of Knowledge Article expiresYY

7 days before the Validity of a Knowledge Article expiresYY

1 Day before the Validity of a Knowledge Article expiresYY

When the article comes in Closed-Auto Reject due to no approvals for more than 30 calendar daysYY

When the Knowledge article is pending for Builders approval in build phase for more than 10 calendar daysY




When the article comes in Retired Validity ExpiredYY

When any article is rated as 'Needs Update'

YY

Attachment and Download optionAn 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 made2. 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 articleThere 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 Subject Symptom Text Cause Text Workaround TextRoles and PermissionsPermissions 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 base2. 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

Knowledge Feedback and RatingFollowing are the sources to provide feedback to any of the knowledge articleThrough Self Service consoleAn 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 fields1. Feedback2. 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 ArticleThrough Global search optionFeedback 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 buttonOnce 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 fields1. Feedback2. Rating 3. Did this Article meet your Need?4. 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 ArticleFrom Other ConsolesA 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.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 fields1. Feedback2. 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 ArticleIn all the above cases1. If a user clicks on Yes checkbox in Did this Article meet your Need? then the use count of an article would increase by 12. 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 1ReportingBelow are the default reports that would be configured in the tool in relation to Process KPIs defined:S. No.ReportLogic to be confirmed

1View Count ReportNumber of times the article is viewed.

2Use Count ReportNumber of times the article is referred or used.

3Number of published articles reportCount of articles that have been published in a given time period

4Article feedbackArticles for which feedback has been provided by the consumer/user

5Knowledge articles by statusArticles based on their status values

6Most Used Knowledge articleCount the maximum available increase in the value of use count for the given period

7Articles to be Retired reportArticles that are about to be retired within the defined time frame

8Article Type wise Knowledge ArticleReport based on Article Type value of articles

9Category Wise reportReport based on category of the Knowledge Article

10Top Rated Articles ReportDisplays the average rating of the Knowledge Articles

Page 10

Draft

Build

Editorial Review

Retired

Closed

Closed

Published

1

6

7

8

2

4

5

Closed

9

3

Rejected

Auto - Rejected

Validity Expired

Cancelled

hcl rf gbp knowledge management process_v1.0_new (2)

Documents

knowledge feedback

knowledge article196

knowledge articles176

problem management236

problem console196

incident console186

problem management196

incident console176