The Article process in Service Desk provides mostly the same abilities as seen across all other modules. This section describes some knowledge-specific ideas and suggestions may help in designing and using knowledge.
If you want unique numbers on articles, add Extended ID to the Article window as described in Adding a control to a window and also to the appropriate queries.
Knowledge relevance is a value shown in search results to confirm how well an item of knowledge matches your search terms. In your search results, you can also show an alternative form of relevance: to whom and when is this knowledge most significant.
For example, an item of knowledge about correcting the output of financial reports may be particularly relevant at the end of each quarter when those reports need to be run.
The simplest approach is to add a text field on your Article to hold this unstructured text, and then present it as a part of the search results.
Design Idea: You could add a Project field to Articles. When you create an Article, use this list to select the project, activity or reason why the knowledge is created. If the Project itself is driven by a Change process, you could automatically pre-populate this link as described elsewhere in this document.
You can add a dropdown list of CIs to the Article window. Then, when you create a new article, you can select which CI the Article applies to.
Alternatively, you could use Keywords or Tags. Also consider the Knowledge-centered Support methodology and the use of Knowledgeable Words.
If you are using a full Service Lifecycle, your Services are defined as CIs and appear in the same list. You can change this list to show only Services and then flag each article with a Service.
Every business has different needs for validating the content of knowledge. Service Desk Knowledge is process-driven, so you can include the same form of validation and approval stages in the pre-publication of knowledge as for any other process.
To help with this process, fields that you add to the Article window can ensure the correct information is captured. Complete validation fields such as SOX / HIPAA / ISO and other governance requirements. Remember you can report on knowledge just like any other process, so a report of Articles showing Governance fields and Review Dates can help with your external audits.
Frequently, knowledge that needs to be shared with users is explained already on a webpage or other external source. Links to these sites can be stored on your articles and can be launched from within the articles by using desktop management capabilities to launch the URL in the field.
Articles only appear in knowledge results when they are at the Approved status. However, sometimes Articles need to be expired when they are no longer relevant. This is achieved by setting the Expiry Date on the Articles. When the Knowledge Management Engine service runs, it removes expired articles from the index so they no longer appear in the search results.
In Ivanti Service Desk, the knowledge management features provided lend themselves particularly to the management of Known Errors generated from Problem Management processes. In this section we describe how these items fit together.
For more information about generating Known Errors from Problems, see Problem Management.
Known Errors are generated during problem diagnosis. One of the benefits of Service Desk is that by making Known Errors 'knowledgeable' (that is, appearing in searches), you can ensure that they appear in searches from all other processes. Knowledge is shareable across all modules and usage in Service Desk. This means you can search for Known Errors from any process or window – even from a CI or Service window if required.
If dynamic searching is enabled, a shortcut appears in Console.
You may see workarounds described in two places in Service Desk. Most typically, a Workaround is created as part of a Known Error in the Problem process.
You can make the Workaround field mandatory if required.
You can also capture Workarounds at later stages in the Problem process. You could add a Workaround attribute as a text field on the Problem Resolution object and place it on your Problem Resolution window. Then, when resolving the Problem, the Workaround can be recorded.
Remember that this is the workaround identified during the problem, and recorded when the problem is resolved, so it may be valuable if that problem itself is ever encountered again. This is distinct from a Workaround on a Known Error (as described above), which provides advice on managing the error/symptoms of one or many Errors that may occur from that Problem.
Because of the way that Service Desk is designed, a knowledgeable item is available to search for regardless of the status of the service to which it refers. Therefore, when knowledge is created about a service during its design phases it will continue to be available to search for when the service transitions in to chartered and even retired statuses. If it is not always desirable to have knowledge available to all users then domains can be used to limit this.
The knowledge index can also be used to present results of all the other processes in the IT environment. Any attribute on any object in Ivanti Service Desk can be made knowledgeable as can any document on the network (including doc, docx, xls, xlsx, pdf, ppt, pptx etc) and all these different items can therefore appear in search results. As a consequence of this, all data stored around any of the other IT processes can be made knowledgeable, including Portfolio, Availability, Configuration Items & Assets and any other processes.
You can set the Is Knowledgeable? property to True for any business object using the Object Designer component. It is often a good strategy to start with only Articles available in searches, because until you are logging and resolving Incidents that provide useful and searchable information, you may find that indexing all of your Incidents provides more noise than value. For this reason, you could design your Incident process to create an Article automatically from an Incident Resolution when a Create knowledge check box is selected on the Resolution window.
For more information about this, see Incident Management: Full Incident.
However, the ability to include any data field from any process in knowledge provides more design opportunities than just searching Incidents and Known Errors. For example, if you are using the Event Manager interface for Event Management and Availability Management tracking, then you can set the Is Knowledgeable? property to True for your Event process descriptions. This means that you can search for event and availability information, and so create Articles from Event Closures. Similarly, you could add text fields to the Analyst window that describe the analyst's areas of expertise so that the names of Subject Matter Experts (SMEs) also appear in knowledge searches.
Like all records stored in Service Desk, Articles can be reported on. This is done by creating queries over the object or using Crystal Reports to generate more complex analyses of the data. Some useful reports to create and run include those listed below.
Was this article useful?
The topic was:
Not what I expected