Preparing for ERP Implementation: Getting Started on the Right Foot
Client planning and preparation can provide a strong foundation for your company's ERP implementation methodology.
Client planning and preparation can provide a strong foundation for your company's ERP implementation methodology.
Table of Content
So, you’ve decided to move forward with a new ERP. While that’s an important decision in itself, it’s only the first of many more yet to come.
You’ve probably gone through a lengthy sales process, met with several different VARS, (Value Added Re-sellers) and communicated your project’s overall goals and objectives. Depending on your purchase strategy, you may have prepared a summary level or detailed requirements document.
Hopefully, best practices such as thoughtful VAR identification and due diligence, as well as, a comprehensive review and selection process were used, and you negotiated a beneficial implementation agreement.
If you haven’t completed these tasks or want to learn more, you might want to take a look at Navigating the ERP Sales Process: Successful VAR Selection and Navigating the ERP Sales Process: Pre-Sale Requirements Review.
A lot of planning and documentation goes into an ERP implementation. Project planning, organization and task completion, assigning resources and setting the project ground rules all need to be completed prior to the project start date.
ERP implementations are controlled using a specific methodology. An example implementation methodology appears below. Note how the preparation activities are a part of the “Planning” phase.
This post discusses some best practices to help ensure that you get your project started correctly. The document also identifies some “pit-falls” to be avoided, which often result in a less than optimal result.
In my experience, five top best practices have emerged that can have a positive impact on client preparation:
Visible executive ownership is the number one success driver across all ERP implementation tasks and phases.
Employees look to company executives for both direction and a sense of the importance placed on company initiatives. If the Executive team doesn’t visibility support the ERP implementation and communicate its importance, chances are that the project team won’t take the project seriously.
Host a project team meeting and communicate executive ownership, as well as, explaining the project’s importance to the team. This is a critical project point. The internal project team meeting should commence prior to the project kick-off meeting.
Setting realistic project timelines is important to a successful implementation. Realistic schedules keep project participants focused, reduces project team anxiety and supports effective accountability. Remember when setting project timelines, unless you hire or assign dedicated implementation resources, each project team member already has a full-time job, and in most cases will not be able to spend 100% of their time on the ERP project without sacrificing other duties.
Unrealistic schedules are frequently set. More times than not, this practice results in short-cutting which causes already completed tasks having to be re-done. Unrealistic expectations, short cuts and chaotic task completion do not support a timely implementation. In fact, unrealistic implementation expectations rarely achieve the timeline set.
Sometimes, the need to set an extremely short timeline is warranted (e.g. acquisition or sale situation). In this case, ensure that the implementation goals to be achieved reflect the time scheduled. Consider implementation phasing or a “layered functionality” approach to ease the process and improve implementation quality.
Creating effective goals and objectives keeps the project team focused and supports accountability. Goals and objectives should be jointly set by the executive team and project team members. Remember, effective goals and objectives should:
Goals and objectives apply to all implementation phases. For example, they serve an important role in the requirements gathering process, as system requirements must address specific company strategies and objectives.
Be sure to keep goals and objectives consistent with the actual need to achieve them.
Let’s use the loading of historic data as an example of a misguided goal. A company may want to load a large volume of detailed historic data. What it forgets to consider, is that the data needs to be scrubbed, converted, tested, loaded and reconciled. All of these tasks need to be completed by the project team before “Go live” and quickly become unmanageable.
Again, unrealistic goal setting results in budget overages and usually, the inability of the company achieve the goal. Be open minded and think out of the box. There are usually alternatives that can be explored and used.
An ERP implementation utilizes resources from many different company roles. It’s important that each resource understands their role, and that all resources are moving in the same direction. The goals and objectives discussed above play a significant role in aligning resources.
Create project teams from each functional area as required. Assign goals and objectives to each team and designate a project team leader. A team leader cannot be effective without equal levels of responsibility and authority. If you’re going to hold project team leaders accountable, supply them with the tools to be effective.
As the project leader of many implementations, I can absolutely say that you must support the team leader with authority commensurate with the responsibility assigned (e.g. setting project task prioritization over daily non-project tasks). At a minimum, build an effective communication path between the team leader and the applicable project team member’s manager.
Build your teams with members from different company levels. In many instances staff level employees have a better understanding of day-to-day issues and solutions than more senior personnel. While managers and other executives are valuable team members, in some situations, they may not be as up to speed on current day to day processing issues as needed.
Assigning team members improperly, can have a negative impact on aligning requirements to “true” company needs and often results in having to re-do completed tasks after the implementation. Including team members from all company levels also results in increased system acceptance and less criticism at the project’s end.
A successful project must have a defined set of deliverables (i.e. scope). I don’t think you’ll find a VAR who’ll agree to implement an ERP without some idea of the project tasks to be completed. They know that if they go down that road, they’ll end up giving back most of their profit, and maybe more, to the customer by having to complete non-billable tasks to meet customer expectations. If unhappy, customers simply will not pay, or will contest project billings, placing the VAR in a position of having to negotiate settlement for each payment due.
By the same token, a customer would probably not sign an SOW without knowing exactly what they’re getting for their ERP dollars. Notice that I used the word “probably”. To my amazement, I’ve encountered many companies who invest many thousands of dollars implementing an ERP solution, then just assume that all implementation tasks they have in mind are included. This is a sign of inexperience or lack of focus. ERP reporting is especially prone to this.
The most dangerous word in an ERP implementation is “assume”. Ideally, get a scope document as a pre-sale deliverable prior to signing a Service Agreement or SOW (Statement of Work). The salesperson should offer to provide a summary project plan explaining all “in scope” tasks to be completed, as well as a project budget. This is a critical project control and should not be overlooked.
If the VAR you’re considering, or already signed with, cannot provide an adequate plan as to how they are going to complete implementation tasks including a project budget, can you really expect them to complete an effective implementation? This is like trying to build a house without a blueprint. Project plans and budgets should be a “no brainer” for any VAR. If they can’t provide quality scope documents, project plans and budgets, this is a major red flag. Get out as fast as you can!
Many software publishers provide their VAR’s with a prepared implementation methodology (a sample methodology is illustrated in the introduction section above). VAR’s may use a modified version of the publisher’s methodology, or something they’ve developed internally.
Regardless of the methodology used, a great deal of emphasis should be placed on project kick-off and project governance. Project planning, organization, scope, reporting and project ground rules are reviewed, modified and agreed to in the kick-off process.
Be sure to schedule a project kick off meeting with the project team and the VAR’s consultants. Make sure someone from the executive team shows up to lend a sense of importance to the meeting and the process. Don’t shortchange this, it’s important.
During the kickoff meeting be sure that project governance documents such as a project charter, project plan, status report, issue identification and escalation, and change order management are reviewed and understood prior to the project team’s approval.
Proper client planning and preparation can provide a strong foundation for your ERP implementation. Organization is key to the project’s success, as is a well-documented process, controlling the inevitable project changes, is critical in “keeping thing on track” both operationally and financially.
Using the best practices and avoiding the pitfalls provided, can assist in a successful project commencement.