Mitigating business risks in cloud based ERP application with automated testing

When implementation is over, the real ERP life begins…

Data security, system effectiveness, platform functionality, and fully operational business. These four main benefits are also threats of having Enterprise Resource Planning in the cloud. During the implementation process the company is fully focused on the secure migration of data and adjusting standard ERP packages to the business needs. Dedicated projects, many people involved, hours of tests conducted. All efforts seem to make implementation risks minimized.

Yet, right after the long-awaited “go-live”, businesses realize that there’s also an “ERP life”. Often neglected or omitted by the overwhelming amount of commitment during the implementation phase.

For the principal part of cases, implementation is just the beginning of a long-term relationship between the company and ERP system. Vendors of the enterprise software, like Microsoft Dynamics, developed different modules to cover and support all functional units of the enterprise. They constantly invest heavily in improvements to their solutions. In turn, enterprises want to keep up with the technology development and thus need to upgrade frequently. For business operations to get the complete benefit of these ERP updates, proper testing and implementation of the same are required.

When a new system begins to work its supervision, testing, and maintenance of the environment are necessary for keeping operations in the company being performed smoothly on a daily basis. If relevant control is well organized, it does not require exceptional effort or the involvement of many company resources.

Are ERP updates your company’s risk? Not necessarily. But if so..

What type of cloud based ERP risk business needs to be aware of:

Customized system and its consequences

“Vanilla” ERP (solution with little or no modification in the basic design) systems can create strategic disadvantages, while ERP customization can create problems after implementation. The more ERP is customized, the farther away it is veered from the natural evolution of the software. Upgrades become more challenging since the code often needs to be rewritten to support newer versions of the software. Such a case leads organizations to defer upgrades – sometimes indefinitely. It’s risky considering that finding defects and validating if such personalized applications work correctly is essential for any ERP upgrade! This is why a well-conducted ERP requires continuous testing of system processes. It is essential to identify and fix flaws, and further ensure quality reporting and decision making.

Monthly vendors modifications to the standard

Taking Microsoft Dynamics 365 as an example – their release plan continuously enhances the system with new functionality to provide businesses with a well-adjusted tool. As a crucial player in the ERP landscape, it is obviously important for Microsoft to do so to stay ahead of the competition. However, a big challenge is that clients cannot benefit from enhancements if they are not on the latest version. Microsoft used to release two major updates per year.

November 2018 was a big break in this approach. From that month on, monthly update cadence that includes application and platform updates started. From April 2019 forward, all Dynamics 365 customers need to be on the same, current version –  ‘One Version’ which will always be up-to-date. Compared to earlier two per year releases, this is a significant change that each client must respect. And that means more update implementations that are crucial for the business.  See Microsoft Dynamics 365 FO – updates plan

Missed updates expose to business deadlock

ERP software reduces human errors in business. But as the company’s departments affect each other and ERP modules are connected, a slight change in one can significantly influence the other. If a customized system or even the small components are not ready for an update, the company is facing the butterfly effect.

Thus, a small update change in the sales module can result in large differences in the inventory and supply part of the system. In addition to these internal modules, there may also be dependencies to external systems, like payment or shipping providers. Updates should never have been introduced without appropriate testing first.

Assessing the risk of update threads is often about answering the question: do changes in the ERP can affect business continuity? If the response is checked with “YES”, ERP users need to introduce an appropriate testing tool.