Relevo · los cambios
Una automatización que aprendió un proceso viejo se vuelve un error que corre solo. Apagarla y corregirla es el cambio que aquí se hace en la sesión.
El portal de la paquetería movió un campo. El agente aduanal cambió el formulario. La operación dejó de hacer un paso. En el modelo con el que se le vendió, cada una de esas tres cosas es un ticket con cotización. Aquí es una edición con su bitácora, y si la automatización ya estaba corriendo, es una edición urgente.
Por qué existe la orden de cambio, y de qué es síntoma
La orden de cambio no es un trámite administrativo: es la consecuencia lógica de un modelo de contratación. Cuando el sistema que usted usa se le licenció cerrado, cualquier diferencia entre su operación y el producto se vuelve trabajo de alguien que no es usted. Ese trabajo hay que cotizarlo, aprobarlo, calendarizarlo, probarlo y facturarlo. La orden de cambio es la factura de esa distancia.
El efecto secundario es más caro que la factura. Con el tiempo, su empresa aprende a no pedir. Se deja de registrar el dato que el cliente pediría, se arma el reporte en una hoja de cálculo paralela, y el sistema que costó una fortuna termina sirviendo para facturar y para nada más. Y no es culpa de su gente: es el modelo con el que se le vendió.
En automatización de trabajo repetitivo ese modelo choca con un hecho que no se puede negociar: los portales ajenos cambian sin avisarle. El portal de la paquetería mueve un campo, el formulario del agente aduanal añade un paso, el complemento fiscal del traslado cambia de versión sin convivencia. Un sistema que cobra por cambiar es un sistema que se queda atrás de las pantallas sobre las que trabaja.
Cuando pedir un cambio cuesta, el sistema deja de reflejar la operación. Y entonces quien decide vuelve a decidir con la hoja de cálculo.
El caso que define la página
El cambio propio de este sistema: la automatización que empezó a fallar
Hay un tipo de cambio que en Relevo no es un caso más: es el caso. Una automatización aprendida ejecuta una tarea de principio a fin porque aprendió la secuencia exacta con la que su equipo la hacía. El día que el proceso cambia —porque el portal movió un campo, porque la operación dejó de hacer un paso, porque el cliente pide un dato más— esa automatización no se detiene educadamente a preguntar. Sigue ejecutando la secuencia vieja, que ahora está mal.
Un robot equivocado corriendo en producción es peor que no tener robot. No porque falle, sino porque no falla de forma visible: captura, avanza y deja registro, y alguien tendrá que deshacer cada una de esas capturas más tarde. La pregunta que decide si un sistema de automatización es apto para su operación no es «¿qué tan rápido aprende?». Es «¿quién puede apagarlo hoy, en la sesión, sin abrir un ticket?».
Ésa es exactamente la clase de cambio que esta página describe. Apagar una automatización aprendida, corregir su secuencia, devolverla a modo de sugerencia para que el operador vuelva a validar cada paso, y volver a habilitarla cuando la secuencia nueva quedó aprendida. Cuatro movimientos que en un modelo de órdenes de cambio son cuatro cotizaciones, y aquí son cuatro ediciones con su registro.
Quien no pueda apagar su propia automatización sin pedir permiso a su proveedor no tiene un robot: tiene un pasivo que trabaja rápido.
- Apagar. La automatización deja de ejecutar y la tarea vuelve a manos del operador, con la sugerencia en pantalla como red.
- Degradar a sugerencia. El sistema sigue indicando el siguiente paso, pero no lo ejecuta: el operador confirma cada uno, al hacerlo, vuelve a enseñar la secuencia nueva.
- Corregir la secuencia. Se edita el paso que cambió, el umbral que se movió o el campo que dejó de existir.
- Rehabilitar. La automatización vuelve a ejecutar cuando quien responde por el proceso lo aprueba, y la aprobación queda con su comentario.
La velocidad para apagar importa más que la velocidad para automatizar. La primera evita daño; la segunda sólo ahorra tiempo.
Los cuatro niveles de impacto, decididos antes de que usted edite
El motor de cambios de la plataforma no pregunta después qué tan grave fue lo que usted tocó. Lo sabe antes. Cada campo editable del sistema está clasificado en una tabla de reglas que vive en el código, y la clasificación se resuelve en tiempo de compilación, sin inferencia al momento.
Son 662 reglas de clasificación, contadas en el código: 2 en nivel bloqueado, 199 en nivel directo, 315 en nivel con efecto en cascada y 146 en nivel con aprobación. Un campo sin regla explícita cae al nivel directo por omisión, no a un limbo.
Nivel de impacto · qué hace el sistema · cuántas reglas
| Nivel | Nombre | Qué ocurre cuando alguien lo edita | Reglas |
|---|---|---|---|
| 0 | Bloqueado | El campo está deshabilitado en pantalla y no genera solicitud. Es el caso de lo que no se toca sin rehacer el expediente | 2 |
| 1 | Directo | Se aprueba solo y el cambio se aplica. Queda solicitud registrada y aplicada, con usuario y hora | 199 |
| 2 | Directo con efecto en cascada | Se aplica de inmediato y encola la tarea que propaga el efecto al resto del sistema | 315 |
| 3 | Con aprobación | La solicitud queda pendiente y el campo se bloquea con un indicador en pantalla hasta que el responsable aprueba o rechaza | 146 |
Fuente: niveles declarados; conteo por nivel verificado · 27 de septiembre de 2026.
Las tres reglas que gobiernan el comportamiento están escritas y son verificables. Bloqueo visual: si un campo tiene una solicitud pendiente, el control queda deshabilitado y muestra el indicador de espera, de modo que dos personas no pidan lo contrario sobre el mismo dato. Detección automática: el nivel de impacto se determina en compilación. Reversión incorporada: la escritura sobre la tabla de origen lleva el valor original, y es el motor el que aplica el valor nuevo cuando corresponde — por eso un cambio pendiente no deja el expediente a medias.
Traducido a este sistema: el umbral a partir del cual una automatización requiere aprobación para ejecutar por sí sola no es un campo cualquiera. Es un campo de nivel con aprobación, y por eso, mientras la solicitud está pendiente, nadie más puede moverlo.
Los tipos de cambio: quién lo pide, qué hace el sistema, qué registro queda
Ésta es la tabla que sostiene la afirmación del titular. Cada fila es un tipo de cambio que el sistema trata de manera distinta, con la tarea del motor que lo ejecuta cuando hay efecto en cascada y el registro que queda al terminar. Las primeras cuatro filas son las propias de un sistema que observa trabajo y ejecuta tareas; las demás son las del sistema de negocio sobre el que observa.
Tipo de cambio · quién lo pide · qué hace el sistema · qué registro queda
| Tipo de cambio | Ejemplo en su operación | Quién lo pide | Qué hace el sistema | Qué registro queda |
|---|---|---|---|---|
| Apagado de una automatización | El portal de la paquetería movió un campo y la captura automática empezó a llenar mal | Quien responde por el proceso, en su propia pantalla | Deja de ejecutar y devuelve la tarea al operador con la sugerencia en pantalla | Solicitud aplicada con usuario y hora, y el momento exacto en que dejó de ejecutar |
| Degradación a sugerencia y reaprendizaje | La operación cambió un paso y conviene que el operador vuelva a validar cada uno | Quien responde por el proceso | Mantiene la indicación en pantalla y suspende la ejecución; cada confirmación del operador vuelve a enseñar la secuencia | Solicitud aplicada y la secuencia nueva con su fecha de aprendizaje |
| Cambio del umbral de aprobación | A partir de qué frecuencia o de qué tiempo ahorrado una tarea puede ejecutarse sola sin confirmación | Lo pide quien opera; lo aprueba quien responde por el proceso | Deja la solicitud pendiente y bloquea el campo en pantalla hasta la decisión | Solicitud con comentario obligatorio del aprobador, y su estado: aprobada o rechazada |
| Exclusión de la observación | Una aplicación, un horario o un puesto que queda fuera del alcance por política de privacidad | Quien administra, con la conformidad de quien fijó la política | Aplica la exclusión y propaga el efecto al resto de la configuración | Solicitud aplicada, tarea de propagación encolada y notificación |
| Dato de configuración de nivel directo | El catálogo de tareas del sector que el sistema reconoce; el nombre de un puesto | El responsable del proceso, en su propia pantalla | Clasifica, aprueba solo y aplica el valor | Solicitud registrada y marcada como aplicada, con usuario y hora |
| Alta de un artefacto nuevo | Una pantalla para un proceso que antes no se observaba; una entidad para un documento que el cliente empezó a pedir | El responsable del proceso, con la aprobación de quien responde por el sistema | Inserta el artefacto —pantalla, entidad o relación— en el proyecto existente | Solicitud, artefacto dado de alta con su identificador y notificación |
| Renombrado con propagación | Un puesto pasa a llamarse como lo llama su empresa, y el nombre tiene que cambiar en todas las pantallas | Quien responde por el sistema | Propaga el nombre nuevo a todos los textos del proyecto que lo referencian, sin intervención de un modelo de lenguaje | Solicitud aplicada y registro de los campos alcanzados |
| Cambio en una matriz de estado | Un estado nuevo en el ciclo de vida del embarque, o un rol que deja de poder mover un estado | Quien responde por el proceso, con aprobación | Da de alta el estado o la transición y ajusta el permiso por rol y estado | Solicitud, estado o transición dados de alta y la matriz con su versión |
| Baja en cascada | Se retira un proceso observado o un puesto que dejó de existir en la organización | Quien responde por el sistema | Elimina en cascada el artefacto aprobado y lo que dependía de él | Solicitud aplicada y notificación |
| Cambio bloqueado | El registro histórico de una observación ya cerrada | Nadie: el campo no es editable | El control está deshabilitado en pantalla y no genera solicitud | No hay cambio, y por eso no hay duda sobre el registro |
| Cambio con efecto en el código | Una pantalla que cambia de campos porque el proceso observado cambió de forma | El responsable del proceso | Ejecuta comprobación previa, respaldo, el cambio y el posproceso; y donde toca, regenera la capa de datos, los servicios y la pantalla | Instantánea de versión de la pantalla, con número de versión consultable |
Fuente: tareas de gestión de cambios del motor y recorrido completo de un cambio:539-586 · los ejemplos de operación provienen del brochure de Relevo · 27 de septiembre de 2026.
Once tipos de cambio, once registros distintos. Ninguno de los once se cotiza.
Qué pasa, paso por paso, cuando alguien cambia algo
El recorrido está documentado y es el mismo para todos los niveles; lo que cambia es dónde se detiene. Se describe lo que ocurre, en orden, sin decir cuánto tarda.
Nadie abrió un ticket. Nadie cotizó. Y aun así hay expediente: solicitud, decisión, comentario, respaldo, versión y notificación.
- La pantalla pregunta antes de dibujarse. Al abrir, consulta qué campos tienen solicitud pendiente y los deshabilita con su indicador.
- Al guardar, el cambio se intercepta. La operación registra el cambio como tal, y la escritura sobre la tabla de origen lleva el valor original.
- El motor clasifica. Devuelve nivel de impacto, tarea de cambio asociada y tipo de operación.
- Se crea la solicitud. Auto-aprobada en los niveles directos, pendiente en el nivel con aprobación.
- Se decide. En los niveles directos, el propio sistema. En el nivel con aprobación, el responsable desde la pantalla de gestión de cambios, que aprueba o rechaza.
- El procedimiento aplica el cambio. Lee la solicitud, escribe sobre la tabla correspondiente, pasa la solicitud a aprobada, si el cambio tiene efecto en cascada, encola la tarea que lo propaga.
- Se ejecutan los efectos. Comprobación previa, respaldo, cambio, posproceso y —cuando el cambio lo exige— regeneración de la base, de los servicios y de las pantallas afectadas.
- Queda la versión. Se calcula el número de versión nuevo y se guarda la instantánea, consultable después por pantalla.
Los ocho estados de una solicitud de cambio, transcritos del motor
Una solicitud de cambio es una entidad con estados, no un correo. El catálogo de estados tiene ocho entradas, y aquí están transcritas tal como el sistema las tiene.
Un detalle que conviene decir porque circula al contrario: no existe un estado «revertido» en el catálogo del motor. Son ocho estados y ninguno es ése. Aparece mencionado en material interno de trabajo y no está en la base. La reversión se sostiene de otra manera, y la sección siguiente dice cómo.
Los ocho estados de una solicitud de cambio
| # | Estado | Qué significa en la práctica |
|---|---|---|
| 1 | Por analizar | La solicitud existe y espera clasificación |
| 2 | Analizando | El motor está resolviendo nivel de impacto y efectos |
| 3 | Por aprobar | Espera la decisión del responsable; el campo está bloqueado en pantalla |
| 4 | Aprobada | La decisión está tomada y el cambio va a escribirse |
| 5 | Rechazada | La decisión fue no, con su comentario |
| 6 | Por aplicar cambios | Aprobada y en cola de aplicación |
| 7 | En proceso de aplicación de cambios | Hay una tarea de propagación corriendo |
| 8 | Cambios aplicados | El cambio está en el sistema, con su instantánea de versión |
Transcrito del motor de la casa, tabla cat_estado_cambio, consultada el 27 de septiembre de 2026. El recorrido documentado del caso frecuente es 1 → 3 → 4 → 7 → 8, con 5 como salida de la decisión.
Cómo se revierte, entonces, si no hay estado de reversión
Con dos cosas que sí existen y están citadas. La primera es el respaldo del artefacto: todo cambio aplicado sobre un sistema en operación pasa por una comprobación previa, un respaldo de lo que se va a tocar, el cambio y el posproceso. La segunda es la instantánea de versión: al terminar se calcula el número de versión nuevo y se guarda la instantánea, consultable después por pantalla.
Hay una tercera pieza que vale nombrar porque resuelve el caso a medias: la escritura sobre la tabla de origen lleva el valor original, y es el motor el que aplica el valor nuevo cuando corresponde. Por eso una solicitud pendiente no deja el dato a medio cambiar: mientras nadie aprueba, lo que está en la tabla es lo de antes.
Dicho con precisión y sin adornar: la reversión no es un botón único que deshace un cambio en un solo movimiento. Es el respaldo más la instantánea de versión más el valor original conservado. Con esas tres piezas se puede volver atrás, y la vuelta atrás deja su propio registro, porque es a su vez un cambio. Quien le prometa un botón de deshacer sin decirle qué guarda antes de aplicar le está prometiendo algo que no puede enseñar.
Un cambio que no se puede deshacer no es un cambio en la sesión: es una apuesta. Aquí lo que sostiene la vuelta atrás es el respaldo, no la esperanza.
Qué se verificó, con su fecha
La afirmación «los cambios se hacen en la sesión» sólo vale si alguien la probó campo por campo. La verificación de cobertura del motor de cambios existe, está fechada y dice lo siguiente.
Verificación de cobertura del motor de cambios
| Qué se verificó | Resultado | Fecha y origen |
|---|---|---|
| Campos editables recorridos de extremo a extremo | 229 campos en 63 entidades, con cero errores | 31 de mayo de 2026 |
| Reparto de esos campos por comportamiento | 175 se aprueban solos · 52 quedan pendientes de aprobación · 2 están bloqueados | 31 de mayo de 2026 |
| Corrida anterior, para comparar | 174 campos, cero errores | 30 de mayo de 2026 |
| Reglas de clasificación en el código | 662 reglas: 2 bloqueadas, 199 directas, 315 con cascada, 146 con aprobación | Conteo en código |
| Pantallas del portal con el motor integrado y pantallas sin él | Inventario con sus huecos nombrados: dos pantallas con regla declarada y sin integración de pantalla, y 31 pantallas fuera del motor por diseño | Verificación interna de cobertura |
Fuente: verificación interna de cobertura del motor de cambios de la plataforma, con las fechas indicadas.
Se publica también el hueco, porque un inventario que sólo lista lo que funciona no es un inventario. Hay pantallas del portal cuya regla de clasificación existe en el código sin la integración correspondiente en la pantalla, y hay pantallas que quedan fuera del motor por decisión de diseño. Están nombradas una por una en el inventario interno, con su fecha.
229 campos probados, cero errores, y los huecos con nombre. Eso es una verificación; lo demás es una promesa.
Lo que no se publica, aunque exista en el material técnico
Hay dos cifras que circulan en el material técnico interno del motor de cambios y que esta página no publica. Se dice que existen, se dice qué son y se dice por qué no se publican, porque callarlas sin explicación dejaría el hueco abierto para que alguien las repita en una reunión.
La primera es un tiempo medio por cambio aplicado. La segunda es un porcentaje de cobertura. Las dos son estimaciones hechas sin instrumentación: no salen de una medición sobre el sistema corriendo, con su método y su muestra, sino de un cálculo de trabajo. Una cifra así no cumple la regla de esta capa, que es que ninguna cifra se publica sin fuente y sin fecha de verificación.
Lo que sí se publica es lo que está contado en el código y lo que está fechado en una corrida de verificación: las 662 reglas con su reparto por nivel, los 229 campos recorridos en 63 entidades con cero errores el 31 de mayo de 2026, los ocho estados del catálogo de la solicitud y los huecos del inventario con su nombre. Con eso alcanza para sostener la afirmación, y no hace falta más.
Cifras del material interno · por qué no se publican
| Cifra | Qué pretende decir | Por qué no se publica |
|---|---|---|
| Tiempo medio de aplicación de un cambio | Que aplicar un cambio es cuestión de un instante | Es una estimación sin instrumentación: no hay medición sobre el sistema corriendo con su método y su muestra. Publicarla sería prometer un plazo |
| Porcentaje de cobertura del motor | Que la mayor parte de los campos editables está dentro del motor | Es una estimación derivada de un conteo de trabajo, no de una corrida fechada. Lo que sí se publica es el inventario con sus huecos nombrados |
| Cualquier plazo de puesta en marcha | Que el sistema está listo en tal o cual término | Esta capa no promete plazos, y hay una razón de mercado para decirlo: ningún competidor de estos productos publica plazo de puesta en marcha. No es un dato que falte; es que la categoría no lo publica |
Criterio editorial de esta capa: ninguna cifra sin fuente y fecha de verificación · la ausencia de plazos publicados en la categoría se midió sobre las páginas públicas de los competidores el 27 de septiembre de 2026.
El contraste, que es sobre el modelo de contratación
Aquí no se compara la calidad de ningún producto ajeno. Se compara el modelo con el que se contrata, que es lo que decide cuánto le cuesta a usted cambiar de opinión. La diferencia no está en las funciones: está en qué pasa el día que el portal de la paquetería mueve un campo.
Qué ocurre el día que el proceso cambia, según el modelo
| Situación | Con automatización licenciada y programada | Con este modelo |
|---|---|---|
| El portal ajeno mueve un campo | La automatización se rompe o captura mal. Se abre un incidente y se espera la atención del proveedor o del socio que la programó | Quien responde por el proceso la apaga o la degrada a sugerencia en su propia pantalla, y la corrección queda registrada |
| El proceso interno cambia un paso | El cambio de secuencia es trabajo de quien programó el robot: cotización, aprobación, calendario y prueba | El operador confirma la secuencia nueva mientras trabaja y el sistema la vuelve a aprender |
| Hay que cambiar quién aprueba qué | Suele requerir intervención del proveedor sobre la configuración | Es un campo de nivel con aprobación: se pide, se aprueba con comentario y queda en bitácora |
| Hay que excluir una aplicación de la observación | Depende del alcance contratado; ampliarlo o reducirlo es una modificación del contrato | Es una edición con propagación: aplica y encola la tarea que ajusta el resto de la configuración |
| Se quiere volver atrás | Hay que pedir la restauración a quien opera el sistema | El respaldo del artefacto y la instantánea de versión existen por cada cambio aplicado, y la vuelta atrás deja su propio registro |
| Quién decide el orden de lo que se cambia | El calendario del proveedor y la prioridad de su cartera de clientes | Quien responde por el proceso, en la sesión |
Contraste sobre el modelo de contratación —licenciamiento, órdenes de cambio y dependencia de consultoría—, no sobre la calidad de ningún producto ajeno · insumo de mercado verificado el 27 de septiembre de 2026.
La pregunta que conviene hacerle a cualquier proveedor de automatización es una sola: «cuando esto se rompa porque mi proceso cambió, ¿lo apago yo o lo apaga usted?». La respuesta describe el contrato entero.
Preguntas frecuentes
¿Qué pasa si una automatización empieza a fallar porque el proceso cambió?
Se apaga o se degrada a sugerencia desde la pantalla de quien responde por el proceso, sin abrir un ticket. La automatización deja de ejecutar, la tarea vuelve al operador con la indicación en pantalla, y cada confirmación del operador vuelve a enseñar la secuencia nueva. Rehabilitarla es una aprobación con comentario. Los cuatro movimientos quedan registrados con usuario y hora.
¿Todos los cambios se aplican solos?
No, y eso es el control. Cada campo editable está clasificado en uno de cuatro niveles antes de que nadie lo toque: 2 reglas en nivel bloqueado, 199 directas, 315 con efecto en cascada y 146 con aprobación, sobre un total de 662 reglas en el código. En el nivel con aprobación, la solicitud queda pendiente y el campo se bloquea en pantalla hasta la decisión.
¿Se puede deshacer un cambio?
Sí, y conviene saber con qué. No hay un estado «revertido» en el catálogo del motor: son ocho estados y ninguno es ése. La vuelta atrás se sostiene con el respaldo del artefacto que se tocó y la instantánea de versión que queda al aplicar, más el valor original que la escritura conserva. La vuelta atrás deja su propio registro, porque es a su vez un cambio.
¿Cuánto tarda un cambio?
Esta página no publica plazos, y la razón es que las cifras de tiempo que existen en el material técnico interno son estimaciones sin instrumentación. Lo que sí se puede afirmar, con su fecha, es que se recorrieron 229 campos editables en 63 entidades con cero errores el 31 de mayo de 2026. Conviene añadir un dato de mercado: ningún competidor de estos productos publica plazo de puesta en marcha.
¿Puedo cambiar una matriz de estado o un permiso por rol?
Sí. Un estado nuevo, una transición nueva o un cambio en quién puede mover un estado entran por el mismo motor: se clasifica el impacto, se aplica o se pide aprobación según el nivel, y queda solicitud, comentario, respaldo e instantánea de versión. Las matrices actuales están transcritas en las matrices de estado, con las 213 transiciones del proyecto.
¿Quién puede pedir un cambio, y quién lo aprueba?
Depende del nivel del campo. En los niveles directos lo pide y lo aplica quien responde por el proceso, desde su propia pantalla. En el nivel con aprobación lo pide quien opera y lo aprueba quien responde por el proceso, con comentario obligatorio. Los campos bloqueados no son editables por nadie. Y todo cambio de configuración de la observación queda en bitácora, por la razón que explica la página de seguridad y privacidad.
Referencias
- Motor de cambios del motor de la casa: (662 reglas de clasificación y su reparto por nivel), (niveles:51-58, bloqueo visual:19, detección en compilación:20, valor original conservado:21, consulta al abrir la pantalla:62-70, intercepción al guardar:78-112, creación de la solicitud:137-164, aplicación:172-205, decisión:244-262, efectos:264-289, instantánea de versión:291-307, recorrido del caso frecuente:209-241). Verificado el 27 de septiembre de 2026.
- Verificación interna de cobertura del motor de cambios: 229 campos en 63 entidades, cero errores, 31 de mayo de 2026; 174 campos, 30 de mayo de 2026; y huecos nombrados.
- Motor el motor de la casa, base del motor de la casa: catálogo cat_estado_cambio, ocho estados de una solicitud de cambio, consultado el 27 de septiembre de 2026. No existe un estado «revertido» en el catálogo.
- Tareas de gestión de cambios del motor y recorrido completo de un cambio, con respaldo del artefacto e instantánea de versión. Verificado el 27 de septiembre de 2026.
- Relevo · brochure de logística, 10 páginas: el ciclo de medir, aprender, sugerir y ejecutar, y las tareas del sector que el sistema reconoce. Origen de los ejemplos de operación de esta página.
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.