Becoming a Dynamics 365 Finance and Supply Chain Solution Architect E-Book

Brent Dawson

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 399

Veröffentlichungsjahr: 2023

Beschreibung

Implementing an ERP project is a daunting task, and it can often get derailed due to several reasons, including but not limited to inefficient planning, inadequate resource scoping, insufficient working knowledge of ERP systems, and more. Becoming a Dynamics 365 Finance and Supply Chain Solution Architect helps you understand the intricacies of ERP project implementation for seamless deployment.
This comprehensive guide helps you gain a deep understanding of how to implement and optimize robust business applications that meet the evolving needs of organizations. You’ll discover various integration methodologies to integrate different software applications and plan successful data migration seamlessly. By leveraging the author’s expertise, you’ll explore different challenges that can lead to project failure or cost/time overruns, along with customized solutions to maneuver past those issues for a successful outcome.
By the end of the book, you’ll be able to identify potential issues that can negatively impact the delivery of the project and make design decisions that will prevent any potential negative impact on the design and functionality of the system at go-live stage.

Leseprobe

Becoming a Dynamics 365 Finance and Supply Chain Solution Architect

Implement industry-grade finance and supply chain solutions for successful enterprise resource planning (ERP)

Brent Dawson

BIRMINGHAM—MUMBAI

Becoming a Dynamics 365 Finance and Supply Chain Solution Architect

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Alok Dhuri

Publishing Product Manager: Kushal Dave

Senior Editor: Ruvika Rao

Technical Editor: Jubit Pincy

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Arunkumar Govinda Bhat

Marketing Coordinator: Deepak Kumar and Mayank Singh

First published: June 2023

Production reference:1160623

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80461-149-4

www.packtpub.com

I’ve been wanting to write a book for a very long time but never really had the opportunity. I’d like to dedicate this book to my amazing fiancée, Violeta, for giving me the motivation and courage to go and try things I was always hesitant to try before. This is only the first of many new accomplishments to come. I am a better person because of you, and I feel more confident in myself. I’m proud of you and of myself because of all the successes we have had... all since I met you.

– Brent Dawson

Foreword

I have known Brent for over 3 years since we met in the Microsoft Business applications community via common interests.

Since then, we have interacted about Microsoft stack products at community events (user groups, conferences) and personally.

This book Overcoming Challenges in D365 Finance and SCM Projects tells you the most important things you need to know about running a D365 project, from identifying if you need the software, to the completion.

Technical information is expressed in a very understandable manner with architecture concepts, configurations and customizations with examples, security and integration considerations. However, this is not all that is covered in the book. Brent also describes how to make a project a success by describing how to manage the human element of the process, which often can be a downfall of a project despite technical brilliance.

Technical know-how and experience are evident in the book, but I knew that as I have consulted with Brent multiple times in the past.

If you are considering using D365 finance and SCM in your organization and you are a functional consultant or seasoned architect, then you will get to know what the bigger picture of the project looks like or at least most likely find something that has got a different angle to it.

Sincerely,

Laurynas Merkelis a.k.a. Larry

Low Code platform Architect

Contributors

About the author

Brent Dawson is the owner of and principal consultant at Digital Ducttape Ltd. He is certified in many different areas, including D365 F&SCM Solution Architect, TOGAF (enterprise architecture), Microsoft Certified Trainer (MCT), and Certified Information Systems Security Professional (CISSP). Brent has over 25+ years of teaching and classroom experience. His focus is mostly on Microsoft Dynamics 365 Finance and Supply Chain Management (F&SCM), Power Platform, and ethics in IT. He has an impressive 30+ years’ experience in the IT industry and has worked in many different facets of IT, including end user, system, and security architecture. Originally from Canada, he currently lives in London in the United Kingdom. He has completed and helped to create several certifications and accreditations in the IT industry, including authoring various exam questions and setting certification exams for Microsoft and ISC2. His extensive knowledge sets him apart in industries such as oil and gas, manufacturing, finance, transportation, and the public sector.

Brent is also a frequent speaker at Microsoft and community-based conferences. He has previously spoken at Microsoft Ignite, Scottish Summit, and South Coast Summit on Microsoft D365 F&SCM, and Syracuse and Northampton universities on IT ethics. He’s always willing and available to speak at conferences.

I want to thank a few people. My family (Dad, Mom, Phil, and Janice) for convincing me to stay in computer science at university, Doug for making me believe that IT wasn’t all about programming, and Leon for introducing me to the world of dynamics architecture. I also need to thank AJ, Chris, Alison, Jeff, Ewan, Kaila, Larry, Malin, and all the rest of the Bespoke Badgers. You are the most supportive and excellent group of people I’ve ever had the opportunity to know.

About the reviewer

Rahul Mohta brings 20+ years of expertise in ERP consulting, implementation, and pre-sales, focusing on Microsoft Dynamics 365 F&SCM.

He has diverse and rich experience, working with customers and partners globally, enabling them to realize the full value of their future Dynamics platform.

Rahul strives to work as a solution leader and trusted advisor, playing diverse roles and working extensively in both the functional and technical domains.

Table of Contents

Preface

Part 1: Architectural Considerations and Best Practices for D365 Finance and SCM

1

Overcoming Challenges in D365 Finance and SCM Projects

How do we get started?

Who wants this software?

How to get started?

What can we do to fix it?

How to be an SA

Conclusion

2

Understanding the Microsoft FastTrack© Process

The Success by Design methodology

Cloud-first

Data-first

Phased approach

What is Microsoft FastTrack for Dynamics 365?

Customer requirements

Partner requirements

Engagement

Implementation guides

Who does what in the project?

FastTrack engagement

The role of the SA

A FastTrack engagement case study

The initiate phase

Conclusion

3

Dealing with Integrations

What are integrations?

What components make up an integration?

Data integration patterns

Custom services

Batch APIs

OData

Dataverse

Virtual entities

Why do integrations fail?

Working in silos

Data dependency

Not understanding interface complexity

Understanding integrations

Resistance to change

We always blame the software

Case study

Integrating two ERP systems

DW for a racing team

Solidworks to D365

Power Automate

Ways to fix integration issues

Change-tracking

Budget properly

Tool selection

Planning your strategy

Creating the team

Standardization

Testing, testing, and testing

Conclusion

4

Efficient Security Design

Why is the cloud different?

What does security look like in D365 F&SCM?

D365 security architecture

Extended data security

Security reports

Segregation of duties

External reports

How to best set up security

Architecture

Conclusion

5

Planning for Successful Data Migration

What is data migration?

Types of data

Data locations

Data migration methodologies

Data management

Data management framework

Data entities

Data mapping

Data tools

Creating a migration strategy

Prepare for data migration

Data import and export strategy

Validating data output

Cutover plans

Data migration best practices

Case studies

So, what are the reports?

Conclusion

6

Licensing Challenges

Understanding the Microsoft licensing model

Where can I get the licenses from?

Dynamics license types

Base versus attached licenses

Other licenses

But I’m an administrator?

How do we know what license to get?

Plan out subscription requirements

Dynamics 365 Licensing Guide

The Users page in System Administration

Custom security

Subscription estimator

ISV, External, and other license types

Multiplexing

Assigning licenses

License reporting

Security configuration diagnostics

Real-world example

Conclusion

Part 2: From Solution Design to Deployment – Practical Advice

7

How to Plan a D365 F&SCM Project

Project management

The project layout

Project management tools

Prepare to start

Project team

Governance

Framework

Risks

Project structure

Steering the project

Project reports

Risks

Stage gates

Change boards

Responsible, accountable, consulted, and informed

Business processes

Project checklists

Conclusion

8

Learning the Client’s Business

Success by Design

Where to start?

Let’s speak the same language

LCS BOM

Identifying the business processes

Dynamics 365 F&SCM TOM

Why understand the TOM?

Business process optimization

Solution modeling

Fit-gap analysis

LCS tools

Business process modeler (BPM)

Implementation of requirements

Case study

Conclusion

9

Collecting Project Requirements

Where do we start?

Why out of the box?

Let’s talk a bit about development

Understanding the differences

What tools are available?

Okay, so what’s next?

Let’s listen to the client

Active listening

Using diagrams

Where are we?

Create the solution blueprint

Conclusion

10

ALM Tools and Applications

Azure DevOps

Version control

Release pipelines

Project management

Testing

Dynamics LCS

Environments

Task Recorder

Task Recorder for security configuration

RSAT

Visual Studio

DevOps examples

Creating a project

Best practices

Conclusion

11

Human Change Management

What is human change management?

