Quan un organisme públic necessita un sistema de gestió nou, es troba invariablement davant la mateixa disjuntiva: contractem un ERP estàndard del mercat i el configurem segons les nostres necessitats, o encarreguem un desenvolupament a mida? Totes dues opcions tenen defensors convençuts i casos d’èxit. També tenen fracassos que han sortit cars. La clau és saber quina és l’adequada per a cada situació.
Què és un ERP genèric i què és el programari a mida
ERP genèric (Enterprise Resource Planning): sistema estàndard de gestió dissenyat per funcionar en múltiples sectors i organismes mitjançant configuració i parametrització. Exemples: SAP, Oracle, Microsoft Dynamics, Odoo. En el sector públic espanyol, també solucions específiques però estàndard, com ara SIGEP, PLYCA per a contractació, o les plataformes de la Junta de Castella i Lleó o de l’AGE.
Programari a mida: sistema dissenyat i desenvolupat específicament per als processos d’un organisme o d’un sector concret. No existeix abans del projecte: es construeix segons els requisits del client.
Entre tots dos extrems hi ha una zona grisa important: els ERP configurables o els productes sectorials, que són estàndard en la base però admeten una personalització profunda. Moltes solucions per al sector públic entren en aquesta categoria.
Quan té sentit un ERP estàndard
Un ERP estàndard és l’opció adequada quan:
Els processos són estàndard i no requereixen diferenciació. Comptabilitat pública, nòmines de funcionaris, gestió d’expedients administratius bàsics: aquests processos estan normalitzats per llei i són iguals a tots els organismes del mateix nivell. Desenvolupar-los a mida no aporta cap avantatge.
L’organisme no té capacitat tècnica per mantenir programari propi. Un ajuntament petit, de 20 empleats, no té personal tècnic per gestionar les actualitzacions, els pedaços de seguretat i les adaptacions legals d’un sistema a mida. Un ERP amb suport del fabricant externalitza aquest cost de manteniment.
El pressupost és limitat i el temps d’implantació, curt. Un ERP existent pot estar en producció en qüestió de setmanes. Un desenvolupament a mida amb la mateixa funcionalitat pot trigar entre 3 i 12 mesos.
La funcionalitat que cobreix l’ERP és suficient en un 80-90%. Si el sistema estàndard cobreix la major part de les necessitats i només requereix petites adaptacions, l’eficiència de l’ERP supera la del desenvolupament des de zero.
Quan té sentit el programari a mida
El desenvolupament a mida és l’opció adequada quan:
Els processos són únics i cap ERP del mercat no els preveu. El sistema de control de traçabilitat d’una cadena provincial de distribució d’aigua, el mòdul de gestió de licitacions d’una diputació amb fluxos d’aprovació específics del seu organigrama, o la plataforma de gestió de mediacions laborals de SIMA: cap d’aquests sistemes no existeix com a ERP estàndard, ja que no hi ha prou mercat perquè cap fabricant el desenvolupi.
La integració amb els sistemes existents és crítica i complexa. Quan el nou sistema s’ha d’integrar amb diversos sistemes heretats (legacy) de tecnologies diferents, i aquesta integració defineix el valor del projecte, un ERP estàndard obliga a fer adaptacions costoses que sovint superen el cost del desenvolupament a mida.
L’organisme necessita controlar completament la propietat intel·lectual del codi. En projectes crítics finançats amb fons públics, tenir el codi font sota el control de l’organisme permet auditar-lo, modificar-lo amb altres proveïdors en el futur i garantir la continuïtat del servei amb independència del proveïdor original.
Els requisits de seguretat són elevats i l’ERP estàndard no els cobreix per defecte. Per a sistemes de categoria mitjana o alta de l’ENS, la seguretat ha d’estar dissenyada des de l’inici (security by design). Adaptar un ERP genèric perquè compleixi els requisits ENS de categoria alta sol ser més costós i menys robust que dissenyar la seguretat des de zero.
Si el teu cas encaixa en algun d’aquests escenaris, a la pàgina de programari a mida expliquem com abordem l’anàlisi prèvia de processos, la documentació i el lliurament del codi font a l’organisme.
El parany de l’ERP «gairebé perfecte»: el cost real de la parametrització
L’argument més freqüent a favor de l’ERP estàndard és l’econòmic: «ja està fet, només cal configurar-lo». Aquest argument falla sistemàticament quan la parametrització és extensa.
Un estudi de Gartner sobre implantacions d’ERP en el sector públic europeu va mostrar que el cost total de propietat d’un ERP amb una parametrització extensa al llarg de 5 anys és entre 1,8 i 2,4 vegades superior al cost del contracte inicial. Els costos ocults inclouen:
- Llicències anuals que s’incrementen amb el nombre de mòduls i d’usuaris
- Consultoria especialitzada del fabricant per a cada parametrització (a tarifes prèmium)
- Actualitzacions de versió que desfan les parametritzacions prèvies
- Dependència tècnica del fabricant, que dificulta el canvi de proveïdor
El programari a mida té els seus propis costos de manteniment, però són més previsibles i no inclouen llicències incrementals.
ENS: com influeix en la decisió ERP vs. programari a mida
La certificació ENS afegeix a aquesta decisió una dimensió important que sovint es passa per alt.
ERP estàndard i ENS: Els grans fabricants (SAP, Microsoft) tenen certificacions ENS per a les seves plataformes al núvol. Tanmateix, la certificació cobreix la plataforma base, no les personalitzacions. Quan un organisme hi afegeix mòduls personalitzats o integracions, aquestes peces addicionals queden fora de l’abast de la certificació i s’han de certificar per separat. Això pot convertir la certificació ENS d’un ERP parametritzat en un procés llarg i costós.
Programari a mida i ENS: Un proveïdor de programari a mida certificat en ENS dissenya el sistema des de l’inici amb els controls de seguretat requerits. La certificació ENS cobreix el producte complet, perquè no hi ha una base estàndard a la qual s’hagin afegit capes de personalització. L’abast de la certificació és més clar i mantenir-la és més senzill.
Per als organismes amb sistemes de categoria mitjana o alta que necessiten una certificació ENS neta i fàcil de mantenir, el programari a mida amb un proveïdor certificat sol ser l’opció més segura a llarg termini.
Llista de comprovació per decidir: 8 preguntes clau
Abans de decidir entre un ERP i programari a mida, respon amb honestedat:
- L’ERP estàndard cobreix sense adaptacions més del 80% dels processos que necessites?
- El teu organisme té capacitat tècnica per gestionar un sistema a mida (actualitzacions, incidències)?
- El termini d’implantació és un factor crític (menys de 6 mesos)?
- Els processos que necessites són estàndard del sector o únics del teu organisme?
- Necessites integració amb molts sistemes externs existents?
- Vols ser propietari del codi font del sistema?
- La categoria ENS del sistema és mitjana o alta?
- Preveus canvis normatius freqüents que afectaran el sistema?
Si les respostes 4, 5, 6, 7 o 8 són majoritàriament «sí», el programari a mida és probablement l’opció més eficient a llarg termini.
Un cop decidit el model, queda la segona pregunta: quin tipus de proveïdor l’executa. A Gran integradora o empresa mitjana? Com triar proveïdor les comparem per categories —mida del contracte, interlocució, llindars de solvència del plec i rotació de l’equip— i diem quan cadascuna és la resposta correcta.
Preguntes freqüents sobre programari a mida vs. ERP al sector públic
El programari a mida es pot licitar com a tal o requereix una figura contractual específica?
Es pot licitar com a contracte de serveis (desenvolupament) o com a contracte mixt (desenvolupament + manteniment). La LCSP permet contractes a mida sense restriccions; l’important és que el plec defineixi correctament l’objecte del contracte i els criteris d’acceptació. En projectes complexos és habitual recórrer al procediment negociat amb publicitat o al diàleg competitiu.
Quines garanties té l’organisme si el proveïdor de programari a mida desapareix?
El plec ha d’incloure el lliurament del codi font, la documentació tècnica completa i el dipòsit del codi en un servei de custòdia de tercers (com ara AENOR o un notari). Amb aquestes garanties, l’organisme pot contractar un altre proveïdor perquè mantingui el sistema. Aquesta clàusula és especialment important en el programari crític.
És més difícil justificar un projecte de programari a mida davant la Intervenció?
No necessàriament. La Intervenció valora que l’objecte del contracte sigui clar, que el preu estigui justificat pel mercat i que els lliurables siguin verificables. Un programari a mida ben documentat i amb criteris d’acceptació objectius és perfectament justificable. La dificultat apareix quan el plec és ambigu o els lliurables no estan definits.