BA 371 Business Systems Analysis - Business Process Remodeling

BA371 - Business Process Remodeling/Improvement

Kock Ch. 6: Factors affecting targeting BPR projects:

Business process rigidity:

High investments in an existing process lowers the likelihood of its reengineering.

Regulatory constraints may prevent/discourage BPR; e.g., CRSS; USBR UC/LC dual installations HDB.

Regulatory constraints (aka bureaucracy) often reinforce rigidity in functionally heterogeneous environments.

Lack of management support.

Employee resistance:

Institutionalized employee behavior (another form of regulatory constraints).

Fear of future.

Loss of ownership.

Lack of involvement.

Distrust and fear.

Kock Ch. 8: Candidates for improvement:

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.

Problem: do you see any synchrony/co-location/sequencing issues in our class project / case study?

Reduction of information duplication:

Duplicate data entry: (class project and LOTS of real-world situations (Metters et al. 157.: LAPD: 70 recordings of DUI suspect's name (1996)):

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:

www.TeachEngineering.org's mirrors database.

TVA Knoxville/Chattanooga.

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 defect 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?

Problem: do you see any unnecessary information flow issues in our class project / case study?

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.

(ex) 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?

Minimize high-level knowledge transfer during operations:

Separate the routine/predictable/frequent tasks from the infrequent/unpredictable/nonroutine 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.

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.

Kock Ch. 9: Using IT to enable new process designs: three fundamental options:

DIY/in-house development:

Still popular.

Often the most expensive and not necessarily the most effective.

Off-the-shelf package optimization:

Base package provides most of the needed functions.

Consider adjusting your business processes to the package (e.g., ERP).

Need good Application Programming Interface (API); e.g., SAP's ABAP.

Often need 'middleware:'

Buid and maintain in-house.

Off-the-shelf.

One of the blessings of XML: middleware on its way out?

Business process outsourcing.

Up-and-coming: Service-Oriented Architectures (SOA):

Subscribe to integrated software services maintained elsewhere (Yahoo, Salesforce.com, etc.).

Application (Service) Servers to integrate external software services.