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.
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.