1.2 Dossier y plan de investigación

Al terminar esta lección

• Armar un dossier de contexto previo que separe lo público de lo interno y no concluya nada sobre el funcionamiento de la empresa.
• Explicar qué prueba y qué no prueba cada artefacto que entrega un cliente.
• Escribir un desconocido como cadena: incógnita, decisión afectada, evidencia, fuente y costo de equivocarse.
• Priorizar un conjunto de desconocidos según lo que bloquean hoy y lo caro que sería equivocarse.
• Conducir una conversación previa con el cliente que busque episodios en lugar de aceptar soluciones.

1.6 Antes de investigar: construir un dossier mínimo de contexto

No entrar a una empresa “en blanco” no significa diagnosticarla desde Google. Significa llegar sabiendo qué vende, a quién, por qué canales y qué vocabulario público utiliza. Diez o veinte minutos de investigación pueden evitar preguntas básicas y permitir que la reunión empiece en procesos. El límite es importante: la investigación previa produce contexto y preguntas, no conclusiones sobre el funcionamiento interno.

El dossier inicial de una PyME puede contener razón social y actividad, productos o servicios principales, ubicaciones, canales de venta, segmentos de cliente, sistemas visibles, documentación pública y cualquier promesa operacional que aparezca en su web. Si una distribuidora anuncia entrega en 24 horas o listas especiales para mayoristas, eso abre preguntas sobre stock, logística y precios, pero no demuestra cómo los implementa.

También conviene preparar un mapa de posibles fuentes internas. Para pedidos: mensajes, órdenes, remitos, facturas, reportes, listas de precios y registros de stock. Para crédito: cuenta corriente, políticas, autorizaciones y casos excepcionales. El objetivo es saber qué pedir si la conversación menciona un punto crítico.

Anatomía de un dossier mínimo

Un dossier sirve si otra persona puede leerlo en cinco minutos y saber qué se sabe, de dónde sale y qué falta. Esta es la estructura que usamos, con un criterio rígido: cada línea indica si es contexto público, material entregado por el cliente o pregunta. Nada de “conclusiones”.

El último arco punteado es el que distingue un plan de una lista: cada reunión devuelve evidencia que reordena las prioridades.

Nexo B2B · Dossier previo a la primera visita

La web de Nexo muestra “más de 8.000 productos”, atención por WhatsApp y entregas a todo el país. Un PDF comercial habla de “condiciones especiales por volumen”. Nada dice sobre reservas, crédito o depósitos. El estudiante registra esas tres señales como contexto público, no como reglas.

Al buscar ejemplos de pedidos entregados por el cliente aparece una orden con dos columnas de precio: “lista” y “acordado”. Otra tiene una anotación manuscrita “OK Sergio”. En vez de explicar esas marcas, el dossier las convierte en preguntas de evidencia: ¿qué determina el precio acordado?, ¿quién es Sergio en este proceso?, ¿qué autorizó exactamente?

Así queda el dossier completo en la carpeta de trabajo. Leelo como lo leería un mentor: ¿puede señalar, línea por línea, de dónde sale cada cosa?

1empresa: Nexo B2B
2actividad: "Distribuidora mayorista de ferretería e insumos (según web y brief)"
3fecha_de_armado: 2026-10-12
4tiempo_invertido_min: 25
5​
6contexto_publico:             # lo que cualquiera puede ver; no es evidencia del proceso interno
7  - id: DOS-01
8    senal: "La web anuncia «más de 8.000 productos»."
9    fuente: "sitio web, página de inicio"
10    abre: "¿Todo el catálogo está en el ERP? ¿Quién lo mantiene?"
11  - id: DOS-02
12    senal: "La atención al cliente es por WhatsApp."
13    fuente: "sitio web, contacto"
14    abre: "¿Es solo atención o también el canal por el que entran los pedidos?"
15  - id: DOS-03
16    senal: "Anuncia «entregas a todo el país»."
17    fuente: "sitio web, envíos"
18    abre: "¿Quién entrega? ¿Cómo se decide desde qué depósito sale un pedido?"
19  - id: DOS-04
20    senal: "El PDF comercial menciona «condiciones especiales por volumen»."
21    fuente: "PDF comercial"
22    abre: "¿Qué define esas condiciones y dónde están escritas?"
23​
24material_entregado:           # lo que el cliente nos pasó; observable, pero incompleto
25  - id: DOS-05
26    item: "Orden de pedido con dos columnas de precio: lista y acordado."
27    observacion: "En una línea figura lista 4.200 y acordado 3.950."
28    abre: "¿Qué regla o acuerdo explica la diferencia y dónde se mantiene?"
29  - id: DOS-06
30    item: "Otra orden con la anotación manuscrita «OK Sergio»."
31    observacion: "No indica qué se autorizó ni con qué criterio."
32    abre: "¿Quién es Sergio en este proceso y qué autorizó exactamente?"
33​
34fuentes_internas_a_pedir:
35  pedidos: [mensajes de WhatsApp, órdenes, remitos, facturas]
36  precios: [lista vigente, planillas de acuerdos]
37  credito: [cuenta corriente de un cliente, un caso de excepción reciente]
38  stock: [captura del ERP, planilla o pizarra de depósito]
39​
40lo_que_este_dossier_no_afirma:
41  - "Cómo se toma un pedido."
42  - "Cómo se decide el precio final."
43  - "Si hay reserva de stock o cuándo se produce."

