Reviewing existing Digital Asset Management provisions seems to be a common consulting request for my firm these days and is no doubt due to a maturing wider DAM market. Between a third and half of the prospective users of a new DAM system who contact us already seem to have at least one legacy product they were already using and an increasing number are web based systems first deployed in 2006-2007 when the uptick of interest in DAM was already well underway. Even among those that profess to have no knowledge of any previous solution, legacy products invariably surface after a discovery process and even if not, there are always a multitude of different collections of assets held by a variety of different stakeholders to consider.
Below are a few pointers to help get a review process started and some items you might find useful to consider. Since this subject is quite a diverse and in-depth one (aren’t they all in DAM?) we are running this as a three part article.
What are all the current sources of assets?
Before you can make decisions about new Digital Asset Management initiatives, you need an idea about the nature of the digital assets you need to manage. Any employee (or department) who is holding at least a few hundred assets should be included in your ‘Doomsday spreadsheet’ of asset repositories that you might need to be interested in. The nature of the collection can include any or all of the following: shared network drives, memory sticks, hard drives, emails with attachments, FTP servers, desktop applications, client/server database DAM systems, web based DAM (hosted internally or with an existing vendor), file sharing web applications like Dropbox, Google Drive etc or SaaS/Cloud DAM subscriptions. In addition, there are also semi-official attempts at DAM (usually using ECM or Sharepoint) where assets might be held and another common source is key suppliers who handle your digital assets (like design agencies, video production companies or printers). Finally, you might also encounter (usually at a departmental level) some who have got fed up waiting for a decent centralised solution and just gone out and bought their own and are making significant use of it already.
To identify all these will involve more than just asking a few people and even circulating questionnaires etc. probably won’t elucidate much either (and is at risk of being biased towards certain interest groups who bothered to fill it in). A tactic I have seen which can be effective is to establish an internal communications programme before you implement DAM (in addition to the ones you should be doing afterwards). This should maximise awareness that your organisation’s Digital Asset Management provisions are being reviewed and all those who might be interested or hold collections of assets are both welcome and encouraged to let you know what they’ve got and give you suggestions etc.
Within each source, you need to decide whether it is worth ingesting into any new DAM system or if it should be left as an independent system. Even if it isn’t worthwhile to consolidate and ingest those assets, they should still be archived somewhere, or at the barest minimum a record kept of what is held and by who. For those systems you will retain as independent entities (not part of your main DAM) you must decide if there is any value integrating the data they contain. Technical discussions about how to go about the task can be mostly set aside, but it is worth someone spending a few hours finding out about some of the characteristics of it and what might be involved to effect integration (or migration if that appears to be a better option later).
What I consistently find is there are more legacy DAM applications lurking in companies than was originally anticipated. If you think about this logically, that isn’t a surprise. The DAM industry is heading towards being 25 years old soon and it stands to reason that once people start creating digital media, they are going to need to put it somewhere and also be able to find it again later. Although DAM might be new to you and have only recently acquired a more socially acceptable (even fashionable) status as a class of enterprise application, don’t imagine that many of your predecessors have not already needed to do this for many years already (although they might have used different terminology than ‘Digital Asset Management’). The key point from this question is to have an accurate idea of where everything of potential interest is across the business.
What lessons can be learned from how things were done previously?
The implication of the final paragraph of the last section is that people in your organisation have almost certainly already had to think about the same decisions you need to make now – probably more than once and over a period of many years. Often, I find the prospective end users of DAM come to the subject with a blank sheet of paper. The current situation appears such a mess that they would prefer to start from scratch so they can start to re-build their own understanding of exactly where everything is and what the organisation currently holds. I can understand why they have that mindset, but the mistakes of the past hold valuable lessons to increase the ROI you can generate from a future replacement.
Where the techniques that have been used are more manual or low-tech (like shared drives, USB sticks etc), this is usually quite easy: finding anything is difficult because the organisational decisions may have been poor (e.g. meaningless or generic filenames), there is next to no other metadata anyway and the backup and retention policies were, at best, ad-hoc. On the positive side, however, these less technically sophisticated methods are very easy and employees with basic IT skills (which is the vast majority now) can probably understand them without any special training. Replacing this with a DAM system is likely to improve the organisation of the collection, but it might also impact productivity since staff have to vary their working practices and jump through more hoops than they did before. It’s easy to be glib and insist that everyone will now have to do that, ipso facto, because there is a DAM solution, but what are the implications of that in practice?
For some assets, it is possible you can apply pressure to bear to encourage staff to make use of the DAM and provide training and awareness programmes etc. In other scenarios, for example, time-sensitive marketing campaigns where there are strict deadlines that must be met, forcing staff to use some regimented and complex method using an unfamiliar system will probably fail as there is a higher priority requirement that trumps your exaltations to use the fancy new DAM system the business has just spent lots of cash on getting implemented.
The lesson here is that you might need to consider either multiple collections and/or different workflow and ingestion processes that adapted for each class of asset. Multi-pass methods might also be appropriate where the ‘front line’ production personnel will be responsible for just getting assets into the system so it is aware they exist, then others (in-house or otherwise) go back later and review them to decide what to add value to by enhancing cataloguing data. With existing asset collections where no prior DAM system was involved, the key question is what the trade-off is (in each collections’ case) between the ease and simplicity they offer as compared with the lack of structure and organisation that they cannot.
Where the asset collections are catalogued using an existing software system it is more difficult to presume any existing characteristics (unlike the manual methods described above) but it is easier because a tangible product exists which can be used and tested with example assets to evaluate what is worth keeping and what should be revised in any replacement. As you might expect, reviewing legacy solutions is also quite a wide-ranging topic and in the second part of this article next week, I will cover that subject.