3.2 Autoridad, excepciones y playback

Al terminar esta lección

• Asignar autoridad dato por dato (ERP, planilla, operador, responsable comercial) y registrarla en un mapa que después guíe el diseño.
• Distinguir variación normal, excepción, workaround y control compensatorio, y decidir qué conservar de cada uno: propósito, criterio o resultado.
• Reconstruir un pedido real con hora, rol, herramienta y fuente, marcando qué se observó y qué se relató.
• Separar carrera digital de discrepancia física de stock y priorizar fricciones con una muestra, no con la queja más fuerte.
• Validar la reconstrucción con el cliente mediante playback sobre episodios, buscando refutación.

3.8 No todas las fuentes tienen la misma autoridad

Una fuente puede ser muy confiable para una pregunta y pésima para otra. El ERP puede ser autoritativo para el SKU maestro y, al mismo tiempo, estar desactualizado respecto del stock físico. El Excel de comercial puede contener acuerdos válidos de precio, pero no ser confiable para saldo de cuenta corriente. La persona que prepara pedidos conoce mejor que nadie el quiebre físico, aunque quizá no tenga autoridad para definir la política de reservas. Por eso no existe una jerarquía universal del tipo “sistema > documento > persona”. La autoridad depende del dato o decisión que querés resolver.

En el dossier conviene escribir frases explícitas, una por dato. Este es el mapa de autoridad provisional de Nexo al llegar a esta etapa. Cada fila tiene fuente, dueño y qué falta confirmar:

1version: 2
2actualizado_con: [NOTA-01, DOC-01, DOC-03, EV-04]
3datos:
4  - dato: "Identidad de producto (SKU maestro, descripción)"
5    fuente_autoritativa_provisoria: "ERP legacy"
6    confianza: alta
7    pendiente: null
8  - dato: "Equivalencia entre SKU (A-184 → A-184B)"
9    fuente_autoritativa_provisoria: "Ninguna confirmada"
10    fuentes_en_uso: ["Excel personal de cada vendedor"]
11    pendiente: "¿Quién mantiene las equivalencias y desde cuándo rige cada una? (U-07, RN-04)"
12  - dato: "Precio de lista"
13    fuente_autoritativa_provisoria: "ERP legacy"
14    confianza: media   # los descuentos nuevos se cargan en el ERP, los históricos siguen en Excel
15  - dato: "Acuerdo especial de precio"
16    fuente_autoritativa_provisoria: "Responsable comercial, con vigencia a confirmar"
17    fuentes_en_uso: ["PRECIOS_ESPECIALES_2026.xlsx", "PDF de condiciones comerciales"]
18    pendiente: "Precedencia lista vs. acuerdo (U-02); qué hacer con acuerdos sin vencimiento."
19  - dato: "Saldo confirmado de cuenta corriente"
20    fuente_autoritativa_provisoria: "Sistema contable / ERP"
21  - dato: "Exposición de crédito (lo que se compara contra el límite)"
22    fuente_autoritativa_provisoria: "Ninguna única"
23    fuentes_en_uso: ["ERP (saldo)", "planilla de administración (comprometido)"]
24    pendiente: "Definición de exposición: DESCONOCIDO (U-01)."
25  - dato: "Stock disponible para prometer"
26    fuente_autoritativa_provisoria: "Ninguna única"
27    motivo: "onHand del ERP y físico pueden divergir; la reserva hoy está en una pizarra."

Si no sabés quién manda sobre un dato, tampoco sabés dónde debe calcularse ni qué entrada puede confiar el backend. Ese mapa no es burocracia: se vuelve, más adelante, la tabla que dice qué campos acepta la API del cliente y cuáles recalcula el servidor.

3.9 Diferenciar variación normal, excepción y workaround

Tres comportamientos distintos pueden verse igual desde afuera. Una variación normal forma parte del proceso esperado, como entrega por transportista o retiro en depósito. Una excepción es una desviación válida bajo condiciones explícitas, por ejemplo autorizar crédito por encima del límite. Un workaround es una maniobra que existe porque el proceso o sistema actual no soporta bien una necesidad, como mandar una captura por WhatsApp y luego corregir manualmente el ERP. Un cuarto tipo, que desarrollamos en 3.15, es el control compensatorio: una persona revisa algo porque otro mecanismo no es confiable. Para reconocerlo, preguntá qué riesgo evita la tarea y qué pasaría si desapareciera mañana: si protege contra un dato en el que nadie confía, probablemente sea un control compensatorio. Automatizar los cuatro del mismo modo suele consolidar defectos históricos o eliminar una protección importante.

