Many companies first introduced computer systems on the lowest level of the organization. This is where the immediate benefits to computerization are most observable and cost-effective. Businesses often take this approach to systems development by going out and acquiring, for example, COTS software for accounting, a different package for production scheduling, and another one for marketing.
When in-house programming is done with a bottom-up approach, it is difficult to interface the subsystems so that they perform smoothly as a system. Interface bugs are enormously costly to correct, and many of them are not uncovered until programming is complete, when analysts are trying to meet a deadline in putting the system together. At this juncture, there is little time, budget, or user patience for the debugging of delicate interfaces that have been ignored.
Although each small subsystem appears to get the working software what it wants, when the overall system is considered, there are severe limitations to taking a bottom-up approach. One is that there is a duplication of effort in purchasing software and even in entering data. Another is that worthless data are entered into the system. A third, and perhaps the most serious drawback of the bottom-up approach, is that, while pockets of users’ needs may have been met, overall organizational objectives are not considered and hence cannot be met.
Top-down design allows the systems analyst to ascertain overall organizational objectives first, as well as to ascertain how they are best met in an overall system. Then the analyst divides that system into subsystems and their requirements.
Top-down design is compatible with the general systems thinking that was discussed in Chapter “Understanding and Modeling Organizational Systems“. When systems analysts employ a top-down approach, they are thinking about the interrelationships and interdependencies of subsystems as they fit into the existing organization.
The top-down approach also provides desirable emphasis on synergy or the interfaces that systems and their subsystems require, which is lacking in the bottom-up approach. It helps to answer the question of how teams must work together to accomplish their goals.
The advantages of using a top-down approach to systems design include avoiding the chaos of attempting to design a system all at once. As we have seen, planning and implementing management information systems is incredibly complex. Attempting to get all subsystems in place and running at once is agreeing to fail.
A second advantage of taking a top-down approach to design is that it enables separate systems analysis teams to work in parallel on different but necessary subsystems, which can save a great deal of time. The use of teams for subsystems design is particularly well suited to a total quality assurance approach.
A third advantage is that a top-down approach avoids a major problem associated with a bottom-up approach: it prevents systems analysts from getting so mired in detail that they lose sight of what the system is supposed to do.
Total quality management and the top-down approach to design can go hand-in-hand. The top-down approach provides the systems group with a ready-made division of users into task forces (specialized teams of users) for subsystems. Task forces set up in this manner can then serve a dual function as quality circles for the management information system. The necessary structure for quality assurance is then in place, as is proper motivation for getting the subsystem to accomplish the departmental goals that are important to the users involved.
