Business Process Improvement Starts Before Automation

01

The Automation Question Comes Too Early

Consider an illustrative example. A growing business receives customer inquiries through several channels. Employees review the requests, enter information into a business system, coordinate with another department, obtain approvals and communicate the outcome. Management notices that responses are slow. The proposed solution is workflow automation.

But several different problems could be contributing to the delay. Customer information may arrive incomplete. Employees may enter the same information into multiple applications. Approval responsibilities may be unclear. Work may wait between departments. Employees may follow different procedures for similar requests. Existing systems may not share relevant information.

Automating the initial intake step might improve one part of the process while leaving the other delays untouched. The issue is not necessarily that automation is the wrong technology. The issue is that the business has not yet established which problem the technology should solve.

APQC's 2026 Process and Performance Management survey, conducted with 156 practitioners, found that 82% of 154 respondents planned to invest in digital tools within 18 months. Yet only 5% of 156 respondents reported that digital and AI systems were fully integrated across functions. The survey also identified end-to-end process mapping as a leading process-management challenge, cited by 31% of 147 respondents.

These figures come from different respondent groups within the same survey, not a direct comparison of identical groups. They nevertheless illustrate an important organizational challenge: technology investment and process integration do not automatically develop at the same pace. [1]

Before selecting technology, establish what is happening across the process and why it is happening.

02

Understand the Process Before Changing It

A business process rarely belongs to just one person or department. A single customer request, purchase, service delivery or internal approval can involve multiple employees, applications, decisions and information exchanges.

Examining one department in isolation can hide problems occurring between departments. A sales team may complete its work on time while the wider customer onboarding process remains delayed. The actual constraint may be an approval, an incomplete record or a handoff between sales and operations.

That is why process improvement requires an end-to-end view. A useful assessment examines the process purpose, its boundaries, activities, ownership, information, systems, exceptions and dependencies.

APQC's guidance on end-to-end process mapping recommends documenting the complete flow from its initial trigger to its final outcome, including roles, handoffs, decision points, inputs, outputs and connected processes. It recommends documenting the current state before designing the future state. [2]

The distinction between the current state and the intended state is important. The current-state view describes how work is actually performed, including variations and workarounds. The future-state view describes how the process should operate after improvement.

Without understanding the first, designing the second becomes an exercise in assumptions.

• Purpose: What business outcome should the process produce?
• Boundaries: Where does the process start and finish?
• Activities: What work is performed at each stage?
• Ownership: Who is responsible for each activity and decision?
• Information: What data enters, changes or moves between stages?
• Systems: Which applications support the process?
• Exceptions: What happens when the normal path cannot be followed?
• Dependencies: Which activities rely on other people, departments or systems?

03

Establish What Improvement Actually Means

A process that feels slow does not necessarily have a speed problem. It may have a quality problem, an ownership problem, an information problem or a cost problem.

Before changing the process, establish a baseline. A baseline describes the current level of performance against which future results can be evaluated.

For example, measuring only how quickly employees complete individual tasks can produce a misleading picture. Work may move quickly within each department but spend most of its total time waiting between them.

Similarly, reducing process costs at the expense of quality may create more rework and additional customer-facing problems.

APQC identifies cost effectiveness, staff productivity, process efficiency and cycle time as useful measurement categories. Its guidance also emphasizes balanced measures and connecting process performance to stakeholder and business outcomes. [3]

The measures should be selected according to the process and its intended outcome. Not every organization needs every metric. The objective is to establish what needs to improve, how that improvement will be recognized and which information can reliably demonstrate the result.

Without a baseline and agreed success criteria, an organization may know that a new system has been implemented but cannot confidently establish whether the original problem has been resolved.

• End-to-end cycle time: How long the complete process takes.
• Waiting time: Where work remains idle between activities.
• Rework rate: How often work needs correction or repetition.
• Error rate: How frequently the process produces incorrect results.
• Cost per completed outcome: What resources the process consumes.
• First-time completion: Whether work is completed correctly without repeated intervention.

04

Choose the Intervention, Not Just the Tool

Once the process is understood and its performance gaps are identified, the next decision is how to improve it. Automation is one possible intervention. It is not the only one.

A process may need to be simplified before anything is automated. Responsibilities may need clarification. An existing application may need better configuration. Two systems may need to exchange information. A new platform may be justified when existing options cannot meet the requirements.

A 2025 systematic literature review published in the Business Process Management Journal examined 205 scholarly articles. The researchers identified 80 improvement opportunities associated with 64 possible process-redesign options. The review organizes these opportunities across process activities, control flows, resources and data objects. [4]

Automation itself also requires careful selection. A peer-reviewed study published in Information Systems and e-Business Management developed a framework for robotic process automation projects using 35 reports of real-life projects, followed by expert interviews and workshops. These findings concern RPA specifically, rather than every form of business automation. [5]

The decision should follow the evidence. The management question should change. Instead of asking what technology can be introduced, ask what is the most appropriate intervention that addresses the identified problem and supports the intended business outcome.

UK Government technology guidance similarly recommends choosing technology according to cost-effectiveness, future flexibility, build-versus-buy considerations and total cost of ownership. [6]

