Por Alejandro Bianchi, Presidente de Liveware

Todos los días leemos y/o intercambiamos ideas sobre la impronta de las empresas de transicionar hacia lo digital ofreciendo nuevos productos y servicios en base a una nueva propuesta de valor soportada por tecnología digital.  También es obvio que no es lo mismo una empresa que nace digital que una tradicional, la segunda corre esta maratón con muchas desventajas que trataremos de clarificar en este artículo.

Una cosa es clara, todas las compañías compiten por liderar la transformación digital y presionan por obtener soluciones cada vez más innovadoras y en menos tiempo. Esta realidad fuerza a los equipos de tecnología a tomar “el camino corto” en lo que hace a decisiones de diseño arquitectural y también en la manera de producir y entregar soluciones. Esta modalidad de trabajo produce un silencioso e invisible costo acumulado conocido con la metáfora de Deuda Técnica. Deuda técnica es el costo que una organización y/o equipo de trabajo deberá pagar como consecuencia de tomar decisiones técnicas para soluciones de corto plazo pero que en el largo implicaran costos de retrabajo y mala calidad.

La deuda técnica no necesariamente es mala si se es consciente de la decisión que se está tomando y del costo que se asumirá, pero sobre todo que se cuenta con capacidad para gestionarla adecuadamente. Hay deuda técnica de requerimientos, de arquitectura, código, testing y también del proceso. Deuda técnica se toma en cualquier ciclo de desarrollo tanto sea tradicional o ágil, aunque en estos últimos la deuda técnica puede ser un asesino serial de proyectos, pero eso lo dejaremos para otro momento.

Las organizaciones tradicionales que acumulan años de llevar sus negocios con aplicaciones legadas, con diseños inmantenibles y con código poco documentado viven aplicando modificaciones que en la mayoría de los casos generan deuda técnica que se traduce en serios problemas de deployment de aplicaciones, calidad y satisfacción del cliente. En este escenario cuando se intenta instalar una plataforma digital, la empresa enfrenta serios problemas para integrarla a la maraña de aplicaciones legadas, datos duplicados y cientos de interfaces que comunican de manera poco eficiente cientos de sistemas. El costo de toda esta deuda técnica es la lentitud con que se ejecuta el proceso de transformación. Se suele decir, que las empresas tradicionales no entienden lo que significa ir hacia lo digital y mucho menos mejorar la experiencia de sus clientes. Personalmente, no creo que sea tan así, sino que el contexto de estas compañías es un inhibidor que impide una dinámica acorde a las demandas del negocio y del mercado.

Este es un problema reconocido a todos los niveles directivos de una empresa, no solo es preocupación del CIO. Una encuesta de Accenture, difundida por el SLOAN Institute durante 2018, dice que el 70 % de los Niveles C reconocen que la deuda técnica es un impedimento importante para acelerar innovaciones en IT; un 72% reconoce que limita las posibilidades de migrar a nueva tecnología y un 69% siente que la deuda técnica impide el alineamiento entre IT y  las necesidades del negocio. También es interesante ver que el 67% de los ejecutivos ven con buenos ojos el reemplazo de sus sistemas legados; pero un 70%  los quiere mantener tanto tiempo como sea posible, (algo así como más vale malo conocido que bueno por conocer) y hay un 50% que considera que pueden aprovechar lo mejor de los dos mundos. En otras palabras, lo que los líderes realmente quieren es poder disfrutar de todos los beneficios de las nuevas tecnologías de la información, adaptarse rápidamente a las nuevas situaciones y al mismo tiempo mantener el funcionamiento de sus sistemas heredados.

Afortunadamente, hay una manera para que las empresas tradicionales tengan lo mejor de ambos mundos, y creen una arquitectura de TI escalable, flexible y resistente. A esta solución la podríamos llamar  “desacoplamiento digital”.

