|
The Sky is Falling? What began a few years ago as an
amusing story regarding a glitch in personal computers that may cause them to do things that frustrate and annoy the user has now grown to a level that many in the news media portray as a direct threat to all of
society. This "glitch" has been dubbed the Year 2000 Bug (Y2K), or the Millenium Bug, and has been gaining attention in the media as the millenium draws to a close. News stories have focused on worst-case
scenarios and have generally attempted to convey the message that society, so dependent on computers and the microprocessors that drive them, will fall into chaos on January 1, 2000. But, while the threat of an
electronic meltdown does contain a certain amount of merit, it only does so for those who do not examine their operations and take the necessary steps now to reduce their risk.
What exactly is the Y2K Bug? Many software and hardware systems that are not updated and made to be Y2K compliant will malfunction in the year 1999 or 2000 because they are unable to correctly identify the
century. For example, the year 2000 will be represented as "00" in two-digit year conventions and will be interpreted by computers as the year 1900. Because of this, many systems reliant on date calculations
will be unable to correctly carry out the commands that are date-sensitive. Who is at Risk?
All businesses and organizations, regardless of size or age, are vulnerable to Y2K problems. Experts have emphasized that this is to PC's,
mainframes and networks. Any device that uses date logic, such as security and alarm devices, telephone systems, heating/air conditioning systems, and elevators, are potentially at risk. An organizations
degree of risk however, is not confined to the computerized systems within the organization. The reliability of vendors, government agencies and emergency support groups may also be compromised because of their
own unique set of Y2K challenges. What Does This Mean For CSRMA Members? Because POTWs are heavily automated, they potentially run the risk of one or more systems encountering operational difficulties because of the Y2K Bug. For a typical POTW,
the following types of systems could be affected:
- SCADA Systems
- Heating/ Air conditioning Systems
- Telephone Systems
- Lab Information Management Systems (LIMs)
- Remote Pump Station Control Systems
- Leak Detection Systems (UST's and other containers)
- Fire Alarm Systems
- Security Systems
- Accounting Systems
- Automated Chemical Feed Delivery Systems
- Auto-testing Systems (Influent/Effluent DO, pH, etc., Automated atmospheric testing)
- Facility Computer Network Systems
- Employee PC's
- Automated Sampling Equipment (Portable and stationary samplers)
Most of those in the wastewater field are well aware of what happens when a sluice gate fails to open or a pump doesn't activate/de-activate, as it
should. Tanks flood, sewers back up, pumps fail and machinery is ruined when the massive level of coordination that occurs in sewage treatment falters. And, as every POTW knows, there is no time during the
year where this coordination is more crucial than the rainy season – which happens to be the time of the year when the Y2K Bug may first appear. Other Y2K issues a POTW will face involve vendors and emergency support. Many POTWs use a "Just in Time" inventory control system for chemical deliveries. This makes
the POTW vulnerable to the suppliers' Y2K issues. Without the timely delivery of chemicals, a POTW exposes themselves to the risk of both violating the conditions of its NPDES permit and having process
upsets. This is especially true during the rainy season when many POTWs experience high flows and must feed high amounts of chemicals. Likewise, the reliability of a timely response from local emergency service
organizations, such as the fire department, may be jeopardized if the contact and response systems within those agencies have been compromised by the Y2K Bug. Even though many systems will bump into
the Y2K Bug at the beginning of the year 2000, many more systems will not falter until weeks, or even months later. This is because many systems are not activated until certain environmental or calendar criteria
are met. For example, if a chemical feed pump has a subroutine built into its programming that calls for an increased delivery at set are over a determined threshold amount and that amount isn't reached until
April, then that particular system won't display the Y2K problem until April. Therefore, staff should remain diligent throughout 2000 and perhaps even into 2001 for Y2K related problems.
Are All Computer Systems At Risk? Not all computerized systems are at
risk. The age of a system however, is not a definite indication of vulnerability. The only way to be certain that a system is not at risk is to test it against one the many Y2K compliance benchmarks that
have been developed. Members should determine if each of their computerized systems and those of their vendors meet each of the Y2K Compliance criteria listed below.
- The software, machinery, equipment, program, application, routine, module, process, or tool will satisfy that:
- No value for dates will cause interruptions in normal operation (including on and after December 31, 1999)
- All manipulation of calendar-related data will produce desired results for valid data values whether by arithmetic, logical, formatting or data management operations
- It can store explicit memory, such as this eight (8) position date format: CCYYMMDD, where CC is the century indicator such as 19 or 20, etc.
These benchmarking criteria are meant to serve CSRMA members as a guide for determining if a system in question is Y2K compliant. What Can a CSRMA Member Do To Prepare? Despite the all the scare stories in the
media, there are steps an organization can and should be taking now. The following are a series of suggestions that will aid in reducing the risk associated with the Y2K Bug:
- Educate and gain the support of senior management and board of directors/ commissioners to define a Y2K Team and provide resources, objectives, budgets and schedules. A project of this magnitude
must have the support and involvement of senior management if it is to succeed.
- Document and record the efforts taken to prevent Y2K mishaps. Such records will be invaluable to demonstrate a due diligence defense should litigation occur as a result of one or more systems
failing.
- Designate a full-time Y2K Project Manager to coordinate system review with senior management, system users and manufacturers.
- Begin an evaluation and prioritization process. Review each system, whether internal or external (external systems are those used by vendors) to consider the consequences of its failure. It will
prove helpful if system manufacturers are contacted to determine if their product is Y2K compliant. If they are uncertain or if they know that their product is not Y2K compliant, ask if they have
resources available to either determine the status or correct the problem. Once all the systems have been identified the decision must be made of whether to convert the software, replace it or
eliminate it. Users throughout the organization should review such an evaluation.
- Contact vendors and determine their Y2K status. Ask what contingency plans they have in place to guarantee continuity of service in the event their systems fail due to the Y2K Bug.
- Develop a contingency plan. Each POTW should have a contingency plan to deal with the failure of any its systems. In some cases this will be as simple as providing additional staffing
to make certain sluice gates open according their schedule, but some will be more complex, such as arranging to have extra chemical on-hand.
- Test the system. One approach that can be used on personal computer equipment is simply to set the computer time to a few minutes before midnight on 12/31/1999 and evaluate the consequences.
However, be certain data and programs are backed-up beforehand.
Insurance Language, Contracts, Warranties and RFP's Looking beyond in-house Y2K issues, all CSRMA member's work with, contract and otherwise rely on outside vendors, suppliers and contractors. This presents an entirely new
set of potential problems related to their Y2K issues. However, there are measures that can be implemented now to limit liability due to the Y2K issues of organizations that are contracted or
otherwise relied upon to provide a service. In addition to the steps already mentioned that a CSRMA member can take now to mitigate the risk associated with the Y2K Bug, there are a host of other
protections relating to insurance, contracts, warranties and requests for proposals (RFP's) that should also be considered. First, every RFP issued for purchasing or renewing contracts that involve software or
hardware should require an express warranty of Y2K compliance and specify damages if the product or service is defective. Next, read all software or software-based service licenses. Identify the vendor's
obligation to fix the programs or devices to operate on 1/1/2000 and thereafter. Be forewarned though, that many software vendors are using Y2K as a convenient vehicle to force upgrades to newer compliant versions
of their software. And finally, put warranty language and specific damage clauses in your new or renewal contracts. CSRMA members may wish to consult with legal counsel regarding contract language
specifics. Sample Warranty Language CSRMA Member's May Want To Use New York has provided a detailed guide regarding the Y2K Bug and contract language on their web site (http://www.irm.state.ny.us/yr2000/contract.htm)
to aid their state agencies in dealing with vendors and contractors. The following is an excerpt from this web site which might prove useful when drafting and reviewing contracts with vendor's and outside contractor's:
New York State Year 2000 Sample Warranty Language "Year 2000 Warranty 'compliance' shall be defined in accordance with the following warranty statement:
Vendor warrants that Product(s) furnished pursuant to this Agreement shall, when used in accordance with Product documentation, be able to accurately process date/time data (including, but not limited to,
calculating, comparing, and sequencing) from, into, and between the twentieth and the twenty-first centuries, and the years 1999 and 2000, including leap year calculations. Where a purchase requires that
specific Products must perform as a package or system, this warranty shall apply to the Products as a system. In the event of any breach of this warranty, Vendor shall restore the Product to the same
level of performance as warranted herein, or repair or replace the Product with conforming Product so as to minimize interruption to Authorized User's ongoing business processes, time being of the essence, at
Vendor's sole cost and expense. This warranty does not extend to correction of Authorized User's error's in data entry or conversion.
This warranty shall survive beyond termination or expiration of the Agreement.
Nothing in this warranty shall be construed to limit any rights or remedies otherwise available under this Agreement."
For More Information… There is an enormous amount of
information and other resources available to deal with the Y2K Bug and its ramifications. The following are three reference web-sites with several links to other informational resources:
www.year2000.com ¨ www.y2k.com ¨
www.irm.state.ny.us/yr2000/yr2000.htm
Conclusion Despite the hype, the millenium will come and go
and organizations will continue to function. Some organizations will undoubtedly fair better than other's, but those which are looking ahead and planning to deal with whatever may happen are sure to be the ones
that fair the best. POTWs should look to staff expertise, other POTWs and professional organizations to share information and ideas on how to best protect the public investment, provide uninterrupted operations
and maintain regulatory compliance. |
---> 
