Images Drive Your Business

Images drive your business.  A design sketch initiates a new product. Technical details are captured in images used to tell a vendor how to build the product. Photos market the new product to consumers. Logos identify the product as yours. When problems arise in manufacturing, pictures document the defects. Sales and inventory reports include images as a reference. Customer service agents use pictures to ensure they are talking about the correct item. Websites require multiple images of the same product. Store signage must have large versions of the pictures.  Marketing needs pictures of the product being used. If your company creates products, images are involved in every aspect of your business.Most companies treat images as after thoughts – something that must accompany their data. Images are lumped together on departmental systems; each department maintaining their own copies and trying to ensure they have the latest and correct version of the image. When enterprise software systems are implemented, they may capture images and include them as part of “one version of the truth”, but the truth is: not every one uses the enterprise software – but everyone uses images.

Linear Workflow Ends in DAM

Previously, the product development department would hand products over to marketing, sales and production in a linear fashion. In today’s world speed to market requires all these tasks to be performed in parallel; the hand-offs are not done all at once. They are iterative. There are plenty of solutions being offered to help automate this complicated workflow and communications, but they still treat images as overhead and attachments.

In the linear workflow, the Digital Asset Management (DAM) system is at the end of the process. Assets are stored when they are complete; the DAM is more of a repository or archive.

Make DAM the Hub

In the world of today, the DAM system needs to be involved up front. DAM is the hub of your business, enabling the images to drive the process.

How?

• Define common attributes – enterprise taxonomy and vocabulary The first step towards implementing an enterprise approach to integration is to define the terminology used by each department and their business systems. This exercise includes mapping of the attributes between systems and documenting the allowed values. Relationships between the attributes should also be captured, such as “one-to-many” and “many-to-one”.

• Use embedded metadata – standard and custom Adobe’s XMP is the industry standard for formatting metadata. It is used in JPGs created by most cameras and previous metadata standards have adopted XMP versions. The current standards contain fields for common elements (especially for photography and publishing) but the power of XMP is the ability to define your own custom schema and tags. Custom fields are used to store your taxonomy and vocabulary.

• Use system’s API’s (RESTful and SOAP if you haven’t upgraded in a while) It used to be common for business systems to have an “open” database. This allowed integration to be accomplished at the database level. Today it is more common for the vendor to supply Application Programming Interfaces (APIs). These API’s are now adopting industry standard so integration can be performed more easily and in a more generic fashion. The first standard to become popular in recent years was SOAP but this has rapidly been replaced by RESTful APIs. In both cases the syntax is similar to XML (as in the XMP standard), allowing straightforward implementations.

• Collect metadata early at origin To make this integration support your workflow, metadata needs to be collected as early as possible; collect all the attributes that are known at creation and add new ones as soon as they can be identified. Make the data collection as easy and non-obtrusive as possible – the fewer keystrokes the better. 

• Define common metadata with subsets for user groups/departments As you collect metadata, you need to keep the dialogs as uncluttered as possible. You want to provide the user with only the attribute fields they are concerned with. The file may have many more fields embedded, but the user doesn’t need to see or deal with all of them. Typically you can divide the attributes up by user group or workflow task. This makes user adoption much easier.

An Ideal Scenario

A designer sketches a product design in Adobe Illustrator. Metadata is collected: season, collection, gender, design number, designer’s name and other attributes. The metadata is embedded in the Illustrator file. A JPG version of the file is created and sent to the PLM system along with the metadata. If the metadata points to an existing record, the image is added to that record; if the record does not exist, it is created and the image is added. At the same time a PNG (with transparent background) is sent to an internal website used for cross-departmental communications. The original AI file is cataloged in the DAM system.

The product development advances to the point where a sample is requested from a manufacturing vendor.  When the sample arrives, it is sent to the photo studio for photos. As the photos are being processed, metadata is added to the files (sample number, season, collection, gender, design number, designer’s name and other attributes). The photos are cataloged by the DAM system. It is now possible for systems to use the metadata from their sketch files (JPGs or PNGs) to query the DAM system and retrieve the photos.

