Va d’ERPs

Escrit per Aaloy a 15 de August , 2007 a les 7:55 p.m.

Des del blog de Ricardo Galli me n'assabent de dos articles [1] molt interessants damunt els ERP, a més obviament del seu(s) propis escrits.

Particularment el ERPs em fan molta grima, tant perquè la majoria són programes tancats que fermen als seus usuaris, per la manera que es comercialitzen i perquè representen una manera de fer programes allunyada del que es consideraria bones pràctiques de programació.

D'ERPs conec l'Oracle Financial, Navision i SAP, encara que aquest darrer molt de passada i tots ells tenen un problema fonamental: és l'empresa la que s'ha d'apatar a l'ERP. Si no es fa així els costs d'adaptacions són tan grans que ben bé l'empresa podria haver-se permès crear els seu programari a mida.

Però clar, la manera de comercialitzar un ERP és dir que el programa fa tot el que necessita l'empresa i més, que té tots el mòduls i que en tot cas sempre es podran fer adaptacions.

La realitat però, és que una vegada s'ha convençut a les altes esferes de la bondat de l'ERP i ja s'ha desembutxacat una quantitat més que considerable en llicències de l'ERP i la base de dades i comença la fase d'implantació i adaptació l'empresa ja està agafada. Si vol seguir fent feina de la manera que sap fer i que és el seu factor competitiu, haurà de fer mils d'adaptacions a l'ERP, adaptacions que es cobren a preu de canari jove i que poden doblar o triplicar el cost en llicències de l'ERP. La història de que la gent de l'empresa podrà fer adaptacions sense problemes no és més que això, una història. La realitat és que l'ERP és tan complexe que els propis consultors reconeixen que tenen gent especialitzada en un mòdul concret del producte.

I després venen les actualitzacions de versions. Actualitzar torna a ser com a una implantació. En vaig viure una indirectament i sols veies gent de la consultora anar i venir, fent hores i més hores. El cost: prohibitiu! I sols va ser un canvi de versió!

Els ERPs són el fast-food del programari de gestió. Prometen una solució ràpida, però després resulta que has de fer coa per a que t'atenguin i si en menges molt tens assegurada una indigestió. Els ERPs també prometen una solució immediata a les necessitats d'informatització d'una empresa, però es cuide'n molt de parlar-te dels temps d'implantació que s'aniran allargant, dels riscs de la implantació i del que et costaran les futures actualitzacions.

Si parlam d'enginyeria de programari hem de parlar del costs de desenvolupament dels projectes i de la quantitat d'errors i del cost del maquinar. Es ben conegut que un programa de 100.000 línies no té un cost 10 vegades major que un de 10.000 línies, sinó que el cost és sensiblement major, i quan es desenvolupa programari per un ERP estan agafant tant les complexitats del programa que desenvolupam més les complexitats del propi ERP.

Els ERPs tenen desenes de milions de línies de codi, i per tant les possibilitats que hi hagi errors en el codi augmenten en la mesura que augmenta el nombre de línies. Si tenim un programa de 10.000 línies i una taxa d'errors de 5 errors per KLOC podem estimar que tenim uns 50 errors pendents de detectar quan el programa passa a producció. Com que segons Putnam-Myers el nombre de defectes per línies de codi és lineal, podem esperar que l'ERP tengui una taxa d'errors en la mateixa proporció o major, ja que el distribuidor es cuidarà molt de dir-nos quin és el ratio d'errors del programa o el temps necessari per la seva actualització. I si el nostre negoci depèn de fer adaptacions a programari que tindrà errors, que haurem de corregir mantenir i que possiblement perdrem en la propera actualització costossísima de l'ERP, doncs la cosa fa por, molta por. Però encara hi ha més, tothom pareix estar d'acord amb que els ERPs són complexos, molt complexos, i amb això la linealitat del nombre de defectes per KLOC no es manté, sinó que creix de manera exponencial, i això malhauradament no afecta sols a les línies de codi de l'ERP sinó a les modificacions i adaptacions que se facin, que hereten aquesta complexitat. Què vol dir això? Doncs adaptacions més cares, més males de mantenir i depurar.

Així que la cosa està clara, davant la opció de desenvolupar un conjunt d'aplicacions a mida per la nostra empresa o tirar d'un ERP hi ha que valorar no sols el cost d'implantació de cada solució, sinó els costs dels anys que vindran i com afectarà la implantació de l'ERP als nostres processos de negoci, ja que en lloc d'adaptar el programari al negoci haurem de fer les coses com l'ERP millor li vagi per gestionar-les.

Respecte a l'arquitectura orientada a serveis (SOA) he de dir que sí que ho veig com a una manera de guanyar independència de distintes capes de programari i augmentar la reutilització de codi, en forma de programes. Si se fa bé, tendrem serveis petits, molt orientats a una tasca, controlables. Podrem controlar la complexitat de cada servei i mantenir la seva taxa d'errors molt baixa.

Això implica no caure en la trampa que volen els fabricants d'ERPs actualment: tot serà un servei i ho podràs fer servir sempre que facis servir el nostre BPEL o el component X que te proporcionen. La idea és seguir-te tenint fermat.

