Part 2: The History of OEM Service Management Models
- Armands Sakne
- Feb 6
- 5 min read
Updated: Feb 7
Introduction
In the first part, we explored the structural flaws in modern OEM service models, how they trap experienced engineers in execution roles while ignoring the goldmine of field insights. Now, let's step back to understand how we got here. The current reactive after-sales model didn't emerge overnight; it's the product of over a century of industrial evolution, shaped by technological shifts, economic pressures, and organizational inertia. We'll trace this history, define key concepts like servitization, and examine the models that dominate today. This isn't just academic understanding the past reveals why many OEMs are stuck in a cost-center mindset and how they can break free.
The Historical Evolution of OEM Service Models
The roots of OEM service management trace back to the late 19th century during the Industrial Revolution, when companies like Ford and General Electric focused on mass production of mechanical equipment. Machines were simple, failures were local, and service was minimally reactive fix to maintain operation and protect reputation, not a strategic function. This era established service as a secondary, cost-driven activity, with little emphasis on learning or feedback.
Post-World War II (1950s–1970s), equipment complexity grew with electrical, hydraulic, and early CNC systems. OEMs like GM and Siemens formalized service departments, introducing warranties and planned maintenance. Yet the model remained reactive: a problem occurs, service responds. Quality was measured by response time and compliance, not systemic insights. This shift was driven by globalization and consumer demands, but service stayed a "necessary evil" rather than a value creator.
The 1980s–1990s brought globalization, electronics, and ISO 9001 (1987), pushing documentation of processes. ERP systems centralized data, but service info was treated as operational logs, not strategic input. This period marked the conceptual birth of servitization, but many OEMs interpreted standards as compliance exercises, not transformation tools.
From 2010 onward, digitalization (IoT, predictive maintenance) promised change, but many OEMs digitized execution without rethinking structure. Service collects vast data, but without feedback loops, it remains untapped leading to the hybrid models we see today.
Best known OEM service models:
Reactive (Breakdown) Maintenance
The oldest and most intuitive model 1900–1950 (early industrialization). The machine operates until it fails, then service repairs it. Documented as early as the early 20th century and still widely used. Knowledge is not systematically accumulated.
More detail about Reactive Maintenance:
Preventive Maintenance
Emerging in the 1950s–1970s, based on schedules and intervals. Effective for mechanical systems but limited for complex electro-mechanical and software-driven machines.
More detail about Preventive Maintenance:
Condition-Based Maintenance (CBM)
Developed in the 1980s–1990s using sensors, vibration analysis, and thermography. Maintenance is triggered by condition rather than time. It optimizes maintenance but does not create organizational learning.
More detail about Preventive Maintenance:
Predictive Maintenance (PdM)
Popularized after 2010 through IoT, big data, and machine learning. Predicts component failures but rarely question why systems are designed the way they are.
More detail about Preventive Maintenance:
Servitization
Introduced in 1988. Service becomes the center of the product lifecycle and the main feedback channel to design and sales.
More detail about Servitization:
Product-Service Systems (PSS)
An academic framework (Tukker, 2004; ISO/TR 14062) distinguishing product-oriented, use-oriented, and result-oriented systems.
More detailed about PPS by Chief Life Cycle Engineer at Rolls-Royce:
Service-Dominant Logic
A systems and marketing theory (Vargo & Lusch, 2004) stating that value is created in use, not at delivery. Field service becomes the primary observer of value creation or collapse.
More details about Service-Dominant Logic:
IT Parallel: Site Reliability Engineering (SRE)
Introduced at Google around 2003. Recognized that incident resolution is not the same as system reliability. SRE formalized learning from production behavior as a function, not a side effect.
This model has not yet been fully adapted to industrial service, but it is the closest parallel to what modern Field Service Engineers already do informally.
More details about SRE:
Historically and Academically Defined Industrial Service Models
Most OEMs operate hybrids, blending old and new approaches. Here's a breakdown:
Model | Core Logic | Key Features | Limitations |
Reactive (Breakdown) Maintenance | Fix when broken | Local repairs, individual craftsmanship | No learning, repeated failures |
Preventive Maintenance | Scheduled servicing | Time-based checks | Over-maintenance, ignores real conditions |
Condition-Based Maintenance (CBM) | Monitor condition | Triggered by sensor data | Limited to symptoms, not roots |
Predictive Maintenance (PdM) | Predict failures | Data-driven forecasts | Data collected but often not acted on systemically |
Servitization | Sell outcomes | Integrated product-service bundles | Requires cultural shift; often superficial |
Product Service Systems (PSS) | Hybrid offerings | Product-oriented to result-oriented | Complex, uneven adoption |
Site Reliability Engineering (SRE) | System reliability | Learning from production behavior | Not fully adapted to industrial OEMs |
These models evolved from mechanical simplicity to cyber-physical complexity, but many OEMs cling to reactive roots due to historical inertia.
Table introduction
The comparison below is not about today’s Field Service Engineer being “better” or “smarter” than in 2005. It is about the fact that the scope of functions and responsibilities surrounding this role has grown exponentially, while academic education, service methodologies, and organizational frameworks have largely remained unchanged.
In 2005, an industrial plasma cutting machine was complex, but still a relatively local system. Most problems existed within a single domain and could be resolved through direct cause-and-effect reasoning.
By 2026, the same machine has become a cyber-physical system, where outcomes are determined by the interaction of mechanics, electrical engineering, software, process physics, and human behavior.
This table does not focus on technology names. Instead, it shows how what a Field Service Engineer actually has to do and understand has changed, simply for the machine to operate as intended.
Plasma cutting 2005-2026
Function area | Field Service Engineer – 2005 | Field Service Engineer – 2026 |
Mechanical installation | Core responsibility | Still core, but only one part of the whole |
Electrical installation | Basic power and signals | Power, grounding, EMC, fieldbus integrity, LAN |
Machine commissioning | Axis check, basic cuts | Full system validation across subsystems |
CNC setup | Basic parameters | Advanced motion logic, multiple technolgies, adaptive features |
PLC interaction | Minimal or none | Reading logic, understanding interlocks, safety |
Safety systems | Physical guards, E-stops | Safety PLCs, zones, certifications, diagnostics |
HMI usage | DOS + Buttons | OS, permissions, modular screens, misuse patterns |
Software versioning | None | Firmware, CNC, PLC, HMI dependency management |
CAD/CAM interaction | Basic G code | Continuous post-processor validation |
Thermodynamic process analysis | None | Gas dynamics, HiDefinition |
Process quality | Visual cut check | Hole quality, bevel accuracy |
Gas & consumables | Manual setup | Integrated process and limits |
Networking | None | Ethernet, VPN, remote access, cloud connectivity |
Diagnostics | Instruments + intuition | Logs, alarms, cross-system diagnostics |
Data interpretation | Personal intuition | Continuous data streams without ownership |
Operator training | Basic machine use | Process discipline and misuse prevention |
Customer interaction | Operator only | Operators, production managers, owners |
Cross-machine comparison | Rare | Constant OEM vs competitor benchmarking |
Failure analysis | Local root cause | Multi-system, interface-driven causes |
Feedback to OEM | Informal | Still informal, despite higher impact |
Decision influence | Very limited | Still limited in most OEMs |
Vertical Service Management vs. Horizontal Technology Reality
The image also makes one thing very clear: traditional service management models do not anticipate horizontal links with other organizational functions.
In practice, service management is structured as an isolated vertical unit. Its core responsibilities are limited to financial oversight, personnel supervision, and providing basic customer support within a service framework designed for the 1950–2005 generation of industrial systems.
Within this model, service has almost no functional value for R&D or Sales. There is no systematic mechanism for transferring field data into design decisions, product improvements, or sales configurations. Service information remains operational, local, and short-lived.
As a result, the service organization operates as an isolated subsystem inside the company. It keeps legacy systems running and customers minimally supported, but it does not contribute to learning, innovation, or strategic differentiation. From an organizational perspective, service exists alongside R&D and Sales, not between them.
It is also the starting point for what I call the T-Index (Technology Framework) based metodology, which I will introduce in Part 3.
Comments