By definition (according to the Oxford dictionary), an engineer is:
- A person who designs, builds, or maintains engines, machines, or structures.
- A person qualified in a domain or industry of engineering, especially as a professional: eg “a mechanical engineer”, “an aeronautical engineer”.
- A skilful contriver or originator of something: the prime engineer of the approach.
The definition has a broad meaning and applies to various disciplines and sub-disciplines, technical domains, and manufacturing industries (excluding in this discussion train drivers, electricians, plumbers and other professions which might also be called – or call themselves – ‘engineers‘).
Whether they want it or not, whether they like it or not, whether they know it or not, engineers use Product Life-cycle Management (PLM) every day: processes, templates, tools, applications, etc. The ‘day in the life‘ of an engineer typically consists of:
- 10% creative work: innovating, solving problems, finding new ways of doing things, new things – high value-added activities. This can’t be done by a process, an IT tool or a machine.
- 30% commodity work (business as usual engineering – whatever that means, depending on the context) – value-added activities. Same as above…
- 30% ‘admin‘ – essential non value-added activities. This can be potentially put into a repeatable process, given to a junior engineer or lower pay-grade person, or this can be outsourced (someone has to do it, but there is little IP or complexity).
- 30% non value-added activities. This can be eliminated as it is basically noise or waste.
Don’t mention ‘PLM‘ to an engineer as it will (most likely) be associated with the ‘admin‘ section above (or worse, into the non value-added activities 🙂
Why engineers love PLM.
- It allows them to collaborate, given them the right tools to share and manage their data.
- They can access the system from anywhere.
- PLM allows them to manage complexity, and care less about dependencies of what other functional groups do and how it relates to their work – somebody else it taking care of that integration and alignment for them.
- PLM helps them centralise their activities into one ‘portal’.
- They think PLM is just a smart ‘plugin‘ to the ERP world – the “natural system of record for products”.
- If well implemented, PLM simplifies their life.
- Some PLM tools are ‘sexy‘ – yes, they are:-)
Why engineers hate PLM.
- What does that acronym stand for? What they see and care is mostly PDM and document management – unless they are manufacturing engineers.
- Systems performances are not good: the system is too slow and over-complex (hence they end up working on local drives until their work is matured enough to share it).
- They don’t trust the data as many of their colleagues work like them: outside of the PLM eco-system because they estimate that they lose too much time in ‘admin‘.
- Processes are too stringent and not intuitive; some important features and requirements are not implemented or not properly implemented.
- They were not part of the key user group to create the requirements and validate the solution during its implementation; they consider that change is hard.
- The training is crap; a lot of manual work is still required.
- It is not their preferred ‘technology‘.
Sometimes, engineers are reluctant to recognize the value of PLM because they perceive that someone else has ‘done PLM to them‘. It is important to make sure that the right people are engaged and involved in a PLM transformation journey. While not every engineer can be heard, education, training and ongoing communication are critical for future adoption. There will always be negative voices about PLM solutions, especially when IT tools are over-customized and when PLM strategists focus most of their time talking about tools and technologies. The fact is that most already ‘do PLM‘ even if they don’t formally use PLM tools. There are sometimes only few tweaks required to make a difference in improving a process, and delivering more tangible value to engineers with PLM…
What are your thoughts?
This post was originally published on LinkedIn on 21 October 2015.
About the Author
