PLM and Multi-domain business processes.

Picture 7I’d like to continue the topic I started yesterday in my post “PLM vs. ERP: Demand for Business Process”. Even from the small amount of comments I’ve got from yesterday, my impression is that there is no agreed position about how PLM and ERP related to business processes and what are their roles in the establishment of organization business processes. I think, there is a significant consensus with regards to ERP and Business Processes. At the same time, I think a role of PLM in a business process is not as agreed.

My topic today is about “Multi-domain” processes. I don’t think this term is widely used and agree, but I think, it reflects quite well a company situation. As a background, from my view, there are several organizational and business trends.

1. Business becomes more connected. In the today business situation, number of connections, communication and dependencies inside of organization are growing exponentially. Business becomes much leaner, agile and this is required to work more efficiently and, therefore, need of connections becomes obvious.

2. Organization activity needs to be optimized independent on boundaries of business systems. Companies accumulated huge amount of separate systems and operate them for the particular needs in the specific situations, scenarios and needs. These applications and systems were built in different time and almost always are not connected.

3. Process-oriented systems can provide a solution by connect people from various domains. Growing trend in understanding how business process systems and technologies can help to streamline business and support overall corporate operation is growing. We had chance to see signs of growing BPM even during a current turbulent time.

So, I think to establish cross domain business processes can be very beneficial for an organization. However, I see multiple problems that prevent business from do so.

1. Application boundaries.
Most of the enterprise applications we have today were developed with a specific business domain in mind. Historically, application focused and improved their functionality and experience in the specific domain. Issues related to communication of application with external systems were considered as complex and in most cases companies were investing in consulting and professional services to establish cross-boundary work and integration.

2. Business silos. This is an organizational problem. Business units, departments in many cases are separate and operate independently or in very loose control mode. To establish horizontal business relationships in an organization is another challenge.

3.  Multiple systems.
This is one of the most serious problems, in my view. Historically, company implemented lots of systems they are using for business needs. To connect this system zoo in something that can work together is very difficult. There are some positive movements related to SOA technologies we can see during last few years, but situation remained very complex.

So, what is a special role of PLM? I see in cross-domain business processes. Product Lifecycle Management, by nature is a discipline that creates a large amount of connection between different aspects of product development in an organization. Today, to establish and maintain these connections and interops is one of the most complicated business and technological problem in PLM. If PLM will be able to invest and/or cooperate with process management technologies and products, it will create a process-level foundation for enterprise system connections around product development. From the technological standpoint, I think, PLM needs to invest in processes technologies and openness to make cross-domain processes happen.

How do you see business process support related to product development organized in your company? Do you think, such PLM approach can improve your current situation with process development and will make your organization leaner?

Best, Oleg.


Share This Post

  • Nawal

    When we talk about silos in organizations, from data perspective, I like to think that a business unit wants to consume and utilize an information that is released from the other business unit. But, if the information is work-in-progress, which means volatile and suspect for large changes, they are usually afraid to collaborate.

    For example, designer will say that I will work when you have finalized the requirements. It is a classic waterfall approach to business process, which gives illusion that there are clear black and white boundaries between processes and departments.

    To a certain extend this was largely true say a decade or two ago. Most of the business systems are designed from that paradigm, that the input that they receive from other system is not volatile.

    For example, I will always submit my travel expenses after I have completed the trip. So, they will make it difficult for me to get paid for only airfare, even though it is big ticket purchase and trip is not complete.

    But, the current business environment is lot more dynamic. There is much greater need to collaborate across process on work-in-progress data.

    This has been largly true for product data. Outside engineering organization, every one wants to work on released data – which is static. PLM can really play a great role to bring all departments together and become comfortable working with work in progress data.

    This will make organizations more agile, resulting in their ability to introduce radiacally different products faster.

  • Nawal, Thanks for your comment. You stated very well move from waterfall approach to more dynamic business practice.
    With regards to your comment about role of PLM system. The problem I see is that only to make product data available outside engineering organization won’t be enough. A lot of work actually should be done in collaborative manner (i.e. Engineering to Order processes etc.). In this case, a significant amount of collaboration between different domain is demanded. How to build such processes that requires communicated between people in sales, engineering, manufacturing? This is place for ‘cross-domain’ business process practice .What is your view on this? Regards, Oleg

  • Nawal

    Before, I get into process issue. I will take to comment on what I truly believe will happen. For past 100 years are the implementation of economies of scale philosophy and “you will get any color as long as it is black”. Even though there is lot of product configuration on DELL website, you can not say that for most business.

    In silicon valley, there are so many Vegetarian Indians like me, but none of the major food chains offer anything for my taste pallete. Whenever I visit my small hometown in INDIA, I am always surprised that a small mom-pop shop has far more clothing variety than a typical clothing giant in US. One could definitely argue about the quality of cloths in my hometown against available here, but there is no argument on variety of offering.

    I firmly believe that we reached the pick of Henry Ford philosophy with the birth of internet, and are already in a reversal.

    Stating this high level believe, we also need to observe that current organization structure, engineering, sales, services, operations etc., is a manifestation of Henry Ford philosophy. In a mom and pop shop, the owner is sales-cum-engineer-cum-accountant-cum-operations, all packaged in one. This is highest level of ‘cross-domain’ collaboration. Most organizations would love to have this agility without loosing the benefits of ‘economies of scale’.

    That’s why in valley, you see giants funding startup till technology gets mature and ready of scale. From process point of view, this is really to save these companies from rigid processes existing in these giant companies.

    What PLM should do?

    1) PLM needs to acknowledge that there are different type of product development – a start up type product development, to some basic maintenance on a product closer to end of life. Each of this project has a different data, process and governance needs. The PLM should be designed for this and not configured for this at a customer site.

    2) PLM needs to make designing/authoring product data much easier for non-design engineers: Product design is no more the responsibilty of engineering. Like in 80’s and 90’s, it was said quality was everyone’s responsibility. We are in an era, where product design is everyone’s resposibility. That means services guy has the equal responsilibty of ease of maintenance on a product. He can’t bitch and point figures at Engineering. I know we have been doing DFx activities for a while now, but DFx has an attitude of please review and do not complain later that I did not ask. We have to move much beyond that attitude.

    3) The entry level interface should be built more like facebook. Facebook is more centered on person, but in our case it is more centered on product. Just think of it as every product actually was a human being, and had an account on facebook. In business system, we call this as dashboards, but dashboards are used more in the context of management matrix. We need to build something mix, that serves as a start point for everything.

  • Pingback: which of the following is correct? | Writing Objectives()

  • Nawal, Thanks for your comments! Actually, I cannot say better. May be just to add to your comments about PLM data on pointing to my prev posts:
    By making PLM content social, we can allow everybody in company to be responsible for design, as you stated.
    Best, Oleg

  • Andy Finkbeiner


    We used to see a major conflict between ERP and PLM in regards to “ownership” of certain data elements. For instance, which system owns a part number that is both in production but also being used for new product development? Who owns the change control system in that case? Does a part change need to flow thru the engineering change control and then over to the ERP change control or not? If you branch the systems for every change then you end up with a mess, if you don’t branch then you end up with a change control cycle that is very long.

    With the latest concepts in SOA we’re now starting to see a way out of the mess. For instance, rather than the idea of “source of record” we now might talk about “sources of records”. So there might be several places that hold data all interconnected within an SOA. If you have a layer of business intel that “knows” where to find the information within the corporation.

    So back to the part number example, in an SOA environment maybe there is a database of just parts that exists as a stand alone data silo. Both the ERP system and the PLM system can reference that part file but neither of those systems “own” it. Maybe ERP goes back to just owning big complex tasks such as MRP and inventory while leaving the collaborative stuff to be managed by more nimble systems.

    I haven’t seen anyone actually implement this yet but we’ve been kicking it around. The ERP folks want to keep control over as much as possible so it will take time of course to move things into a shared environment.

  • Andy, I think you are absolutely right. Systems (and silos) interconnect from the standpoint how they hold data ownership and process ownership. My view on cross-domain business processes is one possible way to resolve ownership problem and create layer beyond silos. From experience, I know what level of mess you can create in trying to resolve ownership problem and breakdown it to the small pieces. SOA won’t be universal hummer in my view, but certainly can point on something doable. Have you had chance to try systems that can do it? Best, Oleg.

  • Andy Finkbeiner


    Yes, I believe we have had some success with this concept but only at a very small scale. Some might say our solutions are so small that they do not matter.

    One example would be a cost information system that pulls data from various silos such as procurement data, ERP systems, legacy mainframe cost systems and provides a design engineer with a “mashup”. This sort of system avoids ownership problems by just connecting existing data. The engineer gets the data required to make a decision and we didn’t have to move a ton of data into an enterprise class PLM system.

    Maybe that example is too small to illustrate the solution but it is the kind of things we’re working on. Rather than deploy a huge enterprise PLM system, we’re focusing on solving the businees needs. If engineers need cost data that is spread all over the organization then why not just go connect to it all rather than move it all into a central location?

    I’m not sure if this is even SOA or not. We’re not too hung up on labels, the important thing is to find the data, connect to it and serve it up to the people who need it. If we can do that using standard tools, services, and protocols then all the better. It would be nice if all applications came with a universal communication layer but evidently nobody has invented that feature yet!

  • Brian Chambers

    Oleg: I think there are a number of core multi-domain business process for which PLM can be positioned to support. These include portfolio and program management, sourcing, regulatory compliance, market launch processes, as well as even run-maintain of products with serialized BOMs (aircraft, ships, nuclear plants, etc). While data mastering can occur in a shared manner, as already discussed, it is really the positioning logic of PLM as a core backbone to these related systems which justifies its positioning.

    So for the example of where to do change control, ERP or PLM, on production parts it comes down to whether those parts are core to the product portfolio and platform strategy. If there are not, and are only plant specific, then change control should occur in the plants. However, if the parts in question are critical to the platform and product strategy, then they will need to be managed through the PLM system.

    I think of PLM at the enterprise level as managing a corporation’s forward looking strategy in ways that an ERP system, which is based on current pipeline and released parts, is not designed to manage. Also, for market launch of new products, taking a backbone approach to PLM provides companies an ability to leverage the released designs for technical documents, operations & service training, sales / marketing collateral and on-line catalogs. Having these downstream functions integrated to PLM makes sure that when the market launch occurs, everyone is working from the latest release of the product models and data. Ongoing design and product updates can also be readily managed.

    I appreciate the context and framework you’ve developed for defining the trends and business challenges regarding PLM and multi-domain business processes.

    For more on PLM as an enterprise backbone, people can go to:

  • Brian, I agree with your concept of “core business approach”. Even more, I do think PLM can provide a very significant advantages for processes you mentioned. However, when two systems are involved into business process, ownership becomes a key point and play a very destructive role in my view. What I think, at the time when ERP and PLM are trying to understand how to own data, customers are paying money. Unfortunately, I’ve seen it many times. Everyone want to become “an enterprise backbone”. How do you think, this issue can be resolved? Thanks, Oleg.

  • Andy, what you are saying is what I called mashup approach. Regardless on technologies and implementation the general rules are to pull/connect data. This is can solve a lot of business problems and I had chance to see few similar implementation of this approach. I’d be interested to know more about what you are doing. Thanks for your comments! great discussion! Best, Oleg

  • Brian Chambers

    There are no easy answers. It has to do with the leadership vision of the executive management in the companies, and their understanding of the advantages of PLM’s strategic capabilities.

    We need more enterprise PLM evangelists, for lack of a better term. Being able to position and sell PLM’s enterprise promise to the C-level suite requires skill levels outside the grasp of most engineering oriented PLM vendors. It is developing, however, and we need to continue to promote PLM enterprise level capabilities.

    Also, the full range of PLM I’ve described in my blog series is not necessarily available across all PLM vendors, so we at Dassault Systemes have the enviable role of leading the charge ! ;>

  • Brian ,what you explain is current “hard way to sell PLM” via evangelists, C-level sponsorship etc. This is so-called enterprise software way. I’m not saying it’s bad, I’m just saying this is probably not the only way. Regards, Oleg

  • Excellent site, keep up the good work

  • Hey good stuff…keep up the good work! I read a lot of blogs on a daily basis and for the most part, people lack substance but, I just wanted to make a quick comment to say I’m glad I found your blog. Thanks,)

    A definite great read.. 🙂


  • Cool site, love the info.

  • Cool site, love the info. I do a lot of research online on a daily basis and for the most part, people lack substance but, I just wanted to make a quick comment to say I’m glad I found your blog. Thanks,

    A definite great read.. 🙂


  • prassy

    Thanks For Your valuable posting,this is for wonderful sharing,I would like to see more information from your side.I am working in Erp In Chennai