Reengineering for proper content management

Reengineering

The savings that can be achieved with an XML content management system will typically not be realized without reengineering. One or more of the following areas should be considered in a reengineering effort:

PROCESS — Automation based on content eliminates entry steps and associated proofreading. Database workflow tracking eliminates the need for most manual production control. Single sourcing the data avoids the conversion steps most publishers go through to deliver information online.



ORGANIZATION — Often organizations are set up to support legacy processes or systems and have many functions which are redundant or unnecessary. Streamlining the Organization not only reduces the time and money it takes to produce a product, it often reduces errors and improves content quality. When "by rote" tasks are eliminated your staff is able to focus on content rather than process which makes them more effective. Reducing the number of people that a process must pass through reduces bottlenecks. Shorter time to market (minutes rather than hours or days) can eliminate competition in highly competitive markets.



DATA — Many implementations of new systems do nothing more than replace one tagging method with another. While this does give access to parsers and other XML compliant tools, it is not enough. When converting data for a project all of the future uses of the data should be considered (e.g. repurposing for new products). In an Online world where only fragments of data may be delivered, the data has to be able to stand alone without the surrounding print context. Tagging content below the paragraph level (e.g. people, subjects, items, and references) provides rich searching or automation of finding aids.



TECHNOLOGY — Often a technology appears to work perfectly well for a task but holds you back. An example might be a desktop publishing application (DTP) that produces pages that look wonderful. What is not obvious is that DTP requires special expertise, which requires more people in the process, which causes more handoffs of the data, which causes more delays in the process. This type of workflow might mean that a web product has to wait for days while desktop re-composes an entire volume, when a simple change could have been delivered to the web as soon as it was written and approved.