In his first article with us this year, frequent contributor Dan Hudson, President of E-Spec, discusses issues with ‘tight’ Adobe/PLM integrations when other systems come into play, and the benefits of ‘flexible’ integrations.
It’s a new year and a time to reflect on the past. Thinking about my previous articles in preparation for this one, I realized I have been “preaching” about allowing creative designers to remain in their native application (Adobe Illustrator, mostly) rather than bouncing back and forth between the product management system (PLM, usually) and their artwork for over 11 years. Providing such a user interface increases the adoption success of the PLM system. This is the year that PLM vendors have jumped on board; most major PLM vendors in the RFA (Retail/Footwear/Apparel) segment now support some level of Illustrator integration.
Most of these integrations are what I have referred to in past articles as “tight integrations”, where the interface is directly linked to the PLM system’s schema. Once this link is established, the Illustrator files are “trapped” within the PLM system. It seems the vendors missed my additional point that the artwork created in Illustrator is also consumed by non-PLM users and systems.
Issues with Tight Integrations
There is nothing inherently wrong with integrating Illustrator “tightly” with the PLM system; what is problematic is locking the file within the PLM system. This content is needed by outside users so, at some point, another copy is exported or saved, severing the tie to the PLM data. This actually creates additional work for the designers, defeating the original purpose of the integration.
The other issue with “tight” integrations is they usually dictate a particular workflow over flexibility. They are geared towards the vendor’s view of how the system should be used. In reality, most medium to larger companies have a diverse collection of products, brands, channels and processes. Configuring the integration for the “typical” product may introduce issues for other workflows.
These “tight” integrations also assume typical workflow duties; Some companies assign BOM entry responsibilities to the designer; others split the tasks between design and tech design; others employ design assistants for data entry – some companies have all three scenarios in different departments. Some designers are responsible for their product through the entire product lifecycle; in other companies, the designer hands the product off to merchandising or sourcing teams and then they continue with the next design. When multiple brands or channels are supported, the required data may also vary. If the integration is not flexible, the user interface may not match the product’s data requirements.
Vendors have an incentive to provide “tight” integrations; if they lock the Illustrator file within their system, any user who requires access will also require a PLM license. They would like everyone to rely on their system. In reality, the PLM system is not the only system in use. The other systems also need access to the Illustrator files (or at least the content) for their workflows. Ideally the other systems would be included within the Illustrator integration but the PLM vendor typically does not include external interfaces within their Illustrator integration. Some allow use of API’s to assist the customer in creating this type of integration, but rarely does it actually happen. The typical answer is the Illustrator user creates an additional copy of the file (or the content) for the other systems.
Benefits of Flexible Integrations
If you have read my previous pieces, you know my answer to this dilemma: Adobe’s XMP metadata. Instead of just linking the file with a record (or dataset) in the PLM system, a portion of the data should be embedded into the file as custom XMP metadata. When the file is copied or exported, this metadata is also embedded in the new files. This allows a “loose” integration approach, which can co-exist with the PLM’s “tight” integration, allowing the file and its content to be used by other departments and systems without accessing the PLM system yet still being “aware” of its connection.
This approach uses a custom XMP metadata schema to maintain hierarchical data that matches the taxonomy and vocabulary used by all of your business systems, processes and workflows. It allows for a “loose” integration between all of the systems via the metadata that creates an index or key between the PLM and the other business systems and websites. Files can be copied or exported and provided to the DAM, ERP, e-Commerce, internal websites, Marketing systems and sourcing systems; each system can access the embedded data to identify the characteristics of the file – what it is and who it belongs to. This data can be used to build queries between systems to enable data mining and metrics across all of the processes and systems in the enterprise.
How it can work
As an example, when a sample of the product is produced one of the workflow steps is to have a photo taken for marketing and e-Commerce. Most PLM systems do not include this step within the system. If you create an XMP schema including fields for:
- Workflow Step,
- Responsible Party,
The selection values for Workflow Step would include ‘Photo Shoot’ and ‘Retouch’; Status values would include ‘Pending’, ‘In Process’, and ‘Complete’; Responsible Party would include the Photographer and the Retouch technician; Location would be used to track the location of the physical sample.
JPGs would be exported from Illustrator for each sample ready to be photographed; their XMP values would be set to Photo Shoot, Pending, Name of Photographer and in-house. These JPGs are placed in a folder that contains sub-folders for each photographer; this folder is a “DropBox” folder with each sub-folder shared with the photographers. An employee searches the folder for images with Photo Shoot, Pending and in-house, they then collect those physical samples and ship them to the address associated with the Photographer, changing the location to Shipped and the status to In Process. The Photographer checks his DropBox and knows which products to expect. When the samples arrive, he changes the location to Photo Studio and as he photographs the samples, he changes the status to complete. He also copies the XMP from the JPG to the photo – not just these XMP values but also the ones that contain the identification of the product (Style Number, Season, Collection, etc.); the photos are also saved in the DropBox.
When all photos are complete, he changes the Work Flow step to Retouch and the status to Pending. The retoucher looks at the DropBox and processes each photo ready to be edited. When done, he modifies the status to Complete.
An employee can now find the completed photos in the DropBox and review them, changing the status to either approved or re-take. The photos that are approved are moved from the DropBox to an internal location accessible to PLM and other systems. The photos can now be linked to the same record and datasets as the original AI file. This is an example of supporting a “loose” external integration that easily co-exists with the PLM vendor’s “tight” integration.
You can utilize your PLM’s vendor’s Illustrator integration and still implement a “loose” integration using XMP metadata – thus providing the best of both approaches.