Erp implementation process and introduction to dynamics 365

UNIVERSITY OF TRIESTE
DEPARTMENT OF ENGINEERING AND ARCHITECTURE
MASTER IN TELECOMMUNICATIONS ENGINEERING
ERP Implementation process and introduction to
Dynamics 365
Supervisor: Student:
Prof. Fulvio Sbroiavacca Varajic Aleksandar

Abstract
L’obiettivo principale di questo elaborato è stato descrivere il processo di
implementazione di un ERP (Entreprise Resource Planning) software e di fornire una
panoramica su Microsoft Dynamics 365, che rappresenta il prodotto software creato da
Microsoft.
L'acronimo ERP si riferisce ad una tipologia di software che le organizzazioni utilizzano
per gestire le attività aziendali: ad esempio contabilità, vendita, pianificazione e controllo,
gestione del rischio e supervisione della catena di approvvigionamento.
La ricerca bibliografica e delle fonti è stata effettuata tramite la consultazione di varie
banche dati, quali Microsoft, Oracle e SAP; sono stati inoltre consultati diversi siti,
prevalentemente appartenenti alle più grandi aziende di consulenza che si occupano
dell'implementazione dei software.
Il primo paragrafo descrive il processo di implementazione e ci si focalizza su quali siano
gli obiettivi prefissati e sulle modalità in cui essi possano essere raggiunti in maniera
efficace.
Proseguendo al secondo capitolo, l'attenzione è stata posta su Microsoft Dynamics 365 e
sui motivi per cui questo software con la sua piattaforma sull' Azure cloud sia considerato
uno dei migliori nel mondo.
Infine, il questionario è stato somministrato a vari soggetti che hanno utilizzato Microsoft
Dynamics 365 nell'ambiente lavorativo per confrontare la loro esperienza di
implementazione dell’ERP rispetto alla descrizione trattata nei primi due paragrafi.
L’esperienza complessiva conferma che Dynamics 365 è uno degli ERP più potenti, ma
suggerisce ulteriori miglioramenti che potrebbero espanderne l'utilizzo.

Contents
Introduction .................................................................................................................... 3
Chapter 1: History perspective ..................................................................................... 5
1.1 Change of ERP in time................................................................................................ 5
1.2 ERP today .................................................................................................................... 7
1.3 History of Dynamics.................................................................................................... 8
1.4 Sap History ................................................................................................................ 11
Chapter 2: ERP Implementation ................................................................................ 13
2.1 Introduction............................................................................................................... 13
2.2 Planning ..................................................................................................................... 14
2.2.1 Project team........................................................................................................... 14
2.2.2 Implementation methodology............................................................................... 17
2.2.3 Defining requirements and scope......................................................................... 19
2.2.4 Cleaning up data.................................................................................................... 21
2.2.5 Benefits-cost........................................................................................................... 21
2.3 Discovery.................................................................................................................... 23
2.3.1 Fit............................................................................................................................ 24
2.3.2 Cloud vs on-premise.............................................................................................. 25
2.3.3 Implementation partner ....................................................................................... 27
2.3.4 Cost......................................................................................................................... 27
2.3.5 Change management............................................................................................. 29
2.4 Design ......................................................................................................................... 29
2.4.1 Organizing processes............................................................................................. 30
2.4.2 Project kickoff ....................................................................................................... 31
2.4.3 Design together...................................................................................................... 32
2.4.4 In the box solution................................................................................................. 35
2.4.5 Customization design............................................................................................ 35
2.4.6 Functional design document................................................................................. 36
2.5 Development .............................................................................................................. 37
2.6 Data migration........................................................................................................... 39
2.7 Test ............................................................................................................................. 40
2.7.1 Types of testing...................................................................................................... 40
2.7.2 UAT ........................................................................................................................ 44
2.8 Deployment ................................................................................................................ 45

2.9 Support....................................................................................................................... 46
Chapter 3: Introduction to Microsoft Dynamics 365................................................ 48
3.1 Finance and Supply Chain Management................................................................ 49
3.2 Business Central........................................................................................................ 51
3.3 CRM ........................................................................................................................... 51
3.4 Commerce.................................................................................................................. 53
3.5 Human Resources...................................................................................................... 54
3.6 Usability of Microsoft Dynamics suite..................................................................... 54
3.7 Dataverse.................................................................................................................... 55
3.8 Azure .......................................................................................................................... 55
3.9 Security....................................................................................................................... 56
Chapter 4: Microsoft Dynamics 365 Survey.............................................................. 58
Conclusions ................................................................................................................... 69
References...................................................................................................................... 71
Sitography ..................................................................................................................... 72

3
Introduction
Enterprise Resource Planning ERP is a software that covers all the core business
processes in company: supply chain, finance, HR, manufacturing, services, and others. It
has a long history of implementations in all kinds of industries form manufacturing,
energy, agriculture to health, pharmaceutical, food and transport industry. As such it
represents the pilaster or “central nervous system” of every company. Nowadays, it is
impossible to imagine any enterprise that doesn’t use ERP software and it became
standard to support company growth and lead company to success. ERP has grown from
the software for managing manufacturing and logistic to the software that contain all of
core end-to-end processes and the possibility to improve decision making based on the
information that are stored in one system. The last 5 years are exciting times for ERP, as
it experiences big changes in the approach of creating ERP software. It is mostly delivered
in cloud, that made ERP available for the companies with limited budget as the
infrastructure for supporting ERP is managed by cloud provider. With the developing od
new technologies ERP is embedded with AI (Artificial Intelligence), Machine learning
and IoT (Internet of Things).
ERP brings lot of advantages to the company, but it is important to understand what does
it take to implement such a software. The main objective of this thesis is to create a clear
picture on implementation process and cost, methodology, time, resources, and risk of
implementation of ERP software. Then, other objective of this thesis is to present a
potential solution in form of Microsoft Dynamics and to explain all possibilities that this
platform offers. At the end, questionary is sent to the people from ERP industry or the
ones that already implemented Microsoft Dynamics in their companies in order to
underspend better their experience of implementing software in light of implementation
process prior explained.
The approach to implementation and software itself have changed over the years, and
they are still changing. Deductive methodology is used to gather useful, up-to-date
information regarding implementation process and Microsoft Dynamics from sources like
SAP, Oracle, and Microsoft official documentation on ERP as well as from different
consultant firms that have expertise in software implementation, both Microsoft and other

4
ERP producers. Then, different white papers coming from Gartner, Forrester, Nucleus,
and many others are used together with different webinars. Some of the information used
are coming from five years’ experience in ERP industry, both from implementation
partner side and recently from end-user client side. At the end, the questionary has been
sent to people from ERP world, in order to check how their experience with
implementation match with points made in second and third chapter.
Thesis is divided in four chapters. First chapter introduce the historical development of
ERP software, explains how are ERP software followed the technology evolution in last
fifty years and what are the milestones in ERP history. Second chapter introduce
implementation of ERP in different companies and describe the path to follow in order to
succeed in software implementation. Implementation is costly and time-consuming
endeavor and every company have to be aware of all potential difficulties before start
considering ERP solution. Chapter is divided in 7 parts in natural order of doing things:
planning, discovery, design, development, testing, deployment, and support. It gives clear
picture of steps in implementation that are leading to success. Third chapter is on
Microsoft Dynamics 365 suite that is one of the biggest and most used ERP solutions
today. It describes all of the advantages that Microsoft Dynamics together with Azure
provides. The structure and the ERP offers together with functionalities like HR and CRM
for different industries are also explained. Eventually , in the fourth chapter the questions
ask to the people from industry are presented. The questions are related to implementation
of Microsoft Dynamics 365 and overall experience with software. The aim of this
questionary was to establish the link between theory and real experiences with software.

5
Chapter 1: History perspective
1.1 Change of ERP in time
The story of ERP begins with development of computers and their more common use in
early 1960. First, they were used for inventory management systems called BOMP (Bill
of Material Processor). This first type of management software quickly evolved in
something more powerful. After some years of working with BOMP, new functionalities
are added in terms of material ordering and planning systems. In the 1960s IBM was first
to develop integrated production and inventory management system that ran on IBM 305
RAMAC System. With a rise of implementations in 1970s and development of new
modules for Sales and Operation Planning (SOP) and Capacity Requirements Planning
(CRP) the new closed loop Material Requirements Planning (MRP) system was born. It
was the first tool to address not only material requirements planning but also managing
priority and capacity. In the 1980s the scope of software becomes to incorporate all the
manufacturing resources and to integrate financial functionalities. The next big thing in
1980s was the concept of Computer Integrated Manufacturing (CIM) that had as a goal
fully automated factory. The main problem was that many companies had lot of different
units of technology that couldn’t communicated with its other. For example, General
Motors had several thousand different units. To overcome this issue, in 1978, Open
Standards Interconnection Reference Model (OSI) was published. It defined standards for
developing all data communications. Also, in 1980s the first Workflow concept is
developed. Workflow is the sequence of processes that must be accomplish in order to
create a product from start till the end.

6
Figure 1.1 IBM 305 RAMAC System Source: Computer History Museum
In 1990s there was break throw in the field of information technologies. The performance
of PCs was better every year, and the computing facilities become available and relatively
cheap. This enabled creation of more powerful and complex software that was called
Enterprise Resource Planning (ERP) for the first time. The company Gartner Group was
first to introduce this acronym. The new version of software was not only more complex,
but it was using GUIs (graphical user interfaces) and client/server architecture. Some of
new features included quality management, process operation management, sales and
marketing. The new functionalities were divided in 3 main modules: Supply Chain
Planning, Customer Relationship Management and Product Data Management. Supply
Chain Planning have the task to understand basic needs of the customer in order to
program the inventory management, procurement, planning and delivery. Customer
Relationship Management (CRM) was first software oriented not only to the part of the
operations but also to the activities that was generating a revenue. CRM covered customer
front-end business activities like sales, marketing and field services. The old MRP and
ERP software couldn’t manage the needs of sales and marketing, so the CRM
development was necessary. In time Product Data Management was introduced with a
task to easy the process of design and it was the natural successor of CAD (Computer
Aided Manufacturing).
The new century brought us the more general use of internet. Lot of companies with
custom based software was concerned about Y2K (Year 2000 problem) and decided to

7
purchase the new ERP software. One more time Gartner group described ERPII as
internet enabled ERP. With the growth of internet, the ERP had to change in order to
satisfy new emerging needs. In 2000s the number of merges took place and market that
had numberless software companies remained with several big ones: Microsoft, Oracle,
Sap and NetSute. New ERP II address web-based functionalities, interaction via mobile
device, real time access to the ERP and Business Intelligence (BI).
Figure 1.2 History of ERP systems Source: technicali.com
1.2 ERP today
Today, ERP software are even more powerful. Not only that they manage basic
requirements like production, supply chain, sales and finance but they have advanced
reporting and business intelligence, ecommerce and service management. They are also
embedded with CRM, e-shop and different third-party software programs. In this way,
with every company process under one software the decision making is made more
accurate. Nowadays ERP software are referred ad SaaS (Software as a service) with is a
software licensing and delivery model in which software is licensed on a subscription and
centrally hosted. Almost every solution in available in market is cloud-based with
exemption on same versions that are on-premises.
Major technology trends in the world of ERP are artificial intelligence (AI) and internet
of things (IoT). Artificial intelligence, especially machine learning, will help automating
business processes and predict patterns in market fluctuation. ERP systems provide large
amount of data that can be used to precise machine learning. It could be used not only to

8
predict patterns but also for error detection and automated reports. In other words, AI
empowers businesses to make rapid adjustments that drive success. On the other hand,
IoT devices like scanners, cameras and sensors have become key source information for
ERP. It starts to pick up among manufacturers and distributors because in helps them to
have real-time picture of their businesses. For example, scanner can track product leaving
and entering the warehouse or sensor and cameras can help with automating industrial
security. According to Gartner report, 65% of CIOs predict using AI in their business.
Figure 1.3 Future of ERP Source: epcgroup.net
1.3 History of Dynamics
History of Microsoft Dynamics starts with different company, Damgaard A/S. This
company was founded in Denmark by the brothers Damgaard with a scope of producing
an accountant software. First, they released Concord Finance (also known as C4) in 1986.
Customers were able to make changes in code in order to tailor the solution to better serve
their needs. In 1991 they released Concord XAL leaving the open source code. This
encourages resellers to create different modules and verticals. Soon enough they become
the leading accounting software for Danish market. This put them in focus and by 1994
they made 50/50 partnership with IBM creating Damgaard International A/S. By the and

9
off millennium they had more than 75000 installation all over the world. In 1998 IBM
and Damgaard release IBM Axapta. First version of Axapta was based on Concorde XAL
but for the first time they introduced Trade, Inventory Management, Logistics and
Production modules. It run on Windows NT servers with Microsoft SQL Server, but also
on Oracle databases and it has the early version of Axapta Object Server which was used
to unload data form client to server processing. The later versions of Axapta were 3-tier
solutions (Client, Server, Database) and had implemented Web Apps. They also had new
modules: Project and Banking and CRM. After merging with Navision and forming
Navision Axapta, Microsoft bought the company and decide to create their own Microsoft
Business Solution.
Figure 1.4 Concorde XAL Source: dyntips.com
After releasing Axapta 3.0 Microsoft Business Solution become Microsoft Dynamics and
Axapta was renamed to AX and Navision to NAV. In 2006 they create new rebranded
Microsoft Dynamics AX 4.0 with addition of Service Management. Microsoft introduced
AOS (Application Object Server) as Window service, CLR (Common Language
Runtime) interoperability and Application Integration Framework. In 2008 Microsoft
relaced Microsoft Dynamics AX 2009, ERP software still in use in Italy and around the

10
world. This was first of many steps of bringing Dynamics into Microsoft family.
Navigation bar and area pages are added to accomplish look similar to Office. The focus
was on businesses expanding globally, as new software offered functionalities to reduce
the complexity of managing operation across many companies. The role-based user
experience and workflows are some of new things related to this version of software.
From technical side of view batch server computing and code versioning control are
added. Microsoft Dynamics AX 2012 is released in September 2011 and it brought the
biggest change in any new version. Most modules were redesigned and there were some
new modules like Sales and Marketing and Procurement and sourcing. AX 2012 was
available in 25 countries in 23 languages. Some of new tools available for developers
were .Net proxies, events and attributes that could define metadata. For the end user there
were changes in design with action panes, fact boxes, strip menu and the experience of
using XML- based SSRS (SQL Server Reporting Services) for printing reports. In the
following years the application had 2 more relaces R2 and R3 that bring new
functionalities. Microsoft officially ended mainstream support for AX 2012 R2 and AX
2009 in October 2018 and the support for Microsoft Dynamics 2012 R3 was ended in
October 2021.
In the end of 2016 Microsoft introduced the new ERP solution. Led by Satya Nadella’s
mantra “Cloud First-Mobile first” Microsoft created Dynamics 365 cloud solution
currently in use. The new enterprise solution brought together ERP and CRM under one
software. Not only that, but Dynamics 365 also growth beyond ERP having to offer other
Microsoft products like Office, Word and Power BI. New cloud solution it is easily
accessible from any device anywhere in the world. The new Warehouse module gave
great mobility to the workers on site and Electronic Reporting made the information
shaping rapidly customized. The third-party programs can connect to Dynamics 365
through Common Data Service for apps and Data Lake. There is also an AppSource where
ISV (Independent Software Vendors) can offer their solutions that function as an addon
to Dynamics 365 core. The trend continued with integrating tools like Cortana digital
assistant, Power Automate and PowerApps. Next, they introduced robust Microsoft
Dynamics 365 AI to help making better and more impactful decisions. Recently, other
tools like HoloLens Mixed Reality Glassies and Dynamics 365 Remote Assist are added

11
to Dynamics family. Microsoft also gave the possibility of using the solution suite on-
premise (Local Business Data) or in hybrid (Cloud and Edge) version.
Figure 1.5 Dynamics 365 suite Source: cloudblogs.microsoft.com
1.4 Sap History
In 1972 five former IBM employees started a company named SAP (Suystemanalyse and
Programmentwicklung). They wanted to develop real-time processing financial
accounting software. One year later they introduced SAP R/1 with clients only in
Germany. In the seventies they add inventory management, purchasing and invoice
verification. SAP was working on IBM servers and DOS operating system. In 1979 they
released R/2 that had capability to cover all business functions including newly
implemented production management module. In the eighties SAP was present in every
European country and more than 1000 companies operated on their software. In 1992
SAP brought new SAP R/3. It was built on the client-server concept that allows user to
access the system via any computer connected to a network. With their software SAP was
aiming large and midsize companies. They were working with Microsoft to release the
SAP R/3 for Windows NT server. In 1996 they went online allowing their clients to
connect online applications with SAP R/3. In following years SAP introduced
mySAP.com that combined e-commerce with ERP applications. In 2004 they released
SAP ECC (ERP Central Component) with Service-Oriented Architecture which meant
that different areas of business were heavily integrated ad the data flow between modules

12
was efficient. In 2009 SAP released SAP Business suite 7 with new maintenance and
update approach. Only 2 years after, SAP introduced SAP HANA and allow their
customers in-memory computing. This was a big break throw shortening a data analysis
from few days to minutes and seconds. SAP started investing in cloud and mobile
companies becoming one of the leaders in the market. The mobile business applications
opened the market for the users that needed mobility. In 2015 SAP release the new
generation of software SAP S/4HANA. It was designed using SAP Fiori user experience
(UX) and it was completely built on proprietary SAP HANA (High-Speed Analytical
Appliance). In addition to intelligent ERP, the suit includes supplier relationship
management (SRM), customer relationship management (CRM), product lifecycle
management (PLM) and supply chain management (SCM). The S/4HANA was also
suitable to combine transactional and analytical functions of different system into a single
source software. There are multiple deployment options on-premise, cloud and hybrid.
The cloud version is available as SAP S/4HANA Cloud and also in private cloud for
companies that are experienced and can host the solution on their own cloud. In 2017
SAP released SAP Leonardo, the new digital innovation system with capabilities in Big
Data, Internet od Things (IoT), machine learning and blockchain.
Figure 1.6 SAP S/4HANA Cloud Source: sileron.com

13
Chapter 2: ERP Implementation
2.1 Introduction
Like we already discussed in previous chapter ERP solutions have a big history of
implementation in different industries. In last 20 years the computers had become more
powerful, and the businesses had grown larger. With more computing power the ERP
software had the space to expand and nowadays it covers every aspect of business. There
were different approaches throughout the history and the ways of implementing ERP
software have changed. Although the software had become more complex today we have
endless examples of successful implementations, but it doesn’t mean that there is a
definition of perfect path to take because every company is different. In this chapter we
will discuss how should company approach the ERP implementation and what are the
biggest challenges to overcome.
The implementation can be divided in 7 different phases:
1) Planning
2) Discovery
3) Design
4) Development
5) Testing
6) Deployment
7) Support
In the first phase it is defined how to prepare for an ERP implementation, what are the
key things to consider when buying ERP and how to organize you project team. In
discovery one of the biggest questions is cloud or on-premise. This part is most important
in every ERP project because it sets the foundation for the future realization. The design
explains necessary change management and how to address it, use of “in the Box”
solution, fit and gap list and design software together with implementation partner. The
Development stage is when we start to create or shape the software. This includes
configuration and customization of the software in order to support redesign processes. It
also introduces three different phases of data migration: extracting, transforming, and

14
loading data from different legacy systems. This phase also includes interfaces with
extern software. Testing and development could be performed at the same time. Together
with testing in this phase we should perform training session where users can perform
their day-to-day tasks. Deployment is final but not the last step in the ERP
implementation. In this phase system goes live and users start to use it in production. It
will be explained how to prepare for potential initial setbacks. The last phase is support
and it covers system maintenance and user support as well as continuous updates of the
software.
Figure 1.7 ERP life cycle Source: by author
2.2 Planning
2.2.1 Project team
The initial task on every project is defining the team that will conduct the project
implementation. Often the reason of failed projects is the wrong work environment and
management that isn’t involved enough. It is important to have the team defined from the
beginning of project as they will have bigger visibility on what has already been done and
will understand more in detail every aspect of project.
Planning
Discovery
Design
Develo
pment
Testing
Deploy
ment
Support

15
First the project lead will be defined, and he will be involved in project team selection.
The project lead is often referred as executive sponsor. It is the person that reports to CEO
(chief executive officer) who is responsible for the success of the project and answer to
the board. The executive sponsor provides project direction and makes sure that the
project team is aligned with company strategy. He is also responsible to overcome a
possible resistance from senior executives who often don’t want to support the
management change. This person could be also the CIO (Chief Informational Officer),
but more effective pick is the person that will be directly affected with new
implementation, the Chief Operation Officer. Project owner is the person that must
coordinate the project and take all the important decisions. This person should have
experience in ERP implementation, understand processes and technology involved in
project. Business project owners are responsible for different business processes in their
area of interest. They must know in detail every aspect of their business. One of main
problems in implementations is that business project owners are not involved into the
project and important process decision are made without their knowledge. Project
manager is someone who organize day to day project activities but also have good
understanding of entire implementation. He must provide status on project, deal with
budget, manage risks and personal problems of other team members. Not only that, but
he should also be a person with attitude, diplomat and resistant. His position is between
the senior management and other team members. Subject matter experts are the persons
that work in the specific business area and provide a knowledge and expertise on their
subject. They define procedures and standards, performance objective and
recommendation for procedural improvements. Also, they define acceptable performance
levels. Project core team is selected form different resources from deferent fields inside
of company that have understanding what the flows of the system are and how to improve
them. They are also referred as “power users” and they can help other colleagues when
system goes live. Business analyst work on translating the business requirements into
system. They manage communication and cooperation of different divisions within the
business. They also can have a role like core team members providing testing, training
and at the end, support after going live. IT specialist is the person that have deep
understanding of software used in company and how this software supports business
processes. It is probable that companies have business specialist that work on the legacy

16
software prior to ERP implementation, but moreover the IT specialist are hire after the
software selection. They have already knowledge and experience with selected software
and can make the transaction smoother. The role of IT resources and developers depends
on the project. There are examples of integration project where the development of the
new functionalities and shaping of the core system is delegate to implementation partner,
and on the other hand there are the companies that prefer to manage the development
inside a company. Most common option is the fusion of vendors developers and end-user
development team. In this way companies tend to transfer the project manutention and
updates on internal team. On the other hand, with new ERP cloud solutions there is no
need for system administrators and server maintenance.
Vendor personnel
Most of ERP software producers don’t follow the ERP implementation project. After
deciding which software to implement, company should choose the implementation
partner. The implementation partner team is made of experience professionals with
specific knowledge about the software and the implementation process. Account manager
is the person that connect company and software partner. They are responsible of sales
and have customer satisfaction as a goal. Account managers also need to learn about
continuous changes in software and how they can benefit or affect the clients. Project
manager defines the scope of the of the project. He must be aware of potential risk and
build the long-term plan to overcome them. His role is like the role of project manager on
client side, and they have same goal, successful delivery of the software solution. Then
every project has an architect, person that has lot of experience in ERP implementation,
create end-to-end solutions, understand potential risks and how they can affect other
streams. Together with stream leaders he creates different processes and changes existing
ones. Stream leaders are senior consultants that cover specific area of business. Almost
every project has financial stream leader and depending on business stream leaders that
cover production, sales, marketing, supply chain and other areas. Also, different stream
leaders are responsible for BI, CRM and integration with other software. Every stream
has different consultants that write documents, run training sessions with clients and test
new customization. Technical lead on project manages other developers, evaluate

17
different gaps and work with consultants on creation of technical documents. Team of
developers can also be divided by area or technology they use.
Steering committee
Steering committee is one of the most important things in every digital transformation
project. It is responsible for setting the tone and overall direction of the project. They are
also responsible for high level strategy, overall time frame, big business process changes
and budget defining. Steering committee is also involved in changes along the way,
whether it is change of budget, scope or major customization. The committee is made of
decision makers, both from client and partner side as well as third party quality assurance
company.
2.2.2 Implementation methodology
The most used implementations methodologies are Waterfall and Agile. Before starting
the ERP project of implementation, every company must understand different approaches
and methodologies. Not only in ERP project, but in every software developing project we
need to adopt certain approach suitable for the software developing or implementation
project.
Waterfall
Waterfall is traditional, step-by-step methodology introduced in 1980s. With this
historically traditional way for implementation of software technology every project
phase is well defined. It keeps all the activities in linear order from start to finish. For the
ERP implementation project, it is a good fit because company must do things in
chronological order. For example, first there is analysis phase were all requirements and
business processes are defined and only when this phase is complete the second phase
can start. One of the advantages of this approach is that is very simple and easy to
understand. It also reinforces some good habits: define before design and design before
code. Some of drawbacks are that waterfall assumes that every phase is perfect, and no
change requests can’t take place. Also, there can’t be overlapping between phases, so
every development task has to be completed before testing and training sessions.

18
Agile
Because of the waterfall’s difficulty to adapt to continuous changing of processes, in early
2000s the new methodology is defined with proclamation of Agile manifesto. The main
principles are:
1) individuals and interactions over processes and tools
2) working software over comprehensive documentation
3) customer collaboration over contract negotiation
4) responding to change over following a plan
Agile methodology is faster and more flexible than waterfall. After the project start team
cycles through planning, executing and evaluation. This methodology defines smaller
parts of organization in order to and get value and deliver functionalities faster without
spending lot of time in analysis only to start a project.
Figure 2.1 Waterfall vs Agile Source: vitolavecchia.altervista.org
Hybrid solution
The main thing to be taken in consideration when choosing right methodology is company
business and structure. For smaller entrepreneur or startup company that changes fast
agile is better solution. For bigger multinational organization that acquire other
companies more waterfall centric approach make sense. Although Agile is generally
better and typically used for software developing, the ERP projects are implementation

