Around the Bizauto web site:

---

BIZAUTO BULLETIN 98.8

Guest Viewpoint:  The Millennium Crisis .  . . Time is Running Out by John Ritzenthaler 

Past Bulletins  

Who is Business Automation?  

Our services  

Consulting projects  

Expert witness projects  

Home   

FEATURE ARTICLE:

• How much business would you lose?
• How many critical deadlines or deliveries would you miss?
• How many of your best customers would desert you for more reliable suppliers?

There's been so much discussion over the past few years about the "Year 2000 Problem" (or "Y2K") that it's surprising how many businesses--even computer businesses--are so poorly prepared for it. This Bulletin starts out by describing briefly what the problem is . . . but if you already know that, skip right ahead to how to tell if your business will be affected, or what to do if it will.  
   

The Year 2000 problem dates back to the early days of computing when the cost of computer memory was so high that programmers had to conserve every last digit of data.  To save space, early programmers always wrote software using only two digits for the year: "65" for 1965 (when this author entered the industry as a programmer), "90" for 1990, and so forth.  This shortcut, which seemed so harmless at the time, has turned out to have consequences much worse than anyone could have imagined.  It turns out that computer programs often need to do computations using these two-digit dates for financial calculations, or to determine when to do various scheduled tasks.  This has worked fine for years, but not when one date is before the end of 1999 and the other date is after it.  The problem is that "00" (which, today, should clearly mean 2000) is a lower number than "99" (i.e., 1999).  But computers don't have the common sense to realize that "00" should come after "99" instead of before it.   

