Part 4 of 4

Written By: Johan Gauffin – Head of Commercial at ForgeSight 

The challenge is that Foundry programs often stall not because of technical barriers, but because the platform remains opaque, understood by a handful, inaccessible to most.

The idea is to make Foundry understandable in business terms, then reinforce that clarity with an operating model where experimentation is safe, delivery is repeatable, and reuse is expected.

The takeaway is that Foundry becomes an innovation engine when leaders make it understandable and trusted, organize teams around outcomes, and manage momentum with metrics that track realized business value, not just activity.

At a certain stage in the Foundry journey, the platform is no longer the main constraint. Data pipelines are in place. Applications are live. Early use cases deliver value. Yet the program starts to lose momentum. Demand gets noisy, adoption is patchy, and impact stays isolated instead of compounding across the business.

In pharma distribution, this plateau is costly. The environment is complex and volatile, shaped by new therapies, changing regulations, cold-chain needs, and ongoing supply disruptions. A powerful but underused platform is not just a missed opportunity; it becomes a liability. The business carries the cost without gaining the strategic flexibility Foundry was meant to deliver.

This is the final post in the four-part series. As before, ForgeSight is not selling Foundry. This series is for leadership teams who have already invested and are now focused on turning the platform into a compounding cPart 4 argues that sustained value depends on two moves often seen as ‘soft’: demystifying Foundry and building an innovation operating model. In reality, these are hard management problems. They decide whether Foundry becomes an enterprise engine or remains an expert tool.

Executives often treat “understanding the platform” as a training issue, something that will improve once people attend a few sessions and see a few demos. That view underestimates what is really happening. When a platform remains mysterious, people do not merely lack information; they also lack a sense of agency. They fill the gap with stories.

Those stories are usually unhelpful. Some employees experience the platform as magic, which creates unrealistic expectations and disappointment when Foundry behaves like any real system, with trade-offs and constraints. Others experience it as a black box for specialists, which encourages learned helplessness, the belief that engagement requires a data scientist and permission from a central team. Still others experience it as a threat to autonomy, to status, or to job security.

Demystification means replacing mythology with a shared, business-grounded narrative. Leaders need to communicate what Foundry is, and what it is not, in business terms, and back that up with visible use cases and stakeholder education.

The most effective narrative is practical. It avoids technical language and focuses on outcomes. For example, ‘Foundry is our digital backbone for supply chain data and analytics, so leaders and operators can make faster, smarter decisions with a shared view of reality’ is more useful than explaining ontologies. People do not need to know how the platform is built to understand how it changes their work.

For something like supply chain, this narrative works when it connects to operational reality. It makes clear that Foundry is not an IT program running alongside the business. It is a mechanism for performance, resilience, and service reliability.

Even the best narrative fails if it only comes from the top. Demystification accelerates when people see themselves in the examples.

That is why internal demonstrations matter. Brown-bag sessions, workshops, and show-and-tell forums where early teams present what they built and what changed operationally do more than polished roadshows. Teams that delivered early PoCs should present results across departments, because peer storytelling sparks ideas and creates internal champions.

The goal of these forums is not marketing. It is about transferring conviction and know-how. Leaders should expect presenters to answer the questions that drive adoption: what was the baseline problem, what changed in the workflow, what decisions improved, and what happened to key metrics. When a warehouse manager hears another manager explain how Foundry reduced reconciliation friction, the platform becomes less abstract and more actionable.

A subtle benefit follows. These forums create a healthy internal marketplace for demand. Instead of a backlog filled by whoever shouts loudest, leaders start to see which use cases resonate across functions and which are isolated to a single function. This matters because innovation capacity is always limited, and the organization needs a way to surface high-leverage ideas.

Demystification that stops at messaging will stall. People adopt what they trust, and trust is built through transparency.

In regulated environments, skepticism is rational. A platform that influences forecasting, allocation, or quality decisions must be explainable enough that operators can challenge it. Your draft highlights the right questions leaders should answer without going too deep: where the data comes from, how quality is ensured, who can see what, how models are validated, and what to do when something looks wrong.

Executives do not need to turn every employee into an engineer. But they do need to set a few non-negotiable routines that make trust normal. One is a clear data lineage and quality posture, expressed in business terms. Another is a visible governance path for issues, so users know how to flag anomalies and how those issues get resolved. A third is a consistent explanation model for analytics and AI, especially when Foundry generates forecasts or risk signals. If leaders want people to act on insights, they must make it safe to question them.

The lesson for Foundry is that adoption accelerates when people can connect platform work to strategic outcomes and see themselves as part of that mission.

Once Foundry is understandable and trusted, the next bottleneck is organizational design. Many enterprises want innovation, but operate in ways that make experimentation feel out of bounds. Every idea needs a formal project. Every project needs heavy approvals. Every approval cycle drains momentum.

Scaling Foundry requires a culture that encourages experimentation, cross-functional collaboration, and continuous learning. That culture does not come from slogans. It comes from systems that make experimentation possible within clear boundaries.

A practical pattern is a three-stage innovation pipeline. The first stage is exploration, where teams test ideas quickly in a sandbox with the right controls. The second stage is incubation, where a promising prototype is time-boxed into a more disciplined pilot with clear metrics and a sponsor. The third stage is industrialization, where the capability is hardened, governed, and integrated into the operating model as a product.

This pipeline matters because it prevents two common failures: uncontrolled prototyping becoming operational risk, and promising ideas dying in the gap between prototype and production. Executives do not need to manage the pipeline daily, but they do need to ensure it exists, is resourced, and that graduation criteria are clear.

