Home Featured Why is this so difficult?

Why is this so difficult?



In his latest piece with us, resident Expert Dan Hudson, discusses why truly successful retail, footwear & apparel PLM implementations are difficult, and how implementing various inter-connected systems can help.

Truly successful RFA PLM implementations are hard to find. I have seen partial successes where companies have implemented PLM in several departments but I have seen very few that live up to the marketing hype of an end-to-end solution. While some might have a favorable ROI, most have limited impact when compared to the time and budget expended. Usually, a large implementation is scaled back once an initial rollout has been accomplished, leaving the PLM system as a three or four department solution. Why is this so difficult?


No one likes change; the power of “we have always done it this way” is very strong. Getting buy-in from the users and management is key in any process improvement initiative, and not just for PLM projects. The unique part of PLM is how wide spread the impact is – truly enterprise-wide. “What’s in it for me?” is an important question to provide answers for. Many times, PLM systems will shift duties and data entry between users and departments; justifying more work up-front that only yields benefits later in the workflow can be a hard sell to already stressed and over-worked employees. PLM projects that have been justified in terms of “worker productivity” have additional barriers as users think they may be working themselves out of a job. Getting users to embrace PLM is only one hurdle for PLM success.

Complexity levels

As a PLM system expands to encompass more users and departments, the level of the data complexity also expands. Relationships between objects (products, components and processes) grow exponentially. Some of the hardest data relationships for PLM to handle revolve around “one to many” and “many to one”. This is true within departments but causing significant hurdles between departments, especially as the focus of the department changes. WhichPLM’s own CEO, Mark Harrop, recently highlighted an example of this focus as the “transactional” and “non-transactional” worlds. The view of data in the non-transactional world (product development) vs. the view of data in the transactional world (ERP, logistics, etc.) is quite different. The enterprise contains other data views and focuses as well; marketing, e-commerce, compliance and business planning all have significantly different views of data while spanning both the transactional and non-transactional worlds.

In the product development world, products are first conceptual and become physical as samples are produced. The ERP world tracks products at a completely different level. A concept style becomes multiple ERP styles – one style now has multiple colors and sizes; it becomes many SKUs. These SKUs now have actual inventory associated with them. A user running reports on conceptual styles will filter the data very differently than users reporting on inventory.  The BOM for a concept style and the multiple variations of the BOMs for the SKUs have drastically different data. These SKUs are further expanded as channel differences are applied. For some stores the product will be supplied on a hanger, others will get it folded in a plastic bag. Someone forecasting hanger or bag requirements needs different data than just the initial SKU breakdown.

Compliance systems not only need the data defining the products, they must also track the origins and usage. It’s not enough to know the description of the button; they need to know the supplier is an approved vendor. If they are looking at fabric, they will need to trace back its approval to specific tests, while knowing every product that uses the fabric.

Someone managing licensed images is a good example of data crossing between all these views. They must manage the license during the concept phase, getting approvals for color variations, usage on product types and minor modifications required for production. They must also then manage data from SKU’s regarding actual usage and quantities as well as from which channels.

Setting up data definitions in a PLM system to account for all the various representations and views is a huge hurdle to success; a success in product development doesn’t mean a transactional success. Compromises made in one area will impact the success later in another area.

Existing systems

A PLM implementation doesn’t happen in a vacuum. There are existing systems and processes in place as the implementation begins.  PLM implementations usually take place in phases; these phases may be defined by departments and functions or they can be defined by product type or business lines. You can address a subset of products across multiple departments or all products but one department at a time. In most cases all of the non-transactional functions will be addressed prior to tackling transactional ones. This means that legacy systems at multiple levels will still be in use. The integration of data, either short term or long term, will have to be addressed; many times this includes manual intervention, usually back to the use of spreadsheets (the ultimate enemy of any PLM success).


This is further complicated by the age of the legacy systems; since they usually are based on older technology making integration with the PLM platform problematic. Getting to the end-to-end solution where previous results can be used in planning new products requires either integration or replacement of all systems.

Which elephant is it?

I think of the blind men describing an elephant parable. You get a drastically different picture of an elephant depending on which blind man you listen to. PLM success will look different depending on your perspective. It may be time to ditch the vendor’s view that a single system or software application can be your PLM solution. Product Lifecycle Management may need to viewed as a discipline that uses multiple systems and software to accomplish creating products and managing them until they are liquidated and archived. A PLM system may provide a backbone for the discipline but one system cannot possibly include everything necessary for success.

Lydia Mageean Lydia Mageean has been part of the WhichPLM team for eight years now. She has a creative and media background, and is responsible for maintaining and updating our website content, liaising with advertisers, working on special projects like our PLM Project Pack, or our Annual Publications, and more.Joining mid-2013 as our Online Editor, she has since become WhichPLM’s Editor. In addition to taking on writing and interviewing responsibilities, Lydia has also become the primary point of contact for news, events, features and other aspects of our ever-growing online content library and tools.