y2k countdown: Welcome to the O.R.
Few places like the Operating Room maintain a high level of attention to methodically avoiding infections and risks via ‘clean room’ management type techniques. It is one of the more costly items in the cure and prevention of additional medical problems. To the health care industry this is commonplace and well known are the associated risks in these areas. The value of a life and consequences of loss are paramount. Should business and MIS begin to think in a like fashion?
For one moment liken your company and its’ Year 2000 efforts to those of medical providers services from EMS to the operating room. Be sure to pick the one that you have to rely on for your good health both routine, more serious, and emergency in nature. Ask yourself honestly, What has my track record been? ‘’How Am I doing at this time?’’ Where are we now?
Evaluate yourself in this performance matrix:
Patient Relations
Systems and Software practices and standards, should be very similar to good medical, engineering, or research ways. Each has a need for creativity, control, discipline and follow up. As an industry, as a company work group, our IS products must adhere to all the cautions and cross all business standards required to function without interruption or newly introduced difficulties. The left-hand column is very interchangeable with Information Systems terms. Terms which can be evaluated on the same function or risk scale.
In Year 2000 project terms, one has to measure both business and operational aspects to have the company come through, come out a leader, or sacrum to a highly reactive set of disorganized happenings. Can You exchange the medical terms in that column with MIS terms and send me the answers? [My Email address is below.]
Standards Rules and Dead-lines
This very much means the same to MIS in terms of spotting errors, omissions, and preventing re-infections to programs and databases you have corrected or modified to work properly with your Year 2000 environment. Bottom line is to reduce risks! Manage risks to prevent new errors when the programs change or data enters from outside sources[inter or intra your systems]. The whole universe will not move to Year 2000 compliance at the same moment in time, nor in the exact same way. Hopefully, all will move to compliance but most all will fall very close to each other and in different ways, thus clogging up your [ER] Emergency [War] room abilities to manage the plethora of varieties and translations for harmonious data exchange and communications. It’s a semi-controllable Domino effect.
More Madness
Pivot dates will vary, implementation dates will be different, formats will not agree and change without notice. These are all risks to be minimized and managed. Your applications data entry points have to provide for the detection, filtration, correction and in some cases denial of uncorrectable transactions. This is not revolutionary news. Our systems have been editing data for years. What is different is the many new ways dates will be represented and the logic required to adequately detect and handle them.
Routes to Translation: Ours or Theirs.
This strongly suggests creating as few date logic segments as possibly. If you are already using of date data type or the likes RPG IV, exploit it for its date validation, mathematics, and handling. IF not , you should be strongly consider standard date routines. Either you can write it yourself and deal with all the concerns of performance efficiencies, testing it thoroughly and debugging it, or go out and buy a commercially available product like IMPACT/2000® which has been developed, tested, and in use by several.
My best bet is regardless of your intentions to implement a pure solution there are exceptions. For example nobody liked the new eight digit date data entry and you had to modify that work by inserting some sort of “input/output” window logic to avoid/ minimize change to the end users and their productivity. How about vendor application software being different from in house written programs in the date handling and display/reporting areas. External trading partners EDI or other mandated forms of data transmission to and from your system. All are good reasons for standard date routines. Routines that can create bridges between unlike formats, handle conversions easily.
On Pivot Dates
A question that appears often is how many different pivot dates should be within a system? A company? An enterprise? How often should these pivot dates change? Who should have access to making those changes and finally how do we track them? In the same vein looking at electronic trading - there are several pure or pivoted methods. Large enterprises very strongly encourage all suppliers to use their format of electronic trading while the smaller companies tend to use one of the several Electronic Data Interchange formats
Conclusion
Regardless of whether you use Encapsulation, Expansion, Windowing, and/or Standard Date Routines, the value statement is on being: highly accurate, extremely correct, fully tested, and independently verified. The second value is consistency with date routines minimizes exposures. It's all about good management and prudent risk! The better built here philosophy is rarely justified if there is a tried and proven solution at a lesser cost.
Glenn Ericson is president and founder of Phoenix Consulting LLC, in East Elmhurst, N.Y. He specializes in Year 2000 and risk management issues. Glenn-Ericson@att.net.