Software deployment projects have changed dramatically in the last 25 years in line with changing IT landscapes. Cloud ERP does not require the installation of software on a server and PC’s and the way many ERPs are modified for industry specific functionality involve standard toolkits that achieve intelligent system changes that exist within your software rather than outside of it as an interfacing but separate programme. It’s slicker and very efficient.
These industry changes have enabled businesses to reduce the duration of a migration project from one solution or interfacing solutions to a single database ERP from considerable months to just weeks.
ERP Implementation methods
What are the ERP implementation options and what are the cost implications? Here we have ‘graded’ each deployment style numerically 1 – 5 to indicate the likely differences in cost of each approach, with 1 being the least financial cost.
Phased roll-out for ERP
This approach, 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.
Expense level 4
Beware the pitfalls of the phased roll-out which tend to be around the issues of protracting the final adoption of the key benefits of your new ERP. These key benefits are usually the new functionality that prompted a move to ERP in the first place. The longer this new functionality takes to be implemented the longer it takes to see your return in investment. Releasing new functionality into your business processing using too many phases is time hungry and increases your project spend overall.
Parallel adoption for ERP
This somewhat ‘traditional’ and potentially outdated approach, 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. This approach takes longer and is often confusing for staff regarding which system is the point of truth at any one time. What data set is the right one to report on?
Expense level 5
The biggest pitfall of this approach is the risk of an implementation taking far too long to be completed or worst still – the impetus of the project is completely lost and you never Go Live on your new system at all. The longer a deployment is strung out for the bigger the chances of department heads changing or project managers no longer being available. One of the major keys to a successful ERP deployment is focus and purpose
- 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.
- Which system is the record of truth?
- How will parallel adoption work for you – supplier payments, EDI transactions, interface into other systems and can only be run from your legacy system OR the ERP you are migrating to.
- Human beings are creature of habit in most cases staff will opt to process data in the system they ‘know’ rather than the system they are learning. We are all under pressure to complete tasks as quickly as possible and taking additional time to process on a new system could be an obstacle that seriously hinders and protracts your change management and project timeline.
- Where core data changes as part of the implementation process such as a chart of accounts or part numbering – how can you easily reconcile the two systems?
“Big-bang” for ERP
Put simply – this approach involves a journey from ‘A’ your existing solution, to ‘B’ your new solution, typically over the weekend following a trial data migration and comprehensive training. On Monday morning following the final data migration, you are processing only on your new solution.
Expense Level 2
What are the pitfalls of ‘Big’Bang’?
This approach can be hugely risky if your data migration trials have not been rigorously tried, tested, and signed off on. Ensure you have completely understood what data your Business Partner is going to migrate and what will be left behind so that you can make necessary preparation to archive data (compliance reasons for example).
It is also imperative that staff have committed to the agreed project timeline and prescribed training programme and completed any recommended workshops and subject matter expert testing. If your new ERP is planned to deliver completely new and/or complex areas of function to support your business – this approach might seem ‘onerous’ on the face of it, but good planning, project management and system testing prior to Go Live ensures that your project is logical, manageable, on time and on budget.
“Big-bang” + Optimisation for ERP
- This final approach combines the ‘Big Bang’ and ‘Phased’ approaches.
The aim of this approach is to ensure that at Go Live all current processes are fully replaced by the new ERP plus any immediate new business critical functionality that has formed part of the decision to move to a new ERP.
This could be bar code data collection, improved central quoting or EDI integration for example.
A further ‘Optimisation’ example might be the deployment of the CRM that sits within your new ERP where CRM has not been historically used but has been identified as a non-negotiable for any new solution or integration with your website to support e-commerce.
It is crucial not to lose sight of these optimisations, and to have them documented within your project timeline from the very start. Doing this avoids project slippage which will reduce your return on investment on the project.
This approach limits disruption to the day to day enabling you to Go Live but supports the change management process and ensures the ERP deployment meets the goals of the project.
Expense Level 2
What are the Pitfalls of ‘Big Bang’ + Optimisation?
Project slippage – every time. Decisions are made to move to an ERP that will deliver additional functionality. Once the project has gone live the ‘day to day’ returns and the business is happy with the ‘quick wins’ the new solution has provided but doesn’t return to some of the key drivers that formed part of the decision-making process.
What is an Expense Level 1?
A ‘Big Bang’ self-service, deployment where you migrate your own data and perform all testing tasks internally with training delivered by ‘how to’ documents and video.
Your business will need manage its Go Live internally without dedicated support. This style of ERP deployment is ideal if you have an experienced and committed project manager and one who has deployed your selected ERP solution before.
FACT
ERP projects require complete integration of people, process, and system. In most cases, any project timeline failure is to do with the quality of testing, training, internal and external communication, rather than a fault with the system itself.
Your ERP Project Management Team is the key
You can have selected the best Business Partner money can buy but the key to any successful ERP implementation is the commitment and participation of your internal project manager. Your external Business Partner project manager can only advise and signpost. Your internal project manager must ensure that advice and procedures are followed. Poor internal project management will protract an ERP deployment thus identifying the right person for the job and ensuring that person is not only capable but keen to take on this role is key. If your team doesn’t have a suitable individual, you may need to take on a specialist project manager or ask your business partner for enhanced project management services which will involve days on site outside of training services and thus increase the costs of your project overall. Whilst an increased initial project cost is not desirable –successful internal project management will pay dividends.
Tip
As an internal project manager, allocate specific areas of the ERP solution testing, following an initial data migration and prior to Go Live, to your department heads, ensuring any issues are centrally reported back to you to share with your external BP Project Manager for resolution. Is further training required? Is a learning through doing workshop the best approach? Are their specific areas of processing causing concern to any department heads?
Getting Ready to deploy Microsoft Business Central ERP
- What functionality in your new ERP must be available at Go Live?
- What if any, functionality should be a post Go Live Optimisation?
- Have you considered who will serve as your internal Project Manager?
- Does your team understand that during the project, piloting real life situations with a copy of your data is a crucial part of the project and involves their commitment?
- Think about the responsibilities of your department heads following Go Live. Ensure you have discussed the necessary change management that successfully supports every IT project.
- Ensure that any project you commit to has the full support of the business to enable staff to attend and engage with training and workshop sessions.
- Find the right business partner, it’s important to get the right ‘fit’ for your business and your team.
Thought for the Day
Qi will work with you to discuss the best approach for your Business Central ERP implementation based on your business structure, number of companies and sites etc. Get in contact with us for an initial discussion?