CHAPTER 2
From Steps to System
Steps → Processes → Rules → Exceptions → System
CHAPTER 2
From Steps to System
Steps → Processes → Rules → Exceptions → System
Every system that runs a business is built on a foundation that predates it.
Before the system existed there were steps, the individual actions people took to get work done. Before the steps were standardised there were variations different people doing the same task in different ways. Before the variations were resolved there were inconsistencies, the same input producing different outputs depending on who handled it and when.
The system did not create the business. It formalised it. And what it formalised, the processes, the rules, the decision logic that the system enforces is only as good as the work that was done before the system was configured.
The progression from steps to system is the most important concept in process design. It is not a theoretical model. It is a description of how every operational process in every organisation actually evolved from individual actions to structured workflows to governed rules to automated systems. Understanding it is the foundation of understanding why migrations succeed or fail.
The organisation that understands this progression can look at any process in its operation and identify exactly where it sits, which steps have been formalised into processes, which processes have been governed by rules, which rules have been built into the system and which exceptions fall outside all of the above. This visibility is what makes good migration decisions possible.
The organisation that does not understand this progression cannot make these assessments. It migrates what it has inconsistencies, undocumented decisions, informal workarounds and all and discovers what that costs when the new system enforces precisely what the old system accommodated loosely.
Key Takeaway:
The progression from steps to system is not a design choice, it is what happens over time in every organisation that operates consistently. Understanding where each process sits in this progression is the foundation of every migration decision.
"Steps are where problems hide. Before any migration or transformation, understanding, documenting and standardising steps is essential to create scalable processes."
MarvinPro_|_March_2026
marvinpro.com
Steps are the individual actions performed by people or systems to accomplish a task. They are what work actually looks like at the operational level before any formal process exists, before any standard has been agreed and before any system has been configured to support them.
Steps are specific and granular. Entering data into a form. Approving a document. Sending a request to another department. Checking a record against a reference list. Each of these is a step a discrete action that takes a defined input and produces a defined output, or should, when it is performed correctly.
The challenge with steps is that they vary. Different teams develop different ways of performing the same task. Different regions apply different interpretations of what the correct action is. Different individuals bring different levels of knowledge, different habits and different tolerances for following the defined approach versus finding a faster one. Over time, the step that was originally defined as a single action becomes a collection of variations, some correct, some approximately correct and some that have drifted so far from the original intent that they produce different outcomes without anyone noticing.
This variation is invisible in normal operations because the people performing the steps know how to navigate the variation. They know which interpretation is correct for which scenario. They know when to apply the standard approach and when to deviate. They carry this knowledge informally, in their heads, passing it to new team members through observation and instruction rather than documentation.
When the migration arrives, this knowledge must be made explicit. The system cannot operate on informal knowledge. It requires defined steps, specific, consistent and documented. Every variation must be resolved. Every interpretation must be standardised. Every informal decision must be made formal.
The organisation that has already done this work arrives at migration with steps that are ready to become processes. The organisation that has not does this work under migration pressure quickly, inconsistently and at significantly higher cost.
Key Takeaway:
Steps are the raw material of every process. If they are inconsistent, every downstream process will inherit those inconsistencies into the rules, into the exceptions and into the system configuration. The investment in step standardisation before migration always produces a return.
"Processes are the blueprint of scalable operations. Design them well and systems follow. Neglect them and chaos spreads."
MarvinPro_|_March_2026
marvinpro.com
Rules are the approved policies and decision criteria that govern how processes are executed. They are what transforms a process from a description of what should happen into a governance framework that ensures what should happen actually does consistently, across every team, every region and every transaction.
Rules define boundaries. They specify the conditions under which a standard process applies and the conditions under which it does not. They define the approval thresholds that determine who can authorise a transaction of a given size or type. They establish the compliance requirements that ensure the process meets regulatory obligations. They provide the decision-making criteria that allow people to act consistently without requiring a manager to review every decision individually.
Without rules, processes are vulnerable to interpretation. Two people performing the same process will make different decisions when they encounter a scenario the process description does not explicitly address. Neither decision is necessarily wrong but they are different, and different decisions produce different outcomes, and different outcomes undermine the consistency that the process was designed to create.
Rules eliminate this vulnerability. When the rule is clear, the decision is clear. When the decision is clear, the outcome is consistent. When the outcome is consistent, the process is governable. When the process is governable, the system can be configured to enforce it.
The relationship between rules and system configuration is direct. Every rule that is clearly defined can be built into the system as a validation, a routing condition, an approval threshold or a workflow trigger. Every rule that is ambiguous, undocumented or inconsistently applied cannot be built into the system reliably. It will produce exceptions, scenarios where the system cannot apply the rule because the rule is not clear enough to be applied automatically.
Key Takeaway:
Rules translate processes into consistent, governed actions. Clear rules reduce variation, prevent errors and enable scalable system automation. Ambiguous rules produce exceptions in the system and in the behaviour of the people operating it.
"Rules are the guardrails of processes. Without them, workflows drift. With them, operations scale reliably."
MarvinPro_|_March_2026
marvinpro.com
Exceptions are deviations from established processes or rules. They occur when a step cannot be executed as designed, when a rule cannot be applied to the scenario at hand or when the system encounters a condition it was not configured to handle.
The most important thing to understand about exceptions is what they are not. They are not failures of execution. They are not evidence that something went wrong. They are signals information about the limits of the current process design, the boundaries of the current rule set and the gaps in the current system configuration.
Every exception contains a question. The exception that occurs when a transaction falls outside the standard approval threshold asks: should there be a rule for this scenario, or is it genuinely unique? The exception that occurs when a process step cannot be completed because the required information is missing asks: was the process designed to capture this information, and if not, why not? The exception that occurs when the system rejects a transaction asks: does the rejection indicate a data quality problem, a configuration error or a genuine scenario the process was not designed to handle?
The organisation that asks these questions and acts on the answers becomes progressively more capable. Each exception analysed and resolved at the design level is a scenario the process can handle automatically from that point forward. The exception rate decreases. The manual handling burden decreases. The consistency of outcomes increases.
The organisation that treats exceptions as isolated incidents, resolving each one individually without asking why it occurred or whether it will occur again does not improve. It pays the cost of each exception indefinitely, because the gap that produced it has not been closed.
Not every exception warrants a process change. A genuinely unique scenario that will not recur should be handled manually and documented for reference. A recurring exception one that occurs with regularity across multiple transactions, multiple teams or multiple regions always warrants a process change. The cost of the recurring exception will exceed the cost of the process change within a defined period.
Key Takeaway:
Exceptions are signals, not failures. Rare ones are handled manually and documented. Recurring ones demand process redesign. The organisation that manages its exceptions as design feedback becomes more capable with every one it resolves. The organisation that manages them as isolated incidents pays the same costs indefinitely.
"Exceptions are signals, not failures. Rare ones are handled manually. Recurring ones demand stronger processes."
MarvinPro_|_March_2026
marvinpro.com
In a global workflow operating across multiple countries, a request process for temporary resource allocation had evolved independently in each market over several years. What had started as a simple request and approval process had developed into a collection of regional variations different approval thresholds, different general ledger coding conventions, different documentation requirements and different timelines for each step.
None of these variations were wrong in isolation. Each had developed in response to a specific local requirement a regulatory constraint, a finance team preference, a legacy system limitation. Each was understood by the team that operated it. Each produced broadly acceptable outcomes within its own market.
The problem emerged when the organisation attempted to consolidate the process into a single global workflow that could be migrated to a central system.
The consolidation revealed that the variations were not simply different approaches to the same process. They were different processes sharing a name and a general purpose but diverging significantly in the steps, the rules and the decision logic that governed them. Standardising them required resolving every divergence deciding which approach was correct for global use, which variations were genuinely required for specific markets and which had developed by habit rather than necessity.
The work took longer than anticipated. Every variation required a conversation. Every conversation required a decision. Every decision required documentation. The process that appeared to be a single global workflow at the beginning of the project was revealed to be seven distinct regional processes that shared a name.
But the work was done before the migration began. The system was configured to a single, agreed, globally standardised process with formally approved local variations where they were genuinely required. The migration of the consolidated process was straightforward because the design decisions had already been made.
The organisation that defers this work to the migration itself pays for it twice, once in the cost of the discovery and once in the cost of the decisions made under pressure.
"When people stop following the process, a new process is created without control."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome
The progression from steps to processes to rules to exceptions to system is not a model. It is a description of what every operational process in every organisation actually is at some stage of development, in some state of documentation, with some level of consistency and some volume of exceptions that the current design cannot handle automatically.
Migration forces every process to be assessed against the same question: is this process defined clearly enough, documented completely enough and governed consistently enough to be built into a new system? For most processes in most organisations the honest answer is no, not yet.
The work of making it yes is the work of migration preparation. It is not glamorous. It is not visible in a project plan. It does not produce a technology announcement. But it is the work that determines whether the migration succeeds and it can only be done well before the migration begins.
""Steps become processes. Processes become rules. Rules become the system. Every weakness in the foundation shows up at the top.""
MarvinPro_|_March_2026
marvinpro.com