Every so often we get inquiries from our RSuite enterprise clients or prospects about why there are services required to implement our RSuite software if the pre-configured environment is pretty much useful out-of-the-box? If one digs a little deeper and analyzes exactly what types of services are required, I think a publisher will be surprised that services related to customizing or extending the content management software are actually pretty small. Sure there will be custom forms for metadata capture or custom search forms, but these are generally a few days worth of work at the most. On the other hand, services related to content structure and workflow re-engineering have a huge impact on the services required for a content management product implementation independent of the software package chosen.
Content Engineering
Content engineering can be simply defined as understanding the structure of your content and putting a migration plan to make it adhere to some type of standard. In some cases very large publishers have crafted a proprietary content standard, but many adhere to industry standards such as NLM, D4P, DocBook, etc. The amount of services required to transform the content from one format to another can vary widely depending on the amount of file formats and complexity of content. While this effort can be categorized as part of the content management project, it is not part of the content management software.
Content structure and organization reflects how an organization has worked over time. If the publisher was disciplined and remained in compliance with industry standards, the amount of services to get the content into the content management system is minimal at best. Basically, if the publisher has well structured content that adheres to a DTD, then it should just work in RSuite or other systems. The challenge surfaces when multiple products adhere to different DTD's and then the publisher wants to consolidate under one standard. Again, a very good idea, but this is an issue beyond the content management software. Or the publisher has no DTD and wants to migrate all of their content to a standard. Again, an excellent idea, but the effort to complete this should not reflect on the content management software. As one of our engineers has said, "there is no magic button to transform the content, you either have the discipline to adhere to a standard or it will take some work to transform the content so that it does comply". There is no simple solution.
Workflow Analysis and Automation
Services related to workflow are generally consultative in nature whereby a business analyst sits with all parties to understand current "as-is" and "to-be" workflows. In some cases publishers have done a very nice job documenting their current as-is workflows but have a difficult time envisioning the to-be workflows. This is normal and can generally be addressed by creating some pilot workflows and showing the client how the software will help them. In some cases though a publisher which has been doing business one way for the past 20-years can have cultural challenges to change to the to-be workflows. This has been becoming less and less over the past 5-years as the need to embrace multi-channel publishing is critical to the sustainability of the publishing business. In other words, optimizing workflows, creating efficiencies, and actually automating multi-channel publishing are no longer options. It does mean in some cases that people within the publishing organization will have to be re-skilled or let go. That is unfortunately the nature of the game right now for publishers. Workflow equals efficiency which equals cost reductions which equals a reduction or reallocation of staff or an increase in production throughput.
A publisher that requires significant manual steps (e.g., a person needs to review and approve content) in their workflow will not realize the true benefits of implementing the workflow software. Manual steps are still required in the editorial process, but minimizing them is key. An automated step (e.g., content transformation) is the key to gaining the efficiencies that are sought by management. Depending on the complexity of the automated steps, the amount of services required can vary widely. The key is automating the highest value steps in the workflow and minimizing the manual steps. Again, the more a publisher understands how they need to change their process, the less services will be required to implement the content management software. The software will do whatever you configure it to do, but time spent understanding exactly what a publisher should be doing takes time and requires a visionary within your organization to think outside the box.
The Bottom Line
For both content engineering and workflow related services, the more a publisher is organized in these areas, the less services are required for a content management project independent of whether it is RSuite or not. The painfulness of addressing years of neglect in a structured or disciplined production of content can require significant services to unwind the structure, business rules, or lack of adherence to standards. Unfortunately this can be seen as a barrier to implementing a content management system.
While a new content management system could offer tremendous value in content reuse, version control, and production efficiency, the new software cannot magically address the messiness of the content or undocumented workflow. If your team has been organized and have very structured content with a well documented and agreed upon workflow (even if you are using legacy technology), then services to implement a CMS should be relatively small.
If you are embarking on a content management initiative, I would highly recommend that you have an honest assessment of your content structure and your workflow. If these pieces are in order, then you have just increased your odds of a successful content management system implementation and reduced the required services to implement the software.
I was recently reading 