La pregunta de campo es: “si mañana pudiéramos cambiar la herramienta sin costo, ¿seguirían queriendo hacer esto?”. Si la respuesta es sí, probablemente hay una necesidad de negocio. Si la respuesta es no, preguntá qué propósito cumple hoy. El propósito puede seguir siendo requisito aunque el mecanismo desaparezca. Nexo imprime una hoja para depósito porque necesita una lista estable y legible de qué preparar, no porque el papel sea valioso por sí mismo.

Probá tu ojo con situaciones reales de Nexo. En algunas hay una segunda lectura razonable; las explicaciones te dicen cuál es la que usaríamos en el dossier y por qué.

3.10 Un solo pedido puede revelar el sistema entero

Elegir un episodio y recorrerlo entero rinde más que diez descripciones generales. En el módulo anterior el pedido 48172 apareció contado por las personas que lo vivieron. Ahora lo reconstruimos con más fuentes: el relato de la vendedora, el historial de WhatsApp (con el audio de Laura), el relato del depósito con la foto de la pizarra y la exportación de estados del ERP.

El mismo episodio, visto como intercambio entre personas y herramientas, muestra cuántas veces el pedido cambia de manos y dónde se apoya en conocimiento que no está en ningún sistema:

Esa secuencia vuelve a registrarse como artefacto, con una columna que importa mucho: de dónde sale cada dato. Un evento observado, uno documentado y uno relatado no tienen el mismo peso. Y fijate que en este episodio no hay ningún evento observado: el pedido ocurrió el jueves, antes de la reunión 1, así que lo que tenés son relatos y documentos.

1episodio: "Pedido 48172"
2fuentes: [S1_relato_vendedora, S2_historial_whatsapp, S3_relato_deposito_y_foto_pizarra, S4_exportacion_erp]
3eventos:
4  - {t: "10:02", rol: Cliente,   que: "Envía foto con 23 códigos (2 mal escritos, 1 discontinuado)", fuente: S2, certeza: documentado}
5  - {t: "10:06", rol: Ventas,    que: "Corrige 2 códigos con Excel personal y reemplaza el discontinuado (A-184 → A-184B)", fuente: S1, certeza: relatado, abre: "¿tabla de equivalencias o conocimiento informal? (RN-04)"}
6  - {t: "10:09", rol: Ventas,    que: "Carga en el ERP, consulta precio y sobrescribe 3 líneas por acuerdo", fuente: S1, certeza: relatado, erp: "INGRESADO 10:08", abre: "¿el acuerdo tiene vigencia? (RN-03)"}
7  - {t: "10:11", rol: Ventas,    que: "Saldo + pedido supera el límite; llama a Laura",             fuente: S1, certeza: relatado,  erp: "EN_REVISION 10:11", abre: "¿qué cuenta como saldo? (exposición, U-01, RN-01)"}
8  - {t: "10:14", rol: Crédito,   que: "Laura autoriza por audio tras mirar la planilla de cheques pendientes", fuente: S2, certeza: documentado, erp: "APROBADO 10:19", abre: "¿el audio es evidencia? ¿quién autoriza qué diferencia? (RN-02)"}
9  - {t: "10:19", rol: Ventas,    que: "Imprime y lleva la hoja a depósito",                          fuente: S1, certeza: relatado,  erp: "IMPRESO 10:24", abre: "¿snapshot necesario o workaround?"}
10  - {t: "10:31", rol: Depósito,  que: "AX-442: ERP 8, 6 reservadas a mano en la pizarra, pedido pide 3; falta 1", fuente: S3, certeza: "relatado + foto de la pizarra", abre: "¿quién reserva y cuándo? (RN-05, RN-07)"}
11  - {t: "10:36", rol: Cliente,   que: "Acepta otra marca",                                          fuente: S1, certeza: relatado,  abre: "¿cambia precio? ¿vuelve a crédito?"}
12  - {t: "10:44", rol: Ventas,    que: "Corrige el pedido y reimprime",                               fuente: S1, certeza: relatado,  erp: "MODIFICADO 10:44"}
13  - {t: "11:02", rol: Fiscal,    que: "Emite comprobante",                                           fuente: S1, certeza: relatado,  abre: "¿facturar antes de que haya transportista asignado?"}
14  - {t: "11:18", rol: Logística, que: "Entrega al transportista",                                    fuente: S1, certeza: relatado}

