If you run a thorough and involved research project of all the PLM tools in the market towards the dual goal of defining what PLM is and what core PLM functionality should constitute, you would be embarking on what is called a fool’s errand.
There are dozens of PLM tools in the market, and I have found no two solutions that can be put in the same bucket, despite the sheer quantity of these tools. Some reasons why:
- Timeline variances in development: Systems have been developed by companies across decades. Most are legacy, however, there are a few younger age upstarts. Technology changes so fast, even within 12 months, so you can imagine the difference between a system that released version one 20 years ago versus another that released version one two years ago. Even if a 20-year-old version one has since had upgrades, it is almost impossible for such a company to catch up and compete with younger companies when it comes to product strategy, modern UI, and when it comes to getting rid of technical debt.
- Architecture and hosting variances: Most tools are on-premise systems. Some have since offered upgrades to SaaS, while others have continued to service customers through standard upgrade and maintenance models. Few are native cloud + SaaS models, and even fewer are native cloud + SaaS + usage-based models.
- Pricing variances: Pricing is all over the place, some cost into the millions for purchase plus implementation, there are a ton in the 6-digit $$s mark, and few in the thousands.
- Industry target variances: Some PLMs focus on fashion and adjacent industries, some on hard goods, and others on services.
- Definition, scope, and functionality variances: This set of variances is the one that counter-contributes most to the effort at finding homogeneity. A Product Lifecycle Management system manages information, processes, and the flow of goods and services across the value/supply chain’s length. This definition has been scoped in different ways by product teams across companies. Some PLM systems are as complex and layered in functionality and UI as an ERP, while on the other end of the spectrum, few PLMs have scoped their products to just allow the design of a new product.
To better illustrate the problem this creates for industry practitioners and executives looking to compare systems towards making a single PLM system purchase, take a look below at two popular PLMs in the market plotted against the above five variance parameters. Each of these two PLMs on each parameter is plotted along the five axes. Variable (A to B) where A is closer to the center and B is the other end. For example, Price (low to high) is interpreted as a lower price that puts the PLM system closer to the center for this variable, and a higher price branches out the position.
PLM 1:
PLM 2:
The vastly different shapes of the two pentagons prove the conundrum and illustrate the PLM market’s confusion. In fact, every PLM we thus plotted when conducting research had a different and unique pentagon compared to the rest of the PLM set.
This brings us to: how do we define the table stakes and standards for modern PLM systems?
Based on firsthand observations and learnings we have been fortunate to aggregate through the GRID and talking with hundreds of product and service companies, the below is a listing of the five non-negotiable standards for modern and scalable PLM systems and tools.*
*It is important to note that these must-haves are my opinion based on our data and conversations with customers, as are all views on this blog.
1. A PLM should allow for product creation, process tracking, and collaboration
As a bare minimum, in terms of functionality, a PLM tool should allow users to have transparency across every stage. This starts with the conception and creation of new products, then tracking the production process (i.e., the inbound supply chain process across raw material suppliers and manufacturing partners) and collaboration with various participants through creation and manufacturing. While these could be a lot of steps to build, the functionality need not be and should not be complicated or cumbersome to use. Like any modern B2B product worth its salt, gorgeous UI and intuitive UX can simplify any layered process. Should you be interested: there is a lot more to discuss and read about when it comes to quality UI and UX processes and assembling teams to ensure scalable interfaces in Supply Chain Sunday.
2. Industry specificity is overrated and counterproductive; a PLM should allow for easy configurations across products and industries
Many legacy PLMs were built specific to one market or industry and gradually stood up custom versions of their product to apply to different industries. Many buyers incorrectly evaluate this specificity as an advantage – this is a traditional software mindset I challenge you to overcome. Modern systems, PLMs or not, are powerfully flexible and powerfully configurable. They allow their users to self-create and self-direct their journey through the product. In fact, tuning too deeply to one industry works against flexibility. Heavy customization to one sector can spell disaster when a company expands into new products or categories: even in the same industry, product lifecycles can vary widely across new products. When a PLM has been pre-wired towards an industry, it means any additional fields or business-specific edits involve professional services hours amounting to hundreds of thousands of dollars. However, when companies can configure their PLM systems and make edits themselves, required changes are minimal in time and effort. The more configurable and cross-industry a PLM, the more likely you will enjoy using the system and the more likely it will scale with your growth at minimal additional dollars.
3. A PLM should allow for created assets to be archived, searched, and easily reused
Concepts and designs created from scratch are rare. Once a company develops a repository of designs that sell well and has a loyal customer base, it is profitable to reuse the same core concepts released with minimal iterations. Most libraries at companies are still stored in the physical world and shared in an analog fashion. A digital library of all finished product designs and digital profiles of suppliers opens the floodgates to a robust and successful merchandising strategy. When all team members can quickly and easily filter and search through these repositories, there will be an improved frequency in new concept releases and sales. At the same time, there is a reduction in payroll overhead to conceive and create new designs. Creating a limitless archive of profiles and concepts also means facing no storage restrictions. This constraint is solved when a PLM is on a public or private cloud. More on this point in point five (5).
4. A PLM should democratize design and empower non-designers
In software development, no-code or low-code software is all the rage. This is where blocks of code are prebuilt, so software developers can reuse and combine these packaged assets and release software applications with minimal coding on top of these packages’ combinations. This strategy democratizes software development, allowing for a notable decrease in software development time, and correspondingly an unprecedented increase in the release of software applications. Similarly, a modern Product Lifecycle Management system should allow for blocks of concepts to be packaged, stored, and reused. This, combined with a simple front-end user drag and drop interface, can allow concept creators the ability to mix and match blocks to create new designs and release new products in fractions of the time it took previously. A simplified workflow democratizes the design and the product creation process. No longer does a product creator need an intense academic and professional background related to design as required previously.
5. Architecturally, a PLM should be cloud-native with unlimited storage charged as used; onboarding should take no more than eight weeks at most
I am shocked when I see large companies running PLMs that are still wired into servers physically located in their buildings even today. Points one through four – table stakes for scalable PLM systems – are impossible to execute unless existing in a world where space and speed are both not constraints. A PLM will be collecting and storing vast hordes of your supply chain data over time. Unless they are sitting on a public cloud or a combination of public clouds, companies using these PLMs are heading towards a disaster to maintain a legacy beast. Data storage on the cloud is a commodity today. The price of storage and hosting is low and getting lower every day – another advantage to hosting on the cloud since companies should be asked to pay as they use storage services.
Modern PLMs – if points one through five are addressed well – should also onboard companies and users within eight weeks or less. This time may be aggressive if including integrations but gone are the days of 9 to 18-month implementations. Longer implementation times also mean a ton more spend on professional services and a ton more customization – all points counter to the definition of modern PLMs.
