Workflow Doesn't
Apr 13, 2015 | , ,

One of the most frustrating ongoing digital asset management discussions is the topic of workflow. For over a decade this word has been thrown around nearly as much as metadata, and its relevance taken as gospel, without a substantive conversation. In this article I plan to address several key themes:

  1. Workflow as a concept is largely irrelevant when applied to creative production and administration
  2. Workflow systems are functionally inadequate to address the use cases they are usually deployed for
  3. Workflow systems are costly to maintain and extend, and cannot keep up with the pace of process evolution
  4. Workflow is largely a means for vendors to extract expensive, per-client customization fees and avoid product-global functional improvements
  5. Workflow implementations come at a cost to clients, and those costs would better be spent elsewhere

Ok, fighting words, I know, so let’s dig in. But, briefly, let me list some assumptions and caveats so we don’t get sucked into nitpicking:

  1. Not all DAMs are implemented in a creative environment – true, but by its very nature DAM almost always touches product that comes out of creative environments.
  2. I’m sticking with Wikipedia’s excellent and concise definition of workflow, so if you don’t agree with this definition then the article may not be relevant:

A workflow consists of an orchestrated and repeatable pattern of business activity enabled by the systematic organization of resources into processes that transform materials, provide services, or process information.

  1. I’m able to distinguish between processes and workflow… do you? Workflow encompasses multiple processes and the decision making glue that binds it all together into a flow.

Workflow as a concept is largely irrelevant when applied to creative production and administration

The most process-oriented DAM environment I ever worked in (let’s call it JOBX) – and I’ve done more than my share of DAM tours – was a high volume photography operation. We produced hundreds of thousands of licensable, finished images, videos, and audio clips a year, with absolutely rigid quality control… images we produced in 2010 had to match similar images from 2004; images produced on one stage today had to match perfectly images taken of a similar product on a different stage, by different teams, yesterday. Color, tone, shadows, dust removal, mask refinement, reflections, and more: we had many dozens of quality points we measured per asset, across hundreds of images, audio, video and interactives per product. File naming was crucial. Realtime tracking was essential. 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.

This experience bookended much of my DAM work – I spent several years there helping bootstrap production, and then left for years of corporate DAM work, and eventually came back to JOBX for a few more years, thinking my intervening enterprise experiences may have taught me something. What was clear soon after returning was that in all the years I had been gone I had yet to see a more sophisticated, better run digital asset management environment, and yet, for all intents and purposes, we had nothing resembling a DAM. We had lots of homegrown tools, and certainly some components overlapped with things a DAM product could do. But we had no DAM product anywhere, and we were missing so many aspects of what would have been recognizably a DAM… we certainly had nothing resembling the workflow engines I’d seen sold to clients over the years, or the broken metadata models so many products try to put lipstick on. We had no shortage of DAM vendors approach us every year, and the challenge I presented to the sales folk was always really straightforward: all I want is a clear analysis that shows me how you will improve at least one of our KPIs without hurting the others. I can’t remember anyone ever even following up after that, though I’m sure there were some attempts. This experience gave me a lot of pause, until I figured out what was at root.

  • 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
  • Effective automation doesn’t require encoding and supplanting human decision making, it means simplifying human intervention where machines do things better. Applying a complex series of transformations to a million images at a time is where automation shines; deciding how to handle production exceptions, or how to interpret a complex sales order, isn’t.
  • Production automation a force-multiplier more as a human-replacer – I wanted to make my people stronger so that their time is spent as much as possible on thinking and not on wrote doing.
  • Exceptions are the rule in production – and exceptions tend to stress decision making intelligence. Automation can fill in the gaps, and can make handling exceptions easier… “oops, you wanted 640px center-cropped square images in sRGB? No problem, I’ve resubmitted the job with the updated spec”, but it doesn’t handle the decision making well – “The rules say our work is first-in-first-out, but we screwed up the order so we’re going to let this job jump the line”.

This reflection lead me to the conviction that DAM workflow has it all wrong. All. Wrong.

