Insider Tips on Buying a SCADA System

Defining Requirements

Once you have defined the goals, then you need to specify what it will take to achieve those goals. Will a newer version of your current SCADA system achieve those goals? Do you need to replace all your hardware to achieve those goals? What new technologies can be applied to achieve the company's business goals?

Typically, the answers to these and other questions end up in a specification that is ultimately put out for bid.

In preparing the specification and other bid documents, many companies make one or both of the following mistakes:

• They define project requirements in vague terms that cannot be measured, or …
• They define project requirements in so much detail that few bidders can cost-effectively fulfill those requirements.

Let's look at each of these a little closer.

Overly Vague Bid Documents = Overly Vague Bids

Let's see now, we want to replace our SCADA system in order to accomplish the following goals:

• Improve usability.
• Maximize flexibility.
• Provide a platform for future expansion.

Improve the usability of what? Do you want your HMI icons to be prettier or do you want your operators to use fewer mouse clicks to close a valve? And exactly how do you measure improvement? Efficiency experts say that any change in the work environment - even a negative change - causes at least a temporary boost in productivity. It's called the Hawthorne effect. So, according to the Hawthorne effect, it's possible that we could improve usability by painting the I/O racks pink. But I doubt that's what the author of "improve usability" had in mind. If you want to improve usability, you at least need to state what constitutes an improvement, not to mention what you expect to improve.

The same is true of maximizing flexibility. The flexibility of what? And what constitutes flexibility? And exactly how much is "maximum"? When my daughter asks for maximum flexibility in her curfew, I guarantee you that her definition of the words "maximum" and "flexibility" are vastly different from mine. Unless those words are defined, they can only lead to confusion, miscommunication, and added costs.

Do we need to discuss "provide a platform for future expansion"? It suffers from the same lack of specificity as the other vague goals.

Vendors think it's very important to know what your goals are. It helps vendors tailor proposals and bids to meet those goals.

What's tragic is that even those bid documents that clearly enumerate goals often go too far.

Overly Detailed Bid Documents = Overly Costly Projects

Let's say you've written a tight, comprehensive specification that states exactly what you'd like to purchase. You then proceed to tell bidders how to accomplish your goals using the tools you have dictated. SCADA vendors will jump at the chance to bid this type of project because we can submit the lowest price to win the job and all the risk is back on you.

This is a big mistake. You can't think of everything in the initial stages of a project, yet this approach assumes you have. Right from the beginning you've either closed the door on improving the SCADA system, or you have made doing so very costly. In the end, the customer who takes this approach ends up paying more for his project than it should cost. Or even worse, the system does not perform the way the company expected it to perform.

Well, that's exactly what many companies do. And they miss out on a tremendous opportunity - the opportunity to get lots of free advice from willing vendors.

We call these two types of specifications performance vs. procedural.

• The performance specification or request for proposal states exactly what the company wants to accomplish.
• The procedural version states exactly how the company expects to accomplish their goals. The procedural version is often loaded with lots of technical specifications for networks, timeouts, software, RTUs, PLCs, protocols, radios, etc. Very often, procedural versions are written by consultants who lock their clients into very narrow options.

RFQs and RFPs Should be Written, Not Collated

You've heard the old saying, "A camel is a horse designed by a committee." In far too many cases, RFQs and RFPs look amazingly like camels.

There are often contradictions between the specification and the compliance table. Sometimes the commercial requirements conflict with the technical requirements. Sometimes the schedule and payment milestones negatively affect execution and performance. Many specs and bid documents look and read like what they are: different documents pulled together with no coordination among sections.

Of course, sometimes you end up with a camel even without the involvement of a committee. For example, it is quite common for a consultant to take the following approach to writing a specification:

1. Start with a previously written specification, perhaps a good one.
2. Solicit sample specifications from several SCADA vendors.
3. Choose the best features of each system and compile them into your specification.

This is the "Greatest Hits" style of specification. It's certainly easier than writing a specification that addresses your needs.

Another problem is that many specifications contain varying degrees of detail. Perhaps the committee member assigned to develop the architecture supplies detailed drawings and itemizes every workstation, every controller, every server, and every communications hub. But another committee member fulfills his or her assignment by specifying nothing more than the phrase "include a simulator".

Such discrepancies make vendors wonder whether or not we are getting the whole story. If we think that you are under- or over-specifying your system, we tend to under- or over-estimate our costs. If we under-estimate them, you'll end up paying more. If we over-estimate them, you'll end up paying more.

Bid Sections Should be Evaluated for Relevance and Usefulness

One of the more problematic sections is the compliance table. The compliance table can be a useful tool. But before you include one in your bid, you need to ask yourself what you expect to learn from the compliance table. If every bidder indicates that they are compliant on every point - which is very often the case - what does that tell you? Is that credible? Does it mean that all bidders are equal?

Some vendors consider taking exceptions to a specification as a negative, not an opportunity to show how they are different or even better. As a consequence, they bend over backwards to avoid taking any exceptions.

How will you evaluate exceptions? Will you consider the impact of each exception on the project, or will you just add up all the compliant check marks and play it by the numbers?

A more useful approach would be to provide space for the vendor to describe an exception and how it might impact the project. Minimally, the compliance table should allow the vendor to flag an exception for further discussion with the customer so that the customer can understand the relevance of the exception to the project.

This suggestion also applies to other parts of the bid. For each section of your bid document, ask yourself how you plan to evaluate that section, its significance within the evaluation, and whether or not it contributes any tangible value to your evaluation. You should also determine whether or not the section can be evaluated, and if so, whether or not you can easily compare vendor answers.

Here's an example of what I'm talking about. Many bid documents request a company history. As a vendor, we are happy to supply one. But what are you looking for in such a section? Are you looking for an older company or a newer one? Are you looking for an innovator or a company that can execute traditional technology? If you ask for something as nebulous as a company history and you're looking for something specific, there's no guarantee that you'll get a response in a form that tells you what you need to know. If you're looking for something specific, ask specific questions.

If you just want to learn about the company's background, that's fine. But if that background is supposed to tell you something significant and you have not figured out what the significance is before you send out the bid documents, consider getting rid of the section. Otherwise, it just makes more work for you during the evaluation.

< Previous 1 2 3 4 5 6 Next >