Relevo · los casos de uso
Un caso de uso no es una promesa. Es quién entra, qué pasos da y qué queda escrito al salir.
Trece casos de uso de una operación de embarques internacionales y del sistema que observa el trabajo con que esa operación avanza: la guía que se captura dos veces, la tarea que se ejecuta sola, la decisión que hay que poder reconstruir, el caso nuevo ante el que el sistema se detiene y la automatización que hay que poder apagar.
Cómo se lee un caso de uso, y por qué importa el orden de los pasos
Un caso de uso escrito de verdad contesta cinco preguntas: quién entra, qué tiene que ser cierto antes de empezar, qué pasos da, qué queda cierto al terminar y qué regla no se puede violar en el camino. Si falta la precondición, el caso se ejecuta sobre datos que no existen. Si falta la postcondición, nadie puede verificar que se ejecutó.
En un sistema que observa el trabajo de personas, hay una sexta pregunta y es la que decide todo: ¿quién autorizó este caso, y cómo se revoca esa autorización? Los casos de la capa del aprendizaje llevan esa columna, y no es un adorno jurídico: es lo que permite contestarle a un empleado observado qué se aprobó sobre su trabajo y quién lo aprobó.
El tipo de pantalla tampoco es decorativo. En el sistema logístico generado hay 178 pantallas repartidas en tipos con comportamiento distinto: una pantalla de aprobación tiene su fila de revisión y su registro de decisión; un tablero de auditoría tiene línea de tiempo; un asistente por pasos valida en cada paso y no deja avanzar si el anterior quedó incompleto. (motor de la casa, el proyecto de este sistema en el motor, tabla pantalla)
Los trece casos de uso
| Código | Caso de uso | Capa | Actor principal | Pantalla donde ocurre |
|---|---|---|---|---|
| UC-01 | Detectar que un puesto captura la misma guía en dos sistemas y proponer la automatización | Aprendizaje | El sistema propone; el dueño del proceso decide | BANDEJA · Tablero de oportunidades |
| UC-02 | Ejecutar una tarea aprendida y dejar constancia de quién la aprobó | Aprendizaje | El sistema, bajo automatización aprobada | PROCESO · Ejecución de tarea aprendida |
| UC-03 | Reconstruir por qué el sistema hizo lo que hizo | Aprendizaje | El empleado observado, su representación, seguridad de la información | AUDITORIA · Expediente de la ejecución |
| UC-04 | Detenerse ante un caso que no se ha visto antes y devolverlo a una persona | Aprendizaje | El sistema se detiene; el operador de captura resuelve | BANDEJA · Casos devueltos a decisión humana |
| UC-05 | Medir las horas liberadas de un puesto contra su línea base | Aprendizaje | El supervisor del área y el dueño del proceso | REPORTE · Horas liberadas por puesto |
| UC-06 | Revocar una automatización que empezó a fallar | Aprendizaje | Quien puede apagar la automatización | APROBACION · Revocación de automatización |
| UC-07 | Firmar la política de uso y el aviso de privacidad antes de que la observación empiece | Aprendizaje | La persona observada y el responsable del tratamiento | PROCESO · Aviso, consentimiento y alcance |
| UC-08 | Programar un embarque con plantilla de ruta recurrente y folio único | Negocio | Ejecutivo de atención de negocio | WIZARD · Captura de datos del embarque |
| UC-09 | Asignar el proveedor del trayecto y emitir el acuerdo de confirmación de carga | Negocio | Coordinador de operaciones | APROBACION · Acuerdo de confirmación de carga |
| UC-10 | Avanzar el estado de un trayecto con bloqueo del tramo anterior | Negocio | Operador de unidad y monitorista de tráfico | WIZARD · Actualización de estado del trayecto |
| UC-11 | Escalar una incidencia de trayecto según su severidad | Negocio | Monitorista de tráfico | MASTER_DETAIL · Gestión de incidencias en trayecto |
| UC-12 | Registrar el comprobante fiscal del proveedor por cada trayecto | Negocio | Coordinador de operaciones | FICHA · Expediente de comprobante fiscal de trayecto |
| UC-13 | Cerrar el embarque y archivar su expediente completo | Negocio | Coordinador de operaciones y gerente administrativo | WIZARD · Cierre y archivo del embarque |
Los seis casos en negro son los de gobierno del aprendizaje. Los casos de la capa del negocio y sus tipos de pantalla se transcriben del motor el motor de la casa, el proyecto de este sistema en el motor, corte de servidor del 27 de septiembre de 2026.
Trece casos, y los seis que deciden si el sistema es aceptable no son los del embarque. Son los que dicen quién manda sobre la automatización.
El caso que define el número
UC-01 · Detectar que un puesto captura la misma guía en dos sistemas
Es el caso que le da su número al sistema. El puesto de captura abre el portal de la paquetería, teclea origen, destino, peso y referencia del cliente, espera, y copia el número de guía que el portal devuelve al registro del embarque. Los datos que teclea ya estaban en su otra pantalla. El sistema no lo deduce de un manual: lo ve, cuenta las veces y cronometra los segundos. (brochure de Relevo, secciones «cómo funciona» y ejemplo de oportunidad detectada)
- La observación está activa dentro del alcance firmado en UC-07; sin esa firma, este caso no arranca.
- El sistema registra la secuencia de pasos de la jornada del puesto: qué aplicación, qué campo, en qué orden, cuántos segundos. Registra el paso, no el número de guía del cliente.
- Detecta que una secuencia se repite con el mismo orden exacto, y la agrupa como una tarea candidata con su nombre operativo.
- Cuenta la frecuencia diaria y la duración media: en el ejemplo declarado, 340 veces al día y 45 segundos por vez.
- Calcula la hora recuperable —veces al día por segundos por vez— y coloca la tarea en el tablero de oportunidades, ordenada contra las demás.
- El supervisor del área confirma que la tarea es la que cree que es, y que los datos de origen son los que el sistema identificó.
- El sistema emite la propuesta de automatización: qué pasos va a ejecutar, en qué aplicaciones, con qué datos de entrada y qué no va a tocar.
- La propuesta queda pendiente de aprobación. Nada se ejecuta todavía: el paso siguiente es UC-02 y no ocurre sin la firma del dueño del proceso.
UC-01 · ficha
| Campo | Contenido |
|---|---|
| Actor | El sistema detecta y propone. Confirman el supervisor del área y el dueño del proceso. |
| Precondición | La política de uso y el aviso de privacidad están firmados por la persona observada, y el alcance de la observación está declarado. |
| Postcondición | Existe una propuesta de automatización con alcance, pasos y hora recuperable estimada, en estado pendiente de aprobación. |
| Reglas que aplican | Se registra el proceso, no el contenido. Contraseñas, tarjetas, RFC, CURP y correos se enmascaran antes de salir del equipo. Una propuesta no se ejecuta por antigüedad: caduca si nadie la aprueba. |
| Norma | Ley Federal de Protección de Datos Personales en Posesión de los Particulares, DOF del 20 de marzo de 2025: base de licitud, aviso de privacidad y finalidad declarada. |
| Pantalla | BANDEJA · Tablero de oportunidades, con tarea, veces al día, segundos por vez y hora recuperable. |
La hora no aparece porque alguien la buscó en una encuesta. Aparece porque se contaron las veces y se cronometraron los segundos.
UC-02 · Ejecutar una tarea aprendida y dejar constancia de quién la aprobó
Éste es el caso que separa a este sistema de una herramienta de medición. Medir produce un informe; ejecutar produce la hora. Y ejecutar sin constancia de la aprobación produce un problema, porque después nadie puede decir qué se autorizó.
La constancia no es un campo de auditoría escondido en una tabla. Es parte del resultado: cada ejecución queda ligada a la automatización que la hizo, a la versión de la secuencia aprendida, a la fecha y al nombre de quien aprobó esa automatización con ese alcance.
- La automatización está en estado aprobado, con actor, fecha y alcance registrados (UC-06 puede revocarla en cualquier momento).
- El disparador ocurre: llega un embarque que necesita guía, o el puesto lo pide desde su pantalla.
- El sistema verifica que el caso está dentro del alcance aprobado. Si no lo está, se detiene y aplica UC-04.
- Ejecuta la secuencia de principio a fin: abre la aplicación, coloca los datos de entrada, envía y recoge el resultado.
- Escribe el resultado en el registro del embarque: número de guía, hora, y el identificador de la ejecución.
- Genera la constancia: automatización, versión de la secuencia, datos de entrada usados, resultado, hora y nombre de quien la aprobó.
- Contabiliza el tiempo que esa ejecución habría tomado a una persona según la línea base medida, y lo suma al expediente de horas liberadas del puesto.
- Si el resultado no es el esperado —el portal cambió, devolvió un error, tardó más de lo tolerado— la ejecución queda marcada y entra al conteo de fallas que UC-06 vigila.
UC-02 · ficha
| Campo | Contenido |
|---|---|
| Actor | El sistema ejecuta. El operador de captura observa y puede interrumpir. El supervisor del área revisa el resultado. |
| Precondición | Automatización aprobada y vigente, con alcance declarado; el caso concreto cae dentro de ese alcance. |
| Postcondición | La tarea está hecha, el resultado está escrito en el registro del embarque y existe la constancia con el nombre del autorizante. |
| Reglas que aplican | Ninguna ejecución sin aprobación vigente. Ninguna ejecución fuera del alcance. Toda ejecución deja constancia, incluida la que falló. |
| Norma | Código Fiscal de la Federación, artículo 30, cuando el resultado forma parte de la documentación comprobatoria del embarque. |
| Pantalla | PROCESO · Ejecución de tarea aprendida, con el resultado y el enlace a la constancia. |
Una ejecución sin constancia del autorizante es una acción sin dueño. En un expediente, una acción sin dueño vale menos que un hueco declarado.
UC-03 · Reconstruir por qué el sistema hizo lo que hizo
Este caso no existe para el comprador del sistema. Existe para quien le pide cuentas: el empleado cuyo trabajo se observó, su representación, el área de seguridad de la información, si llega el momento, la autoridad. Un sistema que no puede explicar una de sus acciones no es un sistema: es una caja.
Lo que se reconstruye no es una intención, es una cadena: qué observación produjo qué detección, qué detección produjo qué propuesta, quién aprobó esa propuesta y con qué alcance, y qué ejecuciones se hicieron bajo esa aprobación. Cada eslabón tiene fecha y actor.
La ley de datos personales vigente desde el 21 de marzo de 2025 pide base de licitud, finalidad declarada, aviso de privacidad y atención de los derechos de acceso, rectificación, cancelación y oposición. Este caso es la forma operativa de atender el derecho de acceso sobre un dato que se produjo observando el trabajo de una persona. (LFPDPPP, DOF del 20 de marzo de 2025)
El sistema que observa trabajo tiene que poder explicarse a la persona observada. No como cortesía: como condición para seguir observando.
- La persona observada, su representación o el área de seguridad de la información presenta la solicitud, identificando el hecho: una ejecución, una tarea, un periodo o su propio expediente completo.
- El sistema resuelve el alcance: qué registros corresponden a esa persona, ese puesto o esa automatización, y qué registros no.
- Reúne la cadena en orden: el alcance firmado, las observaciones dentro de ese alcance, la detección, la priorización con sus números, la propuesta, la aprobación con su actor y fecha, y las ejecuciones.
- Añade las interrupciones: las pausas que la persona activó, y los periodos en que la observación estuvo detenida.
- Añade las fallas y las revocaciones, si hubo: qué se apagó, cuándo y por qué.
- Produce el expediente en formato legible y ordenable, con un índice de lo que contiene y de lo que no contiene, y señala los huecos en lugar de taparlos.
- Deja constancia de la entrega: qué se entregó, a quién, cuándo y con qué versión de los datos.
UC-03 · ficha
| Campo | Contenido |
|---|---|
| Actor | El empleado observado y su representación. También seguridad de la información y el dueño del proceso. |
| Precondición | El solicitante está identificado y su legitimación está verificada; existe al menos un registro en el alcance solicitado. |
| Postcondición | Expediente entregado, con constancia de entrega y con la versión de los datos congelada para consulta posterior. |
| Reglas que aplican | El expediente no se edita después de entregado: una corrección genera versión nueva con su motivo. Un hueco se declara. Nadie puede pedir el expediente de otra persona. |
| Norma | LFPDPPP, DOF del 20 de marzo de 2025: derechos de acceso, rectificación, cancelación y oposición; la autoridad en la materia dejó de ser el instituto que la ejercía bajo la ley anterior. |
| Pantalla | AUDITORIA · Expediente de la ejecución, con línea de tiempo y rejilla de detalle. |
Quien no puede reconstruir la cadena no puede defenderla. Y lo que no se puede defender, tarde o temprano se apaga por la vía mala.
UC-04 · Detenerse ante un caso que no se ha visto antes
El caso que más confianza produce es el que el sistema no resuelve. Una automatización que improvisa ante una pantalla distinta produce daño silencioso: escribe un dato en el campo equivocado y nadie se entera hasta que el cliente reclama. Una que se detiene produce una fila de trabajo, que es un problema visible y por lo tanto barato.
Los disparadores de la detención son concretos y se declaran: el caso cae fuera del alcance aprobado; la pantalla del tercero no es la que la secuencia aprendió; un dato de entrada falta o viene con un formato que no se vio antes; el resultado no coincide con ninguno de los resultados conocidos; el tiempo de respuesta excede el tolerado.
Y hay un disparador que no es técnico: la persona observada activó su pausa. Mientras la pausa esté activa, el sistema no observa y no aprende de ese periodo. (brochure de Relevo, sección «privacidad»)
UC-04 · cuándo se detiene y qué pasa después
| Disparador de la detención | Qué hace el sistema | A quién va | Qué queda registrado |
|---|---|---|---|
| El caso cae fuera del alcance aprobado | No ejecuta; devuelve el caso completo | Operador de captura, y avisa al dueño del proceso | El caso, el motivo y el alcance contra el que se comparó |
| La pantalla del tercero cambió | Suspende la automatización, no sólo el caso | Supervisor del área y dueño del proceso | La diferencia detectada y la versión de la secuencia que ya no aplica |
| Falta un dato de entrada o llega con formato nuevo | Devuelve el caso con el campo señalado | Operador de captura | El campo, el valor recibido y el formato esperado |
| El resultado no coincide con ningún resultado conocido | Marca la ejecución como no concluyente y devuelve | Operador de captura y supervisor del área | El resultado literal y el conjunto de resultados conocidos |
| El tiempo de respuesta excede el tolerado | Aborta y devuelve | Operador de captura | El tiempo medido y el umbral |
| La persona observada activó su pausa | Deja de observar ese periodo | A nadie: no es una excepción, es un derecho | Que hubo una pausa y su duración; no qué se hizo durante ella |
Fuente: Relevo · brochure de logística, secciones «cómo funciona» y «privacidad» · modelo de casos devueltos del sistema en vivo, datos de ejemplo.
El sistema que se detiene cuesta una fila de trabajo. El que improvisa cuesta una reclamación del cliente y una semana de explicaciones.
UC-05 · Medir las horas liberadas de un puesto contra su línea base
El indicador de este sistema son las horas recuperadas al día por puesto, y un indicador que no se puede reproducir no es un indicador. Este caso es el procedimiento de cálculo, escrito para que cualquiera pueda repetirlo.
La línea base se toma antes de automatizar: frecuencia diaria de la tarea y duración media medida por observación, no declarada por el puesto. Después de automatizar, el sistema cuenta cuántas ejecuciones hizo, cuántas se detuvieron y volvieron a una persona, y cuánto tiempo consumió la revisión humana que quedó.
La diferencia son las horas liberadas. Y se publica con las tres cifras a la vista, no sólo con el resultado: si la revisión humana se come la mitad del ahorro, eso se ve.
UC-05 · el cálculo, con el ejemplo declarado
| Componente | Cómo se obtiene | Ejemplo de la tarea de captura de guía |
|---|---|---|
| Frecuencia de la tarea | Contada por observación durante el periodo de línea base | 340 veces al día |
| Duración media por vez | Cronometrada por observación, no declarada | 45 segundos |
| Tiempo total de la tarea al día | Frecuencia por duración | 4.2 horas al día |
| Ejecuciones automáticas concluidas | Contadas por el sistema, con su constancia | Se publica el conteo real del periodo, no una estimación |
| Casos devueltos a una persona | Contados por UC-04, con su motivo | Se publica el conteo real y el motivo dominante |
| Tiempo de revisión humana remanente | Medido igual que la línea base, sobre la revisión que quedó | Se mide, no se supone cero |
| Horas liberadas del puesto | Tiempo total de la tarea menos el tiempo de los casos devueltos y de la revisión remanente | El resultado, con las tres cifras anteriores a la vista |
Fuente: Relevo · brochure de logística, ejemplo de oportunidad detectada (340 veces al día, 45 segundos por vez, 4.2 horas al día) y sección «beneficios» · datos de ejemplo en las filas de conteo.
El brochure lo dice en una frase que conviene tomar en serio: el propio sistema cuantifica el tiempo liberado. Eso obliga a que el número salga del mismo mecanismo que midió la tarea original. Un ahorro calculado aparte, en una hoja de cálculo, no es el indicador de este sistema: es la opinión de quien hizo la hoja.
El ahorro que no se puede recalcular con los mismos datos no es un ahorro. Es una afirmación.
UC-06 · Revocar una automatización que empezó a fallar
Hay un rol que en otros sistemas no existe y en éste es obligatorio: el que puede apagar la automatización. No pide permiso, no abre un ticket y no espera al comité del jueves. Apaga, y después explica.
Los motivos de revocación se declaran de antemano para que la decisión no dependa del ánimo de nadie: la tasa de casos devueltos supera el umbral acordado; una ejecución escribió un dato incorrecto en un registro del embarque; la pantalla del tercero cambió y la secuencia ya no aplica; el alcance aprobado dejó de corresponder al proceso real; o la persona observada, su representación o el área de seguridad de la información lo solicitan con motivo.
Revocar no borra nada. La automatización queda apagada con fecha, actor y motivo, y todas sus ejecuciones anteriores siguen en el expediente. Reactivarla no es levantar un interruptor: es volver a UC-01, proponer de nuevo y aprobar de nuevo. La aprobación no se hereda.
El interruptor de apagado no es una concesión al área legal. Es la única razón por la que un equipo acepta que el sistema siga observando.
UC-06 · ficha
| Campo | Contenido |
|---|---|
| Actor | Quien puede apagar la automatización. Pueden solicitarlo el empleado observado, su representación, seguridad de la información, el supervisor del área y el dueño del proceso. |
| Precondición | La automatización está activa y existe al menos un motivo de los declarados, o una solicitud con motivo escrito. |
| Postcondición | La automatización está apagada con fecha, actor y motivo. La tarea vuelve a ejecutarse a mano y el puesto lo sabe antes de su siguiente turno. |
| Reglas que aplican | La revocación es inmediata y no requiere autorización de un tercero. No borra ejecuciones anteriores. Reactivar exige propuesta y aprobación nuevas. |
| Norma | LFPDPPP, DOF del 20 de marzo de 2025: derecho de oposición al tratamiento; y el propio compromiso contractual de la política de uso firmada. |
| Pantalla | APROBACION · Revocación de automatización, con el motivo obligatorio y el aviso automático al puesto afectado. |
La automatización que nadie puede apagar no se discute: se sabotea. Y el sabotaje no deja registro.
UC-07 · Firmar el aviso y declarar el alcance antes de observar
Éste es el primer caso en el tiempo, aunque sea el séptimo de la lista. Sin él, los seis anteriores son ilegales y los seis del negocio siguen igual que antes.
El brochure lo declara con claridad: cada persona sabe que está instalado, la política de uso y el aviso de privacidad se firman, y el acceso es por rol con auditoría de Recursos Humanos. La ley pone el resto: base de licitud, finalidad declarada, medidas de seguridad y atención de los derechos de la persona. (brochure de Relevo, sección «privacidad», y LFPDPPP, DOF del 20 de marzo de 2025)
- El responsable del tratamiento redacta el aviso de privacidad con la finalidad declarada: detectar tareas repetidas para automatizarlas y medir el tiempo liberado. Ninguna otra finalidad.
- Declara el alcance de la observación: qué aplicaciones, en qué horario, en qué equipos, y qué queda fuera de manera expresa.
- Declara qué se enmascara antes de salir del equipo: contraseñas, tarjetas, registro fiscal, clave única de población y correos.
- Declara los plazos de conservación por tipo de registro, y quién los fija.
- La persona recibe el aviso y la política de uso, pregunta lo que quiera, y firma. La firma queda con fecha.
- Se activa la pausa a voluntad de la persona, sin autorización de nadie, y se le explica dónde está.
- Se configura el acceso por rol: cada jefe ve sólo a su equipo; Recursos Humanos audita.
- Sólo entonces empieza la observación, y empieza con la fecha de la firma, no antes.
La observación que empieza antes de la firma no se puede arreglar después. Los datos de ese periodo no valen y el equipo no vuelve a creer.
La capa del negocio
Los seis casos del embarque, transcritos del sistema generado
Los casos UC-08 a UC-13 no son ilustraciones. Son los seis casos de mayor peso del sistema logístico que la plataforma tiene generado, donde hay 438 casos de uso colgados de 196 subprocesos, cada uno con su actor principal y su subproceso de origen. Se resumen aquí porque son los pasos sobre los que la capa del aprendizaje trabaja. (motor de la casa, el proyecto de este sistema en el motor, corte de servidor del 27 de septiembre de 2026)
Dos de ellos merecen atención porque son donde nace la doble captura: UC-12, el registro del comprobante fiscal del proveedor por cada trayecto, toma un dato que nació en la facturación de otra empresa; y UC-13, el cierre con archivo del expediente, es el momento en que se descubre qué documentos faltan, cuando ya no se pueden conseguir sin pedir un favor.
UC-08 a UC-13 · actor, precondición, postcondición y regla que no se viola
| Código | Actor | Precondición | Postcondición | La regla que no se viola |
|---|---|---|---|---|
| UC-08 | Ejecutivo de atención de negocio | El cliente existe en el catálogo maestro con sus datos fiscales; hay plantilla de ruta o se capturan los trayectos | Embarque registrado con folio único irrepetible, orden de compra en PDF adjunta y notificación a operaciones | No se envía la solicitud con campos obligatorios vacíos: la validación es en tiempo real, antes del envío |
| UC-09 | Coordinador de operaciones | El embarque está validado y el trayecto a asignar es el siguiente en la secuencia | Proveedor asignado con unidad, operador y placas; acuerdo de confirmación de carga generado, aprobado y enviado con hora registrada | Un activo no se asigna a dos viajes en el mismo rango de fechas: el sistema verifica la concurrencia |
| UC-10 | Operador de unidad y monitorista de tráfico | El trayecto tiene proveedor asignado y el estado anterior está confirmado con sus datos capturados | Estado avanzado con hora real, y evento de auditoría inmutable con estado anterior, estado nuevo, usuario y folio | No se salta un estado ni se retrocede sin motivo registrado: el bloqueo lógico entre etapas es del sistema, no del criterio de quien opera |
| UC-11 | Monitorista de tráfico | Hay un trayecto activo y se detectó una anomalía con impacto estimado en tiempo | Incidencia registrada y escalada según su severidad, con la comunicación al cliente disparada cuando corresponde | La severidad determina el camino: baja la resuelve el operador; media escala al supervisor; alta escala a dirección y abre la contingencia |
| UC-12 | Coordinador de operaciones | El trayecto está cerrado y el proveedor existe y está activo en el catálogo | Comprobante fiscal registrado y ligado al trayecto y al embarque, con su estatus de deducibilidad | La fecha de emisión se valida contra la fecha de cierre del embarque; el proveedor se valida contra el catálogo maestro |
| UC-13 | Coordinador de operaciones y gerente administrativo | Todos los trayectos están en estado descargado y sus comprobantes están registrados | Embarque cerrado, activos liberados y expediente archivado con folio, orden de compra, acuerdos de carga, historial de estados, eventos de auditoría y comprobantes | El expediente se archiva completo o se declara qué falta: el cierre no se fuerza con un documento pendiente sin motivo escrito |
Fuente: motor de la casa, el proyecto de este sistema en el motor, tablas caso_uso, subproceso_negocio y Spartan_WorkFlow_Transition · Código Fiscal de la Federación, artículo 30 · corte de servidor del 27 de septiembre de 2026.
Seis casos del negocio, y en cuatro de ellos hay un dato que ya existe en otra pantalla. Ésos son los cuatro que la segunda capa mira primero.
Qué falta declarar de estos casos, con el conteo
Los 438 casos de uso del proyecto están poblados con su actor principal, su subproceso de origen y su descripción. El detalle paso a paso de cada uno y las reglas de negocio que lo condicionan se escriben con su equipo en la implantación, porque dependen del procedimiento de su casa.
Eso significa que los pasos numerados de los casos de esta página se derivan de los subprocesos —que sí están poblados, 196 con rol responsable— y de la matriz de transiciones, que trae acción, condición, rol autorizado y plazo. No se inventa ninguno, y cuando un paso no tiene respaldo en el motor se atribuye al brochure o a la norma.
Los siete casos de la capa del aprendizaje no vienen del motor: vienen del brochure de Relevo y de lo que la ley de datos personales obliga. Están atribuidos así en cada ficha, y el lector puede verificar cada afirmación contra su fuente.
Un caso de uso con su origen declarado se puede discutir. Uno sin origen sólo se puede creer, y creer no es un método de compra.
Preguntas frecuentes
¿Por qué hay casos de uso del embarque en la página de un sistema que automatiza capturas?
Porque la captura que se automatiza es la de un paso del embarque. Sin el caso del negocio delante, la automatización no tiene contexto: no se sabe qué dato entra, de qué registro sale ni qué pasa si sale mal. Los seis casos del negocio son el terreno; los siete del aprendizaje son lo que ocurre sobre ese terreno.
¿El sistema puede ejecutar una tarea sin que nadie la haya aprobado?
No, y no por configuración: por diseño del caso. UC-02 tiene como precondición una automatización aprobada y vigente, con alcance declarado, y verifica que el caso concreto caiga dentro de ese alcance antes de ejecutar. Si no cae, se detiene y aplica UC-04. La constancia de cada ejecución trae el nombre de quien aprobó.
¿Qué pasa si el portal de un tercero cambia y la secuencia aprendida ya no sirve?
El sistema lo detecta como una diferencia entre la pantalla que aprendió y la que encuentra, y suspende la automatización completa, no sólo el caso. Eso es UC-04 en su segundo disparador. Después hay que volver a observar, volver a proponer y volver a aprobar: la aprobación anterior no se hereda a una secuencia distinta.
¿Un empleado puede pedir el expediente de lo que el sistema observó de él?
Sí, y es UC-03. La ley de datos personales vigente desde el 21 de marzo de 2025 reconoce los derechos de acceso, rectificación, cancelación y oposición, y este caso es la forma operativa de atender el de acceso. El expediente trae la cadena completa —alcance firmado, observaciones, detección, propuesta, aprobación y ejecuciones—, declara los huecos y no se edita después de entregado. (LFPDPPP, DOF del 20 de marzo de 2025)
¿Quién puede apagar una automatización y cuánto tarda?
El rol que tiene esa facultad, y es inmediato: no requiere autorización de un tercero ni pasar por un comité. Pueden solicitarlo el empleado observado, su representación, seguridad de la información, el supervisor del área y el dueño del proceso. La revocación queda con fecha, actor y motivo, y el puesto afectado se entera antes de su siguiente turno, porque la tarea vuelve a hacerse a mano.
¿De dónde salen los pasos numerados de cada caso, si el motor no tiene el flujo poblado?
De los 196 subprocesos con rol responsable y de la matriz de 213 transiciones, que trae acción, condición, rol autorizado y plazo. El campo de flujo principal por pasos de la tabla de casos de uso viene vacío en la muestra revisada, y así se declara. Lo que no tiene respaldo en el motor está atribuido al brochure o a la norma, en la propia ficha.
Referencias
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares, DOF del 20 de marzo de 2025, en vigor desde el 21 de marzo de 2025: base de licitud, aviso de privacidad, finalidad declarada, medidas de seguridad y derechos de acceso, rectificación, cancelación y oposición. ↗
- Código Fiscal de la Federación, artículo 30: conservación de la contabilidad y de la documentación comprobatoria del embarque. ↗
- SAT · Complemento Carta Porte del CFDI, versión 3.1, de uso obligatorio desde el 17 de julio de 2024. ↗
- Ley Aduanera. DOF del 15 de diciembre de 1995, con reforma publicada en el DOF del 19 de noviembre de 2025. ↗
- Motor el motor de la casa, base del motor de la casa, el proyecto de este sistema: 438 casos de uso, 196 subprocesos con rol responsable, 213 transiciones con rol autorizado y plazo, 178 pantallas. Reglas de negocio del proyecto: 0 al corte. Corte de servidor del 27 de septiembre de 2026, 08:03:51, consulta de sólo lectura; el nombre del cliente está enmascarado en el origen. ↗
- Relevo · brochure de logística, 10 páginas: ciclo de cuatro capacidades, ejemplo de oportunidad detectada (340 veces al día, 45 segundos por vez, 4.2 horas al día) y seis controles de privacidad.
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es Relevo con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.
Siga por aquí