El serveis ens poden ajudar a anar independitzant capes de l'ERP i anar fent millores sense tenir que llevar tot l'ERP de cop. Per exemple, podem fer un mòdul de facturació en forma de servei que al final deixi les línees de facturació en la manera que les vol l'ERP de torn. Si feim una aplicació de facturació que faci servir el servei, estam aïllant-la de l'ERP i si demà decidim anar cap a un altra ERP lliure o cap a aplicacions sofisticades i separades el cost d'adaptació serà molt menor.

Les empreses no necessiten que tot sigui un servei, necessiten que tot el que es pugui reutilitzar pugui ser un servei, i que els programadors puguin fer servir aquests serveix per anar montant les aplicacions. La metàfora del Tente no és aplicable, no es tracta de sols ajuntar peces, es tracta per una part de montar una arquitectura de serveis i aprofitar-la per crear aplicacions que aprofitin els serveis com si fossin llibreries, però això està molt lluny de joc d'anar encaixant peces.

Particularment és una idea que cada cop m'agrada més, però entesa d'aquesta manera. Per exemple, amb Java i llibreries com XFire o Axis és prou senzill publicar serveis Soap, però els serveis interns no tenen per què ser precisament SOAP, podem tirar de protocols més lleugers com l'XML-RPC per exemple i fer-los servir per augmentar la velocitat de comunicació entre els serveis i la nostra aplicació.

Aplicació, per cert, que no té perquè estar escrita en Java, la capa de presentació en Java, ja sigui Swing o web és feixuga i amb una velocitat de desenvolupament i instal·lació poc àgil. Podem tirar de llenguatges d'script per fer la capa de presentació i tenir el millor dels dos mons: la facilitat de creació d'interfícies d'usuari dels llenguatges d'script i la facilitat de crear serveis que tenen els bastiments de Java.

Tot i això, no crec que a curt plaç els ERPs desapareguin, hi ha massa inversió feta. Seria el mateix que dir que els programes fets en COBOL desapareixeran d'aquí no res. Canviar un ERP és molt costós, i a més hem de tenir en compte que potser l'empresa encara està amortitzant la darrera actualització.

[1] http://evora.mit.edu/smr/issue/2007/fall/01/ http://www.roughtype.com/archives/2007/08/erps_troubled_l.php

Enllaços citats

• Ricardo Galli

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica

És el primer que he pensat quan he llegit el post d'en Ricardo. Lo que passa és que no dispòs de xifres per argumentar-ho.

Quant costa la implantació d'un ERP a una empresa mitjana?

I quin cost té el desenvolupament d'un ERP a mida (anem a suposar un 100% de benefici sobre el cost del desenvolupament)?

Estic quasi convinçut que en el moment de la posada en marxa el desenvolupament a mida és més econòmic i el servei post-venda molt més eficient (un desenvolupament a mida és bén conegut, un ERP "de marca" no).

Per una altra banda, l'extrapolació que fas sobre la taxa d'errors és molt imprecissa. Ja saps els perills que tenen les mètriques de tamany.

Crec que és impredecible el nombre d'errors basant-te en el NLC sense tenir en compte la complexitat funcional dels mateixos. Si fas un CRUD d'un element i disposes d'una mesura d'errors pel NLC el pots extrapolar a la resta de CRUDs.

Però una funcionalitat especial i concreta... és moooolt difícil.

Ei! Millor això que res, però jo no m'hi refiaria gaire. ;-)

Bones Paco,
Quan més gran és el projecte millor s'apliquen les mètriques de línies de codi, després de tot són estimacions estadístiques.
Les dades damunt la linealitat de la taxa d'errors i que aquests augmentin de manera exponencial estan agafats de "Software mesasurement and Estimation" de l'IEEE. Està clar que no pots dir ni quina és la pendent de la recta ni el factor de l'exponencial, però la tendència és vàlida.
Les mètriques de tamany en aquest cas són perfectament vàlides, ja que s'apliquen no per estimar la durada o la productivitat sinó per estimar taxes d'errors una vegada ja es té el programa, i per tant és ben bo de fer calcular el nombre de línies de codi.
De fet, si controles el projecte, pots estimar el nombre d'errors que tindràs, el i el nombre estimat d'errors que et queden per descobrir.
Els errors segueixen una cobra de Rayleigh, que es capaç de donar-nos el nombre d'errors prevists en un interval de temps.
Fins i tot podries estimar els errors que pots tenir introduint a posta errors en el codi i veure si els testejadors els cacen o no. Però clar, tot això ho pots fer si realment controles el projecte, i en el cas de fer modificacions i adaptacions a un ERP tens que no fas desenvolupament nou, sinó adaptació del que hi ha, i per tant el cost és sensiblement més gran, i a més el desenvolupament ho han de fer els experts consultors, amb la qual cosa perds bona part del control del projecte.
La idea fonamental però, és NO fer un ERP sinó fer aplicacions més petites, que es moguin dins el mínim de la corba de complexitat (bathtub chart), la qual cosa garanteix una taxa d'errors mínima i per tant menys costs de manteniment.