Para mantener la competitividad en la era de internet, los flujos de trabajo de publicación tienen que llegar a ser mucho más eficientes de lo que son en la actualidad. De hecho, en algunas áreas, esta tendencia ya se está imponiendo. Por ejemplo, muchas plantas de impresión han logrado automatizar de forma eficaz sus procesos de funcionamiento, a menudo logrando niveles de productividad mucho mayores de lo que nadie habría creído posible hace cinco años.

Sin embargo, todavía queda mucho por hacer. El camino desde la idea creativa hasta la hoja lista para imprimir o para publicar en internet sigue siendo largo y lleno de trabajos manuales. Los distintos participantes en el flujo de trabajo procesan nuevos trabajos sin que se especifique demasiada información; los datos administrativos se introducen y se vuelven a introducir, una y otra vez; los archivos entrantes se clasifican a mano, de forma parecida a lo que ocurre con el correo. Y aunque en el pasado pudiésemos vivir con todas estas ineficiencias, ahora han pasado a ser inaceptables.

Impulsados por la impresión digital y otras innovaciones, los tiempos de preparación se han acortado considerablemente, y las tiradas de impresión son cada vez más cortas. A una capacidad de impresión constante, el proceso creativo debe proporcionar una cantidad cada vez mayor de maquetaciones diferentes. En consecuencia, el antiguo equilibrio se rompe y el proceso creativo amenaza con convertirse en el principal cuello de botella.

¿Cómo podemos aumentar la productividad de los flujos de trabajo creativos premedia? La respuesta lógica es la automatización de las tareas rutinarias. Sin embargo, en la mayoría de entornos de publicación un solo trabajo pasa por muchas manos y en él intervienen muchas empresas o departamentos distintos. Lograr un flujo de trabajo automatizado exige un consenso previo sobre las convenciones más adecuadas para el intercambio de información entre las partes implicadas.

 

La paradoja de la automatización

Aquí es donde radica una paradoja fundamental. Para comprender el motivo, examinemos un ecosistema de publicación típico (véase ilustraciones). Utilizaremos el término isla para definir cada uno de los elementos constitutivos de dicho ecosistema, incluidos los autores, redactores, agencias creativas, diseñadores freelance, editores, propietarios de marcas e impresores. Los propietarios de marcas son especiales porque son quienes, en última instancia, ponen el dinero (en algunos casos el editor es el propietario de la marca, por ejemplo una editorial suele ser la propietaria de sus obras).

Naturalmente, las islas más grandes del ecosistema ya han implementado su propia automatización. Así, por ejemplo, los impresores utilizan sistemas de flujo de trabajo y los editores utilizan sistemas de gestión de recursos o de colaboración editorial. La mayoría de estos sistemas se pueden calificar de monolíticos y céntricos; es decir, provienen de una misma fuente, incluyen las funciones necesarias para satisfacer las necesidades concretas de automatización de una isla determinada, y ofrecen una visión del mundo centrada en dichas necesidades. En otras palabras, estos sistemas están centrados en la automatización de una sola isla. Las interfaces web (que permita a los usuarios de otras islas interactuar con el sistema) parecen confirmar la naturaleza céntrica y monolítica de estos sistemas, en lugar de descartarla.

La automatización intraislas es fantástica, porque permite lograr un gran aumento de la productividad de cada isla. Sin embargo, lo que buscamos es que las islas intercambien información entre sí, a fin de poder optimizar el flujo de trabajo interislas.

 

Relaciones entre islas

Para ello es preciso reflexionar sobre las distintas relaciones entre las islas que forman el ecosistema. Un propietario de marca contrata a su agencia de diseño para crear una campaña y adquiere un espacio publicitario a distintas editoriales de revistas. A su vez, la agencia colabora con un redactor freelance y envía los anuncios finales a los editores. Cada editor trabaja con una o varias imprentas para producir físicamente la revista. Y de hecho, es posible que el propietario de la marca esté solicitando material de marketing directamente a los mismos impresores. Cada una de estas interacciones implica sus propias necesidades específicas (aunque a menudo relacionadas) de intercambio de información.