As the PLM and ERP systems exchange data, records in the ERP now also match the metadata. The internal website can provide data from a group of styles from multiple systems. By selecting the Season/Collection images, queries can return pricing data from one system, color and size data from another, and sales statistics from yet another system.

A customer service representative can use the image to verify that they are referencing the correct product and then use the metadata to access data from the other systems to respond to the customer’s inquiry. This same functionality can be built in to a “self-service” customer service website.

The Key

The key is to create embedded metadata that combines to build indexes of unique records in every business system. Self-aware images and metadata drive your business workflow and processes.

This article originally appeared in WhichPLM? http://www.whichplm.com/editors-choice/images-drive-your-business.html

Generic Tools–The Key to Simple Integration

After my last article, “PLM Integrations with Adobe Illustrator – Keep It Simple”, I have been asked to expound on the correct simple approach. Our experience is that when the integration is too specific or customized to one particular business system, it limits the user’s flexibility when providing similar content to other destinations. Creative users do not live in a single system vacuum; their content can be used and re-purposed by many other people and systems within the enterprise.Our integration approach is based on:

• Industry standard metadata
• Industry standard API’s (usually RESTful but previously SOAP)
• Separating multiple assets from a single file
• Tools to configure/map the metadata and API’s without programming
• Reusable tools – not customized per system, customer or particular installation

First – Identify Attributes

The first step is to identify the attributes that define a unique item (product, asset, object, style, etc.). In most of our customers, this is Style # and season; sometimes Style #, color, season, size or size range. The combination of these values will identify a unique record in all systems across the enterprise. Associating an image to these values enables the image to be linked to multiple systems.

Other attributes also need to be identified; the taxonomy and vocabulary of the enterprise. This is an exercise in determining the proper nomenclature, knowing what each system calls every attribute. This will allow information to be exchanged between systems.

Creating Metadata Fields

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.

We provide a series of tools that can be configured by the customer to match their requirements. Our metadata collection tools are configured per user/user group. Each configuration is designed to minimize keystrokes for the user. Only the fields the user is concerned with are included. Where possible, default values are assigned to reduce data entry. We collect the metadata as the image is created, embedding the unique identifying data inside the image file. Additional descriptive or informational metadata can also be collected and saved in the file.

Separate Multiple Images

An additional tool is used to separate the multiple images that are contained in a single file. These images are typically separated by layer/sub-layer or by artboards. These derived files will also have the same metadata embedded in them as the original file has.

For systems that “catalog” files (like Digital Asset Management systems), this is enough as these systems will read the metadata and import it with the image into the system. For other systems we provide tools that will write the metadata and the image (or image path) directly to their database. If the database is proprietary or encrypted, we provide tools that will communicate with the system’s API’s to allow the metadata and the image to be imported into the system.

To help automate the integration, “target” locations (folders) are used. Most companies already have something similar in place; users have their individual work areas to store their working files and when the files are ready to enter the workflow, they are saved to shared locations so others can access the files. These shared locations become our “targets”. When a file is saved (or updated) in a target destination, the metadata dialog is displayed and all required fields (typically the unique attributes) must be provided. The file is separated into its individual images and the files routed as defined in the configuration.

Unique Approaches by Companies

Different companies use these tools to solve their unique integration challenges in different ways. One company uses this approach to tie their Illustrator files to the BOM maintained in their ERP system. Another separates the images into both JPG and PNG files; the JPGs are sent to their PLM system while the PNGs are used in their website (transparent PNGs allow the image to maintain the background of the website). The JPGs are later provided to their ERP, sourcing system and data warehouse. With each image, the metadata is used to create and update records in each system. Since the data is “sync’d” between systems, it is possible to query related data across multiple systems.

Another customer implements this approach to integrate Illustrator files to their Digital Asset Management (DAM) system. The DAM acts as an integration hub feeding data and images to all their other business systems. Any changes made to the images or metadata are fed downstream via the DAM.

