Foretelling your plant's Y2K future: Who they gonna call? Maintenance, of course
The end of the first millennium found many Europeans predicting the end of the world. Surely a thousand years was enough. The Second Coming would coincide with the advance of the calendar into 1000 A.D.
The end of the first millennium found many Europeans predicting the end of the world. Surely a thousand years was enough. The Second Coming would coincide with the advance of the calendar into 1000 A.D. Well, January 1, 1000, came and went and no world-ending cataclysm occurred.
Now, roll the calendar forward another thousand years. Pick up a newspaper, turn on the television, go to a bookstore, or surf the web, and chances are good that you will encounter a set of dire prophecies -- this time about the Year 2000 (Y2K) computer crisis. These prophecies may not predict the end of the world, but sometimes they come pretty close to it.
For those readers who may have managed to miss the barrage of stories, the Y2K crisis is the result of the inability of certain computer systems to handle dates beyond December 31, 1999. It encompasses a variety of problems that affect how computer systems store, manipulate, and display dates pertaining to the approaching millennium.
These problems manifest themselves in a variety of ways, depending on the software and coding techniques used to develop the system. They can cause systems to crash, produce erroneous results, or simply display dates incorrectly. The problems are not limited to business systems. Any device with an embedded microprocessor that manipulates dates, such as a security system or a fax machine, also may be susceptible to Y2K glitches. Even the BIOS software that maintains your PC's internal calendar may fail the Y2K test.
According to some prognosticators, Y2K problems will cause computer systems to fail at a dramatic rate, driving many companies out of business. And, because most modern equipment and vehicles depend on microprocessors, they too will fail at an alarming rate. Those that don't fail will be useless because there won't be any power or communication services available to operate them. Even financial and governmental institutions are destined to collapse because Y2K problems will cause their information systems to crash.
With less than a year to go, it is time for me to put on my seer's hat and make my own predictions about how the Y2K computer bug will affect maintenance operations. Like all great predictors of the future, I have tried to keep my prophecies general and vague. They are based as much on my intuition as experience. Therefore, they should be as good (or as flawed) as any other predictions.
1 The world will not come to an end. Come January 3, 2000 (the first Monday of the new century), most maintenance departments will be grappling with the same problems that plague them today. The impact of Y2K issues on systems is too well known by IT departments, software vendors, and system suppliers to ignore. Progressive organizations have been tackling these issues for years. Those that weren't so forward-thinking are now tackling Y2K issues in a crisis mode. The vast majority of major systems (such as accounting, order entry, purchasing, and manufacturing packages) will not crash and burn come January 1, 2000.
This statement does not mean there will be no Y2K problems. We all depend upon a plethora of intelligent devices, private databases, and secondary systems to run our businesses. Some will incur unforeseen problems that were not caught by even the most Y2K-diligent organization before the end of the year. Although most big-ticket systems won't crash, a significant number will still have Y2K problems. But most of these problems will occur in noncritical functions and modules. Work-around procedures will be established for critical problems that cannot be fixed in time.
Some spectacular failures will occur and they will not only cripple the user-company, but will also dramatically affect other organizations up and down the supply chain. However, the vast majority of key business systems, including CMMS packages, will handle the new millennium without crashing or producing nonsensical results.
2 Y2K problems will affect maintenance operations more than other departments. This prediction is so obvious to me. I have worked too many years in the maintenance field not to know the typical position of a maintenance department in a company's information-system pecking order. It is at the bottom. If there are any open Y2K issues on a company's fix list come the new year, maintenance will have more than its fair share.
Because just about every modern device has a microprocessor chip in it, maintenance will be on the frontline if there are Y2K problems with these embedded systems. If an environmental system, intelligent tool, or monitoring device fails, who will get the call? Even if the vendor or an outside contractor services these devices, maintenance must manage the effort.
3 Many hurdles must be cleared before your operation is out of danger. When it comes to Y2K problems, most people focus on January 1 as the only date that matters. However, the event horizons that drive our enterprises are not restricted to one day. Some maintenance departments have already cleared their first CMMS Y2K hurdle when they completed their annual PM tasks last January. Hopefully, the next due dates for these tasks were properly cycled forward to January 2000 instead of becoming 99-yr overdue.
Other hurdles exist. The start of a fiscal year or budgetary planning cycle may require a system to process Y2K dates before January 1, 2000, arrives. An annual processing job, or archiving routine or leap year calculations (2000 is a leap year so there is a February 29th), may generate a Y2K problem after January 1, 2000. Just because one hurdle has been cleared doesn't mean a system is totally Y2K compliant.
4 Maintenance departments that are the most prepared will suffer the least. This prediction may sound simplistic, but if it is so obvious, why do I feel that so many maintenance departments are going to be caught off guard by Y2K problems? Given prediction #2, the ultimate Y2K fate of a maintenance department falls squarely on its own shoulders. Operations that take an active, aggressive approach to Y2K problems will be the winners in the new millennium.
Hopefully, your maintenance operation already has or is in the process of preparing an inventory of all systems and devices that are susceptible to Y2K problems. Once they are identified, contact vendors about Y2K compliance and assess the criticality of any outstanding problems. Similarly, you have already developed or will develop action plans to fix, bypass, or replace Y2K-afflicted systems.
If you really want to be prepared, document the steps taken to resolve Y2K problems. If the year 2000 brings with it a worst-case scenario, those with a solid documentation trail will suffer the least.
5 The effects of the Y2K crisis will be felt long after January 1, 2000. I'm not talking about the obvious Y2K cleanup work that will continue well beyond January 1, 2000. I'm talking about the impact that the Y2K crisis will continue to have on our software and system vendors.
The Y2K crisis has already had a profound impact upon the software industry, draining resources from new product development. Many small firms with products that required costly Y2K fixes have folded. Others that succeeded in fixing their products may find themselves in a weakened competitive position.
What does this mean for the suppliers of maintenance management software? Perhaps the large firms will continue to grow through mergers as smaller firms drop out of the picture. Perhaps enterprise-resource-planning (ERP) vendors will give top-tier CMMS vendors a run for their money with improved plant maintenance modules. Will this mean fewer choices for end-users? Or stronger vendors capable of consistently bringing new innovations to the marketplace? I don't know. My crystal ball is getting cloudy.
One wild card that will certainly play out in the future is the litigation factor. Despite all the caveats that appear in any software license agreement, I'm not sure that vendors will escape liability for the Y2K problems generated by their software. I'm not sure they are protected even if they provide free upgrades to fix the problem.
Y2K is not an issue that has materialized out of thin air. Software developers have known about it for years. In 1983, when I was working as a programmer on a CMMS development project, I had a discussion with some coworkers about making our product Y2K compliant. We quickly determined it wasn't worth the effort because newer products and upgraded versions would surely replace our system by the turn of the century.
Whether it was because of the required programming resources, limited memory and disk storage, or available programming tools, a lot of other developers made the same choice. We all assumed the code we were working on wouldn't survive into the new century. In the case of my CMMS package, this turned out to be true. But there are plenty of systems in use today with serious Y2K problems that are operating well beyond their original, anticipated life expectancy.
Were these decisions not to accommodate year 2000 dates sound business judgments or negligence? I firmly believe they were the former. However, it will inevitably be argued in court that some firms knowingly sold defective products. What will the outcome be? My crystal ball is getting cloudy again. But any substantial liability judgments will surely affect which vendors survive and flourish.
I hope my predictions have taken an appropriate balance between panic and complacency. I don't think our technological world will crash and burn on January 1, 2000. But I do think that Y2K problems will cause difficulties for many maintenance departments. I hope your organization is doing everything practical to minimize them.
If it isn't, keep one other prediction in mind. It isn't too early to plan a nice, long vacation to celebrate the advent of the new century. Stay away from those glitzy, high-tech resort destinations. They'll be overcrowded. Pick a nice, self-sufficient tropical paradise. Plan to arrive before December 31st and to stay well into January. Bring plenty of cash, but don't bring your laptop or cellular phone. They won't work anyway.
Tom Singer is a business systems analyst experienced in identifying and developing solutions that address client operational needs. He specializes in the design, development, and implementation of warehousing, inventory control, automatic identification, and plant and facilities maintenance management solutions. He is the author of a number of articles on maintenance management technologies and techniques. Tom's degree is from Indiana University.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.