Notá el bloque final. Escribir lo que el dossier no afirma es una barrera contra el hábito de rellenar: cuando el equipo lo lee, se ve cuánto queda por descubrir.

Qué prueba y qué no prueba cada artefacto

El material que entrega un cliente tiene un valor real y un límite. Antes de usarlo, escribí las dos cosas. Es el hábito que más separa a un analista que “junta documentos” de uno que construye evidencia.

Este cuadro se completa con cada artefacto nuevo. Si no podés llenar la columna derecha, es que todavía no entendés qué estás mirando.

Este pequeño trabajo cambia la calidad de la reunión. En lugar de “¿manejan descuentos?”, podemos mostrar un documento concreto y preguntar “en este pedido figura lista 4.200 y acordado 3.950; ¿qué regla o acuerdo explica esa diferencia y dónde se mantiene?”. La pregunta es más precisa y menos acusatoria.

Microtaller · 30 minutos antes del cliente

Elegí una empresa real que no conozcas. Prepará un dossier de una página y una lista de 12 preguntas. Después revisá cada pregunta y tachá las que ya suponen una solución. El entregable no debe contener arquitectura ni features.

1Rol: revisor de dossier. No describas cómo funciona la empresa por dentro.
2​
3Adjunto: texto de la web, texto del PDF comercial, brief del cliente.
4​
5Tarea:
61. Listá solo lo que esté escrito en esos textos, citando el fragmento.
72. Para cada señal, escribí una pregunta que pediría un caso real.
83. Marcá cualquier línea de mi dossier (adjunto) que afirme algo sobre
9   el funcionamiento interno sin fuente.
104. Sugerí documentos internos que habría que pedir, SIN asumir que existen.
11​
12No uses conocimiento general sobre distribuidoras como si fuera dato de Nexo.

1.7 De la incertidumbre a un plan de investigación

Una lista de preguntas no es todavía un plan de discovery. Para que sirva en un proyecto real, cada pregunta debe estar conectada con una decisión que podría cambiar. Si preguntamos “¿usan listas de precios?” por curiosidad, podemos llenar páginas sin reducir riesgo. Si preguntamos “¿qué fuente determina el precio que termina en un pedido confirmado y qué excepciones pueden reemplazarla?”, la respuesta afecta contratos, dominio, seguridad, trazabilidad y pruebas. La diferencia está en saber qué decisión estamos intentando habilitar.

Una técnica útil es escribir cada desconocido en forma de cadena: incógnita → decisión afectada → evidencia que la resolvería → persona o sistema que puede aportar esa evidencia → costo de equivocarse. Esta cadena evita dos extremos. El primero es investigar todo porque “podría ser importante”. El segundo es avanzar con huecos críticos porque nadie los convirtió en una tarea concreta. En un proyecto chico, cinco desconocidos bien formulados suelen ser más útiles que cincuenta preguntas genéricas.

El plan de investigación de Nexo

Después de leer el brief, hablar con la dueña y mirar el material entregado, el expediente de inicio de Nexo conserva seis desconocidos. Este es el plan completo, que vas a reutilizar en la práctica E01.

1- id: U-01
2  incognita: "Qué significa que un cliente «esté bien de cuenta» (exposición de crédito)."
3  decision_afectada: "Qué datos necesita la evaluación de crédito y de qué sistema salen."
4  evidencia: "Cuenta corriente de un cliente y el último pedido en que se discutió su saldo."
5  fuente_posible: ["administración/crédito", "ERP"]
6  costo_de_equivocarse: alto      # toca dinero y la decisión central del primer slice
7  bloquea_hoy: true
8​
9- id: U-02
10  incognita: "Qué precio prevalece cuando la lista y un acuerdo comercial discrepan."
11  decision_afectada: "Autoridad del dato de precio y diseño del cálculo."
12  evidencia: "Orden con lista 4.200 y acordado 3.950, y la planilla que respalda el acuerdo."
13  fuente_posible: ["responsable comercial", "dirección", "vendedora"]
14  costo_de_equivocarse: alto      # errores de precio salen directo en la factura
15  bloquea_hoy: true
16​
17- id: U-03
18  incognita: "Quién puede autorizar un exceso de crédito y cómo queda registrado."
19  decision_afectada: "Permisos, estados del pedido, auditoría y pruebas."
20  evidencia: "Las dos últimas autorizaciones, con el mensaje o documento correspondiente."
21  fuente_posible: ["administración/crédito", "dirección"]
22  costo_de_equivocarse: alto
23  bloquea_hoy: true
24​
25- id: U-04
26  incognita: "En qué momento se reserva el stock y por cuánto tiempo."
27  decision_afectada: "Modelo de stock, estados y liberación de unidades."
28  evidencia: "Un caso reciente de dos promesas sobre la misma unidad."
29  fuente_posible: ["depósito", "ventas", "dueña"]
30  costo_de_equivocarse: alto      # congelar stock o liberar demasiado pronto
31  bloquea_hoy: false              # hay que decidirlo antes de especificar reserva, no antes de la reunión 1
32​
33- id: U-05
34  incognita: "Qué se hace cuando el stock físico no coincide con el del ERP."
35  decision_afectada: "Reconciliación, excepciones durante la preparación y confianza en el dato."
36  evidencia: "Un pedido que haya vuelto a ventas por diferencia de stock, con la foto del estante."
37  fuente_posible: ["depósito", "operario"]
38  costo_de_equivocarse: medio
39  bloquea_hoy: false
40​
41- id: U-06
42  incognita: "Qué canal será realmente el origen de los pedidos en el primer release."
43  decision_afectada: "Alcance del primer slice y necesidad de integración con WhatsApp o web."
44  evidencia: "Una muestra de pedidos recientes con el canal por el que entró cada uno."
45  fuente_posible: ["ventas", "dueña"]
46  costo_de_equivocarse: medio
47  bloquea_hoy: false

Dos detalles de oficio. El plan no dice cuánto tarda una reserva ni cuál es el límite de autorización: son desconocidos y se registran como tales, aunque tentaría poner un número por prolijidad. Y bloquea_hoy diferencia lo que hay que resolver antes de especificar del resto: no todo desconocido importante frena la próxima semana.

Priorizar: decisión que bloquea por costo de equivocarse

Para ordenar, cruzamos dos preguntas. ¿Esta incógnita frena una decisión que el equipo tiene que tomar pronto? ¿Y cuánto costaría equivocarse? Las respuestas ubican cada desconocido en un cuadrante.

Los cuadrantes no son una fórmula: son una forma de forzar una justificación. Si alguien discute la posición de U-06, la conversación útil es “¿qué decisión depende del canal y qué tan cara sería una equivocación?”, no “¿es o no es importante?”.

Una consulta como pedido de evidencia

A veces el desconocido se resuelve mejor con datos que con conversación. Si el cliente puede exportar pedidos del ERP, una consulta SQL es una forma precisa de formular qué evidencia necesitás. En este momento no hay datos: la consulta es un pedido, no un resultado. Por eso incluye las columnas que asumís, para que quien exporte pueda corregirlas.