Identifying stakeholders and their needs

Developing a change management strategy

Communicating the change

Training and development

Reinforcement and sustainability

Why do employees need to know what’s coming?

The Change Curve

Human change methodologies

Prosci ADKAR Model

Who is best to lead change?

Change tools

Case studies

Case study 1 – the bad project

Case study 2 – the good project

Conclusion

12

Building a Blueprint Solution

Knowing what goes into a solution blueprint

Understanding the blueprint

Assess the suitability of the blueprint

Customize the blueprint

Establish a strong governance structure

Develop a detailed implementation plan

Ensure adequate training and skill development

Implement monitoring and evaluation mechanisms

Foster collaboration and knowledge sharing

Plan for long-term support and maintenance

Review and iterate

Project roles

Expressing user requirements

What to include in the blueprint

Responsible, accountable, consulted, and informed

Project budget document

Living documents

Best practices

Conclusion

13

Deploying the Project Solution

Building the blueprint solution

Design pillars of solution architecture

Strategies

Go-live preparation

Case study

How should it look?

Conclusion

Index

Other Books You May Enjoy

Preface

Many ERP projects are doomed to failure, whether it’s due to bad planning, incorrect resource scoping, or just a lack of knowledge of what a system can do. Organizations that implement large ERP projects will always look for ways to deploy a system that is free from bugs and geared toward making their organization more efficient and profitable.

Focusing on Microsoft Dynamics 365 Finance and Supply Chain Management solutions architects, this book will present some of the more challenging areas that lead to project failure or cost/time overruns. It will present a discussion of the major causes that can cause a project failure, and it will offer some observations from the field that can be a guide to help maneuver past any issues toward a successful outcome.

Who this book is for

This book is for aspiring Microsoft D365 finance and supply chain solutions architects looking to take up the challenges of integrating different systems, configuring security models, complex data migrations, licensing, and overall system design based on client requirements. Furthermore, this book serves as a valuable guide for experienced solution architects seeking to expand their skill set and enhance their expertise in tackling complex challenges within the field.What this book covers

Chapter 1, Overcoming Challenges in D365 Finance and SCM Projects, starts the book with a high-level discussion about the most common roadblocks that can happen during an ERP project.

Chapter 2, Understanding the Microsoft FastTrack Process, introduces the Microsoft FastTrack process for Dynamics projects. We will look at the structure used to complete a project based on Microsoft’s best practices.

Chapter 3, Dealing with Integrations, examines the potential issues that can arise when working with integrations between Dynamics 365 F&SCM and other software applications.

Chapter 4, Efficient Security Design, discusses how to set up security configurations in an organization.

Chapter 5, Planning for Successful Data Migration, explores the major impacts and pitfalls related to data migrations and data translations when moving to D365.

Chapter 6, Licensing Challenges, delves into the types of licenses used in D365 and how to assign them based on job type, as well as security roles.

Chapter 7, How to Plan a D365 F&SCM Project, examines how to prepare for successful project deployment.

Chapter 8, Learning the Client’s Business, discusses how to best capture a client’s requirements, as a successful project is always about knowing what the client needs.

Chapter 9, Collecting Project Requirements, explores how to get a client to work with an architect to kick-start a project, including how personnel will be assigned to work on the project.

Chapter 10, ALM Tools and Applications, delves into the Microsoft recommended tools that should be used during the execution of a project.

Chapter 11, Human Change Management, discusses many issues that can happen when proper corporate change management is excluded from a project.

Chapter 12, Building a Blueprint Solution, examines what needs to be entered into the solution blueprint.

Chapter 13, Deploying the Project Solution, gathers together everything we discussed into a logical cheat sheet that you can use to get your project off on the right foot. We’ll look at the timelines you should follow so that the project starts successfully and stays on track until the final go-live.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/omA3u.

Conventions used

The following text conventions used throughout this book.

Bold: Indicates a new term, an important word, or words that you see on screen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “The Security duty assignments report gives a view of all the duties that are part of a role.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Becoming a Dynamics 365 Finance and Supply Chain Solution Architect, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere? Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781804611494

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Architectural Considerations and Best Practices for D365 Finance and SCM

In this part, you will get a view of the areas that most often cause the greatest number of issues during the execution of a D365 F&SCM ERP project. In addition, you will also learn the best practices and suggestions to resolve these issues, based on the experiences of myself and other solution architects that I have worked with over the years.

This part has the following chapters:

Chapter 1, Overcoming Challenges in D365 Finance and SCM ProjectsChapter 2, Understanding the Microsoft FastTrack ProcessChapter 3, Dealing with IntegrationsChapter 4, Efficient Security DesignChapter 5, Planning for Successful Data MigrationChapter 6, Licensing Challenges

1

Overcoming Challenges in D365 Finance and SCM Projects

Every book needs to start somewhere. As I was sitting and planning out what to put into this book, I was trying to figure out what causes me the most lack of sleep in a project – meaning, what issues come up during a project deployment that cause the most issues and the most grief between consultants and clients?

I have been involved in Microsoft Dynamics projects for over 10 years now. Every project, no matter how hard you try to plan to avoid issues and problems, ends up with at least one major issue. Many, if not most, ERP projects are doomed to failure.

Whether it’s due to bad planning, incorrect resource staffing, or just a lack of knowledge of what a system can do or what a client wants, organizations will eventually run into something that causes a project to go completely off the rails. This, of course, will have not only a negative impact on timelines and budgets but also on the project team’s morale.

If we’re going to be successful, then we need to understand what we can do to help avoid issues and make our work as good as can be.

How do we get started?

That’s an interesting question, isn’t it? How do we get started? Well, basically, someone must decide, “We need to become more modern in our organization; otherwise, we’ll be left behind.” The point and goal of an organization is to deliver a product or service to a customer and, ultimately, make money.

It’s totally possible to make money using old-fashioned systems – account books for accounting, order books to manage orders for customers, and printed flyers for customers, but it’s not really all that efficient. How much time does an employee spend handwriting out these types of documents, and how much space is then required to store those documents? If an organization is to keep, let’s say, seven years’ worth of financial data for tax purposes, how many filing cabinets, or file storage boxes in a warehouse, do we need to keep all that information? And then what happens if you need to find one document from a box that contains data from six years ago?

Alternatively, maybe an organization has several different systems they work with but don’t have the ability to share data. This can cause a number of issues, including duplication of work, extra spending on supplies and maintenance, and potentially missing payments from customers and to vendors.

At some point, someone (usually in the finance department) will visit IT and suggest that they look at a way to improve how the organization operates. Depending on the size of the organization, a committee will be created that will come up with a way to improve operations.

From there, a technology roadmap will be created, and ultimately, a budget will be allocated so that a new digital transformation can occur. But what if you have no idea how or what needs to happen to get to a desired destination?

With so many different types of software available on the market, most organizations can’t make an educated decision without assistance from someone (usually a company that specializes in ERP deployments) who has many years of experience working with technology. So, you find a few people who have experience in leading organizations with their technology roadmaps, interview them, and finally, hire someone to help guide you on the journey.

Now that you have a leader in place (with the guidance of a consulting company), and a good idea of how you want to proceed, you start to look at different software tools, technologies, and partners to help you deploy a solution. You made an important decision in this process – for instance, you really like Microsoft products and would prefer to stick with those technologies, including tools such as Azure and Power Platform, because you trust the company and believe that their technologies will be well supported far into the future.

You can now announce to the company that it is going to migrate its current systems to Microsoft Dynamics 365.

Who wants this software?

Microsoft Dynamics 365 is a cloud-based software platform that allows an organization to integrate its processes into a single, integrated platform. Microsoft Dynamics 365 (D365) provides applications to help manage customer relationships, including D365 Sales (used to manage the sales cycle), D365 Marketing (used to manage marketing campaigns), D365 Customer Service (used to manage customer information and services), and D365 Field Services (used to manage and assist technicians’ schedules and appointments).

There are also two Enterprise Resource Planning (ERP) systems. One of these applications is called Business Central (BC). This is a small- and medium-business version of an ERP system that is suited for a company with around 100 to 250 users. The application consists of three modules:

A Finance and Operations module based on a previous application called Microsoft Dynamics NAVA sales moduleA marketing module

The enterprise edition of their ERP application is called D365 Finance and Supply Chain Management. This application is made up of several modules, including Accounts Payable, Accounts Receivable, inventory management, and asset management. Other enterprise applications include Project Ops for project operations and financial management, Human Resources to manage all users from a human resources perspective, and Commerce, which is used to manage both brick and mortar and online retail stores. Microsoft is also in the process of preparing other tools that will be released in the near future to cover areas such as intelligent order management, Microsoft Supply Chair Center.

