OEM's and SI's

M

Thread Starter

Michael Brown

Ok, OEM's and SI's.

Has anyone found a successful approach for selling control systems to customers that believe they can do everything in-house cheaper?

Why do they think its cheaper? B/c they are using Visual Basic and do not have to pay for the runtime license for Wonderware, RSView, Intellution etc...

Don't get me wrong, I like VB - when it's the right tool for the job, but I do not believe it's the best tool for ALL jobs. In my experience most VB apps get 85% complete and never make it any further. Good enough, that's enough for now.

Any ideas?

Michael Brown
LESSCO
[email protected] <mailto:[email protected]>
 
2 things come to mind

Cost of development. How long to develop code in VB when it may consist of hundreds of windows or forms?

Cost of Ownership. You will always have to keep modifying code base with a programmer.

When it is a simple application that you own and keep verses buying a license it is a harder sell.

The another key is on large scale applications, how good is the communication?
Can large amounts of data be easily passed constantly?

Always a battle with custom, do it yourself ones.
 
VB is good. no doubt about it, BUT ONLY FOR pilot/test/'proof of concept' projects. Its a very good Rapid App Dev Tool.
BUT it doesnt stand a chance in front of C and C++.
All VB apps use some general purpose activex controls. These controls are good for general purpose desktop apps, but may not always be best suited for a control systems applications.

moreover, easy VB is specific to windows only. so the development efforts go waste... if you decide to switch to a better OS. ie *nix

A good approach towards selling can be this:

1. Tell them that the code base required for doing the said job can be huge. You have the expertise of maintaining large applications with proper source code control systems and bug management system. (Please also do what you say.
:)

2. Suggest them that they would be able to concentrate better on their process/business, if they leave the headache of control systems to third party.

3. Tell them that you/your team continuously train yourself in the ever evolving area of control systems. Its going to be difficult for a client to keep a tab on every recent tech development in control systems. VB is today, tomorrow they may need to update to somthing else. Their best guy may just decide to quit some day....etc

The idea is to suggest them that even if they can do it, its better to off load it to the specialists. somthing like, if you need a glass of milk, you don't start milking a cow. Even if you can!
 
S

Steve Myres, PE

> Don't get me wrong, I like VB - when it's the right tool for the job, but I
do not believe it's the best tool for ALL jobs. In my experience most VB apps
get 85% complete and never make it any further. Good enough, that's enough for
now.<

I think this very fact gives you a negotiating point. I think the applications never get finished in part BECAUSE they are done by an inside guy. Projects done offsite or by an outsider are less likely to get interrupted because "Old Bertha is down again and is spewing product on the floor". In my personal experience, I did a better job getting a project to 100% as a contractor than an inside guy for this reason.

Steve Myres, PE
Automation Solutions
[email protected]
 
J

James Ingraham

Let them win. Either they are right -- in which case why fight it? -- or they will realize that they're in over their heads and will then (hopefully) come back to you when they want it done right.

-James
Sage Automation, Inc.
 
B

Bob Peterson

The best sales approach is to let them do this for awhile and wait for the genius that programmed this stuff in VB to move on. Then wait for the inevitable mess of the stuff he left behind. Usually only takes a few months.

They will soon realize that the run time licenses and annual support fees are often worth the expense, particularly when Win version XX has to be replaced, or the PC dies and that hardware is no longer available, or new features need to be added, etc.

I agree with your 85% number. Its amazing how often sloppy, incomplete, and/or buggy in-house projects are just accepted.

I know of a OEM that went bankrupt a few years ago. To save money they used generic PCs (and I mean the cheapest things they could find) and VB to create their own HMIs. I'd be willing to bet the guy that did the programming on them was totally uninterested in fixing/updating/modifying them and the end users were in a world of hurt. I am tempted to suggest they kind of got what
they deserved. Cheap is almost never the answer, but bad (or desperate) managers never seem to learn.

Bob Peterson
 
C

Curt Wuollet

That's what you get for partnering with Microsoft. If you insist on making your living with tools that are "so simple anyone can use them", your customer is very likely to be that anyone. From the questions seen on the list, anyone who can run Windows believes they can do automation. In fact, this has always been the thrust of the Redmond crowd and the widespread appeal of Windows. The pitch is "we don't need any stinking experts" just a couple of clicks and you no longer depend on those Nazis in IS or automation engineers or especially consultants. Why, your secretary can point and click and run your mission critical database. And programmers? Why on earth do you need programmers when anybody can do "anything" in VB? And if those experts laugh hysterically at the notion, you just go around them and over their heads and sell directly to management. If you can get to the people with no contradictory knowledge, you've got it made. And endless repetition and the reenforcement provided by monopoly market share has made "the big lie" an indisputable truth. People actually get hostile if you try to counter that notion. And you have been happy to go along with the crowd on this one as long as the expertise they circumvent wasn't yours.

