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 functional 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 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 & strategic decision making.

Teaching & 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 do not not.

Most exchanges require only sequencing; not synchrony ==> explains the success of mail (drop-off) boxes and email.

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

Reduction of information duplication:

Class project: information is entered and stored twice:

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 duplication required or desirable? ' ==> 'synchronization' rather than separate data entry:

UC/LC databases.

TVA Knoxville/Chattanooga.

Eliminating unnecessary information flows:

P. 81 car rental maintenance schedule: people as information throughput.

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 imply synchrony.

Contacts points increase the likelihood of errors:

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.'

Problem: do you know of other examples?

Minimize high-level knowledge transfer during operations:

Separate the routine/predictable/frequent tasks from the infrequent/unpredictable/nonroutine.

On-the-job training is frequently inefficient (great for the learner, not so good for the process).

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 it part of (pretty much) every IS design project.

Traditional approach to 'Requirements analysis:' ask the stakeholders what the system should do.

Problem: why does this almost never work?

Modern: task-centered design: business process scenarios: use-cases:

Lewis and Rieman downloadable book on task-centered (user interface) design.

Stakeholders describing their jobs/tasks in detail:

Task timing:

Absolute; e.g., at 8:00 AM on weekdays, a report is generated...

Relative; e.g., X generates the data, then sends them to Y.

Required data:

Source (organization, location).

Formats.

Ownership/responsibilities.

Consequences of not meeting the task timing requirements.

Develop multiple scenarios or use-cases: normal workdays, special days (holidays, weekends), exceptional/crisis situations, etc.

Problem: Why does this almost always work?

Our job as system designers:

Carefully document the business processes: customer review and modification until customer signs off!

Scenarios/use-cases will function as cognitive walkthrough documents throughout the remainder of the design.

Involved customers invariably consider scenario reconstruction as a modeling and remodeling exercise

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.

Commercial 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.

Business process outsourcing.