I like simple pictures that hold up in the real world. The “three doors” visual is one of them:
- Door 1: Fiori for operators in SAP.
- Door 2: SAP Analytics Cloud (SAC) for decision boards.
- Door 3: Snowflake apps for cross-functional analysis and activation.
In this analogy, the important thing isn’t so much about the doors themselves. It’s the fact the same SAP data feeds all three choices.
SAP is delivering a growing catalog of data products with shared semantics. Those products carry business meaning and lineage your teams recognize, and they’re the backbone we extend in Snowflake.
In Snowflake, we lean on Horizon for governance and discovery, Cortex for natural-language Q&A and task automation, and Dynamic Tables to set how fresh each product needs to be and what that will cost.
Keeping these controls close to the work is how we stop drift before it starts.
1. Treat “Data Products” as Part of Your S/4 Blueprint, Not an Afterthought
When you map Order-to-Cash, Procure-to-Pay, Finance, and WAM, also list the SAP Business Data Cloud products you’ll make authoritative for each stream.
Give each one an owner and an SLA. This moves you from “tables and extracts” to a contract your teams can design around from day one. Your cutover and testing plans get cleaner because you’re validating products, not reinvented logic.
S/4 takeaway: include data-product contracts in the solution design workshops alongside process and integration design.
2. Design the Three Doors Early So Consumption Never Forks
- Fiori: Decide which KPIs must show on tiles for go-live personas. Use those to anchor your data-product backlog.
- SAC: Define the executive and operational boards that must match Fiori and Snowflake from the start.
- Snowflake: identify where cross-functional analysis or activation lives (supply + finance, service + IoT, etc.). Register products in Horizon so ownership, policy, and lineage are visible to everyone, not just IT. Put Cortex Analyst in front of governed products, and add Cortex Agents where multi-step tasks matter.
S/4 takeaway: build parity checks into your definition of done. Before you close a sprint, the same KPI should land in a Fiori tile, an SAC story, and a Snowflake view with matching definitions.
3. Make Freshness a Budgeted Decision, Not Just Muscle Memory
When you connect your BDC data product to Snowflake, you make the choice within Snowflake for how frequent the BDC metadata will be refreshed. This is effectively setting your refresh cycle from BDC To Snowflake. This puts the governance of Snowflake data latency with the data pipeline owners, not the data product producers.
In addition, when pipelines are then also built using Dynamic Tables, for example, you set target lag per product and let Snowflake schedule to that SLA. Warehouse size becomes the knob you turn on cost and latency.
In S/4, outage boards or “ready to bill” tiles might be sub-hourly, while planning packs update nightly.
Each persona benefits as you are now building Snowflake data product freshness by persona and consumption patterns. Show Finance the latency-versus-spend curve during design, not after go-live.
4. Keep Governance Where People Work
Publishing to Horizon isn’t a post-go-live activity. It’s part of the build. It’s how stewards, auditors, and product owners see policy, sensitivity, lineage, and consumers in one place. That matters when you’re proving “one truth” across Fiori, SAC, and Snowflake.
Snowflake Data Product Owners build in governance muscle memory by adding a “register in Horizon” step to every user story that ships a data product. If it isn’t cataloged, it doesn’t exist.
5. Plan for Intelligent use, Not Just Reports
SAC remains your planning and decision hub, close to SAP context.
Snowflake is where you combine SAP data products with enterprise and external signals and let Cortex help teams ask and act. Cortex Analyst answers questions on structured data. Cortex Agents combine Analyst with search and custom tools for repeatable tasks.
S/4 takeaway: write assistive stories into your backlog. For example, “As a plant manager, I can ask for tomorrow’s expected shortages and have an agent draft a mitigation list based on governed data and policy.”
6. Use S/4 clean core more effectively
This model supports a clean-core mindset. SAP remains the authoritative core for definitions and process UX. Snowflake handles extension, blending, and broad consumption without dragging custom logic back into the ERP.
For S/4 programs, when someone proposes a core modification “for analytics,” route it to the data product owners and keep ERP clean.
What “good” looks like by your S/4 BDC pilot cutover
- A short list of authoritative SAP data products with owners and SLAs, tied to process workstreams.
- A demo where the same KPI appears in Fiori, SAC, and a Snowflake view with matching numbers.
- Products registered in Horizon with policy, sensitivity, lineage, and consumers visible.
- Freshness targets set per product using Dynamic Tables, plus a cost/latency slide you can show the steering committee.
One More Thing as You Reshape Your S/4 Strategy
You don’t have to do this alone. You get the power of two working as one. IBM’s SAP practice brings the depth in S/4, ECC lineage, Fiori, and SAC.
Hakkoda’s Snowflake practice brings governance in Horizon, activation with Cortex, and the engineering patterns that respect FinOps. The IBM SAP practice is an international juggernaught of SAP functional and technical experts that have delivered some of the most technically complex SAP installations in the world.
We show up as a single team so your program doesn’t feel like a handoff. It feels like momentum.
Ready to start building that momentum today? Let’s talk.
