Un cliente nos contactó el año pasado queriendo un panel de reportes personalizado. Tenía una imagen clara en mente - gráficos, filtros, tablas exportables. Incluso había hecho algunos bocetos aproximados. Parecía un proyecto sencillo.
Pasamos una semana mapeando cómo se movían realmente los datos a través de su empresa antes de abrir ningún editor de código. Lo que encontramos lo cambió todo. El problema no era que les faltara un panel de reportes. El problema era que los datos que alimentarían cualquier panel habrían sido erróneos, porque las personas que los introducían seguían cuatro convenciones distintas sin ningún estándar compartido. Un panel hermoso construido sobre datos malos habría sido una manera cara de mostrar números incorrectos más rápidamente.
Les ayudamos primero a corregir el proceso de entrada de datos. El panel vino después, más simple y barato de lo originalmente planeado, y fue realmente útil desde el primer día.
Por eso siempre empezamos con una auditoría de procesos.
Qué es realmente una auditoría de procesos
El nombre evoca un largo y costoso compromiso de consultoría. No lo es.
Una auditoría de procesos es un ejercicio enfocado y limitado en el tiempo - normalmente una o dos semanas - basado en conversaciones estructuradas y observación directa. El objetivo es entender cómo fluye realmente el trabajo a través del negocio: quién hace qué, en qué orden, con qué información, y dónde las cosas se atoran.
Mapeamos las entregas. Miramos dónde se toman las decisiones y de qué información dependen esas decisiones. Preguntamos dónde el trabajo se atasca, se duplica o se pierde. Miramos las herramientas que ya se usan y cómo se usan realmente frente a cómo estaban destinadas a usarse.
Sin informes extensos. Sin marcos metodológicos por el mero hecho de tenerlos. El resultado es una imagen clara de dónde está la fricción real y qué intervención tendría más impacto.
Qué buscamos
Cada empresa tiene su propia versión de los mismos problemas. Buscamos:
Cuellos de botella - pasos en un proceso donde el trabajo se acumula porque dependen de una sola persona, una sola herramienta o una sola decisión que no puede mantener el ritmo del volumen entrante.
Pasos manuales que existen porque nadie los cuestionó - datos copiados a mano de un sistema a otro, aprobaciones hechas por WhatsApp porque no hay un flujo de trabajo adecuado, informes ensamblados cada lunes por la mañana a partir de cinco hojas de cálculo distintas.
Datos duplicados - información de clientes en el CRM, en el sistema contable y en una hoja de cálculo personal, todas ligeramente distintas, ninguna definitivamente correcta.
Decisiones tomadas a ciegas - gerentes que eligen niveles de inventario, personal o precios sin datos fiables en los que basar esas decisiones, o con datos que llegan demasiado tarde para ser útiles.
Estos no son problemas exóticos. Aparecen en casi todas las empresas con las que trabajamos. La pregunta no es si existen - es cuáles cuestan más y cuáles puede realmente solucionar el software.
Qué cambia la auditoría
El resultado de una buena auditoría de procesos raramente confirma el plan original. Con más frecuencia, cambia tres cosas.
Primero, el alcance. Lo que el cliente pidió es demasiado grande, demasiado pequeño, o apunta al objetivo equivocado. Un cliente que pidió un sistema completo de gestión de inventario puede descubrir que el 70% de su dolor viene de un cuello de botella específico que podría abordarse con una herramienta mucho más simple. O descubre que el alcance necesita ampliarse porque el problema que describió está aguas abajo de un problema estructural más grande.
Segundo, el orden. Incluso cuando la visión original es básicamente correcta, la secuencia en la que se construyen las cosas importa. Una auditoría de procesos revela qué partes de un sistema están bloqueando todo lo demás y deben construirse primero. Construir en el orden equivocado significa que las partes posteriores nunca se usan porque los cimientos no eran correctos.
Tercero, el enfoque. A veces la auditoría revela que el problema no requiere software personalizado en absoluto. Una herramienta existente, correctamente configurada y realmente adoptada, haría el trabajo. Es una conclusión incómoda cuando un cliente llegó esperando encargar un desarrollo - pero es la honesta, y ahorra dinero significativo.
Por qué la mayoría de las agencias se la saltan
La respuesta es directa: retrasa el inicio del desarrollo facturable.
Una agencia que gana dinero construyendo tiene un incentivo estructural para empezar a construir lo antes posible. La fase de descubrimiento - entender el problema antes de proponer la solución - es un centro de coste que retrasa los ingresos.
Creemos que es una falsa economía, tanto para nosotros como para los clientes. Los proyectos construidos sin un descubrimiento adecuado tienen más probabilidades de requerir retrabajos significativos, cambios de alcance y conversaciones difíciles más adelante. Eso es caro para el cliente y perjudica la relación. Preferimos pasar dos semanas entendiendo el problema y construir lo correcto una sola vez.
Qué te cuesta saltártela
El patrón es consistente: una empresa identifica un punto de dolor, encarga una solución de software, se construye la solución, la gente intenta usarla, y resulta que la solución no se ajusta a cómo fluye realmente el trabajo. El sistema requiere soluciones alternativas. La gente vuelve a sus viejos hábitos. El proyecto se declara terminado pero el problema no está resuelto.
Entonces llega la conversación sobre la reconstrucción. Más dinero, más tiempo, y ahora un equipo escéptico porque ya han pasado por esto una vez.
Hemos heredado suficientes de estas situaciones para saber cómo ocurren. Casi todas podrían haberse evitado con una auditoría de procesos seria al principio. No un ejercicio de marcar casillas - una mirada real y honesta a cómo funciona el negocio antes de decidir qué construir.
Cómo lo abordamos
Cada proyecto que asumimos empieza con una auditoría de procesos. No es opcional y no es decorativa. Es la base sobre la que se construye todo lo demás.
Programamos conversaciones estructuradas con las personas que realmente hacen el trabajo - no solo gerentes describiendo cómo creen que funcionan los procesos, sino las personas sobre el terreno que saben dónde está la fricción real. Observamos los flujos de trabajo cuando es posible. Miramos qué datos existen, dónde viven y qué tan fiables son.
El resultado es un brief claro: cuál es el problema real, qué recomendamos construir, en qué orden y por qué. Ese brief guía todo lo demás - el alcance, el cronograma, la arquitectura.
No es la fase más emocionante de un proyecto. Pero es la que determina si el proyecto tiene éxito.
Si estás considerando una inversión en software y quieres empezar por entender bien el problema, ponte en contacto.