PLM Software and Business Process Scalability

August 12, 2010

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


PLM and End-To-End Business Process Myth

March 31, 2010

I was reading Arcweb SAP Insider 2010 related to the manufacturing, sustainability and product lifecycle management domains. The tag line “End-to-End Business Process Management” came to my attention, so I decided to go inside and try to understand what SAP is up to in their new PLM deliveries.

The overall document is heavy loaded with general statements about SAP and their investment into PLM program, important customer needs and problems that can be solved by SAP PLM. In the area of new product development, I found three pieces of new release achievements: 1- SAP new user interface; 2- New Project and Portfolio Management; 3- Integrated Development Environment. The last one was related to the information about end-to-end business processes I was looking for.

SAP PLM’s offerings for the Integrated Development environment.  Following the theme of end-to-end business processes, SAP PLM has focused on the need for a comprehensive product development and innovation approach.  This would involve multiple components of their PLM solution portfolio including robust CAD integration, project and portfolio management, single repository for product and process data, and a collaborative development platform that manages role-based IP protection. One of the more interesting offerings in this area is an Integrated Product Development platform for discrete industries and a companion IPD for the process industries.  IPD for the process industries included specific solutions for area like recipe management, material and task sourcing, compliance, and document management.  This follows the trend among PLM providers today to focus on specific industries with tailored solutions sets.

I think, I succeeded to get an idea of End-to-End business processes SAP is talking about. If I will translate to simple words it will contain a single repository for product and process data as well as set of tools and application to work on this data such as Project and Portfolio Management and some others. I still have few important, but not answered questions with regards to End-To-End business processes:

1. How to capture existing business processes?
2. What is the process of “solution tailoring”?
3. How IPD will be integrated with non-SAP modules and tools?

End-to-end business process management is a nice marketing slogan. In the end, there is nothing more than pieces of product and process data that need to stick together. SAP Wizards assumes that they know how to put them together to get an organizational job done by providing a specific tailored solution. Maybe they are right. However, the process to do so will contain lots of small steps related to existing business processes analyzes, integration and customization. I turned me back to one of my previous posts: PLM Best Practices Torpedo. End-To-End Business Processes are set of best practices on top of the single product and process data repository.

What is my conclusion after all? End-to-End processes sound very profound and attractive. However, it seems to me SAP was focused last three years on how to gather all definitions and implementation practices to introduce the comprehensive product portfolio making best practices for customers. The implementation of such can be bumpy and requires lots of energy, skills and the most important – time. The last becomes the most critical for manufacturers today. I’d like to quote another pace from the same write-up: “… that the number one goal for manufacturing companies was to reduce “time-to-profit” for new or changed products...”. With long PLM End-To-End business processes implementation cycles this goal will not be achievable and can easily become Dead-End.

Just my thoughts…
Best, Oleg

Share


PLM vs. ERP: Demand for Business Process

September 2, 2009

Picture 1I want to start today with twitter quote “PLM vs ERP – ERP a transactional system, not suited to manage development of product, integration of all info such as ingredients”. Well, PLM/PDM vs. ERP discussion is old, and I remember it for the last 10-15 years or even more… However, I’d expect some changes in this non-stop confrontation.

The original capabilities of PLM and ERP came respectfully out of their business roots – CAD Design/Data Management for PLM and manufacturing transaction from MRP/MRPII/ERP. However, both domains had demands to grow and make an expansion in organizations. PLM is looking for attractive domains such as requirements, manufacturing, supply chain. ERP is interested to expand toward product development. Both system domains (PLM and ERP) are looking how to establish connected space for enterprise organization business. So, how to achieve it?

I think, very interesting is that both classes of systems are very in favor of business processes. Even if PLM and ERP have a different notion of business processes, I’d say Business Processes can provide good synergy between both systems. PLM traditionally focused on very high level of people involvement in processes. Human based and hybrid processes is something that PLM requires. On the opposite side, ERP is focusing on automation and streamline of processes in organizations.

I think vendors on both (PLM and ERP) sides need to look very pro-actively how adopt Business Process Management technologies. This will be the key to success in organizations. From a technological standpoint, maturity of standards like BPMN and BPEL can provide a solid technological foundation for this work. But, at the same time, both PLM and ERP need to worry about growing capabilities of dedicated BPM vendors. They can take an attractive $$$ from aged PLM and ERP providers and establish strong BPM leadership in organization. I wrote about this in my previous PLM prompt.