19
of already existing software in order to fit the company’s requirement. In general, the best
approach is Hybrid one. Waterfall when come to defining overall solution and agile in
development and testing phase.
2.2.3 Defining requirements and scope
Requirement gathering is time-consuming and complicated process that at the end
produce a document containing all the information relative to creation of ERP. This also
assumes that the requirements do not change over the time which is not always truth.
Sometimes keeping track with on-going changes can be very difficult when the duration
of the project can be longer than a year. That’s why the detail document containing every
little information on what users expect of new system is not always a good idea. The most
important thing is defining best practice that is sensible for all processes that business
involves. Although best practice sometimes doesn’t cover all of the system requirements
it should be use as a foundation to be built on. The aim of gathering requirements is
defining processes, what they do and understanding the issues that need to be handled.
Orientation to processes instead of standalone functionalities improves the likelihood that
there is a flow between different activities and that all the issues are addressed. The
processes can be viewed as a purposeful activity that involves transformation of input
into output. The input are resources and output different products or services and in
between are interactions and transformation that are usually not appreciate. Only if an
individual understands what the purpose is, he can consider whether the right
transformation and interaction is taking place.
Many companies don’t have in house expertise and resources for establishing
requirements. Instead, they may decide to contract some other consulting company to
carry on this task. While they can deliver detail document of all processes it is not
uncommon to carry out this activity in house. The reason behind this is that requirement
definition has other benefits for the persons involved in analysis. First of all, they will
develop a good understanding of business and potential issues. There are different tools
that can be used to collect and sort data, document business requirements, workflow
management and prototype creation. Some of most popular tools are:
1) Modern Requirements 4DevOps - build on Azure DevOps, provides online review
and approval through e-signatures

20
2) ClickUp - used also for project management, highly customizable and can sync
with Google Calendar
3) Blueprint - helps companies to digitalize the business processes and supports
digital transformation
4) Axure - used for developing, prototypes and wireframes; allow access to multiple
users on the same document
When talking about defining requirements it is important to segment our business
processes. The process handling is based on prioritization of different processes because
it has to be assumed that time and money are limited. They can be divided in two types:
core competences and commodity processes. Core competences are the processes that
make the company different form other business and successful. Some of them are
customer facing processes, employee experience and product/service based processes.
Commodity processes are similar in every organization operating in same business area
(General Ledger, Account Payable etc.). The difference between two types is that the
commodity processes will probably be take out-of-box without losing anything but
gaining more efficiency. On the other hand, with core competencies it is not possible to
use standard ERP solutions and companies are more likely to customize this port of
software so they can maintain the things that make them unique in market.
One more thing to consider when creating the list of business requirement is how much
business process detail do we need to get into? It is possible to break out business
processes based on hierarchy, starting with macro processes on level 1 and ending with
transactional level 5, where the step in system is defined (buttons to be press, fields to be
populated) in order to achieve something. Different levels need to be defined in different
instants of implementation. In the discovery stage we should describe the levels where
technology that we use doesn’t matter. First levels are the processes that should drive the
technology.
Another important aspect to be consider is a scope of implementation. Common opinion
is that ERP software can cover every process, which can be true, but one software can’t
be best-of-bread in all aspects. It is crucial to have an idea of project’s biggest needs and
based on that select the best fit. If it’s decided that some legacy systems are efficient, they
could be integrated with new ERP. Also, there are different approaches on how to start

21
the implementation. It can be decided to use so called “big-bang” approach where the
complete switch-over from old legacy system is made or to introduce software in stages
rolling out core functionalities first. In the ERP world of big and medium companies, the
second one is almost always used because of complexity of the system. Project can also
be divided not only by different functionality stages but also by different legal entities
inside a company.
2.2.4 Cleaning up data
The data represents the basic of every informational system. One of the things to be done
even before selecting an ERP is cleaning up the data inside of legacy system. The concept
of GIGO (garbage in garbage out) can be applied to data that is imported to new ERP
software. Before a go-live we need to have clean, standardized data without duplicates. It
is possible to have two records for the same customer, different items with same name
and so on. To prevent this type of errors we should identify system owners that have
knowledge about system data. They should have authority to make changes in legacy
system in order to prevent transfer of error data in new ERP.
2.2.5 Benefits-cost
Potential benefits need to be defined before starting any ERP implementation project.
ERP projects are very complex activities that are costly and time consuming so before
starting one it is necessary to justify future efforts. Benefits can be tangible or intangible
and defining them is not an exact science. Knowing them will give a company useful
picture of what to expect. The organizations that are growing needs more powerful and
scalable software that can expand with the company. Flexible system allows adding new
users as growth occurs and, if in the cloud, enable workers to operate remotely. The
growing of organization often means new merges and acquisitions and parent
organization needs streamline system across companies. One of the biggest benefits
gained from digital transformation is efficiency. Processes and workflow that was
inefficient in the past now become more efficient because of streamlined way of operating
data can flow continuously from department to department and cycle time are reduced.
Another potential benefit is increased transparency and improved collaboration. With
fully integrated software with single source of data, BI capabilities and reports it is
possible to see in real time what’s happening within the business and possibly adjust to

22
the new situation without waiting different persons or departments to finish their analysis.
Employees empowered with CRM and sails modules have appropriate data and tools so
they can sale more to the customers and bring additional revenue to the company. Another
way to increase revenue is throw customer service because customers are willing to spend
more for better service. ERP implementation also bring better customer experience
allowing them to have more visibility on their orders and to know what is available in the
warehouse. Lot of organization that are successful in their digital transformation will
spend less in number of areas from manufacturing to finance. Unifying company legacy
systems reduce spending on multiple licenses, infrastructure and resources to maintain it
all. Another example of cost savings is possibility to grow without hiring new people.
Digital transformation improves employee experience creating workspace attractive to
young and talented people and also helps retaining them by providing learning
opportunities that they might not have otherwise. It can gives the employees opportunity
to grow together with the organization. Better technology brings general usability and
make everyday job easier.
All the benefits mentioned above come with a high cost. To understand what the exact
cost is there are lot of parameters to consider. Softwarepath conducted research on 1338
ERP project implementations, and they come up with a budget of around 9000 dollars for
1 user in 5 years. The cost of project is often calculated by percent of the organization
annual revenue.
Major costs on every ERP implementation project are:
1) Licensing – there are 2 type of licensing perpetual and subscription. Perpetual
licensing allows organizations to install ERP on-premise. Subscription licensing
or SaaS (Service as a Service) licensing is a monthly price per user. This pricing
model is suitable for companies implementing cloud ERP solution. Businesses
pay manual or annual charges for using the software. The subscription model
provides scalability and flexibility and reduced upfront cost. In this case the ERP
software is hosted and maintained by vendor.
2) Additional ERP Modules – some of ERP have lower cost for basic models and
additional cost for industry-specific modules or specific functionality for different

23
countries. Some of them are developed by ISVs (Independent Software Vendors)
and can fill large gaps in the system.
3) Implementation partner – this is by far the biggest cost on the project.
Implementation is always conduct by partner consulting company specialized for
specific ERP. Their responsibility is not only to set-up the system and import
legacy data but also to customize the system so it can fit the company
requirements. This cost should also cover user training and manuals.
4) Internal team cost – different roles are needed to support ERP implementation
internally. Some of them are involved part-time but the cost of internal team
salaries should be taken in consideration when calculating total project cost.
5) Integration cost – this is additional cost for all the interfaces with another systems.
The cost is not strictly for developing the interface but also for number of
transactions processed in cloud or different licenses.
6) External consultants – if there is no internal resource capable of managing
requirement analysis, ERP selection or project manager experienced with certain
type of ERP software, external consultants are required.
7) Living and travel expenses.
2.3 Discovery
Selection of the ERP software is a big decision that will decide a system strategy for many
years. It has financial impact on the company as well as impact on all the people involved
in the project. Also, all the available information should be taken in consideration. This
product will be a core of entire system, and everything is going to need to connect to ERP.
Implementation is difficult, expensive and time consuming task so choosing right
software is critical.
When starting a selection process, one of first questions is the type of request that the
organization what to use when approaching potential vendors. RFP is a request for
proposal, a document in which organization asks a specific set of services to a vendor and
RFI is a request for information used to gather more general information on vendor
products. Timing of evaluation process and making sure that right people are involved in
selection process are of great importance. Another important task is a selection of a
decision maker. This person is almost always CEO, but he has to be involved in the

24
selection process in order to understand all of the things necessary for selection of ERP
that fits the company and not to make decision based on financial offer.
Then, what will be the perfect number of vendors to select from? Based on list of
requirements, company size, cost and technology the list of 10-15 vendors can be made.
After gathering different RIFs and conducting additional search through vendor’s web
site and online the final list of a small number of vendors can be made. In the final
selection of the ERP software 4 things can be evaluated: fit, cloud or on-premise,
implementer and cost.
2.3.1 Fit
Fit definition is how closely the solution match the company system, taking in
consideration the processes that are in scope. Based on document with all the requirement
the company should decide which solution provide most on functionalities in-box.
Different requirements can be resolved with change management, so that number of
customizations remain low. Vendors should explain how ERP can interfaces with other
system that organization want to maintain. Another important thing to consider when
selecting an ERP is the presence of software in company’s industry. The biggest ERP
software companies like Oracle, SAP and Microsoft are present in almost every type of
industry. Different ERPs have verticals for specific industries that can be provided
directly by the vendor or there could be VARs (Value Added Reseller) involved. The
presence of VAR that is useful in project implementation can save some money and time
especially if it’s proven and widely used software and because of that ERP with different
VARs are more desirable. Verticals can also address specific counties and regulations
present in those countries. When the industry is cover with more different software
another thing to be consider is fit/gap analysis. After deciding that solution can be a fit on
high level it is important to get down to detail and figure out which software will be the
best fit for the company. First it is useful to define and rank requirements and processes
from must have and value added to nice to have and then measure the solution based on
those requirements. The measurement should take in consideration if the requirement is
present out of the box, if it is something configurable or does it require a customization
and if customization is needed than how impacting is it. If the requirement is present out
of the box or if it’s configurable those are considered fit and if it’s customization or a

25
third party product those are considered gap. It is crucial to compare results of fit and gap
analysis provided by vendor with real demos in order to understand what the real fits are
and to which extent. Without considering fit it is possible to end up with a solution that
doesn’t meet the organization needs, with customizations that can be costly and not
reliable as an out of a box solution. ERP that is designed for big multinational corporation
may not be a fit for a company in food industry with special requirements in production
and logistics. Personal experience supports the points made. Working with Microsoft
Dynamics 2012 in company that was Microsoft golden partner, the software is
implemented in one of the Italian biggest food companies and the result was a large and
complex software with lot of customization. The implementation took 3 years and
exceeded initial budget couple of times and the results was not satisfied for both client
and vendor. When considering fit it is important not to forget other factors that should
influence selection process. An ERP that seems to be perfect fit can have maintenance
problems, interfaces issues and also cost too much.
2.3.2 Cloud vs on-premise
On-premise computing is the type of computing in which all the computing resources are
managed and accessed from the premises and on the other hand, in cloud computing the
resources are accessed online. Another option is hybrid solution where functionalities can
be divided on multiple tiers for different functionalities, for example sensitive financial
transaction on-premise and logistics in cloud. Cloud solution are present in the market
for the last 10 years, starting with Sales Force and Net suite, and as every relatively new
technology the cloud solution is not accepted in the easy way. One of the first issues that
were raised when talking about cloud is data security and the possibility of processing
large arrays of data. Also, the cost of cloud hosting was way more expensive than on-
premise hosting. Nowadays cloud is considered a secure place for storing sensitive data
or application. The biggest firms like Google and Microsoft with basically unlimited
resourced and teams of experts are working on making their cloud the reliable and secure
place. The security breaches became very rare and sporadic invents but have to be
considered. It can be discussed that cloud become more secure place than on-premise due
to lack of expertise of people that maintain in house hardware that are often outdated.
Although that cloud computing can be considered well protected there are some examples

26
of data breaching in recent history like Microsoft breach that exposed 250 million entries
in 2020. With security as a main concern, large number of ERP implementation (97
percent by some sources) are in cloud. The main advantages of cloud are scalability,
flexibility and cost. Cloud computing is viewed as a utility or pay as you go. Unlike on-
premise system where large upfront investment is required for purchasing both software
and hardware in cloud-based ERP the initial cost is much lower because cloud software
is priced based on monthly or annual subscription. Besides that, company with on-
premise software should have a team that are capable to maintain the hardware and to
applicate new updates. This type of pricing makes the cloud solution more available for
small and medium organization that doesn’t have resources for buying perpetual license.
Most cloud system are easily accessible via mobile device or a laptop from any place any
time. Moreover, cloud ERP solutions are continually upgraded by the provider and
software is always on the last version at the disposal. Cloud ERP can also grow with
business providing more subscription or more store usage along the way. Cloud ERP also
provide different strategies for disaster recovery, one example is Microsoft 365 that runs
on Azure that can be stored in different countries. As for the customization and niche
industries on-premise ERPs are easier to modify. Depending on business model
organizations should decide which computing model suits them the best, with on-premise
model that is initially more expensive but offer advantages in customization and control
or cloud model that is more accessible and flexible but have potential security concerns.
Figure 2.3 Cloud ERP Source: tyasuite.com

