PLM: Controversy About Process vs. Data Management

November 16, 2011

Process vs. Data. I think, this topic not requires a special introduction. In my view, every PLM implementation is facing this discussion and requires to take a decision about how to proceed. Few conversations with customers during DSCC 2011 last week and some articles I read on the long flight from Boston to Europe during the weekend made me think again about this process vs. data controversy, and I wanted to share my thoughts with you.

I was reading Capgemini blog post Business process management and mastering data in enterprise by Nicholas Kitson. Nicholas is talking about interesting aspects in failure of Business Process Management (BPM) implementations he experienced with customers. In the beginning of the artcicle, Nicholas quoting Gartner analyst Michael Blechar: “A failure to address service-oriented data redesign at the same time as process redesign is a recipe for disaster.”

I found this notion of “recipe for disaster” as something very important. In people’s mind, PLM system was a recipe for disaster. Even today, after the value of PLM was confirmed by many organizations and implementations, lots of people are still questioning about how to approach PLM in a right way. To continue with Capgemini article, I found the following passage very interesting:

While BPM tools have the infrastructure to do hold a data model and integrate to multiple core systems, the process of mastering the data can become complex and, as the program expands across ever more systems, the challenges can become unmanageable. In my view, BPMS solutions with a few exceptions are not the right place to be managing core data[i]. At the enterprise level MDM solutions are for more elegant solutions designed specifically for this purpose.

I found an interesting connection between this statement, and the presentation made by Bell Helicopter during Dassault Customer Conference last week in Las Vegas. Bell Helicopter embarked on the journey to implement Dassault newest V6 platform, and I was impressed by the presentation they made. You can see the following slide introduced one of the biggest problems in Bell’s organization back in 2005 was a significant need to modernize processes in the organization. They found that processes are too fragmented, and 467 legacy systems create a significant data and enterprise complexity.

The critical strategic decision made by Bell was to make PLM implementation first. Part of this strategy was so-called “get the core [product] data right first”.

PLM – Focus on Process

Since the industry focus move from PDM to PLM over the past 5-10 years, the question about what is the focus of PLM implementation emerged as something important. Until that time, most of the companies understood the value of PDM. Even despite PDM implementation complexity, the value of having the ability to vault CAD data and manage changes was mostly not disputable.

At the same time, I cannot say the same about management of product development processes. Let’s take Item / BOM and Change Management. Many PLM systems were “pushed” to manage BOM and Changes. However, in practice, it creates many problems. Bill of Material data (especially if you think not only about BOM from your CAD drawing) normally spread out multiple systems- PDM/PLM, ERP, Supply Chain Management. ECO is a process which clearly crossing multiple departments and data islands in an organization.

So, PLM system was pushed to be “focusing on processes”, and this push was very problematic. Sales and marketing were focused on promoting of the values of PLM to the companies. In practice, many organizations faced significant level of complexities to have, for example, change management process implementation across the entire organization. Why so?

PLM: How to streamline the data access

In my view, every manufacturing organization experiences a complexity of data. Data is overwhelmed. According to some industry researches, the amount of data volumes in organizations will be growing x44 times for the next 10 years. The question of managing data is long time in the spot of all PLM implementations. Very often, this question presented as “who owns part, BOM, etc.?”. The same question, but asked in a more intelligent way can sound like “who is mastering Part, BOM, etc. information”. The hidden question, I hear is the need to streamline data access related to these processes. This is a vital part of every PLM implementation.

The latest trend in this space is “unification”. PLM vendors are trying to push everybody to so-called “unified PLM platform” that will consolidate all data in a single place. For PLM vendors like Dassault, PTC, Siemens, it was “all except ERP”. For ERP-based PLM providers it gives even stronger voice of why PLM-ERP bundle may have an advantage.

The question, “how to streamline access to data” in the organization before you embark to the journey of process improvements is the key question that needs to be asked by all manufacturing companies. Without that, most of the “process improvements” and implementation will stack forever or will turn to a nightmare.