To see how this can cause problems, you have to "think" like a computer.  Ponder (using this "computer-think" approach), for a seven-year loan made in 1998 and actually due in 2005, what the loan payments would be in the year 1901 (not 2001 . . . 1901, because of the two-digit years, the computer doesn't "understand" 2001)?  The question doesn't make sense, does it?  Obviously, a loan made in 1998 didn't exist in 1901.  But because a computer won't "know" that, it'll do its usual calculations and come out with some unpredictable and meaningless result, just as if nothing unusual had happened.  That's why the Year 2000 Problem (abbreviated "Y2K") is so dangerous: it causes bogus and unpredictable results without warning.   

Y2K analysts have estimated world-wide costs to fix the problem will be about $500 million and, more that becomes known, the more conservative this figure begins to look.  Although many major companies and government agencies will have their Y2K problems fixed in plenty of time, it's a virtual certainty that many others won't.  Some very significant business interruptions and financial losses will occur as a result.  

The most obvious feature of the Year 2000 problem is that it's coming less than two years from now and nothing is going to change or delay it.  But this doesn't tell the whole story.  Businesses could theoretically wait until the last moment to convert their systems, and many will undoubtedly try, but waiting is a major, and potentially costly, mistake for three reasons:   

• Implementation takes time . . . a margin of safety is important. 
• The computer industry doesn't have enough resources to fix everyone's problems in the year and a half that remains.
• Prices will go up and quality will go down as time passes.

The question isn't whether your business faces a Year 2000 risk, it's how serious a risk you face.  It's easy to predict that nearly everyone and every business will have failures in some of the systems, equipment and services they rely on.  The alarmists believe these failures will be massive, starting with an extended "blackout" of the national "power grid" (and equivalent systems in other countries) and escalating from there.  Although this dire analysis has yet to be disproved, most Y2K observers have figured that the consequences, while still very significant, will be far less catastrophic, as evidenced by the successful mid-1998 test of the NY Stock Exchange systems.  In either case, however, no one will escape entirely.   

Though every business is vulnerable, to assess the vulnerability of any specific business four key areas need to be reviewed:   

• The company-wide computer systems that handle most businesses' day-to-day operational and accounting functions.
• The "embedded" microprocessors inside various types of equipment (e.g., machines, vehicles, control systems, etc.).
• Voice and data communications systems.
• PCs and small networks used by individuals and groups.

Recent studies have shown that few businesses have begun to take Year 2000 seriously as a threat to their operations.  The fact that you're not alone, however, should be scant comfort . . . it's time for the procrastination to end.  Here is a series of steps that you can follow to do what you can to prevent a doomsday scenario in your business.   

1.  Determine whether the products or services you sell have a Y2K flaw.  Your customers will soon be asking for assurances that your products won't do them any harm, or to provide some solution if they do.  You may even face legal liability if your products cause problems, but even aside from the legalities, your future business is likely to depend on your ability to provide Y2K-safe products.  Correcting potential problems with your products is beyond the scope of this Bulletin, but they're your lifeblood, and even if you only distribute them; you should know where to turn.   

2.  Appoint a Y2K Coordinator.  You'll need someone to take primary responsibility for knowing where your risks are and coordinating whatever actions need to be taken.  Depending on the size of your organization and what you find in your initial assessment, this could be anything from a small part-time activity for one person to the management of a large Y2K operating group.  The year 2000 probably presents the greatest quality risk most businesses will face in the next two years, so the quality director or someone in a key position in that area is probably a good place to recruit a Y2K Coordinator.   Once the initial assessment is complete, you can decide how much reinforcement, if any, that person will need.   

3.  Take a comprehensive inventory of every item and system that may be vulnerable to Y2K disruption.  At this stage, you should include everything that uses electric power . . . and don't forget the battery-operated devices like cell phones.  In addition to devices, this list needs to include every software program you use from the most comprehensive systems that affect the whole business down to the programs on all your individual employees' PCs.  Once you've done this, add all of the mini-applications (e.g., spreadsheets, web pages, etc.) you've created with these packages that you use in your day-to-day operations.  As you do this, keep whole applications together . . . if you replace one part of an application, it's unlikely that any of the other affiliated parts can continue for any significant period without it.   

This is the first of many lists you'll make.  Once it's done, you'll need to make sure that everything on this list gets categorized and transferred to another list.   

4.  Create a "Not time sensitive" list.  Transfer all of the items from the first list that have no time display and do not operate on any sort of a schedule or cycle onto this second list.   

5.  Create a "Minor annoyance" list.  Move all the items to this list that, even if they do fail on Y2K-day, won't cause any serious disruption.   

6.  Create a "Not settable" list.  Many of the equipment items on your inventory list -- even though they have internal clocks -- won't have a time-setting mechanism.  While it's possible that some of these can be reset by the manufacturer (check this when you have a chance), cycle failures in systems that don't have any time setting controls aren't likely (no guarantees here) to cause much harm.  However, if you have any concern that an item to this list just might be critical, don't put it on this lower-priority "not settable" list.  

7.  Create a "Not mission-critical" list.  Mission-critical functions include anything that affects:   

• Your ability to deliver products or services
• Your revenue
• Payments to suppliers and lenders
• Any other important commitments such as loan covenants or the like.

8.  Transfer everything that's left to a "High priority" list and prioritize that list.  This is your checklist of Y2K-vulnerable systems.  Every one of these systems needs to be assessed as soon as possible and, if they can't be shown to be reliably certified as Y2K-compliant, they'll have to be fixed, upgraded or replaced.  In prioritizing the remaining items, the most important factors, in order, are:   

• How long it will take to replace each system, if that's what is needed (longest first)
• How critical each system is.

9.  Review the Y2K-compliance of each identified system.  The best place to check the compliance of a system is with its developer or the company that supports it, and the best rule is to be skeptical.  You know how reliable your vendor has been in the past; this is probably the most critical question you will ever ask them, so you need to be totally comfortable with the answer.  With some systems suppliers, a full binding contract with outside certification and insurance might not  be enough, and with others a "handshake" would be sufficient.  You're the one with the experience.  Your judgment is what counts.  Once you have assurance on the compliance of a system that you feel is trustworthy, you can cross that system off your "to do" list and move to the others.   

10.  Fix, upgrade or replace the non-Y2K-compliant systems.  Unfortunately, these are the only three options for resolving Y2K problems. 

The first option, fixing the software, applies mainly to custom or in-house developed software.  Although this approach sounds desirable because it avoids incompatibilities and minimizes the disruption, it's seldom practical because finding Y2K flaws in a system takes massive resources.  Most custom-developed software has been around for years and, unfortunately, the original authors are gone the program documentation is non-existent or out of date.  As a result, the kind of changes needed to fix 2000 problems are almost impossible to make without creating even more problems.  Even in those situations where it is practical to fix software reliably, it takes massive manpower to do it.  Finally, although older systems are familiar, most are also wedded to older techniques . . . new software offers the opportunity for a new approach and newer, better business techniques.

The second option, upgrading the software, applies mainly to commercial "packaged" software.  This includes everything from operating systems (e.g., DOS, Windows NT, Unix, etc.) to desktop software (e.g., word processing) to full scale business systems.  Nearly every active software developer more than a few years old originally wrote its software with two-digit years.  Most have either completed Y2K upgrades by this time or will have them completed them within the next several months.  There are, however, lots of software packages written by defunct or nearly-defunct developers for which this option does not exist.  The most important advantages of upgrading are that, when it's available, it's usually the least expensive alternative and, depending on how significant a change it is, it can usually be done without major data conversions or employee retraining.  Probably the most important consideration in evaluating a major upgrade because it can be either an advantage or a disadvantage is how satisfactory the software and the software company have been since the system was implemented.  If the product and the support are good, it's usually advantageous to upgrade even when "better" or more capable software choices are available.  On the other hand, if the software company is defunct or unacceptable, no amount of cost savings can make this a desirable course of action. 

The final option is replacement.  Although this is often the most expensive and disruptive choice, many organizations do it in order to make a major leap in system capability.  Also, for many systems where the existing software (or embedded processors) can't be fixed or upgraded, this may be the only real Y2K option available.  In addition, many organizations have come to the conclusion that they need a system to address their "mission-critical" business functions and lots of older systems don't do much more than basic accounting.  For these firms, Year 2000 is not just a threat, it's an opportunity.  Procedural changes may be hard to make, but they often bring needed improvements and major cost-savings. 

Regardless of which option is selected, you must begin to take action as soon as possible because, for businesses of any reasonable size, it often takes months to select, test and implement a new "enterprise" system.  Once you've completed this for all your most critical systems, you can go back and attack the less crucial ones.   

It's possible, of course, that once you've completed the first nine steps, you'll find that you don't have time to complete this step for every non-compliant system.  If so, don't panic . . . go back to your priorities and resolve your most critical deficiencies first.  Not every Y2K failure will be a catastrophe.  As long as you keep your vital systems operating, you'll probably be able to resolve the less critical problems on a "triage" basis as they come to light in the first few days of the new year.   

11.  Test and verify everything thoroughly.  Testing must be done every bit as methodically as every other part of the Year 2000 compliance process.  The first step in the testing phase is selecting a testing team, preferable recruited primarily from the ultimate users of the new or revised systems.  Although this team can have some members in common with the Y2K project, its leadership and control should be independent.  The next step in the process is defining the Year 2000 compliance criteria, including (at a minimum) listing all date-related functions and testing:

• That no specific date causes a system "crash" (i.e., for all critical dates before during and after January 1, 2000).
• That all the functions (e.g., scheduling, calculations, etc.) work the same way before during and after 1/1/2000.
• That all dates stored in the system are consistent and unambiguous.
• That leap year calculations are proper (i.e., 2000 is a leap year, 2100 is not).

12.  Once you've begun resolving your own Y2K problems, check your business partners.  No matter how good a job your company does in rooting out Y2K problems, there's no guarantee that your suppliers and customers will do the same.  As described above, the most pessimistic Y2K-analysts are forecasting widespread and extended power failures and shut-downs in many areas of the economy, including the banking system, the stock exchanges, social security, etc.   

Just as with your internal systems, it's important to assess your reliance on outside organizations and systems and, to the greatest extent possible, take the same steps with them that you do with your internal systems.  Focus on your "mission critical" activities with actions such as:   

• Testing your back-up power generation capability if you need 24-hour power,
• Auditing your most critical suppliers' Y2K preparation and finding alternate sources if necessary, and
• Getting new accounts that are similarly concerned about finding reliable suppliers for their key raw materials.

13.  Prepare and execute a Year 2000 cut-over plan.  Regardless of how well prepared you are, things will go wrong during the first week and the first few months of the year 2000.  A cut-over team will be required before January 1, 2000 with the authority and ability to correct or work around every problem that comes up.  Prior to the century change they need to prepare contingency plans in advance for all mission-critical business functions.  Some of the problems that arise will be the lower priority items that were on your "minor annoyance", "not settable" and "not mission-critical" lists.  Others may be minor items that slipped through without being caught during the testing.  The team will need the authority and capability to handle whatever problems arrive on a "triage" basis, implementing "quick-fixes" where possible and/or taking contingency actions when no immediate solution is available. 

If you follow all the prior steps carefully, the last minute corrective actions should be minimal and the business will survive the change better and stronger than it was before.  Furthermore, you'll be better prepared than 90% of your competitors and business partners.  But act quickly and keep a comprehensive written log of everything you do.  There's literally no time to waste.