BA371 — Business Process Remodeling/Improvement
- Kock Ch. 6: Factors affecting targeting BPR projects:
- Business process rigidity ("systemic resistance to change" — p.118):
- Problem: Why would anyone involved in an inefficient process not want to improve/re-engineer it?
- Inertia: previous investment in an existing process lowers the likelihood of its reengineering.
- Regulatory constraints may inhibit BPR; e.g.,
- United States Bureau of Reclamation(USBR) Upper Colorado (UC) / Lower Colorado (LC) dual installations of Hydrologic DataBase (HDB).
- 1920 Merchant Marine Act (aka 'Jones Act').
- Problem: Do regulatory constraints apply in our case study?
- BPR is expensive; hard and time-intensive work; people need room in their work schedule to do this.
- e.g., scheduled Kaizen events.
- Lack of management support (often BPR encouraged but not truly/honestly supported/funded).
- Employee resistance:
- Institutionalized employee 'behavior' (essentially another form of regulatory constraints; e.g., unions,
collective bargaining agreements, etc.).
- Fear of future.
- Loss of ownership.
- Lack of involvement.
- Distrust and fear:
- Jobs / positions threatened.
- Worse if no appropriate resources (funds, staff, time) are made available.
- Worsens if no managerial follow-through.
- Must see the value/interest.
- Harrington, H. J. (2012) Streamlined Process Improvement: Possible (but still difficult!!) ways to reduce employee resistance to change:
- No-layoff policy; e.g., Chili's and FedEx.
- Public commitment to retrain/repurposing of people no longer needed in the new process.
- Involve stakeholder groups such as unions.
- Problem: Do we have any of this in our class project?
- Kock Ch. 8: Five classic candidates for improvement (Note: these are not independent of each other!!!):
- Consider replacing synchronous
with asynchronous components:
Consider reducing data duplication:
- Synchrony; e.g., meetings, requires actors to
be simultaneously available (rigid timing constraint).
- Cost are a multiple of the people involved.
- Delays become much more likely.
- Example: BA371 2012 class project G.
- Problem worsens if synchrony is coupled with co-location;
e.g., face-to-face meetings:
- Implies move time.
- Tactical and strategic / classified and confidential decision making —> Alternative: on-line meetings
- Traditional on-campus classes —> Alternative: distance/on-line learning.
- Regulatory requirements; e.g.,
person must sign under presence of a notary public, sign for a package, write an exam at a certain place
at a certain time etc.
—> digital signatures; e.g., enotary.
- Problem: other examples?
- However... if synchrony / co-location are occurring anyway, might as well use. COB placement project example!!
- Whereas the exchange of higher forms of information (Kock's 'knowledge') may sometimes require synchrony and co-location, the exchange of
less complex kinds of information most often does not.
- Most exchanges require only sequencing; not synchrony —> explains part of the success of (e)mail.
- Problem: Do you see any synchrony/co-location/sequencing issues in our class project / case study?
- Problem: Special case of synchrony: Why is www.doodle.com as a tool
for planning a synchronous event so much nicer/better than trying to do this with email?
- Problem: Similar special case of synchrony: Why is simplybook.me as a tool
for scheduling appointments so much nicer/better than trying to do this with email?
Consider eliminating unnecessary information and/or data flows (eliminate hypercommunication):
- Duplicate data entry: (class project? and LOTS of
real-world situations (Metters et al. p.157: LAPD: 70 separate/independent recordings of DUI suspect's name (1996):
- Potential for errors.
- Requires repetition of updates.
- If repositories not in sync:
- Multiple views of the same construct (recall BA302 example of failed Nike (duplicate) sales forecast).
- Different actors use different information.
- Example (p. 140): Automaker's duplicate record keeping of inventory and purchasing:
- Multiple processes for the same objective; e.g., two purchasing systems:
- Same orders placed multiple times (from both systems).
- —> Unnecessary inventory and its associated cost (purchasing / storage / monitoring, etc.)
- Extra inventory stored inappropriately —> defective parts.
- Conflicts between automaker and suppliers about who bears the cost (automaker was main customer of several suppliers).
- Nowadays: suppliers monitor and update the automaker's inventory by interacting with the car maker's ERP system.
- Another example: OSU/IRB processsing requires providing the same info over and over again.
- Problem: when is
data duplication required or desirable? —> 'syncing,'
'mirroring,' or 'slaving' rather than separate/dual data entry:
- TVA Knoxville/Chattanooga.
- Twin tower banks after 9/11.
- UC/LC HDB syncing.
- Hadoop systems store all data three times, each at a different location.
Consider reducing information transfer (handoff/over) points:
- Car rental maintenance process (p. 81): people and process
steps as information/data conduits without processing.
- Needless spread of data; e.g., mass email/listserv request for input and each responder replying to everyone on the sent list.
- doodle.com advantage applies here as well.
- Inability to separate data from information (track only what you (really) must know):
- OSU IRB application documents —> information and formatting mixed up in (standard, nonXML-ed) Word documents; takes a human to separate.
- 'G' case: information bundled in unstructured blocks of text living in a database.
- Corvallis PD case: tables of data in Word documents.
- City of Portland: results of performance reviews in PDF documents.
- Hypercommunication issue: The less you track, the less you must control.
- However!!!: what you must control, you must track.
- Problem: do you
see any unnecessary information/data flow issues in our class project / case study?
Consider minimizing high-level, non-operational knowledge transfer during operations:
- Any information transfer, manual or electronic, 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:
- Many administrative
tasks may require some form of human judgment (Ray Pahl - role of clerks).
- Human judgment implies variation.
- (Dated) example: call the airline, explain your situation and get
a 'no.' Wait a few minutes, call again, get a different clerk and get
- Irony for IS/automation: 'judgment calls' are frequently needed; yet provide opportunity for error.
- Separate the routine/predictable/frequent tasks from the infrequent/unpredictable/nonroutine ones (operations ≠ tactical ≠ strategic).
- 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 than through asynchronous email.
How to find good targets for BPR in the first place?
Kock Ch. 9: Using IT to enable new process designs: three fundamental as well as some more 'modern' options:
- 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.
- Asking workers to reconstruct/model their own processes is a good method for critiquing those processes (task-centered design).
- Make process modeling and assessment part of (pretty much) every IS design project.
- DIY/in-house development:
- Becoming less popular quickly and increasingly replaced by rented services.
- Often the most expensive and not necessarily the most effective.
- Problem: When needed/beneficial?
- Problem: Is there a role for open source here?
- Buy the systems and run them yourself.
- Rent the sytem: Software as a Service (SaaS) / cloud services: software services maintained
elsewhere; e.g., Salesforce.com, doodle.com, Gmail, Office365, etc.
- Third party package(s) or SaaS platforms provide(s) most of the needed base platform; in-house applications run on top of them.
- Consider adjusting your business processes to the package;
e.g., ERP's 'best practices'.
- Need good Application Programming Interfaces (APIs); e.g., SAP's ABAP; Google's Chart and Maps APIs, Twitter API, etc.
- Might need middleware to facilitate 'graunching':
- Build and maintain in-house.
- One of the blessings of XML/JSON: no more middleware!!
- Business process outsourcing.