By using generic tools configured with industry standards, this approach has provided integration with dozens of DAM, PLM, ERP and other business systems. This approach is not limited to just Adobe Illustrator files as many file types now support custom XMP metadata; even files that don’t support XMP can participate using “sidecar” XML files. Even image files can be related to each other; if the design sketch has the same identifying metadata as a photo, a sample’s photo can be used in a report replacing the previous sketch. The opposite can also happen; a customer service representative can access the design specs for a product by using the metadata contained in the catalog’s photo of the product.

When the data is collected at its origin and passed along with the image, the image becomes the driver for the workflow through the enterprise.

This article originally appeared in WhichPLM: http://www.whichplm.com/editors-choice/generic-tools-the-key-to-simple-integration.html

PLM Integrations with Adobe Illustrator – Keep It Simple!

---

Too Tight

In 2005 a client asked us to provide an integration between Adobe Illustrator and a PDM (Product Data Management) system. The integration was to solve two issues:

1. Provide a alternate file format that the PDM system’s UI could display;
2. Reduce the number of keystrokes required to get the Illustrator file imported into the PDM system.

For the last 10 years we have been a strong proponent of helping “creative users” provide their images to the required business systems in the most efficient method. Most PLM (Product Lifecycle Management) vendors have embraced this as a way to gain system acceptance among the creative user community. What we have seen develop recently is the advent of “tight” integrations; integration so closely coupled with a particular system that the creative users become burdened with data entry. The integration causes the exact issues that they were meant to resolve.

A recent integration I saw was meant to make the importing of images into a PLM system easier by letting the user remain in Illustrator. The users were not required to open the PLM UI in order to upload images. This was typical years ago when workstations did not have enough RAM to have both applications open at the same time. This caused the user to close Illustrator, open the PLM application and then close PLM in order to return to Illustrator and their next image.

With today’s more powerful hardware this is not the case, in fact many users now have two monitors allowing the user to easily operate both Illustrator and PLM at the same time.  Simply staying in Illustrator should not be the objective; reducing keystrokes and steps to make the user more efficient is the objective.

In this particular integration the user was required to do the following in order to integrate their images with the PLM system:

