Introduction to Systems Development

Copyright 2012 Pearson Education

20-1
BAC4684
ERP Systems
Learning Objectives
Explain the five phases of the systems development life
cycle.
Discuss the people involved in systems development and
the roles they play.
Explain the importance of systems development planning
and describe planning techniques.
Discuss the various types of feasibility analysis and calculate
economic feasibility.
Explain why system changes trigger behavioral reactions,
what form this resistance to change takes, and how to
avoid or minimize the resulting problems.
Discuss the key issues and steps in systems analysis.
Copyright 2012 Pearson Education 20-2
System Analysis
When a new or improved system is needed, a
written request for systems development is
prepared. That request describes:
The current systems problems.
The reasons for the proposed changes.
The goals and objectives of a proposed system.
The anticipated benefits and costs.
Copyright 2012 Pearson Education 20-3
Systems Development Life Cycle
(SDLC)
Copyright 2012 Pearson Education 22-4
Behavioral Aspects of Change
The best system will fail without the support of
the people it serves.
So the behavioral aspects of change are
crucial.
You need to be aware of and sensitive to the
types of behavioral problems that can result
from change.
Copyright 2012 Pearson Education 20-5
Behavioral Aspects of Change
Why behavioral problems occur
Employees will tend to view change as good if they
believe it will affect them positively and vice versa.
Copyright 2012 Pearson Education 20-6
Positive effects
Faster and accurate
information gathering
No data redundancy
integrated system
Business process
streamlining increase
productivity
Equal to HIGHER BONUS











Negative effects
Lack of knowledge on IS
development
Need to train staff
higher cost incurred
Time consuming
system development
and daily operation











Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background

Copyright 2012 Pearson Education 20-7
Employees are more likely to accept change if they
are:
Young;
Highly educated; or
Comfortable with technology.
Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background
Manner in which change is introduced


Copyright 2012 Pearson Education 20-8
The rationale used to sell the system may need to
vary with the job responsibilities of the employees
involved.
Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background
Manner in which change is introduced
Experience with prior changes


Copyright 2012 Pearson Education 20-9
Employees who had a bad experience with
prior changes are more reluctant to cooperate.
Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background
Manner in which change is introduced
Experience with prior changes
Top management support


Copyright 2012 Pearson Education 20-10
Employees who sense a lack of top-
management support for change wonder why
they should endorse it.
Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background
Manner in which change is introduced
Experience with prior changes
Top management support
Communication


Copyright 2012 Pearson Education 20-11
Employees are unlikely to support a change
unless the reasons behind it are explained.
Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background
Manner in which change is introduced
Experience with prior changes
Top management support
Communication
Biases and natural resistance to change

Copyright 2012 Pearson Education 20-12
Employees may be too emotionally attached to
their duties or co-workers and may not want to
change if those elements are affected.
Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background
Manner in which change is introduced
Experience with prior changes
Top management support
Communication
Biases and natural resistance to change
Disruptive nature of the change process

Copyright 2012 Pearson Education 20-13
Disturbances often create negative feelings.
Behavioral Aspects of Change
To minimize adverse behavioral reactions, it
helps to understand why resistance occurs:
Personal characteristics and background
Manner in which change is introduced
Experience with prior changes
Top management support
Communication
Biases and natural resistance to change
Disruptive nature of the change process
Fear