27
2.3.3 Implementation partner
ERP solution are almost always represented by implementation partner. It is not best
practice that a company try to implement the ERP by itself using in house resources
because this can be highly complicated and complex task for untrain team without any
experience. The success of the implementation project depends on the level of expertise
provided by partner. When selecting a potential ERP software, it is also important to
select a reliable implementation partner. The first thing to take in consideration is
implementation plan and what will be the way of measuring the progress. Partner that
understands processes and have experience in the specific industry is another thing to
look for. More essential than that is platform experience and although the processes don’t
change much the approach used in different platforms will not always be the same, so
knowing the platform is critical for the success of implementation project. Some of
partner will have expertise in different ERP solutions but they are always managed by
different teams. For example, Ernst and Young have different teams for Dynamics and
SAP, but with stronger background in SAP. Also Engineering S.p.A. have both Dynamics
and SAP in their offer. Another thing to consider when selecting the partner is how big is
their team, how many people can work on the project and how will the implementation
team look like. Choosing ERP based only on implementor is not a correct approach
because we can have a confidence in partner expertise, but software can just not be a fit
or the price could be too high.
2.3.4 Cost
There is different way for estimating upfront what should be the cost of ERP
implementation project. Someone consider that software cost to implementation service
cost ratio should be somewhere from 1:1 to 1:2.5. This approach is considered flowed
because with the majority of the ERP solution on cloud there is no certainty what the total
value of software should be. Another way to measure the cost is based on annual revenue.
As stated by Panorama Consulting solution, for more than 84% of companies this percent
varies from 0.5% to 2% of their annual revenue for the ERP project in 2019. Nevertheless,
those numbers are affected by the size of the company, and smaller companies tend to
spend more, even close to 5%.

28
Figure 2.4 Cost as a % of annual revenue Source: Panorama ERP report
The cost in question is the total cost that includes not only the implementation project but
also the cost of subscription, internal cost and protentional ISVs. In order to keep the cost
low ERP customization should be limited and more standard out of the box functionalities
should be used. Also, the good preparation for project that includes cleaning the data,
change management and getting the internal team in place can lower the project cost.
Subscription cost is one of the biggest factors when calculating the overall cost of the
project, and if on-premise the software license cost. For example, the cost of SAP
Business One ERP perpetual license is around 3200 dollars for professional user and 1666
for limited user with additional maintenance fee. Subscription licenses are 94 dollars for
professional user and 54 dollars for limited user. This price includes maintenance and
requires one-year commitment. Oracle NetSuite creates a price based on a different
parameter like required add-on modules, number of users and different ERP
configurations. The base price is 999 dollars with access cost of 99 dollars per user.
Microsoft Dynamics allows purchase of individual modules based on business area. For
example, Sales Enterprise module costs 95 dollars per user and Sales Professional module
costs 65 dollars per user. All prices per user are considered for a month period. Another
cost to take in consideration is potential ISV cost for different specific requirements.
There could be potential hardware costs even if the ERP is in cloud due to improvements
of internet connection needed for accessing ERP. Calculating ROI (return on investment)

29
is another thing to be considered. This is a most common way to measure project returns
that is calculated by adding up expected returns form ERP and that subtracting the
expected cost of the ERP. Quotient of the ERP is obtained by dividing this value with
expected cost. Bigger the quotient is better the investment ranks among other choices.
Also, on every ERP project additional contingency cost of around 20 percent should be
planned to cover all unexpected costs.
Although it may seem the most important thing on every project, final decision can’t be
made only based on cost. Implementation with ERP system that doesn’t fit the company
or implementation partner that don’t have enough experience to lead this complicated
project can and up costing the company much more than average implementation. That’s
why it is crucial that the decision maker base his decision on all available parameters.
2.3.5 Change management
Every enterprise resource planning project represent the bridge that connects IT and
business, and it brings technology-driven change management TDCM with itself. Change
management can unlock full software potential. Not only it is mandatory, but it also
reduce possibility of project failure. A new ERP software is a perfect place to implement
changes across the organization. ERP system impact company entirely and it is involved
in every process, so it is important to be sure that new software is adopted from all users.
2.4 Design
Design of the ERP solution can be creating a new software from scratch but nowadays
it’s more shaping an existing ERP in order to fit the company requirements. Degree of fit
is one of the things that can decide purchasing the specific solution. But design is not just
adding new functionalities but making the existing ones usable for the specific company.
It is understanding how the desired ERP can be fully used in order to improve the
business. On top of that there are different integrations with legacy systems (that should
remain active) and how and at which level they can affect the existing processes that are
already present in ERP.

30
2.4.1 Organizing processes
There is no ERP software that can work 100 percent out of the box. Different
developments and customizations are part of every ERP project, and they are used for
specific functionalities present in company. Changes come in place when there is no
solution present in ERP. It is important to identify core processes and understand how
they can be translated in ERP. The core processes are used in every company area:
finance, HR, procurement, service supply chain, manufacturing, and others. These
processes are represented in every ERP and every company should tend to standardize
them. In order to standardize core processes company should follow best practices
introduced by software vendor. Standardization of processes is firstly made to improve
productivity and it is introduced by APQC American Productivity & Quality Center. They
developed and continually updated the process classification framework PCF that
explains hierarchy of processes in different industries. One of the methods to determine
and standardize processes is dividing them by:
1) Process category
2) Process group
3) Processes
4) Activity
5) Task
The scope of this exercise is to break down core processes of the business in order to
rebuild the system around them. One more method used for discovering processes inside
a company is SIPOC that means:
1) Suppliers
2) Inputs
3) Processes
4) Output
5) Consumers
SIPOC is used as a visual tool for documenting processes form beginning to end. These
diagrams are useful for high level mapping of processes, and they help to maintain a focus
and find a common language for defining processes between different team members.
SIPOC diagrams can be created in 7 steps:

31
1) Chose a process – chose specific business process and crate a team around key
users that have deep understanding of this process.
2) Define a process – overview of high level steps that determine this process
3) Identify the outputs – this section describes couple of different possible outputs
4) Identify the customers – persons/companies that will benefit from the process
5) Identify the inputs – resources necessary for process to work
6) Identify the suppliers – each of inputs should have defined a supplier
7) Share the diagram – diagram should be shared and validated by all the stakeholder
involved in the process
When it’s finished, diagram provides high level map of processes, it can be used for
identifying the problems or creating a process analysis diagram. Most obvious advantages
of this approach are transparency across the organization and overview of the processes
for all stakeholders.
Figure 2.5 SIPOC Diagram example Source: navvia.com/
2.4.2 Project kickoff
Before kickoff project most if not all preparation for the project should be finished. First
it is important to fully understand meaning of organizational change management,
business processes improvement and have a team in place that will be responsible to carry
on this project. Then, another thing that should be well defined is the current state in
company with the blue print off all the processes. Only by approaching the
implementation in an informed manner, the company will be in good position to succeed
in the ERP implementation. Best time for the kickoff meeting is 5,6 weeks after the end

32
of the selection process. This time is needed to go throw all the planning for environment
management, data migration and testing. It is also important to establish entrance/exit
criteria that should be meet before moving to the next step in the project. This meeting is
an opportunity to set a tone for the entire project. It is a briefing meeting that will inform
project team members and company management on future steps. Also, it is important to
show the background and the current state in order to make the comparation with new
ERP solution. Executive team as well as vendors representatives should be present at the
meeting. Every key business process should have at least one team member.
At the beginning of the kickoff the person with most seniority (probably CEO) should
make the introduction and it is important to underline that company stands behind the
selection of the ERP and decisions to go into the digital transformation. Then, all the team
members involved on the project and the team hierarchy should be presented. It is
important that everybody knows who the persons in the implementation team are and
what is their area of responsibility. Also, the implementation team of the partner should
be introduced. In that way ERP project can be seen not only as a new software but through
the persons that will make in happen. Then it is important to outline the scope of the
project and essential processes that will be cover by the ERP. Defining the scope can
prevent your team to overreach and go out of the expected time and budget. The time to
go-live needs to be establish and communicate to the audience. It is also important to
justify the amount of time and resources spend on the project and to explain why this
digital transformation is necessary. Also, it needs to be explained how will new software
impact the growth of the company and what are the benefits. People from different areas
of business will also be interested to understand how will this change affect them
personally. Getting them on the digital transformation side is crucial. This meeting is like
a milestone in the company life, and it is important that after this meeting everybody
believe in brighter future with a new ERP software.
2.4.3 Design together
Like it’s mentioned before there is no ERP that can cover every aspect of the business,
and that is because in some areas every business is different. Every company have their
way of doing business and in some cases it can’t fit the ERP. Those differences can be
overcome by changing processes in order to execute them in more standardized way so

33
they can fit the software and not only that but also to make them more efficient.
Sometimes the process or subprocess can be specific for industry or a country and
therefore not covered by ERP. In this case the gap has to be analyzed and the solution to
cover the gap have to be found.
There are different approaches to resolve fits and gaps. Historically client should define
all the requisitions and then, based on those requirements, software vendor or partner
should find a solution. When solution is all done, and the coding is finished the solution
is presented to client and often it doesn’t match the picture that client have on their mind
and it’s not usable business. That’s why, this approach is considered ineffective and can
be long and costly, and jet, it may not satisfy the customer. This is a reason behind a shift
in approach that is used when designing a software.
Nowadays, ERP software are designed collaboratively with client. The concept behind
this approach is called JAD (Join Application Design) and is introduced by Chuck Morris
and Tony Crawford form IBM. The JAD includes different workshops with clients where
the future design of ERP in considered. Although the ERP standard solution often
represents 80 percent of the system, this standard part of ERP needs to be parameterized
in order to fit client needs. Another important point of this approach is that client becomes
familiar with software from the start of the project. Becoming familiar with ERP clients
are more likely to accept the change and get used to new way of doing things (although
sometimes it is just different naming or frontend look). One more thing to be aware of
when designing a solution with subject matter experts is that they will always tend to
design the solution “as-is”. On the other hand, leadership will always try to look at the
future and to define the process as “to-be”. It is important that, whenever it is possible,
“to-be” approach should be used so the current system can be improved. In this case
subject matter experts have to understand how we can improve the current way of thing
so they can be on the same page as leadership. Often, the main reason why the people in
team prefer “as-is” is simply because they are used to do things in certain way.
When the methodology of working together with client is define the workload should be
divide in different stages and every process is divide in phases. Like in the figure 2.6 of
the Order to Cash process every subprocess should be discussed separately.

34
Figure 2.6 Order to Cash process Source: oracleapps2fusion.com
The workshop always starts by introducing the standard out of the box functionality that
covers the process. Sometimes with little customization or parametrization it is possible
to cover the company process. As the partners functional consultant go throw standard
process already present in ERP, the company personnel that is involved in this process
should be involved in dialog by shoving how is the ERP process different from the
company process. The communication between two sides is crucial in order to create a
good solution. If the subject matter experts or business owners are inactive and don’t
participate in the dialog they my finish with software that doesn’t cover their needs. The
main advantage of this approach when designing the software is that future users get to
know the system and are able to define requirements that are missing. At the end of this
meeting the list of fits and gaps should be created. Some of the requirements may remain
undefined and for them further investigation is required. For all the gaps define in the
meeting, consultant should design the possible solution and present it in another meeting.
For the more complicated designs the system architect with technical background should
be involved. Between two meetings (or better group of meetings) there should be time for
preparing a solution for defined gaps and for investigating things that remained
undefined. In the next set of meetings, the setting should be the same. Consultant should
walk through the process in ERP but this time, system will be more configured, and the
data should be similar to real data present in organization. This time out of the box
solutions should be validated and put aside. In this meeting it also important to investigate
exceptions to the standard process and how will they be represented in the system. This

35
is also the moment to validate small customizations and to start discussing the bigger
ones. The consultant should always tend to find work arounds or to propose the solution
that will use as much as possible out of the box solution. For the last set of meetings most
of the solution should be well defined and presented to users for validation. Also, some
of the data from the migration should be used in this meeting in order to give better picture
of the system after going live.
At the end of these collaborative meetings all the processes should be defined and
represented in ERP. Ones that are already present in ERP will be marked as fits and ones
that need additional development will be marked as gap. In this way partner will have
clear picture on how to proceed with implementation and client will have better overview
on system and its future look.
2.4.4 In the box solution
Like it’s already mentioned, staying in the box is one of the goals when talking about the
ERP implementation. It provides the solution that is used in numberless implementations,
and it is proven that the system works. So, with the solution that are coming from the box
called ERP we get system that is already optimized and tested. Making customization
only because someone is used to do thing in certain way doesn’t make sense. Change
management is necessary, and the digital transformation will transform “as-is” system to
the system for future. This is not the only reason why correct approach to design is staying
in the box. For every customization it is necessary to design the process that will fit the
existing processes, then that process should be developed and tested. Also, for every
additional customization partner should provide a documentation, both functional and
technical. And then every customization has its own lifecycle, and it should potentially
be reviewed after some time. The conclusion is that every customization is very costly
and time consuming process.
2.4.5 Customization design
Of course, there are processes that have to be heavily customized but before that all the
options should be checked. Customization could be change of the logic of the processes
exiting in ERP, adding new tables, changes in frontend, new or modify reports or
interfaces with another system. In order to design a customization list of requirements is

