December 31, 1999. A once-in-a-millennium New Year's Eve to remember. I expect to enjoy it, secure in the knowledge that the sun will rise the next morning (the sun always rises in Hawaii) and that--well before that night--my bank will have solved the "Year 2000 problem." If we haven't, it won't be for lack of advance planning and effort.

Are you worried? You'd better be, because the "Year 2000 problem" is a massive one for anybody who processes data. One consultant has been quoted as saying that, compared with the potential worldwide predicament associated with computers and the Year 2000, death and taxes will look like discretionary items.

The problem--in a nutshell--is this: many computer programs use two digits to represent the year (1997 = 97). When that shorthand becomes "00," will your computers know what year it is? Or will they assume it's now 19007

December 31, 1999 is a non-negotiable date. On some fronts, you don't even have that long. Soon, you'll be issuing credit cards with the Year 2000 expiration dates.

As of late last year, national surveys showed less than half of all companies had initiatives under way to deal with Year 2000; a surprising number haven't even begun planning.

I'd like to offer some thoughts, based on our bank's approach:

1. It's a survival issue, not a "computer problem." Many executives dismiss Year 2000 as "a computer problem." We may pooh-pooh computer problems that are hyped in the media because they often don't turn out to be nearly as bad as billed. (Remember the Michelangelo virus?)

Think again. This is not just a computer problem. It's a business survival issue to be addressed company-wide. Besides computers, Year 2000 can effect heating and air-conditioning systems, vaults, security systems--anything with computerized time code in it. These peripheral systems may appear to be minor inconveniences...until you get stuck in an elevator that won't work.

2. Your problem doesn't exist in a vacuum. Your bank's systems interact every day with those belonging to customers, vendors and suppliers. Are they, too, already at work solving the problem? Do you know where they stand? Don't assume they have it under control. If you fix your end, but they don't fix theirs, you have a joint mess.

Consider, for example, a simple retail credit card transaction. Year 2000 problems may affect the card itself, your bank, another bank, the merchant's terminal, the merchant's cash register, the phone company, the bank card association.

If you have lots of "home-grown" software developed in-house, the bad news is you need home-grown repairs as well. If the job of creating applications was outsourced, do you know the outsourcer's fix-it plan?

If few of your applications are home-grown, the good news is that your vendors are probably working on solutions. The bad news is that your future is in their hands, reliant on their expertise (or lack of it) and their schedules. If they miss December 31, 1999, you're out of luck.

As we go through our bank, department by department and application by application, we're using the "4 R" options to decide how to insure Year 2000 compliance:

Release. A vendor solution (release) will be installed.

Renovate. We'll fix our own home-grown software.

Retire. The application is no longer necessary, so we'll retire it.

Replace. We'll install a new application.

3. Don't overestimate the time remaining. As of June 1, 1997, only 944 days remain until 12/31/99. You may well need all 944 if you don't get started now. Subtract weekends and holidays and you have about 650 business days left. You can't get a lost day back.

4. Don't underestimate the resources you'll need. For the next two-and-a-half years, everybody--not just banks--is in the same boat, all chasing after a limited number of programmers and software experts. Mainframe programmers are already hard to find. The closer we get to 1999, the more expensive (and less available) those resources will be.

Solving Year 2000 will inevitably impact your bottom line--more so if you wait. Not solving it properly may expose you to legal liability.

Sometimes, we toss one-time projects to the person with the most time on his or her hands. We can't risk that. At First Hawaiian we have a first-rate project manager in charge. It's too important not to.

As with any other challenge, sometimes you can turn it into an opportunity. When some of our customers came to us looking for advice about Year 2000, we worked with an accounting firm to host an educational seminar. More than 150 of our top business customers came. It was a real eye-opener for many. All of them were pleased that their bank seemed to be on top of it.

Good luck, and Happy New Millennium!

By Walter A. Dods, Jr., chairman and CEO, First Hawaiian Bank, Honolulu, Hawaii