Trudno odrzu­cić ​„głos ludu” w takich dys­ku­sjach. Na pyta­nie, zada­ne na pew­nym ogól­no­pol­skim forum dys­ku­syj­nym, o dedy­ko­wa­ne roz­wią­za­nia, pewien pra­cow­nik dużej pol­siej fir­my napi­sał (mam nadzie­ję, że pozo­sta­wio­ne slan­go­we ele­men­ty wypo­wie­dzi nie będą prze­szka­dza­ły), pyta­nia jakie zada­łem na liście pogrubione:

Wypowiem się jako przed­sta­wi­ciel klien­ta, któ­ry wdra­żał roz­wią­za­nia dedy­ko­wa­ne, obser­wo­wał i obser­wu­je wdra­ża­nie sys­te­mów pudeł­ko­wych z pół­ki na nie­złej wyso­ko­ści. Dodatkowo mam za sobą spe­cy­fi­ka­cję wyma­gań prze­tar­go­wych do sys­te­mu dość wyma­ga­ją­ce­go i oce­nę ofert, w któ­rych były i roz­wią­za­nia pudeł­ko­we i dedykowane.

1. Mamy kil­ka sys­te­mów dedy­ko­wa­nych od wie­lu lat. Niektóre są napi­sa­ne przez wewnętrz­ne komór­ki roz­wo­ju i są cią­gle dokła­da­ne kolej­ne funk­cjo­nal­no­ści. Zakres jest bar­dzo uni­kal­ny, użyt­kow­nik jest bar­dzo wyma­ga­ją­cy i takie podej­ście do sys­te­mu (to jest sys­tem typu inven­to­ry zawie­ra­ją­cy rów­nież war­stwę pla­no­wa­nia, czę­sto się poja­wia­ją nowe nazwij­my je «tech­no­lo­gie», któ­re muszą mieć użyt­kow­ni­cy natych­miast zamo­de­lo­wa­ne w sys­te­mie) mu bar­dzo odpo­wia­da. Koszt kil­ku pro­gra­mi­stów jest nie­du­ży w porów­na­niu z tym, co życzą sobie fir­my outsourcingowe.

2. W pew­nym momen­cie padło z góry hasło migruj­my wszyst­ko do jed­ne­go narzę­dzia typu jed­no ERP na wszyst­ko. Było nawet poda­ne super dro­gie i podob­no mają­ce nie­sa­mo­wi­te moż­li­wo­ści narzę­dzie, do któ­re­go mie­li­by­śmy zmi­gro­wać nasz «home-made». Koszty były ogrom­ne, a co śmiesz­ne – część rze­czy musie­li byśmy sami napi­sać. A sys­tem stwo­rzo­ny podob­no spe­cjal­nie pod kątem takich obsza­rów dzia­ła­nia, jak my mamy.

Generalnie nie ma szans. Ten sys­tem pod­pa­da pod kate­go­rię, któ­rą Jarek [to odpo­wiedź na mój post, przy­pis mój] zde­fi­nio­wał jako bar­dzo uni­kal­ne kom­pe­ten­cje i stra­te­gia dzia­ła­nia. Pudełka nie pasu­ją. Na szczę­ście uda­ło się tego unik­nąć. Business Case w żaden spo­sób się nie zamykał.

