Desarrollo de software a la medida: cuando el ERP estándar no alcanza

Un supervisor de mina copia cada semana el reporte de disponibilidad de maquinaria del ERP a una hoja de cálculo aparte, porque el sistema no distingue tiempo de guardia de tiempo productivo por turno. Un jefe de obra hace lo mismo con el avance físico contra el presupuesto, porque el módulo de proyectos no modela avance por fase de construcción. Ese doble trabajo, repetido semana tras semana por la persona con más criterio del equipo, es la señal de que falta una capa de desarrollo de software a la medida entre el ERP y la operación real.

Por qué el ERP estándar cubre la administración pero no la operación real

Un ERP estándar se construye sobre procesos genéricos de gestión: compras, inventario, contabilidad, facturación. Son procesos que se repiten, con variaciones menores, en casi cualquier empresa que compra insumos, mueve mercancía y factura. Por eso un ERP estándar funciona bien ahí sin necesidad de tocar una línea de código.

Qué sí resuelve el ERP estándar de fábrica

Compras centraliza a los proveedores y evita duplicar órdenes. Inventario da visibilidad de existencias entre bodegas. Contabilidad y facturación mantienen los libros al día y cumplen con los comprobantes fiscales del país. Ese es el terreno donde un ERP estándar es, precisamente, la base correcta: no tiene sentido pagar un desarrollo a la medida para reinventar la contabilidad.

Dónde empieza a fallar: el borde operativo

Minería, agroindustria y obra civil tienen un borde operativo que no encaja en ese molde. Una operación minera necesita cruzar turnos, disponibilidad de maquinaria y mantenimiento preventivo en un mismo tablero. Una planta agroindustrial necesita trazabilidad por lote, desde la materia prima hasta el producto empacado. Una obra civil necesita medir avance por fase, no solo gasto acumulado contra presupuesto.

La brecha no es un defecto del ERP. Es forzarlo a cubrir, con formularios genéricos o planillas paralelas, un borde operativo para el que no fue diseñado. Ahí es donde el desarrollo de software a la medida deja de ser un lujo y pasa a ser la pieza que faltaba.

El error habitual es pedirle al ERP que se estire hasta ese borde con configuración pura: un campo extra aquí, un flujo de aprobación forzado allá. Cada ajuste de ese tipo funciona para el caso que lo motivó y se rompe con el siguiente, porque el ERP sigue pensando en términos de compras y facturas, no de turnos, lotes o fases de obra. El síntoma es acumulativo: cada actualización del sistema arriesga romper esos parches, y el equipo de TI termina manteniendo una capa de excepciones que nadie documentó a fondo.

Anatomía de un proyecto de software a la medida: del levantamiento de procesos al despliegue por fases

Un proyecto de desarrollo a la medida bien planteado no empieza en una pantalla de diseño. Empieza en el terreno, con las mismas personas que hoy resuelven el problema a mano.

Levantamiento: hablar con quien opera la maquinaria, no solo con quien factura

El levantamiento de procesos se hace con el equipo de operación, no solo con TI. Quien opera la maquinaria, lleva el registro de lote o mide el avance de obra sabe exactamente dónde se rompe el proceso hoy, y ese detalle no aparece en un diagrama de flujo dibujado desde una oficina. Sin esa conversación, el desarrollo resuelve el problema equivocado con elegancia.

Por qué el despliegue por fases reduce el riesgo del megaproyecto

Un proyecto serio prioriza el proceso crítico que genera más fricción, no el catálogo completo de procesos a la vez. El despliegue va por fases, con validación en campo antes de escalar a toda la operación: primero un turno, una línea o un frente de obra; después el resto, ya con los ajustes que solo el uso real revela.

El desarrollo a la medida se integra con el ERP existente, no lo reemplaza. Sigue leyendo y escribiendo sobre la misma base de compras, inventario y contabilidad; lo que agrega es la capa que conecta esa base con el borde operativo específico del sector. Entre lo que suele cubrir esa integración está:

• Sincronizar el dato operativo capturado en campo con el ERP, sin doble digitación.
• Reflejar en un solo tablero lo que hoy vive repartido en varias hojas de cálculo.
• Dejar trazabilidad del proceso crítico priorizado, no de todo el catálogo a la vez.

Esa integración es también la garantía de que el ERP no se convierte en un sistema aparte del resto de la operación. Los reportes financieros siguen saliendo del mismo lugar; lo que cambia es que ahora esos reportes incorporan, sin transcripción manual, el dato que antes vivía solo en la hoja de cálculo del supervisor.

Cómo evaluar el caso de negocio antes de firmar el contrato

Antes de comprometer presupuesto en un desarrollo a la medida, el caso de negocio se evalúa mirando costos y beneficios concretos, no una cifra de retorno prometida de antemano.

El primer costo a mirar es el de no resolverlo: las horas de un supervisor reconciliando datos a mano entre sistemas, el retrabajo que genera la falta de trazabilidad cuando algo sale mal y nadie puede reconstruir en qué fase ocurrió. Ese costo ya se paga hoy, aunque no aparezca en ninguna factura.

El segundo criterio es distinguir gasto recurrente de inversión en capacidad. Las licencias y el soporte son gasto recurrente. El desarrollo a la medida, en cambio, queda como un activo propio de la empresa: el código, la lógica del proceso y el conocimiento capturado no se pierden si cambia de proveedor.

Qué preguntar antes de firmar, más allá del precio

• ¿Quién del equipo de operación participó en el levantamiento, además de TI?
• ¿Cuál es el proceso crítico que se prioriza primero, y por qué ese y no otro?
• ¿Cómo queda documentado y quién es dueño del código una vez entregado?
• ¿Qué plan de mantenimiento y evolución existe después de la primera fase?
• ¿Cómo se integra con el ERP actual en lugar de duplicar información?

Ningún proveedor serio promete un plazo de retorno exacto antes de conocer la operación a fondo. Si alguien lo hace en la primera reunión, esa cifra no viene de tu operación: viene de una plantilla de ventas.

Quién debería liderar la decisión: TI, operación, o ambos

Una decisión mixta entre TI y operación evita implementar algo que funciona en el papel pero no en la planta, la mina o la obra. TI aporta criterio sobre integración, seguridad y mantenimiento a largo plazo; operación aporta el detalle de dónde se pierde el tiempo hoy. Ninguna de las dos partes tiene la vista completa por sí sola.

Un proveedor que no conoce la operación real difícilmente identifica dónde se rompe el proceso, por más experiencia técnica que tenga. Por eso el siguiente paso no es una demo genérica de software, sino una conversación técnica sobre el proceso específico que hoy te cuesta más: qué turno, qué lote, qué fase de obra.

Esa conversación técnica también sirve para filtrar propuestas. Un proveedor que responde con un catálogo de funciones antes de preguntar cómo opera tu planta, tu mina o tu obra está vendiendo un producto genérico con otro nombre, no un desarrollo a la medida. La pregunta que separa una propuesta seria de una plantilla de ventas es simple: ¿puede explicar, con tus propias palabras, dónde se rompe hoy tu proceso?

Si necesitas que implementemos esta arquitectura en tu empresa, agenda una consultoría con Grupo LDE.