Process mining and time studies: picking which workflow to automate first

Reference article · 6 min read

Most automation efforts in government begin with a demonstration rather than a diagnosis. A vendor shows a workflow tool clearing a backlog, someone recognizes their own backlog in the slide, and scoping begins around that resemblance. The work that follows is often competent. It just lands on a process that was chosen because it was visible, not because it was the largest or the most tractable source of delay.

A better sequence is to measure for a few weeks before committing money. Two methods do most of the work. Process mining reconstructs how cases actually move using timestamps your systems already record. Short, structured time studies capture the parts of the job no system logs. Together they usually produce a ranked list that differs from the list staff would give from memory, and they leave you with a baseline you can hold a vendor to later.

Start with the event data you already have

Process mining needs only three fields per row: a case identifier, an activity name, and a timestamp. An actor or role is a useful fourth. Those fields are usually recoverable from status history tables, audit logs, document management systems, the service desk, and call or web self-service logs. You do not need a specialized tool to begin. A pull into a spreadsheet or a small database is enough to answer first-order questions.

Look for:

• Cycle time distribution, not the average. Report the median and the long tail separately. Averages hide the cases that generate complaints and appeals.
• Wait time versus touch time. Most elapsed time in permitting, licensing, benefits, and procurement is queue time, not work time. Automating a task that takes four minutes will not move a process that waits eleven days.
• Queue age. How old is the oldest item in each queue, and is the queue growing or draining week over week.
• Rework and returns. Count reopened cases, reassignments, and applications returned to the applicant for correction. High return rates point upstream, usually to a form or an instruction sheet.
• Variant count. How many distinct paths do cases actually follow, and what share of volume follows the top three.

Two cautions. Timestamps record system events, not human effort, so batch jobs, overnight status sweeps, and data migrated from a legacy system will distort the picture unless you exclude them. And event logs frequently contain personally identifiable information, so treat the extract as a record subject to your retention schedule and your disclosure obligations, and confirm handling with your records officer and counsel.

Use time studies for what the logs cannot see

Systems do not log the phone call to a sister agency, the second monitor holding a PDF, the retyping of an address from one screen to another, or the wait for a supervisor signature. A short structured time study fills that gap.

Keep it small and honest. Pick two or three roles, define a window of a few days, and use one simple log per person: task category, start and stop, interruptions, and the reason for each handoff. Tell staff plainly that the study measures the process and not their performance, and say what will happen to the data. Review any obligations under your collective bargaining agreements before you begin, since notice or consultation may be required.

Ask four questions during the debrief. What do you look up outside the system of record. What do you type more than once. What are you waiting for. When do you have to ask someone else, and why.

Rank candidates by volume, variation, and rule clarity

Score each candidate process on a simple scale rather than debating it in narrative form.

• Volume. Annual case count multiplied by realistic time saved per case. A rare process cannot produce meaningful savings even if each instance is painful.
• Variation. Low variation is easier and safer. If the top three paths cover most volume, you can automate them and route the rest to staff.
• Rule clarity. Can the decision be written down as a rule that a hearing officer or auditor would accept. If the rule lives only in an experienced examiner's judgment, automate the preparation, not the decision.
• Data readiness. Are the inputs structured, current, and available through a supported interface.
• Consequence of error. Prefer reversible steps first. Eligibility determinations, enforcement actions, and payments deserve human review regardless of rule clarity.
• Change cost. Note where a change would require amending a regulation, revising a public form, or renegotiating an interface. That cost is real and belongs in the score.

The loudest complaint is often not the best first target

The task staff complain about most is usually the most unpleasant one, not the most expensive. Unpleasantness and cost are different currencies, and both are legitimate, but you should know which one you are buying.

Complaints also tend to name symptoms. A team that hates re-keying returned applications is describing a form problem. Fixing the form, the instructions, or the validation at intake may remove the work entirely, at a fraction of the cost of automating the correction handling. Look one step upstream before you accept a complaint as a scope.

Do not dismiss the complaints. Record them, and track morale and turnover risk as a separate factor in the ranking so the tradeoff is visible to decision makers instead of hidden in a total cost estimate.

Freeze a baseline, then buy

Before a solicitation, publish the definitions and the current numbers for the processes you intend to change: volume, median and tail cycle time, rework rate, return rate, and queue age. Decide now how you will measure the same things after go-live. Without that, every post-implementation debate becomes anecdotal.

Then ask vendors:

• Which of our baseline measures will improve, by how much, and how will that be verified from our data.
• How are exceptions detected and routed to a person, and what happens when the rule does not fit.
• What audit trail does the tool produce, and can we export it in full.
• Which changes can our staff configure, and which require a change order.

In the contract, require exportable event and audit data in a documented format at any time and at exit, acceptance criteria tied to your baseline measures rather than to installation milestones, documented human review points for consequential decisions, records retention behavior that matches your schedule, and accessibility conformance for any public-facing interface. Accessibility and records requirements change, so confirm current expectations with your state or local authority and your counsel rather than relying on a template.

HQT works with state and local agencies on data analysis and systems engineering, including process measurement work of this kind.

Frequently asked questions