PLM and Multi-domain business processes.

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.

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.

Oleg,

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.

Oleg,

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, 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.

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 ! ;>

Excellent site, keep up the good work

Cool site, love the info.

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