Microsoft Dynamics AX Implementation Guide - Configuration data management

This article is excerpts from latest book Microsoft Dynamics AX Implementation Guide by  Yogesh Kasat and JJ Yadav , about one of the important topic in Microsoft Dynamics AX implementation process—configuration data management.

The configuration of an ERP system is one of the most important parts of the implementation process. Configuration means setting up the base data and parameters to enable your product features such as financial, shipping, sales tax, and so on.

Microsoft Dynamics AX Implementation Guide-

Microsoft Dynamics AX has been developed based on the generic requirements of various organizations and contains the business processes belonging to diverse business segments. It is a very configurable product that allows the implementation team to configure features based on specific business needs. During the project, the implementation team identifies the relevant components of the system and sets up and aligns these components to meet the specific business requirements. This process starts in the analysis phase of the project carrying on through the design, development, and deployment phases.

Configuration management is different from data migration. Data migration broadly covers the transactional data of the legacy system and core data such as Opening balances, Open AR, Open AP, customers, vendors, and so on. When we talk about configuration management, we are referring to items like fiscal years and periods, chart of accounts, segments, and defining applicable rules, journal types, customer groups, terms of payments, module-based parameters, workflows, number sequences, and the like. In a broader sense, configuration covers the basic parameters, setup data, and reference data which you configure for the different modules in Dynamics AX.

The following diagram shows the different phases of configuration management:

In any ERP implementation project, you deal with multiple environments. For example, you start with CRP, after the development you move to the test environment, and then training, UAT, and production, as shown in the following diagram:

One of the biggest challenges that an implementation team faces is moving the configuration from one environment to another. If configurations keep changing in every environment, it becomes more difficult to manage them. Similar to code promotion and release management across environments, configuration changes need to be tracked through a change-control process across environments to ensure that you are testing with a consistent set of configurations.

The objective is to keep track of all the configuration changes and make sure that they make it to the final cut in the production environment.

The following sections outline some approaches used for configuration data management in the Dynamics AX project.

The golden environment

An environment that is pristine without any transactions—the golden environment—is sometimes referred to as a stage or pre-prod environment. Create the configurations from scratch and/or use various tools to create and update the configuration data. Develop a process to update the configuration in the golden environment once it has been changed and approved in the test environments.

The golden environment can be turned into a production environment or the data can be copied over to the production environment using database restore.

The golden environment database can be used as a starting point for every run of data migration. For example, if you are preparing for UAT, use the golden environment database as a starting point. Copy to UAT and perform data migration in your UAT environment. This would ensure time you are testing with the golden configurations (If the configuration is missing in the golden environment, you would be able to catch it during testing and fix your UAT and the golden environment too).

The pros of the golden environment are given as follows:

·         The golden environment is a single environment for controlling the configuration data

·         It uses all the tools available for the initial configuration

·         There are less number of chances for corruption of the configuration data

The cons of the golden environment are given as follows:

·         There is a risk of missing configuration updates due to not following the processes (as the configuration updates are made directly in the testing and UAT environments).

·         There are chances of migrating the revision data into the production environment like workflow history, address revisions, and policies versions.

·         There is a risk of migrating environment-specific data from the golden environment to the production environment.

·         This is not useful for a project going live in multiple phases, as you will not be able to transfer the incrementalconfiguration data using database restore.

·         You must keep the environment in sync with the latest code.

Copying the template company

In this approach, the implementation team typically defines a template legal entity and configures the template company from scratch. Once completed, the template company's configuration data is copied over to the actual legal entity using the data export/import process.

This approach is useful for projects going live in multiple phases, where a global template is created and used across different legal entities. Whereas, in AX 2012, a lot configuration data is shared and it makes it almost impossible to copy the company data.

Building configuration templates

In this approach, the implementation team typically builds a repository of all the configurations done in a file, imports them in each subsequent environment, and finally, in the production environment.

The pros of building configuration templates are as follows:

·         It is a clean approach.

·         Utilize DIXF, DAT/DEF files to export the configuration and import them into a new environment.

·         You can version-control the configuration file.

·         This approach is very useful for projects going live in multiple phases, as you can import the incremental configuration data in the subsequent releases.

·         You can create additional code to automate export and import process or utilize LCS Configuration manager tool to export and import configuration from one environment to other.

This approach may need development efforts to create the X+ scripts or DIXF custom entities to import all the required configurations.

Summary

Clearly there are several options to choose from for configuration data management but they have their own pros and cons. While building configuration template is ideal solution for configuration data management it could be costly as it may need significant development effort to build custom entity to export and import data across environments. The golden environment process is widely used on the implementation projects as it’s easy to manage and require minimal development team involvement.

About Microsoft Dynamics AX Implementation Guide

ERP implementations are complex by nature and just like configuration data management has so many moving part. In order to make implementation project successful project managers, solution architect and leaders are expected to know all the aspects.

The book Microsoft Dynamics AX Implementation Guide is one of the first books covering the entire Dynamics AX implementation lifecycle with real life learnings and examples, providing stage by stage or phase by phase instructions for Project Managers, Business users and Solution Architects.  Supported by practical examples to validate recommendations and common pitfalls.

This book provides a summary of the various facets for running a successful Microsoft Dynamics AX project without going through expensive and time consuming training courses. Aspects covered include: Management, Functional/Business analysis, Technical design with code examples, and Infrastructure.