PLM and the promise of cloud applications

Cloud is hyping these days. It is not unusual to hear that cloud will solve the problem of complexity related to existing software in the enterprise. Here are few examples:

Dassault is talking about their V6 platform as a unique cloud platform (last week Bernard Charles, DS CEO mentioned $2B investment made into re-architecture of Dassault platform).

Another large company in engineering domain – Autodesk is just a week before making a significant announcement (see more details here). I found this quote interesting: Autodesk will forever improve the way you manage your business processes and workflows when we unveil a modern, zero deployment solution that makes collaboration, data, and lifecycle management accessible to anyone, anytime, anywhere.

Another new comer in this market – Kenesto (according to COFES 2012 registration, Mike Payne is CEO of Kenesto) promising to “revolutionize process automation“.

What is my conclusion? I think the failure to design data access in organizations, was a recipe for disaster for many PLM implementations. PLM programs were focused on “how to improve processes” and forgot about how to put a solid data foundation to support cross-departmental process implementations. So, I’d like to put a quote from Bell Helicopter’s presentation during DSCC 2011 as something PLM vendors and customers need to remember – “to get the core data right first”. Just my opinion, of course. YMMV.

Best, Oleg


PLM Processes, Lists and Implementation Confusion

December 7, 2010

I read the following blog post by Christine Longwell – Do we really need structured workflows if we have visibility and status? In my view, the question asked by Christine can be heard very often from customers trying to decide about PDM or PLM process management. I specially liked the following passage from Christine’s post:

One of the major objections to implementing a PLM system is that it is going to tie a creative organization into a structured workflow that can slow down their process and ability to react. If the process is too strictly structured, people start looking for ways around the process when “special situations” arise. A major deadline, build stoppages on the manufacturing floor, unexpected audits, or irate customers can all be reasons to go around the process and not wait for the standard Friday Morning design review meeting to get designs released.

What if we assume that every design change is driven by a special situation, and allow them to all “flow” naturally? I believe it’s possible to use tools that facilitate real time, collaborative communication and status on issues to treat each problem differently, and come to the right solution more quickly.

I found very interesting to comparison of two opposite things – structured workflow and real time collaboration. The confusion between them, actually, leads to some implementation difficulties and potentially wrong conclusions about tool selection.

Design Collaboration
Product development has many different stages. On the very early design stage, people can collaborate freely without any special constraints and dependencies. This is a time when "designer" is a king. Designer can make any change. However, if a team of people involved into this processes, they definitely need to collaborate (=work together). So, this type of "design collaboration" can be characterized by a very non-formal relationships and communications. The most widely used tools for such communication is email. I don’t think that email is actually the most optimal way to collaborate, but ease of use and wide spread of emails make it an obvious choice. Managing of the emails can be a difficult task for every person. In addition, email becomes very inefficient when you work with CAD systems. Because of technical constraints, you cannot always use attachments, and it causing losing of context in communications.

Change Processes
When product development moves to the next maturity phases beyond the design, communication between people in the organization becomes more complicated. It, obviously, requires more people to be involved to the processes of changes. At this time, changes are controlled by a group of people and requires some synchronization before any change may occur. It may happen when a product is actually already manufactured or, for example, during the advanced stages of "engineering to order" manufacturing. Such situations require more coordinated work between people in different departments, which normally is going beyond just "raising hands" or "sending emails". The most often used procedures at this stage are "approval processes". PDM and PLM systems have an ability to make such implementations.

Processes and Tasks
One of the obvious outcomes of processes and workflow implementations is the need to manage lists of tasks for people. When it comes to "change approval" or "change implementation", the need to manage tasks becomes critical. The important element of process management is the ability to make tasks visible and transparent in the organization. It includes task assignment, task distribution, follow up and changes. A good process or workflow tool needs to provide ways to accomplish that. User interface is an important element in the process implementation story. As a user, I need to have my tasks to show up. List views are one of the most obvious ways to do so. That’s why, Microsoft Excel becomes popular. However, the ease of list creation in Excel is combined with a complicated way to maintain collaborative changes, assignments and follow up. Microsoft SharePoint with Excel Services provided an interesting approach to manage Excel lists. Other alternatives can include "work management" or "task management" tools. Lists are still a very important element of user interface there.

