Gestión de Contenidos, un enfoque independiente

Este articulo es cortesia de la Web Adictos Al trabajo.

Definición de Gestión de Contenidos

Cuando se habla de gestión de contenidos, existe una gran confusión porque el término es bastante ambiguo y "todo cabe" en esta definición.

En el siguiente artículo os voy a comentar en qué creo que consiste la gestión de contenidos y cómo las empresas se pueden favorecer de ello, comentando también los que considero "grandes errores de las empresas, en la implantación de soluciones de gestión de contenidos".

Definir gestión de contenidos, puede ser un poco pretencioso por mi parte pero vamos a ver si entre todos los conseguimos:

"Todos los procedimientos y procesos involucrados en el agregación, transformación, catalogación, agrupación, autorización, presentación y distribución de información útil para nuestros propósitos"

Bueno, como podemos observar dentro de esta definición todo cabe y cuando vemos las distintas herramientas, cada una de ellas se puede centrar en distintas problemáticas:

• Gestión documental: Más orientado a la catalogación y recuperación de contenidos grandes (documentos)
• Gestores de presentación Web/Herramientas de Portal: Más orientado a la construcción rápida de Sites.
• Gestores de conocimiento: Más orientado a la estructuración y correlación de datos.
• Herramientas de composición de publicaciones en papel (que intentar adaptar sus aplicaciones para crear con facilidad la versión Web)
• Herramientas de gestión departamental: Orientado al trabajo en equipo

Y seguro que encontramos numerosas catalogaciones más.

Nosotros vamos a analizar, de un modo simplista, cuales son los procesos asociados a esta tecnología. Reduciremos a tres, las capacidades de los sistemas de gestión de contenidos:

• Adquisición de Contenidos
• Manipulación de Contenidos
• Entrega de Contenidos

El elemento vital y núcleo del sistema será el almacén o repositorio de contenidos (considerando, a partir de ahora, un contenido como cualquier información que queremos almacenar de modo estructurado), donde la información se encuentra estructurada de tal modo que permita ser manipulada y explotada con facilidad. Este repositorio será normalmente una base de datos y tal como evolucina la tecnología, lo ideal sería una base de datos nativa XML.

Normalmente, un problema complejo es la suma de muchos problemas simples. Vamos a analizar cada problema por separado y tratar a su vez de sub-dividirlo.

Adquisición de Contenidos

Un repositorio de contenidos tiene que tener la capacidad de albergar las estructuras de datos necesarias para tratar nuestra problemática concreta.

Normalmente, no habrá definido ningún tipo de estructura pero sí nos permitirá hacerlo con facilidad. Los arquitectos de información deberán analizar las estructuras de datos y procesos de mi sistema y mapearlas (a partir de la obtención de factores comunes) a las herramientas.

Es posible que algunas herramientas ya integren ciertas estructuras que son bastante comunes en cualquier sistema: Noticias, encuestas, productos, etc.. pero en este caso, si no entendemos bien el concepto, es posible que caigamos en un error bastante común y es decir: "como no nos gusta cómo realizamos las tareas hasta ahora, compramos una herramienta y nos adaptamos a ella". NO, "las herramientas deben permitir optimizar los procesos de negocio y adaptarse a ellos y no al revés", nuestra empresa no debería adaptarse a una herramienta de propósito general (aunque sí podría ayudarnos a organizar ideas). Este error se comete con mucha frecuencia con las herramientas de CRM.

Es evidente que posteriormente hay que alimentar de datos estas estructuras. Ya podemos hablar entonces de:

• Metadatos: Definición de las estructuras de datos (y otros elementos esenciales para manipularlos)
• Datos: Contenidos en sí.

Agregación

Debemos tener capacidad de aprovisionar nuestro sistema con contenidos:

• De propia creación: A través de autores
• De otras fuentes externas.

Si los contenidos son propios, debemos tener en cuenta algunos temas:

• Quién puede introducirlos: Autentificación
• Qué revisiones requiere:
• Morfología (sintaxis, tamaño, formato)
• Seguridad de acceso y protección del propio sistema (ataques directos por entrada de datos).

