1

Management Information Systems

Information Systems in Global Business Today

Lecture 3

2

“There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of the new order of things.”

-- Niccolò Machiavelli

Technical and non-technical expertise May not involve technology at all!

Systems Analysis

3

Systems Analysis and Design (SAD)

Structured process employed to develop IT/IS projects Identification of business problems Identification/creation of potential solutions Selection, design and implementation of final solution

Problem solving … technology? How do we allow our customers to order products any time of the

day or night with minimal cost increases? How can we enable the location of physical assets as well as

communication that will allow re-location? How do we determine the optimal production mix taking into

account the limitations on the production floor?

4

Analysis … Design

SAD contains at least two distinct processes Analysis : determine the nature and the domain of the business

problem What is the problem? What is the best solution to solve it?

Design : design, construction and implementation of solution How do we transform the solution to a usable IS?

A good Analysis is often followed by no Design A good Design is rarely preceded by no Analysis

5

Process vs. Data Centricity

Data-Centric Approach Process-Centric Approach

 What data does the system need? 

 What is the system supposed to do?

Tends to have an enduring design stability due to low volatility in organizational data needs.

 Design stability is necessarily limited due to constant changes in business processes. 

 The file structure is enterprise dependent. 

 The file structure is application dependent.

 Data redundancy is generally limited and controlled. 

 Data redundancy is generally massive and uncontrolled.

6

Players in the Development Game

Clients and/or End Users : who benefits IS Management : set criteria and oversee development Systems Analysts : facilitate and communicate Application Programmers : CASE tools? IS Support Personnel

Vendors Database Administrators Telecom Audit & Security: SOX! IT Steering Committee

7

The system analyst bridges the communications gap between those who need the computer and those who understand the technology.

SA understands business and technology transform business and information requirements of the

organization into computer-based information systems

The Goal : improved business processes improved information systems new or improved computer applications all three

The Role of a Systems Analyst

8

SA Skill Set

Technical Skills Integration and Communication

Analytical Skills System Thinking, Value Focused Thinking

Managerial Skills Business Domain, Project Management, Change Management Expectations Management!

Interpersonal Skills Team player, communicator

9

What is an Information System? An information system is an arrangement of people, data,

processes, interfaces, networks, and technology that interact for the purpose of supporting and improving both day-to-day operations in a business - data processing -, as well as supporting the problem solving and decision making needs of management - information services.

What is a Computer Application System? A computer application is computer-based solution to one or

more business problems and needs.

IS

10

Types of IS

TPS

MIS

DSS/ES

EIS

Office Automation (OA)Workgroup Management Systems (WMS)

Web-based

11

IS Support Decision Making

TPSOAS MIS

KWS

DSS

ESS

Organizational LevelTYPE OFTYPE OFDECISIONDECISION OPERATIONAL KNOWLEDGE MANAGEMENT STRATEGIC

STRUCTURED ACCOUNTS RECEIVABLE

ELECTRONIC PRODUCTIONSCHEDULING COST OVERRUNS

SEMI- BUDGETSTRUCTURED PREPARATION

PROJECTSCHEDULING

FACILITYLOCATION

UNSTRUCTURED PRODUCT DESIGN NEW PRODUCTSNEW MARKETS

12

Systems Development Life Cycle

ConceptualDesign

Analysis

PhysicalDesign

Implementation& Conversion

Operation &Maintenance

System requirement

Blueprint for detailed design

Full design

Operational system

PreliminaryInvestigation

The problem

13

Systems Development Life Cycle

ConceptualDesign

Analysis

PhysicalDesign

Implementation& Conversion

Operation &Maintenance

System requirement

Blueprint for detailed design

Full design

Operational system

Change inScope/Requirement

Bad blueprint

Implementationincomplete

Unfixableerrors

PreliminaryInvestigation

The problem

Wrong problem

14

