Wstęp

Swego cza­su bra­łem udział w burz­li­wiej dys­ku­sji (zresz­tą nie­jed­nej) na temat sen­su prac ana­li­tycz­nych i pro­jek­to­wych przy oka­zji wdra­ża­nia sys­te­mów ERP, czy­li goto­we­go opro­gra­mo­wa­nia (prze­czy­taj arty­kuł). Większość dostaw­ców tego opro­gra­mo­wa­nia, z jaki­mi mie­wam kon­takt, uwa­ża, że ana­li­za owszem ale w celu opra­co­wa­nia kon­cep­cji wdro­że­nia, czy­li doku­men­tu mówią­ce­go jak dosto­so­wać sys­tem ERP do potrzeb klien­ta z naci­skiem na sło­wo kom­pro­mis. Pojawia się prę­dzej czy póź­niej świę­te sło­wo kasto­mi­za­cja, któ­re po pro­tu ozna­cza naj­czę­ściej prze­ra­bia­nie goto­we­go pro­duk­tu (nie raz bar­dzo dobre­go do momen­tu gdy się go nie popsu­je tymi prze­rób­ka­mi, prze­czy­taj i ten arty­kuł).

Kastomizacja a parametryzacja

Niedawno pisa­łem, że

goto­we opro­gra­mo­wa­nie nale­ży zosta­wić nie­tknię­te (nie licząc okie­nek kon­fi­gu­ra­cji) a bra­ku­ją­ce funk­cjo­nal­no­ści opra­co­wać, zapro­jek­to­wać i zin­te­gro­wać.

Z regu­ły jak tyl­ko wypo­wiem tę kwe­stię, lecą na mnie gro­my ze stro­ny kon­sul­tan­tów dostaw­ców ERP. Jednak war­to te meto­dę sto­so­wać co potwier­dza­ją nie tyl­ko moje doświadczenia:

Eksperci pod­kre­śla­ją bowiem, że więk­szość kosz­tów gene­ro­wa­nych przez pro­jekt wdro­że­nio­wy nie ma nic wspól­ne­go z kosz­tem same­go opro­gra­mo­wa­nia. ?Średnio trzy czwar­te budże­tu pochła­nia­ją kosz­ty wdro­że­nia, mody­fi­ka­cji stan­dar­do­wej funk­cjo­nal­no­ści oraz moder­ni­za­cji sprzę­tu? ? czy­ta­my w rapor­cie Panorama Consulting Group. […] O sys­te­mach kla­sy ERP coraz czę­ściej mówi się, że są zbyt roz­le­głe, ocię­ża­łe i ogra­ni­cza­ją moż­li­wo­ści biz­ne­su, od któ­re­go wyma­ga się zwin­no­ści i ela­stycz­no­ści. Czy cza­sy takich sys­te­mów już prze­mi­ja­ją?? (źr. IDG, 2010r)

Stale śle­dzę to co się dzie­je na ryn­ku sys­te­mów IT wspo­ma­ga­ją­cych zarzą­dza­nie obser­wu­ję taki wła­snie kie­ru­nek rozwoju:

Systemy zin­te­gro­wa­ne ERP będą pew­ny­mi zesta­wa­mi goto­wych funk­cjo­nal­no­ści, zbu­do­wa­ny­mi w opar­ciu o szkie­le­ty opro­gra­mo­wa­nia zaś inte­gra­cja będzie bazo­wa­nia nie na współ­dzie­le­niu danych a na wymia­nie ich pomię­dzy modu­ła­mi i zewnętrz­ny­mi sys­te­ma­mi na rów­nych pra­wach. Rozwój sys­te­mu w takim przy­pad­ku pole­ga na two­rze­niu nowych modu­łów tym śro­do­wi­sku a nie na mody­fi­ka­cji już istniejących.

Kierunek ten już widać od ok. dwóch lat na ryn­ku (ja o tym pisze od ponad pię­ciu), pra­ce te więc trwa­ją zapew­ne znacz­nie dłu­żej. Widać to na stro­nach nie­któ­rych dostaw­ców, lide­rów na rynku:

Dynamics AX 2009. Framework (szkie­let, przyp. mój) to zestaw wzor­ców pro­jek­to­wych, inter­fej­sów, goto­wych biblio­tek i innych narzę­dzi. Elementy te dają wspar­cie pro­gra­mi­stom. Najlepszą prak­ty­ką jest się­ga­nie do tych zaso­bów i wyko­rzy­sty­wa­nie ich zamiast two­rzyć wła­sne podob­ne. Tu opi­sa­no fra­me­work, pod­sys­te­my i funk­cjo­nal­no­ści Microsoft Dynamix AX (źr. Frameworks Introduction).

