Solving Business Problems with Information Systems

I. TOPIC OVERVIEW

Section I, A Systems Approach to Problem Solving, describes and gives examples of the steps
involved in using a systems approach to solve business problems.

Section II, Developing Information Systems Solutions, describes the activities involved and
products produced in each of the stages of the information systems development cycle, including
computer-aided and prototyping approaches to systems development.

II. LECTURE NOTES

A Systems Approach to Problem Solving, describes and gives examples of the steps involved in
using a systems approach to solve business problems.

A. The Scientific Method vs. The Systems Approach

The Scientific Method

The systems approach is based on the established problem-solving methodology known as the
scientific method. The scientific method consists of five steps:

1. Recognize phenomena in the real world.

2. Formulate a hypothesis about the causes or effects of the phenomena.
3. Test the hypothesis through experimentation.
4. Evaluate the results of the experiments.
5. Draw conclusions about the hypothesis.

The Systems Approach

The systems approach is a modification of the scientific method. It stresses a systematic process
of problem solving. Problems and opportunities are viewed in a systems context. Studying a
problem and formulating a solution becomes an organized system of interrelated activities, such
as (Figure 1):

1. Define a problem or opportunity in a systems context.

2. Gather data describing the problem or opportunity
3. Identify alternative solutions.
4. Evaluate each alternative solution.
5. Select the best solution.
6. Implement the selected solution.
7. Evaluate the success of the implemented solution.

It is important to realize that the steps of the systems approach may overlap each other. Some
activities can be used in more than one step of the process. The completion of activities in one
step may extend into the performance of another. Sometimes it may be necessary to cycle back to
a previously completed step for another try.
The activities and steps of the systems approach are typically grouped into a smaller number of
stages of problem solving:
 a. Understanding a problem or opportunity (steps 1 and 2).
b. Developing a solution (steps 3 through 5).
c. Implementing a solution (steps 6 and 7).

B. Understanding a Problem or Opportunity

To solve a problem or pursue an opportunity requires a thorough understanding of the situation at

hand. This implies viewing the problem/opportunity in a systematic fashion within a systems
context.

1. Defining Problems and Opportunities. Problems and opportunities must be identified

when using the systems approach. Symptoms must be separated from problems.
Symptoms are merely signals of underlying problems.
a. A problem is a basic condition that causes undesirable results.
b. An opportunity is a condition that presents the potential for desirable results.

2. Gathering Data and Information. Data and information need to be captured to gain
sufficient background into the problem or opportunity situation. In the context of a
business systems problem, information gathering may encompass the following:

a. Interviews with employees, customers, and managers.

b. Questionnaires to appropriate end users in the organization.
c. Personal observation or involvement in business operations.
d. Examination of documents, reports, procedures manuals, and other
documentation.
e. Inspecting accounting and management reports to collect operating statistics, cost
data, and performance results.
f. Development, manipulation, and observation of a model of the business
operations or systems affected by the problem or opportunity.

Identifying Organizational Systems. In the systems approach, a problem or opportunity

must be viewed in a systems context. To understand a problem or opportunity, you must
understand both the organizational systems and environmental systems in which a
problem or opportunity arises. You must have a systemic view of the situation.

a. A Business as a System. A business faced with a problem or opportunity needs to

be viewed as an organizational system operating within a business environment
(Figure 2). This concept helps us isolate and better understand how a problem or
opportunity may be related to the basic system components of a business.

b. Environmental Systems. A business is a subsystem of society and is surrounded

by other systems in the business environment. Proper interrelationships with the
economic, political, and social stakeholders within the environment should be
maintained. These stakeholders that interact with a business need to be
identified, to determine their effect on a problem or solution.

c. Organizational Subsystems. Typically a business is subdivided into subdivisions

that compose the organizational subsystem.
i. These typically represent functional areas such as marketing,
manufacturing, and finance, but can also represent geographic areas,
product lines, distribution facilities, work groups, etc.

Solving Business Problems with Information Systems, Page-2

 ii. Decomposition is the process of identifying the boundaries of
subsystems within a business and determining the relationships between
the subsystems. Those subsystems most affected by the problem or
opportunity under consideration need to be identified.
(1). Boundaries - for responsibility.
(2). Relationships - between subsystems.