Now that an organization has selected D365 Finance and Supply Chain Management, its next step is to find an implementation partner. Microsoft has many different partners who can do the deployment, but you want to find one that will not only do the work for a customer but also become a partner in the deployment of their system. By becoming a partner, the consultants have a vested interest in deploying the best system possible.

As a part of the selection criteria when picking a partner, you need to check out their work and references. One of the things that the customer needs to find out is whether the partner is eligible for Microsoft’s architectural support process called FastTrack for Dynamics 365: https://learn.microsoft.com/en-us/dynamics365/fasttrack/

Success by Design is a methodology that prioritizes communication between Microsoft and the partner to provide a successful project. There are specific requirements that both the customer and partner must meet to be eligible to take advantage of FastTrack. We will take a detailed look at FastTrack in Chapter 2.

How to get started?

Once the customer has decided on the partner and the deployment methodology, they have been through the FastTrack design process, and has a blueprint, it’s time to get to work. But where do we start?

I believe the first thing that needs to happen is to start showing people in the organization how the system works – not from the point of view of the solution that has been agreed upon but just the system’s look and feel, and how some of the processes work by default. When you create the first dev/test environment, you have the option of installing the demo data for the Contoso Corporation. With this system, you can show the organization what the system will do.

As an example, let’s say that one of the processes that has been identified needs to be improved is the expense management process. Currently, in your organization, you do everything on paper. A user would go away somewhere that they can do the expense and couldn’t do a claim until they came back to their office.

Let’s say you need to go and attend a conference. You have your travel (flights/trains/mileage), hotel, and meals for the days you’re away. You might also have other items expensed, such as stationery and photocopying.

When you get back to the office, you first make photocopies of all the receipts from your trip, then fill out a spreadsheet that lays out all the expenses in date order, and print and sign the spreadsheet. Once that’s done, you need to put it on your manager’s desk with the receipts and wait for them to review and sign the expense report.

Now, a few different scenarios could happen:

The manager reviews the expense report right away and everything is correct, and he forwards it off to the finance or HR department for reimbursement, and you get the money back on your next payday.The manager reviews the expense report and realizes you forgot to add two receipts that are needed before the expenses can be approved. Therefore, he takes the report back to you, you fix it, and then you resubmit it.The manager is away on holiday for two weeks, so you submit the expense report, but you’re now going to have to wait an extra two weeks to have the expenses reviewed and submitted for payment.The amount of the expenses is higher than the level that your manager can approve, so they need to submit the expenses to their manager for approval. In addition, all the preceding scenarios above could still apply.

There are lots of different ways that this process can fail because of its manual nature. And this is just the submission process. We have even looked at the finance side – knowing which budgets the expenses come from, the expense policies that need to be applied, and so on.

Now that we’ve identified the business process that needs to be executed, how do we take that manual process and input it into D365 Finance?

In D365 Finance, there is a specific module for expense management. In this module, we will set up many features including the following:

Expense policiesBudget allocationsExpense processingExpense reporting

For a user, there are many different expense types that they can choose from, including a standard expense report, cash advances, and travel requisitions.

Figure 1.1 – The D365 Expense module

Once in the expense module, we need to select and create a new expense report.

Figure 1.2 – The New expense report button

To submit the expense report to the system, you will fill out a form that lets you select the expense category and the amount, separate taxes (if required), and attach scanned copies of receipts.

Figure 1.3 – The D365 New expense report form

Figure 1.4 – Expense line items

Once you have entered all the values for the expense report, you can refresh the screen to update each of the expense lines. After you refresh the screen, you will see the Submit button appear in the top menu.

Figure 1.5 – Submission of an expense report

You are able to add some notes to the expense report for the reviewer.

Figure 1.6 – The Expense report submit comment field

To help with the process of approving the expense report, we will implement an expense management workflow. The workflow involves manually passing the expense report around for approvals, signatures, and payment. An example of a workflow is here:

Figure 1.7 – D365 Expense management workflows

Figure 1.8 – A D365 Expense report workflow

We’ve now made the process of submitting expenses less work for the submitter, the approver, and the payor.

Once the expense has been submitted, we can go and look at the history of the workflow to see where it is at any given time. In this case, we will click the View history button, and can see the status of the workflow.

