Modernitzar un ERP legacy: quan convé migrar i quan no

Hi ha dos tipus d’ERP legacy. Un és el sistema vell que va, factura, no dona problemes i que ningú vol tocar. L’altre és el vell que sí dona problemes, tothom els coneix, i el dubte és quan modernitzar-lo.

El que ve a continuació no és per al primer. Si el teu ERP és estable, cobreix el que necessites i no tens funcionalitats noves a la cua, mantén-lo. Parlem del segon: quan el deute tècnic comença a costar més que arreglar-lo, quins senyals objectius mirar abans de decidir, i quines estratègies existeixen més enllà del fals dilema de “llançar-ho tot o aguantar”.

Les 7 senyals que el teu ERP s’ha quedat petit

Aquestes decisions solen arrencar amb una intuïció vaga: “això va lent, hi ha coses que no podem fer”. Abans de posar diners en consultoria, convé traduir aquesta intuïció a alguna cosa mesurable. Els senyals que es repeteixen en les auditories que fem:

1. Hi ha un Excel paral·lel per a cada mòdul de l’ERP. Si el sistema no genera el report que necessita l’operativa o no permet la correcció que demana negoci, l’equip se’n va a Excel. Cada Excel paral·lel és un forat de dades sense sincronitzar.

2. Qualsevol modificació passa pel proveïdor original. I el proveïdor triga setmanes, cobra per hora o, pitjor, ja no existeix. El que hauria de ser un canvi operatiu es converteix en un projecte.

3. Les integracions modernes no són possibles. Facturació electrònica, bancs per API, fitxatge digital, e-commerce. Si cada connexió nova es resol amb un bolcat CSV nocturn, el deute creix sol.

4. Les dades es llegeixen, ja no s’escriuen. L’ERP guarda l’històric, però les decisions del dia a dia es prenen fora. Senyal clar que el sistema ha deixat de ser el sistema de rècord.

5. Onboarding etern. Aprendre un ERP propietari sense documentació moderna pren mesos. Quan algú nou triga a ser productiu el que hauria de costar setmanes, hi ha un cost d’oportunitat real.

6. Només una persona sap com funciona per dins. I normalment està a tres anys de la jubilació. El bus factor és 1.

7. Negoci demana funcionalitats i “no es poden fer”. El sistema decideix què és viable. Quan la limitació tècnica dicta l’estratègia comercial, l’ERP dirigeix l’empresa en lloc de servir-la.

Si te’n trobes amb tres o més, la modernització ja no és opció: és una urgència silenciosa. Silenciosa perquè el sistema segueix funcionant. El cost s’acumula a la corba d’ineficiència, no en una fallada visible.

Les 4 estratègies reals de modernització

El fals dilema més repetit és “ho llancem tot o aguantem”. Hi ha quatre opcions reals, i cadascuna té el seu escenari on guanya.

Estratègia 1: Rewrite total (big bang)

Reescriure el sistema sencer en paral·lel i fer cutover en una data concreta.

Guanya quan: el sistema és petit (menys de 5 mòduls, menys de 20 usuaris), el model de dades està documentat, el domini de negoci és estable, o hi ha una data regulatòria que obliga (un nou RD, facturació electrònica amb format imposat, etc.).

Perd quan: el sistema és gran i arrossega anys de regles no documentades. El rewrite les “redescobreix” a base de bugs en producció. També perd si l’empresa no es pot permetre de 6 a 18 mesos sense funcionalitats noves.

Estratègia 2: Strangler Fig

Patró de Martin Fowler. S’envolta el sistema antic amb una capa moderna (API gateway, façana web) i es migren mòduls d’un en un. El sistema vell mor a poc a poc; el nou va assumint responsabilitats.

Guanya quan: la pime té un sistema mitjà (5-10 mòduls), vol validar arquitectura nova sense comprometre’s del tot, o té un equip petit que no pot mantenir dos sistemes en paral·lel total.

Perd quan: el model de dades és tan centralitzat que no es pot trossejar per mòduls. O quan negoci exigeix tot migrat ja, sense convivència.

Estratègia 3: Side-by-Side

Antic i nou conviuen amb sincronització bidireccional. Els usuaris utilitzen el que els convé. El vell s’apaga quan tot el flux crític ha passat al nou.

Guanya quan: la migració té risc zero permès de pèrdua de dades, el sistema és crític i una fallada no pot aturar l’operativa, o el client vol validar el proveïdor nou en producció abans de comprometre’s.

Perd quan: et pot sortir car. Estàs mantenint dos sistemes durant mesos o anys, i l’equip es duplica. La sincronització bidireccional afegeix complexitat: qualsevol inconsistència es replica a l’altre costat.

Estratègia 4: Estendre, no migrar

A vegades la resposta correcta és no migrar. L’ERP antic funciona, el que li falta és obertura. Es construeix a sobre, sense tocar el core: API REST sobre el model de dades legacy, web i mòbil consumint aquesta API, integracions modernes que el sistema antic mai tindrà nativament.

Guanya quan: l’ERP cobreix el 80% del que necessites i només falta la capa moderna (web, mòbil, integracions), el cost de migrar excedeix clarament el ROI, o el proveïdor segueix donant suport al sistema base.

Perd quan: el sistema antic és una caixa negra sense accés al model de dades. O quan la tecnologia és tan vella que no hi ha manera estable de posar-li una API a sobre.

