Assessment Input Report

Acme Retail Group · generated 11/2/2026, 10:15:02 AM

Maturity per dimension (weighted)

Data StrategyAs-Is 2.3 · To-Be 3.7 · gap 1.4

Data GovernanceAs-Is 2.4 · To-Be 3.6 · gap 1.1

ArchitectureAs-Is 2.3 · To-Be 3.6 · gap 1.3

Data QualityAs-Is 2.3 · To-Be 3.4 · gap 1.1

MetadataAs-Is 2.2 · To-Be 3.4 · gap 1.2

Data AnalyticsAs-Is 2.5 · To-Be 3.5 · gap 1.0

IntelligenceAs-Is 2.3 · To-Be 3.6 · gap 1.2

Data CultureAs-Is 2.8 · To-Be 3.9 · gap 1.2

Scores

Dimension	As-Is	To-Be	Gap	Coverage
Data Strategy	2.32	3.72	1.40	69%
Data Governance	2.44	3.57	1.12	58%
Architecture	2.34	3.61	1.27	53%
Data Quality	2.32	3.44	1.12	58%
Metadata	2.19	3.39	1.21	57%
Data Analytics	2.48	3.46	0.98	66%
Intelligence	2.33	3.58	1.25	47%
Data Culture	2.76	3.94	1.18	50%

Summaries by role

Chief Data Officer — Dana Voss

Justifications

Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.
Observed during the Data Maturity review of the Chief Data Officer domain.

Good practices

Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.

Proposed improvements

Formalise ownership and add a monthly review of STR-01.
Formalise ownership and add a monthly review of STR-02.
Formalise ownership and add a monthly review of STR-03.
Formalise ownership and add a monthly review of STR-04.
Formalise ownership and add a monthly review of GOV-01.
Formalise ownership and add a monthly review of GOV-02.
Formalise ownership and add a monthly review of GOV-03.
Formalise ownership and add a monthly review of GOV-04.
Formalise ownership and add a monthly review of ARC-01.
Formalise ownership and add a monthly review of ARC-02.
Formalise ownership and add a monthly review of DQT-01.
Formalise ownership and add a monthly review of DQT-02.
Formalise ownership and add a monthly review of DQT-03.
Formalise ownership and add a monthly review of MDT-01.
Formalise ownership and add a monthly review of MDT-02.
Formalise ownership and add a monthly review of DST-01.
Formalise ownership and add a monthly review of DST-02.
Formalise ownership and add a monthly review of DST-03.
Formalise ownership and add a monthly review of INT-01.
Formalise ownership and add a monthly review of INT-02.
Formalise ownership and add a monthly review of INT-03.
Formalise ownership and add a monthly review of INT-04.
Formalise ownership and add a monthly review of CUL-01.
Formalise ownership and add a monthly review of CUL-02.
Formalise ownership and add a monthly review of CUL-03.

Business benefits

Fewer rework cycles and clearer accountability for STR-01.
Fewer rework cycles and clearer accountability for STR-02.
Fewer rework cycles and clearer accountability for STR-03.
Fewer rework cycles and clearer accountability for STR-04.
Fewer rework cycles and clearer accountability for GOV-01.
Fewer rework cycles and clearer accountability for GOV-02.
Fewer rework cycles and clearer accountability for GOV-03.
Fewer rework cycles and clearer accountability for GOV-04.
Fewer rework cycles and clearer accountability for ARC-01.
Fewer rework cycles and clearer accountability for ARC-02.
Fewer rework cycles and clearer accountability for DQT-01.
Fewer rework cycles and clearer accountability for DQT-02.
Fewer rework cycles and clearer accountability for DQT-03.
Fewer rework cycles and clearer accountability for MDT-01.
Fewer rework cycles and clearer accountability for MDT-02.
Fewer rework cycles and clearer accountability for DST-01.
Fewer rework cycles and clearer accountability for DST-02.
Fewer rework cycles and clearer accountability for DST-03.
Fewer rework cycles and clearer accountability for INT-01.
Fewer rework cycles and clearer accountability for INT-02.
Fewer rework cycles and clearer accountability for INT-03.
Fewer rework cycles and clearer accountability for INT-04.
Fewer rework cycles and clearer accountability for CUL-01.
Fewer rework cycles and clearer accountability for CUL-02.
Fewer rework cycles and clearer accountability for CUL-03.

Data Steward — Marta Klein, Vladimir Videnovic

Justifications

Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.
Observed during the Data Maturity review of the Data Steward domain.

Good practices

Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.

Proposed improvements

Formalise ownership and add a monthly review of STR-04.
Formalise ownership and add a monthly review of STR-06.
Formalise ownership and add a monthly review of STR-07.
Formalise ownership and add a monthly review of GOV-01.
Formalise ownership and add a monthly review of GOV-02.
Formalise ownership and add a monthly review of GOV-03.
Formalise ownership and add a monthly review of ARC-01.
Formalise ownership and add a monthly review of ARC-02.
Formalise ownership and add a monthly review of ARC-03.
Formalise ownership and add a monthly review of DQT-01.
Formalise ownership and add a monthly review of DQT-03.
Formalise ownership and add a monthly review of DQT-05.
Formalise ownership and add a monthly review of MDT-01.
Formalise ownership and add a monthly review of MDT-02.
Formalise ownership and add a monthly review of MDT-03.
Formalise ownership and add a monthly review of DST-01.
Formalise ownership and add a monthly review of DST-02.
Formalise ownership and add a monthly review of DST-05.
Formalise ownership and add a monthly review of INT-01.
Formalise ownership and add a monthly review of INT-04.
Formalise ownership and add a monthly review of INT-05.
Formalise ownership and add a monthly review of CUL-02.
Formalise ownership and add a monthly review of CUL-03.
Formalise ownership and add a monthly review of CUL-05.

Business benefits

Fewer rework cycles and clearer accountability for STR-04.
Fewer rework cycles and clearer accountability for STR-06.
Fewer rework cycles and clearer accountability for STR-07.
Fewer rework cycles and clearer accountability for GOV-01.
Fewer rework cycles and clearer accountability for GOV-02.
Fewer rework cycles and clearer accountability for GOV-03.
Fewer rework cycles and clearer accountability for ARC-01.
Fewer rework cycles and clearer accountability for ARC-02.
Fewer rework cycles and clearer accountability for ARC-03.
Fewer rework cycles and clearer accountability for DQT-01.
Fewer rework cycles and clearer accountability for DQT-03.
Fewer rework cycles and clearer accountability for DQT-05.
Fewer rework cycles and clearer accountability for MDT-01.
Fewer rework cycles and clearer accountability for MDT-02.
Fewer rework cycles and clearer accountability for MDT-03.
Fewer rework cycles and clearer accountability for DST-01.
Fewer rework cycles and clearer accountability for DST-02.
Fewer rework cycles and clearer accountability for DST-05.
Fewer rework cycles and clearer accountability for INT-01.
Fewer rework cycles and clearer accountability for INT-04.
Fewer rework cycles and clearer accountability for INT-05.
Fewer rework cycles and clearer accountability for CUL-02.
Fewer rework cycles and clearer accountability for CUL-03.
Fewer rework cycles and clearer accountability for CUL-05.

Data Engineer — Ivan Petrov, Svetislav Videnovic, Neil Britliff, Anna Videnovic, Darryn Hinett

