Cross the PLM Culture vs. Technology Divide

Product lifecycle management (PLM) solutions do more than just streamline data management. When properly deployed, they fundamentally change the way in which multiple departments engage with product data, both in terms of creating new data and accessing existing data.

That’s why many companies find themselves facing operational and employee acceptance challenges, rather than integration problems, when they tackle PLM projects.

“The major hurdle to adopting a PLM solution is not technological, it’s on the business process side,” says Bill Lewis, director of product marketing at Siemens PLM Software. “There’s a lot of work that goes into determining what business process should be going forward, and what it will look like.”

The key to overcoming those business process challenges lies with employees across multiple departments. Some will embrace PLM enthusiastically; some grudgingly adapt because they value their jobs. Others simply take an over-my-dead-body position.

“The big win comes when you get those people who are averse to change to finally see the light and have an epiphany about the value of the solution,” notes Todd Cummings, VP of research and development at Synergis Software.

But supporting data management is different than supporting a CAD solution. PLM systems are inter-related, multi-user and multi-department solutions that require employees to think beyond the confines of their own department or work process.

For the Greater Good

Companies are often surprised at the interconnectedness of their data, and how changes in one department can have far-reaching effects in areas of the company they weren’t even considering as part of a data management project. “The plan has to be agnostic, and has to be about the greater good,” Cummings says. “We have to follow every thread to its logical conclusion. There’s an awareness-raising component to this that’s part of the fun of what we do.”

For example, design and manufacturing documents are often used by the marketing department well in advance of an actual product launch. Changes in the specs can also affect things like packaging, product shipping rates, pricing, materials sourcing and other areas that are not necessarily on the radar of most design engineers.

“Engineering groups often don’t understand the whole suite of activities that go on—which take almost as long as the development cycle—that need to happen before you can make money on a product,” says John Kelley, VP, product value chain strategy at Oracle. “Other groups are thrilled once they see how this works. Operational folks, costing, quality, sourcing or supply chain readiness—they are thrilled to have access to this data earlier than they’ve ever had it.”

Engineering groups can, in fact, present a major obstacle if they are reluctant to share design data early and often. “There are still engineering folks who want to work in isolation because they don’t want to expose what they are working on until the very end,” Kelley notes. “But we see those situations less and less.”

Other departments may balk at new or unfamiliar processes. “It’s relatively easy to explain the company-wide benefits of PLM,” says Kevin Eustace, senior VP of product driven services at Siemens. “But when you get to the department level, one department may be asked to do more than another, and you have to make the shift in importance clear in order to incentivize that department to embrace the work. You have to communicate the value.”

Cummings agrees. “When you turn the key on these systems, it’s a different world,” he adds. “People have to work differently after the system goes live.”

A 360° View

According to Cummings, the key to preventing employee resistance from undermining a PLM deployment is to engage every department during the planning stage. Engage a project team that can provide a complete view of the company and the product data, including members from the IT and user communities.

“The team should be made up of people who don’t just have a title, but actually have some operational interaction with employees, who are respected and listened to, and who are willing to listen to the user base,” he continues. “That’s different than a top-down mandate with no explanation.”

Address employee concerns about the solution as early as possible in the process, and emphasize the benefits. “Everyone has to be on the same page,” Eustace says. “You have to make it clear that the solution will make you more competitive. And understand that when you tell people this will make you more efficient and productive, they start to wonder about layoffs. You have to address all of that up front if you want support for the project.”

Another wrinkle in some organizations is that some functions (marketing, manufacturing or even product development) may be outsourced to third-party companies. Now the challenge becomes not just getting the internal team onboard, but also convincing the partner and their employees to get behind the initiative. You can’t integrate data from multiple sources without considering the environment in which you’re doing it—with heterogeneous corporate cultures.

“Companies that outsource strategically develop partner agreements that include a set of terms around data access,” Kelley points out. “You need a strong supplier management group to negotiate those contracts, and ensure there is visibility.”

Strong, engaged executive sponsorship at the VP level or higher is also key. That high-level support can help motivate reluctant managers, and provide assistance in cutting through red tape during the project.

Explain the Value

Developing a comprehensive project plan is also important for user acceptance. Assess the full scope of the project before presenting the plan to the company. If the baseline keeps shifting, or project goals change frequently, it will be harder to keep stakeholders engaged. It will eventually erode trust in the project.

Clearly define who owns the project, what data will be managed and for whom. Which departments will be affected? What are the expected risks and benefits? Define what success will look like in terms of improvements, and how those improvements will be measured.

“We have an assessment process we go through before we talk to customers about technology,” says Siemens’ Lewis. “We ask what their goals are, what they are trying to achieve in the next five years. Do they want to reach a new market? And then we dig in and find out what’s keeping them from getting there.”

