Great stuff on the D365 roadmap

What we currently see is that more and more power user functionality is introduced step-by-step to make Dynamics 365 ready for the next natural technological step; to become a true SaaS solution built as a Azure service fabric. Check out this video from Microsoft for what I hope is the future and architecture direction for Dynamics 365. But before we get there, there have to be a natural transition of making Dynamics 365 more configurable and less dependent on creating your own customizations and extensions.

Now and then I try to keep an eye on the D365 roadmap for signs on this transition, and today I found these nice features that I think will be highly valuable. I have copied the descriptions from the roadmap, and the release date is not clear, but I look forward to present these great enhancements to my customers.

1. Power users can add custom fields to forms without developer customization

Many application customizations involve adding one or more fields to existing tables and including them in application forms. Most of your customizations may be comprised of adding fields.

Customizations are expensive because they require developer intervention for development, test, and code life cycle management. Customizations also need to be managed and migrated from one environment to another.

We are making it easier to add custom fields to forms in Dynamics 365 for Finance and Operations, Enterprise edition. No longer will developer customization be needed. Instead, a power user will be able to add a custom field to a table and then place that field on the form using personalization. An IT administrator will then be able to share the personalization with others in your organization.

2. Product lifecycle state

The product lifecycle state will be introduced for released products and product variants. You can define any number of product lifecycle states by assigning a state name and description. You can select one lifecycle state as the default state for new released products. Released product variants inherit the product lifecycle state from their released product masters. When changing the lifecycle state on a released product master, you can choose to update all existing variants that have the same original state.

To control and understand the situation of a specific product or product variant in its lifecycle, it is a best practice in Product lifecycle management solutions (PLM) to associate a lifecycle state with a variable state model to products. This capability will be added to the released product model. The main purpose of this extension is to provide a scalable solution that can exclude obsolete products and product variants, including configurations, from master planning and BOM-level calculation.

Impact on master planning – The product lifecycle state has only one control flag: Is active for planning. By default, this is set to Yes for all product lifecycle states. When the field is set to No, the associated released products or product variants are:

  • Excluded from Master planning
  • Excluded from BOM level calculation

For performance reasons, it is highly recommended to associate all obsolete released products or product variants to a product lifecycle state that is deactivated for master planning, especially when you work with non-reusable product configuration variants.

Find obsolete released products and products variants – You can run an analysis to find and update obsolete released products or product variants.

If you run the analysis in a simulation mode, the released products and product variants that are identified as obsolete will be displayed on a specific page for you to view. The analysis searches for transactions and specific master data to find the released products or product variants that have no demand within a specific period. New released products that are created within the specific period can be excluded from the analysis.

When the analysis simulation returns the expected result, you can run the analysis by assigning a new product lifecycle state to all the products that are identified as obsolete.

Default value during migration, import, and export

When migrating from previous releases, the lifecycle state for all released products and product variants will be blank.

When importing released products through a data entity, the default lifecycle state will be applied.

When importing released product variants through a data entity, the product lifecycle state of the released product master will be applied.

Note, the ability to set individual product lifecycle states using the data entities for released products or product variants is not supported.

3. Users can pin PowerApps to forms and share with peers to augment functionality

Have you built a PowerApp that uses or shows data from Dynamics 365 for Finance and Operations, Enterprise edition? Or have you been using a PowerApp built by someone in your organization? Would you like to use PowerApps to build last-mile applications that augment the functionality of Finance and Operations?

Your users can build PowerApps without having to be expert developers to extend ERP functionality. PowerApps developed by yourself, your organization, or the broader ecosystem can now be used to augment ERP functionality by including them within the Finance and Operations client.

Your users will be able to pin PowerApps to pages in Finance and Operations. After they’ve been added, these changes can be shared with peers in your organization as personalizations.

 

Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft, my employer

Dynamics 365 : Adding check-digits to number-sequences

In Dynamics 365 we are using number sequences to automatically create identifiers like product number, customer number etc. I’m a fan of having these numbers as “clean” as possible, and I always try to convince my customers use pure numbers. Why ? Take a look at the keyboard:

The numb-pad is the fastest way of typing in data. I also see that users normally perform lookup and see the description of what they are selecting anyway.

But let take a scenario; We will use a number sequence to create products numbers. We will then typical get product numbers like this :

Then I have often seen that another problem arises; typing errors from the num-pad are actually getting a “hit”, because when using a number sequence we can almost always find a product that have the same number as the user wrongly typed.

