Menu
No time to fix Y2K. Now what?

No time to fix Y2K. Now what?

Comments

There's no doubt about it: organisations that have just begun to address the year 2000 problem are behind the eight ball. With less than 18 months to go until the turn of the century, they no longer have the benefit of the lengthy assessment and triage process that those who started even one year ago have had. Late starters have to face the fact that there's only enough time to remedy the most critical systems - and that some system failures are inevitable. That's why it's important that they deploy a contingency-management element in their Y2K programs.

In a nutshell, Y2K business contingency management identifies a comprehensive list of threats, performs impact and ranking analysis, and executes planning and mitigation activities.

With a sound, albeit expedited, assessment and ranking process, organisations have a way to address the most critical risks while preparing appropriate responses for less-damaging problems that are likely to occur.

Customers must understand that the mission of Y2K contingency management is managing the impacts of planned and unplanned failures, not attempting total prevention - it's too late for that. The best available course of action in many cases will be to plan for and allow the failure of some systems.

Despite their best efforts to identify and fix Y2K related problems, every organisation remains vulnerable to the disruption of its business processes, because a key partner's unexpected failure offers virtually the same threat as an internal failure.

Most organisations depend on information and data provided by others such as business partners, federal agencies, financial institutions, suppliers, and customers. The same issues addressed in an enterprise's Y2K plans must also be addressed by its key business partners.

Determining which partners are most important requires an assessment process that takes the business' supply into consideration, as well as the readiness level of each critical business partner.

Threats that must be considered, for internal and external operations, include IT software and hardware, manufacturing-facility technology, embedded-chip technology, physical-plant facilities, and infrastructure.

A plan for identifying threats to business continuity can be adapted to meet the needs of a specific organisation. Typically it will include these steps:

1. Risk identification, analysis, and assessment; 2. Response planning, design, and infrastructure deployment; 3. Proactive/reactive solution execution; 4. Failure monitoring;5. Contingency management.

The first essential set of activities is risk identification. With the high potential for Y2K litigation (both regulatory and conventional) in the event of a failure, you should engage the customer's legal resources to identify litigation risks.

Risk ranking means not only establishing ranking criteria but also identifying minimum levels of service required by the enterprise. Most organisations identify service levels aimed at optimal performance, not what is required to sustain business operations. Understanding this critical difference can allow management to direct resources to the right activities during the contingency-management process.

A source of risks that is often not noted urgently enough is shop floors within manufacturing organisations, specifically the embedded systems and the program-logic controllers in automated equipment. Customers need to identify problem equipment and begin joint remediation activities with vendors immediately.

It is imperative that these organisations develop a plan to deliver finished goods to customers, taking into consideration the high probability of failing equipment or falsely reporting logic units.

The next step, building a response framework, establishes what the desired response will be to a given risk. Some unavoidable risks require a project or task force to begin establishing a contingency plan immediately. (For example, key suppliers of a scarce commodity may have business disruptions that make it advisable to stockpile and warehouse product.) Other risks are less certain but the possible consequences so severe that some sort of telltale, trip wire, or early-warning mechanism will be required to give the organisation the opportunity to respond quickly. (For example, environmental control systems may degrade to failure points.) The response definition and analysis step leads to the next step: designing and deploying response mechanisms.

Response mechanisms establish how an organisation will react to planned and unplanned failures. Some mechanisms will be common to both types of failures, such as war rooms, help desks, and call lists.

For planned or highly likely failures, early-warning components such as call centres, systematic telltales, and third-party discontinuity-prediction capability can be designed and deployed.

Threat books

Senior management should work on designing threat books and escalation procedures in Y2K workshops. The threat book - a book of alternative actions that will be needed in the event of a breakdown - is designed before a failure occurs, when heads are cool.

Threat books are common to many contingency programs. What distinguishes a Y2K threat book is that it must be designed to address multiple threats and the possibility of concurrent failures.

Response mechanisms for unplanned failures are different in that they require the capability to develop failure solutions quickly. In essence, this mechanism establishes the structure, process, and form for handling failure events as they occur. Providing this solution capability will reduce the demand on technical resources during a crisis.