d. Relationships Between Systems. A black box approach aids systems

professionals in analyzing the relationships and interconnections between
subsystems within the firm. In other words, the processing component remains a
black box while inputs and outputs of subsystems are studied.
i. Coupling - the process of determining how tight the function of
subsystems are connected. e.g., JIT - requires a close association between
inventory control and manufacturing.
ii. Decoupling - the process of loosening the connections between systems.
e.g., E-Mail may loosen communications connections within the
organization. People can be more efficient by having differing avenues of
communication available to them.

e. Evaluating Selected Systems. To understand a problem and solve it, you should
try to determine if basic system functions are being properly performed. This
should be done within a systems context by looking at inputs, processing,
outputs, feedback, and control structures. Figure 3 illustrates this concept by
example of a sales subsystem.
i. Inputs.
ii. Processing capabilities.
iii. Outputs.
iv. Feedback.
v. Control structures.

f. Determining Objectives, Standards, and Constraints - a systems approach must

determine firm objectives, identify standards, and recognize constraints. Figure 4
demonstrates the general systems model of the firm with its interrelated
components.
i. Objectives - are accomplishments a system is supposed to achieve.
These need to be stated in clear unambiguous (general) terms. e.g., a
good performance for this season.
ii. Standards - are specific and quantitative measures with which the
objectives achievements can be compared. Standards are used to
measure the progress a firm makes as it tries to achieve objectives of the
system. Standards are needed for systems control. Characteristics of
standards are:
(1). ___________ (2). ______________
(3). ___________ (4). ______________
iii. Constraints - are restrictions on the form and content of a solution
(1). External - constraints required by law or industry conventions.
(2). Internal - constraints that arise due to the scarcity and allocation
of organizational resources or contention among departments.
C. Developing a Solution

Once you understand a problem or opportunity, you can develop an appropriate solution.

Solving Business Problems with Information Systems, Page-3

3. Designing Alternative Solutions. Jumping immediately from problem definition to a
single solution limits your options and robs you of the chance to consider the advantages
and disadvantages of several alternatives. Of course, having too many alternatives can
obscure the best solution. Alternative solutions may come from past experience, advice
of others, simulation of business operations models, and your own intuition and
ingenuity. The "doing nothing" option is also a valid alternative.

4. Evaluating Alternative Solutions. To identify the best solution, the proposed alternatives
need to be evaluated. The goal of evaluation is to determine how well each alternative
solution helps the firm and its selected subsystems meet their objectives.
a. Evaluation criteria - should reflect the firm's objectives and constraints. Figure 5
illustrates a simple example of the evaluation of two alternative solutions using
several criteria.
i. Each alternative needs to be evaluated upon how well it meets the
evaluation criteria.
ii. Criteria may be weighted on their relative importance in achieving firm
goals and objectives.
b. Cost Benefit Analysis - Every legitimate solution will have some advantages or
benefits, and some disadvantages or costs. This process identifies the benefits
and costs associated with each alternative solution.
i. Tangible costs - quantified costs.
(1). Hardware.
(2). Software.
(3). Salaries.
ii. Intangible Costs - difficult to quantify.
(1). Customer goodwill.
(2). Employee morale caused by system errors.
(3). Installation/conversion problems.
iii. Tangible Benefits - favorable results that the firm has attained.
(1). Decrease in payroll.
(2). Decrease in inventory carry.
iv. Intangible Benefits - hard to estimate.
(1). Customer service.
(2). Better delivery of customer request(s).

Figure 5 includes examples of tangible and intangible costs/benefits. Figure 6 lists

typical tangible and intangible benefits with examples.

5. Selecting the Best Solution. Once all alternative solutions have been evaluated, they can
be compared to each other, and the "best" (most desirable) solution can be selected.
Since the solutions are compared based on multiple criteria (some of which may be
intangible), this selection is not always a simple process.

D. Implementing a Solution

6. Implement the selected solution. Once a solution has been selected, it must be
implemented. An implementation plan may have to be developed. A project
management effort may be required to supervise the implementation of large projects.
Typically, an implementation plan specifies the activities, resources, and timing needed
for proper implementation. This may include:

Solving Business Problems with Information Systems, Page-4

 a. Types and sources of hardware and software.
