Automation-Planning to Implementation; the Problems En Route* BY IRWIN H. PIZER. Uniuersitv Librarian
Uniuersity of Illinois at the Medical Center Chicago, Illinois ABSTRACT Once the major decision to automate library processes is made, there are a variety of problems which may be encountered before the planned svstem becomes operational. These include problems of personnel, budget, procurement of adjunct services, institutional priorities, and manufacturing uncertainties. Actual and potential difficulties are discussed.
"THE best laid schemes of mice and men gang aft a'gley." These words, penned by Robert Burns some 200 years ago, are especially appropriate for those who have experienced the difficulties of bringing an automated system into being. The course of automation, like true love, never did run smooth, and there are many pitfalls that must be avoided in the accomplishment of the goal. Anna Russell gave the f'ollowing bit of advice to those determined individuals who have turned IBM's motto of THINK into SCHEME. First, make a list of all the things you want out of life. Next make a list of all the people you know who have those things. Then you can set about getting them in an organized, systematic fashion-Sic semper automation. INSTITUTIONAL COMMITMENT Probably the most important element leading to the successful completion of' any automation effort is institutional commitment. Unless the parent organization which the library serves, and from which funds must be obtained, is fully in agreement regarding the advantages which will accrue from the projected system, then an almost insurmountable obstacle exists. The librarian must, therefore, be knowledgeable and * Presented June 4, 1975, at the Seventy-fourth Annual Meeting of the Medical Librarv Association, Cleveland, Ohio.
Bull. Med. Libr. Assoc. 64(1) Jan. 1976
must understand clearly what the planned automation project will and will not do; why the project is important to the library and its effective functioning; and how the project will help to meet the goals of the institution. Together with institutional approval must come an institutional commitment of' funds, and perhaps more important, there must be an institutional priority for the project which is compatible with the needs of the library. For example, many systems have foundered late in the game because the needs of other departments ranked higher anid were thus attended to first. Suppose that the automation project for the library is being performed by the data processing department of the institution. If' the work of another department with a higher priority expands, then less time mav be available for the library program, or if there is an emergency, and it comes to a choice of running the library program or producing the pay checks for all employees, it is clear which task will take precedence. In many institutions, the acquisition of a large computer can initially produce a situation where there is more capacity than there are tasks. This is a wasteful state with which no administrator will be pleased. As a result, the canny computer center manager or administrator will look for projects which can be developed to use this excess capacity. One should be wary if the library program is used for filler, for it can be readily foreseen that the time will come when other projects will push the library program off' the computer. This phenomenon is not limited to small projects and small libraries. Consider the history of the circulation automation program at the Denison Memorial Librarv, University of Colorado Medical Center. Here, an excellent system was developed, programmed, tested, and was ready to become I
IRWIN H. PIZER operational when the library was informed that no computer time was available for running the system. The expenditure in both state and federal f'unds for the system was thus wasted, and a system which many people hoped would prove a prototype for other libraries cannot be used. A hazard which is totally uncontrollable is that of change of administrative personnel and a consequent change of institutional direction. Because there is little that can be done about this situation, it is simply mentioned so that we do not forget that it can occur.
PROBLEMS WITH INSTITUTIONAL DATA PROCESSING DEPARTMENTS serious Another problem is that of an institutional data processing department which is sure that it can do the job that is needed by the library, but the department encounters various problems in performing at a satisfactory level. The reasons for such problems are varied, but several examples will illustrate the point. No one programmer may be given the responsibility for all of the library program; it is farmed out in bits and pieces to many people, none of whom has the opportunity to become sufficiently expert to perf'orm quicklv or well. The data processing group, not completely understanding the requirements of the library system, may try to mold it to fit standard data processing methods and techniques used for handling business data. Data processing personnel may f'ind that the requirements of' the library system are considerably more sophisticated than they had first supposed and as a result the system is difficult to program. In this case the library may be told that the "machine" cannot do the things that the library needs to have done. A response of this kind should serve as an immediate warning that the library will end up with a system which is unsatisf'actory f'rom its point of' view and will only be second-rate at best. Because of the likelihood that such a response may be received, the library should have either a knowledgeable staff member (in a big library there should be a systems librarian) who can deal with this problem or should have access to impartial outside people for advice who are knowledgeable about library automation. A case in which some or all of these problems have occurred is at the University Library at the Urbana/Champaigin campus of the University
2
of Illinois. Here a planned circulation system for the undergraduate library has never become operational, and the automation of the acquisition department records has generated more problems perhaps than it has solved. Note that the problems with circulation systems recur and one can cite many examples of' unsatisfactory automation attempts in this area, partly because the task appears to be simple and akin to store inventory, but is actually more complex.
AUTOMATION OF CIRCULATION AT THE UNINERSITY OF ILLINOIS AT THE MEDICAL CENTER A problem that is happily uncommon, terminated four years of' work on a circulation system for the University of Illinois at the Medical Center. In 1970/71 specifications were written for a circulation system to meet the needs of the library. We hoped to use the work done in Colorado, and as a result, the same type of equipment was specified. (As a general rule of' thumb, it is cheaper to tie into an existing system than to create a new system.) As the implementation phase progressed, it became clear that there would be differences between systems, but the differences could be handled by the terminals and hardware that were originally specified. Because of the cost of' the system, it was necessary to place the purchase order for the hardware by bid; the vendor who placed the lowest bid was the same vendor used by Colorado. This was a small manufacturer of' hardware with an excellent reputation, and it had been noted that this firm was flexible and willing to work closely with the library to customize the necessary terminals to meet the needs of' the library. Because of the time involved in bidding, it was not until early 1973 that the actual order for the machines was placed, for delivery at the time of the opening of' the new library building. Due to a change in manufacturer specifications, the system was slightly altered, requiring that the whole package be rebid, but the same vendor again won the bid. Concurrently with these procedures, the library was producing the necessary machine-readable book cards, was preparing to produce machine-readable user identif'ication cards, and had purchased terminals from another vendor for printing notices and date due slips, as part of the total system. The library then received word that the small manufacturing firm with which we had been Bull. Med. Libr. Assoc. 64(l) Jan. 1976
AUTOMATION-PLANNING TO IMPLEMENTATION
working for three years had been sold to a larger company. Although that news was not entirely welcome due to the reputation of the larger firm, assurance was given that there would be no affect on the library's order. Then came the first delivery date in the fall of 1973, and no equipment arrived. The library was informed that the manufacturing plant was being moved and that there would be a delay of a couple of months in delivery. With the next missed delivery date, the library was promised that a delivery date of October 1974 would be met. In October 1974, the delivery date came and went, and the library was told, with profuse apologies, that delivery would take place in December, absolutely. In December the library was informed that certain vital documentation, necessary for building the computer interface equipment, had been lost in moving, and that delivery would take place in the spring of 1976. It was now clear that the manufacturer's own internal priorities had been reordered and that library systems were no longer a primarv product. At that point, and because the firm was now on the brink of bankruptcy, the library faced the difficult decision to scrap the entire project as it had been originally planned, and begin again. Other libraries caught in the same double play with this manufacturer are still hoping to receive equipment at a future date. One reason that reconsideration of the library's system was not altogether unattractive in 1975, was that in the years since 1970, considerable technological advances had taken place in two areas, both of which may have significant impact on library automation. Relatively inexpensive minicomputers now seem to provide an attractive and practical solution to many of' the problems which have been noted. In addition, light pens for reading bar-coded markings, like those we are seeing with increasing frequency on grocery product labels, have been developed. Although the initially specified system would have been satisfactory for the needs of the library, the new technology makes it possible to explore and integrate other library operations, both in-house and with other libraries in the geographic region.
people, the problems with acceptance of' automation are vitally important. Automation does not usually eliminate jobs in libraries, but rather frees staff members to perform additional tasks and to provide additional services. It should be clearly put to administrators that hopes for automation to reduce the cost of running the library are largely illusory. What will be achieved is a slowing of the rate of growth of library expenditures for personnel, if' the system works. Besides convincing the administration on this point, it is important to make it clear to library staff'. It is also helpful to conduct training programs for the staff' so that they lose their initial fear of "the machine" and learn to regard it as just another piece of' office equipment, like the typewriter. B UDGET
One should also take an honest look at the budget for a proposed system. An overzealous salesman will make many claims and promises as to the cost of the system, and it is wise to make sure that the estimates are realistic (barring the uncertainties of' inflation) so that one is not caught in the position in which the allotted funds run out midway in the implementation of' a project. The institution must also be prepared to make a long-term funding commitment for an automation project. Once a library automation program begins, it is painf'ul and very expensive not to complete the task. CONCLUSION
If' one is entering the f'ield of library automation anew, take the time to talk to people who have experienced putting together their own system, preferably in a similar environment. The pioneer days are over and it should not be difficult to find an analogous situation for comparison. Do not think that frank discussions of the problems of' a library automation program will be found in the published literature. There is very little in print to indicate what can and did go wrong with plans for many libraries. No one likes to admit failure, especially in print. One may find a published description of' autoPERSON NEI. mation plans for a librarv in the literature, and Personnel are the key factor in any library then f'ind no further reports. This is often a good automation program, and because automation indication that something went wrong, and that is usually a threatening experience for most the system is not working as planned, or not
Bull. Med. Libr. Assoc. 64(1) Jan. 1976
3
IRWIN H. PIZER
working at all. It may be just as important, if not more so, to talk to the staffs of those libraries as to the ones who succeeded. The library staff with plans for automation should be prepared to modify those plans if it is found that all of the things wanted are more than can be afforded. We all start by imagining the best of all possible worlds, but it is often
4
possible to live with less, and not have a system which is the worse for compromise. Just be sure that the compromises made are those which are based on the needs of the library, and not on what data processing people said could or could not be done by the machine. The problems are great, but the rewards are even greater.
Bull. Med. Libr. Assoc. 64(1) Jan. 1976
Uniuersity of Illinois at the Medical Center Chicago, Illinois ABSTRACT Once the major decision to automate library processes is made, there are a variety of problems which may be encountered before the planned svstem becomes operational. These include problems of personnel, budget, procurement of adjunct services, institutional priorities, and manufacturing uncertainties. Actual and potential difficulties are discussed.
"THE best laid schemes of mice and men gang aft a'gley." These words, penned by Robert Burns some 200 years ago, are especially appropriate for those who have experienced the difficulties of bringing an automated system into being. The course of automation, like true love, never did run smooth, and there are many pitfalls that must be avoided in the accomplishment of the goal. Anna Russell gave the f'ollowing bit of advice to those determined individuals who have turned IBM's motto of THINK into SCHEME. First, make a list of all the things you want out of life. Next make a list of all the people you know who have those things. Then you can set about getting them in an organized, systematic fashion-Sic semper automation. INSTITUTIONAL COMMITMENT Probably the most important element leading to the successful completion of' any automation effort is institutional commitment. Unless the parent organization which the library serves, and from which funds must be obtained, is fully in agreement regarding the advantages which will accrue from the projected system, then an almost insurmountable obstacle exists. The librarian must, therefore, be knowledgeable and * Presented June 4, 1975, at the Seventy-fourth Annual Meeting of the Medical Librarv Association, Cleveland, Ohio.
Bull. Med. Libr. Assoc. 64(1) Jan. 1976
must understand clearly what the planned automation project will and will not do; why the project is important to the library and its effective functioning; and how the project will help to meet the goals of the institution. Together with institutional approval must come an institutional commitment of' funds, and perhaps more important, there must be an institutional priority for the project which is compatible with the needs of the library. For example, many systems have foundered late in the game because the needs of other departments ranked higher anid were thus attended to first. Suppose that the automation project for the library is being performed by the data processing department of the institution. If' the work of another department with a higher priority expands, then less time mav be available for the library program, or if there is an emergency, and it comes to a choice of running the library program or producing the pay checks for all employees, it is clear which task will take precedence. In many institutions, the acquisition of a large computer can initially produce a situation where there is more capacity than there are tasks. This is a wasteful state with which no administrator will be pleased. As a result, the canny computer center manager or administrator will look for projects which can be developed to use this excess capacity. One should be wary if the library program is used for filler, for it can be readily foreseen that the time will come when other projects will push the library program off' the computer. This phenomenon is not limited to small projects and small libraries. Consider the history of the circulation automation program at the Denison Memorial Librarv, University of Colorado Medical Center. Here, an excellent system was developed, programmed, tested, and was ready to become I
IRWIN H. PIZER operational when the library was informed that no computer time was available for running the system. The expenditure in both state and federal f'unds for the system was thus wasted, and a system which many people hoped would prove a prototype for other libraries cannot be used. A hazard which is totally uncontrollable is that of change of administrative personnel and a consequent change of institutional direction. Because there is little that can be done about this situation, it is simply mentioned so that we do not forget that it can occur.
PROBLEMS WITH INSTITUTIONAL DATA PROCESSING DEPARTMENTS serious Another problem is that of an institutional data processing department which is sure that it can do the job that is needed by the library, but the department encounters various problems in performing at a satisfactory level. The reasons for such problems are varied, but several examples will illustrate the point. No one programmer may be given the responsibility for all of the library program; it is farmed out in bits and pieces to many people, none of whom has the opportunity to become sufficiently expert to perf'orm quicklv or well. The data processing group, not completely understanding the requirements of the library system, may try to mold it to fit standard data processing methods and techniques used for handling business data. Data processing personnel may f'ind that the requirements of' the library system are considerably more sophisticated than they had first supposed and as a result the system is difficult to program. In this case the library may be told that the "machine" cannot do the things that the library needs to have done. A response of this kind should serve as an immediate warning that the library will end up with a system which is unsatisf'actory f'rom its point of' view and will only be second-rate at best. Because of the likelihood that such a response may be received, the library should have either a knowledgeable staff member (in a big library there should be a systems librarian) who can deal with this problem or should have access to impartial outside people for advice who are knowledgeable about library automation. A case in which some or all of these problems have occurred is at the University Library at the Urbana/Champaigin campus of the University
2
of Illinois. Here a planned circulation system for the undergraduate library has never become operational, and the automation of the acquisition department records has generated more problems perhaps than it has solved. Note that the problems with circulation systems recur and one can cite many examples of' unsatisfactory automation attempts in this area, partly because the task appears to be simple and akin to store inventory, but is actually more complex.
AUTOMATION OF CIRCULATION AT THE UNINERSITY OF ILLINOIS AT THE MEDICAL CENTER A problem that is happily uncommon, terminated four years of' work on a circulation system for the University of Illinois at the Medical Center. In 1970/71 specifications were written for a circulation system to meet the needs of the library. We hoped to use the work done in Colorado, and as a result, the same type of equipment was specified. (As a general rule of' thumb, it is cheaper to tie into an existing system than to create a new system.) As the implementation phase progressed, it became clear that there would be differences between systems, but the differences could be handled by the terminals and hardware that were originally specified. Because of the cost of' the system, it was necessary to place the purchase order for the hardware by bid; the vendor who placed the lowest bid was the same vendor used by Colorado. This was a small manufacturer of' hardware with an excellent reputation, and it had been noted that this firm was flexible and willing to work closely with the library to customize the necessary terminals to meet the needs of' the library. Because of the time involved in bidding, it was not until early 1973 that the actual order for the machines was placed, for delivery at the time of the opening of' the new library building. Due to a change in manufacturer specifications, the system was slightly altered, requiring that the whole package be rebid, but the same vendor again won the bid. Concurrently with these procedures, the library was producing the necessary machine-readable book cards, was preparing to produce machine-readable user identif'ication cards, and had purchased terminals from another vendor for printing notices and date due slips, as part of the total system. The library then received word that the small manufacturing firm with which we had been Bull. Med. Libr. Assoc. 64(l) Jan. 1976
AUTOMATION-PLANNING TO IMPLEMENTATION
working for three years had been sold to a larger company. Although that news was not entirely welcome due to the reputation of the larger firm, assurance was given that there would be no affect on the library's order. Then came the first delivery date in the fall of 1973, and no equipment arrived. The library was informed that the manufacturing plant was being moved and that there would be a delay of a couple of months in delivery. With the next missed delivery date, the library was promised that a delivery date of October 1974 would be met. In October 1974, the delivery date came and went, and the library was told, with profuse apologies, that delivery would take place in December, absolutely. In December the library was informed that certain vital documentation, necessary for building the computer interface equipment, had been lost in moving, and that delivery would take place in the spring of 1976. It was now clear that the manufacturer's own internal priorities had been reordered and that library systems were no longer a primarv product. At that point, and because the firm was now on the brink of bankruptcy, the library faced the difficult decision to scrap the entire project as it had been originally planned, and begin again. Other libraries caught in the same double play with this manufacturer are still hoping to receive equipment at a future date. One reason that reconsideration of the library's system was not altogether unattractive in 1975, was that in the years since 1970, considerable technological advances had taken place in two areas, both of which may have significant impact on library automation. Relatively inexpensive minicomputers now seem to provide an attractive and practical solution to many of' the problems which have been noted. In addition, light pens for reading bar-coded markings, like those we are seeing with increasing frequency on grocery product labels, have been developed. Although the initially specified system would have been satisfactory for the needs of the library, the new technology makes it possible to explore and integrate other library operations, both in-house and with other libraries in the geographic region.
people, the problems with acceptance of' automation are vitally important. Automation does not usually eliminate jobs in libraries, but rather frees staff members to perform additional tasks and to provide additional services. It should be clearly put to administrators that hopes for automation to reduce the cost of running the library are largely illusory. What will be achieved is a slowing of the rate of growth of library expenditures for personnel, if' the system works. Besides convincing the administration on this point, it is important to make it clear to library staff'. It is also helpful to conduct training programs for the staff' so that they lose their initial fear of "the machine" and learn to regard it as just another piece of' office equipment, like the typewriter. B UDGET
One should also take an honest look at the budget for a proposed system. An overzealous salesman will make many claims and promises as to the cost of the system, and it is wise to make sure that the estimates are realistic (barring the uncertainties of' inflation) so that one is not caught in the position in which the allotted funds run out midway in the implementation of' a project. The institution must also be prepared to make a long-term funding commitment for an automation project. Once a library automation program begins, it is painf'ul and very expensive not to complete the task. CONCLUSION
If' one is entering the f'ield of library automation anew, take the time to talk to people who have experienced putting together their own system, preferably in a similar environment. The pioneer days are over and it should not be difficult to find an analogous situation for comparison. Do not think that frank discussions of the problems of' a library automation program will be found in the published literature. There is very little in print to indicate what can and did go wrong with plans for many libraries. No one likes to admit failure, especially in print. One may find a published description of' autoPERSON NEI. mation plans for a librarv in the literature, and Personnel are the key factor in any library then f'ind no further reports. This is often a good automation program, and because automation indication that something went wrong, and that is usually a threatening experience for most the system is not working as planned, or not
Bull. Med. Libr. Assoc. 64(1) Jan. 1976
3
IRWIN H. PIZER
working at all. It may be just as important, if not more so, to talk to the staffs of those libraries as to the ones who succeeded. The library staff with plans for automation should be prepared to modify those plans if it is found that all of the things wanted are more than can be afforded. We all start by imagining the best of all possible worlds, but it is often
4
possible to live with less, and not have a system which is the worse for compromise. Just be sure that the compromises made are those which are based on the needs of the library, and not on what data processing people said could or could not be done by the machine. The problems are great, but the rewards are even greater.
Bull. Med. Libr. Assoc. 64(1) Jan. 1976
