Creating the Right XML Workflow
Technology is changing publishing faster than ever before. Today we need to publish more information faster, and deliver it in many ways: print, PDF, HTML, XML.
Paper-based workflows can't do it. But radically overhauling a paper-based system to digital workflow can traumatize an organization and its publications.
To be successful, publishers must re-evaluate their workflow, and consider the organization's business goals. Without clear business goals driving technological advancements, projects can and do veer off course, and fail to produce anticipated benefits.
Consider this example: A publisher develops a new digital workflow around XML, and includes a DTD with many elements (DTD stands for "document type definition," a description of a document's structure). The production team is required to apply a large number of tags to every piece of content. Worse, they have to do this by hand, using simple text editors.
The tedious nature of tagging documents inevitably tires the production team. They save the XML documents in a repository. But they don't use (or even have) any quality assurance tools to verify the tags were applied correctly. The inevitable outcome: Wasted time and money. The XML documents didn't meet the project manager's expectations.
It's obvious what the production team did wrong. They cut corners, ruined the project launch, and scuttled any hope for a quick ROI. But don't blame the team. Blame their managers. They failed to consider the business requirements beyond the basic need to adopt a digital workflow. Here's why:
• First, the project managers didn't determine the "cost per tag." Think about it: Every XML tag has a cost per application. It might be a fraction of a cent, but the per-tag cost adds up. For every element added to a DTD, project managers must ask, "What is the business case for this element?" Tagging data "because it is there" adds cost, and increases the production workload. This is why many publishers have fewer tags in later versions of their DTD than the first. They ultimately recognize that a lot of tagged information is never used.
• The project managers didn't consider who would apply the tags. That meant they leveraged current staff, without investing in the proper training. When production time isn't critical, consider outsourcing the creation of XML. If production time is critical, or if XML creation must be kept in house, get the software tools that streamline content tagging. And train the staff to use them.
• The project managers didn't pay enough attention to quality assurance. Unlike hard- or soft-proofs that are easily read, XML tagging errors are easily missed. Quality assurance processes enforced by automated tools are essential to the success of any XML project.
• The project managers didn't account for the "people" aspect. Success of an XML project depends on the people who do the production. They must understand the business reasons for the workflow changes. They are more likely to "buy in" to the project effort when they understand why the changes are needed.
XML-based publishing workflows save money and open new markets to publishers. But XML is not a magic bullet. It only succeeds when the implementation is designed to match the publisher's business requirements, and skill level of the production team.
Bruce Rosenblum (Bruce@Inera.com) is CEO of Inera Inc., in Newton, Mass.