3. Narzędzie finan­so­we. W fir­mie było jed­no pudeł­ko­we narzę­dzie A na obsłu­gę całe­go pro­ce­su finan­so­we­go: od zamó­wie­nia zaku­pu poprzez odbiór i roz­li­cze­nie fak­tur i księ­gi finan­so­we. Ma to sens i jest logicz­nym pro­ce­sem prze­pły­wu finan­so­we­go. Jakiś kre­tyn wylob­bo­wał wpro­wa­dze­nie inne­go narzę­dzia dla eta­pu zamó­wie­nia zaku­pu. Bo jakoś wyszło, że ana­li­zy poka­za­ły, ze dla obsza­ru zamó­wień zaku­pu naj­lep­sze jest narzę­dzie X, dla czę­ści środ­ko­wej tego pro­ce­su, gdzie inna orga­ni­za­cja naj­wię­cej robi – naj­lep­sze jest narzę­dzie Y, a dla obsłu­gi fak­tur – naj­lep­sze narzę­dzie Z. Wszystkie 3 (X,Y,Z) i A są narzę­dzia­mi goto­wy­mi. Obserwowałam obie opcje – samo narzę­dzie A i dzia­ła­nie 3 narzę­dzi X,Y,Z. I nie­ste­ty kom­bajn 3 narzę­dzi był gehen­ną dla użyt­kow­ni­ków i kupę kasy i błę­dów kosz­to­wa­ły inte­gra­cje, mimo że skła­dał się z niby lep­szych ele­men­tów. Narzędzie jed­no na cały pro­ces finan­so­wy (ale tyl­ko finan­so­wy, a nie wszyst­ko, co jest w fir­mie) nawet ciut gor­sze – spraw­dza­ło się lepiej. Łatwiej rapor­to­wać, mniej błę­dów przy inte­gra­cjach. Strumień danych prze­pły­wa­ją­cy przez te inte­gra­cje jest na tyle duży, że to jest bez sen­su. Dużo lepiej spraw­dza­ło się 1 dedy­ko­wa­ne roz­wią­za­nie A do obsza­ru finansowego.

4. Prowadziłam prze­targ na sys­tem. Wymagania były bar­dzo dokład­nie wyspe­cy­fi­ko­wa­ne. Oferty były z roz­wią­zań pudeł­ko­wych jak i dedy­ko­wa­nych. W komi­sji prze­tar­go­wej byli przed­sta­wi­cie­le komór­ki stric­te IT, więc mogłam z bli­ska i na zna­nym obsza­rze zaob­ser­wo­wać ich spo­sób dzia­ła­nia i podej­ście do wybo­ru. Rozwiązania pudeł­ko­we: część ofert nie speł­nia­ła wyma­gań (wie­lu! klu­czo­wych). Część speł­nia­ła. Była nawet ofer­ta pudeł­ko­wa, któ­ra mia­ła naj­lep­sze oce­ny tech­nicz­ne, pra­wie ide­ał, według ofer­ty muszą doro­bić tyl­ko 3 funk­cjo­nal­no­ści na ok 25. Oferty dedy­ko­wa­ne – mają­ce lub nie część już goto­wych kom­po­nen­tów. Były fir­my z dedy­ko­wa­ny­mi roz­wią­za­nia­mi, któ­re szcze­gó­ło­wo opi­sa­li, że np wyma­ga­nie x moż­li­we do speł­nie­nia w tro­chę inny spo­sób, niż napi­sa­ne ze wzglę­du na uży­tą tech­no­lo­gię (lub cokol­wiek innego).

No i wybór na sort liście: dedy­ko­wa­ne i pudeł­ko­we, oce­ny tech­nicz­ne róż­nią się w 3 – 4%. Wycena imple­men­ta­cji (w tym jed­no­ra­zo­wy zakup licen­cji): pudeł­ko­we o ok 60% droż­sze w zaku­pie jed­no­ra­zo­wym. To jesz­cze pół bie­dy, moż­na tłu­ma­czyć, że pudeł­ko­we- potem doda­wa­nie nowych funk­cjo­nal­no­ści pra­wie nic nie kosz­tu­je (cho­ciaż dla mnie to nie jest takie pew­ne). Ale, kosz­ty utrzy­ma­nia w pudeł­ko­wym są kil­ka­krot­nie droż­sze niż dedy­ko­wa­ne­go i ta kwo­ta róż­ni­cy sta­no­wi 70% kosz­tów imple­men­ta­cji sys­te­mu dedy­ko­wa­ne­go. Wychodzi na to, że nawet jak się wal­nę­li­śmy o pra­wie 100% w spe­cy­fi­ka­cji wyma­gań, to przy dedy­ko­wa­nym roz­wią­za­niu oszczę­dza­my tyle przez 1,5 roku, że może­my od nowa sys­tem napisać.

