The most challenging aspect of change management is not necessarily managing the process, it’s understanding what systems and users will be affected by the change. I have a few ideas on how to track this.
Gather Information Using SCSM Business Services
At a high level, the first thing you want to do in change management is take stock of your current environment. I like to keep it simple and document the names of applications and the servers each runs on. This is because most changes will affect an application and a corresponding server, and you want to see how one thing correlates and affects another.
Accumulating and assimilating this information is a big job, so you might want to break things down by delegating information gathering across the IT department. Depending on your company’s size, complexity and priorities, though, you might prefer to prioritize critical systems described in your disaster recovery plan. Or you could start with major changes implemented during the past year and work down from there.
One tool that might help you gather and document data in your environment is SCSM Business Services. It is an out-of-the-box configuration item class that is visible in the Service Manager Console’s Configuration Items view.
You can see a few fields and relationships right away, but the Service Components tab is where we are going to focus. This is where we can track our business services (or applications) and corresponding servers.
You can add components (and various groups of components) by clicking “add category.” For this example, however, I’m selecting “computers group.”
Any configuration item type in Service Manager can be added by clicking “add item.”
We are only adding a few servers in this example, but you have a great deal of flexibility in how you choose to define business services and components in Business Services.
The key thing is that you have a visual representation of your environment and that you are tracking the right things. Seeing how applications and servers are connected helps you make decisions—or perhaps prevent problems—down the road.
Change Management Best Practices
It’s often the details that make a big difference, and I’ve found that companies that weather change management pretty seamlessly do a few things particularly well. Let’s break down what they are and why they are considered best practices.
Risk
Every change to a server carries some degree of risk to a business service, so it’s helpful to identify and document the risk level of change to services you are tracking.
You can track risk in conjunction with business services and servers in Service Manager. I like to use the Business Service form with “priority” fields to identify risk as critical, high, medium and low. Something like email normally falls under the category of high or critical risk, because it is vital for internal and external communication and information-sharing. If email goes down, how many people might be affected and what would the business impact be? Changes associated with email, consequently, are going to take more thought, planning and backup scenarios than a low-risk application.
Accountability
How many problems could be prevented if one person monitored the big picture, and if they had final approval for every change affecting the business services they owned? Designating and documenting the change owner helps keep everyone informed, involved and accountable. It also helps a process stay intact. Later, you could automate reviews and approvals, so having the framework in place makes it easier to set that in motion.
Business Services provides a “service owner” field, where the accountable person(s) can be noted in the system. This way it’s clear to the entire team, and if a change warrants involvement of the Customer Advisory Board vs. a project manager, it’s noted.
System Maintenance
Once data is in the system, it doesn’t mean that everything is up-to-date. You are going to constantly be caught in a cycle of maintaining accurate data. For this reason, I highly recommend that you set up a process and activity for new server requests and provisions (and de-provisions). It’s a defensive move that will help you catch missing data, so always make sure a production server request flows through an activity that identifies its business service—or a new business service it enables.
Using SCSM Business Services is a way to further mature your change management process. You could take various paths, including SCSM Orchestrator, SCSM Orchestrator and PowerShell or solely use the Cireson Portal. I’m happy to talk through ideas.
This blog has been updated from its original 2019 version, Are You Making These Common SCSM Change Management Mistakes?
