Testing testing.

If testing your systems for Y2K compliance takes 60 percent of the entire project's time, is there any way you can be ready?

By now, you know the Year 2000 technology problem has moved to the front burner; CFOs say it's their single most pressing challenge.

But you may not know that, as your business begins testing its information systems for Y2K compliance, you may face a number of issues that could produce delays and push your initiatives dangerously close to the January 1, 2000, cut-off (and those systems that store future dates, such as insurance policy expirations, must be fixed before we ring in the millenium). The two greatest risks are underestimating the work required to be Y2K compliant and failing to understand the full consequences of completing this effort on time.

As a CFO or other senior financial executive, you often have the ultimate responsibility for approving Y2K project costs, reporting related exposures to regulators and keeping your board of directors up to date on the firm's compliance measures. So as you test systems and examine an array of what-if scenarios, you should understand what can go wrong and what you can do about it.

Of the six fundamental phases of your firm's Y2K compliance initiative - inventorying your systems, determining which will be affected, assessing your risk, remediating, testing and implementing changed programs - testing is one of the stickiest.

The Testing Template 

As you prepare to test your systems, you first need to establish a consistent methodology. This is especially true for larger organizations with numerous divisions and independent operations. Even if different business units use entirely different hardware configurations and software packages, every organization should have a uniform approach to testing that all operations can implement.

At J&H Marsh & McLennan, Inc., a subsidiary of Marsh & McLennan Companies, Inc., we began a Y2K compliance initiative in 1996, so the effort is well along. Our Y2K testing methodology, developed by the technology and information services department, sets minimum standards to be followed by all of our technology operations. It includes guidelines for organizing test teams and for developing a test plan; templates for process administration and documentation; a test script that contains both mandatory dates to be tested and a list of additional dates that may affect certain functions within an application; and formats for performing tests and documenting results.

In the testing phase, it's critical to develop appropriate tests that focus on date-related functions. For example, the customer database of one company tested fine, but when the firm entered actual data from its clientele, the system ran amok. Time constraints prevent you from testing every bit or byte of data, so make sure the sample data reflect all date-related functions in your applications.

Because testing is the only way to determine how well any computer system will function with the Year 2000 date change, this phase is critical. Testing normally takes 40 percent to 60 percent of the Y2K project time, and most firms underestimate this stage of their correction plans.

The effectiveness of a testing effort depends on how thoroughly the firm has inventoried its systems and those of its suppliers and vendors, assessed critical operations and set priorities and implemented appropriate remediation measures. Nonetheless, even if every measure were flawless, you still might uncover some serious problems.

Mainframes, Mergers and Renegade Systems

After taking an inventory of their computer-based exposures, many businesses quickly realize their testing capacity is insufficient - they won't be able to test all their systems in time. If that happens to you, you can form a Y2K team that involves managers from a cross-section of disciplines to help set priorities based on critical functions and testing resources. (See the box at left.)

Most firms operate mainframes at a high capacity, so there may not be much additional capacity for testing. Your team must determine if you need to invest in additional capacity to meet your test objectives and timetable. Also, you'll have to evaluate the capacity of your mainframe to handle a new test partition for Y2K testing. If capacity is an issue, you may have to upgrade, which may be very costly. In the client-server environment, you'll typically need to purchase additional hardware and software to support Y2K testing and avoid disrupting your production environment.

Of course, if your company is planning a merger or acquisition, you must conduct a thorough examination of the partner or target company's Y2K compliance initiative to be sure you don't inherit a significant problem. As part of our due-diligence process, we evaluate the Y2K compliance initiatives of potential partners.

A Y2K problem also can affect the value of a target company. As the combining firms integrate their operations, they must decide how quickly they can combine information systems. In some situations, you may not be able to complete a timely systems integration. If that's the case, both firms' systems would have to be made Y2K compliant.

Along the same lines, even if all of your systems are Y2K compliant, you could encounter major difficulties if a vendor's or supplier's systems aren't. That's why your testing initiative must include tests of all the vendor or supplier systems that communicate electronically with yours; you can identify potential problems with vendor systems then. If your vendor won't be compliant on time, you may have to seek alternatives.