Copyright 2012 Pearson Education 20-14
May include fear of:
The unknown
Failure
Technology
Losing respect or status
Losing their jobs
Behavioral Aspects of Change
How people resist AIS changes
Resistance to change often takes one of three
forms :
Aggression
Copyright 2012 Pearson Education 20-15
Behavior intended to destroy, cripple, or weaken the
systems effectiveness.
Examples: Increased error rates, disruptions, or deliberate
sabotage.
Behavioral Aspects of Change
How people resist AIS changes
Resistance to change often takes one of three
forms :
Aggression
Projection
Copyright 2012 Pearson Education 20-16
Blaming the new system for any and every unpleasant
occurrence, i.e., the system becomes a scapegoat.
To preserve the integrity of the system, these criticisms
must be controlled or answered.
Behavioral Aspects of Change
How people resist AIS changes
Resistance to change often takes one of three
forms :
Aggression
Projection
Avoidance
Copyright 2012 Pearson Education 20-17
If I dont use this thing, maybe it will go away!
At Davis Controls, the CEO eventually had to
terminate employees who avoided using a new
information system.
Behavioral Aspects of Change
Reactions to change can be improved by
observing the following guidelines:
Obtain management support
Appoint a champion who can provide resources
and motivate others to assist and cooperate with
systems development.
Meet users needs with respect to the form,
content, and volume of system output.
Avoid emotionalism
Emotional issues should be allowed to cool,
handled in a non-confrontational manner, or
sidestepped.
Copyright 2012 Pearson Education 20-18
Behavioral Aspects of Change
Reactions to change can be improved by
observing the following guidelines: (cont.)
Involve users
Allow users to make suggestions and help in
decision-making.
It is ego enhancing, challenging, and intrinsically
satisfying.
Users who participate will be more committed to
using the system.
Copyright 2012 Pearson Education 20-19
Behavioral Aspects of Change
Reactions to change can be improved by
observing the following guidelines: (cont.)
Allay fears
To the extent possible, reassure employees that no
major job losses or responsibility shifts will occur.
If employees are terminated, severance pay and
outplacement services should be provided.
Provide training
Effective use and support is not possible if users do
not understand the system.
Reexamine performance evaluation
Are performance standards and criteria realistic in
light of the change.

Copyright 2012 Pearson Education 20-20
Behavioral Aspects of Change
Reactions to change can be improved by
observing the following guidelines: (cont.)
Keep communication lines open
Managers and users should be fully informed about:
What changes are being made
Why
How it will benefit them
Who to contact with questions.
Test the systems integrity
It is important to minimize bad impressions.
Copyright 2012 Pearson Education 20-21
Behavioral Aspects of Change
Reactions to change can be improved by
observing the following guidelines: (cont.)
Keep the system simple, and humanize it
Avoid complex systems that cause radical
changes.
The new system is unlikely to be accepted if
employees feel the computer is controlling them or
has usurped their positions.
Control the users expectations
Dont oversell, and be realistic.
Ignoring the preceding steps can leave to
behavior issues that are difficult or impossible to
reverse.
Copyright 2012 Pearson Education 20-22
Systems Development Life Cycle
(SDLC)
Copyright 2012 Pearson Education 22-23
System Analysis
The project development team will conduct
the systems analysis in five steps:
Initial investigation
Systems survey
Feasibility study
Information needs and systems requirements
Systems analysis report

Copyright 2012 Pearson Education 20-24
Systems Development Life Cycle
(SDLC)
Copyright 2012 Pearson Education 22-25
Conceptual Systems Design
Developer creates a general framework for
implementing user requirements and solving the
problems identified in the analysis phase.
The three main steps are:
Evaluating design alternatives
Preparing design specifications
Preparing the conceptual systems design report
Copyright 2012 Pearson Education 22-26
Conceptual Systems Design
Copyright 2012 Pearson Education 22-27
Conceptual Systems Design
Evaluating design alternatives
There are many design decisions that must be
made. For example:
Should a document be hard-copy or sent by EDI?
Should the company use a large centralized
mainframe or some form of distributed processing?
What form should data entry take, e.g., keyboard,
optical character recognition, POS devices?
Copyright 2012 Pearson Education 22-28
Conceptual Systems Design
Also, there are many ways to approach the
systems development process
Packaged software
In-house development
End-user development
Outsourcing
The company also chooses between:
Modifying or enhancing existing software
Replacing existing software
Reengineering its business processes
Copyright 2012 Pearson Education 22-29
Systems Development Life Cycle
(SDLC)
Copyright 2012 Pearson Education 22-30
Physical Systems Design
During the physical systems design phase, the
company determines how the conceptual AIS
design is to be implemented.
The broad, user-oriented requirements of conceptual
design are translated into detailed specifications used
to code and test computer programs.
Phases include:
Designing output
Creating files and databases
Designing input
Writing computer programs
Developing procedures
Building in controls
Copyright 2012 Pearson Education 22-31
Physical Systems Design
Copyright 2012 Pearson Education 22-32
Systems Development Life Cycle
(SDLC)
Copyright 2012 Pearson Education 22-33
Systems Implementation and
Conversion
Systems implementation
Systems implementation is the process of installing
hardware and software and getting the AIS up
and running.
Phases include:
Developing a plan
Preparing the site
Installing and testing hardware and software
Selecting and training personnel
Completing documentation
Testing the system