Find ways that the value of the solution will extend to each department, and explain how the departments affect each other. “For example, we had a client where design engineering would always print the most current version of the documents for the people on the shop floor,” offers Synergis Software’s Cummings. “If the shop floor can get that on screen, then they don’t have to waste paper.”

Cummings notes that the concept can be expanded to things like computer numerically controlled (CNC) machines, for example: “Put the CNC code in the solution so we know that every time there is a change, the correct version goes out.”

Siemens’ Eustace notes that PLM makes walls disappear that previously prevented departments from effectively using data. “You can combine information coming from all of these systems in a format that allows them to make good decisions,” he says. “The data becomes company data, and is available for re-use in ways that can be leveraged to make other activities easier.”

It’s important to look for subjective feedback—not just improvement numbers, but input on how users actually feel about the solution during the deployment. Otherwise, once the implementation is completed, users may slip back into old work processes and undermine the solution.

Know Your Data

A key piece of the planning phase is finding out how much data the company has, and what condition it’s in. Evaluate data to determine how accurate or clean it is, and how it can be scrubbed. Find out who owns the data, where it resides, and who uses that data further along in the work process.

“No customer really knows their data,” Cummings points out. “Whether you are talking about a small or a large organization, it’s amazing how multiple people across multiple departments can use the same data without understanding that they are each consuming that information from different perspectives. It’s multi-dimensional, and that’s why its critical to have a project team with a 360° view.”

This process will often uncover data repositories that are critical to the business, but that are otherwise not part of the official workflow. “There’s always an opportunity to find out more than what is actually documented by the company,” Cummings says. “Data sources have an odd way of multiplying once you start digging.”

Finding those “hidden” data sources will also help smooth the transition for employees connected to those repositories, Lewis says.

“There is a whole universe of people orbiting the product data, from sourcing to sustainability to the field technician servicing the product,” he adds. “Companies are seeing the value in having all of these people on the same system, and in an environment that is not an engineering tool. It’s not geared to the technical power user, but it’s for people who don’t live their lives in the CAD system.”

Breaking Down Barriers

With the project team in place and a thorough understanding of the company product data, project leaders can then enlist “champions” in functional areas that can serve as leaders and help remove organizational barriers to the project’s success. These champions can come from any level of the company, as long as they are trusted and respected by other end users.

Communicate both the scope of the project and its progress frequently. Stakeholders should have some ownership in the process so that they are invested in the success of the deployment.

“This is where the local champions come in,” Cummings says. “Those folks can have a tremendous positive influence in helping people understand the why and how of the solution.”

These projects still encounter unexpected pockets of resistance, of course, particularly as the go-live date draws nearer. Users may cling to existing work processes, even if the new PLM can potentially make their jobs easier.

“Even if the old way is convoluted, complex and takes longer, it’s remarkable how we see people hanging on to that old way,” Cummings says. “That’s because the old way is comfortable for them. You really have to map out how this will help them, and show them that it is more streamlined and saves time.”

Employees may have an almost emotional connection to their workflows. While management can force those changes from the top down, a more nuanced approach can result in full employee buy-in, rather than grudging acceptance.

“At the center of those issues are people taking pride in what they do,” Cummings says. “Often we’ll find that at some point in the past, something didn’t go right with a solution and they weren’t able to do their job in the way they wanted to do it, or that they were expected to do it. The process then becomes a bit like arbitration.”

In many cases, where there may be a larger need for education and change management, a third-party consultant or integrator can provide valuable assistance. “Having a systems integration partner that can come in and manage that process is really helpful,” Kelley says. “We have a consulting group that can install the software and train the users, but you need someone there who can execute executive-level change management, and then take that process through the ranks.”

The training approach can also ease employee acceptance. Train administrators and project champions early so that they can help lead group training. And allow time for “over the shoulder,” hands-on training so users can experience how the solution will work in a live environment while they are completing their work.

“You have to keep everyone confident that when they sit down at their desks, they are not in a free fall,” Cummings says. “They know that they can effectively get their work done.”

Dashboard-level controls for management, meanwhile, will help keep executive sponsors involved in the process by providing tangible benefits through direct visibility into the product pipeline, along with analytics and reports. “The executive sponsors also have to stay engaged,” Kelley points out. “You can’t just bless the thing, hold a pep rally and then go away.”

Finally, make sure everyone affected by the project is aware of the important role they play in maintaining product data, and what the value of the solution will be for their department and for their specific role in the process.

“Part of the job is helping people realize that they are connected,” Cummings says. “There is an interdependency and reliance on the data, and a lot of times people may not understand that, even when the processes are well documented. You have to connect the people, not just boxes on the flow chart. When people connect, then the process challenges are a lot easier.

“This is a knowledge-expanding experience,” he concludes. “You have to go in with an adventurous eye. The end result is a deeper understanding about how you work and how you can work better.”

More Info

• Oracle
• Siemens PLM Software
• Synergis Software