Note

It’s also possible to add a business event to the system that can call an external Power Automate flow, allowing for an expense approval without having to log in to F&SCM.

Figure 1.9 – The View history button

The following screen shows the status of the workflow. In this particular case, the expense report still sits in pending status.

Figure 1.10 – The expense workflow history

If we want to see who the report is currently with, we can scroll down the page and see who the work item is currently assigned to. In this case, it’s assigned to Julia Funderburk. If we have the correct permissions, such as System Administrator, we can reassign the work items to a different user.

Figure 1.11 – The workflow work item assignment

Figure 1.12 – The workflow reassignment dialog

Now that I’ve reassigned the approval to myself, we can go back to the home page of D365 and see it listed under the Work items assigned to me list.

Figure 1.13 – The Work items assigned to me list

When we open the task that needs to be completed – in this case, the expense approval – we will be taken directly to the expense report approval screen. We will click on the Workflow dropdown and select one of the options. For this example, we’ll select Approve.

Figure 1.14 – The workflow approval screen

Figure 1.15 – The expense approval comment screen

Finally, we can look at the Expense reports page, and we can now see that the status of the workflow is set to Approved.

Figure 1.16 – The approved expense report

The previous example is just one of many business processes can that be implemented and automated in D365. This was a simple example, but as we go through the book, we’ll look at more complicated examples that can see many more issues pop up.

Let’s say that, as we start to implement the preceding solution, the customer comes to us and says, “You know how we decided that we were going to use the expense module to track our expenses? We decided that we want people who work for one of our legal entities to submit their expenses in a different legal entity when they do work.” That brings in several complications.

First and foremost, how do we track any financial information for a worker who does work for a customer in our system? If they must submit their expenses to the company that they are doing work for, but their timesheets to the company that is their actual employer, how do we know that the expenses are not being submitted twice? And which company pays the expense? And who do they pay them to? And in what format?

These types of situations can occur regularly. Even though you’ve been through the process of discovery, situations such as these will show up completely out of the blue. The next and most important question is, how do we fix this issue?

What can we do to fix it?

When I was planning out the chapters of the book, I was looking at it from the point of view of how I fix things if they go sideways or, better yet, how to prevent those things from happening in the first place. I was trying to figure out the areas where most of the problems occur and things that we can do to help prevent or fix the most common issues.

There are many ways that a project can get out of control, for lack of a better term. Generally, when an organization and a partner put together what a project will consist of, there is a pretty good idea of what the project is supposed to accomplish. Generally speaking, the point of the project is to introduce the system into the business to improve its efficiency, save money, and help the company to improve its financial status.

The sales team of the partner and the customer agree on what the solution will look like in general terms, including which of the D365 F&SCM module will be deployed, some basic configurations of those modules, data management and migrations, reporting, and potentially, the inclusion of ISV modules or application integrations between F&SCM and some other application(s). Note that these applications may be legacy applications, running on hardware in the company’s data center, or newer cloud-based SaaS solutions. We will have a long discussion about integrations in a later chapter.

As most salespeople aren’t technically qualified to create the Statement of Work (SOW) on their own, they will get the help of a solutions architect (SA) to help with scoping out the solution and a project manager to assist in costing the project. Once this is completed, the solution and plan are handed over to the delivery team. As the project plan at this stage is a very high-level plan, the project manager will, with the assistance of the SA, fill in who will do what specific tasks at what point in the project.

However, one of the things we tend to find out after the SOW between the two sides has been worked out and signed is that people have their own agendas, and they want their issues dealt with in a specific way. If we go back to the previous example of the expense report, we need to come up with a solution that will fix the business process.

At this point, those on the project might start pointing fingers at each other and attribute “blame” for the incorrect solution. At this point, as the SA, it is your job to calm everyone down and come up with a way to implement the customer’s requirement, but you should also be able to explain and negotiate a potential change to the way they perform that specific business practice.

In this case, if you can show the customer how the method they wish to use causes issues in areas such as expense payments, reporting, tax collection, and several other areas, you may just be able to convince them that maybe there is a better way to execute this process. The SA needs to be politically savvy enough to be able to negotiate with the customer to do things more conventionally.

How to be an SA

As you go through the different chapters of the book, you’ll notice that we focus on the role of the SA. But what is an SA, and how do you become one? It’s not that hard a role, but it should be given to someone with many years of experience and deployment projects under their belts.