Justifications

Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
Observed during the Data Maturity review of the Data Engineer domain.
My backlog as a pipeline engineer for the Customer & Loyalty domain is driven almost entirely by whichever country's incident or request is loudest that week, not by any documented mapping to the group's digital-revenue strategic goals. I've never seen a prioritisation framework that would let me push back on a low-value urgent request in favour of a higher-value strategic one.
This is the first time my domain's engineering practices have gone through a structured maturity assessment; a platform health review was done 18 months ago but it looked only at uptime and performance metrics, not data maturity or governance gaps, and nothing from it was tracked as an ongoing plan.
There's no strategic direction telling me, as the engineer building the pipelines, which Customer & Loyalty datasets are actually approved for use in AI/GenAI initiatives; when the recommendation-engine pilot needed a training extract, I built the pipeline on request with no reference to any stated constraint.
No AI-readiness assessment has been performed on the domain's data before I built extraction pipelines for the recommendation and chatbot pilots; I pulled the raw CRM tables as instructed with no check for representativeness, staleness, or embedded PII built into the pipeline itself.
Group data handling and classification policy exists as a document, but as the person actually building ingestion pipelines, I apply classification largely through habit and convention rather than any policy reference; there's no automated check in my pipelines that would catch a misclassified field before it lands in the data lake.
Access provisioning for the systems I build and operate is technically ticketed, but the actual grant is often a manual step I or a colleague performs directly in the cloud console, with no automated tie-back to the approval record, meaning the audit trail depends on people remembering to log it correctly.
When a governance issue surfaces in a pipeline I operate — like an access anomaly or a policy-breaching data flow — I typically discover and fix it myself quietly, because there's no defined escalation path telling me who to notify or how to log it formally.
No data contracts exist that I'm aware of for the domain's datasets; when I build a pipeline feeding another team's system, the interface is agreed informally over a chat message about field names, with nothing specifying obligations, permitted uses, or what happens if the source schema changes.
General governance policy predates GenAI and says nothing about how it applies to the pipelines I build for AI initiatives; I built the chatbot's retrieval pipeline with no policy reference telling me what constraints, if any, should apply differently from a normal reporting pipeline.
AI pipelines and models requesting access to domain data go through the same access request process as any other system, and as the engineer provisioning that access, I have no distinct review step to apply extra scrutiny to what an AI system will actually do with the data once it has it.
I have no monitoring built into the pipelines feeding the AI pilots that would detect misuse, scope creep, or data leakage into outputs; once data leaves my pipeline and enters the AI system, I have no further visibility into what happens to it.
Group architecture standards for schema design exist, and I generally try to follow them for new pipeline builds, but there's no automated conformance check in my CI/CD process, so whether a given schema actually conforms depends entirely on my own diligence and a colleague's review, if one happens.
New integrations I build for the CDP consistently use the group's defined API pattern because that's genuinely the easiest path with the tooling available, but several legacy on-prem country feeds I maintain still use point-to-point file transfers with inconsistent formats that predate any integration standard.
Schema and lineage documentation for the CDP is captured automatically in the group's data catalogue as part of the platform's CI/CD process, but for legacy on-prem pipelines I maintain, lineage exists only in my own head and in comments scattered through old integration scripts.
I've never been asked to formally assess whether the storage tier I place data in actually matches its usage pattern; the loyalty transaction archive sits in an expensive on-prem database purely because that's where it was originally built, and I've never had the mandate or the data to justify moving it.
When I hit an architecture constraint — like the on-prem CRM's inability to support real-time loyalty updates the mobile app needs — I build a workaround (in this case, batch updates) and move on, because there's no defined channel for that kind of technical debt to reach the enterprise architecture roadmap.
The pipelines I build support only traditional relational structures; when the recommendation pilot needed a vector store, I built one myself as a one-off outside standard architecture because no approved AI-native storage pattern existed for me to build against.
I built the chatbot's data connection as a direct database query because it was the fastest way to get the pilot working, bypassing the CDP's standard API entirely; there's no defined integration standard telling me AI pipelines should go through the managed layer instead.
I don't build any lineage tracking into the pipelines feeding the AI pilots; if the chatbot produced a response referencing customer data, I currently have no reliable way to trace which specific pipeline run or data extract fed the model that produced it.
I've built automated validation rules into the CDP ingestion pipeline covering the core customer fields, but the legacy CRM pipelines I also maintain have no equivalent rules at all — whatever comes through the feed loads as-is, with quality expectations existing only informally in my head.
The CDP pipeline runs an automated profiling job on every ingest that I built and maintain, which reliably catches malformed records before they reach downstream consumers; the legacy CRM feeds have no equivalent automation, and I check them manually only when I remember to or when something else prompts me.
For the CDP, I've built and maintain a documented remediation script that automatically corrects common issue types like malformed emails and duplicate loyalty IDs; for legacy CRM issues, I fix things manually and inconsistently, often editing records directly with no record of what I changed or why.
I built a basic quality metrics dashboard for the CDP that reports completeness and validity monthly, but I have no equivalent measurement for the loyalty ledger or legacy CRM pipelines — their condition is essentially unknown to me between the periodic disputes that surface a problem.
I've fixed the recurring loyalty-ID mismatch between the app and in-store POS manually more times than I can count over the past year, always at the symptom level, because I've never had the time allocated to properly investigate why it keeps happening.
No documented tolerance threshold exists for how much imperfection the domain's downstream processes can actually absorb; I apply roughly equal urgency to every quality issue I encounter, regardless of whether it materially affects campaign targeting or loyalty point calculation.
No AI-specific quality standard exists for data I extract for AI pipelines; I built the recommendation pilot's training extract using the same general completeness rules I'd apply to any reporting pipeline, with no additional check for representativeness or staleness relevant to AI use.
I don't have any validation gate built into the pipelines feeding the AI pilots; data flows straight from source through my extraction pipeline into the AI system with no checkpoint in between.
When the chatbot produces an odd or outdated response, I have no built-in way to trace whether that traces back to stale or incomplete data in my pipeline; these issues get treated purely as a model or prompting problem, and I'm rarely even looped in to check.
Technical metadata for the CDP's schema is auto-generated into the group catalogue as part of my CI/CD pipeline, which I'm genuinely proud of; the legacy CRM schemas I also maintain have no such automation, and their documentation exists only as outdated comments in old integration scripts.
There's no domain-wide naming standard I'm required to follow; I've named fields in the pipelines I've built based on what made sense to me at the time, and I know this means the same concept (loyalty tier) is named differently across the CDP, the loyalty engine, and legacy CRM systems.
Metadata for the CDP's priority datasets is published in the group catalogue and I rely on it myself day to day; metadata for the legacy CRM and loyalty ledger pipelines I maintain exists only in scattered personal notes that a new team member would have no way to find.
Metadata I write, where it exists at all, tends to go stale after initial creation; several catalogue entries for legacy CRM fields haven't been updated since I made a schema change that made them inaccurate, and I have no scheduled process reminding me to check.
No AI-specific metadata standard exists for me to apply when building extraction pipelines for AI initiatives; the data I pulled for the recommendation pilot carries only standard technical metadata, with nothing documenting provenance, licensing, or known representativeness limitations.
There's no metadata completeness checkpoint built into any pipeline I've built for AI use; both the chatbot and recommendation pilots' data pipelines run with no check on whether provenance, licensing, or sensitivity classification metadata is even present before the data is used.
When the chatbot has misinterpreted or retrieved the wrong customer data, whether unclear metadata in my pipeline's output contributed has never been investigated with me; these issues get treated purely as a model or prompting problem without looping back to the data source.
Dashboards built on the CDP data I maintain generally use calculation logic I've validated with the digital marketing team, but I have no visibility into or control over how country-level report builders interpret or recalculate the raw data I expose, so discrepancies can and do appear downstream without my knowledge.
The CDP's data catalogue entries I generate automatically do include basic lineage, so a technically-minded viewer could trace a metric back to source if they know to look; but most business-facing dashboards don't actually surface that lineage information to the end user viewing the chart.
When a business user spots something wrong in a dashboard built on my data, there's no defined route for that observation to reach me as the pipeline owner; issues get raised informally to whoever the business user happens to know, and I often only hear about a data problem well after the fact, if at all.
I've built and maintain the data pipeline feeding a basic churn-propensity model used by three country marketing teams, so I know the domain's data can support predictive analytics — but I've had no mandate or time allocated to extend that pipeline to the other nine markets.
The recommendation-engine pilot is the only Decision Intelligence capability I've built a pipeline for, and it remains experimental; the data pipeline I maintain for it feeds a limited A/B test rather than any real operational decisioning system trusted across the business.
I have no defined role in the AI model lifecycle for models consuming data I pipeline; I got involved in the recommendation pilot's data selection stage only because I proactively asked to be included, not because it was expected of my role.
I have no visibility into how the fields I pipeline into the recommendation model actually influence its outputs; if a country marketing lead asked me why the model favoured certain products, I genuinely couldn't answer beyond describing what data goes in.
No formal bias assessment has been run on the data I extract for AI models; the representativeness skew toward the three most digitally mature countries in the recommendation pipeline's training data has been informally suspected by me but never formally documented or acted on.
I have no confirmation of whether the pipelines I've built for the recommendation or chatbot pilots have actually gone through any formal model governance review; I built what was asked of me with no governance checkpoint built into my own delivery process.
No sign-off checkpoint exists in my pipeline delivery process confirming AI-readiness before I hand training data to the data science team; the recommendation model's known representativeness gap was never confirmed or mitigated at that point because no such checkpoint existed in my workflow.
No validation checkpoint in my pipeline confirms production data feeding the recommendation model remains consistent with training-time assumptions before go-live; the model moved to a limited production trial with no data-consistency check built into my deployment process.
No ongoing monitoring in my pipeline links the recommendation model's live performance back to potential bias or drift in the underlying data I supply; any degradation in the data I feed would only be discovered if someone else noticed the model's outputs had degraded.
For priority pipeline decisions — like which integration to prioritise — I do generally pull usage or incident data to support my case, but I've also seen decisions about which legacy system to decommission made on management precedent with no reference to any actual usage data I could easily have provided.
I have a good working relationship with the digital marketing lead who consumes the CDP data I pipeline, and we regularly discuss what's actually needed before I build anything — but with country-level business teams outside that relationship, interaction is much more transactional, request-and-deliver with limited shared understanding.
I have access to the general L&D catalogue and have completed a couple of relevant courses, but there's no development pathway specific to a Data Engineer at my level, and the AI/ML pipeline skills I've had to pick up to support the recommendation and chatbot pilots have been entirely self-taught in my own time.

Good practices

Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
The platform team's sprint planning does at least tag tickets with a rough business-value label, which gives some informal signal of priority even without a real strategic linkage.
Running this DataPulse assessment at all is a genuine step forward, and the platform team has committed to treating its findings as a tracked backlog rather than a one-off exercise.
IT Security's general 'no PII into public GenAI tools' notice is at least something concrete I can point to, even though it says nothing about which internal datasets are appropriate for approved internal AI pipelines.
A separate CRM consolidation project has started a completeness and accuracy review of the core customer master, which gives me a useful reference point I can eventually build AI-readiness checks against.
For the CDP ingestion pipeline specifically, a schema-validation step I built does enforce basic field-type conformance, which happens to catch some classification issues as a side effect even though that wasn't its original purpose.
The CDP's IAM roles are reasonably well-structured and role-based, which makes granting access to that specific platform faster and more consistent than the legacy on-prem systems.
IT Security does run a general incident queue that I've used once for a security-adjacent issue, giving at least a starting point for where this kind of report could plausibly go.
For the CDP's outbound API, the platform team has at least published an OpenAPI spec, which functions as a de facto informal contract even though it was never framed as one.
IT Security's general PII notice for public GenAI tools gives at least a baseline assumption I can apply, even though it wasn't written with internal pipeline engineering in mind.
The recommendation pilot's access ticket did at least name 'model training' as the intended use, which is more context than most requests give me, even without a distinct AI review process to act on it.
The platform team's general pipeline monitoring dashboard does track data volumes and latency for the AI-feeding pipelines, which is a foundation I could extend to cover usage-pattern anomalies.
The CDP schema I built with the platform architect's input does genuinely conform to the documented conventions, and I use it as my own personal reference when starting new work.
The CDP's API-based integration pattern is well-documented and I can build a new conformant connection to it in a day or two, which is a real productivity advantage over the legacy approach.
The CDP's automated catalogue integration is genuinely reliable — schema changes I push are reflected in the catalogue within minutes, with no manual documentation effort on my part.
The CDP's storage tiering was deliberately designed around actual query patterns when I built it, so that specific dataset is already genuinely fit-for-purpose.
I did once raise the real-time update limitation informally to an enterprise architect during a project planning session, and they seemed genuinely interested, which is the first time this kind of feedback reached anyone with roadmap influence.
The group's central platform team has an approved vector store product under evaluation, which I'm hoping to migrate my one-off implementation onto once it's approved, rather than continuing to maintain something outside standard architecture.
I'm aware the CDP's standard API could technically serve the chatbot's needs instead of the direct connection I built, and migrating it is genuinely on my own backlog even without anyone formally requiring it.
I did informally note in the pilot's build documentation which source tables the initial training pipeline pulled from, which is more than exists for most of my other pipeline work but still isn't real lineage tracking.
The CDP pipeline's validation rules (completeness and format checks on email, consent status, loyalty ID) are genuinely solid and catch a meaningful share of malformed records before they load.
The CDP's automated profiling job has genuinely proven itself — it caught a malformed batch just last month before it could reach a campaign audience, exactly as designed.
The CDP's remediation script has measurably reduced the backlog of malformed records I used to have to fix by hand, and it's the piece of automation I'm most proud of building.
The CDP's monthly metrics dashboard is something I built on my own initiative and the digital marketing lead has come to genuinely rely on it for planning campaign timing.
I do have an informal hypothesis that the mismatch stems from a timing issue in the nightly POS sync, based on pattern recognition from fixing it so many times, even though I've never formally tested it.
Digital marketing has informally told me minor address-field gaps rarely affect campaign performance, which is useful context I've started applying even without any formal, tested threshold behind it.
I've had an informal conversation with the data scientist on the recommendation pilot about representativeness concerns, which gives me a starting point for building a proper check even though nothing is documented yet.
I've occasionally spot-checked a training extract manually before handing it off to the data science team, which is more diligence than the pipeline itself formally requires of me.
The AI Centre of Excellence's conversation-sample review, introduced for quality purposes, could plausibly be extended to loop me in as the pipeline owner when a data cause is suspected, even though it doesn't currently do this.
The CDP's automated schema documentation is reliable and current by design — I don't have to remember to update it, because it updates itself whenever I push a schema change.
For new fields I build in the CDP, I do try to loosely follow the group naming convention where I'm aware of it, even without anything formally requiring me to.
The CDP catalogue entries are genuinely searchable and I use them regularly myself, which is a real productivity benefit compared to how I have to work with the legacy systems.
The CDP's auto-generated metadata does stay current by design, since it updates automatically whenever I change the schema, which is a genuine strength I'd like to replicate elsewhere.
I've informally noted in the pilot's build documentation which source tables the pipeline pulls from, which is a starting point I could formalise into a proper AI metadata template with modest additional effort.
IT Security's general PII guidance functions as a loose informal check that at least prompts me to think about sensitivity, even without a formal metadata gate built into my pipeline logic.
The AI Centre of Excellence's conversation-sample review provides a natural place to loop me in as the pipeline owner when a metadata gap is suspected, even though it doesn't currently do this.
The CDP's data model was designed collaboratively with the BI team, so the core metrics built on it stay well-aligned with agreed definitions by construction rather than by luck.
The lineage I build into the CDP catalogue is technically complete and accurate — the gap is entirely in whether it's surfaced to viewers, not whether it exists.
On the few occasions an issue has reached me directly, I've generally been able to trace and fix the root cause quickly, which suggests the gap is in routing, not in my ability to respond once informed.
The churn model's pipeline is something I actively maintain and monitor, and the three countries using it treat it as a trusted, reliable input to retention campaign planning.
The recommendation pipeline has fed a limited A/B test that showed a measurable uplift, which gives me confidence the underlying data pipeline is solid enough to support wider adoption if the business chooses to scale it.
On the recommendation pilot, being included at the data-selection stage let me flag a data quality concern the data scientist hadn't spotted, which both of us found genuinely useful.
The data scientist on the recommendation pilot has produced an informal feature-importance summary for their own debugging, which I've seen and which could be formalised into something I could reference when questions come my way.
I raised the representativeness concern informally in a project retrospective, which is documented somewhere even though no formal assessment process picked it up and ran with it.
The AI Centre of Excellence has indicated the recommendation pilot is on its radar for formal risk classification, which suggests coverage is achievable even though it hasn't happened yet.
Now that the representativeness gap has been informally raised, the data science team has shown genuine willingness to involve me earlier in reviewing data before any next model iteration begins training.
The platform team's basic uptime and latency monitoring is a foundation I could extend to include a data-consistency validation step, since the infrastructure to build on already exists.
The A/B test framework already used to evaluate the recommendation pilot's uplift could plausibly be extended by me to monitor for data drift over time, even though it doesn't currently do so.
My own habit of bringing incident and usage data to sprint planning discussions has genuinely shaped how my immediate team prioritises pipeline work, and I've come to see this as good practice worth spreading.
The scoping conversations I have with the digital marketing lead before building anything consistently produce pipelines that actually meet the need the first time, which is a real contrast to how requests from other business areas tend to go.
My manager has been supportive of time spent on ad hoc external courses when I've specifically requested it, which shows organisational willingness even without a formal pathway to guide it.

