BA371 -Business Process Re(engineering)

• Kock: 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 & 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:
• New (information) technologies and global competition require significant and constant reengineering of business processes.
• ERP-embedded 'best practices' drive business process redesign.

• (RR) Latest: Business Process Management (BPM):
• Mutual adjustments of technology such as ERP and business processes.
• Flexible modeling and exploration of process improvement.
• Kock: distinguish two aspects of the business process:
• Activities: sequences & flows of people actions.
  
• Information: generation, consumption & 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 'computer' swimlane; in other words, all information repositories (drum-like symbols) are considered independent!
• ==> no system 'architecture' is assumed.

• (people) data sources without associated activities are 'suspect:'
• 'Customer' (Figure 5.6), clearly has to 'do' something (file a complaint online).
• If the 'Rental manager' (Figure 5.6) has no activity; why is (s)he part of this process? Did we forget to model an 'approval' step (p.81)?

• 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 source/destinations are 'suspect:'
• Why is the 'Rental manager' (Figure 5.6) passing on information to the 'Assistant maintenance manager' without doing anything? Is (s)he only a conduit?
• Why is the 'Assistant maintenance manager' (Figure 5.6) 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?

• 370/378 process mapping:

• Activity/communication diagram hybrid (aka swimlane diagram):

• Note how the solid/dashed arrows distinguish (people) activities from information flows.

• For your project: use the 370/378 (hybrid) activity diagram technique:
• Record ALL information produced or consumed:
• e.g. in the above cotton-buying process, information is exchanged between buyer and sales clerk, yet this information exchange is 'hidden' in the 'activity' arrow connecting the two actors.
• When modeling the existing process, only label information in the 'computer' column if we know it is kept on a computer. Introduce other 'information' columns as necessary.
• Only when we model the 'new' and 'improved' process, will be move currentlu noncomputerized information into the 'computer' column.

• Explicate the information items in the information columns:
• e.g., a cotton 'sale' is not just a sale; it includes things such as a type of cotton, a price, a volume, a delivery date, an order cancellation date, etc.
• 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.

• Notice that these diagrams are models:
• Problem: What's a model?
• Problem: What makes a model a good model?

• Always(!!!) start with an activity diagram with actions written in complete sentences (make it wordy! (Marshall: narrative first, then diagram; Here: put narrative in the diagram):
• The initial activity diagrams describe so-called use-cases (≠ use-case diagram).
• 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.

• Problem: Model Kock's car rental maintenance process (p.81) using the (adapted) version of a 370/378 activity diagram.

• Problem: Target parts of this process for improvement and model the improved process.

• How to elicit these processes in the first place?
  

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

!!!Note that the results from the requirements/needs analysis do not(!!) contain technical specifications!!!