Successful Implementations – Invest in Phase 1 – Establish the Business Case for PLM

Perspectives on successful PLM deployments – what are the common themes across successful implementations.

A reader recently asked me to share perspectives on successful PLM deployments – what are the common themes across successful implementations.

The thought that comes to mind first and foremost is the upfront planning.  By planning I don’t mean the development of a project schedule or of the system requirements - it’s the investment in taking the time to really make sure the business justification is well understood.

There is a process I have used repeatedly that involves managing expectations very carefully before engaging the software vendor.  Too often it seems that the PLM decision is reactive – as sold by the software vendor, not based upon a clear set of business drivers.

To be successful with the process steps executive level endorsement is critical as it has a lot in common with a business process assessment in that it probes the entire organization, however, the assessment is focused upon the product record, not operations or production.  The challenge for many however having someone who knows  PLM well enough to be able to see the opportunities is often not a skill set contained within your company.  The cost of having consulting done for this stage is often well worth the initial investment when taking into account the overall investment you may end up making in the implementation.

The single most significant thing to be done is to look at the PLM project with the same kind of rigor as a product development project.  Too often IT projects (coming from a non revenue perspective) fail to use simple PMO types of processes.  It all starts with the business case phase.

But on the successful implementations – the business case stage would include the following activities:

1. Take your organization chart and mark every department that handles product related information, identify key external partners that are also interacting with your product records (note – do not count your financial transactions here – just focus on the product information).
2. Evaluate each department around it’s  handling of product information or the product record look for manual transactions, duplicated entries, printouts, markups, shadow databases, network storage of product information.  Include examining what IT infrastructure components are involved.
3. Dollarize the impact of the “non-value” added activities associated with these product record related transactions – the caution is that executives will readily let you turn this into a blame game rather than a financial business case – so be careful how this is framed (Read the Dollarization Discipline for more on this).
4. As in product development project management practices – develop a high level specification (similar to a Market Requirements Document) that ties business objectives to the functionality requirements – this is NOT where to say it must run on xyz database, or have n tier architecture.  This is a market level specification for executive consumption.
5. Obtain executive buy-in for the next stage – do not go too deep into specification definition until this phase is approved.

Courtesy - Laila Hirr

PLM – Clearer Definition or Problem Solving?

I’m adding another post to my collection of PLM definitions. Gavlin Quinlan came with the blog post on concurrent-engineering blog earlier this week. Here is the name – A Clearer Definition of PLM. I spent 10 minutes reading the blog and material. It points out to the CIMData Whitepaper 10 Questions to ask PLM Solution supplier from the last year sponsored by PTC. The following passage is presented by the author as a clearer definition of PLM:

PLM is software designed to enhance process efficiencies related to a product’s bill-of-materials (BOM) – the core information that tells manufacturing companies how to design, manufacture, and support products. Specifically, PLM software enables manufacturers to optimise the management and evolution of a BOM throughout a product’s entire lifecycle – from concept to retirement. Any and all activities that affect, change, influence, or finalise a BOM are factors that will drive a manufacturer’s overall operational effectiveness and as such are considered to reside underneath the PLM umbrella.

Also, Gavlin note the following: For clarity’s sake, it’s important to note that it is our perspective that PLM does not include the technologies used to author the information that populate a product’s BOM – such as MCAD/ECAD files and engineering/design calculations.

When talking about PLM ROI, author is coming to the definition of functional areas, but most importantly provides the definition of characteristics for PLM system. Here it is - A single scalable system architecture characterised by high performance, effective data replication, and robust security to support the modern geographically disparate company. The system should be integral, Internet based, and interoperable with other company systems.
Seven functional areas are Document, Visualization, Collaboration, Workflow, MCAD Data Management, BOM Management and Configuration Management.

PLM: Network vs. Single System

I found the definition provided by concurrent engineering interesting and here is why? It represents a very popular for the last 10 years approach on a single large PLM suite (or product) that can solve all product development company problems. Just go for that and all your problems will go away. There is nothing wrong in this approach, in my view. In one of my previous I discussed the “singularity topic in PLM” - PLM Network Effect and Single Point of Truth. My take is the “network” is a more powerful system organization compared to the a single system. The web is the best example, in my view.

What is my conclusion? The run for a completeness in PLM definition, requirements and implementation was, in my view, trendy and popular for the last 10 years of PLM. I think, the vendor’s “me too” and comparison of functional capabilities will go away in coming years. What will come as a replacement? My take is following- the capability of solving a specific business problem with a minimum of effort and in a shortest time period. Does it sounds obvious? Yes, I think so. PLM vendors, service providers, please take a note. This is important, in my view.

