El Blog de Trespams

Blog personal sobre tecnologia, gestió de projectes i coses que se me passen pel cap

Va d’ERPs

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

blog comments powered by Disqus