Service Manager: Runbook to Service Offering

One of the things I get asked about on a regular basis is how to add an Orchestrator Runbook to Service Manager 2012 SP1 and then turn it into a service offering that users can access.  The next few posts will define how to do just that, and I’ll include some of the tips and tricks I’ve learned along the way.

In the demonstration labs we build, there are a number of Service Manager Request Offerings, and most are based on Runbooks.   This means that not only do I configure what is deployed, but I also have to document it.  Don’t get me wrong, like almost everyone else in the world, documentation is not my favorite thing to do, but, of course, it is necessary.

In this overview, I will include the tables I use to capture the information I needed to complete the build, and these tables can be cut and pasted into a build document – it’s a real time saver!

So let’s get started.

There are a number of steps involved in the end to end process.

• Planning
• Create the Service Offerings
• Create the Runbook  (Charles already covers this in his posts) 
• Synchronize the Runbook
• Create a management pack
• Create a Runbook Automation Activity template
• Create a Request Template
• Create a Request Offering
  • Text prompts: the basics
  • Types of User prompts
  • Configuring prompts
• Catalog Groups

Planning

This is the step that takes the longest.  It requires you to understand your business, your users, their needs, and how they will react to this new system. 

Let’s look at what a service catalog is, as what you define here will represent what your users will see. 

Where to Start

This is the step that takes the longest.  This step requires you to understand your business, your users, their needs, and how they will react to this new system. 

Let’s look at what a service catalog is, as what you define here will represent what your users will see.  The Wikipedia definition is a good place to start: 

• A description of the service
• Timeframes or service level agreement for fulfilling the service
• Who is entitled to request/view the service
• Costs (if any)
• How to fulfill the service

Understand Your Business

In order to have an effective service catalog you need to understand your business, what your users require from IT, and how they will interact with the catalog. 

First, ask yourself what do your users need to be able to do. The easiest way to determine this is to look at the help desk tickets or requests that are opened on a regular basis.  Do you users need to obtain software, change passwords, request new laptops or desktops, join Active Directory Groups, etc.?  This type of list can be endless and daunting, but, by examining it, you can better understand what your users need to do – and this will guide your decision around what can/should be fully or semi-automated via a self-service request system. 

Secondly, we want to ensure that everything we put in this catalog is actionable.  Users of the system will be shopping for a service and their end goal will be to get what they need.  As a side note, try to keep any details/notes about how to use the system to an absolute minimum.  If you provide too much detail, they may ignore or (worse yet) decide the self-service option is too hard and instead call their favorite IT guy/gal for a favor – thus bypassing your new service.

Lastly, you will need to ensure that all the steps required for each service being offered are fully defined and map to your businesses internal processes and compliance levels.  You also need to ensure efficiency because, if it turns out to be less efficient then it won’t get used in the first place.

Our Example Service Catalog

This is an example of some of the services you may want to offer and is by no means an extensive list. 

• Email and Messaging Services
• Knowledge Sharing Services
• Identity and Access Services
• Private Cloud Management Services
• Software Services

Keep in mind also that you may want to offer different services to various groups.  The IT tea,, for example, may require a set of services that allow management of servers, the Development tea, may need to deploy virtual machines for their dev needs, and other teams within your organization may need access to different software, systems etc.  Although a list like this may be complex, you do want to simplify the end product enough that it is optimally likely to be used.

The Tables and How they Work:

The key information you will want to define for each service offering can be captured in the table below.  Remember:  This is used while you are completing the build steps, but will also be added to your build document when you are done!

Each item contained in brackets in the configuration section is the data you will enter into the wizards, and you will use a variety of these tables throughout the process.  Not every piece of information is covered, but the required pieces are, and you can extend these as you need to.

Now that we have defined our plan for our service offerings we need to start building! In the next post we will move from the planning phase to the building of our catalog.