Robin Dube, Agfa Healthcare
Selecting and implementing a CMS is not usually something you get to do over. But, lately I’ve been asking myself, “If I could start again, what would I do differently?” And the answer to that question is “Support”.
A CMS implementation, which in our case meant a conversion to DITA, is not just about the purchase price, the features, the conversion project, and the training. Its success relies strongly on your vendor’s support model and your internal support processes. Whether you’re going with open source or a commercial product, when your intellectual property and key deadlines are riding on a CMS, support is critical. Throw in the complexities of a global company writing in multiple time zones, in multiple languages, and producing multiple outputs, and support becomes a key success factor.
So, if I had to start again, I’d put much more emphasis on the following support issues.
Does the vendor provide 24/7 support? If they do, does it really mean 24/7 support or is it limited? Are they located in a specific time zone? What’s their first language? In a global company like ours, language and time zone are a big deal. How many people are supporting you—and if they go on vacation, what happens? What kind of support forums, documentation, and communities are available?
If the vendor does upgrades, who does the system testing for these upgrades, and how much information do they provide about bug fixes and new features? Are you expected to do acceptance testing and what kind of time commitment is required?
Is support limited to specific areas of the CMS? Or does it cover all authoring, publishing, and translation activities? What’s considered issue support and what’s considered professional services, which normally incur additional fees? What exactlyis included in the yearly maintenance fee?
Know the answers to these questions before you select a vendor. When you do select one, ensure that all of these issues are detailed in your contract and have the contract reviewed carefully.
Internal system support
Who keeps the servers running? Who does the installs when an upgrade is available? In our case, this means weekends and night upgrades to accommodate a global schedule. Who runs ongoing stats on memory usage and license usage, and provides alerts if a problem is imminent? Who keeps your physical infrastructure going? Does your internal IT team own this? And if they do, start asking the same kinds of questions you just asked the vendor about their support. As well, who manages bug reports from users, and how?
Who figures out how to make your authors more efficient? Authors are used to tools like FrameMaker or RoboHelp, which are specifically designed to support the normal activities of authoring, including basic things like spellchecking an entire publication and indexing. The authoring tools used with DITA (in our case) and integrated into the CMS, don’t offer the same features—yet—despite the benefits they add to publishing. (And yes, I think many of the true benefits are on the publishing side because, frankly, the authoring tools are not sophisticated enough yet.)
So, a person or a sub-team must be focused on finding tools or ways of working that make authoring more efficient. The skills to do this could be varied. It may involve anything from Java programming to XML know-how to usability expertise. Authors want to focus on what provides the most value, not on navigating the intricacies of a CMS system. Someone who can smooth over the rough edges of CMS authoring workflows can be invaluable.
Who is figuring out the intricacies of publishing? Documentation groups are used to changing stylesheets relatively easily. When everyone agrees to increase the margins on the standard PDF output, it’s not a big deal to update the FrameMaker template. In a CMS, especially when you have implemented DITA and are using XSL transforms through a publishing pipeline, this is not an easy task. Someone needs to know XSL, XSLT, publishing engines, and more. And, online help can be even more interesting. When you are used to a webhelp system with TOC, search, and index, the output from some publishing pipelines is fairly rudimentary. To solve the help problem, we went with ePublisher, which integrates with the CMS—the tool provides a WYSIWYG interface for editing XSL transforms and produces a robust webhelp system out of the box. But, you still need to know DITA and, in our case, some XSL and ANT scripting, to integrate it with your system.
In a global company, who is guiding translation workflows? Translation is one of the most difficult areas of CMS implementation. Translations cost thousands of dollars, and small changes to your workflow can have major impacts to the total translation budget and turnaround times.
The variables that affect translation workflows are many:
- Supported languages—we’ve had issues with Russian publications because the standard fonts didn’t work. And Chinese-Japanese-Korean equals challenges with fonts and stylesheets. Also, how do you handle indexes and glossaries—is reordering manual or automatic?
- Translation memory—does your CMS maintain this internally or is it maintained by your translation vendor? For some companies, this decision is a big deal, for others it’s just a matter of what provides the best cost. If the vendor maintains the memory, the tools they use are standard and the exact/fuzzy match costs are known. If the CMS maintains the memory, they may have different rules.
- Translation vendor—If you use an external translation vendor, get them involved. (If you use an internal one, this goes without saying.) How does the CMS deliver content to the vendor? If your translation workflow includes making the vendor work within the CMS, find out whether the vendor is willing to do this, and if they charge a premium. If possible, get the vendor to test the translation workflow too. Vendors are used to working in their own tools. If they have to use yours, you’re going to pay. And, if they have to use a tool that doesn’t meet their needs, you’re going to pay more. The benefits of having your translation memory in house may make this worth it to your company, but ensuring a good fit from the beginning can avoid these costs.
Implementing a CMS isn’t just about implementing a new tool. It’s about implementing a new way of life for your company. Corny, but true. And, as with any program, someone needs to manage it with the direct input of your support team and authoring team in a collaborative environment. Think of this as a governing body for the CMS involving all the aspects of support mentioned above.
When you implement a CMS, its influence will bleed into every aspect of documentation. A CMS implementation isn’t about buying a tool, but about changing your entire way of working. You need a support model in place at the beginning to ensure the best possible results for your business.
Robin has worked as a technical communicator in the software industry since 1996. Now, her focus is Knowledge Management, which includes CMS Solutions at Agfa. The CMS program is one part of Knowledge Management’s goal of getting the right information to the right people at the right time.