The truth about the work is not in the system, it is at the workstation
How people actually work often differs from the process document and the system configuration. Only being there shows you.
FDE white paper · V1.0
Forward Deployment Engineer: definition and methodology.
Someone who understands the business walks onto the client's floor and pulls out the grunt work, the repetitive work, the wasted work and the work everyone wants to fix but nobody can — then maps it into a process, designs an architecture, matches it to existing resources, codifies it with AI software into a tool that keeps taking cost out, and stays on site to run it in.
Definition
What FDE is
An FDE (Forward Deployment Engineer) is a delivery role: someone who understands the business goes onto the client's floor, first uses observation and conversation to pull out the work genuinely worth improving, then brings to bear a composite expertise across finance, tax, law, manufacturing and process engineering to map the high-repetition, low-value grunt work into a process, design an architecture for it and match it to available resources, and finally uses AI software to codify it into a process and a tool that keeps taking cost out — staying on site afterwards to run it in and keep improving it.
The value anchor in one line: what an FDE delivers is not a software go-live, but a business that has measurably changed.
| Term | What it means | What it looks like in practice |
|---|---|---|
| Forward | The main theatre of delivery is the client's floor — not an office, and not a requirements document | Every insight comes from watching the work and talking about it in person |
| Deployment | Not sell-and-leave, but installing the capability into how the client actually operates day to day | Going live is the start; making it work is the finish |
| Engineer | Engineering discipline and method, turning experience into a system that can be reproduced | Diagnose → design → match resources → codify with AI |
First principle
Someone who understands the business, on the client's floor
What separates an FDE from an ordinary software implementer is where the role starts: with the business, not the product. The implementer's default move is to fit a finished product to the client and configure the features. The FDE's default move is the opposite — not what can the product do, but what is the client actually doing.
| Action | What it involves | Why |
|---|---|---|
| Watch the work | See how the client actually works: who does it, with what, and how many hours a day it takes | Get close to the real business, not the business as the client imagines it |
| Talk about the work | Hear why it is done this way, what they dislike, what improvements they have considered | Understand the motives and the constraints, and build trust |
| Pull out the problems | In the watching and the talking, find the work that can be improved | Produce a problem list and a set of improvement opportunities |
Why it has to happen on site
You cannot get at the problems by asking
Clients have been immersed in their own operation for years, and much of the waste has become habit. It takes an outside eye to notice it.
The will to change has to be drawn out face to face
Many clients have ideas but cannot articulate or push them. A conversation on site turns a vague complaint into a defined improvement.
On-site salvage
Four kinds of work to pull out
There are four types the FDE looks for on site. What they share is that they consume a person's hours without requiring a person's judgement.
| Type | Definition | Typical signal |
|---|---|---|
| Grunt work | Low value, physically or mentally heavy, and nobody wants it | Staff complain it is exhausting and thankless |
| Repetitive work | Done every day, over and over, consuming large amounts of time | The same action performed dozens or hundreds of times a day |
| Wasted, valueless work | Takes a lot of time and contributes nothing to the business outcome | Done for years, then found to be unused downstream |
| Improvements nobody can land | Directions the client wants to improve, and directions someone else demands they improve, but which they cannot move themselves | The boss told me to fix it and I do not know how |
The output is a problem list, not a requirements list
| Dimension | Traditional requirements list | FDE problem list |
|---|---|---|
| Starting point | What the client says they want | What looks wrong on site |
| Granularity | Features: a few fields, a few buttons | Business scenes: how this role's day gets wasted |
| Judging value | The client decides | The FDE judges professionally what is worth changing |
| Form of output | A requirements document for developers | An improvement roadmap for the client |
What to look at and what to ask
| Dimension | What to ask and watch on site |
|---|---|
| Where the hours go | Of eight hours in a role's day, how many are genuinely valuable |
| How data moves | At which points is data re-entered or carried across by hand |
| How functions cooperate | What joins one step to the next — a system, a spreadsheet, or someone shouting |
| Skill mismatch | Are expensive people doing low-value entry and checking |
| Where improvement sticks | The client wants to change it and the boss demands it, so why has it never happened |
The core of the solution
The implementer's composite expertise
Once the problems are out, the FDE does not start writing code or reaching for a template. The industry expertise of the implementer is what solves it. This is the deepest line between FDE work and building AI applications: the industry expertise comes first, the technology second.
| Domain | What it covers | What it does in delivery |
|---|---|---|
| Finance, tax and law | Professional judgement on accounting, tax compliance and legal exposure | Identifies the compliance constraints behind the work, so an improvement does not cross a line |
| Sector knowledge | Understanding how the client's industry actually makes money | Judges which processes are worth changing, and what good looks like |
| Manufacturing and process engineering | Knowledge of machining processes and the production process itself | Understands the physical constraints and process logic on the line |
| Manufacturing operations | Scheduling, materials, cost and quality logic | Finds where the real bottleneck on the line sits |
| Cost and efficiency engineering | Human-machine interaction analysis, production process design, industrial vision | Uses engineering to turn people doing the work into people and machines sharing it |
How the expertise lands on roles and functions
| Who gets the benefit | Example improvement path |
|---|---|
| Front-line operators | Hand repeated entry and checking to a process tool; people keep judgement and exceptions |
| Functional roles (finance, HR, admin) | Codify policy-driven and process-driven work into flows that move on their own |
| Production | Production process design plus human-machine interaction analysis, compressing cycle time and material handling |
| Quality and compliance | Industrial vision and rule engines in place of high-intensity sampling and manual review |
How grunt work gets handled
Proceduralise
Break the actions down into executable standard steps.
Systematise
String the steps together into rules that cross roles.
Fix it in place
Codify it in a system or a tool, so it no longer depends on anyone remembering.
What gets handled is not people's work, but the part of the work that people should not be doing.
Yidao · the rule for handling grunt work
Methodology
The four-step delivery method
The method is standardised, and the order matters: diagnose, then design, then match, then codify. Diagnosis depends on looking — going to the floor and watching, rather than thinking it through at a desk.
Step oneDiagnose the problems
Goal Find, systematically, the work in the client's operation worth changing.
| Key action | Output |
|---|---|
| Watch on site: follow the real work end to end | A map of the real business |
| Interview the roles: establish where each person's hours go | A list of pain points by role |
| Audit the data: where is data carried across by hand | A current-state data flow map |
| Identify constraints: what cannot move, in tax law or in process | A compliance constraint list |
The deliverable is a problem list plus improvement opportunities, ranked by value against feasibility.
Step twoDesign the process architecture
Goal Work out how this should actually run, and set out the target process.
| Key action | Output |
|---|---|
| Derive the target process from the current one | A target process map |
| Decide for each step: person, system, or the two together | A human-machine split |
| Define the inputs, outputs and validation rules between steps | Process rules specification |
| Design the paths for exceptions | An exception handling plan |
Architecture is led by the business; technology only carries it. Get the process right before choosing a tool.
Step threeMatch the resources
Goal Audit what the client already owns, and reach the target process with the least new spend.
| Resource | What to audit |
|---|---|
| APIs | Which interfaces the existing systems expose, and what data can be pulled automatically |
| Data | What data the client holds, of what quality, and where it sits |
| Processes | Which existing upstream and downstream processes can be plugged into directly |
| Tools | Which software and hardware the client already bought can be reused |
Reuse rather than build, call an interface rather than build a data store, plug into an existing process rather than start a new one — this is what decides whether the saving is real.
Step fourCodify with AI, and run it in
Goal Use AI software to fix the target process in place, as a tool that can run for years.
| Key action | What it involves |
|---|---|
| Select and build | Choose the tool on the conclusions of steps two and three, and build it |
| Codify the process | Write the mapped process into the tool, so the system does the work instead of a person |
| Run it in on site | The FDE stays, watches the real work run, and handles the exceptions |
| Measure the effect | Use the yardsticks in section 08: hours saved, cost taken out |
| Keep improving | Feed newly found problems back into the next round of diagnosis, closing the loop |
This step need not start from scratch every time. The kinds of work that recur have already been turned into products — see the next section.
The method in one line
Turn experience into process, process into a tool, the tool into AI, and the effect into something permanent.
| Stage | In short | Key verb |
|---|---|---|
| Step one | Experience → process | Diagnose |
| Step two | Process → architecture | Design |
| Step three | Architecture → resources | Match |
| Step four | Resources → tool | Codify |
The real difference
FDE against traditional software implementation
The difference is not effort. It is three things: where the work starts, what gets delivered, and what counts as finished.
| Dimension | Traditional implementation | FDE |
|---|---|---|
| Starting point | Deploy and configure an already productised piece of software | Go on site and pull out the client's real problems |
| Focus | How to configure the features and set the parameters | How the process runs and where the waste is |
| Source of requirements | The client states them, the implementer follows | The FDE finds them on site and judges professionally |
| Deliverable | System live, features accepted | A process and a tool, plus a business result with cost taken out |
| Mark of success | Project sign-off | A real, sustained improvement in the client's operating measures |
| Relationship with the client | Project-based; delivery ends it | Run-in based; going live starts it |
| How it scales | Copy the same product to the next client | Copy the methodology, customise on each client's floor |
From running projects to running delivery
Traditional implementation is a one-off project with a defined beginning and end, and the end is sign-off. FDE is continuous delivery: going live is where value creation starts, not where it stops — because the business moves and problems regenerate, and only continuous running-in holds the saving in place.
From selling product to selling result
In the traditional model the client pays for a software licence. In the FDE model the client pays for a business that has changed. That shift ties delivery quality to the client's interest: if the improvement did not happen, the delivery is not complete.
What we codify with
Six tools that hold the recurring work in place
Codifying with AI in step four need not start from scratch. The same kinds of work recur across clients, and rebuilding them each time is the most expensive waste there is. Yidao has turned those kinds into products, called on directly in delivery, so only the genuinely client-specific part is built on site.
| Tool | The kind of work it holds in place | Delivery line |
|---|---|---|
| Anxinshui | Manual tax risk review. 264 risk models run against 36 months of filings and invoice data to produce a quantified, industry-benchmarked report automatically | L4 tax risk scan and remediation |
| Jingying Tongbao | Building the same schedules by hand every month. Nine kinds of finance export typed automatically, producing a management dashboard, margin rankings and a rolling three-month cash forecast on the client's own machine | L5 management dashboard and cash flow |
| Neishentong + CFAudit | Rebuilding and reconciling working papers by hand. Working papers as code, reconciliations as assertions, and a break fails the build | L1 internal audit and control framework |
| R&D Steward | Capturing R&D expenditure by hand. Turns an ERP export into the R&D auxiliary ledger and the A107012 filing values on the client's own machine, computes the cap on other related expenses, then runs 24 risk checks and the supporting-file checklist | LR R&D expenditure and super-deduction |
| Cross-border Steward | Re-entering customs and refund data. Connects to the local cross-border e-commerce platforms for one-click filing under 9610 / 9710 / 9810 / 1210, with AI-assisted HS classification and a refund reconciliation ledger | L6 cross-border compliance and VAT refunds |
| Sales Enablement System | Commercial capability passed on by word of mouth. A six-module training and assessment system with a question bank, case library, end-to-end scripts and certification | Organisational enablement |
Why codifying needs products
- The same kind of work recurs across clients, and rebuilding it each time is the most expensive waste there is
- A product pushes marginal cost close to zero: the first report and the ten-thousandth cost almost the same
- The tools run on the client's own machine or in an isolated environment, and no data leaves the premises — which is why clients install them
When it still has to be built on site
- Process variants: lost capacity, yield and scrap, and savings opportunities differ by process, and are built process by process
- Interfaces: what the client's existing systems expose decides what can be pulled automatically
- Exceptions: a process can be codified, an exception cannot — that part stays with people, and with the running-in
Three hard rules, written into the architecture rather than only the contract. The data does not leave the premises: analytical tooling runs on the client's own machines or inside our isolated environment, and ledgers, bank data and invoices are not uploaded to third-party cloud services. Capture is read-only: no write access to equipment controllers, never wired into a control loop, no downtime risk assumed. Only aggregates go out: anything leaving the client is irreversibly de-identified and aggregated, and is not published at all where the sample is too small.
Value and yardsticks
What an FDE delivers, declines, and measures
The last thing a white paper owes the reader is a clear boundary and a clear measure. A delivery that cannot state its boundary ends in an argument at sign-off.
What the client gets
| Deliverable | What it is |
|---|---|
| A problem list | The first systematic view the client has had of the waste in their own operation |
| A target process | How it should run, and how people and systems divide the work |
| A codified tool | AI software holding the process in place and running it |
| A measurement basis | Hours saved and cost taken out, recomputable and traceable |
| A running-in capability | Continuous improvement, and re-engagement when problems regenerate |
What it does not do
| Not this | Why |
|---|---|
| Not pure code outsourcing | Technical implementation without business judgement produces no real saving |
| No promise of one leap | Improvement is iterative: make it run, then refine it |
| Not deciding for the client | The FDE supplies the approach and the tool; the decision stays with the client |
| No going round a compliance line | Tax and legal constraints come first; an improvement cannot cost a breach |
Yardsticks
| Dimension | How it is measured | Direction |
|---|---|---|
| Hours saved | Hours for the same role before and after | Weekly hours per role down by 30% or more |
| Cost down | Cost of processing one transaction, before and after | Unit processing cost visibly lower |
| Quality up | Error and rework rates before and after | Error rate down, first-pass rate up |
| Coverage | Roles and functions the codified process reaches | From a single point to across functions |
| Durability | The tool is still in use after the running-in period | Usage does not decay, and iteration continues |
In closing
FDE in one line
An FDE brings industry expertise onto the client's floor, maps out the grunt work, the repetitive work, the wasted work and the work nobody can land, designs it into a process, matches it to existing resources, and codifies it with AI — so the client moves from people doing the work to the system doing it, and the saving keeps.
The FDE Equation
FDE = know the business × be on site × pull out the problems × apply expertise × match resources × codify with AI × run it in
Three things to remember
Business before technology
Start from the client's business, not from a product.
Diagnose before codifying
Diagnosis depends on looking, and looking happens on site.
Result before sign-off
What is delivered is a changed business, not a software go-live.
Appendix A — Glossary
Glossary
| Term | Meaning |
|---|---|
| FDE | Forward Deployment Engineer |
| Grunt work | Low-value, heavy work that few people are willing to do |
| Systematise | Organise scattered actions into a standard process with order and rules |
| Proceduralise | Turn process steps into logic that can be executed and automated |
| Codify with AI | Use AI software to fix a process as a tool that runs for years |
| Human-machine interaction analysis | Analysing how people and machines or systems should divide work most efficiently |
| Industrial vision | Using visual recognition in place of high-intensity manual inspection and review |
| Production process | The full chain of production and machining steps |
| APIs | Interfaces a system exposes so other systems can call its data automatically |
| Running-in | Staying on site after delivery to follow through, handle exceptions and keep iterating |
Moving the client from people doing the work to the system doing it — a saving that keeps is the whole of what an FDE delivers.
Yidao Financial Consulting · FDE white paper V1.0
Have a specific problem and want a professional view on it?
Tell us the facts and we will tell you what kind of problem it is, how it is normally handled, and how far it can realistically be pushed on the evidence you have.