PLM Software and Business Process Scalability

PLM Software and Business Process Scalability

Scaling up is a tough problem. I want to talk today and PLM Software scalability in unusual aspects – business processes. In the past, CAD and PLM vendors spent lots of effort to help software scale up in their ability to manage huge CAD assemblies and very sophisticated product configuration. When PLM system first loaded airplane 3D model, made a DMU and resolved different airplane or car configurations, we said wow… However, it was many years ago. Since then, PLM wizards are stacking with a problem they didn’t expect to see – how to scale up PLM in the organization?

Emails, Collaboration and Business Processes

In order to scale up in the organization, you need to have people using the system. After many years of different types of collaborative software experience, my fundamental conclusion is simple. Most of the engineering and manufacturing organizations are run by emails. This is where PLM failed massively – it doesn’t scale up to get people using PLM systems. PLM collaboration is very successful when you think about two designers are working on the same feature. However, it is different when you think about a design engineer and a manufacturing engineer are collaborating. Yesterday, I had a chance to read Develop3D article – Design and Manufacturing in Perfect Harmony. You may think, this is an excellent example where PLM system can help design and manufacturing people to work together. So, why it doesn’t happen?

Design to Manufacturing

PLM vendors spent lots of effort and resources working on collaborative processes. Design to Manufacturing is one of them, and this is probably is one of the most important if you think about how PLM implementation can scale up in the organization. However, I can identify top 3 reasons why collaboration is so not efficient between engineering and manufacturing:

1. Environment separation
Designer and Manufacturing Engineer sees a world differently. In most of the situations designers are living in their CAD/PDM world. At the same time, manufacturing engineers are on top of MRP/ERP environment and working on their MBOM-driven processes. PLM failed to scale up and establish a scalable process between these two environments.

2. Common Goals and Synchronization
How to achieve a harmony in a common work? You need to set up a common goal. When designer and manufacturing are working in different environments, they have a hard time to define a common goal and follow this goal in their daily operation. Most of their time they spent to synchronize their environments. The final stop in the synchronization is a weekly meeting. You can see how people spending their time literally synchronizing information between them.

3. Push Processes
How to get work done in the modern manufacturing organization? Unfortunately, email is probably the most widely used mechanism. And this is really bad, because it creates a ping-pong of information going back and forth between people in the organization. This is an environment where Excel is a king of the email road.

PLM and Process Scalability

In my view, this is the place where most of the current PLM implementations failed. Scaling up beyond the engineering department is a tough problem. The best organizations I had chance to see solved this problem by a massive customization work and enormous effort in making people work together in the same environment.

What is my conclusion? When I talk to people, I’m constantly asking the following question – what is the biggest problem you faced in all PLM implementations? Here is my today’s conclusion – PLM is a great concept and a very important organization strategy. However, it doesn’t scale up in the organization. In order to make it work out, you need to spend too many resources. When it comes to results you can see a very low value for money and resources you spent. Think about space shuttles. We need to spend a lot of rocket fuel to get a space shuttle in the space. The same with PLM… Something is wrong behind the scene. Is it technology? Implementation? People?

What is your take?
Best, Oleg

Share

