Communications of the ACM

Communications of the ACM

Exploiting the Benefits of Y2K Preparation

By Stewart Robertson, Philip Powell
Communications of the ACM, September 1999, Vol. 42 No. 9, Pages 42-48
10.1145/315762.315770
Comments

Despite the enormous amount of press coverage Y2K readiness has received, the thrust of that coverage has been that it is just a technology cost that has to be borne. Yet business opportunities and business benefits may also derive from the Y2K problem, if approached properly.

For some organizations, the problem may even represent a competitive opportunity, along with a number of internal and external benefits, including being able to reuse the materials developed to neutralize the problem, forced rationalization of system components, competitive advantage in a number of business markets, improved business operations, increased systems flexibility, and enhanced delivery of new technology.

We therefore propose a management agenda to help reap these potential benefits and draw parallels between Y2K preparation and ongoing preparation for European Monetary Union (EMU). EMU is likely to have consequences similar to those from Y2K preparation for companies doing business in Europe or with European companies, though it takes effect in different years in different countries.

The Y2K problem may affect software packages, operating systems, hardware, firmware, incremental backup and forward recovery, data-set retention dates, and password expiration. The extent of computerization in organizations worldwide is so pervasive that most businesses suffering significant computer failures may not recover. And most insurance policies do not cover Y2K-related losses, as the bug is deemed by insurance companies a foreseeable event.

---

Only senior management is likely to have the vision and ability to reap wider benefits from the Y2K bug.

---

U.K. government statistics for the past few years suggest that many organizations, especially small businesses, are unprepared for dealing with the date change, and none anticipate deriving any business benefits from the Y2K problem. An audit by NetCensus, a consulting firm, found that 80% of one large organization's PCs would be unable to cope with the Y2K date change. The management of Sainbury's, a major supermarket chain in the U.K., characterized the Y2K problem not as a risk but as a "very real danger" [3]. The company's concerns go well beyond its relationships with its regular suppliers and customers to include the possibility that public facilities, such as traffic signals, may stop functioning, preventing shoppers reaching its stores.

Practically all large organizations are addressing the Y2K problem in some way, despite the lack of preparation in most small ones; the public sector generally lags behind the private sector. Most organizations view the Y2K bug simply as a problem to be fixed—a necessary cost with no gain. But organizations that recognize and plan for Y2K benefits will reap much more efficient and effective business operations than those that don't—in the form of a large return for a relatively small incremental investment.

Tackling the Y2K problem is a peculiar endeavor, though preparing for EMU involves some of the same problems in adapting corporate information systems. For instance, at Lloyds TSB, a major U.K. retail bank, EMU preparation involves 600 staff and 5,000 identified potential business effects [1]. Such effects go well beyond a company's IS department to all stakeholders, including users and customers, across all business areas. Revealing the hidden nature of many of their information systems may reveal the extent to which organizations are dependent on these systems. Similarly, the same process can highlight the interdependencies within an organization.

Many of the problems and the solutions, discussed later in the article, are commercially sensitive, though the dependencies between organizations supported by their information systems raise interesting questions about cooperation and competition. The Y2K problem has immovable dates, though there is a range of event horizon dates, mostly before, but some after, January 1, 2000 (such as first month end, first leap-year processing, and first year end), and completion cannot slip. Moreover, the human resources needed to tackle the problem are in demand throughout the global economy and can just leave if not treated well. Indeed, the key resources seem to represent a minority of developers and architects, usually long-time IS employees with specific knowledge of legacy systems.

Meanwhile, senior management's view of the Y2K bug differs from IS management's view. IS generally views it only as a problem inhibiting use of scarce resources on other, more interesting projects, though anecdotal evidence suggests Y2K preparations are being used as an argument for increasing technology budgets, particularly for strategic systems [4]. Senior management may view it as a problem or an opportunity, in light of its increasing concern over value from corporate technology investments in general and may consider Y2K preparation solely as a cost. Moreover, senior management is unlikely to want to be seen as rewarding an IS function it might consider the source of the Y2K problem in the first place. Then again, only senior management is likely to have the vision and ability to reap wider benefits from the Y2K bug.