Mirá la columna erp. La exportación de estados que trajo Sistemas después de la reunión 1 marca otras horas para el mismo pedido: APROBADO a las 10:19, cuando el audio de Laura es de las 10:14, e IMPRESO a las 10:24, cuando la vendedora ubica la impresión a las 10:19. No se elige una: el ERP registra cuándo alguien cargó el cambio, no cuándo ocurrió. Se conservan las dos horas y se anota la diferencia. Esa diferencia es un hallazgo de triangulación: la espera de crédito medida con el audio es de 3 minutos (10:11 a 10:14), y medida con el ERP, de 8 (EN_REVISION a APROBADO). Cualquier métrica futura tiene que decir de qué fuente sale.

La secuencia abre preguntas en casi todos los límites. ¿La corrección de SKU es una tabla de equivalencias válida o conocimiento informal? ¿El acuerdo de precio tiene vigencia? ¿La autorización por audio debe conservarse como evidencia? ¿La impresión es una snapshot necesaria o un workaround? ¿La sustitución cambia precio y vuelve a requerir crédito? ¿La facturación puede ocurrir si el transportista todavía no está asignado? Un junior tiende a ver una lista de pantallas. Un analista empieza a ver decisiones, autoridad de datos, invariantes y puntos de consistencia.

También aparecen relaciones temporales. Si la sustitución cambia el total después de que crédito aprobó, la autorización previa podría ya no ser válida. Si la reserva física no existe hasta picking, dos vendedores pueden prometer la misma unidad. Si una autorización se conserva solo en WhatsApp, luego no hay una explicación estructurada de por qué el pedido excedió el límite. Ninguna de estas conclusiones debe convertirse automáticamente en requisito, pero todas merecen investigación porque pueden cambiar dinero o integridad.

3.11 Observar el proceso como sistema sociotécnico

Cuando observamos una empresa no estamos estudiando solamente pasos. Estamos mirando una combinación de personas, herramientas, información, incentivos y reglas. Un workaround puede existir porque el software es malo, porque el dato llega tarde, porque una política es impracticable o porque un área optimiza su propio objetivo. Copiar el workaround al sistema nuevo puede institucionalizar el problema.

Por eso el shadowing no busca “documentar lo que hacen” como si cada movimiento fuera correcto. Busca entender por qué una acción existe. Si el vendedor imprime el pedido, preguntamos qué propósito cumple el papel: ¿es señal visual de cola?, ¿lleva anotaciones?, ¿acompaña mercadería?, ¿sirve para asignar un picker?, ¿es la única forma de que depósito se entere? El futuro sistema debe preservar el propósito necesario, no necesariamente el papel.

La misma disciplina aplica a Excel. Una fórmula puede ser una regla vigente, un parche histórico o un cálculo incorrecto que todos aprendieron a compensar. Miramos quién la creó, quién la modifica, con qué frecuencia se usa y si sus resultados se contrastan con otra fuente. La existencia de una fórmula es evidencia de comportamiento, no autoridad automática.

3.12 De AS-IS a oportunidades sin dibujar todavía el TO-BE

Un buen AS-IS permite señalar fricciones con evidencia: doble carga, espera, handoff, dato faltante, decisión manual repetitiva, reintento, reconciliación, error recurrente. Todavía no nos obliga a decidir cómo se resolverá. Esta separación es importante porque muchas oportunidades admiten soluciones distintas. Una espera por aprobación podría resolverse con regla automática, con mejor visibilidad para el aprobador o con un cambio de política, y esas alternativas tienen riesgos diferentes:

Estas alternativas son hipótesis de diseño: no se escriben todavía como requisitos. Antes de proponer automatización, preguntá qué parte del paso requiere juicio. Si la respuesta es “nunca cambia, solo copiamos valores”, es buen candidato. Si la persona evalúa información contextual no disponible en el sistema, automatizar el clic no elimina la decisión. Solo la oculta.

Nexo B2B · Segunda jornada de observación