If you try using your credit card online you will see that the number is not accepted if any number is wrong. The solution there is to build in check-digits in the number.

I created a very small extension to solve this in Dynamics 365, with just a few lines of code. In the following example The “green” part is from the number sequence, and the yellow part is from the modulo 10 check digit calculation.

In this way the user can never type the wrong product(or any other identifier), unless it is 100% correct.

In the screen for number sequences I added an option to add the check digit to my generated numbers.

I wanted to share this with you, because it is so simple:

1. Create an extension on the table “NumberSequencetable”. Then add the extended datatype (YesNo) as a field, and name it “AddCheckDigit”.

2. Add this field to the “Setup field group”

Then we have the parameter in place, and it is available on the number sequence as shown earlier.

3. Then create a new class and replace all code with the following :

Here I’m creating an extension to the NumberSeq class, and I’m creating one method; Num, that will add the modulo10 number to my number sequence.

Where I check if my new “AddCheckDigit” is enabled, and I’m also saying that do not do this for continuos number sequences, manual, and I also say that the number sequence must be allowed to be changed to a higher number.

That’s it

Now you can have check-digits on products, customers, vendors, sales orders, purchase orders etc.

PS! I have not tested this code 100%, but the community is full of brainpower that hopefully can share additional findings on bugs or flaws.

If you like this, vote at idea sat https://ideas.dynamics.com/ideas/dynamics-operations/ID0002954

Agile POD’s: Organize for efficiency

Have you ever seen the TV-series “House of Lies“. This is a quite funny TV comedy series that focuses on the extrovert lifestyle of a management consulting team. First of all it is a comedy and not very realistic, but it manages to illustrate the concept of how to create the most efficient organization form for solving problems; The Agile POD.

Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output. This blogpost is about how to organize a consulting business that is non-silo organized around an actual service product.

In many consulting companies today, we see increasingly alarming signs that prevents the full utilization of the people and resources. Some of the signs can be seen as:

– Many non-direct-operative managers. (If you have >5 levels from bottom to top you have an issue)
– To many internal meetings. (Why Meetings Kill Productivity)
– To much time are used to generate budgets, forecasts and excel spreadsheets.  (No actual customer value)
– Organized into silo-team with similar expertise. (Functional, Technical, Support etc)
– New project teams for each project. (Spends 2 months of getting to know your team members)
– Outdated internal systems and processes.
– Mixed marketing message and costly (pre) sales and implementation processes
– Many partners is currently not ready for the Dynamics 365 cloud based disruption (Sticks to waterfall, while agile accelerate)

Agile POD’s is a different way of organizing a team for efficiency. How does a agile POD look like? In this example we have a small 5 person permanent team. This team is specialized for running a some tasks/phases in the initial Dynamics 365 implementation; The Agile preparation phase.

In this example the POD owner is the Solution Architect. The roles in the POD can be described as:

The solution architect:

He runs the POD, and he also have all the responsibility of the POD. It is the POD owner that recruit the POD-members. The Solution Architect is the “face” of the POD, and will organize the work in the POD and also discuss the solutions with the key decision takers at the customer. Very often the solution architect have lot’s experience. In agile terms this is also the SCRUM-master and also very operational.

The Finance expert:

When implementing Dynamics 365, there is an always a need to know how to connect the operational processes into accounting and reporting. This person is highly knowledgeable in Financial Management reporting, Power BI, Excel. He also knows how to improve the reporting from the financial perspective by defining financial dimensions, setting up Tax, Bank, Fixed Assets, HR and Budgeting/Forecasting.

The Vertical Domain Expert:

How to implement best-of-breed processes is the vertical domain experts expertise. In Retail-domains this means expert on Master data, Categorization, Stores, POS, Devices etc.

The Technical Architect:

In a cloud based system, there is a need to understand how environments are deployed, setup and make it all ready for an efficient Application Lifecycle Management. The Architect knows the ITIL-framework. When a change is needed the technical architect will create the necessary documentation/VSTS backlogs for developers to execute on.

The Junior consultant:

The junior consultant is here to learn, offload and support the team. As experience increases the junior will eventually more responsibility and hopefully some day move into other positions in the team.

Within the team we are looking to T-shaped person, that have a width to their expertise, and also a few deep expert knowledge domains. A gaming company called Valve(That delivers the Steam gaming store) described what we are looking for with the following picture of the T-shaped model. Take a look at their employee handbook. This same concept and idea is relevant for Dynamics 365 consulting companies.