Proposed improvements

Formalise ownership and add a monthly review of STR-01.
Formalise ownership and add a monthly review of STR-02.
Formalise ownership and add a monthly review of STR-03.
Formalise ownership and add a monthly review of STR-04.
Formalise ownership and add a monthly review of GOV-01.
Formalise ownership and add a monthly review of GOV-02.
Formalise ownership and add a monthly review of GOV-03.
Formalise ownership and add a monthly review of GOV-04.
Formalise ownership and add a monthly review of GOV-05.
Formalise ownership and add a monthly review of GOV-06.
Formalise ownership and add a monthly review of GOV-07.
Formalise ownership and add a monthly review of ARC-01.
Formalise ownership and add a monthly review of ARC-02.
Formalise ownership and add a monthly review of ARC-03.
Formalise ownership and add a monthly review of ARC-04.
Formalise ownership and add a monthly review of ARC-05.
Formalise ownership and add a monthly review of ARC-06.
Formalise ownership and add a monthly review of ARC-07.
Formalise ownership and add a monthly review of ARC-08.
Formalise ownership and add a monthly review of DQT-01.
Formalise ownership and add a monthly review of DQT-02.
Formalise ownership and add a monthly review of DQT-03.
Formalise ownership and add a monthly review of DQT-04.
Formalise ownership and add a monthly review of DQT-05.
Formalise ownership and add a monthly review of DQT-06.
Formalise ownership and add a monthly review of DQT-07.
Formalise ownership and add a monthly review of DQT-08.
Formalise ownership and add a monthly review of DQT-09.
Formalise ownership and add a monthly review of MDT-01.
Formalise ownership and add a monthly review of MDT-02.
Formalise ownership and add a monthly review of MDT-03.
Formalise ownership and add a monthly review of MDT-04.
Formalise ownership and add a monthly review of MDT-05.
Formalise ownership and add a monthly review of MDT-06.
Formalise ownership and add a monthly review of MDT-07.
Formalise ownership and add a monthly review of DST-01.
Formalise ownership and add a monthly review of DST-02.
Formalise ownership and add a monthly review of DST-03.
Formalise ownership and add a monthly review of INT-01.
Formalise ownership and add a monthly review of INT-02.
Formalise ownership and add a monthly review of INT-03.
Formalise ownership and add a monthly review of INT-04.
Formalise ownership and add a monthly review of INT-05.
Formalise ownership and add a monthly review of INT-06.
Formalise ownership and add a monthly review of INT-07.
Formalise ownership and add a monthly review of INT-08.
Formalise ownership and add a monthly review of INT-09.
Formalise ownership and add a monthly review of CUL-01.
Formalise ownership and add a monthly review of CUL-02.
Formalise ownership and add a monthly review of CUL-03.
Introduce a lightweight prioritisation scorecard that engineering leads can use to weigh incoming requests against the digital-revenue strategy, so backlog decisions aren't purely urgency-driven.
Turn this assessment's findings into a tracked engineering improvement backlog with named owners and sprint-level checkpoints, and commit to re-running the assessment annually.
Work with the AI Governance function to get a dataset-level AI-use classification for the domain, so pipeline builds like the chatbot extract can be scoped correctly from the start rather than defaulting to 'everything'.
Build a reusable AI-readiness validation step (completeness, currency, PII-flagging) into the pipeline framework, so any future AI-feeding pipeline runs the check automatically rather than relying on manual review.
Extend the CDP's schema-validation pattern into a proper classification check across all domain ingestion pipelines, flagging unclassified sensitive fields before they load.
Automate the tie between the ticketing system and the actual access-grant step, so provisioning can't happen without a recorded, approved request behind it.
Establish a named escalation path specifically for pipeline-level governance issues, with a required incident record whenever a fix like the masking bug touches data exposure.
Formalise data contracts for the domain's key interfaces, starting with the CDP API's existing OpenAPI spec as a template, and require contract review before breaking schema changes.
Get an explicit AI-specific policy addendum covering pipeline-level rules (training vs. retrieval vs. agentic access) from the AI Governance function, so engineering doesn't have to guess at appropriate constraints.
Build a distinct AI/pipeline access request template that captures intended use and required scope, so engineering has a structured basis to provision narrower, purpose-appropriate access.
Extend the existing pipeline monitoring dashboard to include basic usage-pattern checks for AI-feeding data flows, flagging access or volume patterns outside expected norms.
Add automated schema-conformance validation to the CI/CD pipeline for new and changed data structures, using the CDP schema as the reference implementation.
Prioritise migrating the highest-risk legacy file-transfer integrations onto the CDP's standard API pattern, starting with the POS feed that caused the matching failure.
Extend the CDP's automated catalogue integration pattern to the highest-priority legacy pipelines before further decommissioning removes my own memory of how they work.
Get a proper storage placement review commissioned for the loyalty archive as part of the hybrid cloud migration roadmap, using the access-frequency data the platform already logs.
Use the informal conversation with the enterprise architect as the basis to formally log the real-time update limitation as a technical debt item with the app-complaint evidence attached.
Adopt the group's evaluated vector store platform for the domain's embedding pipelines as soon as it's approved, and migrate the pilot's one-off implementation onto it.
Migrate the chatbot pipeline onto the CDP's standard API, and establish this pattern as the required approach for any future AI/ML pipeline connecting to domain data.
Extend the CDP's automated lineage capture to cover AI-feeding pipelines specifically, recording which extract version fed which model training or retrieval run.
Extend the CDP's validation rule pattern to the loyalty ledger pipeline as a priority, given it directly drives customer-facing balances.
Extend the CDP's automated profiling pattern to the legacy CRM feeds where technically feasible, replacing my own memory as the trigger for quality checks.
Build a documented, scripted remediation procedure for the most common legacy CRM issue types, modelled on the CDP script, and log every fix with a resolution record.
Extend the CDP dashboard's metric set and reporting cadence to the loyalty ledger pipeline, starting with completeness and accuracy of the fields driving point balances.
Get dedicated time allocated to formally investigate the loyalty-ID mismatch's root cause, starting from my own timing-issue hypothesis, and build an upstream validation rule to prevent recurrence.
Work with the business to define and document a basic tolerance threshold for the domain's top downstream processes, so I can prioritise fixes by actual impact rather than treating everything equally.
Build a representativeness and freshness check into the extraction pipeline for any AI-feeding dataset, based on the concerns already informally raised by the data science team.
Build a lightweight, automated validation gate into any pipeline feeding an AI/GenAI system, checking schema and basic quality conditions before data is released downstream.
Add a step to the AI output review process that loops in the responsible pipeline engineer when a data cause is suspected, so I can investigate and fix issues at the source.
Extend the CDP's automated metadata generation pattern to the legacy CRM pipelines still in active use, ahead of their planned decommissioning.
Adopt a documented naming convention standard for the domain and apply it to every new pipeline field I build, with a tracked backlog to reconcile the highest-risk existing mismatches like the tier field.
Publish metadata for the loyalty ledger and legacy CRM pipelines into the group catalogue, prioritising what a new team member would need first to get up to speed.
Extend the CDP's automated metadata generation pattern to the legacy CRM pipelines, so currency stops depending on me remembering to update it manually.
Build a simple AI-specific metadata template (provenance, known limitations, intended use) into the pipeline framework, and apply it to any dataset feeding an AI initiative.
Build a metadata completeness check into the pipeline framework that blocks data flowing into any AI/GenAI destination unless required metadata fields are present.
Add a step to the AI output review process that loops in the responsible pipeline engineer to check whether metadata gaps contributed, feeding confirmed findings back into pipeline documentation.
Publish a governed semantic layer on top of the CDP data with pre-defined metric calculations, so downstream report builders consume agreed logic rather than reimplementing it themselves.
Work with the BI team to surface the freshness and source metadata my pipelines already generate directly on business-facing dashboards, rather than leaving it buried in the catalogue.
Establish a defined issue-reporting mechanism that routes business-user-reported dashboard problems directly to the responsible pipeline engineer, with a tracked resolution record.
Get dedicated capacity allocated to extend the churn-propensity pipeline to the remaining nine countries, prioritising the largest markets by digital revenue contribution.
Get the recommendation pipeline formally adopted for at least one additional market, building on the proven A/B test results rather than leaving it as an unscaled pilot.
Define a minimum expected role for the Data Engineer at data-selection and validation stages for any model consuming domain data, formalising the pattern that worked well on the recommendation pilot.
Get the data scientist's informal feature-importance summary formalised and made accessible to me as the pipeline owner, so I can answer basic transparency questions when they arise.
Get a formal representativeness assessment run on the recommendation pipeline's training data across all 12 countries, and build a rebalancing step into the pipeline if gaps are confirmed.
Request confirmation of formal risk classification and approval for both active pilots from the AI Centre of Excellence, and build a governance-status check into my own pipeline documentation.
Build a documented sign-off step into my pipeline delivery process, confirming representativeness and bias status before I hand off training data for any future model iteration.
Add a pre-deployment data-consistency validation step to my pipeline's deployment process, building on the existing uptime/latency monitoring infrastructure already in place.
Extend the existing A/B monitoring framework to include a periodic data drift and representativeness check I build and maintain, with findings reported back through the model's development sign-off process.
Make it standard practice to request engineering usage and incident data before any pipeline or platform decommissioning decision, rather than relying on individual engineers volunteering it.
Extend the scoping-conversation approach that works well with digital marketing to become the standard practice for requests from other business areas too, rather than defaulting to ticket-based exchange.
Define a Data Engineer development pathway that explicitly includes AI/ML pipeline skills, and give me supported time to progress through it rather than relying on my own initiative outside work hours.

