Business Process Improvement Starts With Where the Time Actually Goes
Published · Wendy Kinney
Business process improvement (BPI) is the structured work of finding out how a process really runs and changing it so it costs less, moves faster, or produces fewer errors, usually with a method such as Lean, Six Sigma, or Kaizen. Every one of those methods starts by measuring the current state. In most back offices, the measurement that matters most, where people’s hours actually go, is an estimate rather than a record.
Look at the last three projects your improvement team chartered. Each one probably started from a complaint: a slow cycle, an error spike, an unhappy customer. That is a good way to find a problem. It is a poor way to find where a team’s time goes, and the two lists rarely match.
If you run an improvement program, you already know the methods work. This article is about the input they all share. It covers where improvement teams get their time numbers today, what those numbers miss, and how an improvement cycle changes when it runs on activity data, meaning a measured record of what people did during the day, instead of on workshop estimates.
Quick Answer
Business process improvement is the structured work of finding and fixing inefficiency in how a process runs, using methods such as Lean, Six Sigma, Kaizen, and PDCA. Each method depends on a measure of the current state. In back-office work, the key measure, where people’s hours actually go, is usually estimated, so projects get chosen and checked against a guess.
What Is Business Process Improvement?
Business process improvement is the ongoing practice of analyzing existing processes and changing them to meet a specific operational goal. IBM defines process improvement as “a systematic approach to enhancing the efficiency and effectiveness of business processes,” and places it as “a subdiscipline within business process management (BPM).”
Two features separate it from its neighbors. BPI works on processes you intend to keep, one change at a time, where reengineering starts again from a blank page. And it is not the same as automation: many improvements are a changed rule, a removed handoff, or a better intake form, with no new software at all.
TechTarget’s definition adds a detail many guides skip. It describes the goal as continuously improving “the performance of both the formal and informal processes within an organization.” The formal processes have owners, maps, and KPIs. The informal ones, such as chasing a missing document or reconciling two reports that should agree, are where a lot of the working day goes, and they are the hardest to measure.
Process Improvement Methodologies, and the Step That Needs a Measure
Every major process improvement methodology contains a step that measures the work as it is today, and that step decides which problem gets solved. Lean has the current-state value stream map, Six Sigma has the Measure phase of DMAIC, Kaizen has the current-state discussion that opens an event, and PDCA has Check. The methods differ in style. They share this dependency.
| Methodology | Core idea | The step that needs a measure of the work | What usually fills it in a back office |
|---|---|---|---|
| Lean | Remove waste and improve flow | The current-state value stream map, split into value-added and non-value-added time | A walk-through workshop with estimated minutes per step |
| Six Sigma (DMAIC) | Reduce variation and defects | Measure: a baseline before analysis | Defect and cycle-time data from the system, with effort per step estimated |
| Kaizen | Small, frequent, team-led changes | The current-state review at the start of the event | What the team remembers of recent weeks |
| PDCA | Plan, test on a small scale, check, standardize | Check: results compared with expectations | Volume, backlog, and cycle-time KPIs |
| Total Quality Management (TQM) | Organization-wide quality culture | Ongoing measurement of process performance | Quality scores and customer satisfaction |
IBM’s own step list shows where the gap sits. Its guidance for mapping the current process says the map “includes relevant performance data, including cycle time, error rates and customer feedback.” Those are all measures of what comes out of the process. None of them says how many hours of which people’s days go into it, and that is usually the number an improvement case is paid for in.
If your last value stream map ran on workshop estimates, it is worth seeing what a measured one looks like. Our page on the capture, classify, and insight method shows how the time data is produced.
Where Improvement Teams Get Their Time Numbers
Improvement teams in back offices get time data from five places: workshop estimates, self-reported time logs, direct observation, work sampling, and system data. Each one gets something right. Each one also has a known way of misleading, and many programs lean on the two cheapest.
| Source | What it gets right | Where it misleads |
|---|---|---|
| Workshop estimates from process owners and experts | Fast, and good at listing the steps | Minutes are recalled, anchored on the standard case, and exceptions are forgotten |
| Self-reported time logs or diaries | Covers the whole day, including informal work | People round, skip interruptions, and tend to overstate time on work that feels heavy |
| Direct observation or stopwatch time study | Precise for the steps observed | Small samples, expensive analyst time, and people tend to work differently while watched |
| Work sampling (random spot checks) | Statistically sound for the share of time per category | Needs many observations, is slow to repeat, and categories stay coarse |
| System data (KPIs, event logs) | Objective and cheap | Records when an item changed state, not the effort in between, and misses email and spreadsheets |
The bias in self-reported time is well documented. In the Monthly Labor Review, Robinson, Martin, Glorieux, and Minnen compared people’s estimated workweeks with their time diaries and found that employed respondents tend to overestimate their work hours by 5% to 10%, with most of the overestimate coming from people who estimate longer hours. Their summary of the pattern: “The greater the estimate, the greater the overestimate.”
That study is about total hours, the easiest number anyone could be asked to recall. A value stream map asks for much more: the minutes per step, per variant, for work that is interrupted a dozen times a day. System data avoids the recall problem but brings its own, since a timestamp shows when an item moved, not who worked on it or for how long. Our process mining comparison covers that limit in detail.
Three Things Business Process Improvement Misses Without Activity Data
Without a measured record of the working day, an improvement program tends to miss three things: the hours that sit between the named processes, the difference between two people doing the same job, and whether a finished project actually took time out of the day. Each one changes which projects get chartered or how they are judged.
The hours between the named processes
Improvement projects get chartered around processes that have a name, an owner, a queue, and a KPI. A lot of back-office time belongs to none of them: answering status questions, chasing missing information, rebuilding a report that another system should have produced. Across the Microsoft 365 apps, Microsoft’s Work Trend Index found that the average employee spends 57% of their time communicating in meetings, email, and chat. That figure covers office workers in general, not back offices specifically, but it shows how much of a day can sit outside any process map.
This is why the Pareto chart matters. A Pareto of complaints ranks processes by how visible their failures are. A Pareto of hours ranks activities by how much of the team’s time they take, and the tallest bar is often work no process map includes.
Here is how that plays out, in a composite drawn from situations like it rather than any one client. A policy services team at a P&C insurer charters a Six Sigma project on endorsement cycle time. Activity data for the same team shows endorsements take about 18% of its hours, while answering agent emails about endorsement status takes about 26%, spread thinly across every desk.
The status emails exist because agents cannot see where a request stands. So the better first project is visibility for agents, and the cycle-time project follows it.
The difference between two people doing the same job
Standard work is the anchor of Lean, and writing it well means knowing how the most effective people in a role actually do the work. A workshop tends to produce the documented method or an average. Activity data by person shows the spread: two claims processors with the same volume and the same systems, one spending most of an hour a day re-keying data the other pulls from a saved lookup.
This is an old idea done at a new scale. At Nationwide’s back-office processing operation, two sites “operated independently, leading to inconsistent workflows.” Our consultants conducted more than 10,000 side-by-side observations to identify best practices and standardize processes across both locations. The published outcome was a 22% reduction in unit costs, eliminated overtime, and $1.6M in savings.
Individual-level data serves the method, not a ranking of people. The point is to find the better way of working and give it to everyone, with the people closest to the work involved in writing it. We explain where that line sits in workforce intelligence versus employee monitoring.
Whether the improvement held
The Check step in PDCA and the Control phase in DMAIC both ask whether the change worked and whether it stuck. Most control plans track output KPIs, such as cycle time or items per full-time employee. Those can improve while the effort simply moves: minutes taken out of one step come back as a workaround in a spreadsheet, or as rework in the next team.
Measuring the same activities, with the same method, before and after the change answers the question a KPI cannot: did the hours leave, or did they move? It also shows drift. A new method that has quietly slipped back to the old one three months later looks fine on a cycle-time chart until the volume rises.
If a control chart in your program is green while the team feels as busy as before, that is a good use of 30 minutes. Book a strategy call, bring the control plan, and we will go through what its measures can and cannot see.
A Kaizen Program That Started With 868 Observations
One example of improvement built on measured work comes from a payments company’s client services department, where our team observed the work before running a single Kaizen event. The order is the lesson: baseline first, then the team redesigns the process against it.
According to the published case study, more than 90% of customer requests came in by email, landing in individual mailboxes. The company “relied on CSAT and complaint calls to measure quality, and client reps to advise them on workloads.” In other words, the improvement inputs were a satisfaction score and self-reported workload, the two sources in the table above that say least about where time goes.
The team first conducted 868 side-by-side observations “to gain an accurate understanding of key activities and baseline processes.” Only then did it lead several Kaizen events on the current-state problems and the future-state design. The redesign moved the department to a shared services model with a central intake, supported by a custom case management tool, and the project delivered $1.2M in savings in 23 weeks.
Two caveats matter. This was our consulting team’s work, done by hand, before the Ground Truth AI² Platform existed, so it shows the method rather than the platform. And 868 observations take analysts weeks at the desk, which is why many programs never gather them. The platform exists to produce that baseline continuously, for every person in scope, instead of for a sample.
Running an Improvement Cycle on Activity Data
An improvement cycle on activity data keeps your methodology and changes its inputs. DMAIC is still DMAIC and a Kaizen event is still a Kaizen event, but the current state, the project choice, and the Check step all rest on measured hours instead of recalled ones.
- Baseline the whole working day of the team, not one process. Measure for at least one normal cycle, including a month-end or a volume peak, so the baseline is not an unusually quiet week.
- Build the Pareto of hours by activity. Tag each activity as value-added, required but not value-added, or waste, using the Lean categories your team already knows.
- Charter from the top of the Pareto. Give each project an effort measure in activity hours, alongside its cycle-time or defect measure.
- Use the spread between people to write standard work. Find who does the activity in the least time with the fewest returns, and build the method with the team.
- Plan the re-measure when you charter the project. Use the same method as the baseline, at go-live and again after a few months, so Check compares like with like.
Some projects will end in automation rather than a changed method. When that happens, the question shifts from “how do we do this better” to “what should software take over,” and a different set of numbers applies. Our guide to business process automation and what to measure first covers that hand-off, and intelligent automation readiness covers work that involves reading documents or making bounded decisions. To rank several candidates against each other, see how to know what to automate in operations.
Where Summit Trails Fits, and When You Do Not Need Us
We produce the measured baseline an improvement program runs on, and your team keeps the program. We do not run Kaizen events, lead change management, or implement the changes. Our job is the data underneath them, interpreted by someone who has run operations.
The Ground Truth AI² Platform replaces the clipboard and the stopwatch. A small desktop client takes an image of the area around each click, typically 500 to 3,000 a day for each person in scope, with no keystroke logging and no full-screen recording. Vision AI names the activity in each image, so an hour in the policy system becomes “issuing an endorsement” and “answering an agent’s status question,” and every activity is scored for automation potential. That is what activity-based workforce measurement means in practice, and the platform page sets out the privacy architecture.
The engagement is fixed at 90 days, needs at least 50 people in scope, and runs on your Azure or AWS environment. You see a first read of the operation around week three or four, early enough to shape the first charter.
At day 90 you receive the Ground Truth AI² Report: the activity baseline, an AI replacement assessment, a prioritized deployment roadmap, and a staffing model analysis. You can see what that output looks like. Data capture stops when the engagement ends, so the post-change measurement belongs in your project plan as a separate step.
Wendy Kinney reads the findings with you. She has spent more than 20 years in workforce operations, with AT&T, Boeing, AIG, Nationwide, and Farmers among the organizations she has worked with. Prior operational engagements delivered a 2-to-1 return or better for clients who acted on the findings. Pricing is a base fee plus a per-employee cost, scoped on a call.
Plenty of improvement programs do not need us. A Green Belt with a random-interval sampling sheet can size one stable team in one system perfectly well. We earn our place when the hours are scattered across many desks and teams, when the informal work is the big bar on the Pareto, or when the program has to prove to finance where the time went and where it went afterward.
Frequently Asked Questions
What is business process improvement?
Business process improvement is the practice of analyzing how an existing process runs and changing it to reduce cost, shorten cycle time, or cut errors. It usually follows a structured method such as Lean, Six Sigma, Kaizen, or PDCA, and it works on processes an organization intends to keep rather than replacing them outright.
What are the main business process improvement methodologies?
The most common are Lean (removing waste and improving flow), Six Sigma and its DMAIC cycle (reducing variation and defects), Kaizen (small, frequent, team-led changes), PDCA (plan, do, check, act), and Total Quality Management. Many programs combine them, for example Lean Six Sigma. All of them depend on a measure of the current state.
What is the difference between business process improvement and business process automation?
Business process improvement changes how the work is done, which may or may not involve software. Business process automation hands steps of a process to software. Improvement often comes first: automating a process that has not been improved tends to lock in its detours and rework.
Is business process improvement the same as continuous improvement?
They overlap heavily. Continuous improvement is the broader habit of making small, ongoing improvements across an organization. Business process improvement applies that habit to specific business processes, usually with defined projects, owners, and measures. A continuous improvement program is typically made up of many BPI projects.
How do you measure a process before improving it?
Measure both what the process produces and what it consumes. Output measures such as cycle time, error rate, and customer satisfaction usually come from systems. Effort, meaning the hours people spend and on which activities, is harder: it comes from estimates, time logs, observation, work sampling, or automated activity capture, and each source has a different level of bias.
Do you need process improvement software to run BPI?
No. Many successful programs run on whiteboards, spreadsheets, and a good facilitator. Process improvement software falls into several categories, including process mapping tools, process mining, and workflow platforms. Activity measurement is a separate input: it tells you where the time goes, which helps you decide what any of those tools should be pointed at.
Bring Your Improvement Backlog to a Strategy Call
Business process improvement works when it is aimed at the work that actually fills the day. The methods are sound. What most back-office programs lack is a measured record of where the hours go, so projects get chosen from complaints and judged on KPIs that cannot see effort moving around.
If you run an improvement program and your current-state maps rest on workshop estimates, book a strategy call and bring the backlog. We will spend the half hour on the measures behind it and on what a measured baseline would change about the next project you charter.
