Book review: "Business Process Change" by Paul Harmon


There are many books describing business strategy, and many describing the design and development of IT systems. There are very few that link the two activities together. This book is the best that I have read to do so.

This book's subtitle nicely summarises its coverage: "A Manager's Guide to Improving, Redesigning and Automating Processes". It is an introductory guide to Business Process Management (BPM) - in its widest sense, not just covering automation initiatives - and being a recent (2003) book, extends the thinking to include internet-based processes and current standards such as Biztalk and eTOM.

The author is a student of one of the pioneers in the field of BPM, Geary Rummler. Rummler was the co-author of "Improving Performance", a groundbreaking book which introduced the concept of process maps and swimlanes; techniques which have since become the de-facto standard describing business processes.

However, as the book was last revised in 1995, "Business Process Change" provides a welcome update.


Harmon starts with a review of how business strategy is formulated by considering the Porter's work as described in his classic book, "Competitive Strategy". Harmon's summary is a valuable reminder for all business process engineers to validate that a strategy is in place by asking searching questions of the sponsor before starting their work. He then describes how to ensure the strategy is translated into business goals, such as financial targets or customer needs.

Harmon also draws upon Porter's other seminal work, "Competitive Advantage", to show how the business goals should not be mapped onto functional areas, such as sales, but onto what Porter calls "value chains" - those large-scale business processes that convert a customer request into delivered goods or services. Value chains are cross-functional, so that in a typical manufacturing company, a value chain may encompass the sales, engineering, procurement, supply chain, manufacture and warehouse functions. This mapping of business goals onto value chain objectives is the key to the measurement and management of process improvement.

These value chain objectives are then decomposed to activities. Activities are generally the lowest-level process modelled and are usually assigned to a particular role or person. Lastly, measures are established to allow feedback against the business objectives.

Targeting Effort

It would be very unusual to have all business processes targeted in the same way. Harmon describes different types of business process activity:

  • redesign
  • automation
  • improvement
  • management
  • outsourcing.

For each process, he advises consideration of its complexity and strategic importance. Those that are simple or of lower importance should be considered for automation and/or outsourcing. Those processes that are complex and important should be targeted with improvement efforts that are focussed on people, rather than automation.


Harmon builds upon Rummler and Brache's notation for modelling business process. These authors introduced a straightforward notation called process mapping, which was subsequently adopted and extended to form part of the UML (Unified Modelling Language) as Activity Diagrams, and recently further refined into the BPMN (Business Process Modelling Notation). One of the arguments against these recent initiatives is the enormous amount of extra complexity introduced.

Fortunately, Harmon keeps things simple. He uses a small subset of the UML notation to describe clearly business processes at different levels, from an external, top-level company view, decomposing all the way down into role-based activities.

Harmon comprehensively covers different types of process diagrams, from modelling the current situation ("is" diagrams), options for the future ("could" diagrams) - one of which is eventually chosen ("should" diagrams). A key part of his discussion of process modelling is the consideration of process automation efforts - here the modeller can start define the interfaces between human activities and those of proposed IT systems.

He also covers the importance of establishing inputs and outputs for each process and the types of measure to be applied for each output. The discussion of measures includes a useful comparison between his approach and that of the Kaplan and Norton's Balanced Scorecard and KPIs (key performance indicators).


An essential part of the BPM effort is to ensure that the process and measures installed are adequately monitored. Harmon is careful to stress that although functional managers should be responsible for the direct supervision of their staff performing individual activities, it is important that each value chain has its own responsible manager who reports directly to the Board (usually the COO).

Process Redesign

Having discussed process improvement, Harmon discusses at length the more radical approach of process redesign. Using the techniques previously discussed, he covers the setting up of the required teams and an implementation methodology, namely:

  • strategic planning
  • planning
  • analysis ("is" diagrams)
  • redesign ("could" and "should" diagrams)
  • systems development; including human re-organisation as well as IT systems
  • transition throughout the organisation.


This very thorough book also covers other topics as:

  • business process patterns
  • business languages, such as XML and BPEL
  • business process redesign driven by ERP systems such as SAP
  • software considerations, such as architecture, development and tools
  • special considerations for web-based processes.

Lastly, he gives conclusions/recommendations and a comprehensive glossary and references and notes.
This is an enormously useful book, easy to read yet scholarly, covering all aspects of modern business process change. Every practitioner will find new practises that they will be able to put to immediate use.

Additional Thoughts

As mentioned at the start, this book can be regarded as the missing link between business strategy books, such as Porter's, and software engineering requirements books, such as Cockburn's "Writing Effective Use Cases". Use Cases are a widely-used technique for documenting requirements for interactions between people and IT systems.

With care, we have found it possible to link the models described in Harmon's book with IT systems requirements as defined by Use Cases. This traceability can prove invaluable to ensure that systems requirements are not overlooked. This approach will be documented in a future paper.

Copyright (c) 2006 by Marcus Price, Agilier Ltd

Success Stories

"Agilier's experience in managing business processes made them an ideal candidate to manage functional integration thereby reducing a significant risk to the business. This involved them working with the workstream leads and developing a high-level integrated businesses process against which we planned our programme."

Chris Davies
Programme Manager, EADS Defence and Communications Systems


"I was extremely happy with the professional and complete way that Agilier performed their work and would not hesitate to use their services again."

Mike Haynes
Senior Project Manager, Cogent Defence and Security Networks

Book Reviews


Our latest writings, or thought-pieces, appear here.

Take a look at our free, time-saving templates in our new section.

Keep in touch with the latest ideas to help your organisation deliver. Click here for more.

RSS Feed