The time to begin creating a contingency-management plan is now. Y2K programs that are just beginning must be simplified and focused in their activities. Remediation must be focused toward those business partners and systems whose failure would have a catastrophic impact on the organisation.

Y2K projects offer some unique challenges - their scope and the consequences of failure are far beyond those encountered in other systems projects. They also require the acknowledgment that only a select portion of the enterprise's portfolio can be remedied in time. With this in mind, a good program will begin by assuming the failure of some systems. It will create response capabilities for these foreseen events, as well as the unforeseen.

Y2K survival guide

Time's running out, so you'll do best to stick to these basics when preparing for Y2K disastersIdentify the internal and third-party systems whose failures would be catastrophic to the enterprise. These are the systems and partners that must be addressed. The others can wait.

Run the remediation efforts and the contingency- planning process in parallel - don't wait for failures to occur.

Don't become myopic - technology may not be the only solution to a system failure. Process workarounds and creative manual solutions can offer as much or more value as IT-only fixes.

Manage the contingency and remediation activities so that failures are planned if possible.

Don't neglect the need for Y2K-savvy legal assistance in the risk-identification portion of the contingency process. Lack of Y2K legal strategy and advice may be more costly than an actual failure.

Focus as much as possible on building workarounds for business processes that might be disrupted by system failures. Technology-centric programs will have problems retiring systems when business processes are disrupted unexpectedly.

Trust but verify. Site visits may be the only way to obtain a clear picture of business partners' Y2K status. With the high potential for litigation associated with all Y2K activities, many organisations are not responding to third-party surveys with meaningful information. Identifying and visiting key business partners offers the most potential for insights into their readiness.

Build your own contingency plan

Here's a framework for building an expedited Y2K contingency- management plan. Although this outline suggests serial activity, identifying and ranking risks and developing responses should take place in parallel as much as possibleIdentify critical risksIdentify sources of risk, including business systems, infrastructure, and external entities.

Consider internal, non-IT-related risks.

Define and develop criticality levels (catastrophic, critical, and low).

Identify at-risk business processes.

Assess business impact.

Develop databases to classify risk.

Engage legal support.

Validate business-application risk levels.

Rank business contingency risks

Build a business-contingency database.

Define minimum service levels.

Rank, review, and adjust risks.

Develop a response framework.

Review sources of risk.

Develop response scenario categories.

Define early-warning capability needs.

Design response programs.

Develop a communication plan.

Develop a business-contingency rollout plan Define workaround development processes.

Develop a business contingency capability rollout plan.

Communicate the business contingency plan.

Build response mechanisms

Build early-warning capability, by ranked scenario.

Develop workaround processes for planned risks.

Determine response mediums to build for unplanned failures: Establish a help desk, set triage procedures, develop a threat book and escalation procedures, create a war room, and deploy SWAT teams (both technical and process/workaround).

Establish threat response staff.

Create threat-response procedures.

Implement solutions to known critical risks Execute workaround processes for planned failuresDeploy response mechanisms for unplanned failuresAfter 1/1/2000, the future is unclear for Y2K workersWhen the clock strikes midnight on December 31, 1999, what will happen to the jobs of the IT professionals who have been working toward that date? Observers of the IT job market disagree about whether year 2000 work will be completed promptly in 2000 or will drag on for a few more years.

"There's a tremendous amount of year 2000 work ahead in the year 2000. From my perspective, we'll be working on this until 2003," says Kevin Ashworth, a US-based Y2K analyst.

Ashworth's reasoning: corporations will be busy working on mission-critical applications in 1998 and 1999. But another 70 to 80 per cent of applications aren't mission-critical, and they have barely been touched so far. Such non-critical applications, which are nonetheless important because they make a corporation more efficient, include systems that monitor division or departmental performance.

"In the year 2000 there will be a transition of resources from mission-critical applications to those deemed less important to the business," Ashworth says.

But even those predicting an end to Y2K work soon after January 2000 don't believe that competent Y2K workers will be unemployed at a time when IT people are in unprecedented demand.

Because Y2K work has caused most corporations to defer new IT projects, the resumption of work on that backlog of applications is likely to provide more than enough opportunity for Y2K workers willing to learn new skills. by Steve AlexanderNo time to fix Y2K. Now what?