Pudełkowe są cho­ler­nie! dro­gie. Nie mówię już o ofer­tach pudeł­ko­wych, któ­re kosz­to­wa­ły czte­ro­krot­nie wię­cej niż roz­wią­za­nie dedykowane.

-Argument, że w pudeł­ko­wych wie­le firm skła­da się na roz­wój sys­te­mu do mnie nie prze­ma­wia, bo patrząc na ceny mam wra­że­nie, że w pudeł­ko­wych każ­dy klient pła­ci tyle ile kosz­to­wa­ło ich wypro­du­ko­wa­nie tego. Po pro­stu przy dru­gim klien­cie mają już czy­sty zysk.

Obserwowałam pre­fe­ren­cję i spo­sób wybo­ru narzę­dzia przed­sta­wi­cie­li stric­te-IT [ja mam infor­ma­tycz­ne wykształ­ce­nie i doświad­cze­nie, ale nie jestem w komór­ce IT, stąd takie okre­śle­nie]. Teoretycznie, tyl­ko oni mają kom­pe­ten­cje i mogą wybie­rać roz­wią­za­nia infor­ma­tycz­ne]. Podejście na dzień dobry :

[JZ] Pudełkowe jest lep­sze, bo roz­wią­za­nia ​„będą­ce stan­dar­dem na ryn­ku” są lep­sze, sta­bil­niej­sze; więc wnio­sek – roz­wią­za­nia pudeł­ko­we są stan­dar­dem rozwiązań.

Rozwój dedy­ko­wa­nych kosz­tu­je wię­cej niż pudeł­ko­wych (co jak widać powy­żej i w kil­ku innych przy­pad­kach jest nieprawdą:).

– za każ­dym razem się łudzą, że tak będzie tym razem, a tak nie jest 😉

- popeł­ni­li błąd naj­gor­szy – nie pró­bo­wa­li zro­zu­mieć wyma­gań biz­ne­su. Oceny były według sym­pa­tii do firm. Mi (bo ja defi­nio­wa­łam wyma­ga­nia po roz­mo­wach z użyt­kow­ni­ka­mi) powy­cho­dzi­ło, że ofer­ta x nie speł­nia zupeł­nie tego wyma­ga­nia, a od nich oce­na była 5, a innych 2 – 3 mimo, ze speł­nia­li wymagania.

Więc takie decy­zje o wybo­rze z góry, roz­wią­za­nia pudeł­ko­we­go mogą być powo­do­wa­ne bra­kiem kom­pe­ten­cji w ogó­le w tym, co robią ci co wybierają.

- mit pod­trzy­my­wa­ny cały czas, że utrzy­ma­nie i roz­wój będą dla pude­łek tań­sze. – A jak obej­mie jesz­cze inny obszar fir­my i ich pro­ce­sy (bo fak­tycz­nie takie narzę­dzie może to zro­bić), to efekt ska­li spo­wo­du­je, ze kosz­ty utrzy­ma­nia będą tań­sze u pudeł­ko­wych. Guzik, pudeł­ko­we mają bar­dzo czę­sto licen­cje per licz­ba użyt­kow­ni­ków + jesz­cze rocz­ny sup­port tych licen­cji. Więc przy doda­niu kolej­ne­go obsza­ru, nawet jak nie ma potrze­by nowych funk­cjo­nal­no­ści, to docho­dzą nowi użyt­kow­ni­cy => koszt jed­no­ra­zo­wy zaku­pu licen­cji + wzrost rocz­nie kosz­tów utrzy­ma­nia (a miał być podob­no spa­dek, bo kosz­ty niby się rozkładają).

[JZ] O wadach i zale­tach ​„kasto­mi­za­cji” czy­li wpro­wa­dza­niu mody­fi­ka­cji do goto­we­go i prze­te­sto­wa­ne­go opro­gra­mo­wa­nia, ​„odcho­dze­niu” od dys­try­bu­cyj­nej ich wer­sji (utra­ta korzy­ści skali)