The SDLC usually incorporates the following general-purpose problem solving steps: Planning - identify the scope and boundary of the problem, and

plan the development strategy and goals. Analysis - study and analyze the problems, causes, and effects.

Then, identify and analyze the requirements that must be fulfilled by any successful solution.

Design - if necessary, design the solution Implementation - implement the solution. Support - analyze the implemented solution, refine the design,

and implement improvements to the solution. Different support situations can thread back into the previous steps.

The Systems Development Life Cycle

15

Planning

Analysis

Design

Support

Problem to be solved

Problem analysis and

Solution requirements

Acceptable solution

Obsolete solution

Implemen- tation

Implemented solution

Related problem to be solved

New solution to same problemImplementation

error to be fixed

CYCLE!

16

Alternatives to SDLC

OOAD : Objective Oriented Analysis and Design Combine Data and Processes into an Object Focus on reuse

RAD : Rapid Application Development More parallel approach to development

17

A business analyst is a systems analyst that specializes in business problem analysis and technology-independent requirements analysis.

An application analyst is a systems analyst that specializes in application design and technology-dependent aspects of development. system or application architect..

The Roles of a Systems Analyst

18

TQM A comprehensive approach to facilitating quality improvements

and management within a business. Identify quality indicators, measure quality, and make appropriate

changes to improve quality Nature of systems analysis encourages analysts to look for

business quality problems. Incomplete and inconsistent specifications from analysts are a

significant contributor to poor software quality

Trends: Total Quality Management

19

BPR the study, analysis, and redesign of fundamental business

processes to reduce costs and improve value added to the business BPR project begins with identification of a value chain, a

combination of processes that should result in some value to the business.• The business processes are documented and analyzed in excruciating

detail and streamlined for maximum efficiency. BPR & SA

• The skill competencies for BPR and systems analysis and design are somewhat similar.

• Typical BPR project identifies several opportunities for new and revised computer applications (which systems analysts facilitate).

Trends: Business Process Redesign

20

CPI the continuous monitoring of business processes to affect small

but measurable improvements to cost reduction and value added• BPR is intended to implement dramatic change.

• CPI implements a continuous series of smaller changes. Continuous improvement contributes to both cost reductions,

improved efficiencies, and increased value and profit. Systems analysts may be called upon to participate in continuous

process improvement initiatives for any business process, including the design and implementation of improvements to associated computer applications.

Trends: Continuous Process Improvement

21

Most businesses have been forced to reorganize to compete globally

IS must support multiple languages, currency exchange rates, international trade regulations, accepted business practices

Coordination of information International Outsourcing -- detailed requirements needed!

Trends: Globalization

22

Problems vs. Symptoms A problem is a difference between what we have and what

we want. A symptom is an outward manifestation of a problem

Variance, good or bad, from the norm Many symptoms may be the result of the same problem Houston, we have a symptom

A symptom is evidence of the problem but not necessarily the problem itself.

Problem definition requires a viewpoint!

So What is the Problem?

23

Problem Recognition and Definition

Recognize a variance – symptom(s) Investigate – interview users, observe use, test the system Propose a solution – experiment with the system

Ishikawa (fishbone) diagrams can help separate cause and effect

1: come up with symptom categories (people, materials, skills…) 2: relate observed symptoms to categories 3: look for secondary symptoms

Iterative Team Process Why is this *insert symptom here* happening?

24

Ishikawa Diagram

Root Problem

Methods People

Symptom Category

Symptom Category

Possible Symptom Categories

4Ps: People, Place, Procedure, Policy4Ms: Manpower, Machines, Methods, Materials4Ss: Surroundings, Suppliers, Systems, Skills

Possible Symptom Categories

4Ps: People, Place, Procedure, Policy4Ms: Manpower, Machines, Methods, Materials4Ss: Surroundings, Suppliers, Systems, Skills

Observed Symptom Or Variance

Secondary Symptom

High distribution costs

