Analysis: Think your Y2K efforts are error-free? Think again!
So September 9, 1999 [090999 or 990909], the dreaded 999999 tests came and went. Was it a major event in your shop? If so, I'd like to hear about it.
Now the bad news---in an article entitled "More vendors reverse Y2K readiness status" that appeared in Computerworld online edition August 3, author Stacy Collett stated:
The number of software products reversing their Y2K-ready status is going up, not down, according to one Year 2000 compliance-tracking firm.
In July, vendors for half of the 125 software products evaluated made "negative" changes (58 percent) to their Y2K-ready status. That means the manufacturer has discontinued Y2K support or has released previously unknown Y2K issues.
That's much higher than the 33 percent average for this year and was unexpected because more businesses are nearing the final stages of Year 2000 remediation, said officials at Infoliant Corp., a Pittsburgh-based Y2K compliance-tracking firm.
A second trend is that Y2K vendors and services are now focusing on other areas, depleting available resources for the AS/400 world.
Labor Day has just passed and we're headed into the Final Quarter. Roughly 100 days remain to close your "legacy styles" and enter 2000 in a properly prepared manner. Grave concerns over this bad news, given the eye opening double-digit increase of 25 percent in products with late Year 2000 problems, is not one bit encouraging for that solution path.
Some questions you should consider: Did you thoroughly test, in all its stages, the software you have in use as Year 2000-compliant? Are you sure you did all you could do with those modifications or homegrown changes and remediations either by your staff or your package vendors? Are they truly free of Year 2000 bugs, kinks and idiosyncrasies?
Are you sure?
While we change our testing methods to match the complexities of Year 2000, it remains extremely difficult to test every conceivable combination of code paths and conditions. These variables remain infinite, leaving room for embedded errors to remain undetected. Where do we start to overcome this built-in handicap?
You absolutely must make Risk Assessments and establish objectives cooperatively within your organization---assessments that will allow for the rapid resumption of critical, if not all, business operations. During disasters, tremendous uncontrollable outbursts of trauma and emotions flow counter to logically productive decision-making. To be prepared for the unexpected, every Year 2000 project must have a contingency plan.
Contingency plans require that knowledge of critical business priorities and processes are fully defined. This portion of the Year 2000 project will be a joint venture with representative skills and awareness of process from several areas and management teams. There's no way to go this one alone, no matter how much you want to! IT infrastructures would very likely include the continued support through contingency procedures of sales, receivables and payroll.
Contingency plans predetermine individual responsibilities and actions of team of resources: No last minute pressurized decisions or complex matrix of alternate chain of command, simply a clear path for operation during crisis. This is more than planned triage.
We all know Year 2000 will happen on the calendar on January 1, 2000. What is unknown is the first and last processing dates on which this boundary will be processed or crossed, causing incorrect or terminal results.
Keeping with this theme, how does IT maintain clean management of data once it's remediated and validated as correct? There are tools available to forecast when that first transaction falling in 2000 will occur. On the other hand you can forestall 2000 by another 28 years with tools that invoke encapsulation techniques such as MS4 Year 2000 from Millennium Solutions.
Both these types of offerings are inexpensive and good solutions and offer viable risk reduction toward the passage of 2000. Services and tools are available to minimize your risk as time abruptly terminates!Business and General
All risk assessments must take a serious view and analysis of the probability of Year 2000 disasters on each segment and rate them accordingly: High, Medium, and Low. Next, rate the severity of the risk on an appropriate scale, followed by the anticipated duration of the problem.
Take a departmental approach to the problem and plan. In so doing, you'll get to observe the interdependencies that exist between them as you would between programs, applications, systems and companies within an enterprise. This can be taken further into your supplier and customer relationships and dependencies, establishing those that are most important, or single source relationships of high concern.
Moving through all the steps as carefully as possible is difficult. Using the tools and services at your disposal will help ensure the best possible outcome. Nothing in the Year 2000 project is old-hat. Use whatever resources you can afford to remediate, validate, verify, forecast, test and create solid contingency plans. Your efforts during Y2K might just determine what and where your next position is. You're writing your legacy and your future the way you wish to be remembered. Don't screw this one up: We're still trying to get over the bad Y2K rap in the public eye! GOOD LUCK!
Glenn Ericson is president and founder of Phoenix Consulting LLC, in East Elmhurst, N.Y. He specializes in Year 2000 and risk management issues.