• Kock: four-step chronology of business process improvement schools of thought:
• Taylor (1911): The Principles of Scientific Management.
• Interests of workers and business owners do not correspond.
• Find most efficient business process that is compatible with workers' interests.

• Mayo, McGregor, Maslow, Herzberg (1940s-50s): Humanist school of management.
• Happy and motivated workers are good workers.
• Good employers have good workers.
  

• Deming and Juran (1980s): Total Quality Management (TQM):
• Work-related problems are a consequence of faulty (badly designed) business processes.

• Hammer, Champy, Davenport (1990s): Business Process Reengineering (BPR):
• New (information) technologies and global competition require significant and constant reengineering of business processes.
• ERP-embedded 'best practices' drive business process redesign.

• (RR) fifth and latest step: Business Process Management (BPM):

• Mutual adjustments of technology such as ERP and business processes.
• Flexible modeling and exploration of process improvement.
• Kock: distinguishes two aspects of the business process:
• Activities: sequences and flows of people actions.
  
• Information: generation, consumption and flows.

• Problem: Kock argues hard(!) to separate activities from information when thinking about business process models. Why?

• Kock separates activity flows from information (communication) flows:
• Notice that in figure 5.6, there is no 'IS' swimlane; in other words, all information repositories (drum-like symbols) are considered independent!
• All information storage is dispersed throughout the diagram.

• All computerized activities are dispersed throughout the diagram.

• Difficult to follow a specific item of information through the process.

• Kock presents some empirical evidence that the communication diagram method works, but we'll do something a little different.

• Consider IS as an actor ==> activity diagram with IS in its own lane.
  

• Case study process mapping (BA302/371): activity/swimlane diagrams with IS as an actor:
  

• Basic symbols (For full set refer to Flowchart Symbols):

  Activity	Document	Computer- based data	Decision	Delay	Continue on next page	Connector	Inventory	External data	Setup	Information or material flow
  										----->

• Problem: Model the rental car preventive maintenance process (p. 81) as an activity diagram; include ISs as actors (lanes).

• Consider problems with this 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?
  

• Problem:  Model an improved version of this process as an activity diagram.
  

• For your project: use the above activity diagram technique:
• Start with a scenario/narrative with actions written in complete sentences (make it wordy! (BA 378 Marshall: narrative first, then diagram. Here: put narrative in the diagram):

• The scenarios describes a so-called use-cases (≠ use-case diagram).

• One use-case per scenario; you might need more than one.
  
• Use-cases must be documented in detail so that they are entirely clear (no ambiguities, no assumptions other than trivial ones).
• Labels and concept terms are models; i.e., they are abstractions.
• Abstractions 'invite' multiple interpretations.
• We must always be able to resolve the original meaning of the abstraction.

• No need for a true narrative such as the rental car narrative on p.81: use a three-lane scenario tool:

Actor & Action	Medium or Tool	Required data
Customer files complaint on-line.	Web-page/form	Complaint: Customer_id Rental reservation_id Date of incidence Narrative Severity
Assistant manager prints a copy of the complaint.	RentalWizard Printer Paper copy of complaint	Complaint.
Assistant manager adds printed copy to accumulation box.	Paper copy of complaint Complaint box
Assistant manager reviews complaints and filters out 'real ones.'	Paper copy of complaint Complaint box Defect manual	Complaint Defect manual rules
Assistant manager hands 'real' complaints to the Rental manager.	Paper copy of complaint	Complaint

• Record ALL information produced or consumed:

• When modeling the existing process, only label information in the 'IS' column if we know it is kept in an IS. Introduce other 'IS' and information repository columns as necessary.
• Only when we model the 'new' and 'improved' process, will be move currently noncomputerized information into the 'IS' lane.

• Explicate the information items in the information columns; i.e., add the data members of this 'class' of information:
  

• e.g., a 'complaint' about a rental car is not just a complaint; it includes things such as the rental vehicle make and type, severity of the complaint, type of complaint/problem, date, etc.

• Problem: Go back to your improved car rental process and add the details of each information item.
  

• How to elicit these processes (use cases) in the first place?