The business process owner is accountable for the purpose, rules, outcome and changes of a process. The executor performs process steps. The approver makes a decision within a defined threshold. The technical system owner maintains the system that supports the process, but does not take the business decision. When an exception occurs, a predefined escalation threshold must route the case to a person with decision authority.
Business process management often stalls because these four roles are compressed into vague labels: "someone in sales", "finance", "IT", or "the manager". Such a description does not establish who can change a rule, who may approve a deviation, or who carries responsibility for the consequence of a decision.
A functional title is not process ownership. A sales director may own the process from quotation to order, while delegating individual decisions to a sales manager, credit controller, or warehouse manager. Likewise, an IT manager may own the technical ERP configuration without having authority to change discount approval rules.
The business process owner has a business mandate. That person should be able to answer four questions:
If the answer is "we will agree on it", responsibilities in the process are not yet sufficiently defined. Agreement can help, but it cannot replace a decision, authority, and a recorded rule.
The owner defines the process objective, acceptable outcome, rules, and measures for monitoring. This role decides on a business flow change when the change affects several teams, customers, suppliers, cost, risk, or service timing. The owner also determines who may approve specific deviations.
This person does not need to execute every step. Their accountability is not data entry, but the performance of the flow from start to finish. In procurement, for example, the owner may be the business person responsible for procurement policy, rather than the system administrator maintaining the purchase request form.
The executor performs a task according to the current rule. They gather data, check conditions, record an event, send a request for approval, or close a step. An executor should not independently interpret an unclear rule or permanently change the workflow because one case is inconvenient.
A useful instruction for the executor states:
The approver decides on a specific case within a defined authority. That authority needs a boundary: an amount, a type of deviation, a risk level, an effect on timing, or a combination of these elements. Without a boundary, approval can become a general consultation and responsibility returns to the executor.
Approval is not the same as process ownership. An approver may accept a one-off exception, but should not independently change a permanent business rule without a mandate from the process owner.
The technical system owner is responsible for configuration, integrations, access rights, data controls, and reliable system operation within their role. They assess whether a business rule can be implemented in the ERP or connected solution and identify technical consequences.
Technical feasibility is still not a business decision. The statement "the system does not allow this" should trigger a review of configuration, data, integration, and the intended rule. It should not automatically become a reason to abandon the business need.
A process becomes more stable when every handover between roles has a clear trigger, owner, and expected output. A short description for each step is useful, without making a complex diagram a prerequisite.
For every handover, record:
This framework matters especially at departmental boundaries. Sales may consider an order ready for delivery, while finance is waiting for a credit check and the warehouse is waiting for a confirmed date. Without a shared status and handover rule, each team sees only its own portion of work.
The Operational management guide can help structure daily management routines around these handovers.
An exception is not every inconvenience. An exception occurs when a case does not meet a condition in the standard flow, or when the standard procedure creates an unacceptable business risk. The escalation threshold needs to be understandable to the executor and precise enough for consistent application.
A threshold can be linked to:
Alongside the threshold, define response timing. Not every exception needs the same priority. The process should, however, distinguish a case that can wait for a daily decision from one that blocks delivery or period close.
An escalation should contain facts, not merely a request for help: case reference, deviation, consequence without a decision, proposed options, and the deadline after which a decision loses value. The process owner can then assess whether the case requires a one-off approval, data correction, technical remediation, or a change to the rule.
Consider a business flow from receiving a customer order to creating a delivery instruction. This example remains at business process level and makes no assumption about a particular ERP solution.
The sales executor enters the order and checks the customer, items, price, timing, and mandatory data. When all conditions are within the agreed rules, the order moves to the next step for planning or delivery.
When the price departs from the approved price list within a predefined threshold, the order goes to an approver with authority for commercial deviations. The approver can accept or reject the individual order and record the reason for the decision in the case record.
When the deviation exceeds the threshold, affects a contractual term, or recurs across several orders, the case goes to the business process owner. The owner does not need to manually approve every order. Their task is to decide whether to retain the rule, change the threshold, introduce a new commercial model, or begin root-cause analysis.
If the system cannot apply the chosen rule, the technical owner assesses changes to configuration, integration, data, or access control. The business owner approves the business intent of the change, while the technical owner leads implementation within the technical scope. After the change, the team should verify that the flow follows the agreed rule and that a decision record remains available to process users.
A recurring exception often exposes a process weakness, but not every recurring exception proves that a rule should be removed. Before changing the process, it is useful to distinguish four causes:
The process owner should decide on a change using recorded cases and business consequence. An executor can propose an improvement. An approver can highlight the frequency of deviations. A technical owner can explain limitations and implementation options. None of these roles alone replaces the decision on a new process.
A change should have a clear scope: which rule changes, when it takes effect, which cases it covers, who has been informed, and how the effect will be monitored. This prevents parallel instructions in email, verbal agreements, and local workarounds.
Too many approval levels may reduce the risk of an individual decision, but they often slow the flow and obscure accountability. Too few controls speed up execution, but increase the likelihood of inconsistent decisions. The appropriate allocation of authority depends on value, risk, frequency, and process consequences.
One person may also hold several roles, particularly in smaller organisations. This is not inherently a problem when authorities are explicitly recorded. The problem arises when the same person acts as executor in one moment and approver in another, and no one can later establish the rule on which the decision was made.
Process documentation does not need to be extensive. A practical starting point is often to name the process owner, describe key handovers, set escalation thresholds, and record the most common exceptions. Only then can ERP automation or integrations operate on stable business rules.
Choose a process where decisions frequently wait: order to delivery, request to procurement, or work to posting. For several recent exceptions, identify who executed the step, who had approval authority, who should have decided on a change, and where the decision was recorded.
If those answers cannot be provided quickly and consistently for every case, clarify the process before making a larger system change. ORKA's approach in ERP and process screening can provide a structured starting point for mapping responsibilities, handovers, and exceptions before selecting or adapting a solution.