Back in September, Yoann Maingon over at Minerva, an Aras reseller, wrote a blog post that got my attention: Stop Starting PLM from Engineering!!! The gist of the post boils down to this excerpt.

Start your implementation’s phase 1 out(side) of engineering and you’ll get live much faster. These people need integrated systems and their processes are more stable then in engineering.

As you can see, it's another traditional perspective on... wait... what?

The concept of initially deploying PLM outside of engineering runs counter to almost every software or service provider's deployment approach. There's been variations on what defines the so-called foundation of a PLM deployment, but they commonly look something like what Concurrent Engineering, a PTC reseller, has listed in their post titled 7 Must have Components of PLM.

Could such an approach be valid?

Autodesk: Two Proof Points, One View

Not long after Yoann published his somewhat controversial post, Oleg Shilovitsky, a PLM executive now with Autodesk, published his own titled Should We Stop 'Engineering PLM?' With a few caveats, he agreed with Yoann's points.

I can see lots of interesting opportunities in starting PLM from a business side and not engineering side. You can get results (and ROI) much faster. The industry matters, in my view. You can start PLM outside of engineering in companies heavily focusing on the supply chain, build to print processes, service organizations, process industries and others. I’d not be trying to start outside of engineering in companies focusing on ETO and large OEMs in automotive, defense and aerospace.

Separately, on Friday I had a conversation with an Autodesk executive at the PLM Innovation event at Atlanta GA. After our conversation wandered through some traditional points, I was surprised to hear them say that they have seen PLM360 most frequently replacing spreadsheets.

Nope. That wasn't a typo.

Typically, PLM from a traditional PDM perspective replaces the management of engineering data that exists on desktops and shared drives. Beyond that, it commonly replaces the use of email for routing forms around.

If you think about it, most organizations, including engineering still run their businesses on spreadsheets. It might be a Visual Basic programmed report. It might be a BOM with conditional logic. It might be a form sitting on Google Drive.

My Take

You might notice that I haven't condemned nor condoned this view as of yet. And that's for good reason. Let me explain.

In the first episode of Tech4PD, I argued that a more granular point solution approach to PLM offered a far faster path to value and ROI. It also carries much less risk. I'll be honest, I was surprised that enough viewers agreed with me to let me win that debate and make Jim Brown brush his teeth with wasabi. So do I see value is deploying PLM outside of engineering first where the data isn't nearly so complex and heavy? Absolutely. Other organizations can get value far faster as Yoann and Oleg have said.

However, there are some problematic risks.

If you use workflow to automate a process that is loosely tied with some data, does it have to be a PLM system? Absolutely not. Many enterprise systems today like ERP, CRM and many offer workflow capabilities. So the outstanding question in my mind is 'why PLM at all?' I can quite literally see a CEO or CIO asking this tough question to a PLM advocate, turning them away and forcing one of these other enterprise systems on the entire company. That in itself may not be bad, except when the engineering organization does need something to manage and visualize their complex design data.

Summary and Questions

Let's recap.

• Yoann Maignon from Minerva (an Aras reseller) and Oleg Shilovitsky (an Autodesk executive) have written about the potential to start PLM deployments outside engineering.
• An interesting data point comes from Autodesk, who is frequently replacing spreadsheets with PLM360 instead of shared drives and desktop management approaches.
• As I said on Tech4PD, I believe that granular PLM point solutions can provide value independently.
• However, know the risks. If workflow or reporting is the only enabling capability, then many other enterprise systems can offer them instead of PLM. This can lead to difficult conversations with CEOs and CIOs for PLM advocates.

OK. Now I'm interested in your take. Does PLM without engineering data management make sense? Is there any additional logic to use PLM workflow over competing types of enterprise systems? Sound off and let us know what you think.

Take care. Talk soon.