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
PLCs can host a Web site on the internet or your company intranet. So
what’s that going to do for you? How about give you access to Real Time
Data and Data Logging for starters. Do you need a backup Human Machine
Interface (HMI) for a machine(s) or work cell? How about as a tool for
your Maintenance group? Did you know that with some PLCs you can store
documentation with the web server that lets you view machine drawings,
schematics, maintenance and operator manuals and short video clips?
They are all just a mouse click away with your web browser.
Using
a PLC with an internal relational database eliminates the weak link of
the communications from the PC to the PLC. A PC will usually perform
the database lookup faster than a PLC. However, moving the data from
the PC database across a serial network connection (usually limited to
19.2k baud) rate is much slower that a PLC that can retrieve usable
data in one scan of the control program.