El problema de la concesión de permisos en las operaciones sobre el terreno

Cualquier proyecto de infraestructura, por complejo que sea, requiere permisos. Un permiso de construcción del ayuntamiento, un permiso de excavación de la empresa de servicios públicos, una autorización medioambiental, un permiso de ocupación de la vía pública; a veces, los cuatro para un mismo tramo de carretera. El permiso no es opcional: legalmente, las obras no pueden comenzar hasta que se disponga del permiso, y el inspector que acuda posteriormente querrá ver la documentación que lo acredite.

El problema no es el permiso en sí mismo. El problema es el lugar que ocupa en tu flujo de trabajo. En la mayoría de las organizaciones, la respuesta es: en cualquier otro sitio. Una hoja de cálculo que alguien actualiza semanalmente. Una carpeta en una unidad compartida que nadie encuentra cuando el inspector la pide. Una solicitud de permiso independiente que el equipo de campo no utiliza porque no es donde realizan su trabajo real. El permiso se convierte en un proceso secundario que discurre en paralelo al trabajo real, vinculado a este únicamente por la memoria y las buenas intenciones.

Así es como se pierden los permisos, caducan sin que nadie se dé cuenta o llegan cuando las obras ya han comenzado. No porque alguien haya sido negligente, sino porque el permiso se gestionaba en un sistema distinto al de las obras a las que debía dar acceso.

Cuándo fallan los flujos de trabajo paralelos

La respuesta habitual a este problema suele adoptar una de estas tres formas.

Una hoja de cálculo o un documento compartido. Alguien lleva un registro de permisos: una fila por permiso, con columnas para el estado, la fecha de caducidad y la persona responsable. Esto funciona para un proyecto pequeño. Deja de funcionar en el momento en que más de una persona necesita actualizarlo, en el momento en que los permisos abarcan varios proyectos o en el momento en que alguien solicita un historial fiable de quién cambió qué y cuándo. Las hojas de cálculo no tienen registros de auditoría. No envían notificaciones cuando se acerca una fecha. No impiden que alguien borre accidentalmente una fila.

Una aplicación específica para la gestión de permisos. Un software diseñado expresamente para realizar un seguimiento de las solicitudes de permisos, las aprobaciones, las condiciones y las fechas de caducidad. Estas aplicaciones existen y resuelven el problema del seguimiento. Lo que no resuelven es el problema de la integración. El permiso se gestiona en un sistema. La orden de trabajo, en otro. El equipo de campo utiliza un tercero. Ahora hay tres lugares que revisar, tres elementos que mantener sincronizados y un vacío entre ellos donde se producen errores. ¿Alguien ha comenzado a trabajar antes de que se concediera el permiso? El sistema de permisos no lo sabe, porque no puede ver el estado de la orden de trabajo. ¿Ha caducado el permiso mientras se realizaban los trabajos? El sistema de gestión de trabajos no lo sabe, porque no puede ver el estado del permiso.

Confirmación por correo electrónico y verbal. Alguien envía un correo electrónico al jefe de equipo para comunicarle que se ha concedido el permiso. El jefe de equipo se lo comunica al equipo. Nadie anota la fecha y la hora. Cuando el inspector solicita la documentación, el director del proyecto busca en su bandeja de entrada. Esto no es un sistema. Es la ausencia de uno.

Cada uno de estos enfoques genera la misma deficiencia estructural: el permiso y el trabajo al que se refiere se encuentran en lugares distintos, son gestionados por personas diferentes y no existe ningún vínculo automático entre ambos. En cuanto cambia uno de ellos, el otro queda desactualizado hasta que alguien se acuerda de actualizarlo.

Permisos como tareas

Nuestro enfoque es sencillo: un permiso es una tarea. Se planifica como parte de una tarea, se supervisa como una orden de trabajo, se documenta mediante informes y se valida siguiendo la misma cadena de control de calidad que cualquier otro trabajo de campo.

Una tarea representa una unidad de trabajo planificada —«Instalar fibra óptica en la calle Oak»—. Dentro de esa tarea, puede haber tres órdenes de trabajo: una para obtener el permiso de obra, otra para la instalación física y otra para la inspección posterior a la instalación. La orden de trabajo relativa al permiso figura junto a la orden de trabajo de construcción dentro de la misma tarea, es visible en la misma vista del proyecto y se supervisa mediante el mismo sistema de seguimiento del progreso.

La orden de trabajo del permiso incluye sus propios metadatos en forma de propiedades estructuradas: número de permiso, autoridad emisora, fecha de caducidad, condiciones y referencia de la solicitud. Estos datos no se ocultan en un campo de descripción, sino que son campos en los que se pueden realizar búsquedas y aplicar filtros en la orden de trabajo, y que están disponibles en las exportaciones y los informes.

El permiso tiene una fecha de vencimiento y notificaciones. Cuando se acerca la fecha de vencimiento, el sistema envía las mismas notificaciones que envía para cualquier otra fecha de vencimiento: resúmenes por lotes, insignias en la aplicación y actualizaciones del calendario. No es necesario configurar ningún sistema de alertas independiente.