Courtesy - Oleg

Business Process Management, PLM and Open Source Track

BPM (Business Process Management) is another interesting topic I’m following already many years. I found it connected to PLM and other product development disciplines. PLM usually contains some elements of Business Process Management. I’ve been discussing the topic on my blog early. Look on few previous posts such as PLM Software and Business Process Scalability and How to increase business process technology adoption rate for PLM? BPM wasn’t on the list of hot announcements that PLM vendors are doing these days. It was kind of “considered done” action. Was it that, in reality? I don’t know. Process management is an inside topic in PLM implementation. IT and engineering system management people are interested in how to make it right. The same people can also decide what tools and infrastructure will be used for process management. Does it come from PLM vendor? Maybe IT will decide to use some alternatives in addition to that? Who knows? The decision will be hidden deep in IT department…

Nevertheless, I found the following article in CNET interesting – Open Source BPM startup BonitaSoft raised $11M. For me the importance of the event was mostly because of it is another example in a wider trend – finding simpler and more affordable solutions for complicated problems. BPM is one of them. There is plenty of tools that can be used to get BPM done in a complex way. This is where IT is going. This is where complex PLM implementations are going. I found the following passage interesting:

Gartner explained the market growth by pointing to increased interest in software-as-a-service (SaaS) tools, which offer a cheaper entry point, and a shift toward funding BPM projects from business-unit budgets rather than IT, reflecting an emphasis on BPM’s business benefits.

The combination with open sources creates another confirmation that IT (or even departmental management) is seriously considering such a type of solutions to become part of implementation.

What is my conclusion? Think about mindshare PLM vendors. The solution portfolio they are selling combined from multiple layers, components and functional pieces. BPM is one of them. IT is the organization PLM vendors need to convince as part of their selling process. I think, we can see an evidence of how this pattern is going to change. A simpler and cheaper solution is going to challenge larger BPM vendors. Open source play a revolutionary role in this trend. PLM vendors learned from large ERP companies how to sell solutions to large manufacturing firms. Is it going to change? I don’t know. Just my opinion…

Courtesy - Oleg

How to increase “Business Process Technology” Adoption Rate for PLM

One of the things I see very important is user adoption. We can develop brilliant technologies, but if nobody  uses it, the value of these technologies will be very low. I see Process Technologies as  very important for the Product Lifecycle development… One of the problems I see today is that there is inconsistence between the definition of the Process  and its usage.
I think definition side of “process technologies” works very well. We can define who is doing what and when, how information is flowing and many other details. But as soon as we start this process, many things change. People move, new tasks and changes appear,  and at  the end it’s not easy  to understand  what is going on, how to execute, monitor and manage the changes in this process. Therefore, at  the end, many of processes slap and become  very formal or less usable. So, what can we do in order to prevent it?
I’d propose  three steps that can improve Business Process Technology adoption:

1. Flattering Processes Definition. A process needs to become more modular, simple and changeable.
2. Simplification of the User Interface. We need to remove complexity. Simple… Actually,  users need a list of tasks to perform on daily basis and a list of follow up tasks. We need to massively use mobile and other alternative communications and collaboration tools to allow users to follow up the processes.
3. Flexibility and Change. Changes will come very fast. Life and organizational processes are really dynamic. Process implementation  must allow managing those  changes. It  should be easy-to-make step. We need to be able to re-assign people, change/cancel tasks and to change the process itself. 

So, what do you think?

Courtesy - Oleg

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 separationDesigner 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 SynchronizationHow 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 ProcessesHow 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?

Courtesy - Oleg

What is the biggest PLM challenge?

First I want to state that there are several types of definition in the world for PLM, coming from different type of organizations – I listed here two vendor independent definitions:

The Wiki definition:

In industry, product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from its conception, through design and manufacture, to service and disposal. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise.

The 2PLM definition:
Product Lifecycle Management (PLM) is the business activity of managing a company’s products all the way across the lifecycle in the most effective way. The objective of PLM is to improve company revenues and income by maximizing the value of the product portfolio

The Wiki definition gives the impression that you need to have an infrastructure to manage (store) all product data in order to serve as an information backbone for the extended enterprise. It becomes more an IT-project, often sponsored by the IT-department, with the main goal to provide information services to the company in a standardized manner.

This type of PLM implementations tends to be the same type of implementation as an ERP system or other major IT-system. In this type of top-down implementations, the classical best practices for project management should be followed. This means:

