From Operational Problems to Working Systems: An Applied Framework for Forward Deployed Engineering

Most technology projects that disappoint work fine technically, and still fall short because the solution was chosen before anyone understood the operating problem. Here's an eight-layer framework for tracing a business problem all the way to a measured result.

Summary

Organizations keep investing in software, automation, data platforms, and AI to perform better, and many of those projects never produce lasting improvement in how the business runs, usually because the technology arrives before anyone has understood the operation underneath it. A recurring problem can start in organizational structure, workflow design, decision rights, data quality, incentives, policy, handoffs, or the way those pieces interact, and technology aimed straight at the visible symptom tends to digitize the inefficiency, automate the ambiguity, and scale the flaw.

The Revuity Operations Systems Framework, introduced here, is a practical model for moving from operating problems to measurable business results through eight connected layers: the operating problem, the business function, the workflow and its friction, the data and decision logic, the system architecture, the software and AI build, deployment and adoption, and finally the operational outcome. Software and AI sit inside a larger system of people, process, and technology, and good results depend on keeping an unbroken line from the original operating problem to the system that finally goes live.

---

Starting from the wrong end

As organizations grow more complex, the same problems keep appearing. Work moves too slowly, information scatters, people redo the same work, decisions vary from team to team, compliance depends on someone interpreting the rules by hand, systems don't talk to each other, reports arrive late or can't be trusted, important knowledge stays with a few individuals, and the effort spent coordinating keeps climbing.

The usual response is technological: buy a platform, automate a workflow, build a dashboard, add an AI assistant. Each of those can help, and each carries the same risk, which is starting from the technology instead of from the operation it's supposed to improve. The result is often a system that works technically and leaves the original business problem roughly where it was.

The more useful question is what operating condition has to change, and what system has to exist for that change to happen reliably, and that's where the framework begins.

---

A business problem and a system problem

People describe problems in local terms: "we need better reporting," "approvals take too long," "we need a CRM," "we need an AI chatbot." Those are accurate descriptions of symptoms, and they don't yet identify the condition underneath, even though each possible cause calls for a different fix.

"Approvals take too long" might trace back to unclear decision rights, too many approval layers, missing information, steps in the wrong order, inconsistent readings of a policy, too few people, slow systems, scattered data, or controls designed for a different era of the business. An organization that assumes the problem is technological may build a faster approval app without ever asking whether the approval structure should exist at all, and that's the difference between automating a process and redesigning a system.

A useful diagnosis separates three levels.

The symptom is the visible pain. Reports take five days to produce.

The mechanism is how the problem happens. Data gets exported by hand from four systems, reconciled in spreadsheets, reviewed by two teams, and reformatted for executives.

The system condition is the structural reason the mechanism exists. The organization has no shared data model, no automated integration, no clear owner for each metric, and no standard way of building reports.

The technical fix should come from the system condition.

---

The operation as the thing being studied

The framework studies the operation as a whole, with the software project as one part of it. An operations system is the connected structure an organization uses to turn resources, information, decisions, and human effort into results, and it includes people, roles, workflows, policies, decision rights, information, business rules, incentives, software, data, interfaces, automation, governance, controls, feedback loops, and outside constraints.

Results come from how people and technology interact, so software can't be judged apart from the people using it, the decisions it supports, the incentives around those decisions, the information available, the organization's structure, and the work it sits inside, which is why the same technology can produce very different results in two companies, since everything around it is different.

---

Where technology-first projects go wrong

Six patterns come up again and again. The solution gets chosen before the problem is understood, and the requirements bend around the technology. Existing dysfunction gets built into the software, so the process runs faster without running better. The unwritten judgment calls experienced people make on ambiguous cases never get written down, so automation either fails or behaves inconsistently. Data problems surface late, because data was treated as an implementation detail instead of part of the design. Launch gets treated as the end, with little thought for adoption, governance, or who owns the system afterward. And technical measures like delivery dates, uptime, feature completion, and model accuracy stand in for business results, so a system can perform well technically while leaving revenue, cycle time, cost, quality, risk, and capacity untouched.

---

The eight layers

The layers are listed in order for clarity, and in practice the work loops back, since something learned at one layer often means revisiting an earlier one.

Layer	Core question
Operational Problem	What recurring condition must change?
Business Function	What part of the organization produces or owns that condition?
Workflow & Friction	How does the work actually move today?
Data & Decision Logic	What information and rules drive action?
System Architecture	What structure must exist to support the desired operation?
Software / AI Build	What technical capabilities should implement that architecture?
Deployment & Adoption	How does the system become part of real work?
Operational Outcome	Did the condition actually improve?

Operational problem

The first job is to name the recurring condition, kept deliberately separate from any solution. The result should be a short problem statement, like customer onboarding takes 19 days on average because data collection, compliance review, and account setup happen across disconnected systems with unclear ownership. Compare that with we need an onboarding portal, which assumes the answer before describing the problem. The most common mistake here is accepting whatever someone asked to have built as the definition of the problem.

Business function

Once the problem is clear, the analysis turns to the part of the organization responsible for the result: its ownership, goals, measures, dependencies, decision rights, incentives, regulatory duties, and constraints. Organizations often work differently from how they're described, with one owner on the org chart and several people sharing authority in practice, or an official system of record quietly bypassed in favor of spreadsheets. The forward deployed engineer needs the operation as it really runs, which is often different from the version on paper.

