We spend a lot of energy talking about change, and even more talking about how to apply technology to it. The speed of AI innovation itself is no longer in question — it is happening, and it is happening fast. Executives and practitioners are largely aligned on that point, and aligned that the imperative is to adopt, use, test, and deploy. The question left standing is how.
That "how" is the familiar pattern we are observing: pilots are failing, POCs don’t scale, digital initiatives stall, etc. This is real, and it isn’t surprising that organizations reach for technology instead of method to answer it. The tool is always the easier lever to pull — it’s not a new behavior, and it’s a familiar failure mode. Something similar happened when Lean first arrived in manufacturing in the West. The tools got the attention — the focus was on the Kanban boards, the 5S audits, the Supermarkets, Andons, Poka-Yoke, Kamishibai, and so on — while the harder, genuinely transformative process behind them, the organizational adoption of Lean and the change in operational behavior, got skipped. That pattern resurfaces with every new paradigm, and we are clearly watching it happen again.
It’s disheartening that the prescription, once again, is entirely about the technology: data structure, infrastructure, context, integration, connectivity. Every one of those is correct and necessary. None of them will do much on their own, without a strategic process of transformation — one backed by leadership strong enough to actually drive the organization toward an order-of-magnitude productivity improvement.
Deploying transformational technology into an organization that hasn’t changed how it behaves, thinks, designs, engineers, and of course operates isn’t transformation. Transformation is genuinely hard, which is exactly why organizations keep reaching for the tool instead. It’s easier to issue a purchase order for tech; trying to change the way you operate is a challenging, conflict-ridden process that is uncomfortable and very risky.
So what is the best approach here? It really is not new, like in Lean and in CIM (Computer Integrated Manufacturing, yes, remember that?), the answer is the combination of a technology that is truly digital, and an effective method to guide how it’s adopted in a continuous transformative motion. A new way of working, designing, operating, and engineering, not just a new technology capability bolted onto the existing operational model. You will know it’s working when it produces a transformative, order-of-magnitude productivity gain. That is what leadership should be expecting, not an incremental improvement.
The Productivity Equation
 |