High customer walkouts

Low allocation of staff

25

P - the need to improve performance.

I - the need to improve information (and data).

E - the need to improve economics

control costs, or increase profits.

C - the need to improve control or security.

E - the need to improve efficiency of people and processes

S - the need to improve service to customers, suppliers, partners, employees, etc.

PIECES Framework

26

PIECES

The following checklist for problem, opportunity, and directive identification uses Wetherbe's PIECES framework. Note that the categories of PIECES are not mutually exclusive; some possible problems show up in multiple lists. Also, the list of possible problems is not exhaustive. The PIECES framework is equally suited to analyzing both manual and computerized systems and applications.

PERFORMANCE Problems, Opportunities, and DirectivesA. Throughput – the amount of work performed over some period of time.B. Response time – the average delay between a transaction or request and a response to that

transaction or requestINFORMATION (and Data) Problems, Opportunities, and Directives

A. Outputs1. Lack of any information2. Lack of necessary information3. Lack of relevant information4. Too much information – ``information overload''5. Information that is not in a useful format6. Information that is not accurate7. Information that is difficult to produce8. Information is not timely to its subsequent use

27

PIECES

INFORMATION (and Data) Problems, Opportunities, and DirectivesB. Inputs

1. Data is not captured2. Data is not captured in time to be useful3. Data is not accurately captured -- contains errors4. Data is difficult to capture5. Data is captured redundantly -- same data captured more than once6. Too much data is captured7. Illegal data is captured

C. Stored Data

1. Data is stored redundantly in multiple files and/or databases

2. Stored data is not accurate (may be related to #1)

3. Data is not secure to accident or vandalism

4. Data is not well organized

5. Data is not flexible – not easy to meet new information needs from stored data

6. Data is not accessible

28

PIECES

ECONOMICS Problems, Opportunities, and DirectivesA. Costs

1. Costs are unknown2. Costs are untraceable to source3. Costs are too high

B. Profits1. New markets can be explored2. Current marketing can be improved3. Orders can be increased

CONTROL (and Security) Problems, Opportunities, and DirectivesA. Too little security or control

1. Input data is not adequately edited2. Crimes are (or can be) committed against data

a. Fraudb. Embezzlement

3. Ethics are breached on data or information – refers to data or information letting to unauthorized people

4. Redundantly stored data is inconsistent in different files or databases

29

PIECES

CONTROL (and Security) Problems, Opportunities, and DirectivesA. Too little security or control (continued)

5. Data privacy regulations or guidelines are being (or can be) violated6. Processing errors are occurring (either by people, machines, or software)7. Decision-making errors are occurring

B. Too much security or control1. Bureaucratic red tape slows the system2. Controls inconvenience customers or employees3. Excessive controls cause processing delays

EFFICIENCY Problems, Opportunities, and DirectivesA. People, machines, or computers waste time

1. Data is redundantly input or copied2. Data is redundantly processed3. Information is redundantly generated

B. People, machines, or computers waste materials and suppliesC. Effort required for tasks is excessiveD. Materials required for tasks is excessive

30

PIECES

SERVICE Problems, Opportunities, and DirectivesA. The system produces inaccurate resultsB. The system produces inconsistent resultsC. The system produces unreliable resultsD. The system is not easy to learnE. The system is not easy to useF. The system is awkward to useG. The system is inflexible to new or exceptional situationsH. The system is inflexible to changeI. The system is incompatible with other systemsJ. The system is not coordinated with other systems

31

Typical Pieces Analysis

Symptom P I E C E SManagement reports are often not received on time.   X        Production line throughput is below expected standards. X          Product rework is high.     X   X  Inventory control reports are inaccurate.   X        Exceptions occur frequently and must be processed by hand.

          X

Production time is higher than industry average. X          Orders are often cancelled due to excessive delivery wait time.

X          Required information to process an order not available on demand.

  X        Organizational data redundancy is high.   X        Production lines are often down for repair or maintenance. X          Line personnel are often not aware of their production quota.

  X        Data transferred from production system to sales system by hand.

        X X

Several incidents of system sabotage have been recorded.       X    

Totals 4 5 1 1 2 2

Likely Problem Areas

Symptom in one (max 2) categories

32

Problem Statement

First, we observe, identify and record symptoms All we have is an informed guess but we have to start

somewhere Can’t edit or refine something that doesn’t exist

The written problem statement should list the symptoms, suggest their likely cause of causes, and begin an estimate of the resources to develop an effective solution.

a.k.a. Statement of Scope and Objectives Establish what the system will and will not due

This can (will) change but define boundaries early!

33

Bounded Rationality

Problem solvers are willing to settle for a satisfactory solution to a given problem, and avoid the extreme effort necessary to find the optimal solution

cognitive limitations of human beings

But, maybe we do make rational decisions that are just bounded by uncontrollable constraints?

Satisfying

It’s natural to think about what we want and look for it. SAD methodologies are designed to avoid this “anchoring” bias

34

Systems

A system is a set of interrelated elements, with an identifiable boundary, that function together to achieve a common goal

Interrelated Elements subsystems works together to achieve the goals system. Synergy?

Boundaries A system is definable within the context of all other systems by

virtue of it having a boundary. Elements that are not contained within the boundary of a

system are said to be a part of the environment of the system (uncontrollable) rather than a part of the system itself (controllable).

Common Goal The goal or purpose of a system is its reason for being.

35

Divide and Conquer

Functional decomposition the process of breaking a system down into its component

elements allows the study of a single part of a system and consideration of

refinement or modification independently from the larger system Modularity

When do you stop decomposing? When you’ve learned what you need to know.

36

Decomposition : Systems Development Life Cycle

LogicalDesign

Analysis

PhysicalDesign

Implementation& Conversion

Operation &Maintenance

PreliminaryInvestigation

Creeping Commitment

37

Preliminary Investigation

Key Activities Problem definition Estimate problem scope Estimate project feasibility Estimate resource

commitment Go/no go decision

Primary Deliverables Preliminary feasibility

report General problem statement

38

Analysis

Key Activities Create logical models of

current system Refine problem statement

via detailed symptom analysis

Determine requirements for new system

What is? Implementation

Independent!

Primary Deliverables DFD of current system ERD of current system Formal problem statement Formal requirements

definition Include new features and

prioritization of features Expectations management!

39

Logical Design

Key Activities Revise current system

logical models to reflect proposed system changes

Validate logical model of proposed system against requirements determination

“What should be?” not “How?”

Primary Deliverables DFD of proposed system ERD of proposed system Final performance

specifications

40

Physical Design

Key Activities Determine hardware

specifications Determine software

specifications Conduct feasibility analysis

and cost justification for new system

Estimate implementation schedule

Design data structures Prepare training guidelines Prepare preliminary testing

procedures

Primary Deliverables Detailed hardware

specifications Detailed software

specifications Final feasibility report Physical data structures and

data dictionary Implementation schedule

41

Implementation

Key Activities Acquire hardware and

software Determine location

requirements Install the new system

Parallel? Cutover? Steps? Create test data and conduct

initial system tests Train all end users Verify all end user and

system documentation

Primary Deliverables Final performance test

metrics Fully trained end user

community Publish docs

Fully installed system Fully converted data files

42

Maintenance

Key Activities Conduct post-

implementation review Perform requested and

necessary changes to new system

Monitor performance against established guidelines

Primary Deliverables Continually functioning

system

43

Underlying Principles of Systems Development

Get the owners and users involved Use a problem-solving approach Establish phases and activities Establish standards for consistent

development and documentation Justify systems as capital investments Don’t be afraid to cancel Divide and conquer Design systems for growth and change

44

End of Lecture 3

Questions?