What Actually Happens When You Try to Redesign a Workflow
I was brought into a company last year to look at their invoice processing pipeline. It went through seven manual handoffs, took eleven days on average, and half the invoices had errors that nobody could trace back to a specific person because the process was documented on three different shared drives and a whiteboard that hadn't been updated since 2019. The standard textbook answer would be to start with a flowchart and identify the bottlenecks. That works in theory. In practice, the first week was spent figuring out which version of the process was actually being used versus which version people claimed to use when they thought someone important was listening. This is where Business Process Change A Managers Guide To Improving Redesigning And Automating Processes The Morgan Kaufmann Series In Data Management Systems actually earns its shelf space, because it walks through the gap between what happens in a clean case study and what happens when you're trying to get five departments to agree on what "approved vendor" means. The framework isn't magical. It won't save you from people who are protective of their spreadsheets. But it gives you a vocabulary for explaining to leadership why the three-week "simple automation project" is going to take eight months before you've even touched the software.
Getting Started Without Wasting Six Months in Analysis Paralysis
The book breaks process improvement into three phases: improvement, redesign, and automation. Most people try to automate first because that's the part that sounds exciting and justifies the budget. That's backwards. Improvement means fixing the broken parts of the current process while it still exists. Redesign means deciding what the new process should actually look like. Automation is just applying technology to the redesigned version. If you skip ahead, you're going to end up with a faster version of something that was already wrong, which is exactly what happened at that invoice place I mentioned. They automated the entry step and created a bottleneck at the approval stage that got worse instead of better. The practical starting point is picking one process and mapping it as it actually works, not as it's supposed to work. I spent a Tuesday shadowing someone who processed refunds. The documented process said refunds required manager approval after thirty dollars. The actual process they followed had them sending a Teams message to their manager, waiting for a reply, then entering the refund in the system and following up if the manager didn't respond within four hours. The real process included a step that didn't exist in any documentation and added about twenty minutes per transaction. If I hadn't seen that, automating the system entry step would have cut maybe five minutes off an already sluggish workflow instead of the two days of elimination I eventually achieved.
Where the Standard Models Fall Apart
One thing the book doesn't emphasize enough, in my experience, is how often process improvement hits a wall that has nothing to do with the process itself. It hits a wall of organizational politics. I worked on a procurement process redesign where the bottleneck was a single person in the compliance team who had invented a verification step that wasn't required by any policy, regulation, or standard. Removing that step would have saved the company probably forty hours a week. That person's response to the proposal was essentially, "I'll find something else to verify." You can optimize a process until it's efficient and still fail if you don't account for the people who benefit from the inefficiency. The book covers stakeholder mapping, but it treats it more like a logistical exercise than the emotional one it actually is. Another counter-intuitive reality is that sometimes the best improvement is doing less, not doing things faster. At another engagement, we were asked to streamline a quarterly reporting process that took three people roughly eighty hours combined. The actual content of the report was reviewed by about four people in the executive team, two of whom barely looked at it. The process improvement that made the most impact wasn't about the workflow itself. It was about convincing leadership that half the data points weren't useful and eliminating them. That conversation took longer than any of the process mapping. The book has sections on value stream analysis that touch on this, but again, the organizational negotiation part is where most projects die, and that's the part that's hardest to prepare for using a framework.
Get the Full Details
Choosing Between Improvement, Redesign, and Automation
The decision tree in the book is useful but I found it more practical to think about it in terms of scope and risk. Improvement is for processes that are mostly functional but have clear, localized problems. Redesign is for processes where the fundamental approach is wrong or outdated. Automation is for processes that are stable, well-understood, and repetitive enough that the return on investment makes sense. The overlap between redesign and automation is where projects tend to get messy, because people confuse the two. They'll redesign something and then immediately try to automate the redesign without testing whether the redesign actually works in practice first. I ran into this at a manufacturing client where they wanted to automate their maintenance request process. The existing process had technicians filling out paper forms, walking them to a supervisor, getting a signature, then scanning the form into a system that nobody checked for a week. The proposed redesign was to move everything to a mobile app. The automation part was straightforward. The problem was that the new app still required supervisor approval before a work order was generated, and the supervisors were the same people who had been bottlenecks in the paper system. The app just made the bottleneck more visible. We ended up removing the supervisor approval step entirely and replacing it with an automated alert system that flagged unusual patterns. That's a redesign decision that the automation framework alone wouldn't have caught.
The Documentation Problem Nobody Talks About
One of the most frustrating parts of process change is documentation, and the book touches on it but underplays how much time it eats. Good documentation is necessary. Bad documentation is worse than nothing because it creates a false sense of clarity. I've seen teams spend two weeks writing process maps that looked perfect and then realize six months later that the documented steps didn't match reality because the people who wrote them had left the company or because the process had quietly drifted while everyone was too busy to update the documentation. The workaround I use is to treat documentation as a living artifact and to keep it deliberately sparse. Detailed process maps tend to become outdated quickly. What works better is a set of clear principles and decision rules, plus a current-state diagram that gets updated whenever someone actually uses the process and notices a deviation. The book recommends process documentation as a deliverable at each phase, which is reasonable, but I've found that the best documentation is the kind that people actually reference, and that usually means less text and more examples of edge cases. I keep a running list of exceptions and edge cases for every process I work on. That list turns out to be more valuable than the flowchart.
When Automation Is the Wrong Answer
This might be the most important point, and it's one the book implies but doesn't hammer hard enough. Automation is not a universal solution. It's a solution for specific types of problems. If your process is unpredictable, involves significant judgment calls, or depends on relationships and context that can't be codified into rules, automation will make things worse, not better. I worked on a customer onboarding process at a software company where the "improvement" proposal was to automate the initial intake questionnaire and route responses through a decision tree. The decision tree looked clean on paper. In practice, about forty percent of incoming requests contained information that didn't fit neatly into any of the predefined categories, and those requests ended up stuck in a limbo queue that nobody monitored because everyone assumed the automation would handle them. The automated process had reduced the speed of the eighty percent that fit the model but created a new failure mode for the twenty percent that didn't. The fix was to keep the automation for the straightforward cases but to route the exceptions to a human with a clear escalation path and aSLA for response time. That hybrid approach was messier to design but performed significantly better in practice. The book covers RPA and workflow tools extensively, which is useful, but it doesn't spend enough time on when not to use them. Sometimes the right answer is just hiring someone to do the work, or changing the business model so the process isn't needed at all.
Measuring Success Without Getting Misled
Process improvement projects often measure success using metrics that don't actually reflect the outcome. Cycle time is a common one. Reducing cycle time sounds good until you realize you're just pushing work faster through a system that produces more errors at speed. The book mentions balance measures, which is good, but in practice I've found that the most useful metrics are the ones that track downstream consequences, not the process itself. How many rework incidents occur after the process completes? How many customer complaints reference this workflow? How many employees report that the process causes them stress or confusion? At the invoice processing project, we tracked three metrics instead of the usual cycle time and cost per transaction. We tracked error rate after processing, time spent by finance staff on exception handling, and the number of invoices that required manual intervention after the initial submission. The first two dropped significantly within three months of the redesign. The third one actually increased initially, which seemed counterintuitive, but that's because we had made the errors more visible by removing the workarounds that had been hiding them. It dropped again once we addressed the root causes. Those visibility metrics matter more than the headline efficiency numbers, and they're easier to overlook when you're under pressure to show results.
What the Book Does Well and Where It Falls Short
The Morgan Kaufmann series quality shows through in the structure. The progression from improvement to redesign to automation is logical and avoids the common mistake of jumping straight to tools and technology. The case studies are realistic, even if they're somewhat sanitized for publication. The coverage of change management is adequate, though again, I wish it had gone deeper into the political dimension rather than treating it as a communication problem. If people don't buy in, it's rarely because they don't understand the benefits. It's usually because they perceive a threat to their role, their autonomy, or their workload. Where the book is weakest is in its treatment of data quality. Process automation is only as good as the data it runs on, and most organizations have terrible data quality in their operational systems. I've seen automation projects fail because the source data had duplicate records, missing fields, or inconsistent formatting that the automation tool couldn't handle gracefully. The book mentions data governance briefly but doesn't integrate it as thoroughly as it should. If you're planning a serious process change initiative, you'll want to pair this with a data quality assessment before you invest heavily in automation. There's also a gap around scale. The examples tend to be from mid-sized organizations with relatively straightforward structures. If you're working in a large enterprise with multiple business units, regional variations, and legacy systems that predate the current organizational chart, the framework still applies but it needs significant adaptation. The core ideas don't change, but the execution becomes much more complex and political than the book suggests.
A Practical Starting Point If You're New to This
If you haven't done process change before, start small. Pick one process that affects your team directly, map it as it actually works, identify the top two pain points, and fix those before you think about automation. Use the book as a reference framework, not a step-by-step manual. The chapters on redesign methodology are the most actionable, especially the sections on process modeling and stakeholder analysis. The automation chapters are useful for understanding the landscape of tools available, but don't let them drive the project. The tools serve the process, not the other way around. What I'd add to the book's guidance is a emphasis on testing the redesigned process in a controlled environment before rolling it out broadly. I've seen too many organizations go live with a new process and then discover that the edge cases they didn't consider in the design phase caused widespread failures. A pilot phase, even a short one, with real users and real workloads, catches problems that no amount of planning will reveal. The book mentions pilot testing but doesn't give it the weight it deserves in the overall methodology. The process change landscape has shifted significantly in the last few years with the rise of low-code platforms and AI-assisted workflow tools. The book was written before that shift became dominant, so some of the automation recommendations feel dated. That doesn't make the core framework obsolete, but it does mean you'll need to supplement it with more current resources if you're working with modern tooling. The principles around improvement, redesign, and automation still hold. The execution details have changed.