| The Productivity Equation |
Let’s start by stating the obvious. The observation and discussion on digital adoption failure rates are real. I need to start with this background to ground reality and satisfy the skeptics — if there are any left.
MIT’s NANDA initiative found that 95% of enterprise generative AI pilots deliver no measurable return despite tens of billions in enterprise spend — not because the models are weak, but because the organizations never integrated them into how work actually happens. That’s consistent with what BCG found well before generative AI showed up: 70% of digital transformations fall short of their objectives. McKinsey’s own research on why transformations fail lands on the same conclusion from a different angle — the constraint is almost never the technology’s capability, it’s the organization’s ability to change how it works around it.
In the last three decades I have watched this unfold countless times, where companies attempt to absorb new technology without changing their approach or how they work, and then wonder why the improvements do not stick. The technology becomes the thing they tried. Not the operating model they run on.
This is the same digital divide I’ve been writing about for years — not embracing the required change is really just digital theatrics. Naming the problem is half the battle; solving it to produce a sustainable productivity gain is victory. This can only be achieved by executing on the equation — the two specific, concrete components, applied together.
The Technology
You have to use technology that is genuinely digital and AI-native. This critically means composable — not just connected, modular, AI-enabled, digital, IIoT, and, of course, not monolithic. Composable technologies are built to change at the pace of the business and operations rather than the pace of an IT project, and to absorb new capability, including AI, in hours-to-days iteration cycles rather than months-to-years projects.
That distinction sounds like a technical footnote until you sit with what it actually means operationally. In a traditional, monolithic system, a change — a new product introduction, an equipment upgrade, a new process step, a new quality procedure, a technology upgrade, etc. — will trigger a change request, a design review, configuration, a validation cycle, and a deployment window measured in months. This is due to the monolithic nature of the solution: architected around a single, centrally-owned data model, it cannot change locally without touching everything connected to it. That’s not a flaw a vendor fixes with a software update — it’s the architecture.
A composable platform inverts that. Each solution is scoped to one operator doing one job, apps share data through common structures but are independent of one another, and a local change stays local. That’s the concrete, measurable expression of "technology built for transformation": speed-of-change, hours-to-days instead of months-to-years. It’s also the precondition for AI to be useful in operations at all — a model can only iterate as fast as the system around it lets it, and a platform that requires a quarter to reflect a floor-level change will require a quarter to reflect what an agent just learned, too.
Notice that the method, composability, is already embedded in the technology. Technology alone — even genuinely composable technology — produces pilots, not transformation. This is the half of the equation; it is necessary but it is not sufficient.
The Method
You have to use a method that defines the underlying transformative theory and its mechanics — the concepts and the strategic guidance, together. Lean is the clearest example. Its concept is a specific definition of what a Lean operation looks like when it’s actually working, and it rules out what doesn’t count: Lean, at its core, defines a small set of principles for an operation — identify value, make value flow, execute pull, and enable perfection. A cost-cutting exercise with no customer-defined value isn’t Lean, no matter how many Kanban boards it has. The tools — Kanban, 5S, Andon, Poka-Yoke, Kamishibai — are what make that concept usable on the floor, not just legible to a consultant. Concept plus tools is the playbook, and the playbook is what makes a transformation widely usable and easy to adopt at scale.
So, a method that actually drives transformation has two specific components: a concept — the foundational idea, strategic model, and guiding vision that redefines how operations use technology, expressed as a framework that defines the outcome you should expect and, just as precisely, what falls outside it — and a set of tools and best practices that show people how to apply that concept correctly, in daily work.
A concept with no tools stays a slide in a training deck nobody can act on. Tools with no concept behind them turn into techniques people run without knowing what they’re supposed to add up to — which is exactly what happened when Lean arrived in the West, as I noted above.
The method here is called Composability, and I’ve explained it in a number of previous posts. It includes a concept, a framework, tools, and best practices. Composability is defined by five pillars, resting on two foundational, supporting conditions. Each pillar has its own supporting tools and best practices, all bound by the same framework. Here is the framework:
Bottom-up. Solutions are built from the operational level up — not imposed through top-down hierarchies — tailored to the specific process, with the people closest to the problem contributing directly to what gets built. This produces emergent design: solutions evolve in real time as operational needs evolve, deployed incrementally and iterated on immediately, rather than routed through an IT change-request queue against a predefined architecture.
Agility — Augmented Lean. Composability is the reunion of Lean and Agile: rapid test-fail-learn cycles and on-demand process changes, in place of the predefined processes a monolithic system locks an organization into. This isn’t a development methodology; it’s an operational property — the ability of the floor to respond to a process change, a quality event, or a new product introduction in hours-to-days instead of weeks-to-months. I call this Augmented Lean because it is, structurally, the Toyota Production System’s logic of standardize-then-improve, run inside a digital architecture that can actually keep pace with how often the standard needs to change.
Democratization. The people who know the process — engineers, technicians, operators — build and maintain the digital solutions themselves, using no-code and low-code tools, without waiting on centralized IT. This is also the organizational mechanism that lets change scale past the first pilot: people get trained to build, and the organization accumulates a growing portfolio of focused, continuously maintained apps instead of a single archived experiment. Generative and agentic AI are amplifying this pillar further — describe a process in natural language and get a working scaffold back, and the barrier to entry drops for people who would never otherwise touch a no-code tool.
Human-centric. Technology serves the operator, not the reverse. Traditional enterprise interfaces make the person on the floor into a data-entry function for the system — locate the right transaction, navigate the rigid form. A method that inverts this, designing around the operator’s actual workflow rather than the data model, puts the operator at the center: productivity gains come from augmenting human capability, not from forcing people to adapt to system constraints. This is also still fundamentally about people, not software.
Compliance. In regulated environments — life sciences, aerospace and defense, and others — this pillar is less about the baseline technical requirements every platform has to meet (audit trails, e-signatures, data-integrity standards — prerequisites, not differentiators) and more about a mindset shift: the belief that a digital solution can be continuously improved while remaining in a validated state, instead of locked down between full re-validation cycles. Changes get scoped, risk-assessed, and evidenced automatically, which is what makes agility and democratization survivable in a GxP context rather than a liability.
Underneath all five pillars, two more concepts have to be true, or the playbook doesn’t hold. The first is digital maturity — an organization’s actual, demonstrated capability to run composable architectures, not just its enthusiasm for them. Culture, skills, and governance have to advance in step with the technology; an organization can deploy a composable platform and still fail to capture the gain if its people and processes haven’t caught up to what the platform enables. The second is connectivity and data integrity — accurate, consistent, trustworthy operational data, available at the point of work. Without it, none of the five pillars actually function: an operator can’t be human-centric about a decision built on data they know is stale, and an agent can’t augment what it can’t see clearly. Digital maturity and connectivity are the two bases the five pillars stand on — not an afterthought to them, but the ground underneath.
None of this is a modularity story. Composability is not "interchangeable pieces." It’s an operating discipline that determines whether an organization can sustain the rate of change its business actually requires — and every one of Lean’s real tools, including standard work, lives inside it rather than outside it.
The Outcome is Always the Measure of Success
Technology without method produces pilots with marginal productivity increases. Method without technology is a theoretical exercise that fails on execution. Technology with a method drives transformation that results in order-of-magnitude productivity improvements.
My simple equation uses addition, but there’s a scenario where it actually becomes multiplication. A brilliant composable platform deployed with no method for what to build first, on which line, with which team, or toward which measurable outcome doesn’t stay composable for long — it degrades, most detrimentally, into just another monolithic JAM (Just Another Manufacturing System). That isn’t a smaller version of transformation. It’s a sure way to keep doing what you were already doing, which is exactly where the marginal outcomes come from. A beautifully designed operating philosophy with no platform capable of executing it for rapid time-to-value doesn’t drive transformation either. It’s a sure way to build distrust and skepticism.
Technology + Method = Productivity. Not one or the other.
