Every PLM, ERP or AI program eventually needs the same answer: exactly how does the work get done? Process engineering from L1 to L4 is how that answer gets written down, at the right level of detail for each audience.
The four levels
| Level | What it describes | Example | Who uses it |
|---|---|---|---|
| L1 | Value chain | Plan, source, make, deliver | Leadership |
| L2 | Process groups | Engineering change management | Process owners |
| L3 | Processes | Raise, assess and approve a change | Business and IT design teams |
| L4 | Activities | Work instructions, roles, system steps | Configurators, trainers, agent designers |
L1 and L2 set scope and ownership. L3 is where roles, decisions and system touchpoints become explicit. L4 is precise enough for someone, or something, to follow step by step.
Why programs stall without L3 and L4
Many organisations have a tidy L1 and L2 on a slide. Implementation teams then discover, mid-build, that nobody has decided who approves a change, which system owns the BOM, or what happens when a supplier rejects a date. Every one of those questions becomes a workshop, a delay and often a customisation.
Defining L3 and L4 before configuration moves those decisions to where they are cheap to make.
One model, three uses
- Vendor selection. Requirements and scripted demonstrations come straight from L3 processes, so platforms are judged on fit to your work.
- Configuration. L4 activities map to workflows, roles and screens, which keeps systems close to standard and easier to upgrade.
- AI agents. An agent follows an L4 process like a well-trained new hire: same steps, same rules, with a human approval step where the process requires one.
Getting started
Begin with the value streams that matter most: often new product introduction, engineering change and order-to-delivery. Take them from L1 down to L4, agree them with business and IT, and use the result as the backbone of the roadmap.
