Con demasiada frecuencia, las inversiones en tecnología no logran los resultados prometidos. ¿A qué se deben estos fracasos de proyectos informáticos de las empresas? ¿Y qué pueden hacer estas para cambiarlo? Aquí hay cuatro causas identificables de ello y lo que las organizaciones pueden hacer al respecto.

 ¿Recuerda aquel proyecto informático que lanzó su empresa y resultó ser un fracaso? La respuesta, por supuesto, es sí: probablemente haya pocas organizaciones que no se hayan visto afectadas por algún percance, o peor aún, desastre, en un proyecto de TI (tecnología de la información).

¿Cómo es posible? ¿Por qué, a pesar de llevar décadas implantando sistemas informáticos, las organizaciones siguen teniendo problemas con sus proyectos tecnológicos? Mi colega, R.M. Bastien, y yo hemos estudiado cientos de proyectos de este tipo y hemos descubierto que las causas profundas del fracaso o el bajo rendimiento de las inversiones tecnológicas rara vez se encontraban donde los ejecutivos pensaban buscar.

El problema: se centraban en los síntomas, no en las verdaderas causas.

Un proyecto es un esfuerzo temporal, y una vez que se completa y funciona, las personas se enfocan en nuevos proyectos o empresas, dejando el pasado atrás.

¿Cuáles son esas verdaderas causas? Aquí hay cuatro que hemos identificado y lo que las organizaciones pueden hacer al respecto.

Una de las causas ocultas es un proceso de inversión que comienza cuando alguien -normalmente un directivo o un responsable presupuestario- necesita tecnología para resolver un problema o aprovechar una oportunidad. Entonces, el departamento de TI construye o adquiere la solución tecnológica, ya que todas las solicitudes relacionadas con la tecnología pasan por este único departamento.

La consecuencia es que, por un lado, está el “cliente” (la unidad de negocio) y, por otro, el “proveedor” (el departamento de TI). El cliente quiere estar seguro de que recibe lo que ha pagado, por lo que exigirá cierta supervisión del progreso del proyecto y visibilidad de cualquier riesgo. Para ello, puede crear un comité y determinar los parámetros de información adecuados, normalmente el tiempo y el costo.

Por desgracia, todo esto sólo les da la ilusión de tener el control. Lo que ocurre en el proyecto, donde pueden tomarse cientos de decisiones semanalmente, es probable que sea invisible para el patrocinador del proyecto. Y esas decisiones pueden socavar el resultado final del proyecto.

Como analogía, piense en llamar a un Uber y seguir al coche mientras viaja para recogerle. Esto te da la sensación de controlar la transacción. Pero es una ilusión. Sí, el conductor llega a tiempo, pero el coche no tiene combustible, está sucio, el conductor parece bajo los efectos del alcohol y tiene un maletero pequeño en el que no cabrá todo su equipaje.

El departamento de TI quiere ser visto como un socio empresarial, que trabaja en estrecha colaboración con colegas de toda la organización. A pesar de este loable objetivo, lo cierto es que las unidades de TI se designan en su mayoría como centros de costos, mientras que la unidad de negocio es un centro de beneficios.

Esto significa que las prioridades de la unidad de negocio no son necesariamente las mismas que las del departamento de TI.

El conflicto más claro radica en la práctica de que las TI se encarguen de establecer las normas arquitectónicas de los sistemas de construcción y, a continuación, diseñen, construyan y certifiquen que los sistemas digitales se ajustan a dichas normas. En otros campos, como el de la construcción, existe una clara demarcación entre los que diseñan, los que construyen lo diseñado y los que poseen -y obtienen los beneficios- el resultado.

En la práctica, eso significa que las decisiones se inclinan sistemáticamente hacia las prioridades del constructor:

• Que los sistemas funcionen a tiempo y dentro del presupuesto.
• La calidad del sistema.

Y el valor que aporta a la empresa ocupan un lugar muy secundario en la lista de prioridades.

Imaginemos un proyecto que va con retraso y supera el presupuesto. No es raro. Para volver al buen camino, se pueden encontrar soluciones. El equipo del proyecto ha resuelto un problema, el calendario o el costo no se han visto comprometidos y la unidad de negocio no se ha enterado. La solución será el problema de otro proyecto en el futuro.

Cuando finalice el proyecto, la unidad de negocio nunca será consciente de que se ha tomado un atajo; el activo digital funcionará y habrá celebraciones por doquier. Sin embargo, esta decisión podría comprometer el rendimiento de la aplicación que se ha construido. Puede que no inmediatamente, pero cuando el volumen de transacciones aumente, quizás dentro de unos meses o incluso años, se manifestará, quizás en tiempos de respuesta y usuarios insatisfechos.

Piénsalo como un contratista que, al construir una casa, decide ahorrar un poco de dinero y no utilizar las tuberías estándar del sector para la fontanería. Con esta solución, la ducha seguirá funcionando, al igual que la lavadora. Y lo que es más importante para el contratista, el cliente estará contento con la nueva casa. Sin embargo, surgirán problemas si el cliente quiere cambiar la lavadora, instalar un lavavajillas o tal vez construir una ampliación.

Un proyecto, por definición, es un esfuerzo temporal. Por lo tanto, cuando un proyecto tecnológico se completa y funciona, ya está hecho. La gente pasa a nuevos proyectos o nuevas empresas. El pasado se olvida.

En algún momento en el futuro, se pone en marcha un nuevo proyecto que depende de la integración con los activos digitales creados por muchos proyectos a lo largo de los años. Pero cuando los nuevos miembros del equipo del proyecto empiezan a trabajar, es un poco como una excavación arqueológica, sin saber lo que se va a encontrar hasta que empiezan. A medida que el proyecto avanza, es probable que surjan incógnitas que pueden hacerlo descarrilar.

