All Insights

Automation · Operating models · Product planning

How do you choose an automation project that fits the operating model?

Start with the work being performed, its variation and the result the organization needs. Include exceptions, review and the use of released capacity when judging an automation opportunity.

Understand the work before proposing the system

Choose a recurring workflow and observe how it operates. Identify the trigger, the inputs, the decisions and the completed result. Record who does the work, where it waits and which situations require judgment.

Look at the range of cases rather than only the easiest example. A common task may contain several different paths, each with its own information needs and exceptions. Distinguish the portion that follows clear rules from the portion that needs further investigation.

Establish a useful starting point for comparison. Depending on the task, that could include volume, handling time, rework, waiting time or service quality. Keep the definitions and observation period explicit so later results can be interpreted.

Design the operating responsibilities around the automation

Decide what the system should do and where a person should review, approve or take over. Give exceptions a clear owner and a way to return to the ordinary workflow. An unresolved queue is part of the operating model, even if it sits outside the automated steps.

Identify the information and permissions required for the work. Check whether they are available in the form the system needs. Include integration and maintenance responsibilities when estimating the effort to deliver the change.

Think through how the team will use any capacity released. The next step might be faster service, more work completed or greater attention to difficult cases. Define that intended benefit rather than assuming a reduction in one task automatically creates a business result.

Test the whole service at a manageable scale

Select a bounded group of cases and run the proposed approach under conditions the team can support. Include the review and exception work in the measurement. Compare the completed result with the existing approach, using similar workloads where possible.

Review costs across the complete service, including implementation, software, oversight and ongoing changes. A small automated step may save time while moving substantial work into checking or correction elsewhere.

Expand when the team can operate the workflow and explain its limits. Use the test to refine scope, responsibilities and the expected benefit. Keep the decision to scale connected to observed work and the organization’s capacity to support it.