b. Construction of physical facilities.
c. Hiring and training of personnel.
d. Start-up and operating procedures.
e. Conversion procedures and timetables.

7. Postimplementation Review (Evaluate the success of the implemented solution). The

focus of the postimplementation review is to determine if the implemented solution has
indeed helped the firm and selected subsystems meet their system objectives. If not, the
systems approach assumes you will cycle back to a previous step and make another
attempt to find a workable solution.

E. Applying the Systems Approach to Information Systems.

A variety of information systems development methodologies tailor the systems approach

to the process of developing information systems solutions to business problems. A firm
may experience difficulties in applying the systems process to IS due to:

1. Departmental/unit and/or emotional conflicts.

2. Rapidly changing environmental conditions.

SECTION II: Developing Information Systems Solutions

A. The Systems Development Cycle

1. Managerial end users are often times responsible for developing IS solutions for their
organizations. They may also be responsible for managing the developmental efforts of
IS specialists.

2. When the systems approach is applied to the development of information systems

solutions to business problems, it is called information systems development or
application development.

3. The Systems Development Life Cycle (SDLC) - The concept is the application of the
systems approach to the solution of information systems problems.
a. Systems Analysis and Design - is a substantial part of the systems development
life cycle (SDLC).
b. SDLC - includes the following steps:
i. Investigation.
ii. Analysis.
iii. Design.
iv. Implementation.
v. Maintenance.
c. Tools used in the SDLC Process:
i. 4GL's.
ii. Computer Aid Software and Systems Engeering (CASE) TOOLS.
iii. Prototyping.

Figures 7 and 8 show this cycle and the major activities involved in each step.

B. Systems Investigation

Solving Business Problems with Information Systems, Page-5

In this step a business problem or opportunity is identified. Questions related to what causes a
problem and what would be a feasible information systems solution to the problem have to be
answered. This step also includes the screening, selection, and preliminary study of proposed
information systems solutions to business problems. Systems investigation includes: (1) systems
planning and investigation, (2) feasibility study.

1. Information Systems Planning - needs to be part of the regular business planning process.
Business and IS planning helps generate, screen, and select potential IS problems for
further development.

2. Feasibility Studies - are preliminary studies that investigate the information needs,
objectives, constraints, resource requirements, costs, benefits, and feasibility of a
proposed project. Usually a formal feasibility report is given to management for approval
before the systems analysis stage can begin.

Feasibility of a system can be evaluated in terms of four major categories, as illustrated in

Figure 9:

a. Organizational feasibility - how well a proposed information system supports the

objectives of the organization's strategic plan for information systems.

b. Economic feasibility - are expected cost savings, increased revenue, increased

profits, reductions in required investment, and other benefits exceeding the costs
of developing and operating a proposed system.

c. Technical feasibility - whether reliable hardware and software capable of meeting

the needs of a proposed system can be acquired or developed by the business in
the required time.

d. Operational feasibility - the willingness and ability of management, employees,

customers, and suppliers, to operate, use, and support a proposed system.

C. Systems Analysis

If management approves the recommendations of the feasibility study produced by the systems
investigation stage, then the systems analysis stage can begin. Systems analysis is an in-depth
study of end user information needs which produces functional requirements that are used as the
basis for the design of a new information system. Systems analysis traditionally involves a
detailed study of

1. The information needs of the organization (organizational analysis) (see Figure 10) - this
is the first step in the systems analysis process, which involves an understanding of the
following:
a. Organizational management structure.
b. Business personnel.
c. Firm personnel.
d. External business environment.
e. Current IS.

Solving Business Problems with Information Systems, Page-6

2. The activities, resources, and products of any present information system (analysis of the
present system) - the present IS has to be studied to determine correct systems usage of:
a. Inputs. b. Processing.
c. Outputs. d. Storage. e. Control.

3. The information system capabilities required to meet the information needs of end users
(functional requirements analysis)- this step is reasonably difficult process because: (1)
end users specific needs have to be determined, (2) information processing capabilities
for each system activity needs to be determined, and (3) functional requirements need to
be identified. Systems requirements are composed of the following:

a. Input requirements - sources, contents, formats, organization, volume (average

and peak), frequency, codes, and capture and conversion requirements for input.
b. Output requirements - formats, organization, volume (average and peak),
frequency, copies, end user destinations, timing, and retention required for
output.
c. Processing requirements - basic information processing activities required to
convert input into output to perform. Calculations, decision rules, and other
processing operations. Capacity, throughput, turnaround time, and response time
needed for processing activities has to be specified.
d. Storage requirements - organization, content, and size of databases, types and
frequency of updating and inquires, and the length and rationale for record
retention or deletion.
e. Control requirements - accuracy, validity, safety, integrity and adaptability
requirements for system input, processing, output, and storage functions.

Both (a) and (b) above are also called user interface requirements.

D. Systems Design

1. Whereas systems analysis describes what a system should do to meet the information
needs of users, systems design specifies how the system will accomplish this objective.
Systems design consists of design activities which produce system specifications
satisfying the functional requirements developed in the systems analysis stage. These
specifications are used as the basis for software development, hardware acquisition,
system testing, and other activities of the implementation stage. Some of the key
characteristics that should be included in system specifications are outlined in Figure 12.

2. The systems design stage should result in three major products, as illustrated in Figure
11: The user interface design, the data design, and the process design.

a. The user interface design focuses on the interactions between end users and
computer systems, and includes designs for computer display screens,
user/computer dialogues, forms, and reports.
b. Data design focuses on the logical structure of databases and files to be used by
a proposed system. Descriptions of the following will be determined.
i. Entities - people, places, things that the system will need to maintain
information about.
ii. Relationships - between entities.
iii. Data elements - are items that are maintained for each entity tracked in
the IS (databases, files, records).

Solving Business Problems with Information Systems, Page-7

 iv. Integrity rules - govern how each data element is specified and used in
the IS.
c. Process design focuses on the design of computer programs and of procedures
that need to be followed in the proposed system.

3. Logical Systems Design - is the process of developing general specifications for how the
IS can meet end user requirements. In this phase, the logical design concepts are refined
and finalized.

4. Physical System Design - involves the detailed design of user interface methods to
develop hardware, software and personnel specifications for the new system. The
physical design aspects must correspond with the specifications derived from the logical
design phase.

Systems specifications generated from the physical system design phase are:

a. User interface specifications - the content, format, and sequence of user interface
products and methods such as display screens, interactive dialogues, audio
responses, forms, documents, and reports.
b. Database specifications - content, structure, distribution, and access, response,
maintenance, and retention capabilities.
c. Software specifications - the required software package or programming
specifications of the proposed system, including performance and control
specifications.
d. Hardware and facilities specifications - the physical and performance
characteristics of the equipment and facilities required by the proposed system.
e. Personal specifications - job descriptions of personnel who will operate the
system.
f. System documentation specifications - specifications for the documentation of
system characteristics and operating procedures for end users and technical
personnel provided by manuals and built-in software help features.

5. System Design Standards - include the following:

a. Common user access.
b. Common programming interfaces.
c. Common telecommunications support.

A variety of system design standards exist for computer-based information systems.

Conforming to such standards is a major consideration for the design of many types of
software. The primary goal of such standards is to provide end users with application
software with common user interfaces and functions regardless of the CPU platform

E. Implementation and Maintenance

1. Systems Implementation (Figure 13) - Once a proposed information system has been
designed, it must be implemented. This involves hardware and software acquisition,
software development, testing of programs and procedures, development of
documentation, and education and training of end users and specialists who will operate
the new system.
Implementation also includes converting from the old system to the new system (Figure
14). This may involve operating both new and old systems in

Solving Business Problems with Information Systems, Page-8

 a. parallel for a trial period,
b. operating a pilot system on a trial basis at one location,
c. phasing in the new system one application or location at a time, or
d. an immediate cutover to the new system.

2. Systems Maintenance Includes:

a. Monitoring the system.
b. Evaluating system performance.
c. Modifying the system to conform to user needs,
or changes in the business environment.

This may include a postimplementation review process to ensure that the new system
meets the objectives established for it earlier. Later modifications to a system may also
become necessary due to changes within the business or the business environment.

F. Computer-Aided Systems Engineering

