Key parameters exist only in one person’s mind
On the list of the most valuable assets in a workshop, the words “master craftsman” are never written—but any factory manager who has worked in production for more than five years knows clearly: it is often just two or three veteran workers who keep the production line running smoothly. How long a machine tool needs to be preheated in winter, which set of molds is prone to surface roughness after the ten-thousandth cycle, what problems will arise if this batch of material is fed into the machine too quickly—these answers aren’t found in any manual; they’re stored only in their minds.
Problems erupt all at once during the week when these workers retire, leave their jobs, or take extended leave: no one dares to start up a new product trial run, the same material produces defective parts when switched to another shift, and newcomers stand helplessly at their workstations clutching paper-based operation instructions. This isn’t a matter of employee attitude—it’s because the company’s process knowledge has never been turned into an asset that can be preserved, passed on, and assessed. The operation manuals on paper are often still from three years ago, long out of sync with what’s actually being done on the shop floor.
First, let’s clarify what kinds of experience there are
If we break down the master craftsmen’s experience, it actually consists of three distinct types, each requiring a completely different approach:
- Hard parameters: spindle speed, feed rate, temperature, pressure, and duration. This kind of knowledge is easiest to codify; essentially structured data, it should follow the process steps and equipment rather than individual workers.
- Judgment rules: what sound indicates tool wear, what tactile sensation reveals material abnormalities. Such knowledge must be preserved alongside typical defect samples, photographs, and textual descriptions, forming a searchable database of defect cases.
- Operational habits: which surface to wipe first, which datum to measure first. This type of knowledge should be formalized into standard operating procedures, with clear explanations of “why we do it this way”; only when newcomers understand the rationale will their actions remain consistent.
Many companies’ so‑called knowledge management systems fail to deliver because they neglect this crucial step—treating all experience as mere documents and storing them haphazardly. As a result, searching yields hundreds of PDFs, yet no one at the workstation ever bothers to look through them. The first step in managing experience is classification; only then comes storage.
How should the data be designed
In terms of system design, the key is to make the process stepthe primary anchor point for experience. Process routes, operation cards, parameter tables, and defect case studies are all linked under each process step, further connected to equipment, molds, and materials. This arrangement offers several direct benefits: when a worker scans a code to enter a particular process step, they see only the currently effective version of that step’s parameters, avoiding confusion over outdated documents; any changes to parameters must follow a formal versioning procedure, recording who made the change, why, who approved it, and from which batch it takes effect; and defect cases, complete with photos and conclusive judgments, allow inspectors to directly compare current anomalies with historical samples instead of calling retired masters for advice.
Version control is the most easily overlooked aspect. Process parameters don’t stay fixed once set; major equipment overhauls, changes in material suppliers, or new customer requirements all necessitate adjustments. The system must ensure that every batch of products can trace back to “which version was in effect at the time,” so that quality issues can be traced and resolved.
Data collection should follow the workflow
The biggest enemy of capturing experience is “having to spend extra time entering data.” Any practice that requires workers to fill in data after their shift ends will inevitably collapse within two weeks. A viable approach is to embed data collection directly into the work reporting process: when reporting qualified output, workers simultaneously confirm that current parameters match the operation card; when reporting defects, they must select the appropriate defect code and upload photos if possible. These records of how abnormalities are handled happen to be the most valuable source of judgment rules—far more reliable than “experience compilations” drawn up by organizing expert symposiums.
The same principle applies to onboarding. New employees’ training plans are broken down into small tasks by process step, with each step specifying “how many pieces to shadow, how many to perform independently, and who verifies completion.” Progress is visible in real time within the system. Team leaders no longer need to rely on memory to assign mentors; which process step a newcomer is stuck on, which types of operations they repeatedly mess up—all become clear at a glance in weekly reports, allowing training resources to be directed precisely where they’re needed.
What to look for during development and acceptance
At the development stage, three factors are paramount. First, permissions: the authority to modify parameters must be confined to process‑related roles, while operational staff are limited to viewing and confirming execution, preventing arbitrary changes by anyone who happens to have access. Second, interfaces: process data must be seamlessly integrated into the same data pipeline as work orders, job reports, and quality inspections, avoiding the creation of additional information silos and enabling true quality traceability. Third, terminal adaptation: workstation terminals should account for oil, gloves, and lighting conditions; anything that can be handled via barcode scanning or physical buttons should avoid requiring workers to type.
During acceptance, don’t focus on how many documents have been entered—instead, evaluate four key metrics: how much the independent onboarding period for new employees has been shortened, whether the defect rate in the same process has declined, the consistency of parameter application after changes, and the average response time for handling abnormalities. Only when these four figures improve does experience management truly become part of the system—not just another electronic filing cabinet.
Recommended implementation sequence
When planning implementation, don’t expect to migrate all of the factory’s experience into the system at once. Start by selecting one or two processes with the highest defect‑related losses, compile existing parameters and defect cases from the past six months into a first‑phase release, and once the data collection loop is running smoothly, have team leaders monthly supplement the system with newly discovered rules. A knowledge base is nurtured over time, not hastily assembled overnight. After three months, review those four key metrics to determine whether it’s worth scaling up across the entire factory—the numbers will speak for themselves.
The experience repository should also connect to equipment and multiple plant locations
Once the experience repository reaches its second phase, two directions offer the greatest added value. The first is connecting to equipment data: by installing data‑collection boxes on key machine tools, electrical current, vibration, and actual rotational speed can be synchronized with defect records, giving sensors the chance to partially replace the “listening‑by‑sound” judgments of veteran craftsmen—what current waveform corresponds to surface roughness defects? With enough data, such patterns naturally emerge. Experience ceases to be merely an intangible mnemonic and becomes a condition that can be encoded into early warning rules. The second direction is cross‑plant reuse: when the same corporate group operates plants in two different locations, process documentation is often kept separately and modified independently. Once experience is centrally stored in a single system anchored by process steps, new plants opening lines can directly inherit the parent plant’s complete history of parameter versions and defect cases for that process, commonly shortening the ramp‑up period by one to two months.
Conversely, a word of caution: before taking these two steps, avoid overdesigning. First, ensure that the experience loop in one workshop runs smoothly, proving that the onboarding period for new employees has indeed been shortened, before considering equipment integration or cross‑plant reuse—only then will the investment pay off.