Acceptance is the Key to Successful System Changes

Change Management in a Fintech ERP Replacement and Standardization Project

I was assigned the role of organizational change manager on an international ERP system replacement project for a multinational captive leasing corporation. As the first change leader on the project, it was clear that the IT-based project team thought my role was to “make people do what we want them to -- without question.” The deployment managers and business analysts knew what the new suite of systems could do, but they struggled each time a local office described their unique requirements because of regulations, heritage, or current system capacity. The project team wanted to be able to drop in the new suite of systems, train the staff, and move on. As you might expect, deployments were not going as smoothly as the project team, nor the executive team, desired.

In fact, projects were failing. They were taking too long to complete, they were implemented poorly and people didn’t understand how to marry the new systems with their existing processes (many of which were manual or off-system processes). As part of a newly formed PMO, I represented organizational change -- the human side of the project (communication, training, reinforcement) and with the team created a world-class project deployment system that cut project times in half while making sure the right development was completed, that people accepted the new systems and could successfully use the new systems to support their business processes.

Even after three long deployment cycles, the project team could not articulate how processes flowed in the new systems. That lack of a clear future caused anxiety in offices getting new systems and made it impossible to plan for any organizational changes. Only after go-live, when offices were struggling to maintain productivity thresholds could we say they needed help. After two failures in a row, the PMO pulled together a team to walk through every process supported by new systems and document, step-by-step, how they would work. This Operational Run Book concept transformed every part of the project.

I used the Run Book to create an impact assessment that allowed us to forecast the impact of new systems and processes on an office. Management teams could now clearly see which departments would need extra coverage at go-live day, and in 6 months when systems had been fully adopted. This change eliminated the 16-hour workdays and the months-long backlog previous deployments had experienced.

I developed a model office organization structure based on roles and responsibilities allowed in the system. This quick reference guide let management teams visualize where they needed to move headcount or re-assign responsibilities based on segregation of duty conflicts. Previously, problems weren’t identified until employees were prevented from fulfilling their tasks after go-live because of SOD conflicts, which caused high-priority help tickets and employee and customer disappointment in the new environment. This issue was eliminated with the model office.

Leading a small team, we proposed, edited, tested, and launched a business process simulation exercise that offices use just before go-live. The simulation ties together system training, process changes, role changes, and data flows to test their ability to function in the future environment. Any conflicts or confusion in new processes is addressed during the simulation rather than during the high stakes of the first weeks after launch. The successful completion of the simulation is proof to executives that the people are ready to go live.

I documented a global communication plan that spans the life of the project. Each phase has a focus and topics become more specific as employees get familiar with the change. There is freedom for each location to address resistance specific to their project while the general flow of the communication remains consistent. The plan guides local teams and ensures they have topics to keep their locations engaged and interested in the project.

As the conduit and the only constant role between all global projects, I had the opportunity to connect project teams who could benefit from collaboration. The cross-office collaboration created a method for employees experienced in the systems to share best practices, coaching, and reinforcement training with newly launched offices. This sharing provided a stronger case for system change requests and new features; if multiple locations asked for the same functionality, there was a good chance all offices could benefit from it.

Early on in my position as Change Manager, it was clear that the IT-based project team thought my role was to “make people do what we want them to -- without question.” One of the best parts of this job has been to see the slow transformation of our own project team’s acceptance of their role in the change. Person by person, I have watched managers, supervisors, and analysts begin to internalize and own their role as agents of change. They have moved from a push mentality to a pull mentality; they are now coaches, negotiators, and cheerleaders. In turn, my role has changed from heavily influencing thought leaders to spot-coaching particularly vexing resistance.


Want to hear more about how change management can make you more successful? Let's connect!

0 views0 comments

Recent Posts

See All