romney_ch19.ppt

C

HAPTER 19

INTRODUCTION

• Questions to be addressed in this chapter include:

– How do organizations buy software, hardware, and

vendor services?

– How do information systems departments develop

custom software?

– How do end users develop, use and control

computer-based information systems?

– Why do organizations outsource their information

systems, and what are the benefits and risks of doing

so?

– How are prototypes used to develop an AIS, and what

are the advantages and disadvantages?

INTRODUCTION

• Companies can experience a number of

difficulties in developing an AIS, including:

– Projects are backlogged for years because of the high

demand for resources.

– The newly designed system doesn’t meet user needs.

– The process takes so long that by the time it’s

complete, it’s obsolete.

– Users can’t adequately specify their needs.

– Changes to the AIS are often difficult to make after

requirements have been written into the

INTRODUCTION

• We’ll be discussing how to obtain a new

information system by:

– Purchasing prewritten software;

– Developing software in-house; or

– Outsourcing.

• We’ll also discuss how to hasten or improve the

development process through:

– Business process reengineering

– Prototyping

INTRODUCTION

• We’ll be discussing how to obtain a new

information system by:

–

Purchasing prewritten software

– Developing software in-house; or

– Outsourcing.

• We’ll also discuss how to hasten or improve the

development process through:

– Business process reengineering

– Prototyping

PURCHASING PREWRITTEN SOFTWARE

• In the early days of computers,

companies were rarely able to buy

software to meet their needs.

PURCHASING PREWRITTEN SOFTWARE

•

Canned software

is sold on the open

market to a broad range of users with

similar requirements.

– Some companies sell hardware and software

together as a package.

• These systems are called

turnkey

systems

.

PURCHASING PREWRITTEN SOFTWARE

– A major problem with canned software:

• It often does not meet all of a company’s

information needs.

• Can be overcome by modifying the canned

software.

– Usually best done by the vendor.

PURCHASING PREWRITTEN SOFTWARE

• Companies can also acquire software through

application service providers

(ASPs).

– ASPs host Web-based software and deliver it to

clients over the Internet.

– Companies don’t have to buy, install, or maintain

canned software; they simply “rent” it.

PURCHASING PREWRITTEN SOFTWARE

– Advantages of ASPs:

• Reduction of software costs and administrative

overhead.

• Automated software upgrades.

• Scalability as the business grows.

• Global access to information.

• Access to skilled IT personnel.

PURCHASING PREWRITTEN SOFTWARE

•

Purchasing software and the SDLC:

– Companies that buy rather than develop

software still follow the SDLC process,

including:

•

Systems analysis



They conduct an initial investigation,

PURCHASING PREWRITTEN SOFTWARE

•

Purchasing software and the SDLC:

– Companies that buy rather than develop

software still follow the SDLC process,

including:

• Systems analysis

•

Conceptual design

•

An important aspect is determining

whether software that meets AIS

requirements is already available.

PURCHASING PREWRITTEN SOFTWARE

•

Purchasing software and the SDLC:

– Companies that buy rather than develop

software still follow the SDLC process,

including:

• Systems analysis

• Conceptual design

•

Physical design

•

If software is purchased,

program design and coding

can be omitted.

•

But software modifications

may be needed.

PURCHASING PREWRITTEN SOFTWARE

•

Purchasing software and the SDLC:

– Companies that buy rather than develop

software still follow the SDLC process,

including:

• Systems analysis

• Conceptual design

• Physical design

•

Implementation and conversion

•

These activities must still take place,

including:

–

Selecting and training personnel

–

Installing and testing hardware and software

–

Documenting procedures

–

Converting from old to new AIS

•

However, the software modules do not

have to be developed and tested.

PURCHASING PREWRITTEN SOFTWARE

•

Purchasing software and the SDLC:

– Companies that buy rather than develop

software still follow the SDLC process,

including:

• Systems analysis

• Conceptual design

• Physical design

• Implementation and conversion

•

Operation and maintenance

•

The AIS is operated like any other software.

PURCHASING PREWRITTEN SOFTWARE

•

Selecting a vendor

– Deciding whether to make or buy software

can be made independently of the decision to

acquire hardware, service, maintenance, and

other AIS resources.

– And the preceding resources can be bought

independently of the software.

PURCHASING PREWRITTEN SOFTWARE

• Vendors can be found by:

– Looking in phone book

– Obtaining referrals

– Scanning computer or trade magazines

– Attending conferences

– Using search organizations

PURCHASING PREWRITTEN SOFTWARE

•

Acquiring hardware and software

– Once AIS requirements have been defined,

the organization can buy software and

hardware.

– Companies needing only a PC and some

PURCHASING PREWRITTEN SOFTWARE

• When buying large or complex systems, a

request for proposal