Like rogue cops, renegade systems and applications also exist. While it's nearly impossible to test all the personal-computer software packages individuals throughout your organization use every day, remember that some of these applications may be critical to your firm, to one of your key operations or to a major client. In many businesses, employees or isolated business units use software packages that aren't Y2K compliant. Early versions of several popular PC-based database and spreadsheet packages still in use may not be problem-free. And individuals using Y2K-compliant packages may create their own applications that trigger problems.

The key here is to communicate early and often to identify the problems, then to use all means available to correct them. Several software manufacturers are using the worldwide web to communicate possible Y2K problems inherent in their products and available remedies. Their web sites are an excellent resource to help you identify and fix potential problems. But even so, you may need to test the solutions these providers offer.

Because the Y2K problem is unprecedented, you can't always precisely estimate the timeframe to correct it. In some cases, businesses need to establish contingencies in the event that some of their systems - or their vendors' systems - won't be compliant on time. Going to your technology disaster recovery site won't be the answer because any non-compliant applications you're running still won't work at the alternate location. The system has to be corrected or you need to establish work-arounds or other alternative ways to accomplish the task.

As you begin testing, remediating, retesting and repeating the process, you must constantly be aware of your deadline for initiating contingency measures. Remember, in some cases, contingency initiatives need to be tested and require time to implement. Similarly, you have to determine how long you can continue to work with a vendor, bank or payroll firm that's not compliant before you move to an alternative, compliant vendor that can support you.

You also need to ask whether it makes more sense to repair or replace. In some cases, it may be more cost-effective to replace an existing system with a new one than to try to make it Y2K compliant. If you go this route, however, the clock will still be ticking: If you can't replace your systems and provide the necessary support and training in time, you may need stopgap measures, such as a phased-in replacement of systems or temporary outsourcing of certain functions.

What Falls Between the Cracks

As has been widely reported, the Y2K problem is not limited to mainframe and personal-computer systems and software; it can affect anything that runs on embedded chips. As a result, a firm's Y2K steering committee needs to think broadly about what can go haywire and consider the implications. For instance, the access to many commercial buildings is security-controlled. The Y2K problem may cause security doors to cease operating, so firms with these systems should involve their corporate real estate and facilities managers in their compliance initiatives to investigate potential problems. You also may have to take a look at your elevators, fire-safety systems, fax machines and voice-mail systems. Because embedded chips are used extensively in manufacturing equipment and health-care devices, this issue is especially critical in those industries, too.

A Y2K testing initiative also might reveal that your firm won't be compliant on time. Of course, you hope that any such revelation will occur early enough in the process for you to accelerate your compliance initiative or to identify acceptable alternatives. This underscores the fact that it's critical for management to include the appropriate experts from all the relevant corporate disciplines on its Y2K compliance committee.

With the right team in place and a well-orchestrated testing initiative, you can be confident that you're doing your utmost to ensure that your firm meets your Y2K compliance objectives.

RELATED ARTICLE: Team Y2K

Before you get to the testing phase - and certainly while you're in it - one of your most important functions is working with the company's Y2K steering committee. Because you'll make major corporate decisions based on its recommendations, you must ensure that - in addition to having strong information-systems representation - business managers and other executives who direct vendor relationships or critical facilities that could have Y2K exposures sit on the committee. For instance, executives from the corporate control functions, such as auditing, may add value through their broad and independent perspective of the overall corporation and their understanding of its critical operations.

Risk-management executives also are crucial resources for developing and assessing contingency plans. And your legal counsel can assess potential liabilities associated with non-compliance by third-party vendors or key suppliers. In the case of insurance brokers, insurance carriers are critical business partners. One function of J&H Marsh & McLennan's Y2K steering committee, for instance, is to gather information from the carriers it uses to determine if they'll be substantively Y2K compliant and able to support its clients.

-- MEB 

Mitchell E. Blaser is CFO of J&H Marsh & McLennan, Inc., based in New York City. You can reach him at [phone].