Another DAM Blog

Blog about Digital Asset Management


Leave a comment

Is there a real benefit to implementing a DAM?


This was a question posed in a comment received on this blog by a new reader. Obviously, they had not read anything I had written before, but I wanted to answer their question rather than having them believe that a DAM is simply a justification for:

  • Another project just to keep people busy and employed
  • Another application for the collection of ‘shelf babies’ within an organization that does not use the tools which have been developed for them
  • A higher budget to burn on something

Unfortunately, many IT projects are wrongly considered in one or more of these categories listed above because people simply don’t understand them. So, now I will lead you back to the logical business world where people actually want to improve their organization as a whole. I will keep most of this rather simple to understand too.

As more people and organizations accumulate digital assets, they need to:

  • Manage the assets they keep
  • Know what assets they have
  • Know the contents of these assets
  • Know who acquired/created the assets for accountability and sometimes even crediting purposes
  • Know where and how to find the assets
  • Find assets in a timely manner using metadata
  • Know when the assets were acquired/created for the life cycle of the asset and any rights management issues
  • Know what versions/renditions are available of any asset (there is better way than just using so-called unique file names)
  • Enable the use, reuse and re-purposing of assets (how do you spell ROI?)
  • Preview assets from one central repository (let us see what we have)
  • Be organized (really, it is possible)
  • Grow with the organization (rather than against it)
  • Have permission-based access for all users and roles
  • Enable more people throughout the organization to access assets they should have as they need them
  • Enable access to assets 24 hours a day/7 days a week/365 days a year/ from anywhere with internet access/worldwide

These were a few real benefits to implementing a DAM.

Now, who wants to name and count the number of systems that can do all that today, aside from a DAM?


1 Comment

Why should we keep our assets in a DAM?


Some people actually ask themselves this question and wonder why they can’t go back to their old ways of doing business.

Sure, you can. You can also do the following…

  • We can find all my final assets really easily because I have them all right here on my desktop.”

We have:

  • Final1
  • Final02
  • FinalFinal
  • FinalFinalFinal
  • ReallyFinal
  • LastFinal
  • Extrafinal
  • Superfinal
  • SuperduperFinal
  • ExtraLargeFinal
  • Final_with_cheese
  • AlmostFinished_really_Iswear

Ok. I might have a little problem with version control and file naming conventions.

Yes, a DAM can have version control to take care of this little problem a few of us might have.

  • We store all our files on our own desktops.”

desktop is just another silo. Who else can see your assets on your desktop? Can you find all your assets on your own desktop? What happens to these assets when you lose your laptop or get a new computer?

  • We can keep all our assets on shared drives.” Yeah, those are so searchable, right? As long as your perfectly crafted file names say everything about every asset you’ll ever need to know. Oh, wait. Shared drives are not truly searchable to the asset level beyond a so-called unique filename.
  • We have unique file names for every asset.” File names are created by humans and meant for humans outside of a DAM. Many DAM systems do not care what your file names are as long as they are not 250 characters long, filled with spaces and special characters. Scary sounding, huh? Some organizations prior to having a DAM have some of these “unique file names“. You know who you are. Some DAM solutions assign unique identifiers to each and every asset uploaded/imported to the DAM and these make file names into metadata for the DAM.
  • We can keep assets on CDs or external drives so we can share them easily.” You must like burning money if you are still using CDs or DVDs today. Where is the latest version? Which CD is that on again? Or do you need to burn another set of CDs for the latest version of assets? External drives (regardless of how big or small) can get lost, dropped or corrupt very easily. External drives have the same version control issue as CDs, even if backed-up regularly. How often is new version created by someone else? How do you ship these to external clients? That’s free, right?
  • I will just email the asset around to everyone.” Are you planning to fill up every one of those people’s email inbox with high volumes of data? And each one will back up that data multiplied by how many people? What is the file size limitations for your email attachments? 5MB? 10 MB? Some email accounts do not even accept attachments, in fear of viruses. Will you continue to email this asset for each person who needs to see this each time they need to see this asset? Will you repeat this every time they need to see an asset again? Wow, that is a lot of email data repeated over and over again, isn’t it? With a DAM, you could simply send a link to the asset (not email the whole asset) to whomever needs the asset, whether they need just preview it or download the asset, based on permission set by the sender, through the DAM. Let us weigh this option again. Email attachments over and over again vs. email link to asset in DAM which can be updated as needed in DAM.
  • We’ll just FTP the assets to the person who needs it.” That is secure, right? No one else can see the FTP server nor add to the FTP server either, right? And where is the version control on a FTP server? Oops.

What have we learned so far?

  • Use a DAM for assets
  • Associate metadata to each asset in a DAM so you can search and find it again
  • Version control with a DAM
  • Distribute assets with a DAM
  • Prosper and save some money with a DAM.

Let me know if you have any other brilliant ideas on why you should not store assets in a DAM. I would love to share them with readers.


1 Comment

How do I read this DAM documentation?


Don’t we love reading DAM documentation?  I am not referring to the pretty, glossy brochures you get from marketing that has to look great in order to sell you the product. I am referring to the actual DAM documentation which supposedly explains how the DAM works like the guides, manuals, feature sets, configuration options, compendiums of data and volumes of instructions. Instructions are always so easy to read, aren’t they?

Many DAM vendors are reluctant to show us their documentation until we have signed a contract with them. Then we are often stuck trying to understand these things. After we review the tables of contents and volumes of paperwork, we quickly begin to understand why we pay annual support fees for the DAM. We pay them to read and understand their own documentation.

Personally, I have read over the DAM documentation for a few DAM solutions I have used and had the same frustration, but I decided to do something about it. Here is a solution to have up to date, easy to use, easy to navigate documentation:

First, I asked for all the latest documentation (yes, I asked for more) the vendor had for their DAM product. It would help if the vendors updated their documentation as often as they updated the product itself.

Second, I wanted to know everything that was NOT covered in their documentation, such as the new features. If I had a question on how to do something with the DAM which was not discussed in the documentation, I asked. My questions were often forwarded directly to the engineers for an answer. This sometimes exposed more features and little known facts about the functionality of the product.

Then, with the permission of the vendor, I rewrote the documentation. Yes, it was all technical writing. I also had to translate some parts from ‘engineer speak’ back into English. One of the most useful things I did was I wrote step by step directions, complimented with screen shots to illustrate these steps.

I purposely:

  • was not about to re-write the documentation into big thick paper manuals.
  • was not about to print binders full of paper for each DAM user to refer to.
  • was not about to chisel the documentation onto stone tablets.
  • was not going to issue an eraser with each binder for changes.
  • was not about to switch out endless pages per binder for changes.
  • was not about to use a PDF because a user might accidentally refer to an older version of  a PDF with different information which would not help them access immediate, up-to-date results.

This is the 21st century and we have better tools for documentation that occasionally changes, especially since we use computers anyhow.  Welcome to the Web 2.o method of documentation. What I used was an enterprise wiki on our intranet. The enterprise wiki is open to anyone working within our organization’s network at any time from anywhere. The wiki is fully searchable and is kept up to date with latest information at all times. It is updated by me or anyone I assign to edit it. Any changes can be applied to the wiki in seconds. There is full version control, even down to a single character change. Every user can get an email update alerting them of any recent changes to the documentation.

How long did it take me to create the documentation on a wiki? It took me the same amount of time to write on this wiki than it would have as a PDF or paper, but it only takes seconds to update and disseminate to all users. Try that with paper or PDF.

Who uses wikis for their own business? Plenty of businesses are using wikis as a modern dissemination tool for documentation.

Want your own wiki for your own documentation, reports, etc? Do a Google search on wiki or enterprise wiki.

My question to all the vendors is when will they begin offering their documentation as a wiki for their clients as well as their own sanity?