Current Systems Analysis

Contents 1 Applications 2 Procedures 3 Instructions 4 Examples

A set of techniques used to analyze current systems and assess the degree of support provided to the set of business activities being reengineered. Data, procedures, and problems can be analyzed. Assessments of user and technical satisfaction can also be performed.

Applications

• To test for completeness of the logical data model by comparison with the implied entity relationship diagram from an analysis of existing data structures.
• To uncover business rules and procedures which must be included in the process model.
• To confirm compatibility with proposed application packages which must interface with other feeder systems.
• To identify any shortcomings and problems with current systems.
• To assess the usefulness, usability, and overall user satisfaction with the systems.
• To identify transition requirements and/or additional analysis activities to position for the future.

Procedures

1. Identify systems and databases.
2. Analyze the data.
3. Analyze the procedures.
4. Assess usability, and usefulness of current systems.
5. Compare models and determine appropriate actions.

Instructions

For any application of this set of techniques, it is necessary to confirm the scope of the analysis and the level of detail required. If an inventory of system components and/or a set of source material has not been assembled, perform a systems component mapping. This is a vital first step in applying these techniques (see Systems Component Mapping). In addition to component systems, identify any other "systems" used to support the set of activities being reengineered. These manual systems tend to capture key business data which also needs to be analyzed. Sometimes these manual systems are uncovered during interviews (see Structured Interviewing).

In addition, survey the information technology organization to identify:

• systems that support the area of analysis
• user computing systems made available to business users
• systems developed by business users

Also, gather additional information for automated systems such as:

• user documentation
• maintenance documentation
• database schemas
• data dictionaries

Use data analysis techniques to create an "implied entity relationship diagram" (see Entity Relationship Modeling). Begin by selecting a sample of layouts which cover the full range of data used by systems, plus all heavily used screens and reports. Before the implied entity relationship diagram (ERD) can be created, it is necessary to create a data analysis diagram. The data analysis diagram (DAD) is derived from these "user views." For each user view, create a DAD (see figure 1 which follows). When all DADs have been compiled, perform canonical synthesis on the diagrams. This will help create the implied entity relationship diagram (see figure 2). The implied ERDs will be compared with the logical business model for completeness checking.

After the data has been analyzed, it is often useful to analyze current procedures. The purpose of analyzing current procedures is to document the structure and dependencies of procedures in current systems in a way that facilitates ready comparison with the activity models (see Process Modeling). Other reasons include:

• to identify shortcomings and problems with existing business systems and procedures
• to put current procedural descriptions into a form that facilitates transition planning
• to put current systems procedure descriptions in a form which will make for ready comparison with the process model to check completeness

Analyze activities and produce a procedure decomposition diagram (See Decomposition Diagramming). For each business system studied, an indented procedure list (see figure 3) that shows the system, subsystems, and procedures is built. Procedures should not be related to specific tools. Political, historical, or other procedural quirks should be omitted. Detail should be retained for transition analysis. Problems identified should be analyzed for root causes, and actions should be identified to steer subsequent analysis and/or transition planning (see Root Cause Analysis).

Create a data flow diagram of the current system. Data flow diagrams show how the procedures on a procedure decomposition list interact. Data flow diagrams not only show the basic information dependencies between procedures, but also how the dependencies occur. Show all procedures on the procedure list

Perform a usability and usefulness assessment of the current systems by measuring satisfaction from a business or user perspective and a technical perspective. For each system, determine:

• How well does the system meet current and future business requirements?
• How reliable is it in operation?
• How responsive and timely is it?
• How easy is it to use?
• How easy is it to modify/enhance (maintain)?
• How easy is it to operate?
• How easy is it to support?

In order to illustrate the assessments, prepare a systems satisfaction chart. The chart is completed by scoring each business system from 0 to 100 for usefulness and plotting the result against the vertical axis of the chart, and then by scoring from 0 to 100 for usability and plotting the result against the horizontal axis of the chart. The point where the plotted scores for a business system intersect is the system rating in terms of overall satisfaction (see figure 4).

The charting is not intended to be precise. The quarter of the charts in which the plotting appears indicates the business systems that are candidates for replacement. Only the systems in the bottom-left quarter of the chart are considered to be satisfactory in terms of both usefulness and usability. The other systems are not satisfactory from either one or both viewpoints, and need to be reviewed. The analysis can be applied to show either the overall system satisfaction or the satisfaction for each major activity or value stream.

Compare the implied entity relationship diagrams and the procedure list (if required) to the logical business models (information architecture) being developed to support the reengineering. Note any differences, and adjust models as required. Identify transition planning issues (see Transition Planning). Comparisons can also be made to models describing application packages. Identify options for transitioning to the future environment.

Examples