A process engineer becomes an organisational bottleneck when the plant routinely depends on that same person to interpret alarms, diagnose deviations and locate evidence scattered across systems. The problem is not only their calendar. It is the design of work, information and competence that concentrates diagnosis in a single role. (HSE, workload; CRR 348/2001; IAEA-TECDOC-1510).
This piece is about that daily single point of failure. It does not reopen shift handover and tacit knowledge, the two-year expert handover before retirement or the cost of searching for plant information as its thesis. Those stay as side boundaries.
The question is more ordinary: why the same desk gets the alarm nobody fully understands, the deviation that needs reconstruction and the data only one person can pull, and what you can redistribute without inventing a second bottleneck.
James Reason argues that the systems approach concentrates on the conditions under which people work and tries to build defences to avert errors or mitigate their effects, rather than stopping at blame for the visible individual failure. (Human error: models and management). Calling the engineer “slow” or “indispensable” usually hides load, tools, roles and corporate memory. This guide helps you decide which cause to attack first.
It does not replace an SOP, a risk assessment or legal advice for a specific site. WizeeMind can locate and prepare evidence; it does not approve changes, control the process or replace human competence.
Why the same desk gets the alarm, the deviation and the data
In many plants you recognise the pattern without a dashboard. An alarm sounds that the operator cannot quite interpret. A quality deviation lands that needs batches, setpoints and events rebuilt. Someone needs a value that “is in the historian,” but only one person knows the tag, the filter or the join to MES. All three paths end at the same desk. That is not bad luck for one week.
It is how escalation was designed, even if nobody wrote it down.
HSE notes that people have a limited capacity to process information (screens, alarms, documentation and communications), hold items in memory, decide and carry out tasks; excessive workload can slow performance and produce failures such as slips, omissions or decision errors. (HSE, workload). If the process engineer is the only person who absorbs what the shift cannot close in time, their queue grows. Their judgement degrades too, like any saturated role.
HSE CRR 348/2001 frames as a central concern whether operators have the knowledge and capability to detect, diagnose and respond to incidents in time, including timely arrival of support staff. (CRR 348/2001). When the first useful diagnosis appears only once the engineer arrives, on-demand support has stopped being the exception. It has become the daily human interface for diagnosis.
Communications feed the funnel. HSE recommends identifying who needs to communicate and what their communication needs are, choosing medium and method, and using two or more methods when the message is truly important. (HSE, safety critical communications). In practice, many “urgent” notices take the shortest channel: call the engineer who “already knows.” Day one saves minutes. By day thirty it creates dependence.
HSE’s toolkit on human factors in investigations lists among latent failures ineffective training, inadequate supervision, ineffective communications, inadequate resources and uncertainties in roles and responsibilities. (HSE, Core topic 2). A process-engineering bottleneck is often the visible face of several of those conditions at once. You do not need invented prevalence statistics. Map, over one real week, how many alarms, deviations and data hunts end with the same person and why they were not resolved earlier.
If you need evidence for one concrete event, go to quality deviation analysis. The focus here is different: why that event always asks for the same interpreter.
The desk also becomes the default because informal authority outruns the org chart. Operators learn who answers quickly. Supervisors learn who can rebuild a batch story before the quality meeting. Once the habit is set, even well-staffed shifts route ambiguous cases to the same person because “they will do it anyway.” Breaking that habit needs clearer first-response ownership in the control room, not a pep talk about teamwork.
Separate request types for two weeks and you usually see a redistributable share sitting next to a smaller set of genuine process calls.
Knowledge that lives in one head
Part of the bottleneck does not live in the ticket queue. It lives in what only one head knows how to do. IAEA-TECDOC-1510 states that many experts retire taking knowledge and corporate memory with them, with tacit knowledge never extracted; the loss of employees who hold knowledge critical to operation or safety is a clear internal threat to safe and reliable operation. (IAEA-TECDOC-1510). The document is nuclear.
The knowledge-management principle still transfers to high-hazard process plants: if critical judgement lives in a single source, daily operation is already exposed even when retirement is not yet on the calendar. This section is not a pre-retirement handover plan; it is about today’s operating dependence.
The same TECDOC frames the main challenge as how to capture tacit knowledge and transfer it to successors. It distinguishes explicit, implicit and tacit knowledge, and states that tacit knowledge is the hardest to recall and therefore to transfer. Among loss-risk factors it includes employees who are the sole source of critical knowledge. (IAEA-TECDOC-1510).
That describes the engineer who “knows which filter to use” or “which exception to ignore” when nobody else can reproduce the criterion.
HSE links organisational learning to corporate memory, which must withstand staff losses and changes, including outsourcing to contractors; barriers include excessive focus on the immediate event, a culture of individual error, changes in key staff and ineffective communications. (HSE, learning). If every incident closes with a call to the expert and the learning stays in their notebook, the plant does not accumulate memory. It accumulates dependence.
CRR 348/2001 recommends that the assessment team include management or administrative staff with knowledge of operating procedures, control-system configuration, process behaviour, equipment reliability and safety. (CRR 348/2001). The report does not measure the process engineer’s daily load. It does make clear that process knowledge is an input to organisational diagnosis. If that knowledge lives in only one person, any staffing or competence assessment starts out biased.
The OECD Nuclear Energy Agency keeps an institutional knowledge-management topic on its public site. (OECD-NEA, knowledge management). That does not supply figures for chemical plants in one country. It only reminds you that concentration of critical knowledge is not a consultancy invention. For detailed capture and risk claims, the IAEA TECDOC remains the useful source.
Documenting is not the same as capturing. A folder of PDFs without a search rule, an owner and a link to the operating decision does not shrink the single point of failure. Industrial data context explains why a record without usable meaning still needs a human interpreter. Here that interpreter is usually the process engineer.
Useful capture is short, tied to a decision and testable by someone who was not in the room: which signal, which exception, which next check, which stop condition. If a second engineer or a trained supervisor cannot follow those steps without calling the first person, you still have a sole source. Plants often reward the person who “just knows” and under-reward the slower work of making that knowledge usable by others.
Until capture counts in objectives the same way firefighting does, the notebook stays private.
Systems that do not talk: the engineer as human interface
When SCADA, historian, MES and ERP do not share an operating language, someone becomes the translator. In many plants that someone is the process engineer. Not because the org chart says so. Because they know which historian tag matches which MES batch and which SCADA alarm should not be read without production-order context.
ISA-95 models enterprise-control integration in layers: physical process (0), sensing/actuation (1), monitoring and supervisory control (2), manufacturing operations management (3, for example MES) and business planning/logistics (4, for example ERP); the standard focuses mainly on the interface between levels 3 and 4. (ISA-95). The model does not claim every plant fails the standard. It explains why there is no single language by default and why integration is work, not screen magic.
Yan Lu, Katherine C. Morris and Simon P. Frechette (NISTIR 8107) write that standards are fundamental to facilitating delivery of the right information at the right time, enabling actions based on that information and reducing technology adoption and development risk. (NISTIR 8107). Without usable exchange, the “right time” is invented by whoever can cross systems by hand.
NIST describes manufacturers applying data analytics with limited success and often getting actionable results too late to have impact; much time is lost defining objectives, choosing tools and managing input data. (NIST, Data Analytics for Smart Manufacturing Systems). On the floor, that delay feels like another call: “I need yesterday’s join before the quality meeting.”
In the CRR 348/2001 assessment framework, one question is whether information-system design lets operators detect, diagnose and recover plant problems in time without having to depend on others for support. (CRR 348/2001). If the honest answer is “we depend on the engineer to open three screens and paste screenshots,” the information system is not failing quietly. It is outsourcing diagnosis to a person.
The article on SCADA, historian, MES and ERP details why the layers disagree. This section adds the human cost: the engineer as interface. Buying another screen or a connector without deciding which decision it accelerates only moves where the wait accumulates.
Try this: ask two people who are not the usual engineer to reconstruct the same event with only written guidance. If both fail at the same join, you have an interface problem, not a talent shortage. Time spent as translator also crowds out process work. The engineer who spends mornings exporting CSV files has less capacity for genuine exceptions. That is how a systems gap can look like a headcount gap.
Alarms and missing tools for the operator
Not every escalation to the engineer is tacit knowledge. Sometimes the operator asks for help because the alarm system is not doing its job. According to HSE, alarms should direct the operator’s attention to plant conditions that need timely assessment or action; alert, inform and guide the required action; be useful and relevant, with a defined response; and leave enough time before the condition escalates. (HSE, alarm management).
When that is missing, escalation to the process specialist becomes the usual shortcut.
HSE cites evidence of poorly designed alarm systems in serious incidents; for example, staff at the Milford Haven refinery faced a barrier of alarms for five hours before the incident. (HSE, alarm management). The case does not by itself describe the process-engineer role. It shows what happens when operator support collapses: the room is left without usable guidance.
The CCPS Process Safety Beacon (October 2017) says not to ignore safety alarms, to follow response procedures, to report nuisance alarms, not to change setpoints without authorisation and to review design, setpoint or procedure changes through management of change. (CCPS Beacon, 2017-10). It is a short bulletin. It does not replace a lifecycle standard. It does make clear that alarm response is procedure work, not improvised heroics at the engineer’s desk.
ANSI/ISA-18.2-2016 is ISA’s standard for management of alarm systems in the process industries. (ANSI/ISA-18.2-2016). IEC 62682:2022 is the IEC standard for management of alarm systems for the process industries. (IEC 62682:2022). Here we only assert their existence and nominal scope; we do not cite paywalled clauses. Having the standard on a shelf does not remove the bottleneck if the alarm philosophy never reaches the room with defined responses.
HSE (Core topic 3) observes that companies often demonstrate in detail the reliability of a control-room alarm, but when asked how they assure the reliability of the operator responsible for responding to that alarm, gaps usually appear. (HSE, Core topic 3). That imbalance explains many escalations: the plant trusts the signal and underestimates the shift’s ability to act without the expert.
For evidence and rationalisation without turning this into an ISA-18.2 tutorial, see alarm management with evidence and, if the problem is density and nuisance, alarm fatigue and rationalisation. The point of this section is narrower: alarms without usable guidance push load onto process engineering.
Operator tools are not only alarm lists. They include clear first actions, access to recent similar events and a way to see batch or order context without calling someone who knows the joins. When those supports are thin, even competent operators escalate early because delay feels riskier than a phone call. Take ten escalations that reached the engineer and ask whether a defined alarm response existed and would have been enough.
Many of those cases show missing or stale responses rather than missing talent.
How to share the load without creating another bottleneck
Before adding another engineer, decide whether the bottleneck is workload (redistributable tasks), competence (roles and abnormal modes not assured), systems (human interface between layers) or critical knowledge concentrated in a single source. (HSE, workload). Each cause needs a different remedy. Mixing remedies often produces a second single point of failure with a new job title.
HSE recommends considering the whole team and whether tasks can be redistributed among members or shifts; assessing workload in emergencies as well as steady state; and revisiting load for unusual activities such as start-ups. (HSE, workload). Redistribution does not mean “let the supervisor do it in spare moments.” It means writing what can be resolved in the room with usable information, what needs timely support and what stays reserved for process judgement.
HSE defines competence as the ability to undertake responsibilities and perform activities to a recognised standard on a regular basis, as a combination of skills, experience and knowledge. (HSE, competence). It states that inadequate competence management has contributed to disasters such as Esso Longford and BP Texas City, as well as to deaths, injuries and ill health. (HSE, competence).
Training is an important component, but it is not enough on its own: practice is needed, and foreseeable conditions must be covered, including anomalies and emergencies. (HSE, competence).
HSE’s toolkit (Core topic 1) states that competence to prevent major accidents is needed at all levels of the organisation, not only on the front line, and should be linked to hazard analysis and key procedures. (HSE, Core topic 1).
HSE defines the staffing problem as having the right number of the right people, in the right place at the right time, and identifies Contract Research Report 348/2001 as essential guidance for assessing staffing levels before and after a change. (HSE, staffing levels).
CRR 348/2001 contemplates scenarios where support staff are available on call-out for recovery, assuming they will arrive in time. The method does not calculate a minimum or optimum headcount; it shows where arrangements may not be robust enough. (CRR 348/2001). Do not invent engineer-per-line ratios from that report.
HSE notes that supervision problems can arise from poorly defined responsibilities, high workloads, inadequate resources or removing supervisory roles. (HSE, supervision). If supervision is already saturated, pushing more escalations onto it does not share load. It moves it.
IAEA-TECDOC-1510 describes knowledge loss risk assessment to identify where the organisation is most exposed to losing mission-critical knowledge, and calls for transfer and retention strategies. (IAEA-TECDOC-1510). NIST notes that for many SMEs analytics applications are prohibitively complex and expensive, and that a typical SME cannot afford to keep a data-analytics expert on staff. (NIST, Data Analytics).
The useful analogy is concentrated expert knowledge: if the plant can only “afford” one interpreter, any new tool that still needs that interpreter worsens the bottleneck.
One workable order: inventory what reaches the engineer’s desk over two real weeks; classify each item as missing control-room tool, missing shift competence, integration failure or genuine process judgement; attack redistributable and documentable items first; reserve headcount when staffing and competence assessment justify it. To organise quality and process evidence without replacing engineering, the engineering and quality page describes WizeeMind’s approach: prepare and locate evidence, not approve or control.
Share the load in writing. Name owners for first response, timely support and reserved process judgement, and publish that split where the shift can see it. Plants that only redistribute on paper and keep the old phone tree usually find, within a month, that the same desk is still the shortest path.
Limits: what another expert or another screen will not fix
Hiring another engineer without changing work design can duplicate the bottleneck or create an improvised relay between two equally saturated people. Buying another screen, an MES or an analytics panel without deciding which decision it accelerates often adds interpretation steps. NIST describes actionable results that arrive too late and time lost managing input data. (NIST, Data Analytics). A late tool does not free the engineer. It adds another source to reconcile.
Neither an alarm standard nor an integration model such as ISA-95 removes the single point of failure on its own: if critical knowledge remains uncaptured and corporate memory cannot withstand staff losses, the plant will still call the same desk when the case leaves the script. (IAEA-TECDOC-1510; HSE, learning; NIST, Data Analytics).
HSE defines intelligent customer capability as the organisation’s ability to clearly understand the product or service supplied; key to that capability and to core competences is retaining corporate memory, with links to turnover, succession, competence, communications and lessons learned. (HSE, intelligent customer). Outsourcing incident analysis to a contractor or remote specialist can help in peaks. If the plant loses the ability to understand and challenge that analysis, the single point of failure only changes the email address.
James Reason contrasts the person approach (blame the individual) with the systems approach, which concentrates on the conditions under which people work and tries to build defences to avert errors or mitigate their effects. (Human error: models and management). Replacing a “guilty” engineer with a “better” one without touching alarms, integration, competence and memory is, in that frame, a name change.
Automation limits matter too. An assistant can locate records or propose labelled hypotheses; it does not approve a setpoint change or replace an SOP. To avoid confusing informational help with process authority, review plant AI capabilities and limits. And to investigate an incident with evidence without making the engineer the only narrator, industrial incident investigation offers an adjacent frame.
A new alarm module does not capture the unwritten exception list. A historian connector does not invent batch meaning that never existed in MES. Tools and contracts help only where the plant also designs work, competence and learning.
If you want to review a concrete case (what reaches the desk, what is redistributable and what evidence is missing), talk to us. Bring a week of real escalations, not a software wish list. WizeeMind prepares and locates evidence; the decision and the competence stay with the plant.
Frequently asked questions
Why do so many plant incidents end up with the same process engineer?
Because the plant concentrates alarm interpretation, first-pass deviation diagnosis and evidence location in one role when work design, information and competence do not share those tasks. The bottleneck is organisational, not only a personal calendar. (HSE, workload; CRR 348/2001)
That funnel appears when the shift cannot finish detection and first diagnosis with control-room information, and support stops being the exception. Mapping one week of real escalations usually shows the pattern sooner than any generic “engineering productivity” KPI.
What is the difference between an engineer’s tacit knowledge and missing tools for the operator?
Tacit knowledge is undocumented judgement that lives in one person; missing tools are a support failure when alarms or systems do not guide detection and response in the control room. Both drive escalations, but the fix is not the same. (IAEA-TECDOC-1510; HSE, alarm management)
Treating an alarm problem as if it were only “talent” usually ends in more training and the same queue. Treating a critical-judgement problem as if it were only “another screen” leaves the criterion just as concentrated.
How can you tell whether the bottleneck is competence, workload or information systems?
Watch what breaks first: roles and abnormal modes not assured (competence), a queue of redistributable tasks (workload), or one person needed to cross layers and find data (systems). Each cause needs a different remedy. (HSE, competence; ISA-95)
A useful test: if the engineer were unavailable tomorrow, which part of the work could the shift do with better information, which part needs competence not yet assured and which part needs integration that does not exist today?
What can you do before hiring another process engineer?
Redistribute tasks across the team and shifts, improve usable information in the control room, capture concentrated critical knowledge and review staffing and supervision before adding headcount. Hiring without that diagnosis often moves the bottleneck. (HSE, workload; IAEA-TECDOC-1510)
Order matters. First classify escalations; then decide redistribution, knowledge capture or staffing reinforcement. Headcount is a tool, not the first diagnosis.
Do alarm management or an integrated MES remove the bottleneck on their own?
No. They improve support and information flow, but if critical knowledge stays in one source and corporate memory cannot survive staff changes, the plant will still call the same desk when the case leaves the script. (ANSI/ISA-18.2; HSE, learning)
A standard or an integrated system can reduce escalations caused by missing guidance. It does not replace capture of critical knowledge or role clarity when the case leaves the written procedure.
What limits apply when you outsource incident analysis to a contractor or remote specialist?
The organisation must keep intelligent customer capability: understand the service received and retain corporate memory. Outsourcing without that capability weakens oversight of the diagnosis. (HSE, intelligent customer; James Reason, BMJ)
A contractor can add method and capacity in peaks. The plant remains responsible for interpreting, challenging and keeping what was learned. Without that retention, the single point of failure only changes its counterpart.