Working with engineers is like herding cats. Try to put few engineers in a room and get an agreement. If you have 4 engineers in a room, you probably will have about 5-6 opinions about what is the right way. No surprise. That’s what happens when engineers are trying to agree about what is the right focus on PLM. My good blogging buddy Chad Jackson clashed with some of my ideas I posted here – PLM Journey and thoughts about technology. Chad is well known analyst, researcher and publisher in a space of engineering and manufacturing. If you haven’t had a chance to watch his PLM debates with Jim Brown of Tech-Clarity, I recommend you to spend some time on this site (Tech4PD) over the weekend. It is a funny stuff and you can also learn about PLM there.
Let’s get back to Chad’s last blog – PLM requires business transformation. Bollocks. I like the level of expressiveness coming immediately with the title of the blog. If you are (like me) not familiar with some strong Anglo-Saxon swearwords, I recommend to navigate your browser to the following Wikipeadia article to learn more about “bollock” word. I found the following definition interesting -
A survey of the language of London teenagers (published in 2002) examined, amongst other things, the incidence of various swearwords in their speech. It noted that the top ten swearwords make up 81% of the total swearwords. “Bollocks” was the seventh most frequent swearword, after “fucking”, “shit”, “fuck”, “bloody”, “hell” and “fuck off”. Below “Bollocks”, were “bastard”, “bitch” and “damn”, in eighth, ninth and tenth places.[8] This research regarded these words as swearwords in the context of their usage but noted that some might be inoffensive in other contexts.[9]
However, let me back to PLM topic. With the high level of disagreement and passion expressed above, Chad is making his proposal about what is the right focus of PLM. He made two suggestions: 1/data management (or CAD revision management) and 2/ process automation. Here is a passage from Chad’s blog:
The Right Focus for PLM. Over the past decade of PLM deployments, I have seen two areas that provide solid ROI. Here they are.
The first is global centralized data management. Start with CAD. Then go to multi-CAD. Then, if you’re ambitious, go after the full product definition of specifications and the like. I know. It’s not the fireworks lots of people like. Folks I’ve talked to at PLM software providers are sick to death of this. PLM champions at manufacturers cry for the boredom this effort involves. People like something new. I get it. But this is the most solid value of PLM, or debatably PDM, that you can achieve. Everyone gets the right version of the right file, which reduces change orders, scrap and rework and incorrectly ordered parts.
The second is digitization and automation of processes. No, I’m not talking about transforming or re-engineering your processes. Just move from email routing to workflow. I’m not talking about moving your specialized or custom forms into PLM. Take the Out-of-the-Box forms and tweak them as minimally as possible to support your current existing process. There are all sorts of advantages you reap here, including the elimination of delays and incorrect decisions in processes. It’s a very solid, if unspectacular ROI.
PDM is a right focus for PLM?
To me it is an obvious thing. PDM is a core and fundamental thing of product lifecycle management. Without data about product you barely can think about managing product lifecycle. PDM very often considered as a system to manage CAD files including revisions and changes. However, many people see engineering BOM functionality as part of PDM too. Every PDM system implementation starts from capturing existing (legacy) data – existing catalog parts, CAD models, drawings, BOMs, documents releases to customers. This project is painful and complicated. In many situations PDM project failure and/or delay is preventing from future development of PLM solutions. I recently posted about that here – PLM adoption and CAD management valley of death.
PLM and importance of processes
From my experience, “message routing” proved to be an efficient mechanism to improve communication and existing processes. I’ve seen such type of functionality in few PLM tools. For example “message routing” was available long time ago in MatrixOne for ad-hoc collaboration. In addition to that, this functionality was promoted by SharePoint, some BPM-vendors and also startup companies. In PDM/PLM space, I’d note Autodesk PLM 360 with the ability to provide flexible process orchestration and startup company like Kenesto focusing on social collaboration. However, the process of capturing “existing processes” is not simple and require a lot of legacy data work. What are important processes to automate? In my view, ECO is the one that can be ranked as the most important. However, to handle ECO processes without proper integration between PDM and ERP is next to impossible in many situations. Especially, it is right when PDM/PLM focus is on CAD data management only and information about BOM is located somewhere (in ERP?).
What is my conclusion? I think PLM space is ready for disruption. The main reason for that is related to growing expectations of manufacturing companies to have a better PLM solutions multiplied by modern workforce changes. For the last 10 years, PLM companies tried to solve the problem of broader PLM adoption. I don’t think we have a proven recipe how to achieve a broader adoption of PLM deployments in large companies as well as to help smaller manufacturing businesses to leverage PLM values. In my view, PLM vendors need to rethink existing solutions. How to solve old problems PLM trails for many years in a new way? To me, this is a right question to ask these days. As part of this process, we need to focus on user experience and better integration of PLM technologies with existing software in a company. Just my thoughts…
Best, Oleg
For many years, enterprise software was known as a place where development of new features was one of the main priorities. To have comprehensive list of features was considered as absolute necessity. The army of sales people and advisers spent enormous amount of time in validating and comparing features of enterprise systems. From the early beginning, PLM was considered as an extremely complex discipline. Product development methodology and engineering culture made PLM in the way we have it now – overloaded with features, struggling with user experience and the ability to have fast and broad PLM adoption in any company.
