Implementacions de NetSuite que s'endarrereixen: 7 patrons

Una implementació de NetSuite al mid-market es dimensiona habitualment en quatre a set mesos. Segons la nostra experiència amb clients ibèrics, les que s'endarrereixen no s'endarrereixen dues setmanes: s'endarrereixen un trimestre o més, i ho fan per un nombre reduït de causes que es repeteixen amb una constància gairebé tediosa.

Aquesta constància és la part útil. Si el fracàs fos aleatori, l'única defensa seria un pressupost de contingència. No és aleatori. En els projectes que hem heretat d'altres partners a mig camí, els mateixos set patrons expliquen la gran majoria de la desviació, i en tots els casos el patró era detectable el primer mes —normalment la primera quinzena— per algú que sabés què buscar.

Aquest article és aquesta llista. Està escrit per fer-se servir com a diagnòstic sobre un projecte ja en marxa, no només com a llista de comprovació per a un que s'està planificant.

Per què importa

El cost d'una desviació en un ERP no són els honoraris addicionals de consultoria, tot i que siguin la part que apareix a l'informe per al consell d'administració. El cost real s'acumula i és en bona part invisible.

Un projecte que s'endarrereix dos trimestres obliga l'equip financer a mantenir dos sistemes en paral·lel durant dos tancaments addicionals. Consumeix la credibilitat del sponsor intern, que és el recurs que el projecte necessita més en el seu darrer terç. I empeny el go-live cap a un període que ningú no ha escollit: el moment del go-live importa, perquè arrencar un ERP nou tres setmanes abans d'un termini de reporting obligatori o en plena temporada alta converteix una transició gestionable en una crisi.

El més determinant és que canvia allò que l'organització creu. Una empresa que ha viscut un mal projecte d'ERP ajornarà anys el canvi necessari següent, i l'abordarà amb un aparell de governança tan feixuc que el segon intent serà més lent que el primer. La desviació és cara; la cicatriu institucional ho és més.

D'un cop d'ull: els set patrons

La columna que importa és la segona. Tots els senyals són observables molt abans de la fase en què aterra el cost.

Els set patrons en detall

1. Requisits recollits com a llista de funcionalitats en lloc de com a procés.
El mode de fallada és un document de requisits que es llegeix com una llista de coses que el sistema ha de poder fer, sense cap descripció dels fluxos d'extrem a extrem als quals aquestes capacitats han de donar servei. El sistema es construeix contra la llista, passa una verificació funcional contra la llista i després no supera l'acceptació d'usuari perquè ningú no pot completar-hi una jornada real de feina. La solució no té glamur: documenti els vuit a dotze processos d'extrem a extrem que importen —order-to-cash, compra a pagament, registre a informe, devolucions, tancament— com a fluxos amb responsables i traspassos, i dissenyi contra aquests.

2. Absència d'un únic responsable de decisió amb autoritat.
El disseny d'un ERP genera centenars de decisions, moltes de transversals i algunes genuïnament de suma zero entre departaments. Si no hi ha una persona que pugui resoldre aquestes decisions sense convocar un comitè, el projecte no fracassa de manera sorollosa: acumula una cua de punts oberts que discretament esdevé el camí crític. El senyal és fàcil de llegir: miri quant de temps queden sense resoldre les decisions de disseny a la setmana quatre. Si la resposta és més d'uns pocs dies, el projecte s'endarrerirà i cap esforç d'execució no ho evitarà.

3. Qualitat de les dades descoberta tard.
Tot pla d'implementació conté una fase de migració. Molt pocs contenen una fase de perfilat, que és on es descobreix que el 30 % dels registres de clients són duplicats, que els articles històrics tenen unitats de mesura inconsistents, que les dades bancàries dels proveïdors existeixen en tres formats i que els saldos d'obertura no quadren. Descobrir això durant la migració vol dir renegociar el calendari en el pitjor moment possible. Perfili el primer mes, mentre la troballa encara és barata.

4. La personalització com a resposta per defecte a cada mancança.
Cada personalització individual és defensable. El que mata és l'agregat: una instància molt scriptada és més lenta de provar, més difícil de suportar, més arriscada en les actualitzacions i —la part que sorprèn els clients— més lenta de canviar després, que era normalment la raó per implementar en primer lloc. La disciplina consisteix a exigir, per a cada personalització proposta, una resposta explícita a "què es trenca si adoptem el procés estàndard en lloc d'això?". De vegades la resposta és real. Sovint la resposta honesta és que algú prefereix la manera antiga, i això no és un requisit.