Now you want it both ways.

Only complete failure will give you an in. As long as the homebrew thing even kinda works, they will never accept that the notion is wrong. Most smaller companies are completely given to this thinking. Best bet is to go to larger companies where professional management sees through the ruse. Or if worse comes to worse, buy yourself an MCSE ticket and get on the gravy train. Knowledge and technical competance just aren't worth much in a dumbed down world.

Regards

cww
 
M

Michael R. Batchelor

The real truth is that from the plant's perspective - usually something like "Which alligator is going to bite me next" - the 85% really is "Good enough" and that's the bottom line. Good enough is good enough when it's their time and money that it costs to polish it up. Good enough *ISN'T* good enough when it's *YOUR* time and money that it takes to polish it up. And the number of plants with a bean counter in charge of the money who can see past next quarter, much less next year, is so small I think I've been in it once.

MB
--
Michael R. Batchelor - Industrial Informatics & Instrumentation, Inc.
Linux is like a wigwam...
No windows, no gates.
Apache inside.
 
>I know of a OEM that went bankrupt a few years ago. To save money they used
>generic PCs (and I mean the cheapest things they could find) and VB to create
>their own HMIs. I'd be willing to bet the guy that did the programming on
>them was totally uninterested in fixing/updating/modifying them and the end
>users were in a world of hurt. I am tempted to suggest they kind of got what
>they deserved. Cheap is almost never the answer, but bad (or desperate)
>managers never seem to learn.

Are you suggesting that just because someone chooses to use VB that they are going to write cheaply constructed programs and then not support their work. Programmers everywhere should be offended by this.

I have written some very nice VB programs that were well documented and I sure they could be supported. Even RSView and others use VB as their scripting language.

There are well designed systems and poorly designed systems. You cannot tell which is which by asking what language was used to write it in. I have generally preferred to use VB over an MMI package, not to save money because I probably spent more time in development. However you can learn VB on your own time for a very small investment ( < $200.00 US) You can also design a more flexible system and not struggle with the shortcomings and learning curve of the particular MMI package that you have chosen.

These statements are not limited to VB, they also apply to VC, C, Java, TCL....

IMHO,

Bill Sturm
 
One of the problems System Integrators have is that there hasn't been a commonly accepted method of distinguishing between good integrators,
wannabees, and people seriously in need of mental help. This allows the plant personnel to claim that "anybody can do system integration, all it is
is some programming, and I can do that!"

Recently, CSIA, the Control System Integrators Association, released two books (sold directly and sold through ISA Press) called "Selecting a Control System Integrator" and "Working With a Control System Integrator."

Those of you who are having difficulty with clients might want to start handing "Selecting" out to them when you call on them, pre-proposal.

In addition, CSIA provides a Registered Member program, which is a 7-axis full third party audit that several pharmaceutical companies have recognised as more stringent than a GAMP audit. National Instruments has entered into a partnership with CSIA, as has Control.com and ISA.

Basically, the cure for the common "I can do VB so we don't have to hire an integrator" is benchmarking what a system integrator is, and who ought to be calling themselves one.

Walt Boyes

---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"
http://www.netcom.com/~wboyes/SpitzerandBoyesAd.htm
[email protected]
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142
--------------------------------------------
 
C
And of course, the best way to compete might be if you lower the equipment and tools cost to where they don't mind paying for your expertise :^) That's the approach I favor for staying employed. The do it yourself approach has some very strong advantages even if the result is unprofessional and works only marginally. They understand it and can support it and can add to it or modify it without getting out the big checkbook. To a growing list of companies, that's worth more than the finest solution where they are totally dependent on outside people. If you add to that the embarrassingly high prices for
automation gear, it's a tough sell. In good times, people are more likely to say "just hire someone and get it done". In bad times, they
look very closely at what that costs and don't like what they see. It's a very good time to be offering lower cost alternatives.

Regards

cww
 
B
I did not mean to suggest (nor did I suggest) that the programs I commented on were poorly done in any way. My point was that the main tech support choice vanished when the OEM did.

