Beyond Data Models: How Ontology & FDE Capture Manufacturing Tacit Knowledge

The Retired Scheduler Problem

A manufacturing CIO recounts a conversation with a peer: a scheduler with 32 years of experience retired, taking the factory's entire production logic with him. That logic — which order goes on which line, which customer calls demand same-day response — existed nowhere in SAP, MES, or master data systems. Within three months, scheduling errors appeared: an order sequenced behind the wrong customer, and materials prepared for a model discontinued two years prior, creating 100,000+ RMB in dead stock. The CIO concluded their systems were built on sand.

Data vs. Action

The root cause is not SAP, MES, or vendor failure. Systems run data; the shop floor runs actions. Data is static; actions are dynamic. SAP stores "Customer KH001234, XX Casting, receivables 12,847,200" but cannot answer: Is this the strategic client ordering 80M annually or the risk account overdue six months? Should we extend 30-day terms or demand cash on delivery? What approval chain and discount authority apply? These judgments — the very things that make business move — are blank in the system.

All past integration, master data cleansing, and data platform projects essentially moved data around. No one answered the fatal question: In our factory's business context, what exactly is this "customer" and what can we do with it? In academia this is called ontology .

Ontology Demystified

Originating with Aristotle ("Into what categories can the world's things be divided?"), ontology was adopted by AI engineers. Gruber (1993) defined it as:

Writing the objects, relations, and actions of a domain into rules that computers can understand, validate, and reason over.

In plain language: Ontology turns the master craftsman's mental model — what things are, how they relate, what to do when — into a factory-wide blueprint that both people and systems can execute.

Key Distinctions

Data model answers "How to store data." Knowledge graph answers "How entities connect." MDM answers "Which version is authoritative." All three are read-only — they help query, reconcile, identify "who is Customer A." They cannot act . You cannot tell a knowledge graph: "Raise Customer A's credit limit from 5M to 8M." It replies: "I see it. So what?"

Ontology is different. Beyond "who is Customer A," it defines an Action — "Adjust Customer Credit Limit" — with explicit:

Preconditions: who may press the button

Input contract: required parameters

Side effects: chain triggers (notify finance? lock open orders?)

Failure handling: rollback capability

An ontology without Actions is just an expensive Excel.

Data Without Action: The 90% Failure Rate

Over the past decade, nine of ten Chinese manufacturing "data platform" and "knowledge graph" projects died at the same spot: they built entity cards for Customer, Order, Material but defined zero actions. Business users opened the system, saw no difference from Excel, and walked away.

The one survivor did something different: it didn't try to model the whole factory at once. It picked the single most painful business question and went deep. The author's team chose sales quoting . In three months they fully defined the Customer object for that scenario: pricing rules per customer tier, discount authority and limits, end-to-end approval chain with signatories, and rollback procedure. Result: average quote response dropped from 48 hours to 6 hours. The sales director toasted: "IT actually delivered this time."

What Is FDE?

This approach now has an industry name: FDE (Forward Deployed Engineering) . Stop building systems behind closed doors. Embed technical people directly in workshops and sales offices to sit with veterans and translate their tacit knowledge into executable system rules.

A standard FDE squad has three roles:

Business Translator — knows domain and process; converts veteran jargon into objects and actions

Data/Ontology Engineer — handles modeling, cleansing, governance rules

Application Delivery Engineer — builds Agents, dashboards, approval flows

Cycle length: 8–12 weeks per business question. Solve one, retrospective, commit to ontology library, move to the next. Never attempt a factory-wide big-bang ontology — in manufacturing projects that almost guarantees failure.

Four Costly Pitfalls

Underestimating data cleansing. Modeling is only 30% of effort. 50–60% goes into merging SAP's KH001234, CRM's Account_889, and Excel's "Old Zhang's customer" into a single Customer object. It's dirty, unglamorous work; understaff it and the project slips.

Business owners in name only. Initially every object had a designated business owner. They never attended reviews; modeling became an IT self-conversation. Fixed by a hard rule: owner absent = review invalid, document unsigned. Landscape changed immediately.

Missing version control. An engineer overwrote a field definition, breaking a three-month-old report. Sales argued with a customer using stale numbers. Now mandatory: old and new versions run in parallel for one full cycle before cutover.

Veteran expertise stays in heads. The retired scheduler taught this lesson. Every FDE engagement now starts with interviews, extracting "should," "generally," "trust me" into Action preconditions and function rules. When the veteran retires, the knowledge stays.

Three Validation Gates

The CIO judges FDE delivery not by go-live or training completion rates, but by three tests:

Shadow run fidelity: Core metric variance between old and new systems ≤ 2%. If not, model is wrong — don't withdraw.

Post-withdrawal autonomy: Business users independently execute ≥ 80% of core actions. If not, training failed — don't withdraw.

Ontology library consistency: Every object, Action, and rule from the cycle is deposited back with documentation matching code. If not, knowledge leaves with people — don't withdraw.

All three must pass; missing one means the loop isn't closed.

Closing: The Missing Semantic Layer

The earlier systems weren't wasted. SAP and MES still do their jobs — recording data, running processes. But they lack a business consensus semantic layer that translates veteran experience, sales judgment, and shop-floor rules into computer-executable objects, relations, and actions. That layer is ontology. No vendor sold it in the last ten years. We have to build it ourselves, one business question at a time.