George Doubinski is coming to Stockholm and he is going to be holding a very rare level 300 (= advanced) Dynamics 365 developer training.
George is an MVP and a good friend of mine and one of the bright beacons in the D365 community, co-founder of both http://crmtipoftheday.com/ and http://crm.audio/ . He is an excellent developer who told me that he is always striving to learning something new. Last he said his goal was to learn a new programming language every year. And to top that off, he is a great presentor and teacher as he is a lot of fun to listen to and almost none can match his skills when it comes to coding in Dynamics 365.
We at CRM-Konsulterna were very happy when we were able to convince him to come to Sweden and Stockholm and teach us some of what he knows! He lives in Australia so this doesn’t happen often.
During the CRM UG Summit I was approached in the Medic booth by two nice guys from Microsoft who asked me if they could show me and get my opinion on a new feature of Dynamics 365. It was the AppDesigner. There had been so much hype around a lot of the other stuff (editable grids, editable grids, editable grids) that I hadn’t noticed this and when they showed it and I had time to think about it I recognized that it is really a cool and useful feature that I think can do a lot of good in the system.
One of the things I try to evangelize about is to slim the system down, not “dumb it down” but make it slim, and efficient to what you are trying to do. Hence not include a lot of unnecessary stuff. The AppDesigner is excellent for this, it creates subsets of Dynamics 365 (not operations/financials) into what are called apps. With their own sitemaps, view sets, form sets, business process flow sets, chart sets.
I made another film about this, on how to enable and get going with it. Why not watch it?
So, time to try something new. I recorded a small screencast with SnagIt to show how easy it is to enable the awsome new feature Editable grids in Dynamics 365. So, please have a look and let me know what you think!
And yes, I know I keep saying CRM, and Dynamics CRM. I have been working with this product for more than 11 years now. It’s going to take some time for this old dog to sit.
As many of you probably have heard Dynamics CRM will as of Nov 1 2016 be part of Dynamics 365 in a commendable push from Microsoft to bring the Dynamics products closer together. This is partly a branding thing as the products themselves, as Dynamics CRM, will still be the same product from a technical perspective, at least in the Enterprise Edition, (little is known of the Business Edition) and partly a technical concept as they are introducing something called the Common Data Model which is canonical data model (unified data model) to which all “Apps” are integrated to automatically. This is what I wanted to discuss some.
This all sounds great, and I will admit that I havn’t had time to fiddle with it yet, but I have had the pleasure of working with quite a few integration projects between CRM and ERP. And that is not easy, even if you do have a ready made point-to-point integration. So I would just like to make a few points that I hope you do consider before switching it on and hoping it will solve all your issues.
1. Addresses in ERP and CRM are typically not the same. In ERP the addresses that are needed can typically be invoicing address and delivery address, while in CRM the most important addresses are visiting address and postal address. If you naivly presume these to be the same the effects can be dramatic and sometime even catastrophic. I friend of mine, Peter Björkmarker, told me a story of a company integrated just like this, and as CRM was set as the customer data master, it overwrote all invoice addresses in the ERP system with visiting addresses. Next month, all invoices which were sent out were automatically, without anyone noticing sent out to the wrong address, hence nobody paid them. The company got into an accute cashflow problem and almost filed for bankcrupcy. So this is no joke.
2. Ready built integration are usually on a technical level, but you expect it to work on a business level. Integration technology is usually about moving data, but just having the data in the other system doesn’t always DO anything. An example is if you have a boolean field on the customer in the ERP where the financial people can block the customer from further business if they havn’t payed their invoices. So you integrate this field to CRM and can now see it on the account form. But without any additional logic in CRM it will still be possible to create opportunities, quotes and orders. Maybe not what you would like.
3. Data structures are different. My colleague Rickard Norström, whose blog you can find in the list to the right, was part of a CRM project which integrated to Dyn AX. One of their issues was the AX address data structure. An address record in AX can be used by both an account and a contact, And I think even several accounts. When this address is changed, of course this is seen in all affected places. As this is very different from the customeraddress built in logic in CRM they had to create their own new address entity to solve this. Other typical areas where there are large differences are in the logic of setting prices on opps/quotes/order. As you can expect, a system like AX with MPC and many other deep links into costs can of course use that as a base for pricing, something that is very hard for CRM. It also has more complex or just different ways of handling pricelists. I was working with an iScala integration and iScala for instance can have a current price in a pricelist and a comming price with a specified date on which the new price will be enforced. However, no event in the system will trigger at that time. Customer specific pricelists are also something that occur, not advisable but existing especially for larger customer accounts.
4. Centralized integration architecture. The Common Data Model sounds great but it only handles two of the components in the Business system infrastructure. If you for instance are a Telco the amount of business systems will be a lot more, billing systems, provisioning system, logistic systems, product configurators, etc. Banks are also complex worlds. Many of these have tried to consolidate their integrations to integration hub technologies like WebSphere or BizTalk and if done properly they will of course have their company defined canonical data model. It would be interesting to see the story of how the Common Data Model works together with this. It probably can by shuffeling data using Logic Apps to and from the CDM, but in essence you will have two hubs to orcestrate. Another option is of course to use the CDM as the central hub for all information, as long as that is extendable and doable. So, from this perspective, the main issue is probably, if we have 8 systems connected to our existing integration hub, is it plausible to use the CDM or do we manually integrate anyway directly to each application?
To conclude, I think the CDM will be a good tool but I will keep my expectation to a reasonable level and I recommend you do this too. Do not think it will make your highly customized CRM and AX automatically integrate all data and make it work from a business perspective, that would simply be too increadible. If they manage that, I will buy the entire team building CDM a beer (or similar).
Recent Comments