Mieliśmy taki, upgra­de do nowej wer­sji pudeł­ka jest w zasa­dzie nie­moż­li­wy. Trzeba pisać wszyst­ko od nowa – po pro­stu nowy pro­jekt zro­bie­nia systemu+jeszcze ogrom­ne kosz­ty migra­cji danych. I tak stoi np sys­tem pudeł­ko­wy już X lat, cały czas cho­dząc na Oracle 6.

[JZ] O wadach i zale­tach nie­nor­ma­li­zo­wa­nych baz danych i inte­gra­cji sys­te­mów (sys­te­my goto­we i dedykowane)

Wypowiem się tyl­ko o nor­ma­li­za­cji i denor­ma­li­za­cji. Mamy ten sys­tem z pkt 1 jako inventory+narzędzie do pla­no­wa­nia. I mamy oddziel­nie hur­tow­nię, któ­ra prze­cho­wu­je dane sta­ty­stycz­ne z obiek­tów zawar­tych w tym sys­te­mie. Nie ma szans, żeby to dzia­ła­ło jako jeden sys­tem. Nie mia­ły by szans takie ana­li­zy, któ­re są prze­pro­wa­dza­ne na hur­tow­ni. A inte­gra­cja tych sys­te­mów jest nieduża.

Zresztą tu nie widzę o czym dys­ku­to­wać, sys­te­my trans­ak­cyj­ne słu­żą do zupeł­nie innych rze­czy niż sys­te­my hurtowniane.

[JZ] O nie­za­wod­no­ści i ryzy­ku sys­te­mów pra­cu­ją­cych na danych roz­pro­szo­nych i danych sku­pio­nych w jed­nym miejscu.

Jeśli tu cho­dzi o sys­tem np. jeden ERP na wszyst­ko , jed­na mega­ba­za ze wszyst­kim. To nie widzę sen­su cho­ciaż­by dla­te­go, że pew­ne obsza­ry mają nie za dużo punk­tów sty­ku i gene­ral­nie funk­cjo­nu­ją w dość róż­nych płasz­czy­znach. Takim skraj­nym przy­pad­kiem jest np sys­tem bilin­go­wy, sys­tem finan­so­wy (opi­sa­ny wyżej) i bazy dla tech­ni­ki. Wszystko doty­czy np sta­cji bazo­wych, ale pod zupeł­nie róż­ny­mi kąta­mi: w sys­te­mie finan­so­wym – tyl­ko nr code sta­cji i jej adres i wszyst­kie aspek­ty finan­so­wo zaku­po­we; w sys­te­mie tech­ni­ki nr sta­cji, jej adres i abso­lut­nie wszyst­kie para­me­try tech­nicz­ne, sprzęt i soft zain­sta­lo­wa­ny tam plus pla­no­wa­ny. W bilin­gu w ogó­le sta­cji jest potrzeb­ny tyl­ko nr code, zeby wie­dzieć, któ­ra sta­cja obsłu­gi­wa­ła rozmowę.

Mieszanie wszyst­kie­go do jed­ne­go kotła cho­ciaż­by przez to jest bez sensu.

Dodatkowo, sys­te­my mogą ope­ro­wać na podob­nych danych, ale wyma­ga­ją róż­nych pozio­mów utrzy­ma­nia. System zaku­po­wy może dzia­łać 8 – 17/5 dni, a sys­tem obsłu­gi klien­ta musi dzia­łać 24/7 czy nad­zo­ru sie­ci. I awa­ria takie­go sys­te­mu 8 – 17/5 nie jest aż tak dra­ma­tycz­na, jak tego dru­gie­go, ale we wspól­nym sys­te­mie może pocią­gnąć za sobą de fac­to awa­rię dla obsza­ru 24/7.

Uff.

