Roles, permisos y trazabilidad. Lo que una herramienta interna no puede olvidar
Una herramienta interna puede reunir a varias áreas en un mismo proceso y, aun así, necesitar reglas distintas para cada persona. Si esas reglas se deciden cuando las pantallas ya están diseñadas, quedan sin respuesta preguntas esenciales: quién puede actuar, en qué condiciones y cómo se sabrá qué ocurrió.
Imaginemos una empresa que recibe solicitudes de compra en una plataforma. Una persona las registra, su responsable las revisa y finanzas autoriza el pago. El flujo parece sencillo hasta que alguien pregunta si quien creó una solicitud puede aprobarla, quién corrige un importe equivocado o qué sucede cuando falta la persona responsable. La herramienta debe representar esas decisiones y responsabilidades, no solo ofrecer un botón para cada paso. Por eso, los roles, permisos y registros de actividad forman parte de la definición funcional previa al desarrollo.
Puedes escuchar este artículo aquí:
Un rol describe una responsabilidad, no un cargo
En una herramienta interna, un rol reúne las tareas que una persona puede desempeñar dentro de un proceso. «Solicitante», «revisor» y «aprobador» explican mejor lo que cada quien necesita hacer que etiquetas generales como «empleado» o «administrador». Una misma persona puede tener más de un rol, pero eso no significa que deba intervenir en todas las decisiones ni acceder a toda la información.
El control de acceso basado en roles, descrito por el NIST, asocia las acciones permitidas con roles en lugar de asignarlas individualmente a cada usuario. Es un punto de partida para ordenar la herramienta, pero la operación real exige preguntas adicionales: ¿quién sustituye a un aprobador ausente?, ¿durante cuánto tiempo puede hacerlo?, ¿hay decisiones en las que quien solicita no debe ser quien aprueba? Esas situaciones pueden modificar el recorrido tanto como la regla habitual.
«Si todos pueden resolver una excepción, nadie sabe quién debía hacerse responsable de ella».
Antes de dibujar pantallas, conviene seguir una tarea de principio a fin e identificar quién la inicia, quién recibe el trabajo, quién toma cada decisión y quién interviene si algo sale mal. La intención no es copiar el organigrama dentro de la plataforma, sino describir responsabilidades que el equipo pueda revisar y que la herramienta pueda respetar.
Un permiso define qué se puede hacer y en qué condiciones
Tener un rol no equivale a poder realizar cualquier acción dentro de un módulo. Un revisor quizá pueda ver una solicitud y pedir correcciones, pero no cambiar su importe ni aprobar una compra propia. También puede necesitar acceso únicamente a las solicitudes de su área. Escribir que «el revisor tiene acceso al módulo» deja abiertas todas esas decisiones.
Una regla funcional debe relacionar rol, acción, información y condición. En el ejemplo, podría quedar documentada así: El responsable de área puede aprobar una solicitud de su equipo cuando esté pendiente y haya pasado la revisión requerida; no puede aprobar una solicitud que creó personalmente. Si está ausente, una persona designada puede asumir esa tarea durante el periodo registrado. El equipo aún tendría que acordar quién hace la designación y cómo se revoca. Al escribirlo, esas decisiones pendientes se vuelven visibles antes de construir la función.
Aquí conviene distinguir dos ideas. Dar permiso para aprobar significa que la herramienta reconoce a una persona como facultada para realizar esa acción. Aprobar la compra es la decisión de negocio que esa persona toma sobre una solicitud concreta. La primera necesita una regla de acceso; la segunda necesita condiciones, un resultado y, posiblemente, un motivo que quede registrado.
La guía de autorización de OWASP recomienda conceder solo los privilegios necesarios, negar el acceso cuando ninguna regla lo permita y comprobar el permiso cada vez que alguien intenta consultar datos o realizar una acción. Para quien encarga una herramienta, esto tiene una consecuencia práctica: ocultar el botón «Aprobar» a ciertos usuarios no sustituye la regla que impide efectuar la acción.
La trazabilidad permite reconstruir una decisión
Supongamos que una solicitud pasó de «rechazada» a «aprobada» y nadie recuerda por qué. Conocer su estado actual no responde quién hizo el cambio, cuándo ocurrió, qué estado tenía antes ni cuál fue el motivo. La trazabilidad consiste en conservar el rastro necesario para reconstruir ese recorrido y atender una duda, una corrección o una revisión posterior.
En el proceso de compras, podría ser relevante registrar la creación de la solicitud, los cambios de importe, las aprobaciones, los rechazos y las reasignaciones. Para cada evento hay que decidir qué información permite entenderlo y quién estará facultado para consultar el historial. También se necesita definir quién revisará una anomalía y cómo podrá corregirse sin borrar la explicación de lo sucedido.
La guía de registros de OWASP señala que los eventos deben aportar información suficiente sobre cuándo, dónde, quién y qué ocurrió. Advierte, a la vez, que registrar demasiado puede exponer datos sensibles. Por eso, documentar la trazabilidad implica seleccionar los eventos útiles, proteger el historial y definir su conservación conforme a las necesidades y obligaciones aplicables a la organización.
«Una aprobación sin contexto cierra una pantalla, pero puede dejar abierta la pregunta más importante: por qué se tomó esa decisión».
Puedes ver este artículo aquí:
Qué debe quedar definido antes de encargar la herramienta
Para revisar si el proyecto está listo, elige una tarea importante —como aprobar una compra— y recórrela con quienes participan en ella. Pregunta quién la inicia, quién puede verla y modificarla, bajo qué condiciones avanza, qué sucede ante un error o una ausencia y qué información permitirá reconstruir cada decisión. Si las respuestas cambian según el área consultada, todavía hay reglas operativas por acordar.
La documentación funcional debe convertir esas respuestas en roles, permisos, estados, excepciones y eventos que las áreas puedan revisar juntas. Así, diseño podrá mostrar a cada persona las acciones que le corresponden y desarrollo contará con reglas concretas para implementarlas y comprobarlas. La empresa, por su parte, habrá decidido quién responde cuando el proceso sale del camino previsto.
Una herramienta interna necesita dejar claro quién puede actuar y conservar un rastro útil de las decisiones relevantes. Si tu equipo no puede explicar hoy quién aprobaría una excepción o cómo revisaría una decisión equivocada, ¿qué debería definir antes de convertir ese proceso en código?
¿Tu idea necesita más claridad antes de convertirse en código? En Señor Zorro, estudio de diseño de productos digitales, te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
Escrito por: Editorial
#DocumentaciónFuncional #HerramientasInternas #DiseñoDeProductosDigitales #RolesYPermisos #Trazabilidad #IdeasAntesDelCódigo
Comentarios