Auditing Your DAM System And Ensuring You Are Able To Take Advantage Of Innovations Developed By Your Chosen DAM Vendor
One of our featured DAM vendors, Widen, have released an article on auditing your existing DAM system. They cover a number of steps, including:
- Produce a ‘snapshot’ of your current situation.
- Identify your user base.
- Examine your roles and permissions (who can do what with your assets).
- What are the most popular assets?
- Optimising your categories and metadata attributes as well as re-assessing any opportunity to use embedded metadata that may have been missed.
- Any features your vendor has introduced which you are not taking advantage of.
In a similar vein, the book by David Diamond of Picture Park, The DAM Survival Guide is well worth a read and covers a number of areas touched on in this article.
The last point in the Widen article about new features is an interesting one. I have encountered a number of scenarios where the implementation of a DAM for a client by a vendor was so painful for everyone involved that the vendors had (for the most part) elected to cease upgrading the deployed solution and just left it hoping that the users would ‘make do’ with what they had already deployed. The cause of this was about a 70/30 split between highly restrictive server access procedures and heavy customisation and/or configuration. These types of issues are more common with on-premise installations since with SaaS or ‘multi-tenanted’ Cloud apps, the opportunities to heavily adapt the solution are limited (so presumably vendors that can only do SaaS wouldn’t have been discounted during the purchasing phase). In the case of Cloud/SaaS, the reverse problem often occurs where a new feature is rolled out and one group of users not only don’t want it, but actively would like it removed for them specifically and either it’s a core upgrade or the vendor hasn’t built in the option to switch it off.
It does seem that DAM systems are among some of the most complex applications to deploy, in part due to the large number of moving parts in the form of ancillary applications to handle proxy generation, transcoding, databases, LDAP integration etc. When this complexity runs into your typical corporate IT policy (which is to treat internal servers like ‘fortresses’ to be defended at all costs) things really start to get difficult for DAM system suppliers. Many users (especially those from more sensitive industries like financial services) are not permitted to use a SaaS/Cloud option (and may not want to for reasons discussed). Further, where the IT department is closely involved in procurement, their default position does tend to favour installation on their own servers (with any deployment work involved carried out by their personnel).
So as well as checking what interesting new features a vendor has, another useful tactic would be to get feedback from them to find out what issues they face getting updates deployed and to try and make this process a little easier for them to carry out – this might encourage them to be more willing to fix some of the glitches, limitations and other bottlenecks that end users have probably just been putting up with.
Share this Article:
Kudos to Widen on a very nice addition to Henrik’s original piece! (And thank you, Naresh, for the “DAM Survival Guide” shout out.)
Your assessment in this article about the complexity of DAM deployment is spot on. By nature, DAM systems exist solely to interact with objects and processes that involve other software, and human habits and expectations too. Whereas, for example, Adobe Photoshop gets to focus on a relatively tight target user and use case, DAM systems have to remain fairly horizontal in their capabilities. (Those of us in DAM Marketing understand the complexities this presents in trying to speak to diverse audiences.)
All that said, I think DAM software has suffered over the years from the very same ailment that has doomed so many individual DAM deployments: The advice, desires and habits of the end user are not taken seriously enough, if at all. Borrowing the Photoshop example again, I think you’d find that most Photoshop users have wish lists that involve making tweaks to the way Photoshop does things. But for DAM systems, you find user wish lists that are rich with ideas about filling massive holes of missing functionality. Or, worse, they beg vendors to remove clumsy design flaws that actually get in the way of productivity. We rarely hear Photoshop users complain that Photoshop hinders their work, yet Photoshop is orders of magnitude more complex than most DAMs. (And it’s an on-premise install!)
DAM vendors that do actually listen and respond can find themselves in a trap of often having to provide radical new functionality with each release. This can not only lead to the complexities you mention, but for vendors with sloppier R&D or QA processes, it can lead to a customer base that fears updates rather than embraces them.
DAM is complex–no question. But isn’t software all about reducing and managing complexity for users? No excuses for us DAM vendors–we need to try harder.