Microsoft Grow your company with SMART implementation of the right ERP system tailored to your business needs Dynamics 365 Finance and Operations Applications

1. 1. Scope,
   2. Work,
   3. Duration,
   4. Release plan,
   5. Cost,
   6. Licensing part of the project,
   7. Team,
   8. Assumptions & Constraints.

The Project Estimation process activities are conducted in close cooperation between the Customer and the Contractor and can be described as follows:

• Define High-Level Scope – define the requirements for the ERP system functions based on a formal or informal request from the Customer. This task can be performed iteratively and usually requires formalization and classification of requirements. The standard Business Process Classifier is used for this purpose.
• Refine Requirements – clarify the Customer’s requirements by holding meetings, possibly demonstrating some of the ERP system’s functions, to understand the key issues/constraints/processes/expectations and other attributes that define the key project management factors (see above). This operation is used for low-complexity projects.
• Accomplish Discovery Project – this operation is essentially a subproject that is highly recommended to obtain a high-quality plan for the main implementation project. This subproject does not replace the Analysis phase within the main project (see the “D365FO ERP Implementation Methodology Matters” article) but allows for a sufficiently accurate development of an estimation and planning of the main ERP implementation project of medium and high complexity. The implementation of work within Discovery usually takes from 3 to 6 weeks and is paid, and funding from. Microsoft is also possible. The key deliverables of the Discovery subproject are as follows:
  • Project Scope – processes/subprocesses, system modules,
  • Release Plan – grouping of the Content for the purposes of incremental launch of these processes into operation:
    • By processes,
    • By legal entities,
    • By geographical locations.
  • Work for each Release with breakdown to the subprocess level,
  • Duration,
  • Cost,
  • Project Team,
  • System Landscape – a diagram of the interaction of ERP system modules and systems that make up the overall architecture of the future solution, including data flows and integration methods,
  • Fit&Gap – percentage of coverage of the Customer’s requirements by the standard functionality of the system,
  • Key project risks and their management methods,
  • Key project estimation assumptions,
  • Project constraints.

• Estimate Project – estimate the labor costs, qualitative and quantitative composition of the team, project duration with a breakdown by processes and project stages in the form of an estimate file.
• Negotiate Estimation – hold meetings to present, discuss and clarify the estimate data to ensure that all requirements, constraints, and expectations are taken into account and the estimate is understandable to the Customer.
• Create/Negotiate Commercial Proposal – develop a document summarizing the results of previous work, possibly a proposed ERP Implementation Project Plan in MS Project format, and also containing information regarding the cost of the Project and the System, as well as the elements this cost consists of and the principles of its formation. This document is a formal proposal and, if accepted by the Customer, is the basis for the preparation, approval and signing of the relevant Agreements.

Project cost of ERP implementation

The TCO (Total Cost of Ownership) is determined for the entire life cycle of the system use and consists of the following elements:

1. The cost of licenses for the Microsoft Dynamics 365 Finance and Operations Applications software product itself,
2. The cost of environments that are necessary for the deployment and operation of the software product, if they are additional to those supplied as part of the ERP product,
3. The cost of additional software products (e.g., Office 365, external Power BI, etc.), if their use is expected within the framework of the designed business processes, as well as additional modules and services (e.g., localization packages for some countries),
4. The cost of the ERP system implementation project within the framework of those processes and their functions that are within the framework of the implementation project,
5. The cost of post-project support for the system.

• A comprehensive project (within one release or several releases), for which it is possible to plan the Scope before the start of the project,
• A release-by-release project, where the scope of work is planned before the start of each subsequent release (subprojects).

1. Cost of licenses for the Microsoft Dynamics 365 Finance and Operations Applications software product:
   • The ecosystem distinguishes 4 main software products that can be purchased independently + additional software packages that provide a number of specific functions: Microsoft Dynamics 365 Finance, Microsoft Dynamics 365 Supply Chain Management, Microsoft Dynamics 365 Commerce and Microsoft Dynamics 365 Human Resources.
   • Users who are licensed are named and are divided into four types:
     • Premium,
     • Operations – Activity,
     • Standard,
     • Team Member.

• SCM Premium,
• SCM,
• Operations – Activity,
• Team Member.

2. Cost of environments. An out-of-box product includes two environments required for setting up and operating the system – sandbox (testing) and production (operation). The need for additional environments and payment for them depends on the following factors:

• If development is required within the project. If any development (coding) is required within the project, the corresponding environments are required in the quantity determined by the development architecture,
• If simultaneous operation of similar environments is required. When the ERP ystem is put into operation release by release, it is necessary to simultaneously use several test environments or have additional environments to ensure continuous operation of the system and its simultaneous deployment within releases.

3. Cost of additional software. If at the stage of ERP system design it was decided that additional software is required for the operation of business processes, then it is necessary to purchase the corresponding software packages.

4. Cost of the ERP system implementation project. This cost is determined by two indicators:

• The amount of labor costs (in man-hours) that must be spent to perform all the work within the ERP implementation plan in accordance with the approach selected for the project or subproject (for more information on approaches, see “D365FO ERP Implementation Methodology Matters”). This factor is variable and directly depends on the Scope, i.e., the number and labor intensity of tasks performed within the system implementation project. Accordingly, if the scope of work does not change compared to the one planned before the start of the project/subproject, then the cost does not change, while any changes in the scope of work compared to the planned one lead to a change in the amount of labor costs and, accordingly, the cost. Thus, the cost of the project or its parts is a secondary factor and, accordingly, managing this cost means the need to manage the scope of work and the labor costs for this work.
• The cost of a man-hour (rate), determined by commercial agreements between the Customer and the Contractor and fixed by the relevant contract.

5. Cost of post-project support. These costs are associated with the work performed to support a product that has already been put into commercial operation. The performance of this work is usually regulated by a separate contract with the relevant conditions. The amount of labor costs under such a contract usually depends on the following factors:

• The number and qualifications of the personnel who are on the Customer's staff and perform work on supporting the system,
• The number of processes/users within the ERP system,
• The quality of testing the system before Go-Live,
• The qualifications and quality of training end users to work in the system,
• The number of non-standard and unplanned operations in the system that may arise outside the framework that was designed,
• The quality of the data used (directories, etc.),
• The number and specifics of integrations with third-party systems,
• Initiated changes (new requirements or adjustments to configured processes).

A precise understanding of the factors determining the cost of the project and methods for managing them is associated with an understanding of the ERP implementation approach and requires constant attention.

Vlad Berezin

Business Development Manager, SMART business

ERP Implementation Steps (Stages)

1. Project Start
2. Process Modeling and Analysis
3. System Configuration
4. System Testing
5. System Deployment
6. Go Live/Support

I. Project start

1. Project baseline. This plan is based on the Project Estimation data (see the “Estimation Process for the ERP System Implementation” article), but here it is adapted to real resources, their calendars and contractual conditions. The approved project plan is the baseline for further comparison of actual project indicators with planned ones (work, duration, cost, resources, efforts, schedule data).
2. Project organizational structure and roles (the initial definition of this data can be performed within the pre-project activities (see the “Estimation Process for the ERP System Implementation” article), but the final approval takes place here.

II. Process modeling and analysis

• Analysis of current processes, architecture and data flows (As Is Model) in the form of interviews and documentation of their results in the form of a text description and development of process diagrams.
• Collection of requirements and limitations for processes, data flows and forms of information presentation and their documentation in a suitable form.
• Modeling the system to cover the requirements for processes, data flows and forms of information presentation.
• Formalization of requirements for the desired processes, data flows and forms of information presentation in the form of a Functional Requirements Document (FRD). This document contains business process diagrams (Process Mapping), a text description of these diagrams, as well as other information.
• Definition of a requirements backlog and the corresponding work on configuring the system, requirement priorities and their specifics in the form of a Fit&Gap document, where:
  • Fits are work on configuring the system, and
  • Gaps are work on developing new functionality or expanding the existing one.
• Definition of integration points of the ERP system with third-party products, descriptions of data flows and technical parameters of information exchange,
• Definition and formalization of the general architecture of the solution, showing the ERP system and its place in the general structure of the Solution, indicating integration points and data flows within the Solution,
• Approval of FRD and Fit&Gap documents within the Technical Task for system configuration,
• Clarification of the Baseline with possible adjustments based on the data of the Technical Task and, if necessary, modification and re-approval of the Project Baseline.

• the type of implementation (standard approach or based on a prototype),
• the complexity of a specific business process,
• the complexity of the project as a whole,
• the number and specificity of system requirements,
• the number and specificity of integration points,
• other factors.

III. System Configuration

• Perform Setups (Fits).
• Perform Development (Gaps) – adding/changing functions, fields, filters, developing reports, primary forms, etc. using built-in system tools:
  • Preparation of development specifications,
  • Development,
  • Testing.
• Configuration of data sources, workflows, data parameters, reports using built-in system tools.
• Demonstration of the system prototype for selected processes.
• Discussion and approval of key development specifications.
• Preparation of test scripts:
  • Functional test scripts,
  • Integration test scripts.
• Internal Functional Testing – the system is tested by the project team resources.

IV. System Testing

• Individual processes, integrations or groups of processes (Functional Testing) – User Acceptance Testing:
  • Preparation of test data,
  • Demonstration of the system operation within the test scripts and training of key users,
  • The system is tested by key users with the support of the project team,
  • Adjustments to the system and the corresponding test scripts.
• The entire system (End-to-End Testing):
  • Internal Integration Testing – the system,
  • External Integration Testing – testing the system by key users with the support of the project team,
  • Adjustments to the system and the corresponding test scripts.
• Load testing – used only if there are a large number of operations and/or users.

V. System Deployment

• User training (key and end users). The main training of key users is performed at the Testing stage, but additional training may be required at the System Deployment stage. End user training is performed by the Customer’s Key Users. In exceptional cases, the Contractor’s specialists may be involved.
• Preparing data migration templates.
• Data migration (from the old system(s) and manually) and checking their correctness. This work is performed by the Customer’s specialists. It should also be taken into account that this task may be associated with significant efforts and take a long time. Incorrect data is one of the most common problems during Go-Live.
• Setting up access rights to system data – performed by the Customer’s specialist after appropriate training.
• Preparing the production environment of the system.
• Preparing a system Go-Live plan. This plan is developed to describe step-by-step the actions aimed at successful Go-Live. These actions can be either preparatory or describe the sequence of starting system operation for departments/processes tied to the calendar.
• Implementation of the system Go-Live plan.
• Preparation of role-based user instructions – performed by the Customer’s specialist based on the completed Functional Test Scripts.

VI. Go Live/Support

• Implementation of the Go-Live Plan.
• User support.
• Elimination of errors.
• Making changes.

Change Control

• Initiation and description of a change request (CR):
  • Description of the need,
  • Priority.
• Analysis of the request by the specialist responsible for the area:
  • Essence of the request,
  • Feasibility,
  • Areas of influence of the change.
• Review of the Analysis of the request by the project management.
• Request estimation by the specialist responsible for the area:
  • Efforts,
  • Cost,
  • Duration.
• Review of the estimation by the initiator of the change, a member of the project management group and decision making:
  • Accept,
  • Reject,
  • Postpone.
• Implementation of change upon its approval:
  • Inclusion in the plan and adjustment of the Project Baseline,
  • Work execution,
  • Testing:
    • Internal,
    • External.
• Demonstration of the system operation after the change implementation.
• Deployment of the change.

• Changes are one of the most common reasons for increasing the duration and cost of the project as a whole.
• Complex changes can be implemented iteratively.
• Ignoring the above change management procedure can lead to unpredictable consequences for the operability of the system.
• The number of changes directly depends on the quality of the work at the Analysis and Modeling stage and the corresponding project documents.
• The efforts required to implement possible changes are usually impossible to plan accurately. For this purpose, reserves are included in the baseline.

The approach to implementing ERP projects based on Dynamics 365 finance and operations applications, used by SMART business and based on the Microsoft Sure Step (Success by Design) methodology, is a logical and comprehensive set of processes, documents and procedures. Following this approach in implementation projects is a vital element for the successful implementation of an ERP system implementation project of any complexity.

Vlad Berezin

Business Development Manager, SMART business