Process
Tonight I started reading Business Process Change: A Manager's Guide to Improving, Redesigning and Automating Processes, by Paul Harmon. Doesn't sould like a cliff-hanger, does it? It's kept me up way past bedtime.
I'm about 70 pages in, and so far it's great. Paul ties together TQM, Michael Porter, Business Process Re-engineering, Workflow, ERP, CASE, Six sigma, Business Process Redesign, and the net/eBusiness -- all steps leading to today's Business Process orientation. Systems thinking, flows, silos, value chains, alignment, process architecture, and the work of Geary Rummler: it's all here.
These concepts appeared after I'd graduated from B-School. I'm familiar with them all, but from journal articles or the Web or some process of osmosis from the New York Times. I had missed the connections. I'd also failed to appreciate:
- "There has been a basic shift in how strategic goals are aligned with managerial goals in the course of the last two decades. This shift has been a result of the emphasis on business processes and has been driven by the work of Porter and Geary Rummler, and many other business process gurus, who have all placed considerable emphasis on aligning corporate goals, business processes, and job objectives."
The Geary Rummler I remember from the 70s was a behavioralist. I never bought into the stimulus-response oversimplification of the Skinnerians, so I dismissed Rummler as just another bag of ISPI claptrap. Duh!
The chart below, from Improving Performance: How to Manage the White Space on the Organization Chart, which Rummer wrote with Alan Brache in 1990, pried my eyes open. How had I missed their book? This little 3x3 table is profound.
A performance framework (Modified after a figure in Rummler and Brache, Improving Performance)Goals & measures |
Design & implementation |
Management |
|
|---|---|---|---|
Organizational level |
Organizational goals and measures of organizational
success |
Organizational design and implementation |
Organizational management |
Process level |
Process goals and measures of process success |
Process design and implementation |
Process management |
Activity or performance level |
Activity goals and measures of activity success |
Activity design and implementation |
Activity management |
Next day...
- Porter defines business strategy as "a broad formula for how a business is going to compete, what its goals should be, and what policies will be needed to carry out these goals."
Now we come to the business process architecture committee or planning committee, the group that should know what business processes support what goals. In theory, the strategy group feeds the planning group which in turn proposes changes in business process and IT infrastructure.
I have to wonder if this is real or pipe dream. Most of the organizations I've worked in were driven by personality, not logic. Thinking back to the banks, software companies, and high-tech hot-shots I've dealt with, I really don't know if they were doing something this logical when I wasn't looking or if this Business Process stuff is ahead of their curve. (Big company denizens, please comment.)
Turning to organizations, Paul notes that "An organization chart doesn't show the customers. Equally important, it doesn't show the products and services the company provides to customers, or where the resources needed to create the products and services come from in the first place." This is the silo problem.
If you respect the lines on the org chart, you may optimize your unit at the expense of the whole. You win the battle but lose the war. If you've read me for a while, you've heard this before. Locals optimize their fiefdoms at the expense of the federation.
The antidote is "systems thinking," i.e. The Fifth Discipline, taking a broader perspective. Paul says "The alternative is to try to figure out how to assign strategic goals to departments without a clear idea of how the departments must work together to achieve the desired outcomes."
Next we come to notation. A process diagram is a workflow diagram with "swimlanes". Most often, suppliers on the left side, customers on the right, and a presumption that the chronogical flow is left to right. Processes have rounded corners, events and objects have square. Useful models incorporate drill-down, and this keeps the heavy forest from obliterating the trees.
Posted by Jay Cross at December 21, 2003 01:48 AM | TrackBack
A few years back, James Hite in "Learning in Chaos" (1999, Gulf Pub) attempted to align ISD/OD and HPT, but his book is a tough slog, with a whole bunch of scientific theory thrown in. The last couple of chapters are good though. I like what he has to say about human performance technology (HPT):
“The concept of HPT offers an amalgamation of the disciplines which concerns itself with organizational behavior as a whole. This means that human performance is placed in context along with other subsystems that constitute the presence of the organization. From the viewpoint of performance technology, the worthiness of the system as a whole depends not only on human learning, but also on the ways in which that factor is inter-related with electronic knowledge management systems, compensation systems, production systems, and management systems. The value and sustainability of the system is dependent on close interactions among all of the elements in its value chain.” p. 180
It's the most comprehensive explanation of HPT, in one paragraph, I've found so far. The HPT perspective is a good lens through which to start a situational analysis, particularly when the client is confused. It's not the holy grail, but it helps me complete analyses for satisfied (so far) clients.
Posted by: Harold Jarche at December 21, 2003 07:59 AMThere are several things missing from the table. I work with a general model of realization that runs as follows:
Requirements
Design
Implementation
Interface
Documentation
Operations/Experiencial Space
The last three have a per role dimension.
There are a couple more things going on here, however. You have a use domain and an automation or systems domain. And, you have the use practitioner and the systems practitioner. The systems practitoner abstracts away from the use practitioner. The system practitioner sees the system and focuses on it. The use practitioner sees work and focuses on it instead and deals with the system only as needed. These two practitioner types have distinct focus issues that drive a wedge between them.
This leave the use practitioner with the task of designing and planning work. Documentation rarely covers these aspects of systems.
Then, I would say that lumping design and implementation into the same category ignores that design resolves the impedance between the requirements decisions and implementation constraints. Design is not just the process step between the other two, or even the establishment of the architecture, or large spaces view.
If we were to break the table out and add the above aspects of the realization model, then we could go one further and recursively ask what is the requirements for the requirements, the design of, the implementation of, the interface of, the documentation of, and finally the user experience of the requirements. So we have the same kind of granularity shift that they table shows.
We can do the recursion for each layer in the model.
So we would ask what is the activity performer's experience like at the operational level. This isn't activity management. It is doing the work.
It's very much like shopping in a mall. The stores being the activities we step into while doing our work, work that uses those activities. Can the planner, the store clerk or store manager help us? Thee will be so many things in the store I don't attend to, because they are not in the interface, and because they are not within my purpose or work.
Posted by: David Locke at February 3, 2004 02:57 AM
