Risk Management

How do you manage something that doesn't exist?


How do you manage something that doesn't exist? Risk, for instance. I don't mean to say that risk doesn't exist, but I don't think it can be managed.

Risk can be defined as possibilities that can endanger something. Unforeseen wider angles and deeper meanings can get in the way of anything plan you start out with.

Personal and business risk come in many forms, as do certain decisions that can effect the day-to-day operations and successes of any endeavor. I recall I was so impressed by how Coca-Cola introduced "new" Coke, particularly given the fear on management's faces when it was unveiled. So, when it bombed, spin doctors took control, and Classic Coke was "introduced" to let the marketplace have its choice. Quite a recovery--like a 120 foot sand shot that ends up two feet from the cup.

Could they have managed the reaction? That's my point--they couldn't. However, they managed the consequences, and did the planning required to adjust when the risks came to life.

Automation project decisions are no different. I think I now better understand why computer-based control didn't make it and why IEC-61131 is having a tough time. I'm the PLCopen rep in North America for PLCopen, so I'm close to it.

It's all about risk. So is it reasonable to think that if the risks are unknown, status quo might be the best course of action?

I have been involved in a project that replaces IEC-61131-based equipment with better-known automation alternatives. Why? The user perceived more risk in keeping the lesser-supported solution compared with a more widely supported solution. Replacing it was an easier decision than fixing it.

The issue was clear to them: if it broke, and the original integrator wasn't available to help, then what do they do? That's hard to argue with. I could argue that the risk really is worth it, but the consequences of the risk becoming real were too great.

I'm involved in another project that is a bit larger. And to be clear, I work by myself. I have no engineering department, but I do have associates I work with when I need some help.

This project involved two other automation companies--each offered its own PLC solution and software. One company was a smaller machine builder with limited resources, and the other was a major material-handling vendor with vast resources.

So each of us designed and wrote control system software. Where does the risk lie? That question was asked, and the answers were very interesting.

The reason the question was asked was to try to manage the risk, or better said, to identify the risk and plan for it.

So, you tell me, why am I any more or less risk than the other two companies?

Well, it might be easy to see, but in conversations with all concerned it might not quite be all that clear.

The major premise of any PLC program and control system is that source code should be almost universally understood. True enough, but the one who writes it is the king. Twelve people will have 12 solutions for the same problem.

So, the small machine builder writes his code and has an 800 number for support. Well, with the number of machines out there, and the support people not being the code writers, the support guys are left to their own devices. Kind of like a Microsoft help-desk person who hasn't seen a line of code.

The big automation company had one guy write the code. They have 15 guys on staff, but most of the code is custom, so again, who ever wrote the code is king.

Then there's me. One guy, and I'm always king at my company.

The same platform exists--we all wrote code, and if any one of us got hit by the beer truck, the same problems would exist. The learning curve for anyone "taking over" any of our projects would be largely the same. Time is the only enemy.

But, maybe that's why the IEC code is being replaced with a better-known platform--the risk is considered more "manageable" with the better-known platform because the resources to combat the beer-truck scenario are more plentiful.

No one ever got fired for buying IBM. Unfortunately, it does make a bit more sense to me now.

E-mail Jeremy Pollard at jpollard@tsuonline.com

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments