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.

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 NAV
• A sales module
• A 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.

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 policies
• Budget allocations
• Expense processing
• Expense 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?

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.

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.

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.