AgriNet · los cambios
El cambio no es un proyecto. Es un estado del sistema, con su registro.
Su cliente cambió la ventana de andén, el esquema de certificación sacó versión nueva y el comprador pide un campo más en la ficha técnica. En el modelo con el que se le vendió, cada una de esas tres cosas es una orden de cambio. Aquí es una edición con su bitácora.
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 comprador 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 la agroindustria de exportación ese modelo choca con un hecho: su norma se mueve todos los años. El esquema de certificación saca versión nueva, el criterio de agua agrícola cambia de análisis a evaluación sistémica, la lista oficial de alimentos cubiertos da de alta un grupo de producto, el complemento fiscal del traslado pasa de una versión a otra sin convivencia. Un sistema que cobra por cambiar es un sistema que se queda atrás de su propia industria.
Cuando pedir un cambio cuesta, el sistema deja de reflejar la operación. Y entonces el que decide vuelve a decidir con la hoja de cálculo.
El pretexto no es tecnológico
Lo que cambia en su operación, en un año cualquiera
Antes de hablar del motor, conviene ver la lista de cambios reales que la agroindustria de exportación absorbió en los últimos ejercicios. Ninguno es una idea de mejora: todos son obligaciones con fecha, que alguien tuvo que meter a un sistema.
Cambios con fecha que su sistema tuvo que absorber
| Cambio | Fecha | Qué toca dentro del sistema |
|---|---|---|
| Complemento Carta Porte 3.1 obligatorio, sin convivencia con la 3.0 | 17 de julio de 2024 | Campos del registro de salida, emisión del comprobante, validación previa a la salida del CEDIS |
| IFS Food versión 8 obligatoria | enero de 2024 | Requisitos del esquema, evidencia exigida por cláusula, catálogo de certificados |
| Auditorías de frutas y hortalizas sólo contra GLOBALG.A.P. IFA v6 | 1 de enero de 2025 | Lista de verificación, plan de mejora continua basado en datos, preparación para auditoría no anunciada |
| Criterio de agua agrícola pre-cosecha: de análisis a evaluación sistémica | granjas grandes, abril de 2025; pequeñas, abril de 2026; muy pequeñas, abril de 2027 | La entidad de evaluación de agua, su periodicidad y el disparo por cambio significativo |
| Monitoreo de residuos de exportación de 225 a 320 analitos | 2024 | Catálogo de analitos, umbrales y expediente de laboratorio por embarque |
| FSSC 22000 versión 7 publicada | mayo de 2026; auditorías contra la v6 permitidas hasta el 30 de abril de 2027 | Requisitos del esquema y vigencia del certificado en el tablero |
| Sello de Buenas Prácticas Agrícolas de Perú aprobado | noviembre de 2025 | Un régimen más en el motor de cumplimiento por mercado destino |
| Alta de un grupo de producto en la lista oficial de alimentos cubiertos | las altas surten efecto dos años después del segundo aviso | El atributo que decide si un producto de su catálogo exige datos clave en cada evento crítico |
Fuente: 21 CFR Part 1 Subpart S y su lista oficial; regla final de agua agrícola pre-cosecha de la FDA (2024); GLOBALG.A.P. IFA v6; IFS Food v8; FSSC 22000 v7; SAG de Chile; SENASA de Perú; SAT · complemento Carta Porte 3.1 · verificado al 27 de septiembre de 2026
Ocho cambios obligatorios en tres ejercicios. En un modelo de órdenes de cambio, eso son ocho cotizaciones.
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 (conteo verificado). Un campo sin regla explícita cae al nivel directo por omisión, no a un limbo.
Nivel de impacto · qué hace el sistema
| 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, sin tarea posterior | 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.
Los tipos de cambio: quién lo pide, qué hace el sistema, qué registro queda
Esta es la tabla que sostiene la afirmación de la portada. 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.
La primera fila —el dato de configuración que el responsable del proceso cambia en su propia pantalla— se ve así en un sistema ya generado:
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 |
|---|---|---|---|---|
| Dato de configuración de nivel directo | El umbral de temperatura de una cámara; la tarifa pactada contra la que se audita el flete | 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 |
| Cambio de configuración con propagación | El catálogo de mercados destino de un producto; el país al que se exporta una línea | El responsable del proceso | Aplica el valor y encola la tarea de configuración incremental, que ajusta el proyecto sin regenerarlo | Solicitud aplicada, tarea de cambio encolada y notificación informativa al proyecto |
| Alta de un artefacto nuevo | Una pantalla para el nuevo esquema de certificación; una entidad para el analito que el país destino agregó | El responsable del proceso, con la aprobación del responsable del 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 | El rol «Responsable de inocuidad» pasa a llamarse como lo llama su empresa | El responsable del 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 |
| Baja en cascada | Se retira un país destino o un rol que dejó de existir en la organización | El responsable del sistema | Elimina en cascada el artefacto aprobado y lo que dependía de él | Solicitud aplicada y notificación informativa |
| Cambio con aprobación | El umbral de una regla de liberación de producto; el criterio con el que se descarta un lote | 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 |
| Cambio bloqueado | La llave del expediente de un lote ya embarcado | 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 expediente |
| Cambio con efecto en el código | Una pantalla que cambia de campos porque el comprador pide un dato más en la ficha técnica | 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 el recorrido completo de un cambio:539-586 · los ejemplos de operación provienen del brochure de AgriNet · 27 de septiembre de 2026
Ocho tipos de cambio, ocho registros distintos. Ninguno de los ocho 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.
La matriz de estados de una solicitud de cambio
Una solicitud de cambio es una entidad con estados, no un correo. El catálogo de estados está en la base del motor y tiene ocho entradas, transcritas aquí tal como están, consultadas el 27 de septiembre de 2026.
Un detalle que conviene decir porque circula al contrario: no existe un estado «revertido» en el catálogo del motor. Aparece mencionado en material interno de trabajo, y no está en la base. La reversión se sostiene con el respaldo del artefacto y la instantánea de versión, que sí existen y se citan más arriba, no con un estado de la solicitud.
Los ocho estados de una solicitud de cambio, transcritos del motor
| # | 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.
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.
Por qué no hay orden de cambio
La respuesta no es comercial, es estructural. La orden de cambio existe para resolver cuatro incógnitas: qué tan grave es el cambio, quién tiene que autorizarlo, qué más se rompe y cuánto cuesta el trabajo de aplicarlo. En este sistema las cuatro están resueltas antes de que usted abra la pantalla.
Lo único que queda del ciclo tradicional es la parte que sí es suya: la decisión de negocio sobre si el cambio debe hacerse.
- La gravedad no se estima: está clasificada. 662 reglas en el código dicen el nivel de impacto de cada campo, decidido en compilación. No hay una junta que lo dictamine.
- La autorización no es un comité: es un estado. Los 146 campos de nivel con aprobación la piden dentro del sistema, a quien responde por el proceso, con comentario obligatorio. Los otros no la necesitan porque su efecto ya está acotado.
- Lo que se rompe no se investiga: se propaga. Las tareas de configuración incremental, alta de artefacto, renombrado con propagación y baja en cascada existen precisamente para eso, y son parte del motor, no de un proyecto aparte.
- El trabajo de aplicarlo no se cotiza porque no se hace a mano. Donde el cambio toca el código, el propio motor regenera la capa de datos, los servicios y la pantalla, y guarda la versión. No hay horas de consultoría que facturar porque no hay horas de consultoría.
Dicho al revés, que es como se entiende mejor: no es que hayamos decidido no cobrar por los cambios. Es que el cambio dejó de ser un entregable. Y cuando el cambio no es un entregable, no hay nada que facturar por entregarlo — por eso el trato es cobrar por resultados.
El contraste, en términos del modelo de contratación
La comparación que sigue no habla de la calidad de ningún producto ajeno. Habla del modelo con el que se contrata, que es lo que determina qué le pasa a usted el día que su industria cambia una regla.
El mismo cambio, dos modelos de contratación
| Cuando cambia una regla de su industria | En un sistema licenciado, con órdenes de cambio | En AgriNet |
|---|---|---|
| Quién decide si se puede hacer | El proveedor, tras un análisis de viabilidad que se contrata | Está decidido: el campo tiene su nivel de impacto en el código |
| Quién autoriza | Un comité de control de cambios, con acta | El responsable del proceso, dentro del sistema, con comentario obligatorio |
| Qué se firma antes de empezar | Cotización, alcance y calendario | Nada. La solicitud es el registro, y la genera el propio sistema |
| Quién ejecuta | Consultoría, propia o de un socio implementador | El motor, con sus tareas de propagación y regeneración |
| Qué pasa con los demás módulos | Se investiga el impacto y se cotiza aparte | La propagación es parte del tipo de cambio: renombrado, alta, baja en cascada |
| Cómo se prueba | Un ciclo de pruebas contratado | Comprobación previa y posproceso dentro del recorrido; el sistema deja la versión |
| Qué queda documentado | El acta del comité y la orden firmada | Solicitud, estado, comentario, respaldo, instantánea de versión y notificación |
| Qué pasa si sale mal | Una orden de cambio nueva | El respaldo del artefacto y la instantánea de versión anterior existen desde antes de aplicar |
| Qué aprende su empresa | A no pedir | A pedir, porque pedir no cuesta |
Comparación sobre el modelo de contratación, no sobre la calidad de ningún producto ajeno · 27 de septiembre de 2026
El que cobra por cada cambio tiene un incentivo que usted no comparte: que su operación no se parezca al producto.
Lo que esta página no le promete
Aquí no aparece ningún número de días, de horas ni de milisegundos, y la razón se dice completa: en el material técnico de la plataforma existen cifras de latencia del motor de cambios, y al revisarlas resultaron ser estimaciones escritas en un diagrama, sin instrumentación, sin entorno de medición, sin percentil y sin fecha. Una cifra así no se publica.
Tampoco se publica un porcentaje de cobertura que circula en el mismo material, porque su aritmética no cuadra con el universo de campos verificado. Lo que sí se publica es lo que se contó: 662 reglas en el código, 229 campos recorridos con cero errores el 31 de mayo de 2026, y el reparto entre los que se aprueban solos, los que esperan aprobación y los que están bloqueados.
Y queda una distinción que conviene no perder. «En la sesión» describe dónde ocurre el cambio —dentro del sistema, en la pantalla donde se trabaja, sin salir a un proceso paralelo—, no cuánto tarda el reloj. Lo que se compromete es que no hay una orden de cambio entre su decisión y el sistema. El resto lo verá usted mismo cuando lo tenga enfrente.
Se describe lo que ocurre. No se compromete un número de días.
Preguntas frecuentes
¿De verdad no hay órdenes de cambio, o es una forma de hablar?
No las hay porque el cambio no es un entregable que alguien tenga que producir a mano. Cada campo editable está clasificado en uno de cuatro niveles de impacto por una tabla de 662 reglas en el código; la autorización, cuando hace falta, es un estado de la solicitud dentro del propio sistema; y la propagación al resto del sistema la ejecuta el motor con sus tareas de configuración incremental, alta de artefacto, renombrado y baja en cascada.
¿Entonces cualquiera puede cambiar cualquier cosa?
No. Dos campos están en nivel bloqueado y no son editables por nadie; 146 exigen aprobación del responsable, con comentario obligatorio, y mientras esperan, el campo queda deshabilitado en pantalla con su indicador (regla de bloqueo visual). El control no desapareció: dejó de ser un trámite externo para ser una decisión registrada dentro del sistema.
¿En cuánto tiempo queda aplicado un cambio?
No publicamos un plazo, y decimos por qué: las cifras de tiempo que existen en el material técnico interno son estimaciones escritas en un diagrama, sin instrumentación ni entorno de medición. Lo que sí está verificado es el recorrido —solicitud, clasificación, decisión, aplicación, propagación, versión— y que 229 campos se recorrieron de extremo a extremo con cero errores el 31 de mayo de 2026. El plazo lo comprobará usted en el sistema, no en esta página.
Si el cambio toca una pantalla, ¿alguien programa?
El motor regenera. Donde el cambio exige tocar la capa de datos, los servicios o la pantalla, el recorrido incluye comprobación previa, respaldo, el cambio, el posproceso y la regeneración de la base, de los servicios y de las pantallas afectadas, y termina guardando una instantánea de versión consultable.
¿Qué pasa si el cambio sale mal?
El respaldo del artefacto y la instantánea de versión se producen dentro del propio recorrido, antes y después de aplicar, no como un trámite aparte. Lo que no existe es un estado «revertido» de la solicitud: el catálogo de estados del motor tiene ocho entradas y ninguna es ésa (cat_estado_cambio, consultada el 27 de septiembre de 2026). La reversión se sostiene con el respaldo y la versión, no con un estado.
¿Cuándo sí tengo que hablar con alguien de la casa?
Cuando el cambio no es de configuración sino de criterio de negocio: un proceso que su empresa decide operar distinto, una norma nueva de un mercado destino al que no exportaba, un esquema de certificación que se incorpora por primera vez. Esa conversación es sobre el negocio y no se factura como orden de cambio: el trato es cobrar por resultados, no por entregables.
Referencias
- FDA · Food Traceability Rule, 21 CFR Part 1 Subpart S, y su Food Traceability List. Las altas de grupos de producto surten efecto dos años después del segundo aviso. Consultada el 27 de septiembre de 2026. ↗
- FDA · regla final de agua agrícola pre-cosecha (2024): sustituye criterios de análisis por evaluaciones sistémicas, con calendario de abril de 2025, abril de 2026 y abril de 2027 según el tamaño de la granja. Consultada el 27 de septiembre de 2026. ↗
- GLOBALG.A.P. · Integrated Farm Assurance v6: desde el 1 de enero de 2025 toda auditoría de frutas y hortalizas se hace contra v6 Smart o v6 GFS. Consultada el 27 de septiembre de 2026. ↗
- Foundation FSSC · FSSC 22000: versión 7 publicada en mayo de 2026; auditorías contra la versión 6 permitidas hasta el 30 de abril de 2027. Consultada el 27 de septiembre de 2026. ↗
- SAT · Complemento Carta Porte versión 3.1, obligatoria desde el 17 de julio de 2024 sin convivencia con la versión 3.0. Consultado el 27 de septiembre de 2026. ↗
- Evidencia de plataforma: motor de cambios del motor de la casa — 662 reglas de clasificación y su reparto por nivel; niveles de impacto, recorrido y estados de la solicitud; verificación de cobertura, 30 y 31 de mayo de 2026; y inventario y huecos. Recogidas con cita de archivo y línea en el expediente interno. Verificado el 27 de septiembre de 2026.
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 AgriNet 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.