The short answer: define roles, access boundaries, approval rules, delegates, and exceptions before retiring Excel or launching ERP across the company. Test the design on one bounded process or branch, including rejection and absence scenarios, and expand only after the end-to-end process and its reporting meet agreed exit criteria.
Clean master data is necessary, but it does not settle who may submit, edit, approve, or review a transaction. A launch can stall because access is too narrow, or weaken control because access is too broad. Both outcomes point to a governance design gap.
A phased approach is not an indefinite delay. It is a pre-launch discipline with a named scope, documented decisions, representative tests, support ownership, and a formal decision to expand or correct the design.
Why governance comes before migration
Spreadsheets and messages often rely on institutional memory. Employees know whom to call, managers approve in short messages, and finance repairs missing context later. An ERP requires the business to turn those habits into explicit and testable rules.
Retiring the old tool before those rules are settled can leave users blocked or over-privileged. The right response is to resolve the role, policy, configuration, or training gap, not to maintain two uncontrolled systems indefinitely.
Separate role, access, and approval
Role
A role describes operational responsibility: requester, buyer, receiver, finance reviewer, or manager. One person may hold several roles in a smaller company, but the combination and its risks should be documented.
Access
Access determines what a user can view, create, edit, delete, confirm, or report on. A user who needs visibility does not necessarily need edit rights.
Approval
Approval is a business decision triggered by conditions such as amount, department, or transaction type. Permission to create a request is not permission to approve it.
Design around stable roles first, then assign people. This makes transfers, departures, and temporary delegation easier to control.
Pre-launch governance matrix
| Question | Required decision | Test example | Risk if unresolved |
|---|---|---|---|
| Who enters? | Role and permitted fields | Submit complete and incomplete records | Missing or duplicate data |
| Who reviews? | Review scope and edit rights | Return a request for evidence | Unaccountable changes |
| Who approves? | Limits, conditions, and delegate | Below-limit and above-limit requests | Bypass or stalled approval |
| Who views? | Record and report scope | Branch manager views own branch | Excess exposure or missing information |
| Who corrects? | Correction types and history | Correct after rejection or confirmation | Unexplained changes |
| What about absence? | Time-bound delegation | Primary approver unavailable | Permanent delegation or backlog |
| What about exceptions? | Documented escalation | Urgent or out-of-policy request | Decisions move back to messages |
The matrix is a decision aid, not a substitute for detailed system configuration or professional control review.
Choose a useful first phase
Start with a process that matters but does not expose the company to its widest operational risk. One branch, one purchase category, or one expense approval path may provide a suitable pilot.
The first phase should have a manageable user group, clear transaction boundaries, representative exceptions, a report management can review, and a contained impact if the design needs adjustment.
Four implementation stages
1. Document and design
Map the current process, including decisions made outside the primary record. Define roles, limits, delegates, exception paths, and report ownership before configuring screens.
2. Configure and test internally
Use a test environment and representative data. Include rejection, return for correction, absence, a breached limit, and attempted unauthorised access.
3. Run a controlled pilot
Launch the bounded scope with named users and support owners. Record every workaround and determine whether it indicates a policy, configuration, data, integration, or training issue.
4. Decide whether to expand
Compare results with pre-agreed exit criteria. Correct gaps before adding another department or branch. The calendar alone should not make the rollout decision.
Permissions and approvals test checklist
- Authorised users can create only the required records within their scope.
- Unauthorised users cannot view sensitive data or alter transactions.
- Mandatory evidence is enforced at the appropriate point.
- Approval limits route transactions to the correct level.
- Requesters cannot self-approve where policy requires separation.
- Rejection and return for correction preserve reasons and history.
- Temporary delegation has approved start and end dates.
- Urgent exceptions follow a visible escalation path.
- Notifications reach the right people but are not the only record.
- The transaction result appears in the correct report.
- Role changes and departures remove obsolete access promptly.
- Support staff know how to escalate a blocked transaction.
Segregation of duties without daily gridlock
Segregation of duties prevents one person from controlling every sensitive step without appropriate review. The practical design depends on company size, transaction risk, and staffing.
Where a smaller team must combine roles, management may consider limits, subsequent review, or exception reporting under its approved policy and professional advice. A large-enterprise matrix should not be copied without considering how the Saudi business actually operates.
When are reports ready for launch?
A report is ready when decision makers agree on the metric's definition, source, timing, and scope, and tests show that the right user can view it without changing its source outside their responsibility.
Check whether users complete the process that feeds the report, whether rejected and pending records are understandable, whether branch access is properly scoped, and whether finance and operations interpret the metric consistently.
Pilot exit criteria
Agree on criteria before the pilot begins. They may include completing normal and exception scenarios, finding no unauthorised access in the test sample, resolving or accepting documented workarounds, reconciling a report sample, training the named users, and obtaining approval from the process and system owners.
No single duration or percentage is appropriate for every company. Criteria should reflect the process risk, rollout scope, and available support capacity.
Common design mistakes
Granting broad access now and fixing it later
This can expose information and establish habits before review. Start with the access each role needs, then expand it through a documented decision.
Building approvals around one employee
Absence or a role change can stop the process. Design the role, delegate, and escalation path before assigning individuals.
Testing only the ideal case
Rejection, changed values, absence, and unauthorised attempts reveal whether the design is ready.
Retiring Excel before the replacement works
Tie retirement to process readiness, migration, support, and an approved transition plan. Avoid uncontrolled dual maintenance with no owner or end date.
Frequently Asked Questions
Should we begin with broad access and restrict it later?
It is better to define and test the minimum access each role requires, then expand it through a documented decision.
Which process should receive ERP approvals first?
Choose a recurring decision with known limits, representative exceptions, and measurable operational value. The right choice depends on company priorities and risk.
Does every department need a dashboard before go-live?
No. Each decision maker needs reliable information relevant to their role. A limited, trustworthy report may be more useful than several dashboards fed by unstable processes.
How can we phase ERP without disrupting daily operations?
Use a bounded scope, test environment, named pilot users, monitored operation, support channel, exit criteria, and a clear plan for retiring the previous tools.
Who approves the access matrix?
The process owner and relevant management should approve it with input from system, finance, or control teams as appropriate. Technical configuration alone does not define business accountability.
Call to Action
Book an initial permissions and approval-path review with Neyar Solutions before finalising your ERP launch scope. We help turn roles, authority limits, and exceptions into a phased configuration and test plan grounded in your operating reality.
