System Approach to problem solving

The systems approach to problem solving used a systems orientation to define problems and opportunities and develop solutions.  Studying a problem and formulating a solution involve the following interrelated activities:

1. Recognize and define a problem.
2. Develop and evaluate alternative system solutions.
3. Select the system solution that best meets your requirements.
4. Design selected system solution.
5. Implementation
6. Post Implementation and control

1) Defining problems and opportunities

Problems and opportunities are identified in the first step of the systems approach. A problem can be defined as a basic condition that is causing undesirable results. An opportunity is a basic condition that presents the potential for desirable results.

Example;

Symptom: Sales of a company’s products are declining. Problem: Sales persons are losing orders because they cannot get current information on product prices and availability.

2) Developing and evaluating alternate solutions

There are usually several different ways to solve any problem or pursue any opportunity. Jumping immediately from problem definition to a single solution is not a good idea. It limits your options and robs you of the chance to consider the advantages and disadvantages of several alternatives. You also lose the chance to combine the best points of several alternative solutions.

Where do alternative solutions come from/ experience is good source. The solutions that have worked, or at least been considered in the past, should be considered again. Another good source of solutions is the advice of others, including the recommendations of consultants and the suggestions of expert systems.

3) Selecting the best solution

Once all alternative solutions have been evaluated, you can be the process of selecting the best solution. Alternative solutions can be compared to each other because they have been evaluated using the same criteria.

Example;

Alternatives with a low accuracy evaluation (an accuracy score less than 10), or a low overall evaluation (an overall score less than 70) should be rejected.

Therefore, alternative B for sales data entry is rejected, and alternative A, the use of laptop computers by sales reps, is selected.

4) Designing

Once a solution has been selected, it must be designed and implemented. You may have to depend on other business end users’ technical staff to help you develop design specifications and an implementation plan.

5) Implementing solution

An implementation plan specifies the resources, activities, and timing needed for proper implementation. For example, the following items might be included in the design specifications and implementation plan for a computer-based sales support system:

• Types and sources of computer hardware, and software to be acquired for the sales reps.
• Operating procedures for the new sales support system.
• Training of sales reps and other personnel.
• Conversion procedures and timetable for final implementation.

6) Post implementation and Control

The real world has a way of confounding even the well-designed solutions. Therefore, the results of implementing a solution should be monitored and evaluated. This is called a post-implemented. The focus of this step 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.

Information gathering tools...

Introduction

Information Gathering is a very key part of the feasibility analysis process. Information gathering is both an art and a science. It is a science because it requires a proper methodology and tools in order to be effective. It is an art too, because it requires a sort of mental dexterity to achieve the best results. In this article we will explore the various tools available for it, and which tool would be best used depending on the situation.

Information Gathering Tools

There is no standard procedures defined when it comes to the gathering of information. However, an important rule that must be followed is the following: information must be acquired accurately and methodically, under the right conditions and with minimum interruption to the individual from whom the information is sought.

1. Review of Procedural Forms

These are a very good starting point for gathering information. Procedural manuals can give a good picture of the system to be studied: how the existing system works, what are its assumptions, what information flows in, and what flows out, what dependency there is on the external system, if any. Problems that one can encounter here are the lack of updated manuals or documents, or sometimes the need for possession of the correct documents. Hence, this is just one of the means of gathering information. However, procedural forms can capture some important information like:

• Who are the users of the forms?
• Do the forms have all the necessary information?
• How readable and understandable are they?
• How does the form help other users to make better decisions?

2. On Site Visits and Observations

The main objective of an on site visit is to get as close to the real system as possible.
It is important that the person who visits on site is a keen observer and is knowledgeable about the system and the normal activities that occur within the system. When a person observes a system, the emphasis is more on observing how things are done rather than giving advice as to what is wrong or right or passing judgment. There are various observation methods used:
Direct or Indirect: - The analyst can observe the subject or the system directly. E.g.: How do the workers perform a job on the factory floor? An indirect form of observation is done using some devices like video cameras or video tapes which would capture the information.
Structured or Unstructured: - In a structured observation the specific actions are recorded. E.g.: Before a shopper buys a product, how many related products did he see before selecting the final product? An unstructured method would record whatever actions would happen at a given point of time.

3. Interviews and Questionnaires

The interview is a face-to-face interpersonal meeting designed to identify relations and verify information to capture raw information as told by the interviewee.
3.1 Interview – Interview is a flexible tool and a better tool than a questionnaire for the evaluation of the validity of the information that is being gathered. It is an art that requires experience in arranging the interview, setting the stage, establishing rapport. The questions must be phrased clearly, avoiding misunderstandings and carefully evaluating the responses. The disadvantage in this technique is the preparation time it requires and it is obviously restricted to only one person at a time which means that the whole process of gathering results will take far longer.

