I want to lay something on the line here, right from the outset: an ERP implementation is not an IT initiative. When an organization believes that it is, and tasks the IT department with everything from software selection to implementation to training to internal communication, it is setting itself up for ERP failure. Sure, the system might get up and running. And staff might actually use it to perform some basic functions. But it will probably never provide the true operational benefits it could have and should have. And that, my friends, is ERP System Implementation failure — plain and simple.

There is no arguing — nor should there be — that the IT department plays an integral role in ERP implementations. These are the men and women who are the masters of the technical side of the system, handling configuration, customization and all the other complicated stuff that the corporate suits have incredibly little to do with — and that the system can’t run without. But an IT staff, talented and knowledgeable as they are, typically are not the operational experts that need to drive an ERP project. Speaking in generalities, they don’t tend to have the broad, all-encompassing vision of the business that a COO has. Further, they don’t tend to have the authority to make the millions of top-level decisions (about business process management, about standardization, about streamlining) that need to be made in order to derive ROI from an enterprise software solution. Yet they are all too frequently given the responsibilities of an enormous (and potentially thankless) job: choose, implement and oversee the adoption of an entirely new way of doing business. Oh and manage the help desk too . . . you know, during “free time.”

So how should the skills of an IT department be utilized in an ERP implementation? Below is a partial list, highlighting some areas that the IT department might be able to provide invaluable insight into.

  1. Participating in ERP software selection, including review of the business process management and blueprint documentation
  2. Working with a third-party expert to map the “to be” business processes against the software to determine areas of customization
  3. Helping to determine what the organization will do about the gaps between its needs and the system’s capabilities
  4. Working with a third-party expert to implement and test the chosen system
  5. Creating a plan to determine how the organization will handle user and system issues after the cutover
  6. Participating in the determination of a legacy system phase-out approach
  7. Contracting with a third-party to determine a training strategy, materials, etc.
  8. Determining a multi-site training schedule

Of course, each organization is run differently — and has different people, with different skills, in its ranks. Some IT personnel are crackerjack whizzes at operations. And some wouldn’t know an ERP system if it sat on their lap. So view the above through the lens of what you know about your company and its people but remember: although IT employees likely are functional experts in a very important aspect of the system, they should not in charge of the project. That is a job for the executive level, and to pretend otherwise is doing a grave disservice to both the talents of the IT department and the future of the business.

Find out more about ERP implementation pain points — and critical success factors — at our webinar tomorrow, Review of Panorama’s 2012 ERP Report.

Posts You May Like:

How to Overcome Change Fatigue by Fine-Tuning Your OCM Approach

How to Overcome Change Fatigue by Fine-Tuning Your OCM Approach

Have you recently selected new ERP software for your organization? As you prepare to begin implementation, it's important to assess how your employees feel about the change.  If you've undergone other changes in the recent past, your employees might be suffering from...