Instead of workflow engines, here’s what I want from my DAMs:

  • Give me a highly efficient UX that doesn’t make my life more complicated than necessary.
  • Give me a highly composable UI that allows me to configure my working environment the way that most fits my unique role, personal quirks and an operational environment that includes other tools outside of the DAM. One-size-fits-all UIs are almost always designed for lowest-common-denominator.
  • Give me the ability to create macro-like time saving shortcuts without professional services involvement. I do it in Photoshop, I do it in Excel, I know my business and processes better than they do. And I need it today. My project can’t wait.
  • Give me a DAM that plays well with others. Every time I read an article on DAM integration I want to scream… integration does not start with the backend. Valuable integration begins with the user experience, with the frontend- if I can’t easily connect the tools I depend on with your DAM, it’s broken. If I can’t drag a file into Photoshop; if I can’t get data out to a spreadsheet without IT involvement; if it takes me 10 extra steps to check an asset in from my last render; if your copy-paste support is half-baked; if you don’t play by the basic platform rules that tie desktop applications together, you’re a functional silo.
  • Give me the respect to think of my role as conductor of assets because it’s my ability to direct and think and decide that is valuable, and design your tools accordingly.

Workflow systems are functionally inadequate to address the use cases they are usually deployed for

I’m going to spend less time on this one, because the very title almost implies they can be improved. I don’t believe they can as I believe – as outlined in the previous section – the entire concept is broken.

That said, what I find most troubling of the majority of DAM workflow engines I’ve encountered is that they typically don’t expose the breadth of functionality of the DAM itself – with some exceptions. To me, this is analogous to providing an incomplete API and barely worth the effort to complain about further, but it shows a lack of vision and an incompleteness of product to leave one or more of your primary interfaces broken.

Workflow systems are costly to maintain and extend, and cannot keep up with the pace of process evolution

I touched on this quite a bit in the first section, but I’ll reiterate:

  1. Your business processes should represent your competitive advantages. We all have access to the same tools – what’s special is how you use them.
  2. The moment your complex, 10 page Visio workflow diagram is completed – let alone implemented – it’s probably obsolete.
  3. Actually, the workflow diagram most likely never represented a real, complete process to begin with. It was oversimplified, exceptions were ignored, and untested assumptions were baked in.
  4. To the extent that you choose to implement business processes within your DAM, you are necessarily ceding control of the processes to whomever is skilled, affordable, and available enough to maintain the implementation.
  5. The moment workflow automation in your DAM cannot keep up with changing business requirements, your users will (rightly) revolt and begin to workaround.
  6. Your users aren’t stupid. I’ve seen non-technical, creative staff implement complex automation on their own, outside of a DAM, in order to get their jobs done better, faster, and with no support. You can either embrace this and treat these people like heroes, or fight it and force them into substandard, out of date tools. Your call.

Workflow is largely a means for vendors to extract expensive, per-client customization fees and avoid product-global functional improvements

Let’s be honest. Most DAM vendors sell services, and their service margins are substantially higher than what they earn selling software. Put simpler, in a typical DAM implementation, most of the profit comes from services, not licensing.

For many vendors this leads to a tempting perverse incentive: many obvious improvements to the product would reduce the value of the services they can get out of each customer.

  • Did the basic installation cost you money? I don’t mean customizations – I just mean putting the product on a server to the point where you can begin to configure it? That’s because it’s easy to charge $250/hr or more for jr. technical staff who earn $60k/yr to spend a day or two installing.
  • Ever asked for a seemingly basic feature, only to be hit with a $10-100K estimate, and then complain about it with five other customers who all want the same functionality?
  • Wonder why, after funding a broadly useful customization, it’s not rolled back into the product for other customers to use?

Workflow automation, likewise, enjoys high margins on the vendor side, and an even higher level of lock-in than in other aspects of a DAM project. Once you’ve made your business processes dependent on a product you’re not capable of maintaining yourself, you’re stuck. When faced with changing requirements, you now have to weigh external costs that will be involved in updating your workflow. Think it’ll be pain to migrate your assets and metadata out of your existing DAM? Try migrating your custom workflows.

Instead of focusing on radical improvements to the DAM user experience – rolling out functionality to fit the latest trends and habits – your DAM vendor is happy to keep you on a continual cycle of professional service contracts to help you always stay two steps behind the competition.

Workflow implementations come at a cost to clients, and those costs would better be spent elsewhere

This is the bottom line – every dollar spent on vendor-dependent, client-specific workflow automation would be better applied to building improved tools that empower the end users of the system. Every client dollar spent on customizations is a dollar spent forking the environment away from their peers – making their DAM harder to maintain, harder to upgrade, and less productive, while removing control from the people closest to action – the users.