Cómo no equivocarse de Gestor de Contenidos

Content Management SystemRaro es encontrar una empresa que esté satisfecha con el software de Gestión de contenidos que adquirió. Las quejas, ademas, se parecen bastante: “no se adecúa a las necesidades de la empresa”; “no tiene flexibilidad ninguna”; es extremadamente difícil -o costoso- realizar cambios”; “demasiado caro para las prestaciones que ofrece”, etcétera, etcétera.

El origen de esta insatisfacción se encuentra, a menudo, en que la selección del software de Gestión de Contenidos se centró demasiado en los “requisitos funcionales”, pero olvidando las necesidades reales y específicas de la empresa.

Las empresas, desde hace mucho tiempo, se han centrado en los RFP donde se detallan una serie de requerimientos funcionales que, teóricamente, deben cubrir las necesidades de la organización. Por ejemplo: workflow integrado, características del sistema de publicación, etcétera.

Pero, por seguir con el ejemplo, puede ser que un producto que cumpla estos requerimientos (un excelente workflow integrado, por ejemplo) necesite, para su pleno aprovechamiento, dedicarle mucho tiempo/dinero en programación para que realmente se adapte a las necesidades específicas de la empresa. Y si estos recursos en tiempo/dinero no están disponibles, el proyecto de implantación de un CMS inevitablemente fallará.

Por ello, a veces es más práctico ir directamente al grano y definir claramente, desde el principio, cuáles son las necesidades concretas que debemos cubrir. Y en un CMS, las capacidades de administración que debe incluir son, al menos:

  • Gestión de usuarios
  • Creación y edición simple del workflow
  • Reestructuración del sitio web
  • Modificación de plantillas

Y todo esto a través de una interfaz de usuario extremadamente sencilla y amigable. Si se necesita recurrir a la programación para hacer alguno de estos cambios, está claro que en el equipo que administre el sistema de Gestión de Contenidos debe haber perfiles adecuados para realizarlo.

En las RFP estas necesidades deben expresarse de forma clara y nada retórica, evitando en la medida de lo posible el lenguaje técnico. Es deseable, además, acompañarlo de la descripción de algún escenario práctico donde se detalle cuál va a ser el uso real en su contexto real del software que pretendemos adquirir. Los proveedores deben saber qué es lo que esperamos de su software, y debemos preguntarles no sólo lo que hace su CMS, sino también como lo hace. Para que luego no haya “sorpresas”.

Deja un comentario