People and Processes
The most complicated element in all process implementations are people. To capture processes is not a trivial task. Processes can be undefined, fuzzy and even conflicting. Process Management, normally, cannot solve problems related to the process capturing and organization. The flexibility of tools is an important factor here. However, even with a full flexibility, this process can go wrong.

What is my conclusion? The requirements can be different depends on a type of communication. Design team can collaborate via phone, email or Excel spreadsheets. When it comes to more complicated communication, process management and workflow tools need to be involved. However, ad-hoc collaboration, structured workflow and even a very sophisticated processes management tool, can use a simple list-based user interface concept to communicate with users and provide task visibility. Just my thoughts…

Best, Oleg


PLM Philosophies Collide

September 29, 2010

Somebody asked me last week about how I see th future of PLM… Does it look like-BOM or like-Workflow? I found this question very interesting. Bill of Materials and Workflow (or process management) are fundamentally two most important pieces of PDM and PLM systems for many years. So, we have them already in place. However, thinking about the future – what will be a dominant solution? Do we need re-invent the wheel? Is there any conflict here? I want to elaborate about both to see what future PLM looks like.

Bill of Material World

BOM is considered as a foundation of design, engineering and manufacturing. You can see it everywhere – design BOM in CAD system, Engineering BOM, Manufacturing BOM, Support and Service BOM. You can follow a product lifecycle by discovering different bill of materials. You can find lots of methodologies and systems that help you to handle your Bill of Material world. These things are really complicated. Bill of Materials represents many issues related to product development and in the end of the day you can think about a virtual Bill of Material representing everything.

Workflow World

Processes (or how we can simply call them Workflows) are very important for an organization too. They are a life blood of every manufacturing organization. Organization is running business processes and making overall execution of the business. We can classify them as local and global cross-department. Local are mostly focusing on departmental processes. The more interesting and challenging thing are cross-departmental processes. These processes are connected people working in different departments. Cross-departmental processes are very important if you think about the overall product lifecycle.

PLM Philosophies Difference

So, why I put BOM world against Workflow world? You can draw your organization in terms of Bill of Material and, at the same time, in terms of organizational processes. Is it about philosophy or about real development practices? In the early days of PDM and PLM, the main focus was absolutely on files, data management, revisions, Bill of Materials. Later, PLM system discovered “process world”. This “discovery” was part of the competition between PLM and ERP world. PLM systems made an upscale to compete in the high society. The “process approach” presented organic change to fit product development processes in organizations.

What is my conclusion?

I think, this question represents one of the biggest philosophical collide in engineering and manufacturing software. What will be the winning behavior in the future? It is hard to say. In my view, the end-game solution will need to provide answers to both sides of the problem. BOM and Worklow need to be equaly included into PLM solutions. Only together they can keep an organization to manage efficiently product lifecycle. Just my thoughts. What is your take?

Best, Oleg


Should PLM Disconnect Data from Process?

August 27, 2010

I had a chance to read an article byebizQ related to Cordys BPM. For those who is not aware - Cordys is a relatively new outfit in the enterprise software market. The wizard name behind this company is Jan Baan. If you are a long-time citizen in the enterprise software domain, you need his first ERP company - BAAN. These days Jan Baan is very active and Cordys is one of his new babies. In his interview, Jan is discussing his long project related to decoupling of processes. The following quote seems to me interesting:

… ending the data-process dependency is easier said than done. Suppliers attempted it using extremely fat clients at one extreme and sophisticated distributed data with replication at the other.

Process Decoupling

