A crash course in system analysis (part 1) 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

A crash course in system analysis (part 1)



 

INTRODUCTION

In today’s hectic world, we tend to look for an immediate “solution.” Rapid Application Development (RAD) and Computer Assisted Systems Engineering (CASE) tools certainly play an important role in systems analysis, but impatient users and bottom line pressures often push formal systems analysis techniques aside. However, we can not, for the sake of an "immediate" solution, ignore important facets of systems analysis, such as quality and impact on other processes and areas.

Systems analysis is defined as looking at a process with an eye towards understanding and improvement. This requires interviewing users and management to gather insight of the process and discern how it fits into the organization's mission and operational needs. After this comes re-engineering and change. And all the while customers want to be involved with alternatives and decisions.

One definition of quality is "meeting" or "exceeding" user expectations. In order for a systems analysis to be successful, it must therefore involve the user. This article describes the use of "checklist" questioning techniques during interviews to create opportunity for re-engineering, as well as endorses user and management solutions. It recognizes that a solution is often easily offered simply by asking, “what do you recommend.” It can be an “immediate solution.”

THE PROBLEM

A lack of a systems approach by staff - such as that of a broad perspective or understanding of the user need - is a major concern of many managers today. Staff may not always comprehend the unique area of concern, and the environment in which the process resides. A “put out the fire” solution may offer an immediate improvement, however, it does not consider the overall strategy of the department, division or organization. Staff, under pressure for a "solution" within a timeline and budget can emerge from a trouble-shooting effort with recommendations that do not address what is causing the “fire.”

Why, What, Where, Who, When and How

There can be a quick and effective questioning tool applied in several environments --specifically in an information system process. It consists of a series of six age-old questions. When interviewing and trying to understand an existing process or problem, the following questions should be asked -- regardless of the order. Using a checklist approach, one can elicit comments and insights from users simply by asking:

Why? Why do we need this application/process/procedure? Why do we need this method? Why is this a problem?

What? What need does this application/step satisfy?

Where? Where is this application utilized?

Who? Who uses this application?

When? When is it done? When does it have to be done?

How? How is it accomplished?

Getting the answers to the why, what, where, who, when and how

(WWWWWH or 5WH) -- and documenting the answers with flowcharts and narratives clarifies the process being studied. Each question presents a different focus on the process because it requires the responder to further clarify the system in another way.

 

Eliminate, Combine, Change and Simplify

Once a process is understood and defined, another series of questions can assist the analyst - often in conjunction with the person interviewed - in determining if the system and process steps are really necessary in their current state. This is done by looking at each component of the narrative and flowchart with the 5WH questions and asking:

Eliminate Can this node, process or need be eliminated?

Change Can this node, process or need be changed?

Combine Can this node, process or need be combined?

Simplify Can this node, process or need be simplified?

 

What do you Recommend?

Asking for a recommendation turns out to be a very powerful and insightful question. Often the answers are in front of us -- just ask those closest to the process. For some strange reason systems analysts frequently believe "they" are expected to solve the problem. This conception is far from the truth. They are expected to find a solution. By asking users and those ultimately responsible for the process for their thoughts and recommendations, we are able to compile a list of alternatives. They have now been included in the solution process by having their ideas solicited and considered. Therefore, if the users’ ideas are accepted, the user has accountability.

2. Make a written translation of the text:



Поделиться:


Последнее изменение этой страницы: 2016-12-30; просмотров: 290; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.135.205.146 (0.003 с.)