Make your own free website on
Recommended Resources Offshore havens, asset protection, global investing and other useful techniques.
The Year 2000 Bookshelf Books to help your evaluate the Y2K problems you face.

Gary North's Y2K Links and Forums - Mirror

Summary and Comments

(feel free to mail this page)




1998-05-01 18:36:49


Insurance Company Seeks Compliance: How?



Here is the monumental task facing an insurtance company. Its task is typical of any large business today. But its skills in solving the problem are way above average. And its cost -- because it began early -- is way below average.

Of course, management assured the reporter that the code will be fixed by _________. (You fill in the blank. If you have visited my site for more than a month, this should be easy.)

How can this story -- still unfinished -- be duplicated all over the world, in every large institution? The answer is obvious: it can't.

The company hasn't gotten to the problem of shared data: noncopmliant data imported from the outside. That problem must be solved before 2000, assuming the power grid stays up, along with the phone system.

This appeared in the AUSTRALIAN FINANCIAL REVIEW (April 20).

* * * * * * * *

If you think fixing the year 2000 bug is routine, talk to Mary Libens, chief Y2K troubleshooter at Medical Mutual of Ohio.

The $2 billion medical insurance company in Cleveland, Ohio, made all the right moves. It got an early start grappling with its millennium problem.

It brought in Ernst & Young consultants -- some of the most experienced in the business. Senior management made Y2K a top priority, and staff co-operated, grasping the enormity of the problem.

The results? At 20 months and counting to January 1, 2000, Mutual is still racing to debug and test its systems. Libens' team long ago despaired of scrutinising every date in the company's sprawling software operations and databases, which contain the equivalent of 64 billion pages.

For whole swathes of non-critical programs, they've resorted to a patchwork of quick-fixes, trade-offs, tricks and triage. Through it all, a string of unpleasant surprises in the repair process, called remediation, have left Mutual's Y2K team awestruck at the task's scope. "The job is orders of magnitude bigger than expected," Libens admits. "We're scrambling."

The good news: Mutual's critical systems should be shipshape by the end of 1998, allowing for a full year of testing. . . .

The majority of big corporations like Mutual have spent much of the past 40 years adding new computers and software willy-nilly, building up great stables of information and a tangle of jerry-built routines.

With Y2K, for the first time they will be forced to sift through these diverse systems. The programs they devise to remedy the date bugs will, like any software, be imperfect, causing new glitches.

And at this late date, companies could have trouble enlisting the aid of qualified consultants, most of whom are already tapped out assisting customers that signed up early.

As the clock ticks, programs slapped together will produce increasingly less satisfactory results. The problems, Libens says, "are overwhelmingly huge".

Mutual owes its early start to Libens' boss, chief information officer Kenneth Sidon. Early in the decade, Sidon recalls that the millennium bomb "was something we kidded about". But when he began to consider the implications, all joking stopped.

In 1995, he began combing through the company's systems and was aghast at what he discovered: a dizzying total of 25,000 computer programs, many added through three acquisitions made over the previous decade.

All told, Sidon counted 70 distinct operating systems at work in 36 locations across several states.

The hardware diversity was equally horrific -- a hodgepodge supplied by 64 different vendors. In one basement office, an ancient IBM mainframe toiled away. In another stood a spanking-new Hitachi mainframe, running a different operating system. PCs -- some 3,300 of them -- were linked in heterogeneous networks managed by UNIX and Windows NT servers. These shared work with about 800 1970s-era "dumb terminals". . . .

At this juncture, Sidon was handed another nasty surprise. Some suppliers had never gone back and tested their products for Y2K compliance.

Many of the smaller companies were no longer in business. Some who were still around tried to turn Mutual's emergency into a sales opportunity, asking Sidon to buy special Y2K-compliant upgrades. "We've shut some of those vendors down," Sidon snorts.

After the initial winnowing, Sidon found he had 9,000 programs to revamp. . . .

Mutual's budgeted $5 million. That's about one-third what he would charge for a similar contract today. "It's the one we learned on," he explains. . . .

Libens perseveres, because she knows Mutual will make it through. But what of the large companies that are just getting started? In a recent survey of 450 businesses in North America, the Information Technology Association found that 45 per cent of them are still studying their systems and have yet to start fixing them.

A year from now, they'll begin hitting the same kinds of hitches and delays that Mutual has been living with for four years. It's inevitable. It's software. To one and to all -- Godspeed. Business Week

Countdown for Medical Mutual 1995: CIO Ken Sidon, looking into the year 2000 glitch for the first time, orders an inventory of all the company's computers and software. He finds 25,000 programs, two-thirds of them obsolete. The rest need to be fixed.

1996: After hearing Sidon's Y2K bomb scenario, the board allocates $5 million. Sidon hires Ernst & Young to help. The goal: to change as few dates as possible so that all the important ones get fixed.

1997: The company starts walling off entire sections of data processing while they're under repair so that new data isn't entered into old, flawed programs. The early fixes finish on schedule.

1997: People in the company whose systems are deemed non-critical start hearing that two-digit dates in their programs will not be converted to four-digit ones. Complaints start streaming in.

February, 1998: While working on the crucial claims system, programmers find that one of their shortcuts throws computers for a loop. The upshot: more work on an ever-tighter schedule.

March, 1998: Three of the 10 core sections, or clusters, are fixed. The programmers expect that the remaining seven will be done by June, leaving more than a year for testing.


Return to Category: Compliance

Return to Main Categories

Return to Home Page