Types of Interview

A. Structured Interview

The skill of the interviewer helps in getting the interviewee to respond and move to the next question without diversion. The questions are presented to the interviewee with exactly the same wording and in the same order.

B. Unstructured Interview

In the unstructured Interview the respondents are allowed answer freely in their own words. The responses are not forced. They are self-revealing and personal rather than general and superficial. The interviewer has encouraged the respondents talk freely. Unstructured interviews provide an opportunity to delve more deeply into complex topics than is possible with surveys.

3.2 Questionnaire- Questionnaire is a self-administered tool that is more economical and requires less skill to administer than the interview. At any point in time, unlike the interview, feedback from many respondents can be collected at the same time. Since questionnaires are usually self-administered it is critical that questions be clear and unambiguous.
With the help of a table below we can understand the differences between the questionnaires and an interview. This is designed to give a completely unbiased viewpoint of both methods. We will be able to view them in such a way that the benefits and shortcomings of each will be easily visible right away.

Types of Questionnaire

A. Fill-in-the-blanks Questions:

They seek specific responses.

B. Yes / No Questions:

They just seek one value either true or false or Yes or NO. There is no mixed response.

C. Ranking Scale Questions:

The respondent needs to rank the responses into a certain scale. For e.g. to a question you might be asked to rate a service from a level 1 to 5.

D. Multiple-Choice Questions:

They ask for a specific answer choices.

Questionnaire	Interview
Economical	Less Economical
Can be completed by many people at the same time	Can be administered to ONLY ONE person at a time
Chances of error or omissions are fewer	It could be error prone since it depends upon the skill of the interviewer to gauge the questions and interpret the responses.
Anonymity can be maintained. Hence user is not prevented from giving his candid opinion about an issue	Anonymity is not maintained. Hence the user might feel forced to conceal his candid opinion on an issue.
Gives time to the respondents. Hence they can think and give their regarded opinions on an issue	It may not give time to the respondents. Hence they may not get enough time to think and give their opinion on an issue

INFORMATION COLLECTION TOOLS – ADVANTAGES AND DISADVANTAGES

Information Collection Tools	Advantages	Disadvantages
Document Review	·         Relatively inexpensive ·         Good source of background information ·         Unobtrusive ·         Provides a “behind the scenes” look at a program that may not be directly observable ·         May bring up issues not noted by other means	·         Information may be inapplicable, disorganized, unavailable or out of date ·         Could be biased because of selective survival of information ·         Information may be incomplete or inaccurate ·         Can be time consuming to collect, review, and analyze many documents
Observation	·         Collect data where and when an event or activity is occurring ·         Does not rely on people’s willingness to provide information ·         Directly see what people do rather than relying on what they say they do	·         Susceptible to observer bias ·         Hawthorne effect – people usually perform better when they know they are being observed ·         Does not increase understanding of why people behave the way they do
Questionnaires	·        Administration is comparatively inexpensive and easy even when gathering data from large numbers of people spread over wide geographic area ·        Reduces chance of evaluator bias because the same questions are asked of all respondents	·        Survey respondents may not complete the survey resulting in low response rates ·        Items may not have the same meaning to all respondents ·        Size and diversity of sample will be limited by people’s ability to read
Interviews	·         Useful for gaining insight and context into a topic ·         Allows respondents to describe what is important to them ·         Useful for gathering quotes and stories	·         Susceptible to interview bias ·         Time consuming and expensive compared to other data collection methods ·         May seem intrusive to the respondent

The Tools of Structured Analysis:

The Data Flow Diagram

The first step is to draw a data flow diagram (DFD). The DFD was-first developed by Larry Constantine as a way of expressing system requirements in a graphical form; this led to a modular design.

A DFD, also known as a "bubble chart,’’ has the purpose of clarifying system requirements and identifying major transformations that will be­ come programs in system design, So it is the starting point of the design phase that functionally decomposes the requirements specifications down to the lowest level of detail. 

A DFD consists of a series of bubbles joined by lines, The bubbles represent data transformations and the lines represent data flows in the system. The system takes orders from the customer (bookstore, library, etc.), checks them against an index (file) listing the books available, verifies. Customer credit through credit information files, and authorizes shipment with an invoice.

Data Dictionary

•A structured place to keep details of the contents of data flows, processes, and data store.

•It is a structured repository of data about data.

•It is a set of definitions of all DFD elements

Advantages of Data Dictionary

•Documentation- it is a valuable reference in any organization.

•It improves analyst/user communication by establishing consistent definitions of various elements, terms and procedures

•It is important step in building a database

Items to be defined in Data Dictionary

•Data Elements- smallest unit of data that provides for no further decomposition.

For example: date consists of day, month and year

•Data Structure- a group of data elements handled as a unit.

For example: phone is a data structure consisting of four data elements: area-code-exchange-number-extension.

•Data Flows and Data Stores- data flows are data structures in motion, whereas data stores are data structures at rest. A data store is a location where data structures are temporarily located.

Decision Tree

A decision tree is a decision support tool that uses a tree-like graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. It is one way to display an algorithm. Decision trees are commonly used in operations research, specifically in decision analysis, to help identify a strategy most likely to reach a goal. If in practice decisions have to be taken online with no recall under incomplete knowledge, a decision tree should be paralleled by a probability model as a best choice model or online selection model algorithm. Another use of decision trees is as a descriptive means for calculating conditional probabilities.

Structured English

Structured English borrows heavily from structured programming; it uses logical construction and imperative sentences designed to carry out instructions for action. Decisions are made through IF, THEN, ELSE, and so statements. The structured English for our publisher's discount policy is shown

COMPUTE-DISCOUNT

Add up the number of copies per book title

IF order is from bookstore
and-IF order is for 6 copies or more per book title
THEN: Discount is 25%
ELSE (order is for fewer than 6 copies per book title)
SO: no discount is allowed
ELSE (order is from libraries or individual customers)
order is for 50 copies or more per book title discount is 15%
ELSE IF order is for 20 to 49 copies per book title discount is 10%
ELSE IF order is for 6 to 19 copies per book title discount is 5%
ELSE SO:(order is for less' than 6 copies per book order) no discount is allowed
MEDIUM: 20 to 49 copies LARGE: 50 or more copies

From these examples we see that when logic is written out in English sentences using capitalization and multilevel indentation, it is structured English. In this tool, the logic of processes of the system is expressed by using the capitalized key words IF, THEN, ELSE, and so. Structures are indented to reflect the logical hierarchy. Sentences should also be clear, concise, and precise in wording and meaning.

Feasibility Study:

Feasibility Study

Many feasibility studies are disillusioning for both users and analysts. First, the study often presupposes that when the feasibility document is being prepared, the analyst is in a position to evaluate solutions. Second, most studies tend to overlook the confusion inherent in system development-the constraints and the assumed attitudes. If the feasibility study is to serve as a decision document, it must answer three key questions:

1. Is there a new and better way to do the job that will benefit the user?
2. What are the costs and savings of the alternative (S)?
3. What is recommended?

The most successful system projects are not necessarily the biggest or most visible in a business but rather those that truly meet user expectations. More projects fail because of inflated expectations than for any other reason.

Importance=Why Are Feasibility Studies so Important?

The information you gather and present in your feasibility study will help you:

 List in detail all the things you need to make the business work;

Identify logistical and other business-related problems and solutions;

Develop marketing strategies to convince a bank or investor that your business is worth considering as an investment; and Serve as a solid foundation for developing your business plan.

Economic Feasibility

Economic analysis is the most frequently used method for evaluating the effectiveness of a candidate system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. Otherwise, further justification or alterations in the proposed system will have to be made if it is to have a chance of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle. More on cost/benefit analysis is covered in Chapter.

Technical Feasibility

Technical feasibility centers around the existing computer system (hardware, software , etc) and to what extent it can support the proposed addition. For example, if the current computer is operating at 80 percent capacity-an arbitrary ceiling-then running another application could overload the system or require additional hardware. This involves financial considerations to accommodate technical enhancements. If the budget is a serious constraint, then the project is judged not feasible.

In technical feasibility the following issues are taken into consideration.

       Whether the required technology is available or not

       Whether the required resources are available -

- Manpower- programmers, testers & debuggers

- Software and hardware

Once the technical feasibility is established, it is important to consider the monetary factors also. Since it might happen that developing a particular system may be technically possible but it may require huge investments and benefits may be less. For evaluating this, economic feasibility of the proposed system is carried out.

Behavioral Feasibility

People are inherently resistant to change, and computers have been known to facilitate change. An estimate should be made of how strong a reaction the user staff is likely to have toward the development of a computerized system. [t is common knowledge that computer installations have something to do with turnover, transfers, retraining, and changes in employee job status. Therefore, it is understandable that the introduction of a candidate system requires special effort to educate, sell, and train the staff on new ways of conducting business  In our safe deposit example, three employees are more than 50 years old and have been with the bank over 14 years, four years of which have been in safe deposit. The remaining two employees are in their early thirties. They joined safe deposit about two years before the study. Based on data gathered from extensive interviews, the younger employees want the programmable aspects of safe deposit (essentially billing) put on a computer. Two of the three older employees have voiced resistance to the idea. Their view is that billing is no problem. The main emphasis is customer service-personal contacts with customers. The decision in this case was to go ahead and pursue the project.

       Is the audience likely to adopt the behavior? Is the current behavior seen as a problem? How engrained or “rewarding” are the current or competing behaviors?

       How costly is it (time, effort, resources) for the audience segment to perform the behavior?

       How complex is the behavior (does it involve few or several elements)?

The System Development Life Cycle:

System Development Life Cycle (SDLC) Methodologies

SDLC (System Development Life Cycle), just as the name implies, is defined as the process (as a whole) of developing system or software to meet certain requirements. It covers many activities; starts from understanding why the system should be built, studying the project feasibility, analyzing problems, choosing the system design and architecture, implementing and testing it, up to delivering the system as product to the user. SDLC is a process of gradual refinement, meaning that it is done through several development phases. Each phase continues and refines what’s done in the previous phase. Commonly known development phases in SDLC are:

• Planning. It is the process of understanding why the system should be built and defining its requirements. It also includes feasibility study from several different perspectives, technical, economic, and organization feasibility aspects.
• Analysis. This phase includes activities such as problems identifying and analysis, and even predicting potential problems that may arise in the future regarding the system. The deliverables / products of this phase will drive how the system will be built and guide the developers’ works.
• Design. System analysis leads to design decision, which exactly determines how the system operates in terms of process, data, hardware, network infrastructures, user interface, and other important factors in the system environment.
• Implementation. This is probably the most resource-, cost-, and time-consuming phase of all. This is when the system is actually built, tested, and finally installed. It also includes activities such as user training and system maintenance. Some experts like to separate them into different phases Deployment and Maintenance. However the four phases are the most commonly known and accepted steps.

Recognition of Needs

One must know what the problem is before it can be solved. The basis of candidate system is recognition of need for improving the system. The key question is:

What is the problem?

This recognition of need leads to a preliminary survey or an initial investigation of current system to determine whether an alternative system can solve the problem. If the problem is serious enough, management may have an analyst look at it.

The idea for change may originate in the environment or within the firm. Environment-based ideas originate from customers, vendors, government sources etc. When investigated each of these ideas may lead to a problem definition. Idea for change may also come from with in the organization – top management, the user, the analyst. User-originated ideas also prompt initial investigation.

Impetus for System Change

The ideas for change originate in the environment or from within the firm Environment-based ideas originate from customers, vendors, government sources, and the like. For example, new unemployment compensation regulations may make it necessary to change the restructures. Customer complaints about the delivery of orders may prompt an investigation of the delivery schedule, the experience of truck drivers, or the volume of orders to be delivered. When investigated, each of these ideas may lead to a problem definition as a first step in the system life cycle process.

Feasibility Study

Depending on the results of the initial investigation, the survey is expanded to a more detailed feasibility study. As we shall learn, a feasibility study is a test of a system proposal according to its workability impact on the organization, ability to meet user needs, and effective use of resources. It focuses on there major questions:

• What are the user’s demonstrable needs and how does a candidate system meet them?
• What resources are available for given candidate systems? Is the problem worth solving?
• What are the likely impact of the candidate system on the organization? How will it fit within the organization’s master MIS plan?

Analysis

Analysis is a detailed study of the various operations performed by a system and their relationships with in and outside of the system. A key question is: -

What must be done to solve the problem?

During analysis, data are collected from the available files, decision points and transactions handled by the current system. Tools that are used in analysis are data flow diagrams, interviews, on-site observation, and questionnaires. The interview is a commonly used tool in analysis. Training, experience and common sense are required for collection of the information needed to do the analysis. Once the analysis is completed, the analyst understands that what is to be done?

Design
The tern design describes the final system and the process by which it is developed. It also refers to the technical blue print that will be applied in implementing the candidate system. It also includes the construction of programs and program testing. The key question is: -

How should the problem solved?

The first step in designing is to determine How the output is to be produced and in what format?

The second step is input data and master files (database) have to be designed to meet the requirements of the proposed output.
The third step includes a list of programs needed to meet the system’s objectives and complete documentation.

Finally, Details related to justification of the system and the impact of the candidate system on the user and the organization. These details are documented and evaluated by management.

Implementation

The implementation phase is directly concerned with user training, site preparation and file conversion. During the final testing, user acceptance testing is followed by the user training. Conversion usually takes place at about the same time when the user is being trained. Once the program become available and data are ready for testing and the results are OK then the program is run with “live” data. Otherwise, a diagnostic procedure is used to locate and correct errors in the program.

Post-Implementation and Maintenance

After the installation phase is completed and the user or staff is adjusted to the changes create by the candidate system. Evaluation and Maintenance begins. If the new information is inconsistent with the design specifications then changes have to be made. Hardware’s also require periodic maintenance to keep in tune with design specifications.

Changes in organizations requirements or environmental factors also call for system enhancements. This change requires evaluation, program modifications and further testing.