Si los contenidos son de terceros, debemos tener en cuenta:

• Origen de los datos (contemplar copyright)
• Fuentes públicas o privadas.
• Procedimiento de extracción
• Agregación de sistemas en vivo bajo demanda (ir a por los datos)
• Alimentación periódica de servicios contratados (recepción de datos)
• Volumen

En cualquiera de los casos, tenemos que conocer el ciclo de vida de la información:

• Categorización inicial, posiblemente realizada por la fuente de datos para su manipulación interna.
• Definición del público objetivo (por edad, por privilegios dentro del sistema, etc..)

Algunos Ejemplos:

• Web financiero de información sobre cotizaciones: Sistemas centrados en la adquisición de contenidos de recepción contratada:

  En este caso, la presentación está completamente vinculada con la adquisición de datos. Ahora bien ¿y si lo que nos interesa es fidelizar a nuestros clientes ofreciéndoles personalización? Ahora el problema no es tan sencillo.... requerimos que la información esté categorizada pero no como la obtuvimos de la fuente, sino de tal modo que sea explotable por nuestro sistema de un modo integral. Necesitamos entonces mapear las categorización de la fuente a la categorización de nuestro sistema en particular.

• Agregador de ofertas: Sistema centrado en la adquisición de datos de distintas fuentes en función de peticiones:

  Es posible que nos interese construir un sistema que proporcione al usuario la capacidad de, bajo algunos parámetros, localizarle en otros Webs la mejor oferta sobre un producto concreto. Aquí el problema es que la información posee estructuras distintas en origen (html con distintos formatos), que pueden cambiar sin previo aviso y que posiblemente el contenido no tenga el mismo nivel de detalle en cada fuente.

Transformación

Cuando adquirimos los contenidos, normalmente no tienen la estructura ni los atributos obligatorios para el correcto funcionamiento del sistema. Es por lo tanto necesario transformar los datos del modo más eficiente posible.

Si los contenidos son de propia creación, esto puede no ser un problema cuando el usuario introduce los datos por el propio sistema pero ¿y si nos envía un documento Excel, Word, etc.? Es evidente que hay que extraer la información y mapearla a nuestras estructuras nativas. Realizar esta labor de un modo manual, tendría un coste operativo insostenible.

Si los contenidos son adquiridos de sistemas externos, por ejemplo, otros Webs (pensad en un agregador financiero donde se puede consultar nuestras cuentas en distintos bancos, centralizadamente desde un soloWeb) cualquier cambio en la estructura de origen debe ser identificado y adaptado, independientemente de tener que adaptar las estructuras de información de las distintas fuentes. La programación manual de cada transformación obligará a tener un equipo sólo dedicado a esta tarea.

Existen productos que gráficamente nos permiten conectarnos a distintos sistemas y programar las transformaciones y validaciones básicas (y a veces, no tan básicas).

Manipulación de Contenidos

Hasta ahora nos hemos encargado de acercar los contenidos a nuestro repositorio y adaptar su forma. Cuando adquirimos datos, por sí mismos es posible que no nos valgan para nada, también hay que adaptar el contenido.

Imaginad que adquirimos de proveedores de noticias los textos (en chino), sólo los textos, pero somos famosos por tener el Web con las noticias y fotos más impactantes....

Obviamente necesitamos:

• Traducir los contenidos (a nuestro lenguaje) sin perder el original.
• Certificar la traducción (Workflow opcional)
• Asociarle otros contenido (que hay que localizar por sus categorías originales o las de nuestro sistema)
• Categorizar el nuevo contenido que hemos creado (como suma de otros) Definir quién es el público objetivo de este nuevo contenido.

Pero también podemos poner otro escenario, imaginad que el CEO de una empresa quiere introducir la nota de prensa que posteriormente se mostrará por distintos canales cuando se hagan públicos los resultados de la empresa. En este caso, necesitamos algunas cosas más:

• Restringir el acceso de esa información (nivel de acceso)
• Validar tanto la forma como el contenido (Workflow obligatorio)
• Planificar su liberación (coordinado con otros eventos o por una fecha)

