Why DAM Workflow Is Not Flowing

There have been a couple of interesting articles about DAM workflow recently which I have been intending to get around to discussing on DAM News for a few weeks.  One of these is by Roger Howard with the title, Workflow Doesn’t.

Without misinterpreting Roger’s piece, the thesis seems to be that a genuinely productive workflow needs to distinguish between process automation and decision making, with the latter being left to human beings because they are better at it.  The DAM system should provide users with tools to empower them by sub-contracting the time consuming and repetitive  aspects to the system while control about who does what, when and how is retained by the operators.  Here are selection of the points he makes:

“Workflow systems are rigid and don’t reflect the constantly changing realities of most businesses. They are conceptually incompatible with our continual process improvement philosophies.
The rigidity is most often apparent in the decision trees in a workflow – workflow automation largely attempts to move decision making out of the hands of employees and into an automation tool.
Decision making is something humans excel at. It’s almost the thing humans excel at.
Decision making can be rapid and intelligent and flexible when the user has the right tools and information at her fingertips
The valuable stuff is process automation – doing complex tasks with fewer human steps”

[Read More]

I would tend to agree with Roger over all this, however, I do think it might reflect his level of expertise at managing repositories of media and superior understanding of the nature of the task which is unfortunately not shared by many DAM users.

One of the numerous fault-lines in the process of fragmentation ongoing in the DAM market is whether solutions are progressing towards some kind of higher ‘intelligence’ or if their primary role is to leverage your time more efficiently (i.e. increase productivity). The former is like a conjuring trick, played out by amateur magicians who have to deliver the performance three or four times in front of you before they get it right (and somewhat spoil the illusion in the process).  I think this approach is doomed to lead to disappointment for anyone who pins their hopes on it because the problem solving capabilities of most mechanised devices like computer software are woefully poor when compared with those of human beings.  The  competitive advantage the machines have is an ability to industrialise repetitive processes and increase consistency.  Those benefits suggest, however, that you should be using them for productivity enhancement, because that is where the greatest advantage is available at the least cost.

No Solver Bullets

One of the many stages in user’s understanding of DAM is coming to terms with the fact that there is no one single product which does everything you want and before long it will become necessary to effectively de-construct and then rebuild your workflow models so they become progressively more modular and interchangeable.  Roger’s description of his production working environment (which he refers to as ‘JOBX’) is where most DAM users will gravitate to also eventually if they want to continuously improve their efficiency (and many won’t have the luxury of a choice over that decision).

“We couldn’t afford to miss a single beat, and we were almost religious about continually integrating process improvements as they represented our critical strategic edge. We weren’t smarter, better resourced, or more creative than the competition – our primary advantages all began with process control, and were reflected in our key performance indicators, particularly time-to-market, as we existed in a fast-moving market.” [Read More]

This is a point we have been making on DAM News for a number of years now (with particular reference to the DAM Value Chain) and the other article discussing workflow, which was also a follow-up to Roger’s item, by Tim Strehle makes the same connection also.

On the discussion of software vendors and how it is financially advantageous for them to promise workflow solutions that will solve all of a client’s problems (and then fail to live up to expectations) this is an interesting area of discussion.  Up until a few years ago, I would have agreed with him, but with the increased commoditisation of DAM technology, the problems still persist but they have become less of a vendor opportunity to earn fee income and more of complex product development challenge that has to be constantly tackled by everyone involved with a DAM solution, more typically without any fees being incurred now (at least directly through a specific bill for the time involved).

Due to previous activities my employer was engaged in at the time, I have a reasonable level of experience of implementing DAM software for clients (although I am grateful to not still be involved in this market to any significant degree).  While there might have been a professional services income that we could have earned from some of these requirements, it wouldn’t take long for the customer to get irate at the limitations of any unsuitable workflow models and remind us that their budget was not a limitless one, especially when additional expenditure was proposed to solve issues which were uncovered with it (in addition to considerations like who had ultimate responsibility for the workflow or business process being flawed).

Many DAM software operations are typically lightly staffed (even now) with a fairly small number of developers being responsible for some large and sophisticated products with exponentially increasing volumes of users.  Complex workflows are demanding to both architect and code, so the more experienced and skilled members of the team need to be assigned, which means progress on other activities slows down while they are preoccupied on some white elephant solution that has limited use outside the remit of a single customer.  For those DAM vendors who offer either SaaS solutions or who cannot feasibly adjust their codebase to accommodate every prospective customer’s needs, there is even less room for manoeuvre to make compromises.

