Hacer que los procesos de una organización estén digitalizados es tan complejo como urgente. Un error frecuente es creer en la necesidad de una reingeniería previa o un análisis exhaustivo de los requerimientos de los usuarios. Ambas tareas han demostrado ser fuente de atrasos y de gastos excesivos que atentan directamente contra los resultados.
Además de la consabida parálisis por análisis, esas actividades consumen una tremenda cantidad de energía y esfuerzo, y terminan siendo un desperdicio porque si alguna vez se llega el final del proyecto será obsoleto: las necesidades habrán cambiado o el proceso ha sido modificado.
Para evitar esta conocida tragedia de digitalización, se inventaron las metodologías ágiles, en las cuales los usuarios trabajan junto con los técnicos para poner en operación sistemas con mínimas adaptaciones en el menor tiempo posible. Se parte siempre de un “mínimo producto viable” (MVP, por sus siglas en inglés), es decir, una digitalización pequeña de una parte importante del proceso.
Se pone en producción y se consideran los comentarios y requerimientos de los usuarios antes de una nueva, y muy pronta, iteración. De esta manera, con iteraciones frecuentes se va, poco a poco, produciendo la transformación.
El problema de las metodologías ágiles es no contar con un presupuesto “firme e invariable” antes de iniciar el plan, ni con un cronograma detallado donde se indique cuándo terminará el proyecto. Esto hacía, tres o cuatro años atrás, muy difícil a los jerarcas aprobar nuevas propuestas. Pero la experiencia ha demostrado que esas metodologías producen resultados mucho más rápido y baratos que las tradicionales, tipo cascada: primero se definían los requerimientos, luego se diseñaba todo el sistema, después se desarrollaba, se probaba y, con suerte, al final se ponía en producción.
Interacción. La clave, claro está, es la interacción continua y profunda entre los usuarios y los técnicos. Al estar haciendo entregas frecuentes, los usuarios empiezan a utilizar el proceso digitalizado muy pronto, tienden a pedir menos funciones. Antes se pedían algunas funciones “porque tal vez harían falta”.
También se les van haciendo a los procesos pequeñas modificaciones cuya necesidad se vuelve obvia. Nunca se efectúan reingenierías masivas que cambian todo antes de digitalizarlo. El riesgo de digitalizar procesos ineficientes desaparece, pues la puesta en funcionamiento de nuevas funciones de manera constante y frecuente permite modificaciones a los procesos casi en una modalidad de prueba y error. Es muy fácil hacer modificaciones pequeñas.
Estas metodologías ágiles han hecho posible la transformación digital acelerada y exitosa. La necesidad de hacer el cambio muy rápido es dada por la velocidad con la cual está cambiando el mundo a partir de las tecnologías disponibles. Una organización funcionando hoy con procesos de papel está destinada al fracaso porque no solo son muy caros y propensos a errores, sino también porque promueven la opacidad y, por ende, la corrupción.
Para el sector público puede ser un poco más complicado utilizar estas metodologías. Si bien no es cierto que la Ley de Contratación Administrativa sea un obstáculo, es verdad que requieren más pasos de manera más inmediata.
En el sector productivo, hace años existe la consciencia de que para digitalizar procesos no son necesarios ni equipos ni programas, sino servicios. En el sector público, a pesar de que hace como seis años se publicaron un decreto y una directriz para que todos se movieran a la nube, no lo han hecho. Todavía hoy siguen adquiriendo equipos y licencias (ya hasta construyen centros de datos para albergar esos equipos). El primer paso que hay que dar es entender las bondades de adquirir servicios.
Al comprar servicios en lugar de “cosas” es posible determinar, contractualmente, la calidad del servicio. Cuando la calidad de un servicio es parte de un contrato, con consecuencias financieras por incumplimiento, la entrega del servicio se vuelve muy predecible en calidad y oportunidad.
Contratar. En lugar de contratar una empresa para que desarrolle un sistema de acuerdo con una larga lista de requerimientos, es posible contratar el servicio y la operación de uno con mandatos muy vagos, como por ejemplo: “Digitalizar el proceso XYZ, siguiendo una metodología ágil”.
La elaboración de un cartel para la contratación de servicios es muy diferente, se parece más a un concurso de antecedentes. Debe solicitarse experiencia, tanto en la adaptación e implementación de soluciones similares, como en la operación del sistema en producción. Hay que definir la calidad del servicio (SLA, por sus siglas en inglés) tanto en términos cuantitativos (disponibilidad, velocidad, capacidad, etc.) como en términos cualitativos (satisfacción del usuario interno y externo, o ideas innovadoras, etc.). La forma de pago puede ser por hora profesional durante la implementación y por transacción durante la operación (estoy seguro de que existen muchas otras, todas innovadoras).
Se debe definir el plazo de la contratación, sobre todo para la operación del servicio, y asegurarse de que la infraestructura (nube) por utilizar y las licencias necesarias puedan ser traspasadas a otro operador al finalizar el plazo (o en cualquier momento si se incumplen los SLA).
LEA MÁS: ¿Por qué tantos peros a la firma digital?
No pretendo, en ningún momento, insinuar que la contratación de soluciones como servicio, utilizando metodologías ágiles, sea la pomada canaria de la digitalización. Sin duda el proceso requerirá de un enfoque innovador y aparecerán piedras en el camino que pretenderán descarrilar el proceso y habrá infinidad de problemas. Pero en el país existe suficiente experiencia, así como empresas dispuestas a invertir, a cambio de un contrato que genere ingresos durante un período adecuado (¿5 años?). Eso permitirá acelerar la transformación digital del sector público, cuyo rezago pagamos todos diariamente.
También estoy claro en que el método tradicional no sirve; es demasiado lento, caro y produce resultados equivocados. Cuanto más grande el proyecto, mayor la posibilidad de fracaso. De hecho, la probabilidad de fracaso crece más que proporcionalmente al tamaño del proyecto. No podemos seguir haciendo lo mismo y esperar resultados diferentes.
El autor es ingeniero, presidente del Club de Investigación Tecnológica y organizador del TEDxPuraVida.