A status report: the year 2000 bug.

CASE STUDY

One congresswoman just announced she's working on legislation to require that new computer products sold to the government be able to process post-Year 2000 dates. Thank you, ma'am, but most companies know if they haven't demanded that by now, they're in trouble. In fact, when Financial Executive went looking for some slow starters on this date-conversion project, we hit a stone wall. Not surprising, most executives report (whether it's true or not) their companies are in the middle of the pack in addressing the computer bug - not too ignorant, not too aggressive.

Here's a glimpse at where four firms stand on the task.

Ameron International Pasadena, Calif. Project status: Analysis phase

The Year 2000 problem is wider spread than you may think,

warns Dewey H. Norton, vice president and controller of Ameron International. "It can actually hit a company well in advance of the Year 2000. Anybody whose planning horizon goes out 18 months will have problems in July of 1998. It also affects a great deal of software beyond business systems, like controls for machine tools. It can even affect pc-based systems."

With annual sales over $500 million, Ameron International manufactures concrete and fiberglass pipe systems and protective coatings for such giants as CSX, Disney and the U.S. Navy. Mark Peterson, American's corporate systems manager, says it's too soon to estimate the budget for their project since it started only two months ago, although he suspects that around 50 percent of the companywide systems will have a date problem. Norton adds that his company should face little out-of-pocket costs, "unless we have to hire programmers."

Like other companies, Ameron is attacking the problem from three directions. First, any new software must be compliant. Second, the latest releases of any upgrades must be compliant. Third, the company will identify and correct any inhouse applications that aren't compliant.

One dilemma for Ameron is whether to invest in upgrading one of the general business packages it now uses, since its vendor just sold the product to another vendor. "We're not sure we want to put the dollars into it that the new owners will require for the next upgrade," Peterson reasons. "Is it going to be cheaper to have our people make the changes, to buy the new module or to buy a whole new system?"

Peterson and Norton are unsure when they'll complete their project but hope it's done by the middle of 1998 to give them time for finetuning. "I don't think everybody can find every instance of a date," Peterson says. "People absolutely will be reworking their programs after the beginning of the Year 2000."

Norton's advice: You can't have blind faith in your vendors. "These software companies aren't perfect. Most will handle this issue rather well, but there will be some awkwardness with some customers. Also, companies should share a list of some of the unexpected problems they come across. What did they discover they had missed - after they thought they'd done it right?"

Partners HealthCare Systems Boston, Mass. Project status: Completing the identifying-solutions phase

In the next fiscal year, Partners HealthCare Systems expects to spend $2 million, or 5 percent of its information technology operating budget, to remedy the Year 2000 problem. "That should pretty much cover the cost of the project," says John Glaser, chief information officer of the firm, "although I think there's still a fair amount to discover." The company came up with that number using a cents-per-line-of-code formula that accounts for such intangibles as training issues, management's time and interaction with suppliers.

Glaser and his staff have been planning for this project for five months and will start making changes in the code in mid-July. They've decided to call on outside resources to trudge through the programs to look for the two-digit date field - estimating they'll need eight external people at the project's peak. "But no other entity should say, aha, that's the number of people we should have," Glaser warns. "It all depends on the scope and age of your systems and whether a third-party vendor is going to take care of some of the problem."

Glaser's approach is to first identify the major systems he suspects will be affected. "Some of these systems are targeted for replacement," Glaser says, "and their successors are already Year 2000-compliant. For the other systems, programmers going through the code can sometimes use automated tools to help them find the date fields."

One item that's muddying the process for Partners HealthCare is specialized, stand-alone software that researchers use but the firm doesn't track. So, although the company has a good inventory of its systems, it's never complete.

The firm expects the project to be complete at the end of 1998.

Glaser's advice: "There's no magic or mystery here. The project just calls for some reasonably intelligent planning to understand the scope of what you have to do and to make sure you have the staff, internal and external, to do it."

Airlines Reporting Corporation Arlington, Vir. Project status: Implementation phase

Jack S. Mallinger, vice president of financial services at the Airlines Reporting Corporation, thinks some companies may take their chances with the Year 2000 bug. A one-time Cobol programmer, he understands the logic behind that decision. "Depending on how your program is written, you might never know there's a problem. Are you using that date field for anything other than a date?" If you aren't, he says, you could be safe.

His firm isn't counting on that. Airlines Reporting started its formal Year 2000 project in the beginning of 1997. "From a systems standpoint, it's not the kind of project that wins you a lot of points," Mallinger explains. "You'd rather do something that has a higher payoff, not something defensive in nature. It's tedious work and some people would prefer more-challenging projects. But I think all this publicity is helping in the recruiting."

Airlines Reporting collects about $64 billion annually from travel agents and distributes these payments to 150 participating airlines. "The airlines want to be darned sure nothing disrupts that flow," Mallinger says, "so their representatives who sit on our executive committee have made it clear that we need to have a good plan."

The company's problem is an anchor of legacy systems, some as old as 25 years. Mallinger suspects they're ridden with Year 2000 problems, which makes the conversion effort massive. But the firm's chief information officer is taking a methodical approach.

According to Mallinger, the CIO has catalogued 100 percent of the company's applications and every time his programmers enter a system for routine maintenance, they check for - and fix - the Year 2000 bug. That approach eliminates the code's learning curve that the vice president of financial services believes is so time-consuming. After a designated cutoff date, the CIO's staff will open all the programs that haven't naturally been opened during maintenance and specifically address the bug.

To fix one subset of older, management-information systems that aren't opened often - and thus could fall through the cracks - the company hired two work-at-home consultants for two years for a fixed price. And all new applications will be Year 2000-compliant.

Two benefits from the project: The company discovered some obsolete programs it could phase out, and Mallinger found some hidden talent. "I've been impressed with the job our people have done. They're handling it well."

Mallinger's advice: "Take a comprehensive approach. We're looking at the entire systems population, rather than just saying this application is affected and this one isn't - because it's hard to know where the problems really are and you leave yourself vulnerable."

TRW Cleveland, Ohio Project status: Implementation phase

Only 40 percent of TRW's automotive business units have to worry about the Year 2000 computing bug, says Thomas A. Connell, vice president of finance.

After a year on the project, the company is well into the implementation phase but Connell prefers not to put a number on its cost. He reports simply that TRW is using inhouse programmers and "hiring on the outside, including consultants to help us through this."

"What complicates the process is the company's additional initiative of implementing shared services in North America," Connell explains. "We're in the midst of centralizing our automotive accounting transaction processes. If a business unit has a Year 2000 problem, we will integrate its manufacturing systems with shared services using the same software. For those traits not needing to make a change, interfaces will be written from our new accounting systems back to the manufacturing legacy systems."

TRW has been meeting with its customers to reassure them the firm is dealing with the date conversion and their business won't be interrupted come January 1, 2000. Like many firms, TRW also is asking its suppliers to confirm they're going to be compliant.

When Connell attended the last shareholders' meeting, no questions came up on the topic, he notes. Likewise, financial analysts following the company aren't asking about it, he says. The company's audit committee is, however, asking the typical questions. Connell's response is, the project is moving fairly smoothly, with the availability of human resources the only stumbling block. He explains: "TRW has gone through a delayering process, trying to take out costs wherever possible. Putting in new systems adds another complexity, of course, so we have to make sure we have the resources available."

The vice president of finance estimates the project will be complete for the finance side of the house by the first quarter of 1999.

Connell's advice: "Don't underestimate the size of the project. While we've done a fairly extensive job in terms of project planning, including laying out schedules, the human resource element is limited and the timetable has a tendency to slip."

RELATED ARTICLE: Half the Battle

In mid-May, Financial Executives Institute s Committee on Corporate Reporting polled 21 of its Fortune 100 members about their Year 2000-compliance projects. The answers were encouraging. Only three respondents are still in the study and analysis phase, seven are currently identifying solutions and 11 are well into implementing their solutions.

"Of course, this isn't a scientific survey," William Nowak points out. Assistant controller-accounting of the Cleveland-based Eaton Corp., Nowak developed the survey for CCR. "The biggest surprise to me is companies are further along than I anticipated. I do think there may be a touch of optimism in the responses, but I still view the findings as a bellwether." Nowak reports Eaton's project status lands somewhere in the middle of the response range.

Surprisingly, nearly half of the companies confess they still don't know how much this project is going to cost. [ILLUSTRATION FOR CHART OMITTED]. Nowak attributes this to several complicating components of any estimate: Should companies count the cost of their internal resources, since the programmers devoted to the Year 2000 project would just be working on some other program if the bug didn't exist? If a firm is buying new systems, what portion of their cost should be allocated to the Year 2000 fix? Also, in a decentralized technology environment - and 14 of the survey respondents operate this way - rolling all the data into one lump sum to arrive at an estimate may be difficult.

The assistant controller noted two critical issues stemming from the computer date bug. Firms should look carefully at their relationships with their suppliers and ask for certification that these business partners are on top of the problem, too and be sensitive to the same requests from their customers. Also, executives heading up the Year 2000 project must pay special attention to the manufacturing process, where it may not be as easy to locate the vulnerable areas, but where companies have "a huge exposure," Nowak says.