Business Process Redesign

Tools of the Trade

Car Maintenance Example (Kock, P. 81)

Before Redesign

Activity vs. Information/Communication Flow

Synchronous Process Replacement of synchronous with asynchronous

components: • Synchrony; e.g., meetings, requires actors to be simultaneously

available (rigid timing constraint). • Problem worsens if synchrony is coupled with co-location; e.g., face-

to-face meetings: Tactical and strategic decision making. Teaching and learning. Regulatory requirements; e.g., person must sign under presence of a notary

public, sign for a package, etc. Confidential or classified information.

• Whereas the exchange of higher forms of information (Kock's 'knowledge') may require synchrony and co-location, the exchange of lower kinds of information most often does not.

• Most exchanges require only sequencing; not synchrony ==> explains the success of (e)mail.

• See any of this in our Case Study?

Knowledge Transfer During Operations

Minimize high-level knowledge transfer during operations: • Separate the routine/predictable/frequent

tasks from the infrequent/unpredictable/non-routine ones. On-the-job training is frequently inefficient (great

for the learner, not so good for the process). Use the proper medium for information transfer; e.g., complex reasoning is often faster communicated face-to-face.

• See any of this in our Case Study?

Information Duplication Reduction of information duplication:

•  Duplicate data entry: (class project and LOTS of real-world situations: Problem: in the preventive car maintenance example (p. 81), how many

independent (separate) recordings of a complaint exist? Potential for errors. Requires dual updates. If repositories not in sync:

Multiple views of the same construct. Different actors use different information.

• Example (p. 140): Car maker's inventory is maintained by its suppliers.

• Problem: when is data duplication required or desirable? ' ==> 'synchronization,' 'mirroring,' or 'slaving' rather than separate data entry: Catalog & Schedule of Classes.

See any of this in our Case Study?

Unnecessary Information/Data Flows

Eliminating unnecessary information and/or data flows: • Car rental maintenance process (p. 81): people and process

steps as information/data conduits without processing. • Inability to separate data from information (track only what

you (really) must know). • The less you track, the less you must control. • However!!!: what you must control, you must track. • Downstream controls may relax upstream controls:

If a defective product is filtered out down the line, why check now? If the compiler catches all syntax errors, why worry about them

while writing code? Problem: How valid is this reasoning? Is there a happy medium?

See any of this in our Case Study?

Information Transfer Points Reducing information transfer (handoff/over)

points: • Any information transfer implies the chance of information

loss: Data transfer points increase entropy and noise. Contact points increase the likelihood of errors but can also help

the process along: Most administrative tasks require some form of human judgment (R. Pahl). Human judgment implies variation. Example: call the airline, explain your situation and get a 'no.' Wait a few

minutes, call again, get a different clerk and get a 'yes.' Irony: 'judgment calls' are needed; yet provide opportunity for error. Problem: do you know of other examples? Problem: can you see situations in which this human intervention is

beneficial? See any of this in our Case Study?

How to find good targets for BPR in the first place?

Biggies are easy to spot, but what about the more subtle ones? • Kock (p. 149): If TQM is a continuous

process, make process modeling a regular part of people's jobs.

• Make process modeling part of (pretty much) every IS design project.

Consider problems with the Car Maintenance process: • If the 'Rental manager' has no activity but passing along information; why

is (s)he part of this process? Did we forget to model an 'approval' step ? • An information repository in between two activities by the same actor is

'suspect:' Does the Assistant rental manager (Figure 5.6) really have to download and

process individual complaints before reviewing a whole set of them once a week? Can we automate this 'piling' up of information?

• Two adjacent information source/destinations are 'suspect:' Why is the 'Rental manager' passing on information to the 'Assistant maintenance

manager' without doing anything? Is (s)he only a conduit? Why is the 'Assistant maintenance manager' passing on information to the 'QC

specialist' without doing anything? Is (s)he only a conduit? Can we exclude both the 'Rental manager' and the 'Assistant maintenance

manager' from the process? What about the QC specialist? Does (s)he need to be involved in this process?

• Do we need multiple ISs? • Can we remove the 'human' decision step of filtering complaints?

After Redesign