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.
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.
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.
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.
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.