Susan Thomas, director of the Worldwide TEAM2000 Program at Unisys, has more than 17 years experience in the global IT industry. Thomas has successfully implemented midsize and large systems integration projects as well as applications development efforts in multiplatform environments. As director of the Unisys TEAM2000 Program, Thomas leads Unisys' efforts in preparing clients and their mission-critical computer application needs for the century date change. She spoke to IDG's Paul Nesdore about the problems companies face in implementing Y2K solutions with only 15 months to goIDG: When is it officially too late to start on the year 2000 problem? How much trouble will large companies encounter if they are just beginning to address Y2K compliance issues now?
Thomas: It's not too late to begin taking measures to ensure operational continuity. However, the approach for a company starting to fix Y2K today is different from the approach that was used by a company that began to address the issue at this time last year.
Anyone who is just starting to tackle the Y2K problem today should focus on ensuring operational continuity. I would recommend creating a plan founded on managing overall business risk. The plan should be designed so that every hour and every dollar spent to mitigate the impact of year 2000 on the business should yield a maximum decrease in risk to operational continuity.
Is the cost to fix the Y2K problem scaled directly (linearly) to the total number of lines of code involved? In other words, do smaller companies have more time to spring into action?
At Unisys, we've found that the number of lines of code will not always determine total cost. Rather we find that there is a three-dimensional aspect to the challenges presented by the Y2K date change issue. To determine cost, organisations must consider not only their IT systems but also embedded systems and the supply chain.
Also, just because a company is small doesn't mean that it has more time to spring into action. Rather it is the size and sophistication of the system or application that determine how long it takes to become Y2K ready. For example, if a small company has a highly automated manufacturing operation, it faces a more complex issue than it would if it were operating a fairly simple or largely manual operation.
I would add that we are very concerned about the number of small and midsize organisations that believe smaller size means they can postpone addressing the Y2K challenge. Size isn't the issue. System sophistication, the number of embedded systems, and the supply chain determine how complicated a task an organisation will face to comply with Y2K issues.
How should a company handle a December 1999 merger or acquisition with a company that has not done its Y2K homework?
Any company considering a merger or acquisition - even today - should conduct an extensive Y2K audit as part of its due diligence phase.
How serious, or difficult to implement, is the desktop Y2K problem given that most companies have hundreds of "unauthorised" or non-IS department supported software programs loaded on employees' PCs?
Desktop software is just as subject to Y2K date change issues as software running on a midrange or mainframe platform. If there is an advantage in the desktop environment, it is that most application portfolios are made up of off-the-shelf software packages. Therefore companies can presume that the vendors of their software packages will supply them with Y2K-ready versions.
I don't want to minimise the desktop issue. I believe that the greatest challenge in this area is the sheer logistics of locating applications, taking inventory of thousands of them, and managing the distributed networks on which those applications run.
Are there ancillary benefits companies can derive from completing the Y2K correction methodology?
Once a company has gone through Y2K correction methodology, there are a number of collateral benefits, including: establishing control and management of information assets throughout the organisation; recapturing information on how and why software systems exist; implementing a discipline of configuration management and quality processes; and establishing reusable test assets.
What are the consequences of waiting until late in the game to fix the Y2K problem?
The worst consequence is that organisations could experience operational disruption. We're also finding that with the growing awareness of the Y2K challenge, many small and midsize companies are at increasing risk of losing clients, because their clients do not have confidence in their abilities to address these issues successfully. Those clients will find alternative suppliers who are well along the path of implementing a Y2K solution.
Has lack of good software configuration management harmed the Y2K effort in many companies?
Year 2000 has provided the opportunity to reinstitute a rigorous configuration management system - if one is not already in place.
How critical is the "embedded systems" problem?
Embedded systems represent a very serious issue that poses a much greater threat to business disruption than that caused by the date change problem in IT systems. I say this because the industry knows very little about the implications of embedded systems, and the task of finding hidden microprocessors is much like a technology hunt for needles in a haystack.
How can companies tackle the "fix versus replace" issue?
There is no single answer to this question. Every company has to look at each of its applications and then make individual decisions for each one of them. And each component must be evaluated on its individual cost/benefit merits.
Does coming in late to Y2K compliance dictate a triage approach to the fix?
Absolutely. The first step any organisation should do is conduct a business risk analysis. Based on that analysis, every aspect of the business is given a priority. Organisations must tackle the work that will offer the most protection for their business.