Workflow and friction

This layer maps how work actually moves, including the informal adjustments people make: triggers, tasks, handoffs, approvals, queues, delays, rework, escalations, exceptions, and dependencies. Friction deserves to be understood before it's removed, because a workaround usually shows where the official system doesn't support the real work. A spreadsheet points to missing functionality, a Slack thread points to a missing notification, and a recurring meeting points to information nobody can see, so each workaround is evidence about the design the organization actually needs.

Data and decision logic

Operations run on information and on rules, and both need to be made explicit before a design can be trusted. On the information side that means source systems, owners, structure, quality problems, access limits, delays, duplication, lineage, and conflicts over which system is the record, all gathered around one question: what has to be true, available, and trusted for this process to work? On the decision side it means thresholds, eligibility rules, approval logic, priorities, routing, and escalation criteria, much of which lives only in the judgment of experienced people who've never had to write it down. The layer matters most for AI, since involving language or ambiguity is a weak reason on its own to hand a decision to a model, and the design has to settle which decisions need fixed rules, which benefit from AI reasoning, and which need a person.

System architecture

Architecture turns an understanding of the operation into technical structure: application boundaries, services, integrations, data models, access controls, workflow orchestration, and AI components, and it's where business design and technical design meet, as decision authority becomes permissions, workflow dependencies become orchestration, policies become rules, organizational boundaries become access controls, handoffs become system events, and operating measures become monitoring.

Software and AI build

Building starts once the earlier layers are understood well enough. The right technical answer, whether custom software, configured SaaS, integrations, automation, data pipelines, AI agents, or some mix, depends on the operational need, and neither custom software nor AI should be the default. The guiding question is what's the smallest reliable technical system that makes the desired way of operating possible?

Deployment and adoption

A technical system becomes part of the operation only once it's woven into real work, which means migration, training, adoption, documentation, a planned transition, permissions, support, monitoring, and a clear owner. Forward deployed engineering keeps people close to the operation because many assumptions can only be tested through use: people behave differently from the design documents, edge cases appear, workflows shift, and information that seemed important fades while something that seemed minor turns out to matter. Deployment is another stage of learning, well beyond a release date.

Operational outcome

The last layer measures whether the operating condition actually changed, through cycle time, cost, throughput, error rates, revenue, compliance, capacity, quality, reliability, or risk, and it judges the system against the original problem. If the problem was slow onboarding, the question is whether onboarding got faster, more reliable, or cheaper, and the portal launching is only a step on the way to that answer.

---

Outputs and outcomes

This distinction deserves its own moment. Outputs are what the project produced, like an application, a dashboard, an API, an AI agent, or a data warehouse. Outcomes are changes in how the organization performs, like a 35% cut in processing time, fewer manual errors, better compliance, higher conversion, or lower operating cost, and a mature practice measures both while aiming at outcomes.

The framework keeps going after launch, too. Once a system is live, new evidence appears, from new bottlenecks and changing behavior to unexpected failures, outdated policies, and design limits, and that evidence feeds the next round, so each outcome becomes the starting point for the next improvement.

---

A worked example: "we need an AI chatbot for employees"

A technology-first build starts by choosing a model and indexing company documents. The framework asks different questions, layer by layer. Why do employees need it, perhaps because they can't reliably find current policy guidance? Which teams write and maintain that guidance, where do people search today, and what happens when they can't find an answer? Which documents are authoritative, which rules need interpretation, and what information is restricted? How should retrieval, access control, citations, versions, and escalation work, and what mix of retrieval, model reasoning, structured output, and fixed controls fits? How will people reach the system, who owns the questions it can't answer, and how does outdated content get fixed? And in the end, does it cut search time, make answers more consistent, and lighten the support load?

The first approach builds a chatbot, and the second builds a working knowledge system for the organization that happens to use AI.

---

What this means for AI in particular

Many organizations today take an access-first approach to AI: buy licenses, hand out tools, encourage experimentation, and sort out governance later. That can spark useful ideas, and it can also produce inconsistent prompts, duplicated work, unreliable output, scattered knowledge, unsanctioned AI use, security risk, and very little shared learning.

A systems-first approach asks a different set of questions up front: what work are we trying to improve, what information does it need, which decisions follow fixed rules, which benefit from AI reasoning, and which need human judgment, what context has to persist, what controls are needed, and what business result should improve? AI then becomes one component of the design, and the human side matters as much as the technical side, since AI changes who does the work, how decisions get made, what knowledge has to be written down, and where accountability sits. Even the most advanced AI system will fail if the organization around it can't absorb it.

---

From projects to lasting infrastructure

Projects end, and the operations they touch keep running. When transformation is treated as a series of projects, the knowledge gained often leaves when each project closes. When the work is treated as lasting operational infrastructure, attention turns to ownership, maintainability, visibility, governance, reuse, and continuous improvement, which is how Revuity Systems approaches technical delivery.

Most organizations need better operations systems more than they need more software. Software, data, automation, and AI are ways to build those systems, and none of them replaces understanding how the organization works. That understanding comes before any code: seeing how work moves, where information breaks down, and where decisions happen, turning that picture into a design, building only what the operation needs, putting it into real work, and measuring whether the underlying business condition improved, which is the heart of forward deployed engineering, and the difference between delivering software and engineering an operation that works.

Back to articles