By Dan Dube, Managing Director, US Operations, DocZone.com
Publishing organizations have long recognized the value of migrating content to XML to attain the benefits of content reuse, reduced localization costs, and single-source publishing. But, many of these organizations have never been able to justify the high cost and long implementation cycles required to install an in-house XML content management system (CMS). Recently, a new alternative has emerged – the Software as a Service (SaaS) model, which offers a hosted XML content management environment on a subscription basis. According to leading research firm InfoTrends, over 40% of their survey respondents would either “prefer” or “definitely consider” a hosted content management solution.
The Four Keys to a Successful CMS Implementation
In the twenty years that I have been involved in the world of publishing and content management, I have had the “opportunity” to experience many painful issues while trying to help clients move into a production environment. Typically, a content management implementation is an expensive venture, both in terms of actual costs (for software and services), as well as the amount of time and effort required by your staff to successfully migrate over to the new system. Another not-so-well-known fact is that the majority of CMS implementation projects fail.
If you are considering an investment in a content management system, you may want to consider these four keys to success:
1. Pick the right type of CMS to meet your business objectives
The term “content management” is easily one of the most confusing terms in the industry. There are many different types of systems out there that purport to do “content management,” but are designed for completely different purposes. Before you can select a CMS, you must first ask: “What business problem are we trying to solve?”
Do you want a system to enable the dynamic update of your corporate website? Are you looking to manage your corporate digital assets and marketing/brand information? Are you looking to streamline your editorial and localization process? Determine your business problem and then look for solutions that are designed to solve that problem. For example, a web CMS or Digital Asset Management system will not be well-suited to manage an editorial/localization workflow.
A corollary to this rule: if possible, don’t just implement a solution because it is the “corporate approved standard” for content management. You may end up spending more time and money trying to force-fit a system to go beyond the limits of what it was designed for.
2. Always look for a solution that conforms to international standards
The biggest danger with most traditional software applications is their reliance on a closed, proprietary architecture. If the software you are depending on becomes obsolete, you face a nightmare as you attempt to migrate your proprietary content format into a new system. (Just ask anybody who used Interleaf for electronic publishing in the early 1990s. Or, for that matter, anyone who just tries to stay current between releases of MS-Office!)
Whenever possible, a CMS solution should conform to international standards approved by well-regarded organizational bodies like OASIS and the W3C. This will reduce your reliance on specific tools, making your content the most important thing and pushing technology applications into the secondary supporting role that they should have. As a side benefit, this will also prevent “vendor lock-in”. If you decide to switch tools at a later date, migration will be much easier (as long as the new system also conforms to standards).
In the world of publishing and technical documentation/training/help, XML and DITA (Darwin Information Typing Architecture) have become the gold standard for creating and managing content. The benefits of having your content in XML are numerous, and include:
- Separation of content structure from the content format
- Ability to add semantic markup to increase content intelligence (e.g., better search results)
- Unicode compliance, which ensures support for all target languages
- Ability to reuse content at the “component” level
- Facilitation of true single-source publishing to multiple output formats
3. Keep customizations to a minimum
A typical CMS implementation involves the integration of several types of tools, including authoring, database, workflow, translation, and publishing applications. It is rare that all of these features can be found in one product; therefore, there is usually some level of custom integration and development required to fully meet a client’s requirements. To make matters even more complicated, virtually every company feels that their process is highly unique and that a complete CMS implementation must support every aspect of their environment. In my experience, this is a misguided outlook that can lead to problems and unnecessary costly mistakes:
- Integration and customization can be extremely expensive and take many months (or even years) to fully implement.
- Heavily customized environments are difficult to support. If you have an integrated environment with a mix of products, it is difficult to troubleshoot and resolve issues. (Vendors will often blame another application for unexpected behavior. When you have an environment with several products, it is difficult to assign responsibility and get issues resolved)
- An upgrade to one product may impact other products in the mix. Similarly, a change to one product’s API could affect some of the custom integration code that is necessary to make your environment work seamlessly.
- Due to the expense and complexity of the environment, there is a high probability that you will be required to maintain the integrated system well beyond its useful (and even usable) life expectancy.
4. Look for the quickest return on investment
In addition to the tips I’ve already shared, here are two other suggestions that will help you to achieve the most rapid return on your investment:
Start with a representative pilot project
Find a subset of your full content suite that suitably represents the challenges of your production cycle, and get that portion implemented quickly in a production-quality pilot environment. This will enable you to quickly demonstrate the benefits of the new system, work out any kinks in the process before you load all of your legacy data into the system, and get some real value out of the system early. Look for a way to get a production-quality system in place in 90 days or less.
Consider the Software as a Service subscription model as an alternative to software procurement
We’ll talk about this more in the next section, but a typical SaaS solution costs less money, provides all of the required functionality from one vendor, and reduces/eliminates risk (since you usually do not have to pay any license fees until the system is production-ready).
Software as a Service: What is it, and why should I care?
“The on-demand model isn’t about delivering software per se. It’s about delivering the results of successfully using the software.” (Phil Wainewright, zdNet)
The SaaS business model is essentially designed to offer a full-featured solution in a hosted environment. The software application sits in a centralized, secure data center and is served up to end users completely via a browser. Rather than buying and implementing an expensive in-house solution, the customer pays a subscription fee to use licenses on the system. The vendor has to perform to the specifications of a Service Level Agreement (SLA), or there are typically financial penalties to pay. SaaS is gaining acceptance as an alternative business model, led by the popularity of applications like WebEx and Salesforce.com.
Any organization can benefit from a SaaS business model, regardless of their size:
- Small to Midsize Business – For small to midsize businesses, SaaS allows access to software that might otherwise be too costly or complex to implement or support.
- Enterprise – For larger organizations, SaaS allows departments to avoid having to make large capital expenditures and having to pay for internal support costs. Large corporate environments typically turn to SaaS to support short-term projects, software that will only be used occasionally or by a small number of employees, and for applications that need to be available outside of a firewall to partners, contractors, suppliers, or customers.
How does a SaaS vendor differ from a traditional software vendor?
Traditional CMS vendors typically charge most or all of the purchase price at the time a contract is signed, before the system is even installed. Usually, the customer is responsible for the system deployment (often working with a consulting/integration firm). The vendor charges 18-20% annually for software support, and is not accountable for implementation failure, even if the system is never actually used in production! By contrast, a SaaS vendor is responsible for configuring the environment and delivering a “turn-key” application. License fees to a SaaS vendor do not start until the system is production-ready, and there are financial penalties for failure to meet the metrics in the Service Level Agreement.
Many “traditional” CMS vendors are considering (or announcing) that they will now support a hosted model as an alternative delivery mechanism. Most of these companies will struggle, because they will now be held more accountable for a successful production implementation and will have a difficult time adjusting to having to wait for payment. It will also be very hard for these companies to give up their ongoing profitable maintenance revenue. (For example, 45% of Oracle’s revenue comes from maintenance!)
Example of a SaaS CMS: DocZone.com
Our company, DocZone.com, provides the first commercially available XML content management platform available exclusively with the SaaS “on demand” business model. Our customer base spans many industries, from automotive to hardware/software manufacturers to health care solution providers to utilities. Some examples include:
- A European automotive company is using DocZone to facilitate the creation, localization, and automated publishing of glove box manuals in up to 30 languages, including bidirectional languages such as Arabic
- A global healthcare company is implementing DocZone to manage the editorial, localization, and single-source publishing of technical manuals, web-based training materials, and HTML help from the same set of source content
- A localization provider is using the DocZone platform to facilitate their translation and content optimization services to their end user clients, allowing them to pass on significant savings for translation and desktop publishing of multilingual content and making them a more competitive player in the localization industry.
Summary
Implementing or upgrading a content management environment is a significant and risky undertaking, and there are many options available for consideration. But if you properly define your business needs, stick with solutions that conform to standards, start with a small pilot project, and look for rapid ROI models (such as SaaS), your chances for success will increase dramatically. Choose wisely – the rewards are well worth it.
About the Author
Dan Dube is the Managing Director of US Operations for DocZone.com. Dan has 20 years of experience in business process re-engineering and implementation of standards-based content management systems, including three years as the Founder and President of Lighthouse Solutions, an XML systems integration company. He led the successful deployment of approximately fifty XML-based content management and publishing systems around the world in a variety of industries, including telecommunications, legal publishing, aviation, automotive, insurance and software documentation. He designed and managed the implementation of XML-based automated localization systems that are currently used in production at several Global 2000 companies.
