The Euro
The first of these events is the conversion to the EURO that will officially become available on January 1, 1999. The Euro is the new monetary unit and countries in Europe who will participate in the European Monetary Unit effort. Eleven will begin participating next year. Organizations have been allowed a window for conversion until 2002. Contingency planners may not have focused on the Euro because they believe it only affects European firms. Not true. Any multinational company with operations either in an European Economic Community (EEC) country or who deals with European firms will be affected and will need to be able to translate and report both in the local country currency and in Euros. What this means for U.S. firms is the adoption of a new process in money exchange formulas; that of being able to convert each of the participating countries' currencies into Euros, as well as other currencies. This is an extremely complex process and must be added into most financial applications. Obviously, the January 1, 1999, date is not as critical for us as it is for Europe; but the U.S. must also prepare to make necessary conversions so that we can deal with our European trading partners, divisions, parent companies, subsidiaries, etc.
As contingency planners we must theorize about what will happen, if we incorrectly calculate the needed conversions. What problems will we face as a company? How can we get around these? What dislocations will occur and how can they be avoided? The time to think about this is now, before the event occurs, rather than after we encounter a problem.
Year 2000
The second huge problem that is rapidly approaching is the Year 2000 programming effort that is going on in almost every organization in the world. As everyone knows by now, the Y2K problem, or the 'Y2K bug' as it is becoming known, is an event and we have only a finite amount of time for conversion of dates (approximately 1 1/2 years) before they will be needed everyday.
Banks are heavily involved in remedial and/or corrective efforts. Many other firms are just getting started. However, this is not a problem that will go away all by itself. It will require a huge investment: e.g., to take staff from other, more productive pursuits; and drain financial resources from new investments in the business. All computerized functions that use a two digit 'year' designation will have the potential to have problems when used in calculations. This includes the obvious, such as social security calculations, and also the invisible, such as computerized functions within elevators, microwaves, ATM machines, etc.
Even before the Y2K problem occurs, there are a series of dates that may create problems for organizations (see table). Starting in April of 1999, and not ending until 2001, specific dates will be reached that can produce bedlam in computers that run your business. Take a look at two of the dates in the table for 1999: April 9 and September 9. In their own way, they are dry runs for Y2K. People who have been in computing since the days of tape will immediately recognize the significance of '9999'. Not only are these dates followed by the start of the year 2000-it is also leap year! Many unwanted events attributable from these dates have the potential to significantly disrupt business operations.
Why do we, as contingency planners, need to focus on these problems? We assume they are being handled by IT departments and that someone is working to solve them. In fact, many people are spending large amounts of money and effort to ensure that their businesses prevent these problems from occurring. Financial institutions, in particular, are working diligently to correct outdated programs. Citibank estimates that 50-70% of their technology staffs are working on Year 2000 problems. Furthermore, they estimate that they will spend approximately $600 million on Y2K. At the end of 1997, they had already spent $150 million. Calculations indicate they will spend about $225 million this year and another $225 in 1999 to update their 400 million lines of code.
Chase Manhattan, another major bank, estimates that it will spend in the neighborhood of $250 million to become compliant. Estimates are lower at Chase because they have been updating systems as a result of the merger with Chemical Bank in 1996. The interesting point to note regarding Chase's activity, however, is that it estimates a total of 2,900 links to other computer systems, such as stock exchanges and money transfer networks. Thus, there are 2,900 other computer systems that will also need to be in compliance for Chase's systems to work correctly.
Does this have anything to do with business recovery planning? You bet it has plenty to do with it! These events pose the greatest threat to availability and continuity of business and government operations that the world has ever known - and contingency planners should be right in the middle, analyzing and planning so that if, or when, something does go awry the Company will be able to find a rapid work-around. In some companies recovery planners are focused on what will happen if their own systems fail. However, few businesses and government organizations are doing anything proactive to plan the wide variety of scenarios concerning the myriad of 'what ifs' involving business partners - those outside organizations that are critical to success but uncontrollable by the Company itself. It is paramount that contingency planners take a leadership role in preparing for the worst - while hoping for the best - so that the business will weather any potential problems.
How can contingency planners actually get involved in this gargantuan effort? There are several ways. First, it is important to catalog all the processes and systems that the Y2K staff is working on (or not yet working on). Also, it is necessary to make note of all equipment that contains a computer chip (this may require contacting all vendors). The reason for this is that in addressing the Y2K problem, everything that uses a computer or contains a computer chip may have the potential to fail. If the Y2K team is in place such an inventory may already exist and each vendor may have been contacted to determine Y2K compliance. If no inventory exists you need to contact all the vendors and ask them if the particular product is Y2K compliant. It will be very important to conduct this survey and maintain the documentation as a permanent record.
Why do you need to save the documentation? There is a growing move by the legal community to get ready to litigate Y2K cases. They are aware that a number of businesses have not taken due care to protect company assets by preparing adequately for Year 2000. Even if some businesses make the transition successfully, experts expect there will be litigation involving those who do not. The records of the Company's work to prepare for Y2K should be treated as a vital business record and put into permanent storage in the event it is ever needed to prove its diligence in converting systems.
Triage, or the process of sorting out the most important problems, should be conducted on the inventory resulting from the survey of computers/chips. How can you do this? The basic process is similar to conducting a business impact analysis. Questions need to be asked. Things such as 'what could bring the business to its knees?' should be addressed. If this piece of equipment fails, how will the business operate? Basic things such as elevators, telephones (cellular and land), pagers, power, and locking mechanisms need to be examined. Systems such as funds transfers, treasury operations, stock market feeds, billing, etc. all are important to maintaining the cash flow of the organization. Therefore, they should place high in the triage. Each of these functions, and many more, could result in serious disruptions to the business. As a contingency planner your job will be to examine each of these findings and lay out a disaster work-around plan if they fail.
| Date | Explanation |
| April 9, 1999 |
9999 on the Julian Calendar. 9999 denotes the "end of input" in many computer programs. It also is the date which data operations staff have traditionally used to indicate when data may be scratched, or discarded and overwritten. |
| Sept. 9, 1999 |
9999 on the Gregorian Calendar. Same as above. |
| Dec. 31, 1999 |
Last day in the 1999 year. |
| Jan. 1, 1999 |
Beginning of the year 2000. |
| Jan. 3, 1999 |
First business day in the year 2000. |
| Jan. 10, 1999 |
First date to require a 7 digit date field (1/10/2000). |
| Feb. 29, 1999 |
Leap year. |
| Oct. 10, 2000 |
First date to require an 8 digit date field (10/10/2000). |
| Dec. 31, 2000 |
Check that year has 366 days. |
| Dec. 31, 2001 |
Check that year has 365 days. |
A more difficult problem is analyzing interrelationships with partners and vendors. Each one must also be analyzed. As in the Chase example cited earlier, every business has many of these. Your job should be to categorize these by performing triage on them, too. Is there a viable work-around or alternative sources for products and/or services provided by your partners and vendors? Which are going to spell potential disaster if they fail? Every partner, supplier and service provider should be contacted for an assurance that they are seriously working on a solution (or solutions) for Y2K. This may sound simple but many medium and smaller sized businesses have not even begun thinking about how they will comply. If your business is dependent on such a supplier, or a small bank, you need to begin working now to assure yourself that they will be able to meet your needs.
This will not be easy. It will not be simple. However, it must be done. These are not activities that can be put off until they are more affordable. Contingency planning for the Euro and Y2K problem are tasks in support of critical business processes (fiscal calculation and date conversion). The business impacts associated with each must be assessed now because the events associated with this work will not wait until your organization finds a more convenient time or assigns a higher priority to this task. Euro work offers a range of dates when the transition will occur - as long as a work around is available, but the Y2K problem has a 'hard stop' - January 1, 2000. Contingency plans that deal with partners who fail in their efforts must be put in place so that your business does not unduly suffer. We can only hope that these plans will not be needed; but if they are, we will be very happy that we have them. They cannot be developed on the spot. Now is the time. Good luck! Good Preparation!
Patricia Fisher, CEO and founder of JANUS Associates, Inc. has over 20 years of information systems and security experience. She has previously been responsible for information security and disaster recovery for IBM's Latin American sites, as well as for direction of an IBM corporate headquarters data processing center.
