Who pays for PLM?

Companies continuously face tough decisions when it comes to investing in enterprise resource planning (ERP) or product lifecycle management (PLM) solutions. In practical terms, PLM enables product engineering and innovation. Funding these enterprise initiatives and their continuous delivery activities is often challenging due to conflicting expectations and priorities from multiple stakeholders. Successfully implementing enterprise change requires merging multiple requirements and negotiating expectation tradeoffs.

Typically, PLM investments deliver greater financial and strategic impacts than ERP investments, and PLM investments deliver competitive advantages in a way that ERP cannot.

Why PLM?

Prioritizing technology investments can have a dramatic impact on return on investment (ROI). Prioritizing PLM investments can lead to a more effective ERP engine. The reverse might lead to lean ERP operations with unreliable, incomplete, or inaccurate PLM data – a garbage in, garbage out scenario which can spiral into deployment or support issues.

Who benefits?

Asking who pays for PLM often relates to asking who benefits and how to fund it. However, causality between these questions is not always clear as PLM is sometimes seen as a necessary evil to deliver production-ready data to the wider enterprise.

PLM investment decisions should go beyond dollar-for-dollar return, as the platform is essential to an enterprise in its entirety.

For instance, PLM is an enabling platform engineers must use to complete their work. Few clearly recognize or appreciate that it should help them work more effectively and become better at what they do.

While rooted in engineering for product creation – historically product data management (PDM) – most PLM value relates to cross-business functions and integration. Product creation (engineering PDM) and product data usage (wider enterprise PLM) have complementary, albeit sometimes conflicting, requirements.

Engineering teams can perceive enterprise PLM as a burden that constrains day-to-day creativity with non-value-added activities.

Benefit realization (such as productivity and knowledge sharing) is not tracked properly; PLM initiatives end-up being managed by incidents, while success is measured based on the ability to close technical issues rather than end-to-end business improvement.

Investment types

For most cross-functional initiatives, the enterprise should fund the PLM foundation and spread the investment across the relevant functions or user programs. The cost of PLM spreads across three main categories:

Implementation investment (build): Technology and supplier selection, implementation, and preparation of the solution (people-process-technology readiness) includes setting up the infrastructure; building the selected tools and technologies through configuration; customizing, testing the solution, and validating the new processes; preparing data migration and interface procedures and tools; preparing the transition; aligning human elements.

Deployment investment (execute): Interface with the business, training end users, running the transition, facilitating business adoption, performing legacy data extraction, and deploying relevant interfaces on the selected infrastructure (including the cloud).

Support investment (maintain): Capture knowledge and capitalize on PLM implementation, prepare day-to-day usage continuous improvements, and maintain evolution roadmaps.

PLM implementation investments require robust business case creation supported by experienced implementation practitioners. The implementation budget should be owned and managed by the enterprise (across functions) and considered as a sunk cost to deliver the foundation of an enabling platform across the entire value chain.

Adoption challenges, incentives

Some organizations might decide to distribute deployment and support running costs across impacted business functions. This needs to be done carefully to avoid associated challenges. For example, asking project teams or functional teams to pay for on-demand PLM usage with cross-charging models might be perceived as a usage tax that could discourage the business from using the solution.

Teams might work outside of PLM and only use the solution to release or publish data. Or, by limiting access to a few PLM users to check data in and out for the rest of the team, users could create hidden factories outside the enterprise platform – leading to data duplication, uncontrolled processes and data, and other inefficiencies. This, in turn, will affect concurrent engineering and collaboration effectiveness, data reuse, early error identification, quality, and adherence to process.

To show PLM as on-going deployment and to support cost distribution, link usage to continuous business benefit realization and incentivize value enablement. Don’t simply consider quantitative measures which relate to business consumption or usage cost.

PLM as a service

Cloud solutions can lower barriers to PLM technology adoption if users consider service models as more than just cost models. Enterprises should consider PLM-as-a-service for what – and where – benefits are realized so that the appropriate users can access the right data at the right time, from the right source, at the right location, for the right purpose, and at the right price. Evaluate cloud PLM across business processes, partners, technology resources, performance requirements, security needs, enterprise application interoperability, and infrastructure. It is only effective if it helps meet business goals.

Tata Technologies
www.tatatechnologies.com

About the author: Lionel Grealou is vice president of PLM services for Tata Technologies. He can be reached at lionel.grealou@tatatechnologies.com.