Copyright 2012 Pearson Education 22-34
Systems Implementation and
Conversion
Copyright 2012 Pearson Education 22-35
Systems Development Life Cycle
(SDLC)
Copyright 2012 Pearson Education 22-36
Operations and Maintenance
The last step in the SDLC is to operate and
maintain the new system.
A post-implementation review should be
conducted to ensure the new AIS meets its
planned objectives.

Copyright 2012 Pearson Education 22-37
Operations and Maintenance
Copyright 2012 Pearson Education 22-38
Table 22-7 Factors to Investigate During Post-
Implementation Review
APPLICATION DEVELOPMENT
ERP SYSTEMS
INTRODUCTION
ISSUES
MODULES
APPLICATION
DEVELOPMENT
WHAT IS?
WHY?
ROLE
CONCEPT
ELEMENTS
FINANCIAL
MANAGEMENT
STUDENT
ADMINISTRATION
SALES &
DISTRIBUTION
LOGISTICS &
MATERIAL MANAGEMENT
PROCUREMENT
SUPPLY CHAIN
MANAGEMENT
HUMAN RESOURCE
MANAGEMENT
GAP ANALYSIS
& BPR
METHODOLOGY
E-COMMERCE
ERP OR
NOT TO ERP
FOLLOW SOFTWARE
OR CUSTOMIZE
INHOUSE OR
OUTSOURCE
BIG BANG
OR PHASED
SDLC
RAD
PROTOTYPING
CRITICAL
SUCCESS
FACTORS
DEFINITION
CONSTRUCTION
IMPLEMENTATION
APPLICATION
DEVELOPMENT
GAP ANALYSIS
& BPR
METHODOLOGY
SDLC
RAD
PROTOTYPING
CRITICAL
SUCCESS
FACTORS
DEFINITION
CONSTRUCTION
IMPLEMENTATION
FEASIBILITY
ANALYSIS
REQUIREMENT
DEFINITION
DESIGN
BUILDING
TESTING
INSTALLATION
OPERATIONS
MAINTENANCE
CHARACTERISTICS
QUALITY SYSTEM
MODELLING
IMPLEMENTATION
STRATEGIES
PARALLEL
PILOT
PHASE
CUTOVER
MODELLING TECHNIQUES
Context Diagram

Work Process Flow
Diagram

Data Flow Diagram
Characteristics of High Quality
Systems
Accurate
Auditable
Changeable
Efficient
Flexible

Reliable
Robust
Secure
User Friendly
Well Documented
NEW SYSTEM
OLD SYSTEM
NEW SYSTEM
OLD SYSTEM
NEW SYSTEM
OLD SYSTEM
NEW SYSTEM OLD SYSTEM
PARALLEL
PILOT
PHASE
CUTOVER
In simple words direct cutover approach is a direct approach
where old system is cut and over write by new system. The direct
cutover approach causes the changeover from the old system to
the new system to occur immediately when the new system
becomes operational.

This is a least expensive method among all four but involves high risk
of data loss. With the direct cutover method, company cannot
revert to the old system as a backup option.

But as there is lack of funds, this approach will be a possible option
because of its low cost application among all four approaches.
Direct Cutover
Parallel word is use when two things run simultaneously, so here two
operations run simultaneously.

The parallel operation changeover method requires that both the
old and the new information systems operate fully for a specified
period. When users, management, and the IT group are satisfied that
the new system operates correctly, the old system is terminate.

Parallel operation is having very low amount of risk as if the new
system does not work correctly, the company can use the old system
as a backup.