1-- Pedido de evidencia para U-03. TODAVÍA NO HAY RESULTADOS.
2-- Columnas asumidas sobre una exportación del ERP (confirmar nombres reales):
3--   export_pedidos(pedido_id, cliente_id, fecha, total_centavos, estado)
4--   export_clientes(cliente_id, antiguedad_anios, limite_centavos, saldo_centavos)
5SELECT
6  (c.antiguedad_anios >= 5)                         AS cliente_de_anios,
7  count(*)                                          AS pedidos_confirmados_sobre_limite,
8  min(p.fecha)                                      AS primero,
9  max(p.fecha)                                      AS ultimo
10FROM export_pedidos p
11JOIN export_clientes c USING (cliente_id)
12WHERE p.estado = 'CONFIRMADO'
13  AND c.saldo_centavos + p.total_centavos > c.limite_centavos
14GROUP BY 1;

Una advertencia metodológica: el saldo de la exportación es el de hoy, no el del día del pedido, así que esta consulta aproxima el fenómeno pero no lo mide. Esa limitación es parte de la pregunta que hay que hacerle a quien exporte: “¿tenemos el saldo histórico por pedido?”. Una consulta es útil cuando te obliga a descubrir qué dato falta.

1-- Pedido de evidencia para U-02. TODAVÍA NO HAY RESULTADOS.
2--   export_lineas(pedido_id, sku, precio_lista_centavos, precio_cobrado_centavos)
3SELECT
4  count(*) FILTER (WHERE precio_cobrado_centavos <> precio_lista_centavos) AS lineas_con_precio_distinto,
5  count(*)                                                               AS lineas_totales
6FROM export_lineas;

Esta segunda consulta responde “¿qué proporción de líneas se cobra distinto de la lista?”, pero no “por qué”. Para eso hace falta la planilla de acuerdos: dos fuentes, dos preguntas.

Autoridad, confianza y fronteras

La confianza tampoco es binaria. Una declaración de la dueña puede ser suficiente para comprender una intención comercial, pero insuficiente para cerrar una regla que mueve dinero. Un log del ERP puede demostrar qué ocurrió, pero no necesariamente por qué ocurrió ni si el comportamiento sigue siendo deseado. Una planilla usada todos los días puede ser evidencia operativa fuerte y, al mismo tiempo, contener fórmulas históricas que nadie se anima a tocar. La pregunta correcta no es “¿cuál es la fuente de verdad?” en abstracto, sino “¿qué fuente tiene autoridad para esta decisión, en este momento del proceso?”.

Cuando dos fuentes coinciden, aumenta la confianza, pero todavía conviene buscar fronteras. Si comercial dice que el límite de crédito nunca se supera y el sistema rechaza todo exceso, probá el caso exacto en el límite y pedí el último pedido excepcional. Las reglas importantes se vuelven más claras cuando se observan cerca de donde podrían romperse. El analista aprende a buscar el borde, no solo el caso cómodo.

La IA puede ayudar a convertir notas desordenadas en un inventario de preguntas, agrupar términos repetidos y sugerir contradicciones posibles. No puede elevar una hipótesis a regla porque su respuesta sea convincente. Para usarla bien, entregale el brief, tus etiquetas de evidencia y el objetivo de investigación. Pedile que señale qué afirmaciones requieren fuente y qué preguntas discriminarían entre dos interpretaciones. Después verificá cada propuesta contra el material original.

Nexo B2B · Tres versiones del mismo problema en cuarenta y ocho horas

El lunes, Marta describe el dolor como “los vendedores pierden tiempo copiando pedidos de WhatsApp”. El martes, una vendedora aclara que copiar la lista toma pocos minutos, pero validar precio y crédito puede demorar media hora cuando el cliente tiene acuerdos especiales. El miércoles, depósito agrega que algunos pedidos vuelven a ventas porque el stock físico no coincide con el disponible del ERP. Las tres versiones son compatibles y, al mismo tiempo, apuntan a problemas distintos.

Si el equipo hubiera tomado la primera frase como requisito, el primer slice habría sido un formulario de autoservicio. Con la segunda versión, aparece una decisión de precio y crédito. Con la tercera, aparece una garantía de stock que puede fallar incluso después de capturar correctamente el pedido. El problema se desplaza desde “recibir pedidos” hacia “confirmarlos con información confiable y dejar claro qué ocurre cuando una condición no se cumple”. Ese cambio no es retrabajo. Es discovery funcionando.

Probá la conversación del martes

