Teamwork for System Development

To get the most out of your relationship with your system integrator, whether a third-party integrator or a team within your organization, you first must prepare carefully, then communicate frequently—but not too frequently.

Preparation starts with knowing your goals, and that’s not as easy as it sounds. Roger Richardson, president of Delta Sigma Corp., a manufacturing-system developer for clients in the aerospace industry, points out: “Business owners know their process better than we can ever know it. They know the things that are hard and the things that are easy, and the things that we wouldn’t know to watch out for. What they don’t know is how to do it in an automated fashion.”

“Unfortunately, over the past 30 years there’s been a change in the environment at client companies,” says Randy Jennings, vice president of business development at manufacturing, warehousing, and distribution system integrator Transbotics Corp. “It appears that a whole layer of management and engineering is now missing in American industry. They have needs; they have wants; they have desires, but they don’t have the staff to clearly define what they want.”

Project planning necessarily progresses in a top-down fashion. That is, you start defining the overall architecture—the general picture—then progress to finer and finer detail. Implementation, however, proceeds from the bottom-up: you write code modules and buy or build hardware components first, then integrate them into a completed system. If you haven’t defined details before you start working on implementation, you’ll end up reworking just about everything, doing several times as much work as you would have if you knew what you were doing in the first place. More accurately, your system integrator will end up doing several times as much work!

Communicate frequently—but not too much

Bob Hamburger, business development manager at data acquisition and control system integrator Bloomy Controls says, “We find a lot of the things that end up being time-robbers are user interface details in the software. One of the things our experienced engineers ask right up front is, ‘Do you have any preference for the kind of user look and feel for the user interface.’”

Hamburger points out that projects get into trouble when an engineer is working onsite with a customer, and the customer says something like, “That looks nice, but can you make that green instead of blue?”

“It’s like the death of 1,000 cuts,” he says. “Every little thing that they’re asking for is minor—almost insignificant, but the end at of the day, you spent more time on additions and modifications than on what was in the contract.”

That’s where communicating frequently—but not too frequently—comes in. You, as client, have to communicate well enough to make sure the system integrator always has all needed information. On the other hand, you must leave them alone to do their work.

The trick, says Hamburger, is frequent but not too frequent design reviews, as well as answering some open-ended questions at the beginning of a project regarding style, HMI look and feel, appearance—“the kind of things that the customer will end up nitpicking.”

The frequency and timing of design reviews depends on the project’s scope and complexity. Often, a weekly or even monthly progress report by the integrator quantifying progress (using pre-agreed-on metrics), along with bilateral meetings timed to coincide with project milestones (again, pre-agreed-on) is enough. Reviews probably should be more frequent during the initiation and design phases, and less frequent during the fabrication and development-test phases. There should always be at least one meeting to review results of acceptance tests. Of course, all parties should feel free to make contact on the spur of the moment should something significant come up. The thing to avoid is making those contacts for less-than-significant issues. The background color of an HMI screen, for example, is not worth an interruption.

To automate, or not to automate

Automation is not a panacea. Some tasks are ripe for automation, and others are better left manual. In some quarters, robotics integrators look for tasks that fit one of the “Three Ds” criteria: dull, dirty, or dangerous. Those criteria, however, don’t work well in a factory setting. Jennings prefers to look at how repetitive the task is: “You have to be able to recognize and identify repetitive motions. The best teacher for automation is what a human does. If you see a human doing something with repetitive motion, most likely you can automate that function.”

Highly complex tasks that require a lot of flexibility and decision making, however, are poor choices for automation. “You also have to identify areas that don’t require continuous decision-making,” Jenning points out. “If it’s tough to do manually, it’s not going to be a very good automated solution either.”

Gary Cash, vice president of products and marketing for distribution system vendor FKI Logistex, points out that while accuracy goes up when you automate, that is not usually why companies start automation projects. “A warehouse starts out manual when a company is small,” he says. “They automate when they find they can’t hire enough people, or fit them in the building without bumping into each other. When you need to up throughput, you start to automate. Some areas you automate earlier than others. Your shipping operation, for example, tends to go early.”

Do your homework first

Before even thinking about teaming up with a system integrator, do your project homework.

“Understand what your needs are,” Jennings says. ”You don’t have to define solutions, but you do need to understand your own needs–not your wants and wishes, but what your needs are.”

Once your needs are defined, the integrator can find ways to assist you in the best manner possible. Document the things that would be of benefit and value to you.

The system integrator needs to know where raw goods come from, what kind of output you have, what’s the anticipated maximum production rate, how much inventory, what’s the lead time to a customer, and the order life cycle. Naturally one of the things you need to know is how you transfer products from one process to another. “We try to optimize the movement so it arrives just in time to minimize in-process inventory,” Jennings says. “So, one of the biggest things is what does the facility look like? What have you allowed for in this facility?”

The first thing Bloomy’s Hamburger tries to do during the initial contact with a customer is put together a good statement of what the problem is. What is the client trying to accomplish? What are they trying to automate? What are they trying to measure? From the basic problem statement, he tries to define the different aspects of the system. What type of sensors will they use? What types of actuators? How many channels of each type of physical parameter are they looking at?

“Since what we do is fundamentally data acquisition and control,” he says, “the starting point is a channel inventory. How many analog inputs and outputs will be needed, and how do they relate to the device being tested or the process being automated?

“We’ll put down on paper our understanding of the problem, and at least a conceptual description of the solution, including what type of hardware we recommend and how the systems might be architected,” Hamburger adds.

The result is a rough first draft of the manpower requirements and a project schedule. Usually at that point there’s a little bit of iteration before integrator and customer come up with a final proposal and problem statement. “We try to limit the amount of upfront engineering work to what we need to mitigate the risk until we feel confident that we can do what we’re proposing,” Hamburger says. “If the problem is of sufficient complexity, we’ll probably propose a multi-stage development effort where the first phase of the project will be project definition.”

FKI’s Gary Cash says, “We’ll need to understand your business in order to help you. So you need to tell us how your business runs, and we’ll figure out how to make the building work: how to design it; how to lay it out; how to make things do what you need.”

Future goals are important, too. By the time your integrator finishes the project a year down the road, you don’t want you to have already outgrown the facility. Consider what your volume will be in 2010 and if it makes sense to allow for expansion past that.

Another big networking question is whether a piece of manufacturing equipment under development is tied to the corporate IT network, or is it on its own separate network. “There’s a dividing line between networking in the classical sense that the information technology folks talk about,” says Hamburger, “and a network inside a facility.”

If the system you’re developing is tied into the corporate IT system, then the integrator must address IT policies on security, access control, virus protection, and any other area where requirements can differ. Most industrial computers sit behind a firewall where they can’t be seen easily from the outside world. If you want to run a Web server, however, wider access may be possible or required.

“Probably 75% of the Web-enabled interfaces that we’ve done,” Hamburger reports, “are on an intranet. They will only be accessed by people behind the firewall. The other 25% requires us to work with the client’s IT people and get them to punch a hole in their firewall, or put a dedicated server on their network. It’s actually pretty easy to set up a hardware firewall with an inexpensive router to protect a Web server from malicious attacks.”

Non-disclosure agreement

Whenever you contract with a third party to do anything, intellectual property (IP) issues rear their ugly heads. “Typically, the first moment that the customer needs to convey what they feel is proprietary information, the non-disclosure agreement (NDA) comes out, even before the first meeting” Bloomy’s Hamburger says.

“Customers tend to think that their information is a lot more unique and a lot more individual than what we see most of the time,” he continues. “A lot of times what they think is a wonderful proprietary trade secret is actually common knowledge; their doors are closed, so they can’t see what the guy next door is doing.”

Delta Sigma’s aerospace clients are extremely sensitive to IP issues. The company has an unusual relationship with his largest client in that they have worked so closely for so long that sometimes the company approaches Richardson with an idea for an automation project, and sometimes it’s the other way around. Richardson insists the contract spell out IP issues, especially who owns the design at completion.

Working in the aerospace industry, Richardson has a lot of experience writing and signing NDAs. “About two weeks ago,” he recalls, “a potential client sent me his NDA, and I sent back an email that said, ‘I’m not going sign that!’ I sent him my standard form NDA, and he responded with: ‘That’s the best-written NDA I have ever seen.’”

Richardson’s NDA is good because it is completely bilateral. Rather than differentiating between buyer and seller, his form talks about the source and recipient of the data. There’s nothing that makes it more in favor of one party or the other. Many IP lawyers try to push NDAs that favor their clients’ interests at the expense of the other party. That is counterproductive because a highly competent and experienced development partner—the kind you want on your team—won’t sign it. An NDA, like any other contract, is useless unless both parties agree to and abide by it.

Agree on acceptance tests

At the end of the day, your system integrator will present what everyone hopes is the ultimate answer to your dreams. The only way to know if it really is, however, is to test it. You’ll need an acceptance test, and the only way to avoid disappointment is to agree on acceptance criteria as part of the initial contract.

Contract-based acceptance test details provide a blueprint for designing the test and help define project specifications. A wise integrator will design the system to pass the test. Exceeding the test criteria is overkill and a waste of resources. Not meeting the criteria is a failure.

“Typically we will include a section on system acceptance criteria as part of the proposal,” Hamburger says. “You can’t know when you’re done unless you’ve agreed beforehand on what the end conditions are.”

Make sure that the acceptance test includes operating on a sufficiently large set of product units that you supply. The set should include both good and bad units, to demonstrate how the system will react to anything it is likely to see in service. That goes for manufacturing, assembly and distribution systems as well as test systems. If your process drifts so that, for example, out-of-tolerance machined parts arrive at an assembly station, you don’t want the assembler to break down catastrophically. You want to know that the process will fail safely before accepting the equipment.

Follow up

“Another thing that comes to mind is service,” Delta Sigma’s Richardson says. “If you purchase something from somebody that is far away, what’s the probability that [they can] come to your place [in an emergency]?”

Hamburger points out that: “After acceptance, it’s not unusual for the customer to find either additional features that they want or to uncover bugs that weren’t uncovered during final testing, commissioning, and system acceptance.”

“We provide full support for all of our systems,” says FKI Logistex’ Gary Cash, “but most people tend to do most of the maintenance themselves. So we provide product manuals, whether they’re for our own products or products of third-party vendors [incorporated into the system].”

If you don’t have the in-house talent to maintain the system, you may have to rely on the system integrator to service and repair it. Ensure the contract defines maintenance and repair responsibilities. Whether you take responsibility, the system integrator takes responsibility, or you work with a third party, spell it out along with specifying whatever support documentation (e.g., service manuals, schematics) will be needed.

Author Information

C.G. Masi is Control Engineering senior editor covering discrete control. Reach him at charlie.masi@reedbusiness.com

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.