How TecAce FDEs Deliver AI Transformation Consulting in the Field
Updated: 4 days ago
In our previous article we explained what an FDE (Forward Deployed Engineer) is. This article introduces what an FDE actually does in the field.
Across multiple AX projects we conducted a large number of interviews, and in the course of those diagnostics we identified many pain points.
We explain the common root causes behind those pain points, and what TecAce solved with AI and how it was solved.
In this article, AX refers to AI Transformation — applying AI to work in order to change the way work is done. If moving work into digital form was DT (Digital Transformation), AX is the stage built on top of it, where the inputs for judgment are produced automatically and repetitive execution is handed over to AI. TecAce performs both, and this article is a field record from one of those AX projects.
At a glance | Details |
Who this is for | Organizations that want to adopt AI but are unsure where to begin |
The problem | Difficulty determining which AI to use to improve the way the company works. (Why AI adoption that starts without a diagnosis stops at the demo) |
Core methodology | On-site survey → full record of pain points → identification of common causes → design of application order → build and adoption → asset conversion and handover |
Evidence base | Experience delivering multiple AX projects (including on-site consulting and field diagnostics), numerous department interviews and on-site surveys |
TecAce does not sell packaged solutions. Even within the same industry, pain points appear differently in each domain, so we diagnose them afresh every time and propose a different approach in each case. The goal is not the polish of a report but the operational efficiency the business actually feels.
The problems we found were not separate problems
The first reaction of executives who receive our diagnostic report is usually surprise — at how many different problems turned out to exist inside the company. We do not, however, focus on the number of pain points collected.
At one client running a direct-to-consumer e-commerce operation, the problems identified were not separate problems but symptoms derived repeatedly from the points where connections between systems were broken. For example, the chatbot could not look up order history, so a person had to search for it every time; sold inventory was not reflected on the storefront, so out-of-stock labels appeared late; and shipping information was left in no system at all, so every customer inquiry had to be checked again. On the surface these were different inconveniences, but traced back to their root they all came from the same common cause: connection.
If those connection points are left as they are and other visible problems are addressed first, symptoms that appeared solved come back. The correct approach is therefore not to build a "list of improvement tasks" but to find the broken connection points first.
At the center of a problem encountered especially often in accounting is calling the same product by a different name in each department. For example, the purchase-order spreadsheet from the supplier uses one notation, the online store uses a product name, the ledger uses an item name, and the reporting spreadsheet uses whatever name the person in charge assigns at the time — and in many cases nothing specifies which of these is authoritative. As a result inventory and sales cannot be linked in a single table, and every month someone matches them up by eye.
The impact of inconsistent naming does not end with differences in notation. Linking inventory and sales data to a single standard requires manual reconciliation by staff every month, and the time that reconciliation takes becomes a factor that governs the closing schedule. A naming scheme that was never unified also reproduces the same error throughout downstream work — closing figures, order quantities, sales plans. This should therefore be treated not as a data-consistency issue that can be tidied up later but as a fixed monthly labor cost.
The same phenomenon was confirmed in other projects as well. When the pain points were grouped by theme, the four largest clusters were repetitive manual work, data standards and master data, organization and knowledge sharing, and system disconnection.
The Audit stage concludes with a prioritized diagnostic report
The deliverable of the Audit stage is not a simple list of problems but a diagnostic report grouped by root cause and ranked by priority. Repetitive manual work, data standards and master data, organization and knowledge sharing, system disconnection — the causes organized into these four groups are then ordered by scope of impact and difficulty of resolution.
That order becomes the starting point for the next stage.
Now we decide what to automate, and how far
The Eval stage translates the order in the diagnostic report into design. What is decided here is not "whether to use AI" but what to place in which segment. Even within a single process, the segments to be handled by rules, those that require a model's judgment, and those a person must own are all different.
Once priorities are set, each process is broken down into detailed units. In doing so we draw a specific line between the segments AI can realistically handle and those that must remain under the judgment and accountability of the person responsible. If this boundary is not clearly defined at the design stage, confusion over automation scope arises during build, which makes role separation by work unit a step that must come first.
Standard ERP and groupware are designed for general workflows. Exception work that exists only at a particular site, and integration with external systems, are therefore not handled by their general-purpose functions and end up being done by people opening Excel every day to reconcile data by hand. AI agents fill exactly this gap. By having an agent take over the matching and data-entry work people performed repeatedly, the way exception work is handled can be improved across the board without changing the structure of existing systems.
Underneath all of this is the knowledge hub
And underneath all of this lies the knowledge hub. A general-purpose model does not know our company's context. The moment files scattered across individual PCs come together in one space, that data becomes the input for AI inference, and only then does an 'AI that knows our company' become possible.
Automation that has passed validation is defined as a reusable skill and shared within teams and across departments. In on-site projects this approach turned a large number of repetitive tasks across multiple departments into automation cases. Reconciling unit prices that differed by client and approval document against historical data by hand at revenue close; assembling source files in assorted formats to build daily product statistics; entering multiple service numbers from image-PDF telecom invoices split out by department; picking exterior parts out of a BOM by eye and writing specification sheets one at a time — all of these became processes where you put in the source and an approvable result comes out.
We build to the point where the client can operate it themselves
The Deploy stage does not end with the build. Its scope extends to the business actually using it and the client being able to operate it on their own.
When repetitive, high-fatigue work is automated first and the efficiency is proven, the spread happens naturally among the people doing the work.
Once usage has settled in this way, the work of transferring operational ownership follows.
AI Transformation Consulting is already proven at many companies and is spreading rapidly
The FDE is not one company's experiment. It began in the early 2010s when Palantir put engineers on site in environments where clients could not hand over requirements as documents, and it has since become the method companies commonly choose when they want to put AI onto real work.
Pulling together what has been reported, this trend has spread across the industry over the past few years. Frontier AI companies have set up organizations dedicated to deployment, and global consulting firms have created organizations of the same shape. The reasons converge on one point: the bottleneck is field deployment, not model performance. However good a model is, it goes no further than a demo unless it is fitted to the workflow, the existing systems and the exception handling.
The real difficulty in adopting AI is not which model to use. It is how to place it on top of our own workflows and existing systems. TecAce FDE starts exactly there. We go on site and verify the work, decide what to solve and in what order, and put small deliverables into the hands of the business first.
One diagnosis is enough to start. A few days of on-site survey are enough to produce a map of which problems came from which causes and what should be solved first. You can decide whether to proceed to the next stage after seeing the diagnostic results.
When work that repeated every week is automated, a question naturally follows about the role of the person who handled it.
Only when the repetition is stripped away does the essence emerge. An organization where one person did one person's worth of work becomes an organization that does more work, more accurately, with the same headcount. What AI replaces is not jobs but repetitive work that requires no judgment.
Intelligence is now a resource anyone can obtain. What makes the difference is where, and in what order, that intelligence is applied within the complex operational reality of a company. TecAce FDE proves this directly in the field.
Frequently Asked Questions (FAQ)
Q. Can we get just the diagnosis on its own?
Yes. The diagnosis is an independent deliverable in itself. Few organizations hold an accurate map of their own workflows. Two days of on-site survey are enough to produce dozens of problems, their common causes, and a roadmap of what to solve in what order. You can decide whether to proceed to the next stage after seeing the diagnostic results.
Q. How many people and how much time do the interviews require?
The on-site survey takes place over a short period and includes department interviews and observation of actual work. There is no need to prepare materials separately. Unorganized originals in fact lead to a more accurate diagnosis.
Q. How long does the whole project take?
The diagnosis is short — a matter of days including the on-site survey and the write-up. The build period after that varies with the number of target processes and the state of existing systems, so we schedule small deliverables in order of the priorities in the diagnostic report. On-site intensity is highest at the beginning and decreases toward the handover stage. We propose exact timelines and costs once the diagnosis has fixed the scope.
Q. Do we have to change the ERP or the systems we currently use?
No. TecAce works on the principle of coexistence with and reinforcement of existing systems. An AI strategy that tells you to discard systems built over years of cost and effort will fail. In our actual projects too, the existing ERP was left in place and we worked by putting a conversion layer between the two systems or by automating pre- and post-processing.
Q. How do you handle data security and confidentiality?
Before we start, we set out the scope of data handling in writing along with a non-disclosure agreement. Access rights are limited to the minimum needed for diagnosis and build, and as a basic principle source data is handled inside an environment the client designates. What data is used, how far it is used, and what is not used are written into the scope section of the diagnostic report.
Q. Once the project ends, can we operate it ourselves?
That is our goal. Training and handover are allocated separately in the final stage, and the client takes over all configuration rights along with the AI usage rules, the role-based guides and the operating manuals. Every process is learned by two or more people so that a state where only one person knows it is not created again.
Q. Is this suitable for a company of our size?
TecAce FDE primarily serves mid-market and small-to-medium enterprises that have no dedicated AI organization or only a small team. We adapt enterprise-grade methodologies proven in large corporations and the public sector to the speed and budget of a mid-market company.
Comments