The SA is one of the leaders of the project.

Figure 1.17 – An example of a project team

They need to have a deep technical and functional knowledge of the D365 Finance and Supply Chain Management application. They also should have extensive knowledge of technologies and applications that could potentially integrate with D365. As the team leader, the SA is the point person who project members will contact for any issues that may arise during the project timeline. They also need to have a level of soft skills to be able to work and communicate with people about the project solution, as well as the tasks that need to be completed during the project.

As an SA, you are also the point person when it comes to issues that happen during the project. As we mentioned previously, as the solution blueprint is a living document, you will have the opportunity to modify it during the deployment. When changes need to be made, usually a change request is created and signed by the customer, so you have in writing that the customer agrees to the change and, depending on how the project is funded, will pay for it.

In the end, the SA is the person who is the most technically knowledgeable and is able to make design decisions across all areas of the project, including development, configuration, security, licensing, storage, data migration, and go-live tasks. It’s also helpful if the SA understands the customer’s business (if not in detail, from at least an industry level). Above all else, a really good SA is a master of collaboration within their team and across the organization.

A SA will also need to be an excellent problem solver. No one knows all the answers to every question, so they need to be comfortable with doing research or asking colleagues for assistance with any challenges they come across. They also need to be able to distinguish the difference between a problem, a design issue, and a bug.

And lastly, an excellent SA will always be an eternal optimist and level-headed. They can’t let anything get to them. They are the team leader, and if it looks like they are doing something wrong, that will filter down to the rest of the project team and have a negative impact on the team and the delivery of the application. You need to be able to have that human touch that will let you successfully interact with your team members. You must always be positive and happy, even when disaster is staring you in the face.

Conclusion

Now that you’ve read this first chapter, you’re probably thinking to yourself, “Do I really want to do this? Do I really want to read the rest of this book? Do I really want to be an SA???” I promise you, if you do continue reading, you’ll hear lots of examples of when things go right and when they go disastrously sideways. Most of these examples are from projects that I’ve been involved in, but many come from people in the community who have shared their experiences with me at conferences, in presentations, or in one-to-one conversations. By the end of the book, you’ll hopefully know how to avoid situations where a project can fail.

Hopefully, at this point, you’ll see how the role of an SA is important in making a project a success. In the next chapter, we’re going to look at the Microsoft FastTrack for Dynamics 365 project methodology. The goal we will attempt to achieve is to see how you can work within the methodology to successfully implement your D365 F&SCM projects.

2

Understanding the Microsoft FastTrack© Process

In the past, doing a Microsoft Dynamics implementation was based on a process called Sure Step. Sure Step was a methodology created by Microsoft for use when working with Dynamics AX 2012. This methodology sets out what processes need to be completed and followed, and in what order, to complete a successful deployment. There are several workflows, project templates, maps (used to create processes), and implementation tools included in the tool.

The methodology flow looks something like this:

Figure 2.1: The Sure Step methodology flow

The Success by Design methodology

Before we can dig into what FastTrack is, we need to have a good understanding of what the Success by Design methodology is. Success by Design lays out the methods and processes that should be followed, including the best practices identified by Microsoft, to have a successful deployment of a solution. The key is that it is not a project management methodology like Microsoft's previous version, called Sure Step. Also, it doesn’t necessarily follow a specific project management methodology. It will work just as well with agile as it does with waterfall.

Let’s break out the processes involved and get a good understanding of how Success by Design works in practice.

Cloud-first

Today, everywhere that you read about technology, you will see that everything is related to the “cloud.” This is known as the “cloud-first” strategy. This strategy is based upon the concept of putting all of your systems, computers, servers, and applications into a hosted environment, where the provider manages all of the infrastructures and the customer is responsible for managing their data and access to it. That might be a very simplistic way of looking at it, but at a high level, that’s really all it is.

Organizations will start to buy space in cloud systems and move their applications to those spaces. No longer will they have to spend money internally on data centers, software licenses, power, cooling, and storage. They will now start to use that same money to pay for space and applications in the cloud.

One of the platforms provided by Microsoft is Dynamics 365. This platform provides two basic functions:

First off, it provides ERP functionality with the finance, supply chain, human resources, and commerce tools needed for an organization to functionThe second set of functions includes more of the customer engagement functions, such as sales, marketing, and field services