The Agile POD’s must therefore specialize their own services. Each POD-team must therefore build WBS (Work-Breakdown-Structures) that enables the delivery to combinedly utilizes the entire POD.

The idea is that a POD-team is sent out to the field, then delivers the pre-defined services, and returns safely afterwards. Then it is off to the next client to again deliver the same service. As you may understand, it is therefore important that the services delivered is predefined. In this concept there is not one team that delivers a complete implementation. In larger implementations it would be a sequence of Agile POD’s that cover the implementation.

This way of organizing is not a new way of doing things. This working concept have been applied for decades at entrepreneurs and building companies. When building a house this is not done with a single team. It is done by a sequence of teams that is specialized. A POD team will have responsibility of a limited set of tasks, that needs to be performed in a predefined sequence.

By organizing operational skills into POD’s executed in a sequence, we now have a balanced unit. One pain in Dynamics 365 consulting companies I often see is that bottlenecks arises around a few selected roles. Typical on the solution architects. This unbalance will result on high utilization on these roles, with other roles have low utilization, because work is not correctly distributed. We also see that consultants are being placed into project teams because they have free time, and not because they have the right knowledge. This increases costs and reduces satisfaction for customers. Ultimately it also reduces profitability for the implementation partner.

Agile POD’s does not solve every thing, but it makes the center core operational services lean and efficient. Any consulting company still needs sales, project management and customer support as separate functions.

As seen in the figure above the each vertical focus area will have a management functions, that focuses on building Agile POD’s. The idea is not to hire single consultants but to create new POD’s. The POD itself must define the services that the POD can deliver. The role of a vertical department management is therefore to how on recruiting new POD’s. As Valve explains it, the hiring becomes the most important thing in the universe.

A model for money and revenue must also be established. All departments must be self-financing and make sure that they are balanced according to how the revenue stream is defined. One element that is common in the consulting business is bonuses. I personally don’t like the idea of bonuses but I see that it is very difficult without it.(Necessary evil) In the model below is a an example on how different departments can be revarded.

Marketing and Sales: The concept of cloud based systems it that the customer don’t need to purchase all the software upfront. They rent/hire the software in the cloud, and only pays a monthly fee. The Marketing and Sales divisions must therefore be financed by the monthly license revenue, and the bonus would be accumulating. The purpose is therefore to make sure new customers are onboarding and that existing customers hare happy with the services. As a new seller in this way of organizing it, there will not be much bonus in the start, as you have few customers onboarded. But as more customers get’s on board, the bonus will be accumulating, and after 2-3 years there will be a decent bonus and a decent ground for investing more in marketing.

Project and Management consulting: As described earlier, these roles are the only more “permanent” roles that exists in the project. They will ask Agile POD’s to come inn and solve specific tasks. Their services are based on T&M(Time and Material), and their bonus will be based on the revenue(not margin) on the project.

The Agile POD’s: These services are charged in a combination of T&M and Predefined Product Services. The Predefined Product Services is the key here. Create WBS-structures where the price and delivery is clearly defined. The bonus here is a team bonus. Internally in the team it is distributed according to a key. But the POD-team can also choose to use the bonus for other purposes also like training or conferences. Remember that an agile POD is a self-contained unit with costs, revenues and margins. If the POD is not profitable it will be dissolved and the team unattached/fired.

Platform Services: This department is making sure all services/software around the Dynamics 365 is working as expected. This means making sure the azure/tendents are set up correctly, that Office is working and that services like CDS(Common Data Services) and PowerApps are setup as expected. All their services should be Predefined Product Services. And the bonus would be based on margin. Why ? Because we want to become better and better delivering these predefined services. The faster this is delivered the more margin is generated. This is a Win-Win situation for both the customer and for the consulting company.

Customer support/After Sales: Customer support and aftersales is all about delivering excellent customer service after the project have gone live. It’s revenue should be based on support agreements and add-ons. The bonus for the department is based on accumulated revenue, because these services should be reoccurring services that the customer pays for each month. If the customer is happy about the services provided then they will continue to use this service. The alternative for the customer is to use Microsoft Premier Support that can be quite costly and not that relevant in most cases.

At the end of this blogpost I would like to visualize how we envision the Agile POD’s, where we have training on our services and delivering excellent customer services on time and on budget.

giphy-downsized2

And if we don’t, then this is the consequence:

formula-1-fire-gif-1632727

Additional details on Agile POD’s can be found here:

https://www.globant.com/build/agile-pods

https://www.agileconnection.com/article/using-agile-pods-realize-potential-your-team

