CustomerTalk

Organizations decide to undertake ERP implementations for a variety of reasons, but many, or even most, of us are driven by a vision of competitive advantage and strategic gains. ERP systems provide the data and technology infrastructure for real-time, direct business transactions, new service delivery models, and customized user interfaces to an organization's services. The result is more efficient transaction processing and fast, intuitive services that will give your organization the competitive advantage it envisioned.

Because ERP implementations are complex, far-reaching, and challenging to complete, many organizations lose sight of their strategic goals and expected benefits before they complete the implementation cycle. When you set out on the ERP trail, it is important to remember that before you can add the portals and e-enabled real-time business transactions, before you use the data infrastructure for balanced scorecards and performance metrics, before you start analyzing your business transactions for strategic decision support, you have to keep the business running. You have to know how your business runs in your current system, how it is going to run in the new system, and how you are going to keep it running while you're in the transition.

Simply stated, ERP implementation requires the same careful management of people, processes, and technology that you practiced before you moved to enterprise-wide systems and data. If you haven't figured out how to keep the trains running on time while you're leaving the past world and moving to the new, you may never reach your future destination.

ERP implementations mean big changes in how people work. The simultaneous introduction of new data, new tools, new forms, new reports, new screens and pages, and changed business processes is overwhelming to even the most sophisticated employee. The expansive change can result in chaos or opportunity. To lead an organization through such massive change, you have to understand the past, manage the present, and paint the vision for the future. The process you use to navigate your organization through the transition period will quickly determine whether you are a victim or leader of your implementation and whether or not you realize the strategic goals of your ERP investment.

University of Michigan Before ERP
As the result of a strategic plan, the University of Michigan completed three PeopleSoft implementations: financials, student administration, and human resource administration. Each implementation brought significant change in the way people did their jobs. With each implementation, the University made progress reducing the negative impact of change on productivity and moving more quickly to the strategic advantages ERP affords. Lessons learned about managing the change of each implementation were applied to the later implementations to make the transition faster, easier, and smoother.

However, the challenge of communicating to the organization how business was designed in PeopleSoft, understanding the impact of implementation on each department's local processes and systems, and guiding employees through the transition was significantly more complex and daunting than the technical transition involved in the implementations.

The First Implementation: Ready or Not?
One of the critical assumptions established for the transition to ERP was that departments were responsible for changing their business and for seeing that their employees were ready by the "go-live" date. As is usually the case with ERP implementations, the software was being configured and implemented centrally
by a cross-functional team with representatives from across the entire university. But changes in business processes had to occur within every department as well as in the central transaction processing units. Each department appointed a liaison that served as the link between the project team and their unit.

The project team invested significant time into understanding and documenting the current business processes in order to analyze their consistency with the design of the software. The teams then documented the way the business processes worked in PeopleSoft. Even though the project team created the process flows for software configuration, they proved to be critical to communicating the business changes that had to occur at the time of "go-live".

The change management team converted the process flows to high-level business diagrams that were presented in workshops to unit liaisons and their staff responsible for processing business transactions. Software training followed the transition workshops to assure that every person who might need to touch the software had training in the complete system. The approach was based on the assumption that staff who attended the business transition workshops and completed software training would be well prepared for the new business processes.

But within weeks after the go-live celebration for the financial implementation, it became increasingly and painfully apparent that business was almost broken. The software worked, the architecture performed, but we couldn't get business done. The departments across campus were confused about how to conduct their business internally and how to communicate transactions to the central processing units. Business slowed to a crawl as backlogs of transactions piled up. How could such a well-planned change approach result in such difficulty?

Lessons Learned
The important lesson from the first implementation was the realization that simply understanding how business needed to change hadn't changed the business. It was as if we had trained for the marathon by reading the best books on long distance running, but we didn't put on our running shoes and run the miles to be in condition to complete the race. For the next two ERP implementations, we used the same methodology, but we took it much further. The importance of the role of the unit liaisons increased, as we moved to put full ownership for change in the department. Our goal was to transfer the knowledge about the system from the project team to the users on a schedule that would bring their readiness and the system to production at the same time.

After documenting the processes, conducting the transition workshops, and delivering the software training, the entire university went on to manage the business of changing the business. Here is what we learned along the way.

We limited scope of the initial implementation to core functionality required for mission critical business processes and delayed optional features to after "go-live". We defined "optional" as "we won't die without it".
We instituted practice labs for power users. Power users brought real work to the labs to process transactions in a "controlled", highly supported environment before the system and business transactions were available to the entire user community.
We initiated "driving tests" for staff performing mission critical business processes with required throughput. If users couldn't perform mission critical processes in the controlled environment, additional training was provided before access to the production system was granted.
Implementation support staff from the project team worked with unit liaisons and departmental staff to develop "change" plans for every department. The plans included readiness milestones. The implementation support staff worked with the departments to track the plans.
User readiness was assessed periodically and at milestones during the implementation cycle and reported as one of the categories on project status to the project's executive sponsors. User readiness, as assessed according to predefined criteria, was one of the conditions for the "go/delay" decision before the system was turned on in production.
Rather than communicating directly with the broad user community, the project team provided communication devices such as announcements, targeted email messages, memoranda, and guides about the project to the unit liaisons of each department. The departments customized the communications to their own internal mechanisms and tools. Internal departmental newsletters, email groups, and staff meetings became the vehicles for communicating impending changes to users and motivating them to prepare. General knowledge increased significantly over the first implementation.
We supported development of internal departmental procedures for the mission critical processes. Project team members became expert, on-site resources to the transaction processing units to maintain throughput during the transition to the new system. Some of the large processing units hired additional temporary staff to assure that throughput was maintained.

Back to the Future
Taking care to communicate, plan, track, and guide the transition to the new business processes enabled system and process stabilization in a relatively short period of time. Quick stabilization enabled us to more quickly add functionality and features that were important but initially "out of scope" due to our strategy of reducing risk to mission critical business processes.

Now we're moving beyond thinking of ERP as the "new" business processes and systems and we're back to the future. We're investing our time in developing e-business and data analysis tools. In essence, taking care of business while changing the business has positioned us to realize the strategic promise of e-services and high-end analytics that lead us to do ERP in the first place.

For more information go to: www.peoplesoft.com/go/pt_he_um

Want to know more about the PeopleSoft products and services highlighted in this article?
Click here to enter your business information. A PeopleSoft representative will contact you.