Business benefits

Fewer rework cycles and clearer accountability for STR-01.
Fewer rework cycles and clearer accountability for STR-02.
Fewer rework cycles and clearer accountability for STR-03.
Fewer rework cycles and clearer accountability for STR-04.
Fewer rework cycles and clearer accountability for GOV-01.
Fewer rework cycles and clearer accountability for GOV-02.
Fewer rework cycles and clearer accountability for GOV-03.
Fewer rework cycles and clearer accountability for GOV-04.
Fewer rework cycles and clearer accountability for GOV-05.
Fewer rework cycles and clearer accountability for GOV-06.
Fewer rework cycles and clearer accountability for GOV-07.
Fewer rework cycles and clearer accountability for ARC-01.
Fewer rework cycles and clearer accountability for ARC-02.
Fewer rework cycles and clearer accountability for ARC-03.
Fewer rework cycles and clearer accountability for ARC-04.
Fewer rework cycles and clearer accountability for ARC-05.
Fewer rework cycles and clearer accountability for ARC-06.
Fewer rework cycles and clearer accountability for ARC-07.
Fewer rework cycles and clearer accountability for ARC-08.
Fewer rework cycles and clearer accountability for DQT-01.
Fewer rework cycles and clearer accountability for DQT-02.
Fewer rework cycles and clearer accountability for DQT-03.
Fewer rework cycles and clearer accountability for DQT-04.
Fewer rework cycles and clearer accountability for DQT-05.
Fewer rework cycles and clearer accountability for DQT-06.
Fewer rework cycles and clearer accountability for DQT-07.
Fewer rework cycles and clearer accountability for DQT-08.
Fewer rework cycles and clearer accountability for DQT-09.
Fewer rework cycles and clearer accountability for MDT-01.
Fewer rework cycles and clearer accountability for MDT-02.
Fewer rework cycles and clearer accountability for MDT-03.
Fewer rework cycles and clearer accountability for MDT-04.
Fewer rework cycles and clearer accountability for MDT-05.
Fewer rework cycles and clearer accountability for MDT-06.
Fewer rework cycles and clearer accountability for MDT-07.
Fewer rework cycles and clearer accountability for DST-01.
Fewer rework cycles and clearer accountability for DST-02.
Fewer rework cycles and clearer accountability for DST-03.
Fewer rework cycles and clearer accountability for INT-01.
Fewer rework cycles and clearer accountability for INT-02.
Fewer rework cycles and clearer accountability for INT-03.
Fewer rework cycles and clearer accountability for INT-04.
Fewer rework cycles and clearer accountability for INT-05.
Fewer rework cycles and clearer accountability for INT-06.
Fewer rework cycles and clearer accountability for INT-07.
Fewer rework cycles and clearer accountability for INT-08.
Fewer rework cycles and clearer accountability for INT-09.
Fewer rework cycles and clearer accountability for CUL-01.
Fewer rework cycles and clearer accountability for CUL-02.
Fewer rework cycles and clearer accountability for CUL-03.
A strategy-linked backlog would let engineering capacity go toward integrations like the CDP-to-loyalty-engine work that benefit all markets, rather than repeatedly being diverted to one-off country asks.
A tracked, repeated maturity cycle would have caught the still-unresolved pipeline monitoring gap from 2024 far sooner, and gives engineering leadership a defensible basis for prioritising platform investment.
Clear dataset-level AI guidance would let me build narrower, purpose-scoped pipelines from day one, reducing both the compliance exposure and the rework needed when scope gets tightened after the fact.
An automated AI-readiness check embedded in the pipeline would have caught the representativeness imbalance in the recommendation pilot before training even started, avoiding costly rework and reputational risk.
An automated classification check would have caught the untagged date-of-birth field immediately, reducing the domain's regulatory exposure and giving engineering a repeatable control rather than relying on habit.
Automated, auditable provisioning removes the kind of gap that let the contractor access data ahead of formal approval, and gives the domain a defensible access trail for regulatory or audit scrutiny.
A defined escalation path would ensure exposure incidents like the masking bug get properly recorded and reviewed, rather than being silently fixed with no record that could inform future prevention.
Data contracts would have caught the loyalty ledger schema break before it reached downstream consumers, reducing the recurring cross-team firefighting that currently follows undocumented interface changes.
Explicit AI governance rules would have prevented me building the chatbot pipeline on an assumption that turned out too permissive, reducing both compliance risk and the rework needed to correct it.
Purpose-scoped AI access provisioning would have limited the chatbot pipeline's access to only what it needed, reducing the domain's exposure to over-broad data availability in AI systems.
Extending monitoring to catch scope creep would have flagged the loyalty-tier leakage before a manual tester found it, protecting customer trust as GenAI features become more visible in production.
Automated conformance checking would catch schema drift like the legacy CRM naming issue at build time rather than letting it accumulate silently for years, reducing long-term integration debt.
Standardised integration would eliminate the kind of silent format-mismatch failures I've had to debug reactively, freeing engineering time for building new capability rather than firefighting legacy interfaces.
Automated lineage would have cut the multi-day investigation into the loyalty point discrepancy down to minutes, and protects the domain against permanently losing undocumented institutional knowledge as legacy systems retire.
A formal placement review would let me actually act on the mismatch I've flagged twice already, freeing infrastructure budget that could fund the digital-channel initiatives the group's strategy is prioritising.
Formally logging and resolving the constraint would remove a workaround I've had to maintain for over a year and eliminate a recurring source of customer-facing complaints about the loyalty programme.
A managed, approved AI-native storage pattern would let me build future embedding pipelines properly from day one, rather than accumulating more ungoverned technical debt with each new pilot I support.
Migrating off the direct connection would remove the fragility I currently have to manage manually, and gives future AI pipelines I build a safer, repeatable integration pattern from the start.
AI-specific lineage would let me resolve customer-facing AI issues like the stale-status complaint quickly and with confidence, rather than guessing between multiple possible causes across the stack.
Comprehensive, built-in validation rules would catch malformed loyalty records at ingestion rather than after they've already affected customer balances, reducing the disputes that currently consume my time.
Automated profiling on the legacy feeds would have caught the issue that caused the campaign failure weeks earlier, before it consumed a downstream team's time investigating a symptom rather than the cause.
Scripted, tracked remediation would let me verify fixes actually stick rather than guessing, and would free up the time I currently spend re-fixing issues that may have silently recurred.
Extending measurement to the loyalty ledger would give me an early warning system for that pipeline instead of relying on customer complaints as my first signal that something's wrong.
Fixing the root cause would free up a meaningful share of my own engineering capacity currently spent on repeat manual fixes, and removes a visible, recurring source of customer-facing loyalty balance errors.
A defined tolerance threshold would let me focus engineering time on the imperfections that genuinely affect outcomes, rather than over-investing in low-impact issues at the expense of higher-value work.
An automated representativeness check would have caught the country-skew problem in the recommendation training data before it reached the model, protecting the fairness of personalisation across all 12 markets.
An automated gate would have caught the export-format change immediately rather than letting it silently degrade recommendation quality for weeks, protecting the customer experience the pipeline ultimately serves.
Being looped in to trace AI output issues back to my pipelines would let me fix root causes rather than have symptom-level prompt fixes mask problems I could otherwise actually resolve.
Automated technical metadata would remove my dependency on querying production directly to understand legacy structures, and de-risks the ongoing CRM consolidation project I'm supporting.
Consistent naming would have prevented the tier mismapping incident I had to debug and fix under pressure, and reduces the ongoing risk of similar silent errors as I build more integrations.
Discoverable metadata would cut onboarding time for new engineers on my team significantly, and reduces the risk of the domain's pipeline knowledge living only in my own head.
Automatically current metadata would prevent incidents like the colleague's silently wrong report, protecting confidence in the numbers people build decisions on across the domain.
AI-specific metadata generated as part of the pipeline would make known limitations visible to anyone reviewing or extending a pilot, preventing the same representativeness gap from being silently reintroduced later.
A built-in metadata gate would prevent AI initiatives proceeding on data whose sensitivity or provenance is unconfirmed, reducing the domain's compliance exposure as I build more AI-feeding pipelines.
Closing this feedback loop would let me fix the actual metadata gaps behind recurring AI errors, rather than having them repeatedly worked around at the prompt level without ever reaching engineering.
A governed semantic layer would prevent the kind of downstream miscalculation I have no current visibility into, protecting the accuracy of decisions made on metrics built from data I'm ultimately responsible for.
Surfacing the lineage information I already generate would have prevented the regional director acting on stale data, closing a gap that exists purely in presentation rather than underlying engineering.
A direct reporting route would have got the churn-risk discrepancy to me months earlier, when it would have been far faster to diagnose and fix than it ultimately was.
Extending predictive coverage would let more markets act on retention risk proactively using a pipeline that already works, directly supporting the digital-channel revenue growth objective.
Scaling the pipeline I've already built to more markets would let its proven uplift translate into incremental digital-channel revenue without requiring me to rebuild the underlying engineering.
Consistent involvement at the selection stage would let me catch data-quality and scoping issues before deployment, reducing the kind of after-the-fact investigation I had to do on the chatbot pilot.
Being able to answer transparency questions about my own pipeline's data would build the confidence country teams need to trust and adopt the recommendation engine more widely.
Formally addressing the bias I've already suspected would protect the recommendation engine's relevance and fairness across all markets, not just the three my pipeline currently serves best.
Confirmed governance coverage would protect both the domain and me personally from being unable to answer basic compliance questions about pipelines I've built and am accountable for operating.
A pre-training sign-off built into my own delivery process would have caught the recommendation model's bias before it reached customers, avoiding the credibility and fairness risk now being remediated after the fact.
A validation gate built into my own deployment process would catch data drift before it silently degrades recommendation quality, protecting the customer experience the pipeline ultimately serves.
Continuous monitoring built into my own pipeline would catch emerging bias or drift before it causes material customer impact, protecting fairness and trust as the recommendation capability scales.
Consistently evidence-based decommissioning decisions would have avoided the disruption caused by cutting a feed that turned out to still be in active use, protecting continuity for the teams depending on it.
Genuine scoping collaboration, applied consistently, would prevent the kind of costly rework I experienced with the country team's request, saving engineering time and improving first-time delivery accuracy.
A defined development pathway would let me build the AI/ML pipeline skills the domain increasingly needs in a sustainable way, rather than relying on unpaid personal time that isn't a scalable model across the wider engineering team.

