Here's the second in the series. Sixteen years ago, as America tried to forget the dreary eighties, two consultants got rich "reengineering" corporations to be better suited to the high tech world ahead. Most corporations ended up using the concept as cover for big-time downsizings, so it got a real bad rap. I remember the book as being more interesting than that. If nothing else, it's a marker of a historic transition as corporations became fully dependent on networked computers.
So, in honor of our recent reenactment of the 1980s, here are my 1996 notes, copied and pasted from a web 1.0 page (btw, the Amazon link is the original from the late 90s. It still works.) ...
I wrote up these notes when I was reading Hammer and Champy's book. They're reprinted here for public use. The notes are my own, and may bear no resemblance to the book. My comments are in italics, they focus on primary care. Hammer and Champy's ideas are not all original, and many people (myself included) disagree with their analysis of the costs and benefits of their particular approach to reengineering. Indeed, since I put these notes together (1996) reengineering has fallen from grace. I still think there's something to it however.
Reengineering The Corporation: A Manifesto for Business Revolution
Michael Hammer and James Champy, Reengineering The Corporation: A Manifesto for Business Revolution. Harper Collins 1993.I wrote up these notes when I was reading Hammer and Champy's book. They're reprinted here for public use. The notes are my own, and may bear no resemblance to the book. My comments are in italics, they focus on primary care. Hammer and Champy's ideas are not all original, and many people (myself included) disagree with their analysis of the costs and benefits of their particular approach to reengineering. Indeed, since I put these notes together (1996) reengineering has fallen from grace. I still think there's something to it however.
Reengineering Notes
Key Characteristics of Reengineering
- processes: process oriented (most important component)
- fundamental
- radical
- dramatic
- When I read this book, I felt that the "technocentric" reorganization of work was common to all of their successful examples. That is, changing work to organize it around inflexible but powerful technologies. It is an unfortunate truth that we humans are far more flexible than our technologies. Change for us is painful, but it is possible if the rewards are sufficient.
Themes for Reengineering
- process orientation
- ambition
- rule-breaking
- creative use of information technology: IT enables change
Characteristics of Reengineered Business Processes
- several jobs combined into one
- workers make decisions
- the steps in the process are performed in a natural order
- processes have multiple versions
- work is performed where it makes the most sense
- checks and controls are reduced
- reconciliation is minimized: reduce "accounting" procedures.
- a case manager provides a single point of contact. example: the primary care physician
- hybrid/centralized operations are prevalent. (I'm not really convinced by their arguments for this point.)
Characteristics of the Reengineered Workplace
- work units change from functional deparments (gastroenterology) to process teams (family practice).
- jobs change, from simple tasks to multidimensional work (a professional)
- roles change: "empowerment". and, inevitably, power shifts, ergo depowerment
- job preparation changes: from training to education.
- focus of performance measures and compensation shift from activity to results (what if the results are very hard to measure?)
- advancement criteria change -- from performance to ability. (How does one measure "ability"in clinical practice? By board scores? I don't think so ... By outcomes?)
- values change -- from protective to productive.
- organizational structures change -- from hierarchical to flat (Here again I'm not sure how well this applies to all settings, or how fundamental this is to the reengineering process. Does "equal" mean equally replaceable?)
- executives change -- froms scorekeepers to leaders
Approaching a Reengineering Project
- Identify problem processes, other problems, challenges, puzzles (use standard systems analysis techniques). Look for known broken processes or symptoms of broken processes
- data redundancy, rekeying, extensive information exchange
- inventory, buffers, system slack
- high ratio of checking-control to value added
- rework and iteration
- complexity, accretions, special cases
- identify/note technologies: computers, systems
- apply "inductive thinking"
- recognize a "solution" (computer/systems technology) and seek the problem it might solve.
- identify longstanding "rules" or limitations that a new technology can now break.
- want to keep up on latest technologies, and evaluate opportunities. This is what has been long criticized as a solution in search of a problem!
- start with feasible projects
- Benchmark from the world's best, not the industry's best.
Understanding Processes
- Most companies have ten or so principal processes.
- Begin by understanding what the processes's customer does with the process output. What are the customer's real requirements? How does this compare to their self-identified needs?
- Learn the what and why rather than the how. The how will change.
How to Fail at Reengineering: Common Mistakes
- Try to fix a process rather than change it.
- Don't focus on business process.
- Ignore everything except process redesign.
- Neglect people's values and beliefs.
- Be willing to settle for minor results
- Quit too early.
- Place prior constraints on the definition of the problem and the scope of the reengineering effort.
- Allow existing corporate cultures and management attitudes to prevent reengineering from getting started.
- Try to make reengineering happen from the bottom up -- without strong top-level support.
- Assign someone who doesn't understand reengineering to lead the effort.
- Skimp on the resources devoted to reengineering.
- Bury reeningeering in the middle of the corporate agenda.
- Dissipate energy across many reengineering projects.
- Atttempt to reengineer when the CEO is two years from retirement.
- Fail to distinguish reengineering from other business improvement programs.
- Concentrate exclusively on design.
- Try to make reengineering happen without making anyone unhappy. (I think they could have said more here about identifying winners/losers and considering compensation for "losers"
- Pull back when people resist making reengineering's changes.
- Drag the effort out.
No comments:
Post a Comment