Durante el shadowing se aclara de dónde sale la planilla que Laura abrió en el 48172. Cada mañana una administrativa descarga un PDF del ERP con saldos, lo copia a una planilla y agrega una columna llamada “comprometido”. Allí anota cheques y transferencias que todavía no impactaron en cuenta corriente. Laura consulta esa planilla antes de autorizar un pedido que supera el límite.

Esto cambia la idea de “saldo del ERP” como fuente suficiente. El límite de crédito se evalúa contra una vista más rica del riesgo comercial. Todavía no sabemos si el concepto “comprometido” debe existir en el sistema nuevo, ni si la planilla es correcta. Pero sí sabemos que cualquier especificación que use solamente saldoDeudor está incompleta (U-01).

Con las exportaciones de la planilla y del PDF cargadas en tablas de trabajo, podés medir cuánto cambia la decisión según qué definición uses. Es SQL de análisis, no del sistema futuro, y la definición de exposición de abajo es la que administración usa hoy, todavía no validada como regla:

1-- Tablas de trabajo cargadas desde el PDF de saldos del ERP y la planilla de administración
2--   saldos_erp(cuit, saldo_cents)
3--   facturas_no_contabilizadas(cuit, monto_cents)
4--   cheques_sin_imputar(cuit, monto_cents)
5--   limites(cuit, limite_cents)
6-- Parámetro de ejemplo: total del pedido en evaluación (en centavos)
7​
8WITH base AS (
9  SELECT l.cuit,
10         l.limite_cents,
11         s.saldo_cents AS saldo_erp,
12         s.saldo_cents
13           + COALESCE((SELECT sum(monto_cents) FROM facturas_no_contabilizadas f WHERE f.cuit = l.cuit), 0)
14           - COALESCE((SELECT sum(monto_cents) FROM cheques_sin_imputar c WHERE c.cuit = l.cuit), 0)
15           AS exposicion_administracion
16  FROM limites l
17  JOIN saldos_erp s USING (cuit)
18)
19SELECT cuit,
20       (saldo_erp + :pedido_cents > limite_cents)                 AS bloquea_con_saldo_erp,
21       (exposicion_administracion + :pedido_cents > limite_cents) AS bloquea_con_exposicion_admin
22FROM base
23WHERE (saldo_erp + :pedido_cents > limite_cents)
24   <> (exposicion_administracion + :pedido_cents > limite_cents);

Cada fila que devuelve la consulta es un cliente cuya decisión cambia según la definición. No dice cuál es correcta: dice cuántos casos dependen de una definición que Nexo todavía no cerró. Es evidencia para llevarle a quien tiene autoridad.

En depósito ocurre otra sorpresa. El operario no confía en el stock de tres familias de productos porque suelen guardarse temporalmente en una mesa de devoluciones. Cuando el ERP indica una última unidad, camina hasta la ubicación antes de confirmar. Ese comportamiento explica por qué los pedidos grandes tardan, pero también muestra que el problema no puede resolverse solo con bloqueo transaccional: existe una discrepancia entre mundo físico y registro.

Ahora Nexo tiene dos tipos distintos de “stock incorrecto”: carreras digitales entre pedidos concurrentes y diferencias físicas por movimientos no registrados. Una solución robusta necesita no confundirlas. La concurrencia se resuelve con garantías en la fuente autoritativa; la discrepancia física exige proceso operativo de ajuste, conteo o excepción. Las preguntas que permiten saber cuál ocurrió en un caso concreto son pocas:

El 48172 es un caso para el primer camino: otros pedidos ya impresos tenían 6 unidades de AX-442 reservadas a mano en la pizarra, el ERP seguía mostrando 8 y el 48172 pedía 3; 6 + 3 supera 8. En el estante había 8: no se perdió nada. Faltaba el concepto de reserva.

Finalmente aparece una regla escondida en un PDF de condiciones comerciales: algunos clientes tienen acuerdos de precio válidos hasta una fecha. La vendedora decía “uso el Excel porque el ERP a veces no tiene el descuento”. La arqueología documental permite transformar una queja vaga en preguntas sobre vigencia, prioridad entre listas y acuerdos, y autoridad de actualización.

3.13 El playback como prueba de comprensión

Cuando devolvemos el AS-IS al cliente no preguntamos “¿está correcto?”. Recorremos episodios y buscamos refutación. “Según entendimos, un pedido con saldo aparente alto se contrasta contra comprometido antes de escalar autorización. Mostremos el 48172: ¿qué habría pasado si la transferencia todavía no figuraba?” Una respuesta concreta valida mucho más que un asentimiento general.

Ensayá una conversación de playback. Elegí con cuidado: la pregunta correcta no es la más amable, es la que le da al cliente una forma fácil de decirte que te equivocaste.

3.14 Medir fricción sin convertir discovery en consultoría de procesos infinita

Cuando aparece una fricción conviene cuantificar lo suficiente para priorizarla. No necesitamos un estudio de seis semanas. Podemos muestrear veinte pedidos, medir tiempos de espera, contar recargas o clasificar causas de corrección. El objetivo es saber si estamos frente a un caso raro, un costo cotidiano o un riesgo de alto impacto.

La métrica correcta depende del problema. Para doble carga puede ser minutos por pedido y cantidad diaria. Para stock, porcentaje de líneas con discrepancia y costo de corrección. Para autorizaciones, tiempo de espera y frecuencia. Una métrica sin decisión asociada se convierte en dashboard decorativo.

Nexo B2B · Una semana de muestra cambia prioridades

El equipo toma 60 pedidos. Solo 8 llegan completamente estructurados. En 37 hay al menos una corrección de SKU; 14 requieren revisar un acuerdo de precio fuera del ERP; 9 pasan por autorización de crédito y 6 sufren una diferencia de stock físico. La espera de crédito es alta, pero la corrección de productos afecta muchos más pedidos.

Si registraste cada pedido de la muestra como una fila con banderas, la tabla de arriba es una sola consulta. Las categorías no son excluyentes (un pedido puede tener corrección de SKU y autorización), por eso no suman 60:

1-- muestra_pedidos(pedido_id, estructurado bool, corr_sku bool, rev_acuerdo bool,
2--                 autoriz_credito bool, dif_fisica bool)
3SELECT count(*)                                         AS pedidos,
4       count(*) FILTER (WHERE estructurado)             AS estructurados,
5       count(*) FILTER (WHERE corr_sku)                 AS con_correccion_sku,
6       count(*) FILTER (WHERE rev_acuerdo)              AS con_revision_acuerdo,
7       count(*) FILTER (WHERE autoriz_credito)          AS con_autorizacion_credito,
8       count(*) FILTER (WHERE dif_fisica)               AS con_diferencia_fisica
9FROM muestra_pedidos;
10-- pedidos | estructurados | con_correccion_sku | con_revision_acuerdo | con_autorizacion_credito | con_diferencia_fisica
11--      60 |             8 |                 37 |                   14 |                        9 |                     6

Esto no decide automáticamente el roadmap. Algunas fricciones son frecuentes pero baratas, otras raras pero peligrosas. La frecuencia sale de la muestra; el impacto es un juicio que tenés que justificar con el dueño de cada área. Una forma de hacerlo visible es ubicar cada fricción en un plano:

El eje horizontal usa las proporciones medidas (37/60, 14/60, 9/60, 6/60). El vertical es una estimación que el equipo todavía no validó: una diferencia de stock físico es rara, pero cuando ocurre puede romper una promesa al cliente. Sin esta distinción, el Sprint prioriza por la queja más fuerte del último día. Con ella, puede registrar volumen, impacto y confianza de la evidencia.

Antes de leer el gráfico, mirá el tamaño de la muestra. Con 60 pedidos de una sola semana, la diferencia entre 37 y 9 es robusta; entre 14, 9 y 6, no. Con muestras así, esas tres proporciones podrían cambiar de orden en otra semana (por ejemplo, un intervalo de confianza del 95% para 6 de 60 va aproximadamente del 5% al 20%). Además, una semana elegida a mano puede no ser representativa: fin de mes, temporada alta, un cliente grande que justo pidió mucho. El gráfico sirve para separar lo cotidiano de lo raro, no para ordenar fino las fricciones raras entre sí. Dos cosas más: la consulta cuenta frecuencias, así que “la espera de crédito es alta” sale de otros episodios (como el 48172), no de esta muestra; y la muestra no separó las carreras digitales de las diferencias físicas, así que un caso como el 48172 no tiene dónde contarse. En la próxima muestra conviene registrar el tipo de faltante, como en la planilla del microtaller.