What happens after a few rounds of these exercises is that everyone decides to ‘solve the problem once and for all’ by trying to come up with a workflow solution that will answer a diverse range of requirements – this can be where the issues with DAM workflow move to a new level.  As alluded to in Roger’s article, effective and efficient workflow is closely modelled each specific use-case, but the nature of software implementation (especially the generic, abstracted and commodity-oriented approaches software vendors usually aspire to) tries to rationalise requirements and reduce scope because the cost of delivering it has to be paid by someone and increasingly, the customer won’t be prepared to cover the bill.  Hence, there is a built-in conflict of interest between the needs of DAM users and software developers that cannot be easily resolved unless there is an opportunity to selectively replace workflow components.  Unfortunately, that runs against current trends in DAM and it seems likely this problem will continue to present itself as a result.

Workflow and DAM Micromanagement

One of the issues with DAM solutions in more recent times is that where in the past, they would be primarily aimed at production personnel and be powerful, but hard to use; a trade-off which users accepted in return for the productivity benefit on offer.  Now they need to accommodate a far wider cross-section of users.  Roger’s description of his work environment sounds like the more classic example where the inexperienced or incompetent get kept away from any opportunity to inflict serious damage to the efficiency of the rest of the team (for example by not being able to introduce files with random names that do not follow a strict convention).  In larger organisations, especially those who have only recently come to the realisation that they have a digital media operation, knowledge of how to structure and manage workflows successfully is not at all well understood and especially the ability to manage who does what and when to media assets.  The result is some fairly ham-fisted attempts at process control that are more like micro-management and cause work to stop rather than flow.  The reason for the decision to implement these kind of controls rarely originates from the vendor, it can be characterised by a thought process like the following:

1. We need to allow our users to do task x.
2. If we let users do that without any restrictions, chaos will ensue.
3. We need to strictly control access/ability to carry out task x by having requests checked by a manager.
4. This thing sends me hundreds of emails every day, I don’t have the time to deal with them, I’ll just ignore it.
5. Lots of people are complaining about their inability to do task x with this system, the software is obviously faulty.

This reads a bit like a template for a Dilbert cartoon and the situation is exacerbated in larger companies because the personnel involved at each of the steps are often not the same, they only see their slice of it and do not understand the original thought process behind design decisions.  Many times when I was still involved in the implementation side of DAM software, questions from clients would come up along the lines of ‘why does this system do that’ and the answer more often than not was ‘because you told us to make it work that way’.

There is a fair argument that those responsible for implementation should use the benefit of their experience to help differentiate between the level of control that is appropriate for process management in DAM solutions, but not everyone wants to listen to that advice and the effects of enabling automation/self-service etc cannot always be properly anticipated.  With that said, in respect of DAM solutions, it is usually preferable for the system to act in an advisory capacity and provide management reports (perhaps with a sparing number of ‘awareness emails’ if certain thresholds are breached) when activities take place, rather than trying to police everything.

Conclusion

Lots of effort is currently being spent on making systems as simple as possible for the non-expert user and to allow managers to make best practice process models concrete through the medium of software.  That this has needed to happen, is not in doubt, but it has further expanded the range of issues that need to be addressed.  The current theme popular with many vendors seems to be denial that there is a workflow issue any longer, like metadata it is often deemed to be a ‘solved problem’ by many.  This is mostly marketing-led, although it needs to be said that the technical personnel themselves tend to dislike having their own less than perfect code creations critically re-examined on a regular basis, so it cannot just be blamed on marketing alone.  Inflating the scope of requirements your product platform claims to address (even if in reality it doesn’t do it that well for any of them) is an easier sale. This strategy provides the opportunity to release lots of PR material with shiny new screengrabs and a new range of buzzwords sucked in from other adjacent fields.  The end users assist this process by their pursuing their fool’s errand quest for the holy grail DAM that does everything.  For a fractional period of time (usually just prior to signing the contract to buy a solution) they even believe this strategy will work.

As well as focussing on productivity enhancement as opposed to process enforcement, a massively important share of the responsibility falls to the users themselves to understand the nature of the problem and to become more organised and efficient also.  During seminars and conferences, the topic of ‘change management’ and understanding the cultural shift that will have to occur for DAM initiative to be effective is often brought up and everyone nods their heads and agrees about it.  But I don’t think enough end users have properly come to terms with how essential this understanding is yet.  Just like owning a load of books and shelving to store them doesn’t mean you have an operational lending library, so digital media, DAM and workflow solutions also provide the framework only – the rest is up to you.

Share this Article: