A quarterly newsletter for clients and friends of Chenault Systems
This past year, more of our clients have called upon us to perform round table style consulting. For example, since we are completely independent of all hardware and software vendors, several companies have asked Chenault Systems to help in the selection and management of vendors. In today's business world, there is a myriad of products and vendors to choose from in the information technology field. Coming up with a good vendor strategy can be very time consuming to a company. Using our many years experience of working with vendors, and being product vendors ourselves at one time, we act as an impartial advisor to help choose the best vendors and products to best fit our client's long term goals.
Software is continually updated and enhanced because of many issues. The Year 2000 problem is just one of many problems we face in this industry. Our management consulting practice offers many services to address these problems, which include advice and solutions for year 2000 problems.
The year 2000 will not be the end of the world, but we cannot ignore it either. The following is an article from the Review & Outlook Manager's Journal section of the September 28, 1998, issue of the "Wall Street Journal" which explores this subject a little more. In our opinion, the most important aspect of this article is the emphasis on the amount of testing time, which applies to all systems development.
Slowly but surely, public awareness of the Year 2000 Problem is growing. When I chaired my first Senate hearing on Y2K issues in June 1997, there was only a smattering of attendance in a relatively small hearing room; at the opening of the Senate Special Committee on Year 2000 Technology Problems this July, a much larger room was filled to overflowing. Y2K, - the challenge we will face in 15 months, when computers read the two-digit year "00" as 1900 - has been discovered.
The questions that accompany Y2K awareness fit a predictable pattern. How bad will it be? Which systems are most at risk? How much will it cost? And how did we get in this mess in the first place? Perhaps because we all learned to expect miracles in today's high-tech world, there is also a combined sense of denial and faith: Surely the techies will be able to fix this in time. It can't be that big of a deal.
Although I've been immersed in this issue for more than a year now, I don't know how bad it will be in specific terms, and nobody does - we're all guessing. There is no precedent for a problem of this kind to give us any historical benchmarks.
I can tell you which systems appear to be the most vulnerable right now, but I can't predict with any certainty what's going to happen to those systems in the 15 months we still have left. Some that appear to be high-risk today may turn out to be the easiest to fix. John Koskinen, the president's Y2K czar, believes that this is the case with respect to the Federal Aviation Administration, once considered the federal agency in the most Y2K trouble. But others that seem to be fine may fail.
I also don't know what it is going to cost. In all this uncertainty, however, there are some things I know:
When you put all these "knowns" together and weigh them against the unknowns, one thing becomes clear: Preparing for and meeting the Y2K challenge is a top management issue. We cannot "leave it to the techies," as many seem willing to do.
Which are the mission-critical systems that we absolutely cannot allow to fail? How soon should we start looking for alternatives if key suppliers appear to be lagging? What contingency plans need to be drawn up? Confronting key questions like these is not in the job description of the chief information officer. These are the kinds of things we pay chief executive officers to address.
It is clear from the testimony I have heard and the evidence my committee staff has accumulated that Y2K will not be "solved" by New Year's Eve 1999. This means CEOs will have to perform triage - focus on what is critical to sustain the life of the firm, ruthlessly stop action on the less critical activity and lay out realistic contingency plans, starting no later than the last quarter of 1998 - that is, now.
Good CEOs have already discovered this truth; foolish ones have turned the problem over to their CIOs and moved on to other issues that are "more pressing." Nothing is more pressing than a company's survival, and if Y2K questions are not properly answered, survival will be jeopardized.
As I talk this way around the country and in the Congress, I am sometimes accused of being an alarmist. I respond by saying that I am trying to be Paul Revere without being Chicken Little. Like the British in 1775, the problem is coming. However, the sky has not yet started to fall. Whether it does depends on how many, and how soon, CEOs and other top managers address the real questions and prove they are worthy of the corner offices they occupy.
Mr. Bennett (R., Utah) is chairman of the Senate Special Committee on the Year 2000 Technology Problem
Reprinted with permission of The Wall Street Journal copyright 1997 Dow Jones and Company, Inc. All rights reserved.
Recently, in our travels throughout the corporate landscape, we have come across several delayed systems implementations for corporate-wide solutions. For example, one company has postponed any other systems work until they have completely installed SAP - the enormous all-purpose, very expensive, all integrated solution to all problems for everyone. We were told they "have no idea" when the SAP installation will be completed. Apparently, the installation is already two years late. Meanwhile, end-users of new, smaller applications are on hold - and so is the productivity benefit those tools might provide - until further notice.
In many of our writings we have stressed the importance of delegated freedom for information systems. Since the end-user of corporate systems is really the customer, common sense profitability should consider "short term" needs of the customer over long term security for vendors and internal information technology departments.
SAP-type systems can be good solutions, but should not be a panacea for all information technology opportunities. It is too easy for people to quit thinking because a "corporate standard" has been decided. The cost is often lost flexibility. High-level decision-makers need the best information, regardless of what system it comes from. A monopoly should never be granted to just one vendor, service or product.
Over the years, we have seen many "short term solutions" become a real business solution, lasting ten years and more, while waiting for the emplacement of some future corporate system. Many of the systems we have developed fall into this category since we often work with the end-user and try to put what is best for the client (from a business point of view) over what may be best for a software vendor.
In addition, the never-ending corporate goal for a company software standard is nearly always superceded by newer technology. Just about the time a standard is close to being in place, innovation inevitably makes the standard obsolete. Examples are numerous. Mainframe systems were up-ended by PC networks in the late 80's. The Internet has forced policy makers to reconsider wide area networks in favor of "Intranets." Forced marches to make everything all IBM become forced marches to make everything all Microsoft, which will likely be replaced by another forced march brought on by innovation.
In our very first newsletter in 1993 we wrote: "Tiny miracles can be accomplished by individuals or small groups if centralized management will just leave them alone." We still believe that statement to be true and we would like to help with these tiny miracles and promote good pragmatic solutions with or without large centralized systems.
"It's a good thing we don't have all the government we pay for." -- Will Rogers
"Dogma does not mean the absence of thought, but the end of thought." -- Gilbert Keith Chesterton
|
Chenault Systems, Inc. |
(972) 306-3839 Voice |
E-Mail: Chenault Systems,Inc.
Copyright © 1998-99 by Chenault Systems, Inc.
All rights reserved.