I’ve just begun on one of those “these don’t come around often enough for me” projects. I’m working with a customer that is a net new, SAP BusinessObjects customer. No SAP ERP. No SAP CRM. No SAP HANA (yet). Just pure analytics on agnostic data. We’re very early into this project. However, I feel like even just a few weeks into this relationship, there are key learnings everyone must carry forward to all of their analytics projects.
In the Beginning
/*Begin Shameless Plug from our 2014 SAP Press release, SAP BusinessObjects BI System Administration 2nd Edition available now!*/
In the beginning, man created the computer and the database. And the data was without form and void. And Bernard Liautaud said, “Let there be Business Objects.” And it was good.
/*End shameless plug */
Like every customer getting started, some data exists. Somewhere. It may be really good data. It may be really bad data. But, you have to start somewhere.
Your company has just bought SAP BusinessObjects. Somebody, wants to see some ROI on that yesterday, so, build a report fast! This is a hard trap to fall in to. In analytics, we have a tendency to bang out reports in ways we shouldn’t. I’m not going to dismiss that you have to make someone happy there. But you as a BI champion need to put out the fires and steer the ship in the right direction.
Piece by Piece
My friend, Timo, really drew this so-simple-its-stupid-but-really-cute-and-accurate-napkin-sketch that describes the big data iceberg. Oh, Timo. This picture doesn’t just describe big data. It describes any data. My case, in point.
My customer is rearing and ready to go with their new BI tool. They want reports. They will report on ANYTHING they can. But fundamentally, we spent DAYS figuring out how to get the data in a report-worthy format from a report-unfriendly source. The customer didn’t anticipate the need for what we’ll call “good” data that actually works in a report.
Good data, being well-formed, organized, documented, and relatable. Yes yes, needs of the business, pretty report, ROI. I get it. But with the fire drill “inaugural” report out-of-the-way, it’s time to get to basics. We’re going to build a data strategy while these next fire drill reports come around later.
We’re going to tackle basic business terms (and standardize them). We’re going organize and integrate disparate app’s data into a single documented and relatable data source. Call it a data mart. Call it a warehouse. Call it big data. I don’t care. I want to create an experience that makes it easy to consume and share these analytics. This will involve some sort of strategy that involves all those nifty concepts in the big data iceberg, a well thought semantic layer strategy, and cool BI.
In the end of the effort to build a nifty first report, it looks beautiful, but it is a hot mess to compile. That will improve in time. We took data that’d never been mashed up before, got it into a database, and exploited all the great things about Web Intelligence to make a guided experience through this analytic story aimed at improving health outcomes.
I absolutely adore this customer’s mission. It’s philanthropic in nature. They want to improve the quality of lives for millions of people. But they have the same problems in data and BI that any giant customer has. We’re going to tackle those problems with both an appropriate data strategy, as well as in creating beautiful BI. We’re going to chronicle that journey here, and hopefully not alongside the other ill-fated blog series I’ve started and never finished in the past. Wish us luck.
3 thoughts on “Getting Started in Analytics”