Alter

1
Understanding Business Processes
2
Fords New Payables System
3
Fords New Payables System

• New Payables to reduce staff from 500 to 400.
• Mazdas A/P Staff had only 5 individuals.
• Differences in the Business Process Model
• Consider the degree of structure in Mazda model.
• Much of Fords A/P Staff time was spent on
  Exception Processing.
• New System requires only 125 persons.

4
Fords New Payables System

• What changed in the new Ford system?
• Are the successes of the Ford and Mazda systems
  an indictment of management practices in other
  organizations?
• WCA Framework for Ford Case Study

5
Fords New Payables System
CUSTOMER Fords suppliers Fords manufacturing
and purchasing departments
6
Fords New Payables System
PRODUCT Verification that the the order was
fulfilled correctly by the supplier Payment to
the supplier
7
Fords New Payables System

• BUSINESS PROCESS
• Major Steps
• Order material
• Receive shipments
• Reconcile receipts with purchase orders
• Pay suppliers
• Rationale
• store purchase orders in a shared database
• accept shipments only if they match the purchase
  order
• pay on receipt, not invoice

8
Fords New Payables System
PARTICIPANTS Purchasing department Receiving
department Accounts payable department
INFORMATION Purchase order Receipt confirmation
TECHNOLOGY Computer system supporting a shared
database
9
(No Transcript)
10
Introduction

• In order to develop information systems or
  understand them from a business professionals
  viewpoint, one needs to be able to describe and
  analyze business processes.
• We will emphasize the relationship between
  process architecture and process performance.
  Recall
• Improvements in a work system are usually related
  to the links between the architecture and the
  performance perspectives.
• Customer satisfaction is largely determined by
  product performance.
• Product performance is determined by a
  combination of product architecture and the
  internal work system performance.

11
From work system architecture to customer
satisfaction
12
Process Modeling Business Process Architecture

• Process Modeling - A method of documenting
  process architecture by identifying major
  processes and sub-dividing them into linked
  sub-processes.
• Data Flow Diagrams
• Flow charts
• Structured English

13
Data Flow Diagrams

• Data Flow Diagrams - represent flows of data
  between different processes within a business.
• Simple, intuitive, no focus on computer systems
• Use only four symbols
• focus on analysis of flows between sub-processes
• Flowcharts and other techniques can be sued to
  talk of decision criteria and other details.
• Starting point is a Context Diagram - High Level
  representation
• Example Ford Accounts Payable System

14
Creating Data Flow Diagrams

• The starting point for a DFD is a Context
  Diagram, which shows sources and destinations of
  the data being used and generated.
• The context diagram establishes the scope of the
  system.
• Next identify processes, and break them down into
  sub-processes to describe how work is done.
• The value of DFDs is in resolving disagreements
  about how work is currently done, or it should be
  done in the future.
• Example Ford Accounts Payable.

15
Symbols used in data flow diagrams
16
Context diagram for the Ford purchasing system
17
Data flow diagram showing the main processes in
Fords original purchasing system
18
Data flow diagram dividing PCH 1 into four
subprocesses
19
Example Data Flow Diagram Student Grading
Final Grades
REGISTRARs OFFICE
STUDENTS
Current Grade
Test Scores
Current Score
CALCULATEUNIVERSITYGRADES
CALCULATECLASSGRADES
TEACHER
Final Grades
Final Score
CLASS/GRADEFILE
STUDENTFILE
20
Other Process Modeling Techniques

• DFDs are used extensively. However, other
  techniques can also be used to fill in some
  details not expressed by DFDs. DFDs do not
  express the sequence and timing of processes nor
  the detailed logic of processes.
• Flowcharting - represent the sequence and logic
  of procedures
• Structured English - pseudo-code - represent
  the precise logic of a procedure by writing it
  down.

21
Architectural Characteristics of a Business
Process

• Seven Characteristics that often affect business
  process performance
• 1. Degree of Structure
• 2. Range of Involvement
• 3. Level of Integration
• 4. Complexity
• 5. Degree of Reliance on Machines
• 6. Attention to Planning, Execution, and Control
• 7. Treatment of Exceptions, Errors, and
  Malfunctions

22
1 Degree of Structure

• DEGREE OF STRUCTURE
• the correspondence between inputs and outputs
• structured semi-structured, and unstructured
  tasks
• e.g. Total last month's revenue vs. People
  Magazine Cover Story
• DEGREE TO WHICH STRUCTURE IS IMPOSED
• Highest Substitution of technology for people
• High Enforcement of rules or procedures
• Low Access to information or tools
• Problem if the level is too high
• People doing the work are prevented from their
  judgement.
