Your New ERP System – Taking It Live

While you are still very new to the whole process of implementing your new ERP system, someone will start to discuss the implementation process and how you plan to take the system live.  I bet you never guessed the tough questions you would face. Especially when the world is full of horror stories of the calamities that befall companies getting this wrong.

Only this week, TSB was all over the news with an upgrade process that brought their entire system down.  Issues with access, data protection etc. have led large numbers of their customers to transfer their accounts.  Although this article isn’t intended to review what went wrong there, in fact, IBM is on their way, but to consider how stories like this affect people’s decisions about when and how to take a system live.

There are three main deployment methods:

  • Phased roll-out – involves changing to the new system incrementally, over an extended period. An incremental change allows for the early implementation of key features. Phasing ensures that any issues or complications are isolated from working processes that are already online.  However, it takes longer, is more expensive and can bring complexity in terms of bridging the solutions.
  • Parallel adoption – involves the new ERP and legacy systems operating simultaneously. This approach allows users to learn how to navigate the new system while retaining access to familiar and established working environment.  During a changeover, the new system and the existing one run side by side for an agreed period, to ensure all aspects of the new system work correctly.  Both input the same data and perform the same processes, to compare outputs.
  • “Big-bang” – involves cutting overall functionality in a single process, typically over the weekend. Many commentators see this as hugely risky, as there are no guarantees that everything will work.

The rest of this article is not a balanced consideration of the different options, allowing the reader to make their mind up.  On other topics, I’m happy to adopt that approach, but not in this case.  For me, a “big bang,” with consideration of any phasing, is the only way to go.  So, before I outline what, based on 20 years implementing ERP systems, I am confident is the only approach to consider, let me present my arguments to avoid parallel adoption at all costs.

The critical point to remember is that ERP projects require complete integration of people, process and system.  Further, it is often the case that any failure is to do with the quality of testing and education, rather than a fault with the system itself.

My issues with parallel running include:

  • With two production systems, neither system might be right. It can be impossible to achieve the level of reconciliation required to prove the new system.
  • There is confusion as to which is the system of record – where the management accounts are made, as an example.
  • Certain aspects of functionality cannot run in two systems – supplier payments, EDI transactions, interfaces into other systems etc.
  • The impact this has on the users. Even by adding in an additional resource, there will be a tendency to favour one system over the other, deferring the entry of data in the other one until there is more time – which there never is.
  • Where core data changes as part of the implementation process. A new chart of accounts, items, customers, suppliers etc., makes reconciliation a challenge.
  • The change management process is exacerbated, as users will inevitably return to where they are comfortable.

So “big-bang” is the right way to go. Though I do have concerns about the terminology and the explosive implication, I’m not sure I can introduce a new term here to prove my point.

So, when I talk to my clients, I propose the following:

  • Review the scope of the project to determine if there are areas of functionality or business sectors that could either be fast-tracked or deferred to a later stage. I keep the scope as small as practical while delivering business benefit.
  • Recognise that ERP projects require the merging of data, technology and business operations. Because of all the moving parts, this needs to be extensively tested and piloted.
  • Pilot real data and real situations, and not just the easy stuff.
  • Deal with the change management implications as early as possible. This way everyone knows their role post-go-live and takes responsibility for ensuring they can deliver their role using new system functionality and processes.
  • Spend sufficient time training users. Don’t just train the mechanics but also where what they do fits within the holistic nature of an ERP system.
  • Focus on data and reporting as early as possible. Reduce the risk of nasty surprises later on with crucial elements left out of the process.
  • Apply and test security roles. I ensure that users have access to the modules they need to do their job, but that more sensitive records are protected.
  • Have plans to manage any eventualities – the “get out of jail cards” as I call them.

So, you can see, successful transition to a new ERP system requires preparation, preparation, preparation and then turn off the old system and focus all users and the business in general on the new system.

If you would like to find out more, contact us today for an initial, no-obligation discussion about how we can help you and your business on +44 (0) 1282 463710. 

How about learning more about Gradient and why you should let us help you by clicking here.