As a result of decisions made in the systems survey, we know if and how to proceed with systems development. If we have decided to proceed, we perform the second step in systems development, structured systems analysis. We must perform the procedures in this step well to have any chance of achieving the first of our systems development objectives—to develop systems that meet user needs—because it is during systems analysis that we determine those needs. Without a well-understood and documented target (i.e., user requirements) we cannot hope to have a successful development process.
At one point or other in your professional career, you may be asked to take on both roles in this process. You will be a system user or business process owner articulating your needs or you will be a member of the development team that must determine and document those needs. Neither process is easy. The tools and techniques described in this chapter should help in the documentation of user requirements.
Management (or the IT steering committee) bases the decision about whether and how to proceed on information gathered in the systems survey and on other information. Management might decide to reduce the suggested analysis scope in order to reduce short-term development costs. Or management might cancel, postpone, or modify future systems work because a major modification is preferred to the maintenance approach being suggested (or vice versa).
In the case of reengineering and enterprise systems, management faces some challenging decisions. For example, an organization might decide early in the development process (e.g., during the systems survey) that the installation of an enterprise system would solve its Information Systems problems. To ensure a successful installation of an enterprise system, organizations must reengineer their business processes to make them compatible with the enterprise system. Management must decide how much analysis to undertake before and after purchasing the system and how much to change their business practices (versus attempting to change the enterprise system).
|
Figure 6.2 depicts the alternatives considered by one company, Boston Scientific Corporation, before its management decided to embark on a worldwide implementation of a leading enterprise system, SAP R/3. In addition to the alternative chosen—to standardize on SAP R/3 worldwide—Boston Scientific considered: |
- Interfaces: build interfaces among the many systems that existed at their worldwide affiliates.
- Standardize on one: implement at all of the worldwide affiliates the set of applications in use at one of those affiliates.
- Build it: build their own system by writing the necessary applications software.
- Best of breed: select the best system available for each application or business process.
- EBS (Enterprise Business Solution): Select an integrated software package (in their case, SAP R/3) to provide the processing functionality for all applications. Implement that package worldwide.
The development options in Figure 6.2 summarize the typical choices from which organizations may choose. In the systems survey we begin the get some sense of these alternatives and which one looks best at the time. In the analysis step of systems development, we must examine each alternative and gather enough information to make a choice to proceed with development along one of the alternative paths.
Structured systems analysis is a set of procedures conducted to generate the specifications for a new (or modified) Information System or subsystem. Refer to Figure 6.1 to see systems analysis’ place in the SDLC (second), its inputs (approved feasibility document and miscellaneous environmental information) and its outputs (physical requirements and logical specification).
- 2432 reads
