Definir un proceso antes de automatizarlo no exige un proyecto de consultoría de seis meses. Exige dos semanas, cuatro sesiones de trabajo y cinco entregables concretos. Lo que no exige es lo que suele hacerse: pedir a alguien que escriba el procedimiento, porque lo que se obtiene entonces es la versión ideal del proceso, no la que ocurre.
Este artículo es el método que aplicamos, con sus artefactos, para que pueda ejecutarse con o sin ayuda externa.
Cuando se pide a alguien que describa su proceso, describe el camino principal en su versión correcta. Omite las excepciones porque le parecen anecdóticas, omite los atajos porque no está seguro de que estén bien vistos, y omite las reglas no escritas porque para él son evidentes.
Las tres omisiones son exactamente lo que rompe una automatización en producción.
La pregunta que sí funciona es otra: «cuéntame el último caso que te dio problemas». Produce narración concreta en lugar de descripción abstracta, y en la narración aparecen las excepciones, los atajos y las reglas tácitas sin necesidad de preguntar por ellas.
Entregable | Qué contiene | Para qué sirve |
|---|---|---|
Mapa de decisiones | Qué se decide, quién y con qué información | Base de cualquier automatización |
Inventario de datos | Qué dato, en qué sistema, quién es el dueño | Revela contradicciones antes de codificar |
Catálogo de excepciones | Casos que no encajan y cómo se resuelven hoy | Define qué se automatiza y qué escala |
Reglas no escritas | Criterios que solo existían en la cabeza de alguien | Reduce la dependencia de personas |
Línea base | Tiempo de ciclo, manos, correcciones, coste por caso | Permite demostrar mejora después |
Los cinco tienen una propiedad valiosa: producen valor aunque el proyecto de automatización no se haga. El cuarto, en particular, suele ser el que más impacto inmediato tiene, porque convierte conocimiento tácito de una persona en un activo de la organización.
Días 1-2: la línea base. Antes de hablar con nadie, medir. Cuántos casos entran, cuánto tarda cada uno de principio a fin —incluyendo esperas, no solo trabajo activo—, cuántos requieren corrección posterior. Sin este dato, cualquier mejora futura será discutible.
Días 3-5: las conversaciones. Tres o cuatro personas que ejecutan el proceso, por separado y con la pregunta de los casos problemáticos. Por separado es importante: en grupo se impone la versión oficial. De aquí salen el mapa de decisiones y la mayor parte del catálogo de excepciones.
Días 6-7: los datos. Para cada decisión del mapa, qué información hace falta, dónde vive y quién responde de ella. Aquí es donde aparecen las contradicciones entre sistemas, y conviene documentarlas aunque incomoden: cada una es una decisión pendiente que alguien tendrá que tomar.
Días 8-9: las reglas. Redactar los criterios que aparecieron en las conversaciones y devolvérselos a quienes los enunciaron para que los confirmen o corrijan. Es el paso que más resistencia genera y el que más valor produce.
Día 10: la clasificación. Con todo lo anterior, decidir qué parte del proceso es automatizable, qué parte debe prepararse para que decida una persona y qué parte no debe tocarse. Y solo entonces, evaluar tecnología.
Entrevistar en grupo. La persona con más antigüedad describe el proceso oficial y las demás asienten. Se pierde justo la información que se buscaba.
Preguntar a los responsables en lugar de a quien ejecuta. El responsable conoce el diseño; quien ejecuta conoce la realidad. Ambos hacen falta, y en ese orden inverso al habitual.
Documentar el proceso ideal. La tentación de arreglar mientras se documenta es fuerte y arruina el trabajo. Primero se registra lo que pasa; el rediseño viene después y es una fase distinta.
Con estos cinco entregables sobre la mesa, las decisiones posteriores dejan de ser conversaciones de opinión:
Ese es el motivo por el que en TCG-SAF™ las dos primeras etapas —Vision y Domains— preceden siempre a cualquier decisión de construcción. No es formalismo metodológico: es que sin estos cinco documentos, las decisiones se toman igualmente, solo que sin información y por la persona equivocada.
Hay una forma sencilla de saber si el trabajo está bien hecho: entregar la documentación a alguien ajeno al proceso y pedirle que resuelva cinco casos reales.
Si lo consigue, el proceso está definido y se puede automatizar. Si tiene que preguntar, lo que falte en su pregunta es exactamente lo que faltaba en la documentación — y es lo que habría fallado en producción tres meses después.
Con cinco entregables: mapa de decisiones, inventario de datos con su sistema y su propietario, catálogo de excepciones, reglas de negocio no escritas y línea base de rendimiento. Se obtienen en unos diez días de trabajo con cuatro sesiones y no requieren un proyecto largo de consultoría.
Porque las personas describen el camino principal en su versión ideal: omiten las excepciones por parecerles anecdóticas, los atajos por prudencia y las reglas no escritas por evidentes. Esas tres omisiones son justamente lo que rompe una automatización en producción.
«Cuéntame el último caso que te dio problemas». Produce narración concreta en lugar de descripción abstracta, y en esa narración aparecen las excepciones, los atajos y los criterios tácitos sin necesidad de preguntar por ellos.
A tres o cuatro personas que ejecutan el proceso, por separado y no en grupo, porque en grupo se impone la versión oficial. Los responsables conocen el diseño y quienes ejecutan conocen la realidad; hacen falta ambos, empezando por los segundos.
Tres: entrevistar en grupo, preguntar solo a los responsables en lugar de a quien ejecuta, y documentar el proceso ideal en vez del real. La tentación de arreglar mientras se documenta es fuerte y destruye el valor del trabajo: primero se registra lo que pasa, el rediseño es una fase posterior.
Entregándola a alguien ajeno al proceso y pidiéndole que resuelva cinco casos reales. Si lo consigue, el proceso está definido; si tiene que preguntar, lo que falte en su pregunta es exactamente lo que habría fallado en producción.
¿Quieres el mapa real de tu proceso antes de invertir en tecnología? En dos semanas entregamos las decisiones, los datos, las excepciones, las reglas no escritas y la línea base. Sirve tanto si automatizas como si no. Hablemos → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
