Purpose
This statement defines what “prepared” means for the IFS Cloud datamart during the ERP transition period.
Its intent is to:
- Enable controlled validation of IFS Cloud data and logic
- Support confidence‑building and assurance activities
- Prevent false assumptions about production readiness
- Allow legacy reporting to continue without disruption
This is a deliberately scoped definition. It describes minimum viable preparedness, not full production readiness.
What the IFS Cloud Datamart Is For
At this stage of the programme, the IFS Cloud datamart exists to support:
- Field‑level and logic‑level validation of ERP data
- Reconciliation between legacy (Apps10) and IFS Cloud outputs
- Early testing and exploration by reporting and data teams
- Evidence‑based discussion with programme and ERP stakeholders
It is a validation and assurance layer, not a replacement for current reporting.
What “Prepared” Means (Minimum Viable)
The IFS Cloud datamart is considered minimally prepared when the following conditions are met.
1️⃣ Clear Identification of IFS Cloud Views
- A defined set of datamart views exists that explicitly represent IFS Cloud data
- These views are clearly named and distinguishable from legacy (Apps10) views
- There is no ambiguity about which source system a view represents
2️⃣ Thin, Explicit Field Mapping
For each prepared view:
- Key attributes have an understood mapping from IFS Cloud source to datamart
- Any transformation or derivation logic is known (even if not fully documented)
- The goal is explainability, not exhaustive documentation
3️⃣ Known Gaps Are Explicitly Declared
For prepared views, it is explicitly known and documented where:
- Fields are missing, incomplete, or synthetic
- Data is not yet stable
- Behaviour differs from legacy systems
These gaps are expected, visible, and explainable — not surprises.
4️⃣ Predictable Behaviour and Refresh
- Data loads are repeatable and behave consistently
- Refresh cadence is known
- There are no silent schema or logic changes
Perfection is not required; predictability is.
5️⃣ Comparability with Legacy Reporting
The datamart supports:
- Side‑by‑side comparison with Apps10‑based outputs
- Explanation of differences as:
- source system changes
- mapping decisions
- timing or process differences
- known programme limitations
The objective is understanding, not forced parity.
6️⃣ Controlled Audience and Expectations
- Access is limited to appropriate audiences (Data Engineering, Reporting leads, ERP programme stakeholders)
- It is clearly communicated that:
- these views are not business‑as‑usual
- outputs should not be treated as final production truth
This protects both reporting confidence and programme credibility.
What Preparedness Does Not Mean
Minimum viable preparedness does not imply:
- Full replacement of legacy reporting
- Final KPI definitions
- End‑user dashboards
- Complete historical backfill
- Performance optimisation
- Finalised security or access models
- Global rollout readiness
These are later‑stage outcomes and are intentionally out of scope at this point.
Why This Matters
ERP transitions rarely fail because the ERP system itself does not work.
They fail when:
- reporting confidence collapses,
- discrepancies cannot be explained,
- stakeholders lose trust in the data.
IFS Cloud datamart preparedness ensures that:
- validation is structured,
- differences are understandable,
- confidence is built progressively,
- and risk is reduced ahead of cutover.
Summary
IFS Cloud datamart preparedness means:
We can safely validate, reconcile, and reason about IFS Cloud data without undermining current reporting or overstating readiness.
This approach allows the programme to move forward with evidence, clarity, and control.
Owner: Data & Analytics
Status: Living definition — expected to evolve as the programme progresses