Innovation days and hackathons can be useful catalysts, not as tech events, but as ways to surface ideas and spread fluency. Cross-functional hackathons can yield prototypes and accelerate familiarity. The key is what happens next. A hackathon that produces demos but no path to production is theatre. A hackathon that feeds the innovation pipeline becomes a source of compounding capabilities.

Foundry programs often default to large steering groups for innovation, because leaders want broad representation and risk control. That approach is understandable, and often counterproductive.

Nimble, mission-focused teams deliver quick wins and adapt faster than large, siloed committees, creating a startup mentality inside the enterprise. As one CIO put it, it is a Navy SEAL approach rather than a whole army approach.

This is not a call for hero teams. It is a call for focus. A small strike team with executive backing can quickly validate what works, set patterns, and generate reusable components. The governance model from Part 2 then scales those patterns without letting every team reinvent the wheel.

In a risk-aware industry, leaders need to create the right kind of psychological safety. Setbacks should be treated as learning. The organization should distinguish between domains where risk tolerance must be near zero, such as patient safety and compliance, and domains where rapid trial-and-error is acceptable, such as internal process improvement and data utilization.

Culture creates energy. Structure creates durability.

Traditional business and IT silos stifle Foundry’s impact. Product-based teams align accountability with outcomes, not just delivery. This is a crucial distinction. Project teams deliver artifacts, then disband. Product teams own capabilities over time and treat adoption, performance, and iteration as part of the job.

In a product-oriented model, you might have a Demand Forecasting Platform team that includes domain leadership, product management, and technical delivery, and that owns outcomes such as forecast accuracy and planner adoption. In pharma distribution, product teams naturally map to domains that matter: cold-chain performance, inventory optimization, compliance reporting, shortage prevention, and customer service reliability. The point is not the label. The point is persistent accountability.

Most organizations cannot reorganize overnight. That is fine. What matters is moving the unit of management from projects in a queue to capabilities with owners. Even a hybrid model, with durable squads supported by a small Center of Excellence, can generate much of the benefit.

The Center of Excellence serves as both an enabler and a guardrail. It sets standards, shares best practices, supports reuse, and incubates ideas that do not fit neatly into a single product charter. The CoE’s job is not to centralize all delivery. It is to prevent fragmentation and accelerate time-to-value by making the best work reusable.

As Foundry becomes easier to engage, idea volume increases. That is a success, but also a new risk. Without a clear value lens, Foundry becomes a backlog factory.

Use MIT CISR’s four levers of digital value as an executive filter: customer, capability, commercialization, and component. The key is to pull all four levers together with governance support. This framing prevents innovation from collapsing into one dimension, such as efficiency, while ignoring the levers that create strategic differentiation.

In pharma distribution, the customer lever can mean tailoring services to different customer types, hospitals versus community pharmacies versus online channels. The capability lever pushes leaders to build shared foundations, such as reusable inventory visibility, demand sensing, and quality analytics, rather than rebuilding region by region. The component lever reinforces modularity, pipeline templates, connectors, widgets, and reusable patterns that accelerate every subsequent build. The commercialization lever can be optional, but strategically useful, prompting leadership to ask whether internal strengths could become partner offerings, data-driven services, or differentiated customer products.

This does not need to become a bureaucratic scoring model. It can be a set of recurring questions in steering forums. The discipline is in refusing to fund innovation that cannot clearly answer which value lever it pulls and how it will be measured.

Foundry becomes an innovation engine only if leadership treats it as a strategic priority over time, not as a one-time modernization push. CEO and board-level advocacy matter, as do metrics that track innovation outcomes to make progress visible and celebrated. These metrics clarify what the organization values. Three families are especially useful: adoption metrics, innovation output, and business outcomes attributable to Foundry. The best programs treat these metrics as operating indicators, reviewed in the same cadence as other business performance measures.

A final reinforcement mechanism is external storytelling. When appropriate, sharing success stories in industry forums builds organizational pride and helps attract talent. External recognition can become self-reinforcing: innovative reputation attracts innovative people, who then drive more innovation.

Across this series, the argument has been consistent: most Foundry programs do not stall because the platform lacks capability. They stall because the enterprise has not fully aligned its strategy, governance, change management, and operating model around it. That is the real second act. Once the platform is in place, the question is no longer whether Foundry can deliver value. The question is whether the organization can make that value understandable, trusted, repeatable, and scalable across the business.

That is where ForgeSight fits. We work with leadership teams that have already made the platform investment and now need to make it perform as an enterprise capability. That means helping define where Foundry should matter most, putting the right governance and product structures around it, accelerating adoption through clearer operating models and stakeholder enablement, and building the delivery discipline required to turn early wins into durable business outcomes.

If your organization has already invested in Foundry but still sees scattered demand, uneven adoption, and isolated wins instead of compounding value, the next step is not another pilot. It is a clearer operating model. ForgeSight helps organizations make that shift, turning Foundry from a promising platform into a trusted engine for execution, innovation, and measurable business impact.

Acknowledgments
With thanks to Ben Menesi(LinkedIn) and Percy Rivera Salas(LinkedIn) for reviewing earlier drafts of this piece and offering thoughtful feedback that strengthened the argument and improved clarity. Any remaining errors or omissions are mine alone.

References and further reading
Ross, Jeanne W., and Peter Weill. “Six IT Decisions Your IT People Shouldn’t Make.” Harvard Business Review (November 2002).
Eastwood, Brian. “4 levers that create digital value.” MIT Sloan Ideas Made to Matter (October 16, 2023).
Pratt, Mary K. “Transforming IT for digital success.” CIO (October 23, 2023).

Author’s note: This post was informed by executive MBA coursework and class discussion on IT governance, operating models, and digital transformation, and it was adapted from the longer Part 4 in a future white paper.