COCO vuelve a la carga
Probablemente deberíamos dejar de darle ideas a COCO.
El experimento anterior se suponía que iba a ser suficiente.
Una aplicación real.
Navegación real.
Usuarios.
Roles.
Bases de datos.
Idiomas.
Evidencia.
Un caso de estudio respetable.
Una conclusión limpia.
Entonces alguien lo mostró: Logistics in Motion.
Ese fue probablemente el error.
Empezó con tres almacenes
Nada particularmente emocionante.
Tres almacenes DEMO.
- Kalsdorf bei Graz.
- Wiener Neustadt.
- Klagenfurt.
Sin información de clientes.
Sin inventario de producción.
Exactamente el tipo de entorno donde se supone que no debe pasar nada importante.
Luego se seleccionó el primer almacén.
Y la aplicación adquirió contexto.
Desde ese momento, cada pantalla tenía otra pregunta asociada.
¿Esto sigue perteneciendo al mismo almacén?
¿El idioma cambia solo la interfaz?
¿El proceso permanece en el mismo paso?
¿El inventario sigue coincidiendo?
¿La referencia del documento sigue apuntando al evento correcto?
¿El operador ve exactamente lo que se necesita para la siguiente acción?
De repente, la parte interesante ya no era la pantalla.
Era la continuidad entre pantallas.
COCO tiende a hacer eso.
La logística no es una colección de pantallas
Desde fuera, el software de almacén puede parecer engañosamente simple.
La mercancía llega.
Se almacena.
Alguien la pide.
Se recoge.
Se envía.
Hecho.
Excepto que hay todo un mundo operativo escondido entre llegado y enviado.
Esperado.
Recibido.
Verificado.
Disponible.
Reservado.
Movido.
Recogido.
Bloqueado.
Corregido.
Despachado.
Auditado.
El movimiento físico importa.
Pero es la transición de estado lo que hace que ese movimiento sea comprensible para el software.
Y cuando esas dos realidades dejan de coincidir, alguien acaba teniendo un mal día.
Un almacén es más fácil de entender cuando el movimiento es visible, no solo registrado.
Por eso nuestro trabajo de logística nunca realmente empezó con menús, paneles, o tecnología.
Empieza con el Flow material.
¿Dónde entra la información?
¿Dónde cambia?
¿Dónde se puede perder?
¿Dónde alguien se ve obligado a preguntarle a otra persona qué pasó?
¿Dónde un paso manual se convierte silenciosamente en la parte más débil de un proceso por lo demás automatizado?
A veces la respuesta es una nueva interfaz.
A veces una integración.
A veces un escáner.
A veces simplemente un mejor modelo de estado.
Más software no es automáticamente mejor software.
El objetivo no es la automatización por sí misma.
El objetivo es un proceso que permanezca comprensible.
Control. Clarity. Flow.
El proceso comienza antes del primer registro.
Antes de la recepción de mercancía.
Antes del picking.
Antes del movimiento de inventario.
Antes de la primera transacción.
Flow hace una pregunta muy básica:
¿En qué almacén estamos trabajando?
Suena casi trivial.
No lo es.
El contexto del almacén pertenece a todo lo que sigue.
Inventario.
Documentos.
Ubicaciones.
Picking.
Reubicaciones.
Historial de auditoría.
Excepciones.
El proceso puede parecer perfectamente saludable mientras opera en el contexto equivocado.
Ese es exactamente el tipo de problema que una captura de pantalla rara vez revela.
Y exactamente el tipo de límite que a COCO le gusta cuestionar.
El idioma es fácil hasta que no lo es
Alemán.
Inglés.
Croata.
Noruego.
Y otros.
Un perfil de usuario define los idiomas disponibles.
El operador cambia de idioma mientras la aplicación está activa.
La interfaz cambia inmediatamente.
El proceso de negocio no debe hacerlo.
Esa distinción importa.
El almacén no se mueve porque cambió la palabra para almacén.
El pedido de picking no se reinicia porque el usuario seleccionó otro idioma.
Una reserva no desaparece.
Una excepción no pertenece de repente a otra transacción.
El proceso permanece donde está.
Solo cambia su representación.
Eso suena obvio.
Hasta que te das cuenta de cuántas aplicaciones tratan un cambio de idioma casi como una nueva sesión.
Una aplicación de negocio multilingüe no debería hacerlo.
El estado de presentación puede cambiar.
El estado de negocio debe permanecer estable.
Eso hace que el cambio de idioma sea una prueba de regresión sorprendentemente útil.
Una pequeña función.
Una muy buena línea de falla.
A COCO le gustan las líneas de falla.
Paso a paso, la aplicación comienza a acumular historial
La mercancía llega.
El proceso avanza.
La recepción de mercancía se registra.
El inventario cambia.
El estado del almacén refleja la nueva realidad.
El picking comienza.
El stock se reserva.
El operador recibe una tarea.
Una vista móvil reduce todo el proceso a lo que importa en ese preciso momento:
Posición.
Ubicación de almacenamiento.
Cantidad.
SSCC.
Operador.
Nada más.
Nada menos.
Eso es importante.
La interfaz móvil no es un segundo proceso de negocio.
Es otra vista del mismo proceso.
La aplicación de almacén puede saberlo todo.
El operario de picking no debería tener que hacerlo.
Clarity no siempre significa mostrar más información.
A veces clarity significa tener la disciplina de ocultar casi todo.
Entonces alguien escanea la ubicación equivocada
Aquí es donde un flujo de trabajo logístico se vuelve más interesante que una lista de funciones.
La ubicación esperada es una cosa.
La ubicación escaneada es otra.
Flow se detiene.
No se bloquea.
Se detiene.
Hay una diferencia.
El estado del proceso permanece visible.
El stock afectado permanece comprensible.
La excepción se vuelve explícita.
La Ayuda contextual explica lo que es relevante para la situación actual.
El usuario resuelve la discrepancia.
El proceso continúa.
Este momento dice más sobre el software operativo que varias páginas de capturas de pantalla del camino ideal.
La logística real no es difícil cuando todo es correcto.
La logística real se vuelve difícil cuando algo es casi correcto.
Un sistema útil no oculta eso detrás de un panel verde.
Le da a la excepción un estado.
Una razón.
Un historial.
Y un camino a seguir.
Los documentos recuerdan lo que la gente olvida
A medida que el flujo de trabajo progresa, las referencias comienzan a acumularse.
ASN.
Recepción de mercancía.
Movimiento de almacén.
Picking.
Despacho.
Flow.
La parte interesante no es que los documentos existan.
La parte interesante es que cuentan la misma historia que el proceso.
¿Por qué está aquí este stock?
¿Qué recepción lo introdujo?
¿Qué operación lo reservó?
¿Qué picking lo consumió?
¿Qué envío lo sacó?
¿Se resolvió una excepción antes del siguiente paso?
¿Cuál era el almacén activo?
¿Qué pasó antes del estado actual?
Cuando el estado y la documentación son producidos por el mismo proceso, la trazabilidad se vuelve más fácil de confiar.
Cuando no lo son, la gente eventualmente comienza a reconstruir el historial.
Normalmente en Excel.
Normalmente bajo presión.
Normalmente después de que algo ya salió mal.
COCO prefiere la evidencia antes de ese momento.
Al parecer, COCO también viaja
Hubo otro pequeño cambio entre ejecuciones.
Ubuntu tuvo su turno.
Red Hat Enterprise Linux 10 tomó el siguiente.
COCO continuó.
Sin ceremonia.
Sin un "modo Red Hat" especial.
Sin flujo de trabajo reescrito.
Sin prueba convenientemente simplificada.
Mismo Flow.
Terreno diferente debajo.
Una ejecución anterior de COCO ya había puesto a prueba la aplicación en Ubuntu Linux.
La actual se movió a Red Hat Enterprise Linux 10.
Entorno de escritorio diferente.
Bibliotecas de sistema diferentes.
Empaquetado diferente.
Entorno operativo diferente.
Mismo almacén.
Mismos estados de negocio.
Mismas transiciones de inventario.
Mismos cambios de idioma.
Misma lógica de excepciones.
Misma evidencia.
Esa es una forma bastante buena de probar el software multiplataforma.
No anuncies que es multiplataforma. Muévelo. Luego mira qué se rompe.
Estado del idioma.
Contexto del almacén.
Comportamiento de los diálogos.
Tiempos.
Temas.
Transiciones de proceso.
Manejo de excepciones.
Evidencia.
Los sistemas operativos tienen formas sorprendentemente creativas de exponer suposiciones.
Ubuntu expuso algunas.
Red Hat está exponiendo otras.
Eso es útil.
Porque la ingeniería multiplataforma no es la capacidad de iniciar el ejecutable dos veces.
Es la capacidad de cambiar el entorno sin cambiar el significado del proceso.
A un operador de almacén no debería importarle si la aplicación se ejecuta en Ubuntu o Red Hat.
A un pedido de picking tampoco debería importarle.
Ni a un rastro de auditoría.
Si las diferencias de plataforma comienzan a cambiar el comportamiento del negocio, el software no es verdaderamente multiplataforma.
Es simplemente portátil.
COCO parece estar considerablemente más interesado en la primera definición.
Nosotros también.
COCO no decide qué significa logística correcta
Esta parte importa.
COCO no se convierte en un experto en almacenes simplemente porque puede seguir un flujo de trabajo de almacén.
Los humanos siguen definiendo la corrección.
Los humanos deciden cuándo el inventario se vuelve disponible.
Los humanos definen qué significa una entrega bloqueada.
Los humanos deciden quién puede corregir una cantidad.
Los humanos definen qué movimiento requiere un rastro de auditoría.
Los humanos deciden cómo se ve una resolución de excepción válida.
Los humanos deciden cuándo un envío está verdaderamente completo.
El trabajo de COCO es diferente.
Repetir.
Observar.
Comparar.
Recordar.
Dejar evidencia.
Luego hacerlo de nuevo después de que el software cambie.
Y otra vez.
Y otra vez.
Sin aburrirse.
Sin decidir que el resultado de la semana pasada probablemente todavía es válido.
Sin saltarse la excepción molesta porque el almuerzo es en doce minutos.
El glamoroso futuro de las pruebas con IA contiene una cantidad sorprendente de repetición.
Consideramos eso una característica.
La evidencia cambia la conversación
Las pruebas tradicionales a menudo terminan con una frase perfectamente razonable:
"Funcionó cuando lo probé."
COCO está interesado en la siguiente frase.
¿Qué exactamente funcionó?
¿Qué almacén?
¿Qué usuario?
¿Qué idioma?
¿Qué estado del proceso?
¿Qué secuencia?
¿Qué documento?
¿Qué valor de inventario?
¿Qué pasó inmediatamente antes del paso de prueba?
¿Qué cambió inmediatamente después?
¿Puede otro ingeniero entender el resultado sin preguntarle a la persona que realizó la prueba?
Ahí es donde las pruebas de regresión se convierten en algo más que clics repetidos.
Una pantalla puede ser correcta mientras el proceso está mal.
Una ventana de picking puede verse perfecta mientras el inventario ya se ha desviado.
Un documento puede existir mientras el estado que debería haberlo creado nunca ocurrió.
Una aplicación puede mostrar 100% mientras un rastro de auditoría silenciosamente discrepa.
COCO sigue el Flow porque es en el Flow donde estas contradicciones se vuelven visibles.
En algún lugar entre Control y Flow
Hay una simetría interesante aquí.
Un buen software de logística intenta reducir la incertidumbre dentro de una operación.
Unas buenas pruebas intentan reducir la incertidumbre sobre el software que las ejecuta.
Uno pregunta:
¿Dónde está el artículo?
El otro pregunta:
¿Cómo sabemos que el software todavía lo sabe?
Uno pregunta:
¿Se completó este movimiento?
El otro pregunta:
¿Qué evidencia demuestra que el estado cambió correctamente?
Uno pregunta:
¿Puede continuar el siguiente turno?
El otro pregunta:
¿Puede el siguiente ingeniero entender qué pasó?
Preguntas diferentes.
El mismo instinto.
Hacer visible el estado.
Preservar el razonamiento.
Reducir la cantidad de conocimiento que existe solo dentro de la cabeza de alguien.
Quizás esa es la conexión que originalmente no planeamos.
Excelencia en ingeniería sin la pancarta
Nadie hace clic en un botón de Engineering Excellence.
No hay ninguno.
Y probablemente no debería haberlo.
La excelencia en ingeniería aparece indirectamente.
El contexto del almacén sobrevive a un cambio de idioma.
El mismo proceso sobrevive a otra plataforma Linux.
Un movimiento de stock permanece trazable.
Un operario de picking móvil ve exactamente lo que se necesita y nada más.
Una excepción interrumpe el proceso sin destruir su estado.
La ventana de ayuda explica el contexto actual en lugar de mostrar documentación genérica.
La cadena de documentos concuerda con la secuencia operativa.
El siguiente ingeniero puede entender qué pasó sin preguntarle a la persona que casualmente estaba allí.
Hay mucho teatro disponible en el software moderno.
La IA puede generar demostraciones impresionantes.
Los paneles pueden animarse.
Los números pueden moverse.
Los videos pueden parecer muy convincentes.
Nada de eso prueba que dos operaciones de inventario no puedan producir silenciosamente un resultado incorrecto.
Nada de eso prueba que una excepción todavía pueda reconstruirse semanas después.
Nada de eso prueba que el trabajador de almacén, el despachador, y el desarrollador estén mirando la misma verdad operativa.
La excelencia en ingeniería comienza en un lugar menos fotogénico.
Con consistencia.
Con evidencia.
Con límites.
Con la voluntad de mantener aburridas las partes aburridas.
La fiabilidad invisible rara vez produce la captura de pantalla más dramática.
Hasta que empiezas a buscarla deliberadamente.
Control. Clarity. Flow.
Control es saber qué almacén, qué proceso, y qué estado están activos.
Clarity es entender qué cambió, cuándo cambió, y por qué.
Flow es permitir que la operación continúe sin perder la historia detrás de ella.
Eso funciona para la logística.
Funciona para las pruebas de software.
Funciona sorprendentemente bien para la ingeniería en sí misma.
El primer experimento Flow le dio a COCO la Administration.
Usuarios.
Roles.
Bases de datos.
Idiomas.
Luego alguien le dio un almacén.
Luego varios idiomas.
Luego el picking móvil.
Luego el inventario.
Luego las reubicaciones.
Luego las excepciones.
Luego los documentos.
Luego otro sistema operativo.
En este punto, probablemente deberíamos dejar de añadir cosas.
Probablemente no lo haremos.
Control. Clarity. Flow.
Ubuntu tuvo su turno.
Red Hat tiene el actual.
El Flow sigue moviéndose.
COCO sigue observando.
Y en algún lugar en medio de la última ejecución, se hizo evidente que hay otra pregunta esperando detrás de esta.
Sabemos qué es.
COCO sabe qué es.
Tú no lo sabes.
Todavía.
Podríamos decírtelo.
Pero entonces podrías dejar de comprobar si ha aparecido un nuevo artículo de Insiders.
Y eso arruinaría el experimento.
Publicado: 28.08.2026