Suport d'ERP després del go-live: no dependre d'una persona

La majoria de les implantacions d'ERP tenen un pla ben definit fins al go-live i gairebé res definit després. El contracte del partner d'implantació s'acaba, l'equip de projecte es dissol i el suport passa discretament a ser responsabilitat de la persona interna que va estar més implicada durant el projecte — normalment perquè era qui entenia millor el sistema, no perquè ningú decidís deliberadament que n'havia d'assumir el suport d'ara endavant.

Això funciona durant un temps, perquè aquesta persona coneix realment bé el sistema. Deixa de funcionar en el moment en què agafa una baixa prolongada, canvia de lloc o marxa de l'empresa, i és aleshores quan l'organització descobreix que una quantitat substancial de coneixement operatiu existia només al cap d'una persona, no es va documentar mai i no té pla de successió. És una fallada del tot previsible i és previsible precisament perquè és habitual — la majoria de les empreses mid-market amb qui treballem han viscut alguna versió d'aquesta situació, normalment més d'una vegada.

Aquest article tracta de construir un model de suport de manera deliberada, abans del go-live i no després que la mancança es faci visible.

Per què això importa

El cost immediat d'un suport no documentat i dependent d'una sola persona és la fragilitat operativa: una pregunta que s'hauria de respondre en una hora triga dies perquè l'única persona que la podria respondre no està disponible i tots els altres estan reconstruint la lògica des de zero.

El cost acumulat és pitjor. Cada millora, canvi de configuració i solució provisional que aquesta persona fa de manera informal, sense documentació, es converteix en deute tècnic indistingible del problema d'acumulació de personalització que es tracta en un altre article d'aquesta sèrie — excepte que aquí s'acumula en la memòria institucional i no en el codi, cosa que és probablement més difícil de recuperar, perquè no hi ha cap registre per auditar ni codi per llegir. Quan aquesta persona acaba marxant, l'organització no perd només una persona: perd un mapa no documentat del seu propi sistema.

Hi ha també una dimensió de governança. Un sistema el funcionament del qual depèn del coneixement tàcit d'un únic individu és una debilitat de control que es fa visible en el pitjor moment possible — durant una auditoria, durant l'absència d'aquesta persona o durant un projecte posterior que necessita entendre la configuració actual i no pot, perquè ningú no la va escriure.

En resum: els components del model de suport

Totes les files d'aquesta taula existeixen durant una implantació ben portada, aportades pel partner com a part del projecte. La fallada no és que aquestes coses siguin difícils de fer — és que ningú no decideix deliberadament qui les fa quan s'acaba el contracte del partner.

Què funciona i sobre què cal ser honest

Què funciona:

Decidir el model de suport abans del go-live, no després. Això hauria de ser un lliurable concret del projecte d'implantació i no una ocurrència tardana — qui atén quin nivell d'incidència, amb quin recurs intern, escalant a quin recurs extern, documentat abans que s'acabi el contracte del partner en lloc de negociat amb presses després.

La documentació com a artefacte viu, no com a lliurament puntual. La documentació d'implantació descriu el sistema tal com es va construir. Un model de suport necessita documentació que descrigui el sistema tal com és ara, actualitzada cada vegada que canvia — la mateixa disciplina que el registre de personalitzacions que es tracta en un altre article d'aquesta sèrie, aplicada a la configuració en general i no només a la personalització.

Propietat designada, diferent del coneixement més profund. La persona que coneix millor el sistema és un recurs que cal protegir i donar-hi suport, no automàticament la propietària de la seva governança continuada. Separar aquests papers — un propietari responsable que garanteix que existeixin documentació, successió i procés, amb el suport de qui té el coneixement tècnic més profund — redueix la dependència d'una sola persona fins i tot abans que aquesta persona marxi.

Una relació mantinguda i de menor intensitat amb l'expertesa d'implantació. No necessàriament amb el partner original, i no a intensitat de projecte, però sí algun accés continuat a expertesa per a dubtes de configuració genuïnament difícils, avaluació de l'impacte de les actualitzacions i revisions periòdiques de l'estat de salut del sistema. Les empreses que tallen això del tot tendeixen o bé a infrautilitzar la capacitat del sistema, o bé a acumular una deriva de configuració que ningú no detecta.

Una cadència deliberada per revisar les actualitzacions del fabricant. Algú hauria de tenir assignada la tasca de revisar les notes de release, valorar l'impacte sobre la seva configuració i les seves personalitzacions concretes i provar abans que les actualitzacions s'apliquin — en lloc d'aplicar-les a cegues o d'ajornar-les indefinidament per por.

Sobre què cal ser honest:

Això costa diners reals i recurrents, i competeix amb altres prioritats posteriors al go-live. Un model de suport amb una disciplina documental adequada, propietat designada i accés mantingut a expertesa no és gratis, i les empreses mid-market hi inverteixen menys del que caldria amb freqüència, perquè el cost és visible i el risc que mitiga no ho és, fins que es materialitza.

La disciplina documental es degrada sense manteniment actiu. Un model de suport que comença ben documentat i deixa d'actualitzar-se al cap de sis mesos no és apreciablement millor que no tenir documentació, perquè una documentació obsoleta que contradiu l'estat real del sistema sovint és pitjor que una absència honesta de documentació — indueix activament a error.

La dependència d'una sola persona sovint serveix els interessos d'aquesta persona, encara que sigui sense intenció. Ser l'únic que entén el sistema és una font de seguretat laboral i d'influència, i pot haver-hi una resistència silenciosa a transferir realment aquest coneixement. Això s'ha de gestionar com un problema d'incentius i no només com un problema de documentació — reconegui i valori explícitament qui té el coneixement, en lloc de tractar la transferència com una cosa que se li imposa.

Les relacions mantingudes amb el partner necessiten un abast real, o resulten cares sense ser útils. Un contracte de retainer obert i sense abast definit tendeix a infrautilitzar-se fins que arriba una crisi i, aleshores, a dependre-hi excessivament. Una revisió periòdica de l'estat de salut amb abast definit, més disponibilitat per als dubtes genuïnament difícils, sol ser més útil que qualsevol dels dos extrems.

Marc de decisió: construir o arreglar el model de suport

Recorri'l en ordre. Aturi's a la primera coincidència.

1. El seu model de suport actual depèn del coneixement d'un individu concret, sense documentació?
Si és així, aquesta és la prioritat al marge de tot la resta — comenci a documentar ara la configuració i la lògica actuals, no com un projecte sinó com una disciplina continuada, començant per allò que aquesta persona consideri més crític o més fràgil.

2. Té una estructura de suport per nivells definida — qui atén quin nivell d'incidència?
Si no, defineixi-la ara. No cal que sigui elaborada en una empresa mid-market, però cal que existeixi i que es conegui, en lloc de recaure informalment en qui estigui disponible.

3. Hi ha una persona designada que respongui de la governança continuada del sistema, diferent de qui té el coneixement tècnic més profund?
Si no, assigni-ho explícitament. Els dos papers serveixen propòsits diferents i confondre'ls recrea la dependència d'una sola persona que aquest marc existeix per evitar.

4. Hi ha un procés de control de canvis per a les modificacions de configuració fetes després del go-live?
Si no, estableixi'n un, proporcionat a la seva escala — fins i tot un simple registre de què va canviar, per què i qui ho va aprovar evita que la deriva de configuració es torni impossible de rastrejar.

5. Té algun accés mantingut a expertesa de nivell d'implantació més enllà del seu equip intern?
Si no, i la seva capacitat interna és genuïnament suficient, pot estar bé — però confirmi-ho deliberadament en lloc de descobrir la mancança durant una actualització difícil o un requisit nou i complex.