But it is the most costly changeover method. Data have to be input
in both systems. Users must work in both system and result in
increased workload and processing delays.
Parallel
The pilot operation changeover method involves implementing the
complete new system at a selected location of the company. The group
that uses the new system first is called the pilot site. The old system
continues to operate for the entire organization including the pilot site.
After the system proves successful at the pilot site, it is implemented in
the rest of the organization, usually using direct cutover method.

Pilot operation is combination of parallel operation and direct cutover
methods. Pilot site assure the working of new system and reduces the risk
of system failure. This is also less expensive than the parallel operation as
only at one section both system works for limited period. This is less
expensive and safer approach as its combination of both direct cutover
and parallel operation. It will save money of health centre and also keep
their data safe with smooth working.
Pilot
Phased operation works in different phases or stages.
Implementation of new system in modules or stages is phased
operation. This is also a combination of direct cutover and parallel
similar to pilot operation.

But in this approach the entire system is provided to some users
instead a part of system to all users.

In phase operation the risk of errors or failures is limited to the
implemented module only and also phased operation is less
expensive than the full parallel operation. But in some cases, phased
operation can cost more than a pilot approach where the system
involves a large number of separate phases.
Phased
SYSTEM DEVELOPMENT LIFE CYCLE
(SDLC)
SYSTEM ANALYSIS & DESIGN
Systems Analysis
the process of gathering and interpreting facts,
diagnosing problems and using that information to
recommend improvements to the system.
Systems design
is the process of planning a new business system or one
to replace or complement an existing system.
GROUP / INDIVIDUAL REQUIRED TO
ASSIST IN SYSTEM DEVELOPMENT?
STEERING COMMITTEE
WORKING COMMITTEE
PROJECT MANAGER
SYSTEM ANALYST
USER

SYSTEM ANALYST
Systems analysis only (information analyst)
The analysts' sole responsibility is conducting systems studies to
learn relevant facts about a business activity. The emphasis is on
gathering information and determining requirements. Analysts
are not responsible for systems design.
Systems Analysis and Design.
Analysts carry out complete systems studies but have added
responsibility for designing the new system.
Systems analysis, design and programming
(programmer analysis)
Analysts conduct the systems investigation, develop design
specifications and program software to implement the design.
HISTORY OF SDLC
1950s & 1960s
Applications which involve the basic data processing
processes of copying, retrieving, filing, sorting, checking,
analysing, calculating and communicating.
Typical examples would include:-
customer records
sales records
invoice production
payroll
PROBLEMS
difficulties in the communication of user needs to system developers
developments were frequently delivered late, over cost and did not
meet the users needs
projects were viewed as short term solutions rather than long-term,
well-planned implementation strategies for new applications.
changing the system was problematic and generally introduced new
problems into the system. Therefore it appeared to take an
inordinately long time to make relatively trivial changes.
documentation, if it existed, was usually out of date and
programmers rarely had time to update it.
documentation standards were resisted by programmers as they
were viewed as restricting creativity, increasing workloads and thus
increasing overall development time. (true, but the time spent
documenting a new system could pay dividends in reducing the
maintenance time for systems).
companies were reliant on a few experienced programmers, new
programmers found it difficult to take over because of the lack of
documentation, uniform practices and techniques.
SYSTEM DEVELOPMENT LIFECYCLE
Business Problem Definition
Feasibility Study
Systems Analysis
Systems Design
Physical Design
Testing
Implementation
Post Implementation Review
Maintenance
1
2
3
4
5
6
7
8
9
Provide other name for SDLC
System Development Life Cycle
Business Problem Definition. (Sometimes known as Requirements
Definition)
is the job of identifying and describing what is required of the new
information system.
i.e. it provides the terms of reference for the development process.
Techniques used in this stage include interviews and
questionnaires.

Feasibility Study
is an investigation of alternative solutions to the business problem
with a recommended solution chosen out of the alternatives.
The technique of cost benefit analysis is used in this stage.


