Workflow Modeling - Tools for Process Improvement and Application Development - Artech House 2001

Alec Sharp is the founder and senior consultant of Clariteq System Consulting, Ltd. in West Vancouver, British Columbia, Canada. He is a founding member and past-president of the British Columbia DAMA (Data Administration Management Association) chapter. Patrick McDermott is president of McDermott Computer Decisions, Inc., in Oakland, California. He received his B.A. in Economics from California State University at Sacramento. He has served as director of the Data Management Association (DAMA). --This text refers to an alternate Hardcover edition.

Rarely do I get excited about books on workflow modeling. I have a few good books on the subject, all of which provide solid approaches and most of which are well written. This book stands out because it goes beyond merely "solid" or "well written" by giving one of the most comprehensive approaches to workflow modeling I've had the pleasure of reading.
First, like most books on the topic, none of the components of the approach are new. What makes the approach refreshing is the way the authors take standard techniques and tie them together into a coherent process. Second, this book can be used as a workbook during a workflow modeling project, and is well suited to this because of the numerous checklists and diagrams that will prove invaluable every step of the way. Finally, this is the first book of its kind that incorporates use cases, making it invaluable to project teams that have standardized on UML (Unified Modeling Language)or wish to integrate an object-oriented approach into a workflow modeling project. If you're not familiar with use cases I strongly recommend Writing Effective Use Cases by Alistar Cockburn (the best book on the subject in my opinion); UML Distilled by Fowler and Scott is an excellent introduction to that subject if it's new to you.
The approach is straightforward: frame the process and define its scope, understand the existing process (if there is one), design the "to-be" process and develop use case scenarios. I wish to offer one caveat at this point: if you are reengineering a process that is seriously broken you might consider skipping the "as-is" process. Understanding the existing process is useful if your goal is incremental improvement. Reengineering efforts usually radically transform existing processes, making efforts to understand them both moot and wasted.
Some of the highlights of this book include the authors' clear definitions and way of decomposing complex systems into discrete steps and components. For example, they use a five tier view of processes that ensures you have a complete view of all issues and factors. The views are: (1) mission, strategy and goals (I personally extend goals further into Goal-Question-Metric), (2)business processes, (3) presentation, (4) application logic and (5) data. Note that the last three align nicely to a 3-tier client/server architecture. This observation clearly shows how coherent the authors' approach is and how it can foster alignment of technology to business requirements.
I also like how the authors clarify the key issues in process design by pointing out six enablers that you need to account for during the analysis and design phase: (1)workflow, (2) technology, (3) human resources, (4) motivations and measurements, (5) policies and rules and (6) environmental constraints (facilities, external process capabilities, etc.). There is one minor point of disagreement I have between their workflow modeling technique and the one I use. The authors use swimlane diagrams (also called Rummler-Brache diagrams), while I use deployment diagrams. The difference? Swimlane diagrams do not capture phases or cycles. I always place workflows into the context of Entry Criteria-Task-Validation-Exit Criteria (ETVX), which is nearly identical to the TQM Plan-Do-Check-Act (PDCA) cycle. I insist on ETVX because it allows me to spot missing validation points in an existing workflow, and ensures that I clearly define entry and exit criteria, as well as validation points in a "to-be" workflow. Of course I am stating personal preferences - following the authors' approach verbatim will definitely result in a workflow design that is not only "bulletproof", but will align information systems and business process almost perfectly.
This book is a gem. It's readable, full of ideas and, with the incorporation of use cases into the approach, completely up-to-date with respect to IS/IT methodologies. If you want a fresh, modern approach to workflow design this book is the only one that will provide it.

1 Comment | Was this review helpful to you?

This book nicely sets forth a detailed methodology for doing swimlane diagramming for workflow business processing. This book is for analysts; the discussion is about the nature of business processes that have workflow as a key characteristic. It is not about the architecture of computer solutions for such processes. If you follow the methodology in this book and flesh out the diagrams with use cases (just briefly touched on here), you will have captured most of the requirements for a business workflow process.
The book is nicely bound and well written. The authors have been around a while and the vocabulary and approach fit nicely with older concepts like business process reengineering. The authors are not unaware of the latest developments and "UML" crops up here and there but not in the index. The diagramming is very simple compared to UML activity diagrams.
This is good reading for the domain experts on a team working on the requirements document and a nice primer for geeks who are forced for the first time to talk to the business side of an enterprise.

Comment | Was this review helpful to you?

Can you clearly identify what is a process and what is not?
Ever wanted to know where things usually go wrong in real life process improvement projects?
Have you ever wondered what should be measured in a business process and what should not?
When should you stop analyzing the current process so you can focus on the new one?
How will you go about designing the new process so it doesn't have the same old problems?
What can be done to help address those internal politics between departments that hinder your process improvement efforts?
How many diagrams should you have?
Should this diagram be a swim-lane diagram, a use case or something else?
What is the most important, quick and easy, diagram to capture at the beginning of your process analysis?
What should be in a flow diagram and what should be written out as narrative?

If you ask these sorts of questions, or get asked these questions, then Sharp and McDermott's book is for you. Their combined experience as process troubleshooters, expert project managers and training consultants comes shining through in every part of the book. They are not trying to sell a product nor are they high on the latest industry buzz juice. They have technical depth that is apparent from time to time, but this is not a technical book. If you want to learn a lot about how to improve almost any kind of organizational process, this is a fantastic book. The approach would have worked well 20 years ago and it probably will 20 years from now. Nevertheless, there is some discussion about IT and how important it is to the effort. In fact, the last part of Workflow Modeling shows how to translate all the process analysis work into Use Cases suitable for a detailed software development effort, but that is not the overall emphasis.

The method the author's apply is given in four steps (p29):
1. Frame the process - Identify what is in and out of scope for being in the process to be improved. Make sure you are working on an actual process and if not, locate one important to the original request so it can be improved. Lots of tips on managing upper level management and non-quantifiable factors such as corporate culture, building grass roots support for the project etc. This is roughly 30% of the book.
2. Understand the current as-is process - This is really the meat of this book. Even if you aren't trying to change a process, but just understanding one, this section makes the book worth its price. Using swim-lane diagrams at various levels of detail the book explains how to analyze the stuffing out of a process without getting bogged down in unnecessary detail. Constructing professional swim-lane diagrams with all the actors, milestones, areas of uncertainty, process enablers and many other important topics are covered in practical, how-to terms. Roughly 40% of the book.
3. Design the new (to-be) process - using all you've gathered from previous stages, systematically apply and manage brainstorming and other creative tools to make sure the important parts of true improvement make it into the new process. Roughly 20% of the book.
4. Develop Use Case Scenarios - For those who will then need to launch development work to support the new process (very common) this shows how to bridge that notorious gap between business needs and technical IT work. Roughly 10% of the book.

The style of the book is almost like a manual, but still interesting. The writing style is very informal and keeps the information personally applicable where it might otherwise become dry and abstract. There is some high level management alignment, strategy information in chapter 7 that probably could have been left out, but even this has its useful points. This book is practical and as easy a read as this topic will allow. Highly recommended.