Forum Discussion

CeeVee33's avatar
CeeVee33
Icon for Advocate II rankAdvocate II
1 day ago
Solved

Generic 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'...
  • v-csrikanth's avatar
    1 day ago

    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.

    Best Regards,
    C Srikanth
    Community Support Team