Decía Jean-Baptiste-Pierre-Antoine de Monet, más conocido como Lamarck, que "la función crea el órgano". Más de dos siglos después, el supuesto formulado por el naturalista francés que anticipó la teoría de la evolución de las especies formulada por Darwin 50 años después, sigue vigente y en un entorno que, como la naturaleza, se encuentra en evolución permanente: las organizaciones TI de las empresas.

Al igual que la industria tecnológica, las áreas TI de las empresas también evolucionan y, si hace tres décadas asistimos a la designación en Citicorp de Steve Katz como el primer Chief Information Security Officer (CISO) de la historia, en los departamentos TI está emergiendo una nueva función y, por ende, un nuevo órgano o cargo, al que ya podemos dar nombre: el Chief Performance Officer (CPO), responsable de una función tan crítica como es velar por el rendimiento tecnológico, cuyo impacto en la cuenta de explotación de las empresas es evidente.

El nacimiento de esta nueva figura no es casual y está directamente relacionado con la profunda desconfianza respecto al valor de la tecnología en el nivel de dirección de las empresas, donde desde hace años se ha instaurado la duda sobre la aportación al negocio de la tecnología, siempre con su jerga y sus costes crecientes.

Estos recelos no son la única causa tras el advenimiento de la figura del CPO. La principal razón se encuentra en la misma estructura de las organizaciones TI que, en la gran mayoría de las empresas y desde prácticamente los orígenes de la informática empresarial, se ha dividido y está dominada por dos grandes funciones: por un lado, Infraestructura y Operación; y, por otro, Desarrollo.

El desempeño de la primera de estas áreas, Infraestructuras, que representa una media de entre el 15% y el 25% del gasto en TI de las grandes empresas, normalmente se mide por dos indicadores o KPIs fundamentales: los costes y la disponibilidad. Desde el punto de vista de los costes, sus actuaciones, habitualmente de carácter reactivo, pasan por la migración a entornos más baratos y el outsourcing, y sus soluciones tecnológicas se centran esencialmente en la monitorización y el fine tuning o reajuste.

Por su parte, los dos KPIs con los que se mide a la función de Desarrollo son, en primer lugar y de nuevo, los costes. No en vano, de media, entre el 30% y el 40% del gasto en tecnología de las grandes empresas corresponde al desarrollo y el mantenimiento de aplicaciones. El segundo KPI con el que se mide al área de Desarrollo suele ser el "go to market", es decir, su capacidad para adaptar o desarrollar nuevas aplicaciones que respondan a las necesidades del negocio.

Así las cosas, la experiencia nos demuestra que las empresas lidian con un problema estructural que han intentado solucionar recurriendo al outsourcing de infraestructura y desarrollo, un modelo que puede tener su recorrido, pero que no ataca, e incluso puede agravar, la verdadera causa del bajo rendimiento de las organizaciones TI y verdaderamente se encuentra en la baja calidad del software.

Y, ¿por qué nadie parece darse cuenta de ese problema? Sencillo, nadie se ocupa del rendimiento global de la función TI, que es justamente para lo debería nacer la figura del CPO. El área de infraestructura, por su parte, considera que no es de su competencia y, el área de desarrollo, por la suya, no es proclive a reconocer que la calidad del software es baja y tampoco quieren violentar al usuario.

Además, y a pesar de la adopción teórica de la metodología DevOps, los responsables de desarrollo parecen no ser conscientes de que el concepto de prueba es incompleto ya que, tras superar las distintas fases de desarrollo, las pruebas de software no se realizan en un entorno real.

Ambas funciones, sin embargo, siguen justificando su labor y han sido incluso capaces de optimizar su actividad a lo largo del tiempo. Como mencionaba antes, en el primer ámbito gracias a la propia innovación tecnológica –más capacidad de proceso a menor coste- y la adopción del modelo cloud que, en la práctica, está muy lejos de aportar las alegrías esperadas; y en el segundo ámbito, recurriendo al outsourcing y la deslocalización. De hecho, el desarrollo y mantenimiento del software son funciones altamente subcontratados con niveles de outsourcing que pueden llegar a calificarse de salvajes. Hablamos de un mercado de bajo precio y, por tanto, de baja calidad.

El problema, por tanto, persiste y, del mismo modo que las jirafas alargaron su cuello para tener acceso a las zonas más elevadas de los árboles y sus nutritivas hojas, es necesario que las organizaciones TI también alarguen su alcance, que conecten estos dos entornos funcionales y que resuelvan el problema raíz que lastra su rendimiento, la baja calidad del software, problema aparentemente irresoluble.

La buena noticia es que, cuando se deciden a realmente resolver esta problemática, las organizaciones entran en una dinámica en la que se dotan de capacidad para medir el rendimiento bajo nuevos parámetros fundamentales para el negocio, más allá del coste que, por si solo, no mide nada; y de la monitorización reactiva, que únicamente sirve para avisar de los "accidentes" cuando ya se han producido.

La proactividad distingue a las organizaciones en las que ya se cultiva la cultura del rendimiento y tienen proyectos en marcha para su mejora continua. En estas organizaciones los profesionales TI que han cogido por el mango la sartén del rendimiento reciben diversos apelativos que coinciden en detonar la novedad de su función como IT for IT Projects manager o Head of Special Projects, entre otros.

Además de su nueva denominación, a estos profesionales TI les distingue su capacidad para correlacionar variables financieras (ingresos) y operativas del negocio (número de clientes, transacciones…) y para manejar KPIs que verdaderamente son representativos del perfomance de la función de TI: costes y tiempos de respuesta, pero también disponibilidad y cumplimiento de los Acuerdos de Nivel de Servicio (ANS), un indicador capital en entornos donde prima el outsourcing.

Y ¿cuál es el rol del CPO? El CPO, insisto, tiene el cometido de velar por el rendimiento. Para ello, en dependencia directa del CIO, el CPO debe tener funciones ejecutivas tanto sobre Infraestructura como sobre Desarrollo, es decir, no solo debe poder medir el desempeño de ambas áreas, también ha de tener capacidad prescriptora y capacidad de ordenar cambios.

La labor de CPO es, por tanto, continua, como lo es la mejora del rendimiento. Tiene que operar sobre lo ya existente -la terrorífica deuda técnica-, pero también sobre el nuevo software que se desarrolla y debe ser capaz, además, de gestionar el cambio porque, sin lugar a duda, encontrará resistencia.

A pesar de ello, sin lugar a duda la esta función está llamada a ser capital ante los CEOs, los CFOs y las cada vez más habituales comisiones de Tecnología de los Consejos de Administración de las grandes empresas que, como mencionaba antes, están instalados en el espacio de la desconfianza.

***Ángel Pineda es CEO de Orizon.