In E-Spec’s seventh guest article with WhichPLM, President Dan Hudson discusses how to make your files ‘self-aware’, and five reasons your business should have an Enterprise Image Management Solution.
5 Reasons Your Business Should Have an Enterprise Image Management Solution
- Your images have a lifecycle too. Metadata should be entered by the creator and updated throughout the workflow. It helps identify the content of the images, make them searchable and helps them to be integrated into systems.
- Your metadata matters. It should be consistent, searchable, and easy for the users to enter and in some cases collected automatically.
- Your users have too many clicks to save their files in other formats for downstream systems and departments. These formats should be automatically created on save; and updated each time you edit the image.
- Your file directory is a huge navigation mess. The filing structure should be created automatically based on consistent file information that is saved within the file.
- You will need to know information about that image downstream. Now you can look it up in the embedded metadata. It’s all there because your images are now self-aware. If we match a technical design image’s metadata with the marketing photograph’s metadata, we can find the picture of the item made from the sketch.
About DAM Time
Many PLM solutions offer image management capabilities; some will even call their image functionality a DAM (Digital Asset Management) solution. In any case PLM systems will not provide an enterprise approach to image management unless every employee who uses images also uses the PLM system. Most Marketing departments have an image solution already. There are subsets of enterprise images, which belong in PLM, and others which extend beyond the PLM realm. Self-aware images can be easily managed among multiple systems. E-Spec views metadata as a means of system integration while also reducing redundant data entry in the business process.
Keywords vs. Attributes
Our mantra for process improvement is “collect the data at the source and eliminate redundant data entry between systems”. The data of interest is “attribute” data whether it is product attributes, image attributes or file attributes. As the user “publishes” their content for collaboration, they know certain attributes. The goal is to capture these attributes just as the users share their files. Most corporate creative departments allow each user a personal workspace (still on the network so IT maintains the backups) and provide “share” locations where users can collaborate together on this content. In the shared locations, we find “attributes” are maintained using folder/sub-‐folder structures and specific “coding” in the actual file names (did you bring your Dick Tracy decoder ring?). The types of attributes might be the consumer/customer of the content, the type of content or other product information; for example in the fashion world: season, collection, product type, gender, size range, etc.
What I have observed from many metadata discussions is more of a content emphasis; the keywords represent the visual content in the file; the image is of a “dog”, a “retriever”, a “golden retriever” and it is in a “fenced yard”, in the “mountains”, etc. Back to the fashion example, the keywords might include; “dress”, “knee-‐high”, “floral pattern”, “sleeveless” – things that anyone looking at the file can see. Note that some of these keywords might also be considered attributes, but many attributes could not be derived by observing the contents of the file. From looking at the dress, I cannot tell that it belongs to a particular season (Fall 2015) or is intended for a particular customer (Macy’s) or a marketing collection (Martha Stewart). So while attributes and keywords are related and even overlap, their methods of collection may be different.
Attached vs. Embedded
There are different approaches to how the data is captured. Some DAM systems catalog the files and keywords are entered in a database with links to the file (asset). Some of the data may or may not be embedded in the file but a large portion of the data is only contained in the database (a general observation -‐ varies by system/vendor). If the asset is checked out the linked data may or may not travel with the asset.
Our approach has been to immediately embed attribute data in the file; if the file is moved or copied the attributes still exist in the file (the asset has become “self-aware”). If I make a copy of the file and send it to another department for use in their business system, the attribute data is available to integrate the file with other existing business data. If I place the file in a shared “drop box”, the recipient still has access to the attributes in his copy of the file. And if I provide the file to a DAM system, the attributes can be extracted and included with the keywords already being entered. Embedding attributes in the file means the file knows to whom and where it belongs, it knows which external data elements are relevant to it and it can be a conduit for system/data integration.
The optimum approach is to create the attribute taxonomy and vocabulary to match the business applications used in the enterprise workflow. A sub-‐set of the attributes can be used to identify a key to a single record in a particular database; different sub-‐sets for different systems. The creative user is creating an image to be used in producing the previous discussed dress. As they save their work to the shared location, they know some of the attributes; season, customer, collection, gender, product type. As other users work with them, other attributes become known; size range, color, target price, etc. At some point an ID is assigned (prototype #, style #, etc.). Sending a copy of this file to a product development database, a unique record can be created for this style using the embedded attributes. The product development system will then collect additional data about our dress as it progresses through the product workflow (sampling, sourcing, production). This data might be related to the fit of the dress, the required components to make the dress and even the cost. If another copy of the file is sent to an inventory/production system, a unique record can be created there as well.
Additional data will be collected regarding factories, ship dates, quantities, etc. Other copies of the file might be sent to e-‐commerce websites, sourcing systems, etc. The file is provided to our DAM system as well. A user can use the DAM system to find the dress and knowing the attributes, can query the other business systems to get information such as status, sales results or any other data in those databases related to our dress. The dress image has become self-‐aware!
This does not replace or interfere with the traditional DAM approach; it simply provides some data (attributes) earlier in the cycle. Keywords can still be added to our dress (“floral print”, “roses”, etc.) at any point.
The key benefits are numerous and the integration doesn’t stop with business systems. For example, if at some point a photo is taken of our dress to be used in a catalog. If we embed the same attributes in the photo, then later when customer service gets a call about the pink floral dress in the catalog, the metadata can be used to look up in the inventory system how many size 6’s are in stock; they can look up in the product system if the dress fits the same as last season’s model, etc. The photo can take me to the original sketch and from there to the rest of the enterprise.
The point is the taxonomy and vocabulary requirements are different when using metadata for integration and need to be included in your DAM implementation planning – it can’t be added after the fact.
In creative and graphic-‐intensive enterprises, the DAM system can become the hub of data integration by using “self-aware” images.