36
needed. The requirements are always linked to processes present in organization so they
can be tested when testing different processes. Requirements are in the form of a
document and can be complex like entire process and then divided in different documents
that represent logical or functional subprocesses, or they can be simple as adding a field
into a table or in a report. The design document should first explain as-is functionality in
the ERP and then add the needed modification on the existing structure. Document should
have detail instruction on desired behavior of the ERP process. Logical trace of the events
in system that should happen have to be described. The part of documents are also
securities or how can have access to the newly created functionalities. Process owner
should always approve this document, so the company should know what are they getting
before start of the development. Design of more complex processes must be always
carried on by a consultant that have good knowledge on the entire process, because the
customs that change core functions of the project can have side effects on other parts of
the process that should remain out of the box.
2.4.6 Functional design document
At the end of designs phase functional design document should be produced. It is a set of
specification on how to implement desired requirement. First of all, it should contain the
reason behind creation of the document and to specify what is the mail goal of the
customization. Also, in the overview it should contain all the dependencies if there are
any. This is important because customization can depend on other gaps that should be
completed prior to initializing the current task. Then it should contain the evaluation of
potential risk in changing the standard process. Document need to have all the steps that
need to be executed in order to fulfill the requirement. This part of document should be
approved by business owner. Functional design document FDD also contains a technical
part. It contains the list of tables and forms that need to be changed. This technical part is
created in different ways depending on the implementation partner that make the
customization. It can be very detailed if the developer that have to code the solution
doesn’t have lot of experience, and it could contain all the classes and tables that need to
be modify. Of course, this exercise can’t be done by functional consultant that have no
experience in developing but the creation of technical part is assigned to senior developer.
More detailed technical part means more time that should be spent on creation of the

37
document. Often FDD contains only high level logic, and the gap can be developed by
the same person that wrote technical part of document. The last part of the functional
design document should contain test cases in order to check if program runs without errors
and if the output is correct. This first level test is often caried out by developer himself.
2.5 Development
Development must start when all requirements for the specific core process are defined
together with client. If there are some dependencies with other core processes it is better
to wait that the phase of design is finish for those processes. Only then programmer can
start developing his gap and in this way some of the rework can be avoided. This is when
implementation methodology comes to play. Waiting design to be finish in order to start
development is clearly waterflow approach. It will be shown in following chapters that
after this phase in implementation agile approach is more suitable.
After defining when development should start it is important to explain what it means.
Development is creation of new functionality in programming language or more
programing languages that work together. In ERP this definition is slightly different
because development represent shaping of the existing processes. It sometimes could
mean developing brand new functionality but even then this new functionality should be
part of a bigger picture. ERP development could also mean creating new verticals of
different functionalities but it’s a very rear thing in the implementation project because if
it comes to that probably the external software should be used, or the selection process
was not carried out in a proper way. From personal experience, making a vertical solution
development or design entire process for specific company can be time consuming end
very expensive job, not only for company but also for the implementation partner that
agreed upon this work. Cost of project that goes up to 5 percent of annual revenue can’t
cover this kind of job, and it’s not only development that needs lot of time, but also the
user testing. Of course, this type of processes are entire modules with lot off
functionalities. For this kind of work, it’s always better to find ISV solution for specific
ERP or some other third party software that can be interfaced with ERP.
Key of every successful development is communication between developer and
consultant. Even before writing any code developer should have a meeting with
consultant that should explain the bigger picture of the gap and potential risk and test

38
cases. In the meeting they can go over all requirements and see some similar cases already
covered in ERP. If it’s a more complex gap, the senior developer should be involved in
this first meeting.
Different environments are used for development and test, so ongoing coding will not
have impact on testing. Of course, another different environment is used only for live
production. Depending on ERP, different approaches are use when comes to
environments. In some ERP all developers code in the same development environment
and this can potentially cause an issue because there can be some overlapping between
different development projects. To prevent this code branching can be used. In other ERP
systems every developer has its own development environment where he can code the
solution and then even do the first test. After this first test, code can be released in testing
environment. One of prerequisites for maintaining the development environment is that
it has to be aligned with other environments and it have to contain all the modification
present in the project.
Because of potential dependencies and overlapping the number of developers in the
implementation project is limited. The most suitable number of developers in the ERP
project is 3-5 people. One person should follow entire process, if possible, so he can
already know information flow form input to output. Moreover, same developer should
follow his gap to the moment when it is released in production, because if another
developer has to make reworks on the somebody else code it can be time consuming.
That’s why it’s important to write comments while coding so other developers have clear
picture on the job done. One of the most important things while developing is following
best practice of programming language. It can prevent inefficient code and hidden errors
in production.
One of the best practices that is not coming from a specific programming language is
doing a code review after development. Code review is a two way street because it
provides additional check of the code and help educating second developer that is doing
the review. Code review is not only finding errors in code, because for that exists
compiler, but it’s more improving the code and giving another opinion on potential
solution that can be more performing.

39
After the code review development can be promoted to another test environment.
Development of the gap doesn’t end here, in new test environment code must be tested
with real data and it is possible that it should be redone because of potential bug in code,
unpredicted errors or part of analysis that were missing. Then, the development is sent
back to developer and the circle continues until the code is ready and can be released in
production.
2.6 Data migration
Data migration can be explained in a simple way as migration of data from legacy system
to new ERP software. It is one of the things that cat be underestimated on ERP project
implementation, add still without finished data migration it is impossible to go in
production. With old waterfall approach to implementation the data migration had to be
executed after all modification are coded and tested, but this can be to late. With hybrid
approach data migration has to be stared right after kick-off meeting.
Every company have legacy data that have to be imported in new software. The process
of data migration should start by data cleansing because only the clean data will go into
the new system. Then it is important to decide which data have to be migrated. Most
common things to migrate are customers, vendors, products and all the open transactions.
Then company should decide how much historic data should be imported into ERP and
the common limit is all transactions not older than one year.
The data from legacy system can’t be just directly migrated to new ERP but it has to be
transformed first so it can fit the data structure present in ERP. This is wan ETL(Extract
Transform Load) tool comes to play. Data extraction is maybe the easiest part of three. In
this process it is important to identify all off potential data sources and to specify which
data need to be extract and in which way. Sometimes external help from IT experts that
work on legacy software is needed to define all of tables and relation between them. Also,
there can be different sources of data that have different set of rules. For example, in the
company that I been working for, data is migrated from different sources as every
company that was purchased use different legacy system. When all the desired data is
extracted from legacy system it has to be transformed in order to fit new ERP software.
In order to start transforming the data it’s necessary to do the mapping of old and new
fields. Data should be mapped in order to follow ERP logic. The biggest challenge is to

40
adapt existing data so it can be used in ERP. Sometimes fields can’t be mapped one to
one but some of them have to changed in order to be usable. Example may be different
states of order that can be managed differently in two systems. It is important to involve
experience consultants that have good understanding of the target software in order to
produce meaningful data. The last process in data migration is data loading and this is
when all transformed data are migrated in ERP software. It important to follow the rules
of ERP data as some field can be mandatory and they will have to be present in
transformed data.
Process of data migration happens multiple times over the course of ERP implementation,
first in test environment so that can be tested and used in UAT and then in production
environment prior to going live.
2.7 Test
Testing is an important part of every implementation because no matter how good
development is, it has to be tested in a right way. In can happen together with a developing
phase and also when this phase is partially finished. It is of a critical importance because
a system with bugs or processes that work but with wrong output are not acceptable.
2.7.1 Types of testing
There are lots of different type of testing when comes to testing of ERP, but the main two
categories of testing are functional and non-functional. Functional test should check the
correct functioning of the system, or better are the outputs correct for the specific input.
Non-functional test, on the other hand, include everything that supports the ERP. Some
of the examples for non-functional tests are usability and performance test.

41
Figure 2.6 The pyramid of testing Source: cobaltintelligence.com
Some of the testing types are:
1) Functional testing – it is a category of testing but also represent types of checks
of specific functionality developed by a programmer. It is most common type of
testing, and it is executed by consultant and sometimes developer in order to
validate ERP against the requirements and specifications. Based on appropriate
inputs system is tested to check if it provides expected output. The order of testing
is as follows: first requirement document is defined and approved, then test cases
and test data are created, and, at the end, functionality is executed, and output data
is compared with exapted data. It is often viewed as a black-box testing because
tester doesn’t have to know external system specifications in order to evaluate
particular requirement.
2) Performance testing – this is non-function test as mentioned before. It is used to
test ERP performance, speed, stability and scalability in demanding areas and
situations. It is of high importance to predict how will ERP react in situations of
large amount of data or difficult calculation tasks. The goals of performance test
are to measure processing speed, command response time and workload
efficiency. In cloud software in is important to take in consideration internet
connection speed. This type of test is often run to determine if system satisfies

42
performance requirements. The scope of performance testing is also to locate
potential computing bottlenecks, establish whether the performance is in line with
levels claimed by vendor and measure stability in peak computing tasks. There
are different sub-types of performance testing. Load time is one of the parameters
that could been measured. First load time is measured on a single user and then
for the concurrent users in order to understand how load time changes with incised
workload. Stress test is when system operates outside normal working conditions.
The scope of this test is to determine at what point software breaks. Volume
testing measures how efficient can ERP be with large amounts of data.
3) Automated testing – this type of testing provides quicker way to test some
functionality making long and repetitive test automatized. In this type of tasting
in is important to select appropriate automatization tool. Automating testing use
automation framework to meet specific software requirements. Those type of tests
are conceptually same as manual tests with only difference being that they are
managed and conducted by a program using artificial intelligence and machine
learning. Ones implemented, testing automation solution can execute wide-range
of tests. They can save lot of time after system updates when regression tests are
required. Some of the best test automation tools present in market are Accelq, Avo
Assure, Applitools, Eggplant and Virtuoso. All of these tools tend to be codeless
and therefor convenient to person without programing background.
4) Integration testing – this test has the scope to determine how well different units
of software work together. In the word of ERP software, it refers to testing of
interfaces with third party software. This can potentially be the source of many
errors because of different data structure, wrong mapping, or even different
functioning of a software. This test should be performed by experience senior
consultant or architect with deep knowledge on data flows in both systems.
Integration test should also take in consideration timing of data transfer from one
software to another. For example, creation of client doesn’t have to be immediate
but financial transaction transfer shouldn’t take more than few seconds.
5) Security testing – not every person can access company sensitive data. There
should be different security roles based on position in organization hierarchy and
job nature. Also, there are different roles that give a person date uses software a

43
possibility to view, update, delete or insert data. One obvious example of security
is that only HR personnel can see workers retributions. Security testing can be
performed together with other types of testing.
6) End-to-end testing(E2E testing) – represent testing of entire process covering all
business cases and developments involved in process from beginning to end. The
tester should use real company data and preform the test in the system that has
been setup as a production environment. Two types of end-to-end testing are
horizontal and vertical testing. Horizontal testing may be performed across
multiple applications or on single ERP software. This type of testing can include
different area, for example production of an item, inventory status, shipping
details and even invoice creation. It can follow entire life of an item inside a
company. In vertical testing different layers of application are tested.
7) Regression testing – it is responsible of overall stability of the system in presence
of new code changes or updates elsewhere in the system. They are recommended
after mayor updates of the platform. Test are carried through on software or parts
of software that is already been tested. It can be performed on entire software but
that is not always necessary. ERP software should be tested with regression test
after a program update that typically happens 2 times a year. This test could be
prioritized, and only heavily developed modules could be tested. One of the tools
that can easy a regression test is automatization test that can be performed after
every code change.
8) Usability testing – it is not specific testing on a functionality or process but more
on design and general user-friendliness of the ERP. Sometimes it can be done
directly by user and based on their response make the modifications.
9) Use case tasting – provides complete test for use case scenario. It can be done
across different processes and areas of ERP. It is used to control if the functions
performed by user are being executed correctly. This is black box testing because
there is no inspection of the code, but software is used as a black box. Use case
testing is used most of all for finding missing links and incomplete tasks.
10) Unit testing – it is a first test after development or in the process of developing
and has as a goal to check is every different part of program function in correct
way. It doesn’t provide a testing of process or data but the new code by checking

44
that it can execute in different scenarios. Debugging is one way of providing a test
of new functionalities. It can ensure a developer that his code will not brake for
different inputs. Some of examples of errors that can occur are different object
that are not initialized or format of data that are not expected. In this way different
parts of code can be tested to prevent execution errors.
2.7.2 UAT
UAT stands for user acceptance test, and it is critical part of every ERP project. The UAT
is the ultimate test performed after unit, integration, and end-to-end test. It is conducted
by end-user or client so the system can be tested by the person that will eventually use it.
For every ERP implementation this is the last check before decision to go live. Before the
start of UAT test it is necessary that all developments are finish and tested and there are
no any major issues with the core processes. The data should be migrated into the UAT
environment, and all the configuration should be set up. Also, security roles have to be in
place and integrations with other software tested. Only when all mentioned conditions are
met, the UAT can start.
For some of the users this can be a first time to have an access to ERP environment and
to do all the testing before going live with the software. UAT should be led by
implementation partner team lead for particular business area and business owner
together with subject matter experts that should also attend this meeting. Subject matter
experts need to understand what potential challenges in the specific process may be. UAT
session start with consultant explaining end-to-end process in ERP environment and
showing which steps need to be executed in order to complete the process. Then test
cases are introduced to participants that will have to run through them. Every user has to
execute the test from start to finish without any error in order to verify the correct working
of the system. Almost every test will finish with some errors, but the important thing is
that those error aren’t blocking and that they can be fixed before going into production.
At the end of the UAT section there will be different error and bugs and it is important to
create the list of the issues that have to be addressed before going live. These problems
are not only related to incorrect functioning of the system but some of them could be data
migration, security, or configuration issues. After correcting all of issues or at last the

45
ones that have priority and allow system to work correctly, business owner should sign-
off on the process.
2.8 Deployment
Deployments used to be a system administrator task and it required specific set of skills.
ERP software were stored in house and all the manutention and hardware design was
managed by system architects or administrator. All of data were stored on the company
hardware and this infrastructure was very costly. Nowadays things have changed with
introduction of cloud ERP that represent the great majority of cases. Database
infrastructure is maintained by software vendor that usually offers cloud services as well.
There are still different environments of the same software. Every software project has at
least 3 different environments:
1) Development environment
2) Test environment
3) Production
All the mentioned environment should be the exact copy of the production, with same
data and modifications. The reason behind different environments is that prior going in
production with modification, they should be tested. Development environment is usually
provided for every developer working on the ERP implementation. If the group of
programmers work on the same process it is important to update the environment with
the latest modifications. One of the advantages of the cloud software is that the number
of environments is very scalable. These environments are usually on Virtual Machines
and can be reached from every place with internet connection, and it is also possible to
turn them on and off as needed. The code modification that pasted unit test is ready to be
migrated to test environment. Here consultants and business owners test all the new
functionalities and make the configurations of the system in order to prepare it for
production. Data from legacy system are imported in this environment so they can be
tested together with new functionalities. This is also the place for integration with other
systems and for security setups. At the end the most important environment is production.
It is the software version that will be use after going live. All modification and standard
functionalities must work without any bugs in production environments. In theory the
only environment needed for ERP to work is the production, all the modification can be

46
done directly in production. But it is only theory because this type of approach can cause
major error and stop of the production that can cost greatly the company. While in some
older versions of Microsoft Dynamics AX it was easily possible to access production
code and make some modifications and in emergency times the problems in production
were resolved in that way. But the problem was that, as in any open source, if there is a
possibility of doing changes in production, somebody will eventually do them, which can
lead to serious problems in production. That is why Microsoft Dynamics 365 doesn’t have
an option for changing code directly in production environment, but the modification has
to pass different steps in order to be released. Then, for releasing the code modification
production has to be stopped, and while with new cloud versions it is possible to set up
the time for automatic release, in the old on-premise software the stop of production needs
to be done manually after working hours.
2.9 Support
In the life of ERP software, the last and longest phase is a support phase. Already before
selecting ERP solution, one of the things to consider is support strategy. Who will be
responsible for the support, for how much time and what will be the cost are some
question the company should ask when selecting ERP and implementation partner. With
biggest ERP solution there are strategies available for maintaining the software, but with
the smaller ERP vendor it may not be the case. One of the reasons that most companies
prefer well known ERP software is that with guaranteed support they lower the risk of
remaining without any support.
Support has to start as soon as first legal entity of the organization go live. What this
mean is that in big multinational companies ERP implementation is done in different
rollouts. It is common that entire organization doesn’t start to use a software same day,
but whole integration circle is divided by counties or different core processes that can go
in production separately. From the first day of going live, and especially in the first period
of software usage, the support will be critical. The internal team and implementation
partner will have to provide support and go on with other roll-outs at the same time.
The support can be categorized in different tiers. First tier can be help desk that collect
all the potential bugs and issues. Then there is internal team for support made of business
analyst with experience in software and sometimes ERP developer. Third tier of support

47
is implementation partner. After the implementation, partner gets involved only on mayor
issues, but it also can depend on different types of agreements between implementation
partner and company. And at the end, when problem cannot be resolved by partner,
software producer gets involved. These types of error are rare, and they are used as last
option.
Typically, there are to different types of support. First one is provided by company or
partner personnel and can cover most of the things related to ERP project. Then, the other
one is software vendor support, that can have limited duration. For example, support for
Microsoft Dynamics 2012 ended last year. Not only that they don’t cover any issues or
bugs on software but there are no new updates anymore for that specific version. In the
cloud ERP this approach has changed. User pays licenses on monthly or yearly bases as
well as usage of cloud space and vendor provides unlimited support with new version
released couple of time a year, so the user will always have the latest version of software
available.

48
Chapter 3: Introduction to Microsoft Dynamics 365
This chapter will be introduction to Microsoft Dynamics 365 and overview of modules
and functionalities available in this software. This solution is made with an aim to convert
CRM and ERP in one software, together with other functionalities present in Microsoft
family. Microsoft made this step of integration CRM and ERP and really become the
unique complete solution in the market. Depending on industry and needs of a client there
are different solution dedicated to cover specific area. Dynamics 365 also includes HR or
Microsoft Talent, Retail, Marketing, Field Service, Sales and Project Service Automation
with a scope of creatin platform that cut the cost of different interfaces providing unique
suit for all Microsoft products. Silos of data provides easy access to all company’s data
through single business platform for powerful tools like Business Intelligence (BI).
Microsoft Dynamics 365 suite provides a platform that is easily scalable and have a
potential to grow together with the business. With continuous updates available across
the suit, it become the last platform business needs to implement. In the core of entire
suite lays Microsoft Dynamics 365 for Finance & Operations that cover core processes
like procurement, inventory, finance , supply chain and production. Like it’s mentioned
before, Microsoft Dynamics 365 contains different application that are licensed
separately, and they can be divided in four big groups:
1) ERP – Supply Chain Management, Finance and Business Central
2) CRM – Sales, Marketing, Field Service, Project Service Automation, Customer
Service
3) Commerce
4) Human Resources
The key benefit of having suite solution is that they are on the same data model or
Common Data Model now renamed in Dataverse. For example, any master record can be
present across the application that are in the suite and change of any master data record
is visible across entire platform. Microsoft Dynamics 365 platform is embedded with
Office 365 and Power BI that are others Microsoft applications. What is mean is that all
of those applications are available out of the box and can be integrated with minor or non
additional modifications. All of those applications are stored in Microsoft Azure Cloud.

49
3.1 Finance and Supply Chain Management
Supply Chain Management and Finance is more commonly known as Microsoft
Dynamics for Finance and Operation, and that was the official name till October 2019
when Microsoft came up with new naming convention. The new Microsoft ERP has built
on top of Microsoft Dynamics AX 2012, which is old on-premise ERP, and it also took
some proven functionalities form other Microsoft solutions like Microsoft GP. The best
and most usable functionalities found their way into a new solution, they are redeveloped
and deployed to the cloud. Although it is new a new ERP solution, most of the
functionalities are used worldwide over the years. The solution is designed for very
complex organizations with more than fifty finance and management users and it also has
a limit of minimum twenty users. Supply Chain Management and Finance is made to be
high level enterprise solution that can compete with SAP and Oracle. This solution can
support multi entity companies offering budget planning and reporting across the
organization, and not only that but is can also support companies across different
industries, covering every entity or industry with different roll-out. For the top
management is important to get overall real-time view across entire enterprise and with
Dynamics 365 they can have this possibility. As mentioned before, it is deployed in the
Microsoft Azure platform, like others Microsoft solution. While in cloud, the data for
specific ERP solution is stored in separated data base without mixing it with somebody
else’s data. While old on-premise solution had down time for every code release, with

50
Dynamics 365 stored in cloud the only down time is when updating to the new version.
Those new updates can be deployed on the company’s tenant at the time that fits
organization the best. The greatest thing about those updates is that it allows the
organization to always have the last version of the solution and it is the part of Microsoft
strategy of One Version software.
Microsoft Dynamics 365 Finance offers great financial management functionalities. One
of the core functionalities is Account payable module. This module allows manual or
electronical creation of vendor invoices. Some of the subprocesses are vendor invoice
polices and workflow in order to approve only invoices that meet certain criteria. Then,
there is Account receivable for all the incoming payments and customer invoices. Of
course, different types of payments are possible and some of them are cash, credit card,
bills of exchange and electronic payments. Some of options are Banking and Financial
Closing to name few of them. Those functionalities are built on the solution providing
automatization, workflows, internal control, and overall visibility of financial state of the
organization. Application also provides analytics and reporting across entire organization.
Figure 3.2 Microsoft Dynamics 365 Finance Source: dynamics.microsoft.com
Dynamics 365 Supply Chain Management is made of different core modules:
Procurement and Sourcing, Product Management, Inventory Management and
Warehouse management. Procurement and sourcing module is end-to-end process that
starts with identifying the need for a product, invoicing, and payments to the vendor.

51
Procurement can be the result of master planning, processing of purchase orders,
agreements or manually created. System also contains information on prices and
discounts that are represented by trade agreements with different delivery options.
Product management is covering product lifecycle from product prototyping and
modeling to manufacturing and product release. Product can be specific for one company
or can be common across multiple companies. It is represented by an item that can have
different configuration, color, or size, and then based on configuration it creates different
Bill of Materials (BOM). Also, it is possible to have different categories of items throw
Merchandising and different pricing base on discount models. Dynamics 365 Supply
Chain Management is also able to manage warehouses throw Warehouse Management
System (WMS) that has a mobility component named Warehouse Mobile Application
which is a standalone application installed on handheld scanning device.
Being on the Microsoft platform, Supply Chain Management and Finance Dynamics 365
provide more than the ERP itself. One of the features available in Azure for process
automation and workflow is Microsoft flow that is used to mash-up different applications.
3.2 Business Central
For the smaller and medium-sized organizations Microsoft came up with Business
Central that have roots in Dynamics NAV, the old Microsoft solution. It is optimized
system that can be implemented really quick, and it is easier to use than Supply Chain
Management and Finance solution. It is more flexible than other ERP solution for SMBs
present in the market. Also, being built on open source .Net it is easier to integrate with
other software. Like a solution for enterprises, it is on the same platform with other CRM
application and can be used together with them. Business Central has financial module as
well as analytics, inventory, and distributions module. Also, there are simplified modules
for project management with inventory and billing options. It is a functional solution that
is not as robust as bigger Supply Chain Management and Finance ERP.
3.3 CRM
Dynamics 365 Sales is Microsoft solution for sales and customer experience. The
COVID-19 move sales to digital data-driven channels and the sales CRM has become
more important than ever. In the world of buying and selling it is critical to meet customer

52
expectation. CRM sales helps targeting new customers and it is build to serve better
existing customer with real-time AI recommendations. Microsoft set customer experience
as an ultimate goal by providing workflow, data, and intelligence. It has strong hold in
the industries such as retail, services, and manufacturing. Dynamics 365 Sales is divided
in modules, entities, dashboards, and processes. Sales module provides a functionality for
tracking leads and opportunities. Service module is used for the support of existing
customers and marketing module is used for planning and executing campaigns engaging
customers from multiple channels. Besides AI, Dynamics 365 Sales uses data to predict
and highlight areas of focus, provide tailored solution for sellers that puts the best
customers up-front and improve customer calls and feedbacks in order to upgrade
customer experience.
Figure 3.3 Microsoft Dynamics 365 Sales Source: dynamics.microsoft.com
Dynamics 365 Marketing that is divided in Marketing Lists, Campaigns and Quick
Campaigns. One of the most important tools is Marketing emails as it often a start point
of interaction with a new customer. There are different email templates that can be modify
and used easily. Segments module is used to determine customers that should receive
email marketing. Segments are group of customers, that are grouped by different criteria
from geographic location to the ones that opened previous email. Then there is a
possibility of creating Customer journey in the specific module, where campaigns for
specific customer could be followed. Dynamics 365 Marketing is built on same Dataverse
backend as other Microsoft CRM and anything that would interact with Dataverse can

53
sync with Marketing in order to make interfaces with applications like Twitter and
LinkedIn. As mentioned before all off customer details can be coming from ERP part of
solution or can be created only for Marketing purpose.
Dynamics 365 Field Service is a CRM solution for helping organizations to deliver on-
site service to the customers. It uses scheduling algorithms, work orders, workflow, and
mobility in order to achieve a support for mobile workers. For example, work order
created in Dynamics ERP is automatically transfer in Filed Service where free worker is
scheduled for on-site interventions. Upon completing his assignment, worker can access
and change a status in work order which will be automatically updated in Dynamics 365.
Field Service Mobile is the mobile application connected with CRM that gives the
workers great mobility in executing their tasks.
Project Service Automation Dynamics 365 (PSA) is an end-to-end CRM project service
solution running on Microsoft platform covering processes from quoting to billing. PSA
is designed to increase productivity and ensure that projects are delivered on time and
within budget. It is used for project planning, resource management, team collaboration,
time and expenses and at the end customer billings and project analytics.
3.4 Commerce
Microsoft Dynamics 365 Commerce is an omni-channel solution that provides business
to engage with customers in different ways in-store, e-commerce, or a call center. All
information end up in unified back office where business can centrally manage all of their
operations that are coming from interactions with clients. Business can use Microsoft
Dynamics 365 Commerce to manage all sales operations, web site operations and
physical stores. It is deeply integrated in Microsoft Dynamics platform but can also work
as a standalone system with integration with third party software. Commerce in
considered headless system because it can be use with different application providing
commerce logics such as buying in store or on-line out of the box. Headless commerce
provides not only an omni-channel solution, but it also comes with a great flexibility. It
can be deployed on cloud or on-premise. Commerce also has digital commerce
capabilities that provide engaging experience that is natively supported with content
management system, digital asset management system and AI-driven technology like
product recommendation, rating, and reviews and more. There is also a store solution