El ejemplo más claro de amnesia informática es la documentación que describe lo que se ha construido. Reunirla sólo sirve para futuros proyectos, mientras que consume un tiempo y un dinero preciosos en el presente, por lo que con demasiada frecuencia se descuida.

Sin embargo, esta documentación será crucial si hay que modificar algo, quizá debido a un nuevo requisito de conformidad o reglamentario o a una nueva necesidad empresarial. Los equipos encargados de llevarla a cabo necesitarán todos estos conocimientos si quieren acometer esta tarea. Sin esa documentación, su trabajo será difícil y tendrán que volver a crearla. Y a menudo no pueden, al menos no tan bien como les gustaría.

Lo que observamos es que un departamento de TI orientado a proyectos, creará sistemáticamente estas deficiencias que repercutirán en futuros proyectos. Paradójicamente, centrarse en el éxito de un proyecto conduce a su fracaso en el futuro.

Dado lo mucho que se gasta en tecnología, cabría esperar que estos sistemas digitales se consideraran activos y se gestionaran como tales. En otras palabras, cabría esperar que los activos digitales se gestionaran como las centrales eléctricas, los buques de carga o cualquier otra inversión de esa magnitud.

Pero esto no es así.

La realidad es que la tecnología no tiene un valor inherente; el mero despliegue de la tecnología a tiempo y dentro del presupuesto no se convierte automáticamente en ningún valor empresarial. Se requiere mucho trabajo por parte de la unidad de negocio para obtener los beneficios esperados. Mientras que TI sigue de cerca y supervisa el costo de construcción y mantenimiento del activo, pocas organizaciones gestionan activamente la obtención de beneficios del uso de este activo.

Compárese con las aerolíneas. Las aerolíneas saben que si los aviones no vuelan, no generan ingresos, por lo que buscan maximizar su tiempo en el cielo, transportando pasajeros. Por el contrario, la mayoría de las organizaciones no gestionan activamente para garantizar que se obtengan los beneficios esperados de la tecnología. La tecnología llega y “funciona”. Pero, ¿aumenta el valor para la empresa? Rara vez se hace esa pregunta.

Individualmente, estas causas ocultas tienen un impacto significativo. Colectivamente, su impacto puede ser devastador para la consecución de los resultados empresariales previstos.

– Buscar valor, no financiamiento. El modelo de éste impulsa gran parte del comportamiento que vemos en las organizaciones. Se financia todo un proyecto y los informáticos se ponen a trabajar en él. Adoptar un enfoque de financiación más dosificado, en el que la financiación completa de una inversión no esté garantizada, sino supeditada a la demostración de los avances; reduce el riesgo, pero también significa que la continuación de un proyecto se determina evaluando la utilidad de lo que se ha entregado en un momento dado y demostrando los resultados.

Sin embargo, para demostrar los resultados relacionados con el negocio es necesario conocerlo a fondo, lo que puede verse obstaculizado por la división que existe entre el departamento de TI y el resto de la organización. Así que las organizaciones necesitan encontrar formas de eliminar la brecha entre TI y “el negocio”. Más sobre esto en un momento.

– Poseer y gestionar los sistemas digitales como activos productivos. Del mismo modo que un avión aparcado en la pista no genera ingresos, el valor de los activos tecnológicos debe gestionarse activamente. Lo que ayuda es tener clara la propiedad del activo digital. Nuestra sugerencia es que pertenezca a quien lo paga. Al fin y al cabo, será él quien obtenga los beneficios y, por lo tanto, debe ser responsable de garantizar que se consigan.

El director general de una de las empresas estudiadas ha dejado muy claro a los que buscan financiación para TI que es probable que los llame de nuevo ante el comité de inversión, en algún momento muchos años después de que un proyecto haya terminado, para demostrar que los beneficios que enumeraron en el caso de negocio para la inversión se han logrado.

Como todos los activos, llega un momento en que el activo deja de serlo y se convierte en un pasivo y un lastre para que la organización alcance sus ambiciones estratégicas. No dejan de sorprendernos las empresas que siguen utilizando aplicaciones que nunca se usan.

Eliminar los conflictos de intereses. Para lograrlo, hay tres tipos de funciones que deben disociarse:

1. Los que establecen las normas de diseño de los activos digitales, de los que los construyen y mantienen.
2. Los que comprueban el cumplimiento de la calidad de los que crean lo que se comprueba.
3. Los que gestionan los proyectos, de los que utilizan la creación del proyecto.

Hacer las TI de otra manera

La génesis del problema que tiene la mayoría de las organizaciones con las tecnologías digitales se debe a cómo se organizan actualmente para adoptarlas; están diseñadas para gestionar las TI en lugar de aportar valor a partir de ellas. Como ya he escrito antes, la respuesta es deshacerse del departamento único de TI.

Eso no significa deshacerse de las TI. Significa integrar las TI en todos los departamentos, de modo que quienes crean activos digitales colaboren realmente con quienes obtendrán valor de esos activos.

Ningún ejecutivo tiene la intención de que las TI de su organización fracasen o no rindan lo suficiente.

Sin embargo, las decisiones que toman conducen desgraciadamente a proyectos fallidos, resultados negativos e inversiones malgastadas. Estos ejecutivos, aunque ocupan puestos influyentes, simplemente no saben lo que se necesita para tener éxito con la tecnología en el mundo digital de hoy. Esencialmente, no saben lo que no saben. Están trabajando a partir de un mapa cognitivo que es fundamentalmente defectuoso, y esto conduce a una toma de decisiones errónea. A menos que se ponga remedio a esta situación, su organización seguirá obteniendo pésimos resultados de las inversiones en TI.