So, what is my conclusion today? Business process have strong demand from both sides- PLM and ERP. The road toward successful BPM implementation can be very bumpy for PLM and ERP. Need to watch it out. Multiple vendors can still business and establish success business in front of enterprise behemoths.

What do you think about it? What are your practices with regards to process management in organization?

Best, Oleg


PLM SOA – how to mix integrations and business processes?

August 14, 2009

soa-dangerSOA is a very oversold article these days. Even if, I think, social media and cloud successfully over hyped SOA during last one-two years, on the technological horizons SOA is still a topic that raises discussions and questions.

Wikipedia: In computing, service-oriented architecture (SOA) provides a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as interoperable services: functions provided as a service are available to be used from systems created by other organizations

So, a topic I want to touch today - what could be important components of SOA implementation in PLM. On the ground, Product Lifecycle Management should be yet another enterprise system. Why should we try to understand specific SOA topics? But, if we would take deeper look on what is going behind the scene in PLM, you probably will see what I mean.

One of the very important characteristics of PLM implementation is flexibility. Since almost every manufacturing enterprise organization is different, in the end of the days, you will find yourself making changes in your PLM environment. So, you better will be prepared and have all tools to do so. Another reason is integration with multiple external systems – design, engineering, manufacturing, supply chain. All these systems need to be somehow connected together since they provide ultimate input for PLM. Last, but not least – processes. Processes are flowing across organizational domains and boundaries. To be able to handle them, you need to have an ability to be connected to process oriented environment. It is normally, PLM environment or environment that comes from IT systems (depends on what you have in organization).

So, what is my conclusion? SOA is ultimate answer to provide PLM system configured and flexible. Two most important components of PLM SOA environment are to be able to integration with external systems and manage business processes. I think, PLM SOA having such characteristics will have very good chance to success these days.

Best, Oleg.


PLM Process Management – How many Workflows do we Need?

April 20, 2009

In one of my previous posts, I already discussed PLM process management: Should PLM develop its own process tools?. In reality, I see that companies have many products that have process management and workflow capabilities. Some of them are part of IT platforms (Microsoft SharePoint, IBM WebSphere etc.), while others are part of PDM, PLM and ERP tools. With such a large number of capabilities, I noticed that companies often develop multiple solutions to manage these processes – and these solutions are tightly connected to existing products. From a particular standpoint, it will let customers maximum the reuse of product capabilities and organize a dedicated process management and workflow solution integrated with data managed by a particular system (PDM, ERP etc.). But, one of the biggest drawbacks of that kind of situation is that organizations have multiple silos of disconnected solutions, with multiple process/workflow management implementations.

So my question is how many ”workflows” do we need in an organization? More precisely, I’d like to think about how to organize separated and disconnected workflow and business processes management solutions. Following are the priorities needed to organize this solution:

1. Establish a single process modeling environment

2. Multiple process deployment

3. Immersive access to process /workflow execution in a built-in user environment

A single process modeling environment would user to organize and maintain a single picture of the organizational processes. My preference in this case is IT platforms. Organizations normally chooses one IT platform, so having an environment in which to model processes makes a lot of sense to me. Consolidation around popular notations such as BPMN can let you use 3rd party tools, in some cases, if they provide additional benefits in managing of single process model.

Multiple process deployment can resolve the procedure of integrating processes into many existing systems. This depends on the specific system deployed by the company, and can be done in different ways – but the goal here is to keep the process connected to specific solution as much as possible (i.e. product data management and/or any vertical solution in the organization). This will allow existing systems to maintain the connection with data management using this system/sub-system. Access to this data is very important since most of process logic, in many cases, depends on this information.

Most of the processes require user involvement for control and data submission (i.e. document approval, ECO management etc.) Immersive access to process/workflow execution and control from the regular user daily environment is critical – because this is what guarantees the user’s acceptance. A process solution will be live only when customers will use it rather than bypass it.

So, where do you start? 1- Analyze what system can be used to keep overall control of processes in the organization; 2- Choose process modeling tools; 3- Analyze how to connect multiple workflow and process management solutions that already exist in the organization; 4- Give priority to solutions that have immersive integration in the user environment.

