Management Information
Systems
Information Systems in Global
Business Today
Lecture 3
1
Systems Analysis
“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!
2
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?
3
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
4
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.
5
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
6
The Role of a Systems Analyst




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
7
SA Skill Set

Technical Skills


Analytical Skills


System Thinking, Value Focused Thinking
Managerial Skills



Integration and Communication
Business Domain, Project Management, Change Management
Expectations Management!
Interpersonal Skills

Team player, communicator
8
IS

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.
9
Types of IS
Web-based
EIS
DSS/ES
Office Automation (OA)
Workgroup Management
Systems (WMS)
MIS
TPS
10
IS Support Decision Making
TYPE OF
DECISION
STRUCTURED
Organizational Level
OPERATIONAL
KNOWLEDGE
STRATEGIC
ACCOUNTS
RECEIVABLE
TPS
ELECTRONIC
SCHEDULING
OAS
SEMISTRUCTURED
PRODUCTION
COST OVERRUNS
MIS
BUDGET
PREPARATION
PROJECT
SCHEDULING
DSS
KWS
UNSTRUCTURED
MANAGEMENT
PRODUCT DESIGN
FACILITY
LOCATION
ESS
NEW PRODUCTS
NEW MARKETS
11
Systems Development Life Cycle
Preliminary
Investigation
The problem
Analysis
System requirement
Conceptual
Design
Blueprint for detailed design
Physical
Design
Full design
Implementation
& Conversion
Operational system
Operation &
Maintenance
12
Systems Development Life Cycle
Preliminary
Investigation
Wrong problem
The problem
Analysis
System requirement
Conceptual
Design
Blueprint for detailed design
Change in
Scope/Requirement
Bad blueprint
Physical
Design
Full design
Implementation
Unfixable & Conversion
Operational system
errors
Operation &
Implementation Maintenance
incomplete
13
The Systems Development Life Cycle

The SDLC usually incorporates the following generalpurpose 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.
14
Obsolete solution
Planning
Problem to be solved
Related problem to be solved
Analysis
Support
New solution
to same problem
Implementation
error
to be fixed
Problem analysis
and
Solution requirements
Implemented
solution
Implementation
Acceptable
solution
Design
15
CYCLE!
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
16
The Roles of a Systems Analyst


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..
17
Trends: Total Quality Management

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
18
Trends: Business Process Redesign

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).
19
Trends: Continuous Process
Improvement

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.
20
Trends: Globalization




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!
21
So What is the Problem?



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!
22
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?
23
Ishikawa Diagram
Methods
People
High customer walkouts
High distribution costs
Secondary Symptom
Observed
Symptom Or Variance
Root Problem
Possible Symptom Categories
Symptom
Category
Symptom
Category
4Ps: People, Place, Procedure, Policy
4Ms: Manpower, Machines, Methods, Materials
4Ss: Surroundings, Suppliers, Systems, Skills
24
PIECES Framework
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.
25
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 Directives
A. 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 request
INFORMATION (and Data) Problems, Opportunities, and Directives
A. Outputs
1. Lack of any information
2. Lack of necessary information
3. Lack of relevant information
4. Too much information – ``information overload''
5. Information that is not in a useful format
6. Information that is not accurate
7. Information that is difficult to produce
8. Information is not timely to its subsequent use
26
PIECES
INFORMATION (and Data) Problems, Opportunities, and Directives
B. Inputs
1. Data is not captured
2. Data is not captured in time to be useful
3. Data is not accurately captured -- contains errors
4. Data is difficult to capture
5. Data is captured redundantly -- same data captured more than once
6. Too much data is captured
7. 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
27
PIECES
ECONOMICS Problems, Opportunities, and Directives
A. Costs
1. Costs are unknown
2. Costs are untraceable to source
3. Costs are too high
B. Profits
1. New markets can be explored
2. Current marketing can be improved
3. Orders can be increased
CONTROL (and Security) Problems, Opportunities, and Directives
A. Too little security or control
1. Input data is not adequately edited
2. Crimes are (or can be) committed against data
a. Fraud
b. 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
28
PIECES
CONTROL (and Security) Problems, Opportunities, and Directives
A. Too little security or control (continued)
5. Data privacy regulations or guidelines are being (or can be) violated
6. Processing errors are occurring (either by people, machines, or software)
7. Decision-making errors are occurring
B. Too much security or control
1. Bureaucratic red tape slows the system
2. Controls inconvenience customers or employees
3. Excessive controls cause processing delays
EFFICIENCY Problems, Opportunities, and Directives
A. People, machines, or computers waste time
1. Data is redundantly input or copied
2. Data is redundantly processed
3. Information is redundantly generated
B. People, machines, or computers waste materials and supplies
C. Effort required for tasks is excessive
D. Materials required for tasks is excessive
29
PIECES
SERVICE Problems, Opportunities, and Directives
A. The system produces inaccurate results
B. The system produces inconsistent results
C. The system produces unreliable results
D. The system is not easy to learn
E. The system is not easy to use
F. The system is awkward to use
G. The system is inflexible to new or exceptional situations
H. The system is inflexible to change
I. The system is incompatible with other systems
J. The system is not coordinated with other systems
30
Typical Pieces Analysis
Symptom in one (max 2) categories
Symptom
P
Management reports are often not received on time.
Production line throughput is below expected standards.
I
E
S
X
X
Inventory control reports are inaccurate.
X
X
X
X
Orders are often cancelled due to excessive delivery wait
time.
Required information to process an order not available on
demand.
Organizational data redundancy is high.
X
Production lines are often down for repair or maintenance.
X
X
X
Line personnel are often not aware of their production
quota.
Data transferred from production system to sales system by
hand.
Several incidents of system sabotage have been recorded.
Totals
C
X
Product rework is high.
Exceptions occur frequently and must be processed by
hand.
Production time is higher than industry average.
E
X
X
X
2
2
X
4
5
1
1
Likely Problem Areas
31
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!
32
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


But, maybe we do make rational decisions that are just
bounded by uncontrollable constraints?


cognitive limitations of human beings
Satisfying
It’s natural to think about what we want and look for it.

SAD methodologies are designed to avoid this “anchoring” bias
33
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.
34
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.
35
Decomposition : Systems Development
Life Cycle
Preliminary
Investigation
Analysis
Logical
Design
Physical
Design
Implementation
& Conversion
Operation &
Maintenance
36
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
37
Analysis

Key Activities



Create logical models of
current system
Refine problem statement
via detailed symptom
analysis
Determine requirements for
new system

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!
What is?
 Implementation
Independent!
38
Logical Design

Key Activities



Revise current system
logical models to reflect
proposed system changes
Validate logical model of
proposed system against
requirements determination

Primary Deliverables



DFD of proposed system
ERD of proposed system
Final performance
specifications
“What should be?” not
“How?”
39
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
40
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
41
Maintenance

Key Activities



Conduct postimplementation review
Perform requested and
necessary changes to new
system
Monitor performance
against established
guidelines

Primary Deliverables

Continually functioning
system
42
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
43
End of Lecture 3
Questions?
44