Back to Top

Comprehensive Y2K Project Preparation

Most comprehensive Y2K preparation programs focus on information systems, business issues (especially supply chains), processes, and embedded chips. The cornerstone is a comprehensive inventory of all technology components. Solutions may be a mixture of code fixes and product replacement, upgrades, and decomissioning. The overall solution needs to be integrated with the corporate plan for technology refreshment and upgrade over the appropriate period. Typically, critical business areas get a complete integration test in a simulated Y2K hardware and systems software environment. The preparation schedule is a key competitive issue; no company really wanted to be first (as customers might go elsewhere), but none could afford to wait too long.

We've all heard how the Y2K bug affects PC hardware and mainframe application code, but every part of the corporate computer and telecommunications infrastructure, code, products, and processes needs to move through the preparation cycle. A company's IS department has to check processes, as well as application functions. For example, it has to know whether a backup made in 1999 will restore correctly after Jan. 1, 2000. Similarly, disaster-recovery facilities also needs to be Y2K ready, and special thought needs to be given to the retention dates of archived data sets. Application redemption is the biggest and longest-duration item for most large organizations, and event horizons may occur well before the actual date change.

Given the limited time—only three months to go—and the lack of attention given the problem by some organizations, it is not surprising that many organizations are applying triage, or the fixing of only the most critical systems, applying full integration testing to only those systems. The triage approach requires the setting of clear business priorities for the systems and may, in senior management's mindset at least, preclude doing more. However, Y2K readiness also represents potential benefits.

Reusable materials. Many of the materials developed in a typical Y2K bug-neutralization program (such as inventories, test plans, and test cases) are, if maintained properly, reusable in future projects and in the ongoing management of corporate technology facilities—hence they have the potential to deliver continuing benefits. The key to this value is that the materials are comprehensive, validated, and maintained. Materials available under less dramatic circumstances than the panic over Y2K risk usually satisfy none of these criteria. The benefits of reusable materials include improved control, a defined base, and better processes for future developments.

Underlying Y2K readiness is a comprehensive inventory of all IT components. Most organizations maintain such inventories, but they are worthless without robust processes for maintaining their currency. For example, a major U.K. insurer that physically audited its PC hardware and software found that over 20% of its inventory records needed correcting.

Aside from making the current inventory as efficient and productive as possible, Y2K readiness engenders development of disciplined asset registration and stewardship. Most valuable are "intelligent" inventories, such as databases, that map all components, including application modules, infrastructure components, data, and interfaces required to support individual business applications. Inventories of technology assets have to be developed, including hardware and software products, applications, suppliers, and user-developed systems and applications. A key benefit here is that some user-developed systems may be critical but not identified as such or, indeed, not known to the central IS department. For example, a major U.K. supermarket chain discovered it had some 16,000 end-user applications. This exposure merits further investigation, even if there were no Y2K risk. In addition, such applications are likely to involve miscellaneous "homegrown" exits, utilities, modifications, and job control language. The major U.K. insurer mentioned earlier, when updating its inventory, defined a standard set of desktop builds that would be needed to make all its desktops Y2K ready. Greatly reducing the variety of desktop hardware and software in the field will significantly reduce future support and training costs.

The documentation of systems should be carried out in parallel with the updating of inventory. Documenting systems goes beyond identifying components to highlight interdependencies among business systems, and is especially valuable for interorganizational systems. The process of documentation also enables assessment of the state of knowledge in all parts of the business, providing a blueprint of best practices for possible use later in the reengineering of both business and technology processes.