Systems Analysis
is the detailed investigation and analysis of the requirements of a
system to fulfill a given business problem. The techniques used
in this stage include:
Dataflow diagrams
Entity modeling
Functional Analysis
Decision Trees
Decision Tables
Systems Design
is the process of constructing a design for a system to fulfill a
given business requirement.
The techniques used in this stage include:
Dataflow diagrams
Entity modeling
Functional Analysis
Decision Trees
Decision Tables
Structured English
Prototyping
Sometimes the systems design stage is broken down into:
a) Logical Design
is the production of a design far a system that ignores the physical
characteristics of the system. That is we look at what the system logically
does, not how it is physically done.
The logical design stage provides an opportunity to rationalise the
design and any duplication or unnecessary functions would be
removed.


b) Physical Design
is the production of a design for the physical system, that is we are
concerned with how the system will physically operate.
Coding
is the production of machine comprehensible instructions. Techniques
commonly used is structured programming techniques.
Coding may be performed in one of 4 types of languages:
a) First generation languages - machine code i.e. 1s and 0s
b) Second generation languages - simple instructions such as arithmetic
functions e.g. assembly language
c) 3rd generation languages - languages which use more english or more
scientific constructs. e.g. COBOL, PL1, FORTRAN
d) 4th generation languages - languages which use powerful commands to
perform multiple operations. e.g. FOCUS, POWERHOUSE


Testing
There are 6 types of testing that are performed.
a) Unit testing - testing of individual modules
b) Link testing - testing of communications between modules
c) System testing - testing of the system as a whole
d) Volume testing - testing that the system can cope with the
anticipated volumes of data.
e) User-acceptance testing - letting the users try the system.
f) regression testing - used during the maintenance phase to
ensure that changes do not corrupt other parts of the system.
Implementation
Actually implementing the live system. There are four methods of
implementing a system
a) direct changeover - scrap the old system and start using the
new system immediately.
b) parallel running - running both the old system and the new
system until the new system has proved itself.
c) pilot - implementing the whole system in just a part of the
organisation or part of the system in the whole organisation.
d) phased implementation - implementing the system in stages.
e.g. for an integrated ledger package we might implement
just the sales ledger first, then at a later date implement the
purchase ledger and then later still the nominal ledger.

Post-implementation Review
After 6 months or 12 months the implementation and
performance of the system is reviewed to determine how
successful the exercise has been.

Maintenance
Enhancements, error corrections and minor changes are made
to the system until we each the point where the system
becomes obsolete and then we start the whole systems
lifecycle again with a new business problem definition.

Copyright 2012 Pearson Education, Inc. publishing as Prentice Hall 20-62
These stages are frequently referred to as
conventional systems analysis
traditional systems analysis
the systems development lifecycle
the waterfall model

The term lifecycle indicates the iterative nature of the process as
when the system becomes obsolete the process begins again.
System analysis
Conceptual
Design
Physical Design
Implementatio
n & Conversion
Operation &
Maintenance
Waterfall Model
Potential Strengths of the
Traditional SDLC
This conventional systems analysis methodology has a
number of features to commend it.
It has been well tried and tested
deadline dates are more closely adhered to
unexpectedly high costs and lower than expected
benefits are avoided
progress can be reviewed at the end of each stage
Potential Weaknesses of the
Traditional SDLC
Although this approach represents a significant improvement over
earlier more ad hoc approaches there are, at least potentially, some
serious limitations to the SDLC.
Failure to meet the needs of
management
Unambitious systems design
Instability
Inflexibility
User dissatisfaction
Problems with documentation
Lack of control
Incomplete systems
Application backlog
Maintenance workload
Problems with the ideal
approach
TSDLC
Advantages
Highly structured
systematic process
Thorough requirement
definition
Clear milestones with
business management
sign-off
Disadvantages
Does not account for
evolving requirement
during project
Time consuming (and
costly) process
Top-down commitment
required
The Prototyping Life Cycle
Identify basic
system requirement
Develop initial
prototype
Use prototype and
note desired changes
Revise and
enhance prototype
Make necessary
modification / abandon
Install, operate
and maintain
Evaluate as
operational system
Prototyping
Advantages
Only basic system
requirements are needed
at the fronted of the
project.
Initial working system is
available for user testing.
Higher rate of user
acceptance

