NT, we have a problem ...
People have begun to complain about the Year 2000 (Y2K) problem. "We didn't create this situation. Why should we have to pay for it?" "Two-digit year fields with the millennium coming? What were those programmers thinking in the 1960s and 1970s?" I'll tell you exactly what those programmers were thinking. I know, because I was one of them. What we were thinking was, how can we get this application and several others to work on a 32KB machine? (We are the programmers who, to this day, will inform you that 1KB is not 1000 bytes--it's 1024 bytes.) Conserving bytes mattered in those days, because MB systems did not exist. Those century digits were bytes we could save--so we did.
No matter what caused the problem, today's pressing concern is that only about 16 months remain before 2000 arrives. Are your systems ready? A recent study by the GartnerGroup determined that 30 percent of US businesses haven't begun to consider how the Y2K problem will affect them. That's a frightening statistic when you realize how dependent on computerized data our information-based society is. In this two-part article, I will walk you through an eight-step approach to solving the Y2K problem in your organization. If you've already begun getting your systems ready for January 1, 2000, you can use these steps as a checklist of essential action. If you don't think Y2K will pose a problem for you, follow the steps to prove it. Should you discover you're not as safe as you thought you were, you'll know how to begin fixing your problem and develop contingency plans.
The Eight-Step Approach
A comprehensive approach to the Y2K problem involves eight steps. Let's take a quick look at the steps, then I'll discuss each one in depth.
Step 1: Awareness. Before you can fix a problem, you must recognize that a problem exists. Some systems will fail on January 1, 2000. However, which systems will fail is anybody's guess. With careful testing, you can remove some of the guesswork from the situation in your company.
Step 2: Inventory. Before you can do anything about the Y2K bug, you must take a complete inventory of your hardware and software. When I suggest you take an inventory, I don't mean the kind in which you determine that you have 34 PCs, 34 copies of Microsoft Word, 12 copies of Microsoft Excel, and a homegrown accounting system. I mean compiling a complete and detailed list of all your data processing resources and the systems they connect to.
Step 3: Assessment. After you have your inventory of resources and systems, you must check every item on the list for Y2K compliance. This process involves inhouse testing of individual hardware units, contacting manufacturers to verify their software's Y2K compliance (then testing the software anyway), and checking custom code line by line for obvious and hidden date usage. (Some currently available Y2K assessment packages can help you check custom code. Table 1 lists some of the available Y2K tools and services.)
Step 4: Planning. You need to devise a strategy for fixing the Y2K problems you discover in the assessment stage. Business-critical processes come first, because the likelihood is strong that you won't have time to fix anything else. In fact, prioritize your business-critical processes--because you might not have time to get to all of them.
Step 5: Remediation. Focus all your MIS resources on fixing as many of your business-critical processes as possible. (Y2K conversion packages exist to help here, too.) Use your priority list, because unless you have a very small company, you probably won't have enough time to fix everything. Don't try to implement new projects until after you've completed and tested your Y2K project.
Step 6: Testing. After you've fixed the business-critical functions, you need to unit test, package test, and system test. Many large companies have determined that they must complete all their coding changes by January 1, 1999, in order to have enough time to thoroughly test the changes. You'll need to spend two to three times more time on testing than you took to fix the problems you found.
Step 7: Integration. When your systems test cleanly, you need to integrate all your systems and test functions and interfaces both inside and outside the company. You must be certain that the changes you made to bring one system into Y2K compliance don't crash another system. You must also be sure that you can still pass information to and from suppliers, regulators, and customers.
Step 8: Contingency planning. The most important step is to devise plans that answer the "what if?" challenge. What if your company has more Y2K problems than you thought? What if you don't complete your project on time? What if you missed something? You must establish alternatives to your current dependence on computers, and you must do it before January 1, 2000--just in case.
Previous
Register