For a very long period of time the concept of “a process needs data” were dominant. Multiple BPM vendors claimed that the only way to make BPM successful is to bring meta-data (and other data) into BPM product suites. I can agree, this strategy seems to be successful if you plan is to create integrated enterprise software suites. However, thinking more about Internet technologies and lean architectures it makes much more sense to make a disconnection of data and process.

PLM: Process vs. Data

In my view, PLM Software vendors are definitely moving towards better vertical integration. Users are asking PLM companies for a better integration between products, and PLM (and not only PLM) companies are starting to couple products and solutions together to ensure customers will spend fewer resources tailoring these solutions.

What is my conclusion? I think, enterprise software vendors can miss the dangerous point of data and process connection and interplay. When most of the enterprise companies use data to lock-in customers in their product suites, the addition of processes seems to them as a natural continuation of this strategy. The real danger of these strategies is a large complicated software products and extremely high cost of changes. Just my thoughts…

Best, Oleg


PLM, Social Silos and Information Streams

March 25, 2010

I had chance to read the following blog post on IT Business Edge – Oh No, Social Medial Creates Even More Information Silos. . It made me think about process interaction into enterprise organization. What I like very much, is a definition of social channels. This is a short quote from the article:

Social channels are repositories of siloed information just as often as traditional enterprise applications, if not more so. At least with enterprise applications, companies recognize the need to integrate different data streams, have been cracking away on the problem for years and have enlisted support from vendors. (Sure, sometimes the “support” seems like little more than lip service, but vendors largely do try to offer integration when and where it makes sense.) IT Business Edge’s Loraine Lawson last week wrote about the growing need for companies to consolidate information from various social channels in one place, perhaps on their Web sites.

This fits my view on how processes will be organized in the future. The biggest problem of process organization, as I see them is their absolute inability for self organization. I see process management as somewhat half successful in the systems like CRM and ERP. However, it becomes an absolute failure when it comes to the engineering space. Why, I think, it happens. The main problem is the very informal way of communication during product development, engineering and manufacturing. In the CRM and even ERP domains I can always identify “push event” that can trigger a process. Opposite to that, in engineering, the type of the communication is more in the “pull” mode. The most popular collaboration and communication tool in the engineering enterprise is the email. However, information and communication overflow is the biggest problem of process communication in the enterprise manufacturing organization.

Organization of Social Information Stream is an interesting idea. I came to that looking on how multiple social tools successfully promote information flowing between their members. Think about Twitter lists, for example. If you’ll “twit” from the side of various actors in your engineering organization, you probably will be able to organize your communication in a better way. In addition to that, PLM organization is pretty much siloed. It prevents PLM from the efficient organization of process and data management. Maybe social information streams using social websites collaborative approaches, is the way to go in the enterprise? If I’ll take this idea forward, my next step will be probably to define “twitting actors” in my product development. Subscription to these “actors” will allow me to flow in my product development information streams.

What is my conclusion today? The communication in the enterprise organization is not a simple task. Today, email is still the king of the road. The real advantage of email is that you can consolidate your information streams in the single place. However, you easily can get to the point where your single email stream is overflowed and become inefficient. Email is a typical “push” process model. I think tomorrow’s PLM will be using the “information stream” concepts to better organization communication. The content and context of these streams will be very important to make it useful… The future talks!

Best, Oleg

Share


Next PLM Challenge: To Connect Process and Communities

December 9, 2009

Social is growing. During the past two years, we had seen many new topics introduced by social computing – social networks, communication, collaboration. A bunch of product were previewed, released… and already failed in this space. Enterprise 2.0 is growing as a separate and very interesting industry. The most visible social computing related movements in Product Lifecycle Management are DS Social Innovation and PTC’s Social Product Development – both pushing the power of social-network-like elements into PLM mainstream. I tried to analyze potential challenges in various aspects related to adopting of social software in Product Lifecycle Management and would like to share my thoughts and conclusions.