Data Consumer — Lena Novak, Natalia Zueva, Tony Boyle, John Johnson

Justifications

Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
Observed during the Data Maturity review of the Data Consumer domain.
I know a Data Strategy document exists somewhere on the intranet because it was mentioned once at a town hall, but nothing has ever been translated into what it means for how I plan digital promotions day to day. I've never been shown how the group's data priorities connect to the dashboards and reports I actually use.
Some of what's available lines up with what I actually need for campaign planning — the core sales dashboards are decent — but plenty of gaps remain, like reliable cross-country promotion performance data, and no one seems to be actively closing them against any stated plan.
When I've needed a report that doesn't exist — like a combined online/in-store basket view — I've mentioned it to whoever I happen to be talking to, and nothing has ever come of it. There's no route for that kind of need to reach anyone who actually plans the data roadmap.
When my area has wanted a new data source or a fixed report, getting it funded has come down entirely to how persuasive my manager could be in a budget conversation — there's no framework or business case template that connects the ask to the group's data strategy.
I've had no clear guidance on which of the data I use I'm actually allowed to put into AI tools; there's a general IT notice about not pasting sensitive information anywhere, but nothing specific about which reports or datasets are fine for something like a GenAI summarisation tool.
This assessment is the first time I've been asked for my perspective as a data consumer on the organisation's data maturity; previous reviews I'm aware of only involved the central data and IT teams, so business-user experience of what's actually delivered has never been captured before.
For the core sales and promotion datasets, I know who to ask because the digital trading team has an informal go-to contact, but for anything outside that — like loyalty data or supply chain extracts — I genuinely don't know who owns it or who to ask if something looks wrong.
Getting access to a new dataset or report usually means raising an IT ticket and waiting anywhere from a few days to a couple of weeks, with no visibility into where the request actually is in the process while I wait.
When I've been granted access to a new dataset, I've never been shown or asked to acknowledge any terms of use — I just get access and am left to guess what I'm allowed to do with it based on common sense.
I have a rough, common-sense understanding of data handling policy — don't share customer data externally, be careful with anything that looks personal — but I've never actually read a policy document, and I couldn't point to where one lives if asked.
If I saw something I thought I shouldn't have access to, or noticed an extract shared somewhere it shouldn't be, I genuinely wouldn't know who to tell — there's no channel I'm aware of for that kind of concern.
I have no real idea what I am and am not allowed to do with organisational data using AI or GenAI tools; I use a general-purpose AI assistant for writing help occasionally but have never been told which of our data is fine to reference in it.
When I've shared data I've been given — a report forwarded to a regional colleague, an extract sent to an agency — I've never had any obligations passed on to me about what the recipient can or can't do with it, so I just use my own judgement.
The main sales dashboard is usually reliable, but the reporting tool that pulls in loyalty and promotion data together is slow and sometimes times out entirely during month-end, which is exactly when I need it most for reporting deadlines.
I have to log into at least four different systems to piece together a full view of digital trading performance — the sales dashboard, the loyalty platform, a separate promotions tool, and an Excel file someone maintains manually for cross-country comparison.
When I look at a figure on a dashboard, I generally have no way to tell which system it actually came from or how it was calculated; I just have to trust it or ask around informally if something looks off.
There's no supported way for me to get data out of the sales or loyalty platforms into Excel for my own analysis beyond manually copying tables or asking an analyst to run an export for me, which can take days depending on their workload.
When the reporting tools are slow or missing an integration I need, I just work around it — usually with an Excel workaround — and never report it anywhere, because I don't know who would even want to hear about it.
For the core sales figures I use weekly, I've come to trust them through experience, but for anything involving loyalty or cross-country comparisons I still double-check against a second source before using it in anything that matters, because I've been burned before.
I generally assume the sales dashboard updates overnight because that's been my experience, but nothing on the dashboard actually tells me when it last refreshed, so I can never be fully sure a figure isn't a few days stale.
I have no way of knowing whether the datasets I use are actually complete; I only find out something is missing when a total looks obviously wrong and I go digging, which has happened more than once with country-level sales data.
Nothing on any dashboard or report I use tells me whether it's currently considered reliable or has a known issue; every report looks equally authoritative to me regardless of its actual condition.
There is a general IT service desk I can raise a ticket through for data issues, and I've used it a couple of times, but it isn't clear whether it actually reaches whoever owns the dataset or just gets logged and forgotten.
The couple of issues I've reported have simply gone quiet — no acknowledgement, no update, and no way to tell whether they were ever fixed, so I've mostly stopped bothering to report anything at all.l
There's no shared understanding of how accurate data actually needs to be for the decisions I make; I apply my own informal judgement about what's 'good enough' for a trading decision, without any documented guidance to check it against.
When I've used a GenAI tool to summarise a report or draft campaign copy, I have no way to judge how reliable the output actually is beyond reading it myself and hoping it looks right; there's no guidance on what to check.
When I hit a term I don't recognise in a report — like 'active loyalty member' — I have no agreed definition to check against; I just ask around and get slightly different answers depending on who I ask.
When I need data for a new question, I generally have no way to search for what already exists; I ask around my network and usually end up either building something from scratch or discovering, weeks later, that a report already existed.
Beyond a bare definition, I'm rarely given any context about a dataset's limitations — what it excludes, what period it covers, what caveats apply — so I've occasionally misinterpreted a figure simply because I didn't know what it didn't cover.
The same concept, like 'revenue', can mean gross or net depending on which system or report I'm looking at, and nothing tells me which one I'm seeing at any given moment — I have to remember or guess based on the numbers looking familiar or not.
I have no confidence that any documentation I find about a dataset is actually current; the one data dictionary I've come across for the loyalty system looked like it hadn't been touched in a couple of years, based on fields it didn't mention.
The couple of issues I've reported have simply gone quiet — no acknowledgement, no update, and no way to tell whether they were ever fixed, so I've mostly stopped bothering to report anything at all
There's no shared understanding of how accurate data actually needs to be for the decisions I make; I apply my own informal judgement about what's 'good enough' for a trading decision, without any documented guidance to check it against.
When I've used a GenAI tool to summarise a report or draft campaign copy, I have no way to judge how reliable the output actually is beyond reading it myself and hoping it looks right; there's no guidance on what to check.
I have a self-service dashboard tool for the core sales and promotion data, and I've become reasonably comfortable building my own simple views in it, but it doesn't cover loyalty or supply chain data at all, so anything involving those still needs a request to an analyst.
I got a half-day training session on the self-service tool when it was first rolled out two years ago, and I've picked up the rest by trial and error since; there's been no refresher as the tool has added features I don't fully use.
When two dashboards appear to answer the same question with different numbers, I have no way to tell which one is actually the authoritative source; I generally default to whichever one I'm more used to, which isn't a reliable basis for that choice.
The same metric — like conversion rate — regularly shows different values in different reports depending on who built them, and there's no single place I can go to see which calculation is actually correct.
The standard KPI pack I receive monthly covers the metrics I need for basic trading review, but comparing performance consistently across all 12 countries is harder than it should be because a few countries still report their numbers slightly differently within the same pack.
Before I build a new analysis, I generally can't easily check whether something similar already exists elsewhere in the organisation; I rely on asking around my own network, which only covers a fraction of what's actually out there.
Before I build a new analysis, I generally can't easily check whether something similar already exists elsewhere in the organisation; I rely on asking around my own network, which only covers a fraction of what's actually out there
I have access to descriptive reporting on past sales performance, but nothing forward-looking; if I want to know what demand is likely to look like next month, I have to make my own informal estimate based on last year's pattern.
The product recommendation engine on the digital storefront makes suggestions to customers, but as a business user I have no visibility into how it works or how it factors into any decision I'm responsible for — it feels entirely separate from my own workflow.
When the recommendation engine or any scoring model produces an output that affects my work, I have no explanation of why it made that choice; it's a black box as far as I'm concerned.
Test
I'm reasonably comfortable reading a standard dashboard and drawing sensible conclusions from it, having picked this up through experience over five years, but I've never had any structured training in things like statistical caveats or how sample size affects confidence in a figure.
I'm vaguely aware a data literacy programme exists somewhere on the learning platform, but I've never engaged with it and don't know anyone on my team who has either; it's available but effectively invisible.
For significant decisions, my team does generally expect some supporting data, but I've also seen decisions made on the trading director's gut feel with data brought in afterwards to support a call that had effectively already been made.
I have a good informal relationship with one analyst who's always willing to help when I get stuck interpreting something, but I know this depends entirely on that personal connection — colleagues without a contact like mine seem to just struggle alone or give up.
With the analyst I have a good working relationship with, collaboration feels genuinely productive — we discuss what I'm trying to achieve before anything gets built; with the central reporting team, it's much more transactional, submit a request and wait for a deliverable that doesn't always land right.
I generally trust the core sales dashboard because it's proven itself reliable over time, but for cross-country and loyalty figures I still keep my own parallel spreadsheet as a check, because I've been caught out by those before.
Beyond the initial training when the self-service tool was rolled out, I've had no further structured development in data skills; anything I've learned since has been through trial and error or asking my helpful analyst contact.
My immediate manager consistently asks for supporting data before approving a trading decision, which I appreciate, but I've also sat in meetings with more senior leaders where data-backed arguments were clearly overridden by seniority or gut feel with little visible engagement.
I have no formal understanding of what GenAI tools are actually good at versus where they're likely to fail; everything I know has come from my own experimentation and the occasional cautionary story from a colleague.
I didn't know we had one.
Generally they are what we need.
Usually pretty quick turnaround
Takes a long time. We have to justify it to management then it goes up for budget approval.
We just generally use internal data so no constraints on it.
I've never been asked.
We generally ask the IT guy who built the dataset.
Generally quite good. We ask the IT guy and he gives us access.
Not really. If we have access it's assumed we can use it. Obviously we're not going to do anything 'bad' with it.
We're pretty good. We worked here a long time, we are careful.
We know to report it to the IT security guy.
No clear rules, use our own judgement. Don't share internal data with external tools. Fairly obvious really.
We kinda know what is 'private' and what is allowed to be shared. Years of experience in this stuff.
All good. System is always up.
Usually quite easy, we know the systems well enough to know where things are.
We generally know. The data is refreshed overnight, every night.
Usually quite good. The IT Team supplies the tools and the training.
We report it to the IT Manager and he take it up with the architecture people, I think.
For everyday reports the data is good. Sometimes we check if the numbers don't look right.
Sales data is refreshed overnight. Stock numbers are done weekly. We base our decisions on those metrics
Generally quite good but occasionally find missing values.
We don't have that on our datasets.
We report it to the Data Manager
Pretty quick but not always informed unless we ask
We'd like it perfect, but we work around the issues.
Still experimenting with AI. The team uses the rule - Trust, but verify.
There is a data catalogue available
Not great. We usually ask the IT guys or some of our colleagues in other departments
Not really defined anywhere, we just know what it is from experience.
Usually quite consistent.
Usually quite good but not always up to date
Generally know from experience
We report it to the data manager.
We're told they're made with AI, so trust is low.
We are pretty good at using the tools now
We had good training and are using them a long time.
We can't. But there are some reports we trust more than others.
Ussually quite good, as long as the data was generated at the same time.
Usually quite good.
We ask around
We're fairly confident with the older reports.
Pretty confident with the older reports. Based on experience
We are confident as we work with the IT department during testing.
We report it to the IT dept and they check
We use predictive reporting for future sales and stock levels.
No decisions, but recommendations. We use analytics for this, not AI. Use it a lot.
Not great to be honest. We know which reports to 'trust' and which ones to ignore.
Do this from experience.
We are early users of AI. Not corporate standards yet, we are experimenting.
We are early users of AI. Not corporate standards yet, we are experimenting.
We discuss internally.
We're pretty good now I think.
As mandated.
Mostly based on data, but also depend on our experience
The IT dept are pretty good. Always help
Work well together
We have a lot of trust in the data
Could always be better.
Sometimes ask us why, and can we prove it
We are in the early stages of AI adoption.
I have found documentation for the loyalty system that was at least two years out of date, ...