The first observation you can make about the “cloud-first” philosophy is how an organization spends its money. Previously, a company would have a large capital expense budget that was used to purchase servers, software licenses, and desktop computers. Once these items were paid for, they were listed as a fixed asset to the organization, which means that they could depreciate the value of those purchases over a number of years, allowing them to reduce the tax requirements that they had to pay to their local governments.

Cloud deployments now mean that we no longer have these capital purchases but, instead, take all of those funds out of the CAPEX side of the business and move them to the OPEX side of the business. We now pay for services based on consumption of those resources, rather than paying for them upfront, all at once.

Now, in reality, what I just said isn’t exactly 100% correct. In theory, that’s how it works, but in reality, there are different ways to work out how the whole licensing of resources works. In a later chapter of the book, we’ll delve into a deep discussion about licensing.

Data-first

Another philosophy that has become popular is the idea of data-first. This philosophy is based on the idea that an organization should focus on the processes and technology around the data that is created and consumed. Dynamics 365 has a data-first strategy where you merge frontend and backend business functions together, such as an e-commerce website and a supply chain system that fulfills the orders that customers make.

The advantage of these types of systems is that they are configurable, allowing customers to be able to get the most out of their investments. Also, this idea lets companies make these changes without having to use the old method of pulling out a complete system and replacing the whole thing with something new. Furthermore, it allows for an organization to keep existing systems in place and then integrate that data with newer, more advanced cloud-based applications.

One concept that follows the data-first philosophy is the ability of an organization to view its data and use it, without having to worry about the technology that’s used to access it. They understand that the data itself is more important than the tools used to work with it. This is the type of organization that is the most mature in its organizational structure. Going forward, it will find it very easy to implement new and advanced technologies.

Phased approach

The Success by Design methodology is a phased approach. The phases are used to break a project into smaller projects that let you succeed in smaller increments, allowing the whole project to be successful.

Figure 2.2: The Success by Design phases

The four phases of the process are as follows:

Initiate: This phase gets the ball rolling for a projectImplement: The project team starts to implement a solutionPrepare: This phase has a completed solution that needs to be deployed to user accessOperate: This is post-deployment and involves offering support for a production environment

Initiate

The point of the initiate phase is to get the people together who will work on a project. This will be both experts from the partner and Subject Matter Experts (SMEs) of the customer. Both the project manager and solutions architect will guide and lead the process of identifying the requirements for the solution. One of the project processes that will be discussed and agreed upon during this phase, if it hasn’t been agreed to in the Statement of Work (SOW), is which project methodology will be used. There are a number of different project management types that can be used. In previous projects, many companies used a waterfall methodology.

The waterfall methodology is a very linear process. In this methodology, you spend the beginning of the project collecting the requirements. Once all of those requirements are collected and the solution is created, you go back to the project plan and update the work breakout structure, assigning the tasks needed based on the requirements. So, as long as there are no changes to the solution, this point should be the last time you make major changes to the project plan.

The more common project methodology that is followed currently is the agile method. Agile is a methodology where you break a project down into small chunks, and the overall project is completed in several stages or iterations. Each of the iterations is intended to finish a specific part of the project and then move on from there. Also, agile is intended for the project team to learn what they did well in the previous iterations and bring those forward to later ones.

Figure 2.3: An agile project management methodology

However, in reality, Dynamics 365 projects don’t really work well with either of those methodologies in their pure form. In most cases, you will have a hybrid approach that will contain some waterfall methodology – that is, the creation of the solution and gathering all of the requirements at the beginning – and agile iterations, where you break the deployment into smaller parts and complete each one before moving on to the next iteration.

Implement

The implementation phase of a project involves completing the tasks needed to build the solution that was agreed on earlier in the project. During this phase, there will be constant reviews of the work that has been completed to make sure that it falls within the scope of the solution. If you’re using the agile approach, at the start of each iteration, a review of tasks for the next iteration will be agreed upon, the project plan will be updated, and task assignments will be created.

At the end of the iteration, you’ll look at what you’ve completed, which has been tested and merged into the solution code management tool.

Prepare

In the prepare phase, the solution has been built. At this point, the customer’s SMEs will start to test the solution. The scripts that will be used to test the solution are created near the beginning of the project, when the requirement-gathering sessions were completed. The testing scripts can be run either as a manual or automated process.