There's no doubt about it: organisations that have just begun to address the year 2000 problem are behind the eight ball. With less than 18 months to go until the turn of the century, they no longer have the benefit of the lengthy assessment and triage process that those who started even one year ago have had. Late starters have to face the fact that there's only enough time to remedy the most critical systems - and that some system failures are inevitable. That's why it's important that they deploy a contingency-management element in their Y2K programs. by David LandIn a nutshell, Y2K business contingency management identifies a comprehensive list of threats, performs impact and ranking analysis, and executes planning and mitigation activities.

With a sound, albeit expedited, assessment and ranking process, organisations have a way to address the most critical risks while preparing appropriate responses for less-damaging problems that are likely to occur.

Customers must understand that the mission of Y2K contingency management is managing the impacts of planned and unplanned failures, not attempting total prevention - it's too late for that. The best available course of action in many cases will be to plan for and allow the failure of some systems.

Despite their best efforts to identify and fix Y2K related problems, every organisation remains vulnerable to the disruption of its business processes, because a key partner's unexpected failure offers virtually the same threat as an internal failure.

Most organisations depend on information and data provided by others such as business partners, federal agencies, financial institutions, suppliers, and customers. The same issues addressed in an enterprise's Y2K plans must also be addressed by its key business partners.

Determining which partners are most important requires an assessment process that takes the business' supply into consideration, as well as the readiness level of each critical business partner.

Threats that must be considered, for internal and external operations, include IT software and hardware, manufacturing-facility technology, embedded-chip technology, physical-plant facilities, and infrastructure.

A plan for identifying threats to business continuity can be adapted to meet the needs of a specific organisation. Typically it will include these steps:

1. Risk identification, analysis, and assessment; 2. Response planning, design, and infrastructure deployment; 3. Proactive/reactive solution execution; 4. Failure monitoring;5. Contingency management.

The first essential set of activities is risk identification. With the high potential for Y2K litigation (both regulatory and conventional) in the event of a failure, you should engage the customer's legal resources to identify litigation risks.

Risk ranking means not only establishing ranking criteria but also identifying minimum levels of service required by the enterprise. Most organisations identify service levels aimed at optimal performance, not what is required to sustain business operations. Understanding this critical difference can allow management to direct resources to the right activities during the contingency-management process.

A source of risks that is often not noted urgently enough is shop floors within manufacturing organisations, specifically the embedded systems and the program-logic controllers in automated equipment. Customers need to identify problem equipment and begin joint remediation activities with vendors immediately.

It is imperative that these organisations develop a plan to deliver finished goods to customers, taking into consideration the high probability of failing equipment or falsely reporting logic units.

The next step, building a response framework, establishes what the desired response will be to a given risk. Some unavoidable risks require a project or task force to begin establishing a contingency plan immediately. (For example, key suppliers of a scarce commodity may have business disruptions that make it advisable to stockpile and warehouse product.) Other risks are less certain but the possible consequences so severe that some sort of telltale, trip wire, or early-warning mechanism will be required to give the organisation the opportunity to respond quickly. (For example, environmental control systems may degrade to failure points.) The response definition and analysis step leads to the next step: designing and deploying response mechanisms.

Response mechanisms establish how an organisation will react to planned and unplanned failures. Some mechanisms will be common to both types of failures, such as war rooms, help desks, and call lists.

For planned or highly likely failures, early-warning components such as call centres, systematic telltales, and third-party discontinuity-prediction capability can be designed and deployed.

Threat books

Senior management should work on designing threat books and escalation procedures in Y2K workshops. The threat book - a book of alternative actions that will be needed in the event of a breakdown - is designed before a failure occurs, when heads are cool.

Threat books are common to many contingency programs. What distinguishes a Y2K threat book is that it must be designed to address multiple threats and the possibility of concurrent failures.

Response mechanisms for unplanned failures are different in that they require the capability to develop failure solutions quickly. In essence, this mechanism establishes the structure, process, and form for handling failure events as they occur. Providing this solution capability will reduce the demand on technical resources during a crisis.