Video : https://www.youtube.com/watch?v=IwJKRaocdxI

Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft, my employer EG or other parties.

Dynamics 365 Pre go-live checklist

I asked Microsoft if I could share their Pre go-live checklist that is used in the Fast-Track program. And they said yes

So here is a copy for you, and what customers must be prepared to answer before Microsoft is deploying the production environment.

Pre Go-live Health Check list:

  1. Solution acceptance by users: UAT
    1. Is UAT completed successfully? How many users participated in UAT?
    2. Did UAT test cases cover entire scope of requirements planned for go-live?
    3. How many bugs/issues from UAT are still open?
    4. Any of the open bugs/issues a showstopper for go-live?
    5. Was UAT done using migrated data?
  2. Business signoff:
    1. Business has signed off after UAT that the solution meets business needs?
    2. Solution adheres to any company/industry specific compliance (where necessary)
    3. Training is complete
    4. All features going live are documented, approved and signed off by customer
  3. Performance:
    1. How was the performance in UAT? Is it acceptable for go-live?
    2. If Performance testing was done, then are there any open actions from it?
  4. User & Security setup:
    1. How many security roles are being used. All security roles are setup and tested?
    2. Users that will need access at go-live have been setup with correct security role?
  5. Data Migration:
    1. Data migration status – Masters & Open Transactions/Balances
    2. Business has identified owners for data validation?
    3. Review cut-over plan: Business & Partner teams are comfortable with the plan?
    4. Does the Data migration performance fits within cut-over window?
  6. Configuration Management:
    1. Are the configurations updated in Golden Configuration environment based on changes in UAT?
    2. Data stewards/owners identified and process in place for post go-live changes in Master/Configuration data?
    3. All Legal Entities configured for Go-Live?
    4. Are configurations documented?
  7. Integrations:
    1. Review list of integrations and readiness plan for each
    2. Latency requirements and performance criteria are met
    3. Integration support is in place with named contacts/owners
  8. Code Management
    1. Production fixes/maintenance process defined?
    2. Code promotion (between environments) process is in place, documented and the entire team knows and understands the process
    3. Code promotion schedule for production is in place?
    4. Emergency process for code promotion to production is defined?
  9. Monitoring and Microsoft Support
    1. LCS diagnostics setup and knowledge transfer to customer
    2. Issue resolution and Escalation process defined – LCS support is verified?

A Practical Guide for Dynamics 365 Iterative Implementation

With the introduction of Dynamics 365 and cloud enabled tools like Office and VSTS(Visual Studio Team Services) we have accelerators towards iterative ways of performing an implementation.

Digitalization also enables the ability to go from a document and template approach to a committed task driven implementation with a sprint based sub-deliveries, where all parties are involved. This also increases visibility, removes lead-times and results in faster deliveries. Adapting digitalization and going iterative in a project it not only about using new tools and processes like VSTS, but also covering Practices, Principles, Values and Mindsets of the project participants.

The iterative preparation

As described in earlier blogposts it is vital to have a clear concept of process modeling where processes are broken down to sub-processes and requirements. Having WBS (Work-Breakdown-Structures) is the tool to plan and execute on deliverables. The traditionally solution analysis is transforming into a iterative preparation phase that can let us define clear work packages that can be solved in sprint executions.

The Iterative preparation should have a formalized set of workshops, and the main purpose is to generate an approved solution backlog. It is normally recommended to complete the preparation phase before going into the execution phase. But in larger projects the preparation phase could be a parallel phase to the execution phase, and where customer approved solution backlogs can be planned into sprints and started upon before the phase is ended.

Please remember that iterative implementation models do not give a detailed picture of scope or costs! The actual deliveries are defined by the customer approved solution backlog.

The following flow chart shows the main activities in the preparation phase.

The granularity and level of details needed in the deliverable documents is agreed on in the project. A middle and practical way is to create the deliverable documents with a minimum set of information and a final conclusion, and then URL link the content in documents towards a VSTS site for further information and process.

The preparation phase is highly customer intensive and require a detailed plan, invitations, workshops and time to document the findings. Before is participating in preparation workshops it is recommended that the participants have completed a “Learn, Try, Buy” phase. An example project plan for the preparation phase can look like this for a retail customer.

As seen in the example plan, the preparation can have dedicated tracks for the functional areas, and these will vary based on the vertical models that is being used. The level of granularity of the sub topics is recommended to be according to the first and second level in the process models.

Use process models to define scope and topics.

