integration headaches


Thread Starter

Jeffrey D. Brandt

This term was recently used by a contributor to the list.

As an employee of two different integrators for over 7 years, I'd like to respond, as to what causes these things.

First of all, this term might be used in relation to the perceived cost of assembling a control system. Rather than go on and on about what things cost, lets just say that the integrator is generally powerless to control the cost of ANYTHING in a control system. Customers and end users are making ALL the big decisions about the
really high cost components of a control system. The PLC, MMI, Inverters, and even operator interface devices (pushbuttons). At this point in the project, the words, "Can't we save a little money by substituting components?" ring a
little weak.

Another reference to the subject term might be those things in a project that cause the end result to be less than successful. The cause of these things can usually be traced,
('blamesmanship'), and, sadly, the best guy to blame is the guy who is not in the meeting. Integrators become the whipping boys for poorly executed projects, sometimes out of political

Finally, the mentioned headaches are sometimes self-inflicted. When an integrator says "In my experience...", he's actually applying the knowledge that caused the end user to go to
him in the first place. Instead of a listening ear, this phrase is generally answered with a string of things that, to us integrators, sound a little self-serving. Believe it on not,
regardless of how much time you've wasted generating a stack of programming directions for us, at the end of the day, 1 + 1 still equals 2. The rules of physics are not suspended in your plant, just because you want them to be.

We (integrators) may not be experts at the process of doing whatever processing the end user is doing, but one thing we sure do know is that TTL is different from mADC. Please understand
that when you say "All <whatevers> should be made by <however>", that you are limiting the technology used to solve your problems, and the solution will be limited to the capability of the best-of-breed within the family of 'things' YOU'VE specified.

Finally, we have to talk about time. When drawings take 2 weeks to get approved, whose time just got used up? That's right

I know these words will fall on deaf ears, and also find others cheering. Regardless, until something DOES change, the integrators will ALWAYS be the bad guys. ('Last one to touch it wins')

Jeffrey D. Brandt
[email protected]


You are sounding a little cynical, albeit - perhaps justifiably so. One of the many things I learned when working for an integrator before
launching off on my own is that in the end, the customers really do want the system to work well - despite the fact that they unwittingly throw
all manner of obstacles in the path along the way. Getting input from everyone from the operators to the bean counters provides a much better vantage point from which to design the system and avoid some of the problems that you mention.

While I have not been known for tact and diplomacy and this has had some negative marketing impacts, I think the projects that we have been involved in have been for the most part successful because we are pragmatic (nice word) and align ourselves with the facts and let
everyone know clearly what is going to happen if certain (un-enlightened or just plain dumb) decisions are followed through on. If this does not convince the customer to keep from driving off the cliff, we kindly step aside and do not submit a proposal. We have been around long enough now to see that this approach usually pays off within a year or two after declining to bid.

An earlier forum topic along these lines parallels your comment about buying all items in the system from company X. We tend to walk away
from customers with this attitude when we see that company X does not have the product to do the application robustly. I am reviewing our
third proposal for an application now that was done by one of the largest automation suppliers own integration group. Quite simply, they
screwed up and they do not have a product that is suitable for the application. The customer's corporate engineering management is still
pounding on them to "make it happen" while the corporate bean counters are having fits because the production line is hemorrhaging money when
prior to the retrofit it was a profitable line. We are standing by to answer the call because we know that eventually, the costs associated with poor performance will become the hammer that smashes the mandate for a "100% company X solution" This will fall into the one to two year
envelope since we walked away from the 100% company X RFP. This echoes similar situations in two other companies that we work with.

The bottom line is that integrators who recognize the problems and point them out to the customer prior to being awarded the contract can avoid
the pitfalls you identify. I realize this can be tough when you are hungry for work and you don't know the application 100% and the vendor has told you that product X can do it easily . . . And, once the contract is secured, you need to be diligent in following through with sound engineering decisions and document, document, document. If part of the customer organization (rarely is it the customer as a whole) is bent on playing CYA and pointing fingers, make sure they will have to deal with real documented evidence as to why things failed to go as planned.

Hope this gives the list some useful feedback from another "Integrator"

Best Regards,

Ken Brown
Applied Motion Systems, Inc.

Michael Griffin

At 10:53 17/10/00 -0400, Jeffrey D. Brandt wrote:
>Customers and end users are making ALL the big decisions about the
>really high cost components of a control system. The
>PLC, MMI, Inverters, and even operator interface devices
>(pushbuttons). At this point in the project, the words, "Can't
>we save a little money by substituting components?" ring a
>little weak.

A customer should be specifying all the typical, common, important components such as PLC, MMI, relays, sensors, push buttons, etc. They have to stock spare parts, and they can't afford to stock everything that everyone in the world has ever made on the off chance that they will need it some day. The automation suppliers and distributors are cutting their inventories, and it can now sometimes take weeks (or months in some cases) to get a spare part delivered when you actually need it in minutes. By the time the part arrives from the manufacturer, you can be already out of business.

"Substituting components" is seldom done as a genuine cost saving. It is often just a way of burying capital costs in the maintenance budget. If I have to buy 2 MMI panels (one to install, and one spare because the first one is the only one of its model in the plant) to "save" 10 percent on the one that is installed, there wasn't any money saved except in someone's

If a customer finds themselves regularly saving money (genuine savings, not imaginary ones) by substituting components, then they ought to consider changing their specifications to favour the "substitute" items. They would seem to be the ones they are actually using anyway. Simple specifications can cover all components in 95% of applications, and most of the components on the remaining ones.

