⏱ 24 min read
At 6:00 AM, a new maintenance technician arrives for first shift.
He has steel-toe boots, a lunch bag, and exactly the expression you see when someone is trying hard not to look nervous on day one. The supervisor is already short-handed. The line had an issue overnight. Everyone wants this person productive as quickly — and as safely — as possible.
And then the slow-motion failure begins.
The badge does not open the gate.
No one assigned a locker.
Mandatory safety induction is still sitting somewhere in a training queue, incomplete.
SAP access? Missing. MES? Missing. Quality system? Also missing.
The supervisor says HR was supposed to handle it. HR says plant admin manages local readiness. IT checks the queue and says there was never an approved request to provision anything. Security says they can print a temporary badge, but not for restricted maintenance areas without authorization. EHS says the worker cannot go near the line until induction is complete. TOGAF training
So the new hire stands there while six different functions discover, in real time, that “onboarding” was never actually one process.
It was a pile of disconnected assumptions.
The offboarding version is worse. A contractor finishes work during a plant turnaround, leaves the site, and two weeks later still has VPN access and supplier portal credentials. Nobody intended that. Nobody approved it. But nobody truly owned the full chain either.
That, in my experience, is the blunt truth underneath most HR process failures in manufacturing: they are rarely HR failures in isolation. More often, they are orchestration failures across HR, plant operations, IT, security, EHS, payroll, and local site administration. ArchiMate in TOGAF
This is where BPMN becomes genuinely useful.
Not because the notation is elegant. Not because governance teams enjoy process maps in slide decks. Because BPMN is very good at exposing handoffs, waiting states, ownership gaps, event timing, and exception paths that organizations would often rather not look at too closely. BPMN training
And factories have a lot of those.
Manufacturing makes HR process modeling harder than office environments
A surprising number of HR workflow designs are still built as if every worker is a laptop user sitting in headquarters.
That assumption falls apart immediately in manufacturing.
You are not dealing with one worker population. You are dealing with salaried staff, union labor, shift workers, temporary labor, contractors, seasonal workers, and often internal transfers between sites with slightly different local rules. Sometimes the rules are not just slightly different. Sometimes they are wildly different.
Physical access matters just as much as digital access. In some plants, it matters more.
Safety qualifications are not “to-do list items.” They are gating conditions. If forklift certification is missing, the worker cannot operate a forklift. If hazardous area training is incomplete, they do not enter the zone. If lockout/tagout authorization is not valid, work stops there. This is not administrative tidiness. It is operational and legal reality.
Then add site variation. One plant uses a modern badge system integrated with IAM. Another still depends on a local security office and a spreadsheet. One site provisions shared workstation access through Active Directory groups. Another has a local historian viewer that nobody remembers until audit season. One site’s supervisors are disciplined about confirming start dates. Another changes shift assignments the night before.
Roles are also more contextual than office titles suggest. “Operator” is not enough. Which line? Which work center? Which machine family? Which hazardous area? Which shift? Which union classification? Which restricted warehouse zone?
Timing is unforgiving. If first shift starts at 6:00 AM, and payroll activation or badge access is still pending at 5:45, then in operational terms the process has already failed.
This is why generic onboarding and offboarding diagrams usually collapse in factories. They model “employee joins” and “employee leaves” at such an abstract level that the output becomes useless. A plant does not need a poster saying HR sends data to IT. It needs a model that reflects worker type, site variation, safety gates, physical access, and exception handling.
If the BPMN model is not role-aware and site-aware, people may politely admire it.
They will still ignore it.
The architecture problem hiding underneath the HR process
Once you look past the HR label, onboarding and offboarding are really coordination problems across architecture domains.
The HRIS or HCM system creates the employment event. IAM creates and governs digital identity. Physical access control handles badges and zones. LMS and EHS systems manage induction and compliance. Payroll and timekeeping need activation aligned with employment status. Service management platforms generate tasks. ERP, MES, QMS, CMMS, WMS, and local applications each have their own access logic — often inconsistent, and occasionally undocumented.
That stack matters because a process model is not the same thing as an integration design.
A process model describes who does what, when, under what conditions, and what happens when something fails or waits. An integration design describes how systems exchange messages, APIs, events, payloads, and retries. A policy model defines what is allowed, who approves it, and what evidence must exist.
Teams mix these up constantly.
One group draws a business-only diagram so vague that nobody can automate it or measure it. Another group dives straight into technical orchestration, modeling every service call and field mapping until HR and plant leaders can no longer validate whether the process makes operational sense.
The sweet spot is above integration detail, but below generic business theater.
In practical terms, BPMN should sit above API-level mechanics while still showing where events originate, where approvals are required, what evidence gates progression, and where waiting states or escalations occur. If the HRIS hire event is the trigger, show that. If plant access cannot be activated before EHS induction is complete, show that. If legal retention requires mailbox preservation on termination, show that too.
I have seen this work best when the architecture team treats BPMN as the coordination contract, not the technical implementation spec. BPMN and UML together
Underneath, the implementation can use Kafka events, cloud integration services, IAM provisioning workflows, ServiceNow tasks, or custom adapters. But the BPMN remains the thing business and technical stakeholders can both argue over productively.
And they should argue over it. Quite a bit, actually.
Onboarding should not be modeled as one giant flow
“Employee onboarding” sounds singular.
It is not.
In manufacturing, it is usually a bundle of related subprocesses with different timing, different owners, and different completion criteria. Trying to cram all of it into one giant BPMN chart is how you end up with a diagram nobody reads except the person who created it.
A cleaner decomposition looks something like this:
- pre-hire to approved start date
- pre-start readiness
- day-one activation
- training and qualification completion
- post-start stabilization
That decomposition matters because the controls are different.
Pre-start readiness is about whether the person can arrive and function. Day-one activation is about whether they can actually get in, get paid, and work safely. Qualification completion often extends beyond day one, especially in regulated or hazardous environments. Post-start stabilization catches the very normal reality that not everything gets perfect before first shift.
For the top-level BPMN, I usually recommend a collaboration diagram with lanes or pools for:
- HR
- Hiring Manager or Plant Supervisor
- IT / IAM
- Security
- EHS / Training
- Payroll / Timekeeping
- Facilities / Plant Admin
That is usually enough to make handoffs visible without making the model impossible to maintain.
And yes, message flows versus sequence flows matter here. If HR triggers an onboarding event consumed by IAM, that is a message flow across participants. If IAM then runs internal provisioning tasks, that is sequence flow inside its lane or subprocess. Ignore that distinction and the diagram tends to blur organizational accountability.
That can sound pedantic.
Until you are in a workshop and everyone starts arguing about who actually owns the next step.
At that point, it becomes very useful.
A table will often tell you more truth than the polished process poster
Before getting fancy with BPMN, I often push teams to build a simple architecture table. It surfaces ownership and system reality faster than most process workshops do.
I like this artifact because it strips away decorative process language.
It tells you where the event comes from. It tells you who owns the step. It tells you which gate matters. And it tells you how the failure usually happens in the real world.
Most importantly, it reveals that onboarding is not one handoff. It is a dependency graph.
That matters when you start choosing BPMN constructs.
What the BPMN onboarding model should include — and what it absolutely should not
There are a few BPMN elements that are genuinely useful here.
A message start event from the HRIS hire event makes sense. It reflects reality: onboarding does not begin because someone feels like starting tasks. It begins because an authoritative employment event exists.
Conditional gateways are essential for worker category and plant/site. Employee, contractor, temp, union worker, internal transfer — these are not cosmetic variations. They often trigger different access rules, approvals, and training paths.
Parallel gateways are where BPMN starts earning its keep. Identity creation, badge request, safety training assignment, payroll setup, and local equipment prep often happen independently. If you serialize them on paper because it looks tidy, you are not simplifying the process. You are misrepresenting it.
Event-based gateways are useful when the process must wait for one of several things: background check completion, medical clearance, visa confirmation, union clearance, or maybe a start-date change.
Timer events matter more than teams expect. If readiness is incomplete 24 hours before start, there should be escalation. Otherwise you are not modeling a control. You are modeling a hope.
Boundary error events are worth using around provisioning failures. An MES account creation failure should not disappear into middleware logs while the business process calmly proceeds as if the worker is ready.
And there is a subtler point that people often skip: compensation and rollback thinking. If access was pre-provisioned and the start date changes, or the hire is canceled, the model needs a path to suspend, revoke, or re-time activation. Without that, organizations quietly accumulate stale access and broken status records.
What should you not model?
Every API call. Every field transformation. Every IAM internal step. Every ticket status transition in a service tool.
That level of detail belongs somewhere else: orchestration design, integration specs, event contracts, service workflows. Not in the main business BPMN.
My strong recommendation, based on more than a few painful implementations, is to maintain one business collaboration BPMN and one lower-level service/orchestration design. If you force one diagram to do both jobs, it usually does neither especially well.
A concrete onboarding example: forklift operator at Plant 3
Let’s make this real.
A new forklift operator is hired for Plant 3. The worker is union-classified. They need a site badge, forklift certification verification, safety induction, WMS access, and timekeeping activation. They do not need ERP finance access. They do need restricted permissions for warehouse zones and loading areas.
That sounds straightforward until you actually walk it.
HR enters the hire event in the HCM system with start date, site, worker type, and role information. That event is published — in a modern setup maybe through Kafka or an event broker, in a less mature setup maybe through batch integration or workflow initiation. Either way, the BPMN model should treat it as the authoritative trigger.
The process checks worker type and plant location. Plant 3 has its own site-specific requirements, so the Plant 3 onboarding variant is selected.
Then several tasks launch in parallel:
- identity creation in IAM
- badge request to the physical access control workflow
- safety induction assignment in LMS
- payroll and timekeeping setup
- supervisor task for equipment and local readiness
A gateway checks whether forklift certification is already valid and recognized by site policy. That matters because sometimes a new hire has prior certification, but not from an accepted provider, or not within the required recertification window.
If the certification is valid, proceed.
If not, schedule training and restrict the worker to observer status until qualification is completed. This point is critical. The BPMN should not simply say “assign training.” It should represent the gating effect on work eligibility.
Then set a timer. If readiness is incomplete 24 hours before start, escalate to the supervisor and plant admin. Not because escalation is bureaucratically satisfying, but because late discovery is what creates operational chaos.
Here is a simple illustration of the flow:
The architecture lesson here is simple, and often missed: “ready to start” is not a field in one system. It is a business milestone assembled from multiple systems and human confirmations.
Once teams see that, their process models usually improve quickly.
Where onboarding models usually go wrong
This is the candid part.
A lot of onboarding BPMN is poor because it is drawn by people who have never had to explain to a plant manager why a worker was on site but not operational.
The common mistakes are depressingly consistent.
First, modeling tasks as if they happen instantly after HR record creation. They do not. Badge offices have operating hours. Supervisors are on shift. Local admins are covering multiple plants. Some systems only sync every few hours. Background checks and medical clearance can lag. Even cloud-first companies still have islands of delay.
Second, ignoring local plant variation. There is often an enterprise urge to insist all sites are the same. They are not. Pretending otherwise just pushes variation into email and spreadsheets.
Third, using one role called “Manager” for everything. In reality, hiring manager, shift supervisor, plant admin, security coordinator, and app owner have different responsibilities and different response times. If you flatten them into one lane, you create fake accountability.
Fourth, forgetting contractors and transfers. Contractors are where access control gets messy quickly. Transfers are even trickier because they are not pure onboarding or pure offboarding. More on that later.
Fifth, not modeling start-date changes and no-shows. Both happen constantly. If your BPMN has no path for them, your process is not realistic.
Sixth, treating training as informational rather than gating. In manufacturing, some training is optional orientation. Some training is a hard stop. Your model needs to distinguish those.
Seventh, provisioning before approval logic is stable. I understand why teams do this. They want speed. But if role mapping and site authorization are still uncertain, early provisioning creates over-entitlement and cleanup work.
Eighth, no escalation path when the supervisor never responds. This happens more often than teams want to admit.
And finally, no explicit end-state definition. When is onboarding done? First day? First paid shift? Qualification complete? Full productivity? If you do not define the outcome, you cannot govern it.
Honestly, some of the ugliest BPMN diagrams I have seen were built to impress governance boards. They had perfect notation, careful color coding, and almost no operational value. ARB governance with Sparx EA
Pretty diagrams are cheap.
Useful ones are harder.
Offboarding is riskier, faster, and much less forgiving
Onboarding causes embarrassment and productivity loss.
Offboarding can create security incidents.
That alone should change the tone.
In manufacturing, offboarding is not just about disabling email. It touches payroll, labor compliance, physical safety, sabotage risk, intellectual property, supplier access, tooling, devices, radios, PPE, lockers, keys, and often systems that nobody remembers until something goes wrong.
A terminated line supervisor retaining historian or MES access is a real problem. A contractor still enabled after a turnaround project ends is a real problem. A retired engineer keeping remote vendor support credentials is a real problem.
And unlike onboarding, which sometimes tolerates a few hours of administrative slippage, offboarding often has hard time sensitivity. Immediate termination means immediate disablement. Planned departures allow sequencing, but even then the timing has to be deliberate.
This is where BPMN has to get more event-driven.
Offboarding has multiple triggers, not one
A lot of organizations model offboarding as if there is one trigger called “employee leaves.”
That is too simplistic to be safe.
The initiating events differ materially:
- resignation with notice
- voluntary resignation effective immediately
- retirement
- reduction in force
- involuntary termination
- contractor contract end
- internal transfer between plants
Each one has different urgency and different downstream behavior.
In BPMN terms, this is a good place for variant flows or event subprocesses. Immediate termination should trigger a near-real-time disablement path. Planned departure can support knowledge transfer, asset return, and scheduled deactivation. Contractor end dates may rely on sponsor confirmation and vendor workflow. Internal transfer is especially mishandled — it is not a clean offboarding. It is really offboard-from-site and onboard-to-site, often sharing identity but changing access scope, physical permissions, training requirements, and local payroll/timekeeping context.
That nuance matters architecturally. One employment status change can generate several downstream process variants.
If your systems and process design cannot express that, operations will invent manual workarounds.
They always do.
A realistic offboarding BPMN flow
A practical offboarding model starts with the HR termination or contract-end event. Again, that should be authoritative where possible. If your trigger is a manager email, you have a control problem before the process even begins.
The next step is a gateway determining departure type and effective timestamp.
If the departure is involuntary or immediate, the process should prioritize critical revocation:
- disable digital identity or suspend access
- revoke remote access and VPN
- notify security
- suspend badge and physical access
- notify local supervision
- preserve mailbox and files according to legal retention policy
Notice what happens here: the process splits between revocation and preservation. Those are different concerns, and in most organizations they are owned by different teams.
If the departure is planned, the flow can include:
- asset return tasks
- manager knowledge transfer checklist
- final payroll and benefits processing
- compliance closure
- mailbox forwarding or retention handling
- scheduled end-date deactivation
There should also be a parallel branch for non-federated systems and legacy applications. This is the uncomfortable truth nobody likes to hear: non-integrated legacy systems are where offboarding quietly fails. Not the big identity platform everyone demos. The strange old lab system. The local maintenance portal. The shared workstation account. The vendor access list maintained by one person who happens to be on vacation.
Timer escalation is important for unreturned assets after the final day. So is an exception path for employees on leave, remote workers, or people not physically onsite when the event occurs.
A simple sketch:
It does not need to be more complicated than that at Level 1.
The complexity belongs in the subprocesses, not in an unreadable monster chart.
The systems nobody remembers until audit time
Every manufacturing offboarding review eventually reaches the same awkward moment: someone asks about a system that was not on the original list.
Shared workstation accounts.
SCADA or historian viewers.
Vendor maintenance portals.
Building management systems.
Quality lab instruments.
Mobile handhelds.
Shift email distribution lists.
External training portals.
Sometimes it is not even a system in the normal sense. It is a list. A local admin tool. A machine account used by a team. A badge exception group. A warehouse handheld pool with weak assignment tracking.
BPMN should explicitly include review tasks for non-automated or non-authoritative systems. Not because manual review is ideal, but because pretending everything is integrated is worse.
“We’ll catch those manually” is not a control design.
It is a confession.
Architecture patterns that actually work
A few patterns consistently help.
Authoritative event pattern.
The HRIS or HCM system emits hire, termination, or transfer events. This works well when employment status is trustworthy and timely. It creates a clean trigger model. The challenge is data quality: if HR enters start dates late or changes effective dates casually, downstream disruption follows quickly.
Readiness aggregation pattern.
Multiple downstream statuses are rolled up into a business checkpoint like “ready to start.” Very useful. It gives supervisors and HR a single milestone without pretending one system owns everything. The complexity is that someone still has to define the aggregation logic and unresolved exception handling.
Parallel provisioning with gated activation.
Pre-stage access and resources, but activate only when prerequisites are met. This is often the best compromise between speed and control, especially with IAM and cloud-connected systems. The downside is rollback logic when start dates change.
Critical revoke first pattern.
For high-risk departures, disable critical digital and physical access first, then complete administrative closure. This is the right default for involuntary termination. It can frustrate teams that prefer neat sequencing, but in my view security should win here.
Human exception lane.
I strongly recommend this one. Create an explicit lane or subprocess for manual review and local exceptions. Plants always have them. If you do not model them, they still exist — just invisibly.
Deciding BPMN boundaries is an architecture decision, not a drawing preference
A useful BPMN model has deliberate boundaries.
Where does onboarding begin? Offer accepted? HR record created? Background check passed? Medical clearance received? Different organizations choose differently, but they should choose consciously.
Where does onboarding end? First day? First productive shift? Qualification completion? Full system provisioning? Again, it depends, but if you do not define the outcome, you get permanent in-flight processes that no one can close.
For offboarding, does the process end at account disablement? Asset recovery? Legal retention completion? Benefits closure? Often there are layered endpoints: operational closure versus administrative closure versus legal retention completion.
As an architect, I care less about the drawing boundary and more about three things:
- the defined outcome
- the evidence required to claim completion
- the owner of unresolved exceptions
This is where governance often fails. No one owns the process end to end across HR, IT, and plant operations, so the BPMN becomes documentation instead of a control mechanism.
And once that happens, people stop trusting it.
The artifact set that makes the reference architecture usable
One BPMN diagram is not enough. Ten is too many.
A sensible artifact set for this domain usually includes:
- a Level 1 BPMN collaboration diagram for onboarding
- a Level 2 subprocess for start-date readiness
- a Level 1 BPMN collaboration diagram for offboarding
- a system context view showing HRIS, IAM, LMS, PACS, ERP, MES, payroll, ticketing, and local plant systems
- a RACI or ownership matrix
- a data and event list including hire created, start date changed, worker type updated, termination effective, asset returned, qualification completed
These artifacts should complement each other, not duplicate each other’s meaning.
The BPMN shows coordination and timing. The system context shows the landscape. The RACI shows accountability. The event list helps integration teams and data architects understand what must move and when.
When teams try to force all of that into one mega-diagram, quality drops quickly.
Metrics are not an afterthought
I would not start the article with metrics, and I would not start the architecture effort with them either. Teams need to understand the operational pain first.
But eventually, you have to model backward from measurable outcomes.
The metrics that matter are usually pretty plain:
- percentage of workers fully ready by start of first shift
- average time from hire event to identity creation
- number of day-one access failures by plant
- percentage of offboarding tasks completed by effective termination time
- lingering access count after departure
- asset return completion time
- training completion before unsupervised work
These metrics should influence BPMN design.
If you care about readiness before first shift, add milestone checkpoints and timer escalations. If you care about offboarding completion by effective termination, model urgent branches and exception queues. If lingering access matters, create explicit review points for non-federated systems.
A process that cannot be measured usually cannot be improved, and it certainly cannot be audited credibly.
Practical advice for architects inheriting a mess
Most people do not get to design this from scratch.
They inherit a half-automated, politically sensitive, multi-site mess with old systems, local workarounds, and three competing definitions of “ready.”
If that is your situation, start smaller than you want to.
Pick one plant. One worker type. One painful scenario. Maybe contractors at a high-security site. Maybe new hourly operators. Maybe involuntary terminations where VPN linger is a known issue.
Map actual events and delays before you design future state. Not assumed flows. Actual ones.
Identify authoritative systems and non-authoritative spreadsheets. Be ruthless about this. If a spreadsheet drives badge requests, admit it. Hidden truth is still truth.
Separate process variants early. Employees, contractors, transfers, no-shows, start-date changes — these are not edge cases. In manufacturing, they are normal.
Automate high-risk handoffs first, not every task. I would rather automate termination-triggered access revocation and readiness escalation than spend six months polishing a low-risk admin subtask.
Define a “ready to start” status contract. What conditions must be true? Which are mandatory? Which are informational? Who can override? For how long? Under what evidence?
Build exception handling before polishing the happy path. That is one of the biggest lessons I have learned. The happy path is easy to draw and easy to demo. The exceptions are where the plant actually lives.
And test transfer and no-show scenarios. If your onboarding design does not survive contractors, shift changes, and local badge-office delays, it is not production-ready.
When BPMN is the wrong tool, or the wrongly used tool
I like BPMN. I use it a lot. But it gets abused.
It is the wrong tool when teams try to use it as a data model. It is also the wrong tool when the real issue is just a policy matrix — for example, which worker types require which training. Do not draw a process diagram to avoid making a decision table.
It is also badly used when the goal is compliance theater: static Visio charts nobody owns operationally, built so someone can say the process is documented.
That is not process architecture.
That is wall art.
BPMN is valuable when coordination, timing, ownership, and exceptions matter. In manufacturing onboarding and offboarding, they absolutely do. But the notation is only useful if someone owns the process outcomes and the underlying events are tied to actual systems and actual accountabilities.
Otherwise you get diagrams that look serious and change nothing.
What good looks like six months later
Let’s go back to that first-shift technician.
Six months after a sane redesign, the arrival feels almost boring.
The badge works.
PPE and locker are ready.
Timeclock is active.
Mandatory induction was completed before line access.
The supervisor sees a readiness dashboard with the worker marked ready, with one remaining non-critical task scheduled for post-start completion.
Nobody is improvising at the gate.
And on the offboarding side, a contractor’s term ends. Site access is revoked on schedule. VPN is disabled. Supplier portal access is removed. Equipment return is tracked. The one unresolved exception — a handheld not yet returned — is visible in an exception queue, not buried in someone’s inbox.
That is what BPMN is for here.
Not prettier diagrams.
Fewer production disruptions. Fewer audit surprises. Fewer security holes caused by ambiguous handoffs and invisible delays.
In manufacturing, that is not administrative elegance.
It is operational discipline.
And frankly, it is worth the effort.
Frequently Asked Questions
What is BPMN used for?
BPMN (Business Process Model and Notation) is used to document and communicate business processes. It provides a standardised visual notation for process flows, decisions, events, and roles — used by both business analysts and systems architects.
What are the most important BPMN elements to learn first?
Start with: Tasks (what happens), Gateways (decisions and parallelism), Events (start, intermediate, end), Sequence Flows (order), and Pools/Lanes (responsibility boundaries). These cover 90% of real-world process models.
How does BPMN relate to ArchiMate?
BPMN models the detail of individual business processes; ArchiMate models the broader enterprise context — capabilities, applications supporting processes, and technology infrastructure. In Sparx EA, BPMN processes can be linked to ArchiMate elements for full traceability.