Disadvantages
Lacks of security and
control features.
Reduce testing processes
Incomplete
documentations
Rapid Application
Development
Requirements
planning
User design
Construction
Cutover
Rapid Application
Development
New System
Request
System Analysis
Maintenance
Enhancement
System
Modularizing
Module
Prioritizing
Module
Prototyping
Module Coding
Module
Integration
Technical
Approval
Module
Deployment
Module
Enhancement
Requirement
Study
Logical Design
Physical Design
Brainstorming, Briefing, Meeting, Workshop, Training, Training, Coordinating
CULTURE
Rapid Application Development
Advantages
Dramatic savings in
development time
Focuses on essential system
requirements
Ability to rapidly change
system design at user
request
Disadvantages
Quality may be sacrificed
for speed
Time-consuming
commitments for key user
personnel
Possible shortcuts on
internal standards and
module reusability
Percentage Breakdown on
SDLC projects
Development Activities
Definition Phase
Feasibility Analysis
Requirement Definition
Construction Phase
System Design
Coding and Initial testing
System Testing
Documentation and procedures
Implementation Phase
Installation planning, data cleanup and
conversion
5%
15%
15%
13%
12%
15%
25%
100%
GAP ANALYSIS
In information technology, gap analysis is the study of the
differences between two different information systems or
applications, often for the purpose of determining how to get
from one state to a new state.
A gap is sometimes spoken of as "the space between where
we are and where we want to be."
Gap analysis is undertaken as a means of bridging that space.
IDEF (Integrated Definition) - a group of methods used to
create a model of a system, analyze the model, create a
model of a desired version of the system, and to aid in the
transition from one to the other.
Time
P
e
r
f
o
r
m
a
n
c
e

R
e
q
u
i
r
e
m
e
n
t
s

Needs of the
organization
Performance
of the system
G
A
P

GAP ANALYSIS
Solution :

Replacement
Reengineering
BUSINESS PROCESSES
REENGINEERING
1-77
Business Processes Reengineering
What is business process reengineering (BPR)?
The ultimate goal of any business is to add value to its customers.
It is the thorough analysis and complete redesign of business
process and information systems (Value Chain & Value System)
to achieve performance improvements.
It is a process that challenges traditional organizational values
and cultures associated with underperformance.
Business Processes Reengineering
BPR reduces a company to its essential business
processes and focuses on why they are done rather than
on the details of how they are done.
It completely reshapes organizational work practices and
information flows to take advantage of technological
advancements.
Business Process
Reengineering
"the analysis and design of workflows and processes
within and between organizations" (Davenport & Short
1990).
Teng et al. (1994) define BPR as "the critical analysis and
radical redesign of existing business processes to achieve
breakthrough improvements in performance measures."
Business Process
Davenport & Short (1990) - "a set of logically related tasks
performed to achieve a defined business outcome."
A process is "a structured, measured set of activities designed to
produce a specified output for a particular customer or market. It
implies a strong emphasis on how work is done within an
organization" (Davenport 1993).
In their view processes have two important characteristics:
(i) They have customers (internal or external),
(ii) They cross organizational boundaries, i.e., they occur across or
between organizational subunits.
Business Process
One technique for identifying business processes in an
organization is the value chain method proposed by
Porter and Millar (1985).

Processes are generally identified in terms of beginning
and end points, interfaces, and organization units
involved, particularly the customer unit. High Impact
processes should have process owners. Examples of
processes include: developing a new product; ordering
goods from a supplier; creating a marketing plan;
processing and paying an insurance claim; etc.

Processes
Processes may be defined based on three dimensions
(Davenport & Short 1990):
Entities: Processes take place between organizational
entities. They could be Interorganizational (e.g. EDI, i.e.,
Electronic Data Interchange), Interfunctional or
Interpersonal
Objects: Processes result in manipulation of objects. These
objects could be Physical or Informational.
Activities: Processes could involve two types of activities:
Managerial (e.g. develop a budget) and Operational
(e.g. fill a customer order).
Principles of Reengineering
What are the seven principles of business processing
reengineering?
1 Organize around outcomes, not tasks.
2 Have output users perform the process.
3 Have those who produce information process it.
4 Centralize and disperse data.
5 Integrate parallel activities.
6 Empower workers, use built-in controls, and flatten the
organization chart.
7 Capture data once, at its source.

Principles of Reengineering
BPR methodology
Formation of BPR Steering Committee
Identify Process Owner
Formation of BPR project team
Inculcate BPR culture
BPR methodology
Davenport and Short (1990) prescribe a five-step approach to BPR:
Develop the Business Vision and Process Objectives:
BPR is driven by a business vision which implies specific business
objectives such as Cost Reduction, Time Reduction, Output Quality
improvement, QWL (Quality of Work Life)/Learning/Empowerment.
(cf: Shared Vision of Senge 1990, Ikujiro & Nonaka 1995).
Identify the Processes to be Redesigned:
Most firms use the High- Impact approach which focuses on the most
important processes or those that conflict most with the business
vision. Lesser number of firms use the Exhaustive approach that
attempts to identify all the processes within an organization and then
prioritize them in order of redesign urgency.
Understand and Measure the Existing Processes:
For avoiding the repeating of old mistakes and for providing a
baseline for future improvements.
Identify IT Levers:
Awareness of IT capabilities can and should influence
process design.
Design and Build a Prototype of the New Process:
The actual design should not be viewed as the end of
the BPR process. Rather, it should be viewed as a
prototype, with successive iterations. The metaphor of
prototype aligns the BPR approach with quick delivery of
results, and the involvement and satisfaction of
customers.

BPR methodology
Benefits of BPR
Better decision making and management control - accurate, on-
time and available and accessible information.
All processes will be delivered are of the highest quality and standard
Improved resource utilization and ability to grow without proportional
cost increase
Simulation capabilities to support proactive versus reactive
management
Reduced management expediting : more time to plan
Ability to react faster to changes in economy and government
policies
Improved business processes: simplified, reduced non-value added
activities, enterprise view incorporating cross functional focus,
information availability and aligned infrastructure information
technology, training, people, policies, structure etc.
Improved Quality of Life of the employees.
Why BPR projects fail?
70% of the BPR projects fail. Biggest obstacles that
reengineering faces are:
(i) Lack of sustained management commitment and
leadership;
(ii) Unrealistic scope and expectations; and
(iii) Resistance to Change.
Based on the BPR consultants' interviews, Bashein et al. (1994)
outline the positive preconditions for BPR success as:
Senior Management Commitment and Sponsorship;
Realistic Expectations;
Empowered and Collaborative Workers;
Strategic Context of Growth and Expansion;
Shared Vision;
Sound Management Practices;
Appropriate People Participating Full-Time; and
Sufficient Budget.
Positive Preconditions
They also identify negative preconditions related to BPR as:
The Wrong Sponsor;
A "Do It to Me" Attitude;
Cost-Cutting Focus; and,
Narrow Technical Focus.
The negative preconditions relating to the Organization include:
Unsound Financial Condition;
Too Many Projects Under Way;
Fear and Lack of Optimism; and,
Animosity Toward and By IS and Human Resource (HR)
Specialists.
Negative Preconditions
To turn around negative conditions, firms should:
Do Something Smaller First;
Conduct Personal Transformation (change of
mindset); and
Get IS and HR Involved (CIO initiated the change
and HR factors were given due emphasis).
Solutions
King (1994) views the primary reason of BPR failure as
overemphasis on the tactical aspects and the strategic
dimensions being compromised.
He notes that most failures of reengineering are attributable to
the process being viewed and applied at a tactical, rather
than strategic, levels.
He discusses that there are important strategic dimensions to
BPR, notably,
Developing and Prioritizing Objectives;
Defining the Process Structure and Assumptions;
Identifying Trade-Offs Between Processes;
Identifying New Product and Market Opportunities;
Coordinating the Reengineering Effort; and,
Developing a Human Resources Strategy.
He concludes that the ultimate success of BPR depends on the
people who do it and on how well they can be motivated to
be creative and to apply their detailed knowledge to the
redesign of business processes (cf: Davenport & Stoddard
1994, Markus et al. 1994).