Resumiendo necesitamos ciertas capacidades:

• Seguridad
• Workflow
• Categorización (o re-categorización)
• Planificadores de actividades

Tened en cuenta que hasta ahora no hemos hablado absolutamente nada de presentación de la información. La tratamos como algo abstracto. Será la base de nuestros sistemas de presentación.

Aquí es donde difieren las distintas herramientas y donde se producen las confusiones sobre las capacidades de los gestores de contenidos.

Entrega

Cuando utilizamos un gestor de contenidos nuestros objetivos pueden estar centrados en intereses distintos:

• Construir un Web rápidamente y a bajo coste: Orientación a presentación (ejemplo: Web de tecnología)

  Seleccionar los contenidos de un modo sencillo ( o introducirlos directamente) y proporcionar servicios básicos (chats, foros, encuestas)

• Controlar la información publicada: Orientación a contenido (ejemplo: Web Institucional)

  Nos interesa menos la capacidad de presentar contenidos y más la de estar seguro que ha seguido un Workflow

• Publicar contenidos en distintos Web de modo simultáneo: Orientado a difusión (ejemplo: Gran empresa)

  Nos interesa la capacidad de difundir en muchos sites una misma información. Piense en empresa muy grande (o grupo de empresas) que tiene muchas divisiones (donde cada una tiene su propia Web) y quiere que cierta información esté presente en todos.

• Fomentar el consumo de productos (Compra): Orientado a fidelización (ejemplo: Web de venta directa)

  Nos interesa capturar los hábitos del usuario en nuestro sistema y facilitarle el consumo. La personalización será uno de los puntos claves del sistema (juntos a una correcta categorización e indexación de contenidos)

• Reaprovechar los contenidos en múltiples canales: Orientado a reutilización (ejemplo: Periódico con versión electrónica y el papel)

  Nos interesa que los mismos contenidos sean publicados en distintos medios, con el mínimo esfuerzo.

Bueno, está claro que no todos los sistemas son iguales por los que tampoco podemos pretender que todas las herramientas puedan ser igual de provechosas para todos los clientes.

Cualquiera que sea nuestro objetivo, siempre deberíamos poder controlar:

• Workflow de publicación multi-rol.
• Qué publicamos en un momento determinado (la foto del sistema en un momento determinado).
• Debemos tener capacidad de encontrar los contenidos publicados y proporcionar esta capacidad a nuestros usuarios (motor de búsqueda).
• Capacidad de integración con sistemas transaccionales.
• Previsualización interna de contenidos anterior a su publicación a público en general.
• Existencia de enlaces rotos.

Tampoco debemos olvidar que hay veces que los contenidos que poseemos no queremos entregarlos cuando el cliente accede al sistema sino que queremos realizar una entrega pro-activa, es decir, le enviamos contenidos de reciente publicación. Normalmente se habla de entrega multi-canal: Wap, e-mail, sms, etc

Presentación

Los sistemas de presentación deben ser capaces de recuperar los contenidos y presentarlos de un modo eficiente (rápido y claro). Un mismo contenido debe tener la capacidad de ser mostrado de distintos modos por lo que se habla de plantillas de presentación.

Los sistemas de presentación suelen funcionar del siguiente modo:

• Un Web es un conjunto de páginas organizadas jerárquicamente.
• Una página posee una plantilla (definición de estructura y tipo de contenidos a mostrar).
• Una plantilla de página incluye varias plantillas de componente (definición de como mostrar un contenido concreto).
• Un editor decide introducir una página (con una plantilla concreta y las plantillas de componente asociadas) y los contenidos concretos (seleccionados del repositorio existente).

Está claro que necesitamos poder definir las plantillas de página y de componente, así como de poder localizar y asociar los componentes.

Esto podría ser el primer paso pero no debemos olvidar que cuando definimos una inversión tecnológica, esta debería estar motivada por la reducción del coste, la mejora del tiempo de explotación (time-to-market) y la mejora de servicio a cliente. Para que estos tres puntos puedan cubrirse se requiere una correcta explotación de los sistemas para conocer a nuestros clientes y ofrecerles un trato personal. Requerimos de personalización ....

La personalización puede ser explícita o implícita, es decir, en base a datos sobre preferencias indicadas por el usuario o en base a nuestro análisis de sus hábitos de navegación y consumos. En este caso necesitamos registrar (trazar) el comportamiento del usuario y ser capaz de ofrecer dinámicamente contenidos de categorías concretas.

Pero nunca se puede olvidar una cosa, el perfil del cliente cambia con el tiempo por lo que nuestros sistemas deben ser sensibles a estos comportamientos. Aquí entran en juego otros elementos como son el análisis de datos y la definición de contenidos asociados a segmentos de usuario, es decir, CRM analítico y CRM operacional.

Cuando los Webs tienen un número alto de visitas, los problemas con los que nos enfrentamos son más complejos. Un sistema de presentación como el que hemos comentado con unas pocas tablas de base de datos y un poco de imaginación, lo podríamos resolver pero .... funcionaría con 100.000 peticiones diarias. ¿Qué infraestructura necesitaríamos para dar soporte a este sistema?. Es posible que necesitemos un mecanismo un poco más complejo de composición dinámica de sistemas de presentación pero que se comporte en ciertos casos como si fuera estático.

Para esto hay algunas opciones:

• Mecanismos de caché.
• Generación de árboles estáticos a través de sistemas dinámicos.

Para que estos mecanismos sean efectivos, debemos conocer muy bien el ciclo de vida de todos los contenidos presentados en una página así como los mecanismos tecnológicos de los que disponemos.

Distribución

Si nuestra corporación es grande, puede que tengamos versiones de nuestras publicaciones en varios idiomas o que participemos de empresas (de modo mayoritario o no) y nos interese que parte de nuestros contenidos se publiquen automáticamente en el resto de los subsistemas. En este caso, hablamos de la publicación multi-site.

Los contenidos, pueden ser mostrados en nuestro sistema o entregados a otros sistemas (bajo demanda o de modo pro-activo).

Es posible que nuestro sistema tenga la capacidad de agregar, transformar, categorizar y empaquetar los contenidos y que otras empresas quieran centrarse en su negocio y olvidarse de estas tareas y simplemente agregarlos a sus sistemas de presentación. Un ejemplo pueden ser las grandes proveedoras de noticias que se encargan de recopilar datos de multitud de fuentes y proporcionarlas a multitud de destinos (que no tienen interés ni recursos en hacerlo).

Se suele hablar de sindicación de contenidos.

Plan de implantación de soluciones de Gestión de Contenidos

Motivación

Cuando una empresa se plantea la posibilidad de implantar un producto de gestión de contenidos normalmente es porque se encuentra en una situación incómoda y desea solucionarla:

• Demasiados Webs en su sistema con contenidos desactualizados o difícilmente gestionables.
• Imposibilidad de encontrar una información concreta en nuestro propios sistemas.
• Falta de homogeneidad en la presentación de datos (navegabilidad, formato y actualidad de la información).
• Costes elevados en sistemas que aportan poco valor al negocio (internos).
• Falta de coordinación y mínima reutilización de los desarrollos.
• Poca capacidad de análisis de hábitos de los usuarios y bajo nivel de retención de clientes.
• Han creado divisiones tecnológicas tan pesadas y complejas que éstas realmente no llegan a comprender cuál es su función (aportar valor al negocio principal de la empresa).

Errores comunes

Cuando una situación es incómoda, muchas veces nos precipitamos....

Comprar una herramienta (de cualquier tipo) y pretender que en pocos meses esa solución habrá resuelto todos nuestros problemas puede parecer cuanto menos que:

• No somos conscientes de nuestra problemática
• Nos queremos engañar a nosotros mismos (por si acaso)
• Nos han hecho una buena labor comercial.

Si una gran organización (empresa) tiene 20 Webs y queremos unificar criterios .... hay que arreglar algo más que la tecnología. Probablemente halla que modificar muchos procesos internos así como reeducar a mucha gente.

La consolidación de estrategias de gestión de contenidos, requiere la madurez e involucración de distintas áreas de la empresa:

• Negocio (comercial)
• Marketing
• Legal
• Tecnología

Los proyectos de gestión de contenidos, para mi gusto, no se deben abordar a lo ancho, es decir, tratar de resolver 20 problemas grandes al mismo tiempo.

Todavía lo podemos hacer peor (esto seguro que no le gusta a algunos comerciales con cultura de tierra quemada) y es comprar una licencia corporativa de un producto cuando todavía no hemos implantado ningún proyecto con éxito y cuando no tenemos ninguna referencia fiable de lo mismo.

Implantación de solución:

Los proyecto de gestión de contenidos deberían (repito que para mi gusto) abordarse en profundidad:

• Identificar cuales son elementos prioritarios en nuestro sistema.
• Seleccionar un producto que creemos que puede cubrir nuestras necesidades a un coste reducido.
• Subcontratar los servicios de empresas especializadas (el vendedor, socio tecnológico o empresas con probada capacidad) para ayudarnos a adquirir las capacidades necesarias en poco tiempo, en un proyecto vital para la empresa (para nuestro negocio principal)
• Crear una primera fase del proyecto, corta y poco ambiciosa, tratando de analizar la idoneidad de la solución para la empresa y capacitando a nuestro personal sobre el producto elegido.
• Continuar el desarrollo sobre ese proyecto aumentando las capacidades del sistema: Nuevos contenidos, Wokflows y capacidades de personalización.
• Una vez ratificado que el beneficio compensa el coste, elegir otro proyecto e integrarlo en nuestra solución.
• Si en este momento estamos contentos... a lo mejor debemos plantearnos la compra de una licencia corporativa .......

Leyendo entre líneas, lo que queremos comprobar:

• Que el producto nos compensa
• Que el comercial no nos ha vendido un concepto muy bonito pero difícil de alcanzar a un coste razonable (ha pasado y seguirá pasando).
• Que tenemos soporte local de la empresa en nuestro país (a un coste razonable).
• Que varias empresas de servicios tienen personal cualificado para que no estemos atados con un único proveedor. Hay veces que las políticas de formación de la empresas de productos son tan tiránicas que impiden que otras empresas de servicios se formen adecuadamente sobre los productos. Esto es un circulo vicioso porque cuando las empresas implantan soluciones, lo suelen hacer de un modo mediocre, lo que perjudica seriamente a la imagen de la empresa de productos (¿os suena?).
• Que es factible reutilizar los esfuerzos (código, workflows, etc..) y conocimientos adquiridos en otros proyectos.

Riesgos a Evitar

Sería triste que después de finalizar un proyecto de gestión de contenidos, llegásemos a las siguientes conclusiones:

• Que hemos reconstruido un proyecto con un gestor de contenidos para no obtener ningún beneficio para el negocio.
• Que hubiera sido lo mismo haciendo el proyectos con tecnologías base (asp, jsp) y nos hubiera costado 10 veces menos.
• Que como nos hemos gastado tanto dinero en el producto, para no tener problemas internos, defendemos una tecnología o productos con el cual estamos descontentos o frustrados (somos cautivos de nuestra elección).
• Que hemos definido unos Workflows durante semanas y luego siempre la misma persona (casi siempre) realiza todas las tareas.

Otras consideraciones

Cuando se abordan soluciones, hay otras consideraciones que condicionan la elección de herramientas:

• La tecnología condiciona la herramienta a utilizar.
• La tecnología debe ser un medio para alcanzar un fin, "mejorar nuestra capacidad de generar negocio".
• Sin inversión no hay beneficio. Hay que planificar con cabeza y preparar nuestros sistemas para el futuro.
• Hay que confiar en los recursos internos y apoyarlos con recursos externos para no caer en organizaciones endogámicas.

Comentario final

Debemos aprender de los errores ( y hablo en primera persona de muchos de los mencionados con anterioridad ), tratar de no volverlos a cometer (aunque cometeremos otros esperemos que no tan graves) y adelantarnos al futuro (que es lo que garantizará la diferenciación respecto a la competencia).