As usual, I’m open to discuss this and am interested to know what type of solutions you have and how you organize workflow and business processes within your organization.


Process Thinking with the Development of Social Collaborative Business Processes for PLM

March 6, 2009

I’ve been thinking about how a company can use business process tools to manage their processes. In one of my previous posts, “How to improve PLM process before PLM system using BPMN,” I discussed the possibility of using process tools supporting BPMN to capture business processes in the organization. One of the key ideas in this post was that you can use BPMN tools to capture process definition, and later, to implement these processes using tools and systems you already have in your organization. PLM and dedicated BPMS products are systems that can be used for this process implementation.

 When I started to think about how process capturing may occur, I came to the conclusion that the business process capturing process is very painful for an organization. As for product development in a manufacturing organization, this process can differ greatly from organization to organization. So process capturing is natural step for the organization when they implement Product Lifecycle Management and create a collaborative business process environment. 

What we can do to change this? One of the ways is to reuse the practice of social networking and crowdsourcing for process capturing. My key point in formulating this conclusion is that process development knowledge in an organization is spread over many departments – engineering, manufacturing and others. It is very problematic to have people efficiently involved in capturing their existing processes – too many people, too much time… Also, people are busy running their businesses and claim not to have time for processes capturing. Allowing all people in the organization to be involved in ‘capturing processes’ which I refer to as “Process Thinking” changes the rules of the game. With everyone involved, people are able to do multiple reviews. Step-by-step adjustments can make a significant change in the product development process implementation for PLM. In addition, this process can improve people’s process adoption. Socially created processes will reflect the existing processes accurately. Afterwards business process management tools can optimize and improve existing processes. 

How can we make this happen practically? The answer probably comes from software providers. What if process tools were to support a staged process of continuous process changes? Each person would be able to adjust the process to reflect the way people manage their work. Allowing everyone to vote and approve process changes will let all people be involved in the process definition possible right from the beginning. Another important achievement would be an increased trust in the process definition – normally, people trust something more if they were a part of it and defined it collaboratively together.

 I believe that you may have some experience in this by trying to centralize the definition and approval of processes. However, making process definition open and transparent for all people in the organization can allow PLM companies to leapfrog the overall adoption of PLM systems in an organization.


Should PLM develop its own process tools?

February 20, 2009

There is no discussion – PLM is very oriented towards processes. In order to be able to coordinate multiple organizational activities around product lifecycles it seems like process tools is  a “must to have” component in PLM tool box. But is it really true?

In today’s world, process tools are becoming available as part of many non-PLM products. Starting as workflow automation, process tools were developed and/or acquired by platform vendors (IBM, Microsoft and others). Large ERP vendors also provided process tools as part of their packages. In addition to these big behemoths, many BPMS (Business Process Management Suites) are focusing on process definition, execution and improvement. In addition, some standards initiatives around BPMN and BPEL are also focusing on process management and tools.

So where does PLM play into this game? I see two possible options: (1) PLM providers will focus on the development of process management tools; (2) PLM providers will allow the integration of PLM information and IP  (Intellectual Property) into existing process tools provided by platforms. I believe that option #1 will be very helpful in integrating PLM systems into the enterprise software already available within the vast zoo of software within the organization, option#2 can simplify deployment and and keep the implementation of PLM simple.

From a customer’s standpoint,  I see great significance to maintaining single organizational process. Therefore, a promising alternative is to align the PLM process implementation with the growing adoption of standards like BPMN /BPEL. This allows customer to run multiple tools around the same process…

 



Should PLM Fit Business Process or Change it?

November 30, 2008

If company business processes need to be re-engineered it’s a management decision. Now the question is if we would like to make this decision part of the process for software purchase? I see two opposite approaches: 1/implementation of the best practice system which will require changes and, as a result, improvements of company’s business process; 2/Adaptation to existing processes with the future capability to improve and optimize. There are some pros and cons in both directions:

Implementation of the system best practices: Pros – better process engineering, optimization, ability to bring existing best practices. Cons’ – changes of business processes and need for management decisions potentially will cause implementation to be delayed and increase chances of failure.

Adaptation to existing processes: – Pros – potentially shorter implementation cycle, fewer organizational changes; Cons’ – tendency to automate obsolete and non-efficient processes.

Your comments are welcome.


Follow

Get every new post delivered to your Inbox.

Join 71 other followers