PLM: Business Transformation vs. Business Pain Solving?

Oleg, Thanks for triggering discussion on this, but I think that transformation vs. fixing pain-points is a false debate. I believe the core issue is outmoded methods, based upon an incomplete understanding of the business environment (shall we say “ecosystem”?).

There is an apparent dilemma between large-scale transformation vs. fixing pain points. Large scale business transformation methods generally take considerable time and investment in vision, cultural transformation and process engineering, in addition to adoption technical solutions, whether enterprise, cloud or hybrid. Invariably, mid-course corrections are required, due to environmental changes and long timelines for implementation. Pain-point fixing also suffers from constantly chasing new challenges. So neither approach seems to generate expected value.

Classic Business Transformation often involves large scale requirements definition, followed by technical specifications, solution engineering and finally development and delivery. Formal process reengineering, is always based on the premise that current and future processes can be defined. Pain-point fixes often involve similar methods, but on an incremental, smaller scale. The problem is that most business do not truly understand the the context into which these new solutions are to be deployed.

Businesses operate as complex adaptive systems. This is especially true when the extended enterprise of suppliers, JV partners, technology providers and so forth are considered. Relationships are nonlinear and constantly changing. Classic business transformation is doomed from the start. So is pain-point fixing. That is the real reason these effort fail to produce expected value.

Many PLM implementations are grossly over-engineered and overly complex. The focus is often on widespread adoption. Propagation of the these complex solutions across across and beyond the enterprise drives waste and inefficiency. Businesses need to focus upon work products and practice, not processes. Smart companies concentrate on precision information logistics — simply making all needed information available, in widely available formats to drive consumption. Sharing information to drive contextual understanding is the challenge — not processes, and certainly not widespread system adoption.

Oleg, you are touching a very interesting point, obviously not limited to the PLM space by the way.

PLM was invented to overcome the information (flow) deficits in organizations with an increasing division of labor and to control the compliance along fairly stable internal processes. Meanwhile organizations and processes change so often and fast, that “business transformation” projects, but even typical change projects are regularly overrun by changing business demand.

That indicates – very briefly – the following issues:

#1 Rightsizing the scope of PLM: Data Management instead of Process Management

PLM tools and data models are strong in managing information and their relations, providing functions to analyze and visualize, but I saw too many Process Management dinosaurs. Trying to enforce processes with PLM is where a huge amount of money is spend during implementation, where solutions are build that never meet the primary expectations of the business and later often hinder changes and a flexible adoption to changing demands. They usually never pay
off, and even worse, they often become a burden to the companies.

Returning to the strength of PLM and removing ballast leads to an additional potential that can, by increasing the flexibility, reduce the TCO significantly:

#2 Flexibilizing the PLM delivery: Cloud Computing based PLM

Cloud Computing means “ready to use” (or at least “ready to configure”), fully managed and supported at a consumption based price. It does NOT mean a PLM software installed on IaaS only (your Siemens PLM example, Oleg).

A real gain in flexibility and reduction of TCO requires that companies behave just as consumers, articulating expectations and buying a solution as a product (not only a toolbox). The product will be offered with different options and service levels, but there is always a service provider that keeps the full responsibility, described in SLAs, for the whole service stack. A good example is the Canopy solution for Teamcenter, mentioned in CIMdata’s commentary. Companies just do not need to have own IT, IT stuff, application experts and support stuff to run a PLM application appropriately. Money and people can be used more value-adding these days.

The business drivers are tangible, trustworthy Cloud provider are already offering PLM Cloud services. The challenge is the mindset of decision makers in the business and IT departments. Cloud Computing is vigorously shaking ancient wisdom and certainties.

Here is my 2 cents: The fact is that large PLM system implementations are at cross roads, business transformation or not. I was one of the program directors for a large PLM deployment at $18B manufacturing company. We ran into some major issues when trying to get our users to adopt PLM. The CAD assembly management deployment went well but when we tried to deploy a standard workflow for change management and product structure, the users rejected the system. I heard of a previous client of mine who just deployed engineering bill of material management after 10 years! People are rejecting large, monolithic, top down enterprise applications. Are companies
going to able to force people to use PLM systems? A company could use the argument that if you
work for them you must use the dictated systems. Will this argument really work in the age of
smartphone and apps that will do anything a person wants the way they want it? The business transformation may not do any good if people just will not use a system.