During a cloud ERP implementation what are some significant difficulties experienced and how do you best manage them?
This question was asked by an attendee during the Proformative
During a cloud ERP implementation what are some significant difficulties experienced and how do you best manage them?
This question was asked by an attendee during the Proformative
Wow- a wide ranging question:) so let's address what may be unique to Cloud/SaaS rollouts than the whole universe of ERP best practices. Here are some and I hope others weigh in:
1. Did you negotiate access to a "sandbox" to develop your configuration, test designs, test data migration/open balances, etc? If not, how will you manage the UAT phase and cut over to live production?
2. Failing to apply rigorous UAT standards and routines; Cloud/SaaS per se does not mean you let up on UAT phase.
3. Cloud means being connected via the internet to record transactions; test for what happens when your internet connection goes down midway through a 20 line journal entry or a 1000 line csv file import.
4. Performance/stress testing-are you a high volume transaction site? On a real busy day (like the day after Thanksgiving), how many concurrent customers could hit your e-commerce site and place orders, obtain order confirmation/shipping date?
etc.
And I meant to add:
5. Integration with other business systems in your IT environment. This can vary greatly based on company size, business model, degree of integration required.
For example, if you need payroll cost data once a month for GL posting, maybe a journal entry/file upload will suffice. But if you need real time inventory updates, credit card processing, two way integration with other systems, then your integration needs differ. What is your Cloud vendor going to do/not do in their services/subscription agreement? Can they in fact do it anyway, or do you need to engage other resources to work with them? Make certain that there are no gaps between their respective SOW's that leave you in the lurch.
And, you need to test each integration thoroughly before going live and at update time.
I just did an implementation of NetSuite and my biggest challenge was understand how India operates and how to implement them in NS. For example, we do Inter-Company invoicing between the US parent and the Indian sub. and testing in both the US and India. While seemed to work at first (i.e, all accounts balanced) we later found some issues in the way it handled FX Gain/Loss. We ended up dong workaround for India since they were billing in USD and depositing in Rupees.
So the challenge for us was not to assume if the process works in the US, it will work in a foreign sub.
I have also seen where "configuration" quickly turns to "customization" as requirements shift as part of the implementation. With configuration being the setup of the system's built in options vs. customization which is specific code changes for your instance. I have found what works best is setting up some "guiding principals" at the beginning of the implementation, one being a restriction on customization out of the gate. It takes the temptation off the table and forces a critical look at process. Understand your underlying processes and change them as needed to take full advantage of the system vs. changing the system to try and automate a less than optimal process.