Obecnie stan­dar­dem jest sto­so­wa­nie w fra­mer­wor­kach, prze­zna­czo­nych do two­rze­nia opro­gra­mo­wa­nia biz­ne­so­we­go w śro­do­wi­sku prze­glą­da­rek WWW, (i nie tyl­ko) wzor­ca pro­jek­to­we­go MVC:

Wzorzec MVC poma­ga two­rzyć apli­ka­cje roz­dzie­la­jąc trzy róż­ne aspek­ty opro­gra­mo­wa­nia: inter­fejs użyt­kow­ni­ka, logi­kę biz­ne­so­wą oraz zacho­wa­nie sys­te­mu, poprzez zacho­wa­nie mini­mal­nych wza­jem­nych zależ­no­ści. Wzorzec opi­su­je gdzie każ­dy z ele­men­tów tej logi­ki umiesz­czać. Interfejs użyt­kow­ni­ka obsłu­gu­je widok (view). Sterowanie apli­ka­cją obsłu­gu­je kon­tro­ler (con­trol­ler). Logika biz­ne­so­wa zawar­ta jest w mode­lu (model). Ta sepa­ra­cja poma­ga zarzą­dzać zło­żo­no­ścią opro­gra­mo­wa­nia pod­czas jego two­rze­nia, ponie­waż poma­ga sku­pić się w danym momen­cie na jed­nym tyl­ko aspek­cie pro­ble­mu. (źr. MSDN MVC Overwiew)

Inny przy­kład podej­ścia do otwar­cia się:

Tu mamy coś w rodza­ju fasa­dy ([[wzo­rzec pro­jek­to­wy fasa­da]]) dla IFS Application (mate­ria­ły z publicz­nej stro­ny WWW), któ­re­go nowa wer­sja to już nie śro­do­wi­sko pro­ce­dur w Oracle DBMS a ser­wer apli­ka­cyj­ny Java J2EE (cie­ka­we ilu pro­gra­mi­stów Java mają na eta­tach dostaw­cy IFS’a). Zapewne powyż­sze to nie jedy­ne przy­kła­dy tego rodza­ju roz­wią­zań ERP na ryn­ku (fir­my chcą­ce uzu­peł­nić ten arty­kuł mogą mi prze­słać sto­sow­ne materiały).

Tak więc da się, trze­ba nie tyl­ko chcieć ale i potra­fić. Tu mała łyż­ka dzieg­ciu do gar­nusz­ka inte­gra­to­rów i dostaw­ców ERP: naj­czę­ściej nie potra­fią i mam wra­że­nie, że nie chcą bo, jak już w poprzed­nim arty­ku­le pisa­łem, nie jest to w ich inte­re­sie.

Model biz­ne­so­wy dostaw­ców goto­we­go opro­gra­mo­wa­nia to w więk­szo­ści przy­pad­ków brak kosz­tów two­rze­nia wła­sne­go pro­duk­tu i jego roz­wo­ju i budo­wa­nie mar­ży na cudzym pro­duk­cie. Oferowany jest cudzy pro­dukt wraz usłu­gą jego wdro­że­nia. Firma taka sta­no­wi kanał sprze­da­ży pro­du­cen­ta tego opro­gra­mo­wa­nia. Problem w tym, że od pew­ne­go cza­su rynek się zmie­nia: goto­we pro­duk­ty bez mody­fi­ka­cji nie mają tu (zarzą­dza­nie) racji bytu a mam wra­że­nie, że dostaw­cy ERP sta­ra­ją się za wszel­ka cenę uni­kać dosto­so­wań. Dlaczego? Bo ich model biz­ne­so­wy wła­snie w więk­szo­ści przy­pad­ków nie prze­wi­du­je utrzy­my­wa­nia bar­dzo kosz­tow­ne­go zespo­łu ana­li­ty­ków, pro­jek­tan­tów i programistów.

Czy mam rację? Przejrzałem co nie­co ogło­szeń o pra­ce dostaw­ców ERP, z tego co zebra­łem skom­pi­lo­wa­łem naj­czę­ściej powta­rza­ją­ce się oczekiwania:

Konsultant sys­te­mów ERP

Osoba będzie człon­kiem zespo­łu bio­rą­ce­go udział w pro­ce­sie wdra­ża­nia sys­te­mu ERP (ana­li­za, kon­fi­gu­ra­cja, szko­le­nia) oraz zapew­nia­ją­ce­go bie­żą­cą obsłu­gę i ser­wis ist­nie­ją­cych wdrożeń.

Opis sta­no­wi­ska pracy

