La diferencia entre conocer el camino de un CIO y recorrerlo

Una de las máximas que todo CIO “debería tener” es la de buscar la alineación/integración de SI/TI con el negocio. Claro, que hay una diferencia sustancial entre conocer el camino y recorrerlo (esta frase la he hecho mía después de tener que utilizarla en más de 5 ocasiones en el último mes, así que no mencionaré que se la escuché a Morfeo en Matrix). Uno se centra en conocer los objetivos estratégicos de la empresa en la que está, identifica-estudia los procesos clave, y busca automatizar/transformar los mismos en la medida en que esto es posible (posible=f(equipo, tecnología, cultura, apoyo de la dirección … y un montón de cosas más)). Acuerdas con los directores funcionales los proyectos a abordar, elaboras conjuntamente el “as-is”, diseñas el “to-do”, se desarrolla e implanta siguiendo un método ágil, tienes tus baterías de test, haces pruebas de aceptación, y el equipo del proyecto está enormemente orgulloso de la labor realizada. Enhorabuena!!!.

Algunas veces, cuando consigues llevar a cabo semejante despliegue y crees que has satisfecho las necesidades de tu cliente interno (con el que se supone que tienes que estar alineado/integrado) te das cuenta de que no. De que no es suficiente. Falta algo más: un “informe nomina”, cambiar la posición del logo, multicolorear un grid, o lo que suele ser más grave, otro proceso tangencial que han convertido en “estratégico” recientemente (o que ya lo “era” y nadie lo identificó). Lo más curioso tiene lugar cuando, por vete tú a saber que razones (normalmente políticas), insisten con la implementación de un software cuyo objetivo subyacente es eliminar la estupidez humana (cómo que no lo habrá intentando durante años IBM). Si llegas aquí, es momento de parar (se tiene que disparar la misma alerta que cuando le has puesto un try-catch a un printf, has comenzado la implementación de un motor de bases de datos o de un hermano pequeño de Excel). Normalmente esto ocurre porque alguien no está haciendo bien su trabajo: las prioridades dependen de quien hable, hay una lucha de egos considerable, alguien está condicionando en exceso externamente, etcetera. Sin embargo he llegado a la conclusión de que esto sucede normalmente cuando no se pone un coste y un ROI a los proyectos de SI/TI. Cuando el cliente interno no percibe que lo desarrollado tiene un coste (sobre todo de oportunidad) y que sobre éste coste tiene una responsabilidad en el cumplimiento del ROI, tiende a minusvalorarlo.

Llegado este momento, que bajo mi experiencia indico que tiene carácter cíclico, el CIO tiene que obrar con tranquilidad y seguridad. Si no eres capaz de llegar a un acuerdo (puede que esté fuera de tu alcance o que no debas llegar a él para poder cerrar el ciclo) debes identificar el impacto en el núcleo de los servicios y procesos clave, dejando que el tsunami transcurra. Requiere mucha experiencia, templanza y seguridad. Si se hace bien provoca una “catarsis” en los afectados, algunas veces es el propio CIO el que lo necesita.

Empieza entonces el baile de alternativas: consultoras externas, desarrollos a medida con personal “cualificado” (cuidado con los informáticos externos a SI/TI ), hojas excel, bases de datos access, consultas sql cruzadas con … el universo. La posición del CIO debe ser la de preservar el núcleo de los SI/TI. Dejar que se hagan pruebas, si, pero con gaseosa.  Pasado un tiempo y un coste, se implantará el proceso.

Si es un éxito el CIO deberá replantearse su forma de gestionar. Se encuentra seriamente desalineado con el negocio lo que, desde una perspectiva constructiva, debe traducirse en un reciclaje en procesos de innovación o gestión, o en la identificación y gestión del talento dentro de su empresa. La máxima de “si funciona no lo toques” puede traer consigo estas consecuencias y no debemos alarmarnos si sucede. Simplemente tenemos que adaptarnos a las nuevas condiciones, analizar que es lo que ha pasado, y tener claro que en cualquier caso lo que tenemos que conseguir es la integración con el negocio.

Si por el contrario la implantación del proceso es insatisfactoria tenemos una oportunidad única de restablecer el aporte de valor al negocio de  SI/TI. Éste restablecimiento puede ser acumulativo, aprovechando lo desarrollado por el proyecto “externo” lo cual suele ser un poco infierno, o recomenzando, afrontando el desarrollo desde cero pero con la confianza mutua de los departamentos afectados.

Recuerdo una situación en la cual, por motivos de “por que lo digo yo”, se afrontó una implantación de una herramienta con carácter unilateral por parte del departamento de más peso de la empresa. Se llevaron a cabo reuniones indicando lo inadecuado del proceso y la solución adoptada, la dificultad en la obtención de información útil, los problemas de operativa, etc. Dio igual, se quería implantar “la herramienta” y se implantó. SI/TI dio cobertura a las necesidades de infraestructura. El entramado que se montó entre hojas excel, base datos access, ficheros compartidos en red y consultas sql fue tal que el sistema colapso en menos de 1 mes. Era como volver a los orígenes de la empresa. Entonces y sólo entonces se dio el OK al proyecto que SI/TI había propuesto para integrar los procesos de negocio y que posteriormente sirvió para escalar la solución.

Todo esto puede parece un “pelín” radical, pero hay muchos ejemplos en la vida cotidiana de lo que aquí he intentado describir cómo dejar que tu hijo tenga un pequeño susto mientras hace una trastada patinando/montando en bici/practicando algún deporte. Recuerdo una situación, un poco extrema,  siendo yo un niño en el que un gran maestro, no diré quien,  me dejó que tocase los cables de corriente para ver que pasaba después de mucho insistir y enredar por mi parte. No sólo aprendí porqué no se deben tocar los cables de tensión a la vez. También aprendí que hay una gran diferencia entre conocer el camino y recorrerlo

Advertisement