One of the criticisms commonly made about Systems Engineers
is that they are not knowledgeable in the area under study.
This is often a legitimate criticism. It can be overcome by
the study of the current system and at the same time, provide
management with the benefit of objectivity. The goal of Systems
Engineering is not only to understand the current systems in
detail (both good points and shortcomings), but the engineer
should also have a detail knowledge of the operating units and
their business contributions to the company. This knowledge, as
an objective, should be so complete that Systems Engineering
could manage the areas under study.
Systems Engineering must constantly be reminded to
define only what exists NOW, not what will be in the future.
Problems, errors and weaknesses in the existing system will
inevitably be encountered during this activity. But they should
only be noted and not corrected at this time. If this is not
heeded, the project will take an inordinate amount of time to
complete and waste money needlessly.
Prior to performing the current system analysis, Systems
Engineering must clearly understand the level of detail
required. ISEM recommends a Phase 3 level of detail (down to
the procedural level of the system hierarchy). However,
operational needs may require documentation down to the program
level. Regardless, the Systems Engineer must be fully aware of
the level of detail required.
ISEM recommends the Phase 3 level of detail because it will
identify all of the major processing components, the areas
responsible for performing the procedures, and the major files,
both computer and manual. It is unlikely that working files
between programs will unveil anything salvageable for use in a
new system. A Phase 3 level of detail will define:
- Sub-Systems
- Administrative and Computer Procedures
- Inputs and Outputs
- Manual files
- Primary computer files
- Input transaction files
- Output data files
- Input transaction records
- Print maps and screen panels
- Primary and generated data
Of these resources, perhaps the data resources (files,
records and data elements) are the most important since they may
be re-used in a new system. It is important that the Systems
Engineer be concise and to the point. Rambling narratives will
not necessarily be required (beware of the "War and Peace"
syndrome).
The following should be uncovered as a result of studying
current systems:
- The information produced by the system.
- The data used to produce the information.
- The processing logic used to produce the information.
Current systems analysis requires the participation of
several people:
- User Management can provide insight into the systems and
objects they use in their normal activities. This includes
DP Operations.
- Data Engineering can provide assistance in the identification
of the objects associated with the system.
- Data Base Administration can locate physical files used by
the system.
Current system documentation is available through:
- The information resources as defined in the IRM.
- Work sampling - by collecting printed copies of reports,
screens, messages, reference cards, forms, templates,
user developed instructions, file layouts, control
language statements (JCL), help text, computer run books,
computer timetables, source code, etc.
- Interviewing User Management and DP Operations.
Departmental management and clerical personnel should
both be interviewed. Management's view of the existing
system may differ significantly from how it is actually
performed by the staff. A key secretary or clerk knows
the existing system perhaps better than anyone.
Regardless of how documentation is obtained, it is the
System Engineer's responsibility to VALIDATE WHAT IS
ACTUALLY HAPPENING, not how it should be happening.
Discrepancies should be noted for comment later under the
Current System Analysis.
Before proceeding with interviews, Systems Engineering
prepares an interview outline and schedule. Each department
manager is then informed of the schedule and format to be
followed. In this way, each department manager is able to plan
the department's activities and schedule personnel for the
interviews. Systems Engineering follows this plan and informs
the managers of any changes.
During interviewing, Systems Engineering limits discussion
to the existing system, not to new requirements as developed
during Activity C. Avoid discussions of personalities and
company politics. Systems Engineering must lead and assist each
individual to describe their activities as correctly and
thoroughly as possible. In cases where a particular activity is
performed only once a year, or even once a quarter, the
individual may have a tendency to forget the details. In this
event, each step is carefully covered to assure correct
documentation.
ISEM related flowcharts are useful for documenting the
existing system. The System Flowchart is used to differentiate
the various business processes (sub-systems) based on timing;
the Sub-System Flowchart reflects the processing flow and data
flow of each sub-system, and; the Computer Procedure Flowchart
expresses program dependencies. When completed, the flowcharts
are reviewed for completeness with pertinent users. Any
omissions or errors identified on the flowcharts should be
corrected immediately.
Other items that can provide assistance during this
activity include:
- "PRIDE" Worksheets are used to collect and organize notes,
all of which can then be entered in the IRM for analysis.
- The ISEM rule that a sub-system can have no more than
one computer procedure is very helpful for partitioning
sub-systems.
After studying the current system, Systems Engineering
prepares a formal Current System Analysis which highlights the
strengths and weaknesses of the current system. The Current
System Analysis and supporting documentation is then reviewed
with User Management for accuracy and completeness. This review
provides the managers with a better understanding of the systems
in their departments. Systems Engineering may find that after
these reviews are completed, the current system will run more
efficiently as a result of the managers identifying problem
areas and making adjustments. It is even possible that a new
system will not be required and that simple enhancements to the
existing system will correct problems better than a complete
redesign of the system.