The time to begin creating a contingency-management plan is now. Y2K programs that are just beginning must be simplified and focused in their activities. Remediation must be focused toward those business partners and systems whose failure would have a catastrophic impact on the organisation.

Y2K projects offer some unique challenges - their scope and the consequences of failure are far beyond those encountered in other systems projects. They also require the acknowledgment that only a select portion of the enterprise's portfolio can be remedied in time. With this in mind, a good program will begin by assuming the failure of some systems. It will create response capabilities for these foreseen events, as well as the unforeseen.

Y2K survival guide

Time's running out, so you'll do best to stick to these basics when preparing for Y2K disastersIdentify the internal and third-party systems whose failures would be catastrophic to the enterprise. These are the systems and partners that must be addressed. The others can wait.

Run the remediation efforts and the contingency- planning process in parallel - don't wait for failures to occur.

Don't become myopic - technology may not be the only solution to a system failure. Process workarounds and creative manual solutions can offer as much or more value as IT-only fixes.

Manage the contingency and remediation activities so that failures are planned if possible.

Don't neglect the need for Y2K-savvy legal assistance in the risk-identification portion of the contingency process. Lack of Y2K legal strategy and advice may be more costly than an actual failure.

Focus as much as possible on building workarounds for business processes that might be disrupted by system failures. Technology-centric programs will have problems retiring systems when business processes are disrupted unexpectedly.

Trust but verify. Site visits may be the only way to obtain a clear picture of business partners' Y2K status. With the high potential for litigation associated with all Y2K activities, many organisations are not responding to third-party surveys with meaningful information. Identifying and visiting key business partners offers the most potential for insights into their readiness.

Build your own contingency plan

Here's a framework for building an expedited Y2K contingency- management plan. Although this outline suggests serial activity, identifying and ranking risks and developing responses should take place in parallel as much as possibleIdentify critical risksIdentify sources of risk, including business systems, infrastructure, and external entities.

Consider internal, non-IT-related risks.

Define and develop criticality levels (catastrophic, critical, and low).

Identify at-risk business processes.

Assess business impact.

Develop databases to classify risk.

Engage legal support.

Validate business-application risk levels.

Rank business contingency risks

Build a business-contingency database.

Define minimum service levels.

Rank, review, and adjust risks.

Develop a response framework.

Review sources of risk.

Develop response scenario categories.

Define early-warning capability needs.

Design response programs.

Develop a communication plan.

Develop a business-contingency rollout plan Define workaround development processes.

Develop a business contingency capability rollout plan.

Communicate the business contingency plan.

Build response mechanisms

Build early-warning capability, by ranked scenario.

Develop workaround processes for planned risks.

Determine response mediums to build for unplanned failures: Establish a help desk, set triage procedures, develop a threat book and escalation procedures, create a war room, and deploy SWAT teams (both technical and process/workaround).

Establish threat response staff.

Create threat-response procedures.

Implement solutions to known critical risks Execute workaround processes for planned failuresDeploy response mechanisms for unplanned failuresAfter 1/1/2000, the future is unclear for Y2K workersWhen the clock strikes midnight on December 31, 1999, what will happen to the jobs of the IT professionals who have been working toward that date? Observers of the IT job market disagree about whether year 2000 work will be completed promptly in 2000 or will drag on for a few more years.

"There's a tremendous amount of year 2000 work ahead in the year 2000. From my perspective, we'll be working on this until 2003," says Kevin Ashworth, a US-based Y2K analyst.

Ashworth's reasoning: corporations will be busy working on mission-critical applications in 1998 and 1999. But another 70 to 80 per cent of applications aren't mission-critical, and they have barely been touched so far. Such non-critical applications, which are nonetheless important because they make a corporation more efficient, include systems that monitor division or departmental performance.

"In the year 2000 there will be a transition of resources from mission-critical applications to those deemed less important to the business," Ashworth says.

But even those predicting an end to Y2K work soon after January 2000 don't believe that competent Y2K workers will be unemployed at a time when IT people are in unprecedented demand.

Because Y2K work has caused most corporations to defer new IT projects, the resumption of work on that backlog of applications is likely to provide more than enough opportunity for Y2K workers willing to learn new skills. by Steve Alexander


Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments