|
|
Circles of Risk
by Jay Golter and Paloma Hawryl
Introduction
Throughout a typical day, computer systems facilitate an extraordinary number of transactions initiated by each individual and business. We are used to occasional, isolated malfunctions of these systems and have become resigned to the attendant disruptions. However, because of various shortcuts that computer programmers have taken over the past few decades, a large number of disruptions may occur simultaneously with the approaching turn of the century. As explained below, many of these errors will occur because dates in which the year ends in "00" will be misprocessed. Additional disruptions will occur because the microprocessors that control some machinery and equipment will not work after the date changes -- even though from casual observation one would not suspect that dates are used in the machinery or equipment's operation. The range of associated problems has therefore been referred to as "the Year 2000 problem" (Y2K). If the situation is not corrected in advance, some of these disruptions may be serious indeed, life threatening. However, because the number of systems and applications in the problems could emerge is so large, finding and correcting all of them in time is a daunting task.
This paper discusses the origin of the problem; all of the ways in which a typical business could be exposed to Year 2000 risks; and ways in which these risks can be managed. Appendices identify several dates during the next two and a half years that could pose problems, and describe steps that businesses should take to manage their exposure to Y2K disruptions among their important vendors. The article concludes with a listing of sources for additional information.
Background
Early computer programmers worked around a variety of constraints imposed by the emerging technology. Two of the biggest constraints were the usable memory of the machines, and the costs of storing data. One technique used to circumvent these limitations was to represent dates with an implied century. For example, a date field holding the value "01/01/56" meant "January 1, 1956" not "1856" or "2056." Use of this convention reduced the amount of storage required (more records would fit in the same space if room did not have to be allocated to hold "19" in every date field of every record), and improved processing speeds (with fewer pieces of data per record being held in the computers memory, manipulations could be performed more efficiently). For the few applications in which valid dates could span a century (for example, birth dates for the general population in which some people are 1 year old and others may be 101 years old) the specific date fields would be expanded accordingly. A mortgage system might have four-digit years for "maturity date" but two-digit years for "opening date, "last payment date," "next mailing date," and so forth. The technique of representing years with two digits was also used when the microchips that are embedded in many kinds of machinery and equipment were hard-coded. Other programming shortcuts, as well, were applied to dates in ways that can create problems by the end of the century (see appendix 1).
Computer systems use dates for a large number of functions. One is to determine how long something has existed (for example, to schedule maintenance or replace components in a manufacturing plant): the computer makes the determination by subtracting an earlier date from the current date. A system that orders replacements for a particular part every five years might record that a part was last installed on June 1, 1992; on June 1 1997, the system would calculate that "97/06/01" - "92/06/01" represented five years and that the part needed replacing. In the year 2000 however, the system might conclude that the part was -97 years old ("00/01/01" - "97/06/01" equals -97 _ years). How the computer would then proceed would depend on how the programming instructions had been written. Some systems might recognize the calculated age as invalid, and generate a report listing such occurrences for further investigation. Other systems might leave the replacement parts unordered, since they would never have reached a calculated age of five years. In the second case, the part would eventually wear out and fail. Depending on the function of the part and the machinery it belonged to, this failure could result in the production of defective merchandise, significant down time while the defective part was identified and a replacement was ordered and installed, or, in the worst case, serious injury or loss of life if the part was essential to the safe operation of the equipment.
To the extent that the eventual consequences of using date shortcuts were contemplated during the 1960s and 1970s, it was believed that the underlying programs would be replaced well before the century changed and that if they were not, there would be plenty of time to correct the problem. Unfortunately, this attitude endured long enough so that some software written even as late as the 1990s contains the same date problems, and some equipment being sold today will malfunction in the next couple of years. But with the century now drawing to a close, the time left in which to correct this problem is rapidly shrinking.
The actual amount of time required to modify a system that has a century date problem can vary significantly. The relevant factors include the age of the systems in operation; the number of systems in operation; the number of programs and lines of code in all systems; the number of computer languages in which programs are written (and the availability of programmers with skills in those languages); the quality of the system maintenance that has been performed (in particular, the extent to which documentation explains the purposes of each computer instruction); the extent to which electronic data are exchanged with other entities; and the extent to which the organization depends on equipment with embedded microchips that may not function properly in the next century.
In most cases, modifying any part of a program that has date problems is not especially difficult. What is difficult and what makes Year 2000 remediation programs especially challenging and time-consuming is the need to (1) find all of the places where date problems might lead a program to miscalculate or terminate; (2) coordinate the repair of each part of the overall system so that no one repair interferes with the operations of other parts of the system; (3) test the repair by using data that accurately mimic the processing that will occur in the next decade; and (4) complete the project without granting any time extensions.
Scanning for date logic, modifying code, and, especially, testing the revisions as units and as parts of an integrated system, as needed to bring a large scale system into date compliance is time-consuming and therefore expensive. The estimate used by many firms to budget for the conversion project has been $1.00 per line of code.2 But, as the shortage of programmers qualified to work on the problem intensifies, remediation costs will rise.3
Significant expenses will also be incurred in the process of finding, testing and repairing or replacing vulnerable pieces of equipment and machinery with embedded systems -- and these costs may be more difficult to estimate than the cost of renovating software. Some replacement parts may not be available or may not be compatible with older equipment. For those products that prove to be noncompliant and must be replaced, shortages may occur or replacement parts may be unavailable, because the original manufacturer is no longer in business or the product line has been discontinued. Although the source of a problem may be merely a minor component, if the component is scarce or unavailable an entire piece of equipment or system may have to be replaced.
Concentric Circles of Risk
Every firm faces a variety of risks from Year 2000 problems. These risks, like ripples in a pond, move outward from the center of the firms operations. The central risk resides in the firms core "mission critical" information systems. Traditionally these functions were housed on mainframe platforms and were centrally maintained by the firms own staff. Recent trends in automation system designs and in business practices have moved much of this activity onto other platforms and, in a growing number of cases, to outside service providers. Although the viability of the firm may depend on these core systems, their operation and maintenance may no longer be under the firms direct control. The second circle of risk encompasses networks or desktop PCs that may be important to the day-to-day operation of the firm or, at a minimum, may support employees performing their jobs. Many of the applications running on these platforms have been placed in the control of end users. The third circle of risk involves exchanges of data with third parties. This type of activity has grown extraordinarily in recent years, with the result that firms are increasingly dependent on these interchanges for many key business activities. The fourth circle of risk involves activities that are not part of the data processing systems, but remain within the operational walls of the organization. This risk involves equipment built around microprocessors that operate with internal calendars. Extending outside the company, the fifth circle of risk is composed of business partners -- those organizations that provide essential services or are key customers. Finally, the sixth circle of risk is represented by the macroeconomy, which may be adversely affected by the disruptions that result from efforts to prepare for and adjust to the uncertainties posed by this unprecedented challenge and from the failures of some to prepare successfully for the date change.
Because of the limited time remaining before the new century arrives, organizations must focus their efforts on the elements most critical to their ongoing operations. For each mission-critical business function (including marketing, sales and order processing, production, delivery and distribution, financial operations, and administration and management), the organization should examine current processes against the circles of risk model to identify where vulnerabilities lie. Strategies must be developed to assess the likelihood of failure, to propose the best method of mitigating the problem (repair, replace, or work-around), and to develop contingency plans if the resolution chosen should fail.
First Circle: Core Information Systems
Larger enterprises generally have developed or purchased automated applications to process and manage their critical business information. Traditionally, these data systems were maintained and controlled by the company's own professional information management staff operating within corporate-defined standards for updates, processing and output. Functions that are likely to be automated include payroll and benefit administration, inventory management, accounting, accounts payable and receivable processing, and scheduling (of staff, production, or deliveries). The software used to run each of these processes may have been developed by an in-house programming staff or purchased off the shelf from a vendor, or may represent a combination of off-the-shelf products and custom-developed applications. While these systems used to reside on mainframe computers, in recent years many organizations have developed other, more distributed platforms for these functions. Often, what were once considered core systems may even be managed on-site or off-site by an outsourcer. These arrangements may leave the outsourcer as the only entity with knowledge of the internal workings of the applications program, even though any Year 2000 impairments to those programs represent a serious or even fatal problem for the firm.
To date, the most intense Year 2000 compliance work has been in data processing departments ensuring that the core systems will continue to function after the millennium changes. For operations to continue unaffected, many elements of the system need to be scrutinized, modified, tested and replaced. This process must be conducted on all important components of the system in a coordinated fashion so that the replacement of one part of the system with a century-compliant version does not interfere with the functioning of another part of the system with which it interfaces.
In some cases, the hardware on which important applications run will itself be unable to process data after the 20th century. For example, IBM has announced that it will not provide upgrades to system 360 mainframes (1970s technology). Some of these platforms may still be in operation at firms that were unsuccessful in converting to newer equipment. Replacing a mainframe platform is rarely an easy proposition because some of the software running on the old system may be incompatible with the new system, requiring that new application software be purchased or created. Some of the complexities of replacing applications software are described below.
Assuming that the hardware platforms are capable of operating in the next century, the next core area of concern is the operating systems. Operating systems instruct the computer on how to read and follow the instructions that comprise the application software. Elements of the operating system include media software, which enables the computer to read and write data in electronic formats such as magnetic tapes or optical disks; language compilers, which enable a computer to understand programs that have been written in different software languages; and computer job scheduling systems. The problems inherent in upgrading hardware are comparable to those in upgrading operating system software: it is necessary first to test to see whether all of the applications currently being used will work with the new operating software. Over time, some data processing centers may have deliberately chosen to forgo upgrading their operating systems, so that now, for example, only an early version of a language compiler might read some of the programs that the firm continues to use. Upgrading this firms operating software will also require upgrading the language compiler. But upgrading the language compiler will require that the application software written in that language be converted or modified. Originally, the improvement in performance that the new operating system would have provided might not have been worthwhile. Now, however, all of these conversions must be completed, and in a fairly short period, simply for the firm to be at a point where the hardware and operating systems are capable of functioning in the year 2000.
The next layer of the system that needs to be examined is the applications software. These are the programs that, for example, run the general ledger system, track order processing, or contain the customer information files. Some of these applications may have been purchased from software vendors (Commercial Off-the-Shelf Software, or COTS) and some may have been developed by in-house programmers. Hybrid situations are also common. Often a COTS program will have been modified by the in-house staff to accommodate the firms unique needs. At other times, the COTS developer may customize the software to match the operational needs of the firm. For example, an application may house a database that was developed in-house and that may be accessed with a COTS program that was modified by the firm. At the time this article was being written, Year 2000 patches or upgrades for many COTS applications had not yet been released. However, in the near future the software vendor should be releasing newer versions that will function during the next decade (or else go out of business).4 Once again, extensive testing must take place before the new versions can be installed. The difficulty of testing and installing will increase with the number of modifications that the in-house staff has developed. Furthermore, individual firms may have chosen not to upgrade with the previous two or three releases. In such a case, it may be necessary to install an intermediate version of the application before installing the final, compliant version.
Some of the greatest challenges will involve applications that were created in-house. These programs must be examined line by line for places in which dates are used as part of an instruction. Once these date-related processes are identified, it must be determined if the instructions represented by that section of code will properly execute when dates from the year 2000 are processed. Modifications must be made to accommodate the new century, and the modified application must be tested to ensure that the changes have not inadvertently affected another part of the program. Locating date-sensitive code may be complicated by the fact that a programmer may have used dates in ways that are not obvious. For example, a programmer may have created a temporary signal within the program to indicate that some processing routine would be necessary for certain records. The signal may actually contain date information, and the programmer may have named the signal after his or her pet at the time. A Year 2000 remediator who finds a line of code that reads "If Spot is greater than 64 then do routine X" would not immediately realize that date information was being processed.
Repairing in-house code can be complicated by two additional factors. First, the code may be written in a very old programming language that has not been taught to new students for many years. In the past, whenever the program needed to be modified, the data-processing center might have relied on a few veteran staffers who knew the particular language or contracted the job to outside vendors. Unfortunately, while these resources might have been adequate to handle occasional jobs, they may not be sufficient for the job of combing each line of each program in that language to look for date fields and date logic. The alternative is to replace the program, either with a COTS product or with a new program written in a more common programming language. However, converting to new software can often be difficult and time-consuming; existing files must be modified to accommodate the formats used in the new software, and the software must be tested to verify that it handles all of the functions that the old system performed. Employees must be trained in use of the new system (inputting data, reading reports, taking inquiries), and procedures must be established to replicate any important functionality that was lost when the old application was retired. Furthermore, to minimize the complexity of a systems conversion, historical information from the old system is often dropped from the new system. During the early days of operations, therefore, while the new on-line histories are being built up, employees have to use other tools, like CD ROM files, for information that had previously been readily available on-line.
The other factor that will influence the difficulty of converting in-house applications is the extent to which those old systems are well documented. In the early days of data processing, computer codes were written and implemented without much thought to how easily the code could be modified latter. Over time, as data processing departments experienced the difficulty of making changes to these early programs, they established new methods and standards. For example, English-language comments or narratives should accompany the code, describing the purpose for each section of the code and the logic that the system will follow. But partly because of the difficulty of untangling the old sections of code and partly from a sense that "If it ain't broke, don't fix it," some old, undocumented programs are still being used. Now they must be examined for date sensitivity. In some cases, this task is further complicated by the lack of source code.5
Over the past couple of decades, most data-processing systems have been enhanced by the integrating of different components. For example, a system used to process customer orders received by telephone may first pull up name and address information from a customer database (along with a summary of information describing past contacts with the customer), then determine if the merchandise being requested is available from an inventory system, perform a quick credit check on the customer (perhaps with an outside servicer), determine the cost of shipping the merchandise by accessing another database, initiate the processing of the order, provide data for an accounting system, and create a log of the conversation for an employee-performance evaluation system. Expanding the date fields in the file structure of the order-taking system without also modifying the programs that allow the various other systems to interface with it would be likely to cause several of these systems to stop functioning properly. Furthermore, if the information being exchanged with another system is a date, special bridge programs must be written to convert the newly formatted date to the format maintained in the other system. At some future time, the date format in the other system may itself be modified, a change requiring that the bridge programs be altered and tested before the new change is implemented.
One recent trend in data processing at large organizations is the construction of "data warehouses." In such systems, data from various applications are defined consistently so that each element can be viewed from a variety of platforms (that is, endusers from different divisions, using different computer systems, will all be able to access the same database). Such systems may involve multiple tiers of systems. For example, a processing tier, a data storage tier, and presentation software, may all work together to create a comprehensive system. These components may be developed, in part, with a variety of COTS software, vendor software, and applications developed in-house. By enabling several applications and platforms to operate together seamlessly, such system designs provide many benefits to a business. However, they create special management challenges in the areas of data control and data integrity, data translation, and transaction timing. Network performance and connectivity become an integral aspect of the application design and functionality. These issues complicate the process of making an organizations critical systems ready for the Year 2000.
Second Circle: Networks, Workstations, PCs
The search for an institutions vulnerability to Year 2000 problems moves outward from the systems controlled by a data-processing department to other systems that are wholly or partly controlled by endusers. Although the core functions of larger organizations usually reside on centralized systems, decentralized systems offer greater flexibility -- thus many important tasks have migrated to network systems, workstations, or stand-alone PCs. Common examples include e-mail and systems that enable files to be electronically shared (for example, between loan officers and credit review officers). In addition, many of the desktop applications (such as word processing and spreadsheet programs) used in the organization may be delivered to the user over a network.
Some firms might be able to function with these systems down for an extended period of time, but doing so would still be very disruptive and inconvenient. Other firms, however, have placed extremely critical operations on these systems and may not be able to function properly should they become dysfunctional. Early in its Year 2000 remediation project, each organization must determine how dependent it is on each of the applications that run on these platforms. Part of a Year 2000 compliance plan should include testing the network servers, bridges and routers; software applications; and the drivers that enable the applications to interface with the different components of the network; the central data maintained on the network; and the special programs (such as spreadsheets) that users created to analyze or manipulate data.
PC users, whether networked or stand alone, have often created spreadsheet or database programs that help them make important decisions. These users may not be aware of the need to verify that those programs will function properly after the dates change, or they may not have the experience to design adequate tests. Indeed, the application may have been written by a former employee who had greater programming skills than the incumbent. After the century changes, these programs may appear to be still functioning even though the results they produce are faulty. Therefore, firms must identify which of these programs are critical or important, and must provide support for users trying to test and convert them.
Third Circle: Third-Party Data Exchanges
The next circle of vulnerability involves exchanges of data with other entities. Even though an institution may have corrected all of its own data-processing systems, it may still be vulnerable if it is not prepared to read accurately the data it receives from other sources. One of the ways in which automation has developed over the years is by increasing the use of systems that exchange data between organizations. An example would be EDI (Electronic Data Interchange) systems, in which a major business and all of its suppliers exchange important data -- from initiation of orders through invoicing and payment -- without manual intervention. The widespread use of such systems complicates the Year 2000 compliance process: all of the parties to an EDI system must agree on how the data will be modified to accommodate the new century. As each side of the data stream modifies and updates its data systems, coordinating and testing the results with the counterparties become very important. Organizations that are connected to several different EDI chains may find themselves having to comply with a number of different solutions.
Exchanges of data in electronic formats may occur when entities file reports with government agencies, including the IRS; when businesses order and receive credit reports on potential customers; and when organizations exchange a variety of data -- including ACH transactions, and cash management reports -- with their banks. If all users of a particular system can not agree on data formats, each user will have to create programs that, upon receiving the data, determine how to modify the input so it is handled correctly. Finding and using the proper conversion program with each incoming data stream will increase the time required for processing each transaction, and the deterioration in performance could become a serious problem for high-volume, real-time systems.
Fourth Circle: Plant and Equipment6
Although the key area of risk for some organizations will be in their data-processing systems, other organizations are exposed to more serious disruptions from other types of Year 2000 failures. Many important pieces of equipment, including telephone switchboards, security systems, HVAC, and elevators, may operate with embedded microprocessors that use calendar functions. These pieces of equipment must be tested to determine how they will behave when the century changes. Furthermore, it is not always obvious that a particular piece of machinery incorporates date functions. For example, a buildings elevator system may have an embedded calendar that determines whether the system should follow a weekend pattern of responding to calls or a weekday pattern. Even more potentially disruptive may be the same elevator systems built-in maintenance schedule: if the schedule determines that too much time has elapsed since the last reported maintenance examination, the elevator may shut down until another examination takes place. Equipment used in the production process at different firms may have similar problems. Some manufacturing processes may rely on control systems that receive time-stamped data from sensors, compare the changes over time between readings, and then either signal an operator that some procedure should begin or automatically make some adjustments to the process (for example, closing a valve). If such control units incorrectly determine the sequence in which readings occurred or incorrectly calculate the time between readings, they may fail to perform properly. The failure could disrupt the manufacturing process.
To determine in advance which machinery will be impaired, an organization has to know how the machinery was designed, and what the specifications of the embedded microprocessors are. However, many organizations are having great difficulty uncovering this important information. In some cases, the manufacturers or distributors of the equipment may no longer be in business. In other cases, manufacturers produced products using components from various sources; the result is that devices with the same make and model number will perform differently as the turn of the century nears.
The potential failure of embedded microprocessors could expose some organizations to even greater risks than those they face if data-processing systems malfunction. For example, much of the equipment used in a hospital, including patient monitors, automatic drug-dosing devices, MRI and CAT scan equipment may rely on embedded technology.7 Failure of the equipment could result in serious injury or death. But hospitals are not the only firms that may face great risks from failures of equipment. For example, in Bhopal, India, in December 1984, an estimated 6,000 people died when a valve in a Union Carbide chemical factory malfunctioned. Many plants that use or produce similarly dangerous chemicals rely on "smart technology" to monitor and control the process, and some of these may be vulnerable to Year 2000 malfunctions.8
Fifth Circle: Business Partners
The next circle of vulnerability is located outside of the firm itself. All business organizations depend on suppliers to provide essential goods and services. These suppliers include manufacturers of components and firms that deliver supplies or finished goods. Many firms, however, have become even more vulnerable to potential disruptions within the suppliers operations, for during the past decade, seeking to reduce inventory carrying costs, they have moved to "Just-in-Time" (JIT) inventory systems. In preparation for the year 2000, some of these firms may decide to increase the levels of their raw-goods inventory. This could require them to rent storage space to accommodate the increase.
Organizations are also dependent on third parties that provide services such as equipment maintenance, building and grounds maintenance, and other services such as printing. Nearly all organizations rely on utility firms that provide telecommunications, power, and water. If any of these suppliers has difficulty providing service at the level on which the organization has depended, the organizations own operations could be adversely affected. Thus, it is important for all organizations to perform due diligence on their important suppliers to make sure that each has adequately addressed Year 2000 issues. If an organization determines that any of these suppliers is not ready for the date change, the organization must locate alternative provider or establish work-around procedures. Many organizations are now including language in all newly written contracts requiring the supplier to warrant that it will be able to perform in the year 2000. Although this may be a wise business practice, it is important to recognize that by themselves such warranties do not offer enough assurance to the purchaser of the service. Organizations should be prepared to assess the Year 2000 programs of their key suppliers, or obtain independent analysis of the suppliers plans. Appendix 2 describes the vendor management process in more detail.
Firms also depend on the success of their customers. Thus, it is appropriate for most businesses to engage in a dialogue with their customers about Year 2000 issues. The immediate goal of this effort is to motivate each important customer to develop and implement a Year 2000 remediation project, but at the same time the dialogue may achieve other valuable goals. For example, a business may learn that its customer has decided to shut down some production facilities in January 2000 in order to verify the Year 2000 readiness of each production process in a controlled setting before reopening the facility. In such cases, it would be important for the supplier to learn this ahead of time and adjust its business plan to reflect the modified demand for its goods or services. Businesses may also suffer if, in advance of the date change, customers lose confidence in the firms ability to navigate the difficult waters. Continuous dialogue about Year 2000 plans with key customers may help prevent such erosion from occurring.
Sixth Circle: Macroeconomic Repercussions
The final circle of risk to which an organization is exposed because of possible date-change problems involves the economy as a whole. The sales and income of most businesses are affected by the performance of the overall economy and Year 2000 problems could adversely affect the Gross Domestic Product.
The most immediate cause of economic disruption would be the large cost many firms will incur to fix their systems in preparation for the next decade. This cost includes the opportunity cost of not being able to undertake other projects during the remaining months of the 20th century, because resources are focused on Year 2000 conversions. In addition, some machines and equipment will have to be replaced before the end of their useful life. Some marginal firms may in fact choose not to incur the cost of a conversion project and, as result, may find themselves unable to remain in business.
Additional macroeconomic disruption will occur as firms plan for the date change. Because they will be unable to determine with certainty which goods and services will be available without interruption after January 1, 2000, many will build up inventories of raw materials and finished goods. This anticipatory stocking up is like the publics rush to buy batteries and various staples when a major storm is predicted. Indeed, individuals are also likely to engage in similar preparatory activities in advance of the date change. In these cases, even if no systems actually fail, simply the process of accumulating inventories and then reducing them back to normal, will cause some distortions in the overall level of economic activity.
A third source of disruption will be the actual failures of some systems or enterprises. Initial failures will be caused by the inability of individual organizations to fix mission critical systems in time. One analyst predicts that Year 2000 problems will create a 1 percent risk that any given Fortune 500 corporation fails, a 3 percent risk of failure for any given small firm (fewer than 1,000 employees), and a 5 percent to 7 percent risk for any given mid-sized firm (1,000 - 10,000 employees). The analyst notes "Mid-sized corporations ... have historically shown a distressing tendency to utilize quite a lot of software, but to be only marginally competent in how they build and maintain the software...There are about 30,000 companies in the mid-size range in the United States, and a 5% to 7% business failure rate would mean that from 1500 to about 2100 companies might close or file for bankruptcy as a result of the year 2000 problem. This is a significant number and it is an open question as to whether the impact of the year 2000 problem is severe enough to trigger a recession."9
As other firms that depend on the failed entities as key customers or suppliers are affected by the failures, a ripple effect will occur. Because most observers believe that other countries are less ready for the year 2000 than the United States, the ripple effect may especially touch firms that rely on overseas production facilities or for which exports constitute a large portion of their sales. Additional aftereffects may also be experienced by community businesses that serve large numbers of employees of failed firms. The magnitude of these repercussions will be affected by the extent to which additional disruptions take place. Any disturbances in the operations of critical infrastructure systems (for example, power generation or transportation, including air traffic control) will complicate the process of repairing damaged systems and returning the economy to normal levels of production.
Another important factor in determining the ultimate consequences of Year 2000 problems will be the ability of government entities at all levels to deliver services. For example, urban areas where traffic signals or subway systems no longer function or where 911 operations break down, could face great difficulty. And if the delivery of some government assistance program, such as unemployment insurance benefits, is disrupted by Year 2000 problems, the economic disruptions would be exacerbated.
Dr. Edward Yardeni, chief economist at Deutsche Morgan Grenfell, has written extensively about the Year 2000 problem and its potential effects on the world economy.10 Given his analysis of the remediation efforts to date of the federal government, the electric utility industry, the transportation industry, and other components of the economy, he recently raised to 60% his estimate of the likelihood of a severe global recession related to the Year 2000 computer problem.11
On a continuum, the United States and the world could experience anything from mere disruptions (a lot of time and money spent fixing the problem or cleaning up after systems malfunction) to recession (system failures causing many business failures) or even crisis (failures severe enough to cause deaths and economic depression). Where we end up on the continuum will be determined by how successfully each firm, government entity, and key nonprofit organization handles the conversion process in the remaining months of this century -- and months are all that remain.
Modern Business Trends
Several recent trends in business have added to the complexity of a Year 2000 risk mitigation project. They include: downsizing, outsourcing, use of automated communications systems (including the Internet), use of just-in-time inventory systems, industry consolidation, and establishment of sole-supplier systems.
Downsizing
Efforts to achieve greater operating efficiency have often led firms to make large reductions in staff. Although these initiatives may have been justified economically, they may also have complicated the Year 2000 remediation process. Layoffs may create loss of operational knowledge, loss of redeployable manpower, and reductions in employee morale.
Loss of operational knowledge. Over the past few years, many organizations have provided early-retirement incentives to older operations personnel. In some cases, the affected employees are computer programmers who may have written many of the programs that now need remediation, or may at least have known how the programs functioned. To the extent that newly hired or contracted programmers must now repair these systems, productivity will be lost as these people navigate a learning curve. Many firms have found it useful to rehire former programmers, either as employees or as consultants.
Another type of employee whose knowledge and understanding might now be especially useful are long-time operations personnel who remember the procedures that were followed before certain functions became automated. Many firms, if not most, will be limited to fixing only the most critical software applications before the deadline, yet the other operations may still be important and will need to be performed another way. Knowledge of how the processes were handled before automation will be helpful when these business continuity plans are developed. However, the persons most likely to remember how jobs were performed in the past are often the same persons who were targeted during the downsizing.
Loss of redeployable manpower. When a process that has been automated must be performed manually, the manual labor needed for the job may be hard to find. Although a firm may be able to hire or contract for temporary labor, quickly recruiting and training a large group of new workers and managing them is difficult. The fewer current employees available for reassignment, the greater the challenge becomes. One popular technique for making an organization leaner is sometimes termed "job enrichment." A vernacular term for the same technique is "piling more duties on each employee." In any case, organizations may now have fewer operational employees available to deploy at the breaches.
Reductions in employee morale. Often the employees targeted in a downsizing are the ones least likely to want to leave their jobs without an incentive to do so. This group includes older, risk-averse individuals, and it may also include individuals who want to preserve the value of their institutional knowledge. These workers are more likely to want to stay with the company during difficult periods. In buying out or laying off these people, the company may have not only lost a reservoir of goodwill, but also created an impression that corporate loyalty is not rewarded. In such an atmosphere, managing the stressful events that may accompany Year 2000 disruptions will be more difficult.
Outsourcing
In conjunction with downsizing, many organizations have been outsourcing (using outside contractors) a large number of activities. Therefore, functions (sometimes very critical ones) that used to be entirely within the organizations control are now performed by third-party firms. These functions may include: performing certain data-processing activities, assembling finished goods, warehousing and distributing of products, and delivering, installing or servicing products. Depending on the ability of the third party to manage its Year 2000 risks, outsourcing may complicate or simplify the Year 2000 project within the original organization.
Essentially, because every organization is part of the vast interdependent network that our modern economy has created, the only difference between an organization that outsources, and one that maintains in-house control of certain functions is where the lines are drawn between internal risks and external risks. An example of an organization where the risks are internal is one that maintains a delivery fleet. This organization will need to assess the readiness of software systems that schedule deliveries, assign routes to drivers, and keep maintenance records for the fleet. It also needs to determine if its vehicles contain any embedded systems that may cause them to malfunction when the year 2000 arrives. Although these tasks add to the organizations overall Year 2000 work load, the organization still maintains control of its own destiny in these areas, while having external dependencies on firms that supply spare parts, fuel, and anything else needed to keep the fleet in operation. In contrast, an organization that has outsourced the delivery of product will still have the same dependencies -- the same need for deliveries to be scheduled, routes to be assigned, and so forth -- but now they are one level removed. Primary responsibility for addressing the year 2000 readiness of these systems rests with an external firm. The organization must now determine whether the firm that delivers its products has a viable Year 2000 risk management program, and whether that program encompasses dependencies external to it. Ultimately, the decision to outsource will prove to have been beneficial if the firm providing the services is capable of managing its own Year 2000 project, or if an alternative provider of the service is readily available.
Just-in-Time Inventory
Many manufacturing firms have also improved their financial performance by adopting Just-in-Time inventory policies. In these systems, firms reduce inventory carrying costs by having smaller quantities of raw materials (and components) delivered more frequently. In some systems, these deliveries are made directly to the point in the production line where they are used, so that the expense of maintaining a raw-materials storehouse is eliminated. But the operating efficiencies that this creates comes at a price: increased dependence on suppliers performing according to the manufacturers specifications. Disruptions in the receipt of a single material can quickly affect the entire production process. Because each supplier will be battling its own Year 2000 demons, some firms may consider it worthwhile to build up temporary stockpiles of raw goods that would be used to smooth over any disturbance in normal deliveries.
Automated Communications Systems
The frequency with which new area codes are assigned in the nations telephone system is a sign of the extraordinary growth of communications networks. Much of this expansion has been generated by the development of new business systems, including Internet access, voice-response systems, and order receipt by fax machine. These systems often involve moving information through a large number of channels that, when they all function properly, are transparent to the users. In the aftermath of the year 2000, however, each system could become a weak link. For example, ordering a plane ticket through a travel agent on the Internet may involve eight parties -- each of which must be functioning for the transaction to be completed. They are: 1) the purchasers local telephone company, 2) the purchasers Internet service provider (ISP), 3) data lines connecting the purchasers ISP to 4) the travel agents ISP, 5) an airline reservation system computer (and the data lines connecting it to the travel agent), 6) data lines connecting the travel agent to a credit-card authorization network, 7) lines connecting the credit-card network to the credit cards issuing bank, and 8) the banks authorization system.
Industry Consolidation
During the past several months, mergers and acquisitions have been planned in many industries -- often involving combinations of large organizations.12 Unfortunately, merger can adversely affect an organizations ability to manage its Year 2000 problems successfully. Both the operational and the managerial aspects of a Year 2000 project may be impeded, and the effect may spread to other firms competing in the same industries.
Merging two unique organizations involves many challenges. In some cases, the challenge is great enough to disrupt the new firms delivery of goods and services. Recent examples include the merger of Wells Fargo Bank with First Interstate and the merger of the Union Pacific Corp with the Southern Pacific Railroad Corp.13
The planning and implementing of operational consolidations will often involve some of the same resources as the Year 2000 remediation project. In some cases, a merger or acquisition may be motivated by one partners desire to avoid the expense involved in preparing its own systems for the Year 2000. In these cases, conversion to a compliant system may be a preferred solution. However, in mergers motivated by other considerations, the process of assessing another organizations Year 2000 readiness, developing plans for the consolidation of operations, and implementing the consolidation may complicate the planning and scheduling functions of the Year 2000 project. If conversion testing consumes resources that may otherwise be devoted to Year 2000 renovation testing, the demands of the merger may become a hindrance.
An additional concern is the extent to which mergers create large distractions for most of the employees in one or both of the organizations.14 Although the year 2000 presents all organizations with unprecedented and complex challenges, many managers will be spending large portions of their time on merger-related issues. This will make it more difficult for them to assess the readiness of key suppliers and customers, and to develop contingency plans for potential disruptions.
The consequences of some mergers can extend beyond the organizations directly involved. Large-scale mergers that affect the structure of an industry can create conditions in which competing firms question their own long-term viability. To the extent that this results in additional consolidation activity or, at a minimum, new discussions with potential merger partners, the management of other entities may be distracted from Year 2000 considerations.
Sole-Source Suppliers
During the past couple of decades, when many firms increasingly emphasized quality control, new practices took hold. One such practice was to greatly restrict the number of suppliers for each component used in the production process. The purpose of this restriction was to keep these inputs at a constant quality level and decrease the firms need to inspect shipments at the receiving dock or to modify processes to adjust for variances in quality across suppliers. At the same time that the purchasers narrowed their sources for goods to a few or even a single supplier, the suppliers chosen tended to narrow their customer lists in order to focus their attention on satisfying the needs of these very large accounts. Although this practice was beneficial to the businesses involved, creating greater operational efficiency, it aggravates the Year 2000 problem. Each firm is now more closely tied to the fate of its business partners. If either party is unprepared for the year 2000, the effect on the counterparty -- which may now have fewer alternative firms to go to -- could be severe.
Year 2000 Project Management
Problems related to the year 2000, if not addressed in a timely manner, could cause virtually any business, nonprofit organization or government unit to fail. For this reason, it is important that top management of each entity become active in overseeing the Year 2000 remediation project. Senior management will need to ensure that adequate resources are made available. They should also participate in making strategic decisions related to the project; remain informed about the problems and challenges that emerge during the remediation efforts; and track progress toward the completion of all important goals.
At this late date it is essential for each organization to review its Year 2000 efforts to ensure that it will be able to perform the tasks most critical to its operations. Only after it is confident that sufficient resources are being applied to these areas, and that the problems facing these parts of the organization are being resolved, should it expand the project to include other systems and processes of decreasing importance. To determine which elements of its operations are most critical, the organization must analyze each step of the production function. At each step, it should ask the question "Would the organization fail if it were unable to perform this task?" For each task identified as critical, the organization should analyze how it may be vulnerable to each circle of risk. It must develop plans to address each of these vulnerabilities. The plans should include contingency plans in case if the initial approach is not successfully completed.
The organization should then analyze the plans for each critical unit as a whole. Any changes to be made in one area may affect the operations in another. Care must be taken to ensure that all of the pieces will continue to function together. Schedules should be developed so that the repair process can proceed smoothly and so that several areas do not have to use the same resources simultaneously. Finally, strategies must be developed for testing all changes, including testing how well systems will operate together after they have been modified.
Throughout this process, it is important to communicate with the external parties with which the organization interacts. To the extent that the organization depends on goods or services provided by others, it has to confirm that those entities expect to be capable of performing those functions. Similarly, organizations have to communicate to their customers which goods and services they will continue to deliver (and at what levels) and which ones they may discontinue or curtail.
Conclusion
The Year 2000 problem will be the most challenging one many organizations and individuals will ever face. Organizations that mismanage this process will be severely hurt, but those that take adequate steps to repair their own systems and to prepare for inevitable disruptions will greatly improve their likelihood of emerging whole. Although the hour is late, a lot of fruitful work can be completed in the remaining time. Lets roll up our sleeves and get at it.
Appendix 1 Critical Dates
January 1, 2000, is not the only date in the near future that may disrupt data-processing systems. Other dates that could cause disruptions are the following:15
January 1, 1999 One-Year Look-Ahead Date into Next Century Many computer programs process data by looking forward one year and counting dates back from that point. If such systems have two-digit date problems that are not corrected in time, they may begin to malfunction or fail at the start of 1999.
August 22, 1999 GPS Rollover The Global Positioning System16 is a constellation of 24 low-orbiting satellites that continuously signal data that can be used to determine the exact location of any receiver on the surface of the earth. The data are also used by some systems to establish the exact time of day for transaction logging. The clocks on this system report the time as the number of weeks since the launch of the system in 1980. On August 22, 1999, this counter will overflow and return to 0000 (as would happen on the odometer of a car that traveled 1 million miles). At that point some systems, or equipment, that use the GPS signals may malfunction. Among the vulnerable devices are some cellular telephones, devices that track the location of freight shipments, and some navigational equipment. However, many manufacturers of such devices have built their products to handle the rollover period correctly.
September 9, 1999 (9/9/99) A common programming device was to enter 9999 as a signal that a stack of data had reached its end. This signal may sometimes have been programmed on date fields, with the result that the date 9/9/99 will have a special and unintended - meaning in a program. Although the incidence of 1/1/2000 problems appears to be much greater than that of 9/9/99 problems, systems should be checked for each.
February 29, 2000 Uncommon Leap Year The year 2000 is divisible by four and is a leap year. However, years divisible by 100 are not leap years (1900 was not) unless they are divisible by 400 (2400 will be another leap year). Some programmers did not know about the hundred-year rule when they wrote their original codes, and those programs will run fine in 2000. Some programmers knew about the hundred-year rule, but not about the four-hundred-year rule, and their programs are likely to fail.
December 31, 2000 (366th Day of Uncommon Leap Year) Some programs operate by counting the days in the year. If the writers of these programs were unaware of the uncommon-leap-year situation, their systems may not fail until December 31, 2000, the (unexpected) 366th day of the year.
Appendix 2 - Vendor Management17
Businesses and other large organizations rely on vendors to provide products and services critical to the operations of the firm. Should the performance of these vendors be impaired because of Year 2000 (Y2K) malfunctions, the firm could be at risk or, at minimum, could find its own ability to provide services to its customers impaired. However, since firms do not have direct control over their vendors Y2K remediation and testing programs, this aspect of a Y2K project plan can be especially challenging. Because the potential consequences are so serious, all firms should take a proactive role and perform sufficient due diligence to assure themselves that their vendors will be able to meet Y2K deadlines. This appendix describes some of the steps that should be part of a firms Year 2000 vendor management program.
Types of Vendors Vendors provide a wide range of goods and services. Information Technology (IT) providers (including service bureaus, turnkey systems providers, and firms that sell software applications), may be responsible for core functions of the organization. Equipment manufacturers and distributors sell devices that enable employees to perform their jobs. Finally, third-party firms may provide a wide variety of goods and services, including, for example, raw goods and components, business forms, delivery and distribution services, security services, telecommunications services, equipment maintenance, power, and employee benefit administration (including payroll). The elements of a Y2K vendor management program which are unique to each type of vendor are discussed below.
Overview of Vendor Management Vendor management is an integral part of any organizations Y2K project management effort. Because the nonperformance or dysfunction of key vendors could place an organization at risk, it cannot rely on mere assurances from vendors that they will be prepared for the Y2K. The organization should consult all critical vendors and monitor their Year 2000 remediation efforts. When appropriate, it should test and verify that readiness. It must also be prepared to develop contingency plans in case critical vendors are significantly impaired by Y2K problems.
An organization should evaluate Year 2000 readiness for all new and renewing contracts and for all goods purchased from this time forward. Whenever they determine that the purchase of goods or services that are not Year 2000-ready is unavoidable (for example, if no Year 2000-ready alternatives are currently available, or if a counter-party is not yet Year 2000-ready, but has a reasonable Year 2000 project plan) they should establish a plan for transitioning to a Year 2000-ready vendor. If the vendor is expected to have available in the future Year 2000-ready versions of the products being purchased, organizations should establish in the contract the terms and conditions under which the new products will be made available. Important terms include the cost (if any) of the replacement, the dates by which the new versions will be available for testing, the dates by which the new versions will be available for installation, and the penalties the vendor will suffer for failing to meet these dates.
Each organization will have to implement a management program for existing vendors and devices that may be implemented centrally or by each division. The program will include inventory, communication, assessment, verification and testing, and contingency planning.
Inventory The first step of a vendor management program is to create an inventory of all vendor relations and all equipment used by all the departments of the organization. Methods that can be helpful in constructing the inventory include asking all employees, as part of an awareness program, to submit their own lists to the Y2K project team; looking to see what fixed assets are on the books; reviewing accounts payable records from the past few years; reviewing maintenance contracts; and creating special teams that review the operations in each department.
At this initial stage, attached to each item on the list should be a list of the devices or systems that may create data for, or receive data from, each item on the list. Also included should be an early assessment of how important each item is for the organizations Y2K readiness (the factors to consider are the items importance to the organizations operations, the availability of alternative providers, and the time frame that would be required to switch providers).
Communication In many cases, communication with vendors will be ongoing. An important aspect of a vendor management program is documentating all communications. As vendors appear on the inventory list, they should be asked in writing for information on their Y2K readiness. The communications process is facilitated if the initial letter includes specific information about the products and services the vendor provides to the organization (the information would include model numbers or versions and releases), and about any of the organizations systems that interface with the vendors product. Many vendors maintain Web sites on the Internet with information about the Y2K readiness of their various products. To the extent that an organization relies on information from a vendors Web site, it should keep a hard copy of the information on file and should periodically checked the Web site to determine if the information has been updated.
Assessment Organizations should fully assess each vendors products to determine the products importance to the organizations operations, the probability that the product(s) will fail, the alternative solutions available to the organization, and the contingency plans that can be implemented if the vendors products are not ready at the start of the next century. Organizations should develop low-priority lists of those vendors whose products they have determined to be Year 2000-ready, vendors whose products are not essential to the organizations operations, and vendors for whom several alternative providers should be available. The organization can then focus attention on the critical list of vendors whose products are important or essential for conducting business and whose Year 2000 readiness it has not adequately established. The critical list should include vendors who have not been forthcoming with information about Year 2000 readiness and vendors whose announced release dates for Year 2000-ready versions are too late for the organization to incorporate in its own Year 2000 readiness program.
For the list of critical vendors, it is important for the organization to determine the latest date at which switching to an alternative provider is possible. The organization should then determine what the latest date would be for deciding to replace the vendor (incorporating enough time for reviewing alternative vendors and managing a transition or conversion to the new vendor).
Verification and Testing The organizations management should not rely on mere assurances from vendors about their Year 2000 readiness. Whenever possible, products should be independently tested and verified. Depending on the product and the organizations resources, the verification may be performed internally or by qualified, independent third parties. Many organizations may find it beneficial to establish joint testing facilities or programs for common vendors, working either through existing trade associations or through user groups or ad hoc committees. However, each organization will still have to test how the vendors products perform in that organizations own environment. In isolation products may be found to be Year 2000-ready, but when they interface with particular systems or devices there may be problems.
In the case of a vendor that provides a service, the verification would involve evaluating the vendors Year 2000 readiness plans, its commitment, and its progress towards fulfilling the plans. In the case of a vendor that provides a product or device, the testing would involve simulating the products or devices operations in an environment that, as much as possible, replicates what things will look like on critical dates during the next couple of years (see appendix 1).
Contingency Planning The organization should develop contingency plans for all vendors on the critical list, describing how the organization will continue operating if the vendor fails to produce Year 2000-ready product. For some types of vendors -- for example data processing service bureaus -- the plan will detail the dates by which a conversion to a different vendor will have to be implemented. Other contingency plans may involve forging agreements with other similarly equipped organizations to provide each other back up if some equipment used in one institution turns out to malfunction in the new century. In such cases, the organizations should consider having their respective employees practice processing work on the others equipment.
If the critical vendor is a firm that is part of the economic infrastructure (for example, a provider of telecommunications services, electricity, and so forth), the contingency plans will be similar to disaster recovery plans that the organization may already have developed. In these cases, the organization should review the existing disaster recovery plans to determine if they would require modification for possible Year 2000-related events.
Service Providers All firms that organizations rely on for services face their own challenges in preparing for potential Year 2000-related disruptions. To avoid discontinuity of service, the organization will have to evaluate the Year 2000 plans of its critical vendors. The evaluation should cover the scope of the vendors Year 2000 remediation project; the vendors financial capacity to complete the remediation project; the commitment of the vendors management to the project; the vendors progress in achieving project completion; and the contingency plans the vendor will implement in the event the project is not completed on time.
It will be especially important to determine if the products or services that the organization obtains from the vendor are included in the vendors remediation plans. If the vendor plans to discontinue or modify those products, the organization should determine how the change would affect its operations.
Vendors of Information Technology A special class of vendors are those that provide information technology for other organizations. This class includes service bureaus, turnkey solution providers, and creators of application software. In addition to using due diligence procedures for all service providers, an organization should obtain specific information about IT products as quickly as possible in order to develop testing strategies and create testing data. It should also carefully monitor each IT vendors ability to meet deadlines within its project plan. As a starting point, the organization should make every attempt to obtain the following information from IT vendors:
•The vendors written plan, or a summary of it that includes benchmark dates, testing, and deliverables. •Financial statements for the organizations management to analyze, to determine whether the vendor has the financial capacity to carry out its Year 2000 project successfully. •A list of those programs, systems, and hardware that are compliant and those that are not. •A description of any changes an organization will have to make in its hardware/software environment and/or its communications systems. •The type of remediation the vendor will be using. If both expansion and windows18 are being used, the organization should seek details as to which method will be used for each application. •Information on how interfaces will be affected by Y2K solutions and on whether the vendor is working with other entities on any third-party software interfaces. •Scheduled periodic updates so that the organization can monitor and measure progress in solving Y2K problems. •Vendor plans regarding testing -- including information about the scope, assumptions, and conditions that make up the testing environment. The plans should also identify the dates when testing will be performed and should specify whether the organization will be able to participate actively in the testing procedures. •Effect on data entry and employee training. •Vendor contingency plans addressing unexpected developments or problems. •The level of help available from the vendor if the organization encounters problems. •A vendor warranty or certification of the system. If provided, exactly what does this warranty or certification cover? Since organizations cannot transfer their Y2K risks to the vendor, vendors should provide product verification plans that identify the following: •The date products will be ready to handle processing up to, through, and beyond the year 2000. •A list of products the vendor does not plan to support up to and beyond Y2K. •The pivot year, if windowing is used. •Notification to the organization of when the product is ready for testing by the user. •Guidance on the users testing of the product.
The organization should also determine what its role will be during the vendors renovation and validation phases. Communication with the vendor will be necessary to determine the users responsibility for interfaces with other programs, the contingency plans that may be necessary, and the dates when the organization must meet with the vendor to coordinate the organizations activities with the vendors plan.
Vendors of Equipment In the case of equipment providers, it is important for the organization to determine if the specific equipment provided is Year 2000-ready. In most cases, the organization will not have to evaluate the manufacturers overall Year 2000 readiness. Unfortunately, however, year 2000 problems have appeared in many pieces of equipment whose date dependency was not obvious. The source of a lot of these problems is the use of microchips to control functions of the equipment, or to maintain maintenance logs. At times, the designers of a given piece of equipment would choose to incorporate microchips that include real-time clocks. Microchip manufacturers have built real-time clocks that will properly function in the Year 2000. However, some real-time clocks have their own Year 2000 problems.19 The engineers who designed the equipment did not always specify that only year 2000 compatible microchips could be used. Over time, as the machinery was assembled using components from a variety of suppliers some noncompliant products may have been shipped. Finding these noncompliant devices before they break down during operation can be a great challenge.
The organization should contact equipment vendors and provide them with the makes and model numbers of the devices the organization uses and include a description of the systems or equipment the devices interface with (if any). The organization should ask the vendors if the specific equipment is susceptible to Year 2000-related problems. Organizations will need to decide under what circumstances they will require confirmation of a vendors response. Factors that may influence the decision include the criticality of the equipment and the results other firms attained when independently testing the equipment. It may be advisable for industry groups to perform joint tests of some of the products common to those industries.
Unfortunately, it is not always possible to obtain a definitive response from the vendor. In some cases, the manufacturer may no longer be in business. In other cases, the manufacturer had used components from a variety of sources and did not maintain records to determine which serial-numbered ranges would contain components from specific suppliers. When definitive responses are not possible, the organization has to develop a method of testing the equipment, or has to prepare contingency plans in case the equipment fails.
Sources of Additional Information
Web Sites: The World Wide Web on the Internet includes many sites that maintain extensive information about Year 2000 issues.
General Interest:
Government Entities
General Accounting Office: The GAO is a research arm of the Congressional branch. It has issued many audits analyzing the Y2K progress of various Federal agencies. In addition, the GAO has published Y2K guides for Federal Agencies to follow which are useful to any organization. Two in particular are: "Year 2000 Computer Crisis: An Assessment Guide" available at http://www.gao.gov/special.pubs/y2kguide.pdf, and the exposure draft, "Year 2000 Computer Crisis: Business Continuity and Contingency Planning" available at http://www.gao.gov/special.pubs/bcpguide.pdf. If it is not already on your computer, you will need the Acrobat Plug-in to view these pdf-format Acrobat files.
General Services Administration: The GSA maintains a comprehensive Year 2000 Information Directory with links to other government agencies, vendors, and news articles at http://www.itpolicy.gsa.gov/mks/yr2000/y2khome.htm.
Small Business Administration: The SBA maintains a Web site to assist small businesses with Y2K at http://www.sba.gov/y2k/.
Trade Associations
Institute of Electrical Engineers: This British association has some detailed information about the problems associated with equipment built with microchips that may malfunction when the calendar changes. http://www.iee.org.uk/2000risk/
Information Technology Association of America: The ITAA has a program for certifying that organizations are following best practices in dealing with Year 2000 issues. The web site has more information about this program, including a way to order the questionnaire upon which certification decisions are based (at the time of this writing, there is an initial fee of $250 to receive the questionnaire and a very substantial fee for applying for certification). The web site also contains an archive of past issues of the ITAAs electronic newsletter on Year 2000 issues, a page from which to order books about the Year 2000, and additional useful information. http://www.itaa.org/year2000.htm
Society of Information Managers: SIM sponsors a web site upon which the Year 2000 Best Practices Discussion Group takes place. The web site also includes a page from which a large number of Year 2000 related books can be ordered. http://www.year2000.unt.edu
Private Firms
Ed Yardeni: Ed Yardeni, Chief Economist at Deutsche Morgan Grenfell, sponsors Dr. Ed Yardenis Economic Network, a web site of general interest to the business community. Within the web site is the Center for Cyber Economics from which the public has access to Dr. Yardenis writings on Year 2000, and an extensive listing of related web sites, including several that discuss legal issues. The site also contains a database of Year 2000 disclosures from the financial statements of publicly traded companies. http://www.yardeni.com
Year 2000 Information Center: This site is the home of Peter de Jager, perhaps the Paul Revere of the Year 2000. The site includes featured articles of interest to a Year 2000 Project Manager and links to various solution providers, local user groups, and to a daily listing of articles that have appeared in the press about Year 2000. http://www.year2000.com
Industry Specific Sites:
Banking and Finance
Federal Financial Institutions Examination Council: The FFIEC is the umbrella organization for the many Federal agencies that supervise banks, thrifts, and credit unions. It has issued many guidance papers to the banking community regarding their Year 2000 projects, many of which would be useful to any organization. http://www.ffiec.gov/y2k.
Market Partners: Market Partners was established to assist banks in their Year 2000 projects. Their web site is open to the public and includes breaking news stories related to Year 2000 and the banking community and an extensive list of links to related web sites. http://www.marketpartners.com
Electric Utilities
Electric Utilities and Year 2000: This site is run by Rick Cowles, an engineer with many years of experience in the industry. He is now critical of the efforts taken so far by the utilities to prepare for year 2000. The home page for the site is at www.uey2k.com. The site also contains an extensive list of links to web sites of electric utilities, trade associations, and government agencies at http://www.euy2k.com/links.htm.
Healthcare
Food and Drug Administration: The FDAs Center for Devices and Radiological Health maintains a database of the Year 2000 status of medical devices and laboratory equipment. The database, and other Y2K information of interest to the medical community is available at http://www.fda.gov/cdrh/yr2000/year2000.html.
RX2000 Solutions Institute: This organization maintains an extensive Web site which includes an example of a hospitals Y2K remediation plan and articles of interest to the medical community. http://www.rx2000.org
Retail
National Retail Federation: This site includes an assessment guide for retail businesses, a survey of industry readiness, and a white paper on EDI and Y2K. http://www.nrf.com/hot/yr2000/index.htm
Telecommunications
Federal Communication Commission: The FCC has a Web Site which describes the various initiatives it is taking to assure that the industry is prepared for the year 2000. It also has links to other sites relevant to the industry. http://www.fcc.gov/year2000/welcome.html.
Transportation
International Air Transportation Association: The IATA has a Web site that includes the results of a survey completed by a few dozen member airlines and a members' forum. http://www.iata.org/y2k/Index.htm.
Electronic Newsletters
Several organizations produce newsletters about Year 2000 issues that are delivered via e-mail. The ones listed here are free to the public.
ITAA: The ITAAs weekly newsletter has an emphasis on issues relating to government policies. It includes a listing of upcoming Year 2000 conferences and seminars. http://www.itaa.org/year2000.htm
Year 2000 Information Center: This newsletter includes the URLs for several recent press reports on Year 2000 topics that are available online. http://www.year2000.com
Books
Year 2000 Problem: Strategies and Solutions from the Fortune 100
Leon Kappelman, Contributing Editor
International Thomson Computer Press.
Leon Kappelman, a professor at the University of North Texas, is the Co-Chair of the Society of Information Managers' Year 2000 Task Force. The book can be ordered online at discount from the year2000.com book store, http://www.year2000.com/y2kbooks.html. It can also be ordered by calling (512) 321-9652 or (toll free in the U.S.) 1-888-906-8410 (mention "SIM" for 20% off).
The year2000.com book store also has links to a long list of additional books about the Year 2000 problem. However, it is beyond the scope of this article to review each of them.
Footnotes
1 Jay Golter is a financial analyst in the Federal Deposit Insurance Corporation's Division of Research and Statistics. He can be reached by email at jgolter@fdic.gov. Paloma Hawry is a manager at the Actoras Consulting Group in Schaumburg, IL. She can be contacted through that organization's Web site at: http://www.actoras.com. This article expands upon an earlier article, "What Every Loan Officer Needs to Know About the Year 2000 Computer Problem (But Didn't Know How to Ask)," published in the FDIC Banking Review, Vol. 10, No. 2, and available at: http://www.fdic.gov/databank/bkreview/1998mar/y2k.pdf. If it is not already on your computer, you will need the Acrobat Plug-in to view this pdf-format Acrobat file. The views and opinions expressed in this article are those of the authors and not necessarily those of the organizations that employ them. Back to article.
2 See Gartner Group, "Year 2000 Arithmetic," July 29, 1996. Back to article.
3 See The Millennium Challenge, Merrill Lynch Forum available at: http://www.ml.com/woml/forum/index3.htm. Back to article.
4 Some software vendors may choose not to upgrade less-profitable products. Back to article.
5 Source code is written in a programming language such as COBOL. The computer's language compiler processes this and converts it into machine-readable "object code" which is a series of zeros and ones. When programs are modified, programmers do not work with the object code. Instead they change the source code and have it compiled into new object code. In some shops, the original source code may have been overwritten, lost or misplaced. Back to article.
6 For further information about embedded technology and the Year 2000 problem, see the Institute of Electrical Engineers' Web site at http://www.iee.org.uk/2000risk/. Back to article.
7 See "Is Your Pacemaker Ready for 2000? Your Hospital Hopes the Answer is 'Yes'," Pittsburgh Business Times, April 27, 1998. Also, "Year 2000 Problem Just a Heartbeat Away", Minneapolis St Paul City Business, February 9, 1998. The U.S. Food and Drug Administration maintains a web site with information about the Y2K readiness of medical devices at http://www.fda.gov/cdrh/yr2000/year2000.html. Back to article.
8 See "Millennium Bug Fear for Factories", by Chris Ayres, The Sunday Times of London, January 19, 1998. Back to article.
9 See "The Global Economic Impact of the Year 2000 Software Problem," by Capers Jones, 1997 available at http://www.spr.com/html/year_2000_problem.htm. Back to article.
10 Dr. Yardeni's various articles on the subject are available on his Web site at www.yardeni.com/cyber.html. Back to article.
11 The Y2K Reporter #16, March 16, 1998. Back to article.
12 Examples include WorldCom Incorporated's purchasing MCI Communications Corp, Compaq Computer Corp's purchase of Digital Equipment Corporation, Citicorp's combining with Traveler's Group, and mergers involving NationsBank and BankAmerica Corp, and First Chicago NBD and Banc One Corp. Back to article.
13 See, "Wells Spells Out First Interstate Merger Difficulties," American Banker, July 22, 1997 and "Wrong Track: A Big Railroad Merger Goes Terribly Awry in a Very Short Time," Wall Street Journal, October 2, 1997. Back to article.
14 See "Seven Office-Mates at a Dying Bank Ask: 'Who Will Survive'" by Ralph T. King, Jr., The Wall Street Journal, October 9, 1996. Back to article.
15 For a comprehensive listing of critical dates, see John Stockton's Web site of critical dates at http://www.merlyn.demon.co.uk/critdate.htm. Back to article.
16 For more information about the GPS system, see http://tycho.usno.navy.mil/gpsinfo.html. For information about the rollover period, see, http://gps.laafb.af.mil/y2000/index.html. Back to article.
17 Parts of this Appendix are drawn from Federal Financial Institutions Examination Council's Interagency Statement Guidance Concerning Institution Due Diligence in Connection with Service Provider and Software Vendor Year 2000 Readiness, March 17, 1998. Available at http://www.ffiec.gov/y2k/vendor.htm. Back to article.
18 "Expansion" and "windowing" are commonly used terms to describe two different approaches to remediating a data-processing system. These approaches are described in "A Comparison of Procedural and Data Change Options for Century Compliance" by Andrew Eldrige and Bob Louton, available at http://www.year2000.com/archive/options.htm. In this article, the authors refer to "windowing" and "expansion" as "procedural changes" and "data changes" respectively. Back to article.
19 A July 23, 1997, article on the Bloomberg News Service, "Potential Year 2000 Problems Go Far Beyond Big Computer Systems," about Dallas Semiconductor, (identified in the article as the world's largest manufacturer of real-time chips), states that 85 percent of that type of chip that they were producing at that time would not handle date functions properly after the end of 1999. Back to article.