Share This Post

  • Hello Oleg,
    I think an important reason of this is that most of the projects are MCAD related. The system is used by the CAD users who wil only manage there CAD Files. As long as an organisation does not see PLM as there backbone for there Product Data, this will not change. People need to realize that PLM is more then only CAD File Management. I wrote an article (in Dutch) about other aspects

    You can find it on:

    http://plmconsult.nl/blog/6-de-invloed-van-plm-op-de-uitdagingen-voor-uw-organisatie-deel-i.html

    There is a part I-II and III and perhaps you can use Googel to translate

    Regards,

    Menk Slot

  • Jha Git

    Great Article, once again Oleg,
    I am sure its not technology behind the scenes because when we are talking about cloud and PLM, then i dont see a reason this type of collaboration would fail because of that.
    I think that again its implementation which have not thought upon deep. Need to scale it to down level again to get into the lowest level of conceptualization.

  • Fred Schwark

    Oleg,

    Great article. I think you are hitting a lot of the heavy hitters, but when it comes to a deep rooted system engineering issue you will find trouble in adaptation of anything but the status-quo. Until organizations are able to transform from the typical siloed organizational structure into project oriented teams, you will continue to have this problem.

    Amazingly enough, if companies are able to transform themselves, adapt a systems driven approach to design, manufacturing, and full lifecycle management they will find reduction in cost, increase in efficiency, and returning profits.

    Fred

  • beyondplm

    Menk, Thank you for your comment! I agree, as soon as you establish PLM backbone, the life of PLM strategists will be easy. However, the biggest problem is that to establish such a backbone is a very expensive. So, most of the customers are starting it as a phased project and their first step is CAD data management. My assumption is that about 10% or less is coming to the next step. Thanks for sharing your links. I will take a look. Best, Oleg

  • beyondplm

    Jha, thanks! This is a very interesting comment. I disagree with the first path. Cloud cannot solve a problem with collaboration. By moving your email to the cloud, you will not start to collaborate in a better way. However, I completely agree with your second part – we need to scale down PLM to a very low, granular level to fix some fundamental problems that make PLM expensive and complicated. Just my thoughts… Best, Oleg

  • beyondplm

    Fred, I think you are right! Siloed organization is the first problem. However, in order to scale, PLM (concepts and implementations) needs to step beyond an engineering silo. The reason why I think it can be possible is simple – organization understood – they have no other way to optimize product cost rather than get people from design and manufacturing to live in a perfect harmony. ERP can shave another 1-2% of cost cut. CAD/PLM is still sitting on top of much bigger potential. Best, Oleg

  • Melvipais

    Your Blog seems very interesting! wish it were in English though..

  • Melvipais

    Great Article! Our company has managed this feat (Manufacture what you design)by loads of customization and process Drives..but the process is complex + with the current attrition rate there is hardly anyone who has the time to be exposed to the whole process and hence understand it..Even then..I could nt imagine how huge organizations would manage without it..It is a undoubtedly a necessity!

  • beyondplm

    Thanks for your comments! I agree, the design-to-manufacturing process is the must. However, many organizations are managing it in a very loosely manner. Best, Oleg

  • You can use Google to translate

  • Oleg,
    Thank you for this and all the previous posts. I like reading them – this is the first time I ever comment.

    IMO, the main technology gap is because the ‘modern’ IT landscape is built out of silos, and these silos were not designed with customization and integration in mind.
    The ‘real’ application and process needs are cross silos and cross organization, and cross organizational function. There’s a need for different views on the data depending on who you are and what organization you belong to. But the data doesn’t come from just one source. It comes from multiple systems in the organization and across the supply chain.

    Heavy point to point customization is a very risky and costly approach, what is the alternative? Using silos ‘out of the box’? 🙂

    Also, with regard to PLM. I really feel sorry for the PLM vendors. They keep running in the same direction for the last few decades, but the more they run the more effort they need to exert to just stay in place.
    All the major vendors have PLM technology that is 20+ years old. They have become very large and complex, a mish mash of mergers and acquisitions not very well integrated.
    As a result, armies of software engineers are required to maintain them, hence an unacceptable price of the end product.

  • beyondplm

    Yaron, Thanks for your comment. Agree with you “siloed view” of enterprise IT. Their integration strategies are self centric. ERP will put their solution in the middle. The same will do so PDM, PLM, etc. Middleware and Busienss Process Management software came to solve this problem. However, in most of the situations I’ve seen that, BPM was lacking of domain expertise to provide an efficient solution. What is your view on this in Cordys? Do you guys have (or plan to have) a vertical strategy/portfolio to play PLM game? Best, Oleg