Expanding a Digital Content Management System

for the Growing Digital Media Enterprise

Magan Arthur, Magan H. Arthur

• Publisher: Routledge
• Year: 2013
• Print ISBN:
  9780240807942
• eBook ISBN:
  9781136034176
• Topic: Business
• Subtopic: Computer Science General
• Index: Business

Building large integrated content management systems is a daunting task and there is little guidance for the implementation process for the mid-level manager. There are thousands of home grown or old standalone systems in need of upgrading and expanding to keep up with the growing challenge of digital media. This book allows the non-technical executive to understand the key concepts and issues. It covers the technical process and business aspects of expanding a system.

1 Defining the Starting Point and Direction of the Expansion

This chapter explores the need to define the various options and reasons to expand a digital content management across the enterprise and it will provide recommendation for the implementation planning of such an expansion.

Digital content management systems have been around for about 20 years. Document (or records) management systems have helped companies streamline text-based, content-related workflows and processes, such as government approval for products in the pharmaceutical industry. Web content management, the next evolution of managing content, has established itself as an important part of solving the growing challenge of managing the flow of information in digital form. Over the last few years, entertainment and publishing companies as well as many marketing organizations have come to look to digital asset management technologies and processes to streamline the production, review, approval, and distribution of rich media assets such as photos and videos.

This book will provide recommendations and case studies and will touch on three areas: text-based documents and records, Web site management, and rich media management. Chapter 3 will define document management (DM), digital content management (DCM), also known as Digital Asset Management (DAM), and Web content management (CM or WCM) in more detail.

One underlying assumption is that the reader’s organization has experience with at least one existing digital content management project, potentially with a limited scope, that addresses a specific need such as an online library of stock photos/footage or learning objects, a marketing distribution portal, a collaborative work environment for the creation of content, or a system to manage the content published on the Web.

Phase Zero: Problem Definition

Defining the problem is the most important step toward solving it. Consider this anecdote about Albert Einstein, the ultimate authority on problem solving:

Einstein remarked that creativity is all about asking the right questions. When asked what he would do if given one hour to save the world, Einstein replied that he would spend 55 minutes to understand and formulate the problem, and 5 minutes to execute the solution. For complex business problems that require process changes and software development, it is vital that the right problems are identified in order to prevent costly design and implementation mistakes.¹

Defining the Current State

Before planning any extension of or addition to the system, one should allow for some examination of the system in use today. While some might know what the system can do, does everyone? The capabilities of the current system or process to manage content may not be apparent for stakeholders of other groups within the organization. It may be smart to involve one or more vendors or consultants in the expansion.

Even if the existing system will be replaced, important lessons can be learned from it. There are reasons why it is being replaced. It is highly recommended to capture those reasons as precisely as possible. One should note things such as:

• Business case overview including any return on investment (ROI) if available. What was the original business case? How has the system changed since then? How has the business changed?

• A description of the asset types managed in the system and the life cycle of the assets in the system. Different asset types might have different life cycles.

• A description of all user roles and use cases, including any administrators.

• The number of users per role.

• The number of assets by asset type in the system.

• The frequency and quantity of new assets added to the system.

• Use of the system specific to geography, including time zones and languages.

Prior Lessons

The lessons learned by the organization during the implementation of the original system can be very valuable. This is true even if its initial implementation was a painful experience. However, too often, these lessons are not captured anywhere. Maybe nobody took notes or the primary planner for current expansion was not involved with the original implementation. In that case, contact members of the original implementation team and tap into their memories. Even if some team members are no longer working for the organization, they may be willing to share their experiences. Capturing the lessons learned from prior projects will save money, time, and nerves. Table 1.1 lists some questions to ask.

WHAT WORKED?	WHAT DID NOT WORK?
What did the implementation team do right in terms of planning, communication, and implementation?	What were the challenges in terms of planning, communication, and implementation?
What helped in setting correct expectations with stakeholders and users?	Were the initial expectations unrealistic? If so, how?
Did the vendor(s) provide any specific helpful support in terms of planning, communication, and implementation?	Did management misunderstand the objectives? If so, how?
What positive things did the users have to say about the process?	What were the vendor’s challenges in terms of planning, communication, and implementation?
	What negative things do the users note about the current system?

TABLE 1.1 Evaluating Past Implementations

Capturing User Feedback

Getting detailed feedback about the existing system and about its implementation process is the first important step for scaling a system. Create a survey for the users to rate the current system. After this exercise, one should have vetted documents describing the system in comprehensive terms and describing the process of how the system was implemented. Not only will these documents help in the planning process, but they also represent a key element of the business case. Providing information about the current state and the lessons learned will build a solid foundation for recommendations with respect to future investments. Chapter 6, dedicated to building the business case, covers this in more detail.

Here is an inspiring article. “CMS Acceptance Testing” by Lisa Welchman provides good ideas for user testing but also user feedback in general. Welchman states “…it’s important for users to understand before any code gets written exactly how they are going to work in the system and how it will impact their job.”

The article can be found at www.cmswatch.com.

