About CPSR
Y2K Home
FAQ
Y2K Policy
Rumor Central
Speakers Bureau
Survival Guide
W.G. Members
Volunteer
Y2K Forum
Privacy Policy
Disclaimer
Further Reading
Webmaster
|
The CPSR Year 2000 Action Plan
The most critical part of
the Year 2000 problem is not any specific technical issue
or the code and data changes necessary in a particular
language. Rather, it is in the project plan of specifying
and managing all the details associated with such a
wide-reaching project. The purpose of this white paper is
to specify an organized method of determining the scope
of the problem and a systematic way of working on it.
In order to specify the
theme for this action plan, consider the acronym "I
ACT 2000". This acronym has the advantage of both
being representative of the various phases of the Year
2000 project as well as being indicative of the critical
success factors involved. The letters in the acronym
stand for Inventory, Assessment, Correction, and Testing.
These four phases are detailed below. The "I"
indicates that this project will only be successful if
people take individual ownership and accountability for
the project. There is too much to be done to simply
expect others to do all of it. The "ACT"
indicates that the project will only be successful if it
is geared to action. Spending a lot of time just studying
it or waiting for a better solution to come along wastes
precious time, and this project is not one where we can
afford to be late * the year 2000 cannot be delayed.
Finally, the "2000" indicates that we must be
prepared for the year 2000 when it arrives. Despite the
best plans and the best people, there are still likely to
be things which were not anticipated. We must also have
proper backup and recovery procedures for when any
difficulties arise.
Phase 1 - Inventory
The Year 2000 problem is
not limited to old COBOL programs written on IBM
mainframes. Because the shorthand method of referring to
years by using only the last two digits has been
pervasive, instances of it can be found in any area where
automation or electronic circuitry is involved. Some of
these may be obvious, others less so. In order to
categorize the issues, there is a list of possible areas
at the end of this paper. This list has been constructed
through observation of many comments on the subject in
various Internet discussion groups and news groups and
has been verified by cross checking it against lists
prepared by others such as the AIAG (Automotive Industry
Action Group), a coordinated effort of the major
automobile manufactures in the United States. Not all of
the areas listed will be pertinent to every situation,
and not every possible variation in each category is
listed. However, this is a good starting point for
deciding what areas to examine in any specific situation.
Phase 2 - Assessment
There are a number of
tasks in the assessment phase. If there is computer
software involved, then examination of the code for the
number of dates (density) and dependence on them should
be done. If there is computer hardware or other purchased
products involved, then letters to vendors establishing
their Year 2000 compliance is appropriate. For all items
in the inventory an assessment of how important that item
is to the continued operations of the enterprise is
appropriate. Items which are critical or have a high
degree of "risk" associated with them deserve
more attention than those which are less critical. The
following categories are indicative of the
"risk" involved: High Risk -- Safety / Health /
Environment / Regulatory reporting; Medium Risk -- Plant
shut-down / Production constraint / Asset control /
Customer relationships; Low Risk -- Inconvenience /
Efficiency loss / Billing / Internal reporting. However,
risk is cumulative, so a particular system may have high
risk because it impacts multiple low-medium risk areas.
(For a more complete robust definition and calculation of
risk, the Corporate Audit Department has developed a
model, contact them for details.) For critical systems,
one should consider testing it anyway to determine or
verify compliance, even if a vendor indicates that there
are no problems. Finally, if results indicate that there
may not be enough time to correct every last detail, then
one might consider "triage", setting priorities
as to which systems will get attention first so that
limited resources may be used where most needed.
Phase 3 - Correction
Like the assessment phase,
the correction phase is multi-faceted. One simple
solution is sometimes a simple version upgrade. Where
actual computer programs or code exist, a possible
solution is rehabilitate it, i.e. expand the dates or
change the logic to properly handle dates in multiple
centuries. Another solution is replacement of the system
with a purchased or other (compliant) package, however,
if a replacement strategy encounters delays, adequate
time and resources must be available to revert to a
rehabilitation strategy. Finally, one could consider
retiring a non-compliant system or piece of hardware.
Phase 4 - Testing
While some limited testing
may have been done in the assessment phase, all critical
systems as well as those which have been modified during
the correction phase must be properly tested. A
well-conceived test plan must address not only
verification that the changes made during the correction
phase have not introduced other problems (regression
testing), but that there will not be any problems when
the actual century change occurs (time-dimensional
testing). To this end, we have introduced a Year 2000
test plan for application packages. A similar type of
checklist would be needed for infrastructure changes,
process control changes, etc. The purpose of this testing
is to ensure that the problem has been addressed properly
and that we have not overlooked anything. While testing
cannot ensure that no problems exist, a well-conceived
test plan can help us ensure that we have taken proper
diligence in determining whether the system will work
correctly. The testing phase can take anywhere from
30-70% of the total time and resources in a Year 2000
project, so careful planning of this phase is necessary.
In all of the above
phases, one must ensure that proper documentation is made
of all activities and that appropriate record retention
policies and practices are used. There are quite likely
to be lawsuits and various types of post-mortem analyses
performed as a results of Year 2000 activities. Having
the proper evidence of efforts made will be valuable.
Because of the large number of Year 2000 activities and
the necessity of being done on time, having appropriate
measures to track progress is also important.
Categorization
of Areas to Check for
Year 2000 Compliance
Note - Not all of the
areas listed will be pertinent to every situation, and
not every possible variation in each category is listed
1) IT
Infrastructure
Hardware, PC's, etc.
Local area networks (LAN), servers, security systems,
routers
PC*s (286*s, 386*s, 486*s, etc.)
Operating systems, utilities, security software,
databases, etc.
Operating system, scheduling software, development tools,
tape backup
units
Other "standard" components, such as word
processors, etc.
Microsoft office, Windows, Microsoft Access, Paradox,
FoxPro
2) Application
systems
MIS developed, user
developed, purchased, or used (i.e. outside
services)
Computer-aided design (CAD), computer-aided engineering
(CAE), modeling
Material requirements planning, inventory, forecasting
Production scheduling
Ordering and billing
Accounting, general ledger
Purchasing
Personnel, payroll, human resources (HR)
Electronic Data Interchange (EDI)
3) Non-IT
Infrastructure
Communications
Telephones, voice mail, wireless communication, video
conferencing,
faxes, etc.
Building services
Energy management systems, heating, air conditioning,
electrical
systems
Security systems, building access, fire alarms
Elevators
4) Process Control
Systems and Equipment
Operating plants
Bar coding, card readers, conveyers, optical scanners,
equipment
testing devices,
robots
Programmable Logic Controllers (PLC*s), Computer
Numerical Control
(CNC*s),
Radios, pagers
Research & Development
Diagnostic systems
Data management systems
Simulation tools
Embedded systems
Electronics, processors
5) Other Areas
Utilities, financial
services
Maintenance scheduling, Vehicle maintenance systems
Production suppliers
Non-production suppliers (tools, office supplies,
chemicals, etc.)
Outsourcing vendors, Service providers (transportation,
etc.)
Disaster recovery plans
Back-up and restore systems and procedures
Send
Questions or Comments to Webmaster
©1997, 1998 Computer
Professionals for Social Responsibility
Revised 1999-01-06
|