(RFP) should be

prepared:

– The RFP is an invitation to bidders to propose

a system by a specific date.

– Each proposal is evaluated.

PURCHASING PREWRITTEN SOFTWARE

• The formal approach is important for

several reasons:

PURCHASING PREWRITTEN SOFTWARE

• The formal approach is important for

several reasons:

– Saves time

–

Simplifies the decision-making process

PURCHASING PREWRITTEN SOFTWARE

• The formal approach is important for

several reasons:

– Saves time

– Simplifies the decision-making process

PURCHASING PREWRITTEN SOFTWARE

• The formal approach is important for

several reasons:

– Saves time

– Simplifies the decision-making process

– Reduces errors

–

Avoids potential for disagreement

PURCHASING PREWRITTEN SOFTWARE

• When an RFP is solicited based on exact

hardware and software specifications:

– Total costs are usually lower.

– Less time is required for vendor preparation

and company evaluation.

PURCHASING PREWRITTEN SOFTWARE

• A generalized RFP contains a problem

definition and requests a system that

meets specific performance objectives and

requirements.

– Leaves technical issues to the vendor.

– However, makes it more difficult to evaluate

proposals.

PURCHASING PREWRITTEN SOFTWARE

• Usually, the more information a company

provides to the vendors, the better their chances

of receiving a system that meets their

requirements.

– Detailed specifications should include:

• Required applications

• Inputs and outputs

• Files and databases

• Frequency and methods of file updating and inquiry

• Unique characteristics or requirements

PURCHASING PREWRITTEN SOFTWARE

•

Evaluating proposals and selecting a system

– Eliminate any proposals that:

• Are missing important information.

• Fail to meet minimum requirements.

• Are ambiguous.

– Those that pass the preliminary screening should be

compared with the proposed AIS requirements to

determine:

• If they meet all

mandatory

requirements.

• How many

desirable

requirements they meet.

PURCHASING PREWRITTEN SOFTWARE

•

In reviewing the proposals, you need to

evaluate:

PURCHASING PREWRITTEN SOFTWARE

•

In reviewing the proposals, you need to

evaluate:

–

Hardware

PURCHASING PREWRITTEN SOFTWARE

•

Criteria to evaluate hardware include:

•

Cost

•

Ability to run required

software

•

Processing speed and

capabilities

•

Secondary storage

capability

•

Input and output speeds

•

Communication

capabilities

•

Expandability

•

Recency of technology

•

Availability

•

Compatibility with existing

hardware, software, and

peripherals

•

Performance compared to

competitors

•

Cost and availability of

support and maintenance

•

Warrantees and guarantees

•

Financing arrangements

PURCHASING PREWRITTEN SOFTWARE

•

In reviewing the proposals, you need to

evaluate:

– Hardware

–

Software

PURCHASING PREWRITTEN SOFTWARE

•

Criteria to evaluate software include:

•

Conformity with

specifications

•

Need for modification

•

Performance (speed,

accuracy, reliability)

•

Use by other companies

•

Satisfaction of other users

•

Documentation

•

Compatibility with existing

software

•

User-friendliness

•

Ability to be demonstrated

and test-driven

•

Warranties

•

Flexibility and

maintainability

•

Capability for online inquiry

of files and records

PURCHASING PREWRITTEN SOFTWARE

•

In reviewing the proposals, you need to

evaluate:

– Hardware

– Software

PURCHASING PREWRITTEN SOFTWARE

•

Criteria to evaluate vendors include:

•

Size

•

Financial stability and

security

•

Experience

•

Quality of support and

warranties

•

Regularity of updates

•

Ability to provide financing

•

Willingness to sign

contract

•

Willingness to provide

references

•

Reputation for reliability

and dependability

•

Hardware and software

support and maintenance

•

Implementation and

installation support

•

Quality and

responsiveness of

personnel

•

Willingness to provide

training

PURCHASING PREWRITTEN SOFTWARE

• Approaches to comparing system

performance:

– Benchmark problem

– Point scoring

PURCHASING PREWRITTEN SOFTWARE

• Approaches to comparing system

performance:

–

Benchmark problem

– Point scoring

PURCHASING PREWRITTEN SOFTWARE

• Benchmark problem

– The new AIS performs a data processing task

with input, processing, and output jobs typical

of what would be required of the new system.

– Processing times are calculated and

compared.

PURCHASING PREWRITTEN SOFTWARE

• Approaches to comparing system

performance:

– Benchmark problem

–

Point scoring

PURCHASING PREWRITTEN SOFTWARE

• Point scoring:

– A weight is assigned to each criterion used to

evaluate the system, based on the relative

importance of that criterion.

– Each criterion is rated for each product.

– Each rating is multiplied times the weight

assigned to the criterion to develop a

weighted score.

PURCHASING PREWRITTEN SOFTWARE

• Example:

– Zorba Co. is evaluating systems offered by three

different vendors: Able Co., Baker Co., and Cook Co.

– Zorba has determined three criteria that they will use

to evaluate the different systems: cost, speed, and

vendor reliability.

– They have provided the following weights to each

criteria, with vendor reliability being the most critical:

• Vendor reliability—9

• Cost—6

PURCHASING PREWRITTEN SOFTWARE



Zorba examined the packages offered by the three

vendors and rated them based on these three criteria.

Ratings were from 1–5 with 5 being the highest score.

Criteria

Able Co.

Baker Co.

Cook Co.

Vendor reliability (9)

2

5

4

Cost (6)

5

3

4

PURCHASING PREWRITTEN SOFTWARE



The weighted scores are then computed by multiplying

the rating given to each vendor on each criterion times

the weight assigned to that criterion.

Criteria

Able Co.

Baker Co.

Cook Co.

Vendor reliability (9)

2

5

4

Cost (6)

5

3

4

Speed (4)

3

4

2

WEIGHTED SCORES

Criteria

Able Co.

Baker Co.

Cook Co.

Vendor reliability (9)

18

45

36

Cost (6)

30

18

24

PURCHASING PREWRITTEN SOFTWARE

• The weighted scores for each company are

summed:

– Able = 60 points

– Baker = 79 points

– Cook = 68 points

• Based on the preceding scores, the bid would

probably be awarded to Baker Co.

WEIGHTED SCORES

Criteria

Able Co.

Baker Co.

Cook Co.

Vendor reliability (9)

18

45

36

Cost (6)

30

18

24

PURCHASING PREWRITTEN SOFTWARE

• The preceding example is a simplification.

In a real-life scenario, several factors

would be different:

– There would probably be many more criteria

being considered.

PURCHASING PREWRITTEN SOFTWARE

• Approaches to comparing system

performance:

– Benchmark problem

– Point scoring

PURCHASING PREWRITTEN SOFTWARE

• Requirements costing:

– Estimates cost of purchasing or developing

features that are

not

included in a particular

AIS.

– The total AIS cost is calculated by adding the

acquisition cost to the purchasing and

development costs.

PURCHASING PREWRITTEN SOFTWARE

• To verify that the AIS that looks best on

paper is actually the best in practice:

– Test-drive the software.

– Contact other users for references.

– Evaluate vendor personnel.

INTRODUCTION

• We’ll be discussing how to obtain a new

information system by:

– Purchasing prewritten software

–

Developing software in-house

– Outsourcing

• We’ll also discuss how to hasten or improve the

development process through:

– Business process reengineering

– Prototyping

DEVELOPING SOFTWARE IN-HOUSE

• Despite the availability of good canned

software, many organizations develop

their own because:

– Their requirements are unique; or

– Their size and complexity necessitates a

custom package.

• Developing custom software is difficult and

error prone and consumes much time and

resources.

•

The GAO reports that

31% of federal

government IT projects

are poorly planned or do

not meet intended

DEVELOPING SOFTWARE IN-HOUSE

• The most difficult hurdles:

– Lack of time.

– Complexity of desired system.

– Poor requirements and systems planning.

– Inadequate communication and cooperation

between departments and users.

– Lack of qualified staff.

DEVELOPING SOFTWARE IN-HOUSE

• After end users define their requirements,

the analysts:

– Work with the end users to determine the

format of paper and screen outputs.

– Identify:

• Data required for each input.

• Data to be retained in files.

DEVELOPING SOFTWARE IN-HOUSE

• The process requires much discipline and

management supervision.

• Accountants may help as project

DEVELOPING SOFTWARE IN-HOUSE

• Custom software is usually developed and

written in-house.

– Alternately, organizations may engage an

outside company to develop a package or

assemble one from their inventory of modules.

– These modules are adapted, combined, and

DEVELOPING SOFTWARE IN-HOUSE

• When contracting with an outside organization,

maintain control over development and observe

the following guidelines:

–

Carefully select a developer

•

Look for:

–

Experience in the industry

–

A good understanding of:

•

Business in general

DEVELOPING SOFTWARE IN-HOUSE

• When contracting with an outside organization,

maintain control over development and observe

the following guidelines:

– Carefully select a developer

DEVELOPING SOFTWARE IN-HOUSE

• When contracting with an outside organization,

maintain control over development and observe

the following guidelines:

– Carefully select a developer

– Sign a contract to clearly define responsibilities

–

Plan and monitor each step

•

Design all aspects in detail.

DEVELOPING SOFTWARE IN-HOUSE

• When contracting with an outside organization,

maintain control over development and observe

the following guidelines:

– Carefully select a developer

– Sign a contract to clearly define responsibilities

– Plan and monitor each step

DEVELOPING SOFTWARE IN-HOUSE

• When contracting with an outside organization,

maintain control over development and observe

the following guidelines:

– Carefully select a developer

– Sign a contract to clearly define responsibilities

– Plan and monitor each step

– Maintain effective and frequent communication

–

_{Control all costs}

DEVELOPING SOFTWARE IN-HOUSE

• Information systems consultants suggest that

clients develop their own software only if it

provides a significant competitive advantage.

– Payroll and A/R systems are not good candidates for

in-house development.

– There might be significant benefits to developing

sophisticated product manufacturing software.

• If there is no significant competitive advantage,

buy software from an outside supplier.

– Trend appears to be in that direction.

DEVELOPING SOFTWARE IN-HOUSE

• Another approach to developing software

in-house is to take the lion’s share of the

effort out of the hands of the IS

DEVELOPING SOFTWARE IN-HOUSE

• End-user developed software

– End-user computing (EUC) is the hands-on

development, use, and control of computer-based

information systems by users.

– With EUC, individuals use IT to meet their own IS

needs rather than rely on systems professionals.

– Why?

• The demand for information systems has grown

exponentially since the introduction of the computer.

DEVELOPING SOFTWARE IN-HOUSE

• Technology has evolved to automate

much of the system development process.

Factors contributing to EUC are:

– Increased computer literacy.

– Easier-to-use programming languages.

– Inexpensive PCs.

DEVELOPING SOFTWARE IN-HOUSE

• Consequently, users have begun to

develop their own systems to:

– Create and store data.

– Access and download company data.

– Share data and computer resources in

DEVELOPING SOFTWARE IN-HOUSE

• As end users began to meet their initial

needs, two things happened:

– Users realized computers could be used to

meet more and more information needs.

– Increased access to data created many new

uses and needs for information.

DEVELOPING SOFTWARE IN-HOUSE

• EUC has altered the role of the IS staff:

– They continue to develop and maintain transaction

processing systems and company-wide databases

from which end users draw information.

– They provide users with technical advice and

operational support and make as much information

available to them as possible.

– While the support work has increased for the IS staff,

this work is counter-balanced by a decreased demand

for traditional IS services.

– EUC may make up 75–95% of all IS processing by

2010.

DEVELOPING SOFTWARE IN-HOUSE

•

Appropriate end-user development and

use

– End user development (EUD) happens when

information users (e.g., managers,

accountants, auditors) develop their own

applications using computer specialists as

advisors.

• Inappropriate for complex systems.

• Not used for large-scale processing, such as

DEVELOPING SOFTWARE IN-HOUSE

– End user development may be most

appropriate for:

• Retrieving info from company databases to

produce simple reports or answer single queries.

• Performing “what if,” sensitivity, or statistical

analyses.

• Developing applications that use prewritten

software (e.g., spreadsheet or database software).

• Preparing schedules (such as aging of accounts)

DEVELOPING SOFTWARE IN-HOUSE

• Benefits of end-user computing:

–

User creation, control, and implementation

•

Users control the development process, decide

what info needs are important, and if a system

should be developed.

DEVELOPING SOFTWARE IN-HOUSE

• Benefits of end-user computing:

– User creation, control, and implementation

–

Systems that meet user needs

•

Because users discover flaws that systems people

would not catch.

DEVELOPING SOFTWARE IN-HOUSE

• Benefits of end-user computing:

– User creation, control, and implementation

– Systems that meet user needs

–

Timeliness

DEVELOPING SOFTWARE IN-HOUSE

• Benefits of end-user computing:

– User creation, control, and implementation

– Systems that meet user needs

– Timeliness

–

_{Freeing up systems resources}

•

The IS department can exert time and resources

on other information and maintenance activities.

DEVELOPING SOFTWARE IN-HOUSE

• Benefits of end-user computing:

– User creation, control, and implementation

– Systems that meet user needs

– Timeliness

– Freeing up systems resources

–

Versatility and ease of use

•

Most EUC software is easy to understand and use.

•

With a laptop, the work can be done at home or

DEVELOPING SOFTWARE IN-HOUSE

• Risks of end-user computing:

–

Logic and development errors

•

End users are inexperienced in systems development.

•

Consequently, they are more likely to make errors and less

likely to recognize them.

•

They may:

–

Solve wrong problem

–

Poorly define systems requirements

–

Apply inappropriate analytical methods

–

Use wrong software

–

Use incomplete or outdated information

•

Errors are often caused by faulty logic, formulas, or software

DEVELOPING SOFTWARE IN-HOUSE

• Risks of end-user computing:

– Logic and development errors

–

Inadequately tested applications

•

Users probably won’t test rigorously.

•

They tend not to recognize the need for testing, the difficulty,

or the time involved.

DEVELOPING SOFTWARE IN-HOUSE

• Risks of end-user computing:

– Logic and development errors

– Inadequately tested applications

–

Inefficient systems

DEVELOPING SOFTWARE IN-HOUSE

• Risks of end-user computing:

– Logic and development errors

– Inadequately tested applications

– Inefficient systems

–

_{Poorly controlled and documented}

systems

•

Many end users don’t implement controls to

protect their system.

DEVELOPING SOFTWARE IN-HOUSE

• Risks of end-user computing:

– Logic and development errors

– Inadequately tested applications

– Inefficient systems

– Poorly controlled and documented systems

–

System incompatibilities

•

Some companies add end-user equipment without

considering the technological implications.

DEVELOPING SOFTWARE IN-HOUSE

• Risks of end-user computing:

– Logic and development errors

– Inadequately tested applications

– Inefficient systems

– Poorly controlled and documented systems

– System incompatibilities

–

Duplication of systems and data and

wasted resources

•

If end users aren’t aware that others have similar

information needs, duplication occurs.

DEVELOPING SOFTWARE IN-HOUSE

• Risks of end-user computing:

– Logic and development errors

– Inadequately tested applications

– Inefficient systems

– Poorly controlled and documented systems

– System incompatibilities

– Duplication of systems and data and wasted

resources

–

Increased costs

•

Buying PCs for multitudes of workers is costly.

•

Regular updating of hardware and software is

also expensive.

•

EUC also increases costs if it diverts users from

their primary jobs.

DEVELOPING SOFTWARE IN-HOUSE

• To achieve proper balance between

maximizing the benefits of end user

systems and minimizing the risks:

– Systems analysts can act as advisers and

require user-created systems to be reviewed

and documented prior to use.

– Users can be trained in systems analysis so

they can identify and adequately meet their

needs, as well as reviewing the work of

DEVELOPING SOFTWARE IN-HOUSE

• Organizations use several approaches to

managing and controlling EUC.

– If you give the systems department control over EUC:

• Growth of EUC is discouraged.

• The organization is denied most of its benefits.

• It’s not in the company’s best long-term interests.

– However, if there are no controls over the tools that

can be purchased or how they can be used:

• Chaos can result

DEVELOPING SOFTWARE IN-HOUSE

• Best to provide enough guidance and

support to adequately control the system

but allow users flexibility.

• A help desk can encourage, support,

coordinate, and control end-user activities.

– One level of help desk employees might be

trained with scripted answers.

DEVELOPING SOFTWARE IN-HOUSE

• Help desk duties include:

– Providing hotline assistance to solve problems.

– Serving as a clearinghouse for information, coordination,

and assistance.

– Training end users how to use specific hardware and

software, and providing technical maintenance and

support.

– Evaluating new end-user hardware and software products.

– Assisting with application development.

– Developing and implementing standards for:

• Hardware and software purchases to ensure compatibility.

• Documentation and application testing.

INTRODUCTION

• We’ll be discussing how to obtain a new

information system by:

– Purchasing prewritten software

– Developing software in-house

–

Outsourcing

• We’ll also discuss how to hasten or improve the

development process through:

– Business process reengineering

– Prototyping

OUTSOURCE THE SYSTEM

•

Outsourcing

is hiring an outside company

to handle all or part of an organization’s

data processing activities.

– In a mainframe outsourcing agreement:

• The outsourcers buy the client’s computers and

hire all or most of the client’s employees.

• Then operate and manage the entire system on

the client’s site or migrate it to the outsourcer’s

computers.

• Many of these contracts have terms of 10 or more

years and cost from hundreds of thousands to

OUTSOURCE THE SYSTEM

– In a client/server or a PC outsourcing

agreement the organization outsources:

• A particular service (e.g., help desk services);

• A segment of its business;

OUTSOURCE THE SYSTEM

• Examples of outsourced activities:

– Installation

– Training

– Maintenance

– Help desk

OUTSOURCE THE SYSTEM

•

The growth in outsourcing applications

– Outsourcing was initially used for

standardized applications such as payroll,

accounting, and purchasing.

OUTSOURCE THE SYSTEM

• Kodak and Xerox were very successful at

cutting capital expenditures and other

costs, which motivated others to outsource

their systems.

• Now many Fortune 500 companies

outsource some or all of there IS.

•

Outsourcing business

processes is the fastest

growing IT trend—large

and small companies are

jumping on the band

OUTSOURCE THE SYSTEM

• Most companies that outsource use

several different companies rather than a

single source in order to:

– Increase flexibility

– Foster competition

– Reduce costs

• Most companies do not outsource:

– Strategic management of their IT environment

– Business process management

OUTSOURCE THE SYSTEM

• Benefits of outsourcing:

–

Provides a business solution

OUTSOURCE THE SYSTEM

• Benefits of outsourcing:

– Provides a business solution

–

Asset utilization

•

Companies can improve cash position and reduce

expenses by selling their computers to an

OUTSOURCE THE SYSTEM

• Benefits of outsourcing:

– Provides a business solution

– Asset utilization

–

Access to greater experience and more

advanced technology

OUTSOURCE THE SYSTEM

• Benefits of outsourcing:

– Provides a business solution

– Asset utilization

– Access to greater experience and more

advanced technology

–

Lower costs

•

Outsourcing can reduce IS costs by 15–

30% because of economies of scale and

lower costs of outsourcers.

OUTSOURCE THE SYSTEM

• Benefits of outsourcing:

– Provides a business solution

– Asset utilization

– Access to greater experience and more

advanced technology

– Lower costs

–

_{Improved development time}

•

Experienced specialists can often develop and

implement a system faster and more efficiently.

OUTSOURCE THE SYSTEM

• Benefits of outsourcing:

– Provides a business solution

– Asset utilization

– Access to greater experience and more

advanced technology

– Lower costs

– Improved development time

–

_{Elimination of peaks-and-valleys usage}

OUTSOURCE THE SYSTEM

• Benefits of outsourcing:

– Provides a business solution

– Asset utilization

– Access to greater experience and more

advanced technology

– Lower costs

– Improved development time

– Elimination of peaks-and-valleys usage

–

Facilitation of downsizing

•

Companies with in-house systems that downsize

are often left with an unnecessarily large AIS

OUTSOURCE THE SYSTEM

• Risks of outsourcing

– Many outsourcing contracts fail to meet

expectations for reasons including:

–

_{Inflexibility}

•

Many outsourcing contracts are for 10 years.

OUTSOURCE THE SYSTEM

• Risks of outsourcing:

– Inflexibility

–

Loss of control

•

The company may lose control of its system and data.

OUTSOURCE THE SYSTEM

• Risks of outsourcing:

– Inflexibility

– Loss of control

–

Reduced competitive advantage

•

Companies can lose a fundamental understanding of

their IS needs and how the system can provide it with

competitive advantages.

•

Outsourcers are not as motivated to meet the client’s

competitive challenges.

OUTSOURCE THE SYSTEM

• Risks of outsourcing:

– Inflexibility

– Loss of control

– Reduced competitive advantage

–

_{Locked in system}

OUTSOURCE THE SYSTEM

• Risks of outsourcing:

– Inflexibility

– Loss of control

– Reduced competitive advantage

– Locked in system

–

Unfulfilled goals

OUTSOURCE THE SYSTEM

• Risks of outsourcing:

– Inflexibility

– Loss of control

– Reduced competitive advantage

– Locked in system

– Unfulfilled goals

–

Poor service

•

Some companies complain of poor service from

their outsourcers, particularly with respect to:

–

Slow or no responsiveness to changing business

conditions.

OUTSOURCE THE SYSTEM

• Risks of outsourcing:

– Inflexibility

– Loss of control

– Reduced competitive advantage

– Locked in system

– Unfulfilled goals

– Poor service

–

Increased risk

•

Increased risks include loss of market position,

loss of human capital, and reputation

INTRODUCTION

• We’ll be discussing how to obtain a new

information system by:

– Purchasing prewritten software

– Developing software in-house

– Outsourcing

• We’ll also discuss how to hasten or improve the

development process through:

–

Business process reengineering

– Prototyping

BUSINESS PROCESS REENGINEERING

• Business process reengineering (BPR) is

the analysis and redesign of business

processes and information systems to

achieve significant performance

improvements.

– Reduces a company to its essential business

processes.

– Reshapes organizational work practices and

information flows to take advantage of

BUSINESS PROCESS REENGINEERING

• BPR:

– Simplifies the system.

– Makes it more effective.

– Improves a company’s quality and service.

BUSINESS PROCESS REENGINEERING

• Michael Hammer has set forth several principles

that help organizations successfully reengineer

business processes:

-

Organize around outcomes, not tasks.

•

DO AWAY WITH: Assigning different parts of a business

process to different people, with the resulting handoffs,

delays, and errors.

•

INSTEAD: Each person’s job is designed around an

BUSINESS PROCESS REENGINEERING

• Michael Hammer has set forth several principles

that help organizations successfully reengineer

business processes:

- Organize around outcomes, not tasks.

-

Require those who use the output to perform the

BUSINESS PROCESS REENGINEERING



Michael Hammer has set forth several principles

that help organizations successfully reengineer

business processes:

- Organize around outcomes, not tasks.

- Require those who use the output to perform the

process.

-

Require those who produce information to

