Companies planning to implement DAM for the first time or replacing something they already have typically spend large amounts of time analyzing technical functionality from various DAM vendors and ignoring or, at least, postponing the real challenge for success in the 80%. ROI really has little to do with the vendor at all. Granted, basic DAM functionality needs to be there: search, taxonomy, conversions, collections, check-in/check-out, social tools, etc. But the real work is in getting people to use the tool effectively across the enterprise.
The primary challenge for a corporate digital asset management system is to effectively manage the natural tendency of corporate employees to hold onto digital assets as “mine” and not be willing to make them easily accessible to others by investing the time and effort to properly “tag” or describe them in metadata. Different groups within corporations typically compete with each other for resources, recognition, budget, etc. What should I help “Joe” or “Mary” over in “XYZ Dept” find “my” assets. “Why should I help them meet deadlines through re-use when my department is already behind schedule ??”
Whether publicly articulated or not, this issue rears it head in one form or another. “Why should I share my work with anyone else but my team???”
Well, the answer is the same as for people rowing in a boat: the more everyone rows in the same direction, the easier it is for the whole group to move forward!! The ability to extract this truth in the heat of corporate competition is usually the difference between a “good” companies and “great” ones (see Collins Good to Great) .
In many respects, the adoption of digital asset management today follows a scenario from many years ago with the early adoption of relational databases.
I am old enough to remember when companies such as a global bank discovered that customer information (names, addresses, and phone numbers, etc) should be stored in a secure place where authorized bank employees could easily find them. In addition to security, consistency or reliability of the information was also desired. Updates such as an address change could be done once and in one place. This need created the market for relational databases such as Oracle(™) or Sybase(™) The alternatives were paper files, spreadsheets, personal databases such as Filemaker Pro(™).
However, a classic banking customer relationship problem of the day surfaced when banks did not fully share the information and is described as follows: A major banking institution such as Chase has a large customer in their wholesale division, say, a Fortune 500 company with a $50M credit line. The CEO of that bank enjoys a privileged relationship with the bank and has wholesale bank executives and account managers falling over themselves supporting and maintaining the account.
The bank had invested in a modern relational database to keep an up to date record of the bank’s accounts, etc. However, the database only contained information about the $50M credit line and other accounts within the wholesale side of the bank because executives of the wholesale decision were unwilling to share any customer information with the retail or any other division of the bank declaring that these customers were “our” customers and didn’t trust anyone outside of the wholesale division with “their” data.
So what happens next is this… The daughter of the CEO of the Fortune 500 bank customer leaves for freshman year at a fine liberal arts college in New Hampshire. She goes into a local Chase branch and applies for a credit card or car loan. Guess what happens! She is denied credit because the bank sees only a young woman with no credit history applying for a loan. The fact that her father is one of Chase’s largest customer is lost on the local Chase branch in New Hampshire The retail customer database has no information about the woman or her Dad because the data was not shared. Dad launches an angry phone call to Chase, and, although the matter is quickly resolved, needless damage is done to relationship between Chase and their Fortune 500 customer.
Of course, such a scenario would be considered ridiculous today as banks learned long ago that all data pertaining to the bank’s “relationship” with their customers needs to be readily available to all authorized bank employees across all customer facing divisions of the bank.
Today, with digital asset management, we have a similar situation playing out between various groups across the enterprise, whether it’s creatives vs marketing, or customer service vs sales, one group wants to hold it’s data (digital assets) close and prevent another group from “messing” with them. This leads to various permutations of the bank scenario.
The solution is to create a corporate culture that embraces sharing and cooperation. Once that is in place, successfully implementing an enterprise DAM is easy.