The development of testing processes and procedures is valuable; those involved in Y2K readiness can be leveraged into adjacent business areas. This leverage may involve the creation of testing templates and materials, test cases, and data. As with business modeling, the development of such tools may be as valuable as their use. Such procedures should involve audits to establish and check inventories, with exceptions flagged for investigation. Indeed, much of this material may be of almost immediate value, as an organization addresses its EMU needs over the next few years. In effect, it represents a complete regression test suite for the whole business.

In order to simulate realistic Y2K conditions, many organizations have established mainframe systems integration test environments—dedicated logical partitions with their own copy of the operating system and direct access storage device and the option of changing the system clock. Many organizations plan to retain these facilities even after the date change to provide a more integrated level of testing for future software platform releases. These testing procedures, along with robust release processes for handling high volumes of concurrent systems changes, will make future systems changes easier to simulate and implement.

Forced rationalization. In many cases, the Y2K problem is being used as a means of driving wholesale hardware and software upgrades. In one U.K. local government authority, the easiest solution has been to replace all PC hardware. Some of this forced rationalization is beneficial, although the danger is that IS management may, or may be perceived to be, forcing senior management into sweeping, but unnecessary, hardware and software replacements. Note the need for a holistic view; application standardization, bulk buying, and database upgrades can lower costs, and piggybacking on a technology refreshment is rational. Standardization can lower the costs of maintenance, support, and training and probably boost productivity and system availability. IS management should at least spell out a business case with piecemeal fixing as an alternative—allowing long-term cost comparisons.

---

Y2K status is increasingly taken into account in assessing business loans and even acquisition targets.

---

The benefits of forced rationalization include reduced operating costs and improved speed of response. Applications and other technology are brought to a modernized, rationalized state that may be considerably cheaper to maintain and operate than the systems they replace. Programming languages may be upgraded to common, supported levels. Application redundancy can be identified and removed, especially in the management information and reporting areas. And system software can be refreshed, allowing redundant licenses to be rationalized or discontinued.

There are also benefits in reduced diversity, especially among PCs bought by end-user departments. Reducing diversity is an opportunity to map the end-user platforms to a limited number of standard operating systems and applications. Coming today, at a key point in the evolution of technology, characterized by Web-enabled applications and network computers, the Y2K problem may be a catalyst for a strategic technology move. Current application software bugs may also be fixed as a by-product of the process of Y2K readiness and general upgrading. The Y2K problem focuses the microscope on all corporate information, applications, and processes.

Just as some IS managers view Y2K as an opportunity to encourage senior management into upgrades, some technology suppliers do too. However, many software suppliers are giving customers considerable help, including free evaluation tools, upgrades, and intellectual capital. For these suppliers, the Y2K problem is a competitive opportunity to demonstrate customer focus while maximizing revenue; in any case, those pursuing the former course—trying to force upgrades—may find far fewer eager customers after January 1, 2000.

For technology customers, the most sensible approach is to synchronize Y2K technology replacement with other refreshment programs—perhaps accelerating some in order to meet the various upcoming date-change deadlines. This replacement strategy may also have hidden benefits. For example, the advent of network computers, or medialess PCs, represents an opportunity to replace eclectic desktop populations with low-cost standard (Web-enabled) technology—that also happens to be Y2K compliant.

Competitive position. Aside from technical rationalization, Y2K readiness may be used as a competitive weapon. In time (probably shortly after January 1, 2000), readiness will be a competitive necessity, though it could be argued that January 2000 is too late to discover that your electronic-data-interchange trading partner is not ready. And many event horizons occur earlier than January 1, 2000.

In the meantime, there are various aspects to the potential competitive advantage. First is being Y2K compliant to enable the business to focus on other competitive goals. Second, readiness or early readiness may be vital to others in the value chain and may be a prerequisite for obtaining custom business. Third, efficient Y2K readiness may help push costs lower than competitors who handle the problem poorly. And finally, there is evidence that the extent of readiness is a factor considered in the overall assessment of an organization's worth, even its viability. Y2K status is increasingly taken into account in assessing business loans and even acquisition targets. Organizations ready early or seen as having transferable skills or practices become attractive candidates. Conversely, in the run-up to Y2K readiness, organizations deemed unprepared are unattractive, though bargains may emerge post-2000 in picking up the pieces. Still, the primary benefit is improved position relative to competitors, including market share and customer and supplier partnerships. However, while Sainbury's management maintains it does not view Y2K as a competitive issue, a number of organizations, especially in finance, have publicized their Y2K-ready status, hoping to attract or retain customers.

