How to Converge on One PLM System—The Tough Approach

Collins Aerospace designs and manufactures engine nacelle systems such as the one shown on the Airbus 320neo. (Image courtesy of Collins Aerospace.)

How do you manage an enterprise-wide installation of software across a globally dispersed company affecting ten thousand users—many of whom want no part of it? That’s what happened at Collins Aerospace. In 2015. United Technologies (UTC), Collins’ parent company, found itself teetering under a polyglot system of applications from all the companies it had acquired. Each company came with its own CAD and product lifecycle management (PLM) systems. UTC realized it had to unify under one platform.

It took a high-level commitment from company executives and someone to lead the charge. It was going to take a lot more than convincing and cajoling for engineers to give up their tried-and-true applications.

Kevin Gordon is a rough and tough, no-nonsense senior director of PLM at Collins Aerospace. Back in June, he was delivering the keynote at Realize LIVE, the new name for the Siemens PLM annual user meeting, and recounted his ordeal. If he talked a little slower, he would sound a bit like John Wayne.

I imagine Gordon riding into town, flying the Teamcenter flag and saying, “I’m going to get off my horse and show you Teamcenter. Drop your PLM.”

“You can take my PLM from my cold, dead hands” was the most likely the response.

“If you insist,” Gordon would then say.

The State of PLM at Collins

Collins Aerospace is about as big as an aerospace company can get without actually making aircraft. The company’s annual sales top $23 billion, a quarter of which is military, with the rest being commercial. For the aircraft manufacturers, Collins builds and supplies avionics, interiors, landing gear, engine parts and other parts and systems. Now a division of UTC, it is a combination of UTC Aerospace and Rockwell Collins. Collins employs 70,000 people and 16,000 of them are engineers.

“We had 53 PLM systems at one time,” he said.

Shipping Work to India

“Coordinating work between different far-flung divisions was a nightmare. We had a division in one location who had no idea what another location was doing,” said Gordon. “We struggled to collaborate. Bangalore, India, is our biggest engineering operation for Collins. We’d generate work in the U.S., package it all up, have it worked on in India, then bring it back. That’s not collaboration. With our new system, we don’t have to wait and send a whole package. We can send a drawing here, a simulation there.

“Also, if we do something good in one part of the company, we need it to be known everywhere. And that is what we can do with one PLM system.”

You’re Not Special

“Not only did we have many different software packages, we customized the crap out of them,” he explained. “All the customizations were driving us nuts. We’d hire consultants to customize the software, but we didn’t have the manpower to maintain them. If our PLM system was revised, we could deploy it because the customizations broke down.”

Gordon risks alienating the engineers in the audience at Realize LIVE but he’s not worried. Engineers typically think of IT as standing between them and their favorite tools—hardware and software. These tools are trusted to do the job and the engineers have grown attached to them—they cling to them and are loathe to change them. Gordon understands that to some extent. He came from the engineering group. “I’m not an IT person.” While this gives him some credibility when he is trying to talk engineers into dropping their favorite tools, in order to implement the company’s PLM unification strategy, Gordon’s role has to be that of the IT person. But after hearing things from Gordon’s perspective, the multiple, different systems that have created information silos and impediments to collaboration, the IT person no longer seems to be the bad guy.

In Collins’s attempt to standardize on PLM, it paired the consulting services of Deloitte with Gordon. The team called a high-level meeting with several of Collins’s executives. On the board were written the words “You’re not special,” a clear message that their tools and processes were threatened. While the various divisions were special in terms of the products that they made, they were not going to be recognized for the tools and processes they used to create the products. In Gordon’s world, there was no reason for engineers to dig in and fight for one engineering tool over another. “Nobody buys your product because you have three steps in your change management system that are really, really good,” mocked Gordon. “Our shareholders invest in our company because we design, build and ship really good products. Having a world-class process tool will make a little more money. Having a better product will make us a lot more money. I wanted our engineers to focus on innovation, on products. If we can use an industry standard process to keep us compliant and let us manage and collaborate on data, and keep us compliant, then we can make a lot more money,” he explained.

An EPEC Transformation

An EPEC transformation. About two years ago, Collins embarked on a massive standardization project led by Gordon and Deloitte called EPEC. The project involved over 150 subject matter experts, whose 10,500 users consumed or needed access to the company’s design data.

In the beginning it was “very painful.”

“We translated a lot of data”, said Gordon. “Until this project, our previous biggest data conversion was a SAP project with 65 million records. This project had over 370 million records held in eight legacy PDM and PLM systems.”

The company shut down for 10 days. The outcome seemed an overall successful: a 99.85 percent success rate in record translation.

Bleeding Edge

Collins stays “slightly behind” the Teamcenter releases. “If we are sure Siemens has everything right, and everything works, we’ll update our version right away,” said Gordon. “That’s a big if. Most of the time, we may be six months behind… a year at the longest. Like other big enterprise installations of PLM, the administrators see no need to keep to the leading edge (bleeding edge, as they call it) of software, eschewing the bells and whistles, the new features, but have learned to mark time, to let things settle, to be assured the new software is watertight and what leaks is patched.”

Lessons Learned

His biggest mistake? He forgot about ECAD, he says. Months into the migration project, they realized they had not considered the electronic and software data. “Hey, I’m a mechanical/aerospace engineer,” he joked.

Also, if Gordon were to do it over, he would work harder on reinforcing the new system with the company’s middle managers. While transformation was complete at the highest levels of management, when the time came to go live, “there was a lot of fear,” he recalled. Gordon’s team used training modules on a system called Brightspace, developing videos to train users for Teamcenter. “We relied on it too much,” he admitted. “We should have had some more formal, classroom type training. Some groups felt as if we turned the system over to them and then ran off to the next project.”

Gordon’s team had to relent on customization. While IT’s goal may be zero customization, the company found that some customization was necessary. “We settled on 15 percent customization,” said Gordon.

A successful transformation requires an understanding of the data. There were several instances where data in the old system was not working in the new system. “People talk about ‘cleansing the data,’ but it’s more about understanding the data,” said Gordon. Rather than do a wholesale transformation of data, Gordon’s team found that taking smaller chunks of data and migrating them a chunk at a time was the more effective approach.

But one thing engineers will relate to is the challenges Gordon experienced dealing with people and culture. “Changing the people is harder than changing the process,” he concluded.