54
available that can use all the data present in the e-commerce. Back office can also use
data gathered in e-commerce and fiscal store for managing order orchestration and
fulfillment. Commerce application is fully out of the box integrated with other Dynamics
solution such as Supply Chain Management, Finance, Power Platform and Customer
Insights. One of the newest functionalities available in Microsoft Commerce is integration
with Connected store, Microsoft IoT platform. In this way it is possible to use cameras
and sensors installed in the store to leverage that to modern AI technologies to drive
actions that users in store can take.
3.5 Human Resources
Microsoft Dynamics 365 Human Resource is solution that covers entire employee’s
lifecycle in company or so called end-to-end hire-to-retire process. It is divided in three
different parts with functionalities tailored for employee, manager, and HR professionals.
Some of the functionalities available out of the box are Organization hierarchy, Employee
profile that can store documents, Overview of open jobs and positions, Personnel
management, Task management that can flow the enrolment of an employee. Then, it also
covers employee experience with possible integration with Microsoft Teams,
Performance review, Goals and skills, Training and certification and Employee and
Manger self-service. There are also modules for Compensation and Benefits and Leave
and Absence. Like in other solutions available in Microsoft suite the biggest strength of
Human Resources is extensibility. It uses Power Apps to connect different solution in
Dynamics suite and Power Automate in order to have the data flowing seamlessly from
one application to another. It has out of the box connections to LinkedIn, Power BI,
Payroll integration, and Dynamics 365 Finance for expense management.
3.6 Usability of Microsoft Dynamics suite
Microsoft Dynamics 365 lays on secure cloud-based platform that allows user to access
platform from any place. The usual way off accessing the platform is via browser like for
any web site. This also applies the necessity of good internet connection that become
standard in last 10 years. The solution works on every major browser like Edge, Safari or
Chrome. Beyond accessing the solution throw web there are mobile application for every
product both on Android and IOS. Mobile apps contain most key functionalities, for

55
example approving transaction and creating new one. Microsoft aim is to give great
mobility possibilities to their users.
3.7 Dataverse
Dataverse formerly know as Common Data Service is a part of Microsoft Power Platform
that allows interconnection of applications from Microsoft Dynamics suite. It is low-code,
cloud-based data service. Dataverse can’t be deployed locally but it needs internet
connection. CRM applications like Sales and Field Service run on Dataverse and also use
similar design. Microsoft Dynamics Finance and Supply Chain Management can be
connected to Dataverse with Dual write that provides instant update of desired
information and can be bidirectional. On ERP Dual write is only active when turned on,
and some codeless setups are needed to achieve connection between two systems. It is
very new concept, and although at beginning it wasn’t easy to use because there weren’t
too many guides today is commonly used in large number of ERP implementations.
3.8 Azure
Ones purchased Microsoft Dynamics 365 cloud version is stored within the Azure
subscription and can use all of the Azure computing abilities. Like we said before, it can
use Power Platform for integration with Power Apps, Power BI, Power Automate and
Power Virtual Agents. Also, with Dataverse it can interact with other application from
Microsoft suite or third party software with different data connectors.
Azure provides storage of data, applications, and virtual machines. It provides
Infrastructure as a Service (for deploying cloud based solutions), Platform and Service as
a Service (PaaS and SaaS) for using software available on the internet and storage and
databases. Azure is one of the larges cloud computing platforms that offers more than 600
services and millions application, customers, and integrations. It is present in more then
67 regions with more than 160 data centers. Azure region has different availability zones
with multiple independent data centers. This means that if any availability zone has
problem with power or any other problems, other availability zones inside of Azure region
will keep running. Basic pillars of Azure are compute, network, and storage. Azure also
offers great hybrid solutions.

56
Figure 3.3 Azure regions Source: mspoweruser.com
3.9 Security
When talking about security of Microsoft Dynamics ERP there are two different types of
security to be covered. One is within ERP and the other one is cloud security. Some of
the customers have major problem accepting cloud solution due to concerns about cloud
security. Azure meets different security standards like ISO/IEC 27018 for protection of
personal data in cloud, ISO/IEC 27701 for privacy standards and has more than 90
compliances for 50 regions. Azure’s basic tier have implemented continuous monitoring
and have real-time DDoS (Distribute Denial of Service) attack detection. Security Identity
management is achieved through Azure Active Directory that allows users to authenticate
when they get access to Azure application. Security center is responsible for continuous
scanning of Azure services in order to find potential threats to the applications or data
stored. With different layer of security Microsoft Azure is considered one of the most
secured services for cloud computing. As such, it is used by major organization including
United States Government. Be that as it may, potential threat of data leaking is always
present, but it is reduced to minimum. Security is continuously updated with new
protocols and Microsoft invests large amounts of resources to address potential security
problems. Having the ERP on-premises also brings security concerns due to incapability
of following potential technological threats.
Other type of security is the one inside of ERP. Not everyone can have access to some
sensible data stored in the ERP. That’s why Microsoft has adopted different securities
that are connected with form (data) and functionalities. Based on the user role in

57
organization he can read, update, or delete the data from data base. Often times user
doesn’t have even the access in order to read company data that doesn’t concern him.
Securities are then regrouped in duties and duties in roles that are assigned to different
users. Every organization can reorganize roles based on the company politics or can use
the roles that existing out of the box.

58
Chapter 4: Microsoft Dynamics 365 Survey
The survey “Microsoft Dynamics 365 - overall analysis” had the aim to collect the data
related to the experience of the customers who have implemented it. The survey is
composed out of 18 questions. Most of the questions were close-ended questions and
scale/rank answer questions. Close-ended questions are those that have one-word answer,
such as “yes” and “no”. Scale answer questions are used to determine the preference of
the respondent or the rate on which they agree/disagree with statement. Moreover, the
survey also contains the open answer questions, where interviewees were asked to
indicate the industry or provide any further considerations. The advantages of the survey
are that data is standardized and comparable. The targeted respondents were in charge of
ERP implementation on the customer side, CIOs that have followed the whole
implementation process or rather leaders in charge of specific stream of implementation
(such as for e.g., Finance, Supply Chain, Production). Major part of respondents is from
manufacturing, retail, or distribution industry. Findings from survey will be listed and
explained below. It included perspectives related to the customer satisfaction with
Microsoft Dynamics 365, its costs, shape-ability, complexity automatization, support, and
future perspectives of the implementation.
Survey
Bellow, there is a list of questions (and possible answers) that were inquired through the
survey:
1. What is your overall experience with the ERP system? (Not at all satisfied, partly
satisfied, satisfied, more than satisfied, very satisfied)
2. How likely is that you would recommend this software to another business
partner? (Very likely, likely, neither likely nor unlikely, unlikely, very unlikely)
3. Rate the difficulty to engage the system integrator with a solid expertise within
your industry. (Very difficult, difficult, moderate, easy, very easy)
4. Would you consider that ROI (Return on Investment) of the implementation has
a generally acceptable value? (Yes, no)
5. Does, /Did your IT infrastructure support new software? (Yes, no)

59
6. What percentage of your business requirements is covered with standard version
of the ERP? (0% - 50%, 50% - 65%, 65% - 80%, 80% - 90%, 90% - 100%)
7. Is the ERP easily shapable system respect to your business processes? (Yes, no)
8. What is the level of complexity of the integration with other business
tools/applications? (Very simple, considerably simple, ordinary, considerably
complex, very complex)
9. Define the complexity of data migration from your legacy system to the new ERP
solution. (Very simple, considerably simple, ordinary, considerably complex,
very complex)
10. The ERP solution is/will automize high percentage of business processes? (Very
likely, likely, neither likely nor unlikely, unlikely, very unlikely)
11. Did the user workload decrease with the utilization of new ERP? (Yes, no)
12. Are the software upgrades and the releases of new versions in line with your
business growth? (Yes, no)
13. Is the support of software provider (Microsoft) available for your implementation?
(Yes, no)
14. How do you rate support planned (and delivered) by partner? (Exceptional, very
well, well, bad, very bad)
15. Indicate the complexity level of the roll-out phase(s). (Very simple, considerably
simple, ordinary, considerably complex, very complex)
16. How long are you going to use the software in the future? (1-5 years, 5-10 years,
10+ years)
17. Specify below the industry in which you operate.
18. In case you have any other specific considerations/comments about your
experience with ERP implementation please do list them.
Overall experience and recommendation of Microsoft Dynamics to other business
partners
The overall experience of the software implementation that consists of planning,
discovering, design, development, testing, deployment, and support is positive indeed.
More than half of the respondents said they are more than then satisfied and 18% of

60
respondents declared to be very satisfied. Given the optimistic overall experience, it is
not surprising that most respondents would recommend the software to its business
partner. However, there was a small group of respondents who indicated that are very
unlikely to make a positive suggestion to peers.
Graph 4.1 Overall implementation experience Source by: author
Graph 4.2 Willingness to recommend the software Source by: author
Partly satisfied
18%
Satisfied
9%
More than
satisfied
55%
Very satisfied
18%
Overall experience
Not at all satisfied
Partly satisfied
Satisfied
More than satisfied
Very satisfied
0%
5%
10%
15%
20%
25%
30%
35%
40%
VERY UNLIKELY UNLIKELY NEITHER
LIKELY NOR
UNLIKELY
LIKELY VERY LIKELY
Willingness to recommend the
software

61
Difficulty to engage the partner integrator
Microsoft Dynamics 365 reaches a wide variety of sectors across the world. Most success
stories come from the following industries: automotive, education, financial services,
government, health, manufacturing, media and telecommunications and retail and
consumer goods. Although it is omnipresent on the market, the audience mainly finds it
difficult to find a partner who has solid expertise within their industry. Usually, it takes
years to create a solid knowledge base about specific ERP solution.
Graph 4.3 Difficulty to engage the system integrator Source by: author
ROI (Return on Investment) of the implementation
Return on investment (ROI) of the software is a performance measure used to evaluate
the efficiency or profitability of the implementation investment. ROI tries to directly
measure the amount of return on an investment, relative to the investment’s cost.
Generally, software implementation is considered as a long-term investment.
Interviewees are mostly satisfied, 82% of them, with the ROI related to the projects they
were involved to.
Difficult
73%
Moderate
27%
Difficulty to engage the system
integrator
Very difficult
Difficult
Moderate
Easy
Very easy

62
Graph 4.4 ROI generally acceptable Source by: author
IT infrastructure
Hundred percent of the respondents indicated that IT infrastructure support ERP
implementation. They provided this feedback because the whole infrastructure behind
ERP is managed by cloud computing provider. Putting ERP on cloud has cut the costs of
maintaining on premiss data storage. The only thing needed for cloud to work is a good
internet connection.
Business requirements (FIT and GAP)
Almost two-thirds of the audience indicated that standard version of ERP solution covers
between 65% and 80% of their business requirements. None of respondents declared that
it covers less than 50% or more than 90%. Moreover, 91% of audience indicated that ERP
is easily shapable system respect to their business processes. That means that the number
of developments is limited. Even though, changes are usually possible to execute, given
the technical flexibility of the ERP solution.
Yes
82%
No
18%
ROI generally acceptable
Yes
No

63
Graph 4.5 % of business requirement covered with standard version Source by: author
Integration with other business tools/applications
Organizations implementing Microsoft Dynamics 365, usually put this software as a
centre of their technology portfolio. Still, there is a need to enhance this ERP solution
with other business tools or other software solutions. Those third-party applications can
be used to support various departments from marketing to production. Consequently, it
could be necessary to integrate the system with e-commerce, CRM (Customer
relationship management) solutions, marketing automation tools, MES (Manufacturing
Execution System), etc. The integration of ERP solution with other required business
tools could provide significant added value to the organization, in terms of well-
functioning processes and therefore, in terms of economic expansion. The audience has
been asked for their opinion on level of complexity of the integration with other business
tools/applications. Only a fifth of respondents indicated that considers it considerably
simple. Major part indicated that the incorporation between Microsoft Dynamics 365 and
other instruments has an ordinary entanglement. There are two different types of the
integrations – those related to the applications from Microsoft Suite and those related to
third party business tool. Microsoft is continuously working to ease the integration with
third parties through the Azure. Currently it still represents an ongoing development.
0%
10%
20%
30%
40%
50%
60%
0% - 50% 50% - 65% 65% - 80% 80% - 90% 90%-100%
% of business requirements covered
with standard version