The contents of the preparation workshops should be organized based on the process models. This makes sure that best practices are discussed and taken into account for the execution phase. The value chain shown here is the divided into 3 main epic tracks; Management processes, Operational processes and Support processes. There are different models for each vertical. As seen in the following figure I typical use to illustrate the EG retail value chain model.

ProcessModels

For each of the “boxes” in the model represents a topic, where business processes is discussed and defined. The model will provide:

  • Workshop Agenda’s templates
  • UAT test scripts templates and recommended process recordings
  • Stack/technology recommendations
  • Process flows (visio or BPM in LCS)
  • Solution Backlog templates.
  • KPI assessment recommendations (APQC)

From Model to solution backlog

Based on the findings from the preparation phase a solution backlog is created. The most efficient tool to do this in, is the VSTS (Visual Studio Team Services), setup using the CMMI definitions. Here all backlogs are organized in a hierarchy of Epic’s, Features, Backlogs, tasks and Impediments.

The general consensus of these definitions are:

Level Description
Epics Something that transcends projects/releases/versions.
Features Something that cannot be delivered in a single sprint, but can be delivered in a single release.
Requirement(CMMI)
Product Backlog (SCRUM)
Something that can be delivered in a sprint, and have an estimation.
Bug Something that that is not working and can be solved in a sprint, and have an estimation.
Task Assigned work elements with remaining effort.

To relate the structures to CMMI, the following guideline can also be followed.

More details in how to create a backlog in VSTS can be found here. Best practice is that the VSTS site is located on the customers tendant, and that external project participants are invited. The VSTS backlog can also be regarded as a WBS (Work Breakdown Structure). In the following example you can see how the backlog is structured according to a business process model.

The VSTS will also provide dashboards where a complete status can be seen and monitored. Setting up these Dashboards is based on defined queries towards tasks and backlogs, and are easy to tailor to the needs.

How to fill in a backlog item

The product backlog (and other elements) contains a small set of fields needed.

What should be regarded as a minimum set of information defined on a backlog is:

  • Name
  • Description
  • Acceptance Criteria
  • Effort estimated.

If additional fields are needed, they are quite easy to add and also easy to extend with new statuses.

If additional fields are needed, like APQC ID, planning dates, additional names etc, they can very easily be added to the form. See https://www.visualstudio.com/en-us/docs/work/customize/customize-work for more information.

In the preparation phase perform these activities:

  • Right-size backlog items by splitting larger items into smaller items. No backlog item should be larger than it will take to complete in a single sprint.
  • Identify and fill in gaps in the product backlog. Capture new ideas and stories, architecture and design requirements, and other spikes.
  • Reorder the backlog to represent today’s priorities and business value focus.
  • Ensure well defined acceptance criteria has been added to each item.
  • Revisit estimates made to backlog items and adjust upwards or downwards based on recent understanding about scope and acceptance criteria.
  • Review all potential backlog items to consider for the upcoming sprint to make sure they are well understood and that any additional work required to support their development is well understood by both product owner and the team.

Mapping a VSTS product backlog to the functional requirement documentation

Most often it is mandatory to also deliver a Functional Requirement Document. This document is delivered as in the end of the preparation phase. The reason why this document is important, is that it explicitly defines all requirements, and is a commercial document. But instead of writing a hundreds of page document, try to link the requirements using URL-links to the document. Then the FRD only contains the vital and important information that regulates responsibilities and commercial conditions.

The preparation phase ends when the deliverables from the phase is approved and signed by the customer. After the phase is approved, all information on the VSTS site can be copied into Excel backup sheets, that represents a snapshot of the status at the end of the prep phase.

Roles involved in an iterative preparation phase

The roles running an iterative preparation phase depends on project size and complexity. As a minimum, it is recommended that the following defined roles are present in this phase:

  • Project manager (Planning and facilitating)
  • Solution architect (Overall approval of solution)
  • Technical lead (Integrations and migration)
  • Functional Consultants (Covering training, functional area’s)
  • Junior Business consultants (Assisting writing and maintaining the solution backlog)

Customer project participants need to match this roles.

Iterative Execution phase

As the solution backlog is filled, sprints may be filled with approved backlog items. The overall process of the sprint is to deliver at set of backlog items, that have been broken down to specific tasks. The duration of a sprint is determined by the scrum master, the team’s facilitator. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Normally, a sprint lasts between 2 to 4 weeks. During the sprint, the team holds daily stand up meeting to discuss progress and brainstorm solutions to challenges. The customer may not make requests for changes during a sprint and only the scrum master or project manager has the power to interrupt or stop the sprint. At the end of the sprint, the team presents its completed work to the customer and the customer uses the criteria established at the sprint planning meeting to either accept or reject the work.

The following diagram shows the activities involved, and the expected deliverables from a sprint.

Define the Sprint log

To solve a backlog, then several resources may be required to be involved. When defining the sprint log, each backlog is split into tasks, that defines the sequence, remaining work and the assigned to. This means having tasks for analysis and design of the backlog, creating scripts for testing, tasks for developing and tasks for performing the test of the backlog item. As seen in the following figure a backlog is divided into tasks, and each task is must have a clear description and a “remaining work” estimate. If essential resources are needed to solve the task, then the task also should be assigned to this person.

When a task have been assigned to a person the person is committing to the task, and agrees on delivering the task within the defined sprint.

Conducting a sprint planning meeting

The customer, project manager and the Scrum Master will start a sprint by selecting the backlogs that should be solved in the current print. This is done in VSTS, and the backlogs are “dragged-and-dropped” to the selected sprint, or marked to specific iteration.

When planning a sprint, also identify what resources are needed in the sprint. In the sprint overview, then define the capacity and the resources required in the sprint. This makes planning easier and resource/capacity constraints can be identified by project manager/scrum master.

The daily sprint meeting

This meeting is the most important meeting each day. It should only last for 15 minutes, starts at the same time every day and is located on the same place every day. The SCRUM master is responsible to make sure that the meeting is as efficient as possible. It is a team meeting, where each team member explains what he is working on, and if there are any issues. Do NOT use the sprint meeting to try to solve issues. Just identify and share. Use other meetings to solve and to go deeper into each topic. Any notes that is important and identified in the CMMI can be described in the discussion field on the task/backlog.

Also use the “Add Tag” to mark tasks and backlogs that need special attention and follow-up.

Reporting status and completion

All backlog items have a state. The meaning of these states can be seen in the following flow charts:

Teams can use the Kanban board to update the status of backlogs, and the sprint task board to update the status of tasks. Dragging items to a new state column updates both the State and Reason fields. If additional intermediate steps and stages are needed, this can be customized in the settings of the VSTS.

Documentation

One of the disadvantages of an iterative implementations is that there are no clear and sharp end-phases, and this often does not fit good with commercial contracts. It is therefore important to make sure the deliverable documents are created/updated according to the progress. But remember to be active in documenting as much as possible in VSTS, and define the creation of deliverable documents as defined backlogs in the sprint. Expect to use at least 10% of you time in VSTS to give visibility to others.

Conduct Solution testing

Quality is a vital aspect of and everybody in the team owns quality – including developers, managers, product owners, user experience advocates, and customer project members. It is vital that the solution testing is a customer responsibility and that the testing is structures and planned accordingly.

VSTS provide rich and powerful tools everyone in the team can use to drive quality and collaboration throughout the implementation process. The easy-to-use, browser-based test management solution provides all the capabilities required for planned manual testing, user acceptance testing, exploratory testing, and gathering feedback from stakeholders.

Creating test plans and performing test are one of the most vital elements in the iterative implementation. Please read the following URL for UAT testing https://www.visualstudio.com/en-us/docs/test/manual-exploratory-testing/getting-started/user-acceptance-testing . Building a test plan is therefore a mandatory step and this ensures that defined accept criteria have been met.

The following documents are the input to the solution testing:

Flow Test Script
UAT Test Script by Function
UAT Test Script by Role
UAT Test Script Details

Test & Feedback

Visual Studio Team Services Marketplace contains a ton of jewels, and one add-in that can accelerate testing and feedback is the Test & Feedback extension to VSTS.

When installing it, you get a small icon in Chrome, where test and feedback can be given.

When setting it up, you just point to the VSTS site. And then you are ready to start giving feedback, and to collect backorders, bugs or tests, just click on the play button.

While navigating and taking screenshots, notes and video, it all gets recorded, with URL, time etc.

When done with the recording then create a bug, test or create a test case:

After saving the bug. I see that a bug have been created in VSTS:

I now have a complete bug report in VSTS, that the consultants can start to process and to identify if this is a bug or an “as designed” feature.

Microsoft Tools available for a Dynamics 365 project.

When working in a project, it is important to know that Microsoft tools and services are tightly connected and that each tool can simplify and enrich the user experience and efficiency. In the following figure the different most common tools can be seen. Also pay attention to that there are powerful integrations between these tools, and this section will provide some small tips on how to make these tools work together.