There are few past examples of the competitive aspects of such a problem and therefore little guidance from history. The few lessons that do exist involve technologies or practices that are now ubiquitous, such as ATMs in banking and airline reservation systems. Competitive advantage in these areas, especially the former, was neither sustainable nor long-lived. Hence, competitive advantage from Y2K compliance and failure will be ephemeral for those that survive and nonexistent for those that fail. More likely, suppliers and customers will force preparation and compliance to be a competitive necessity. The Y2K readiness and compliance process also raises the cost base of any organization trying to comply, though organizations pursuing the benefits discussed here may achieve long-term cost reductions.

The cooperative nature of most business operations and interorganization communication means that Y2K readiness cannot happen in isolation. Readiness entails working closely with suppliers, customers, and industry bodies, yielding a better understanding of what is critical to the products and services customers are most willing to pay for.

An alternative view is that by highlighting how dependent organizations are on each other and how vulnerable they may be if their suppliers' or customers' systems fail, organizations may seek to remove themselves from the value chain or, at least, set up firewalls between themselves and their collaborators. An analogous situation in interorganizational systems is when organizations, trying to cope with the various transmission "standards" imposed by their customers and suppliers, introduce translation-layer software through which all input has to pass. Outside data never enters the internal systems directly.

Aside from direct advantage relative to competitors, other business issues, such as credit rating, external audit, and insurance coverage, also need to be proved Y2K ready. There are also the national and international competitiveness issues. Some governments that have proactively encouraged Y2K readiness may also reap international rewards. But Y2K will hit the developed world harder than the less computer-intensive regions.

The activities involved in Y2K readiness may also improve everyone's understanding of their organizations' critical business priorities, possibly as a result of the high cost of complete integration testing. The final result is the need to give priority to the systems they cannot afford to let fail. Organizations also have to give priority to their critical applications, in light of limited time for integration testing. Whereas new development projects are often justified on optimistic business cases (with evaluation often a ritual), survival helps management focus on what's most important to business performance and success. The focus is on key interfaces to business partners and on systems processing transactions.

Direct business opportunities resulting from Y2K in the computer industry include being able to sell special Y2K tools, deliver forced upgrades, provide consulting services, and contract out staff expertise. Others are available to non-high-tech organizations clever enough to take advantage. For example, one enterprise is cashing in by making a giant airplane parking lot in a desert location to store planes expected to be grounded when the world's airports reach capacity.

People skills, culture, organizational learning. In addition to competitive positioning and forced rationalization, Y2K preparation affects every individual employee. While certain individuals earn suddenly higher salaries, benefits for the organization include increased organizational capability, flexibility, and efficient project delivery. Moreover, contract rates have really exploded, for example, one U.K. financial institution, developing a major application suite in parallel with its Y2K fixes, has had to strengthen its configuration management.

Y2K is a major but inherently simple project that could represent a vehicle for staff learning. Such a companywide staff learning opportunity involves IS and non-IS staff becoming acquainted with the pervasiveness of information systems, encouraging project management skills and adherence to deadlines. Further, as the Y2K problem covers all parts of the organization—in and outside the IS department—crosses all internal functional boundaries, and impinges on external relationships, Y2K preparation can have an "integrative" effect. However, while skills can be derived from the project, they may end up only as triage skills. As demonstrated in the management action plan, such benefits are possible only if the process of Y2K readiness is viewed by senior management as something more than a problem and if the organization has a learning culture and allocates sufficient resources.

Y2K readiness forces organizations to adopt a "delivery culture." Organizations repeatedly design yet fail to implement blue-sky solutions. But Y2K preparedness forces a focus on pragmatic delivery by fixed dates. Indeed, it might be argued that, by precluding IS staff professionals getting involved in other projects, they begin to view things in a way not possible otherwise. Limited resources also force management to identify and exploit what's most important to achieving business performance and financial goals.

Readiness projects engender customer and commercial awareness. Applications and service delivery organizations are forced to improve their teamwork and coordination. And readiness may highlight critical exposures (involving applications, dependence on unsupported hardware and software, and key dependencies with customers and suppliers) that previously were not recognized.

Typically, a Y2K upgrade project needs a few key IS employees with in-depth systems knowledge, technical or project management skills, and a larger number to execute the prescribed changes. A smart organization deploys its own IS people in the specialized roles that inherently develop, growing skills, and expensive—but disposable—contractors on the repetitive element.

Action plan. IS management is hamstrung by the publicity and fallout from general Y2K concern and faces a credibility challenge, especially if it did not alert senior management to the looming issues and is now firefighting. IS management should therefore focus on maintaining (preferably intelligent) inventories. The entire organization has to focus on using its own IS employees and employing contractors on particular tasks. IS management has to think in terms of investment, rather than just paying a cost. Senior management can make a virtue out of the necessity of spending in the short term by proposing a longer-term, say, five-year, plan that includes recurring cost savings that offset current Y2K spending.

At the same time, senior management should appreciate and envision the opportunities, as well as the costs, in Y2K readiness. It needs to direct and facilitate an organizationwide program management structure and ensure that the related benefits feed into other programs. Another senior-management responsibility is quantifying the potential value of the benefits and setting this value against the amount that would be lost through a laissez-faire approach. These actions depend on executive commitment, outside the IS department, that must be incorporated into plans that, in turn, have to be monitored and controlled.

Management commitment implies the opposite of a knee-jerk reaction. Y2K readiness can be used to raise both IS and senior management profiles in the long term. They can begin by adding the state of Y2K readiness to regular board agendas and establishing a senior-level steering committee. Both IS and senior management need to recognize that managing Y2K readiness is a business problem, not just a technology problem, putting in charge an overall program manager with a business background. Senior management cannot afford to alienate scarce IS managers and staff—even if they wish to.

Failure to prepare for Y2K adequately poses potentially catastrophic business risks, coming at a time when there is a shortage of skilled IS staff to engineer the solution. Senior management can develop incentive programs for IS managers to give back learning and ongoing improvements, as well as just solve the problem. It also has to initiate productive relationships with suppliers, clients, and competitors.

EMU. EMU has had the same effect on business management, calling attention to resource constraints, complexity across all business units, interdependencies with customers and suppliers, the need to maintain business as usual while changes are made, and the potential for differential benefits from the preparation process.

The director of technology at the Royal Bank of Scotland, a U.K. clearing bank, claims the cost of EMU readiness is three to four times that of Y2K readiness. Technologically, EMU and Y2K preparations involve similar efforts, but EMU will absorb twice as much user and business time [5]. As in Y2K readiness, EMU readiness needs to inventory all software, conduct modify and regression tests, and manage the readiness of vendors, suppliers, and customers. EMU is, however, more complex in terms of software function; Y2K readiness is more pervasive, affecting all software, hardware, procedures, and documentation.

Back to Top

Conclusion

The Y2K cloud could hold a silver lining if senior management and IS management both recognize the opportunities and act accordingly. Y2K readiness represents a competitive business opportunity for some organizations; potential internal and external benefits include reusable materials, forced rationalization, competitive advantage, increased organizational capability, flexibility, and enhanced project delivery. In order to realize these potential benefits, senior and IS management need to prepare a Y2K agenda to help lead their organizations to them. Y2K preparation also anticipates EMU preparation, which represents the next major companywide problem likely to arise.

Back to Top

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 1999 ACM, Inc.

---

No entries found