A process is not a thing. It is an organised sequence of change.
Manufacturing, learning, diagnosis, publishing, hiring, shipping, digestion, software deployment and scientific inquiry are all processes. They transform inputs into outputs through stages, decisions, constraints and feedback.
Categorising processes well requires us to preserve motion. If we classify only the nouns involved, we lose how the system actually works.
Quick answer: how should processes be categorised?
- Purpose: what transformation is the process trying to achieve?
- Input: what enters?
- Stages: what sequence occurs?
- Decision structure: where can paths branch?
- Actors: who or what performs work?
- Output: what leaves or changes?
- Feedback: how does output influence later behaviour?
- Control: what keeps the process within acceptable limits?
- Failure: where and how can it break?
- Lifecycle: is it one-off, recurring, continuous or adaptive?
This article applies the wider framework from How to Categorise Anything to systems that unfold through time.
1. Define the transformation
A process exists because some state before differs from some state after. Name that transformation first.
2. Separate process from event
A process unfolds through a sequence; an event is a bounded occurrence. A launch event can sit inside a product-development process.
3. Separate process from project
A project is usually temporary and goal-bounded. A process may repeat indefinitely.
4. Inputs define what the process receives
Inputs may be materials, information, energy, requests, evidence, people, money or prior states.
5. Outputs define what the process produces
Outputs may be products, decisions, knowledge, records, transformed materials or new system states.
6. Stages create internal structure
Processes can often be decomposed into recognisable phases without treating every tiny action as a separate process.
7. Stage boundaries should reflect handoffs
A useful stage boundary often appears where responsibility, evidence, state or control changes.
8. Sequence can be linear
Some processes follow a mostly fixed order from input to output.
9. Sequence can branch
Decision points can route different cases into different paths.
10. Processes can loop
Revision, retry, quality control and learning often send work back to an earlier stage.
11. Feedback deserves its own classification
Positive feedback amplifies change; negative feedback can stabilise; delayed feedback can create oscillation or overshoot.
12. Control processes are different from production processes
A process that makes something and a process that checks whether it is acceptable serve different functions.
13. Core and support processes should be distinguished
Teaching may be a core educational process while scheduling and record maintenance support it.
14. Manual, automated and hybrid processes differ
Classify how much work is performed by people, machines or both.
15. Deterministic and probabilistic processes differ
Some processes produce predictable outputs from identical inputs; others contain stochastic variation.
16. Reversible and irreversible processes differ
Undoing a file edit differs from reversing combustion, biological development or a published legal act.
17. Batch and continuous processes differ
Batch processing handles bounded groups; continuous processing operates as an ongoing flow.
18. One-off and recurring processes differ
A unique emergency recovery differs from a monthly payroll cycle.
19. Adaptive processes change themselves
Learning systems, markets and AI workflows may alter later behaviour based on feedback.
20. Actors need role labels
Initiator, operator, reviewer, approver, customer and regulator perform different process roles.
21. Handoffs are structural risk points
Information, responsibility or material can be lost where one actor hands work to another.
22. Bottlenecks need separate representation
A bottleneck limits throughput even when other stages have spare capacity.
23. Queues are not the same as stages
Waiting between activities may dominate cycle time even though no transformation occurs there.
24. Throughput, cycle time and quality are different properties
A fast process can be low quality; a high-quality process can be slow. Keep performance dimensions separate.
25. Failure modes deserve taxonomy
Omission, delay, wrong routing, incorrect transformation, duplication and control failure require different repairs.
26. Failure cause and failure effect are different
A delayed handoff may cause missed delivery, but delay and missed delivery should not be treated as the same category.
27. Exceptions reveal process structure
Repeated exception paths may indicate the standard process is too narrow or reality has changed.
28. Escalation is a special routing process
Cases can move to higher authority when ordinary rules cannot resolve them.
29. Process evidence comes from traces
Logs, timestamps, documents, sensor readings and approvals show what actually happened rather than what the procedure says should happen.
30. Designed process and observed process can differ
Compare official workflow with real execution to find workarounds and hidden loops.
31. Process mining can discover real paths
Event logs can reconstruct frequent sequences and reveal variants at scale.
32. A discovered cluster of paths is not automatically a good process taxonomy
Interpret whether variants are meaningful, accidental or evidence of failure.
33. Processes can be nested
A publishing process can contain editing, production and distribution subprocesses.
34. Granularity should match control needs
Too much detail creates unmanageable maps; too little hides where failure occurs.
35. AI can classify process states
Models can infer routing, stage or anomaly from logs and text, but explicit process rules should validate consequential transitions.
36. Processes drift
New technologies, policies and workarounds can change actual execution while the documented taxonomy remains old.
37. Version process definitions
Historical records need to know which workflow and rules were active at the time.
38. A practical process record
- process ID;
- purpose;
- inputs;
- stages;
- decision points;
- actors and roles;
- outputs;
- feedback loops;
- controls;
- failure modes;
- performance measures;
- version.
39. Processes are maps of transformation
The classification should preserve what changes, how it changes, who changes it and what happens when the route fails.
40. The deeper idea
A process is a moving architecture. Good categorisation captures not just the pieces but the logic that moves one state into the next.
If events are dots in time, processes are the routes connecting those dots.
Final answer
Categorise processes by purpose, inputs, stages, decisions, actors, outputs, feedback, control, failure and lifecycle. Separate process from event and project, distinguish designed from observed execution, represent loops and handoffs explicitly, and version the process as reality changes.