Any useful pre-approved material list should always contain a statement to the effect that the machine builder is responsible for
selecting components that suit the application, and that any deviations from the pre-approved list should be discussed with the (customer's) engineering staff. This should cover situations where unique devices are required to meet the performance requirements. The point of the pre-approved material list should be that anything on the list is automatically approved if it is
suited to the application, anything else should be subject to discussion.

>Believe it on not,
>regardless of how much time you've wasted generating
>a stack of programming directions for us, at the end of the
>day, 1 + 1 still equals 2. The rules of physics are not suspended
>in your plant, just because you want them to be.

Customer equipment specifications often arise as a result of previous bad experiences. Keep in mind that everyone learns from their
mistakes. The difference between the machine builder and the customer is that the machine builder leaves his mistakes behind him, while the customer has to live with them forever. This makes the customer anxious to see that particular mistake is not repeated.
The big problem in writing equipment specifications is that it is hard to turn a list of things you never want to see happen again into a comprehensive document. A useful spec has to be specific enough to get your intent across without being more specific than you really meant it to be.
Some specifications grow to enormous size for the same reason some software programs grow in size. If there is a problem with it, the
temptation is to "improve" it by adding on to it. This of course tends to introduce more problems which need additional "fixes", and the cycle continues.

>We (integrators) may not be experts at the process of doing
>whatever processing the end user is doing, but one thing we sure
>do know is that TTL is different from mADC. Please understand
>that when you say "All <whatevers> should be made by <however>",
>that you are limiting the technology used to solve your problems,
>and the solution will be limited to the capability of the best-of-breed
>within the family of 'things' YOU'VE specified.

Keep in mind though that while you may be an expert at building machines in general, your customer probably has a lot more experience in his
particular application area. He has seen your competitors both succeed and fail on other similar projects in the past. Be ready to learn from the mistakes of other people as well as your own. As for material selection, see the above.

>Finally, we have to talk about time. When drawings take 2 weeks to
>get approved, whose time just got used up? That's right

Time for drawing approval should be scheduled into the project time line. Keep in mind that the customer has your project plus probably a dozen others with other companies that you don't know anything about and a full day's work on other problems besides. He's probably got these other companies demanding that he put *your* project aside to work on *their* project.
The biggest problem with scheduling work load is when a project contains a single vague unknown chunk between "P.O." and "run-off". Design
reviews need to be scheduled in, not dropped on someone as a surprise.
Also, being asked to "review" drawings when nobody has figured out yet how the machine is going to work (or if they know, they're not telling anyone) is a waste of time. The customer spends days reverse engineering the machine from the drawings and isn't able to find many potential problems since he has to guess at what some of the details of the machine function are. Review of schematics should take place in conjunction with the review of the functional description (which everyone writes down, don't they?). One fellow I have done business with likes to say that "some people never seem to have time to do things right, but they always seem to have time to do it over".

Michael Griffin
London, Ont. Canada
[email protected]

Curt Wuollet

Hi Jeff

This is where the whole single source proprietary model really sucks. The customer takes two existing systems and says " I want you to
integrate these". They may be from competing vendors. In our case they may very well be machines that were never intended to be run
automatically, let alone integrated into a cell. The amazing part is that the latter case is actually easier than where the systems are from competing automation vendors. At least then you only have one set of roadblocks to overcome. All the solutions offered involve replacing one vendors gear or the other. This is not what the customer wants to hear. They invariably ask why the systems won't talk to each other, they invariably are very skeptical of the answer. Telling them that they don't talk to each other simply because the vendors don't want them to talk to each other never quite shifts the blame to
them, there's always that suspicion that you are just selling equipment. And if you do endeavor to make them talk to each other, then the time
spent becomes a big issue. And the vendors and even well meaning people ask "Why don't you just use brandX" which has nothing to do with the problem.
Integrating systems is way more difficult than it needs to be because of this petty yet absolute refusal to support each other's stuff or in
many cases, like CNC, to support any reasonable means of communication at all. This falls heavily on integrators that do "old work" where you can't pick and choose what you work with.
You lose a lot of opportunities when you have to quote more hours for getting things to work together than for solving the original problem.
And no one hears this, they simply pretend it's not a problem or offer to sell you all new stuff, and the customer be damned. Even when it's
_their_ stuff that won't all work together.


Curt Wuollet

Jeffrey D. Brandt

After reading a few responses, its clear that there are present on this board, the two classical types of systems integrator experiences. As such, there appear to be some
differences of opinion, because each of us think we're all talking about the same type of S.I.

Low prices, simple quotes, gets lots of work (one project at a time) stuff eventually works.
His guys are 'really good with this PLC stuff', and the reason the end users know this is that they ask him to do all kinds of stuff with the machine, while he's 'fine tuning' it in the
field during the (extended) startup. Nightmares during startup are usually the omissions of others, that, of course, this integration knew about long ago, but, since it wasn't in his
scope, failed to tell anybody.

Prices not always the lowest (to start), quotes point out all the errors and omissions that the spec writer made, including specifying obsolete parts and out-dated specifications. Has
a core group of loyal customers. Believes in simulation, and writes down details, even when others don't. End users don't know of his people's abilities, because they never meet them.

P.S. I've worked for both types. Each has its place out there, determined, of course, by the all-powerful project accountant.

Jeffrey D. Brandt
[email protected]