El permiso sigue el mismo proceso de validación. Una vez obtenido el permiso, se envía un informe con el documento del permiso adjunto. Un validador comprueba que se trata del permiso correcto, para la ubicación adecuada y con las fechas correspondientes. Si el permiso incluye condiciones, el validador las registra como observaciones. El estado de la validación —aprobado, rechazado, necesita revisión— determina si las órdenes de trabajo posteriores pueden seguir adelante.

El estado del permiso se puede ver en el resumen del proyecto. Cuando un jefe de proyecto consulta la tarea, ve que la orden de trabajo del permiso aparece como «completada» o «pendiente» junto a las órdenes de trabajo de construcción. No es necesario consultar un sistema independiente. Si el permiso no está listo, la tarea no está lista, y eso lo puede ver todo el mundo de un solo vistazo.

¿Y los sistemas municipales?

Una pregunta sincera que surge en todas las conversaciones sobre la concesión de permisos: ¿debería el software integrarse directamente con los portales municipales de concesión de permisos?

Lo hemos analizado detenidamente y hemos decidido no desarrollarlo. La razón es sencilla: no existe un estándar. Cada ayuntamiento gestiona un portal diferente: formularios distintos, flujos de trabajo distintos y API distintas, si es que cuentan con ellas. Muchos siguen trabajando en papel. Desarrollar una integración con un solo ayuntamiento beneficia a los usuarios de ese ayuntamiento y a nadie más. Crear una «integración de permisos» genérica que pretenda funcionar en todas partes es una promesa que no se puede cumplir.

Lo que ocurre en la práctica es que una persona inicia sesión en el portal municipal, comprueba el estado del permiso e introduce las fechas y los números de referencia pertinentes en la orden de trabajo. La función del sistema en ese momento es hacer un seguimiento de la fecha, notificar cuando se acerca y generar un registro de auditoría fiable para cuando alguien lo solicite más adelante. Eso no es una laguna. Es un reconocimiento realista de dónde se encuentra la frontera entre su sistema interno y los procesos administrativos externos.

El registro de auditoría que realmente quieren los inspectores

Cuando un inspector de la autoridad reguladora o un auditor externo pregunta por los permisos, en realidad está planteando tres cuestiones: ¿Tenías el permiso antes de comenzar las obras? ¿Era válido el permiso para la ubicación y el alcance de las obras? ¿Puedes demostrarlo?

Cuando la licencia forma parte de una orden de trabajo dentro del mismo sistema que la obra de construcción, las respuestas son estructurales y no se elaboran a posteriori:

La orden de trabajo de la licencia cuenta con una cronología inmutable —fecha de creación, fecha de finalización, fecha de validación— que puede compararse con la fecha de inicio de la orden de trabajo de construcción. Si las obras comenzaron antes de que se validara la licencia, las fechas lo reflejan.
El informe de la licencia incluye el documento de la licencia adjunto, la confirmación del validador y cualquier condición registrada como constatación. El informe pasa a ser de solo lectura tras la validación, por lo que las pruebas no pueden modificarse.
Las transacciones de inventario en las órdenes de trabajo de construcción llevan marca de tiempo y son inmutables. Si los materiales se recogieron antes de que se autorizara el permiso, las marcas de tiempo de la transacción de recogida QR lo indican.
Todo es exportable —CSV, PDF, registro de auditoría— desde un único sistema, en una sola consulta. No hay referencias cruzadas entre bases de datos separadas.

Al inspector no le importa qué módulo haya generado la documentación. Lo que le importa es que sea coherente, que lleve una marca de tiempo y que sea a prueba de manipulaciones. Cuando el permiso y la obra comparten un mismo sistema, esa coherencia se da de forma automática. Cuando se encuentran en sistemas distintos, hay que crearla artificialmente.

Resumen

La obtención de permisos es un requisito universal en los trabajos de infraestructura sobre el terreno, y el error más habitual no es carecer de un permiso, sino llevar un seguimiento del mismo en un sistema desconectado de las obras a las que se refiere.
Las hojas de cálculo, los programas específicos para la gestión de permisos y las confirmaciones por correo electrónico presentan todos la misma deficiencia estructural: el permiso y las obras se gestionan en lugares distintos, sin ningún vínculo automático entre ellos.
Tratar un permiso como una orden de trabajo en el flujo de trabajo principal significa que hereda la misma infraestructura de planificación, seguimiento, validación y registro de auditoría que cualquier otro elemento de trabajo, sin necesidad de mantener un proceso paralelo.
Los metadatos específicos del permiso —número de permiso, autoridad emisora, fecha de caducidad, condiciones— se almacenan como propiedades estructuradas en la orden de trabajo, y se pueden buscar y filtrar junto con el resto de datos de trabajo.
La integración del portal municipal de permisos es un problema que nadie ha resuelto de forma genérica, porque no existe un estándar. El flujo de trabajo realista consiste en que una persona introduzca las fechas desde el portal, y que el sistema realice el seguimiento y envíe notificaciones a partir de ahí.
El registro de auditoría que desean los inspectores —prueba de que el permiso precedió al trabajo, de que era válido para el alcance y de que la documentación es a prueba de manipulaciones— surge de forma natural cuando tanto el permiso como el trabajo comparten la misma línea temporal inmutable.
No hay que aprender a utilizar ningún módulo independiente, ni hay que mantener ningún flujo de trabajo paralelo. La gestión de permisos está integrada en el flujo principal por diseño.