Forum Discussion
Advocate IIGeneric Data Capability Question
Hi Experts - reaching out for some generic advice. I did not find any other forum to post this question.
I've recently joined a company which do not have a formalised data and analytics function. I've been brought in to establish it. They have been in the business for about 10 years and had pockets of people preparing regulatory related reporting using Excel. No engineering function, no BI function and no Insights generation.
My question is straight forward, and this has come after few comments by colleagues who think they know data analytics but they .... don't.
How should I go about establishing the capability that will enable and unlock the power of data (considering money, resources are not an issue)? And why?
Options in the debate with these people are -
- Do a big bang and establish a wider Enterprise Data Model that will cater for any and all reporting and analytics need.
- Pick high-value reporting use cases and build the EDM piece by piece.
What are your thoughts?
1 Reply
- v-csrikanth
Community Support
Hi CeeVee33
Thanks for sharing this, and no need to apologise for posting it here. It's a fair question and one that comes up regularly.
My short answer is Option 2, but with the shared foundations agreed up front.
I would not recommend the big-bang model. Starting from almost nothing, it's very easy to spend a year or more designing around assumptions about the business and the source systems. Requirements will move while you build, and you'll have little to show the business in the meantime. With no existing BI function behind you, that's a difficult position to hold.
At the same time, I wouldn't build each use case in isolation. That tends to produce duplicated pipelines, conflicting definitions and disconnected models, which is close to the Excel situation you already have, just on a newer platform.
The middle ground works better. Spend a short period agreeing the things that are expensive to change later: key business definitions, common dimensions, modelling standards, data ownership and platform direction. Keep it to weeks rather than months. Then deliver one business area at a time, with each delivery extending the shared model rather than working around it.
A useful way to think about this is Kimball's enterprise data warehouse bus matrix, which sets out business processes alongside the dimensions they share. Their guidance favours building in manageable increments rather than attempting, in their words, "a galactic Big Bang approach."
One other thought. You mentioned money and resources aren't a constraint, but in my experience budget is rarely the limiting factor. The harder problems tend to be data quality in the source systems, agreement on definitions, and whether the business trusts and adopts what you produce. Those take time rather than money.
On your regulatory reporting, that's where your credibility will be won, but also where mistakes are least forgiving. I'd start with something visible and genuinely painful today rather than your most critical report, and move the higher-risk work across once the process has proven itself. Regulatory work also needs lineage, auditability and clear sign-off, so it's worth building those in from the start.
- Kimball Group — Enterprise Data Warehouse Bus Architecture
- Kimball Group — DW/BI Lifecycle Methodology
- Microsoft Fabric adoption roadmap
Best Regards,
C Srikanth
Community Support Team