Además, la red de relaciones es muy diferente en función de la isla que se utilice como punto de mira. La Agencia A interactúa con el Editor X y el Editor Y, mientras que el Editor X interactúa con la Agencia A y la Agencia B. Por lo tanto, a menos que todo el mundo utilice las mismas convenciones, las agencias o los editores se verán obligados a trabajar con múltiples convenciones para el intercambio de datos. (En el caso de interfaces de usuario web, la situación es aún peor: algunos participantes se verán obligados a utilizar muchas interfaces web a menos que todos utilicen el mismo flujo de trabajo, algo inconcebible.) Si lo trasladamos a todas las islas del ecosistema, la red de relaciones adquiere una gran complejidad.

Esto nos lleva a la paradoja de la automatización. La automatización integral de los procesos premedia exige una serie de convenciones inequívocas para el intercambio de información y la interacción entre los participantes. Sin embargo, este objetivo parece inalcanzable a la vista de la complejidad de la red de relaciones, porque dichas relaciones difieren enormemente para cada punto de vista, y porque cada isla de automatización ha implementado su propio sistema.

Quizás el lector piense que no pasa nada, y que lo único que hay que hacer es acordar una norma universal para todos los intercambios de información del ecosistema. ¿Seguro? Personalmente, a mí me parece una idea terrible. Analicémoslo en detalle.

 

La guerra de los metadatos

Como ya hemos dicho, para lograr automatizar un flujo de trabajo es necesario que se dé un intercambio de datos estructurado entre todas las partes implicadas. En este sentido, la industria ha llegado a un cierto consenso sobre los mecanismos para la transferencia de contenido. Entre PDF para los documentos orientados a páginas y XML para el contenido centrado en la web, parece que este tema ha quedado zanjado -por lo menos, de momento.

Y lo que es más, también se necesitan mecanismos para transportar información descriptiva sobre un determinado trabajo, además del contenido propiamente dicho. Este tipo de información descriptiva suele denominarse metadatos. Éstos se utilizan para informar a los procesos automatizados sobre determinadas características del trabajo y sobre su entorno pasado y futuro. A fin de que los metadatos sean útiles en un contexto de automatización, deben proporcionarse en forma electrónica, en un formato estructurado y con un alto nivel de calidad (a la hora de tomar decisiones automatizadas basadas en campos de metadatos, no hay mejor información que la información incorrecta).

Esta concienciación ha dado lugar a una multiplicidad de normas de metadatos, entre las que cabe destacar XMP (www.adobe.com/products/xmp), EXIF (www.exif.org) y numerosas normas de metadatos basadas en XML como NewsML, AdsML, PRISM, ebXML y JDF.

 

JDF

JDF (www.job-definition-format.org) está muy en boga y está calando hondo en la producción impresa, ya que permite la interacción automática entre sistemas que pueden ser de distintos fabricantes. JDF se utiliza principalmente en las fases de preimpresión (por ej., para gestionar la imposición y el trapping) y en las tareas de la sala de impresión y de acabado.

Curiosamente, JDF se ha planteado como la norma integral para etiquetas de especificaciones de trabajos que debería solucionar todos nuestros problemas. La idea es ofrecer una descripción detallada del trabajo (y de sus procesos creativos y de producción, hasta llegar a la entrega final) incluso antes de que se inicie dicho trabajo. En consecuencia, el contenido creativo del trabajo se puede contrastar con las especificaciones en todos los pasos de la cadena, partiendo de la página en blanco.

Es un concepto con muchas posibilidades, y en entornos bien estructurados puede llegar a convertirse en el punto de inflexión que estamos buscando. Adobe ha dado un primer paso en esa dirección con las capacidades JDF de Acrobat 7, y más recientemente Quark subió el listón integrando la compatibilidad de JDF en QuarkXPress 7. Aunque todos estos progresos son muy alentadores, dudo de que ninguna de estas iniciativas logre generar un impulso sustancial a corto plazo.

 

Alcance y complejidad

Uno de los principales problemas a los que se enfrenta JDF es su amplio alcance y complejidad. Incluso los grandes fabricantes lo tienen difícil para crear sistemas totalmente compatibles con la especificación, lo cual se traduce en implementaciones segmentadas y, en ocasiones, incompatibles. Decidir qué campos o subgrupos deben utilizarse es una tarea reservada a los expertos, e incluso así, el proceso creativo no se puede aprovechar tan fácilmente.

Además, JDF está lejos de englobarlo todo. Los sistemas de gestión de recursos suelen basarse en EXIF y XMP para procesar la información sobre derechos de autor y otros datos comerciales. Por ejemplo, los metadatos IPTC para fotografías de prensa (www.iptc.org/IPTC4XMP) se almacenan en el archivo de imagen como etiquetas binarias o un XMP, no como JDF. Las normas para captar la lógica de negocio relacionada con los artículos de noticias (www.newsml.org) y anuncios (www.adsml.org) están basados en XML simple, no en JDF.

 

Un ejemplo

Un excelente ejemplo que ilustra ambas ideas es la iniciativa de etiquetas de publicidad (ad-tickets) implantada recientemente en Bélgica. Medibel+ (www.medibelplus.be) es la asociación belga de empresas del sector de la publicidad, incluidas agencias, centros de medios y editores. Frustrada por la complejidad de las normas existentes, la asociación definió un mecanismo para incluir un conjunto básico de metadatos sobre publicidad (25 campos) en un archivo PDF, basándose en XMP. Esta especificación también ha sido adoptada por el subcomité de etiquetas de especificaciones del Ghent PDF Workgroup (www.gwg.org), de forma que se puede ofrecer a asociaciones de otros países.

Esta pragmática especificación de etiquetas de publicidad está siendo implantada en Bélgica, utilizando herramientas sencillas para editar los campos de metadatos (incluido el panel de información del archivo de Adobe Creative Suite). Debido a su gran facilidad de implementación, Medibel+ espera que muchas empresas la adopten. Y aunque puede no abarcar todas las situaciones posibles del sector, sin duda sustituirá a cientos de faxes que se envían todos los días, eliminando el factor de error humano y al mismo tiempo reduciendo gastos y el nivel de frustración.

 

Hay esperanza

Éste es sólo un ejemplo que nos indica que ninguna norma de metadatos puede dominar sobre las demás. Por definición, los monopolios e imperios son negativos; suelen ahogar la competencia y la innovación. Debemos aceptar la idea de que la automatización de procesos vendrá dada por una mezcla de normas de metadatos muy amplias como JDF, especificaciones más modestas como la etiqueta de especificaciones basada en XMP de Medibel, y convenciones sencillas fijadas por unos pocos individuos u organizaciones.

Hay lugar para la esperanza. Aprenderemos a superar las complejidades que nos encontremos por el camino. Las facciones antagónicas de normas de metadatos encontrarán una forma de coexistir e interactuar en paz. Por ejemplo, el Ghent PDF Workgroup ha entrado en contacto con el organismo normativo AdsML para garantizar la compatibilidad de sus trabajos actuales y futuros.

Y llegará un día en el que estaremos contentos de dejar que varias formas de metadatos guíen nuestros documentos por el flujo editorial (desde la creación hasta la entrega) mientras nosotros disfrutamos de una barbacoa con los niños.

*Peter Camps es fundador y CEO de Gradual Software (www.gradual.com). La línea de productos SWITCH de la empresa está diseñada para contribuir a facilitar las tareas de automatización descritas en el presente artículo.