The early 1950s found the banking industry on the brink of a crisis. Check use in the United States had doubled between 1943 and 1952, from four billion to eight billion checks per year, and bankers were projecting continuing increases of one billion checks per year by 1955. Banks were at a standstill, unable to expand, or, in some cases, even to keep pace with the increasing flow of paper. The immediate culprit was the check clearing process. Each of the 28 million checks written every business day passed through approxi- mately 2; banks, taking more than two days to be processed. The result was a staggering 69 million checks in process throughout the United States on an average day. Unless deposited at the bank where both accounts were located, a check had to be sorted by hand and individually tallied on an adding machine at least six times during the clearing process. In a 40-person branch, seven or more people were kept busy sort- ing, adding, and bundling checks. Most were young female book- keepers between the ages of 18 and 24. Given the drudgery of the work and the age of the women, who traditionally left the banks upon marrying, turnover was exceedingly high, in some instances 100 percent per year.’ Bank of America (called Bank of Italy until 1930) was founded in 1904 as a small San Francisco savings and loan. A single branch, opened in 1909, grew to 24 by the end of 1918 and to 292 by the bank’s twenty-fifth anniversary in 1929, at which point Bank of 42 America employed more than 7,000 people and had more than $1 billion in assets. L. M. Giannini, some of founder A. P. Giannini, took the bank to 495 branches and $2.1 billion in assets by the end of 1941. With World War II, California’s population and economy mushroomed, boosting the bank’s resources to more than $5 billion. Following the war, Bank of America opened nine overseas offices; by 1946, it was the largest bank in the world. Former national bank examiner S. Clark Beise, who had come to Bank of America under A. P. Giannini and risen to senior vice president by 1950 (and to president in 1954 to 1964), was acutely aware of the serious problems that faced the nation’s banks in gen- eral and Bank of America in particular. The bank was managing more than 4.6 million checking, savings, and Timeplan loan ac- counts, with checking accounts growing at a rate of 23,000 per month. Realizing that growth would be limited not by new busi- ness, but by inability to service new accounts adequately, Beise became the first of the bank’s senior managers to seek a solution in the automation of check handling.
The Searching Phase: 1950-1953 When a promotional meeting at the Emporium department store near Bank of America headquarters ended earlier than expected, Dr. W. B. Gibson of the Menlo Park, California, Stanford Research Institute (SRI), an independent technology research institution at the leading edge of electronics, decided to call on Beise. “I told Beise that this was just a ‘shot in the dark,’ but that I thought Bank of America should be thinking about electronic applications,” Gibson later recalled.’ Beise had previously approached several business equipment manufacturers about creating an automated bookkeeping system. Although willing to improve their basic proof machines, none of the manufacturers was interested in investing time or capital to create an entirely new system. Beise acted quickly on Gibson’s ad- vice; vice president of operations Frank M. Dana, asked by Beise to follow up and develop a proposal, contacted SRI’s director of engineering research, Thomas H. Morrin, and immediately com- menced a series of meetings to explore the automation of check processing, account numbering, and paper handling. SRI seemed to Beise to be the perfect solution. As a prominent research and development organization with a strong track record in electronics research, it could establish the possibilities in automated check han- dling and design a model to test or sell to a manufacturer. Beise formed a close relationship with Morrin, vice president of SRI Engi- neering and R&D. Working under a charter from L. M. Giannini to solve the banking crisis, he signed a contract, with the understand- ing that no publicity would be given to the effort. Morrin became his R&D manager. Subsequently, a highly secret feasibility study was initiated. Beise assigned Charles Conroy as systems analyst to work with the SRI team. Automating Check Processing When a check was deposited at a bank, two steps had to be accomplished quickly: proofing and bookkeeping. Each afternoon, “on us” checks, meaning checks drawn on the bank that held the account, were sorted by signature and taken to a conventional led- ger-card accounting machine whose operator entered the dollar amount on a ledger card and subtracted it from the balance, thereby creating a permanent record for month-end reporting. Daily depos- its and withdrawals were subsequently posted to customers’ ac- BANK OF AMERICA 45 count balances. All other checks were batched into proofed totals and forwarded to other branches and banks. To finish proofing early enough to catch stop payments or overdrafts, most banks were forced to shut their doors to business by 2:00 p.m. The check was central to SRI’s feasibility study. Bank of America, regarding it as an important emotional link to customers, wanted few, if any, changes to the check. One of the first critical choices was between customers’ usage habits and system needs with respect to the account filing system. Standard banking practice was to orga- nize customer files alphabetically, which resulted in changing the order of sorting with the addition of each new account, and to identify and verify checks against customers’ signatures, which were maintained on index cards at branch offices. SRI engineers suggested that a numerical accounting system would make check processing easier to automate and provide a more reliable means of identifying checks. Conroy worked with them to develop a revised paperwork flow to articulate the potential savings. The proposed change would entail distributing new checkbooks with customer name and account numbers printed on checks and warning cus- tomers against loaning bank checks to friends, a common pre- automation practice. The feasibility study provided an opportunity for engineers and bankers to learn the complexities of each other’s businesses. Bank of America vice president Ranaulf Beames stressed to SRI engineers the service-industry/customer-focus character of banking, empha- sizing that prompt, reliable banking services engendered customer loyalty. He also underscored the bank’s desire that customers be inconvenienced as little as possible and that usage habits be changed only as necessary. Beames discussed with Beise the alter- native work flows resulting from printing identification numbers on the checks, and Beise quickly agreed the change was essential. They encouraged SRI to explore the means of electronically identifying the account number, thereby changing a banking tradition estab- lished in Venice in 1431.* In late September 1950, Morrin informed Beames that SRI’s feasi- bility study “indicated it was technically possible to build an auto- matic bookkeeping system for ledger posting and processing of commercial checking accounts” and suggested a three-phase project approach entailing (1) a study of banking procedures external to the machine, (2) logical design, and (3) development, construction, and testing. Because manufacturing ran counter to SRI’s mission state- ment, the last phase was to be carried out by an equipment manu- 46 facturer. Beise approved the project under CEO funds and made the fixed investment toward electronic banking. The $15,000 con- tract (later augmented by $5,000) for SRI’s part in the project re- ferred to the system as an electronic recording machine (ERM). Although the Bank of America was interested in using the proofing process as an input to bookkeeping activities, an April 30, 1951, interim report described the machine as fundamentally a bookkeeping device. Completion of the first two phases of the proj- ect found the bank and SRI in agreement that the system would have to perform five basic bookkeeping functions: credit and debit all accounts; maintain a record of all transactions; retain a record of current customer balances to be printed as needed; respond to stop-payment and hold orders on checks; and notify operators of checks that caused accounts to be overdrawn. SRI subsequently began what was supposed to be its final project for the bank, estimation of optimal account capacity for and cost of constructing the ERM. An initial rough estimate of $750,000, with an additional $15,000 for development of a check reader, was arrived at by comparing it with estimated construction costs incurred by other companies for such large-scale computer projects as the Mark III, UNIVAC, EDVAC, and Whirlwind I. When ERM development was broken down into specifics, the final estimate was $949,000, a fig- ure deemed high by Morrin, who suggested estimating minimum and complete systems. The readjusted figures were $530,000 and $830,000, respectively. Only Burroughs expressed an interest in building an ERM for the bank, and its proposal to modify an existing system that would deliver less functionality at twice SRI’s cost estimate was rejected. Consequently, Beise asked SRI to construct an engineering proto- type of the ERM, a decision motivated to some extent by his belief that confidentiality was less at risk with the research firm. Although it had no interest in manufacturing and was ill equipped to build what was to become one of the largest and most complex computer systems yet designed, SRI, on January 28, 1952, contracted to de- velop, construct, and test a pilot ERM. Beise still planned, once SRI had demonstrated a working prototype, to sell the system design to a manufacturing company. Phase 3 work on the ERM was to involve completing the logical design of remaining operations; constructing a pilot model; testing the model at a Bank of America branch; and finishing and install- ing the machine at a local branch. The bank was to pay SRI no more than $850,000 over four years, plus an additional $25,000 to cover BANK OF AMERICA 47 subcontracts. (Although expenses were never released, most engi- neers estimate that the final cost was in excess of $5 million.) Once SRI had the mandate to develop the system, Morrin and colleagues Jerre Noe and Oliver Whitby — referred to by the few bank employees who knew about the project as the “whiz kids” — began working as technical advisers on the creation of a prototype. Conroy moved to Palo Alto to supervise the project and work with the team. Monthly review meetings with Beise were held at bank headquarters. Design and operation of the ERM were fairly well defined by the fall of 1952. The primary system was to consist of four centrally located, 30,000-account capacity ERMs linked by (in some cases, flying) messenger services to approximately twelve branches. Each ERM was to be operated by ten or twelve bookkeep- ers and handle both bookkeeping and proofing functions. SRI had begun in 1952 to develop a system for encoding electroni- cally readable customer, bank, and account information on checks to support automatic proofing. A magnetic ink bar printed on the backs of checks was selected as the best solution to punched-card approaches. Encoding project manager Kenneth Eldredge devel- oped a system to form the magnetic ink into Arabic characters that could be read by humans as well as computers. This magnetic ink character recognition (MICR) system, successfully developed and tested in the summer of 1954 on Bank of America’s traveler’s check program, proved a superb showcase for advances in machine read- ing and paper handling; by June 1955, more than 300,000 traveler’s checks had been scanned through the system. SRI launched a wide-ranging technology search for components, visiting companies in the United States and Europe to observe and assess willingness to develop products for the ERM. Meanwhile, SRI engineers had set to work on the logical design of the system. A major design choice was to develop electronic logic using tubes and wired programs, leaving open the possibility of transistorizing the final ERM. Organizing for Automation On December 23, 1950, just as SRI had begun work on phase one design of the ERM, Al Zipf, an operations manager in a Southern California branch, received from Bank of America president L. M. Giannini a letter marking the former’s fifteen years of service. Zipf, a high school graduate, joined the bank as a night clerk and worked his way up to assistant branch supervisor, along the way securing 48 four patents for inventions and improvements in banking machin- ery and systems. He responded with a detailed letter encouraging the president to automate bank activities. “If we are willing to take an active part in the engineering development of new machines,” he wrote, “I am confident that it is possible and economically practi- cal to accomplish the virtually automatic performance of such tasks as the sorting, listing, and commercial ledger posting of near- standard paper checks.” He closed the letter with “my best wishes for Seven Million Dollars, less staff, and more machines.’”° Gian- nini gave the letter to Beise, who invited Zipf to San Francisco. Im- pressed by his energy and recommendations, Beise asked Zipf to join the innovation team on a confidential basis to explore alternatives to the SRI approach and instructed that he receive Frank Dana’s copies of SRI reports and meeting minutes. Encouraged by Beise and Dana to evaluate the applicability of current technology to banking, Zipf, on leave at UCLA to study electronic systems during the spring of 1952, began searching for equipment and ideas under the guidance of pioneering computer designer George W. Brown. Zipf visited computer-using manufac- turers and firms to observe management and service problems and evaluated the banking potential of more than a dozen suppliers’ systems. In a letter to Dana, he observed that there ‘“were enormous opportunities in electronics’ and suggested that the bank form a systems and equipment research group. In late 1952, over Morrin’s protestations that the ERM could be expanded to support all the bank’s data processing, Zipf persuaded Beise and Dana that it was important to begin a computer acquisition appraisal to gain experi- ence with computers for improving bank operations beyond the automation of check handling. Zipf returned to Bank of America in the summer of 1953 and in October was promoted to assistant vice president with responsibil- ity for managing the newly created Systems and Equipment Re- search (S&ER) Department. He began with one secretary and a mandate to establish internal systems capability, evaluate suppliers, and pursue potential economic applications of general-purpose computers. Zipf, on the basis of an analysis of two general-purpose computers, the UNIVAC I and IBM 702, decided that IBM could deliver better support and reviewed the latter system’s potential with Beise. A tentative order, authorized in October 1953, called for delivery of one IBM 702 to San Francisco in September 1955 and a second to Los Angeles in June 1956. It was contingent on Zipf’s providing detailed analyses of costs and benefits with profit objec- BANK OF AMERICA 49 tives by the fall of 1954. The implementation effort was to parallel the ERM project to gain experience in the management and opera- tion of general purpose computers in non-check-processing opera- tions. Discussion of the Searching Phase The management team had acquired perspective on the state of electronic technology and the means of applying the technology to banking. They knew it was critical to capture information electroni- cally as soon as possible to take advantage of the speed and econom- ics of electronic processing. In addition, for efficiencies, the more information printed in accessible electronic form, the better. Auto- mating with IT was profitable for certain paper-based systems. Plan- ning is most important prior to designing a system because it is essential to perform a careful analysis of exactly what is desired in the process so as not merely to automate existing procedures but to redesign to improve the entire process. Planning is time consum- ing and iterative with involvement of systems analyzers and knowl- edgeable bankers. There are no absolutes, but trade-offs must be made between costs and service requirements. The role of business leadership is to make those trade-offs. In addition, some seemingly obvious processing activities, such as on-line access to memory, are not possible at this point but may be in the future. The team also gained a broader set of insights into the overall impact of electronic automation. To really gain significant cost re- ductions, old methods had to change dramatically, not incremen- tally. There existed no paper-processing standards, and each manu- facturer had its own set of codes and designs for the proofing and bookkeeping procedures. The manufacturers intent on incremental inventions in their present systems to maintain and grow market share were unwilling to risk a leap to a totally new system. To obtain such a system, significant capital would have to be invested and the banks would have to change their procedures. The push for that change could come from a knowledgeable banker with per- sistence and capability. Since he knew it was just as difficult to learn banking as it was to learn systems, Beise decided to lead. Building IT Competence: 1954-1956 Zipf was faced with three immediate challenges: deciding which tasks to automate, designing and developing programs to automate 50 these tasks, and selecting and training a team. He immediately set about recruiting a group of knowledgeable systems analysts and programmers. An internal personnel announcement of an opportu- nity for training in computer programming drew thirty-four re- sponses from experienced bank officers. After all were carefully screened, four senior managers were selected to attend, with Zipf, IBM’s 702 programming school in Poughkeepsie, New York. There Zipf met and hired the bank’s first data-processing ‘‘professional,” Harry Kahramanian, a graduate of Grace Hopper’s UNIVAC pro- gram. Hopper, a computer pioneer, had developed the first produc- tion-control system for a computer and the elements of a systematic approach to programming computers. When they completed the course, two teams were organized — one in Los Angeles and one in San Francisco — to analyze existing operations and determine where computer automation would be most profitable. Zipf believed that the computer’s greatest potential was for im- proved management reporting but recognized that the cost of large- scale computing could not be justified on that basis alone. With management reporting as the ultimate objective, he and his team of newly trained programmers searched for areas of bank operations characterized by high-volume, repetitive clerical activities. In 1954, the American Bankers Association, concerned with the explosive growth of float owing to the cumbersome sorting process, appointed a committee on the mechanization of check handling; Harold A. Randall of the First National Bank of Boston was its chairman. In early 1955, Randall appointed a technical subcommit- tee of operating managers who were the leaders in using electronic process in their banks. At the time, eleven banks were actively pursuing the use of computers, ranging from the suburban County Trust bank in White Plains, New York, to the Mellon Bank of Pitts- burgh.’ Most were automating loan processing and two were testing punched-card checks. The committee was chaired by John Kley, leader of the White Plains effort. He selected his committee from innovative IT manag- ers at innovative banks.* Zipf, a member of this group, gained ac- cess to leading users of IT and the opportunity to be exposed to manufacturers’ proposed solutions. The committee met regularly twenty-two times over a three-year period to define a standard that would allow automatic sorting of checks and proofing the sort. At these meetings they heard proposals for the standard from all the major manufacturers, including IBM, NCR, Burroughs, and Addressograph-Multigraph. In July 1956 the subcommittee recom- BANK OF AMERICA 51 mended, with ABA committee approval, that the Bank of America’s MICR be the standard for U.S. check processing. One year later it approved the present bottom right-hand corner location, which was consistent with the electronic recording machine (ERM) design. The Bank of America was assured that it was developing the stan- dard check-processing system not only for its customers but for the entire U.S. banking system. By November 1954 programs for real estate and installment-loan accounting were sufficiently defined to permit evaluation of the functionality and economics of the IBM 702. The program design provided a basis for detailed evaluation of the potential savings from converting existing manual operations to electronic proc- essing. The comparison showed early losses owning to conversion, with a profit beginning in the second year and leveling off at $189,364 in the third year as a result of staff reductions. On Beames’s death in the spring of 1953, Howard Leif became control- ler and assumed responsibility for the ERM project. Beise, Dana, and Leif reviewed the analysis with the management committee and in early December 1954 Zipf confirmed the order for delivery of the first IBM 702 to San Francisco. Each group then proceeded with full-time IBM 702 programming of the system it had analyzed — San Francisco for installment, and Los Angeles for real estate and loan programs. They began to automate operations. Even without a computer, S&ER had grown to twenty-five people by June 1955. Its two development projects, the SRI ERM and the IBM 702, were at the forefront of computer technology with the first operational large-scale computer applications in banking. The ERM was to be announced and begin servicing the San Jose branch, and the 702 was to be delivered to San Francisco in the fall of 1955. Zipf, having learned during his trips to other companies of the anxieties that introducing a computer could generate, had encouraged the bank in the spring of 1955 to launch a training program to further develop bank employees’ understanding of computer systems and mitigate their apprehensions by emphasizing the joint man- machine nature of data processing. The message promulgated to bank employees was that although the IBM 702 (nicknamed BEAST for Bankamerica Electronic Accounting Service Tool) was to take over dull work, it would require strong personnel support to func- tion well. Beise, Leif, and Zipf, growing restless as experimental costs con- tinued to rise, declared the design of the ERM complete in the spring of 1955. They had shifted their goal from building an opera- Bz tional system to building an “as is’ prototype for a September 1955 demonstration, with adjustments to be permitted afterward.’ Completing construction within the bank’s time frame proved challenging; engineers were working in around-the-clock shifts as September neared. When existing paper-handling systems were deemed too unreliable to support proofing, the ERM became ex- clusively a bookkeeping machine. Checks were to continue to be proofed at branches and sent to the ERM centers. SRI’s earlier hope of combining high-speed sorting and bookkeeping into a continu- ous process also proved unfeasible in the time allotted, relegating the SRI sorter to postprocessing sorting of checks to customers. When, in the spring of 1955, Beise diverted his team’s attention from construction to a grand public announcement, the bank’s pub- lic relations office, deeming ERM too technical sounding and po- tentially intimidating to customers, introduced a name change. To the considerable dismay of the engineers, who requested the more scientific-sounding FINAC (for financial accounting), the Market- ing Department rechristened the machine to the more appealing ERMA (Electronic Recording Machine Accounting). Bank of America designated September 22, 1955, ERMA Day. To avoid leaks, the press was bused from San Francisco to SRI’s Menlo Park headquarters, the site of the announcement. S. Clark Beise, by then Bank of America president, and Thomas Morrin conducted the presentation. Beise spoke of the great contribution the machine would make to Bank of America and the banking community in general; Morrin emphasized the magnitude of the engineering ac- complishment and demonstrated the system. Neither named the firms that had collaborated on the project nor the costs incurred. Bank of America had invited an impressive list of journalists — including the financial editors of newspapers and wire services, California business syndicate writers, and writers from The New York Times, Life, Fortune, Newsweek, and Business Week — which paid off in a barrage of articles lauding its accomplishment. The same month that ERMA was announced, the bank’s first IBM 702 was installed in a new computer room in San Francisco. The installment loan system was brought up on the San Francisco computer within three weeks, followed in November by the Los Angeles—developed real estate loan program, to which 90,000 loans had been converted. An S&ER implementation audit of the install- ment and real estate loan operations compared estimated with ac- tual costs to verify the savings and justify to the management com- mittee purchase of a second 702 for Los Angeles. Increased machine BANK OF AMERICA 53 costs were attributed to necessary system modifications and the high labor costs of variable run times. Scheduled five-hour jobs could be stretched to eight hours or more by system errors and to as much as twenty hours when unplanned maintenance was necessary at busy times, yet overall potential savings still produced a planned positive cash flow in the fourth year and a net profit from labor savings in the fifth. Although machine and labor costs were found to have exceeded expectations by $6,373, or 23 percent, Beise, on the basis of analyses that suggested that the loan system would eliminate 200 man-years of clerical activities, approved the second IBM 702 for delivery to Los Angeles in June 1957. In 1956 Zipf appointed a number of bank managers who relied on the IBM 702 or were interested in automation to an advisory council charged with appraising bank procedures and suggest- ing automated-processing improvements. Potential plans were re- viewed with this council, which also suggested new applications to Zipf. The annual progress summary for 1957 noted forty-three suggestions, a number of which were incorporated into 1957 activi- ties or a 1958 plan. These included such improvements as five new services for Timeplan loans, automated automobile insurance re- newal, and discontinuation of delinquent loan notices, for which the new system had eliminated the need by focusing on collection procedures. Discussion of Building IT Competence Years Senior and systems management developed a set of habits that gave the bank technological leadership in the use of computers in banking. The members initiated technology scanning of competitors and suppliers and perfected it with experience. They moved quickly to invest in research or early developments, often in parallel, to ensure that their approach stayed at the leading edge and better understand its strengths and weaknesses. They naturally brought these discussions into the management committee and assumed quarterly reviews and full-scale analyses of new technology stan- dard procedures for running a bank. For 1955, this was a unique bank. In this process, they became competent at managing the com- plexities of computer systems to reduce costs and provide differenti- ated service. The bank’s senior management had begun to understand the need for changes and the significance of cost savings in automating paper processing with computers. The costs of processing loans had 54 been reduced and accuracy improved by the 702 system, with a base for doubling volume at marginal increases in cost. For a fixed investment, working computer system costs were, up to a point, independent of changes in volume. However, the fixed-cost struc- tures were complex. There were significant up-front costs for train- ing and programming as well as for equipment. Further, the state of development of electronics and programming made precise esti- mates of functionality difficult. It was essential to set objectives, deadlines, and cost guidelines and trade off among the three. Even- tually, however, the deadline had to be adhered to, and functional- ity was restricted to control cost. The managers learned that at the current state of the technology, computers were not necessarily cheaper than punched cards and were more rigid and costly to maintain. The bank’s management team and system staff gained an under- standing of how to design and build computer systems. On the positive side, they learned what applications would reduce op- erating costs and how to design systems to improve reliability and accuracy. To obtain this benefit, they learned the nitty-gritty essen- tials of computer-based systems and the importance of redundancy and reliability. They developed a strong sense of the state of the art in electronics and the reasons the current technology was expensive and unreliable. They learned about emerging technologies, the problems these innovations might solve, and those areas which remained significant uncertainties. This perspective, rooted in a pragmatic systems approach of considering cost versus speed and capacity, evolved into an appreciation for the art of the possible, economically as well as technically. The SRI’s learning-by-doing de- velopment of ERMA had alerted them to the importance of compre- hensive planning for a computer center. The ERMA experience provided the team perspective on all as- pects of implementing a computer system and the necessary lead time required to meet deadlines. It was able to plan and construct a fully operational environment that allowed its 702 to roll in and start up quickly, while at least one bank took delivery on a computer before beginning to build the space. The 702 experience convinced the bank management that programming was time consuming and required considerable testing. In addition, it discovered the impor- tance of exchanging information to learn of problems and solutions as it went along. It initiated and practiced a team approach to sys- tem development. It learned that programmers had to provide com- BANK OF AMERICA oO plete documentation and that running and maintaining systems re- quired well-defined operational procedures. Beise and Dana learned the necessity of management analysis. Careful planning was essen- tial to building cost-effective systems. Most important, the team learned the value of knowledgeable, well-trained people who can solve complex problems quickly. The SRI experiments tempered the management’s expectations about the reliability of electronic systems: they failed unexpectedly. The operation was highly dependent on quick, responsive actions by alert individuals. Repairing breakdowns took time and usually required restarting of the entire procedure. Because banks depend on overnight processing for knowledge of their cash positions at the start of the following day, it was essential to finish processing every night. The development of backup procedures and emergency actions was an early concern of the team. Finally, Beise and Zipf concluded that it was equally important to mold the computer sys- tems to their needs, and that existing technology could not com- pletely satisfy those needs. By the fall of 1955 the team consisted of relatively sophisticated computer managers. At the time, several banks had automated loan processing and two large banks were experimenting with alternative check-process- ing systems. The Chase Manhattan Bank was working with the MIT Laboratory for Electronics to design and build a system — a com- puter referred to as Diana, the ‘“Goddess of the Chase.” The First National City Bank was collaborating with an International Tele- phone and Telegraph subsidiary in Antwerp, Belgium. Both proj- ects relied on slave systems, with checks placed into transparent pockets for sorting and with human encoding at the input stage. The subsequent proof process was electronic. A few banks, includ- ing the County Trust of White Plains, were experimenting with books of punch-card checks. Following the announcement of ERMA, all shifted to planning for MICR-type processes.” Finally, they had initiated management procedures for dealing with system issues within a small clique of managers. This group knew how to deal with the technology in terms of costs, risks, and rewards. The ERM experience had shown the value of carefully tracking the system-development process and phrasing questions in bank-processing terms. They appreciated the trade-offs between function, access speed, and cost, realizing that the use of computer technology was in constant, rapid change. The 702 implementation had demonstrated the learning required to achieve technical compe- 56 tence in developing and operating a system and gave them the confidence to expand. The traveler’s check project confirmed the value of printed information and taking a system point of view. Expanding IT Competence: 1956-1958 By the fall of 1956, data processing at Bank of America had grown from one IBM 702 in an air-conditioned room in San Francisco to two full-fledged data centers, one in San Francisco and one in Los Angeles, each with an IBM 702 and a thirty-person support staff, plus thirty temporary staff to handle data conversion. The bank’s seasoned systems-development and programming staffs had estab- lished proven track records and were growing at the rate of 30 percent per year. The close ties to senior management that resulted when Zipf was promoted to vice president reporting to Dana enabled S&ER to de- velop a broad research and development program within its charter to ‘function as an internal consulting group [with] authority to initi- ate studies and projects in instances where a preliminary evaluation of an application suggests it is justified.’”!! For any project it under- took, Systems and Equipment Research had responsibility and au- thority for economic evaluation of the application, systems design, evaluation and selection of equipment, site preparations (if re- quired), and installation, conversion, and daily operation until a stable routine was established — essentially complete control of the system-development life cycle. S&ER maintained a list of potential applications that would pro- vide significant payback, and Zipf sequenced these to reduce expen- sive infrastructure development. An example was the complete re- write of tape files, which was embedded in a project to convert all credit applications. The high marginal returns covered the invest- ment in infrastructure. Zipf met with Dana regularly to review prog- ress, and both met with Beise to keep him informed. Quarterly, Zipf discussed a portfolio of projects with the operating committee of senior managers; annually, he submitted a proposed budget and longer-term program plan to the management committee for ap- proval. He generally provided a two-year program of work, which always included two or three research projects such as remote input or modification of standard machines. BANK OF AMERICA 57 Manufacturing ERMA Following the announcement of ERMA, Bank of America faced the task of selecting a qualified manufacturer to build thirty-six of the machines for use throughout California. A bank team outlined four criteria by which to judge prospective manufacturers: techno- logical ability, financial stability, reputation and size, and cost of the proposed system. The approximately thirty companies that visited Stanford Re- search Institute to observe the prototype and submit some form of proposal ranged from such predictable contenders as International Business Machines (IBM) and Remington Rand to companies as remote from electronics as General Mills and United Shoe Machin- ery. By late November the bank had arrived at a short list of four manufacturers, each of which was invited to make a presentation. Three of the four finalists: IBM, Radio Corporation of America (RCA), and Texas Instruments (TI) were expected contenders. Gen- eral Electric (GE), a newer entrant, had experience only in military computer systems. The companies’ final proposals were submitted to the bank in February 1956. IBM, although a logical choice, was suspect relative to its intentions (a 1971 report suggested that IBM might have been planning to shelve the technology). RCA, although in the final list, also was not considered seriously, leaving TI and GE. Texas Instruments’ plan was to provide the requisite functionality through staged development of a transistorized computer. Payment to Bank of America for patents and rights ranged from $5 to $17 million over six to eight years, in addition to which it was antici- pated that the bank would realize $135,000 in annual savings. TI strongly recommended that the automatic input system be devel- oped with SRI. General Electric, the dark horse in the competition, had no publi- cized digital computer experience and no organized unit-developing computer systems. GE’s proposal encouraged advancing SRI’s sys- tem and using transistor circuitry wherever possible. The proposal showed how new technology could increase reliability and speed while reducing processing costs, and a work program called for GE engineers to collaborate with SRI engineers on the initial design stage. SRI engineers overwhelmingly favored Texas Instruments be- cause of its demonstrated technological know-how and interest in 58 extending a number of SRI innovations. The bankers, however, favored General Electric, whose $30 million proposal was consider- ably lower than any of the others and specified a million-dollar default to be paid to Bank of America if the machine was not pro- duced. Because TI’s more costly proposal specified a down pay- ment, the bank was concerned by what it perceived to be the company’s shaky financial circumstances. Ultimately, the bankers prevailed, and GE was awarded a $30 million contract to build the thirty-six ERMA computer systems. The contract called for a de- tailed design proposal by December 31, 1957. PROPOSALS AND COUNTERPROPOSALS. Once GE recovered from its surprise at being awarded the prestigious contract, Bob Johnson was recruited from its Schenectady electronics laboratory to form and lead a development team. Owing to severe time constraints, Johnson and his team decided to design and develop the hardware logic, assembler language, and control program in three parallel efforts — incredible goals that were nevertheless realized. The team set three objectives: design a reliable computer that could perform necessary functions without strain, given existing capabilities; write assembler programs to perform the necessary banking functions; and develop peripheral hardware to create sorted input tapes. The bank was to design the latter jointly with NCR. In parallel with the GE effort, Al Zipf and his team, under assis- tant vice president of systems Reg Carlson, had been making a detailed analysis of check processing in the Los Angeles area, the fastest-growing customer base. Believing that GE needed more sys- tems guidance, in September 1956 the bank gave GE a counterpro- posal that detailed check-processing activities at the branches and added proofing to the system. The bank believed that paper handling was key to check-proofing operations; simultaneously proofing and sorting checks to their sources in account order and generating a dollar amount control tape would reduce paper proc- essing to a minimum, as checks would have to be sorted to tape only once, after which all processing would be from magnetic tape. Proofing, which had been in the original, was lost in the final SRI system design. S&ER’s proposal restored it, causing a flurry of meetings among the bank, GE, NCR, and SRI. Although GE and NCR were concerned about the extra cost and complexity of adding proofing, all recognized the market value of doing it, and discus- sions focused on how best, not whether, to implement the function. The interest and demonstrated flexibility of the vendors led Beise BANK OF AMERICA 59 and his team to conclude that GE would probably fulfill its contract, and Zipf was asked to develop for the bank’s board of directors a proposal identifying the costs and benefits of the proposed system (Table 3-1 compares expected cost for the GE ERMA with competing systems of the day).’? Analysis was favorable due, in part, to recov- ery of cash from systems depreciation, expected growth in proc- essing activities at relatively constant cost, and projected labor sav- ings from the new system of 51.4 percent direct clerical labor hours, or $46,566 per month, for the Los Angeles branches. The proposal was subsequently approved. PREPARING FOR ERMA. Planning for the implementation of ERMA began in late 1956 and continued throughout 1957. ERMA systems were to be installed every other month during the first year and every month during the second year. The first system was to be installed in San Jose by December 31, 1959, the thirty-sixth in San Diego County on February 28, 1961. Each would require a trained staff of seventeen and total training time of 221 man-months. With ABA specifications finalized in March 1958, following more than two years of discussion with manufacturers, the bank continued rollout of its standard MICR checks for nearly two million accounts. Over the following five years, Bank of America spent more than $3 million teaching other banks and printers how to print MICR checks and test the quality of printing for character definition and signal strength. THE FINAL PUSH TO COMPLETION. In the fall of 1958 the GE—Bank of America team hunkered down to develop a working model of ERMA. All components were in the process of being debugged, with connection planned by year end. A working system for Decem- ber 31 handling of 100 accounts proved that the system could pro- cess checks. Zipf accepted the ERMA system from GE as meeting the contract requirements on December 30, 1958. But a contract that spelled out no functions, only the processing of a specified number of checks at a set price, was open to varying interpretations. Zipf and Mel Gienapp, manager of the bank’s data operations, recruited a team of thirty seasoned operations managers to be trained as ERMA programmers to serve as backup. Starting on the 702, they switched to the emerging ERMA language. An off-contract compro- mise on proofing needs, reached in late February, called for GE to expand the core of the main computer hardware to allow the bank to move quickly to automate proofing as the systems were deliv- 62 ered. Bank of America was to provide most of the programming support needed to code the applications. Organizational Learning during Expansion The maturing of the bank’s organization is evident in its ability to develop two complex system expansions and at the same time continue a research program and provide new services. The need for detailed, long-range planning for a service-oriented computer system was well understood as a prerequisite to guiding implemen- tation and conversion of computer-supported processing. The man- agement committee recognized that human planning was at least as important as preparing for equipment and buildings. The bank’s experience demonstrated the importance of involving key senior management in reviewing future system developments. Senior management was a part of the ongoing process, which could become intense when important decisions were to be made. Plan- ning never stopped. The state of current demand, future demand, and expected alternatives was reviewed at least quarterly. Tracking outside developments was a full-time activity. Senior managers con- tinuously developed a portfolio of computer-based product services to meet and influence customer needs. This had evolved naturally from early reviews of customer needs and was refined with the rollout of the 702 and ERMA. Monthly, senior management moni- tored exception to plans on the status of equipment and applications of new developments, always considering cumulative savings and new adaptations of existing systems. Equally important, management developed the complementary assets to nurture and support systems and gained perspective on the lead times required to develop support. Space, training, utility support, and backup procedures all had to be planned, maintained, and factored into the “cost” of the system. Management’s acquisi- tion of pragmatic competence led it to appreciate the necessary level of detail, the lead times, and the importance of people to the success of the system. Charles Conroy’s early difficulties in securing suit- able printing made the team conscious of how broadly a new system affects existing practices. Initially, printing seemed a minor detail, but it proved to be a major problem that had to be solved for the system to work. SRI and bank employees became printing experts and that knowledge became a competitive edge. The success of ERMA was due in no small part to the bank’s effort in training independent check printers. BANK OF AMERICA 63 As technology managers they had fashioned an evolving technol- ogy strategy. They managed a broad spectrum of external sources while continuing an internal inventive activity that expanded proc- ess and product design efforts. They had also acquired an under- standing of and skill in developing specialized IT with ERMA. They tracked their competitors, learned new ideas, and confirmed their policies with regard to the importance of investing in people. They formulated a program to expand the scope of applications with the 702 and began to gain experience in general as well as special- purpose systems. They had developed an efficient electronic bank- ing factory and moved to operational dependence on IT. Establishing the Banking Industry Dominant Design: 1958-1964 In late 1958, Systems and Equipment Research progressed from automating to include exception reporting, trend analysis, and no- tice of time-dependent actions, a move to informate as they auto- mated. IBM 702 use was expanded to increase management support for loans and mutual funds and add such functions as bond invest- ment, branch clearings reconcilement, accounts receivable, and cor- porate trust. The trust system was developed to provide timely information on due dates, coupon requirements, and other opera- tional activities of portfolio management, including inventory man- agement and accounting and analytical investment portfolio eval- uation. An S&ER program initiated the same year to develop standards, due dates, and cutoff points for exception reporting on overdue loans helped managers identify out-of-control situations by tracking actual results rather than merely identifying exceptions for management analysis. Most loans were being tracked by 1959. S&ER clearly had progressed beyond the automation of existing procedures to utilizing programmed procedures on electronic data to improve customer service and deliver new services to the branches and credit offices. Meanwhile, an S&ER team working with the bank’s credit man- ager for retail businesses developed a design for a timely exception- reporting system that would build upon the new systems. By the end of 1959, the bank had extended exception reporting to all loans, balances, and payment procedures, and a number of analytic pack- ages supported trust and loan officers in portfolio management. Management of large commercial accounts and automation of the 64 general ledger were untouched. Commercial banking did not seem appropriate for inclusion, as it would yield no cost savings, and in any case, managers continuously reviewed their credit accounts to provide personal service to their clients. In April 1959, twenty newly trained programmers and three sea- soned IBM 702 programmer-managers began working with the GE team to test the production ERMA system. With an August comple- tion date for bringing up the San Jose system and a parallel installa- tion of a second ERMA system under way in Los Angeles, activity became intense. A bank team headed by Tom Russo, a systems manager, had developed a proofing system and set of procedures for implementing the bank’s proposed operations, which were tested and implemented in San Jose in the fall. Against all odds, and in the face of Stanford Research Institute’s initial skepticism and the stormy start of the Bank of America—GE relationship, GE produced ERMA on time and within budget, a matter of great pride to those working on the project. ERMA was a far different machine from the computer SRI had constructed three years earlier. The state-of-the-art, programmed computer with automatic check sorting and magnetic character rec- ognition input took advantage of progress in many areas, including transistorization and the latest data-processing techniques. The cen- tral processor’s command structure and peripheral equipment were especially designed for Bank of America’s accounting system. A 1959 analysis of ERMA’s economic impact showed savings in- creasing at a faster rate than cost, owing partly to a greater than expected volume of processing resulting from higher than projected numbers of customers and increases in check usage. Original esti- mates were for 1.98 million accounts; by the time the system was implemented, there were 2.3 million. More accurate check proc- essing, coupled with the elimination of 2,332 bookkeepers, helped to reduce float and expand the customer capacity of branches and variety of services. Opening ceremonies for ERMA, held in 1960 at three different locations connected by closed-circuit television, were hosted with great fanfare by Ronald Reagan of General Electric’s Masterpiece The- ater. With the installation of the last ERMA in June 1961, 13 ERMA centers, employing 32 computers, were servicing 2.3 million check- ing accounts at 238 branches. Conversion of the bank’s 2,382,230 savings accounts was begun on January 11, 1962, and completed on February 23, 1962. BANK OF AMERICA 65 Exploiting an All-Electronic Base Shifting data processing to an all-electronic base had opened a new set of opportunities. There was no longer a crisis to solve, only economy of scale and experience in providing systems to build upon. Over the next seven years Bank of America, under the leader- ship of Clark Beise and Al Zipf, expanded the domain of informa- tion technology to link to customers, support the introduction of new products and services, and improve management control. IT support became a means to market expansion, not just a way to achieve cost savings, and the availability of up-to-date information fostered more effective control throughout the bank. Believing that with ERMA he could economically open more branches in smaller communities than had previously been possi- ble, Beise aggressively pushed branch growth, acquiring and con- verting small banks to branches. Branches grew from 617 in 1957 to 871 in 1964, with a peak addition of 81 in 1961. Bank of America owned 40 percent of the branches in California, which accounted for a 44 percent market share (because its branches could serve more customers). At a board of directors review of ERMA on July 19, 1960, Zipf presented a detailed cost analysis of the 1958 proposal for savings for 1963 with a 1960 analysis based on two years of actual experience. Compared with the former manual system, the cost would have been $15,880,000 versus an expected total of $9,775,000 or a $6 million—plus saving, as shown in Table 3-2. Since the internal supply of available and interested bankers could not keep up with demand for systems personnel, a new ap- proach was adopted — recruiting from engineering schools and training the beginners for a career in systems. The key ingredient was not the electronic boxes, but capable people who could use the boxes effectively. Zipf, Gienapp, and Herb Swenson of S&ER personnel carefully worked the bank’s bureaucratic personnel sys- tem to make their job classifications of systems personnel equal to middle-level loan officers or branch managers so as to maintain externally competitive salaries. They developed career paths from operations to programming systems to analyst and eventually to manager. Although the bank’s system development organization was growing rapidly, the operations organization provided faster promotions for professionals. Gienapp, the human resource leader of the group, creatively documented the functions of the new jobs in order to substantiate salary levels and job titles competitive with
outside employers. However, while individually rewarding the cre- ation of a two-culture environment — fast-track techies and tradi- tional bankers — who required much longer to be promoted — began to isolate systems personnel from other bank employees.
With S&ER overloaded during the ERMA and IBM 702 projects, Howard Leif, asked by Beise to identify other services that might benefit from the processing potential of the new computer systems, had contracted with Arthur Andersen for an analysis of alternatives. BANK OF AMERICA 67 Among other projects, Arthur Andersen had suggested introducing a credit card. Western Union had issued credit cards as early as 1914 but succumbed to expensive operating costs and credit losses. Since the computer could potentially reduce costs and provide tight credit control, Leif recommended that the bank introduce a credit card; a program was initiated in 1958 under the direction of the assistant controller. Development of system design was subcon- tracted to an outside supplier, which created a debossed card sys- tem (depressed versus raised character). The system was to be tested in Fresno in 1959 and, if successful, gradually rolled out to other branches. The plan was to move city by city, issuing credit cards to the bank’s better customers, beginning with the valley cities of Sacramento and Redding and refining the system before taking on the large metropolises. As Bank of America prepared to enter Sacamento, the First West- ern Bank of San Francisco announced its intention to issue a credit card statewide. With Beise overseas at the time, Leif and the man- agement committee decided, on the basis of a trial, to preempt the competition by immediately rolling out Bank of America’s card statewide, beginning in Los Angeles and San Francisco in early