SCSM From Framework to Real Work Part II

In part I of this series we explored the link between current frameworks and how we do our real work. We also discussed how SCSM takes you from framework to real work with less risk and more business benefit by being customizable and portable. We introduced the Administration node of the console.

In part II of Framework to Real Work, we will explore the Library node of the SCSM console

 

The library is your process toolbox. This part of the console contains the sub-nodes where various objects are provided for you and can be created for use in the ITIL/MOF processes SCSM implements. The objects and items in this section are relevant to the job you need to do (Incident or change management as examples). We will provide an introduction to the sub-nodes;

• In SCSM you have things (Configuration Items – CIs) you want to do something to or, have something wrong with (Work Items). Groups are a used to organise CIs to match your organisations real work view.
• Groups act as building block for organising CIs (e.g. All Database Servers) which then allows us to apply role based security (who has access to database servers), or how to categorise our incidents or change requests. More on Groups when we get into the specific process sections in our series of Framework to Real Work.

In SCSM you have the ability to learn from past experiences in your organisation, sharing known best practise and also providing access to external information.

• The Knowledge sub-node presents a single pane of glass to view all your internal knowledge and use this information as part of your processes.
• All Knowledge Articles – Where we can view all knowledge articles includes Archived, Draft and Published articles.
• Archived – Knowledge articles that have been archived to reduce the number of articles presented/displayed whilst retaining important information (archived knowledge may be referred to if a known problem is encountered again).
• Draft – Knowledge articles pending approval before publishing or not yet ready for publication
• Published – Knowledge shown to our users or analyst depending on the ITIL/MOF process (e.g. in Incident Management – try this first user?)

• Lists drive the Framework to Real Work flexible approach implemented by SCSM. This sub-node has default predefine lists used in the ITIL/MOF processes SCSM is designed to implement. We can extend this list to match our environment.
• One approach to understanding the use of lists is to view their use to support the incident management process.

Incident Management Lists	Description/Use
Incident Classification	Type of incident e.g Printer problems. Add your custom types. this list is presented as a drop down in the incident form
Incident Source	How the incident was raised. Email, portal and console are all examples. Also provides us with a method to measure and track where the incidents are generated
Incident Tier Queue	The levels of service support. The default is tier 1 , 2 and 3. Most environments may have 1st line , 2nd line and 3rd line. Rename and or extend as required to reflect your needs
Impact	Impact of the incident (NB this is a shared list with other processes) – Low, Medium and High. Extend as required.
Urgency	Urgency of the incident (NB this is a shared list with other processes) – Low, Medium and High. Extend as required.

 

• The default lists in SCSM can be renamed to suit the organisation terminology (Do Not Delete the default lists; they are referenced by GUID in default SCSM Workflows etc.). We can also create and extend the lists in the console (Some list types have to be created in the Authoring Tools only)

• Queues are used to create collections of what needs to be done (Work Items – WIs) so we can assign it to the teams or individuals for doing what needs to be done. So we create a queue for all Desktop incidents and we can then assign the queue to the Desktop Group (Configuration Items user group).
• Typically Queues are mapped to the Incident, Change and Configuration Management processes. We will expand on this as we progress through this series of Framework to Real Work.

• This sub-node is where you create a gateway to external calls to tools used to support processes like incident and problem management. So we can create a ping task to launch the command prompt and ping a CIs (Computer) that is reported as unavailable.  SCSM allows you to pass the computer name automatically by querying the information in the SCSM Database. This not only presents a single gateway but also reduces the time it takes to switch consoles whilst also increasing user input quality.
• Tasks can be scoped to specific areas in the SCSM Console (e.g. only present the launch Active Directory Users and Computers console from the Users node in SCSM). This means we can extend our role based security as well as only showing what is relevant to a section.

• The templates found in the Library node is the second type of templates in SCSM. The two types are Notification and Forms. The forms (Library)Templates in SCSM provide two common functions; static (standard prefilled templates) or dynamic (workflow and activity templates). Templates are also best viewed by the process they support. Looking at the incident management process;
  • Static (standard prefilled templates) – similar to traditional templates (e.g. MS word template with company logo and prefilled address); Template for all incidents created using the portal. From the image we can see that the incident source (refer to the use of lists described earlier) is prefilled with “Portal” and also the Urgency and Impact are also filled.

• Dynamic (Workflow and Activity templates) – to perform an activity like changing the support team from 1st line to 2nd line, we have to create a template with the assigned field set to 2nd line. The workflow step will then “change” the field by “applying” our template. A second  workflow example is to assign incidents with a specific classification category (also refer to the Incident Classification List) to a support tier.

 

The library components in action

In our scenario to demonstrate the use of the Library node, all tickets are initially assigned to Tier 1. Once investigated we assign the ticket to the team responsible for further investigation; we will use the database team as our example.

Tier 1 use the Knowledge base as the reference to perform diagnostic tasks and escalation processes. Tier 1 assign the category to the relevant team (e.g. database team) using the Incident Category. A workflow monitoring the incident category field automatically assigns the incident to the next tier team.

Steps to achieve the scenario

1. Create active directory group e.g. Database Support Team (add members)
2. Create Active directory group called Tier 1 Support (add members)
3. Synchronise the AD connector for SCSM
4. Create the SCSM Group for the database components. We can use the business service as input for the group. Services are a component under the configuration Items node. We can define a simple service that includes all database servers.
5. Modify the default Incident Template – change the Assigned to field to Tier 1 Support (AD group created)
6. Create a Knowledge Article for Database Service Issue first diagnostics steps (e.g. KB directs Tier 1 to ping the server(s) and then check for the DB services; if unsuccessful change the Incident Category to the Database Services Problem)
7. Create a task for the database diagnostics (e.g. ping task, services applet)
8. Add a new list item to the Incident classification list (e.g. Database Service Problems)
9. Create an Assigned to changing Template (dynamic) where the Assigned to field is set to the Database Support Team
10. Create a Queue for the Database Support Team by using the Incident Classification field  equals “Database Service Problems”
11. Create a Workflow that checks the Incident Category equals Database Service Problems and applies the Assigned to changing Template from step 9

In this blog we discussed the Library node in the SCSM console and how this node is core to the SCSM processes. We also explored a scenario for incident management to demonstrate how the various components interact and depend on each other.

We would explore detailed processes with screenshots in future blogs. The SCSM official step by step guides are available here