InformationWeek

Getting software ready for the millennium could cost as much as $600 billion worldwide.
Worse, only half of all companies will be ready.

By Doug Bartholomew
Issue date: Feb. 5, 1996
"A lot of companies are like deer frozen in the headlights of a big truck coming right at them." --Kevin Schick, analyst, Gartner Group

Actually, it's as if those companies must deal with a bomb that's ready to explode. Never befo re in the history of computers has there been such a threat as the one posed by the year 2000. Now less than four years away, the turn of the century promises to wreak havoc on the world's legacy systems unless they're fixed or replaced.

"This is the biggest single information systems project the world has ever seen," says Stan Johnson, chief information officer of the Port of Los Angeles, "and it could turn out to be the biggest goof." The reason: Half of all companies will still be unprepared by the time the big ball descends in Times Square on Dec. 31, 1999, predicts Gartner Group Inc., an information technology advisory firm in Stamford, Conn. As for now, InformationWeek's informal survey of IS managers and consultants finds that not a single U.S. company is completely 2000-ready.

The roots of the year 2000 problem lay in the past use by programmers of six-digit date fields in many business applications. Because the year is indicated by just the last two digit s-1996, for example, would be represented as "96"-when the year 2000 rolls around, these programs will assume the date is 1900. For any program that is time-sensitive--and in business, that's most programs--the result could be complete failure.

The threat is not only real, it's also ominously predictable. You know exactly when it's coming, and you still can't postpone it. "Nobody can change it for you," says Colin Campbell, senior computer scientist at CSC-Hughes in El Segundo, Calif. Quips Kevin Schick of the Gartner Group, "It's the first time IS has had to do something by a certain time."

Almost every kind of software--not just the legacy stuff--is at risk. As for hardware, the problem spans not only mainframe systems, but also networks, PCs, and all kinds of computer hardware. If you don't believe it, ask IBM. Last fall the company revealed that some of its decades-old hardware, such as the S/370 mainframes, cannot be modified at all to speak 2000-ese. Instead, users will have to replace those machines--at a cost of untold millions of dollars.

There are signs that the IS community, after paying scant attention to the problem for years, is finally waking up. This past November, more than 700 IS managers attended a sold-out year 2000 conference in Orlando, Fla., organized by the Software Productivity Group of Westboro, Mass. SPG has set follow-on year 2000 conferences for March 7 to 8 in New York, April 3 to 6 in Chicago, and Sept. 11 to 13 in San Francisco.

But going to conferences and dealing with the realities in your company's computers are two very different things. The impending date change is forcing technology managers to warn their CEOs and chief financial officers. Their companies are running millions of lines of computer code that in just a few years won't work.

Failure to get 2000-ready carries the possible penalty of total business failure. "Some financial-services companies will go out of business because they didn't fix this problem," says Jim Woodward, senior VP at Cap Gemini America in Iselin, N.J., which is helping businesses get their computers ready for the year 2000.

The impact will be particularly acute for banks and other financial institutions. So many bank functions, including determining interest payments, are based on the time-money equation. If their systems aren't fixed in advance, bank systems will either crash or compute incorrect information. "A bank's data could lose its integrity, and that's what their business is based on," Woodward notes.

The alternative to doing nothing about the year 2000 is spending a bundle on fixing myriad systems throughout a large organization. For example, one large New York bank estimates it must sort though about 250,000 applications. Analysts estimate the cost to fix year 2000 troubles could add up to $40 million per large corporation. In fact, the most difficult piece of the message IS must give senior management is not so much that the problem exists, or that IS caused the problem, but the sheer cost.

Worldwide, the cost of fixing the year 2000 problem will reach $400 billion to $600 billion, the Gartner Group predicts. To put that amount in perspective, that's roughly IBM's total revenue, at current levels, for nine years combined.

So, you might ask, why didn't anyone think of this when these programs were written decades ago? Were the programmers and developers who wrote them merely short-sighted?

Not at all. They honestly believed they were saving their employers money--and at the time few, if any, imagined these systems would be used into the next millennium. "Back when these systems were set up, external disk memory was expensive, and they saved millions of bytes of storage by not using fields for the year," says Woodward of Cap Gemini. "This problem now is the interest that organizations are going to have to pay on that discount."

Not s urprisingly, given the huge cost of fixing the year 2000 problem, a slew of vendors offer help to technology managers. From IBM to Dun & Bradstreet Software, to Cap Gemini to TransCentury Data Systems, Peritus Software Services, and Adpac, it seems everybody wants to help corporate America get things straightened out in time for the 21st century-and get a chunk of that $600 billion cleanup fee.

Possible solutions include buying new systems or updating old ones. The latter approach involves going into the code and fixing each date reference using semi-automated tools such as those offered by Adpac, Peritus, and TransCentury Data.

Updating old code is the approach being used by Reliance Group Holdings Inc., a $3.1 billion property and casualty insurer in New York. Under a project managed by RCG Information Technology, its IT subsidiary, the company's Reliance Insurance division in Philadelphia is using semiautomated tools from Viasoft Inc. of Phoenix. Reliance has hired a team of a dozen outside programmers to expand date fields in its core business system for processing premiums and claims. "Reliance Insurance plans to get the project done in time to be able to write three-year policies," says Ray Sheerin, a senior VP at RCG, which also provides year 2000 services to other companies. Reliance expects to be done by July 1997, well ahead of the October 1998 cutoff date for writing three-year commercial casualty coverage.

The cost and hassle of fixing the date change may be sufficient reason to purchase and install client-server software that's 2000-capable. "People say you get nothing for fixing year 2000, but that's not true," adds Schick of Gartner Group. "This can be a catalyst for change if you're considering migrating to relational databases."

That's one approach being weighed by the Port of Los Angeles. The port might stick with its Dun & Bradstreet Software mainframe systems and use D&B's scheduled upgrades that will be 2000-compli ant. Or it might purchase new client-server-based software, which would require a whole new set of in-house skills. "Do we just fix the millennium bug," wonders CIO Johnson, "or should we take this as an opportunity to put in some new systems?"

At CSC-Hughes, the former IS unit of General Motors' Hughes Aircraft division that outsourced its computer shop to Computer Sciences Corp., business managers only recently understood the full importance of the year 2000 problem. "We are bringing the situation to the attention of Hughes," says computer scientist Campbell.

Actually, Campbell tried to develop an awareness of the problems associated with the century date change at Hughes back in 1991, but to no avail. But with a new boss in place, he's now able to get the message across. CSC-Hughes has formed a year 2000 team and put Campbell in charge of gathering and sharing all the organization's information on the year 2000 issue.

The problem is especially pre ssing for Hughes. The company uses an older manufacturing resource planning (MRP) system that won't accept dates beyond 1999. But Hughes expects to sign contracts that will go well beyond that date.

Hughes already has used homegrown software to convert about 1,000 applications to handle four-digit years. Still, some 30,000 mainframe programs and dozens of date routines remain throughout the company. Campbell says Hughes may elect to use commercial software packages to handle the date conversions.

Probably the most frightening aspect of the year 2000 problem is that it could transcend any one company's borders. Even if your company has solved the problem, your customers' and suppliers' bad data ultimately could pollute your 2000-enabled systems, similar to the way a computer virus spreads. Chubb Insurance Co. of America, worried by this possibility, hopes to educate its business partners on the issue. "We're going to take an aggressive stance to educate our clients, as well as those we d o business with, such as banks or other insurers," says John Jung, VP and year 2000 project manager at the Warren, N.J., insurance firm.

This month Chubb will begin the first of a series of data conversions. Cap Gemini will use proprietary software to help ferret out and change two-digit dates to four digits. The Chubb project is scheduled to be completed by December 1997.

In Reserve
Much further along is the Federal Reserve Bank. It began a major upgrade of mainframe-based systems five years ago-though it's still a few years from completion. The redesign includes homegrown software that is year 2000-ready, says Nancy Emerson, director of applications support for the 12th Federal Reserve District in San Francisco. Getting the overhaul are such vital Fed systems as funds transfer, securities transfer, accounting, and treasury systems. "Our new system will already accommodate the four-digit year, so we don't see the year 2000 as a major effort for us," Emerson adds.

Still, many companies act as is if their systems are all but immune. Says the CIO at a major New York brokerage firm, "We've started looking at [the year 2000 problem], but I don't think it's going to be that difficult for us."

Gartner's Schick calls that attitude "denial." He adds: "My chief concern is that the attitude among the companies I've met with and talked to about the issue has shifted from awareness to denial. Our view is that no one is immune."

Part of the reason for the denial is the assumption that most newer software programs can handle the date change. Not necessarily so, experts warn.

"Most companies should assume their systems are guilty until proven innocent," says Cap Gemini's Woodward. "Just because you have a client-server system doesn't mean it's year 2000-enabled." In fact, no software platform is totally immune from the problem, analysts say.

Some companies simply aren't willing to spend the money for something that promises no tangible payback. "I ran it up the flagpole here about three years ago, but I've not been able to get anybody to pay attention to it," says a frustrated Brian Pitts, a senior systems analyst at the Berry Network, a national marketer of Yellow Pages advertising in Dayton, Ohio. "Their attitude is, 'I don't need to hear about this now, because this doesn't bother me today.' The bottom line is that if it's not going to make them money, they're not interested in hearing about it."

The year 2000 date change could bring a lot of money to software suppliers. Dun & Bradstreet Software in Atlanta already has released new versions of its mainframe software to manage fixed assets, general ledger, and human resources that are year 2000-compatible. D&B also plans to update its purchasing, receivables, and payables modules in the next year.

By contrast, several Big Six consulting firms have been unusually quiet about the year 2000. Gar tner's Schick wonders if the reason could be a concern over culpability. "I think it's because they are worried that somebody's going to ask the question if they are at fault," he says. "If I paid $5 million to $10 million to EDS or Andersen Consulting to build a system, and now I have to spend $3 million more to fix it, I'm not happy."

But the consulting firms say they've been quiet because year-2000 clients are already coming to them in droves. "All of our client base has this issue, and we're getting a request for proposal every other week," says Ken Gernhart, a senior manager with Ernst & Young's Center for Technology Enablement in Detroit. Ernst & Young has devised a year 2000 solution by joining forces with Formula Systems Ltd. of Israel, which has a semiautomated system for fixing the dates in software code. Help is clearly available. But the bottom line for anyone concerned about getting their systems ready for the year 2000: Time is running out. The time to start is now, if not sooner--and be prepared to pay, big-time.

If that gives you the jitters, there is one other way out. CIO Johnson at the Port of Los Angeles, who turns 65 in December 2000, plans to retire this summer.