• People doing the work feel like cogs in a machine
  because they have too little autonomy.
• Problem if the level is too low
• Easily foreseeable errors occur because
  well-understood rules are not applied
  consistently.
• Outputs are inconsistent.

23
Structured and Unstructured Tasks

• Structured Task
• information requirements known exactly
• methods of processing known precisely
• desired format of information known exactly
• decisions or steps within the process are clearly
  defined and repetitive.
• Criteria for making decisions clearly understood.
• Success in executing the task can be measured
  precisely

24
Structured and Unstructured Tasks

• Semi-structured Task
• information requirements and procedures are
  generally known, although some aspects of the
  task rely on judgement of person doing the task.
• Unstructured Task
• so poorly understood that the information to be
  used, method of using the information, criteria
  for deciding when task is done can not be
  specified.
• Unstructured tasks are performed based on
  experience, intuition, trial and error, rules of
  thumb, and very qualitative measures.

25
2 Range of Involvement

• RANGE OF INVOLVEMENT
• too many participants or too few
• the organizational span of people involved in a
  process.
• RANGE OF INVOLVEMENT
• Problem if the level is too high
• Work is slowed down because too many people get
  involved before steps are completed.
• Problem if the level is too low
• Work is performed based on narrow or personal
  considerations considerations, resulting in
  decisions that may not be the best for the
  overall organization.
• The Role of Information Systems
• Information systems can be designed to broaden or
  constrict the range of involvement.
• Executive Information Systems
• Case Manager Approach
• TQM Reduce involvement and empower workers
• Note separation of duties from an internal audit
  perspective.

26
3 Level of Integration

• Integration is the mutual responsiveness and
  collaboration between distinct activities or
  processes.
• In general, the extent of integration between two
  processes or activities is related to the speed
  with which one responds to the other.
• The speed depends on the immediacy of
  communication and the degree to which the process
  responds to the information communicated.
• e.g. level of integration between NJIT Registrar
  and Rutgers-Newark Registrar
• Five Levels of Integration
• common culture
• common standards
• information sharing
• coordination
• collaboration

27
Five levels of integration between business
processes
28
Five levels of integration between business
processes - continued
29
Five levels of integration between business
processes - continued
30
Level of Integration

• LEVEL OF INTEGRATION
• Problem if the level is too high
• Steps in the process are too intertwined.
• Participants in different business processes get
  in each others way.
• To change one step it is necessary to analyze too
  many other steps or processes.
• Problem if the level is too low
• Steps in the processes are too independent.
• The process needs greater integration to produce
  results.

31

4 Complexity

• Systems that are too simple dont handle the
  complexity of the problem systems that are too
  complex are hard to understand, maintain, and
  fix.
• Complexity can be measured by the number of
  elements it contains, and the number and nature
  of their interactions
• Reduce Complexity by reducing low value
  variations, reducing the number of interacting
  components, and simplify the nature of
  interactions.
• COMPLEXITY
• Problem if the level is too high
• Participants, managers, and programmers have
  difficulty understanding how the system operates
  or what will happen if it is changed.
• Problem if the level is too low
• The system cannot handle the different cases that
  it should be able to handle.

32
5 Degree of Reliance on Machines

• Not everything can be automated!
• DEGREE OF RELIANCE ON MACHINES
• Problem if the level is too high
• People become disengaged from their work.
• Peoples skills may decrease.
• Mistakes occur because people overestimate what
  the computers are programmed to handle.
• Problem if the level is too low
• Productivity and consistency decrease as bored
  people perform repetitive work that computers
  could do more efficiently.

33
6 Attention to Planning, Execution, and Control

• Participants in a business process need to know
  what to do, when to do it, and how to make sure
  it was done right.
• Planning - decide what work to do and what
  outputs to produce when.
• Executing - process of doing the work
• Controlling - use information about past work
  performance to assure goals are attained and
  plans carried out.

34
6 Attention to Planning, Execution, and Control
35
Comparison of Planning, Execution, and Control

• PLANNING
• Time focus Future
• Important issues related to information
• Having reliable methods of projecting into the
  future by combining models, assumptions, and data
  about the past and present
• EXECUTION
• Time focus Present
• Important issues related to information
• Providing information that tells people what to
  do now to meet the plan and adjust for any
  problems that have occurred recently
• Using current information to identify problems or
  errors in current work
• Collecting information without getting in the way
  of doing the work
• CONTROL
• Time focus Past
• Important issues related to information
• Having reliable methods of using data about the
  past to develop or adjust plans, and to motivate
  employees
• Provide information current enough that it can be
  used to guide current actions

