Cuando una empresa decide implementar un ERP, tarde o temprano aparece una frase que suena bastante lógica: “primero tenemos que levantar los procesos”.
El problema es lo que entendemos por levantar.
Si el ejercicio consiste únicamente en registrar cómo compra, vende, factura, produce o controla inventario la empresa actualmente, podemos terminar haciendo algo paradójico: usar un sistema nuevo para conservar problemas antiguos.
Un levantamiento de procesos debería servir para algo bastante más importante. Es el momento de entender cómo funciona realmente la organización y decidir qué vale la pena llevar al nuevo ERP, qué puede hacerse mejor y qué debería quedarse atrás.
El proceso declarado rara vez cuenta toda la historia
En una reunión, un proceso puede parecer perfectamente ordenado.
Una persona recibe determinada información, realiza una tarea y se la entrega a la siguiente. Sobre el papel, el flujo funciona.
Pero después aparece la operación real.
Hay excepciones, decisiones que se toman por fuera del flujo, información que llega tarde y reglas que nadie escribió porque “siempre se ha hecho así”. También aparecen diferencias entre cómo la gerencia entiende el proceso y cómo lo viven quienes trabajan diariamente con él.
Esa brecha entre el proceso declarado y el proceso real es justamente una de las cosas que un buen levantamiento debe descubrir.
Porque un ERP no gestiona solamente tareas. También conecta información, decisiones y personas.
Por eso, preguntar “¿cómo hacen esto hoy?” es insuficiente. También importa entender qué información necesita cada parte del proceso, dónde se pierde visibilidad y qué consecuencias tiene eso más adelante.
El problema que ves puede haber comenzado mucho antes
Los puntos de dolor y los cuellos de botella son una parte fundamental del levantamiento, pero existe un riesgo en concentrarse exclusivamente en ellos: el lugar donde aparece el problema no necesariamente es el lugar donde se origina.
Una demora visible en una etapa puede ser consecuencia de una decisión tomada antes. Una persona puede estar haciendo trabajo adicional porque la información que recibe no es suficiente. Una solicitud que parece razonable desde una tarea específica puede complicar el flujo completo.
Por eso conviene mirar el proceso desde arriba y no solamente desde el problema inmediato.
Esto también explica por qué durante un levantamiento deben participar perfiles distintos.
Los usuarios conocen el día a día. Saben dónde aparecen las excepciones, qué información necesitan y qué les dificulta trabajar.
Quienes toman decisiones tienen otra responsabilidad: evaluar si una necesidad particular realmente aporta al funcionamiento general del proceso.
Ambas miradas son necesarias, pero no son intercambiables.
“Siempre lo hemos hecho así” también es un requerimiento que hay que cuestionar
Toda organización tiene reglas que no aparecen en ningún procedimiento.
No están escritas, pero todos las conocen.
A veces responden a una necesidad real del negocio. Otras veces son simplemente la herencia de una herramienta anterior, una solución que funcionó alguna vez o una costumbre que terminó convirtiéndose en regla.
Cuando llega un nuevo ERP, esas prácticas suelen presentarse como requerimientos: “necesitamos que el sistema haga esto porque nosotros trabajamos así”.
Ahí aparece una de las decisiones más importantes del levantamiento.
¿Es una particularidad que realmente necesita el negocio o estamos intentando reproducir una costumbre?
En nuestra experiencia trabajando con Odoo, una manera de enfrentar esa conversación es comenzar mostrando cómo resuelve el proceso la funcionalidad estándar y, desde ahí, identificar las brechas reales junto al cliente.
No se trata de obligar a la empresa a adaptarse al software. Se trata de evitar el camino contrario: modificar el sistema antes de preguntarse si el proceso que queremos preservar todavía tiene sentido.
Del “as-is” al “to-be”: ahí está el verdadero valor del levantamiento
En proyectos ERP se suele hablar del as-is, la forma en que funciona actualmente la organización, y del to-be, cómo debería funcionar después.
La diferencia es importante.
Si el levantamiento termina solamente con una fotografía detallada del as-is, todavía falta la conversación más valiosa.
Hay que decidir qué se mantiene, qué puede mejorar aprovechando el estándar del ERP y qué corresponde descartar porque pertenece a una forma anterior de trabajar.
Eso también permite discutir las brechas con más criterio.
En vez de asumir que cada diferencia entre el proceso actual y el sistema debe convertirse automáticamente en una personalización, primero se puede evaluar si el estándar ofrece una mejor manera de resolverla.
Una vía es proponer el levantamiento desde las funcionalidades del Odoo nativo, involucrando tanto a usuarios como a quienes toman decisiones y revisando junto al cliente las particularidades que realmente necesita conservar.
No significa que todos los procesos de todas las empresas puedan resolverse siempre de forma estándar. Significa algo más prudente: antes de pedir que el ERP copie una particularidad, conviene entender por qué existe.
Un ERP nuevo no debería convertirse en un sistema antiguo con otra interfaz
Un mal levantamiento puede tener consecuencias que van más allá de la configuración del software.
Puede generar costos innecesarios, reducir la visibilidad sobre los flujos completos y contribuir a que las decisiones se tomen tarde o con información insuficiente.
Por eso, antes de comenzar una implementación, vale la pena hacer una pregunta incómoda:
¿Estamos diseñando cómo queremos trabajar o simplemente explicando cómo hemos trabajado hasta ahora?
La diferencia parece pequeña, pero cambia completamente el propósito del levantamiento.
El objetivo no debería ser preservar cada hábito de la organización dentro de un sistema nuevo. Debería ser entender suficientemente bien el negocio para distinguir aquello que realmente lo hace particular de aquello que simplemente se volvió costumbre.
Y esa decisión ocurre antes de configurar el ERP.
Antes de avanzar con tu implementación
Si tu empresa está en etapa de levantamiento, no evalúes su calidad por la cantidad de procesos, diagramas o requerimientos documentados.
Pregúntate algo más útil: ¿este trabajo nos está ayudando a decidir cómo queremos operar mañana?
Si la respuesta es no, probablemente todavía están describiendo el presente.