Having a clear understanding of the tools available can speed up implementations, and also give better visibility to all stakeholders. In the following topics, some of these benefits are discussed.

Microsoft VSTS: Visual Studio Team Services

Create a VSTS site at http://VisualStudio.com. For internal projects, create using your domain account. For customer project, it is recommended to create the site on a customer controlled domain, and then add the domain users as guest users. Other elements in relation to VSTS have been covered earlier in this document.

Who uses it? All implementation project members both from EG, Customer and 3’rd party vendors.
When to use it? Everyday and in all SCUM meetings.
Pricing 5 users free, stakeholders free. Paid user is 6$/month.
Members with Visual Studio subscriptions don’t need licenses. https://www.visualstudio.com/team-services/pricing/

Microsoft Excel: Upload and Maintain

Microsoft Excel can be used to import and publish the structure into VSTS, when the Visual Studio Community edition is locally installed on your PC. This makes it possible to extract all fields and values by using VSTS defined query.

Then a process model may be imported and a best practice product backlog is ready to be processed. Step-by-Step instruction on how to use Excel with VSTS, take a look at https://www.visualstudio.com/en-us/docs/work/office/bulk-add-modify-work-items-excel

Who uses it? Solution Architects and vertical responsible.
When to use it? In the start, when uploading process models and WBS’s as a start.
When mass updating backlog items and tasks.
Pricing Office 365 prices. https://products.office.com/en-us/compare-all-microsoft-office-products
Visual Studio Community edition is free.

Microsoft Project: Plan and Breakdown

Microsoft Project is a vital tool for streamlining quotations, WBS and resource planning. Built-in vertical templates, familiar scheduling tools, and access across devices help project managers and teams stay productive and on target. Microsoft Project is also directly integrated with VSTS, and exporting created backlogs and tasks/activities to Dynamics 365 for Operations can be done, and create a complete end-to-end process covering “from quote to cash”.

“Plan-the-work”, and “Work-the-plan” are essential activities and where all stakeholders can participate and cooperate, and that we deliver what is planned, and the invoice the customer receives corresponds to the agreement and contract. Having predefined WBS structures in Microsoft Project simplifies project planning, and the VSTS is auto updated accordingly to how the planning is performed.

 

Who uses it? Presales, Sales and Project management.
When to use it? Microsoft Project is excellent to handle WBS structures when planning and quoting a project. Microsoft Project is also used for planning resources, and to reach project deadlines. For more information on how connect VSTS and Microsoft Project, take a look at https://www.youtube.com/watch?v=GjYu5WmcQXo
Pricing 30$/user/month for Project Online Professional
https://products.office.com/en-us/project/compare-microsoft-project-management-software?tab=tabs-1

Microsoft Outlook: Inform and Alert

Some stakeholders do not want to go deep into VSTS, or to extract information from Excel/Projects. Also when tasks are being assigned they want to be informed and when issues are resolved, they want to notified. Setting up notifications in VSTS solves this requirement, and will keep project participants informed of any changes. The email also contains a URL directly to the task/backlog.

Setting up notifications are done in VSTS, and individual filtering can be defined.

Who uses it? All project participants receive assigned notifications. Project managers and solution architect receive all notifications.
When to use it? When Outlook is used to keep participants informed.
Pricing Outlook included with Office 365 prices. No additional costs.

Microsoft Teams: Discuss and Involve

Informal communications are vital for any project. Tools like Skype for Business will take care of meetings and screen sharing, but Microsoft Teams gives flexible communication on all platforms and keep everyone in the loop. The users can see content and chat history anytime, including team chats with Skype that are visible to the whole team. Private group chats are available for smaller group conversations. The Microsoft teams can also function as the center point, with direct tabpages towards VSTS, Home Dynamics 365, LCS, Sharepoint etc. Since this September the Microsoft teams support guest users, and since these sites normally is on the customers tendents, we consultants are logging in with our company email addresses.

The VSTS Kanban board are easily accessible from the Microsoft teams.

Who uses it? Project participants involved in a project, that needs to have informal communication and the ability to work asynchrony with a discussion history.
When to use it? When more direct communication is needed, and especially for developers.
Pricing Teams normally included with Office 365 prices. No additional costs.

Microsoft SharePoint online: Documents and Archive

Even in a highly interactive and iterative environment, there is a need for documents. And then especially for deliverable documents. For this, SharePoint Online is used to store, track and develop the documentation. The internal folder structure is optimized for the sales process, and contains commercial binding documents. The SharePoint online site in mention here, is the SharePoint online site that is the customer property. The following document structure can be recommended.

