Un debate relativamente habitual en el tema de la Transformación Digital y la eAdministración es el papel que juega la tecnología. Es fácil encontrar afirmaciones un poco extremas (al menos para mi gusto) del tipo «no es sobre tecnología, sino sobre personas» o «más que tecnología, son procesos«. Digo extremas, porque, siendo cierto que la TD es mucho más que tecnología, el elemento tecnológico está ahí. En todo caso, estos posicionamientos, más o menos comunes, nos llevan a un dilema importante, al menos en el área de la ciencia política, y es el perfil de las personas que ejercen el liderazgo de la Transformación Digital. Es decir, según entendamos la importancia del plano digital en estos procesos, iremos de requerir perfiles muy técnicos (como el de la SGAD) a perfiles mucho más organizativos o normativos que encontramos a nivel autonómico o local.
En resumidas cuentas, más que formación, estamos hablando de perfiles y necesidades, y de alguna manera tenemos que preguntarnos ¿qué conocimientos tecnológicos deben tener las personas responsables de TD en las organizaciones públicas?
El mix del liderazgo de la Transformación Digital
En primer lugar hay que decir que el liderazgo de la TD es un mix de competencias derivado de las condiciones de la organización en la que se trabaja. En el caso del sector público, es necesario tener conocimientos de, al menos 3 componentes (o 4 y medio)
- Conocimientos normativos: en el caso del sector público en países de derecho público como España, es necesario conocer la normativa administrativa con la que se trabaja, dado que establece las normas del juegos.
- Conocimientos de la organización: más allá de la normativa, el conocimiento de cómo funciona la organización, sus valores, estructuras, principios y roles definen el escenario de juego.
- La tecnología: si antes teníamos las reglas y el campo, la tecnología nos marca las posibles decisiones a emprender. Saber qué elementos podemos usar para qué para hacer «el juego» de la TD
Vale, había dicho al menos tres, pero hasta 4 competencias y media, porque a estas tenemos que sumar:
- El «negocio». Utilizo este término porque es el que se usa en desarrollo a las normas, principios objetivos a los que debe servir la organización. No la cuento del todo, porque en muchos casos, el negocio en el sector público no está bien definido. Esto sucede cuando hablamos de elementos de gestión interna o de staff. El negocio es necesario, pero en muchos casos hablamos de negocio interno no del todo definido.
- Competencias «blandas«. Esta es la «media». No son competencias técnicas específicas, pero las competencias blandas, que son más un modo de actuar que una técnica concreta, facilita la gestión de la relación con las personas y la organización.
En todo caso, como suele pasar en otros ámbitos, el liderazgo en la TD es el mix de estos elementos. La manera en la que se mezclan estas competencias y habilidades generan modelos de liderazgo muy diferente.
Lo que se tiene que saber de tecnología ejercer el liderazgo de la Transformación Digital en una Administración Pública
De estas 4,5 competencias que tenemos, la tecnología es quizá laque genera más polémica en ciertos círculos. Esto se debe a que entendemos que un responsable de una Administración sabe de derecho y conoce su organización. Por otro lado, muchas organizaciones no disponen de personal TIC para dar este salto. En otros casos, se decide priorizar las cuestiones técnias.
Las competencias blandas, lamentablemente, no se consideran imprescindible y el negocio, en muchos casos, no se define. Dentro de esto ¿qué debería saber una persona de tecnología para llevar la TD en una organización pública? Diría que, al menos, estas cosas:
- Cuáles son las principales tecnologías disponibles para una administración. Esto no es un simple listado de qué hay, sino el nivel de madurez que tienen y qué casos de uso se desarrollan en torno a ellas.
- Fundamentos básicos de informática. No es que tengas que saber de código o de lenguajes de programación, pero aspectos de como funciona la computación (qué hace un programa, cómo funciona, qué necesita para funcionar, qué puede o no puede hacer).
- Funcionamiento general de las tecnologías más frecuentes. Igual que antes: no necesitas saber cómo funciona el código que hace posible el blockchain, pero si deberías saber cómo funciona en líneas generales para encontrar aplicaciones y posibles limitaciones.
- «informatiqués básico»: gestionar equipos es muy difícil si hay posibilidades de perderse en la traducción y, perderse en la traducción informátiqués-funcionariano es algo muy posible. Aún recuerdo un debate en un proyecto acerca de la diferencia entre una plantilla y un esquema. Si te manejas con los dos idiomas, te ahorras muchos problemas y tiempo.
- Gestión de proyectos y de desarrollo. Un último punto es la gestión de proyectos y de desarrollo es algo importante. El desarrollo de software y los proyectos digitales no es como construir casas: tiene sus reglas, ventajas, limitaciones y necesidades. Si no se tienen en cuenta, es posible que haya desajustes mayores en la vida del proyecto y en su resultado.
Pero ¿realmente es necesario conocer estas cosas?
La verdad es que creo que, a niveles básicos y más bien intuitivos, si. En caso de no conocerlo, nos encontraríamos con los posibles siguientes problemas:
- Perder oportunidades de innovación: la aparición de nuevas tecnologías o nuevas aplicaciones son oportunidades para activar el cambio. No estar al día es perder oportunidades.
- Tener expectativas desajustadas de la tecnología: si no sabes las reglas más comunes de la informática puedes esperarte resultados muy superiores a lo que de verdad da de sí el cacharro. Lo malo es cuando te enteras al final de la película, como en las de Shyamalan.
- Comprar humo. Si el apartado anterior tiene unas condiciones más o menos fijas, las tecnologías más nuevas pueden venderse como solución a problemas tradicionales de la informática. Aunque esto es muchas veces así, otras veces es fácil vender gato por liebre y, si no se distingue, te quedas el gato entero.
- Pérdidas en la traducción: más de uno y más de dos proyectos que conozco se han ido al garete cuando se ha descubierto que el concepto «expediente» no era lo mismo en un workflow que en un procedimiento administrativo… o que una reserva de plaza no significaba que esa plaza se estimara como «no disponible» (historias reales)…esto son cosas que se pueden anticipar si entiendes como habla el equipo técnico de proyecto
- Entropía en el proyectos: no saber que un desarrollo requiere pruebas, o documentación, o cuándo y cómo seguir los entregables, provoca retrasos o problemas de arranque o de gestión del cambio.
Estos son los problemas que veo más a menudo en estos temas.
Entonces ¿puedo dirigir la TD de mi organización sin saberlo?
Si os digo la verdad, conozco perfiles de todos los tipos. Entre estos conozco perfiles muy técnicos que tienen problemas para gestionar otras áreas y perfiles nada técnicos que hacen muy bien este trabajo. ¿Cuál es el secreto? Pues que la mayoría de lo que he dicho no es algo que requiera tanto «profesionalización» como oficio. Es decir, estas personas al principio no tenían un conocimiento técnico no muy alto, pero han ido aprendiendo con mucha atención, respeto e interés.
Y es que creo que las dos competencias técnicas más importantes para dirigir la TD en una organización pública son dos cosas:
- Saber lo que no sabes. Hace poco leía un extraordinario artículo de Amalio Rey sobre los problemas del perfeccionismo en los proyectos y me vi muy identificado. Reflexionando, me di cuenta de que los proyectos en los que he acabado más contento (y creo que también mis clientes) son aquellos en los que me sentía más inseguro y tenía que buscar, escuchar y preguntar más. Luego extrapolé un poco eso a casos que conozco de TD en AAPP y creo que lo que hace que estas personas que han llevado equipos de digitalización sin conocimientos técnicos previos pero con éxito es que no han tenido nunca problemas en preguntar, repreguntar, y requetepreguntar hasta entender todo lo que necesitaba para tomar decisiones.
- Tener capacidad de aprender. Una cosa es escuchar y otra cosa es guardarlo en buen saco. En este caso, la capacidad de integrar lo que aprendes sobre las competencias anteriores con los aspectos de negocio, normativa y organización, es la que acaba generando grandes modelos de TD. El problema está en que hay gente que, incluso teniendo claro lo que le han contado, no acaba de conectarlo con todo lo demás.
Esto entra muy en la línea de estas tendencias en la gestión y selección de personas de buscar mucho más actitudes que competencias.
No es como se empieza, es como se termina
A fin de cuentas, como comentaba, en el tiempo que llevo dedicándome a estas cuestiones, he encontrado perfiles de todo tipo. Lo cierto es que en muchos casos las organizaciones públicas no disponen de perfiles técnicos para soltarles la TD, y acaban cayendo en áreas de lo más diverso. En otras ocasiones es más la vocación de cambio organizativo la que llevan a perfiles más «funcionales» que técnicos. El caso es que, como decía, más de una y más de dos personas que conozco y respeto han llevado y llevan proyectos muy serios sin saber lo que es un webservice y el mundo no se ha hundido. Simplemente han ido aprendiendo con el tiempo, y generando una manera de liderar que funciona con bastante solvencia.
En otros casos, estas carencias se han suplido temporal o indefinidamente con trabajos de consultoría (algunos los he hecho yo otras veces otra gente), especialmente útiles para situaciones muy iniciales, procesos complejos, o transiciones muy breves que no prevén cambios sustanciales una vez realizado un cambio tecnológico (por ejemplo, la introducción de un gestor de expedientes que va a digitalizar toda la tramitación y no se esperan hacer más cambios).
Muchas personas se encuentran con una circunstancia «desafiante» como liderar algo con lo que no son del todo familiares. Es la capacidad de aprendizaje y adaptación es la que permite hacerlo con garantías.