36
Attention to Planning, Execution, and Control

• ATTENTION TO PLANNING, EXECUTION, AND CONTROL
• Problem if the level is too high
• Too much effort goes into planning and
  controlling within the process, and not enough
  goes into execution.
• Problem if the level is too low
• Insufficient effort in planning and control
  leaves the business process inconsistent and
  unresponsive to customer requirements

37
7 Treatment of Exceptions, Errors, and
Malfunctions
Exceptions The system does not handle special
cases properly. Operational failures The system
fails to operate as intended. Bugs The system
does not correctly reflect the ideas of the
system designers. Design errors The system does
what the designers intended, but they failed to
consider certain factors. Capacity shortfall The
system cannot meet current output
requirements. Displacement of problems The
system creates problems that must be absorbed and
fixed somewhere else. Computer crime The system
is used for theft, sabotage, or other illegal
purposes often based on fraudulent data inputs.
38
Treatment of Exceptions, Errors, and Malfunctions

• The danger in designing systems is not planning
  for the unexpected.
• A mistake should be as easy to correct as it was
  to commit in the first place!
• TREATMENT OF EXCEPTIONS, ERRORS, AND MALFUNCTIONS
• Problem if the level is too high
• The process focuses on exceptions and becomes
  inefficient and inconsistent.
• Problem if the level is too low
• The process fails altogether or handles
  exceptions incorrectly, resulting in low
  productivity or poor quality and responsiveness
  perceived by customers.

39
Evaluating Business Process Performance

• PROCESS PERFORMANCE VARIABLES
• Rate of output
• Consistency
• Productivity
• Cycle Time
• Flexibility
• Security

40
Evaluating Business Process Performance

• PROCESS PERFORMANCE VARIABLES
• Rate of output - the amount of output it
  actually produces in a time period
• consider capacity and scalability
• How can I handle special needs?
• Consistency
• A Basic TQM tenet unwarranted variation
  destroys quality.
• Carefully specify how something should be
  performed and monitor the process to ensure it is
  performed consistently.

41
Control chart for monitoring consistency of a
business process
42
Evaluating Business Process Performance

• PROCESS PERFORMANCE VARIABLES
• Productivity - amount of output per level of
  resource usage.
• Resources mean money, time effort.
• Control waste (consumption of resources with no
  output value).
• Cycle Time - (the total time from start to
  finish
• what about waiting time?
• Bottlenecks?

43
Evaluating Business Process Performance

• PROCESS PERFORMANCE VARIABLES
• Flexibility - (ease of adjustment to meet
  immediate customer needs)
• Security - (likelihood of vulnerability to
  unauthorized use, sabotage, criminal activity,
  etc.)

44
Finding the Right Level for Each Process
Performance Variable

• RATE OF OUTPUT
• Problem if the level is too high
• Lower productivity and consistency due to
  increasing rates of errors and rework
• Problem if the level is too low
• Lower productivity due to the cost of unused
  capacity
• PRODUCTIVITY
• Problem if the level is too high
• Too much emphasis on cost per unit and too little
  emphasis on quality of the output
• Problem if the level is too low
• Output unnecessarily expensive to produce
• CONSISTENCY
• Problem if the level is too high
• Inflexibility, making it difficult to produce
  what the customer wants
• Problem if the level is too low
• Too much variability in the output, reducing
  quality perceived by the customer

45
Finding the Right Level for Each Process
Performance Variable

• CYCLE TIME
• Problem if the level is too high
• Lack of responsiveness to customer
• Excess costs and waste due to delays
• Problem if the level is too low
• Product produced too soon is damaged or
  compromised before the customer needs it Delivery
  before the customer is ready
• FLEXIBILITY
• Problem if the level is too high
• Too much variability in the output, reducing
  quality perceived by the customer
• Problem if the level is too low
• Inflexibility, making it difficult to produce
  what the customer wants or to modify the process
  over time
• SECURITY
• Problem if the level is too high
• Excess attention to security gets in the way of
  doing work
• Problem if the level is too low
• Insufficient attention to security permits
  security breaches

46
Information systems related to Mintzbergs
management roles
47
Common Sources of Management Information
FORMAL, COMPUTER-BASED Internal sources Key
indicators generated by internal tracking
systems External sources Public
databases FORMAL, DOCUMENT-BASED Internal
sources Planning reports, internal
audits External sources Industry reports, books,
magazines FORMAL, VERBAL Internal sources
Scheduled meetings External sources Industry
forums INFORMAL Internal sources Lunch
conversations, gossip, management-by-walking-aroun
d External sources Trade shows, personal contacts