The result of proper planning should be a well-documented analysis of the current formal and informal processes and practices regarding creating, reviewing, approving, distributing, storing, reusing, and ultimately destroying content. From that analysis improved processes can be identified, and most likely technology can be used to improve efficiencies and control. With this background, the planning process can now move forward. The next step will be to define what kind of enhancements and expansions to the digital content management system are required.

Case Study

Zweites Deutsches Fernsehen (ZDF)

The following case study highlights the potential for cost savings and enhanced services. It discusses carefully examining current processes and technologies before changing or replacing them.

Background

ZDF, one of Europe’s largest public broadcasters, had a legacy system called Fernseh Data Base (FDB) that was supporting thousands of concurrent users on a terminal server based system. The FDB system was not capable of supporting integration with production and newsroom systems, nor was it able to provide video browsing functionality.

Solution

ZDF approached Blue Order, a German digital content management company, to provide a new solution that would leave FDB in place for many of the users, but would provide additional functionality for up to 800 “super-users” with integration across production and newsroom platforms.

Result

It was not necessary to incur the expense of totally replacing a solution that still met the needs of the majority of users. ZDF also benefited from the streamlined workflows that could be achieved with the integration available with Blue Order’s solution.

This case study was first published at the Henry Stewart Digital Asset Management Symposium in New York, on May 10, 2005, by Jeremy Bancroft, former sales and marketing director, EMEA, Blue Order Ltd. It is published here with the permission of Blue Order

Contact: Christina Seemann, Manager Marketing Services, Blue Order AG.

Defining the Expansion

As with all complex systems, it is important to ensure that the meaning of “expansion” is clear. It can mean different things to different people. There are many possible reasons for expanding a system–too many to list. This section defines three ways a system can grow and should help clarify and communicate goals for the expansion. A company might need to expand in more than one way. If at all possible, plan the expansion in phases and implement one at a time.

Scale in Size

In the traditional sense of scaling an application, a significant number of new users and/or content are added to the system. If all new users are able to use the system in the same language (no multi-lingual interfaces) and if all new content can be categorized by the existing taxonomy, this is most likely only a hardware issue. These issues are addressed in Chapter 8, which deals with scaling the hardware and software. However, it may be necessary to consider the added work for the administrator in supporting and managing user accounts. Quite often, a company will need to rethink the system taxonomy or data structure if multiplying the number of assets by a factor of 10 or more. Chapters 10 and 11 are focused on expanding the taxonomy and data structure.

FIGURE 1.1 The Content Life Cycle

Expand Vertically

A vertical expansion adds an additional aspect of the life cycle of the existing assets within the system. The life cycle of an asset can usually be defined in the same manner, as shown in Figure 1.1. This applies regardless of whether the company is a media company whose digital assets represent its core business, or whether the organization is using a digital content management system to manage marketing materials or a specific element of a value chain such as product labels.

Most likely, there will be additional formal and informal approval processes between the steps of the life cycle, often driven by complex dependencies and rules. The existing system likely addresses or at least supports some of these processes in the organization for certain assets today.

For example, an organization might currently manage the distribution of marketing material to the distribution channel or to the direct sales force, or both. One example of a vertical expansion would be the inclusion of the creation process by ingesting material prior to final approval, using the system for an online approval process. The process would ensure brand compliance, legal compliance, and such. Approved assets might then automatically move into the existing structure for management and distribution.

Expand Horizontally

The author defines a horizontal expansion as adding entirely new areas of business to the system. For example, a company might distribute marketing material to a certain channel, but now it wants to manage internal email archiving for compliance reasons. Or the company is a publishing house and, while one division has made good use of the system, managers wish to introduce it to a new division that has a different asset life cycle (workflow). For example, a printing division likely has a different workflow for assets than does a TV division.

Recommendations for the Implementation Planning

As the earlier case studies, the business case and technical requirements of digital content management system implementations are not the same, even in the same industry sector. However, there are a few universal truths about implementing large scale, potentially disruptive, technologies that should be highlighted. Additionally there are a few specifically digital content-related issues that might be well worth the attention when building an implementation plan.

Phased Approach

There have been many articles and a few books written about the advantages of breaking complex projects into smaller logical steps. However, it cannot be stressed enough that the most-violated rule of sound project management is aiming for the “Big Bang.” This approach tries to address various possible business problems at once and aims to present the solution for all of them together.

This book and this article provide more in-depth information about phased project management:...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Dedication
• Acknowledgements
• Author Biography
• Table of Contents
• Introduction
• 1 Defining the Starting Point and Direction of the Expansion
• 2 Preparing the Organization for Expansion
• 3 Definition of Technologies and Products
• 4 System Definition Recommendations and Advanced Concepts
• 5 Digital Rights Management, Authentication, and Compliance
• 6 Building the Business Case for a System Expansion
• 7 ROI Models
• 8 Expanding the System Hardware and Software
• 9 Integration
• 10 Advanced Taxonomy (Classification System)
• 11 Metadata
• Appendix
• Index