Business Process Change, 2

This is a continuation of my notes from Paul Harmon's Business Process Change.

Paul walks us through the notational schemes for modeling organizations, processes (where the top swimlane is always reserved for the customer), and activities. Why the differences? Because each is at a different level of detail, paralleling the Rummler-Brache model. (An excellent summary of the model appears on page 160.)

Harmon thinks that managers of the future should be as fluent with business processing modeling tools as today's managers are with spreadsheets and organization charts. Work gets done in processes. Managers are responsible to see that work gets done in the processes they manage. This involves planning processes and managing processes. Planning involves setting goals and expectations, estalishing plans and budget, providing resources and staff, and implementation. Controling has to do with monitoring the process, reinforcing success, diagnosing deviations, and taking necessary conrrective actions. Process measure derive from general measures of customer satisfaction with the outputs of a process. From these measures, we work backward to measure how each department might contribute to customer satisfaction.

Six Sigma has evolved into a systematic approach to process improvement.

Business Process Reengineering earned a bad reputation when people came to view it as a heartless tool for Chainsaw Al's, a euphemism for downsizing. The activity itself, drawing an ideal process on a blank sheet of peper is still a worthwhile thing to do. It's called for in major reorganizations, simplifying how things are accomplished, eliminating non-value-adds, and closing gaps and disconnects. Paul suggests a "business process redesign pattern" for each of these.

Paul credits Tom Davenport's Mission Critical: Realizng the Promise of Enterprise Systems with helping popularize packaged software apps for improving and integrating systems. SAP, PeopleSoft, and Oracle refer to their apps as "best processes," although by definition, there are average processes. When I read Davenport's book, I missed the point, thinking this was the way you'd want to do things no matter what; I didn't appreciate that any of this was new.

Installing ERP apps is backwards compared to the blank-sheet-of-paper idealism described earlier. You start with a solution and then modify your processes to accommodate the software. ERP software is not that simple to change; if you expect to make major changes, perhaps you shouldn't be considering ERP in the first place.

Chapter 13 gives a history of software development that I am not going to go into, save to say that these days lots of development is driven by models rather than coders.

Important development framework for enterprise software architecture was written by IBM's John Zachman in 1987. (See here.

I found this a very enlightening book, although I'll admit to leafing through the last 1/3 rather rapidly. No matter. This one will be on my reference shelf.

Posted by Jay Cross at December 28, 2003 02:08 PM | TrackBack