An ERP Project's Organizational Structure

Your business has formalized its organizational structure, hired the right people and incentivized the right behaviors all with the goal of driving a successful business. In my article Set Up Your Project Like a Mini-Business, I argue that organizations should apply the same rationale when setting up their ERP projects.

An effective enabling structure is key to delivering a successful ERP implementation project. It facilitates effective execution, rapid decision-making and knowledge transfer.

In terms of structure, the steering committee should sit atop the project hierarchy and be made responsible for executive-level strategic decisions (learn more about the ERP steering committee here). The core team is below the steering committee on the project hierarchy and should be charged with managerial and functional implementation responsibilities, including end-user training (learn more about the ERP core team). The end-users are underneath the core team and collectively comprise the ultimate project "client".

Training

We devised our training methodology based on the philosophy that an implementing organization should largely become self-sufficient in the future management of its ERP system.

Conceptually, our approach is simple: we help make the core team members super-users or, in other words, ERP experts in their respective functional areas. These super-users ultimately become responsible for training the end-users (among other things).

Although I set out the formal training requirements below, it's important to mention that much of the training takes place outside of the classroom, as part of the implementation. For example, the core team members accumulate and demonstrate their knowledge of processes and systems during the walkthrough presentations and the departmental pilot phase (among other things). And, select end-users get practical hands-on training when they run the business scenarios through the integrated pilot testing.

Core Team

The core team receives its formal, in-class training early on in the implementation. In terms of formal classroom training, we recommend the following four-course program for the core team.

Course 1: Overview Session, ERP System Theory and Specific Application The core team members are trained on the general theories relating to the ERP system as well as the modules that collectively comprise the ERP environment.
Course 2: Navigation Session The core team members participate in hands-on software training with the goal of learning how to manipulate fields and navigate screens, forms and sessions.
Course 3: Functional Training The core team is split into groups representing their respective functional departments. Each sub-group is trained on the specific system modules that relate to their department.
Course 4: Administrative Training The core team members are trained on concepts relating to software administration, including the application of patches, upgrades, and security access (among other things).

End-User Training

Poor end-user training is a leading cause of ERP implementation failure. Simply put: if front-line employees fail to use the system as intended, the system will neither be capable of processing transactions nor generating meaningful reports.

For this reason (among others), it's critical to ensure that the training accomplishes what it's intended to do: make end-users proficient, comfortable and willing to adopt the new business processes and systems. We do this by incorporating quality control and assurance processes in our training methodology.

Training course preparation - including the drafting of documentation and manuals - should take place during the business process mapping phase. This is the phase during which the project teams plan their organization's evolution from its current state to its future state. It, therefore, makes sense to - at the same time - plan how to get the end-users from their current states to their future states. (However, the course won't be delivered until close to the end of the implementation project.)

Here are the key components of an end-user training plan:

Training Strategy

Under this umbrella, the teams determine the following (among other things):

  • Deployment method: in-house/outsourced (we advocate in-house)
  • Management of geographic constraints
  • Selection of training locations
  • Establishment of training schedule
  • Definition of training assessments
Training Budget

A fulsome budget must be established, including the costs of the following:

  • Course materials
  • Travel costs
  • Consultant costs
  • Materials and resources
Selected end-user training As you will recall from the organizational structure discussion above, certain end-users are on the core team. These users require early training to assist with the systems testing. This early training also gives the teams an opportunity to test and revise the end-user training courses before and documentation.
General end-user training The general end-user training plan should identify the participants, logistics, schedule, and location, among other things. It should provide a detailed course schedule and should include training course material preparation (documentation). Finally, the training plan should contain an effectiveness assessment component. Two purposes of the assessment component include: 1) determining whether the end-users were well trained, and 2) determining what follow-up training is required.

As with each phase of the project, it's critical that training be delivered on-time, on-budget and in accordance with performance expectations (in this case, training effectiveness). As discussed above, all of these elements are built into the training plan.

Data Migration

Effective data migration is another critical driver of ERP success (and poor data migration is a critical driver of ERP failure).

Consider, for example, the case of Canadian airline Westjet. In 2009, Westjet failed to properly migrate 840,000 customer transactions as it cutover to its new CRM and online reservations systems. Consequently, its online booking system repeatedly crashed upon launch and led to an unanticipated and unmanageable flooding of call centers. Four months after the cutover nightmare, call center wait times had still not been reduced to pre-cutover levels. Further, Westjet required six months to repair the damage caused by its poor data migration effort. The irony of the story is that the problems occurred in the context of a new system that was intended to improve its customer service and reservations processes.

To avoid problems like the ones suffered by Westjet and many others, the implementing organization needs to execute an actionable data migration plan. Using our Milestone Deliverables methodology, we develop a comprehensive data migration plan that includes: data location, quality control, timing, and testing.

Our data migration plans generally include the following four components:

Testing and Quality Control In this phase, the company plans the various data testing and quality control ERP environments. Each testing environment is represented by an instance of the company in which certain data, settings and programs are tested. Generally, we plan for six different instances of the company. These different environments are: virgin, sandbox, development, quality assurance, migration and production.
General Migration Strategies The implementation team sets out the various strategies and methods for locating, cleansing, migrating and maintaining correctness of data (learn more about migration concepts relating to cleansing and migrating).
Static and Dynamic Data Strategies The team sets out a table that contains the key migration information for each category of migrate-able data. They should generally track the following for each data source: the relevant table, the original data source, the type of data (static or dynamic), the cleansing method, the migration method and the “maintaining correctness” method. Learn more static and dynamic data here.
Timing Planning an appropriate data migration schedule is critical and should be based on a consideration of: 1) the burden on the implementation team, and 2) the validity of the data. We generally prioritize the following data categories from earliest to latest migration: static data, long-term dynamic data and short-term dynamic data.

 

Read the rest of our series: An Introduction to Milestone Deliverables

Part 1: Driving ERP Implementation Success

Part 2: ERP Organizational Structure, Training and Data Migration [you are here]

Part 3: A Structured Approach to Organizational Change Management

 

Need to learn more about Milestone Deliverables?

We wrote the book. Read Milestone Deliverables: ERP Project Management Methodology.

Milestone Deliverables Book