Year 2000

Preparedness Guidelines for Small and Mid-Size Companies

By Sid M. Edelstein

In Brief

Do It Now

Many enterprises with large, complex computer systems are already testing to see whether their efforts to fix Y2K problems have worked. But what about the small and mid-size entity that has been ignoring or denying the fact that its own computer systems or its customers, suppliers, and vendors are not Y2K compliant?

The author provides a work plan that delineates how the smaller entity can finally take charge of its own Y2K destiny. Fears will be dispelled and inertia overcome by those that follow this step-by-step process: taking a complete inventory of the exposures, seeing what fixes are readily available, and then moving on with implementation, testing, and, finally, contingency planning.

The clock is winding down on companies that have been actively preparing for the Year 2000. Changes are being implemented and testing has been scheduled. But what about companies that have not even begun to address the issue? If asked whether there is time left for those that have not yet addressed the problem, many information technology consultants would say it's already too late. For large, nationally or internationally dispersed enterprises, they would be correct.

This, however, is not necessarily the case for many small and mid-size companies, whose communications networks and business systems typically lack the complexity and customization of a larger enterprise. For these companies, the six months remaining in 1999 are more than enough time to make major strides toward protecting against Year 2000 hazards--complacency is the primary obstacle.

A January 1998 Gartner Group study found that 30% of all companies internationally had not yet begun to deal with the Year 2000 problem and that the majority of these were companies with 2,000 or fewer employees. To further illustrate this point, I can draw upon our firm's own experience in attempting to educate our clients and alert them to the potential business risks involved. Our firm's client base is composed primarily of closely held small and mid-size businesses across a wide variety of industries. Over the last two years, we sent three notifications to our clients regarding the Year 2000 problem and requested information about their preparations. Less than 10% responded to these mailings. Many respondents demonstrated an alarming lack of awareness of both the proper scope of a Year 2000 risk analysis and the potential consequences that technology failures could have upon their business operations.

We would all do well to remember the venerable words of Professor C. N. Parkinson: "Delay is the deadliest form of denial." Although late in the game, small and mid-size companies may still have enough time to effectively prepare themselves. However, the time to act is now. The threat is real and the potential consequences of ignoring it far outweigh the effort involved in preparing for it. The guidelines that follow are intended to provide a framework for the small and mid-size company to address Year 2000 issues and take corrective action in a speedy and efficient manner.

Year 2000 Analysis Guidelines

A word of caution is in order. No one knows or can predict the full extent of the Year 2000 issue. Therefore these guidelines cannot be definitive or all-inclusive. They are designed to provide an organized approach for assessing a company's Year 2000 preparedness and taking the necessary steps to ready its business operations for what may happen. There are no guarantees, only sound practices that reasonable managers can follow to prepare for risks that are not fully assessable.

The Year 2000 preparedness guidelines that follow are organized into six distinct phases that should be performed sequentially.

Phase I: Systems Inventory

Business Hardware. A complete inventory of all electronic business hardware systems in use (computers, networks, telecommunications, machinery, office equipment, etc.) must be taken and documented. This inventory should include information on the manufacturer, model number, serial number, and system vendor.

The following additional information should be gathered for computers that employ internal components made by manufacturers other than the vendor producing the system:

* Motherboard manufacturer and model number,
* CPU manufacturer and model number, and
* ROM BIOS manufacturer and version number.

Vendors that provided specialized manufacturing equipment or other types of customized business hardware must be contacted to determine whether any date-sensitive third-party components or embedded instruction chips are utilized within the system's design. Manufacturer and model number information for these embedded systems should be included in the hardware inventory.

The Year 2000 problem is not limited to computer hardware--it can potentially affect any electronic hardware in use that maintains date and time information. Such systems typically include (but are not limited to) the following: security systems, clocks and timers, postage systems, photocopiers, calculators, cash registers, credit card processing systems, fax machines, electronically regulated pumps and valves, climate control systems, elevators and escalators, point-of-sale systems, and voice mail and PBX communications systems.