Good practices

Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
Existing automated quality checks cover the core ingest paths.
The town hall did at least put the strategy on the radar of business users like me, even if it went no further than a mention.
The core weekly sales dashboard genuinely reflects what my team needs for basic trading decisions, and it's one of the few things I'd call fit for purpose.
My local BI contact did once informally pass on a request of mine to the central analytics team, which is the only time anything I've asked for has gone anywhere beyond my own team.
My manager did once successfully get a small reporting fix funded by simply escalating it persistently, which shows it's possible even without a formal process.
The general IT notice at least exists and gives a baseline sense that some caution is expected, even without dataset-specific guidance.
The fact that this assessment now explicitly includes a Data Consumer questionnaire is itself a step forward from whatever process existed before.
For the datasets my team uses most, knowing who to ask has become second nature because the same person has always answered promotion-data questions for the last two years.
For the systems I already use regularly, access requests for teammates joining my function have generally come through in a reasonable timeframe once the ticket is correctly raised.
For one particularly sensitive customer dataset, my manager did verbally explain the handling expectations before I got access, which is more than I've had for anything else.
My team's general caution around customer data, even without formal training, has so far avoided any obvious policy breach that I'm aware of.
IT does have a general security incident inbox that I believe could handle this kind of report, even though nothing has told me that's the right place for a data governance concern specifically.
IT's general notice not to paste sensitive information into public AI tools is at least a starting point of awareness, even without anything specific to my own data use.
For particularly sensitive material, I have at least developed a habit of asking my manager before forwarding it externally, which has avoided problems so far even without formal guidance.
The core weekly sales dashboard has been genuinely dependable over the past year, rarely giving me cause for concern about its availability.The core weekly sales dashboard has been genuinely dependable over the past year, rarely giving me cause for concern about its availability.
The sales dashboard and the promotions tool do at least share a common login, which is a small convenience compared to the fully separate loyalty platform.
When I look at a figure on a dashboard, I generally have no way to tell which system it actually came from or how it was calculated; I just have to trust it or ask around informally if something looks off.
For one dataset, IT did set up a scheduled export that lands in a shared folder automatically, which is genuinely useful and the only thing close to self-service I currently have.
I did once raise a slow-loading dashboard as an IT ticket, and it was fixed relatively quickly, which shows the mechanism can work when I actually use it.
The core sales dashboard has proven reliable enough over time that I no longer feel the need to cross-check it before using it in reporting.
The dashboard does at least appear to update reliably most mornings based on my experience, even without any stated commitment or visible timestamp confirming it.
Once a completeness gap is found, the analyst supporting my team has generally been quick to explain what happened when I've asked, even though nothing was flagged proactively.
I did once receive an email warning about a known issue with a specific report, which at least meant I avoided using it that week — though nothing on the report itself carried that warning.
Raising a ticket through the general service desk is at least a defined, known route, which is more than nothing even if I'm unsure how effective it is.
On one occasion a colleague mentioned in passing that an issue I'd raised months earlier had eventually been fixed, which is the only confirmation I've ever had that reporting achieves anything.
For financial reporting figures specifically, there is a general sense across the team that these need to be treated with more care, even without a documented standard behind it.
The general AI usage notice at least implies outputs shouldn't be blindly trusted, even without telling me what specifically to verify.
For a small number of core sales terms, the definitions have become common knowledge across my team simply through repeated use, even without anything written down.
For the reports my own team produces, I do know what exists because I've been here long enough, but that knowledge doesn't extend anywhere else in the organisation.
For the flagship sales dashboard, a brief note does exist explaining it excludes certain outlet types, which is more context than I get for almost anything else.
Within the digital trading dashboards specifically, revenue is defined consistently, which at least gives me one reliable pocket of consistency to work from.
For the core sales dashboard, informal knowledge among the team has stayed reasonably current even without documentation, simply because the dashboard hasn't changed much.
On one occasion a colleague mentioned in passing that an issue I'd raised months earlier had eventually been fixed, which is the only confirmation I've ever had that reporting achieves anything
For financial reporting figures specifically, there is a general sense across the team that these need to be treated with more care, even without a documented standard behind it.
The general AI usage notice at least implies outputs shouldn't be blindly trusted, even without telling me what specifically to verify.
The self-service tool for sales and promotion data genuinely lets me answer most of my day-to-day questions myself, which has been a real time-saver compared to a couple of years ago.
The initial half-day session did give me a solid enough foundation that I've been able to build most of what I need since, even without further formal training.
The flagship group sales dashboard is informally understood across the team to be the 'real' number, even without any formal certification marking it as such.
Within my own team's dashboards, conversion rate is at least calculated consistently, because we've all copied the same formula from the original report builder.
For the majority of countries, the standard KPI pack is genuinely comparable and gives me a reliable basis for month-to-month trading review.
Within my immediate team, we do keep informal track of what's been built recently, which at least avoids duplication within our own small group.
Within my immediate team, we do keep informal track of what's been built recently, which at least avoids duplication within our own small group.
I've heard that a demand forecasting capability exists somewhere in the supply chain function, even though I've never had access to or visibility of its outputs myself.
The recommendation engine has anecdotally seemed to improve basket sizes based on informal observation, even though I've never seen any actual performance data confirming this.
I did once get a general explanation from a data scientist about what factors the recommendation engine broadly considers, which is more insight than I've had into any other model.
Five years of regular exposure to dashboards and reports has given me a genuinely solid working literacy for the day-to-day figures my role requires.
The fact that some kind of programme exists at all is a foundation to build on, even if awareness and participation are currently negligible.
For our weekly trading reviews, we do consistently pull supporting figures before discussing a change, which has become a genuinely reliable habit within the team.
Having built that relationship with a helpful analyst over time has genuinely made a difference to how effectively I can use data in my role.
The scoping conversations I have with my go-to analyst before work begins consistently produce results that actually meet my need the first time, which is a real contrast to the alternative.
My trust in the core sales dashboard is genuine and well-earned through years of it proving accurate, and I no longer feel the need to second-guess it.
The initial training, even as a one-off, did give me a genuinely useful foundation that has carried me for the past two years.
My manager's consistent expectation of supporting evidence has genuinely shaped how my team approaches decisions, and I've come to see this as a model for good practice.
The general IT notice about not pasting sensitive data into AI tools is at least something, even though it doesn't tell me anything about capability or reliability limitations.
Give us some training.
IT Dept pretty quick at generating new datasets when we need them
We ask, it's delivered in a few days normally.
Have money, people and time set aside for these requests.
We probably need some rules around the use of customer data. Also which AI tools we can use.
Get regular input from us
Have a central point of contact
We don't always know what's available. We need to ask other departments what they use.
Have some rules written down.
Defined rules.
Immediate reporting
Write the rules down if you want them followed.
Sharing should go through a central body.
Whatever we're currently doing.
A system "map" would be nice.
Keep up the tool training, especially for new releases and new features.
Have 100% confidence
Refresh everything in real-time
Every field should be populated
Works well now
Have a closed loop reporting system
Regular meetings on data quality, feedback both ways.
Easily accessable
Have a catalogue of available reports, with samples
Most of them are defined in the data catalogue
Keep it up to date
Don't share customer or financial data outside of a select few people
More rules needed on how confident we can be with this data
They work well, maybe 65% accurate based on past sales.
We use the output as a guide, not an explicit instruction.
Continual training
Learn what's available and what it can do

Proposed improvements

