Process as a Product: The Functional Side of Digital Projects

A digital program produces two things. It produces software — a platform, an ERP module, a scheduling engine, a data pipeline — and it produces a new way of running a business process on top of that software. Only the second one shows up on the P&L. The first one is the container.

The habit in most large programs is to treat the software as the product and the process as configuration. Requirements get gathered. A vendor gets selected. The integrator gets to work. Somewhere in the deck there is a slide about “change management” listing training days and communications. The redesigned process — the actual sequence of steps a planner or a technician or a supervisor will follow on Monday morning — is assumed to fall out of the configuration. It never does.

Process as a product means flipping which one is the deliverable. The primary output of the program is a running business process, with owners, documentation, versions, tests, and a lifecycle. The software is what the process runs on, the way a manufacturing line runs on a physical building. The building has to be there. Nobody confuses it with the product.

If the process is the product, it has to be built the way products get built. That means a specification, a design, a version, a test plan, a release, and an owner who is on the hook after go-live.

The specification is written in the language of the operator, not the analyst. It names the input a step consumes, the decision it makes, the output it produces, and the exception it will raise when the world does not cooperate. A work-order release step is not “run MRP.” It is: planner receives the demand signal, checks these three constraints, releases the order at this granularity, escalates when this condition holds. The system does part of it. A person does the rest.

The design is the workflow itself, drawn end to end, with the handoffs between people and system made explicit. Where does the model decide, where does the person decide, where does the check happen, what does the exception path look like. A workflow without an exception path is a wish.

The test is not a system test. It is a process test. Can a real planner, at a real desk, run the redesigned process to completion using only the artifacts the program has shipped — the SOP, the training, the coaching, the tool? Not in a conference room with a consultant next to her. On Monday, cold. Programs that never run this test discover the gap in production.

The version and the lifecycle are what separate a process product from a one-time deployment. Version 1.0 is the go-live process. Version 1.1 is what ships in month three when the exception rate comes in higher than the design assumed. Version 2.0 is the redesign that happens when the business changes shape. There is a named owner for each version and a change log. This is how software teams work. It is how process teams need to work when the process is the product.

Every process product needs a named human who owns it. Not a steering committee. Not a co-chair pair. One person, from the business the process serves, who is accountable for what the process produces and who has the authority to change it.

On most digital programs the functional owner shows up as a title on the org chart and then disappears into the review cycle. The IT program manager runs the plan. The integrator runs the build. The functional lead approves deliverables, chairs a workshop, and comes back at user acceptance testing. That is oversight, which is a different job.

Real functional ownership looks unglamorous on paper. The owner is in the design sessions with the operators. She writes the specification with them. She sits with the technicians during the pilot and watches where the workflow breaks. She signs off on the exception path because her team will have to run it. She sets the leading indicators — cycle time, first-pass yield, unplanned overtime, escalation rate — and reviews them in her operating meeting every week after go-live.

The reason this role is hard to staff is that it is a real job, not a program job. It cannot be done by a rotating secondment or a project manager on loan from PMO. The business has to release someone from her operating role for the duration of the program and place her back in the business afterwards, still owning the process she just shipped. Programs that cannot name that person on day one usually will not have a functional owner at go-live either.

The clearest way to tell which kind of program a company is running is to listen to how leaders describe the outcome. When the program is technology-first, the sentence starts with the noun of the tool. “We stood up the CMMS.” “We rolled out the new MES.” “We migrated the plants onto the platform.” The subject is the software. What the software is for is implicit and often unmeasured.

When the program is process-first, the sentence starts with the work. “We shipped a new reliability process for the pump fleet, and the CMMS is what it runs on.” “We redesigned the release-to-shop-floor process, and the MES carries it.” The subject is the redesigned way of working. The tool is the vehicle. The number that gets reported at the next earnings call is the business outcome, not the deployment milestone.