BUSINESS PROCESS REENGINEERING

• Michael Hammer has set forth several principles

that help organizations successfully reengineer

business processes:

- Organize around outcomes, not tasks.

- Require those who use the output to perform the

process.

- Require those who produce information to process it.

-

Centralize AND disperse data.

•

You centralize operations to achieve economies

of scale and eliminate redundancy.

•

You decentralize operations to be more

responsive to customers and provide better

service

•

With technology, you don’t have to choose.

–

Corporate-wide databases centralize data.

BUSINESS PROCESS REENGINEERING

• Michael Hammer has set forth several principles

that help organizations successfully reengineer

business processes:

- Organize around outcomes, not tasks.

- Require those who use the output to perform the

process.

- Require those who produce information to process it.

- Centralize AND disperse data.

-

Integrate parallel activities.



Example: In developing a new product, include on the

BUSINESS PROCESS REENGINEERING

• Michael Hammer has set forth several principles

that help organizations successfully reengineer

business processes:

- Organize around outcomes, not tasks.

- Require those who use the output to perform the

process.

- Require those who produce information to process it.

- Centralize AND disperse data.

- Integrate parallel activities.

-

Empower workers, use built-in controls, and

flatten the organization chart.

•

In a traditional system, there is a layer of worker

bees and several layers of manager bees,

auditor bees, and controller bees.

•

In a reengineered system, the people who do the

work have decision-making responsibility.

–

Information technology enables their decision

accuracy.

BUSINESS PROCESS REENGINEERING

• Michael Hammer has set forth several principles

that help organizations successfully reengineer

business processes:

- Organize around outcomes, not tasks.

- Require those who use the output to perform the

process.

- Require those who produce information to process it.

- Centralize AND disperse data.

- Integrate parallel activities.

- Empower workers, use built-in controls, and flatten

the organization chart.

-

Capture data once—at its source.

BUSINESS PROCESS REENGINEERING

• Underlying reengineering is the efficient

and effective use of the latest information

technology, e.g.:

– Radio- and satellite-based communications.

– Powerful handheld computers.

– Image processing that lets multiple users

handle a document simultaneously.

BUSINESS PROCESS REENGINEERING

•

Challenges faced by reengineering efforts:

– Many BPR efforts fail or fall short of their objectives. A

company must overcome the following obstacles:

•

Tradition

•

“We’ve always done it this way!”

BUSINESS PROCESS REENGINEERING

•

Challenges Faced by Reengineering Efforts:

– Many BPR efforts fail or fall short of their objectives. A

company must overcome the following obstacles:

• Tradition

•

Resistance

•

Change is always met with resistance.

BUSINESS PROCESS REENGINEERING

•

Challenges Faced by Reengineering Efforts:

– Many BPR efforts fail or fall short of their objectives. A

company must overcome the following obstacles:

• Tradition

• Resistance

•

Time and cost requirements

BUSINESS PROCESS REENGINEERING

•

Challenges faced by reengineering efforts:

– Many BPR efforts fail or fall short of their objectives. A

company must overcome the following obstacles:

• Tradition

• Resistance

• Time and cost requirements

•

Lack of management support

•

Managers are nervous about the “big hype—few

results” syndrome.

BUSINESS PROCESS REENGINEERING

•

Challenges Faced by Reengineering Efforts:

– Many BPR efforts fail or fall short of their objectives. A

company must overcome the following obstacles:

• Tradition

• Resistance

• Time and cost requirements

• Lack of management support

•

Skepticism

BUSINESS PROCESS REENGINEERING

•

Challenges Faced by Reengineering Efforts:

– Many BPR efforts fail or fall short of their objectives. A

company must overcome the following obstacles:

• Tradition

• Resistance

• Time and cost requirements

• Lack of management support

• Skepticism

•

Retraining

BUSINESS PROCESS REENGINEERING

•

Challenges faced by reengineering efforts:

– Many BPR efforts fail or fall short of their objectives. A

company must overcome the following obstacles:

• Tradition

• Resistance

• Time and cost requirements

• Lack of management support

• Skepticism

• Retraining

•

Controls

INTRODUCTION

• We’ll be discussing how to obtain a new

information system by:

– Purchasing prewritten software

– Developing software in-house

– Outsourcing

• We’ll also discuss how to hasten or improve the

development process through:

– Business process reengineering

–

Prototyping

PROTOTYPING

• Prototyping is an approach to systems design in

which a simplified working model of a system is

developed.

– The prototype (first draft) is built quickly at low cost

and provided to users for experimentation.

– Playing with the prototype allows users to determine

what they do and do not like.

– Developers modify the system in response to user

comments and re-present it to them.

PROTOTYPING

• The basic premise is that it’s easier for

people to express what they like or dislike

than to imagine what they want in a

