Problem dosto­so­wy­wa­nia (tak zwa­nej kasto­mi­za­cji) goto­we­go opro­gra­mo­wa­nia nie od dziś jest dys­ku­to­wa­ny. Jak wspo­mnia­łem w arty­ku­le o psu­ciu sys­te­mów ERP, fir­my wdra­ża­ją­ce naj­czę­ściej pre­fe­ru­ją dosto­so­wy­wa­nie (tak zwa­na [[kasto­mi­za­cja]]), pro­du­cen­ci tego opro­gra­mo­wa­nia dla odmia­ny, odra­dza­ją tę ścież­kę. Popatrzmy co na to Martin Fowler, zna­ny w bran­ży IT doświad­czo­ny pro­jek­tant i deve­lo­per, czło­wiek zna­ny z tego że napi­sał napraw­dę dużo biz­ne­so­we­go kodu:

A com­mon question in IT depart­ments is whe­ther to pro­vi­de a capa­bi­li­ty by buil­ding custom softwa­re or by buy­ing a pac­ka­ge. For lon­ger than I’ve been pro­gram­ming the deba­te has raged abo­ut how to make that cho­ice. My base posi­tion on this is foun­ded on the UtilityVsStrategicDichotomy. Boiled down this means that if the busi­ness pro­cess you are sup­por­ting is part of your com­pe­ti­ti­ve advan­ta­ge you sho­uld build custom softwa­re, if not you sho­uld buy a pac­ka­ge and adjust your busi­ness pro­cess to fit the way the pac­ka­ge works. (źr. PackageCustomization).

Fowler pyta o to, o co wie­lu wie­lu infor­ma­ty­ków: czy dostar­cze­nie fir­mie kolej­nych nowych moż­li­wo­ści, powin­no się reali­zo­wać poprzez napi­sa­nie (two­rząc dedy­ko­wa­ne) potrzeb­ne nowe opro­gra­mo­wa­nie, czy poprzez zakup goto­we­go opro­gra­mo­wa­nia. Ogólnie opi­nia, zale­ca­ne podej­ście przez Fowlera to: jeże­li pro­ces wyma­ga­ją­cy wspar­cia nowym opro­gra­mo­wa­niem, to pro­ces klu­czo­wy dla utrzy­ma­nia kon­ku­ren­cyj­no­ści lepiej stwo­rzyć opro­gra­mo­wa­nie dedy­ko­wa­ne do tego pro­ce­su. Jeżeli to jeden z pro­ce­sów pomoc­ni­czych, efek­tyw­niej będzie kupić goto­we opro­gra­mo­wa­nie i dosto­so­wa­nie do nie­go pro­ce­su w fir­mie. Co cie­ka­we, podob­nie jak ja, zale­ca w przy­pad­ku goto­we­go opro­gra­mo­wa­nia dosto­so­wa­nie się do nie­go a nie dosto­so­wy­wa­nie opro­gra­mo­wa­nia do siebie.

Z mojej stro­ny dodam, że to kolej­na opi­nia bar­dzo doświad­czo­nej oso­by, z któ­rej wyni­ka, że sys­tem ERP raczej nale­ży trak­to­wać jako fede­ra­cję zin­te­gro­wa­nych pro­gra­mów dzie­dzi­no­wych, a nie jako jeden zin­te­gro­wa­ny pakiet opro­gra­mo­wa­nia. Ten ostat­ni zawsze w jakimś obsza­rze będzie kula u nogi.