Contenido8 secciones
- La regla que define a la empresa
- Qué es la auditoría y qué no es
- Los tres artefactos
- Los cuatro patrones de rechazo
- El template de ROI
- La matemática "40 horas de desperdicio antes de automatizar ahorran 40 horas/semana"
- Qué compra la regla "si no muestra ROI no construimos"
- Qué significa esto para un operador que evalúa un build
Auditoría de proceso antes de automatizar: el playbook del 'no construir'
Un contrato puede terminar en el diagnóstico con el depósito devuelto. El playbook de auditoría, los 4 patrones de rechazo y el ROI firmado antes del código.
La regla que define a la empresa
Un workflow va a build solo después de que una estimación escrita de ROI, firmada por el operador, queda positiva bajo premisas conservadoras. Si no queda, devolvemos el depósito del diagnóstico y el contrato se cierra. Hay contratos que terminan exactamente ahí, y ese es el sentido de tener la compuerta: un filtro que nunca rechaza nada no es un filtro, es un trámite.
No es una postura de venta. Es el seguro más barato que un proyecto puede comprar. Casi toda automatización con IA que falla a los seis meses falló en la etapa de auditoría, y la auditoría no lo detectó.
Qué es la auditoría y qué no es
La auditoría es la etapa Break del Protocolo INITE. Cinco días hábiles. Un workflow a la vez, a veces dos. Tres artefactos nombrados al final. ROI firmado antes de cualquier PO de build.
No es llamada de ventas. No es sesión de discovery. No es deck. El operador paga un fee chico por ella (en general 5-10% del presupuesto de build previsto) y ese fee es reembolsable en su totalidad si la auditoría termina en decisión de no construir.
La comprobación de idoneidad gratuita de quince minutos que hay en el sitio es otra cosa, y va antes: responde si el proceso merece una auditoría, y no necesita nada más que una conversación. Aquí hablamos del paso siguiente. En cuanto entra en juego el acceso real a sistemas y números, el precio pasa a ser la palanca aislada más grande sobre calidad — a una auditoría pagada mandan al dueño del proceso, a una gratis mandan al vendedor.
Los tres artefactos
| Artefacto | Qué responde | Tiempo de producción |
|---|---|---|
| Mapa cuantitativo del proceso | ¿Dónde está el cuello de botella real? | 2 días |
| Reporte cost-of-chaos | ¿Cuánto cuesta el modo actual en $/semana? | 1 día |
| Priority matrix + ROI firmado | ¿Qué candidato tiene matemática para construir? | 2 días |
El mapa del proceso es un swimlane a resolución de handoff — cada paso desde el kick-off hasta el cierre, cada paso en su carril por rol, con tres números estampados en cada handoff: throughput por semana, tasa de error, cycle time mediano. La mayoría de los equipos nunca vio su propio trabajo en esa forma. El mapa es lo que hace visible el cuello de botella, y la mayor parte de las veces no está donde los operadores creían.
El reporte de cost-of-chaos es un número en dólares por semana — cuánto le cuesta a la empresa la forma actual de hacer este workflow en horas perdidas, más allá del trabajo necesario. Tres renglones: costo de retrabajo, costo de espera, costo de fuga. Inputs explícitos. El controller de la empresa firma los inputs.
La priority matrix es un 2x2 de viabilidad técnica de automatización por ROI de negocio para cada workflow candidato surgido en la auditoría. La esquina superior derecha es lo que va a Cast. Todo lo demás recibe explicación escrita de por qué no entró.
Los cuatro patrones de rechazo
La auditoría termina en No cuando la matemática no queda positiva bajo premisas conservadoras. Cuatro patrones producen casi todo No.
Espera dominada upstream
El paso lento del workflow es esperar algo fuera del control de la empresa — la respuesta de un regulador, la firma de un cliente, la compensación de un pago en un sistema bancario. La automatización interna ahorra minutos de procesamiento, pero el número de cycle time no se mueve porque la espera está upstream y no es abordable. Automatizar acá es un caballo más rápido en un camino bloqueado por una barrera.
La auditoría detecta esto midiendo cycle time en cada handoff y rotulando si la espera es interna (capacidad del operador), entre equipos (handoff entre funciones) o externa (proveedor, cliente, regulador). Un workflow con 80% de su cycle time en esperas externas es un No para un build que propone automatizar pasos internos.
Mid-rewrite
El equipo está cambiando el proceso por razones ajenas — migración de ERP, reorg, nuevo régimen de compliance. Automatizar la versión actual congela un proceso que en tres meses no va a existir.
La auditoría detecta esto con dos preguntas en la entrevista al operador: qué cambió en cómo hacen esto en los últimos 6 meses, y qué esperan que cambie en los próximos 6. Un workflow en el que la segunda respuesta es "todo" o "estamos cambiando de sistema" es No hasta que la reescritura se asiente.
Bloqueo de adopción
El workflow tiene una dimensión de confianza o control que los operadores no delegan. Un controller aprobando una transferencia saliente no va a entregarle la autoridad de firma a un modelo, no importa qué tan bueno sea. Un médico firmando una derivación no delega la firma. La automatización funcionaría técnicamente y no se usaría.
La auditoría detecta esto preguntando a los operadores reales del workflow (no a su jefe) si usarían la automatización propuesta. La respuesta suele ser directa. Un workflow en el que el operador dice "igual revisaría cada salida" está bien si la revisión toma segundos; es No si la revisión toma tanto como el trabajo original.
Volumen muy bajo
El workflow candidato sucede 8 veces por semana. Ahorro por instancia: 90 minutos. Total: 12 horas por semana. Aun a $120/hora cargado, la línea de recuperación es $74K/año contra un build all-in de $74K. La línea de recuperación queda en o por debajo del break-even en el año uno, y el workflow tiene que seguir corriendo sin cambios por dos años más para pagar a una tasa decente. Eso es No para un build, incluso si la tecnología funcionara y el equipo adoptara.
Este patrón es la razón más común por la que un pequeño negocio pide una automatización que la matemática no va a justificar. La auditoría la detecta con el cálculo explícito de volumen × time-saved × costo, y el operador suele estar de acuerdo con la conclusión en el momento mismo en que ve los números dispuestos.
El template de ROI
El template de matemática tiene tres columnas y una regla.
| Input | Cómo se toma | Por qué |
|---|---|---|
| Tiempo ahorrado por instancia | Percentil 25 del rango observado del operador | No asumimos la mejor semana |
| Costo de build a 12 meses | Percentil 75 de la estimación de ingeniería | No asumimos la entrega más suave |
| Costo de mano de obra por hora | Salario + beneficios + ajustado por utilización | No la horaria bruta — el costo/hora real |
La regla — el cálculo de ROI tiene que quedar positivo bajo esos inputs en 12 meses. No 24, no 36, no "alguna vez". Doce meses. El operador firma el template antes de que se emita cualquier PO de build. Esa firma es lo que vuelve la decisión compartida en lugar de impuesta.
Un ejemplo trabajado de la aritmética, sobre un candidato que no construimos. Workflow: triage y ruteo de RFPs entrantes. Volumen: 38 RFPs por semana. Tiempo ahorrado por RFP en el percentil 25: 22 minutos. Costo cargado: $95 la hora de un senior account manager. Son 38 RFPs de 22 minutos cada uno, a $95 la hora, sobre 50 semanas laborales: una línea de recuperación de $66.200 al año. Costo de build en el percentil 75: $42.000 all-in. La matemática cerró en el mes siete y el workflow fue a Cast. A los doce meses, el número realizado fue $87K porque el tiempo ahorrado quedó más cerca de la mediana que del percentil 25 — ese es el punto: inputs conservadores, upside real.
La matemática "40 horas de desperdicio antes de automatizar ahorran 40 horas/semana"
La primera tarea de la auditoría es averiguar si el workflow propuesto es el workflow que debería automatizarse. En el 40% de las veces, no lo es. El workflow propuesto tiene un costo real, pero el costo más grande está en un workflow relacionado upstream, o en la espera entre dos workflows, o en el retrabajo que viene de un input ausente dos pasos atrás.
Por eso la etapa Cut, que va después de la auditoría, quita pasos antes de que arranque cualquier automatización. Pasos que no deberían existir no se codifican. La auditoría es lo que hace visible ese corte.
Un patrón concreto. Un contrato con una empresa de logística propuso automatizar la toma de decisión de despacho. La auditoría mostró que los despachadores pasaban 60% del tiempo persiguiendo documentación faltante de los choferes y solo 25% en las decisiones que la automatización propuesta habría reemplazado. El build pivotó a un workflow de recolección de documentos del lado del chofer. La automatización de la decisión de despacho se difirió a fase dos y al final no fue necesaria — los despachadores tuvieron holgura cuando la caza de documentos se fue. Ese pivote es la auditoría haciendo su trabajo. Sin auditoría, el build habría salido como estaba planeado, los despachadores lo usarían poco, y el cuello de botella habría seguido donde estaba.
Qué compra la regla "si no muestra ROI no construimos"
Tres cosas, todas downstream.
Seis meses después de que el workflow sale a producción, el operador que aprobó el build no es la misma persona que revisa los resultados. El CEO original se fue, o el COO que firmó está en otra empresa, o el head of operations es nuevo. La matemática de ROI tiene que sobrevivir esa sucesión. Inputs conservadores firmados sobreviven. Estimaciones con sabor a marketing no.
El equipo que opera el workflow tiene que confiar en el sistema. Los operadores aprenden muy rápido si un proveedor va a rechazar trabajo que no paga. Los proveedores que rechazan reciben un segundo contrato. Los que no rechazan reciben un contrato y después una despedida cortés.
La capacidad de automatización de la empresa tiene que componer. Cada workflow que sale con matemática honesta es un workflow con un ROI que se sostiene en una revisión de presupuesto. Cada workflow que sale con matemática optimista se apaga en silencio, y el próximo proyecto de automatización es más difícil de financiar. La auditoría es la palanca más barata sobre si los próximos diez proyectos se aprueban.
Qué significa esto para un operador que evalúa un build
Tres consecuencias operacionales.
Primero — esperá que el diagnóstico sea pagado, esperá que tome cinco días, esperá tener que producir números reales sobre throughput y tasa de error. El precio es chico. El cambio de comportamiento que produce en el equipo de auditoría es la palanca aislada más grande sobre calidad.
Segundo — contá con una chance real de que la auditoría termine en No, y preguntale al proveedor cuándo fue la última vez que le pasó. Si su tasa de conversión diagnóstico-a-build está cerca del 100%, su diagnóstico es venta, no diagnóstico. Querés la respuesta honesta, no la halagadora.
Tercero — cuando la auditoría termina en Sí, esperá que el build salga en 2-4 semanas contra números de ROI firmados, con la ganancia de productividad medida contra una línea de base que firmaste antes de empezar. Una ganancia medida así es real en los workflows que sobrevivieron al filtro. No es real, en ningún sentido por el que valga la pena pagar, en los workflows que nunca se deberían haber construido. La auditoría es lo que mantiene esa diferencia visible. Las piezas vecinas: integración de IA en los negocios, automatización de procesos y la cuenta financiera en medir el ROI de la IA.
Las cuatro preguntas que conviene hacer sobre cualquier cifra de retorno, la nuestra incluida, están en cuatro preguntas que tumban casi cualquier cálculo de ROI.
01Si devuelven el depósito cuando la matemática dice no, ¿qué les impide simplemente sellar la matemática?+
Tres barreras. Primera — la matemática misma trae defaults conservadores escritos en el template: time-saved se toma en el percentil 25 del rango observado del operador, costo de build en el percentil 75 de la estimación de ingeniería y costo de mano de obra se toma cargado (salario más beneficios, ajustado por utilización, no la horaria bruta). Un workflow tiene que quedar en ROI positivo bajo esas premisas malas, no bajo las optimistas. Segunda — el cálculo de ROI es un artefacto firmado: el operador ve los números, los inputs y las premisas antes de que se emita cualquier PO de build. Es parte de la decisión de rechazo, no destinatario. Tercera — los contratos rechazados reciben un memo escrito de una página explicando en cuál de los cuatro patrones cayeron; ese memo se archiva y trackea. El memo es lo que hace auditable un rechazo después, y es la única evidencia de que el filtro hace trabajo real y no teatro: un proveedor que no puede mostrarte uno nunca rechazó nada.
02¿Cómo se ve el swimlane que produce la auditoría?+
Una foto de un workflow a resolución de handoff — cada paso desde el kick-off hasta el cierre, cada paso en su carril por rol, con tres números estampados en cada handoff: throughput por semana, tasa de error (retrabajo o corrección) y cycle time (espera mediana entre handoffs). La mayoría de los equipos nunca vio su propio trabajo en esa forma. El mapa es lo que hace visible el cuello de botella, y la mayor parte del tiempo no está donde los operadores creían. Usamos notación BPMN cuando el equipo ya está habituado; rectángulos y flechas si no — la notación no es lo importante. Lo importante es que los tres números quedan visibles por handoff y la conversación sobre dónde automatizar se ancla en datos en lugar de en la voz más alta de la sala. El mapa más los tres números por handoff suele tomar dos días hábiles, incluyendo entrevistas y shadowing observado.
03¿Qué es el reporte de cost-of-chaos y cómo se calcula?+
Un número en dólares por semana — cuánto le cuesta a la empresa la forma actual de operar este workflow en horas perdidas, más allá del trabajo necesario. Es la suma de tres renglones. Renglón uno — costo de retrabajo: tasa de error por handoff multiplicada por el tiempo mediano de retrabajo, multiplicado por throughput, multiplicado por el costo cargado por hora del rol que rehace. Renglón dos — costo de espera: cycle time mediano por handoff multiplicado por throughput, multiplicado por el costo cargado del recurso que queda detenido (un vendedor esperando aprobación de crédito cuesta más que un contador esperando una firma). Renglón tres — costo de fuga: valor en dólares del trabajo que se fue del embudo por el cuello de botella (deals perdidos, jobs reembolsados, escalaciones cerradas con crédito). Los tres renglones tienen inputs explícitos, los tres son visibles en el artefacto. El número es conservador y el controller de la empresa firma los inputs. Contra ese número se mide el ROI del build.
04¿Qué hallazgos de la auditoría más a menudo terminan en No?+
Cuatro patrones cubren la mayoría de los rechazos. Espera-dominada-upstream — el paso lento del workflow es esperar a una parte externa (un regulador, la firma de un cliente, la compensación de un pago), y automatizar cualquier paso interno no mueve el cycle time porque la espera está fuera del control de la empresa. Mid-rewrite — el equipo está cambiando el proceso por razones ajenas (migración de ERP, reorg, nuevo régimen de compliance); automatizar la versión actual congela un proceso que en tres meses no va a existir. Bloqueo de adopción — el workflow tiene una dimensión de confianza o control que los operadores no delegan (un controller aprobando una transferencia saliente, un médico firmando una derivación); la automatización funcionaría técnicamente y no se usaría. Volumen muy bajo — el workflow candidato sucede 8 veces por semana, ahorra 90 minutos por instancia, es decir 12 horas por semana contra un build de 6 meses; incluso a $120 cargado por hora la línea de recuperación nunca cruza. Cada uno se cierra con un memo, el operador ve qué patrón le tocó, y el contrato pivota a otro workflow candidato o se cierra.
05¿Por qué cobrar por el diagnóstico? ¿Por qué no auditar gratis como parte del proceso de venta?+
Primero una definición, porque aquí 'diagnóstico' cubre dos cosas distintas. La comprobación de idoneidad de quince minutos es gratis y seguirá siéndolo — no necesita más que una conversación y sólo responde si el proceso merece una auditoría. Esta pregunta es sobre la auditoría de cinco días, que necesita acceso a tus sistemas y a tus números reales. Dos razones que aparecen en el comportamiento del operador en cuanto hay plata sobre la mesa. Los diagnósticos gratuitos se tratan como reuniones de venta — el operador manda al perfil amigable de BD, el acceso a los números reales sigue cerrado, y la auditoría se vuelve un intercambio de respuestas de comparación de proveedores en lugar de investigación de proceso. Los diagnósticos pagados se tratan como trabajo — el operador manda al dueño real del proceso, abre los sistemas reales y responde honestamente las preguntas aburridas sobre throughput y tasa de error. El precio es chico (en general 5-10% del presupuesto de build previsto) pero el cambio de comportamiento es la palanca más grande aislada sobre la calidad del diagnóstico. La cláusula de reembolso vuelve el precio psicológicamente reversible: si la matemática no cuadra, el lado negativo del operador es el tiempo invertido, no el efectivo. Ese intercambio — precio chico a cambio de acceso honesto, reembolsable en no-build — produce auditorías que en serio informan la decisión en lugar de diagnósticos que justifican la decisión que el vendedor ya quería.