• Unnecessary activities or approvals: Simplify the process.
• Inconsistent execution: Standardize the workflow.
• Unclear responsibilities: Define ownership and decision rights.
• Existing software is poorly configured: Improve configuration.
• Applications do not exchange information: Evaluate integration.
• Suitable repetitive and rule-based activities: Consider automation.
• Existing products cannot meet essential requirements: Assess build versus buy.

05

Engineer Against Agreed Requirements

After deciding what should change, the proposed solution needs a defined structure. This is where business requirements become engineering requirements.

A solution should establish its scope, functional requirements, ownership, dependencies, system interfaces, implementation risks, costs and acceptance criteria.

NASA's Systems Engineering Handbook provides established guidance on translating stakeholder expectations into requirements, managing system relationships and controlling the engineering lifecycle. Its guidance reinforces the importance of traceability between stakeholder needs, technical requirements and verification. [7]

The practical distinction is that a Solution Blueprint should describe how the entire intended system will operate, not just which features developers will build.

A documented blueprint, defined scope, timeline, risks and success criteria make it possible for decision-makers and delivery teams to agree on what is being engineered before significant implementation work begins.

Technology choices should also account for the surrounding environment. A new application that cannot operate reliably with existing systems may add another layer of complexity rather than remove one.

• Scope: What is included, and what is outside the project?
• Requirements: What must the improved system or process accomplish?
• Ownership: Who performs, approves, maintains and monitors the work?
• Dependencies: Which systems, teams, information or decisions must be available?
• Integration: How will the proposed system interact with existing applications?
• Cost and risk: What investment and ongoing responsibilities should be considered?
• Acceptance: What evidence will demonstrate that agreed requirements have been met?

06

Prove the System Works in Practice

A completed development milestone does not automatically establish that a business problem has been solved. Two different questions need to be answered.

Verification asks whether the system was built according to its agreed requirements. Validation asks whether the resulting system actually meets the intended need in its real operating context.

A feature may pass its technical tests while the people expected to use it still find the process difficult, incomplete or unsuitable.

That is why validation should involve appropriate users, realistic workflows, relevant exceptions and agreed acceptance criteria. Where practical, a controlled pilot can expose issues before a wider rollout.

The US Government Accountability Office's Agile Assessment Guide describes incremental software development in which functionality, quality and customer satisfaction are evaluated continuously. [8]

For a business improvement initiative, validation should establish whether agreed requirements have been met, intended users can complete important tasks, relevant exceptions have been handled, the solution works with connected systems and the business has evidence to accept the completed work.

The objective is not simply to demonstrate that the software operates. It is to establish that the engineered solution is fit for its intended purpose.

07

Make the Improvement Sustainable After Launch

A system can be technically complete and still become difficult to maintain. Employees may not understand the revised process. Documentation may be incomplete. Responsibility may shift back to individuals who already carry too much coordination work. Performance may gradually deteriorate without anyone noticing.

Transition should therefore be treated as a distinct part of delivery. The organization should know who owns the process after implementation, who maintains the system, how employees are trained, where operating documentation is maintained, how exceptions are reported and who reviews performance.

APQC's process-performance guidance emphasizes that organizations should measure not only process outcomes but also adoption and sustainment, including employee understanding, training, process adherence and documentation. [3]

After transition, the business should continue comparing actual performance with the original baseline and agreed targets. If the process has improved, the organization should understand why. If it has not, the next decision should be based on evidence rather than defending the original implementation.

GOV.UK's Service Standard similarly recommends defining success measures, collecting performance data and using the results to decide whether a service is solving its intended problem and where further improvements are needed. [9]

An improvement initiative should not end simply because a system has gone live.

08

From Business Process Improvement to BSEM

The principles discussed above require a structured way to move from understanding a business problem to delivering and sustaining an appropriate solution.

At CodeLixi, this is organized through the Business Systems Engineering Methodology (BSEM™). BSEM™ is CodeLixi's six-phase methodology for diagnosing business requirements, engineering appropriate systems, validating delivery and supporting continuous improvement.

The first phase, Discover & Diagnose, examines the business context, existing workflows, systems and operational bottlenecks. It establishes which problem is worth solving.

Design translates the diagnosis into an agreed solution blueprint, with defined scope, timeline, risks and success criteria. Build engineers the agreed solution through controlled stages, with visible progress and documented changes.

Validate tests the system against agreed requirements, involves intended users where appropriate, reviews exceptions and evaluates readiness. Transition prepares the organization to operate the delivered system through documentation, training and structured handover.

Finally, Optimize reviews performance against agreed measures, identifies further improvement opportunities and establishes a suitable reporting and support plan.

BSEM™ is not an argument for making every business change more complicated. Its purpose is to make important decisions explicit, establish accountability and ensure that technology serves a defined business requirement.

The intervention may be a process change, a better use of an existing tool, a system integration, automation or a purpose-built application. The choice should follow the diagnosis.

09

The Real Measure of Improvement

A business does not become more effective simply because it introduces more technology. It improves when important work becomes more understandable, responsibilities become clearer, information reaches the right people and intended outcomes can be measured.

Automation can support that progress. Software can enable it. Integration can make it possible. But none of these guarantees that the original problem has been solved.

The discipline is to understand the business before engineering the system. That is where meaningful business process improvement begins.