Should We Stop ‘Engineering PLM’?

by Oleg on September 29, 2012 · 10 comments

Even if PLM (as a buzzword, business strategy and software) has a relatively short history, we can talk about some historical roots. There are two main roots or directions in the historical development of PLM. One takes us to design companies, CAD, Engineering Data Management (EDM) and Product data management (PDM). Another one takes us to business systems like enterprise resource management (ERP), workflow and business process management (BPM). These two roots defined the way PLM systems were sold and implemented in many companies during the past decade. First direction used CAD and engineering foundation to establish an initial PLM implementation. ERP vendors were slow in introducing product lifecycle management solutions. Independent PLM companies were weak financially and because of traditional conflict for data-ownership lost the battle to more powerful CAD and ERP companies.

Recently, I started to hear more voices towards “a process foundation” of PLM. The combination of cost-effective platforms (open source, cloud) and increased sensitivity to ROI created the opportunity for new style of PLM implementations – faster, cheaper and… less engineering focus. The last one requires some additional explanation. For many years, the roots of PLM implementations go to engineering department. I can see many benefits in doing so. However, engineering foundation and engineering focus slower an adoption of PLM system by other departments. I’ve been reading Yoann Maingon Minerva blog called Stop starting PLM from Engineering. The main point is how to proliferate in PLM to non-engineering parts of an organization. I liked the following passage:

Start your implementation’s phase 1 out of engineering and you’ll get live much faster. These people need integrated systems and their processes are more stable then in engineering. We know that in engineering you can have very different software acceptance from one to another. You need then to have people in the company that are already supporting the project. The risk is of course to not take into account the software capabilities to support Engineer’s processes. And that’s where it is good to have IT people coming from Engineering to select the solution.

What is my conclusion? 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. Just my thoughts… What is your opinion and practices?

Best, Oleg

Share
  • http://www.facebook.com/menk.slot Menk Slot

    Hi Oleg,

    For me PLM starts with product data and most of this data is defined by engineering. When I started in this business we called it EDB (engineering data base). Later came PDM and after this PLM. If I look at most of the implementations, it is more CAD Data management.

    So can you explain me in wich cases you want to start PLM outside the engineering department?

    Regards,

    Menk Slot

  • Steve

    Hmmmmmm. Should we be surprised by this new point-of-view? ;-)

  • beyondplm

    Thanks for provoking :) . I think, PLM vendors always wanted to expand “beyond engineering”. So, why you call it “new pov”?

  • beyondplm

    thanks for the comment! Yes, PLM starts from product data. But product data resides in many systems – not only engineering. It is in CRM, ERP and many others. I can see more “network of data” these days, compared to “database of data” in the past. What is your take?

  • chris

    If you were developing a PLM system today I think it would be very different than if you were developing one 20 years ago. Back 20 years ago the PLM guys wanted to take the BOM away from ERP. We now know where that has ended.
    Business already has enough systems of records – systems to control data. These are all very much needed to run a business. But when you look at how these are used you find poeple dumb data into them, or report inforamtion into them. You find people do not work in these. You also find that these systems have not really changed the productivity of poeple.
    I think you need to look at PLM with respect to where all the time in engineering goes. The ad-hoc, discussion and decision process used to convert concepts into products. The truth about engineering is it is not very structured.

  • MarcL

    Oleg, good post. I completely agree. What I think we’re really talking about it the fact that a “single VERSION of the truth” is a fallacy. What we’re really after is a “single VIEW of the truth” IMHO… PLM, ERP, custom, etc who cares… as long as you’ve got the right info for the right people to do the job.

    MarcL
    http://www.aras.com

  • Scott Cleveland

    I worked for a company that sold the first available PLM software [Sherpa]. We didn’t call it PLM at the time – the acronym hadn’t been created. Our president used to say that our software could get ‘the right information to the right person at the right time’. I think that defines PLM well – It is not just about engineering.

  • beyondplm

    I think, people are looking for a single version of truth, but it doesn’t mean it co-located in a single database of truth.

  • beyondplm

    Chris, thanks for commenting! Yes, agree- PLM is changing. Processes are more dynamic today and it is impossible to plan years upfront.

  • beyondplm

    Scott, thank you for your comment! I have to say – “the right information to the right person at the right time” – interesting enough, it is still relevant.

Previous post:

Next post: