A problem becomes an operating model question when the obstacle is who decides, who acts or how work moves between teams. A new system can support those decisions, but it cannot define them alone.
Follow the work before replacing the system
Trace a request from initiation to completion. Record where it waits, who needs to approve it and which team owns an exception.
Repeated approvals, unclear handoffs and work returned for missing information often point to decisions about the process. Establish those issues before assuming the application is the main constraint.
Separate information gaps from ownership gaps
A team may need better information to act. It may also lack authority to make the decision even when the information is available. These require different interventions.
Define the decision, the required input and the person accountable for the outcome. Then assess what the system needs to make that decision visible or easier to execute.
Make the new way of working usable
Describe the change for each role, including routine tasks and escalation paths. Test the design with the people who will follow it.
Training supports adoption, but workload, incentives and the ability to resolve exceptions also matter. A recurring workaround is a signal to review the design.
Review outcomes as well as milestones
Track a small set of measures tied to the problem: waiting time, repeated handling, service consistency or decision turnaround. Agree who reviews them and what action follows.
Use feedback from users to interpret the measures. The aim is to understand whether the changed process works in practice and what needs to improve next.
- Map the decisions and handoffs in one priority process.
- Separate missing information from missing authority.
- Agree the owner and review rhythm for the new process.
