Digital Asset Management Workflow – The Key To Implementing Effective CXM Strategies

There have been a few more articles on DAM in CMSWire over the last week or two.  One which is short, but makes a very good point is this by Irina Guseva: Improve DAM Creative Workflows First, CXM Will Follow.  The theme of the item is that CXM depends on having the right assets available to the relevant people in a timely manner.  To make that objective a reality, the workflow capabilities of DAM solutions are critical:

“While your goal may be better Customer Experience Management, it all starts with assets: the assets that live in your DAM and that multiple people touch in the creative flow. When you start by fixing the problem of ill-designed creative workflows, you start to eliminate duplication of efforts. Do you know how much time is wasted as the asset moves from internal designers to internal approvers to external agency and back? Creative workflows, collaboration, governance and associated processes allow you to be faster and more agile. And that means the creation of more revenue — whose CFO wouldn’t like that?” [Read More]

There has been a fair amount of debate about the value of CXM and DAM’s relationship with it.  I have considered this topic for quite a while and reached the conclusion that it makes a better management theory rather than than a technology-oriented topic (not that the two are necessarily mutually exclusive, I would concede).  That you need a CXM strategy and that your technology should help you realise it I can fully agree with.  The idea that such things like ‘CXM Suites’ get beyond the ‘solution looking for a problem’ cul-de-sac seem less clear cut.  I note Scott Liewehr’s recent critique of the Forrester Digital Experience Delivery Wave: OpenText, Demandware, and Salesforce.com are all on a buyer’s shortlist. What are they buying?   In my opinion, the reason why there is a lack of definition and clarity about this whole subject is because it is not about technology tools, but what you do with them.  That covers a diverse array of problems which do not lend themselves to being reduced to a single classification without the definition bursting at the seams under the strain of over-burdened expectations.

Back on the article, this is an excellent analysis of one of the key issues preventing CXM objectives from being properly realised.  A number of the larger companies who I work with with on their DAM initiatives have an ongoing problem, which is just persuading their users to put assets into their DAM system.  Even before you consider metadata, taxonomies etc, simple accession (i.e. uploading stuff) is quite frequently the biggest issue they currently face.  Significant numbers of users who hold or produce assets just don’t put them in the DAM.  This is not necessarily because they want to hoard the assets to retain control of them or stop others getting access to them (although that does happen) it is because the effort involved is too great and they have more pressing jobs to get out of the way.

There are various methods available which try to ease this, including batch ingestion and simplified uploading using drag & drop features etc but the perceived level of effort involved is still sufficient to de-motivate them.  This is the front-line DAM workflow related problem and many of the others stem from this.  Another DAM-related article in CMSWire by Elliot Sedegah has the recommendation: “Ditch the Shared Network Drive”

“Most of us have already learned this lesson. The shared network drive as a central collaboration space without asset management can be a recipe for disaster. For many organizations, the shared network drive wasn’t the original plan. It was useful in the early production cycle but then it grew into the de facto place to store creative marketing assets. The team went around or didn’t integrate with the DAM for various reasons, from outgrowing a DAM that no longer met the needs of today’s stakeholders to a draconian IT policy that forced creative and marketing teams to use a corporate enterprise CMS that was designed to manage documents, not rich media assets.” [Read More]

I suspect many people who work in the DAM industry (and related fields) might have learned that lesson, but a lot of others couldn’t care less.  When they have finished ‘their bit’ of the asset origination task, they want to save to a shared network drive (because they know where it is and it won’t ask difficult questions) shut-down and go home.  The second part of the quote above alludes to some other attempts to try and join up the dots and solve this issue.  There are features within ECM repositories which can pretend to be network shares that users can save to using a familiar working environment.  They might provide some options for optimising this element but often they fall into states of disrepair post-deployment or have faults, performance issues and incompatibilities which reduce their level of adoption.

Another possibility is direct integration within the user interface of some the origination tools so the users can put them into the DAM there.  There are already many DAM solutions that offer this feature, but they are still not fully universal yet.  Integrating them with SaaS or externally hosted DAM solutions can also increase the deployment complexity beyond what many end users might have bargained for as it usually means they will require the assistance of an in-house IT department (certainly for most larger organisations).

I have discussed just one aspect of DAM workflow, but there are numerous other similar challenges like this as you go further down and across the digital asset supply chain.  Irina mentions that the vendors and implementation services providers have some responsibility for the disjointed workflow which characterises many current DAMs:

“The DAM vendors are partially at fault for failing to provide the necessary support for creative workflows. Systems designers and implementers also share the blame, for not doing a better job designing and implementing creative workflows and proper access rights. And let’s not forget “user error.”[Read More]

I don’t think I would argue with that, however, there are two points I will make about reasons why this problem has become the issue that it has.  Firstly, I can point to numerous occasions when I have been involved with a DAM implementation and the business process model employed by the organisation was over-complicated and contained more steps than was needed, or was just broken anyway and everyone just learned to work around it.  Many of the vendors are aware that they can’t argue too loudly about a workflow that is needlessly complex in case someone from the client questions their technical ability to deliver the requirements in full (and as all DAM software sales guys get taught, you never, ever say ‘no’).  When the implementation services providers get called in, it is either a rescue mission (to save a vendor whose sales people should have been less obliging pre-appointment) or because a tight brief has been defined and the client is eager to emphasise that they are paying everyone at the sharp end to deliver a result, not argue about whether it was a good idea or not.  Many over-complex existing (pre-DAM) workflows depend on human software to function properly and which has been extensively trained and refined over many years.  When software people try and rationalise all that into code logic, they either end up trying to build complicated custom pseudo-artificial intelligence apps (usually without success) or they have to simplify it and the flaws lurking in the process model are thrown into sharp relief.

The second point, is that DAM workflows are routinely underestimated, both in terms of cost and complexity.  As has been mentioned on these pages before, there is a ‘features arms race’ on-going in DAM where the vendors are required to spread themselves over an ever-wider area of functional scope.  To meet that, they have to skim across the top of the requirements and ensure they have something which ticks a box, so they won’t be the only ones in the pitch who can’t deliver on some currently fashionable requirement or other.  The result is this ‘bag of bits’ effect described in Irina’s article:

“What the DAM system usually provides is an array of mainly disjointed tools and processes. A toolset or semi-integration with, say, Adobe Bridge for designers, an integration with CMS for content managers, Dropbox and Google Docs for collaboration and file sharing among marketers, measly if any integration with Facebook and Pinterest for social media managers, and often very little insight into the DAM system for sales force.” [Read More]

There are DAM vendors who focus on workflow and claim it to be a core of their offer.  That they can support complex workflows and reconfigure them to adapt to changing requirements might well be correct.  The areas where many current participants in the DAM market lack the required sophistication, however, are on providing a cohesive user experience where all the parts look and feel like they were built to work together as a single functional unit.  This is one of the minutae detail that derails the most well intentioned of CXM strategies (and as described in the article, the key one).

A lot of end users with executive responsibility for CXM strategy might be taking the view that these are problems which will get solved, but they (and many of the people who are paid to advise them) are in-line to be disappointed by the slow progress in this area.  If you want it in simple terms, CXM technology is trying to run before it can even stand, let alone walk.  Rather than trying  to aggregate together ever more incompatible and disparate technologies into some kind of monolithic CXM grand techno-coalition, it’s the detail of getting this stuff to work together which is where attention should be directed and where the ROI opportunity is far more substantial and easier to realise.

Share this Article: