ManageEngine’s change management journey in a nutshell
ManageEngine's journey from a startup in the late 90s to a SaaS enterprise in the 2020s is well-known. However, little known is how our experience with managing changes has contributed to our growth both as a company and in the maturity of our products.
Despite our experience with a wide variety of changes, our formula for learning and improving our change management framework has always been simple:
- Spot the oncoming challenges in changes.
- Establish processes and technological interventions to tackle them better or avoid them.
This two-step method has brought us from a novice organization that handled changes in multiple silos, to an enterprise that has a semi-automated, foolproof change management system. Here's a snapshot of that journey:
|
Change management area |
In the 2000s |
In the 2020s |
|
Workflows |
The process operated in silos. Initiating the change, approvals, asset management, and execution happened through separate mediums. |
We have a unified change management workflow with assets, change management processes, and service requests brought under a single window, interconnected. |
|
Approvals |
We used to send emails manually to get approval. This allowed room for error, time delays, and inefficiencies throughout the change life cycle. |
Automated notifications inside our ITSM tool, automated emails, chat, and remote VPN ensure quick, smooth approvals. |
|
Assets |
We maintained assets in a separate database. After making changes to an asset, we needed to manually make the modifications in a separate database. This manual work took up time and left room for error. |
We’ve integrated our configuration management database (CMDB) with our service management tool. Once a change is initiated through that tool, the asset is automatically linked to the change. The process of updating and tracking assets is smooth, and there is almost no room for error. |
|
Change management style |
Reactive change management: Changes were executed when we felt the need for them. For instance, after we noticed a performance issue in an asset. |
Proactive change management: As we track all changes and learn from them, we create procedures (like periodic maintenance) and technical interventions to ensure we eliminate the performance issue beforehand. |
|
Speed and accuracy |
Without much technological support or well-defined procedures, we took more time to execute changes. Even if we needed to upgrade the operating systems for 10 machines, we did it manually. It took time, and there was room for error. |
With enhanced test environments and advanced procedures, our speed has improved. Even if we need to upgrade 50 devices, we do it almost instantly using the concept of imaging. We select devices from our device management servers, create the necessary scripts, verify them with our checklists, and tap a few buttons in our CMDB to get it done. |
This is but a snapshot of the changes in our change management framework itself. The early 2000s saw us maintaining assets in a database (like spreadsheets or a local webpage) and making the change elsewhere, while using a completely different tool to update and track the changes we made to the assets.
After we implemented ServiceDesk Plus internally, we brought in a change management process to include initiating change tickets, approvals, and closure inside the tool. The assets were still managed in a different database, and we still had gaps and inefficiencies in our process. From such a process that functioned in silos, we have now moved on to an integrated, proactive style of change management with semi-automated execution.
If we need to install a server, we now have tools to guide us on which location, in which country, in which rack the server is going to fit in. We tag the server using a serial number as we install it, and our ITSM tool is immediately aware that a change (installation) has been made in a particular rack, and the change management starts right there. Then every change, including provisioning, inspection, repair, and maintenance of that server, is tracked without any trouble.
How did we bring about this improvement in our change management? By constantly learning, and improving our frameworks. That is what you’ll see in detail throughout this e-book.
How we classify changes
The first and rather instinctive step of our methodology is to classify a change request. We classify changes in such a way to help our IT leaders make decisions quicker and to put a set of processes immediately in motion. That leads us to two categories:
Changes by impact:
To create an adequate framework to handle them
Changes by nature:
To introduce company-level principles and policies to execute them
In this e-book, we will predominantly focus on how we handle changes by impact. In a later chapter, we will briefly discuss the organizational measures and practices that will help you handle changes by nature.
|
Changes by impact |
Changes by nature |
|
|
Changes by impact
Most of our IT changes fall into this category. Each of these types of changes has a different impact on the organization and also differs in how we use our frameworks to implement it.
|
Type of change |
More about the change |
Examples |
Approval |
Risk involved |
|
Normal changes |
They go through a comprehensive framework with planning, implementation, and review, similar to our overall change management methodology. |
Server upgrades and antivirus upgrades |
Need approval |
Low to medium risk |
|
Standard changes |
They are pre-approved. The technicians will carry them out straight away with the necessary supporting evidence. In the event of a change being unsuccessful, we can either fix it or roll it back. |
Periodic maintenance of systems; patches; and antivirus updates |
Don't need approval because they are pre-approved |
Low risk |
|
Major changes |
They have a significant impact on the organization. We handle them with thorough approvals, and they need to go through an additional set of processes and checks. If unsuccessful, a major change can impact a significant number of users and may cause monetary or reputation losses. |
Migrating our services to a new server or moving on-premises services to the cloud |
Need approval and may involve the change advisory board (CAB) |
Medium to high risk |
|
Emergency changes |
These are typically responses to fixing the damage done during an incident. We expedite approval stages for emergency changes and focus on execution, using as many resources as needed. |
Server failure or a data center security breach |
Require approval and oversight from the CAB |
High risk |