Dodam też, ze widzia­łam dużo sys­te­mów dro­gich i zupeł­nie do kitu jak pudeł­ko­wych tak i dedy­ko­wa­nych. Ale tam głów­nie winę bym z baaar­dzo dużym praw­do­po­do­bień­stwem poło­ży­ła po stro­nie tzw ana­li­ty­ków, co albo uwa­ża­ją, że wie­dzą lepiej niż uzyt­kow­nik, albo są naj­zwy­czaj­niej w świe­cie głu­pi i niekompetentni.

Z innej stro­ny nie zupeł­nie mnie to dzi­wi, bo nadal są fir­my, któ­re uwa­ża­ją, że infor­ma­ty­ko­wi ty 2000 – 2500 PLN brut­to to jest wystar­cza­ją­ca pen­sja. Sorry, ale w takim przy­pad­ku tak niska jakość ich pra­cy mnie nie dziwi.

A i jesz­cze nt kom­bajn czy komponenty.

Jak mamy kom­bajn (vide przy­kład z narzę­dziem finan­so­wym) fir­ma się poczu­ła bar­dzo pew­nie i nawet włą­cza­nie kolej­nych funk­cjo­nal­no­ści w pew­nym momen­cie zaczę­li wyce­niać na ogrom­ne kwoty.

Monopol nigdy nie jest dobry, w żad­nym przypadku.

I wła­śnie, przy zaku­pie pudeł­ka, ofer­ty któ­re widzia­łam albo sys­te­my już dzia­ła­ją­ce pudeł­ko­we – zapła­co­no wię­cej niż by kosz­to­wał dedy­ko­wa­ny. Z myślą, że kupu­je­my wię­cej niż teraz potrze­bu­je­my, żeby potem tyl­ko pew­nym para­me­trem zmie­nić funk­cjo­nal­ność. A w prak­ty­ce się oka­zy­wa­ło, że trze­ba doku­pić jesz­cze moduł B (licen­cje do nie­go), a za włą­cze­nie funk­cjo­nal­no­ści C zapła­cić i nie­ma­ło. W zasa­dzie nie wiesz, co dokład­nie kupi­łeś jako nad­mia­ro­we: jak ktoś traf­nie porów­nał – kupu­jesz wia­der­ko lego, żeby zro­bić samo­chód. Tylko w tym przy­pad­ku nie wiesz, co pozo­sta­ło w tym wia­der­ku i nie wiesz, czy możesz czy nie zro­bić z resz­ty bagaż­nik dachowy.

Może to wina źle skon­stru­owa­nej umo­wy, ale chy­ba i tak w fir­mie kupu­ją­cej ktoś musi dobrze poznać całe narzę­dzie (nawet nie­uży­wa­ne kom­po­nen­ty), aby nie pozwo­lić tak się wykorzystać.

Wypowiedź na blogu IDG

Reasumując ? nie wie­rzę w uda­ne wdro­że­nie bez mody­fi­ka­cji sys­te­mu. Jeżeli sys­tem ma uspraw­nić funk­cjo­no­wa­nie fir­my, jego wdro­że­nie nie może abs­tra­ho­wać od jej struk­tu­ry, uni­kal­nych pro­ce­sów i kul­tu­ry kor­po­ra­cyj­nej. Niektóre rze­czy moż­na zała­twić wyko­rzy­stu­jąc mecha­ni­zmy kon­fi­gu­ra­cyj­ne. Niestety nigdy nie są one wystar­cza­ją­ce i nie moż­na bać się doró­bek. Sądzę, że kla­pa nie­jed­ne­go wdro­że­nia to sku­tek kur­czo­we­go trzy­ma­nia się dogma­tu o nie­na­ru­szal­no­ści sys­te­mu ERP. Narobił on już wystar­cza­ją­co dużo szko­dy ? zapo­mnij­my w koń­cu o nim.

Źr. http://​pro​jek​ty​.erp​stan​dard​.pl/​2​0​1​0​/​0​9​/​1​4​/​e​r​p​-​o​w​y​m​-​p​u​r​y​s​t​o​m​-​m​o​w​i​m​y​-​s​t​a​n​o​w​c​z​e​-​n​ie/