Ed Smith recently wrote an article for CMSWire, "My Other DAM is a Self-Service Intranet Portal," comparing DAM systems to self-service petrol stations where drivers can fill up their cars themselves. While Ed makes some good points, my own experience suggests that self-service isn't a stop and pump solution.
The examples Ed has given are all good ones, however, in many cases, the range of functionality that DAM is now being put to are extending beyond simply finding assets. When one gets into MRM, or other more sophisticated asset manipulation activities, the process becomes more complex and that can present some new or unexpected challenges.
Technical or Human Challenges
As a consultant, I sometimes get called in to advise on implementations that aren't delivering the anticipated benefits. On a few occasions, an analysis reveals that it is often that euphemistic "PEBKAC (Problem Exists Between Keyboard And Chair) fault. At this point, the focus of the engagement shifts from away from technical considerations and towards HR (Human Resources) questions.
So, what how do you recognize those problems and avoid them with your own DAM implementations? The issue that I am talking about was briefly touched on in Ed's article where says:
As one DAM attendant recently bemoaned, 'They need my brain to find anything!'"
Many times I find that what end users really want is a "DAM Servant" rather than a "DAM Service." I will illustrate this with an example from a client I once worked with.
The firm's staff headcount for the marketing department was already at the limit set by senior managers. Spending on productivity enhancements like software were permitted, but new hires would definitely not get approved. So they commenced a search for some DAM/MRM software that could be deployed to enhance productivity.
The objective was to reduce pressure on mid-managers in head office by enabling more of a self-service approach and to delegate the basic work to local users in regional offices. As well as asset searches for static marketing assets like presentations, brochures, etc, they also required facilities to prepare custom print templates and order promotional merchandise. The solution they decided to go with was a system that provided the "one-stop shop" DAM/MRM feature set they needed.
The vendor appeared to do everything by the book. They had a platform that could handle the majority of the required core functionality with minimal customization. They interviewed all of the key stakeholders in the marketing department. Business rules about workflow were documented in some detail. It all looked like textbook stuff.
A specification of both the configuration and customization needed was presented to the client for approval and feedback and the sign-off was delivered. The shortness of the timeframe between submission and sign-off (two business days) without any suggested amendments by the client was the first indicator of a potential problem.
The software was duly configured, custom changes made and it was rolled out. Training was delivered, but using the "cascade" method where head office staff were instructed on the understanding that they would in turn train each region. This was carried out too, but attendance by end users at workshops was optional (and patchy as a result).
When Self-Service Meets Resistance
As is common with new software, the end users were initially upbeat and eager to try it out. About a month or two afterwards, however, they were complaining about processes taking too long and being over-complex. The vendor and the client were also at loggerheads as the vendor's support helpdesk were inundated with requests for assistance which the vendor claimed were well outside their remit.
Continue reading this article:
Source : cmswire[dot]com
Running a