ERP data access: 5 top tips
One of the most-read blogs on the ZAP website is a piece I wrote earlier this year with advice for successful ERP data access. This will undoubtedly be a hot topic at Big Data LDN but, with so much great information coming out of the event, I’ll cut to the chase and set out a more ‘portable’ version of that blog for Big Data LDNers.
In brief, those 5 top tips:
- At some point, you will own two of something, be it ERPs, CRMs or other data sources. And a single application’s entity store may not give you the visibility you need across these multiple sources.
- Don’t feel you have to accept turning off or turning away historical data if you don’t want to.
- Remember, few vendors understand their competitors’ data and likely cannot easily accommodate it.
- Migrating data into a new application can be a very expensive project line item.
- Data Management often outlives your individual business application choices!
“How did this happen? We have two ERPs with data we can’t relate to!” It’s the age-old problem. One vendor solves (some of) the data access issues for their application but what about the other applications you own?
And the companion to that problem: vendors pop up looking to show how easy it is to build a narrow way of consuming data. Plus ERP and CRM are complicated and challenging worlds to navigate to bring forward the data which is most meaningful to leaders on all levels. Often, if you succeed at navigating your ERP data, there is still a need to present it in a consumable way.
First things first, let’s consider the end users…. REALLY! There are many awesome tools for supporting the visual aspects of the data journey. Often, the end users across both small and large organizations are using different tools. The finance team may really like Excel whereas the sales team might be great with a Power BI or Tableau dashboard; somewhere in the middle are people trying to drive operational functions at multiple levels of detail which might be a combination of reports, personal dashboards and performance metrics using the afore-mentioned products or other tools like Tableau or SQL Server Reporting Services.
“Everyone, get on the bus…”
The monolithic (and increasingly dated) view of data integration with a newly-acquired ERP platform is to bring all the data you need with you from your past applications and put them into the new ERP platform.
It reminds me a bit of the difference between a bus on a school bus route versus a shuttle bus picking up at a popular stop. On a school bus route, passengers (or, in our case, data) is acquired over the journey, and there’s a reasonable assurance there is a place for everyone on the bus. The driver knows about everyone (or the data) and, despite personality differences (or data issues), journeys successfully to the destination.
In the case of your old ERP and ensuring the vitality of its data as your new ERP goes live, doing so is a great deal like making the shuttle bus stop at a convention center. At the shuttle bus stop, you likely have more passengers than you have places for them, so you order more buses and try to coerce people into positions they don’t want (standing, tight seating, etc..). No consideration for the uniqueness of the rider/data, just pegs (whether they are round or square) in holes.
In short, I would say that any former ERP data has a great deal of value, forcing it into the wrong shape (or having to leave some of it behind) erodes insight and shouldn’t be taken lightly.
The better data management approaches support acquiring data, blending the information to support contiguous (historical and current) views of business processes but allowing for a sustained view of the data in its original form.
One solution: “You can have whatever color and shape you want, as long as it is a black box.
One solution that has been bandied about by vendors to solve blending data from multiple ERPs (i.e. your old one and your new one) is a Common Data Model to provide the “it doesn’t matter where it came from” answer or the “Look, our apps are integrated!” message.
It is inherently good when vendors take steps to integrate their applications, most notably Dynamics 365. The delivery of a Common Data Model and Common Data Service engenders the use of the application and its processes as a means of integration. Not domain to this post, Microsoft is doing some very compelling things beyond products like Power BI to drive complex workflows.
However, the extensibility of the model (particularly loading of data into custom entities) is in no way technically complete or non-trivial. In my view, this leaves data from other systems at risk and waters down where the actual true data lies.
So, I am not saying anything done in a Dynamics 365 only context is wrong, but these technologies don’t accommodate the variety of shaped/sized data from multiple sources the organization often needs.
One look at the technical investments you’d make and the shortcomings you might still find, and you’ll possibly be considering moving on from the color “black” and the shape of a “box”…
About the author:
Trey Johnson is ZAP’s Chief Evangelist. Based out of Jacksonville, Florida, he joined the company in 2008 bringing experience from leading various boutique BI software and national consulting companies. A published author, speaker, and consultant, Trey sat on the PASS Board of Directors over multiple terms, concluding as their Executive Vice President. He was a long-term member of Microsoft’s BI Partner Advisory Council and has spent the last 25 years delivering business intelligence, data warehousing, and data management solutions to businesses of all shapes, sizes and “data challenges.” Follow Trey on Twitter and LinkedIn.