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
Comments

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 AM

There 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

30 Poppy Lane
Berkeley, California 94708

1.510.528.3105 (office & cell)



Subscribe to this Blog

Enter your email address to subscribe. We vow never to share your information with anyone. No Spam.

Subscribe Unsubscribe

Reference Pages

Articles
Blogs
Building Community
CSS, Semantic Mark-Up, and codes
Design
First Principles
Glossary
How People Learn
Knowledge Management
Learning Links
Learning Standards
Making It Work (Implementing)
Metrics & ROI
Presentations
Psychology
Social Software
String theory
The eLearning Museum
Time
Visual Learning


Search


Our Infrequent Newsletter
Sign up for our sporadic newsletter.
Email:


Entries by category...

Blogging
Books
Collaboration
Customer care
Design
Emergent Learning
handbook
Jokes
Just Jay
Learning
Meta
Networking
Outbound
Recycled from Blogger
Ref
store
The Industry
Time
Visual
Workflow-based eLearning


Blogroll


Internet Time Group



© 2004 Internet Time Group



Click for Berkeley, California Forecast
Berkeley, California


Recent entries

New Blog
Blogger Experience, Housekeeping, Something New
Loosely Coupled
Above all
Demographics is destiny
Are you setting the bar high enough?
Virtual Apps
Aerobic Learning
Work as Video Game
Oracle and Macromedia, Sitting in a Tree
The Blogosphere
ASTD Silicon Valley
Performance Support
Kingsbridge Conference Center
First Post by Email
Transition
Inactive Blog
RSS Feed for New Site
Comment Spam
Testing ... testing ... 1...2..3
IT Doesn't Matter - Learning Does.
All blogging is political
Mutlimedia Learning
Damn, damn, double damn
Nonverbal impact?
The New Religion
Shhhhh.....
Wolf! Wolf! Wolf! Wolf! Wolf! Wolf!
Business Process Management (2)
Really Big
Business Process Management Conference
WorkFLOW
Don't Lose a Common Sense: LISTEN
It's only natural
Gmail!
Go with the flow
Time Out for the Fair
Informal get-together in SF this Wednesday
Repetition, reverb, and echoes
Who Knows?
Ur-blogging
Cognitive Mapping
Push vs pull
The Big Picture on ROI
Art Break
TDF Finale
New Community of Practice Forming
Dropouts
More TDF04
Training Directors Forum 2004
A Rare One-Liner
PlaNetwork LIVE 2
PlaNetwork LIVE
ASTD 2004 Leftovers
Googlism
Worker Effectiveness Improvement, not KM
Upcoming Events
eLearning Effectiveness?
Jay's Talk at ASTD
Mintzberg & Cooperider
Lest ye forget
ASTD International Conference & Exposition 2004
Knowledge Tips
What is Workflow Learning?
ASTD msg 1 of n
Look out, it's Outlook
Collaboration at ASTD Next Week
Tell me a story
User indifference
Interdependence
The shortest presentation on metrics you will ever hear
Back to Blogger
Windows fixes
The Alchemy of Growth
Grab bag
Very loosely coupled
E-Learning from Practice to Profit
Robin Good kicks off Competitive Edge
China Bloggers
Sonoma Dreaming
Upcoming Events
Emergent Learning Forum: Simulations
'Lanta
The Best Things in Life Are Free
Metrics and Web Services
OpEd: ROI vs. Metrics
e-Merging e-Learning
Loosely Coupled
Search me
Exercise?