5. La integració tractada com a tasca posterior.
En la majoria dels projectes amb problemes que veiem, la integració es dimensiona després de la configuració base, i és allà on el calendari se'n va realment. La raó és que la integració és el punt en què les hipòtesis de dos sistemes sobre un mateix objecte —un client, una comanda, un preu— s'han de conciliar, i aquestes hipòtesis solen ser incompatibles de maneres que forcen canvis de disseny de tornada a la construcció base. El disseny de la integració pertany a la mateixa fase que el disseny base, no a una posterior.

6. Operacions no representada al disseny.
Finances patrocina els projectes d'ERP, de manera que finances assisteix als tallers. El magatzem, l'equip comercial i l'atenció al client sovint no hi assisteixen, o hi envien algú sense autoritat. El resultat és un sistema que tanca els llibres de manera impecable i fa que la preparació de comandes, l'elaboració d'ofertes o l'atenció d'una trucada d'un client siguin materialment més lentes que abans. La resistència operativa al go-live és gairebé sempre una fallada de disseny disfressada de gestió del canvi.

7. Formació planificada com a última activitat.
La formació es comprimeix perquè és al final d'un pla que ja ha consumit el seu marge. La conseqüència visible són dos primers mesos lents i propensos a l'error. La invisible és duradora: els usuaris que han après un sistema sota pressió de temps desenvolupen dreceres, i aquestes dreceres esdevenen el procés permanent de l'organització. Designi un responsable de formació i fixi les dates a l'inici del projecte, i protegeixi-les.

Sobre què cal ser honest

Part de l'endarreriment és legítima. Un projecte que s'allarga perquè el negoci ha canviat de debò —una adquisició, un canal nou, un canvi normatiu— no està fracassant. Confondre el canvi d'abast amb el fracàs produeix un equip de projecte que amaga els requisits nous, cosa que és pitjor.

Ni tots els patrons són culpa de la consultora, ni tots són del client. Els patrons 1, 4 i 5 recauen normalment en el partner d'implementació. Els patrons 2, 6 i 7 recauen normalment en el client. El patró 3 és compartit. Un partner que culpa el client dels set no és un partner que convingui mantenir, i un client que culpa el partner dels set tindrà el mateix projecte dues vegades.

Corregir un patró a mig camí costa més que prevenir-lo, i tot i així val la pena. L'instint quan un projecte va tard és prémer més en l'execució. Si la causa de fons és el patró 2 o el 3, prémer més empitjora la desviació, perquè s'està construint més de pressa sobre decisions que no estan resoltes o dades que no estan netes.

Una implementació neta no garanteix l'adopció. Aquests patrons prediuen si s'entra en producció dins de termini i de pressupost. Si el sistema s'utilitza realment bé és un problema diferent amb una resposta diferent, sobretot relacionada amb la propietat i el mesurament després del go-live.

Marc de decisió: diagnosticar un projecte en marxa

Recorri'l en ordre. Aturi's a la primera coincidència: aquest és el seu problema principal, i els punts posteriors no es resoldran fins que aquest no es resolgui.

1. Hi ha decisions de disseny sense resoldre des de fa més d'una setmana?
Arregli la governança abans de qualsevol altra cosa. Designi un únic responsable de decisió amb autoritat sobre el disseny transversal, doni-li una franja fixa a l'agenda i estableixi la regla que un punt no decidit passa per defecte al comportament estàndard del sistema després d'un termini fix. Res més d'aquesta llista no es pot arreglar mentre les decisions estiguin encallades.

2. Ha perfilat algú les dades reals?
Si no, aturi's i perfili ara: recomptes de registres, duplicats, completesa dels camps obligatoris, integritat referencial i si els saldos d'obertura quadren. Una setmana invertida aquí torna a valorar honestament la resta del pla.

3. La documentació de requisits descriu els processos d'extrem a extrem?
Si és una llista de funcionalitats, reconstrueixi-la com a fluxos abans de continuar configurant. Ho pot fer en tallers al llarg de dues setmanes i farà emergir les mancances que altrament apareixerien a l'UAT.

4. S'ha dissenyat la integració, o només s'ha enumerat?
Si només s'ha enumerat, incorpori-la al disseny immediatament i especifiqui, per a cada objecte integrat, el sistema de referència, la direcció del flux, la regla de resolució de conflictes i el requisit de latència. Faci-ho abans de continuar amb la configuració base, perquè les respostes canvien la base.

5. Està creixent el nombre de personalitzacions sprint rere sprint?
Si és així, instauri una porta de personalització: cada sol·licitud necessita una conseqüència de negoci concreta per adoptar l'estàndard en lloc d'això. Compti amb rebutjar-ne un terç, i compti que resultarà incòmode.

