ANALYSIS: Minimizing Risk Via Audits and Reviews
By Glenn Ericson
In the last year or so, many tools have entered the market to help with the Y2K audit/review process. These tools increase the speed of a review and provide a consistent methodology throughout, through automation of the process. Such automation leaves more time and focus for the heuristic areas. In some reviews, use of the right tools has reduced my information gathering time from weeks to anywhere between eight hours and three days. This is not always the case, as you can occasionally run into a system that is not well tuned, and a normal four-hour automated job segment will take 60 hours.
Year-2000-centric IS audits and reviews have continued to grow over the last three years. Informal surveys taken across this time span suggest the percentages have risen many magnitudes above the 10 percent level that was common prior to early 1998. In 1999, trends move upward as the time remaining to day one of "00" diminishes.
One wonders why more time is not being spent reviewing new systems development--those applications that replace older non-compliant application--as part of the Year 2000 effort. Perhaps it is the old rule that suggests investing only in the highest risk for very vigilant protection and attempting to deal with the rest on an 'as it occurs basis'. There is an assumption here that the incident rate and the resource ability to handle these problems will be within an acceptable repair time level as not to cause costly business disruptions. This could be a severe concern if the theorem is not true.
Audits or independent validations and verifications are point-in-time reviews. Reviews under given conditions and parameters. One might view these findings to remain valid as a function of change control or other AS/400 features for tracking change. As this suggests, follow-up reviews are necessary to ensure these systems and projects remain, with the same level of quality and functional status as when reviewed.
How long can code changes or application enhancements or additions be frozen? Can progress be inhibited? The right answer should revolve around the shortest path to Year 2000 compliant systems and the risk analysis for both project and business wellness. Wellness both internally and externally to the supply chain and other infrastructures that surround it.
Perhaps IS should work on Year 2000 in a "find it, fix it, bless it, and move on" manner. However, be cautious to minimize introduction of new risk. Can we do that prudently? Can we judge our results and stability fairly and objectively? Enter the audit or independent review while the staff might be deployed to future project development and recalled as required.
As an example, consider e-business. This has been receiving a very strong push from IBM and others as the wave of the future. After the Web site the next transition is to e-commerce. The transaction of business on the Web--worldwide, any time, lower marketing resources, 24-hour availability. Who could say 'no' to such lucrative opportunities? If it gets done now, assuming time is available and put in place, there are regression tests and verifications or validations to ensure an uneventful entry of the year 2000. Alternatively, development might happen just short of production implementation. Even perhaps a separate static introduction isolated from Year 2000 completed production efforts.
For most organizations, the focus is primarily on their internal systems within the enterprise or department. You must take time to look at a more global view of your computing infrastructure. Understand that infrastructure spills over to external communications product and service providers within and outside one's own organization. Have they taken the steps to become Year 2000 compliant? Do they meet your objectives?
Can you mesh in such areas as EDI? EDI is a unique example as the inbound and outbound message structures can be company-to-company specific more than any other area. In many cases, an entire or portion of an organization's business may be sourced from product or service providers. If this is a single or sole source and it falters, serious business disruption and/or financial loss can occur. Look for proof of compliance, specific processes and alternate suppliers.
At this juncture, it is best if IS handles the technical aspects according to all business priorities. IS can be very helpful in identifying sole suppliers, but business managers should handle the investigation and assignment of the audit or review in the non-technical areas.
Often the Year 2000 is not the problem, but rather symptoms of underlying dilemmas found in inadequate communications, change control, leadership direction and common sense. Do not assume everyone is making corporate-wide central communications and consistent directions with yours. There needs to be an empowered focal point to decide the best use of resources, time and funds for the good of the organization.
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.