Formalise ownership and add a monthly review of STR-CON-01.
Formalise ownership and add a monthly review of STR-CON-02.
Formalise ownership and add a monthly review of STR-CON-03.
Formalise ownership and add a monthly review of STR-CON-04.
Formalise ownership and add a monthly review of STR-CON-05.
Formalise ownership and add a monthly review of STR-CON-06.
Formalise ownership and add a monthly review of GOV-CON-01.
Formalise ownership and add a monthly review of GOV-CON-02.
Formalise ownership and add a monthly review of GOV-CON-03.
Formalise ownership and add a monthly review of GOV-CON-04.
Formalise ownership and add a monthly review of GOV-CON-05.
Formalise ownership and add a monthly review of GOV-CON-06.
Formalise ownership and add a monthly review of GOV-CON-07.
Formalise ownership and add a monthly review of ARC-CON-01.
Formalise ownership and add a monthly review of ARC-CON-02.
Formalise ownership and add a monthly review of ARC-CON-03.
Formalise ownership and add a monthly review of ARC-CON-04.
Formalise ownership and add a monthly review of ARC-CON-05.
Formalise ownership and add a monthly review of DQT-CON-01.
Formalise ownership and add a monthly review of DQT-CON-02.
Formalise ownership and add a monthly review of DQT-CON-03.
Formalise ownership and add a monthly review of DQT-CON-04.
Formalise ownership and add a monthly review of DQT-CON-05.
Formalise ownership and add a monthly review of DQT-CON-06.
Formalise ownership and add a monthly review of DQT-CON-07.
Formalise ownership and add a monthly review of DQT-CON-08.
Formalise ownership and add a monthly review of MDT-CON-01.
Formalise ownership and add a monthly review of MDT-CON-02.
Formalise ownership and add a monthly review of MDT-CON-03.
Formalise ownership and add a monthly review of MDT-CON-04.
Formalise ownership and add a monthly review of MDT-CON-05.
Formalise ownership and add a monthly review of MDT-CON-06.
Formalise ownership and add a monthly review of MDT-CON-07.
Formalise ownership and add a monthly review of MDT-CON-08.
Formalise ownership and add a monthly review of DST-CON-01.
Formalise ownership and add a monthly review of DST-CON-02.
Formalise ownership and add a monthly review of DST-CON-03.
Formalise ownership and add a monthly review of DST-CON-04.
Formalise ownership and add a monthly review of DST-CON-05.
Formalise ownership and add a monthly review of DST-CON-06.
Formalise ownership and add a monthly review of DST-CON-07.
Formalise ownership and add a monthly review of DST-CON-08.
Formalise ownership and add a monthly review of DST-CON-09.
Formalise ownership and add a monthly review of DST-10.
Formalise ownership and add a monthly review of INT-CON-01.
Formalise ownership and add a monthly review of INT-CON-02.
Formalise ownership and add a monthly review of INT-CON-03.
Formalise ownership and add a monthly review of INT-CON-04.
Formalise ownership and add a monthly review of INT-CON-05.
Formalise ownership and add a monthly review of INT-CON-06.
Formalise ownership and add a monthly review of INT-CON-07.
Formalise ownership and add a monthly review of CUL-CON-01.
Formalise ownership and add a monthly review of CUL-CON-02.
Formalise ownership and add a monthly review of CUL-CON-03.
Formalise ownership and add a monthly review of CUL-CON-04.
Formalise ownership and add a monthly review of CUL-CON-05.
Formalise ownership and add a monthly review of CUL-CON-06.
Formalise ownership and add a monthly review of CUL-CON-07.
Formalise ownership and add a monthly review of CUL-CON-08.
Formalise ownership and add a monthly review of CUL-CON-09.
Give business teams a short, role-relevant translation of the strategy — even one page — showing what it means for the reports and data we actually rely on.
Ask business teams directly what data would most improve their decisions, and prioritise closing the biggest gaps — cross-country promotion visibility, in my case — against a visible roadmap.
Set up a simple, visible way for business users to log unmet data needs, with some confirmation that it's been seen and a rough sense of what happens to it.
Provide business teams with a simple template for making the case for data investment, showing how to tie a request to the group's stated strategic priorities.
Publish a short, practical list of which reporting data is safe to use with which AI tools, aimed at business users rather than technical staff.
Make business-user input a standing part of future maturity assessments, not a one-off, so the gap between what's built and what's actually usable gets tracked over time.
Publish a simple directory showing who owns or stewards each major business dataset, so business users don't have to rely on institutional memory to find the right person.
Give requesters basic status visibility on access tickets, and set a stated turnaround expectation so people aren't left guessing whether anything is happening.
Add a simple, mandatory step at the point of granting access where the recipient sees and confirms the key terms — what they can and can't do with the data.
Provide a short, practical policy summary aimed at business users, covering the handful of rules that actually matter for day-to-day report and data use.
Clearly communicate to business users that the existing security channel is also the right place for data governance concerns, and give a rough sense of what happens after reporting.
Give business users clear, simple rules on what data can and can't go into which AI tools, specific enough to cover common everyday tasks like drafting summaries from dashboard figures.
Make onward-sharing obligations explicit and visible at the point I receive data, so I know what I can pass on and under what conditions before I do it.
Prioritise performance and reliability fixes for the combined loyalty/promotion tool specifically around the month-end period when demand and business impact are both highest.
Work toward a single consolidated entry point, or at minimum a shared view, bringing sales, promotion and loyalty data together for business users who need the combined picture.
Add basic source labelling to business-facing dashboards and reports, even something as simple as naming the underlying system and last refresh time.
Provide a documented, supported self-service export or connection option for the datasets business users request most often, starting with the ones causing the longest waits.
Make it clear to business users that recurring platform friction can and should be raised as an improvement request, not just worked around silently each time.
Publish basic accuracy information — even just 'checked' vs 'unchecked' — for the datasets business users rely on most, starting with loyalty and cross-country data.
Add a simple last-updated timestamp to business-facing dashboards, and notify users when a scheduled refresh has failed rather than leaving them to assume it worked.
Document known gaps and exclusions for the datasets business users rely on, and put basic completeness checks in place that would catch a silent drop like the one that occurred.
Introduce a simple visible marker on business-facing reports — even a basic 'known issue' flag — so quality status travels with the asset rather than depending on catching the right email.
Confirm and communicate that data quality issues raised through the service desk actually route to the right dataset owner, and give reporters basic visibility into what happens next.
Introduce a basic acknowledgement and close-the-loop step for reported issues, so the person who raised it is told what was found and what was done.
Provide simple guidance on the intended fitness-for-purpose of key datasets — which are precise enough for financial decisions and which are indicative only — so business users aren't guessing.
Provide simple, practical guidance on what to check in AI-generated outputs before using them for business purposes, tailored to common tasks like summarising reports.
Publish a simple glossary of the business terms that appear in the reports I use most, starting with the ones I've seen cause confusion, like loyalty status definitions.
Provide a simple, searchable listing of existing reports and datasets that business users can check before building something new.
Add basic interpretive notes — coverage, exclusions, known limitations — to the datasets and reports business users rely on most for cross-country decisions.
Label the calculation basis (gross/net, or equivalent) directly on reports wherever a term like revenue could plausibly mean more than one thing.
Put a visible 'last reviewed' date on any documentation shown to business users, so they can judge for themselves whether to trust it or double-check.
Introduce a basic acknowledgement and close-the-loop step for reported issues, so the person who raised it is told what was found and what was done.
Provide simple guidance on the intended fitness-for-purpose of key datasets — which are precise enough for financial decisions and which are indicative only — so business users aren't guessing.
Extend self-service access to loyalty and supply chain data, even in a basic form, so business users aren't split between self-service and request-based access depending on the topic.
Offer periodic refresher sessions or short guides covering new features as the tool evolves, rather than relying entirely on a single initial training session.
Introduce a simple certified/authoritative marker on the small number of dashboards that should be treated as the source of truth for a given metric.
Document a single agreed calculation for the domain's key metrics like conversion rate, and communicate it to all report builders as the expected standard.
Align the calculation basis for the two outlier countries in the standard KPI pack with the rest, so the pack delivers genuinely comparable figures across all 12 markets.
Provide a basic searchable catalogue of existing reports and dashboards that business users can check before starting something new.
Provide a basic searchable catalogue of existing reports and dashboards that business users can check before starting something new.
Give digital trading business users access to whatever forecasting capability already exists elsewhere in the organisation, even in a basic form.
Give trading teams basic visibility into what the recommendation engine is doing, so promotion planning can be coordinated with it rather than operating blind to it.
Provide business users with basic, plain-language explanations of what drives model outputs that affect their work, even at a general rather than per-decision level.
Offer short, practical literacy sessions covering the kind of statistical pitfalls — like small sample sizes — that experience alone doesn't reliably teach
Clearly communicate which literacy modules are expected for roles like mine, and track completion so participation becomes a visible, real expectation rather than an invisible option.
Extend the discipline we already apply in weekly trading reviews to bigger, less routine decisions like the promotion discontinuation, so data genuinely informs rather than just justifies.
Set up a defined, known support route for data help that doesn't depend on personal relationships, so colleagues like the newer team member aren't left to struggle or give up.
Encourage the scoping-conversation approach that works well with my regular analyst to become the standard practice for the central reporting team too, rather than a request-and-deliver model.
Build the same kind of track record of accuracy for cross-country and loyalty reporting that the core sales dashboard already has, so parallel spreadsheets become unnecessary there too.
Offer periodic refresher or advanced sessions as tools and practice evolve, rather than relying on a single initial training session to last indefinitely.
Extend the evidence-based expectation my manager already models consistently to senior leadership decision forums, so data-backed recommendations get genuine engagement rather than being quietly overruled.
Provide practical AI literacy guidance for business users covering what these tools do well, where they commonly fail, and what to check before relying on an output.
It works, don't change it. Unless that IT guy leaves.
We need to get better at esstimating what we'll need in the coming year.
Have some company-sanctioned tools and guidelines for us to follow.
Document the data set when it's delivered
Have a central repository of all the datasets, reports available.
Have some rules written down.
Write down the rules if you want them followed.
It works ok now
Document the rules
Create a central body to allow and approve ssharing.
Create an easy to follow map that shows where every piece of data is.
Maybe add a timestamp
Give us a direct line to the right people.
Data needs to be checked and verified before it gets to my team.
Real-time refreshing of the datasets.
Ensure all data is captured by the sales staff and warehouse staff
Need to fix it quicker and report back when it's fixed
Log a ticket, get a number, follow it up
Have a regular feedback session with the data manager until DQ improves.
Keep it up to date!
Create the shopping list of available reports/graphs/data
Put someone in charge of keeping the documents up to date.
Define it, if it's a problem in the company (not sure it is)
Have a closed loop system for reporting
Refresher training on features we don't use, as well as new features.
If the answers are different, fix them in the reports/dashboard/data.
Include last month's figures in the report. We have to go back and check them in the old report.
Have a central catalogue of available reports
Not sure
A closed-loop support system would be good.
If/when AI becomes more trussted I'd like to use it more.
Document exactly how the result came up, and share it with us.
Have some corporate standards and recommendations of tools to use. And explain why they should be used.
No corporate standards yet
Keep training users.
They need more people there. They are always busy
Would be great to have our own guy in the team
More training
AI Training. Selection of tools

Business benefits

