Apparel, Retail and Consumer Goods: PLM Selection Considerations

Selection Header

PLM vendors for the Apparel, Retail and Consumer Goods market segments can be classified based on their origin.  The selection of the right PLM vendor for your company, in part, may depend on matching your company’s culture with the vendor’s background. The PLM vendors’ backgrounds fall into 4 categories.

1. Engineered Products

Several of the larger PLM vendors have their roots in highly engineered products. They started in aviation, electronics and manufacturing industries. Their legacy applications were typically UNIX-based and provided integration with CAD/CAM systems. Several can be traced back to a common Windchill development environment. These systems were typically focused on configuration control and tracking. (The QA approval for a particular lot of rivets must be linked to the exact part they were used on and the particular aircraft where the part is installed.) Originally the products had long lifecycles but as these vendors moved to electronics, lifecycles became shorter. Dealing with shorter lifecycles positioned these vendors to move into our target market. The arrival of browser-based graphical user interfaces and the technology move from UNIX to PC workstations (Windows and Macintosh) set the entry into the Apparel, Retail and Consumer Goods markets.

2. Extension of a CAD System

Another set of vendors entered the market via pattern making systems. These companies had pattern systems in place at apparel customers and creating an application to generate “tech packs” was a logical extension to the pattern systems. The early versions of these products were PDM systems rather than PLM, but again the technology changes allowed these vendors to move from PDM to PLM as they moved to browser-based systems. These applications tend to be focused on fit, sampling, BOM and costing functionality, as these functions were core to their PDM roots.

3. ERP add on

A third group of vendors were supplying ERP and/or sourcing applications to the Apparel, Retail and Consumer Goods market. As they modernized the systems’ databases and also implemented browser- based interfaces, it was a logical step to increase their user base by implementing PDM/PLM functionality. As you might expect, these systems tend to focus less on design and more on merchandising, logistics and delivery of the products.

4. Started in the Apparel / Retail / Consumer Goods space

The last group of vendors started as Apparel, Retail and Consumer Goods PLM systems; the majority were started by those who worked for, or with, other PLM systems. They saw missing functionality or new technology not yet embraced by the other vendors. They had the advantage of starting from scratch but also the disadvantage of having to build an entire application along with an infrastructure for their support and sales staff.  These vendors’ applications are usually based on a development environment  (i.e. Microsoft Dynamics), a particular database technology or a “cloud-based” implementation. Since they started from scratch implementing the latest technology is easier than a vendor with legacy code to support.


While the origin of a vendor is not the critical factor in a PLM system selection, it can be useful to help determine if the vendor is a fit for your organization. If you have highly engineered products (outdoor apparel or lingerie for example) then a vendor from an engineering tilt may be an advantage. If you have a large diverse user base, an established vendor with an extensive support infrastructure may jump to the front of the line. If your IT department consists “early adopters” then a start-up may be the best fit.

One PLM for all

The philosophy or approach of your company is another consideration in the PLM vendor selection. Some companies want each department to have the best in class tools for their function. This approach means integrating multiple departmental applications into a single “PLM” system.

Other companies will pick the PLM system with the best “overall” capabilities, even at the expense of a particular department using a less than fully functional application. This is indicative of the company’s organizational structure: top-down or bottom-up; whether individual department heads get to make decisions or whether these decisions are dictated from corporate (usually IT).Modular

If your organization is a bottom-up business (departmental decision-makers) then vendors whose applications are modular may get the advantage. Modular systems allow for more flexibility in integrating additional tools with the PLM system.  It may go as far as buying components from multiple PLM vendors to create a mixed breed PLM system.


Top-down organizations tend to like to work with fewer vendors. They are likely to pick a PLM system from an existing vendor – their ERP vendor or their pattern system vendor for instance. They will use “adequate” tools in some areas in order to get support from a single vendor.

Business Processes

