Click to see: Andrew Abramaczyk of Erie Insurance Co.

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.