Digital Asset Management: Lessons from the Field #2 – Current State Analysis
Let’s assume for purposes of this lesson that you have developed your core business use case for implementing a digital asset management platform. That’s great, and not to be taken for granted as an essential early step. In doing so, you have also analyzed essential stakeholder needs and have determined the core business drivers. They may include achieving faster time to market, standardization of processes, or overall reduction in operating expenses, amongst other worthy goals. Perhaps you only have one, like having a single source of truth for all your digital assets. That alone can be sufficient, but generally there is more than a single objective for moving forward. But, you have that, and it is documented. So, now you can move on to vendor selection, right? Not so fast.
In order to know where you are going, you still need to know where you are. The starting point of any journey is still the point of origin, so never underestimate the value of and need to be thorough with analysis of the current state of your organization. What does this entail? Understanding, and documenting, the key attributes and issues related to any systems and tools, functions, and processes that are affected by the organization’s use of digital assets. Current state analysis usually means conducting work in these three core areas:
·Asset Structure Mapping
Determining what all the types of assets the organization uses now, or anticipates using in the near future. This includes their practical uses like for the web, packaging, or for social marketing, as well as their literal file formats like .jpg, .pdf or .mp4.
Mapping the precise repositories in which the different types of assets reside, and any issues related to those repositories, such as the tools they may be using, including which repositories might be desirable to keep intact, consolidate, or eliminate (the same goes for the tools themselves, like not wanting to renew a license, for example).
Identifying the methods for asset tagging and metadata entry that exist now, and assessing how well they work. How easily or difficultly assets are searched is related to tagging and metadata and should also be documented.
Tools and Technologies
Documenting all of the off-she-shelf software that is used anywhere in the digital asset lifecycle now, for every step from asset creation through ingestion, annotation, storage, retrieval, internal and external uses and distribution (automated or manual), curation, archiving, and measurement.
Identifying every custom app or widget or piece of custom code used anywhere in the asset lifecycle.
Understanding all user interfaces that may exist on top of various repositories to make the assets therein more accessible or usable, including what is good about them as well as what is less than desired.
Diagramming all existing system integrations between current asset repositories and other systems, such as product information management tools (PIM), Web CMS, CRM, SSO, or any of the newer three letter acronyms such as CDP, DMP, or MDM (Customer Data Platform, Data Marketing Platform, or Marketing Data Management). You may also have social listening or other tools that feed data back into one or more repositories (although, quite frankly, if you do, you may already have a good DAM platform). This is the literal roadmap for how things work together (or separate) now, such that your organization can alter course with a revised map in the next step.
Process Mapping
Understanding how all core user groups work now to create, use and distribute digital assets, and what processes they follow, formal and standardized or informal and undocumented (of course, with this step they will become somewhat documented, although likely not in great detail). This includes external user groups as well, such as agencies, independent contractors and other partners.
While this is actually part of the next step in a DAM initiative, it’s also a good idea to identify what the organizational ‘mandatories’ are in terms of what should be kept, consolidated, or discarded. This applies to types of assets, repositories, tools and technologies, and processes. Ask your key user group representatives what is important to them, and note where there is consensus or lack thereof.
Last but not least for current state analysis is confirming all of the above with your core stakeholders, and making sure you have consensus. Hopefully, a somewhat impartial strategist or project manager will lead this process so they can ask the hard questions needed. If there are key points of disagreement, resolve them before you move on, or they will have to be dealt with in the next step, future state modeling.
I’ll mention it one more time, too – have of your organization’s current state documented, in words and diagrams and imagery that can be clearly understood by those with budget authority, so the recommendations for improvement that follow can be more easily understood, placed in context, and acted upon. Those stakeholders own the landscape, so to speak, on which your journey is proceeding.