ZAP Data Hub’s pre-built reporting solutions are the fastest, most cost-effective way to get accurate, trusted reporting from the most widely used ERP, CRM, and finance systems.
Get in touch
June 8, 2018
By Trey Johnson
No comments yet
If you’re looking to bring together data from multiple sources while having the freedom to use existing tools to present that information, here are my top 10 tips – writes ZAP’s tech evangelist, Trey Johnson…
1. 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 across these multiple sources.
2. Don’t feel you have to accept turning off or turning away historical data if you don’t want to.
3. Remember, few vendors understand their competitors’ data and likely cannot easily accommodate it.
4. Migrating data into a new application is a VERY expensive project line item.
5. Migrating data into a Common Data Model can also be expensive with unknown TCO.
6. Change is less disruptive if you can empower users to consume data with tools you already own, or that they are already using.
7. Make sure you know who is going to use any new data management technologies you select before you start to implement.
8. The more approachable the technology, even data management, the more choices you have as to who on your team will own it.
9. Data Management often outlives your individual business application choices!
10. If something sounds too good to be true, ask your prospective vendor to prove it…
“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?
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.
For these reasons, in this blog explore how you might consider making data management for your ERP/CRM data compelling and approachable.
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 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.
If part of an organization’s data management strategy is to get to the point where information is consistently yet voraciously consumed, you’ve got to help users optimize the visualization tools they are most familiar with, and give them a robust underlying data platform to get there.
While you are thinking about the end users, don’t forget about the data management platform owners, too. There are no “ownerless” data management technologies, especially with multiple data sources. Knowing who’s going to own it goes a long way to making the right (not hype-driven) decisions.
Well, if your vendor’s answer to supporting analyses or reporting with a data platform is to suggest you should Bring Your Own Database (BYOD), that might feel as lame as a Bring Your Own Beer/Bottle (BYOB) party invite. The acronyms are similar and have similar implications. IE the vendor isn’t going to take much responsibility for the outcome. They’ll provide aspects of the infrastructure, but that’s it.
The larger challenge with a BYOD option is you’re having to, in a very “up to your elbows” way, get technically dirty prescribing what gets exported from the application into your database. Yes, you’re starting with some very purposeful administrative ERP/CRM UI the vendor provides and choosing what data gets delivered to the database you brought.
Sadly, the result of this push isn’t a metadata-rich, reflection of what was exported but more like the underlying table names and fields, which can be harder to understand. Ever opened a CSV in Notepad or an Excel spreadsheet without column headers? Yep. That’s pretty much how it feels.
Some questions to consider with a vendor providing an export mechanism from their ERP/CRM platform:
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.
Your 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 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”…
One last thought, another movement I’ve encountered is the “I don’t want a graph/dashboard/visual” movement. Somewhat surprisingly, some vendors think the answer to solving this is to provide a new platform for delivering data management PLUS a toolset for consuming lists of data. It sure feels like a very narrow sweet spot and reminds me of an all-out revolution against all other tools and technologies.
A proper data management platform provides ALL the facilities for summary data supporting senior decision making AND operational insights at a much more granular level.
All without having to contemplate acquiring another tool which acquires data in its own way and makes lists appear on a hand-held device in a warehouse, on a sales call or anywhere in between.
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 Twitterand LinkedIn.
#DirectQuery | #Dynamics365EntityStore | #BYOD | #CommonDataModel | #CommonDataStore | #DataManagement framework | #DIXF | #Excel | #PowerBI | #Tableau #SSRS
Comments are closed.
All Rights Reserved