• Open integration plug-in from the menu
• Use a dialog to logon to the PLM system (Enter system name, username and password)
• Enter information (metadata) in another dialog (Division; Manager; Style #; Description; Project Parent; Master Product; Template)
• Navigate a tree structure for each artboard to “place” the images
• Navigate a tree structure for where the image database record is located
• Submit

Assumptions Made

How is this easier than having both systems open on the same workstation? The vendor essentially recreated the PLM system’s UI within a plug-in in Illustrator.

This integration also assumes that the multiple images contained in the single Illustrator file exist on individual artboards. This is not always the case; there can be multiple images on the same artboard. The image may be needed with and without the text callouts. Multiple colorways may exist on a single artboard but the PLM system will need each colorway as a separate image. This integration made the user responsible for replicating images across multiple artboards – dictating how the user organizes their Illustrator content.

Adding Unnecessary Steps

By providing such a “tight” integration, there is an assumption that the PLM system is the only destination for these images. They have “locked” the Illustrator output within a single system. The creative users are also responsible to provide images to many other destinations; websites, e-commerce systems, marketing departments, sourcing systems, even labels and retail signage. All of these steps will require additional steps/clicks by the user. This integration is counter productive as the users will now see it as adding effort, and not reducing it.

Also, this type of “tight” integration doesn’t allow for varying roles among different sized companies. In small companies, one creative user may be responsible for all data relevant to the image. In larger companies teams of creative users will have artists responsible for the graphics, and designers responsible for the product incorporating the graphics. The data and workflow for these users is different. Tight integrations are not flexible enough to make everyone’s job easier.

Doesn’t Fit the Workflow

Other  “tight” integrations we have seen allow the user to create a complete BOM while in Illustrator.  Again, this is replicating the PLM system’s UI for their raw materials database within Illustrator. The keystrokes are almost identical. The advantage of not opening the actual PLM application is offset by the rigidity imposed on the workflow.  When a sketch is ready for sharing with PLM users, it is not yet time for a complete BOM. All that is required is a family of fabrics and some suggested colors from the seasonal palette. The exact thread, the specific fabric and the packaging information are not required to get an image in PLM. In the seasonal workflow of a designer, many sketches and images are generated early in the season; only some will reach the point in the workflow where a BOM will be required. Many times it is a design assistant or a tech designer who completes the BOM; the person might not even open Illustrator. Tight integrations make assumptions about the duties of the users and the product’s workflow that may not fit the particular implementation.

It seems that “tight” integrations also make the assumption that every consumer of the image needs access to the original editable version of the image. In reality not all users need or want the large original file at their disposal. For previous architectures this may not have caused problems but as more and more applications become cloud based, providing everyone with the large original image is unnecessary overhead. Some users and systems only require an adequate representation of the image in order to view, comment, review, include on a report and possibly print. If a change is needed, in most cases the original author of the image is asked to make the change.

Limiting the image integration to Illustrator is also a problem. The same users will have images that do not originate in Illustrator. Forcing the user to import those images into Illustrator in order to use the integration is counter-productive.  JPGs from cameras, output from Photoshop and Light Room as well as other digital applications must all be easily integrated with the business systems.

Keep it Simple, Silly

A better solution is to provide a more flexible “generic” integration; one that focuses on the image or asset rather than the system’s data. Use of standard and custom metadata to drive the integration makes the image the link between users and data. It enables multiple systems to access the same images. It allows representative versions to be “tied” to the original file. It allows the image to support the desired workflow rather than having an integration dictate your business processes.

PLM users get very frustrated with some of the Illustrator integrations out there. The most common reaction I have observed is that the user stalls as long as possible before submitting the image to the PLM system.  Designers have used AI files, Excel spreadsheets and e-mail to get their samples made and then, only after sample approval, do they use the Illustrator integration to place the image in the PLM system. They then just backfill the required data and the PLM system misses an entire step in the workflow.  That can’t be the intention of the vendor’s integration.

Things have changed in the last 10 years and are changing at a faster rate. It’s time for a new approach on how to use images in the enterprise. One thing is for sure: we need to try to keep it simple.

Apparel, Retail and Consumer Goods: PLM Selection Considerations

---

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.

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

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.

Adobe Releases CC2015; Why are you still using CS6?

On June 30, 2015 Adobe released Creative Cloud 2015; Creative Cloud is now over two years old but I find many companies hanging on to CS6. My question is, why? Here is what should be considered.Misconception: Some think that Adobe Creative Cloud applications are “cloud-based”; that they run on a remote server. This is not the case; the applications are still downloaded to your workstation and installed just like they were from a CD or DVD. The applications run on your computer.

Licensing: What has changed is the licensing and payment strategy. Adobe now uses a subscription-based model for licensing; you “rent” the application by the month (with a discount for paying for a year at a time). Applications available individually or “bundled” so you don’t necessarily have to subscribe to the entire suite. Previously you purchased a license for the application and if you included support, you could get free updates to fix bugs. This model also included bundling of the application or purchasing individual applications. Under the purchased license strategy you were required to buy upgrades for each major release; typically at least every two years. In my opinion, over a period of several years the costs to use the software is close to the same. The advantage to the consumer is Adobe’s Creative Cloud now includes many useful features that were not available under the old licensing model.

Budgets: When Creative Cloud was initially released, I heard several arguments regarding “double dipping” – “we have already paid for CS6, why should we begin paying a monthly subscription too?” This may have had some validity during the first rollout as Adobe didn’t provide any “credit” for existing licenses (like they do for an upgrade). Now that we are on the third release of CC, you have gotten your money’s worth from your CS6 purchase. The other argument regarded “capital” vs. “expense” budgets; purchases are regarded as capital expenditure and subscriptions come out of the expense budget. I have found that using the subscription model, many companies can actually save money. One example is the use of contractors during peak times; the contractors can be assigned a license on a monthly basis rather than consuming a purchased license.

Software updates: Initially IT departments had a major valid concern regarding updates on the applications. Creative Cloud initially allowed each user to decide how and when to apply application updates. This could lead to support issues when users are on different versions of the applications. Adobe released Creative Cloud for Teams (targeted for up to 150 users) and Creative Cloud for Enterprise (over 150 users) that allows an administrator to control the installation and update processes. It also allows for easy transfer of licenses among users. With Team and Enterprise version, IT actually has more options and control than under the CS6 versions.

Integration support: Another concern is the support for integrations between the Adobe applications and other business systems and processes. From experience, I am aware of the burden Adobe has placed on integration providers. Prior to Creative Cloud Adobe released major releases on a pre-defined basis (yearly or longer) with only minor updates in between. Now the release cycle has accelerated and major features can be added at almost any time. This presents a challenge to vendors who provide integration products and services. The vendor must constantly monitor the pre-release programs so they can prepare for the updates. Even with participation in the pre-release, testing must be completed on the final Adobe release prior to providing updates to the integration. With CC2015, the final release was provided with the public announcement, requiring a delay of integration support. If your vendor is not keeping up, alternative integration strategies may be required.

Advantages of upgrading to CC:Besides the technical issues involved with continued use of CS6 (incompatible file formats and lack of hardware/OS support), there are significant productivity advantages of implementing Creative Cloud.

• File storage options

While your files can be stored in Adobe’s Creative Cloud storage, you can still save your files in your current storage locations. You can take advantage of cloud storage when it makes sense while still keeping your important IP files in your secure servers.

• Shared assets

You can create libraries of assets that you can share with others. Share with colleagues or vendors depending on the asset. Logos, colors, fabric swatches, construction details and almost any reusable asset can be organized into libraries.

• Mobility and multiple devices

Use your libraries and cloud storage to make your files and assets available at work, home and while traveling. You can sync your settings so your workspaces are identical whether at home, work or mobile.

• Access to additional applications

Since you can access application “by the month”, you can occasionally use additional applications as the need rises. In the Creative Suite you purchased a set bundle of applications; Creative Cloud has more “bundled” sets of applications as well as individual applications available.

• Licensing flexibility

With Team and Enterprise editions, you can re-assign licenses among users as required. You can add licenses for just a single month or pay for them for a year and move them among departments and divisions as their workload varies with their season. Freelancers and contractors can easily be accommodated without buying a copy of the application, just rent it.

If you are still using CS6, you owe it to yourself and your organization to explore Adobe’s Creative Cloud 2015.

*Disclosure: I am not an Adobe employee or representative and these comments are not endorsed by Adobe. E-Spec, where I am President and founder, is an Adobe Silver Solution Partner. 

Not all images are created equally

Not all images are created equally, so why do we try to manage them in the same way or within a single system?

Image overload

In recent years the number of images a company must deal with has exploded. What used to be a few sketches, pattern pieces and photos has become a mountain of Illustrator files, digital photos, PDFs and images downloaded from the internet. Images are used as inspiration, to convey design concepts, to provide details to vendors, to maintain brand identity, for consumer interaction, for almost every transaction and interaction that occurs, there is an image.

Back in the day

In the past many business systems contained no images, then a few started to include “thumbnails” for browsing and reporting. Most images were maintained in product systems and marketing systems. Departments and individuals managed their own images as best they could; using the file system tools provided by their operating systems and networks.

What’s in a name?

Most of the organization was implemented using folders and sub-folders along with “intelligent” file names. Over the years prefixes and suffixes ran out of room, so most of the “intelligence” was lost. Many business systems had file name restrictions on length and special characters, further limiting the “intelligence” of the file names.  This also meant that in newer systems more descriptive (and longer) names were used, making integration with the older systems a challenge.

Bandaids

Many departments started using various applications to help manage their images; PDM/PLM systems in product development areas and DAM systems in marketing departments are typical. These are what I refer to as “point solutions”; they only addressed the immediate needs of the departmental users. Little or no thought was expended to other users of the same images and typically there was little enforcement of rules; users still maintain their own images, submitting only the bare minimum to the departmental systems. User share folders on the network continue to explode. The typical IT reaction was to add hard drive space; enabling the problem further.

Recently Master Data Management (MDM) and Product Information Management (PIM) initiatives and systems have come into play. While these don’t address images directly, they do try to enable enterprise-level consistency of data about the company’s products and services. This data is “data about data” – metadata. Most of these initiatives still treat images as an afterthought rather than the lifeblood of the company’s creativity and workflow.

Solution- An Enterprise Approach

What is required to achieve industry best practice in regard to images is an enterprise approach. This approach must include enterprise taxonomy and an enterprise structured vocabulary. Taxonomy creates the classifications for the business; division, department, product type, season, collection – how the business attributes are organized. The vocabulary creates the nomenclature; being structured means everyone uses the same values or names, across departments, systems and users. The taxonomy and vocabulary must be consistent across all business systems so the data elements are easily exchanged allowing for integration.

With an enterprise taxonomy and vocabulary in place, images can be “tagged” with compliant metadata allowing the image to be accessed via the metadata by any user from any system. Best practice is to embed the metadata into the file itself, this allows the image to move (or be copied) from system to system, location to location and still retain the information. The image becomes “self-aware”.

The first metadata attribute should be “image type”. Each image type will have a subset of metadata attributes associated with it. Fabric images will have a different subset of attributes than a style sketch or a sample photo. Each subset will have common enterprise attributes to relate the image to its workflow, users and systems. Having the enterprise level standards allow images to participate in multiple workflows and systems.

Implementing an enterprise level DAM (Digital Asset Management) system enables the sharing of images from a single source. DAM systems don’t have to move or create additional copies of the images; they catalog and index the images in their current locations. Metadata is extracted form the images and imported into the DAM database allowing easy access to the images and the metadata.  Images can be “served” with the proper file format and resolution from the original source file tracked by the DAM. Applications can access images on demand or they can be “copied” as required. If the metadata is embedded in the copy of the images, the applications continue to have access to the metadata.

Folders, sub-folders and file names can still help manage the images but with the addition of embedded metadata and an enterprise DAM, images are no longer locked into “point solution” databases or departmental network share locations. All users and applications can access the images as they progress through their workflows.  The ever-growing image repositories can be managed.

Benefit

Images now drive your business rather than filling your network storage and clogging your business processes.

6 Adobe Illustrator Best Practices for Apparel, Fashion and Retail

Adobe Illustrator is the premier drawing tool of the Apparel, Fashion and Retail Industry. We found 6 ways to save time through improved efficiency and consistency.

Set up a Common File Structure

An artist, designer or tech designer will store their files in a designated local working location. Once the user has the work to the point where they want to share it with other users in their department or company, it will be moved to a designated shared location on the network. A folder structure is typically used to organize the files. Best practice is for an administrator to create the structure prior to the users saving the files. The folder structure should mimic the companies processes; typically season, product type, division, gender, etc. The number of levels should be adequate to categorize the files but small enough to reduce complexity. The order of the levels can also be crucial; if a company manages its business by season, season should be one of the top levels – not at the bottom. This makes file management (archiving, sharing, security, etc.) much faster and easier. Four of five levels is usually adequate and anything over seven can make navigation too time consuming.

Start with Templates

In order to maintain consistency among multiple users, these files should be based on templates. The temple will implement standards, but will also be flexible to support various uses. Multiple templates can be used support various functions and product types. Typically there will be different templates for Artists (artwork), Designers (style sketches and colorways) and Tech Designers (details and call-outs); in smaller companies or departments, the same people may perform these roles so the templates may also be combined.

Variations of the templates may also be required to support different products or markets. Some companies use one template for knits and another for wovens, or a template for Men’s, another for Women’s and a third for Children’s. As product complexity changes, different templates may also be required; T-shirts and lingerie may not be able to share a template.

In almost all cases multiple images are maintained in a single Illustrator file. They might be sketches for the front, back and side views with additional detail images with callouts; it might be a plain black and white drawing with a “filled” version for each colorway; it might be one piece of artwork with size variations for different applications (the artwork may be used on the garment, the label, marketing material, websites, in-store signage, etc.). Keeping these multiple images in a single file makes maintaining changes that impact all of the images much easier for the user. The template should be created with a “place holder” for each of these images. Originally this was accomplished using layers and sub-layers; with the addition of multiple artboards in Illustrator, artboards may also be used. This approach allows the user to easily maintain all of the images in the file while making exporting the individual images easier so they can be provided to their particular recipient.

A template can include an object library of pre-existing approved objects. Logos, branding standards, buttons, trims, standard call-outs, etc. can be included. The object library can be specific for the intended usage of the template – only keeping the relevant reusable objects so that searching is easier.

Utilize Standard Libraries

The usage of these libraries should be standardized. In some cases the object should be copied and others linked; by linking a logo, any changes made to the logo can update all the instances in the file. Copying makes more sense when the each instance needs to be maintained individually.

Utilize Standard Color Palettes

A similar practice should be used for color palettes. A standard and a seasonal color palette should be included in each template. This doesn’t keep the user from creating their own colors but it does encourage the usage of the agreed upon palettes. Note this makes the templates seasonal, meaning they will need to be updated with the correct palettes each season.

Store Metadata with the file

Most templates also include a standard header and footer; the header usually contains the information about the file and its intended usage; season, collection, designer, delivery, product type, size range, etc. The footer typically contains copyright information, company information as well as date/time stamps.

Many of the values contained in the header may also be the same values used in the folder hierarchy. These values are data about the file; metadata. Many companies have Master Data Management projects/systems; this means the company is implementing an enterprise level taxonomy and vocabulary (simply put – every one agrees to call things by the same name). The metadata should comply with these standards. Illustrator (being an Adobe product) supports embedded metadata (using the Adobe standard XMP). The future is to embed the file’s metadata within the file itself using the XMP standard. XMP metadata is available to applications without the need to open the file. Applications like Bridge can allow users to search for files based on the metadata.

About E-Spec, Inc.

E-Spec, Inc. is an Adobe® Solutions partner, which means images are at the forefront of our focus. From the creation of an image, we embed XMP data that flows through your business systems. This creates a digital image workflow through the combination of image files and related data; allowing images to flow to all systems instead of remaining locked inside a single database or location. Our suite of products and services utilize Adobe® technology to embed data within the image file; Illustrator, Photoshop, InDesign, JPGs, PNGs and PDFs; so the files become self-aware, allowing the image to drive your business.

Dan Hudson, President E-Spec, Inc. dan@e-spec.net  http://www.e-spec.net

Want to improve your webPDM experience?

If you are still running webPDM, you might need a health check.

Are you experiencing:

• “run-time” errors ?
• browser timeouts?
• print servers which must be restarted daily?
• slower running speeds?

Some of the causes of your inadequate user experience may be caused by:

• Hierarchy changes
• files and images that begin to clutter your system
• database records that were deleted –causing “orphaned” images and files
• inactive users and user groups
• un-purged log files
• extra hardware that was never added even though additional users were

In a recent Health Check, we found over 27,000 orphaned images!

With our webPDM Health Check, you can extend and improve performance of your existing webPDM.increasing performance and decreasing run-time errors and system restarts.

Let’s discuss how best to optimize your webPDM today!

Call us: 214 616 0527 or email us at sales@e-spec.net

Enterprise Digital Workflow and what it means

Learn how to create a digital media workflow using metadata and automated integration tools from E-Spec!
Create media assets Identify attributes using metadata Convert assets to useable file formats Deliver assets to databases, systems and websites Publish line sheets, catalogs, and other electronic documents.

Does your business process include enterprise image management?

Here are 5 reasons it should:

1 Your images have a lifecycle too. Metadata should be entered by the creator and updated throughout the workflow.

2 Your metadata matters. It should be consistent, searchable, and easy for the users to enter and in some cases collected automatically.

3 How many clicks do your creators use to save their files in other formats for downstream systems and departments? These formats should be automatically created on save; and each time you edit later.

4 Is your file directory a huge navigation mess? The filing structure should be created automatically based on consistent file information that is saved within the file.

5 Need to know information about that image downstream? Look it up in the stored metadata. It’s all there because your images are now self aware.