6. Hi ha algú assignat a revisar i valorar les actualitzacions del fabricant abans d'aplicar-les?
Si no, assigni-ho. Aplicar actualitzacions a cegues i ajornar-les indefinidament són totes dues coses pitjors que un procés de revisió deliberat i provat, i això sovint no és responsabilitat explícita de ningú.

7. Tot l'anterior és al seu lloc — la documentació s'està mantenint realment al dia?
Auditi-ho periòdicament. Un model de suport amb l'estructura correcta però amb documentació en degradació fallarà en silenci, i l'única defensa és comprovar-ho, no suposar-ho.

Cost i esforç indicatius

Sol·liciti un pressupost per a un disseny de model de suport amb abast definit o una revisió de l'estat de salut.

Preguntes freqüents

Hauríem de mantenir el nostre partner d'implantació en retainer després del go-live?
No necessàriament el mateix partner, i no necessàriament amb la mateixa intensitat, però alguna forma d'accés mantingut a expertesa més enllà del seu equip intern sol valer la pena com a mínim durant el primer any o els dos primers, quan és més probable que els dubtes de configuració i els impactes de les actualitzacions superin la capacitat interna.

Com aconseguim que el nostre expert del sistema documenti el seu coneixement sense que ho senti com una amenaça per al seu lloc?
Plantegi-ho explícitament com protegir i valorar el que sap, no com substituir-lo — la documentació converteix el seu coneixement en un actiu de l'organització en lloc d'una càrrega personal que suporta tot sol, i aquest plantejament, fet amb sinceritat i no com una frase per apaivagar resistències, importa més que qualsevol plantilla de documentació concreta.

Quin és el model de suport mínim viable per a una empresa mid-market petita?
Una estructura per nivells (encara que els nivells dos i tres apuntin tots dos al mateix petit equip intern), un document viu de la configuració actual i de les solucions provisionals conegudes, un propietari responsable designat diferent de l'expert tècnic més profund si la plantilla ho permet, i algun camí definit cap a expertesa externa per a tot allò que superi la capacitat interna. No calen eines elaborades; sí que cal l'assignació deliberada d'aquestes responsabilitats.

Amb quina freqüència s'hauria de revisar el model de suport mateix?
Anualment és raonable per a la majoria de les empreses mid-market, i a més sempre que hi hagi un canvi significatiu de persones, una actualització important del sistema o un mòdul o una integració nous — cada un d'aquests és un moment en què és més probable que els supòsits del model necessitin revisar-se.

Som a mitja implantació. És massa aviat per pensar-hi?
És el moment ideal. El disseny del model de suport és molt més barat i més eficaç quan s'incorpora al pla d'implantació com a lliurable que quan s'afegeix després, i aborda directament el patró de fallada de formació i transferència de coneixement del qual es parla en l'article sobre implantacions de NetSuite en un altre punt d'aquesta sèrie.

Tancament — Passos següents

La distància entre el go-live i un model de suport sostenible rarament és un problema tècnic. És una decisió no presa — ningú no va triar explícitament qui seria propietari del sistema, el documentaria i donaria continuïtat quan la persona que el coneix millor no estigui disponible — i les decisions no preses recauen per defecte en qui estigués més a prop, cosa que és un fonament fràgil per a alguna cosa de la qual el negoci ja depèn diàriament.

Si ja ha passat el go-live i no té clar en quin punt es troba: pregunti a la persona que coneix millor el sistema què passa si està inaccessible durant un mes. La seva resposta honesta és el diagnòstic més directe disponible, i normalment revela exactament per on ha de començar el model de suport.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora de NetSuite que dona servei a clients mid-market de tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per aconseguir fluxos 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 en 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 capaços de vigilar-se a si mateixos.

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

Fonts

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

• Oracle NetSuite, documentació d'administració i suport — https://docs.oracle.com/en/cloud/saas/netsuite/
• ITIL (Axelos), marc de gestió de serveis — principis de nivells de suport i de control de canvis — https://www.axelos.com
• Experiència de projectes d'Atypical Tech, models de suport d'ERP mid-market a la península Ibèrica