Process-centric Microsoft Dynamics 365 Business Central Implementation by Finclair

Organizations need to carefully consider multiple key factors, in order to successfully initiate digital transformation initiatives. Unfortunately, Gartner reports that between 50% – 75% of digital transformation initiatives are unsuccessful. Enterprise Resource Planning (ERP) system implementations, for example, often fail to deliver the desired benefits due to tight scheduling, insufficiently specified requirements, lack of communication between consultants and organization representatives, or resistance from users. In order to complete an implementation successfully, both customer and implementation partner need to be able to identify and understand the problems at hand even before a project implementation starts.

At Finclair, we know from our past experiences that a Microsoft Dynamics 365 implementation often means a big change in how a company works and that it opens up new ways of doing business. This requires a thorough analysis of the organization’s current state of the business before taking any actions in terms of process redesign, reengineering, implementation or change – and we know it pays off at the end.

We are following a process-centric implementation approach that leverages the benefits of Business Process Management.

Every company has its own language that describes daily routines of the business. Together with our clients, we translate this language and its industry specific terminology into business processes. During the Dynamics 365 implementation projects, this process language facilitates the communication that the business understands; a common language that acts as the bridge between customer and partner. It also enables business users to think about their needs, the tools and technologies that they use for work. We support our clients to create their own organization’s language that contains day-to-day transactions and activities – which we refer to as taxonomy.

The Taxonomy

Simply put, a process taxonomy categorizes an organization’s processes in hierarchy, starting from the high-level top – the value chain, to the descriptive bottom – the Standard Operating Procedure.
An organization’s taxonomy should be designed in a way, that it strategically supports the company’s business model. In a collaborative exercise with our clients, we capture and organize processes of the organization, or the relevant part for system implementation, in a process repository. All processes are arranged hierarchical, with numbering, labels and unique references. When the implementation project starts, using the process taxonomy as foundation delivers multiple benefits which we will elaborate more closely in each phase of the implementation cycle.

Assessment & Discovery

As part of our Design phase, we challenge our clients to think about the status quo before they start the system design. The process taxonomy enables internal as well as external stakeholders to have a common understanding of the problems at hand. Once transparency on the current challenges is created, business processes are also the main drivers to start defining the solution that is being implemented in the project. Hence, they are used not only to describe the as-is stage – the status quo, but also the to-be stage – the solution. As part of the system design discussions, we highlight the importance of maximizing Microsoft Dynamics 365 out of the box offerings whilst minimizing the amount of customizing for organizational specific requirements. However, we believe that Technology is an enabler, and that the system should serve and fit the client’s operations and it’s the business stakeholders.

Exactly these stakeholders represent the major challenge during the Discovery phase. Achieving an alignment across multiple departments, organizational layers, or even countries is key to a successful D365 implementation. Therefore, we structure our design discussions based on end-to-end processes across departments, organizational layers and countries. Spending time during the Discovery phase and achieving cross-functional alignment before the implementation is crucial, as the designed to-be processes will act as basis for requirements gathering and project scope management. On top of that, these processes are also relevant for internal and external auditors – especially for financial processes – as well as certification authorities such as ISO or IATF.
Another widely neglected benefit of careful process design at this stage is system security. Process maps contain all relevant information to design system user roles and authorizations including Segregation of Duty rules as well as the opportunity to map the organization’s risks and controls. In order to capture this level of details in the business processes, we at Finclair focus on four process dimensions in our process maps: Roles, Tasks, System and Data.

BPM System Usage

Another important factor that contributes to a successful D365 implementation and rollout is a Business Process Management (BPM) platform. A BPM platform contains the entire organization’s process repository that can be accessed by all involved project stakeholders. There are multiple software vendors that offer a BPM platform, such as Signavio, Camunda and others. While the BPMN process notation acts as a language for collaboration with the customer, a BPM platform facilitates the communication between the client, our functional consultants, and the technical consultants who need to validate that the scope can be accomplished in the agreed upon timeline. This platform can also be used after system implementation for employee onboarding purposes, business performance analytics, process optimization projects, external audits or risk and control mapping.

Implement

Whether our clients decide to follow a Waterfall or Agile implementation methodology, breaking down the implementation effort into end-to-end processes and meaningful sub-processes results in scope items that are manageable and understandable units of works for both business and tech teams. It allows for better communication between the two worlds and it ensures that implementation work on task level can be related to subprocesses – therefore its easier for business users to review and review designs in business context. We also leverage our previously mentioned process taxonomy during implementation to determine the sequence of work, highlight dependencies between different business functions, departments and roles. Focussing on the business process scope during implementation also reduces efforts spent on unnecessary customizations and results in faster delivery of functionality within D365.

In comparison to working on a DevOps task or a design document without the proper anchoring in a business process, the process background provides a better context for developers that shows all implications of a build task. Our process-first approach provides high probability that the tasks and activities implemented form into a coherent and well-functioning solution. The reviews of the solution, when the new processes are first explained in business process terms, significantly improves the quality and usefulness of the business review by minimizing the technical implementation jargon and instead concentrating on the business language. Showing incremental progress of the build and development using business process language improves the confidence of the wider business in the project. This has proven to be key to the project’s success.

Implement

Test

Once we have reached the testing phase with our Finclair clients, we’re able to reap the most benefits from our process-centric approach. Aside from the narrow focus of unit testing and some non-functional tests, all other test types are rooted in some form of process definition.

During the functional test phase, the Integration test phase as well as the UAT, we slice test cases and their expected outcome based on business processes and also report test progress against the process repository. The process focus helps to ensure full testing coverage and enables earlier detection of any missing or inadequately defined functions or processes.

Launch & Train

When we have completed the D365 implementation, we create process-based system trainings prior to go-live in order to introduce the system to the business users. These trainings are also leveraged by our clients at a later point in time, when new hires need to be onboarded or existing users change roles. It allows those new to the system to absorb the business process simultaneously while understanding how that process is performed within the system and increase adoption and user acceptance within the organization.

Operate & Stabilize

The process repository created in the project is, in fact, more than an implementation framework. It also helps to support the solution once launched. The support team, may this be an internal or external AMS team, often have to reproduce reported functional issues so that they can investigate the root causes. A robust process-based definition of the flow allows support to recreate the steps defined by the agreed standard process flow. The visual depiction and description of the process allows the support team to speak a common language with the business user when discussing the issues. Should the organization decide to go with an external application managed service (AMS) partner, the processes can also serve as the basis for Service Level Agreement (SLA) definition, as they clearly describe the scope and expected outcome of each business area.

Summary

As we have described in this article, we at Finclair see processes as the foundation for the definition of the solution scope but also as a useful tool during and after the solution implementation. In summary, a processes-centric implementation approach ensure that:

connections between business units, roles, functions, task-level steps, and systems are identified in the DISCOVERY phase and all stakeholders have a common understanding of as-is and to-be state (solution)
IT & business teams speak a common language during IMPLEMENTATION phase and development tasks derived from processes cover all required functional elements
incremental testing of processes and subprocesses during the TEST phase, which in turn helps engineer quality into the solution
User acceptance of the solution is high due to user TRAINING / onboarding that is focussed on end-to-end business processes
The transition into system OPERATIONS can be smoothly handed over to internal or external operations teams with the business process repository as key deliverable

What we have not touch upon, is the impact business processes can have on optimization projects – but we’ll keep this topic for another blog article in the future.

Have we sparked your interest in this topic or did we outlined some of the issues you’re currently facing with your D365 implementation?

We offer full support during your Microsoft Dynamics 365 implementation with our proven process-centric approach.

If you want to know more, get in touch with us at Finclair through our contact form and let’s discuss your path towards a successful D365 implementation!