After the project is delivered, the SharePoint site will remain as the documentation together with the VSTS site.

Who uses it? Project participants involved in a project, that needs to create or use formal documentation and deliverable.
When to use it? When having specific deliverable that.
Pricing SharePoint is included with recommended Office 365 E3 prices.

Microsoft Flow and PowerApps: Workflow and Apps

Microsoft Flow and PowerApps are quite new technologies in the Microsoft office family. The idea of bringing these tools into the scope, is to be able to have process and workflow automation in the implementations. PowerApps is also a great tool for data collection in testing and for getting feedback.

Some examples of Microsoft Flow:

Streamline approvals by sending files with approval requests

  • I’m sick button
    à Inform colleagues and block calendar.

Some examples of powerApps:

Who uses it? Superusers and Architects
When to use it? Used for automating tasks and to create fast simple prototype apps that can assist in the implementation
Pricing Flow and PowerApps are included in a Dynamics 365 Plan 2 license.

I hope this blogpost gives an insight into the digitalization process partners now are using in Dynamics 365 implementations. The Microsoft sites contains tons of more information and I recommend to explore more of the Microsoft technology stack that is available for Dynamics implementations.

Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft, my employer EG or other parties.

 

Common Data Service(CDS); Talk the talk, but not walk the walk yet

With every new release and platform update we see a clear Microsoft commitment to support deeper integration across the D365 portfolio. It’s still in the early stages, but we see the direction. New developments such as parts of Dynamics 365 for Talent is using the CDS. I think that we in the future will see more business apps utilizing the CDS as the data storage. The benefit of the common data model is that applications can work against data without needing to explicitly know where that data is coming from. To see what the Microsoft business platform are, take a look at https://businessplatform.microsoft.com

The CDS also have an important role in both process and data integration between the Sales(CRM) and Operations(ERP) apps, and the current status after the July release and Update 9 is that we have 6 templates that we can use to test some scenarios with D365. The Business platform admin center is where the CDS data integrations can be set up. You can reach this from https://admin.businessplatform.microsoft.com or from https://admin.powerapps.com

The first needed to be set up is Connection sets. Connection sets are a collection of two more connections, organization mapping information, and integration keys that can be reused among projects.

In this case I have set up a integration where data can go from D365 for Finance and Operations à CDS à D365 Sales:

Then also to map the organization ID’s across the 3 services.

And finally the integration key’s.

After the connection sets have been setup, the CDS knows how to connect to the different systems. We can then create an integration project

We can then select between the current 6 templates.

I have only been able to test the Accounts and Products. The Sales Quotes did not work for me (but they are also in preview currently).

After the integration project have been created it is possible to add more integration tasks and make changes to the mapping. If there are issues with the mapping or you need to map additional it will show in the “Issues” column.

N the mapping transformation functions, like this where the item type is changed when transferred from CDS to Dynamics 365 for Sales

The integration can also be scheduled to run at specific times:

Some unofficial benchmarking, I managed to transfer 200 products to CRM in 40 seconds.

Summary:

We are definitely going in the right direction, but we are yet not ready to “Walk-the-walk”. Microsoft currently only support synchronization in one direction, but bi-directional synchronization are in the roadmap. This is important to support “multi-master” system where the same fields can be authored on either side. Like Customer Name etc. It seems Microsoft is focusing on providing business scenario’s like “Prospect-To-Cash”, and what we mainly have now is a preview of how this would look in the future. The mapping is not complete from the templates and needs more work.

My final comments are that we will in the future have a very easy to use system for connecting the unified business operations apps. It was hoped that this business platform would be more ready with the July release, but it needs more releases for this to be useful in actual implementations. This feature needs to grow beyond the “Minimum-Viable-Product”. I hope and expect that we will see in place through the fall, and that the next release will have more mature integration templates. So far, good work Microsoft, but please hurry ! To learn more take a look into the https://docs.microsoft.com/en-us/common-data-service/entity-reference/dynamics-365-integration.

 

 

 

 

Dynamics 365 for Finance and Operations On-Prem

Now the On-Prem system requirements are available : https://www.microsoft.com/en-us/download/details.aspx?id=55496

To get it running the minimum recommended requirements are:

Total Number of instances(VM/Machines) : 21

Total number of CPU cores : 104

Total Memory : 408 Gb

This minimum configuration will estimated be able to support 240-1200 users.

To sum it up: Go Cloud . Much smarter.