Failed ERP implementation will change partners to become trusted advisors.

A norwegian customer won a compensation case against an ERP implementation partner after the customer terminated the parties’ agreement on the supply of a new ERP. The customer was compensated by the Norwegian district court assessed at 288 mNOK (36,7 mUSD). Originally the contract was worth 120 mNOK. You can read the complete story here http://www.selmer.no/en/nyhet/felleskjopet-agri-wins-district-court-case. The court decision is expected to be appealed.

Luckily this was NOT a Dynamics 365 implementation, and the customer is actually replacing the failed ERP system with Dynamics 365. The reason why I wanted to write about this story is that it has implications on how much risk and responsibility an ERP implementation partner can take. A major part of the ERP partners are smaller companies with less than 100 employees, than cannot take the risk of getting into such a situation. There are always problems and risks that is beyond what a ERP partner can control. Partners are not the developer company of the standard software. They are implementing, and in some cases adding additional extensions. Also the cloud based software are running on azure that is beyond the control of the partner.

How can this change partners behavior? Partners are changing towards becoming verticalized trusted advisors, but with limited responsibilities. We can give recommendations based on what we know about the software and how to use it efficiently but the costs are more on a T&M(Time and Material) basis. It will more be the customer them selves that is responsible for the implementation and time-tables.

Some customers will not accept this change, but other do. There are currently resource constrains in the Dynamics 365 partner channel and we partners avoiding customers that takes a back-seat approach towards their implementation projects. The sales focus will change towards those customers that take more of the responsibility themselves, and that do understand to take a more dynamic and agile approach. A 400-page requirement document is not a good start for an ERP project, as we see the digitalization possibilities are accelerating. We also see that customers don’t run a 2 year ERP implementation project before going live. They run a 90 days project to get live with only parts of their requirements. The project then takes on other areas and they extend their use of the Dynamics 365.

At the end, I include some trusted advisor recommendations that I think can inspire anyone that is about to start a project.

D365FO – Speed up Retail RSSU download performance

If you don’t know what RSSU is, I suggest reading this, but the RSSU is about having a database locally in your store that MPOS or CPOS can connect to. It is typically used if you have an unreliable or slow internet connection.

One of the things you can evaluate is to implement the Azure Express Route, and Microsoft have released a whitepaper for Dynamics 365. This can really speed up the connectivity performance.

Another thing I see is annoying is that the local RSSU is only picking up the distribution files every 15 minutes. The Cloud channel database is really fast. This means that when sending new products or prices to the RSSU, it can take up to 15 minutes before this data is available in the MPOS. That is really annoying to wait 15 minutes when testing.

In the Microsoft documentation we are instructed to use the Data Sync interval to speed up the synchronization. But somehow it does not work.

But there is a way around this. On the local RSSU there is a configuration file, where you can modify how often the RRSU should request new data to be downloaded.

Then change the following two lines:

Then just restart the AsyncClient Services and reset the IIS on the RSSU box. Then the distribution of data to the RSSU is really speeding up.

But what is the recommended setting from Microsoft ?

This is recommended to make the RSSU request packages at an interval that is a proper fraction of what the packages are generated at. So if you are sending new products every 10 minutes? Do 5 minutes. If you are sending new products every 5 minutes, do 2 minutes download interval. The higher frequency the more often the RSSU will request data, and some consider this as a waste of bandwidth.

Good luck in your retail implementation

D365FOE-Moving to a new tenant

Companies change, merge, sell, purchase each other, and we encounter requirements where it is a requirement to move to a new/other Azure AD tenant.

But…. That’s not a small thing. We requested through a Microsoft support ticket on how to do this, and hoping this was a small formality, and that Microsoft had some magic tricks of doing this. But they don’t. But I can explain the process we are on to achieve this.

  1. Create Azure subscription on new tenant.
  2. Buy a new required licenses in new CSP-subscription for D365FO DEV/TEST/PROD instance.
  3. Add admin user on new tenant to the new LCS.
  4. Setup new azure connector in existing LCS project with the new subscription.
  5. Deploy new DEV/TEST/PROD environments for the new connector in the new tenant
  6. Setup new VSTS in the new tenant.
  7. Copy all checked-in code from old to new VSTS.
  8. Import all checked-in code from new VSTS to new DEV environment.
  9. Compile and install the code packages into the new stage environment.
  10. Request DB copy from “old” PROD to the “old” stage environment.
  11. Export an Azure back-pack from the “old” stage environment.
  12. Import the Azure back-pack into the “new” Dev environment.
  13. Run AdminUserProvisioning tool with admin user from new tenant to swap tenant.
  14. Repopulate email settings, users and other settings lost by the copy.
  15. Check, Check, Check….Fix, Fix, Fix.
  16. Request DSE to copy new stage to new PROD (only possible once).
  17. Check, Check, Check….Fix, Fix, Fix.
  18. Suspend/end the “old” CSP subscription.

In the process you will lose all documents that is record attached/stored in the old environment. There are also some other expected issues.

Do expect to spend some time on such a process. And it’s a good thing to perform the DB copy two times (first time just for validation and test). Microsoft is looking into how to improve this process, but this is how we are performing it.

If any in the community have better ideas, feel free to share it

BIG credits to my colleague HAKAM.

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