Who needs a PLM supporter ?

The past week I was involved in three different situations, which seem to be disconnected from each other, but when looking back, I found one common similarity

The first case was with a company that had implemented pdm with a tight CAD integration many years ago. They have built together with their implementer(s) a dedicated environment, which was working efficient, perhaps never efficient enough. In the beginning of this year they planned an upgrade to the latest available software and after going live with the upgrade of CAD and PLM software, they discovered severe issues both in performance, in data inaccuracy and user acceptance. With ups and downs and serious effort from several sides, it looked like things were going better, but now they are in a down again as some users refuse to work with the system.

What do to: Fix the system everyone would think ?

In the second case a company has implemented document management and with the support of the IT department the system was defined to cover the known needs.

The users however were reluctant to work with the system, complaining it was too slow, too complex and a lot of extra work, so nothing happened.

More than a year later, the engineering department got the assignment from the management to revive the system and they focused on implementing their main processes in the system, so everyone could work with the system. Still the system has not gone live! As all the time, when the management or users see the system, there are discussions on making it more user-friendly, simple interfaces and more.

What to do: Simplify the system everyone would think?

The third case is a company ready to launch their first PLM implementation and they really go for the full PLM story, including CAD data management, EBOM, MBOM and even BOP (Bill of Process) managed in their PLM system. Main reason they were able to plan the full PLM story was the fact that they were implementing a new ERP system too, so no legacy habits from the ERP side around ‘owning data’ like the Item master, MBOM or BOP. The past year has been spent on building the systems (PLM & ERP) conceptually in a test environment and from there on the PLM side they discovered some performance issues, which were considered critical to fix. And then they would go live both PLM and ERP at the same moment (a big bang), after almost a year of isolated preparation.

What to do: Fix the critical issues and go live everyone would think?

Although all three projects are in different countries, in a different culture and with different software, they all share one thought:

Implementing PLM is like installing an operating system. Once it is installed fix some bugs and the company will work with it. Perhaps not everyone is happy, similar like we have Windows, Apple MAC and UNIX communities, but the platform is there and we make it work. And updates of the system come with the new hardware; check our applications – if they are still running we are happy, if they are not running anymore we implement new versions or other software

By writing it so black and white, I hope you will agree it is more complicated. And I will be very happy that you agree here, as in many PLM implementations, the management of such a company has this impression – not being aware, not being knowledgeable, not being informed it is different. In addition PLM vendors and implementers try to stay close to this simple message, as no-one wants to be the messenger of the bad news that PLM is more than a software installation

 The root cause of all these problems is exactly the lack of management understanding and commitment to PLM.

As most of the members in a management team are relying on their ERP system for financial activities, production status, order status, stock value, etc, they also try not to touch ERP anymore once it is running. It is a mandatory system for execution and everyone is aware and somehow comfortable with costs.

And there is the difference with PLM. Do we need PLM ? We have been doing projects, designing projects already before our ERP system ? And if we install a PLM system, isn’t it like the ERP system, you install it and it is up and running ?

No !

PLM is not a system, it a vision how to work more efficient and intelligent. And by collaboration (using modern tools and means) between all stakeholders: market, design, execution (production or construction) and field services, we are better able to understand what is happing and as a next step, we are able to react or even better, be pro-active and come with better and innovative products and services.

So it is not about automation only. It is a change in doing businesses. It is about connecting people who were not used to work together, share information together. And there are various ways to achieve this – but not by installing simple, error free software only.

And this happened in all three companies I described. The vision of PLM was (partly) based on certain software capabilities. In the first example, it was not really PLM. It was automating the existing situation and now several years later, the company assumes after upgrading it still works, without making an evaluation, where the PLM vendor was heading to, without making an evaluation what the current quality of their data was. The focus was again on a system and fixing errors that the system should be able to understand

In the two other situations, there was the thought that once the system is there, users will accept it and start working with it.

Big, big mistake !

Users do not like software that requires them to change their way of working and we forget every time that changing the way someone works is not a software change. For the oldies: remember MS-DOS ? Single screen – no window swapping/multiple applications open. Many users loved the old MS-DOS due its simplicity (now they are retired) and we see the Apple generation (single window and single tasking again, but modern interface)

Building a multi-tasking environment, which PLM often is, requires a guided change process, motivation of the users, but at the end a firm statement from the management that this is the chosen way to go forward -assuming they support the introduction and usage of PLM.

(I received a nice comment on my previous post, stating we should give every user £100 to commit start working with the software, instead of paying thousands of pounds for customization to comfort the user)

 And here is the major pain in all of these three companies. The management is not able to take the ownership of the PLM vision and guide it through the company.

They let the execution to their project leader, lead engineer or IT staff and assume like ERP, everyone knows what to do and fix the bugs – no business change – just software implementation.

This leaves these front-runners in a very difficult position.

• Not loved by the end-user, who wants no change and if there is a change it should be more fun. The will show the system is not working for them.
• Not loved by the management as they are wondering why it takes so long to fix the issues. Should not we be up and running already after such a long time ?
• Not loved by the PLM implementer as there is a limit to fixing the problem. After solving a problem there is always a next problem discovered
• Not loved by the PLM vendor as they need positive references

And put any combination of people above in a meeting, the ones who are not there are to blame – and I realize I am doing the same – I am pointing to the management who is often invisible.

Call for the management

For me the management has the task to feel responsible for PLM – as they are responsible for the company’s future – not the end-users. This means they should be able to judge the steps executed during a PLM implementation, or for an upgrade and assure they fit in the vision. They should realize that they are the voice to the end-users to explain the value of PLM and why there is a different way of working. They do not have to go into the details, but keep the bigger picture in mind.

And the management must show commitment to all –they want PLM . So commitment is needed to the end-users, to the IT department, to project team and to the implementation partner. And commitment is not easy to delegate.

Unfortunate commitment for PLM is also a  long-term engagement, as it is not like ERP. Once it is running do not touch it. The markets change, the people change, technology changes and therefore the software practices change. To decide where, when and how to engage with a next PLM step should be a strategic decision from the management, not from a user who wants a new interface.

My last remark: it is clear that the management does not have the time and in-depth knowledge of PLM today as also the PLM is a young and moving vision due to changes in our society. (In my next post I will go into the new social hype – ask yourself is there also social ERP ?).

 So the management team needs a sparring partner, a PLM supporter, who will reflect their vision into PLM steps and how to enroll them and communicate them into the organization, without losing visions and faith but also without talking about software features. Either you should make sure this knowledge is in your company, as several companies have already successfully discovered. Or search for an external PLM supporter – looking to my blog questionnaire results they exist !!!

I am curious to learn if you recognize these situations, if you agree, disagree – feel free to comment