The focus of this discussion is how to use Business Services (as they are called in SCSM) to greatly enhance and automate your SCSM Change Management implementation.
If you haven’t had a chance to read our previous blog about creating an ITIL Change Management Checklist (which includes best practices to avoid common pitfalls), I highly suggest giving it a read, as it is a great starting point and roadmap as you navigate Change Management in your organization. It also serves as a great gateway into a topic I find very valuable and extremely helpful as your Change Management processes mature.
Background: Business Services in Microsoft Service Manager
I want to start by giving a brief background and explanation of Business Services in Microsoft Service Manager. They are a Configuration Item Class that comes out-of-the-box in Service Manager and can be seen in the Configuration Items pane in the Service Manager Console.
Like any other Class in Service Manager, there are several fields and relationships that you get right out of the gate. I will get into a few of these in the next sections. One area within Business Services that I would like to highlight right now is the Service Components tab.
Let’s click on the Add Category button and you can see that there are different groups of components that can be added here. I’ve selected the Computers Group.
From here you can select any type of Configuration Item in the system and add it within this group through the Add Item button.
We have a ton of flexibility in how we define a Business Service and the Components that make up the service. In this scenario we are just adding a few Servers.
There is an automated way to have these components synced in from Operations Manager but that is another story for another day. Quite honestly, it is a very complex and cumbersome task that requires a great deal of administrative overhead.
The layering of these components and how it can help your SCSM Change Management Implementation is where I want to focus.
Business Services: How to Gather Data and Where to Start
More than likely, a lot of this information already exists in your environment. If you are using Microsoft Operations Manager and are maintaining Distributed Applications, you can leverage an SCSM Connector that can bring in this information. As stated earlier, this process involves a lot of work and may not even cover everything in your environment. It is worth noting that the intended use for this ties Distributed Applications to Business Services. These are groups of objects (or Configurations Items) that you are monitoring in your environment.
This information could also exist in a previous solution, or a data source, or even a spreadsheet. The key is to start by defining all your Production Systems (or Applications or Business Services). Whatever you want to call it. They all live on a Server and may or may not have a backend that lives on some other Server.
I like to keep things very basic in the beginning and start with the Name of the System (or Application or Business Service) and the Servers that it relies on. Back in the previous section, I added a Computers Group to a Business Service and then added 2 Servers to that Group. That is it to begin with. When it comes to Change Management, most changes will be against a Server and/or an Application (Business Service). It usually makes sense to spread the information gathering tasks out across the various Service Owners or Groups within your IT department.
If that is not ideal or just too daunting of a task, then start with your most critical systems. These could be defined through your DR plan (as pointed out in Brett’s blog). Or, look at your Changes over the past year and identify your heavy hitters first. In any case you must start somewhere, and the process will get easier over time.
With Business Services in place, here are some common mistakes we see organizations make.
Mistake #1: Not Associating Risk to a Business Service
As we are identifying and building our Business Services, it is of great value to determine the level of Risk that is associated with a Change to the Business Service. A great place to start is by looking over your DR plan and getting an idea for these business-critical systems. From there, it is more of an organizational decision on what the difference is between a Low or Medium risk and how it relates to a Business Service.
The Business Service form in Service Manager comes with a field called Priority with default values of Critical, High, Medium, Low. I like to use this field for this Risk level as it relates to SCSM Change Management. You could also create a Risk field by extending the Business Service class, but we won’t get into that right now. The bottom line is that defining this risk will help you identify the risk associated with a Change to a Server that is related to a Business Service. If I am going to make a change on a Server that is associated with Enterprise Email, the associated Business Service would probably have a High or Critical Risk as it relates to the Change. On the other end, if I am making a change to a Server that is associated with a Low Risk Business Service, then that Change probably doesn’t need the same scrutiny as the former.
It is worth noting that there could be other factors beyond the plain risk of the Business Service to the business. Impact is something that will come up as different Changes can affect smaller subsets of a Business Service. This is something that will continually come up and will help grow your SCSM Change Management Process. Once again you must start somewhere, and these other variables will help you identify your next steps.
Mistake #2: Not Getting the Right Reviewers and Approvals
Another valuable field on a Business Service is the Service Owner. This is the person that needs to know every Change that could affect the Business Service(s) that they own. Adding this person allows us toproperly involve the individuals for a given Change and eventually automate the reviews and approvals for these Changes.
These individuals can be the “final” approval for lower risk changes instead of having to go through the CAB for approval. At the end of the day, we want our SCSM Change Management process to run as smoothly and efficiently as possible. The technicians making the changes shouldn’t have to wait for a weekly CAB Meeting in order to get a Change approved (if it doesn’t need that CAB Approval). On the other end, we want to make sure that we do involve the CAB if a Change is being made to a Server or Business Service that has High or Critical Risk. This is the place where you want to make sure that the right person is informed of what is going on regardless of anything else.
Mistake #3: Improper Maintenance of Business Services
So you have followed this entire blog and you have everything in the system. Pat yourself on the back because that is an extremely difficult and time-consuming task. Guess what? There have probably been another 5 servers (or more) built in your environment this week. Your data is already out-of-date.
You MUST build process around Server builds. Every single server should be tied to some form of a Business Service, otherwise, what is the server’s purpose to your organization? There should be a process (and Activity) around what happens when someone requests and provisions (or de-provisions) a new Server. Any new PRODUCTION server request should flow through some sort of activity that identifies the Business Service it belongs to, or the NEW Business Service it is facilitating. This is where you will catch this missing data.
Closing Thoughts
I’m being very biased in my opinion here, but you have a TON of options as far as how you proceed. Service Manager (and the Cireson Portal) can get you to where you want to be. There are options if you go down the traditional SCSM à Orchestrator Route. There are options if you go down the SCSMàOrchestrator à PowerShell Route. There are options within the Cireson Portal itself. The hardest part is getting to a starting point. Once you get there, Service Manager and the Cireson Portal can help you get to the next level of SCSM Change Management.
