2014-20-May-Darth-Vader-Valet.jpgWhen management gets wind of an up and coming software application and decides it's necessary for business objectives, the results are often the same. A decision is made to adopt one product -- to the exclusion of all others -- which everyone will be expected to use.

I think it's folly to impose a monolithic solution to cover the entire Digital Asset Management needs of an enterprise. An integrated, best of breed approach is more likely to succeed.

DAM Is Already More Widely in Use than You Think

When I make first contact with clients planning new enterprise-wide solutions, many are either replacing a single existing platform or are of the opinion that there are no other existing DAM solutions. I usually recommend carrying out a comprehensive audit of all existing repositories of assets, whether held in a system or not. As well as obvious sources like external hard drives, DVDs, memory sticks, etc., an audit usually yields a range of hitherto unknown software applications which the original stakeholders had not been fully aware of, including departmental DAM systems, desktop applications (both custom built or off-the-shelf) and in some cases, SaaS DAM subscriptions. In organizations with more than 1000 employees, it is common to find multiple DAM systems being actively used well before anyone decides to implement an enterprise-wide one.

This revelation can cause some disappointment for the stakeholders of the planned enterprise DAM since it appears to add to the complexity of the task. The benefit is a more realistic assessment of the full scope of any planned enterprise-wide DAM can be carried out with some real examples and usage scenarios.

I also have clients who have either skipped this discovery stage or chose to ignore the existence of other solutions until post-implementation, when they find end users refuse to abandon their existing tools to migrate to the shiny new ones.

Failure to differentiate between heavy asset and typical DAM users is the main issue when auditing existing asset repositories. The former may be net suppliers of assets (i.e. they upload more than they download when measured by unique assets alone). The light users usually will not have any existing files because their own personal media management needs are limited. There is often an incorrect assumption that everyone across the business will behave like a typical end user and have a relatively small collection of media assets which they have never properly attempted to organize before.

Many will be shocked that there have been DAM systems in existence for around 25 years now, separate from any semi-manual methods (using spreadsheets, etc.). While the interfaces of older DAM systems are leagues behind their more modern counterparts in terms of visual sophistication, some older application's metadata features can be as advanced (and a few specialist ones exceed them). Older niche systems usually benefit from both a far tighter scope and years of refinement and feedback from more engaged users.

While this scenario will not be the case for every organization, it is important to come to terms with the fact that many of your former and existing colleagues have thought about this problem before you did. DAM is not new, only your appreciation of the need for it.

The Challenges of Defining DAM Characteristics

Elizabeth Keathley wrote an article for DAM Foundation last month: "What Is A DAM? The 10 Characteristics Of A Digital Asset Management System."  Elizabeth gave 10 key criteria which she considered essential for a DAM system to be considered worthy of the name. I would agree with her list, however, one major caveat is that the interpretation of what they mean in practical terms can have significant implications for the resulting DAM solution.

An example: point two is "workflow":

The ability to construct, monitor, and provide metrics on workflows are inherent to all DAMs; in fact, may people consider this function to be the very point of DAM systems."

An interpretation of workflow in DAM is for approvals purposes (to authorize ingestion or usage) and some defined process that may involve one or more people making decisions which are tracked in the system. Another definition of "workflow" is as it applies to every process in the DAM, whether it involves human beings or otherwise. In some systems these are given more technical descriptions like "triggers" or "events."  Lastly -- as Elizabeth alludes -- some refer to the entire DAM itself as "the workflow system."

From just one point in the defining characteristics of DAM systems, a wide range of potential interpretations is possible. Which one is right? They all can be, until you can define and agree with every single user exactly what is meant by each major feature. The more users who disagree with your interpretation, the less people will want to use your DAM and the lower the ROI from it.