A la pràctica, la majoria de pimes que es modernitzen bé van per l’estratègia 2 (strangler) o la 4 (estendre). El rewrite total té el seu lloc, però és minoritari.

Com decidir: la matriu del cost mensual

La decisió rarament és tècnica; és financera. I la pregunta correcta no és “quant costa modernitzar?”, sinó aquesta altra: “quant em costa al mes no fer-ho?”.

Cost mensual de no modernitzar (estimació honesta, sense maquillatge):

• Hores perdudes en Excels paral·lels × salari mitjà de l’equip
• Hores de l’equip IT en pegats manuals
• Errors de transcripció que detectes (els que no detectes són pitjors)
• Funcionalitats de negoci que no es poden llançar (lucre cessant)
• Risc de bus factor: probabilitat × impacte si la persona clau desapareix
• Feina manual per falta d’integracions: enviaments, conciliacions, validacions creuades

Cost mensual de modernitzar (amortitzat a 5 anys):

• Inversió total ÷ 60 mesos
• Manteniment del sistema nou
• Corba d’aprenentatge de l’equip

Si el primer supera el segon, la decisió és aritmètica. Si està a prop, cal ponderar risc regulatori, fuga de talent i moment estratègic. Variables que no van en un full de càlcul però que pesen igual.

El factor que gairebé ningú avalua: l’estat de les dades

A les auditories que fem abans de començar una modernització, el que més subestima el client no és la complexitat tècnica del sistema nou. És l’estat de les dades de l’antic. I això és el que sol triplicar terminis.

Preguntes que cal respondre abans de tocar codi:

• Hi ha duplicats en clients, proveïdors o productes?
• Els codis de compte comptable estan alineats amb la realitat fiscal d’avui, o amb la de fa vuit anys?
• Quants anys d’històric cal migrar de debò i quants poden quedar en mode consulta?
• Existeixen catàlegs orfes, registres sense referència creuada, NIFs mal formats?
• L’operativa utilitza camps lliures com si fossin estructurats? (Spoiler: sí, gairebé sempre.)

Cada punt és un mini-projecte. Una modernització seriosa arrenca amb una auditoria de dades de 2-3 setmanes abans de tocar res.

I el compliance durant la migració?

Si el sistema antic cobreix obligacions regulatòries (registre horari pel RD-Llei 8/2019, facturació electrònica, RGPD, conservació fiscal de 4 anys, etc.), la modernització no pot trencar aquest compliment durant la transició. Side-by-side i strangler faciliten que tots dos sistemes segueixin generant registres legalment vàlids. Un big bang mal planificat deixa l’empresa amb períodes no documentats, exposada a sancions.

Quan hi ha obligació de fitxatge o retenció de dades durant la migració, el que recomanem:

1. Mantén el sistema vell com a sistema de rècord legal fins que el nou estigui validat.
2. Genera els registres en tots dos durant la convivència. És feina extra, sí; ho és menys que defensar davant la Inspecció que falten tres mesos.
3. Apaga l’antic només quan hagis superat la fase crítica (3 a 6 mesos) sense incidències al nou.

Build vs Buy: a mida o SaaS?

La pregunta paral·lela és legítima: ja que gastarem diners, per què no comprem un SaaS estàndard i ens n’oblidem? Ho desenvolupem a fons a Software a mida vs SaaS: quan triar cada un. El resum: si el teu ERP heretat existeix precisament perquè els teus processos no encaixen en un SaaS estàndard, la resposta segueix sent a mida. Si els processos s’han estandarditzat amb els anys i un SaaS sectorial cobreix el 90%, allà sí canvia la decisió.

Com treballem nosaltres una modernització

Els passos que apliquem quan un client ens demana modernitzar un ERP heretat:

1. Auditoria inicial (2-3 setmanes). Revisió de codi, model de dades, integracions, qualitat de dades, processos crítics. Acaba amb un informe que defineix abast real, no l’aspiracional.
2. Decisió d’estratègia. Recomanem rewrite, strangler, side-by-side o estendre, amb justificació documentada i sense amor propi per una opció.
3. POC del mòdul més crític (4-6 setmanes). Abans de comprometre’s al projecte complet, validem la viabilitat amb el mòdul que més fa mal si falla. Si la prova no convenç, es para.
4. Roadmap iteratiu. Lliuraments cada 2-3 setmanes amb revisió conjunta. Res de “torno als 6 mesos amb això acabat”.
5. Migració per fases. Els usuaris passen a producció amb cada mòdul tan bon punt està llest. Res de big bang.
6. Apagat controlat del legacy. Només quan el flux crític porta almenys un trimestre en producció sense incidències.

Si tens un ERP que sospites que ha arribat al límit, parlem. Una trucada de 30 minuts sol bastar per distingir si el que necessites és modernització seriosa o només una capa d’integracions a sobre.

Recursos

• Patró Strangler Fig (Martin Fowler, original)
• Control horari obligatori RD-Llei 8/2019: què tenir en compte si modernitzes un sistema que registra jornada.
• Software a mida vs SaaS: quan cada un: la decisió paral·lela que convé prendre abans de començar.
• Serveis de VisibleSoft: quin tipus de projectes de modernització abordem.
• Reserva un diagnòstic gratuït