6. Han validat el magatzem, vendes i atenció al client els seus propis processos?
Si no, faci aquests tallers abans de l'UAT en lloc de descobrir la mancança durant l'UAT.

7. Té la formació un responsable designat i dates protegides?
Si no, assigni tots dos ara, i tracti aquestes dates com a inamovibles i no com el marge del projecte.

Cost i esforç indicatius

Els intervals suposen una única instància de NetSuite, d'una a cinc entitats i un perfil transaccional de mid-market. Els entorns multiinstància, les operacions de M&A simultànies o un projecte ja passat l'UAT canvien això de manera substancial. Sol·liciti un pressupost per a una avaluació dimensionada al seu projecte.

Preguntes freqüents

El nostre projecte ja va tard. Hem de moure la data de go-live o prémer l'equip?
Diagnostiqui primer. Si la causa són decisions encallades, dades brutes o una integració sense dissenyar, prémer l'equip augmenta el cost final perquè s'està construint sobre fonaments inestables. Si la construcció és realment sòlida i el que queda és volum, una empenta pot funcionar. Establir la diferència triga aproximadament una setmana i és la setmana de més valor de què disposa.

Com sabem si el problema és el nostre partner d'implementació?
Miri quins patrons hi són presents. Un partner responsable d'un document de requisits en format llista de funcionalitats, d'un nombre de personalitzacions no gestionat i d'una integració sense dimensionar no està lliurant al nivell exigible. Un partner que s'enfronta a decisions del client encallades, a responsables operatius absents i a la manca d'un responsable de formació està sent impedit de lliurar. Totes dues situacions són recuperables; requereixen respostes oposades.

Podem entrar en producció per fases per reduir el risc?
Sovint sí, i per a grups amb diverses entitats sol ser el correcte. Però la divisió en fases té un cost: un període amb dos sistemes en marxa i conciliació entre tots dos. Faci fases per fronteres on la conciliació sigui barata —per entitat legal o per geografia, rarament per funció—, perquè partir l'order-to-cash entre dos sistemes crea precisament la càrrega de conciliació que el projecte havia d'eliminar.

Quanta contingència ha de portar un projecte d'ERP al mid-market?
En lloc d'un percentatge, situï la contingència allà on la incertesa és realment: el sanejament de dades i la integració, que és on es concentren les desviacions. Un pla amb un 15 % repartit de manera uniforme és menys útil que un amb intervals realistes en aquells dos fluxos de treball i estimacions ajustades a la resta.

Encara no hem començat. Quina és la cosa de més valor per fer primer?
Perfilar les seves dades i designar el seu responsable de decisió. Totes dues costen gairebé res, totes dues s'ometen habitualment i juntes cobreixen els dos patrons que generen les desviacions més grans.

Tancament — Passos següents

Cap d'aquests set patrons no és exòtic i cap no requereix eines especialitzades per detectar-se. El que requereixen és algú disposat a buscar-los aviat, quan la troballa és incòmoda i no catastròfica, que és precisament quan ningú no vol sentir-ho, perquè el projecte encara va nominalment dins de termini.

Si la seva implementació està en marxa, el diagnòstic anterior triga un matí. Recorri'l en ordre i aturi's a la primera coincidència. Si encara està en planificació, les dues pòlisses d'assegurança més barates al seu abast són un perfilat de dades i un responsable de decisió designat, i cap de les dues no necessita una partida pressupostària.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora de NetSuite que treballa amb clients del mid-market a tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per aconseguir fluxos d'order-to-cash sense friccions, construint pipelines automatitzats de gestió de comandes que eliminen la introducció manual de dades entre els equips comercials i financers. Com a partner oficial d'implementació de Stacksync, Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació, convertint fluxos de comandes fragmentats en sistemes fiables i amb autosupervisió.

LinkedIn: https://www.linkedin.com/in/brunogd

Fonts

Els URL són a nivell d'editor i s'han de verificar abans de la publicació.

• Oracle NetSuite, documentació d'implementació i de bones pràctiques — https://docs.oracle.com/en/cloud/saas/netsuite/
• APQC, Open Standards Benchmarking (indicadors de rendiment de projectes d'ERP i TI) — https://www.apqc.org
• Panorama Consulting Group, ERP Report anual (dades de durada, pressupost i realització de beneficis dels projectes) — https://www.panorama-consulting.com
• Standish Group, CHAOS Report (recerca sobre resultats de projectes de TI) — https://www.standishgroup.com
• Experiència d'Atypical Tech en projectes d'implementació de NetSuite al mid-market ibèric