GovOps: DevOps y gobernanza
Este artículo fue traducido automáticamente del japonés por una IA (Claude). Puede contener errores. Leer el artículo original en japonés.
Creo que, en la gobernanza pública del futuro y en la de ciertos ámbitos, puede concebirse algo como GovOps, en lugar de DevOps.
Con la creación de la Agencia Digital, la DX de las administraciones públicas, la DX de las empresas y otros procesos, las tecnologías digitales están a punto de integrarse de lleno en la sociedad. Hay todo tipo de opiniones: unas se quedan en la mera implantación de software bajo el nombre de DX, otras hablan de la mejora de los servicios y de la UX gracias a la DX, y otras sugieren que la DX transformará a sectores enteros.
Sin embargo, personalmente creo que el núcleo de la DX es la transformación de los «mecanismos» y, más concretamente, que son importantes las «innovaciones complementarias» (Brynjolfsson y otros) como las instituciones y los sistemas. Para esto, remito a mi reciente libro «Implementar el futuro»; en esta ocasión hablaré de por qué GovOps.
Governance as Code
Hoy en día, las tecnologías digitales no solo hacen más eficientes las Ops (Operations), sino que están cambiando la propia Dev (Development) de las leyes y las normas.
Como señalan la innovación en gobernanza y la gobernanza ágil, entre otros, la tecnología digital no solo agiliza la aplicación de las normas, sino que puede cambiar la forma misma de elaborarlas.
Por ejemplo, si el Estado pasara a gestionar la plataforma de drones, podría cambiar en tiempo real las zonas en las que se permite volar. Como resultado, quizá ya no sería necesario que la ley fijara con todo detalle las zonas restringidas. Además, si las inspecciones que hasta ahora hacían las personas en fábricas, ascensores y otras instalaciones pudieran sustituirse por una monitorización en tiempo real con sensores, tal vez se podría alargar un poco el intervalo de las inspecciones periódicas realizadas por personas. Unas inspecciones que hasta ahora eran anuales podrían pasar a hacerse cada tres años, más o menos. Un ejemplo reciente es el eKYC, con el que la tecnología digital ha hecho posible una verificación de identidad distinta de la de antes. Son ejemplos en los que la tecnología digital cambió la forma de operar y, como consecuencia, también cambió la forma de elaborar las normas.
Las operaciones se hacen más eficientes gracias al código, y cambia incluso la forma de crearlas desde el principio. Esto se parece a la corriente de Infrastructure as Code / Operations as Code que surgió hace unos diez años en el mundo de las TI. Consiste en que al definirse y operarse la infraestructura y las operaciones mediante código, la infraestructura se vuelve programable y, con ello, cambia también la manera de hacer Dev.
Si trasladamos esto al contexto de la gobernanza, ¿no podría pensarse que están surgiendo Governance as Code o Governance by Code?
GovOps
En el mundo de las TI, en paralelo a la corriente de Infrastructure as Code / Operations as Code, y en influencia mutua con ella, se produjo la reintegración de Dev y Ops. Eso es DevOps. Si lo consideramos en el contexto de la gobernanza, quizá exista algo como GovOps.
Si el «producto» de los burócratas es, en cierto modo, la «ley», el objetivo de desplegarla con rapidez y, al mismo tiempo, operarla de manera estable se parece al de DevOps.
De hecho, el «sandbox regulatorio» (regulatory sandbox), que se menciona en la gobernanza ágil y otros textos, puede entenderse como el despliegue gradual (rollout) de DevOps. Si pensamos que los mecanismos para asegurar la agilidad probablemente se parecerán, creo que la manera de trabajar de DevOps puede servir de referencia para pensar el futuro de la gobernanza pública y de la gobernanza corporativa.
Dicho esto, imitar DevOps y fijar «diez despliegues diarios de leyes y ordenanzas» causaría demasiada confusión en la sociedad y, además, a diferencia de los sistemas de TI, las leyes suelen ser difíciles de «revertir», por lo que creo que conviene evitar copiarlo tal cual. Sin embargo, si mediante la tecnología digital se optimizara el flujo de trabajo desde la aprobación del proyecto de ley hasta su aplicación y los servicios, y se pudiera aumentar el número de proyectos de ley que pueden proponerse al año (y se pudiera deliberarlos en el Parlamento con gran transparencia y eficiencia), tal vez sería posible una gobernanza muy ágil ante los cambios de la sociedad.
Al mismo tiempo, se vuelve más claro el lugar que ocupan las distintas medidas relativas a la DX del trabajo de los burócratas, como «introducir IA para revisar los proyectos de ley existentes con vistas al número de despliegues de leyes».
GRE
Con una mentalidad similar a la de SRE (site reliability engineer), también puede pensarse una analogía como GRE (governance reliability engineer).
De la mentalidad SRE, lo aprovechable serían el presupuesto de errores (error budget) y el toil. El presupuesto de errores es un mecanismo que fija de antemano el margen de error admisible y permite asumir riesgos dentro de él para intentar cosas nuevas con cautela. El toil, por su parte, se refiere al trabajo manual frecuente que puede automatizarse.
En SRE, el presupuesto de errores suele basarse en el uptime. En el caso de las administraciones públicas, habría que definir KPI adecuados y, por supuesto, hay ámbitos en los que los errores no son tolerables, de modo que no puede aplicarse a todo. Pero, como idea para crear un margen que permita nuevos desafíos, ¿no podría aplicarse en algunos casos?
También sería una opción fijar una cifra anual de reducción de toil. El toil es, por así decirlo, «el esfuerzo que no tendrían que hacer las personas». Parece que en el trabajo administrativo abunda el toil, así que, al reducirlo, se podría dedicar tiempo a lo que realmente importa, como el servicio a los ciudadanos y las consultas con ellos. Supongo que esta mejora de la eficiencia ya se hacía de antes, pero creo que ponerle el nombre de toil facilita un poco las cosas.
Hacia GovOps
Al pensar así en GovOps, creo que las ideas cultivadas hasta ahora en el entorno de DevOps podrían ser aprovechables, hasta cierto punto, también en la gobernanza.
Por ejemplo, se repite a menudo que DevOps es cultura, práctica y herramientas, y la digitalización de la gobernanza no debería quedarse en una simple cuestión de herramientas.
Además, para mejorar GovOps también se podría pensar, por ejemplo, a partir de los siguientes «tres principios» de DevOps.
- Principio del flujo: acelerar el flujo de trabajo
- Principio de la retroalimentación: hacer realidad el flujo de retroalimentación
- Principio del aprendizaje y la experimentación continuos: generar una cultura de empresa
Si lo aplicamos a la gobernanza existente (por ahora, la gobernanza pública), se trataría de ordenar los flujos de trabajo con el mapeo del flujo de valor (value stream mapping) y otras técnicas, y acelerar con tecnología digital los flujos de trabajo de las tareas existentes; de lograr el flujo de retroalimentación con sensores, Decidim y similares; de aprender y experimentar de forma continua; y así sucesivamente.
Conclusión
Todavía hay partes de las que yo mismo no estoy seguro, pero como se había publicado el informe sobre la gobernanza ágil, pensé que, si hablamos de ágil, hablamos de DevOps, y lo escribí en esa línea. De hecho, en el informe sobre gobernanza ágil aparece la siguiente figura, que me parece que guarda similitud con la figura de DevOps (GovOps) del principio.
En las diapositivas sobre xOps que escribí hace tiempo, también incluí GovOps.
Sé que una analogía tan burda difícilmente funcionará tan bien, pero aun así creo que la mentalidad de DevOps es un concepto que puede servir de referencia en los debates futuros sobre gobierno digital y en la DX de cada empresa.
xOps: el día en que los ingenieros serán el motor del crecimiento de las startups from Takaaki Umada