Microtaller · Muestra de episodios

3.15 Workaround, excepción y control compensatorio no son lo mismo

Observar trabajo manual no significa asumir que todo es desperdicio. Algunas tareas son workarounds nacidos porque el sistema actual no soporta una necesidad. Otras son excepciones legítimas del negocio. Otras funcionan como controles compensatorios: una persona revisa algo porque otro mecanismo no es confiable. Automatizar las tres categorías de la misma manera puede eliminar una protección importante junto con la fricción.

Para distinguirlas, preguntá qué riesgo evita la tarea, qué ocurriría si desapareciera mañana y si el negocio desea conservar el criterio o solo el resultado. Si ventas llama a depósito antes de confirmar pedidos grandes porque no confía en el stock, la llamada puede ser un control compensatorio. El objetivo no es digitalizar la llamada. Es entender qué incertidumbre protege y decidir cómo ofrecer una garantía equivalente o mejor.

Los documentos heredados merecen el mismo cuidado. Una fórmula en Excel es evidencia de comportamiento actual, no automáticamente una regla aprobada. Un color rojo puede significar deuda vencida, una marca manual o simplemente una convención personal. Una columna llamada “saldo disponible” puede incorporar cheques pendientes que el ERP ignora. La arqueología documental busca semántica, propietario, momento de actualización y consecuencias, no columnas para copiar a SQL.

La autoridad puede ser distinta por campo. El ERP puede ser autoritativo para SKU y descripción, la planilla comercial para un acuerdo temporal de precio, el sistema contable para saldo confirmado y un conteo físico para corregir disponibilidad. Diseñar una única “fuente de verdad” sin esta granularidad suele producir integraciones que técnicamente sincronizan datos pero semánticamente mezclan responsabilidades.

El AS-IS sirve cuando vuelve visibles estas dependencias. No necesita describir toda la empresa. Debe mostrar dónde entra información, quién decide, qué espera, qué se corrige, qué artefactos cambian de mano y dónde aparece incertidumbre.

Un prompt de ejemplo para clasificar tareas observadas sin que el agente decida qué eliminar:

1Sos un asistente de análisis de procesos. No decidís qué se automatiza.
2​
3Entrada: el archivo episodios/pedido-48172.yaml y notas-de-campo/shadowing-ventas-01.yaml.
4​
5Para cada tarea manual que aparezca, devolvé una fila con:
6- tarea (cita textual con id de evento)
7- hipótesis de tipo: variación | excepción | workaround | control compensatorio
8- qué riesgo parece evitar (como hipótesis)
9- qué evidencia haría falta para confirmar el tipo
10- pregunta para el dueño del proceso
11​
12No propongas soluciones. No marques ninguna tarea como "desperdicio".
13Si no hay evidencia para distinguir, escribí "INDETERMINADO".

Para revisar la salida, recorré las filas que dicen “control compensatorio” y preguntate qué pasaría si esa tarea desapareciera mañana. Si el agente propuso eliminarla o la llamó “innecesaria” a pesar del prompt, la clasificación no es confiable: revisá a mano ese ítem.

Nexo B2B · Una mañana de shadowing cambia el modelo

A las 8:17 entra el primer pedido observado. La vendedora abre WhatsApp Web, copia los SKU a una hoja temporal y pega parte de la lista en el ERP. Dos códigos no existen. En lugar de rechazarlos, busca en pedidos históricos del cliente y encuentra equivalencias. El equipo había supuesto que “código inválido” sería un error simple. El shadowing muestra que puede representar un producto renumerado, una abreviatura habitual o un error real.

La hoja temporal dura menos de diez minutos y luego se descarta. No merece convertirse automáticamente en entidad. Lo importante es la función que cumple: limpiar una entrada semiestructurada antes de consultar catálogo y precios. Para el diseño futuro, eso abre opciones como búsqueda tolerante, alias controlados o una etapa de revisión. El artefacto actual informa el problema, pero no determina la forma de la solución.

A las 8:42 aparece un cliente con precio especial. La vendedora abre PRECIOS_ESPECIALES_2026.xlsx. La hoja tiene columnas para CUIT, SKU, precio, fecha de vencimiento y una columna “OK” con iniciales. Algunas filas no tienen fecha de vencimiento. Al preguntar por “OK”, la vendedora explica que significa “lo habló alguien de dirección”, pero no siempre recuerda quién. El equipo encuentra una regla comercial candidata y, al mismo tiempo, un déficit de auditabilidad.

