Map the work, identify delays and improve the process before deciding where automation or new software would help.
When a process frustrates the people who run it, the instinct is often to look for a tool. A new system promises to remove manual steps, enforce consistency and give managers visibility. Sometimes it does. But technology applied to a poorly understood process tends to reproduce the same problems faster, or move them somewhere less visible. The approach below starts with the work itself and treats technology as one of several possible responses, chosen once the causes of delay and rework are clear.
Understand the workflow first
Process improvement starts with how work moves between people, systems and decisions. Document the actual steps, including exceptions and informal workarounds.
The documented process and the real process are rarely the same. The most reliable way to see the difference is to follow a handful of recent cases from start to finish, asking at each stage who did what, which information they needed, where they found it and how long the item waited before anyone acted on it. Waiting time is frequently where most of the elapsed time sits, and it is invisible in a process map that shows only activities.
It helps to capture the workarounds without judgement. A personal spreadsheet, a standing weekly call or a habit of copying a colleague into every email usually exists because the formal process does not meet a real need. Each workaround is a clue to a requirement the improved process will need to address.
Choose a process that matters to users or the business. Agree the desired improvement and collect a baseline for time, quality, rework or another suitable measure.
Good candidates are processes with high volume, visible frustration or a direct effect on customers, patients or revenue. Starting with a process that is important but contained, such as a single approval route or a recurring request type, allows the team to learn the method and show results before tackling larger, cross-functional workflows.
Identify the causes of delay and rework
Look for incomplete requests, duplicate entry, unclear responsibilities and repeated checks. Discuss the causes with the people doing the work before choosing a tool.
Several patterns appear across many organisations. Requests arrive without the information needed to act on them, so the first step is always a round of clarification. The same data is typed into two or three systems because they are not connected. Nobody is quite sure who makes the final decision, so items circulate until someone senior intervenes. Checks are repeated at several stages because each reviewer is unsure what the previous one covered. Each of these has a different remedy, and only some of them are technical.
For example, an approval workflow may need a clearer intake brief and decision owner before automation is useful. This is an illustrative pattern, not a reported client result.
To extend that example, consider a marketing team that commissions content through an internal request process. Turnaround is slow, and the team assumes that a workflow tool would solve it. When the cases are traced, most of the delay comes from requests that lack a clear objective, audience or deadline, followed by several rounds of clarification. A structured intake step that guides requesters through the information needed, similar to the digital intake and scoping tool we have built, would address the cause directly. Automation of later steps may still be worthwhile, but it would deliver far more once requests arrive complete.
Design a workable target process
Agree the steps, responsibilities and controls that should remain. Standardise where it helps consistency, while allowing for justified differences between teams.
In regulated environments, some steps exist for good reason. Medical, legal and regulatory review in pharma, financial approval thresholds and data protection checks are not inefficiencies to be removed, although the way they are performed can often be improved. Being explicit about which controls are mandatory and why helps the team focus improvement effort on the steps that are genuinely negotiable.
Test the proposed process with representative cases. Make the exceptions visible, including what happens when information is missing or a decision needs escalation.
A walk-through with real examples is one of the most effective tests available. Take a recent straightforward case, a complicated one and an unusual one, and run each through the proposed process on paper. Where the design has no answer for a case, the gap becomes obvious before anything has been built. Leaders reviewing a target process can ask a few direct questions:
- Who owns the process end to end, and who owns each decision within it?
- What happens when an item is incomplete, urgent or outside normal rules?
- Which controls are required, and which are habits that could be reconsidered?
- How will we know whether the new process is performing better than the old one?
Use technology where it fits
Automation may help with repetitive transfers or notifications. An application may help people track status and records. AI may assist with suitable tasks, provided its limitations and oversight are considered.
Once the target process is clear, it becomes much easier to see where technology adds value. Moving data between systems, sending reminders and producing standard documents are typical candidates for automation. Where teams are managing status through shared spreadsheets and email, a purpose-built application can provide a single record and clearer accountability, as in our process automation application for European operations. AI can help with drafting, summarising or classifying information, but outputs need appropriate human review, particularly where content has regulatory or reputational consequences.
Compare the benefit with implementation, maintenance and support effort. New technology is one option; simpler forms, clearer guidance or a changed responsibility may solve part of the problem.
A common pitfall is to underestimate the ongoing cost. Every integration needs monitoring, every application needs an owner, and every automated rule needs updating when the process changes. Sometimes a well-designed form and a clear responsibility deliver most of the benefit at a fraction of the effort.
Review the change in use
Provide training and support, then compare results with the baseline. Check whether the change has improved the experience for users and whether it has moved work elsewhere.
Early weeks after a change are often uneven, as people learn new steps and edge cases emerge. Planning a short review period, with a named contact for questions and a simple way to report problems, allows the team to refine the process quickly. A later review against the original baseline then shows whether the improvement has held.
Where to start
Pick one process that matters, follow a few real cases through it and write down where time is lost. That evidence is usually enough to decide whether the next step is a process change, a small tool or a larger build. Glyz combines process improvement, design and development and automation to help teams define and deliver an appropriate next step.
