Six Decisions You Must Get Right Before Upgrading Your Automation System

There are six decisions you must get right before upgrading your automation system.

It doesn’t matter whether you are just upgrading equipment – like PLCs, RTUs, or HMIs – or upgrading larger automation systems – like compressor stations, pumping stations, or master station SCADA systems. We have found that automation upgrades often fail because buyers fail to make a few critical decisions early in the upgrade process.

This report identifies the critical decisions you must make early and correctly in order for your upgrade project to be cost effective, achieve your goals, and reduce the risk of incorrect startup and operation.

1. Decide on a clear purchasing and evaluation plan

Make sure you have a plan for identifying your needs, for documenting those needs, and for identifying the best vendors to approach for proposals and/or bids. Whether you hire a consultant or do this yourself, the purchasing and evaluation plan needs to include a time line for at least the following major tasks:
 

• Requirements development
• Procurement process
• Bidder selection process
• Bidder evaluation process
• Vendor award process
• Configuration
• Factory acceptance test
• Start-up

The plan should also indicate what percentage of each stage will be performed in-house and what percentage will be performed by the consultant, vendors, or others who will be involved.

This is your road map. As the philosopher once said, if you don’t know where you’re going, how will you know when you’ve arrived?

2. Decide early which stakeholders will be on the project team, and put only one person in charge

If your project’s scope warrants it, put in place a project team that participates in the upgrade process from the very beginning stages. This team should include all of the major stakeholders. Depending on the scope of the project, this might include field engineers, technicians, analysts, operations personnel, IT people, and management.

The field and operations people know what will and won’t work in the field. For a larger project, the IT people know the requirements of the back office or host system that might need to be interfaced with the field operations. And, management is best suited to keeping an eagle eye on the business goals and bottom line. Don’t wait to get these people on board. Get them involved from the beginning.

Once you have a project team, make sure that a single person is in charge. That person must have the authority to make decisions and to ensure that the system meets both the company’s technical and business goals – especially the company’s business goals. When one person has his or her reputation on the line, the project is more likely succeed.

3. Decide why you want to upgrade (your goals)

Why do you want to upgrade? If you can’t identify compelling reasons, don’t do it.

The absolute worst answer is “because it’s time.” Maybe your system’s components have reached end-of-life and are hard to repair, but they still work. Maybe they no longer represent cutting-edge technology. Maybe you’re tired of your competition whipping out photos of their shiny new system while you are embarrassed to show worn-out photos of your ancient, toothless system.

These are not usually compelling reasons to upgrade.

In fact, the only good reason to upgrade is because it achieves one or more tangible business goals. The exact goals will vary from company to company. What’s important is that those goals be identified and quantified, and that they become the most significant criteria in selecting a replacement system.

4. Decide what it will take to achieve your upgrade goals

Will a newer version of your current system achieve your stated 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. And, just as typically, these documents are either too vague or too detailed for their own good.

Overly vague bid documents lead to overly vague bids. Telling vendors that you want to improve usability, maximize flexibility, and provide a platform for future expansion could mean just about anything. Vendors want to know exactly what you are trying to achieve so that they can provide you with a bid that will best meet your goals.

However, overly detailed bid documents can lead to overly costly projects – not bids, projects. If you tell vendors exactly how to do their job, they’ll give you low-ball bids that put all the risk back on you. Unless you know exactly what you want and how to go about getting it, you can’t think of everything this early in the upgrade process. If you try and you’re wrong, you’ll likely end up with low bids and lots of change orders. And you know what that means – project cost overruns.

What’s an engineer to do?

If you know exactly what you want, then you can write what we call a procedural specification that states exactly how you expect to accomplish your goals. Such a document is often loaded with lots of technical specifications for networks, timeouts, software, RTUs, PLCs, protocols, radios, etc. This will lock you into very narrow options. But if you’ve done your homework and know that this is the best way to go (i.e. no fear of change orders), then go for it.

But you may find that it’s best to write what we call a performance specification. The performance specification or request for proposal states exactly what you want to accomplish and asks vendors to propose ways to achieve those goals. You’ll get lots of ideas, and you may discover an approach worth considering that you would never have thought of otherwise. We have also found that taking this approach usually results in minimal (or no) change orders.

5. Decide what you want from your vendor before you start looking

Evaluating vendors and their responses to your questions should be a combination of art and science – a combination of corporate chemistry and bottom-line common sense.

Of course, cost is an easy factor to quantify. But it’s not so easy to compare less quantifiable factors like customer references and project methodology. It’s especially difficult calculating the effectiveness of a long-term relationship with the vendor.

But if your project is to succeed, those factors must be at the top of your list for consideration.

For example, if your project is large, you should consider examining each potential vendor’s project execution methodology. A documented project execution methodology can help ensure that all members of the team understand their role, understand company procedures, and understand the best way to accomplish major milestones.

How can you test that methodology short of actually hiring the vendor? First, ask each vendor staff member that you meet where they fit into the project lifecycle. Do they seem to act more like independent contractors or more like a team with a common sense of mission?

Next, talk to the vendor’s customers. Do their customers see tangible evidence that the vendor has a project execution plan? 

Does the vendor actually follow the plan, or is it just to impress prospects? Does the vendor provide written reports on a regular schedule? Are key vendor contacts available when needed? Can you talk to them and get straight answers? How is the after-project support? Go on site visits and see the installed systems first hand.

Similar questions can be applied to other intangible factors.

6. Decide what criteria will be used to judge the vendor and system

Very often we see very dense and complex vendor selection criteria. It seems that scoring bids will take a lot more work and time than it took to create the bid. You have to wonder how consistent scoring can be with such complex criteria. Most of it still boils down to a judgment call, and those judgments can’t possibly be consistent with so many criteria to consider.

If your selection criteria seems complex, then it’s probably not the fault of the selection criteria, but rather the specification and/or bid documents.

Make sure that all the information you ask from a vendor will be useful to you. Ask yourself how you plan to evaluate it, its significance to your goals, and whether or not it contributes any tangible value to your evaluation. You should also determine whether or not the information can be evaluated, and if so, whether or not you can easily and fairly compare vendor answers.

Source:-http://www.automation.com/library/articles-white-papers/general-automation-articles/six-decisions-you-must-get-right-before-upgrading-your-automation-system