system.

– In another words, it helps to have a straw man

to aim at.

– Even a simple system that is not fully

PROTOTYPING

• Developers who use prototyping still go through

the systems development life cycle.

• But prototyping allows them to expedite some

analysis and design.

• For example, prototyping captures user needs

and helps developers and users make many

conceptual and physical design decisions.

• Current practice leans heavily toward

PROTOTYPING

• Four steps are involved in developing a

prototype:

– STEP ONE: Identify basic requirements

– STEP TWO: Develop an initial prototype

– STEP THREE: Repeated iterations

PROTOTYPING

• Four steps are involved in developing a

prototype:

–

STEP ONE: Identify basic requirements

– STEP TWO: Develop an initial prototype

– STEP THREE: Repeated iterations

PROTOTYPING

• The first step is to identify basic

requirements by meeting with users to

agree on the size and scope of the system

and decide what it should include and

exclude.

– Developer and users also determine:

• Decision-making and transaction processing

outputs.

• Inputs and data needed to produce those outputs.

– The emphasis is on what outputs should be

PROTOTYPING

– The developer must ensure:

• User expectations are realistic.

• Their basic information requirements are met.

– The designer uses the information

PROTOTYPING

• Four steps are involved in developing a

prototype:

– STEP ONE: Identify basic requirements

–

STEP TWO: Develop an initial prototype

PROTOTYPING

• The second step involves developing an

initial prototype that meets the agreed-on

requirements.

– Emphasize speed and low cost rather than

efficiency of operation.

PROTOTYPING

• Because of time constraints, some

aspects are sacrificed. For example, at

this point, you ignore:

– Non-essential functions

– System controls

– Exception handling

– Validation of input data

– Processing speed

PROTOTYPING

• Users must see and use tentative versions of:

– Data entry display screens

– Menus

– Input prompts

– Source documents

• They must also:

– Respond to prompts

– Query the system

PROTOTYPING

• When the prototype is finished, the

developer returns to the users and

demonstrates the system.

• Users are instructed to:

– Experiment.

PROTOTYPING

• Four steps are involved in developing a

prototype:

– STEP ONE: Identify basic requirements

– STEP TWO: Develop an initial prototype

–

_{STEP THREE: Repeated iterations}

PROTOTYPING

• The third step involves repeated iterations

of:

– Users identifying changes.

– Developers making the changes.

– The system being turned back to users for

next round.

PROTOTYPING

• Four steps are involved in developing a

prototype:

– STEP ONE: Identify basic requirements

– STEP TWO: Develop an initial prototype

– STEP THREE: Repeated iterations

PROTOTYPING

• The final step involves using the system

approved by the users.

PROTOTYPING

• Half of the prototypes are turned into fully

functional systems referred to as

operational prototypes

.

– To make them operational, the developer

must:

• Add needed controls.

• Improve operational efficiency.

• Provide backup and recovery.

PROTOTYPING

• Changes may be necessary to allow the

program to:

– Accept real input.

– Access real data files.

– Process data.

– Make necessary computations and

calculations.

PROTOTYPING

• When it’s not practical to modify the

prototype to make a fully functional

system,

non-operational

or

throwaway

prototypes

can be used in several ways:

– They may be discarded, and the systems

requirements identified in the process of

building them can be used to develop a new

system.

PROTOTYPING

– Alternately, they may be used as the initial

prototype for an expanded system designed

to meet needs of many users.

– As a final alternative, if users and developers

decide the system is unsalvageable, the

PROTOTYPING

•

When to use prototyping

– Prototyping supports rather than replaces the SDLC.

– It is appropriate when:

• Users don’t fully understand their needs, or the needs

change rapidly.

• System requirements are difficult to define.

• System inputs and outputs are not known.

• The task to be performed is unstructured or semi-structured.

• Designers are uncertain about what technology to use.

• The system is crucial and needed quickly.

PROTOTYPING

• The users’ reactions to the new system are important

development considerations.

• Many design strategies must be tested.

• The design staff has little experience developing this type of

system or application.

PROTOTYPING

• Good candidates for prototyping:

– Decision support systems.

– Executive information systems.

– Expert systems.

– Information retrieval systems.

– Systems that involve experimentation and

trial-and-error development.

PROTOTYPING

• Prototyping is usually inappropriate for:

– Large or complex systems that:

• Serve major organizational components; or

• Cross numerous organizational boundaries.

– Standard AIS components, such as:

• Accounts receivable

• Accounts payable

PROTOTYPING

• Advantages of prototyping:

–

Better definition of user needs

PROTOTYPING

• Advantages of prototyping:

– Better definition of user needs

PROTOTYPING

• Advantages of prototyping:

– Better definition of user needs

– Higher user involvement and satisfaction

–

Faster development time