Predix is the extreme version of the first sentence. GE poured billions into a platform, forecast $15 billion in software revenue by 2020, and never shipped a new process that its own divisions wanted to run. Aviation had its own analytics workflow. Healthcare had its own data infrastructure. Power was skeptical a Silicon Valley cloud team understood gas turbines. When adoption was demanded from the top and no redesigned process arrived from the middle, the businesses said yes in the review meeting and kept working the old way at their desks. GE Digital was doing about one billion in annual software revenue by 2018, most of it from products that predated Predix. The name was retired in 2022 and the remnants were folded into GE Vernova’s asset performance suite by the time GE split into three companies in April 2024. The technology was not the failure. The absence of a shipped process was.

Siemens has been telling a version of the same story in a quieter register. MindSphere launched as the industrial cloud that would carry customers into predictive maintenance and digital-twin analytics. In 2023 Siemens rebranded it as Insights Hub, split off Industrial Edge and an Industrial AI Suite, and moved hosting onto AWS. The reorganization is coherent on a slide. The harder question the plants keep asking is what redesigned reliability, quality, or maintenance process the platform delivers to the floor — owned by whom, versioned how, tested against what. Where that answer is clear, the platform earns its place. Where the answer is “the plant will figure it out,” the platform becomes another stack the operator learns to ignore.

Programs that treat process as the product organize differently from day one. The plan is not phased by system module. It is phased by process release.

Release one is a single redesigned process, running end to end, in one plant or one business unit, with a real operator running it and a real functional owner accountable for the outcome number. The software behind it is whatever the release needs to work — a slice of the platform, a lightweight integration, sometimes a spreadsheet in the first eight weeks while the deeper configuration is still being built. What the release proves is that the process holds up under real conditions, that the operator can run it without a coach at her elbow, and that the leading indicators move the way the business case promised.

Release two adds the next process, or extends the first into a second site, using what release one taught the team about where the design broke and where the training missed. The platform gets built out in the shape the process needs. When a design decision has to be made between a cleaner technical architecture and a workflow the operator can actually run, the workflow wins, because the workflow is the product.

The budget is written the same way. The change work — process redesign, functional-owner time, operator engagement in design and pilot, training tied to the redesigned workflow, floor-level coaching in the first eight weeks, adoption sustainment through month six — is a real line item, not a residual. On the programs where the tool arrives and the process does not, the change work was budgeted as a percentage of the software spend and then cut when the software ran over. On the programs that ship a process, the change line is at least as large as the software line and protected the way infrastructure spend is protected in a physical build.

A process product does not end at go-live. It enters its operating life, which is where most digital programs quietly stop paying attention. The functional owner keeps her role. Usage of the tool is a leading indicator, not the outcome; the outcome is the process metric the business case was written against. Exception rates get tracked to feed the next version of the design. Training gets revised in month four, because the first version was written before anyone had run the process at full volume and roughly a third of it turns out to have missed what the job looks like.

Then the process gets versioned. When the business changes — a new product line, a regulatory requirement, a supplier arrangement — the process is redesigned, tested, and released the way version 1.0 was. The owner and the change log make this cheap. Programs that skipped the ownership step end up doing the redesign as a new project, with a new business case and a new round of software spend to justify what should have been a version bump on a process that already existed.

When a leadership team approves a large digital program, the deck in front of them is almost always a technology deck. Architecture, vendor selection, integration diagram, security, timeline. The question the deck rarely surfaces — and the one leadership has to insist on — is what redesigned process the program is going to ship, who is going to own it, and how the team will know it is running.

The uncomfortable version of that question is: if the platform is delivered on time and on budget and no redesigned process ships alongside it, is that success or failure? On most program charters, it is technically a success. On the P&L, it is not. Bringing those two definitions back into alignment is the leadership move. It shows up in how the program is chartered, how the functional owner is chosen and released from her operating role, how the change work is budgeted, and how the outcome number is reported at the operating review after go-live.

The organizations getting real returns from digital programs are the ones treating the process as the product, the tool as the vehicle, and the functional owner as a permanent role in the business. The rest have a very expensive collection of platforms and a growing suspicion that the software was never the point.