PLM: Controversy About Process vs. Data Management

by Oleg on November 15, 2011 · 19 comments

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

Share

Tagged as: Autodesk, Capgemini, Dassault, Data, Kenesto, PLM, Process

  • Hakan Karden

    Hi Oleg,
    this is the reason STEP and even more so new standards like PLCS and AP233 for Systems Engineering data are designed as they are. While the PDM/PLM vendors have focused on process support, others have spend time standardizing product data information models. This is becoming more and more relevant. Some process support have made systems impossible to upgrade because of too much customization.

    Large OEMs/MODs etc are asking for independence from PLM vendors, no vendor lock in, open data etc. One of the best examples are long term archiving and retention of product data - 100+ years for aircrafts etc. With this in mind the value of data becomes obvious. Also, when PLM is realized cross domain and cross organizations the value of data becomes obvious. Processses needs to change to enable agile business. IS/IT as well. Data is the foundation for this so cannot be locked in – has to be open and based on standards.

    My take,
    Håkan

  • beyondplm

    Hakan, thanks for your comments! I think you are making an interesting connection about a potential value of standards to redesign data services in an organization before process improvements. The problem I see in this approach is a high complexity and diversity of data. Similar to “big-bang” PLM implementation, move to PLCS or AP233 data models can require a significant effort. What is your take on effort and risk of these implementations? Thanks, Oleg

  • Hakan Karden

    Oleg,
    My take is that PLCS/AP233 does not have to be Big Bang.
    Switching PLM (and ERP) systems are BIG BANG.

    As Share-A-space is designed using these standards we know this. Legacy systems can be integrated easily using Excel, csv, web services etc. Then PLCS is used as the Canonical format and a road map. Enterprise product data, across the product life cycle and extended enterprise is complex and requires attention and governance.

    By focusing of STEP/PLCS and data and decoupling this from processes and IS/IT existing processes and IS/IT can remain in place. Much of the cost with classig Big Bang is with training, processes and authoring tools. This is why classic PLM and ERP are endless and expensive truggles.

    Cheers,
    Håkan

  • http://twitter.com/sddinabq Steve Denman

    Hakan,

    I would suggest that your argument for the importance of standardizing data representation is a valid one. And, it's been going on now for decades.  I was involved in extensive efforts to develop standard engineering, manufacturing, and service data representations in the mid to late 1980's.  IGES was a big buzz word at that time.  I've been involved in engineering lifecycle management and related activities ever since then and the buzz words just keep coming… and going.

    My nearly 30 years of experience with both data and process standardization efforts leads me to both agree and disagree with your position.  I'm in agreement with you that focusing on process (business, engineering, manufacturing, and/or service) alone can lead to captive data silos across the organization.  However, I think your claim that “legacy systems can be integrated easily using Excel, csv, web services, etc.” is revealing.  I mean no disrespect at all in stating this.  I simply want to point out that patchwork legacy system integration has already been tried and has failed miserably.  In fact, it's been tried almost everywhere, in nearly every engineering/manufacturing company on the planet that is large enough and has been in business long enough to have accumulated numerous partitioner, PLM, ALM, ERP, and MRP automation tools.  

    Data interchange standards certainly help, but they aren't the answer either.  I realize that you're suggesting more than just the standardization of data for exchange purposes; That you're proposing standardization of the data where it is stored.  If I'm not mistaken, the end of this approach would be that, no matter what vendor solution you employ for ALM, PLM, ERP, MRP, and so on, the underlying data would be stored in a standard form.  This should make it far easier to migrate form one vendor tool or solution to another as the need arises since there would essentially be no migration effort, essential just plug and play tools.  It should also require nearly zero effort to exchange the same data between systems, yes?  After all, the organization's “crown jewels,” as you suggest are not its processes, they are the data itself.  

    Here's the thing: If that last claim is true, and I believe it is to a large extent, though I think organizational processes can and should also be a source of innovation and competitive advantage, this is exactly where we do NOT want to apply rigorous standardization.  Why?  Because it's part and parcel of the tool vendor's means of innovation.  Many point fingers at tool vendors because of their use of proprietary data storage formats, but the underlying representation of data in an automation or practitioner tool is part of their means of innovation.  

    In fact, I believe that it is equally incorrect to focus on data standardization in the underlying storage mechanism of tools and expect a better result.  I think we need to recast this discussion (not just the here on this blog, but the larger community discussion) on finding a better way to deal with both problems.  Not surprisingly, I work for PTC, a provider of PLM and ALM solutions, among its offerings.  You might say, then, that I'm just biased because of that, and fairly so.  Here's the rub: I've worked in both communities and found that the problem each is trying to solve with its respective approach is actually the same problem, perhaps cast a little differently from one point of view or the other.  In the end, I think it's the same problem that we've collectively been trying to solve now for at least 30 years (really much longer than that but I can personally speak to the last 30 years from my own experience).  

    I believe that the problem we are all trying to solve is how to enable large organizations, including business, engineering, manufacturing, and service, to work in a way that encourages rapid innovation while getting high-quality products to market quickly, remaining in compliance with endless regulations, and managing middle-line costs, so that at the end of the day, there is enough money on the bottom line to satisfy our shareholders.  

    To do a better job at this, original equipment manufacturers, customers, and supply chain partners need to successfully face-down a number of key business challenges as alluded to previously.  How to do this successfully?  Standardization on a number of fronts (process, methods, tools, data, …) is part of the formula for sure.  But, we can't overlook the “innovation” factor as this is key to a healthy free-market economy and the primary ingredient that allows those economies to grow.

    The trouble with standardizing everything, or even most things, is that it tends toward making all the players look the same, act the same, and thus deliver nearly the same products and services.  So, how does a company that wants to keep innovation alive, or perhaps even increase the rate and volume of it, address the rest of the business challenges while not killing the most important one?  Well, it's probably some combination of standardization and agility.  OK, then what do we standardize and what do we leave to individuals to do their own way in order to keep innovation alive?  Process, method, tool, and data standardization, and integration where standardization is not the right answer or not possible, seems to make sense.  If done right, it seems that, in addition to helping us control cost, get products to market faster, improve product quality, and streamline compliance, this could even enable the organization to be more agile, more responsive, and ultimately more innovative.  Well, most, if not all of us, would agree that we've certainly seen this kind of  standardization done the wrong way. ;-)  What about the right way?  

    Maybe this is just 30 years in the trenches speaking, but I'm not even going to try to answer that question here, or anywhere else for that matter.  I'll just say that the same 30 years in the trenches tells me deep in my gut that the answer will not lie in exclusively focusing on one standardization approach or another, one best practice or another.  It's going to be more holistic and it will certainly involve lots of innovation, just as our customers and the users of our standards must do.

  • http://twitter.com/sddinabq Steve Denman

    Hi Oleg,

    I'm fascinated by the presentation slide photos in your post.  In particular, I'm interested in the approach of doing PLM first, THEN ERP.  I would really love to get more information on what was meant by that statement; What drove them to that conclusion?  And, in asking, I'm not suggesting that I think this conclusion is wrong.  In fact, I think it is largely correct, for my own reasons, and would like to understand their reasons.

    Also, I found the third bullet under “Why did the business take this on?” to be stunning!  The first two bullets are the same ones I see every time we talk to a customer or deliver a presentation, in some form or another.  

    But, the third bullet… Well, not so much!  I wish more chairmen and CxO's would do this!  I think 90% of them would run from the room, screaming, long before they got done with the exercise, go straight back to their respective offices, and start making calls.  Lots of calls.  I suspect that budgets would we adjusted accordingly and practically overnight, and that we would finally begin to see significant, measurable progress in enabling our engineering, manufacturing, and service organizations to get their jobs done!

    Finally, can you expand the 'BSM' acronym for me?

    Thanks!

  • beyondplm

    Steve, thanks for your comment. The main point of Bell Helicopter was how to organize the large big-bang project of implementing multi-system environment to replace 400+ legacy systems. It contains four systems (see attached slide). The question for them was how to start and what system needs to be implemented first. Their conclusion was that “data” about products is the fundamental piece and needs to be done (implemented) first. After PLM they shifted effort to other systems. I hope it helps. Best, Oleg

  • beyondplm

    Hakan, my problem with standardization is that application of standard data and processes is leading to organizational mediocracy. From the beginning, you may think it is not true. The first time I thought about that was when I was involved into implementation of so-called “best practices”. “Best practices” was an invention of sales how to sell packaged solutions to enterprises and take down the cost. However, it ended up with pure marketing. Customers were loving to see functionality, but still wanted to customize it. So standards don't work  in this aspect. In my view, the future belongs to “flexible” and “granular” systems that can be adapted in a very easy way to any environment. Just my take… Best, Olegthe

  • http://www.facebook.com/snisargs Nisarg Shah

    Since the acronym has not been explained… here it is:

    BSM stands for Business Systems Modernization. And I think it is self explanatory now.

    One of the primary reasons why Bell desperately wanted to get to a “better” state was because of the legacy involved in its prior implementations. This project has been a massive effort to address that issue, and as Oleg has pointed out, and as can been seen in the slides, massive cleanup was a big part of the process… Having been a part of the BSM process, I think the program has lived upto its name…

    Best,
    Nisarg

  • http://www.facebook.com/snisargs Nisarg Shah

    Oleg / Hakan / Steve,

    Having been associated with DS (and its many clients, including Bell), I found this discussion very interesting. However, I would like to know what you (“Oleg”) mean by your last comment, esp. when you say that “the future belongs to flexible and granular systems that can be adapted…”

    Because that would contradict the very foundation of why BSM was successful in the first place. In-fact that would go against the very foundation of having package softwares where many thousands of hours of efforts have gone to just meet industry best practices (which Hakan says is just marketing), and develop processes around it. I mean, I tend to think more like Steve, where standardized process frameworks are just as important as managing data correctly.

    Would love to hear more from you all, and would like to know if I am not thinking something right!

    Best,
    Nisarg

  • Lars Taxén

    Oleg / Steve / Hakan

     

    After spending 30 yrs in the trenches (Steve)
    we cannot, as Einstein once said “solve the problem at the same the same level
    of thinking with which we created them”. The problem needs to be recast in
    quite a different way.

     

    The key, I believe, is to start from a
    human perspective and realize that socially organized work is always motivated
    by some needs and directed towards some work object. This will drive the
    formation of a context of relevance around the work object in focus. Some
    things become relevant and others less relevant. If you are in marketing,
    prices and customers are certainly relevant, while if you are in production,
    manufacturability is a key concern. This means that the key construct in PLM is
    neither processes, nor data, but the context. Unless you have a contextual
    perspective, you will inevitably lose control of complexity. Making “collaboration,
    data, and lifecycle management accessible to anyone, anytime, anywhere” is nothing
    but a nightmare. You want to be bothered only with what is relevant to your particular
    context; not everything!

     

    A contextual perspective has been extensively
    researched under different labels: 
    “communities of practice”, “workpractice”, “work context”, “work
    system”, “activity domain”. They all have in common that data, processes,
    business rules, knowledge, tools, specific concepts and terms, common
    understanding, etc., are submerged under and interrelated in the context.

     

    Such a perspective will provide a fresh
    look at many of the issues discussed here. Take standards for example. Since
    every context is different, standards can only be used to a certain extent. The
    balancing point is somewhere where standard alleviates your business without
    hindering it, much like it makes sense to drive on the same side of the road in
    a certain context; a deliberating standard. Moreover, a standard is not
    effective in a certain context simply because it is a standard. You must
    appropriate that standard into the context, which means an extensive learning
    and training effort to make sense of it. Just because Microsoft Word is a “standard”,
    this does not mean that you can use it out of the box.

     

    Another issue is the data versus process
    thing. In a contextual perspective, both are needed, and moreover, they are
    tightly interdependent in all but trivial cases. But that is not enough. You
    need to take into consideration also business rules and how to traverse
    different contexts. The slide Oleg showed “Bell before BSM” illustrates this
    well I think. The problem is not so much the silos (these are in fact the
    cornerstones of the organization!) as the (presumed) neglect of focus on the
    transition between them. Also, the systems supporting the activities in a
    context will inevitably be geared towards the context. The “467 system”
    syndrome is something that every organization of some size experiences (a similar
    survey at Ericsson estimated something like 700 different systems some years
    ago). Again, there is a trade-off between what should be context-indifferent
    and context-specific.

     

    Much more could be said of course, but I am
    pretty convinced that we must “go back to the drawing board” and acknowledge
    how human, socially organized work is structured; regardless of whether that
    was hunting mammoths thousands of years ago, or developing sophisticated
    product and services today. You need, as Steve points out, a holistic perspective.

     

    Just my thoughts (to paraphrase Oleg)…

     

    Lars

  • beyondplm

    Nisarg, thanks for the clarification. I think, what is the most interesting part is how Bell is keeping up with all changes in this system? One of the most important elements in such systems is to keep making them flexible for changes. Any experience to share about that? Thanks, Oleg

  • beyondplm

    Nisarg, Thanks for your comment! I think you are asking a very important question. In my previous comment, I asked how Bell (and other customers) are keeping up with changes. The complexity of implementation, which includes multi-years effort of developing processes is a huge barrier to make PLM implementation successful. My believe is in open systems that can be easy inter-operated and integrated. Best, Oleg

  • beyondplm

    Steve, Thanks for your comments and deep insight and apologies for my slow response. I largely agree with your points related to standardization. To bring everything into a similar form doesn't solve the problem. It is an intuitively straightforward and unfortunately wrong way to solve the problem of data and interoperability. Organization can think about how to replace all software packages, they have to a single one (from any vendor), but the reality is that it is very complicated, expensive and time consuming. Therefore, my believe is in systems that granular to be able to interconnect and flexible to provide people in a company way to organize and optimize processes around that data. Just my thoughts. Oleg

  • beyondplm

    Lars, Thanks for comments and insight. I liked your definition of work objects. However, if I understand you correctly, “context” is an example of “work object” in your view. Idea of context is not very new, I think.  What is the context, in a nutshell? The context is a piece of data that used by the application in order to fulfill the need of a particular application (or action). Examples – if I need to approve the change, the information about part/assembly/drawing will be a context. If it is a new item release, the relevant piece of data from ERP/PLM (and other) systems will be requested. The problem of systems (especially “process management”) today is that they cannot work with contextually organized data. Most of process management relies on the data located in a single system. It takes us back to the controversy of data vs. process implementations. Just my thoughts… Oleg

  • Pingback: Product LIFECYCLE Management? Really? « realtimerick

  • Laurentius2

    Oleg, The way I see it is that context is everything which becomes relevant when we direct out attention to some (work)object in focus. Take for example a grand piano. If the context is the concert hall, properties like tuning, tonal quality, attack, and so on become relevant. If, on the other hand, you are moving the grand piano, properties like weight, size, etc. are relevant (whereas tuning is not). This is simply the way we as humans experience reality; our actions are always directed to some object, which determines a context of relevance around it.

    As you point out, working with contexts upfront is not possible today because PLM systems basically do not have such a modelling construct as part of their “worldviews”. The first vendor that realizes this, will have a great advantage in the future I think. This would certainly not make away with processes and data, but they would be seen as context dependent; a different perspective. I believe that such a perspective would be very beneficial for PLM.

    Lars

  • beyondplm

    Lars, I completely agree. The context is important in process management. The complexity of the contexts in product development (aka PLM) is something that makes it not trivial for implementers. Just my thoughts.. Thanks for your comments, Oleg

  • Pingback: Design & Engineering Tech Insights Weekly Blog Round-Up | CAD/CAM Performance Blog

  • Prajeesh Nair

    Hi,
    Thank you all for the wonderful article and comments. My thought on data and process is as follows.
    The data is the most important in any organization and its management through right process add values to system. In the current world of “Global”, standardization will not make sense and it will inhibit the innovation. But at the same time, the so called master data can be used across the organization for a right process. So in that scenario, the context at which data is used becomes more interesting. At each context , the data is viewed as different prospective and will be used for a different process.

    So it is very much needed that we should have the right data in first place and process can use the data in different prospective.

    Now the regarding the format of data?… If the data can be viewed in different prospective in different context, the format of master data doesn’t need a standardization. May be a standardization at the context level may help. So to get the different prospective in different context, each organization go for customization. So if I can get the different prospective of data at different context that will solve the issue

    This is my thought

Previous post:

Next post: