National Academies Press: OpenBook
« Previous: SYSTEM ACQUISITION
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 17
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 18
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 19
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 20
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 21
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 22
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 23
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 24
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 25
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 26
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 27
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 28
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 29
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 30
Suggested Citation:"TRANSITION PLANNING." National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, DC: The National Academies Press. doi: 10.17226/10442.
×
Page 31

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

CHAPTER IV Transition Planning TtiF SIGNIFICANCE OF TRANSITION In its previous report, the panel expressed its concern, which is shared with the Social Security Administration, about the planning for the transition from the present process to the future one. The panel observed: The transitional stage from the existing SSA Process to the future one should be given high priority--certainly equivalent to the priority that is being given to the design of the future process. The Social Security Administration responded by suggesting that transition planning be central to this second review and then by work- ing with members of the panel in a series of ten one-day meetings devoted to analysis of transition problems. The panel has arrived at its recommendations largely through a cooperative effort with the SSA staff, and to a large extent the recommendations have already been adopted or incorporated into the SSA's planning. Even so, a strong follow-up effort is considered necessary to determine the difficulty of reorganizing and unifying the data base and of adapting or rewriting the application programs. An instantaneous "cut-over" from the present process to the future one is not deemed possible. The panel therefore considers that the objectives of a smooth transition must permeate the planning and design of the future process. Some otherwise desirable future system designs may have to be rejected because they are incompatible with an orderly transition. The future process must be reachable from the present one without loss of continuity. PROBLEMS OF TRANS ITION The transition to the SSA's future process is likely to be difficult because there is a need for continuity of service even as significant changes take place in the process itself. Difficulties will arise because: . The SSA process must not be interrupted for any period, but must continue to function throughout the transition. 17

18 . . The continuity of the content of the data, on which almost all the SSA work relies, must be preserved and available for use, even while new data structures and new storage media are being introduced e The communications capability of the future pEOC~SS~- to deliver messages and data in seconds, replacing the heavy present dependence on mail between local offices (where the SSA meets its clients) and the program service centers and central complex (where it stores its data)--will allow transactions to be completed during a client's single visit or telephone call, which wall in turn generate basic changes in the SSA's work patterns and procedures. A large number of SSA people will require training to carry out these new or revised work patterns and procedures. Task know-how and technical know-how are both essential to transition planning. In order to plan and design the future process it is necessary to fully understand the present process--not just its objectives. It is necessary, also, to bring into the transition planning process the technical expertise of the development contractor or contractors. Indeed, the SSA's task know-how and the contractor's technical know-how will have to be brought into close interaction. That will not be easy to achieve because, in accordance with the principles of OMB Circular A-109, several contractors may be participat- ing in an active competition at the stage when transition planning will have to be made firm. FRAMEWORK FOR CONSIDERATION OF TRANSITION PROBLEMS A simple framework in which to discuss the transition problems is illustrated in Figure 1. The framework is constructed in three dimensions. Along one axis are represented the many district offices, teleservice centers, program service centers, and the central computer complex. Along the vertical axis are the various SSA services, such as enumeration, earnings, claims, and payments. Along the third axis are the several subsystems that support the work of the SSA--subsystems such as the terminals and associated minicomputers in the local offices, the telecommunications systems, the data base, and the processing systems in the central complex and regional centers. One approach to transition is to bring up each of the services (identified along the vertical axis) one at a time in all local offices and other offices of SSA involved in providing a particular service. Only after each service is mastered would another service be introduced. This approach has been referred to as the "horizontal slice" approach because each step in the transition is represented by a horizontal slice of the rectangular solid in Figure 1. Whenever some of the supporting subsystems are not essential to the provision of a particular