The traditional systems development life cycle process is often inflexible, time-consuming, and
expensive. Computer-aided systems engineering (or computer-aided software engineering) or
CASE has emerged to help with project management, interface design, database design, and
software development. CASE involves using software packages, called CASE tools, to perform
many of the activities of the systems development life cycle. Figure 15 illustrates the
components of CASE.

G. Prototyping

Microcomputer workstations and a variety of CASE and other software packages (e.g., 4GL's and
DBMS) allow the rapid development and testing of working models, or prototypes, of new
applications in an interactive, iterative process involving both systems analysts and end users.
Prototyping not only makes the development process faster, but it has opened up the application
development process to end users. Typically, large systems still require using the traditional
systems development approach, but parts of such systems can frequently be prototyped. As
Figure 3.16 illustrates, prototyping is an iterative, interactive process that combines steps of the
traditional systems development cycle.

H. Developing Information System Solutions: Getting Started

The problem-solving and systems development fundamentals introduced in this chapter should
help you propose information system solutions for simple real world business problems. First,
use the solution methodology discussed in Section I. Next, try to use one of the systems
development tools discussed in Appendix A at the back of this text entitled: Using Systems
Development Tools. If you have access to computer-aided tools, you can start by learning how to
use the software packages involved

Solving Business Problems with Information Systems, Page-9

III. KEY TERMS AND CONCEPTS DEFINED
A business as a system. A business firm is an open, adaptive, organizational system with system
components of input, processing, output, feedback, and control.

Black box approach. Concentrating on the inputs and outputs of systems and the interfaces
between subsystems, rather than the processing components within systems.

Computer-aided systems engineering (CASE). Using software packages to computerize many

of the activities in the systems development process.

Constraints. Restrictions on the form and content of a solution.

Cost/benefit analysis. Identifying the advantages (benefits) and the disadvantages (costs) of
proposed solutions.

Economic feasibility. Cost savings and additional profits will exceed the investment required.

Evaluation criteria. Key factors used to evaluate a proposed solution.

Feasibility study. Investigation of the organizational, economic, technical, and operational

feasibility of a solution.

Intangible benefits and costs. The non-quantifiable benefits and costs of a proposed solution.

Objectives. Accomplishments a system is expected to achieve.

Operational feasibility. The willingness and ability of end users to use a proposed system.

Organizational analysis. Evaluating the organizational and environmental systems and

subsystems involved in any situation.

Organizational feasibility. The proposed system supports the objectives and strategic plan of an
organization.

Postimplementation review. Evaluating the success of a new system after it has been
implemented.

Problems versus symptoms. A problem is a basic condition that is causing undesirable results.
Symptoms are merely signals of an underlying problem.

Prototype. A working model of an information system.

Prototyping. An iterative and interactive process of systems development.

Scientific method. An analytical methodology which involves recognizing phenomena,

formulating a hypothesis about the causes of the phenomena, test the hypothesis through
experimentation, evaluate the results of the experiments, and draw conclusions.

Standards. Measures of performance developed to evaluate the progress of a system towards its
objectives.

Solving Business Problems with Information Systems, Page-10

System design standards. Standards or application architectures promoted in the industry for
computer-based information systems.

Functional requirements. A detailed description of user information needs and the input,
processing, output, storage, and control capabilities required to meet those needs.

System specifications. A detailed description of the hardware, software, people, data resources,
and information products required by a proposed system.

Systems analysis. Studying in detail the information needs of users and any information systems
presently used.

Systems approach. Using an organized sequence of activities to study a problem or opportunity

in a systems context.

Systems context. Recognizing systems, subsystems, and components of systems in a situation;

also called a systemic view.

Systems design. The process that results in specifications for the hardware, software, people,
data resources,and information products needed by a proposed system.

Systems development life cycle. A multistep process to conceive, design, and implement an
information system.

Systems implementation. Acquiring hardware and software, testing and documenting a

proposed system, training people to use it, and converting to the new system.

Systems investigation. Identify problems and opportunities and conduct feasibility studies of
possible solutions.

Systems maintenance. Monitoring, evaluating, and modifying a system.

Tangible benefits and costs. The quantifiable benefits and costs of a proposed solution or
system.

Technical feasibility. The availability of hardware, software, and technical skills needed for a
proposed system.

User interface, data, and process design. The three major activities or products of systems
design.

Solving Business Problems with Information Systems, Page-11