What an FDE builds in the first four weeks

Four weeks is enough to take one workflow from a vendor demo to a system the AP lead runs without the engineer in the room, if the four weeks go to the right things. A forward deployed engineer spends them on integration, exceptions, governance and handover, in that order. The vendor's platform supplies the runtime. The four weeks supply the production system.

The plan below uses an order-to-pay workflow as the worked example. The workflow is illustrative and does not describe a client; the sequence is the point.

WEEK 1 INTEGRATION

The engineer sits with the ERP administrator and maps the fields the work touches, including the custom ones a vendor demo has not seen. The agent gets a dedicated credential with read access on purchase orders and invoices and write access on nothing. It runs against last month's invoices with the output going to a file rather than the system.

Deliverable by Friday: the field map, the credential, and a match rate on real data.

WEEK 2 EXCEPTIONS

The engineer sits next to the AP lead and they read the mismatches together. Each one becomes a rule: route to the controller, hold for the vendor, or approve within a tolerance. The rules get written in the AP lead's words.

Deliverable: the exception rules, an owner for the queue, a limit on how long an item can sit, and the person who gets paged when the limit passes. A pilot with no owner for the exception queue turns into a queue the team stops trusting, and the team turns the agent off.

WEEK 3 GOVERNANCE

The engineer writes the log in the format the security lead said they would accept, before anyone asks for it. Write permission gets turned on for the narrow set of actions the AP lead signed off in week two, and no others. The runbook goes to the team that will own it.

Deliverable: an audit log the security lead has seen, a permission list with the AP lead's sign-off, and a runbook.

WEEK 4 HANDOVER

The AP lead runs it. The engineer watches, fixes what breaks, and stays through the second week of production because that is when the edge cases arrive. Then the engineer leaves and the runbook stays.

Deliverable: two weeks of production run by the team, an open issues list with owners, and the engineer off the workflow.

Why four weeks matter to the P&L

Three in four decision-makers in Futurum's survey have delayed or avoided a strategic initiative because their teams lacked the hours. Close to two-thirds say manual, repetitive work takes more than 40% of employee time. A pilot that stalls on integration or exceptions leaves the shelved project shelved. The four weeks are the difference between a demo and hours returned to a team.

The other reason is who does the work if the engineer does not. Integration, the exception rules and the audit trail get built inside your systems by someone. Without an FDE, that someone is the ERP administrator in spare time, and spare time is the resource the survey says is gone.

What Futurum found

Source facts, from Keith Kirkpatrick's report for The Futurum Group, Bridging the Capacity Gap, published August 26. Futurum surveyed 664 enterprise decision-makers and interviewed IT and operations leaders at six IFS customers running digital workers in production. 66% are likely or very likely to invest in digital workers within twelve months. Close to two-thirds report that manual, repetitive work consumes more than 40% of their employees' time. More than three-quarters have delayed or avoided a strategic initiative because their teams lacked the hours.

Kirkpatrick names three capabilities that move digital worker pilots into production: native integration, governance and auditability, and a human-in-the-loop exception model. The report describes the six IFS customers as "reclaiming dozens of hours per person per week on core procurement and order-to-pay workflows."

Two notes on that last line. It is Futurum's description of six customers of one vendor, in workflows with a system of record, a clear right answer and a known set of exceptions. I would treat it as the ceiling for a well-chosen workflow rather than a planning number. My read, not Kirkpatrick's: the report does not use the FDE title, but its three capabilities are the FDE job description, and weeks one to three above map onto them one for one.

A vendor with a production path can answer three questions

Which system does the work run in, and who administers it. Who handles exceptions today, and how many a week. What log format your security lead will accept. A vendor who can build against those answers has a production path. A vendor who answers with a roadmap has a pilot, and the pilot will stall in week one or week two.

If you are choosing the first workflow for a digital worker, Yellow Brick runs a one-hour workflow screen: system of record, exception count per week, log format, and a named owner for each. It tells you if the four weeks above fit the workflow, or if the workflow needs a different shape first.