Más tarde, administración muestra otra planilla. Para crédito no usa el saldo visible del ERP de forma aislada, sino saldo más facturas emitidas todavía no contabilizadas menos cheques recibidos sin imputar. El cálculo cambia durante el día. Si el nuevo sistema consulta solamente un endpoint del ERP, puede tomar una decisión correcta técnicamente y equivocada para la operación. La arquitectura futura necesita una definición temporal de autoridad, no solo una integración.

En depósito, el picker recibe una hoja impresa. Marca faltantes con lapicera y, si el pedido es grande, cuenta el producto antes de empezar a preparar. La impresión parecía una reliquia fácil de eliminar. Al observarla, el equipo descubre que es también un punto de coordinación: indica prioridad, ubicación y quién está trabajando el pedido. La solución futura puede reemplazar papel, pero deberá preservar esas señales o introducir un mecanismo mejor.

Al final de la mañana se comparan tres pedidos. En dos, el flujo fue parecido. En el tercero hubo sustitución, autorización y quiebre físico. Ese tercer caso produce más conocimiento que una decena de happy paths. El AS-IS se actualiza con un loop de sustitución, una espera por crédito y un handoff explícito entre venta y depósito. El glosario también cambia: “disponible” deja de significar stock ERP y pasa a diferenciar físico, reservado y vendible.

El playback con Nexo no presenta una lista de ineficiencias. Presenta decisiones y dependencias: dónde el sistema actual no alcanza, qué controles manuales protegen errores y qué reglas todavía viven en personas. Marta reconoce que “queríamos sacar WhatsApp” era una simplificación. El primer objetivo se reformula: reducir la reconstrucción manual y lograr una confirmación confiable sin perder excepciones comerciales legítimas.

Las notas de esa mañana quedaron en el dossier. Antes de usarlas como base del AS-IS, alguien las tiene que revisar. Este fragmento tiene cuatro defectos de los que ya hablamos en esta lección:

Comprobá tu criterio

Errores frecuentes

• Síntoma: el sistema nuevo replica la hoja impresa. Causa: se trató el workaround como requisito. Corrección: preguntá qué propósito cumple (prioridad, ubicación, quién la trabaja) y especificá eso.
• Síntoma: se elimina una llamada de control y reaparecen sobreventas. Causa: era un control compensatorio y se lo confundió con desperdicio. Corrección: antes de quitar una tarea manual, nombrá el riesgo que evitaba y la garantía que lo reemplaza.
• Síntoma: “el stock del ERP está mal, hay que arreglar el ERP”. Causa: se mezcló carrera digital con discrepancia física. Corrección: aplicá el árbol de decisión (¿había otro pedido concurrente? ¿el estante coincide tras contar?) para separar los dos problemas.
• Síntoma: una regla de precedencia aparece en el dossier sin dueño. Causa: se infirió de ver abrir una planilla. Corrección: registrá un hecho y una pregunta; la regla nace cuando hay segunda fuente y alguien con autoridad.
• Síntoma: el playback termina en “se ve bien”. Causa: se pidió validación en lugar de refutación. Corrección: recorré un episodio concreto y preguntá dónde no coincide.
• Síntoma: se prioriza el problema del último llamado de un vendedor. Causa: no hay muestra. Corrección: tomá 20 episodios con columnas ligadas a decisiones y mostrá frecuencia e impacto por separado.

Para llevarte

• La autoridad se asigna dato por dato; un mapa de autoridad evita que el backend confíe en una entrada que no manda sobre ese dato.
• Variación, excepción, workaround y control compensatorio se parecen desde afuera y se tratan distinto: conservá el propósito o el criterio, no el mecanismo.
• Un episodio reconstruido con hora, rol, herramienta, fuente y certeza abre más preguntas útiles que diez descripciones generales.
• Carrera digital y discrepancia física de stock son problemas distintos con remedios distintos; no los mezcles bajo “stock en tiempo real”.
• Medir con una muestra pequeña y columnas ligadas a decisiones evita priorizar por la queja más fuerte.
• El playback busca refutación sobre un caso, no aprobación general del diagrama.