Your organization’s acceptance of process change is another consideration when selecting a PLM vendor. If your business processes are defined and in place then your PLM system will need to mirror your processes. If one of the reasons to implement PLM is to define new business processes (or re-define existing ones), then your new business processes can mirror the PLM system. In either case the ability of the PLM system to support modifications is key. Some PLM systems are “hard-coded” and require custom programming to alter how they are implemented. Other systems are “configurable” allowing administrators to setup or change how data is represented in the system. Of these configurable systems, there are two approaches. In one, administrator dialogs are used by the system to present configuration options. In the second, XML control files are used to modify how the system works. In the latter case it often becomes more like customization programming than “configuration”.


If your organization is set in its ways, finding a vendor who can configure their PLM system to your processes will be beneficial. If your organization is flexible and willing to change, finding a vendor with an OOTB (Out of the Box) version of its PLM system will make the implementation go much faster.

System Integrations

The last consideration I want to put on the table for discussion involves system and data integration. In every PLM implementation I have been involved with system and data integration was a requirement at some level. PLM vendors have taken two approaches; one, provide an open database model allowing for easy data access for integration; two, provide a proprietary database that requires the use of APIs (Application Programming Interfaces) to access your PLM data.  Open database solutions tend to fit better with companies who have internal IT resources to perform their integration. The use of APIs tends to require the PLM vendor (or an approved contractor) to perform the integration.  Both methods can be successful; again. it depends on the resources and priorities of your organization.

I hope this article highlights the important considerations in selecting a PLM vendor/system that is not on your typical RFQ system functionality checklists.

Success & PLM


Once upon a PLM

When I first started in the apparel industry, designers didn’t have computers on their desks. Tech Designers typically would share CAD/pattern system workstations. These workstations were not networked so file sharing was via floppy disks. There was usually a mini computer system with green screen terminals for the ERP system. When we were selling our PDM software, we were actually selling the company on the need to have PCs. Designers would carry to meetings manila folders, one for each of their styles. These folders contained CAD printouts, hand drawn sketches, fabric swatches, ERP printouts (folded computer paper with perforated edges), buttons, trims and maybe a floppy disk.

Our pitch followed the lines of, “wouldn’t it be nice if all of this information was stored in a single location that everyone could have access to and you wouldn’t have to worry who borrowed your folder or where you left it?” We usually had positive responses, but I will always remember one head designer at a large mid-west retailer who said:

“Why would I want to put all of this information into the computer when the style isn’t even in production yet?”

She owned the style until it went into production and she didn’t want to share control of her data. I don’t think I even tried to explain it to her. These were the same people telling me that software would never replace hand sketches.

“A PLM Success Story”

I was reminded of this story recently. I was visiting a customer who had just completed a “successful” PLM implementation (according to management and IT). I was discussing their image integration points with a Designer, asking at what point she uploaded her Illustrator files to PLM. Her answer seemed very late in the workflow to me: after the samples were approved. I inquired as to how the PLM system showed the image prior to sample approval.

“Oh, it’s too much trouble to put all that data into the system so we wait until we are sure the style will make the line meeting before entering it”.

I asked how the concept samples got produced.

“We send the Illustrator file, an Excel spreadsheet and a pattern reference # to the factory and they make the samples based on that”.

I have never viewed “successful PLM implementations” the same since.

What is a successful PLM implementation? 

Typically a company pursuing a PLM system will have a champion, someone who pushes to get a PLM system purchased. This champion usually represents one or two departments who are having difficulty with the current systems in place. One measure of “success” is making these one or two departments happy. This may mean replacing an aging PDM or PLM system, or replacing a manual process of Illustrator and Excel files being e-mailed around. But this is not what most PLM vendors are pitching in their demos – it is not about just solving a particular departmental problem. PLM is positioned as an enterprise solution.

Sometimes an edict will come down from upper management about the need to implement PLM; usually with very little guidance on what the goals are. Objectives like shorter development calendars, increased SKU counts or other “bottom line” metrics are used to justify the purchase of PLM, but reaching these types of goals can be done with a poor PLM implementation (usually at the expense of employees’ time and sanity).