19 CHANGES ~PPEALs CO ~ ~ Swears CO CLAIMS 48NI~G5 BENT riot Vertical Slice Vertical Slice Based on Based on Subsystems Locations c; = COCA ~5 `10~5 1 ~1 Horizontal . Slice . at' 0~ rid ,, A _ NG oryx ark- ~ l I I a,. LOCATIONS FIGURE 1 Framework for Transition Planning SUBSYSTEMS

20 service, the "boxes" corresponding to the non-essential subsystems may be visualized as empty. Another general approach to transition is to bring up in a single local office (or in a small group of local offices) all the services rendered by SSA, to master the whole process in that office (or offices), and then to replicate the process in additional local offices until all of the 1,300 or so local offices are operating within the new process. This approach is referred to as the "vertical slice approach based on locations," because each vertical slice of Figure 1 (representing the office locations) is dealt with in succession. The imagery is not entirely valid because some of the functions of the program service centers and the central complex would also have to be activated in order to activate services in a local office. The essential idea of the vertical approach is more solid than mere imagery, however. Indeed, the panel considers it important to develop, "debug," and demonstrate in a realistic operational setting the complete system before introducing it throughout the SSA. A few local offices would require only a small segment of the overall data base, and for demonstrational and "debugging" purposes simulating some of the supporting operations at central or regional centers might suffice. The three dimensions of Figure l suggest that there is a third way of slicing the figure--by cutting a vertical slice across the third axis. In this approach, the subsystems required to support SSA services would be put into operation successively. One way would be to start with the telecommunications system, introducing a packet-switched network to provide a rapid, economical data and message service among all the geographically distributed parts of the SSA. This might be followed by conversion of the data base in support of the "whole-person" concept, providing on-line, interactive retrieval of information. Other sub- systems would follow. This approach may be termed the "vertical slice approach based on subsystems." A number of other options are also open. There are intermediate or hybrid approaches. The task of transition planning is, essentially, to select from an array of alternatives, a single, definite sequence in which the services of the SSA future process and the subsystems required to support them will be introduced into the many SSA locations. The decision about the transition sequence is similar to the decision about the nature of the demonstrations that contractors will be asked to perform in the competitive demonstration phase of acquisition. The nature of the demonstration is important because it could be used to test approaches to the first step in the transition process, and could provide criteria for the evaluation of transition plans. For the horizontal slice approach based on services the competitive run-off required by Circular A-109 is estimated to require about 18 months. Members of the panel who have studied transition problems most intensively have come to the conclusion that the same amount of time would suffice for a run-off based on a vertical slice approach. There is no strong assurance, however, that the full gamut of application programs could be completed in that time. A set of "most frequently used" application programs might have to suffice.

21 ALTERNATIVE APPROACHES TO TRANSITION Horizontal Slice Approach Based on Services An orderly way to proceed toward the selection of a transition sequence is to examine a number of plausible alternative sequences and a number of evaluation criteria. This section briefly describes the alternative sequences that have been examined. A later section lists evaluation criteria. At the beginning of the panel's study of transition, the dominant approach was the horizontal slice--that is, the transition that starts with a single SSA service function, the primary candidate being enumeration, which is the assignment and accounting for social security numbers (SSN's). The enumeration module is fairly simple and under- standable. The future process will be keyed, as nearly everything in the present process is keyed, to the SSN. The enumeration module would be activated as a single horizontal slice out of the block of services, locations, and subsystems (Figure 1~. Following the enumeration module, it would be reasonable to bring up the earnings module, then the claims module, and afterward the post-entitlement modules. As each module is introduced throughout the SSA, users would learn to operate with it, and it would reach a stable level of operation before the next module is introduced. In such an approach, however, trouble-shooting expertise would be geographically dispersed; furthermore, the interaction between modules would not be demonstrated in an operational setting until late in the transition process. Activation of the enumeration module in the future process would require the introduction of a communication capability or the augmenta- tion of the present capability, but--since enumeration is not at all data intensive--it would not require a communication system capable of handling a high volume of traffic, nor perhaps one highly developed with respect to security and privacy. Indeed, services leased from a value- added or primary common carrier might well suffice. The initial require- ment for terminals in the various SSA locations would be modest. Only a small part of the data base would have to be converted to future process form. The central (or regional) processing facilities required by the enumeration module would also be relatively small. As the second, third, and further service modules were brought up, the requirements for communication, terminals, data base, and processing would increase progressively, and there would be an opportunity to master each module throughout the SSA as a stable basis for taking the next step. Vertical Slice Approach Based on Locations After many discussions and much analysis, the panel considers the vertical slice approach based on locations to be strongly competitive with the horizontal slice approach. The focus of the vertical slice approach is the local office--the main point of contact between the SSA and its clients. The vertical slice approach based on locations involves bringing up the entire future process, or at least a very substantial part of it, first in a single local office or a small group of such

22 offices. Only after it has been -successfully demonstrated there, would the future process be extended progressively throughout the SSA. At first, the panel found this approach difficult to accept. The overall process had been viewed as being extremely large and enormously complex in the sense that individual processes are strongly intertwined, contain many interfaces, and share many data elements. However, experience with transition from an old process to a new one in other situations has shown that--to the surprise of many--a system that is first viewed as very large and complex may turn out to be very large but fairly straightforward. The key consideration is complexity, not size. The panel is confident that the technology has advanced to a point where a large data base, even one as large as the SSA data base, is manageable if properly organized. The panel's analysis of the problem has increased its confidence that it would be feasible to bring up, in the initial step of develop- ment and transition, a fairly comprehensive system--one capable of handling all the main social security services for a single local office or a few local offices. If that is done successfully then it would surely be a straightforward (though extensive) undertaking to replicate the system horizontally across the whole array of SSA locations. There- fore, the panel has become increasingly confident of the feasibility of the vertical slice approach based on locations. Vertical Slice Approach Based on Subsystems The approach based on bringing up one subsystem at a time--for example, first the telecommunications network and then the data base-- has not been examined as thoroughly as the other approaches. It appears possible, for example, to introduce a modern telecommunications service that would accustom SSA personnel to fast-response message and data transfers without actually developing a new, unique telecommunications network. The SSA could simply subscribe to an available commerical network and, whenever it is necessary to protect confidentiality, it could use end-to-end encryption for message and data content. A modern telecommunications service would speed up access to records of all kinds, paper as well as electronic. Achieving such a service would require additional terminals over and above those now associated with the SSA Data Acquisition and Response System (SSADARS), the telecommunications and processing system now in use. A crucial step in this subsystem-by-subsystem approach to transition --and indeed in all the approaches--is the conversion of the data base. At present there is no single, integrated SSA data base. Instead, there are several separate ones, each supporting its own particular processing activity. It seems not only possible but essential to convert the separate data bases into a single, integrated one, capable of supporting the several SSA services effectively, efficiently, and in such a way that all the pending business with a client can be conducted in a single session. Obviously, conversion/integration of the data base will be a large and very demanding undertaking, requiring special facilities, including, very probably, a computer system with software designed

23 specifically for the purpose of analyzing, reconciling, and reorganizing data with diverse formats. This problem is examined more fully below. Given a telecommunications network, an initial set of terminals, and an integrated data base, the next step in a vertical slice approach based on subsystems is to update the application programs and the work procedures into which the application programs feed information. That the application programs operate, for the most part, with records stored serially on magnetic tapes means either that the old data base on magnetic tape and the new (to a large extent on-line) data base would have to be used concurrently over a period of time, or that data from the new data base would have to be converted to the forms that the old application programs require. The upgrading of work procedures and the application programs would be left to the end, and would proceed as rapidly or as slowly as the amenability of the situation and tolerance for change would permit. Hybrid Approaches It seems unlikely that any one of the three approaches will turn out to be applicable in the idealized form that has been described here. There are many possible departures from these idealized forms, and each of them in some sense constitutes an alternative approach. In the case of the horizontal slice approach based upon services, one of the main criticisms is that the enumeration process is neither typical nor demanding, and that it would be better to start with two, three, or more services in order to provide a more valid test of the capabilities of the competing contractors. Another variation of the horizontal slice approach is to start out in one group of local offices with enumeration, in another group with earnings, and so on, thus moving somewhat diagonally, with a reduced demand for adjustment to change at any one location, and with an opportunity to debug different parts of the new process in different places. One possible variation of the vertical slice approach based on locations would be to implement only the main or the most frequently used parts of the new process initially, so that the experience of adjustment could be less traumatic. Yet such a variation is essentially a withdrawal from the principle of testing system integration by bringing the overall system into operation at the outset. In the vertical slice approach based upon subsystems, terminals-- and at least the minimal processing associated with terminals--could be introduced into local offices in order to take advantage of a modern communications network. In this approach, beginning the conversion/ integration of the data base need not wait until the communications system and terminals are in place. As a result of such hybridizing, the SSA process could be thoroughly modernized with respect to data organiza- tion and transmission but could still be carried out as it is now and could use existing application programs. This methodology would enable the SSA to effect the transition in work procedures as gradually or rapidly as thought desirable.

24 Should the Application Programs be Revised or Rewritten? To move from the old process with its several separate tape-oriented data bases to the future process where much of the data would be on-line and all of it under the control of an integrated data management system, it will be necessary either to revise the application programs rather fundamentally or to rewrite them from scratch. Which of those alterna- tives should be pursued? The answer depends upon the number, size, complexity, and present condition of the application programs. On the basis of hard-learned experience, software experts dread the revision of programs that are large, complicated, and poorly documented. It is extremely difficult to revise a program without knowing what the writers of the program tried to accomplish. Unfortunately, old-style programming methods left very little trace of what the writers intended, either in the program itself or in its documentation. It is conceivable that the best way to revise most of the SSA application programs is to study the legislation that they are intended to implement and to rewrite the programs de nova. On the other hand, equally hard-bought experience teaches that it is no minor matter to prepare, from scratch, a large system of applica- tion programs, especially if they have to deal with complicated patterns of exceptions and precedents. The creation of software programs directly from legislation is only in its infancy. While interesting research on this subject is being done at the London School of Economics, not enough progress has been made to provide a methodology for turning the social security legislation directly into software. Perhaps some advantage can gained from the technique called "Production Rule Systems," in the field of artificial intelligence, to structure the SSA procedures in terms of conditions that could exist in a particular case, and the actions that should be taken when the conditions exist. It is likely that SSA programs in the future process will be shorter and simpler than those of the present one. The panel has worked with the SSA staff to estimate the level of simplicity/complexity of the SSA process, but it has not been possible to draw firm conclusions. During the past few months, the panel has moved toward adopting the simplicity hypothesis--namely, that individual processes can be self-contained, with few if any interfaces with any others. The subpanel that studied the SSA's transition planning estimates that reprogramming de nova could cut the amount of ''code" (measured in terms of numbers of machine instructions) by 70 to 80 percent. The amount of code that has been generated is currently estimated to be 12 million machine instructions. If this amount of code could be reduced to 1 million machine instructions, based on 100,000 source level statements in a high level language, almost everyone would certainly favor reprogramming from scratch. From the point of view of software development, the fact that there are some 200,000,000 individual accounts in the overall SSA data base poses a challenge, although not an insurmountable one. The records of different clients do not often interact. Indeed, the only significant interactions are limited to the records of the members of the same family, and rarely do more than three or four records have to be examined together. Of course, computer programs are just as capable of dealing

25 successively with 200 million records as with 200. The quantity of data primarily affects the data base, rather than the application programs, and even in the case of the data base, the quantity affects size rather than complexity or intricacy. It is somewhat intimidating to see the many, many pages of client information that fill thick file folders on desks and in racks at the Program Service Centers. After looking at a "worst case" file folder, one can imagine that the corresponding data structure in a computer would probably be a tree or network of some kind, full of pointers, data groups, and data elements, and it would be very large and complex. But the complexity of the worst cases need not be the measure of difficulty of creating applications to deal with normal-transactions. The typical case is much less complex than the worst case. Records of typical clients seem to be fairly simple and manageable. Until there is a formal data dictionary, with definitions of all the data elements that make up the SSA data base, it will be difficult to determine just how many data elements are essential or frequently encountered. For example, the client's home address might be a single data element, or might be broken down into street address, city, state, and ZIP code, or the street address might be broken down into street number, street name, and street type. Conversely, annual income, which appears to be only one item when considered in the aggregate, may turn out to be ten or twenty or even fifty items when taken year by year over the client's life. Such differences explain why estimates of the number of data elements in a typical client's record have varied from about a hundred to a few thousand. Even so, all the estimates appear to fall within the capability range of modern data management technology. CONVERSION OF THE DATA BASE Although application programs for the future process can be created either by modifying existing application programs or by writing new ones, the data base for the future process can be assembled only by the conversion of the several existing files. It is not clear how much the present data bases need to be "cleaned up" by the SSA before being be turned over to a contractor for conversion to the future data base, either for a competitive demonstration or for the transition. Both the magnitude and cost to establish and maintain an upgraded data base compatible with existing application programs are unknown, but an attempt should be made to assess the effort and cost. This would appear to require the full cooperation of an SSA staff organized to reflect the several existing data bases and application programs. Because the condition of the data base to be turned over to the contractors represents for them an important baseline, the essential characteristics of the data must be established by the SSA at an early date. The data elements that will be furnished to the contractor (and that will be in concurrent use in the present process before transition) should be clearly defined and standardized across all SSA programs. Such definitions of data elements could be established by a task force made up of both short-ten and long-term planners. The definitions could be the interface from which GAS and the contractors could plan

26 and toward which SSA redesign efforts now in progress could proceed. It is important to note that the panel has been discussing only the definition of data elements, not data base structure or storage media, which are matters to be decided during the acquisition process. The panel considers it important for the SSA to establish at the outset the relationships between data elements, even though the sequence of steps in conversion/integration of the data base will necessarily depend on the approach taken to transition. In the horizontal slice approach based on services, the enumeration data base would be brought up first. Not at all representative of the central body of the future process, it is a very special data base, different from all the others, and, in a sense, an index to them. In the vertical slice approach based on locations, it would be necessary to establish control over all the different data elements, but it would not be necessary initially to convert all the data. It would suffice to convert only the data pertinent to the one or several local offices. In-the vertical slice based on subsystems, it would be necessary to convert and integrate the entire SSA data base. Attacking the whole data base at once would focus attention upon the requirement for special facilities to resolve the conflicts that are bound to arise when corresponding but perhaps contra- dictory parts of the present unintegrated data base are brought together and unified. It seems unavoidable that both the existing and the new versions of the data base will exist concurrently for at least some interval during the transition. It would be natural to build the new data base progres- sively, record by record. It will be necessary to have an index or directory that will provide a quick response to the query, "Where is account (SSN) xxx-xx-xxxx ?" When there are new as well as old applica- tion programs, the new ones could use data retrieved from the new data base, and the old ones could process the old-style tapes as they are doing now. Before new application programs are ready, there must be a way to return the new data base to the old formats. It may even be necessary to write old-style tapes from the new data base. The problem of keeping the two versions in agreement appears formidable. Accordingly, the panel has considered two approaches. . The old data base could be maintained as the total and definitive data base until the new one is fully prepared. In this case, the basic updating should be carried out on the old data base, so it would always be current. When- ever a record is updated that is also in the new data base, it must be updated in both the new data base and the old one. Obviously, maintaining an updated new data base requires extra work, but this approach is essential- ly conservative. The old data base is always available, and, therefore, the information and organization cannot get worse than they were before the transition began. The new data base could be definitive for records it contains, while the old data base could be definitive only for records not in the new data base. But if there

27 are requirements for a complete data base in one uniform format, the old data base should be updated--with respect to records contained in the new one--from the new one on a batch basis. While it would be desirable not to use the old data base for new data base records in intervals between updatings, it could be used for management information purposes, where errors of a fraction of a percent would not be disastrous. Mass storage devices open up interesting technical possibilities with promise of reducing the overall cost of storage. Although the cost of mass storage devices may not be decreasing as rapidly as the cost of disk files, their cost advantage is still a factor of five or ten, which may be very important during the transition, if it proves necessary to operate two data bases concurrently for a long period. The pace of data base conversion might be greatly accelerated by the transfer of the most- frequently-used of the present tapes into mass storage. From there, a data conversion facility could process them readily and translate their contents from old-style formats to new. There are many other possible approaches, of course, and the SSA has a contractor exploring several of them. CRITERIA FOR EVALUATING TRANSITION PLANS Whether the SSA itself will pick a specific transition sequence, or whether transition planning will be one of the topics dealt with competitively by the contractors during the competitive detailed design phase, it is important to develop criteria for the evaluation of transition plans. The main criteria discussed by the panel are the following: Service~Related Criteria: o Continuity of operation through every stage of transition · Avoidance of service disruption 0 Avoidance of transition-induced errors Achievement of significant and visible improvement in service at an early date Provision for capturing, in the basic design of the system, management information on quality of service and on productivity Cost-Related Criteria: · Minimal concurrent operation of old and new systems Minimal non-productive investment

28 Minimal transition bulge in personnel ~ Minimal transition bulge in overall operations cost · Achievement of significant improvement in cost-effective- ness at an early date Personnel-Related Criteria: · Maximal use of existing SSA people and skills · Minimal work force apprehension and disruption · Distribution of demand on SSA and contractor expertise uniformly over time · Early identification, definition, and resolution of problems of concern to employees and clients Security and Privacy Related Criteria: o No hiatus in security control during any interval of the transition 0 Incorporation of security and privacy protection features into the basic design of the new system · Incorporation of authentication procedures and audit trails into the new system These criteria are obviously not independent of one another. It will be necessary to give ground on some to achieve others. The SSA will have to establish the relative priorities and trade-offs between the criteria. Several trade-offs seem especially significant in the panel's review. The criterion of minimal non-productive investment would not be met if a large fraction of the total work of creating the new process were applied to only a small part of the SSA--and thus failing for a period of time to achieve full return on the investment. Still, this consideration must be weighed against other criteria that call for the avoidance of disruption and transition-induced errors. The~criterion of minimal concurrent operation of the new and old systems is based on two considerations: it will be expensive to operate the two systems concurrently, and it will be difficult to keep them in agreement during any necessary period of concurrent operation. Nevertheless, it would be highly undesirable indeed to make an irrevocable transition to the new process before it is debugged and made stable. Finally, early identification, definition, and resolution of problems of concern to employees and clients are easy to enunciate but difficult to reduce to a program of specific actions. The panel concludes that the SSA should have a positive program to identify the skills required by the new

29 process, to conduct training necessary to achieve those skills, to deal effectively with concerns about transfers and job security and to bring the practical knowledge of the present process that is in the minds of so many SSA employees to bear upon the design of the future process. Considerations of human factors are amplified in Chapter VI. CONCLUSIONS AND RECOMMENDATIONS Even after a year of study and deliberation, the panel's conclusions about transition are by no means sharply defined, but some of the work required to reach conclusions has been identified. First, it is essential that the size and complexity of the data base be understood more clearly. In particular, it is necessary to define the data structures and, especially, the basic data elements. The SSA has two significant activities in progress that are designed to clarify the state of its data. The Office of Advanced Systems has plans to have a contractor study this problem, and the Office of Systems, in its Retire- ment, Survivors, Health, and Disability Insurance (RSHDI) Redesign Project, has been in the process of simplifying existing batch job streams. Each of these projects requires that the basic data elements that make up a client's record be determined and defined. Accordingly, the panel recommends that a task force be created to enumerate and to define the basic data elements, to study the patterns of interrelation among the data elements, and where possible, to define data groups or structures as well as elements. Another question such a task force might examine is whether the future data base should be organized along the lines of a hierarchy, a network, or--in the parlance of relational data bases--a system of relations. Second, it is essential to understand the application programs in approximately the same way as it is essential to understand the data elements. Just as with the data, understanding begins with definition. It is not possible to say how many application programs there are until what is meant by a program has been clearly defined. The widespread impression is that there are many application programs, and that the structures of the data are built into the application programs--rather than into a data management system ln the RHSDI Redesign Project, the data are being brought under the control of a data management system, and application program segments that deal with data structures and data addresses are being separated from the segments that actually process data. The panel sees the need for a survey of the application programs that will yield an understanding of their classes, their sizes, their structures, and their complexity of organization--that is, where they stand on a scale running from simple, direct, and straightforward to complicated, baroque, and bizarre. It is important, also, to identify the programming languages in which they are written and the actual degree of machine independence. Therefore, the panel recommends that a joint project be undertaken to clarify the present state of the applica- tion programs, especially in the light of integrated data base concepts. Third, there is the problem of how to bring to bear upon the planning of the future process and the design of the future system the knowledge that is in the minds of SSA people in the district and branch

30 offices. The thrust of OMB Circular A-109 puts a large amount of initiative and responsibility into the hands of contractors, and it is clear that during the initial phases of the work there will be a number of contractors. Their initiative, creativity, and knowledge of computer- communications technology will need to be complemented by an understand- ing of the actualities of the SSA process. The contractors will need to learn many of the things the SSA personnel know. The problem is how to transfer such knowledge. To some extent, it may be possible to partition the problem by having the contractor work on the future system "from terminal to terminal" and to leave to the SSA itself the responsibility for defining all the aspects of the future process that will affect the procedures and patterns of work. But interactions across the terminals, across the interfaces between the two areas of expertise will surely be very strong. The contractors will, in fact, have to understand the procedures and patterns of work and the attitudes and skills of the SSA people. Even though this problem is well understood by the planners in SSA, and they are working on it, the panel recommends that it be given continued and even increased attention. This problem should be considered carefully, also, by the officials concerned with the develop- ment of A-109 policy, because the effort to take full advantage of the creativity of contractors intensifies the need to transfer to the contractors knowledge of the work procedures and processes employed by the agencies of government. Fourth, closely related to what has just been discussed, there is the problem of foreseeing the concerns of the work force as it moves from the old process to the new one. This problem is critical because the time constants are long. During the past year, personnel from local offices and program service centers have worked with the planners in OAS and with this panel, giving it a direct appreciation of the contributions they can make. The panel therefore recommends expansion and intensifi- cation of the effort to bring into the activities of planning, design, and evaluation, the SSA people who interact directly with clients. Finally, the new process will have to be tested. No doubt a major test will be its acceptability to the SSA personnel who are thoroughly familiar with the present process and expect the future process to be faster and more efficient than the present one and at least as effective. Nevertheless, the panel considers it desirable to put the new process through a series of formal tests. The planning of such tests has been undertaken, but not enough progress has yet been made to lead to conclusions. TRANSITION GUIDELINES During the panel's study of transition, several guidelines were examined and found to be of basic value despite being relatively obvious. The panel lists them here as considerations that should be taken into account during the planning for transition: · Modularize the transition as if it were a system. · As part of the modularization, divide the transition into steps, with the ability to stop the transition and operate successfully after any step.

31 · Consolidate after each step to avoid an accumulation of bugs. Take no irrevocable step. o Achieve visible successes early; avoid early conspicuous failures. Make it clear to all observers that, because of the magnitude and difficulty of the undertaking, some temporary setbacks can be expected. Choose an initial module that is representative of the overall task of designing and implementing the future process. · Emphasize contributions, involvement, and acceptance by the SSA people who will use the new system. Test human factors innovations in the Test and Evaluation Facility and then in actual operating situations before adopting them throughout the system. · Build privacy and security provisions into both the transition and the future process; and guard against the creation of future vulnerabilities by the "Trojan Horse" method during transition. Minimize the duration of continued vulnerability to a single-site disaster. o Harmonize the upgrading of the present process with the transition to the future process.

Next: PRIVACY AND SECURITY »
Second Review of a New Data Management System for the Social Security Administration Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!