How the IBM Big Data and AI Maturity Model sharpens your strategy

Why bother with a maturity model

Leadership teams routinely disagree about how ready the organisation is for AI. Engineering thinks the data is a mess. Marketing thinks it is fine. The CFO wonders why nothing ships. Everyone is answering a different question, because nobody defined what "ready" means. A maturity model fixes that by giving everyone a shared scoring rubric, which is often the first useful outcome of the whole exercise — before a single project gets picked.

The IBM Big Data and AI Maturity Model covers five domains: business strategy, information, analytics, culture and execution, and architecture and governance. Each is scored from ad-hoc through to optimised. It was built for big data programmes rather than for generative AI specifically, but the domains still map cleanly onto the questions any AI initiative has to answer: do we know why we're doing this, is the data usable, can we build and run models, will people actually change how they work, and is the platform safe to build on.

What a good assessment produces

A useful assessment is not a score. A score on its own is a number nobody can act on. It is a set of concrete gaps and the investments that close them.

• Business strategy gaps usually point to missing ownership or unclear value hypotheses — nobody can say who is accountable for an AI initiative, or what "success" would look like in revenue or cost terms.
• Information gaps translate to data quality, cataloguing, or access programmes — the data exists, but nobody trusts it, or getting at it requires a ticket and a three-week wait.
• Analytics gaps show up as platform, MLOps, or skills investments — teams can build a proof of concept in a notebook but have no way to deploy, monitor, or retrain it.
• Culture and execution gaps are almost always change-management work: incentives, training, ways of working. This is the domain organisations most often skip, and the one that kills otherwise sound projects.
• Architecture and governance gaps become policy, security, and platform roadmap items — nobody has agreed who approves a model going into production, or what happens when it's wrong.

Worked example: a mid-sized retailer scores itself "defined" on business strategy (they have an AI steering group) but "ad-hoc" on information (product data lives in four systems with no shared key) and "initial" on culture and execution (store staff were never consulted about a forecasting tool that changes their ordering process). The honest read is not "we're not ready for AI." It's "we're ready to pilot something that doesn't depend on clean cross-system data, and we need to bring operations staff into design before we build anything that changes their job." That's a materially different, more useful, conclusion than a single average score would give you.

Pitfalls to watch for

• Self-scoring without evidence. Teams mark themselves "managed" because that's the comfortable middle. Ask for the artefact that proves the score — a data catalogue, a model registry, a training log — not just an opinion.
• Averaging domains into one number. A single "maturity score" hides exactly the information you need. A 3.5 out of 5 could mean five domains at 3.5, or one domain at 5 and one at 2. Only the second tells you where to invest.
• Scoring the org you wish you had. Assessments done by leadership alone tend to run optimistic. Include people who touch the data and the tooling daily.
• Treating the model as a checklist to complete. You don't need every domain at "optimised." Most organisations shouldn't try. Chasing uniform maturity wastes money on domains that don't matter for your chosen use cases.

How to use it in strategy work

1. Score each domain with a small cross-functional group, not a single team — include someone from data, someone from delivery, and someone who'll actually use the output.
2. Agree the target level per domain for the next 18 months. You do not need to be optimised everywhere; pick targets that match the use cases you actually intend to pursue.
3. Use the gap between current and target to size and prioritise foundational work, and cost it like any other programme of work, not as a footnote to a use-case business case.
4. Re-score annually. Momentum is the real signal — a static "managed" score three years running usually means the assessment has become theatre.

What the model will not do

A maturity model will not tell you which AI use cases to pick. It tells you which ones you can realistically deliver, and what you would need to build first to unlock the rest. It also won't tell you if a use case is worth doing commercially — that's a separate judgement about value and cost. Pair it with a business model canvas and a prioritised project list, and you have a strategy that stands up to scrutiny instead of one built on enthusiasm alone.

Where Florence helps

Florence's AI Readiness Assessment step scores your organisation across comparable domains and asks for the evidence behind each answer, not just a number. Insights then translates the gaps into plain-language findings, and Strategy and Projects turn those findings into a prioritised, sequenced set of initiatives — so the assessment feeds straight into what you build next, rather than sitting in a slide deck.