ERP ‘Best Practice’ model – the testing myth

During a catch up with an old testing colleague the other day, we mused over why testing often, and especially in ERP Programmes, is underestimated in time, effort and duration. We concluded that most ERP Programmes in today’s market are based on adopting a predefined industry best practice model which then leads to a sense that as the solution is pre-proven, it ‘just works’ and therefore testing can be reduced or shortened. We also felt other areas are underestimated such as data migration, integration and performance testing. Data because it is oversimplified, a debit is a debit, right? Integration because people forget about the numerous interfaces and file exports that have grown up over time, and performance, especially now with cloud, as it is sold as being ‘elastic’ and not your problem.

So, if you are engaged in or about to start an ERP, using a best practice approach, the points below may help you approach the weeks and months to come.

 

Functionality testing

Even with a high degree of fit between your business processes and the best practice model, the scale of configuration changes needed is significant and as such, functionality testing is still essential. The best practice models do allow you to apply a risk-based testing approach to the platform i.e., where the business process is low risk and a tight fit then testing can be scaled back to positive testing only. Negative and multi permutation testing can also be reduced but in the end; this is a new system and as such you need to make sure that it works. After all your ERP is your primary ‘system of record’ and is an audited platform. It must be right.

Good testing practice is still necessary, especially with ERP. You need an audit trail to prove to your auditors that the new platform is correct. Allow enough time and resources to build quality testing plans, traceability matrixes, test scenario and evidence logs that reflect the full end-to-end.

 

Data – Migrated data

Data has a significant impact on how your system functions. Migrated data is typically responsible for a lot of your post go live process failures. Migrated data will have been validated using the old systems criteria which may well be at odds with the new platform. Data will have been transformed in the migration process which leads to changes in the data itself. Finally, your new system will have different validation and processing rules that may not work with migrated data in the way you expect. Testing with migrated data allows for the refinement of Data migration routines as well as potential ‘Migration Compromises’ or workarounds to handle any exceptions.

Test all your functional processes again with migrated data.

 

Integration

On a recent programme, I identified over 100 interfaces supporting the business and linked to the ERP. Not only did this prove a tough challenge at cut over but it also significantly increased the level of testing. Design often assumes the same interface can be used or slightly tweaked, the consequence is a belief you can test less. Combining SIT with Data Migration, functional testing builds to an end-to-end testing regime.

 

Performance

Modern ERP’s are heavily weighted to workflow to support and manage the business processes. It is critical that you conduct performance testing, ideally using migrated data to ensure that your new efficient process is going to save time. Performance testing is often overlooked as the focus is on new functionality, but volume and scale are critical and feature on most post go live issues logs. Reporting is susceptible to performance issues.

Performance testing is particularly challenging in a cloud environment. The production platform you are moving to is already live (cloud being a shared platform) and therefore you will not be allowed to conduct traditional performance testing. But that doesn’t mean you shouldn’t performance test, you should. Test your network (LAN and WAN), your internet gateways and your end-user desktop environment for latency. Run your reports and do this through the business lifecycle. Invariably cloud platforms are performant and scalable, so if you are facing poor end-user performance issues, it is typically your network or your data warehouse which needs looking at. Test thoroughly and test at multiple stages of your end-to-end monthly cycle.

 

User acceptance testing (UAT)

Sometimes, it feels like UAT is the only testing that ever gets done, the traditional cycles of unit, system and integration are quickly passed over to get the platform in front of users. The reality is that slippages in blueprint, design, build and late change requests means that testing is even more important – short cuts will have been taken and therefore your UAT is critical to stop disaster at go live.

The success of UAT is based on good testing practice, being well resourced (time and people) and the solution being in a mature state before UAT starts. Mature does not mean 100% complete.  Starting too soon means users will get fatigued and your delivery will struggle when you go live.

 

So, does ERP Best practice model really shorten your testing?

ERP, even with a Best Practice Model is like any other project, it needs the full lifecycle of testing to properly assure its delivery. Best Practice models help with some of the functional testing but not the full lifecycle of testing. Beware the myth that by adopting this you short cut your testing, you marginally reduce the effort.

ERP is the backbone of a company, not just a finance system. Failing to adequately and robustly test the new platform will simply lead to a failed delivery and one that will be very visible to everybody, including your shareholders.

 

Do you need change expertise?

At Project One, we have a whole team of experienced change experts, helping customers navigate their change agendas.  If you are currently facing a challenge like this and need a sounding board, please don’t hesitate to get in touch.

SIGN UP TO OUR NEWSLETTER

For more information on how we use your data, please refer to our privacy policies.

POSTED BY: Simon Birbeck - Consultant

CONTACT: simon.birbeck@projectone.com

View the author's team profile page

Get in touch