I have been asked to help maintain older PDM systems, years after they were “replaced” by successful PLM implementations. In most cases, it turns out that the company didn’t force all departments/brands to use the new system so the older system lingered for years – circumventing the PLM advantages along the way. A deprecated system usually must be used until the current production styles work their way through their lifecycle. It is expected for an older system to survive 9 months or so after the new PLM system is implemented – but 5 years is excessive. The reasons given are

  • The new system is too complicated for our usage; or
  • It doesn’t do “this function” the way we have to have it done.

In reality, management didn’t achieve buy-in from all parties or didn’t remove people who weren’t on-board.

Some successful implementations have been “halted” mid-rollout. They were declared a success even though not all divisions/departments were using the system. Some users were allowed to use or revert to Excel spreadsheets and e-mail. There was too large of an investment to admit failure so management, and investors all believe that PLM is adding to the bottom line when, in truth, they wasted their money.

In another case, a division (previously a company that was acquired) is allowed to continue to use its older PDM system rather than the new corporate PLM system. Not because the division didn’t see the value in the new PLM system, but rather that their old system was paid for but acquired constant additional costs; corporate would “bill” them for not only the cost of the new PLM licenses and maintenance, they would also add IT overhead to the monthly bill – even though the IT staff was off-site and its effort would be unchanged. While the PLM system might have saved more than the charges, it was a matter of control and politics that ruled their decision.

Product Lifecyle – you already have one

The issue is the very idea of success – PLM is not an application that is installed, turned on and maintained. It isn’t even necessarily a single application. Everyone has a product lifecycle management system; it may be completely manual or even paper based. If you produce products, you are managing them through a lifecycle (even if you aren’t aware of it). Automating your management of products and optimizing the workflows while instituting metrics (for continual process improvement) should be the measure of success. It is an unending road and tone that may lead through multiple PLM vendors along the way.

Which PLM?

Many times I have been asked which PLM software I think a particular company should purchase. My answer is always:

“It doesn’t really matter. I can make any of them work, but only if management has a commitment to change.”

It is not the software, it is about how you use the system as a team. If departmental barriers (budgets and bonuses) remain in the way, no software will make department heads cooperate. If “blame games” remain the status quo, how can computers help?

Ongoing and Evolving

If you view your PLM implementation as “complete”, then you don’t have a successful implementation. If you are not taking advantage of Adobe Creative Cloud or 3D modeling, your system is falling behind. PLM should be viewed as an on-going process improvement initiative; one that utilizes the latest technology improvements while continuing to adjust fast changing markets. If your PLM budget has an end date, you might need to rethink your approach.

This article originally appeared:

15 – How can it be 15 years?


As we reflect and celebrate on our 15 year anniversary, we are so proud of how far we have come.  When we started, we set out to fill in gaps of for the widely known and implemented, webPDM ™ by Gerber Technology. It actually goes even further back then that; we started with Microdynamics “classic PDM”. As E-Spec enters its 15th year, we continue to evolve and redefine our company. It has been a long journey; going from consulting to customization and ERP integration to our sweet spot – enabling Creatives to painlessly manage their content and workflow.

While the first versions of our image integration tools only supported webPDM, they now support additional business systems. With our tools gaining maturity and implementing industry standards, they now allow us to support almost any business system, database or website.

Our tools are integrated and in production with:

We have working prototypes with customers/vendors for:

Because our tools implement industry standards, they can easily be integrated into almost any workflow. We use RESTful and SOAP webservices to access the system’s APIs. We use Adobe XMP (standard and custom schemas) for easy integration of metadata. We support SQL-based databases; including, Microsoft SQL Server, MySQL, Oracle and others.

Side note about time and costs:  As our tools have matured, the implementation time is now weeks not months. As our feature set is complete (no need for further customization), so the costs have gone down. Our last three implementations of our entire product suite averaged under $600 a user – all in; installation, training and licenses. Each implementation was up and running within the month of installation.

Don’t see your system on our list? Call us. We’ll get you there.