May 12, 1998
Your letters to my
print
column
and this E-mail forum ask some serious questions about managing information
technology in today's world. Since today's world is essentially absurd, my serious responses may
sometimes sound a little whimsical, and my occasional whimsical ones, serious. In any case, if
you want to participate, write to me at
lovelace@home.com
. I'll respond to those letters that I
can. I reserve the right to edit for size and content. Just sign your E-mail the way you want it to
appear online.
Dear Herb:
I wonder about your friend ("
1998: Year Of Conversions
," Jan.
5, p. 121) who is not worried about business systems because they are installing SAP, but is
worried about process control systems. What type of a process control system does he have?
Most process control systems have no idea what the date and time is, only how long it's been
since the operation was started. As a process engineer, I can tell you that we have no process
control systems that really care about
the date and time. On top of which, our vendors have already fixed what little had to be fixed for
the year 2000 problem.
I sure would like to hear more from your buddy who has process control systems which are going to go "crazy" when they cross that 1999-2000 border.
Maybe I have one too and never realized it.
Frank G.
Dear Frank:
I, also, w
as interested in my friend's comments about process control systems, so I asked him
during that lunch to expand on what he had told me. His response spurred me to do a little
investigation into our own year 2000
program and what I found, I am afraid, isn't good. It seems that he may be correct. In fact, I have
made some
major modifications to our own plans as a consequence of what I found.
When I spoke to the manager in charge of our year 2000 efforts, she said that our manufacturing people had the same initial reaction as you did (which coincided with my own first thoughts) when the subject of year 2000 and process instrumentation was raised:
1) Our process control systems don't care about the year date.
2) What little in the way of problems we do have is so obvious that we've fixed it.
3) Anything that remains is the responsibility of the vendor.
Alas, my complacency was shattered when I looked into it further. It seems that we have very little idea which chips are concerned with date s and which are not. This made no sense to me until someone told me that the processors in some of our controllers are ordinary logic chips that have calendar capacity even though we assume the software doesn't use the date. The chip, itself, may become flaky and crash the system.
When we checked with the vendors, they told us that everything would operate fine and not to worry, that they were working on checking out any problems as we spoke. That comforted us somewhat until we asked for certification letters. At least two of our primary process control suppliers refused to do so, saying that, in fact, they could not guarantee there would be no difficulties. What was especially scary was that they no longer had the information as to the heritage of some of the chips in our equipment and had no idea, if truth be told, as to whether or not the turn of the millennium would cause the instruments that run our plants to barf.
Perhaps my fears were overblown. I did a little more research only to find there w as no reason to relax. It seems that Phillips Petroleum did a year 2000 test on an oil-and-gas production platform in the North Sea toward the end of last year to find out if there was any reality around the concerns about the big, bad triple-zero year. They found that when the clocks were advanced to the witching hour after Dec. 31, 1999, a critical safety system shut down, which would have released a poisonous by-product gas onto the platform.
Although not directly a year 2000 difficulty, a marvelous date problem caused by demented clock chips occurred on Dec. 31, 1996. It seems that New Zealand Aluminum Smelters had a program on one of its process systems that did not believe in leap years, which 1996 was, and decided that the day date of 366 was invalid. The computer shut down all the smelting-pot lines at the plant. The pot cells overheated and had to be trashed. Cost: $1 million New Zealand dollars.
This last one will really warm your heart -- or maybe make it glow. The Nuclear Regulatory Commis sion has reported that in one year 2000 test, the security computer at a nuclear power plant failed and unlocked areas of the plant that are usually kept very secure. So maybe a Dec. 31, 1999, scavenger hunt at these power-plant sites will permit the millennium to arrive with some really unusual party favors for the enterprising and foolhardy.
I'm not saying that the year 2000 will be a disaster for process control computers or for that matter the computers that control elevators, train signals, or even the air traffic control system. But I am worried.
At a recent conference I attended about an entirely different subject than the year 2000, a member of the audience asked the speaker if he would fly on New Year's Eve, 1999. The said he wasn't worried about flying on that date, but he was concerned about landing.
How are most CIOs managing to keep up to date on the multitude of technologies and the evolu tion of technologies that are occurring? I read a few hours a week, but still feel like there is a lot I don't know about.
The Donn of IT
Dear Donn:
In a word: badly.
In two words: not enough.
Keeping up with the rapid technological change in information technology is akin to trying to drink from a high pressure hose: It is essentially impossible to get anything but a small taste of what is spewing out from the source. Everyone I know is complaining about the impossibility of absorbing all of the information out there.
The old joke, which is no longer funny, is that you should get away from your job for a week if you want to remain sane. Get away for two weeks if you want to really relax. Get away for three weeks if you want to become hopelessly technically obsolete.
Most of the people in jobs like mine read magazines like InformationWeek and CIO that give short summaries and some in-depth analyses of hot topics. We look at other magazines such as Business Week and Fortune to get the business perspective of how technology is being used and judged. We speak to each other to learn what other CIOs are actually implementing, and we depend a great deal on key members of our staffs to keep us up to date on what they are doing in their own particular area of expertise and why.
And we rarely, if ever, take three week vacations.
I enjoyed your article " The Art Of The Budget " (Sept. 22, 1997, p. 392). I'm preparing a research paper for a graduate study on intranet ROIs and stumbled upon your piece. In my research from many different sources, including personal interviews with Internet/intranet experts, I've heard ROIs from 20% to 1000% (the majority being around 35 to 45%). What have you seen for ROI in this area?
Doug C.
Dear Doug:
There is a strange phenomena. It occurs among fishermen describing the size of fish that they
have caught over the years, golf players
recollecting great shots they have made, and older men reminiscing
about the women they dated while in college. While some of the stories are no doubt true, others
have benefited by the benign effects
of retelling the tale.
As you probably are aware from your studies, it appears that intranet applications are at the stage of development where they are more likely to provide high ROIs than Internet applications. There are exceptions. Federal Express' Web-based package-tracking system has reportedly saved them millions of dollars in personnel costs for customer service people.
The use of intranet applications to eliminate administrative work such as producing manuals and newsletters, or permitting employees to make the changes themselves to their benefits selections, has proved to be of great value. I don't doubt that the high ROIs you're hearing about are possible. In our own company, we have generated some impressive double-digit ROIs for this type of work. The only problem with these large numbers is that the base on which they are calculated is not terribly large compared to the cost of raw materials for a company or its total manufacturing expense. As a result, they're not always the best projects on which to devote scarce IT and business resources.
I have a career counseling question.
I have five years experience with selling computers to Fortune 1000 companies. I have worked with many large customers on several projects involving procurement, troubleshooting, and rollouts of over 1,000 PCs. Prior to this, I was the general manager of a small computer firm where I had many responsibilities, including overseeing 60 PCs, programming the database, and managing up to 15 people.
I am considering a move into an IT organiza tion and am curious as to the possible areas where organizations might see a strong fit. Should I enroll in a masters-level program before I find this position, or after? Do my skills make sense for an IT organization?
John
Dear John:
Your goal of moving into an IT organization is a very logical and
obtainable one. In today's environment, many IT shops would be
delighted to have a person with your background of sales and general
management.
There are several specific areas within an IT group where your talents could be utilized. These include working with end users to provide PC support, doing systems requirements analyses for proposals, and being the person on a major project who deals with the vendors or who prepares the overall status evaluations for the users.
With regard to your question about masters-level program, keep in mind that enrolling in graduate school before you start looking for a position shows a prospective company your desire to increase your skills -- a plus in the eyes of a recruiter.
Herbert W. Lovelace is CIO at a multibillion-dollar international company. Herb practices his day job under an alias and has changed the names of colleagues to protect the guilty.
Home | Career | Financials | NewsFlash
Resource Centers | Shop Talk | Search
This Week's Issue
Technology Whitepapers
- Mobile BI: Actionable Intelligence for the Agile Enterprise
- Creating the Enterprise-Class Tablet Environment - by Yankee Group
- How To Regain IT Control In An Increasingly Mobile World - by BlackBerry
- Red Alert: Why Tablet Security Matters - by BlackBerry
- New Visual and Wizard-Driven Paradigms for Exploring Data and Developing Analytic Workflows