• współ­pra­ca z klien­tem oraz doradz­two merytoryczne
• udział w ana­li­zach wdrożeniowych
• zaawan­so­wa­ne wspar­cie dla obec­nych klien­tów systemów
• udział we wdra­ża­niu systemów
• prze­pro­wa­dza­nie pre­zen­ta­cji pro­duk­tów u klienta
• pro­wa­dze­nie szko­le­nia dla klientów
• wspar­cie użyt­kow­ni­ków systemu
• pro­wa­dze­nie doku­men­ta­cji technicznej,
• zarzą­dza­nie zmia­na­mi w systemie,
• szko­le­nie koń­co­wych użytkowników,

Oczekujemy:

• 2 – 3 let­nie­go doświad­cze­nia we wdro­że­niach sys­te­mów kla­sy ERP
• zdol­no­ści ana­li­tycz­ne­go myślenia
• umie­jęt­no­ści roz­wią­zy­wa­nia problemów
• doświad­cze­nie we wdra­ża­niu systemów
• ogól­na orien­ta­cja w pro­ce­sach biz­ne­so­wych i chęć pogłę­bia­nia tej wiedzy,
• zna­jo­mość meto­dy­ki zarzą­dza­nia pro­jek­ta­mi wdrożeniowymi
• zna­jo­mo­ści SQL

To ostat­nie (SQL) poja­wia się od cza­su do cza­su, to kom­pe­ten­cja wyma­ga­na do two­rze­nia nowych rapor­tów w sys­te­mie. Gdzie tu jest inży­nie­ria opro­gra­mo­wa­nia? Czy w pań­stwa wdro­że­niach poza kon­sul­tan­ta­mi bra­li udział ana­li­ty­cy pro­jek­tan­ci i pro­gra­mi­ści czy tyl­ko kon­sul­tan­ci wpa­da­ją­cy po to by pozmie­niać coś w sys­te­mie (powo­du­jąc nie raz uszko­dze­nia w innych jego częściach)?

Tak więc co mogę pora­dzić? Bardzo dokład­ne przy­glą­da­nie się roz­dzia­łom ofer­ty pod tytu­łem Dostosowanie sys­te­mu, Koncepcja wdro­że­nia oraz ile ocze­ki­wa­nych przez Państwa funk­cjo­nal­no­ści to te, któ­rych sys­tem w swej wer­sji stan­dar­do­wej nie ofe­ru­je. Powinny one być po dokład­nej ana­li­zie, zapro­jek­to­wa­ne i zaimplementowane.

Jeżeli Konsultanci zaczy­na­ją nego­cjo­wać rezy­gna­cję z czę­ści ocze­ki­wań lub ofe­ru­ją coś podob­ne­go w sys­te­mie, to pierw­szy sygnał, że powi­nien ktoś im zacząć patrzeć na ręce, i nie mam tu na myśli ich przełożonego.

Na zakoń­cze­nie list jed­ne­go z moich klien­tów, nazwał bym to typo­wym problemem:

Planujemy wdro­że­nie nowe­go opro­gra­mo­wa­nia, chce­my tym razem unik­nąć pre­sji ze stro­ny dostaw­cy opro­gra­mo­wa­nia. Poprzednim razem dostaw­ca opro­gra­mo­wa­nia uprasz­czał sobie pra­cę, już na eta­pie ana­li­zy, któ­rą wyko­ny­wał sam. Analiza wyma­gań pole­ga­ła na wywia­dach i warsz­ta­tach gru­po­wych, skoń­czy­ła się zwy­kłym opi­sem, tabel­ka­mi i kil­ko­ma nie­czy­tel­ny­mi sche­ma­ta­mi. Podczas ana­li­zy i wdro­że­nia sta­le wma­wia­no nam, że ​„tego nie moż­na”, ​„to nale­ży upro­ścić” albo ​„tak się nie robi” my zaś nie potra­fi­li­śmy tego oce­nić. Wiele naszych potrzeb odkry­wa­li­śmy dopie­ro pod­czas insta­la­cji kolej­nych pro­to­ty­pów, zaś dostaw­ca uni­kał wpro­wa­dza­nia zmian i obie­ca­nych dosto­so­wań. Dostaliśmy w efek­cie nie­przy­dat­ne i nie­zgod­ne z biz­ne­so­wy­mi potrze­ba­mi opro­gra­mo­wa­nie. Czy może nam Pan tym razem pomóc?

P.S.

Nie jestem w żaden spo­sób zwią­za­ny z dostaw­ca­mi pro­duk­tów wymie­nio­ny­mi w arty­ku­le. Ich nazwy zosta­ły wska­za­ne wyłącz­nie z sza­cun­ku dla praw autor­skich cyto­wa­nych treści.