1. Organizational Social Network. With increased potential of social software, various communities of people will be established in the organization. They exist today. However, no software that can present it and support their activities. Transformed from various forums, portals, IM, wikis and other forms, these community building tools will play a role of “facebook of enterprise organization”.

2. Social Network interaction with Organizational Processes. Growing community activities in the organization will continue to take power of interaction between the people and. Therefore, questions of how business and organizational processes will be integrated into this communication will be raised very loud and very soon, in my view.

3. Community and Business Process co-existence. Ability to balance between well-defined development, engineering and other business processes compared to social intercommunication will become very important. Cannibalizing of each of them – communities or processes, can be very painful for organizations.

So, what is my conclusion today? Social networking in various appearances will be growing in enterprise and manufacturing organizations.They will become visible on different levels. The biggest potential mistake is to see them replacing “organizational business processes”. However, failing to establish a successful process management system (especially in development, engineering and manufacturing organization) can emphasize the role of social networks as a potential major process driver in an organization. To make it successful PLM needs to have a goal to connect organizational business processes with social networks. So, community-based interaction will be directed to replace business process management.

Just my thoughts. I will be looking forward to your comments.
Best, Oleg


Product and Process Models in PLM – What Should Come First?

December 3, 2009

Common definition of the process – “a set of activities leading to the desired outcome”. Despite on such simple and straightforward definition, implementation of processes in PLM delayed and very often lead to a significant complexity in implementation. I’d like to analyze and discover why it happens and what other factors can influence process implementation in the organization.

Process Model.
It depends on tools, technologies and environment customer has, processes in the organization can be modeled and implemented differently. Normally, there are more than one enterprise systems in the organization that is able to handle process modeling. Starting from middleware and specialized BPM software, following by enterprise systems such as ERP and PLM and ending with various Enterprise 2.0 collaboration tools. Process model, these days, can be developed by multiple tools. For the last few years, BPMN becomes somewhat similar to the standard process definition tools. What is the main problem? Data. Various products and corporate data needed to be injected into process implementation to make it work.

Product Model.
Originally started from CAD models, product model developed as an extended set of information describing various aspects and dimension of product – model, bill of material, requirements, items, information about customer requests etc. As we learned from process model definition, this specific product model information is needed to make process definition. Processes actually need to access data to trigger tasks and events to handle processes.

So, what should come first? Product or Process? My conclusion is that lack of the rational product model can drive to a very high level complexity of process definition and implementation. Product Model is the foundation of product lifecycle. Without a well defined product model that can cover enterprise product definition scope and related disciplines, development of a process oriented PLM environment becomes a complex and not achievable task. Organization implementing PLM as a process environment needs to invest first in implementation or adoption of the product model that will be used as a process foundation.

What is your opinion? What was your experience in similar tasks and efforts?
Best, Oleg


PDM vs. PLM – Is this about Process?

September 21, 2009

I was reading interesting article during the weekend- PLM & The Importance Of Process by Gary S. Vasilash. Gary is the founding editor of Automotive Design & Production (AD&P) Magazine.plm-vs-pdmThere are few very interesting points were made by Gary and I liked it very much. Gary is discussing PLM topic with Twila Osborn, Lean Manufacturing and PLM, Computer Sciences Corp. (CSC; csc.com). Started with a solid statement came out of CIMData about strategic importance of the process for PLM, later Mr. Vasilash made some very important notes about handling of design data and BOM. “Who owns BOM?” Excellent questions.”The BOM is a corporate asset, not an engineering asset.” Sounds like PLM is the best candidate to own Bill of Material. However, a conclusion made immediately after mentioned that PLM companies (like DS and Siemens) invested a lot in Design Process, and it really works today. What sounds to me, BOM story is not as completed as a design story for PLM systems. You can hear a lot of “buts” when you start to discuss BOM story of PLM. “The mindset needs to change; it is not just CAD data.” About most of PLM implementations in organizations - “It might be very old, out of date. It might not have an integrated BOM. Some have BOMs based on proprietary technology, built from scratch. They might have a PLM system, but they’re using it as a PDM system.” A lot of “buts.”. What is very remarkable is a short review of top three PLM vendors (DS, PTC and Siemens). Unfortunately, this summary is corp-marketing-publishing-fully-buzzword-compliant. What will be very interesting is to find analyzes related to who owns Bill of Material and how to manage a BOM and related process beyond engineering on the corporate level using standard PLM systems.

But, I’d like to get back to the original topic - PDM vs. PLM. I asked many times about what is the difference between these two from customers, on conferences and during professional meetings. I think, professional community made a tremendous job in trying to explain it, but these two domains are continuing to confuse users.

I thought about few definitions to make before:

Product Data - product design, bill of materials
Product Data Changes - ECO-related information including design and Bill of Materials.
Product Lifecycle - information and process-definitions related to global product development stages.

I think PDM is definitely about first two. However, getting back to Mr. Vasilash’s - “The mindset needs to change; it is not just CAD data”. As soon as we can come to matured Bill of Material implementations (not home grown as it today), PDM will become mature to manage a complete scope of Product Data Changes and not only Design portion.

PLM definition is very fuzzy, in my view. However, this is definitely about how to move from Product Data Changes to Product lifecycle and corresponded to organizational processes. There are many business process management software suites (BPMS). However, all of them won’t be able to provide a relevant answers on product lifecycle. Because “product data” is a key asset that needs to be taken into consideration to manage organizational processes around product.

This is not the first time I’m touching this topic. I’d be interested to hear your voices and comments.

Best,
Oleg


PLM Prompt: Dynamic Business Application and Design Collaboration

September 9, 2009

During last week, I had chance to discuss PLM, Design and Business Process trends. The core idea behind was about how we can apply business processes in the context of design application and collaboration. I had chance to take a look on Forrester’s Dynamic Business Applications imperative. The idea of processes built for change as well as “context” is very co-sound, in my view, with designer work. Even most of Forrester analyzes were done in the context of MS Office application, I think it can be applied to Design Application as well. The core idea, if I got it right, is to be able to have flexible contextual information to make a business process decisions and this contextual information comes from interactive and visual communication.

forrester-dynamic-business-apps

What do you think about it? Does it make sense to define adaptable contextual design application that has an ability to inject business data?

Best, Oleg


What is the right time to implement PLM Workflow and Processes?

July 23, 2009

PLM-process-workflowEvery time I’ve been talking with customers about processes, work flows and PLM, the conclusion was that one of the important factors of process implementation is to choose right timing. You need to have company ready to think about process improvements. So, the point was very clear – to change business processes in organization is not simple. To make it happen you need to have all stakeholders on board and do it with timing, which will be aligned with overall organizational changes.

In today’s turbulent time, many companies are thinking about rationalization, improvement and changes. So, I think this should be right time for companies to think about PLM processes in organization. I want to propose a possible 3-steps plan to achieve it.

Step 1: Make analyses of existing organizational processes. To focus on these processes that require improvement first. Capture existing process definitions with process/workflow tools you have in your PLM systems.

Step 2: Plan your data and IP management for these processes. Your processes and workflow can work efficiently only in the case they will have access to the right data. Without accessing right data, your processes will not reflect reality, and you will not be able to follow them as well as use them for your decision support. So, by creating right data modeling and/or connecting PLM system to right sources of data, you will prepare solid basement for good process orchestration.

Step 3: Optimize and run your process/workflow environment. As soon as you existing processesand data in your hands, you can start planning process optimization and executing. This is time when you will need to analyze captured processes, make improvement and right first pilot and second production environment.

What is my short conclusion? Use right timing, capture and improve your PLM related workflows and processes now. You will  be able to optimize your organization now and be prepared for future growth.


Follow

Get every new post delivered to your Inbox.

Join 73 other followers