La actuación de un CIO o responsable de Sistemas durante un ejercicio normalmente viene gobernada por un plan estratégico de Sistemas o plan director.

Parece lógico que la dirección general de una organización o comité de dirección se plantee unos objetivos y que la actuación en materia de tecnología tenga que adaptarse para cumplirlos.

Cito hipotéticos casos:

• Si el objetivo de la dirección es duplicar ventas, esto puede ser imposible sin adquirir otra compañía. Entonces los esfuerzos ese año, o incluso de alguno más, tendrán mucho que ver con la fusión.
• Si el objetivo es aumentar la retención de los clientes, posiblemente se deba invertir en un CRM o en una política de fidelización (o gamificación), creando bonos o cupones de descuento.
• Si el objetivo es captar nuevos empleados, posiblemente haya que desarrollar o integrar una herramienta de selección de candidatos.

En grandes organizaciones habrá distintas líneas de negocio e incluso países con distintos niveles de madurez y particularidades que puedan hacer que el catálogo de objetivos y posibles soluciones sean inmensos por lo que tendrán que priorizarse de acuerdo al valor que puedan aportar.

El plan director de Sistemas clásico normalmente tiene actuaciones a varios años que tienen que ser revisadas para dotarlas de agilidad. Por ejemplo, rehacer el sistema transacional de un banco puede llevar 5 años y tiene que convivir lo que hay con lo que se va sustituyendo poco a poco.

Habitualmente, las empresas contratan a grandes consultoras la elaboración de este plan estratégico de Sistemas, lo que tiene sus ventajas e inconvenientes.

• Ventajas: se pueden centrar ya que disponen de un método maduro para realizar el trabajo, se evita la endogamia, se incorpora la visión externa del sector y de qué hace la competencia, hay informes de mercado y gente dedicada externa.
• Inconvenientes: suelen quedarse en la estratosfera, como declaración de intenciones, con un gap muy grande entre la idea y cómo ejecutarla; el coste de la consultoría, a veces prohibitivo; los intereses en la posterior ejecución o en recomendar productos de aliados; la sobre-actuación dedicando meses; la poca alineación con los nuevos modelos ágiles de construcción.

Resumiendo rápidamente, el método de generación de un plan estratégico de Sistemas podríamos decir que consisten en:

• Redactar los objetivos de la organización.
• Tomar la visión de a dónde va el mercado y los clientes (con benchmarking y/o cuadrantes de consultoras estratégicas).
• Recopilar las necesidades de los propios Sistemas de Información (que se quedan simplemente con el tiempo obsoletos).
• Identificar el as-is del sistema (cómo estamos).
• Describir el estado final deseado (no ideal sino una visión continua de mejora).
• Marcar los indicadores o KPI de éxito de las iniciativas, como el ROI (recuperación de la inversión).
• Definición de los cambios en procesos, infraestructuras/herramientas y personas.
• Estudio de riesgos (coste/beneficio).
• Detallar el calendario, coste y plan de acción.

El formato de entrega de las actuaciones suele ser fichas, que tienen un nivel de abstracción suficiente para presentarlo a la dirección.

Es importante comparar la organización con el resto del sector en términos de inversión tecnológica vs. ventas, empleados externos respecto a internos, subcontratación respecto a construcción in-house. Parece lógico que compañías donde se incorporar CIOs con alto background técnico, tendrán una tendencia excesiva a querer hacerlo todo internamente y compañías donde los CIOs tengan un background consultivo tiendan a no valorar la ejecución y a subcontratar todo externamente. La media del mercado puede darte una referencia más sensata.

En casi todas las organizaciones, muchas veces se olvida lo más importante: hablar con los clientes y con los empleados de qué es lo que más les frustra en los procesos de la compañía o en el uso de las herramientas actuales, por lo que se gasta el dinero intentando dar más valor cuando perdemos al personal y a los clientes por la falta de elementos aparentemente evidentes, si se pregunta. Recordemos que estamos en la época de la transformación digital donde se pretende poner a los clientes en el centro del sistema. Hablar con ellos no parece descabellado.