The facts are that it is generally much easier to deal with a single system like WW/RSView/Fix, etc. rather then a conglomeration of what some guy at the OEM thinks is the ideal HMI environment. The end user then learns a single
environment that applies to every HMI/SCADA package he has, regardless of who the OEM is, and does not have to deal with the idiosyncrasies of the guys that wrote the code. Its bad enough learning to deal with the different conventions developers use (like color coding, descriptor names, etc.).

I readily acknowledge that using VB and some of the inexpensive tools and drivers now readily available can result in less expensive and maybe even "better" systems then what you can buy. The main issue for me (if I were an end user) would be how the heck do I support God knows how many different versions of things? Its the same reason plants tend to standardize on a single PLC family, even if in a specific instance a different PLC brand or family might be a "better" choice. The long term implications of support are such that the costs become astronomical to support additional brands/familys of PLCs, and even more so for HMI/SCADA packages.

Now you want to come in with something that has no defined structure at all? And don't tell me how great your documentation skills are. I guarantee they do not even come close to the documentation supplied by any of the commercial
suppliers. And even if your documentation was as good, would the next guy that supplied a similar (but totally different) system do as well?

After a few dozen of those type of systems in a plant, some SI will make a lot of money down the road converting them to some standardized way.

Bob Peterson
 
C
I'd have to agree with Bill on this one. I've seen incompetance at every price level. Using shrinkwrap software is no guarantee of a better system. People really do like to think so though. It's merely a sign of great marketing. And no software product can be better than what it's built on no matter what you do. I start with a stable OS. The hardware picture has to be managed for reliability. There are extremely cheap PC's that are also very reliable and there are some
very expensive ones that are not. Generally, as a class, they are very good regardless of cost. Seeing as they are, in most cases, all fed from the same offshore commodity stream, it's a matter of careful selection. A little fairly easy to do research is a far, far, better indicator of reliability than brand name or price. I like to find out what _is_ reliable and use that. Making the choices blindly and on the basis of marketing is what builds horror stories. My stuff has been
outperforming the packaged parts of the systems for reliability hands down and that's a fact. It's all in how you do it.

Regards

cww
 
> >I know of a OEM that went bankrupt a few years ago. To save money they
> >used generic PCs (and I mean the cheapest things they could find) and VB
> >to create their own HMIs.
...
> >Cheap is almost never the answer, but bad (or desperate) managers never
> >seem to learn.

Bill Sturm:
> Are you suggesting that just because someone chooses to use VB that they
> are going to write cheaply constructed programs and then not support
> their work. Programmers everywhere should be offended by this.

I think the suggestion is rather the other way around - that said OEM cut all the corners they could and then some, and that VB use was a symptom of this.

> However you can learn VB on your own time for a very small investment ( <
> $200.00 US)

You can learn VB for that, but not programming, certainly not in the timescale these books suggest. If they even mention programming at all.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
OTOH, VB use is often a resonable choice for small projects. I have not worked with many MMI packages, but what initially turned me off to all of them was their pricing structures. For a small project, it is simply not resonable to implement a large package.

Plus, has anyone looked at the scripting language in Wonderware, for example? It is crippling with it's small command set and other restrictions that are placed on the system programmer.

If the person doing the VB app is good at what they are doing, then it can be reasonable to think that it will handle what they need. I don't think that it is an automatic and foregone conclusion that if someone is using VB, then they are automatically unable to write it properly.

IIRC, the original poster was asking how to convince an end user to stop writing their own, and make the investment into a large scale package. I would suggest to that person that if they cannot find a suitable economic reason that is compelling to the end user, maybe they need to either re-evaluate the pricing of their current offerings to make them more compelling, or accept the fact that not everyone needs the pre-packaged
systems.

As for OEM's and SI's that roll their own systems, you get into a different situation. In that case, someone else is going to have to learn and maintain they system, account for compatibilty to other equipment, etc., and it may cost more in the long run.

However, when the end-user is doing the VB app, they can write in compatibility as needed to other equipment, and can create the level of
customization that isn't possible with large, general purpose packages.

Just my $.02,

--Joe Jansen
 
B
There seems to be a serious disconnect among those who want to "roll their own". Homemade PLCs, HMIs, SCADA systems, etc., may indeed have a lower upfront price. However, the long term and ongoing costs of these things are almost never discussed by the proponents of such things.

Someone who shall remain nameless, but who posts here regularly, claims he saves his customers a "lot" of money by doing his own thing in Linux. And tech support is only a phone call away (to him). The problem with this approach is that if he gets run over by a truck, there is no more tech support available at all. That was the real problem I was trying to get at in my original post, not that VB was good or bad.

With off the shelf items supplied by companys with a history of supporting their stuff, there is a support path. There is also a pool of qualified people available to service and support it. With the homebrew crowd, there is typically a guy working out of his basement. Who are you going to trust with your next $1 billion plant?

These systems do not go out in the world for a few months. They often run for many, many years. What happens to the end user when the homebrew control system dies 5-10 years down the road and the designer is no where to be found? Or the parts he used can no longer be procured?

Thats why smart plants rarely care about the upfront costs of the control system. Its usually such a small part of the overall cost of a system, that little bit of upfront savings is dwarfed by the long term costs, not the least of which is loss of production. A one hour outage in a car plant can easily cost them a $1 million worth of production. If they go down and can't
repair it quickly because the designer is not answering his cell phone right this second, you can bet that the control system will be out the door as fast as they can get it replaced.

Bob Peterson
 
Joe Jansen:
> OTOH, VB use is often a resonable choice for small projects.
...
> If the person doing the VB app is good at what they are doing, then it
> can be reasonable to think that it will handle what they need.

Definitely. It's just that many of the bad programmers use VB because it's marketed as being easy.

> As for OEM's and SI's that roll their own systems, you get into a
> different situation.
...
> However, when the end-user is doing the VB app, they can write in
> compatibility as needed to other equipment, and can create the level of
> customization that isn't possible with large, general purpose packages.

This is perhaps a reason for GPL or some similar licence, giving the end-user the same flexibility as they get with in-house VB.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Michael Griffin

I don't have any argument with what you have said, as far as it goes. I think you've over simplified the situation though. Often, custom systems are unavoidable. There simply isn't anything on the market that does what you need. In other cases you can buy a complete packaged solution off the shelf. In between is a large grey area of increasing customisation.
The examples of "VB" versus "Wonderware" applications are not poles apart, but rather both fall into this grey area. Both require programming or configuration to be used in a particular application. The amount of programming or configuration required for each will depend upon which one suits the application better.

Where custom or "grey area" systems are both often lacking is in documentation. Unfortunately, many consultants or system integrators seem to think that "documentation" means putting comments in their source code. They
seldom put themselves in the user's shoes to ask what the customer really needs to use a system, as opposed to what they themselves would need to
maintain it.
Writing a decent operating manual is a considerable amount of work, and usually gets short shrift at the end of a project. It can be easy to understand why a customer may be sceptical about the benefits of a system
integrator's services unless they show some tangible benefits. A nice "Wonderware" application which no-one but the integrator fully understands isn't really more than 85% complete either.

************************
Michael Griffin
London, Ont. Canada
************************
 
B
Bob Peterson wrote:
>Someone who shall remain nameless, but who posts here regularly, claims he
>saves his customers a "lot" of money by doing his own thing in Linux. And
>tech support is only a phone call away (to him). The problem with this
>approach is that if he gets run over by a truck, there is no more tech
>support available at all. That was the real problem I was trying to get
>at in my original post, not that VB was good or bad.

I would be happy to provide support for some one elses code, as long as the source is available. And from what I know about the person that your are referring to, I suspect that the source is indeed provided.

>With off the shelf items supplied by companys with a history of supporting
>their stuff, there is a support path. There is also a pool of qualified
>people available to service and support it. With the homebrew crowd, there
>is typically a guy working out of his basement. Who are you going to trust
>with your next $1 billion plant?

A person working out of his basement would be foolish to try to program a billion dollar project on his own. A robot or a CNC mill or... is within the scope of a one man integrator. I do suggest that complete source code is provided, however.

If a large company is comfortable using and supporting code written by a guy and his basement, then why not.

>These systems do not go out in the world for a few months. They often run
>for many, many years. What happens to the end user when the homebrew control
>system dies 5-10 years down the road and the designer is no where to be
>found? Or the parts he used can no longer be procured?

Again, if he has source, find someone else to hire or contract to maintain the code.

>Thats why smart plants rarely care about the upfront costs of the control
>system. Its usually such a small part of the overall cost of a system, that
>little bit of upfront savings is dwarfed by the long term costs, not the
>least of which is loss of production. A one hour outage in a car plant can
>easily cost them a $1 million worth of production. If they go down and can't
>repair it quickly because the designer is not answering his cell phone right
>this second, you can bet that the control system will be out the door as fast
>as they can get it replaced.

You point is not lost in all of this. Support is of the utmost importance when you sell software or hardware to a production environment. A person has to be careful not to sell something that they cannot support. Also, companies must not buy large systems from people who cannot show that they can support it.

Bill Sturm
 
Top