Business Software. A thorough inventory of all business software applications in use (computer/network operating systems, generic software applications, customized software applications) must be taken and documented. This inventory should include information on the software vendor or developer, application name, and version number. It should also include an internally assigned rating code indicating the importance of the application to the company's business operations. This coding methodology will be used to help prioritize remediation activities detailed later.

Computer/Network Operating Systems. Year 2000 issues for all existing versions of Microsoft's operating systems (including MS-DOS, Windows, Windows for WorkGroups, Windows 95, Windows 98, and Windows NT Server/Workstation) and most existing versions of Novell's Netware network operating systems (4x and prior) have been documented. Problems with these operating systems range in significance, and, generally speaking, the more current the operating system, the less significant the Year 2000 issues. Under Phase III, instructions are provided on how to obtain upgrades and patch files for these operating systems to bring them into full Year 2000 compliance. Affected customers should contact respective vendors or visit their websites for information on their product's Year 2000 status, upgrades, and fixes for other operating system platforms [i.e., Sun, IBM, HP, Tandem and Digital (now Compaq)].

When taking a software inventory, it is important to note the version and release number of the operating system. When rating the significance of the business applications in use at the company, operating systems should be considered high priority.

Generic Software Applications. Generic software applications are commercially available, prepackaged software applications with a "locked" feature set (i.e., Microsoft Office and Peachtree Accounting). Source codes for most of these applications cannot be directly accessed by the end user. Year 2000 fixes are the responsibility of the vendor and are typically released in the form of version upgrades. It is important to know the correct version and release of the generic software application in use before attempting to perform upgrade and patch procedures. In Windows applications, this information is usually contained in the Help menu under the About section. Software manuals or the software vendors themselves should be consulted for the whereabouts of product version information for non-Windows applications.

If the source code of a generic application has been customized or modified internally (or by a programmer or reseller), the full extent and details of the modifications should be documented. The name of the party that performed the modifications should be noted on the application inventory.

Customized Software Applications. Customized software applications refer to any proprietary business software application that has been designed exclusively for the user, utilizing a programming language or client/server development environment. Customized applications are commonly found in larger organizations and specialized business environments. Because these types of applications typically lack the support structure of a commercial product, they present a high degree of exposure to Year 2000 complications. This is particularly true of business applications developed in popular older programming languages such as Basic, Fortran, and Cobol.

For customized software applications, the language and development tools used to create them must be documented along with information on the vendor or programmer that developed the application. Additionally, depending upon the size and complexity of the application's source code, consideration must be given to the specialized skills and lead time necessary to analyze and correct it. When rating the significance of the business applications in use, customized software applications should be considered high priority.

Phase II: Research

Phase II involves obtaining the Year 2000 status of all the items on the inventory. For most commercial hardware and software, this information will be readily available on the vendor's website. Alternatively, this information can be acquired by contacting the vendor directly. In some cases, a vendor may ask for a written request prior to providing Year 2000 product information. No matter how this information is ultimately gathered, it is critical that the company acquire a hard copy for its records either by printing the vendor's website posting or through correspondence. These documents will provide a paper trail of the efforts taken to correct Year 2000 problems and may be needed in the event of claims and assertions arising out of a problem. The documentation should be kept until the Year 2000 conversion has been successfully demonstrated and there is no possible need for pursuing or defending a claim.

Often vendors may initially classify a product as fully Year 2000 compliant only to discover, as the result of subsequent user feedback, problems of which they were originally unaware (e.g., Microsoft Windows 98). As a result, vendor Year 2000 product status reports are updated regularly. It is a good idea to visit vendor websites or otherwise maintain contact on an ongoing basis to learn of late-breaking Year 2000 news, especially for critical applications.

Phase III: Remediation

