Gestión de Contenidos, un enfoque independiente
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«.
Definición 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).
Contacto
Cualquier comentario, crítica o aportación será bienvenido
Visita mi Web gratuito y abierto sobre nuevas tecnologías www.adictosaltrabajo.com
Puedes subcontratarme para impartir formación o ayudarte en tus proyectos, en mi
propia empresa.
www.autentia.com
