Because many systems analysts once were programmers and now work closely with them, it is worthwhile comparing the primary functions of these two positions. A programmer's job is essentially to translate a procedure from a set of human-language instructions into a machine-readable language. Programmers are usually given the instructions they need to accomplish the translation from the systems manager, the systems analyst, or the end user for whom the work is being performed.
In contrast to programmers, systems analysts attempt to perceive a rational organization in the flow of information, describe it, and propose specific measures that programmers, users, and managers can take to improve it. System analysts investigate and solve problems creatively. They are frequently responsible for project design, budgeting, and feasibility studies on problems that are less well-defined than programming assignments.
Another position within the data processing-systems analysis area is that of systems designer. Systems designers develop software for systems programmers. Systems software is any program that manages the computer rather than produces directly useful information for the user's business. The software is used to store, retrieve, or manipulate data so as to provide useful information for users. Designers answer questions about which systems analysts know enough to ask but lack the technical knowledge or time to answer themselves. For example, a systems analyst would know whether a computer could perform a certain task or run a certain kind of program, while the systems designer would know exactly how it would run and would be in charge of assembling and testing the software components.
One other specialization in this area is operations research, which is involved in the analysis of production processes. While systems analysts suggest ways to make information systems more efficient, operations researchers suggest ways to make production systems more efficient. Operations researchers study how people, machines, and physical objects move, consume energy and raw materials, produce products, stock them, and make them available for selling at the most advantageous price. There is potential for overlap between systems analysis and operations research work, as operations often include several information systems in addition to production processes. An operations project may therefore employ several systems analysts and operations researchers.
Responsibilities And Activities
As a systems analyst, you would usually work simultaneously on several projects that are likely to be at different stages. Meetings, analysis, interviews, and writing occur as part of your daily work. Many systems analysts work 9:00-to-5:00, although some start early and some go home late. All have periods of exceptional challenge and stress throughout the year-particularly with respect to implementing online operating systems.
Because you may be involved in several projects at one time, your attention may well be pulled in many directions. You may find telephone messages from users or managers when you arrive at the office. Mornings commonly include setting up appointments and interviews with users, analyzing of system specifications, and meeting with managers or users.
You will spend a lot of time with users during a project, especially in the preliminary information-gathering stage and during system implementation. Early interaction is especially important here. If incorrect decisions are made, and systems are then designed around them, later revision can be expensive. When users' questions require an involved explanation or discussion, it is a good idea for you to meet face-to-face in the user's office so as to foster the user's confidence in you and promote his or her involvement in the project. The user must believe that you are there to help find a solution that is best for the user's area, not to impose your preconceived ideas. The level of understanding between you and the user bears directly on your ability to enhance the user's productivity.
To determine a potential user's needs, you will need to collect background data. Often a user discussion group is formed; data is then collected through interviews, study of documentation, and personal observation.
Interviewing is often the forum in which analysts and users first meet. It is important for both groups of professionals to communicate their needs openly, especially in initial interviews. Analysts often interview a variety of users. For example, a systems analyst in a brokerage house would interview users in a variety of roles: line manager, broker, securities analyst, and corporate officer. A user group might include a representative from each functional area which will use the system.
The second information source of systems analysts is documentation. Documentation is a common body of knowledge and terms that employees and managers use to communicate the principles of their business and their daily tasks. However, documentation has one weakness as a resource for systems analysis: While it shows most of the rules that users are supposed to follow, it does not necessarily show the rules they do follow. Discrepancy between documented and accepted operating procedures could indicate poor communication between upper management and other personnel. Or it may show that experienced employees know when it is expedient to ignore rules in order to get the job done. Sometimes managers break rules to compete for the firm's resources or expedite their projects. The analyst is in a position to discover many who bend the rules, and while investigating should be aware of the potentially sensitive nature of the investigation.
The systems analyst must consider company regulations in light of the actual environment in which people work. Many people resist following rules; some managers resist enforcing them. Many people have constructive ideas that managers have yet to hear or adopt. All of these conditions contribute to the inconclusiveness of systems documentation.
Observation is one way to collect information that has not yet been documented. Using direct observation, you can see the impact of individual differences on the way people work. For example, some people work slowly because they are new and are being careful. Others work quickly because they are competent enough to do so. Others are careless, working quickly but making errors, and requiring double-checking by another person or machine. Such differences and idiosyncrasies have to be kept in mind when designing systems for users.
Observation is also a reasonable way to verify the information you receive through interviews, meetings, and documentation. You should always verify information from an independent source before you use it. Verification is important because individuals can be misinformed, misinterpret things, or be biased. An enthusiastic worker may exaggerate requirements, informational needs, and so forth. An insecure or bored worker may omit information. A dis-satisfied worker may even subvert the process of systems analysis by withholding or distorting data.
When analysts finally have the background they deem important, they typically recommend that the user committee clearly define the needs of the user population. A committee of three or four users tends to be large enough to provide a representative variety of opinions, and small enough to facilitate productive discussions. Because the user group will be influential in the design of the system, it is important that its members approach these discussions with the whole firm's best interests in mind, not only their own department's interests.
As a systems analyst you may use your free time to conduct business on a more informal level. For example, you may use lunch time to meet with users, perhaps to determine the next step of a project. You can use this time to seek out inside information that will help you make the project schedule more realistic, or to learn which documentation to study and which to ignore. Spending lunch with other analysts facilitates comparing ideas on projects, discussing new projects, and exchanging referrals to help users and managers. Of course, job notes are also compared: Who is hiring, who is looking for work, what other projects are up coming.
You would typically devote the afternoon to further data collection, informal user training and consultation, and following up a morning discussion of user requirements for a new system. For example, a morning in which a meeting resulted in revision of user requirements would typically be followed by an afternoon in further consultation with other users, fellow analysts, or your manager.
You must consider the feasibility of any new system model along technical, economic, and personnel lines. Technical questions include: What does a particular system do? What tasks would be done well by machine, what by people? Can a computer reliably perform the work involved? What configuration would make an operation practical, what optimal? In what ways should users gain access to the system? What future applications are likely to grow from this system and others of equal importance to the company? Your training will suggest answers to many of these questions; others will require consultation with other analysts and programmers.
An economic analysis must answer these basic questions: What is the break-even point, where the return equals the cost of designing and implementing the proposed system? What is the net present value of this project? How much time will it take for the system to pay for itself?
You must also assess whether the organization has enough personnel to staff the new system and benefit from it, or whether the new system will allow management to reduce staff and reorganize its operations. The latter possibility is attractive to upper managers, but often threatening to employees and middle managers. For example, a new information system might allow a company to reduce its personnel costs by 40 percent and raise productivity by 200 percent.
Finally, you must consider what retraining of personnel will be needed in order to be able to use a new system, whether upper management will adequately support training needs, and how long it will take before personnel will be productive with the system. You may be able to answer these questions by finding out about other firms that have installed similar systems. Since other firms may keep this information from public view, you may have to become somewhat of a detective as well as analyst and project leader.
A feasibility study is the final product of your analysis. This study proposes alternatives to the current system to meet users' needs. It evaluates the technical, economic, and organizational costs and benefits of each alternative, and then proposes the best one to management.
Note that routine administrative-clerical tasks take up more time than analytical-technical tasks. Management activities take about as much time as analytical-technical activities, and marketing activities are a major activity. In a service business, nearly every contact with a supplier, customer, or user involves marketing and selling yourself and your service.
Performance Evaluation
Schedules and formats of performance evaluations vary by organization. A brief, weekly discussion of goals and a semiannual or annual written report on performance are typical. Monthly progress meetings or reports share useful information, such as new developments that may affect a project, staff changes in personnel, and unexpected delays.
Systems analysts are evaluated in several areas of performance, including
- quality, timeliness, and ease of maintenance of deliverables (A deliverable item is anything that you agree to produce and turn over to the systems manager. Two examples are a description of user requirements and a feasibility study of a new information system. The systems manager judges how useful this work is to users.)
- project management skills
- success in communicating with and motivating users' programmers and technicians
- willingness to comply with company standards and to suggest improvements
As an analyst, your project management skills will be essential in turning in deliverables on schedule and within budget. This involves planning, organizing, and conducting business effectively.
Systems managers look for evidence that systems analysts can motivate users to participate in systems development. If users are aware of the potential of a new system to make their job easier, they are more likely to be enthusiastic about planning it with the analyst. Therefore you must be able to communicate technical concepts to non-technicians. Analysts need to get users to see that the analysis phase is an opportunity to shape the future of the firm.
As already mentioned, an important part of your work as a systems analyst is in the documentation, accounting, and control of systems. You must describe the information flow of a system in a format and vocabulary that is both understandable and conformable to management's standards. You must communicate in clear, technical writing, and be able to recognize and dispel others' confusion regarding systems on which they work and that you are trying to improve.
A systems analyst's objective in assembling programmers and other technicians is to foster team spirit. During a project assignment, the group members will learn more quickly and produce better work if they discuss each other's work. Like the systems analyst, no programmer can be expected to know or remember everything about a data processing system or item of hardware or software. Pooling the talent makes the best use of that talent for the broadest group of programmers. Cooperation among programmers will ultimately put proposals into action. Your ability to manage their work is one of the most important skills in delivering a system.
Finally, the willingness to accept and at the same time suggest improvements in company standards is important to systems managers. A systems manager in charge of five analysts does not have time to constantly check each one's activity. The manager needs people who can be trusted to follow instructions and use methods that management approves. At the same time the firm needs the flexibility to change systems and processes when necessary, as when faced with new technology and economic trends. The analyst who works within company standards while being able to suggest constructive improvements takes on a partnership with the manager. Managers consider such an analyst a resource worth nurturing, particularly if he or she proposes changes of standards with creativity, objectivity, and neutrality.
