Before You Implement an ERP System

Back to Knowledge Bank
Posted by: briansittley Comments: 0 0 Post Date: October 19, 2017

There are any number of suggested approaches to implementing a business software system, but a few tips offered by frequent ERP blogger Eric Kimberling contain some key points that we think all software vendors could agree with.  We’ll share a few of those tips, with which we concur, here.  We could add a few more from our own experience, but these provide a great foundation in helping to avoid time and cost overruns.

  • Create your project management organizational structure. Your ERP provider will have a project manager, or project architect, or maybe both as we often do.  You need to have one on the client side too.  As well, remember (as should your provider) that there are a great many non-technical project aspects to attend to that involve work streams, people issues, organizational changes and the not-so-simple mechanics of having staff available for training and implementation when they already have their ‘real jobs’ to do!
  • Define project roles and responsibilities. No two projects are alike.  Your provider knows in advance (or should know) exactly who will be doing your training, your customizations, your technical work and writing your reports.  But ultimately, it’s your project, so be sure you have defined all the roles at your end, and that each person knows who they’ll be working with.  Strike a balance between your “internal competencies and your bandwidth” as Kimberling puts it.
  • Make key strategic decisions regarding your implementation.  Again, all projects have their unique challenges.  (We’ll get 90% of our side right and still beat ourselves up over how we could have done the other 10% better.)  So early in your project, work with your partners to realistically define project phases and timetables.  Hint: all clients and most implementers underestimate the actual time required, and the unplanned hiccups along the way.  Data conversion is typically one large problem area.  Another hint: the less data you absolutely have to transfer from old to new system, the easier (i.e., less costly) your project.  Remember, you can always turn on the old system on the few occasions where a missing piece of old data is critical.
  • Define your future state business.  Don’t fall into the trap of letting your software always drive your business process improvements.  The software should be made to fit the way you do business.  That’s why buying a ‘customizable’ system is so critically important.  Modifications and customizations exist for a reason: they support the business’ intrinsic competitive advantages.  Don’t settle for software or process flows that do not match up with your own best practices.  Defining your future state can often be accomplished in stage one, after you’ve mapped the current state and identified the gaps and technology touch points you need.
  • Think people. Many projects fail or succeed based on how well firms have handled the changes to the organization and to the workflows that a newer, better system require.  Remember that people are always on the critical path to project success.  And don’t wait until it’s time to get folks trained to bring them into the picture.  The time to involve your team is at the very start of your project.  But that’s a post for another time.


Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Knowledge Bank