Insurer conquers change management

Implementing any type of formal process is never easy, but modifying an existing process that works is even harder.

That's what we found to be the case at Erie Insurance as we automated our IT change-management process. Change management refers to the addition, modification or removal of any component of an IT environment, not just hardware and systems and application software. A firmware upgrade to a switch and patch installation on a server are a few examples.

Six years ago, we had a mostly manual change-management process. In the years since, we've made incremental changes that resulted in our present automated system. We moved slowly and precisely, with the idea that we could modify our plan as we went. An early change to the process was our move to an e-mail-based system that provided some workflow elements.

Then we began to align the process with the best practices defined in the IT Infrastructure Library (ITIL) framework. Later, we used SupportMagic (now called Magic Service Desk), the change-management module in BMC Software's IT service-management tool (ITSM). At first we used it in parallel with our e-mail-based system, but eventually we migrated our entire process to it. Erie Insurance's roughly 500 IT employees are all trained to use SupportMagic, but it's most often used within the operations and application-development groups.

There were some bumps along the way that caused us to stop and rethink an approach, a step in the workflow, or even how a screen looked and how the business rules should work. What follows are some of the biggest challenges we faced and how we worked around them to achieve our objectives.

Workers thought they always were being watched.

This was not necessarily true. We put a formal ITIL wrap on the change-management process to ensure consistency and compliance. We had to hold management accountable for how their staff used the change process and for how well changes were performed.

We had to build our process into the ITSM tool in such a way that we could easily see how it was being followed: Were we consistent? Were we improving? We needed to be able to pull the core data components of the request for change (RFC) easily, correlate that data to key performance metrics and ask: Are we improving on these metrics?

Now we easily can run reports based on key performance metrics and provide good, reliable feedback to staff, plus identify gaps in the process that need to be filled. We can also more easily set targets against which everyone can be measured. Some of these metrics are the number of late approvals, complete and unsuccessful changes, incomplete and unsuccessful changes, changes that were not completed within the change window, and changes that caused a service impact.

Staff was sensitive to the results of a change or its impact on service.

This was a big factor that we had to overcome collectively. One of the challenges we faced was that originally, the people performing changes had to look objectively at what they did vs. what was documented, and then evaluate whether their changes were successful or unsuccessful, complete or incomplete. Staff had a hard time doing this, so we automated the classification process.

Instead, we built several business rules into the tool that would look at the postassessment data entered by the worker performing a change and automatically flag it as complete, incomplete or withdrawn. Then we ran a management report against that assessment to determine whether the change should be further considered successful or unsuccessful.

Automating this process eliminated much of the emotion involved. And by management not overreacting to the results of a particular change but instead analyzing the metrics to see how well the entire change process is being used over time, we can identify areas that need attention and employees who are struggling with managing their changes.

Would we control automation or would it control us?

We didn't fully automate our process until we experimented with different workflow approaches and RFC-logging abilities. Going through this process allowed us to determine how we needed a tool to work and to develop business rules that met our needs. It also enabled us to restrict who can modify a change, who can approve at specific points in the workflow and who is responsible for assessing the change. We came out with a solid process that works better because we shaped the automation process, as opposed to having an automated system dictate how our process works.

We needed an audit trail, a better way to track changes.

We also had to overcome the problem of using an inadequate tool, our e-mail workflow, to manage our changes. The e-mail system lacked an audit trail, so it could not track changes as they went through the approval and assessment process.

We focused on how to track changes properly and audit what was done to them, which helps tremendously with both Sarbanes-Oxley audits and individual performance assessments. Now we can see where a change is in the workflow, when it was made, whether or not an approval was made and when, and whether or not any fields in the original RFC were improperly modified and by whom. This in turn allowed us to determine key areas for improvement. For example, we can target managers who repeatedly approve their changes late.

Entering multiple changes with different start dates.

What was the one thing we could build into the tool that would be a selling point for anyone using it? When we were determining this, the concept of multiple changes with different start dates came to mind.

In rollouts there are often places where a change has to be repeated on different devices or code, such as for patch management, virus updates or firewall changes. In our manual system, changes would need to be re-entered and submitted each time they repeated. We decided to build a feature into the tool that would let change initiators save their change as templates. This allows them to call up a change at a later date, make minor modifications and resubmit it, obviating the need to re-enter RFCs. This feature was a huge selling point and a big timesaver for workers making changes.

These are just a few of the obstacles we overcame while incorporating our change-management process into our ITSM tool. While we would consider the effort successful, we also understand that everything is open for debate and can be improved. We continually strive to ensure we are heading in the right direction, and we always look for ways to make things more efficient and effective.

Abramczyk is manager of IT Information Services within the Operations and Support department of Erie Insurance Group. He can be reached at Andrew.Abramczyk@erieinsurance.com.