Your New ERP System – Taking It Live

Whilst 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 be faced with, especially when the world is full of horror stories of the calamities that befall companies getting this wrong.

Only this week, TSB were all over the news with an upgrade process that brought their entire system down.  Issues with access, data protection issues 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 are 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. This allows for the early implementation of key features and ensures that any issues or complications are isolated from working processes that have already been brought on line.  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 whilst retaining access to familiar and established working environment.  During changeover, the new system and the existing one run side by side for an agreed period, to ensure all aspects of the new system are confirmed as working correctly.  Both input the same data and perform the same processes, to compare outputs.
  • “Big-bang” – involves cutting over all 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 for the reader to make their own 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 that should be considered, let me start by presenting my arguments for avoiding parallel adoption at all costs.

The key 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, making it 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 will be produced from, as an example.
  • Certain aspects of functionality cannot be run in two systems – supplier payments, EDI transactions, interfaces into other systems etc.
  • The impact this has on the users. Even by adding in 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 has been changed as part of the implementation process, new chart of accounts, items, customers, suppliers etc, this clearly makes reconciliation more challenging and time-consuming.
  • 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, but as it’s generally recognised then I’m not sure I can introduce a new term here just to prove my point.

So, when I talk with 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, keeping the scope as small as practical whilst delivering business benefit.
  • Recognise that ERP projects require the merging of data, technology and business operations and, because of all the moving parts, need 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, so that everyone knows their role post go live and takes responsibility for ensuring they can deliver their role using new system functionality and processes.
  • Ensure sufficient time has been spent training the users, not just 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 in the project to reduce the risk of nasty surprises later on, when some key element of data has been missed from the process.
  • Apply and test security roles to ensure that users have access to the modules and data 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’ve like to find out more, contact us today for an initial, no obligation discussion about your aspirations and how we can help you and your business deliver your vision for the future on +44 (0) 1282 463710

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