Phase III begins with the development of a remediation checklist. This checklist should contain a listing of all inventoried items showing their Year 2000 status, their importance to the company's business operations, and the time frame in which these items must be corrected. This checklist should be reviewed with upper management to determine the proper course of action for all noncompliant items deemed critical to the company's operations. In this way, the planned remediation measures will receive the necessary attention, funding, and staffing to complete the project on time.

In general, there are two ways to remedy noncompliant software or hardware: repair or replacement. The decision as to which of these options is the best alternative depends largely upon the availability of Year 2000 fixes (or the staffing and skills required to perform the repairs) and the time, effort, and cost involved in administering the required repairs.

BIOS and Operating System Patches and Upgrades. The next step is to acquire the necessary Year 2000 upgrades, fixes, and patch files for all items in the inventory deemed noncompliant. With regard to computer hardware, these fixes will usually consist of ROM BIOS upgrades and operating system patch files or service releases obtained from websites or the vendor. Incidentally, Novell has recently released a new Year 2000 utility named "Information Ferret" designed to automatically search their network applications and operating systems for noncompliant versions. This utility is free to all licensed users of Novell products and can be downloaded from http://www.novell.com/year2000/y2kferret.html. Microsoft has recently released Service Pack 4 for Windows NT 4.0, which, according to Microsoft, would bring the Windows NT 4.0 Server/Workstation operating systems into full Year 2000 compliance. It can be downloaded free of charge by licensed users of Microsoft Windows NT 4.0 from http://www.microsoft.com/msdownload/. Microsoft's Year 2000 resource center website is http://www.microsoft.com/technet/year2k.

The installation of computer BIOS upgrades, operating system upgrades, or patch files should only be performed by trained professionals that have technical experience with the systems in question.

Upgrading Generic Software Applications. In general, most commercial software Year 2000 upgrades take the form of new version releases. Since these releases are effectively standard upgrades to the product, no special care or skill is typically required to install them. Vendors usually provide clear instructions along with automated data conversion utilities for existing data and user information within the application. Users of older versions of a vendor's product that has not been regularly upgraded may find the new Year 2000 compliant version significantly different from their old product. For instance, some vendors may forgo releasing a Year 2000 compatible version of their DOS-based software and require users to switch to a Windows environment to run the new version. This transition may entail additional time, effort, and user training that should be taken into consideration when determining the time frame for full implementation.

Vendor product upgrades may not adequately address the Year 2000 compliance of customized generic software applications or customized applications developed by the generic programs (i.e., company databases and specialized spreadsheets). Any modifications performed upon or developed by a generic software application (including macros, formulas, and applets) must be verified independently by the party that developed the modifications or customized the functionality.

Replacing Noncompliant Software. If no Year 2000 upgrade path exists, the user will need to replace the application with another vendor's offering. In the event that the product being replaced is complex or will require customization, the purchaser should obtain contractual assurance that the new application (including all necessary modifications) can be implemented within the specified time frame and is fully Year 2000 compliant.

Customized Application Code Revisions. If the company is utilizing proprietary, customized applications that cannot be easily replaced, all lines of code must be analyzed and repaired as necessary. Numerous commercial software tools designed to aid programmers in the process of discovering and correcting Year 2000 coding errors exist for all programming languages and development environments.

Code analysis and repair can be extremely labor intensive. If the company utilizes customized business applications and has not yet begun a Year 2000 analysis, it is highly recommended that it employ such tools to expedite the remediation process or outsource this function to a qualified programming vendor immediately.

Phase IV: Testing

Vendor assurances are not sufficient for guaranteeing Year 2000 compliance. Internal testing must be performed upon any hardware or software application deemed critical to operations.

System Rollover and Leap Year Testing. At a minimum, all computer hardware and operating systems (including network file servers and peripherals) should be tested for both Year 2000 rollover and leap year functionality. This can be accomplished by setting the computer's clocks (BIOS and operating system) to 12/31/99 11:59 p.m. and 2/28/00 11:59 p.m. and analyzing what occurs as the date changes on the system. Alternatively, numerous PC shareware and commercial software products are available (i.e., Symantec's Norton 2000) that can simulate these conditions automatically and analyze a variety of other functions and applications for Year 2000 compliance. Test results should be documented, and any system that fails testing should be placed back on the remediation checklist for upgrade or replacement.

Application Testing. Application testing is a complex process that should be performed upon all date-sensitive and mission-critical applications. Particular attention should be given to accounting and financial system applications, as these systems rely heavily upon date functionality. All mission-critical applications in use should be thoroughly tested regardless of vendor claims regarding Year 2000 compliance.

Ideally, application testing should be performed on a replicated system or database, not the company's live systems. If the company lacks the necessary hardware or capacity to replicate its systems, numerous vendors (IBM, Comdisco, and SunGuard Recovery Services) can provide temporary land-based and mobile equipment and staging facility services to enable testing.

Application testing typically involves the following:

* Analyzing and documenting all date-related functionality and reports
* Developing test data. This data should be a representative sample of date range values for transactions typically generated on the current systems. An attempt should be made to look ahead and anticipate the range of values the application will be required to process in the future (i.e., aging parameters, date-of-birth and date-of-death information, and loan maturity life spans). All test data, notes, working papers, and testing results should be documented and retained for a period of five years for audit purposes.
* Determining that all system dates will be set appropriately for the desired test scenario (file servers, workstations, and applications)
* Testing modules for the application of Year 1999 transactions going forward
* Testing modules for the application of Year 2000 transactions going backward
* Testing modules for the application of Year 2000 operations including 2/29/2000
* Testing the ability of the application to handle the following specific dates: 9/9/1999, 12/9/1999, 1/10/2000, and 10/10/2000
* Documenting all errors discovered
* Working with application vendors or developers to address any Year 2000 issues discovered and monitor remediation progress in written reports.

Phase V:Critical Third-Party Reliance

Critical third-party reliance refers to all business entities and service providers upon whom the business depends to successfully conduct its operations. Any business provider whose failure to provide staffing, products, or services to the company could result in a material loss should be considered a critical third party. Typical critical third-party reliance candidates would include (but are not limited to) banks and brokerages; utilities; building management; key vendors, suppliers, and customers; telecommunications carriers; Internet service providers; value-added networks; electronic data interchange business partners; and service bureaus.

Assessing and documenting the Year 2000 compliance status of critical third parties is essential to the company's Year 2000 preparedness. Correspondence should be sent to all critical third parties requesting information and assurance regarding the Year 2000 status of their operations. Contractual assurances should be obtained from service bureaus performing mission-critical business functions (e.g., payroll, securities trading, and information providers). Documentation of the Year 2000 compliance status of critical third-party providers should be kept for a period of five years for audit purposes. In the event that a critical third-party service provider cannot attest to its Year 2000 preparedness or will not be ready in time, alternative sources should be researched and contracted to perform the services in question.

Phase VI: Contingency Planning

Despite the best efforts at establishing a state of preparedness, the fact remains that the full impact of the Year 2000 problem is entirely unpredictable. Factors beyond control could temporarily wreak havoc upon commercial utilities and support structures that businesses depend upon to conduct day-to-day operations. Major Federal and industrial studies regarding the state of the nation's power grid and telecommunications infrastructure are still not complete, and it is likely that there will not be enough time left to remedy all of the problems discovered.

While it is impossible to fully anticipate and prepare for every conceivable consequence, basic disaster recovery and business continuity planning should be a core component of the company's Year 2000 preparedness agenda. A disaster recovery plan provides the company with the strategies and technical resources necessary to quickly reestablish its critical business systems and operations in the event of disaster. *

Sid M. Edelstein is the director of information technology services for Cornick, Garber & Sandler, LLP. His firm has developed a Year 2000 Preparedness Kit that includes form letters and sample contracts, legal guidelines, accounting software vendor product status reports, and a list of useful resources and websites. It is available upon request by contacting the firm at http://www.cgscpa.com.