Roadblocks to Successful Collaborative Manufacturing

Nov. 30, 2011
Following a list of best practices for cross-geography collaboration can be a difficult pursuit and one whose end result may not be a good fit for many circumstances. However, engineers and operations managers with years of collaborative manufacturing experience are eager to share their knowledge about collaboration problems that can easily be avoided.

Manufacturers of all sizes increasingly find themselves either leading a global business or functioning as a small cog in another company’s worldwide operation. As a result, collaboration across time zones has become a core facet of production operations. It’s no longer a question of whether engineers and operators will need to collaborate for success, but how they will collaborate and when.

With collaboration so ubiquitous, numerous technologies have grown up around this business process. Most provide a positive boost for intra- and inter-company collaborative efforts in terms of ease of communication, ability to work on single documents from multiple locations, and cost savings on travel, just to name a few of the most obvious benefits.

However, when speaking with engineers about their cross-geography collaboration experience, it’s clear that the collaborative process, even with the aid of technology, is far from perfect — or even precise. The ever-changing nature of company affiliations, personalities and regional economies will always see to that.

Avoiding the four most common collaborative manufacturing missteps will go a long way toward ensuring the success of your current and future collaborative efforts.

1. Lack of Perspective

Setting the business context for a cross-geography collaboration effort needs to be viewed as step 0 for any collaborative effort, as it needs to take place before any other steps commence.

“The biggest mistake most companies make is in it not looking at collaborative manufacturing as an enterprise issue,” says Rob Gellings, P.E.,
senior vice president of enterprise integration with system integrator company Maverick Technologies, Columbia, Ill.. “They let each facility go off and do their own thing and wind up with something that can’t be leveraged for any other purpose. True collaboration really begins with developing that corporate team with representatives from each area.”

As a corporate enterprise concern, true collaboration is something that has to be constantly monitored and maintained with strict change procedures and by people with a good understanding of the overall requirements. It’s not an automated, software-driven application that runs itself requiring you to check the dashboard on occasion. Marc Leroux, collaborative production manager at automation systems vendor ABB, Columbus, Ohio, says that he sees this set-it-and-leave-it approach employed more often than not.

“Collaboration is a tactical engineering tool for maintenance and operations,” Leroux says. “You have to understand the scope of what you’re trying to achieve, but this is typically not done in practice.”

2. Unclear Business Definitions

Once the groundwork for successful collaboration is set by placing the proper perspective on the project, the next step is to identify what’s driving the collaborative effort and why.

“This sounds simple, but these drivers will dictate how the collaboration will actually work,” says Steve Bashada, vice president of TeamCenter Applications for Siemens PLM, Cincinnati, Ohio. “Most companies don’t go through the process of examining these drivers by exploring basic issues such as: Is this a joint venture? Is it an OEM [original equipment manufacturer] supply chain collaboration? Is this the result of a merger?”

Such simple project framework questions are simply not asked all that often. But, Bashada says, you have to understand these issues upfront because they are going to affect the lifecycle of the collaboration. “The lifecycle might mean that today’s joint venture could dissolve in 18 months, then come the questions of where’s the data, how will it get taken down, who controls the IDs, security, etc. People often think through all the setup points, but not how to take it in the other direction when it’s over,” he says.

Though this type of problem is more common with inter-company collaborations, it can happen within companies too, Bashada says. For example, when manufacturing in one country moves to another facility in another geography or, say, if there’s a new design center established in Korea.  “It happens all the time at OEMs and with their supply chain peers,” he says.

3. Technology Landmines

This aspect of collaborative manufacturing contains multiple areas where missteps commonly occur. Since they all fit under the software/technology umbrella, I’ll list them all here for easy reference.

Be careful about what you as for. “Don’t ask a software supplier if their product can do ‘x’ because the answer is always ‘yes’,” says Gellings of Maverick Technologies. “Too many companies don’t drive software implementations based on business objectives; instead they get enamored with the technology and not how it supports the business issue at stake.”

As a corollary to this point, Bashada adds that there is often the mistake of developing your collaborative data architecture around a specific business demand rather than the dictates of the data architecture. The problem with this is that the technology used to collaborate is then not capable of expansion when needed.  In such cases, the data architectures just “grow along with the companies without a strategy for them,” Bashada says. “So what you typically end up with is 40+ instances of collaboration databases (a different database to go along with a different instance of software installation) that need to be synchronized.”

Don’t get enamored with technology. “Software suppliers tend to leapfrog each other every few years,” says Gellings. “So think about collaboration from the perspective that the software used will likely still be in pace for the next 10 years. Within 12 months, however, it won’t be the latest and greatest piece of technology available. Make sure it can address the current and foreseen business issues you need to address.”