La mejor manera de entender por qué el problema se movió es ponerte en el lugar del analista que recibe el mensaje de la vendedora. Elegí cómo responder y mirá las consecuencias.

Marta envía además una captura del ERP. El producto AX-442 muestra stock 8 y precio lista 12.450. La vendedora responde con una planilla donde el mismo cliente tiene “precio acordado 11.900 hasta nuevo aviso”. Depósito, por su parte, manda una foto de la pizarra de depósito con 6 unidades de AX-442 marcadas como reservadas para pedidos ya impresos. Ningún artefacto por sí solo define todavía qué precio o qué cantidad debe usar el futuro sistema. Lo que sí existe es evidencia concreta de que el brief “el ERP ya tiene productos y precios” era incompleto.

El alumno debe conservar las tres piezas sin sintetizarlas prematuramente. Precio ERP es un HECHO sobre lo que muestra un sistema. Precio acordado es un HECHO sobre una planilla, pero la vigencia de ese acuerdo todavía necesita autoridad. La pizarra es una observación puntual, no un registro: dice qué se prometió a mano, no qué hay en el estante. La calidad del dossier consiste justamente en poder explicar qué prueba cada evidencia y qué no prueba.

Cuando se pregunta quién define el precio final, Marta responde “comercial”. La vendedora dice “depende, algunos acuerdos los cerró dirección”. Esa diferencia abre un nuevo stakeholder y cambia la siguiente reunión. El equipo no necesita diseñar aún un motor de precios. Necesita reconstruir la jerarquía de autoridad y obtener casos reales donde dos fuentes discrepen.

Al cerrar esta primera etapa, Nexo sigue sin tener una solución propuesta, pero el proyecto ya es mucho menos ambiguo. Hay un objetivo operativo más preciso, tres fuentes en tensión, actores nuevos, riesgos identificados y un plan concreto para la reunión. Esa es la primera transformación que buscamos en el alumno: pasar de “entiendo la idea del cliente” a “sé exactamente qué necesito comprobar antes de comprometer una solución”.

Comprobá tu criterio

Errores frecuentes

• Síntoma: el dossier incluye frases como “gestionan el stock con el ERP” o “tienen logística propia”. Causa: se infirió el funcionamiento interno desde información pública. Corrección: mové esas líneas a preguntas y agregá la sección de lo que el dossier no afirma.
• Síntoma: pedís “toda la documentación” al cliente y recibís un PDF de procesos idealizado. Causa: pedir documentación ideal en vez de lo que se usó ayer. Corrección: pedí tres a diez ejemplos reales, incluyendo una excepción.
• Síntoma: hay una tabla de artefactos con una sola columna (qué dicen). Causa: no se explicitó el límite de cada fuente. Corrección: agregá “qué no prueba” a cada fila antes de usarla en una decisión.
• Síntoma: todos los desconocidos están marcados como críticos. Causa: no se cruzó lo que bloquea con lo que cuesta equivocarse. Corrección: ubicalos en el cuadrante y justificá cada posición con una frase.
• Síntoma: en la conversación aceptás una cifra (“unos 30 minutos”) y la anotás como dato. Causa: se registró una estimación de memoria como medición. Corrección: anotala como DECLARACIÓN con quien la dijo y pedí un caso para contrastarla.
• Síntoma: la consulta SQL que pediste devuelve algo, pero nadie sabe qué significa. Causa: no se explicitaron las columnas asumidas ni los límites del dato exportado. Corrección: documentá qué asumís, qué no sabés y qué pregunta responde la consulta.

Para llevarte

• El dossier previo produce contexto y preguntas, no conclusiones; cada línea debe estar etiquetada como público, entregado o pregunta.
• De cada artefacto que recibís, escribí qué prueba y qué no prueba antes de apoyarte en él.
• Un desconocido útil es una cadena: incógnita, decisión afectada, evidencia, fuente posible y costo de equivocarse.
• Priorizá cruzando lo que bloquea pronto con lo caro que sería equivocarse, y justificá cada posición.
• Una consulta o un pedido de datos es una forma precisa de formular qué evidencia necesitás; antes de tener datos, documentá qué asumís.
• En conversaciones previas, pedí el último caso concreto: la cifra de memoria y la solución ofrecida son los dos atajos que más cuestan.
• Cuando el problema se desplaza entre versiones, no es retrabajo: es discovery funcionando.