Fewer rework cycles and clearer accountability for STR-CON-01.
Fewer rework cycles and clearer accountability for STR-CON-02.
Fewer rework cycles and clearer accountability for STR-CON-03.
Fewer rework cycles and clearer accountability for STR-CON-04.
Fewer rework cycles and clearer accountability for STR-CON-05.
Fewer rework cycles and clearer accountability for STR-CON-06.
Fewer rework cycles and clearer accountability for GOV-CON-01.
Fewer rework cycles and clearer accountability for GOV-CON-02.
Fewer rework cycles and clearer accountability for GOV-CON-03.
Fewer rework cycles and clearer accountability for GOV-CON-04.
Fewer rework cycles and clearer accountability for GOV-CON-05.
Fewer rework cycles and clearer accountability for GOV-CON-06.
Fewer rework cycles and clearer accountability for GOV-CON-07.
Fewer rework cycles and clearer accountability for ARC-CON-01.
Fewer rework cycles and clearer accountability for ARC-CON-02.
Fewer rework cycles and clearer accountability for ARC-CON-03.
Fewer rework cycles and clearer accountability for ARC-CON-04.
Fewer rework cycles and clearer accountability for ARC-CON-05.
Fewer rework cycles and clearer accountability for DQT-CON-01.
Fewer rework cycles and clearer accountability for DQT-CON-02.
Fewer rework cycles and clearer accountability for DQT-CON-03.
Fewer rework cycles and clearer accountability for DQT-CON-04.
Fewer rework cycles and clearer accountability for DQT-CON-05.
Fewer rework cycles and clearer accountability for DQT-CON-06.
Fewer rework cycles and clearer accountability for DQT-CON-07.
Fewer rework cycles and clearer accountability for DQT-CON-08.
Fewer rework cycles and clearer accountability for MDT-CON-01.
Fewer rework cycles and clearer accountability for MDT-CON-02.
Fewer rework cycles and clearer accountability for MDT-CON-03.
Fewer rework cycles and clearer accountability for MDT-CON-04.
Fewer rework cycles and clearer accountability for MDT-CON-05.
Fewer rework cycles and clearer accountability for MDT-CON-06.
Fewer rework cycles and clearer accountability for MDT-CON-07.
Fewer rework cycles and clearer accountability for MDT-CON-08.
Fewer rework cycles and clearer accountability for DST-CON-01.
Fewer rework cycles and clearer accountability for DST-CON-02.
Fewer rework cycles and clearer accountability for DST-CON-03.
Fewer rework cycles and clearer accountability for DST-CON-04.
Fewer rework cycles and clearer accountability for DST-CON-05.
Fewer rework cycles and clearer accountability for DST-CON-06.
Fewer rework cycles and clearer accountability for DST-CON-07.
Fewer rework cycles and clearer accountability for DST-CON-08.
Fewer rework cycles and clearer accountability for DST-CON-09.
Fewer rework cycles and clearer accountability for DST-10.
Fewer rework cycles and clearer accountability for INT-CON-01.
Fewer rework cycles and clearer accountability for INT-CON-02.
Fewer rework cycles and clearer accountability for INT-CON-03.
Fewer rework cycles and clearer accountability for INT-CON-04.
Fewer rework cycles and clearer accountability for INT-CON-05.
Fewer rework cycles and clearer accountability for INT-CON-06.
Fewer rework cycles and clearer accountability for INT-CON-07.
Fewer rework cycles and clearer accountability for CUL-CON-01.
Fewer rework cycles and clearer accountability for CUL-CON-02.
Fewer rework cycles and clearer accountability for CUL-CON-03.
Fewer rework cycles and clearer accountability for CUL-CON-04.
Fewer rework cycles and clearer accountability for CUL-CON-05.
Fewer rework cycles and clearer accountability for CUL-CON-06.
Fewer rework cycles and clearer accountability for CUL-CON-07.
Fewer rework cycles and clearer accountability for CUL-CON-08.
Fewer rework cycles and clearer accountability for CUL-CON-09.
If I understood the strategic priorities, I could stop chasing ad hoc report requests that don't matter and focus my time on the data that actually moves the digital revenue numbers leadership cares about.
Better-aligned data provision would let my team make faster, more confident cross-market promotion calls instead of guessing or waiting weeks for a bespoke extract.
A real feedback channel would surface gaps like the combined basket view that are currently invisible to whoever plans the data roadmap, so effort gets spent where business users actually feel the pain.
A clear way to justify data investment would let good ideas — like fixing the promotion-performance gap — actually get funded instead of dying for lack of the right framing.
Clear guidance would let my team safely use AI to speed up campaign work, instead of either avoiding it out of caution or unknowingly creating a compliance risk.
Including the consumer perspective regularly would catch the kind of disconnect between 'built' and 'usable' that a supply-side-only review would otherwise miss entirely.
A visible ownership directory would save the kind of time I lost chasing the loyalty data question, letting business users get answers in minutes rather than days.
Faster, more visible access requests would stop new team members sitting idle for weeks waiting on tools they need to actually do their jobs.
A clear terms-of-use step at access time would have prevented the agency-sharing inA clear terms-of-use step at access time would have prevented the agency-sharing incident, and would give business users the confidence to use data correctly rather than guessing.cident, and would give business users the confidence to use data correctly rather than guessing.
A clear, practical summary would reduce the kind of well-intentioned but risky mistakes I've seen colleagues make simply from not knowing where the lines are.
Knowing how and where to report concerns like the over-broad access I noticed would help catch governance gaps before they become a real incident.
Clear AI usage rules would let my team use these tools productively and with confidence, instead of either avoiding them or using them in ways that might breach policy wClear AI usage rules would let my team use these tools productively and with confidence, instead of either avoiding them or using them in ways that might breach policy without realising it.ithout realising it.
Clear onward-sharing rules would close the kind of gap that let my extract travel further than intended, protecting the organisation from exposure it currently has no visibility into.
Reliable access during month-end would stop my reporting deadlines slipping every time the tool struggles under load, which currently happens at the worst possible time.
A consolidated view would save the day of manual work I currently spend assembling cross-system reports, freeing that time for actual analysis rather than data assembly.
Even minimal source visibility would have saved me the half-day I lost reconciling two figures that, it turned out, were never meant to match in the first place.
Self-service extraction would eliminate the multi-day waits I currently experience, letting me respond to business questions same-day instead of after a delay that often makes the answer less useful.
Surfacing recurring friction like the month-end slowness would let it finally be fixed at the source, rather than being silently absorbed by business users every month indefinitely.
Knowing which figures are genuinely checked would let me stop double-checking data that's already reliable and focus my caution where it's actually warranted.
A visible timestamp would have prevented me presenting stale data to that planning meeting, protecting my own credibility and the quality of decisions made in the room.
Documented, monitored completeness would catch a silent data drop within days rather than weeks, protecting the accuracy of the regional totals leadership actually acts on.
A visible quality marker would have stopped me using the flawed dashboard for two weeks, and more generally would let me trust reports based on their actual condition rather than luck.
Knowing my reports actually reach the right person would encourage me to keep reporting issues rather than quietly working around them as I increasingly do now.
Closing the loop on reported issues would rebuild the confidence I've lost in the reporting channel, and would likely surface more issues that currently go unreported because people assume it's pointless.
Clear fitness-for-purpose guidance would prevent the kind of misuse I fell into with the promotion budget estimate, improving the quality of decisions made across my team.
Practical verification guidance would have caught the wrong figure in my AI-generated summary before it reached a presentation, protecting both accuracy and my own credibility.
An agreed glossary would have resolved the loyalty-member confusion in seconds instead of leaving me unsure which of two conflicting answers to trust.
A searchable listing would have saved the two days I spent duplicating an existing report, and would likely save similar duplicated effort happening elsewhere in the organisation right now.
Interpretive context would have prevented the incomplete customer count from reaching a decision unqualified, protecting the accuracy of conclusions drawn from cross-country data.
Label the calculation basis (gross/net, or equivalent) directly on reports wherever a term like revenue could plausibly mean more than one thing.
Even a simple 'last reviewed' date would have warned me the loyalty dictionary was too old to trust, saving me from misreading a redefined field.
Closing the loop on reported issues would rebuild the confidence I've lost in the reporting channel, and would likely surface more issues that currently go unreported because people assume it's pointless.
Clear fitness-for-purpose guidance would prevent the kind of misuse I fell into with the promotion budget estimate, improving the quality of decisions made across my team.
Extending self-service coverage would let me answer cross-domain questions myself in minutes instead of waiting days for someone else to build them, directly speeding up trading decisions.
Keeping training current would help me and colleagues actually use the tool's full capability, rather than quietly working around features we don't know exist.
A visible certification marker would have stopped me presenting figures from the superseded dashboard, avoiding the credibility damage that came from mismatching leadership's numbers.
A single agreed calculation would prevent the kind of false cross-country comparison I nearly presented, protecting the accuracy of the regional summaries leadership relies on.
Fully comparable KPI reporting across all markets would let leadership make fair, accurate cross-country trading comparisons instead of ones quietly skewed by inconsistent inputs.
A searchable catalogue would prevent the kind of duplicated effort I experienced, and would likely save meaningful analyst and business-user time across the wider organisation.
Access to genuine forecasting would have improved my stock allocation estimate for that promotion, directly reducing the kind of lost sales that come from planning on last year's pattern alone.
Coordinating promotion planning with the recommendation engine's output would avoid conflicting customer messaging and likely improve the combined effectiveness of both.
Basic explainability would let me confidently answer questions like the odd bundle suggestion, rather than being unable to account for a model output I'm expected to work alongside.
Better statistical literacy would have caught my small-sample misjudgement before it influenced a promotion decision, improving the quality of conclusions drawn across the wider business team.
Clear expectations and tracking would turn an unused resource into something that actually raises the baseline data literacy across my team and others like it.
Consistently evidence-led decisions would have caught whether the promotion discontinuation was actually the right call before it was made, rather than only being checked against data after the fact.
A defined support route would have helped my newer colleague complete her analysis instead of abandoning it, spreading the benefit I get from my own contact across the whole team.
Genuine scoping collaboration, applied consistently, would prevent the kind of rework I experienced with the central team's report, saving time on both sides and improving first-time accuracy.
Reducing the need for parallel spreadsheets would free up the time I currently spend on redundant reconciliation, and would signal genuinely improved trust in official cross-country reporting.
Ongoing development would have surfaced the better charting approach much sooner, saving the time I spent doing things the hard way for over a year.
Consistent leadership engagement with evidence would have given our recent recommendation a fair hearing, and more broadly would reinforce the evidence-based culture that currently exists only at my manager's level.
Practical AI literacy would have prepared me to catch the campaign summary error myself, and more broadly would let my team use AI productively without the recurring risk of quietly wrong outputs.
We would know what we're looking at, and where it comes from.
Generates reports quicker.
Quicker turnaround.
We all know what we're working with.
Makes it quicker and easier to do our job.
We all know what we can/can't do with the data we have access to.
No mistakes. Easier for new staff too.
More secure data.
No data sharing, better security.
No security issues.
For real-time reports this would be useful
Makes it quicker to do our job.
We can work with confidence.
Can base our decisions on near real-time data.
More accurate reports to management
quicker and accurate reporting
Better data = better output from us
Everyone knows what they're looking at
Quicker for us to get the information we need
We all know what we're working with
No data leaked by mistake
No clear AI strategy in the company. Everyone playing with it, but no central coordination.
We could do more with the same tools.
All data we see should be clearly timestamped. This doesn't always happen.
Makes it quicker for us.
Saves us time.
Get the problem fixed faster.
really important tools for cashflow and stock levels.
If it can save us time/money then we'll use it.
If we know, then we'll use it more.
The quicker we get help, the quicker we work
It's gonna save the world, right? that's a good thing.