Avoid incorrect partitioning of data in your software applications. Gellings notes that he has seen users place data in proprietary plant systems that should be in their enterprise resource planning (ERP) system from a collaborative demand planning and scheduling viewpoint. “I have also seen people put batch management systems for product/bin selection in their ERP (enterprise resource planning) system, which means that they then have to go into the ERP system to make those basic inventory control decisions,” he adds.

Latency. This all comes down to how long it takes a file of a certain size to travel over a given distance, for example, from the United States to India. “This is a big issue with Japan now because they’re doing offshoring and centralization due to areas being affected by the tsunami,” says Bashada. Bottom line: The size and capability of your communication links can be a big issue that affects performance at remote global locations.

Sharing. It’s generally understood that basic business agreements make it OK for just about everyone involved with the project to share certain pieces of information like computer-aided design (CAD) files. But what about more sensitive project data? “You have to have a strategy around what will be shared and what won’t be shared,” Bashada says. “PLM (product lifecycle management) is still new to most manufacturers and the granularity of data available is huge, so this is something that needs to be thought through.”

Access and security. When you’re dealing with production collaboration, it’s hard to predict up front what kind of access remote experts will need in cases like abnormal situation management, notes ABB’s Leroux.  “With the growing emphasis around the need for industrial system security, this is the largest issue we now face,” he says. “Network access strategy needs to be part of your collaborative system plan. You have to consider how you will develop an infrastructure that allows multiple vendors to have access to their own systems in a facility, but not access to other systems, while still maintaining a degree of access that allows them to assess infrastructure issues.”

Upgrades. They’re a fact of life in the software, so you must plan for them—even though too many companies don’t bother and then have to deal with the headaches later. When it comes to planning for upgrades as part of your collaboration strategy, Bashada says it’s important to realize that the actual upgrading process typically takes three weekends to complete and that companies should plan and test for this up to a year in advance. “During the three week roll out, some sites will be on new software, while some are on the old platform.

“Then there’s performance, user training, testing/validation and maintenance,” says Bashada. “These are all areas where I’ve seen people run aground. There are best practices for software upgrades, but if a company decides to cut corners and not follow all those best practices, that’s where it can get scary.”

4. People and Politics

People and politics—aren’t these two issues the root cause of every problem? Of course they are, but there are specific people and political issues that undermine successful collaborative manufacturing efforts. And like the plethora of technology issues above, the various human and cultural issues that represent common collaborative manufacturing mistakes are listed below.

Language. This one’s about as obvious as it gets, yet it still often goes unaddressed as part of the core strategy for cross-geography collaborative manufacturing. “In conversational speaking, misinterpretation generally does not have the same consequences as when the topic is of a technical nature,” says Eric Gilbert, senior control systems engineer at automation systems vendor Optimation, Rush, N.Y. “The frequent use of jargon can make it very difficult to translate technical information properly.  Hired translators should have the technical knowledge that allows them to not only translate the words, but get the idea across as well.”

“We have found that if an individual in a non-English-speaking country says ‘yes,’ it might only mean that he hears you, not that he understands you,” says Dale Reynolds, systems engineer and electrical group manager at Optimation. “This makes it harder to communicate the technical aspects of the job, because you’re not sure if there is a true understanding of these details.

To mitigate this issue, Gilbert advises having at least one person on the opposite team speak the same language as you do.  “That way, they will have a foundation in the basic concepts and it will minimize the number of translations necessary to get the correct information,” he says.

Skilled labor. Be aware that skilled workers that interact well with your team may be difficult to come by, says Gilbert. “Ensure that you understand how well the required skill sets for an individual matches their actual abilities,” he says.

Cultural differences. People in other cultures may have different motivations when placed in difficult situations in the workplace.  For example, it may be very important to avoid shame and ‘save face’,” says Gilbert. “In such cases, we don’t put a person or team on the spot; we deal with it offline.”

Attitude toward the chain of command is one of the many cultural differences encountered in cross-geography collaboration that companies often fail to appreciate fully. “Titles and a company’s organizational structure can be very important in some cultures,” says Gilbert. “Dealing with this adds time to purchasing, engineering, and basically anything that might need approval.  Therefore, we factor in the additional time to avoid major disruptions in our schedule and project process.”

SIDEBAR: Read "The Problem with Peer-to-Peer" from December 2011 Automation World:

David Greenfield, [email protected], is Media & Events Director of Automation World.

For additional information:
Maverick Technologies
Siemens PLM

Companies in this Article