64
Graph 4.6 Complexity of the integration Source by: author
Migration from legacy system to the new ERP solution
When implementing a new ERP solution, one of the key tasks to tackle with is data
migration. Data migration is process of transferring data form the storage of legacy
system to the new software data lake. This process allows to key users to get crucial
business insights and make the decision that would have an impact. To allow that, users
must plan and map all the data migrations, decide the right methodology to be used,
extract and clean the data, load them and finally, verify the accuracy of imported data.
The complexity could vary based on the amount of data, different structure of legacy
system, industry, and company’s core business. When put together those elements have
resulted in different considerations of migration complexity. So, as it can be deducted
from the graph 7, some of the players declared to consider it very complex and
considerably complex. However, major part of the audience considers it considerably
simply or ordinary.
Considerably
complex
10%
Ordinary
70%
Considerably
simple
20%
Complexity of the integration
Very complex
Considerably complex
Ordinary
Considerably simple
Very simple

65
Graph 4.7 Complexity of data migration Source by: author
Automatization of business processes and workload decrease
Like mentioned in Implementation chapter the implementation process is the right
moment to introduce change management and therefore automatization of certain
processes. Microsoft Dynamics 365 solutions are used to improve and simplify time-
consuming tasks. This has been confirmed by interviewees. Almost 90% of them
indicated that high percentage of business processes has been automatized.
Graph 4.8 Probability of business process automatization Source by: author
0,0%
5,0%
10,0%
15,0%
20,0%
25,0%
30,0%
35,0%
40,0%
45,0%
50,0%
VERY COMPLEX CONSIDERABLY
COMPLEX
ORDINARY CONSIDERABLY
SIMPLE
VERY SIMPLE
Complexity of data migration
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
VERY UNLIKELY UNLIKELY NEITHER
LIKELY NOR
UNLIKELY
LIKELY VERY LIKELY
Probability of business processes
automatization

66
At the start of the implementation workload is indeed higher than expected for the simple
reason that users must familiarize with the new solution and adopt it. But over the time,
when they gain experience, they became able to take advantage form the ERP and in that
moment the workload start to decrease. Probably, because of this experience cycle, 64%
of audience noticed the increase and 36% of them the decrease of the work volume.
Updates and new versions
Could Microsoft Dynamics 365 is based on the new versions rather than on the new
solutions. So, ERP updates boost the new features. Two-thirds of respondents answered
that the software upgrades and the releases of new versions are in line with their business
growth.
Support (delivered from both – partner and Microsoft)
Support from Microsoft as well as the support from partner are activities that are decisive.
The one from Microsoft should resolve the bugs in the system and provide a know-how
on specific business processes solutions. Support from partner is usually organized and
delivered through the ticketing system where majority of users can request assistance.
Go-live is one of the phases where the support has the main role. Hence, it must be well
planned and delivered. All the players indicated that the support is not bad or very bad.
They consider it well, very well, and exceptional as indicated in the graph bellow.
Graph 4.9 Quality of the support delivered by partner Source by: author
0%
10%
20%
30%
40%
50%
60%
70%
VERY BAD BAD WELL VERY WELL EXCEPTIONAL
Quality of the support delivered by
partner

67
Roll-out
Usually, Microsoft Dynamics 365 implementation considers more than one legal entity.
This is one of the reasons for the pluriannual durations of the ERP implementation
projects. Once the ERP solution is established in one legal entity it is easier to implement
it in other companies. 64% of the audience thinks that ordinary effort is needed to
accomplish the roll out and 36% indicates that the roll-out is considerably complex.
Graph 4.10 Complexity level of the roll-out phase(s) Source by: author
Software time cycle
Majority of respondents indicated to plan to utilizes the new ERP solution for more than
10 years due to the investment and nature of ERP that instead of new versions of software
provides continuous updates. The future duration of the software utilization is also
dependent on the years of initial implementation and on numbers of roll-out that should
be completed. More than one-third indicated that plan to utilizes it for next 5 to 10 years.
Less than one-fifth declared to have intention to operate on the new ERP for the next 1 to
5 years.
Considerably
complex
36%
Ordinary
64%
Complexity level of the roll-out
phase(s)
Very complex
Considerably complex
Ordinary
Considerably simple
Very simple

68
Graph 4.11 Years of software utilization Source by: author
Other impressions of respondents
Below are listed some points of the additional feedback gathered from respondents of the
survey through the open-answer question:
- “Very interesting ERP solution, fully cloud with access to new functionality like
AI.”
- “The issue today is the availability of resources with experience and know-how.”
- “Very high turn-over during project increase the risk of delay and re-work.”
- “Microsoft provides more new tools than partners are able to propose and
implement.”
- “Change of company’s ERP should go alongside with change management.”
- “It is important to mention that the implementation of Microsoft Dynamics 365
should consider significant collaboration and availability of business process
owners.”
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
50%
1-5 YEARS 5-10 YEARS 10+ YEARS
Years of software utilization

69
Conclusions
ERP software is the center of company and as a such it connects different parts of
organization and makes decision-making more efficient. It increases the productivity and
grow together with organization. The main objective of this thesis was to explain how
process of implementation works and to introduce Microsoft Dynamics 365 suite. This
thesis has shown the difficulties of implementation process and what are the things to
consider in order to execute a successful implementation. First, before starting an ERP
implementation it is crucial to understand all the benefits that this software can bring to
the company. It this thesis it is shown that ERP solution reduce cost with adoption
standardized processes throw change management and also brings total visibility and data
reliability. The process of implantation continues with selection process. It is made clear
that most important things when selecting ERP solutions are degree of fit, implementation
partner, platform, and cost. Cloud or on-premise is one of the biggest questions of ERP
implementation and in this thesis it is shown that the future lies in cloud ERP and in order
to unlock all of advantages that digital transformation has to offer it is the right way. Be
that as it may, some concerns about cloud security are mentioned. Then approach to
design together with user is articulated with all benefits that it has to offer. My findings
are that with hybrid approach using both Waterfall and Agile methodologies is to key to
positive result when it comes to design, development, testing, deployment, and support.
Another key finding is that decision making is critical for executing good implementation.
Technical characteristics of software are very important, but the overall result depends on
the people involved in implementation project, that’s why it is crucial to have a structured
project team with roles particularly defined. It is shown that all these factors are very
important and only the combination of all factors is the way to implementation of the ERP
software that will be in the centare of an enterprise in years to come.
In the third chapter Microsoft Dynamics is presented putting the light on the positive and
negative side of this ERP solution. It is shown why it is considered one of the most
powerful ERP systems in the today’s market. Wide spectrum of businesses that this ERP
has to offer is made Microsoft Dynamics one of the most implemented ERP solutions. In
this thesis it is explained that Microsoft Dynamics is more than ERP because it comes
with components such as HR, Commerce and CRM. The entire suite lays on Azure

70
computing cloud. In this way clients get access to powerful tools like Artificial
Intelligence , IoT and Azure computing and data storage. In forth chapter the survey is
made for people that work with Microsoft Dynamics and all statements made before are
put to the test. Most of respondents confirmed that they have good overall experience
with Microsoft Dynamics. By their opinion the solution has high percentage of fit with
business and therefore it comes with less development. They also agree that the IT
structure provided by Azure and the constant updates of the platform are in line with there
expectations. They rated Microsoft Dynamics as a solution with good ROI and the starting
point of business automatization and change management. Also, the support from
Microsoft and implementation partner are confirmed to be satisfying. The questionary
also reviled some aspects that can be improved like integration with third party software.
Another downside of Microsoft Dynamics 365 implementation is the lack of experienced
partners that can lead the implementation process, and this can be improved by Microsoft
with organization of workshop and seminars on new technologies in the world of ERP.
The future of ERP lies in unlocking the full potential of cloud computing. Having almost
unlimited resources and all desirable information in one software is the goal set by major
ERP producers. In order to achieve that they have to work on the cloud security. One of
the potential solutions to that problem could be blockchain technology that can make the
cloud security unbreachable. Another thing that is future task for ERP software
developers is making codeless software solutions and making it available to everyone.
The secure cloud computing ERP software with a codeless platform could give great
opportunities to business to improve their productivity and efficiency and could lead the
way to the Industry 5.0.

71
References
Harwood S., ERP Implementation cycle, Butterworth-Heinemann, 2003
Panorama Consulting Group, 2021 ERP report, , 2021
Hilman M., Comparative Study Of Erp Implementation Methodology Case Study:
Accelerated Sap Vs Dantes & Hasibuan Methodology, Faculty of Computer Science,
Universitas Indonesia, 2012
Samani R. , Navigating a Cloudy Sky, McAfee, 2018
Newel E. , Mastering Microsoft Dynamics 365 Implementations, Sybex, 2021
Aggarwal S., McCabe L., The Compelling TCO Case for Cloud Computing in SMB and
Mid-Market Enterprises, Hurwitz & Associates, 2009
Kimberling E., The Definitive Guide to a Successful Microsoft Dynamics 365 Digital
Transformation, Third stage, 2019
Wallace T., Kremzar M. , ERP: Making it Happen, Jonh Wiley & Sons, 2001
Lau L., Managing Business with SAP, Idea Group Publishing, 2005
Pelphrey M., Directing the ERP Implementation, Taylor & Francis, 2015
Faith T.,Tori D., Magic Quadrant for Cloud ERP for Product-Centric Enterprises, 2021
Leggett K., Hong D., Sales Force Automatic Solutions, Forrester, 2021
MacMillen A., ERP Technology value matrix 2020, 2020, Nucleus research
Sarosa A., Carey I., The total economic impact of Microsoft Dynamics 365 Supply
chain management, 2021, Nucleus research
Della Rosa F., Ellis S., Anew breed of cloud applications powers supply chain agility
and resiliency, 2021, IDC

72
Sitography
https://support.microsoft.com/en-us/office/what-s-new-in-microsoft-365-95c8d81d-08ba-
42c1-914f-bca4603e1426
https://www.sap.com/italy/about/company/history.html
https://dyntips.com/history-of-ax/
https://www.netsuite.com/portal/resource/articles/erp/erp-history.shtml
https://www.netsuite.com/portal/resource/articles/erp/erp-implementation-phases.shtml
https://www.qad.com/what-is-erp
https://accelerationeconomy.com/cloud-wars-top-10/
https://www.nigelfrank.com/blog/a-brief-history-of-microsoft-dynamics/
https://www.panorama-consulting.com/erp-software-selection-guide/
https://www2.novacura.com/blog/agile-vs.-waterfall-for-erp-implementation
https://softwareconnect.com/erp/top-vendors/
https://www.sterling-team.com/news/en/steps-in-erp-system-implementation-part-1/
https://blogs.sap.com/2013/11/15/basic-understanding-on-asap-methodology-for-
beginners/
https://blog.advancedresources.com/how-to-build-a-successful-erp-implementation-
team
https://dynamics.folio3.com/blog/erp-cost-software-pricing/
https://www.erpfocus.com/erp-implementation-costs.html
https://terillium.com/benefits-of-erp/
https://softwarepath.com/guides/erp-report
https://www.inecta.com/blog/should-you-choose-a-var-based-on-geographic-location-
or-vertical-experience
https://www.softwareadvice.com/resources/cloud-erp-vs-on-premise/
https://www.triskelelabs.com/blog/cloud-cyber-attacks-the-latest-cloud-computing-
security-issues
https://www.capgemini.com/ch-en/2019/01/how-much-should-you-expect-to-spend-on-
a-new-erp-
system/#:~:text=Software%20sales%20folks%20will%20sometimes,be%20between%2
0%24100%2C000%20to%20%24250%2C000.

73
https://www.zdnet.com/article/crm-watchlist-2020-and-the-winners-are/
https://home.kpmg/ch/en/blogs/home/posts/2021/08/erp-implementation.html
https://www.sam-solutions.com/blog/erp/
https://www.erpsoftwareblog.com/2014/01/erp-deployment-options-defined/
https://solutionsreview.com/enterprise-resource-planning/5-types-erp-software-
deployment-models-consider-buy/
https://insights.sap.com/cloud-erp-deployment-options/
https://gisuser.com/2020/10/a-beginners-guide-to-the-three-main-types-of-erp-system-
deployment/
https://stackify.com/ultimate-guide-performance-testing-and-software-testing/
https://www.microfocus.com/en-us/what-is/performance-testing/
https://cobaltintelligence.com/blog/integration-tests-are-good/
https://docs.microsoft.com/en-us/dynamics365-release-plan/2021wave2/finance-
operations/dynamics365-supply-chain-management/
https://www.constellationr.com/research/constellation-shortlist-b2b-marketing-
automation-enterprise-0
https://dynamicconsultantsgroup.com/blogs/out-with-the-old-in-with-the-new-
microsoft-
dataverse/#:~:text=Common%20Data%20Service%20(CDS)%20%E2%80%94,but%20
with%20a%20different%20name.&text=Expect%20further%20name%20changes%20fr
om%20Microsoft%20in%202021.
https://azure.microsoft.com/en-us/services/monitor/

Erp implementation process and introduction to dynamics 365

More Related Content

What's hot (20)

Similar to Erp implementation process and introduction to dynamics 365 (20)

Recently uploaded (20)

Erp implementation process and introduction to dynamics 365