Si lo leído hasta aquí le resulta interesante, entonces lo que sigue le ayudará a llevar adelante estas ideas de desacoplamiento. Ahora, piense en sus sistemas heredados y si bien no quiere que interfieran con la implementación de la nueva tecnología digital, tampoco desea que dejen de funcionar porque el core de su negocio depende de ellos. ¿Entonces qué hacemos? No es una tarea fácil, porque su organización no es Netflix, Uber, Amazon ni otro gran número de empresas que nacieron digitales y que no tuvieron que lidiar con esta problemática. No obstante, a no desesperar,  hay algunas buenas prácticas que pueden ayudar:

  1. El negocio debe definir cuál es la nueva propuesta de valor que justifica la Transformación Digital del negocio. ¿Qué nuevos productos y servicios queremos ofrecer? , ¿Cómo hacemos frente a la nueva competencia?, ¿Cuáles son los valores que queremos potenciar a través de la tecnología digital?
  2. Evalúe y entienda su arquitectura actual. Si no comprende donde está, nunca podrá encontrar el mejor camino para llegar a su destino.
  3. Modele su arquitectura futura en función de la nueva visión del negocio e identifique los componentes críticos que debería desacoplar y un modelo de referencia para la integración de los nuevos componentes.
  4. Diseñe una hoja de ruta para implantar su nueva arquitectura. Piense en el largo plazo, pero actúe en el corto. Considere esfuerzo de desarrollo, gestión de los proyectos, migración de datos y proveedores con quienes crear una relación sólida de trabajo y confianza. Ningún proyecto de Transformación digital en una organización tradicional llevará menos de cinco años, pero puede sacar ventajas a partir de ciclos cortos en donde se implementen soluciones digitales que vayan mejorando la experiencia de los clientes, al mismo tiempo que sus equipos de trabajo van adquiriendo las capacidades y competencias digitales.
  5. Desacople los datos maestros de los sistemas legados. Este es un punto crítico, no hay transformación digital si no disponemos de una “única versión de la verdad”. En este sentido diseñe “data lakes” con robustos procesos de gobierno y gestión de datos de manera de crear una sólida capacidad de Analytics.
  6. Desacople las aplicaciones de la infraestructura legada, en otras palabras “muévase” a la nube. Esto le permitirá escalar a bajo costo y pagar por lo que realmente consume de procesamiento y le facilitará la integración con su plataforma digital.
  7. Desacople un equipo de trabajo para crear una “Digital Factory”. Conforme la misma con gente de negocio de manera de crear un ambiente multidisciplinario para generar experiencias relevantes, que dejen sólidos aprendizajes que se vuelquen al desarrollo de los componentes digitales. Adopte ciclos de vida ágiles con destino final en DevOps. Y adicionalmente, un equipo multidisciplinario facilitará el cambio cultural que deberá enfrentar la organización. Por último, defina un mecanismo que permita que el resto de la organización de IT también pueda participar en algunas actividades en esta “Fábrica Digital”, de esta manera evitará frustraciones y/o falta de motivación.

Nada de esto es fácil de ejecutar y como bien dice un viejo conocido, “hay que meterse en el barro” para que la Transformación funcione, pero si se entiende el concepto que hemos tratado de explicar en este artículo, el esfuerzo seguramente será mejor aprovechado y no caerá en el engaño de soluciones mágicas. Este tipo de desafíos se resuelven con gestión, sólida ingeniería y equipos de trabajo bien integrados y motivados.

One thought on “Un riesgo oculto en la Transformación Digital: La Deuda Técnica

  1. Coincido plenamente Alejandro!
    Una condición no menor para emprender una verdadera transformación digital es que la organización toda y especialmente la dirección entienda que se trata de una transformación en la forma de operar.
    No se trata de renovar la tecnología para seguir operando de la misma manera. Sino, por el contrario, apalancar en la tecnología para cambiar la operación e integrarse a un mundo digital.
    Por otra parte, dado que como dices un programa ambicioso requiere de varios años, recomiendo desacoplar la transformación del Front End de la del Back End. Operando en ágil en el Front End, acelerando aquí la transformación y anticipando la entrega de valor, mientras se transforma el Back End mediante estrategia basada en releases.
    Existe tecnología disponible actualmente para poder realizarlo.

    Saludos,
    Horacio Goldenberg

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *