Criterios para elegir un ERP adaptable

Los sistemas integrados de gestión —los ERP— aparecieron para resolver contabilidad, facturación, compras, inventario y planificación de la producción en un solo sitio, en lugar de tener un programa por departamento. Ese sigue siendo su trabajo y lo hacen bien.

Lo que ha cambiado es la expectativa. Hoy se le pide además que se comunique con todo lo demás, y ahí es donde se separan los que se adaptan de los que obligan a adaptarse. Estos son los criterios que importan, y por qué el mantenimiento es el caso que mejor los pone a prueba.

1. Que sea integral

Que pueda cubrir las áreas y departamentos de la empresa sin dejar huecos que haya que tapar con hojas de cálculo. No significa que tenga que hacerlo todo: significa que lo que hace, lo hace con el mismo dato y sin duplicarlo.

La prueba práctica es sencilla: pregunta cuántas veces se teclea un cliente nuevo desde que entra hasta que se le factura. Si la respuesta es más de una, el sistema no es tan integral como parece.

2. Que sea modular

Que se pueda implantar por partes y crecer después. Es lo que permite empezar por lo urgente sin comprar de golpe funcionalidad que no se va a usar en dos años.

Aquí conviene hacer una pregunta incómoda y muy reveladora: qué pasa cuando necesitas algo que está en otro módulo. Si la respuesta es una ampliación de contrato cada vez que surge una necesidad nueva, el coste real del sistema no es el que figura en la oferta inicial.

3. Que sea adaptable

Es el criterio que engloba a los otros dos. Adaptable significa que admite módulos específicos junto a los estándar, para cubrir lo que cada empresa necesita de verdad sin convertirlo en un desarrollo a medida imposible de mantener.

Y dentro de este criterio está el nexo entre un ERP y el mantenimiento.

Por qué el mantenimiento es la prueba del algodón

Casi ningún ERP resuelve bien el mantenimiento, y no por descuido: no es su materia. Concretamente deja fuera cuatro cosas.

La ficha del activo como historia. No el artículo comprado, sino el equipo instalado: dónde está, qué número de serie tiene, qué se le ha hecho, qué anomalías quedaron abiertas, cuánto lleva costando acumulado.

La periodicidad. Un ERP no genera solo la revisión semestral de doscientos equipos ni comprueba si el día que toca es festivo o si el técnico está de vacaciones.

El trabajo en campo. Es la carencia más clara. Los ERP están pensados para una oficina, y el mantenimiento ocurre en una cubierta, en un sótano o en una nave sin cobertura.

La relación con quien recibe el servicio. Quién avisó, con qué prioridad, qué se le prometió y qué se le puede demostrar después.

Un GMAO cubre exactamente eso, y por eso encaja como módulo específico junto al ERP en lugar de competir con él. Está desarrollado en cómo se plantea la integración.

La frontera: quién manda en cada dato

Esta es la decisión que determina si la integración funciona, y es anterior a cualquier cuestión técnica.

El ERP manda en clientes, artículos y tarifas. El GMAO manda en activos, intervenciones y consumos. Cada dato tiene un único sitio donde se crea y se modifica; el otro sistema lo recibe y no lo toca.

Tiene sentido si se piensa en quién crea cada cosa: el alta de un cliente nace en el circuito comercial, no en mantenimiento; un consumo de repuesto nace cuando un técnico abre la caja, no cuando alguien lo factura.

Sin esa frontera acordada pasa siempre lo mismo: el mismo cliente existe dos veces con dos códigos, alguien corrige un artículo en el sistema equivocado y la siguiente sincronización deshace la corrección. No es un fallo del software; es un fallo de diseño.

Qué preguntar sobre las integraciones

La pregunta «¿os integráis con X?» no sirve, porque la respuesta siempre es que sí. Las que sirven son estas.

¿Qué dato viaja y en qué dirección? No todos los conectores hacen lo mismo. Los hay que solo traen maestros —clientes, direcciones, artículos— y no devuelven nada; los hay que exportan órdenes para facturación pero no importan. En el catálogo de integraciones de GMAO CLOUD está el alcance de cada uno: por ejemplo, Sage X3 importa clientes, direcciones y artículos, pero no exporta órdenes de trabajo.

¿Con qué frecuencia? Casi nunca hace falta tiempo real. Que las órdenes cerradas lleguen cada noche suele bastar, y es mucho más barato de mantener.

¿Qué pasa si mi sistema no está en la lista? Es el caso más frecuente. Lo que importa entonces es que existan vías genéricas: API REST, SOAP, acceso directo a base de datos, intercambio por CSV o FTP. Son las que cubren los casos que nadie previó, incluidos los desarrollos a medida de hace quince años.

¿Quién resuelve los conflictos? Habrá un cliente duplicado y un artículo sin código. Conviene decidir antes quién lo mira y con qué criterio.

Lo que no hay que hacer

Migrar el ERP para poder hacer mantenimiento. Es un proyecto caro, con una curva de aprendizaje larga y con riesgo en el circuito que factura. Si el ERP funciona, lo sensato es dejarlo y añadir encima la pieza que le falta.

Intentar sincronizarlo todo en ambos sentidos. Es la forma más rápida de complicar un proyecto que podía ser sencillo. Se empieza trayendo clientes y artículos y mandando las órdenes cerradas con sus horas y consumos, y el resto se deja para cuando esa parte lleve meses funcionando sin que nadie la mire.

Dar por hecho que la trazabilidad sobrevive al salto. Si el dato viaja pero se pierde quién hizo qué y cuándo, la integración ha convertido un registro en un importe. Lo que da valor al histórico es poder reconstruir la intervención.

Y una observación sobre el orden de los proyectos, porque la pregunta aparece siempre: rara vez conviene hacer el ERP y el mantenimiento a la vez. Compiten por las mismas personas y por la misma paciencia de la organización. Lo razonable es empezar por el que resuelva el problema que más duele hoy y dejar el otro para cuando el primero lleve meses funcionando solo.

Si quieres que veamos cómo encajaría con tu ERP actual, puedes escribirnos o solicitar una demo.