Modern ERP Systems: Business value and benefits

Pre-cloud era

So, what was typical for business applications before the cloud era?

Microsoft entered the business solutions sector in 2002 with the acquisition of Navision and Axapta solutions. Navision, now known as Dynamics 365 Business Central, was already aimed primarily at small businesses at the time, while Axapta, known today as Dynamics 365 for Finance and Operations, was aimed primarily at larger companies. Despite the differences between the two solutions, there are quite a few common features that are actually typical of most traditional business solutions:

• Deployment on own infrastructure (or on data-centre infrastructure),
• The way of making customisations - customisations are an integral part of any implementation, as there are often cases where standard functionality does not meet all the client requirements. In traditional solutions, the customisations mostly meant a direct change to the standard program code provided by the vendor (Microsoft in our case),
• Methodological approach to implementation - in most cases, the approach of sequential execution of individual phases (most often the so-called waterfall model) was used, where the phases followed each other: diagnostics,  analysis, design, development, testing, training, transition to production operations.
• Change management - updates to the standard solution (in the form of hot-fixes, improvements etc.) were provided throughout the support lifecycle period of a particular version, but were often quite complex to implement in environments that were heavily burdened with customisations,
• Upgrades and the entire application lifecycle - typically, a new version was introduced over a period of one or two years, which brought with it major changes, both in terms of data structure and technology. The more the system was burdened with customisations, the harder it was to make the transition to the new version.

Dynamics 365 Business Applications

Today, Microsoft offers Dynamics 365 Business Central and Dynamics 365 Finance and Supply Chain in the field of business applications, along with many other Dynamics 365 apps. Both solutions have been designed with the idea of modern cloud solutions in mind, and aim to respond fully to all the challenges associated with the implementation of traditional business solutions. The answers also bring with them important impacts on the method of implementation, i.e. on the implementer, as well as on the client. So, what do these impacts refer to? 

Infrastructure

Let's start with infrastructure – perhaps the most obviously impacted area.

With the arrival of cloud solutions, we no longer need to think about the required hardware and software that ensures smooth operations. We don’t need to concern ourselves with system or application software updates. We do not need to worry about scenarios which involve ensuring high system availability, backups and the like… We can get a lot of information based on telemetry, which tells us what state our system is in. 

Cloud infrastructure makes it easy to set up additional environments for different purposes, e.g. development, testing, performance testing, etc , which is a major advantage over local deployment (additional environments in the cloud infrastructure are of course associated with additional costs).

Additional environments in the cloud infrastructure may or may not be associated with additional costs. For example, with Dynamics 365 Business Central, Microsoft offers one production and three test environments in the basic subscription. If the company needs to use additional environments (additional production or four test environment) it will be associated with additional costs.

It is important to emphasise that Dynamics 365 ERP solutions can also be installed on local infrastructure, which of course greatly increases the complexity. In this case, the implementer must make a detailed plan of the required hardware, system and application software. Maintenance and update mechanisms need to be put in place. 

Customisations

One of the important findings of vendors of traditional ERP solutions was that it could be very difficult for customers to decide whether to upgrade to newer versions of their solution. Doubts and fears were mostly related to wariness about the possible high numbers of customisations required. The more customised the solution, the more effort is required to upgrade. 

Therefore, we often came across the fact that we were no longer talking about upgrading, but also about re-implementing. 

One of the main features of all cloud services is the constant updating and addition of new capabilities - updates can occur practically every month. In order for users to be able to adopt new versions of their solution relatively easily, it was necessary to fundamentally change the way the customisations were made. It may have previously been possible for the standard base code provided by the vendor to be changed, but this is no longer possible in the case of cloud solutions. Therefore, a new model was introduced in which the implementer no longer has the option to change the standard code, but they can write their own code - a so-called extension - in predetermined places in the program code (so-called extension points). When the manufacturer replaces its standard code and does not make breaking changes (e.g. removes certain data structures, software artifacts etc…), existing extensions work with the new update as they did before the update (e.g. for ease of presentation - when replacing a laptop, all USB devices work as before, a breaking change would of course be a change in the standard). As a result, making customisations becomes more complex.

On the other hand, there is a "Low-Code Development Platform" under the common name Power Platform, which includes Power BI, Power Apps, Power Automate, Power Pages, and Power Virtual Agent products; these services enable the construction of fast solutions in the areas of "self-service business intelligence", application development and automation. 

Methodology

The modern Dynamics 365 family of business applications are updated practically every month or more often. Major transformations are currently taking place - there is a decomposition of large monolithic solutions, which manifests itself in the elimination of entire modules to be replaced by new cloud solutions (some recent examples - Dynamics 365 Human Resources, Dynamics 365 Finance Insights, Dynamics 365 AI etc…), and in such an environment it is impossible to imagine using rigid implementation methodologies to implement a complex business solution. In response to the rapidly changing environment, Microsoft has proposed a methodological approach called CRP (Conference Room Pilot) as a blend of the waterfall and agile approaches. 

In this case, the implementation consists of the following steps:

• Agile preparation of the initial backlog of tasks (backlog items),
• Setting milestones in the form of CRP workshops,
• Iterative implementation of CRP phases (each CRP phase consists of a brief analysis, design, development, testing; progress occurs simultaneously after all project activities from settings, customisations, integrations, migrations…),
• Training,
• Testing,
• Transition to production.

The key advantages of such an approach are:

• Involvement of the client from the beginning to the end of the project,
• Monitoring progress on an ongoing basis and taking corrective action if necessary,
• Continuous feedback from users,
• Adapting the requirements according to incremental deliveries (often the requirements change during the implementation itself), which all result in faster implementation.

Application lifecycle

In traditional solutions we were often used to complete autonomy in code management and patch installation, but this is completely different in the case of cloud solutions. In the case of Dynamics 365 Finance and Operations, application lifecycle management is only possible using the LCS (Lifecycle services) collaboration portal, which in the case of cloud solutions means that applying updates to the production environment is performed by Microsoft as part of their regular services. Both the client and the implementer can only access the system using the user interface. Whereas we used to be able to easily access data, install patches, and perform quick ad-hoc actions, this possibility is now completely disabled. There is now a procedure that precisely prescribes the steps to install a new package in production, e.g. a prerequisite is testing in a sandbox environment. 

In the case of Dynamics 365 Business Central, Microsoft automatically offers the update for testing and production environments through the Dynamics 365 Business Central admin centre. The administrative interface can be accessed by both the client and the company that implements the business solution, and through the update settings they can schedule updates at a specific time (certain period, day, month). As it is a SaaS (software-as-a-service) solution, these updates cannot be skipped and must be installed. If the update is not manually triggered by the client or implementer within the specified time frame, Microsoft will automatically trigger the update on the latest scheduled update date (approximately 30 days after the release of the major version).

More than ever, testing backed by automated tests has now become particularly important, as we can’t afford to have system failures due to poor testing. 

Evergreen solution

Updates include the continuous addition of features and functionality. For Dynamics 365 for Finance and Supply Chain, the client has 8 updates per year and must accept at least 2 per year, which in practice can mean skipping 3 consecutive updates. In addition, critical fixes are always available for the previous release (i.e., if the current release is 10.0.6, then critical fixes for release 10.0.5 are provided). 

For Dynamics 365 Business Central, emergency fixes (Minor release) are published regularly and there are two main annual releases (Major release). Hotfixes or minor updates are released once a month and are accompanied by version v21.1 marks. For minor updates, Microsoft will automatically trigger the update on the last scheduled update date (approximately 20 days after the release of the minor update).The main issues are published twice a year, in April and October (with the labels wave 1 and wave 2).

In this way, clients are constantly on the latest update, which includes all known critical fixes, new features and functionalities.

This, of course, means that as implementers, we need to be able to accept updates several times a year and make sure that all the extensions work properly. Again – automated testing plays important role.

In the case of a "cloud" solution, of course, we must not forget that we are talking about an all-inclusive service, which means updating both the system and application software.

There is a difference between cloud and on-premises deployment - in the case of a local deployment, the client retains more flexibility (i.e. they have to take care of themselves), but it is not possible without regular updates.