The Business Case for Asset Management

In the process of planning for a system that will manage media assets, it becomes extremely important to quantify, qualify and clarify what the MAM, DAM or DRM system is to accomplish. When quantifying how well a system is expected to perform, one must determine how the goals will attribute to its success. For the remainder of this discussion, focus will be placed on the nontechnical issues of selecting a MAM and DAM system-opening the eyes of potential purchasers and exploring what you should strive for, what to watch out for, and how to be successful in selecting systems. As a set of guidelines for specifying and selecting a MAM or DAM system, the prospective purchaser should consider the following steps.

Carefully define the scope of this digital integration project. Understand that to be successful, a DAM integration project must be of high value and well-bounded. Do not make the system too broad in scope so as to make it impractical to implement.

Establish a project leader that can effectively engage not only senior management (who sign the checks and provide the capital), but also the users. Both management and user must find true value or the system will be doomed to fail. Identifying the intended results is important or the plan may be considered wasteful.

Appreciate that a DAM system is not worth implementing unless the stakeholders understand the benefits to be achieved; senior management will want to see financial rewards and strategic value. Middle management will want to see operational improvements; satisfied users (or customers) and staff and other users will want greater productivity without serious additional effort.

Knowing that the front-end deployment of any new system is painfully time-consuming, the reward comes when the users let it be known "it was all well worth it." The end users, whether internal or external, will expect to see better service as a result of implementation. They get what they want, when they want it and without undue stress and strain on the balance of their needs or requirements.

Recognize that false expectations from promises that cannot be achieved will inhibit the end user's ideas and creativity. Evaluate and test the product before you buy it; thoroughly assess your requirements to determine what and how much you need. Avoid excessive customization; resist the temptation to add special features unless you are replacing a system from which you are unsatisfied (and you knew where the shortfalls were). Customization always costs more, and until you know precisely what you can achieve from the new system, holding off on customized feature sets pending full testing and implementation of the base systems may save costs in the long run. If the selection process has been thorough, application-specific customization may not be a requirement.


Strike an early internal balance between those who will use the system, and those who must maintain it. Get an unbiased view of the entire project; your IT department may lead the project, but they should not direct it. IT people should not force the creative users into a techno stronghold. Additionally, a business-led project may indeed ignore corporate IT needs, such as platform changes for performance, security issues, support and vendor qualifications. Engineering should support the needs of all the parties. Harmonize your internal project team into a working group that is respectful of each others' needs and you will be far more successful.

Define the system architecture for the departmental needs of the facility. Understand the scalability of the system and if it will meet both immediate needs and future extensions as well. For example, building a DAM system around only program-length material and ignoring other media objects, such as graphics or interstitials, will eventually paralyze the usefulness of the system. Not being able to index and link subcomponents to master project files will deter fluidity.

Whenever possible, avoid architectures that employ proprietary standards because they may be fraught with long-term problems, unless you are certain the hardware and software vendors will remain stable for the useful life of the DAM asset. Upgrades and improvements for the hardware and software are expected, and routine, but be sure there is a clear migration path to future developments, and that the vaporization of one contributor will not lead to complete system implosion.

Match the facility workflow to the metadata collection processes. Simply ingesting media into the system and ignoring the crucial entry of as many metadata elements as are practical will signal an "end of life" flag from the onset. Metadata is a fact of life, so select a product that is extensible and practical. Understand just how much effort is required for the complete and thorough ingest of all types of digital media. Whether metadata is automatically tagged through scene detection and voice recognition, or manually entered by operators; if the time required to ingest material is limited from a workflow perspective to simple tagging of the house number and EOM/SOM, then why bother with a DAM system in the first place?


Provide essential training and documentation for a successful rollout and long-term implementation. As with any software product, if the users fail to embrace it because they weren't trained or allowed sufficient "get up to speed" time-the products will turn into shelf-ware. Development and enforcement of internal policies, the creation of a users' forum for tips and practices, and keeping the lines of communication open between the user and middle managers will lead to success.

In conclusion, coming full circle once again, management should have already defined what "success" means before the selection process is finalized. If the goals are not set and displayed, if the users and staff do not understand what is supposed to be achieved, and if the criteria for operations cannot be met, it will be impossible to reach success. A DAM or MAM system is not just about technology, it is about workflow-successful and improved workflow.

Karl Paulsen

Karl Paulsen is the CTO for Diversified, the global leader in media-related technologies, innovations and systems integration. Karl provides subject matter expertise and innovative visionary futures related to advanced networking and IP-technologies, workflow design and assessment, media asset management, and storage technologies. Karl is a SMPTE Life Fellow, a SBE Life Member & Certified Professional Broadcast Engineer, and the author of hundreds of articles focused on industry advances in cloud, storage, workflow, and media technologies. For over 25-years he has continually featured topics in TV Tech magazine—penning the magazine’s Storage and Media Technologies and its Cloudspotter’s Journal columns.