Uno de los mayores problemas al implantar un plan director de Sistemas es el poco seguimiento del mismo. El día a día puede con las organizaciones y se hace fundamental que haya alguna persona que se encargue de velar por que las actuaciones convergen con ese plan director.

Otro problema todavía más grande es el hacer del plan una ley. Lo importante no es seguir el plan sino planificar.

Ahora es cuando viene un poquito el cambio en modelos ágiles: parece lógico que introduzcamos en nuestro vocabulario la palabra hipótesis. Sobre un objetivo hay una o varias soluciones, pongamos un ejemplo.

Hemos hecho una encuesta a los clientes y el grado de satisfacción con nuestra página web no es el adecuado. No es bonita, no es responsive (se ajusta al dispositivo) y creemos que eso está lastrando la conversión y las ventas. Imaginad que en el plan director decidimos hacer una sustitución del mismo, pongamos por tres millones de euros (calderilla para empresas gigantes e impensable para una startup). Posiblemente se nos quedaría una gran cara de tontos si, después de hacerlo, descubrimos que el nivel de ventas no cambia (o incluso baja por el choque para el cliente) porque realmente no era el factor decisivo para el cliente. Posiblemente el precio, política de devoluciones, plazos de entrega, poca calidad de soporte u opiniones desfavorables en redes sociales podrían ser las causas que no arregla el nuevo sistema.

Parecería entonces lógico que para validar cualquier hipótesis tenemos que hacer proyectos mucho más pequeños. O mejor dicho, descomponer el proyecto en una primera fase de validación (con funcionalidad limitada) y otra ya de ejecución. De tal modo que si en la primera fase nos damos cuenta de que no es el camino, podemos cambiar de rumbo (pivotar) y buscar alternativas sin haber consumido el presupuesto. Algo obsesivo en nuestra mente debería ser la frase “falla rápido, falla barato”.

En los modelos Lean una de las claves es reducir el tamaño del lote. ¿Qué pasaría si en vez de pedir un plan anual pedimos un plan solo a 6 meses? Podríamos definir unos objetivos globales, unas soluciones a corto plazo detalladas y unos titulares de lo que se podría hacer el siguiente semestre. De este modo, viéndonos obligados a podar y priorizar, posiblemente se abordasen las partes fundamentales del proyecto y se validasen esas hipótesis con costes mucho más reducidos.

¿Y si en vez de 6 meses lo hiciéramos en 4 meses? Obviamente se podrían hacer muchas menos cosas en cada entrega, pero siguiendo el principio del “tren de entregas”, Negocio no se pondría muy nervioso porque si algo no se lo entregas en un bloque, irá en el próximo. Mayor elasticidad que posiblemente requiera menor formalismo y mayor comunicación cara a cara.

Uno de los cambios más importantes que se han producido en los últimos años gracias a los modelos ágiles es la visualización del trabajo. Einstein decía que “no lo entiendo si no lo puedo pintar”. Parece razonable que en las empresas deberíamos acostumbrarnos a tener las paredes llenas de paneles. Alguien podría decir que es información confidencial y que el exceso de transparencia no es bueno. Obviamente no todo hay que contarlo pero una estrategia no comunicada es una estrategia inexistente y es casi imposible que una organización se alinee con ella si no la conoce, no se refuerza o no se adapta a las condiciones del día a día.

El agilismo se implanta en todos los niveles de una organización y el plan de Sistemas no es una excepción.

Os recomiendo que visiteis a Vanesa Tejada y veáis como plantea la gestión del porfolio, seguro que os dará muchas buenas pistas: https://vanesatejada.com/2016/03/01/como-un-portfolio-de-proyectos-nace-crece-se-reproduce-y-muere/

Roberto Canales Mora,

CEO de Autentia.