• A clear vision
• Management sponsorship
• A steering committee
• A skilled project leader and team
• Committed resources
• Power user involvement
• Communication
• …… and more …

The following passage is worthwhile:

Instead of being able to implement new concepts or new technology, the implementation became more and more vendor monolithic as other capabilities and applications do not fit anymore. This is against the concept of openness and being flexible for the future. I believe if PLM becomes as rigid as ERP, it blocks companies to innovate – the challenge for big companies is to find the balance between stability and flexibility.

The flexibility is an important topic. It corresponds to some of my previous blogs: PLM out-of-the-box: Missleading or Focusing? and PLM Model: Granularity, Bottom-Up and Change. The ability to deploy pre-configured solution and make an easy change by manipulating multiple elements of PLM infrastructure in a granular way is one of the most important technological aspects related to most of successful PLM implementations. I think Jos nailed these topics in the list of PLM challenges. Here is the list:

-PLM is considered complex to implement
-PLM is a huge IT-project
-PLM requires change and structuring – but what about flexibility
-Where is the PLM value and ROI – user acceptance
-PLM for the mid-market – does it exist ?

Earlier, this year, I had a chance to run Beyond PLM panel discussion during Aras Community Event (ACE). Navigate to the following link to see my presentation and read more comments. Look on the slide from my presentation shows the list biggest PLM challenges as I see them:

What is my conclusion? PLM as it today introduces a significant level of changes in an organization. It can be considered as an organizational improvements and impact organization for the future improvements. However, in many cases, this change is burden organization and people. It is also coming with a significant cost. So, to decrease PLM implementation and future changes cost down is the top priority for all PLM vendors. This is a time to innovate. Just my thoughts, of course.

Courtesy : Oleg,Jos

PLM, ERP and Managing of Effectivity

Conversation about Effectivity is always complicated. There are lots of opinions about how you need to manage effectivity, what system serves the best the purpose of effectivity management and how to solve potential complication when dealing with effectivity management.

Effectivity in ERP vs. PDM/PLM

Effectivity definition originally comes from MRP/ERP environment. The most typical example is “date effectivity” which defines the available to a particular Part/Item. The “effectivity” term is not specific for manufacturing environment. However, I found it useful in many related to manufacturing systems. PDM/PLM originally was created without effectivity in mind. Most of engineering systems are “revision” oriented rather than “effectivity” oriented. It means PDM/PLM is managing different revision of objects (i.e. Parts, Documents, etc.) rather than defines their effectivites. However, with the increased need of integration between PDM and ERP as well as the introduction of PLM systmes on the market, the need to manage effectivity on multiple Bill of Materials int the environment different from manufacturing increased significantly. Effectivity might be defined as a date, serial number or, in a more complex way, as a “unit” (think about a particular car configuration / model).

Effectivity: Part vs. BOM

The difference between effectivity in the context of a Part and the effectivity in the context of a BOM is often getting misunderstood. These two effectivities can be managed independently. Part effectivity scope is only Part itself. An example is a manufacturing part effective from 1-June until 31-August. At the same time, you can define effectivity of a particular part in the context of the assembly. In the case of assembly, a Part can be used in different assemblies /BOMs with a different effectivity.

Effectivity Management

What means management of effectivity? Some of the elements of effectivity management related to the definition of effectivity dates, S/N, units, etc. They are coming as an information from suppliers (in case of standard parts), subcontractors, manufacturing planners, etc. At the same time, there is another aspect of efectivity management related to proliferation of effectivity during the management of Bill of Materials and ECO. One of the examples can be a change of Bill of Material related to the ECO implementation. There are many other situations. They can be very specific and depend on company practices and development/manufacturing processes.

Effecitivity and Different Industries.
Some elements of effectivity management can be different, depends on the industry. Development practices in discrete manufacturing are from electronic and others. In addition, different effectivity types can be applied in case of managing highly configured equipment (i.e. cars, airplanes, etc.)en. The diversity between industry are caused by differences in product development methodologies as well as by differences in data modeling.

What is my conclusion? Effectivity management can be complicated. It can be especially complicated, in the case of multiple environments – PDM, PLM, ERP. The synchronization between systems as well as effectivities updates can be challenging to be implemented. To maintain a consistent system is a crucial part of implementation from the standpoint of a standalone system as well as multiple connected environments. I hope this summary provided you with the basics of the effectvity management. At the same time, I would be interested to hear about your practices in how you manage effectivity in different environments.

Courtesy - Oleg