Usuarios y permisos en un GMAO

La gestión de usuarios parece un asunto administrativo hasta el día que importa: cuando un proveedor ve precios de otro cliente, cuando un técnico modifica algo que no debía o cuando hay que demostrar quién hizo qué.

En un GMAO tiene además una particularidad: no hay un tipo de usuario, hay cuatro muy distintos —quien planifica, quien ejecuta, quien contrata el servicio y quien lo subcontrata—, y cada uno necesita ver una parte distinta del mismo sistema.

Tres interfaces, no una con permisos

La primera decisión de producto que conviene entender. En GMAO CLOUD cada rol entra por un sitio distinto:

• El backend web para quien planifica y administra.
• La app de técnicos para quien ejecuta en campo.
• El acceso de clientes para quien recibe el servicio.

No es la misma pantalla con cosas ocultas: son tres interfaces pensadas para tres necesidades que no se parecen. Un técnico no necesita una versión reducida del panel de administración; necesita otra cosa.

Perfiles y permisos

Dentro de cada interfaz, el acceso se controla por perfil: qué módulos ve cada persona y qué puede editar. Eso permite lo habitual —que administración no toque la configuración de activos, que un jefe de equipo vea lo suyo y no las órdenes de toda la empresa— sin tener que decidirlo caso por caso.

Los técnicos se agrupan además en equipos con su responsable, que es lo que hace manejable una plantilla de veinte personas: cada jefe ve su equipo, no una lista de trescientas órdenes abiertas.

La visibilidad documental, que es donde más se falla

Aquí está el control que más trabajo ahorra y el que menos se configura.

Cada documento del gestor documental lleva su propia visibilidad: si lo ve el cliente, si lo ve el técnico, si lo ve el proveedor, y si requiere validación.

La consecuencia práctica es que desaparece una decisión que se repite cada semana: qué le enseño a este. Se configura una vez por tipo de documento y ya está. Y cuando un proveedor deja de trabajar contigo, se le retira el acceso: la documentación sigue siendo tuya y él deja de verla, sin mover un fichero de sitio.

Qué ve el cliente, exactamente

Merece la pena detallarlo porque es donde más dudas hay al abrir el portal.

El cliente ve lo suyo: sus centros, sus activos, sus órdenes, sus incidencias y los documentos que le hayas marcado como visibles. Puede abrir incidencias con descripción y foto, seguir el estado de sus órdenes, descargar los partes de cada intervención y ver sus próximos preventivos en calendario.

Y hay dos límites que conviene conocer porque son decisiones de producto, no carencias:

El cliente no puede cambiar el estado de una orden. Está deshabilitado a propósito: el estado del trabajo lo marca quien lo ejecuta.

Su app no funciona sin conexión. Se instala en el dispositivo, pero el modo sin conexión completo es el de la app de técnicos.

También puedes controlar qué estados son visibles para él y cuáles se quedan dentro, y marcar los que no deben notificar. Eso último es tan importante como lo contrario: avisar de cada movimiento interno convierte las notificaciones en ruido.

Los proveedores

Se dan de alta como usuarios con su propio alcance y reciben las órdenes que les corresponden, registrando tiempos, material, documentación y firma. Pueden tener sus almacenes asociados, y se les puede definir un precio por artículo con su descuento pactado.

Que estén dentro del sistema no es una comodidad: si trabajan fuera, el histórico tiene agujeros justo donde están las intervenciones más caras.

El detalle que lo condiciona todo: el coste por usuario

Parece de tarifa y es de arquitectura de permisos.

Si el software se paga por usuario, dar de alta a un técnico nuevo, a un eventual de temporada, a una subcontrata o a un cliente es una decisión económica. Y entonces pasa lo previsible: se comparten cuentas.

En cuanto dos personas firman con el mismo usuario, tres cosas se rompen a la vez. Los informes por técnico dejan de significar nada. El histórico deja de valer como prueba, porque no se sabe quién hizo qué. Y todo el sistema de permisos se vuelve decorativo, porque el acceso real es el del que compartió la contraseña.

En GMAO CLOUD las licencias son ilimitadas en los tres planes. Da de alta a tu equipo, a tus clientes y a tus subcontratas sin hacer cuentas antes de cada alta.

Trazabilidad: quién hizo qué

Dos cosas que se valoran el día que hacen falta.

Queda registro de creación, modificación y eliminación, con su usuario y su fecha. En una discusión sobre si un documento se entregó o un dato se cambió, eso es la diferencia entre una opinión y un hecho.

El borrado es lógico, no físico. Lo que se elimina por error se puede recuperar, que es una tranquilidad operativa distinta de la seguridad pero igual de útil.

Sobre protección de datos

Un apunte de prudencia, porque es terreno donde se promete de más con frecuencia.

Lo que se puede describir son los controles: acceso por perfil, visibilidad documental configurable, registro de acciones, borrado recuperable y retirada de acceso a terceros. Lo que no se puede afirmar es que un software garantice el cumplimiento de ninguna normativa: la calificación jurídica no la hace un programa.

Lo mismo aplica a certificaciones: describir controles sí, prometer sellos no.

El usuario que se va

Un caso que llega siempre y que conviene tener resuelto antes de que ocurra: un técnico deja la empresa, o una contrata termina su contrato.

Lo que no hay que hacer es borrar el usuario. Si se borra, el histórico se queda sin autor: todas las órdenes que cerró, los checklists que cumplimentó y las firmas que recogió pierden la referencia de quién las hizo, y con ella su valor como prueba.

Lo correcto es retirarle el acceso y conservar el usuario. El trabajo sigue atribuido a quien lo hizo, los informes por técnico de periodos anteriores siguen siendo correctos, y esa persona deja de poder entrar.

Con un proveedor es lo mismo: se le retira el acceso y la documentación que subió o que se le compartió sigue siendo tuya, en su sitio.

Por dónde empezar

Con lo mínimo: los perfiles del equipo interno y la visibilidad por defecto de los documentos. Los accesos de cliente y de proveedor se abren después, cuando ya haya contenido que enseñar —un portal vacío genera más llamadas de las que evita—.

Y una recomendación práctica: abre el acceso a un cliente piloto antes que a toda la cartera. Sus preguntas te dirán qué documentos hay que marcar como visibles, que es algo que no se acierta a la primera.

Si quieres ver cómo quedaría con vuestros roles, puedes solicitar una demo.