The strategy conversation you can only have here
Newspapers and magazines have been shouting impending doom as computers are gearing up to deal with the switch over from 23:59:59 on 31st December 1999 to 00:00:00 on the 1st January 2000. If you haven't yet heard anything about the 'year 2000 problem', 'Y2K compliance', 'the millenium bug' or 'century date code compliance (CDC)' then you are far defter at dodging sensationalism than I am.
It is of course a real problem and quiet likely to affect a number of people. Almost all of us are in one way or another reliant on computers. If you think you're not and you don't even know how to switch one on then think again. When last did you use an autobank, a petrol pump, an elevator or fly in an aircraft? All of these are dependent on computers and if not checked out could cause a problem.
The issue revolves around the fact that many systems written over the last 30 years stored only two digits for a date - so instead of storing 1987 the system stored 87 (assuming that the century will always be 19 for the life of the system). At the time it was expensive to store information and programmers were very conscious of saving whatever space they could. A database with 10 million dates stored as 87 takes half the space of 10 million dates stored as 1987.
So there are systems out there that are not going to know anything about the 21st century. Problems that arise could range from the disastrous to mere inconvenience. Credit card expiry dates that used to be in the format 08/97 will now have to be extended to include the century. Banks may face more drastic problems. Their computers have checks built in which disable customers' accounts if they haven't been used for a certain period of time. If the computers do not know about the century, then on the 1st January 2000 they will subtract the current date (00) from the date when the account was last used say 27th December 1999 (or 99). This will result in them thinking that the account hasn't been used for 99 years and they will logically (as computers are) disable it.
These mistakes are not normally very difficult to fix. A graduate programmer should be able to rectify most of them with one arm tied behind her back. The problem is that some companies don't recognize that they have a problem and won't until Saturday morning on the 1st January 2000. By that time things are going to be pretty hectic. Step in the consultants and self-appointed experts on the year 2000 problem. If you believe everything that you hear from these people, you might as well close down your business and spend your time thinking of your next career.
Large accounting firms, legal firms and software companies are all getting in on the act by offering their services. Employing these people you will quickly be advised on the current horror stories about companies that will fail because of the year 2000 problem. You will be further advised on how to employ them for large periods of time (normally until 2001 when the danger will have subsided) to advise you on how to make your systems year 2000 compliant. In selling their services they are likely to instill a sense of fear in you that without them you are going to face a major disaster.
The year 2000 problem is a real threat to business. It is highly likely that you and your company will be affected by it in some way between now and the turn of the century. Like any problem though, hype, panic and fear will not do anything to solve it. Don't believe everything you hear from people who are supposedly assisting you in solving the problem. First identify potential problem areas - these can range from your mainframe, to your PABX and pocket calculator. Work out the worst case scenario, decide what is crucial to fix and set about fixing it. Ignore the endless articles showing statistics of how many businesses will fail in 1999. At the end of the day, the most important thing is that you survive.