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: http://www.whichplm.com/editors-choice/success-plm.html
We provide our customers with a tool to create the metadata fields. We use Adobe’s XMP metadata standard to create custom XMP fields; these can be text, memo (multi-line text), date, combo boxes (pick lists) and check box fields. The field definitions look very similar to XML.
E-Spec Blog 