SCADA, GIS, OMS, CIS… the list of acronyms goes on and on. In fact, about ten years ago I wrote an editorial about the fact that there are so many acronyms we’ve had to start recycling them. For example, is ATM an Automated Teller Machine? Or, is it Asynchronous Transfer Mode? Is EMS Energy Management Systems (of several types and varieties on its own!) or Environmental Management Systems? And the list goes on…
Any reasonable person would correctly say that one must look at the context to understand the intended meaning. Context is pretty much a basic underpinning of communications, whether written, spoken or otherwise transmitted from Point A to Point B. However, when it comes to utility automation, it seems like we may be losing track of context.
When utilities look at a new automation
project, I think the context tends to be (too much and too often) what it is rather than what it does. You don’t hear much about utilities going out for bids to improve reliability, enhance safety or boost efficiency (or reduce rates?!); they usually just go looking for a new SCADA system; a new GIS ; or a new OMS . And hardly anyone puts out an RFP labeled: “Customer Service Improvement” request; instead they prepare specifications for a new CIS .
In all fairness, I’ve personally seen a few specs that attempt to explain a little about what the real objectives of the project are in beneficial terms, but even then, it typically only gets a paragraph or two in the preface. The preface, if you’re not familiar with it, is the part of the RFP everyone skips over trying to see what it is that the utility is trying to buy and how much it is likely to cost.
As a former application engineer (and the author of a proposal or two during my supplier days), I can say with some degree of experience that the underlying reasons for automating are frequently lost on the buyer and the seller – the result of being overshadowed by technical, financial and commercial issues. This is not to say that those factors should be ignored or even diminished; only that the benefit side of the cost/benefit analysis should also perhaps be shared more completely and more openly with the suppliers so that everyone can understand the real reason they’re being asked to present their wares.
Of course, maybe I’m being a little too
presumptuous by assuming that a cost/benefit analysis was actually performed. As a widely respected utility automation consultant said to me a few years ago, ”Somewhere between engineering school and deregulation, most utility engineers seem to have forgotten how to do a cost/benefit analysis!” He was lamenting the fact (or at least his recent observations at the time) that too many automation projects were being rushed out the door with hardly a clue of what kind of return the project could be expected to produce, not only in dollars – the cost element of the CBA – but especially in terms of the benefit side of the equation. Sure, sometimes it goes the other way, and it’s all about the money and ROI , but that really shouldn’t be the end of the story. You’ll never be able to claim a successful project if it doesn’t deliver the desired results.
In any case, the next time you are called upon to plan or launch a new automation project, make sure that you understand what it is you’re really trying to accomplish, and not just what you will buy to accomplish it. It is indeed possible to buy exactly the right thing, but for completely the wrong purpose… and at the end of the day, isn’t it really all about the results?
_____________________________________
Key to Abbreviations:
SCADA - Supervisory Control And Data Acquisition
GIS - Geographic Information System
OMS - Outage Management System
RFP - Request for Proposals
CIS - Customer Information System
ROI - Return On Investment (Some might argue,
however, that this really means: Really Old Information!)
About the Author
Mike Marullo has been active in the automation, controls and instrumentation field for more than 35 years and is a widely published author of numerous technical articles, industry directories and market research reports. An independent consultant since 1984, he is co-founder and Director of Research & Consulting for InfoNetrix LLC, a New Orleans-based market intelligence firm focused on Utility Automation and IT markets. Inquiries or comments about this column may be directed to Mike at MAM@InfoNetrix.com.
©2005 Jaguar Media, Inc. & Michael A. Marullo. All rights reserved
Any reasonable person would correctly say that one must look at the context to understand the intended meaning. Context is pretty much a basic underpinning of communications, whether written, spoken or otherwise transmitted from Point A to Point B. However, when it comes to utility automation, it seems like we may be losing track of context.
When utilities look at a new automation
project, I think the context tends to be (too much and too often) what it is rather than what it does. You don’t hear much about utilities going out for bids to improve reliability, enhance safety or boost efficiency (or reduce rates?!); they usually just go looking for a new SCADA system; a new GIS ; or a new OMS . And hardly anyone puts out an RFP labeled: “Customer Service Improvement” request; instead they prepare specifications for a new CIS .
In all fairness, I’ve personally seen a few specs that attempt to explain a little about what the real objectives of the project are in beneficial terms, but even then, it typically only gets a paragraph or two in the preface. The preface, if you’re not familiar with it, is the part of the RFP everyone skips over trying to see what it is that the utility is trying to buy and how much it is likely to cost.
As a former application engineer (and the author of a proposal or two during my supplier days), I can say with some degree of experience that the underlying reasons for automating are frequently lost on the buyer and the seller – the result of being overshadowed by technical, financial and commercial issues. This is not to say that those factors should be ignored or even diminished; only that the benefit side of the cost/benefit analysis should also perhaps be shared more completely and more openly with the suppliers so that everyone can understand the real reason they’re being asked to present their wares.
Of course, maybe I’m being a little too
presumptuous by assuming that a cost/benefit analysis was actually performed. As a widely respected utility automation consultant said to me a few years ago, ”Somewhere between engineering school and deregulation, most utility engineers seem to have forgotten how to do a cost/benefit analysis!” He was lamenting the fact (or at least his recent observations at the time) that too many automation projects were being rushed out the door with hardly a clue of what kind of return the project could be expected to produce, not only in dollars – the cost element of the CBA – but especially in terms of the benefit side of the equation. Sure, sometimes it goes the other way, and it’s all about the money and ROI , but that really shouldn’t be the end of the story. You’ll never be able to claim a successful project if it doesn’t deliver the desired results.
In any case, the next time you are called upon to plan or launch a new automation project, make sure that you understand what it is you’re really trying to accomplish, and not just what you will buy to accomplish it. It is indeed possible to buy exactly the right thing, but for completely the wrong purpose… and at the end of the day, isn’t it really all about the results?
_____________________________________
Key to Abbreviations:
SCADA - Supervisory Control And Data Acquisition
GIS - Geographic Information System
OMS - Outage Management System
RFP - Request for Proposals
CIS - Customer Information System
ROI - Return On Investment (Some might argue,
however, that this really means: Really Old Information!)
About the Author
Mike Marullo has been active in the automation, controls and instrumentation field for more than 35 years and is a widely published author of numerous technical articles, industry directories and market research reports. An independent consultant since 1984, he is co-founder and Director of Research & Consulting for InfoNetrix LLC, a New Orleans-based market intelligence firm focused on Utility Automation and IT markets. Inquiries or comments about this column may be directed to Mike at MAM@InfoNetrix.com.
©2005 Jaguar Media, Inc. & Michael A. Marullo. All rights reserved
