Hace años que se habla de la transformación digital, y aún se busca la mejor forma de diseñar una estrategia para alcanzarla. Adelantemos la conclusión de este texto: no hay receta, o mejor dicho, hay una receta para cada caso.
Algunos de los big players en el mundo de IT (de colores muy característicos) suelen empujar la idea de que la transformación digital es guiada por la tecnología, y que la adopción de sus soluciones disparará -mágicamente- una sucesión de hechos dentro de las organizaciones que inexorablemente las convertirá en digitales. Teniendo este destino a la vuelta de la esquina, es fácil decidirse por alguno de estos productos y esperar que las personas automáticamente se organicen con una eficiencia nunca antes vista alrededor del nuevo juguete de la empresa. Luego debería venir lo inevitable: que comiencen a desplegar su talento oculto para resolver 25 años de capas geológicas de arquitectura y una cantidad desconocida -pero enorme- de deuda técnica. Todo esto en tan sólo un semestre.
La realidad es que nada de esto sucede. El flamante juguete difícilmente alcance a llevar alguna solución a producción, y termina transformándose en un nuevo componente incómodo al que nadie quiere acercarse: quién quiera innovar usándolo, sabe bien que no sólo enfrentará su propia iniciativa sino que deberá también satisfacer la enorme expectativa (a esta altura deuda de valor) puesta previamente sobre la “solución”. Por último, si lo anterior no fuera suficiente para desalentarnos, se agregan otras dificultades propias del contexto: falta de capacidad, habilidades en estadíos iniciales y plazos seguramente desafiantes.
Y es que el cambio que se espera que suceda, sólo puede ocurrir dentro del sistema compuesto por las personas, los procesos y la tecnología: por lo tanto cualquier mínima alteración, sin importar su tamaño pero que presente características transformacionales, deberá contemplar estas 3 piezas.
“Las organizaciones que diseñan un sistema producirán un diseño cuya estructura copia la estructura de comunicación de la organización” (Melvin Conway, 1967).
En primer lugar, una breve aclaración: todas las organizaciones diseñan sistemas, la organización en sí misma es un sistema.
¿Qué sucede entonces? Son las personas las que terminan gobernando, aún sin proponérselo, los patrones de diseño de sistemas en su acepción más amplia; la manera en la que la información fluye -exclusivamente- entre las personas define la forma que tomarán los procesos y finalmente la tecnología: así es que terminamos adoptando el último juguete techie para hacer exactamente lo mismo que hacíamos hace 20 años pero con lindos dashboards, y poco o nada cambia de fondo.
Pensando en estrategias de transformación y considerando la trilogía personas, procesos y tecnología y el impacto que entre ellas presentan, comenzamos a ver que el foco debe estar puesto sobre las personas y en cómo hacemos para optimizar la forma en que ellas interactúan y se relacionan, o más específicamente: se comunican.
Probablemente en esto pensaba Jeff Bezos cuándo en 2002 emitió su famoso mandato, el cuál copiamos aquí en su inglés original para mantener su esencia:
All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. Anyone who doesn’t do this will be fired.
En el fondo, estamos modificando el comportamiento de las personas, y así debemos abordarlo. Aquí también encontramos otro ejemplo: con la irrupción de la metodología Agile en la industria, nos sucedió algo similar a lo mencionado en los primeros párrafos, todo lo quisimos “agilizar”, con casos de éxito y fracasos igual de rotundos. Al igual que la tecnología, también acá vemos que no existe una única metodología que funcione eficientemente en todas las condiciones, y que la adaptación del método según el tipo de trabajo y la forma en la que las personas se comportan es imprescindible.
Thank you; have a nice day!
Si analizamos en detalle cada sentencia, todo se resume a la comunicación y a lo que los equipos (personas) deben hacer en torno a ella: explícitamente manifiesta que la tecnología no importa y no define nada acerca de los procesos entre equipos, en realidad lo que hace es desacoplarlos de forma tal que sean componibles, pero de esto hablaremos en otro momento.
claramente esto es un ejemplo extremo, pero sirve para poner nuevamente en el centro de la mesa a las grandes protagonistas de las transformaciones organizacionales: las personas. Así encontraremos muchísimos otros ejemplos de prácticas y metodologías que usamos a diario (por ejemplo: el Manifiesto Agile) cuya esencia también es la interacción entre las personas y que solemos pasar por alto: ¿qué porcentaje de personas que trabajan con Agile a diario aplican el manifiesto?
En el fondo, estamos modificando el comportamiento de las personas, y así debemos abordarlo. Aquí también encontramos otro ejemplo: con la irrupción de la metodología Agile en la industria, nos sucedió algo similar a lo mencionado en los primeros párrafos, todo lo quisimos “agilizar”, con casos de éxito y fracasos igual de rotundos. Al igual que la tecnología, también acá vemos que no existe una única metodología que funcione eficientemente en todas las condiciones, y que la adaptación del método según el tipo de trabajo y la forma en la que las personas se comportan es imprescindible.