Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użyt­kow­ni­ka. Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet wykład­nią”.

Czytaj dalej… Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i reko­men­da­cje”

Wdrożenia systemów ERP

Od cza­su do cza­su poja­wia­ją się w sie­ci woła­nia będą­ce czymś co ja nazy­wam anty refe­ren­cja­mi. W więk­szo­ści zna­nych mi przy­pad­ków jest to wina dostaw­cy, który:

  1. zobo­wią­zał się do reali­za­cji wyma­gań nie testu­jąc ich wykonalności,
  2. zobo­wią­zał się do wdro­że­nia ofe­ro­wa­ne­go roz­wią­za­nia bez wyko­na­nia (posia­da­nia) rze­tel­ne­go audy­tu biz­ne­so­we­go (kom­pu­te­ry­za­cja bała­ga­nu) u klienta.

Tłumaczenia w rodza­ju bo klient nie wie cze­go chce” są jedy­nie wyra­zem nie­kom­pe­ten­cji dostaw­cy w obsza­rze ana­li­zy przed-wdro­że­nio­wej.

Oto przy­kład takie­go woła­nia” z Lipca 2016 i pró­ba wyja­śnie­nia tych zgło­szo­nych pro­ble­mów (z oczy­wi­stych powo­dów zanonimizowane).

Od sierp­nia 2014 r. moja fir­ma – jako Zamawiający jest bene­fi­cjen­tem dofi­nan­so­wa­nia UE PARP 8.2 PO IG – dzia­ła­nie 8.2 i co za tym idzie kom­plek­so­we­go wdro­że­nia opro­gra­mo­wa­nia XXX kla­sy ERP dostar­czo­ne­go przez XXX. Za wdro­że­nie opro­gra­mo­wa­nia odpo­wie­dzial­na jest fir­ma XXX, któ­rej zespół do dnia dzi­siej­sze­go zma­ga się z wdro­że­niem oraz jego skut­ka­mi tech­nicz­ny­mi i eko­no­micz­ny­mi.
Poniżej załą­czam głów­ne tech­nicz­ne pro­ble­my, z któ­ry­mi spo­tka­li­śmy się pod­czas wdro­że­nia XXX:…

Architektura monolitycznych systemów ERP

Zanim jed­nak przy­stą­pi­my do wyja­śnień, kil­ka słów o archi­tek­tu­rze mono­li­tycz­nych sys­te­mów ERPII (taki jest tu wdra­ża­ny). Używam tu nazwy mono­lit, gdyż mimo dekla­ro­wa­ne­go podzia­łu na modu­ły, tych sys­te­mów, są one mono­li­tem zbu­do­wa­nym na jed­nej współ­dzie­lo­nej bazie danych. To co nazy­wa­ne jest tu modu­łem, to wydzie­lo­ne lecz nie roz­łącz­ne, ele­men­ty logi­ki biz­ne­so­wej. Poniżej uprosz­czo­na archi­tek­tu­ra sys­te­mu ERP dla fir­my pro­duk­cyj­nej (uprosz­cze­nie doty­czy wyłącz­nie gra­da­cji i ilo­ści modu­łów sys­te­mu ERPII).

Model modułowego ERPII

Na dia­gra­mie po lewej poka­za­ne są pod­sys­te­my dzie­dzi­no­we, któ­re prak­tycz­nie nie wystę­pu­ją w ofe­ro­wa­nych na ryn­ku ERP. Prawa stro­na to typo­wa archi­tek­tu­ra mono­li­tycz­ne­go sys­tem ERPII. Jej klu­czo­we cechy to:

  1. jed­na mono­li­tycz­na baza danych zawie­ra­ją­ca znor­ma­li­zo­wa­ną logi­kę związ­ków mię­dzy dany­mi i i ch współdzielenie,
  2. modu­ły dzie­dzi­no­we zawie­ra­ją­ce wyłącz­nie logi­kę prze­twa­rza­nia tych danych,
  3. jed­no­li­ty inter­fejs użytkownika.

Ważna, rzecz: Rachunkowość finan­so­wa to szkie­let bazy danych (dowo­dy księ­go­we i pozo­sta­łe zda­rze­nia gospo­dar­cze). Taka archi­tek­tu­ra powo­du­je, że:

  1. modu­ły obsłu­gu­ją­ce zda­rze­nia gospo­dar­czej (co naj­mniej rachun­ko­wość, maga­zy­ny) są obli­ga­to­ryj­ne, czy­li zawsze muszą być wdro­żo­ne i zawsze jako pierwsze),
  2. pew­ne ele­men­ty logi­ki są nie­mo­dy­fi­ko­wal­ne (logi­ka związ­ków pomię­dzy dany­mi jest w cen­tral­nej bazie danych, ta zaś jest prak­tycz­nie niemodyfikowalna),
  3. mody­fi­ko­wa­nie logi­ki zwią­za­nej z prze­twa­rza­niem danych wyma­ga inge­ro­wa­nia w skom­pli­ko­wa­ny kod ist­nie­ją­cych modu­łu, skut­ki tych zmian mogą się prze­no­sić na pozo­sta­łe modu­ły (poprzez współ­dzie­lo­ne dane),
  4. współ­dzie­le­nie danych (np. pomię­dzy zamó­wie­niem a fak­tu­rą) powo­du­je, że zmia­ny w zasad­ni­czej tre­ści doku­men­tów i ich logi­ka są prak­tycz­nie niemożliwe,
  5. moż­li­we two­rze­nie (mody­fi­ko­wa­nie) nowej logi­ki biz­ne­so­wej jest ogra­ni­czo­ne do tego, co nie koli­du­je z mode­lem danych w cen­tral­nej bazie danych.

To tyl­ko klu­czo­we ogra­ni­cze­nia. Większe wdro­że­nia nie unik­ną inte­gra­cji z uwa­gi na to, że takie funk­cjo­nal­no­ści jak PLM (zarza­dza­nie cyklem życia pro­duk­tów), MES (moni­to­ro­wa­nie pro­duk­cji) czy APS (Advaced Planing System) nie są dostęp­ne w ramach ERPII, więc bar­dzo czę­sto nie jest praw­dą, że sam sys­tem ERPII wystarczy.

Skutki kastomizacji

Popatrzmy teraz na zgła­sza­ne problemy:

- wada nie­sta­bil­nych cen zaku­pu towa­rów, błąd ceny zej­ścia towa­ru na WZ, błęd­ne ceny na prze­su­nię­ciach i przy­ję­ciach na maga­zyn, błąd – ceny wyda­nia i przy­ję­cia na maga­zy­nach MM minus / MM plus. Przykładowo ten sam towar po prze­su­nię­ciu na inny maga­zyn z nie­wia­do­mych przy­czyn zmie­nia swo­ją cenę zaku­pu. Wada zwią­za­na z błęd­ny­mi cena­mi nie pozwa­la na pra­wi­dło­we usta­le­nie war­to­ści poszcze­gól­nych maga­zy­nów fir­my
- wada sald kon­tra­hen­tów zwią­za­na z poda­wa­niem błęd­nej wyso­ko­ści zadłu­że­nia klien­ta,
- wada nie­sta­bil­ne­go obsza­ru rapor­tów ? rapor­ty two­rzo­ne według tych samych para­me­trów przed­sta­wia­ją róż­ne dane, przy­kła­do­wo 3 rapor­ty doty­czą­ce sta­nu tego same­go maga­zy­nu przed­sta­wia­ją 3 róż­ne kwoty,

Są to naj­praw­do­po­dob­niej efek­ty tego, że inge­ren­cja w logi­kę poszcze­gól­nych modu­łów spo­wo­do­wa­ła błę­dy. Związki mię­dzy doku­men­ta­mi maga­zy­no­wy­mi i ich ewen­tu­al­ne współ­dzie­le­nie z inny­mi (np. PZ, MM, WZ) są wbu­do­wa­ne w bazę danych, wyli­cze­nia zaś tkwią w modu­łach dziedzinowych. 

Zmiany wpro­wa­dza­ne lokal­nie w poszcze­gól­nych modu­łach mogą burzyć logi­kę modu­łów współ­dzie­lą­cych te dane. Kolizja wyli­czeń i logi­ki danych w bazie danych z regu­ły wpły­wa destruk­cyj­nie na rapor­ty z tych danych.

Powyższe bra­ki i wady nie wyczer­pu­ją dłu­giej listy pro­ble­mów (ok. 200) spo­wo­do­wa­nych moim zda­niem niskim przy­go­to­wa­niem mery­to­rycz­nym spe­cja­li­stów z cen­tra­li XXX oraz z fir­my wdro­że­nio­wej XXX.

Naszym głów­nym pro­ble­mem w pra­cy na opro­gra­mo­wa­niu XXX, wie­lo­krot­nie prze­ja­wia­ją­cym się w cią­gu kil­ku ostat­nich mie­się­cy, jest brak sta­bil­no­ści opro­gra­mo­wa­nia, w szcze­gól­no­ści w pod­sta­wo­wych modu­łach jaki­mi są Sprzedaż i Zarządzanie Zapasami. Jedna z naj­waż­niej­szych wad opro­gra­mo­wa­nia mani­fe­stu­je się zja­wi­skiem nie­kon­tro­lo­wa­nej zmia­ny cen towa­rów w róż­nych loka­li­za­cjach maga­zy­no­wych, obja­wia­ją­cym się zwięk­sza­niem lub zmniej­sza­niem cen bez żad­ne­go logicz­ne­go powodu.

Powyższe potwier­dza skut­ki inge­ren­cji opi­sa­ne powyżej.

Prace mają­ce na celu usu­nię­cie tej wady nie przy­nio­sły dotąd spo­dzie­wa­nych efek­tów, pomi­mo zaan­ga­żo­wa­nia w nie rów­nież pro­du­cen­ta opro­gra­mo­wa­nia. Doraźne napra­wy nie pozwa­la­ły na korek­tę naro­słych wcze­śniej błę­dów w księ­go­wo­ści fir­my. Straty fir­my pole­ga­ją m. in. na błę­dach w sto­so­wa­nej mar­ży – utra­cie klien­tów lub zysku, koniecz­no­ści pro­wa­dze­nia cią­głych i absor­bu­ją­cych inwen­ta­ry­za­cji, błę­dach wysy­łek, dodat­ko­wych kosz­tach pra­cy, co wprost prze­kła­da się na spa­dek obro­tów oraz wzrost kosz­tów działalności.

Obawiam się, że powyż­sze pro­ble­my są nie do roz­wią­za­nia. Nieprzemyślana (a nie raz po pro­stu nie­moż­li­wa do wyko­na­nia) tak zwa­na kasto­mi­za­cja, to nic inne­go pró­ba bez­kar­ne­go wpro­wa­dza­nia lokal­nych zmian do kodu liczą­ce­go nie raz milio­ny linii.

Moim zda­niem opro­gra­mo­wa­nie XXX nie zosta­ło pra­wi­dło­wo przy­go­to­wa­ne do wpro­wa­dze­nia na rynek pol­ski. Po zain­sta­lo­wa­niu oka­za­ło się, że opro­gra­mo­wa­nie nie posia­da sze­re­gu funk­cjo­nal­no­ści przy­ję­tych jako stan­dar­do­we, nawet w pro­gra­mach niż­szej kla­sy. Przykładowo XXX w modu­le F‑K nie posia­da sze­re­gu zesta­wień wyma­ga­nych do pro­wa­dze­nia księ­go­wo­ści, a wypad­ku H‑M np. pra­wi­dło­we­go zesta­wie­nia sta­nów maga­zy­no­wych towa­rów wraz z ich cena­mi na poszcze­gól­nych maga­zy­nach, z któ­rych w spo­sób łatwy może sko­rzy­stać handlowiec.

Tu uwa­ga dot. zama­wia­ją­ce­go: nie­ste­ty nie ma cze­goś takie­go jak funk­cjo­nal­no­ści przy­ję­te jako stan­dar­do­we”, co naj­wy­żej stan­dar­dem może być zgod­ność (nie­ko­li­do­wa­nie) z odpo­wied­ni­mi prze­pi­sa­mi (np. o rachun­ko­wo­ści). Bardzo czę­sto to Zamawiający jest sam sobie robi krzyw­dę, uwa­ża­jąc że coś jest oczy­wi­ste, nie­ste­ty nie ma rze­czy oczywistych. 

Jeżeli Zamawiający uwa­ża, że ana­li­za biz­ne­so­wa przed wybo­rem i wdro­że­niem sys­te­mu ERPII jest zbęd­na lub, że wyko­na ją popraw­nie dostaw­ca po zawar­ciu umo­wy, to nie­ste­ty szu­ka kłopotów. 

Poważnym pro­ble­mem utrud­nia­ją­cym roz­wią­za­nie trud­nej sytu­acji Zamawiającego są pró­by unik­nię­cia odpo­wie­dzial­no­ści za pro­dukt ze stro­ny pro­du­cen­ta XXX, któ­ry powo­łu­jąc się na zapi­sy umo­wy licen­cyj­nej sta­now­czo odrzu­ca odpo­wie­dzial­ność za wady pro­duk­tu. Zamiast rze­czy­wi­stych napraw ww. wad, moja fir­ma otrzy­mu­je jedy­nie dekla­ra­cje, mówią­ce o ?pod­cho­dze­niu ze zro­zu­mie­niem do pro­ble­mów? i ?goto­wo­ści do pomocy?.

Niestety po pod­pi­sa­niu umo­wy i pro­du­cent i dostaw­ca opro­gra­mo­wa­nia mają pra­wo się na te umo­wę powo­ły­wać. Odpowiedzialność pro­du­cen­ta jest wyłą­czo­na już po pierw­szej inge­ren­cji w kod, uda­ne kasto­mi­za­cje są z regu­ły nie­moż­li­we z powo­dów wyżej opi­sa­nych. Kupujący nie­ste­ty tak­że pono­si odpo­wie­dzial­ność za swo­je dzia­ła­nia. Co praw­da może i nale­ży ocze­ki­wać od dostaw­cy tak zwa­ne­go peł­ne­go pro­fe­sjo­na­li­zmu, jed­nak życie uczy, że to tak­że nale­ży sobie zapew­nić w umowie.

www-all-now-everything-for-free

Produkt wpro­wa­dzo­ny do sprze­da­ży i użyt­ko­wa­nia powi­nien być wypo­sa­żo­ny w funk­cjo­nal­no­ści wyma­ga­ne na pol­skim ryn­ku oraz sta­bil­ne pod­sta­wy pro­gra­mi­stycz­ne, któ­re powin­ny gwa­ran­to­wać trwa­łość wpro­wa­dzo­nych danych i rze­tel­ność gene­ro­wa­nych rapor­tów i ana­liz. Niestety XXX nie oka­zał się rze­tel­nym, i co naj­waż­niej­sze, wia­ry­god­nym narzę­dziem słu­żą­cym zarzą­dza­niu wszyst­ki­mi pro­ce­sa­mi przedsiębiorstwa.

Tu nie­ste­ty łyż­ka dzieg­ciu zno­wu do becz­ki kupu­ją­ce­go: po wyję­ciu z pudeł­ka”, prak­tycz­nie każ­de opro­gra­mo­wa­nie pra­cu­je popraw­nie. W ogrom­nej więk­szo­ści przy­pad­ków to pró­by jego dosto­so­wa­nia” powo­du­ją skut­ki jak wyżej opi­sa­ne. Wdrożenie powin­no mieć dwa eta­py: testy wer­sji stan­dar­do­wej, wdro­że­nie, testy wer­sji wdro­żo­nej. Bez tego prak­tycz­nie nie ma praw­nej moż­li­wo­ści eska­la­cji żądań napra­wy błę­dów powsta­łych w toku kasto­mi­za­cji (czy­li inge­ren­cji w kod aplikacji).

Jak uniknąć kłopotów?

Wdrażanie mono­li­tycz­nych sys­te­mów ERP samo w sobie nie jest niczym złym. Powinno ono, wdro­że­nie, być jed­nak poprze­dzo­ne wni­kli­wą ana­li­zą uwzględ­nia­ją­cą stra­te­gię fir­my, ewen­tu­al­ne uspraw­nie­nia i zmia­ny orga­ni­za­cyj­ne, zmien­ność oto­cze­nia ryn­ko­we­go danej fir­my. Poprzedni nie­daw­ny arty­kuł koń­czy­łem słowami:

Każda fir­ma, szu­ka­jąc spo­so­bu na uzy­ska­nie prze­wa­gi ryn­ko­wej, sta­ra się pew­ne obsza­ry ope­ra­cyj­ne budo­wać wg, wła­snej stra­te­gii. To mię­dzy inny­mi powo­du­je, że każ­de wdro­że­nie jest inne i nie ma jed­nej jedy­nie-słusz­nej archi­tek­tu­ry IT. (Źródło: Podsystemy sys­te­mów ERP | | Jarosław Żeliński IT-Consulting)

W arty­ku­le tym opi­sa­łem ogól­ną, dzie­dzi­no­wą archi­tek­tu­rę fir­my produkcyjno‑, handlowo‑, usłu­go­wej (popu­lar­ne w Polsce PPHU). Wygląda ona tak:

Model komponentów dziedzinowych ERPII

Powyższy dia­gram to uprosz­czo­na dzie­dzi­no­wa archi­tek­tu­ra IT fir­my. Analiza biz­ne­so­wa powin­na dać rekomendacje:

  • któ­re modu­ły są w ogó­le wyma­ga­ne w danej firmie,
  • któ­re mogą być stan­dar­do­wy­mi ele­men­ta­mi będą­cy­mi ele­men­ta­mi sys­te­mu ERP,
  • któ­re ele­men­ty są na tyle istot­ne i spe­cy­ficz­ne, że wybór roz­wią­za­nia spe­cja­li­zo­wa­ne­go da lep­sze efekty.

Biorąc pod uwa­gę fakt, że samo­dziel­ne sys­te­my rachun­ko­wo­ści finan­so­wej to raczej rzad­kość, moż­na zało­żyć, że wdra­ża­ny będzie zawsze (lub już jest) tak zwa­ny System ERP. Wersja mini­mal­na to modu­ły obsłu­gu­ją­ce dane bilan­so­we czy­li dowo­dy księ­go­we, środ­ki trwa­łe itp., oraz pła­ce, cza­sem tak zwa­ne kadry. To jest trzon opi­sa­ny pra­wem i w tym obsza­rze ame­ry­ki nie odkryjemy”.

Reszta to już indy­wi­du­al­ne potrze­by danej fir­my, łatwiej dobrać i wdro­żyć bez kasto­mi­za­cji, kil­ka naj­bar­dziej pasu­ją­cych, dostęp­nych na ryn­ku kom­po­nen­tów spe­cja­li­zo­wa­nych, niż dosto­so­wy­wać wiel­ki mono­lit. Po dru­gie ewen­tu­al­ne zmia­ny wpro­wa­dza­ne w jed­nym z takich nie­za­leż­nych kom­po­nen­tów nie prze­nio­są się na pozo­sta­łe (bo nie współ­dzie­lą żad­nych ele­men­tów). Do tego kolej­ność ich wdra­ża­nia jest prak­tycz­nie dowol­na, więc wdro­że­nie jest cał­ko­wi­cie pod­po­rząd­ko­wa­ne bie­żą­cym potrze­bom fir­my (bar­dzo czę­sto naj­mniej­szym pro­ble­mem jest wła­śnie rachun­ko­wość, któ­rą moż­na wdra­żać na koń­cu). Możliwa jest tak­że przy­szła rezy­gna­cja, z któ­re­go­kol­wiek kom­po­nen­tu, bez potrze­by inge­ren­cji czy rezy­gna­cji z pozostałych.

Pięć lat temu pisałem:

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. Dobry sys­tem ERP to śro­do­wi­sko pro­gra­mi­stycz­ne (tak zwa­ny fra­me­work, szkie­let). Systemy, nazwę je ?zapóź­nio­ne?, nadal wyma­ga­ją inge­ren­cji w ich kod by cokol­wiek osią­gnąć. Kompromisem jest sytu­acja, w któ­rej sys­tem ERP ma boga­ty inter­fejs (tak zwa­ne API, Application Programming Interface) pozwa­la­ją­cy na inte­gra­cję dedy­ko­wa­nych pod­sys­te­mów lub wła­śnie zewnętrz­nych kom­po­nen­tów czy­li korzy­sta­nia z moż­li­wo­ści jakie daje Cloud Computing). Przyszłość to kom­po­nen­ty? (Źródło: Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP | | Jarosław Żeliński IT-Consulting)

I to się już dzieje.….

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

Niedawno pro­wa­dzi­łem krót­ką ale cie­ka­wą dys­ku­sje na temat podej­ścia do ofe­ro­wa­nia opro­gra­mo­wa­nia ERP, wdro­żeń, ich doku­men­to­wa­nia i zapi­sy­wa­nia wyma­gań. Osoba, z któ­rą dys­ku­to­wa­łem to były kon­sul­tant dostaw­cy opro­gra­mo­wa­nia ERP świa­to­we­go lide­ra w tej bran­ży. Rozmowa potwier­dzi­ła jed­ną rzecz: celem dostaw­cy goto­we­go sys­te­mu ERP jest wdro­żyć go bez żad­nych mody­fi­ka­cji bo (jej kosz­ty) zja­da­ją mar­żę dostaw­cy. Celem kupu­ją­ce­go opro­gra­mo­wa­nie ERP, jest wspar­cie swo­ich pro­ce­sów biz­ne­so­wych a nie kopia cudzych. To dwa sprzecz­ne inte­re­sy. Silna fir­ma wymu­si na dostaw­cy ERP zmia­ny, sła­ba nie raz pod­da­je się wie­rząc tezom dostaw­cy, że nowy sys­tem upo­rząd­ku­je stan ich orga­ni­za­cji i da prze­wa­gę nad kon­ku­ren­cją. Kto tu ma rację?

Drugie pyta­nie: Po co wyko­rzy­sty­wać np. nota­cję for­mal­ną UML czy BPMN przy wdro­że­niach goto­we­go opro­gra­mo­wa­nia? Po pierw­sze po to by dostaw­ca mógł spraw­dzić czy opro­gra­mo­wa­nie, któ­re ofe­ru­je prze­twa­rza takie dane i tak jak chce tego kupu­ją­cy. Po dru­gie jeże­li tyl­ko nale­ży dodać bra­ku­ją­ce funk­cjo­nal­no­ści to trze­ba je naj­pierw zapro­jek­to­wać a potem zaim­ple­men­to­wać. Niestety obser­wu­je, że to wła­śnie dostaw­cy goto­we­go opro­gra­mo­wa­nia łamią wszel­kie regu­ły tego pro­ce­su: pomi­ja­ją etap pro­jek­to­wa­nia nowych ele­men­tów sys­te­mu, czę­sto pra­cu­ją ?na żywioł? ? wpa­da ana­li­tyk dostaw­cy ERP i ?coś robi? od razu ?w sys­te­mie?. Potem jest tyl­ko lawi­na błędów?

Wróćmy więc do rozmowy:

[Konsultant zna­ne­go na ryn­ku mię­dzy­na­ro­do­wym sys­te­mu ERP. Wiele lat pra­co­wa­łam jako kon­sul­tant księ­go­wy przy wdro­że­niach sys­te­mów ERP, teraz pra­cu­je jako admi­ni­stra­tor modu­ło­wy. W obsza­rze moich zain­te­re­so­wań jest głów­nie pro­ce­so­we uje­cie przed­się­bior­stwa, ale rów­nież ana­li­zy przed­wro­że­nio­we oraz kon­cep­cje wdro­że­nio­we. Chciałabym Pana zapy­tać, jak w prak­ty­ce spraw­dza sie doku­men­ta­cja UML na potrze­by wdro­żeń? Z tego co zaob­ser­wo­wa­łam, a tak­że z roz­mów, dys­ku­sji doszłam do wnio­sku, że UML jest narzę­dziem pra­co­chłon­nym, cza­so­chłon­nym, za mało prze­źro­czy­stym”.

[Jarosław Żeliński] UML to narzę­dzie for­mal­ne (nota­cja), wyma­ga więc pew­nej wie­dzy teo­re­tycz­nej (podob­nie jak pro­gra­mo­wa­nie z uży­ciem jakie­go­kol­wiek języ­ka pro­gra­mo­wa­nia). Pracochłonność? Model UML (np. dia­gram klas) jest (zależ­nie od sza­cun­ków) wie­lo­krot­nie mniej pra­co­chłon­ny w wyko­na­niu niż odpo­wia­da­ją­cy mu kod, prze­kła­da się to tak­że na testo­wa­nie kodu i oce­ny kosz­tu dane­go roz­wią­za­nia. Jednoznaczne opi­sa­nie np. for­ma­tu danych opi­so­wo (?pro­zą?) jest prak­tycz­nie nie­moż­li­we. Tabele są znacz­nie bar­dziej pra­co­chłon­ne niż dia­gram klas i maszy­ny sta­nów im odpowiadające.

[Konsultant] UML moim zda­niem nie wspo­ma­ga wdro­żeń, aby taka doku­men­ta­cja była war­to­ścio­wa musi być aktualizowana.

[JŻ] UML to nie jest narzę­dzie do wdro­żeń goto­wych sys­te­mów ERP, to jakieś nie­po­ro­zu­mie­nie, UML to narzę­dzie pro­jek­to­wa­nia opro­gra­mo­wa­nia, zaś w przy­pad­ku goto­wych ERP ma sens jedy­nie do mode­lo­wa­nia obiek­tów biz­ne­so­wych i inter­fej­sów na eta­pie spe­cy­fi­ko­wa­nia wyma­gań bo obiek­ty takie (np. fak­tu­ra, zle­ce­nie zała­dun­ku itp.) są prze­twa­rza­ne w sys­te­mach ERP (doku­men­ty itp.).

[Konsultant] Pan wie ile to zabie­ra czasu.

[JŻ] Znacznie mniej niż testo­wa­nie pro­to­ty­pów na żywym kodzie.

[Konsultant] Specjaliści z bran­ży źle sie wypo­wia­da­li o UML twier­dząc, że jest bar­dziej narzę­dziem aka­de­mic­kim, świet­nie uczą­ce filo­zo­fii pro­gra­mo­wa­nia, nato­miast zupeł­nie niepraktyczne.

[JŻ] Obawiam się, że nigdy nie korzy­sta­li z doku­men­ta­cji for­mal­nej, korzy­sta­li ze źle wyko­na­nej (w więk­szość jaką widu­ję) lub nie potra­fi­li sami jej wyko­nać w UML. Prawdopodobnie kry­ty­ko­wa­li coś cze­go nie uży­wa­li, jak prze­ka­zu­ję doku­men­ta­cje z uży­ciem UML to pro­gra­mi­ści klasz­czą z rado­ści, zaś na widok wyma­gań w posta­ci pro­zy od razu doda­ją 40% zapa­su na ryzyko …

[Konsultant] A Pan korzy­sta z UML’a. Jak do tego pod­cho­dzą klien­ci? Nie jest to pro­sta nota­cja i pew­nie nie do koń­ca zro­zu­mia­ła dla każ­de­go. Jakie są Pana spo­strze­że­nia w tym temacie?

[JŻ] UML to narzę­dzie ana­li­tycz­ne i pro­to­ty­po­we, klien­tom nie poka­zu­ję kodu pro­gra­mu i dia­gra­mów UML (po co??). Czy tłu­macz na chiń­ski daje swo­im klien­tom tekst tłu­ma­cze­nia do zatwier­dza­nia? Nie – daje go chiń­czy­kom do czy­ta­nia. Jest wie­le nie­po­ro­zu­mień wokół UML i BPMN. Krytykują go chy­ba tyl­ko Ci, któ­rzy nie zna­ją i nie potra­fią użyć. Podam taki przy­kład: wyma­ga­nia w posta­ci opi­su i dia­gra­mów UML są reali­zo­wa­ne przez pro­gra­mi­stów w zasa­dzie z bar­dzo małym ryzy­kiem, wyce­ny kosz­tów imple­men­ta­cji nie mylą się bar­dziej niż 10%, testo­wa­nie przy­pad­ków uży­cia na dia­gra­mach jest nawet 10 krot­nie tań­sze niż kodo­wa­nie i testo­wa­nie prototypów.

Typowe błę­dy jakie spotykam:

- złe mode­le (nie speł­nia­ją­ce zasad nota­cji, błęd­ne pro­jek­ty – w zasa­dzie nie­przy­dat­ne obraz­ki) fak­tycz­nie niko­mu nie poma­ga­ją (a wie­le jest nie­ste­ty złych, podob­nie mode­le pro­ce­sów, wie­le z nich to złe mode­le pozba­wio­ne zasad pragmatyki)

- sto­so­wa­nie UML do goto­wych sys­te­mów ERP jest nie­po­ro­zu­mie­niem za wyjąt­kiem doku­men­to­wa­nia danych oraz nowych funkcjonalności

- nie da się wyko­nać w posta­ci opi­su słow­ne­go sku­tecz­ne­go (jed­no­znacz­ne­go) opi­su dedy­ko­wa­ne­go sys­te­mu podob­nie (lub jakiej­kol­wiek dedy­ko­wa­nej czę­ści goto­we­go) jak nie da się tą meto­dą opi­sać pro­jek­tu biu­row­ca – robi sie rysun­ki tech­nicz­ne, któ­rych nie rozu­mie miesz­ka­niec tego biu­row­ca, ale te rysun­ki nie są dla nie­go, on dosta­je wizu­ali­za­cje (w inży­nie­rii opro­gra­mo­wa­nia matry­ce ekra­nów – mockupy).

Z moje­go doświad­cze­nia wszel­kie for­ma­li­zmy (UML, BPMN, inne) krytykują:

- ci któ­rzy ich nie rozumieją

- ci któ­rym prze­szka­dza­ją (zbyt jed­no­znacz­na doku­men­ta­cja pozwa­la ści­śle roz­li­czyć wyko­naw­cę, cze­go nie­któ­rzy nie chcą)

Dla przy­kła­du. Większość ludzi nie lubi geo­me­trii ale też nie potra­fią oni nicze­go nary­so­wać tyl­ko z pomo­cą cyr­kla i linij­ki, muszą mieć wzor­ni­ki do ryso­wa­nia figur geo­me­trycz­nych a na geo­me­trię narze­ka­ją, że trud­na i teo­re­tycz­na. Geometrie zna bar­dzo dobrze za każ­dy archi­tekt, musi. Niestety zawsze będą pro­jek­ty, w któ­rych mała i skoń­czo­na licz­ba goto­wych figur wzor­ni­ka nie wystar­cza i potrzeb­ne są inne… ktoś to musi zro­bić a nagi­na­nie wszyst­kie­go do kil­ku figur na wzor­ni­ku to zły pomysł…

Po dru­gie: nie­za­leż­nie od tego co wie ana­li­tyk piszą­cy wyma­ga­nia pro­zą, struk­tu­ra pro­gra­mu jest struk­tu­ra for­mal­ną i kom­pi­la­tor jest bez­względ­nym sędzią, podob­nie jak potem przy­szły użyt­kow­nik. To cze­go nie zwe­ry­fi­ko­wa­no na eta­pie pro­jek­to­wa­nia i tak trze­ba zro­bić na eta­pie kodo­wa­nia, tyl­ko tu jest to o wie­le droż­sze w przy­pad­ku popeł­nie­nia błędów.

Niewątpliwie ana­li­za i pro­jek­to­wa­nie (UML to narzę­dzie doku­men­to­wa­nia pro­jek­tu i two­rze­nia mode­li do testów) są trud­ne ale to tak jak z mode­la­mi samo­lo­tów w tune­lu aero­dy­na­micz­nym: nikt przy zdro­wych zmy­słach nie testu­je wszyst­kie­go na goto­wych samo­lo­tach tyl­ko na mode­lach bo to po pro­stu taniej (i bezpieczniej).

Zapewniam Panią, że tam gdzie pła­ci się za dzie­ło” sta­ła kwo­tę coraz czę­ściej mode­lu­je się i pro­jek­tu­je na papie­rze np. w UML, a potem dopie­ro koduje.

[Konsultant] Do tego miej­sca wszyst­ko jest dla mnie pięk­ne, ale zna­jąc życie, resz­ta już nie jest taka pięk­na. Powstaje pro­to­typ i trze­ba go prze­te­sto­wać. Jakoś nie wyobra­żam sobie, aby nawet naj­bar­dziej dosko­na­le wyko­na­na doku­men­ta­cja UML pozwo­li­ła nam pomi­nąć ten etap. W 2004 roku przez oko­ło pół roku bra­łam udział we wdra­ża­niu sys­te­mu dedy­ko­wa­ne­go, pamię­tam etap testów, jak wie­le poja­wia­ło sie błę­dów, pamię­tam ogrom pra­cy jaki nagle poja­wił sie na tym eta­pie. Gdyby wów­czas mia­ło dojść do tego jesz­cze bie­żą­ca aktu­ali­za­cja doku­men­ta­cji UML to pew­nie ter­min zamknię­cia pro­jek­tu prze­su­nął­by sie dale­ko, daleko..

[JŻ]Mamy trzy pod­sta­wo­we eta­py two­rze­nia oprogramowania:

- ana­li­za wyma­gań, jej pro­duk­tem jest spe­cy­fi­ka­cja wymagań

- pro­jek­to­wa­nie

- imple­men­ta­cja

Testowanie doty­czy prak­tycz­nie każ­de­go etapu:

- spe­cy­fi­ka­cje wyma­gań testu­je­my na mapach pro­ce­sów i to jest pro­ste jeże­li mamy dobry model pro­ce­sów biz­ne­so­wych: każ­dy biz­ne­so­wy doku­ment powi­nien przejść” przez model pro­ce­sów, na nim wska­zu­je­my miej­sca, w któ­rych ocze­ku­je­my inte­rak­cji z opro­gra­mo­wa­niem (sam dia­gram wska­że kontekst)

- pro­jekt (w szcze­gól­no­ści model dzie­dzi­ny) testu­je­my w ten spo­sób, że dla każ­de­go przy­pad­ku uży­cia wyko­nu­je­my model sekwen­cji: ta meto­dą prze­te­stu­je­my czy mamy wszyst­kie kla­sy i ich meto­dy czy­li prze­te­stu­je­my całą logi­kę systemu

- teraz ma miej­sce imple­men­ta­cja i tu testu­je­my kod każ­dej kla­sy (wewnątrz klas lub meto­dą testo­wa­nia inter­fej­sów, zale­ży od przy­ję­tej meto­dy, pole­cam poczy­ta­nie o TDD), bo one same z sie­bie, kla­sy i ich logi­ka prze­te­sto­wa­na na eta­pie pro­jek­to­wa­nia, są OK a pro­jekt jest spój­ny bo prze­szedł testy logi­ki na modelach.

I lite­ra­tu­ra i pro­gra­mi­ści potwier­dza­ją, że wykry­cie błę­du w pro­jek­cie jest co naj­mniej o rząd (albo nawet dwa, jak twier­dzą nie­któ­rzy) wiel­ko­ści tań­sze do popra­wie­nia niż błę­dy wykry­te w kodzie. Dotyczy to tak­że wpro­wa­dza­nia zmian.

[Konsultant] Aby Pan mnie źle nie zro­zu­miał, nie kwe­stio­nu­je korzy­sta­nia z UML’a, raczej w kon­tek­ście swo­ich doświad­czeń nie spo­tka­łam sie z wiel­ka apro­ba­tą u prak­ty­ków tego narzę­dzia. Dla mnie za bar­dzo chce być boha­te­rem” w tej sztu­ce jakim jest wdro­że­nie. Za bar­dzo absor­bu­je w pro­ce­sie implementacji.

[JŻ] Podtrzymuje, że na UML (a kon­kret­nie pro­jek­to­wa­nie przed kodo­wa­niem) narze­ka­ją Ci któ­rzy pro­gra­mu­ją na żywioł”, ana­lo­gie do pro­ce­su w budow­nic­twie są moim zda­niem jak naj­bar­dziej na miejscu.

[Konsultant] Mogę się mylić. Pan jest pierw­szym prak­ty­kiem jakie­go pozna­łam, któ­ry korzy­sta z UML’a i twier­dzi, że jest to dobre podej­ście, dla­te­go zapy­ta­łam Pana jak to wyglą­da w życiu.

[JŻ] W życiu jest tak, że moimi klien­ta­mi są głow­nie fir­my po przej­ściach”, te któ­re doświad­czy­ły wdro­żeń bez eta­pu pro­jek­to­wa­nia. Ostatnio coraz czę­ściej kon­trak­ty zwią­za­ne z opro­gra­mo­wa­niem są fixed pri­ce” (sta­łe zakres pro­jek­tu, koszt i ter­min reali­za­cji) i nie opła­ci się wyko­naw­cy kodo­wać i testo­wać w nie­skoń­czo­ność”, kodo­wa­nie bez pro­jek­tu jest w zasa­dzie nie­prze­wi­dy­wal­nym pro­ce­sem (dokład­nie tak jak zło­żo­na budo­wa bez pro­jek­tu). Po dru­gie znam innych ludzi uży­wa­ją­cych UML, są to naj­czę­ściej ludzie zwią­za­ni z dobry­mi pro­gra­mi­sta­mi .NET, JAVA (J2EE) a tak­że pro­jek­tan­ta­mi baz danych, korzy­sta­ją­cy z wzor­ców pro­jek­to­wych i gene­ral­nie obiek­to­wych metod two­rze­nia opro­gra­mo­wa­nia. Praktycznie każ­da fir­ma korzy­sta­ją­ca z meto­dy­ki RUP (lub lżej­szej ICONIX) uży­wa UML w jakiejś posta­ci. W przy­pad­ku goto­wych sys­te­mów ERP jest to (UML) dosko­na­łe wręcz narzę­dzie do opi­sa­nia tego jakie dane o doku­men­tach nale­ży prze­twa­rzać i jak je przetwarzać.

[Konsultant] Ale tak sobie myślę, że Pan dostar­cza doku­men­ta­cje UML pro­gra­mi­stom, oni się cie­szą bo maja kawal robo­ty juz zro­bio­nej, ale czy póź­niej po zro­bie­niu pro­to­ty­pu ta doku­men­ta­cja jest dalej uak­tu­al­nia­na? Jeśli nie, to jej żywot jest skoń­czo­ny, wła­śnie ten etap powsta­wa­nia sys­te­mu jest dla mnie momen­tem, gdy zasta­na­wiam się nad sen­sem two­rze­nia pra­co­chłon­nej doku­men­ta­cji w nota­cji UML, ale mogę sie mylić.

[JŻ] Po pierw­sze dobry prze­te­sto­wa­ny pro­jekt nie jest zmie­nia­ny pod­czas imple­men­ta­cji 🙂 bo taka jest jego rola (jak dosta­nie Pani dobry pro­jekt archi­tek­to­nicz­ny dom­ku, to domek jak powsta­nie jest taki jak pro­jekt i nie ma co uak­tu­al­niać), waż­ne by utrzy­mać szcze­gó­ło­wość pro­jek­tu na wła­ści­wym pozio­mie, nie powi­nien wykra­czać zbyt­nio poza samą logi­kę dzia­ła­nia. Moim zda­niem wie­le pro­jek­tów UML jest prze­sad­nie szcze­gó­ło­wych a w wie­lu miej­scach są zbyt ogólne.

[Konsultant] Jednak chcia­ła­bym wró­cić do goto­wych sys­te­mów ERP bo taki­mi sie zaj­mu­je. Wracam do arty­ku­łu. Dlaczego glo­ry­fi­ku­je Pan przed­się­bior­stwo i jego potrze­by? Czytając Pana arty­kuł odno­szę wra­że­nie, że potrze­by przed­się­bior­stwa uzna­je Pan jako jedy­ne słusz­ne. A gdy­by tak było, to nie było­by szan­sy wdra­ża­nia goto­wych sys­te­mów, a trze­ba by dla każ­dej fir­my pisać dedy­ko­wa­ne opro­gra­mo­wa­nie. Bez sensu.

[JŻ] Osobiście uwa­żam, że zama­wia­ją­cy jest głów­nym źró­dłem wyma­gań ale pod tym poję­ciem rozu­miem spon­so­ra pro­jek­tu i to jego biz­ne­so­wy cel jest nad­rzęd­ny bo to on za swo­je pie­nią­dze reali­zu­je stra­te­gię swo­jej fir­my. Jestem gorą­cym zwo­len­ni­kiem tezy, że to mene­dżer (pre­zes, itp.) jest auto­rem celu biz­ne­so­we­go i to on sta­wia cele dostaw­com sys­te­mów ERP. Jeżeli jest ryzy­ko, że tu jest pro­blem z zama­wia­ją­cym” (a nie raz bywa) to koniecz­ne nale­ży tu umie­ścić usłu­gę doradz­twa biz­ne­so­we­go i stra­te­gicz­ne­go”, któ­ra da uzgod­nio­ne wyma­ga­nia i cele biznesowe.

Wdrażanie goto­we­go opro­gra­mo­wa­nia w dużych fir­mach bez mody­fi­ko­wa­nia go jest w prak­ty­ce bez sen­su bo fir­my się róż­nią. Na wdro­że­nie gotow­ca bez uwag może sobie pozwo­lić mała fir­ma kupu­ją­ca sys­tem fak­tu­ro­wa­nia z pudeł­ka za 1000zł, ale fir­ma mają­ca swo­je zwy­cza­je i stra­te­gię? Nie. W moich pro­jek­tach zawsze (po ewen­tu­al­nym upo­rząd­ko­wa­niu) sza­nu­ję wewnętrz­ne zwy­cza­je firm, powsta­je model pro­ce­so­wy całej fir­my (dość ogól­ny), na nim wydzie­la­ne są te obsza­ry, któ­re są kan­dy­da­tem na goto­wy ryn­ko­wy sys­tem ERP (z regu­ły obszar finan­sów i pro­duk­cja cza­sa­mi inne) a to co wyma­ga­ło­by zmian w danym sys­te­mie ERP kan­dy­du­je na dedy­ko­wa­ny pod­sys­tem. Proszę zwró­cić uwa­gę na to, że prak­tycz­nie każ­dy sys­tem ERP jest, pod­czas wdro­że­nia, para­me­try­zo­wa­ny a bar­dzo czę­sto tak­że mody­fi­ko­wa­ny. Jeżeli więc w ofer­cie widzę, że koszt mody­fi­ka­cji (dosto­so­wa­nia do potrzeb klien­tów, wpro­wa­dze­nie nowych funk­cjo­nal­no­ści) to np. 30% war­to­ści ofer­ty, to ten obszar roz­wa­żam jako mate­riał na dedy­ko­wa­ny pod­sys­tem. Potem nie raz oka­zu­je się, że dostaw­ca ERP doda bra­ku­ją­ce funk­cje za np. 200 tys., a dedy­ko­wa­ny sys­tem wraz z inte­gra­cją kosz­tu­je nie raz mniej niż 100 tys. (zazna­czam, że oba te warian­ty wyma­ga­ją zapro­jek­to­wa­nia i testo­wa­nia wiec to nie jest argu­ment prze­ciw­ko pro­jek­tom w np. w UML).

[Konsultant] Widzi Pan, pozna­jąc wie­le pol­skich przed­się­biorstw zda­łam sobie spra­wę, że w Polsce panu­je bar­dzo dziw­ny zwy­czaj (jeśli to moż­na nazwać zwy­cza­jem). Ktoś zdo­by­wa pie­nią­dze i posta­na­wia zało­żyć fir­mę. W okrze­płych wol­no­ryn­ko­wych pań­stwach (zachód) w takiej sytu­acji wła­ści­ciel finan­sów poszu­ku­je spe­cja­li­stów, mena­dże­rów. Przekazuje im pałecz­kę, czu­wa, dowia­du­je się ale jeśli się nie zna na biz­ne­sie, to sie nie wtrą­ca. U nas jest ina­czej: mam kasę, two­rze fir­mę, mia­nu­je się jej pre­ze­sem i wtrą­cam się wszę­dzie, wszyst­ko wiem naj­le­piej. Efektem jest stwo­rze­niem jakieś dziw­nej, indy­wi­du­al­nej stra­te­gii przed­się­bior­stwa. Nie raz sły­sza­łam z satys­fak­cją wypo­wia­da­ne sło­wa: Takich roz­wią­zań nie spo­tka­cie nigdzie! Ale to zupeł­nie nie o to cho­dzi. Nie chcę się roz­pi­sy­wać. Chciałabym jed­nak Panu powie­dzieć, że ofer­ta goto­we­go sys­te­mu, zawie­ra w sobie boga­tą bazę uwag, popra­wek zdo­by­tych w trak­cie wie­lu, wie­lu wdro­żeń. Moment wdro­że­nia syte­mu infor­ma­tycz­ne­go w przed­się­bior­stwie jest bar­dzo dobry, aby zre­wi­do­wać stra­te­gie i zało­że­nia biz­ne­su, jak jest reali­zo­wa­ny w fir­mie. Może war­to wła­śnie sko­rzy­stać z tego co ofe­ru­je sys­tem, a nie upie­rać sie, że moje roz­wią­za­nia są naj­lep­sze i tak musi być! Niestety czę­sto tak jest w praktyce.

Proponuje Pan zbyt ide­ali­stycz­ne roz­wią­za­nie. Sądzę że tutaj potrzeb­ny jest mądry kom­pro­mis mię­dzy tym co pro­po­nu­ją sys­te­my, a potrze­ba­mi firm i bra­ku­je mi jed­ne­go: ujednolicenia.

[JŻ] To jest to co róż­ni mnie od wie­lu dostaw­ców ERP, ale też nie ja jeden tak uwa­żam (pole­cam M.E.Porter – Strategia kon­ku­ren­cji, napi­sał tam, że fir­my kopiu­jąc tech­no­lo­gie od kogoś tym samym podej­mu­ją decy­zje że zre­zy­gno­wa­ły już z kon­ku­ro­wa­nia na ryn­ku). Źródłem prze­wa­gi ryn­ko­wej jest tyl­ko to co odróż­nia fir­mę od jej kon­ku­ren­tów. Studiuje tak­że lite­ra­tu­rę z zakre­su zarzą­dza­nia i mar­ke­tin­gu: nigdzie na świe­cie nie potwier­dza się teza, że sko­pio­wa­nie metod kon­ku­ren­ta daje cokol­wiek poza usta­wie­niem się za nim (nigdy przed). Tak więc jeże­li fir­ma decy­du­je się na roz­wój i chce sobie w tym pomóc wdra­ża­jąc nowe tech­no­lo­gie to wła­śnie po to to robi, by być jesz­cze trud­niej­szym do dogo­nie­nia. Ja tak­że bar­dzo czę­sto sły­szę Takich roz­wią­zań nie spo­tka­cie nigdzie” i to jest głów­ny cel pro­jek­tu! Ujednolicenie firm to dla nich Walec Drogowy, któ­ry po nich prze­je­dzie i wyrów­na! Owszem trze­ba zwe­ry­fi­ko­wać i ewen­tu­al­nie zop­ty­ma­li­zo­wać orga­ni­za­cję fir­my (i po to się robi dobry model pro­ce­sów biz­ne­so­wych, by to prze­te­sto­wać i go ewen­tu­al­nie opty­ma­li­zo­wać) ale potem wła­śnie takie dedy­ko­wa­ne roz­wią­za­nie” nale­ży zaim­ple­men­to­wać bo ta fir­ma naj­praw­do­po­dob­niej dzię­ki nie­mu wła­śnie jest lide­rem w swo­jej bran­ży (to nie jest przy­pa­dek, że nie­któ­re pro­ce­du­ry są tajem­ni­cą fir­my) i usu­nię­cie tego jej lokal­ne­go zwy­cza­ju może nawet zabić firmę.

[Konsultant] W tema­cie wdro­żeń panu­je taka róż­no­rod­ność na każ­dym eta­pie prac, że dopraw­dy trud­no się w tym poła­pać. Nie two­rzy­my wspól­nych plat­form, nie mamy punk­tów wyj­ścia”, każ­de wdro­że­nie to pra­ca od począt­ku. Dla mnie to jest zupeł­nie nie tak.

[JŻ] A dla mnie jest to wła­śnie sens nowych tech­no­lo­gii IT i opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie. Polecam lite­ra­tu­rę o archi­tek­tu­rze kor­po­ra­cyj­nej, uka­za­ła się nie­daw­no książ­ka Architektura kor­po­ra­cyj­na jako stra­te­gia”. W niej auto­rzy poka­zu­ją na przy­kła­dach wie­lu firm, lide­rów ryn­ko­wych, że wła­śnie kul­ty­wo­wa­nie wła­snych uni­kal­nych struk­tur” dało im prze­wa­gę na ryn­ku i sukces.

Notatka: Polecam tak­że cie­ka­wy wpis na blo­gu Computerworld: ERP-owym pury­stom mówi­my sta­now­cze nie.

Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Wśród wie­lu zna­nych i sto­so­wa­nych spo­so­bów doku­men­to­wa­nia wyma­gań na sys­te­my są tek­sto­we i tabe­la­rycz­ne opi­sy oraz meto­dy for­mal­ne. Pierwsze są tak nie­jed­no­znacz­ne, że są źró­dłem wie­lu pro­ble­mów dru­gie tak kosz­tow­ne i nie­zro­zu­mia­łe dla laików”, że w zasa­dzie nie sto­so­wa­ne. Pośrodku mamy meto­dy pół­for­mal­ne” czy­li mode­le. Ich cechą jest duża jed­no­znacz­ność wyma­ga­ją jed­nak pew­ne­go mini­mal­ne­go oby­cia z dia­gra­ma­mi u ich czy­tel­ni­ka oraz dużych umie­jęt­no­ści u twór­cy. czę­sto powta­rzam swo­im stu­den­tom: dobry model jest jak wiersz: dużą sztu­ką jest jego napi­sa­nie ale do prze­czy­ta­nia powin­na wystar­czyć zna­jo­mość alfa­be­tu. W tym arty­ku­le, adre­so­wa­nym do każ­de­go kto spo­ty­ka się lub wie, że go to spo­tka, z ana­li­za­mi wyma­gań i ich doku­men­to­wa­niem za pomo­cą dia­gra­mów. Zwrócę tak­że uwa­gę na typo­we pro­ble­my i ryzy­ka zwią­za­ne ze sto­so­wa­niem popu­lar­nych meto­dyk i notacji.

Napisze kil­ka słów adre­so­wa­nych głów­nie do nabyw­ców sys­te­mów. Powiem na co zwra­cać uwa­gę w doku­men­ta­cjach wyma­gań i cze­go raczej nie robić same­mu. Cała doku­men­ta­cja wyma­gań opi­su­je to jaki ma być przy­szłe opro­gra­mo­wa­nie jed­nak klu­czem do jej sku­tecz­no­ści jest opis biz­ne­so­wy orga­ni­za­cji i jej zro­zu­mie­nie czy­li zro­zu­mia­ły dla wszyst­kich uczest­ni­ków pro­jek­tu model biz­ne­so­wy i wska­za­ny na nim zakres pro­jek­tu. Jest to naj­czę­ściej pomi­ja­ny ele­ment pro­jek­tu przez dostaw­ców sys­te­mów. Dlaczego? Zaryzykuje tezę: dostaw­cy sys­te­mów to dobrzy inży­nie­ro­wie, któ­rzy z regu­ły nie mają wie­dzy i doświad­cze­nia z zakre­su mar­ke­tin­gu i zarzą­dza­nia jed­nak anga­żo­wa­ni są w two­rze­nie narzę­dzi do wspo­ma­ga­nia zarzą­dza­nia. Źródłem wie­lu pro­ble­mów pro­jek­tów IT jest luka komu­ni­ka­cyj­na pomię­dzy biz­ne­sem a inży­nie­rią opro­gra­mo­wa­nia. Podobno powszech­nie o tym wia­do­mo a jed­nak nadal wie­le doku­men­ta­cji wyma­gań pozo­sta­wia wie­le do życze­nia. Dlaczego?

O tym jak przy­pad­ki uży­cia rodzą kłopoty

Obserwuję dwa rodza­je róż­nych podejść do ana­li­zy i doku­men­to­wa­nia wyma­gań: opi­sy testo­we i struk­tu­ral­ne w przy­pad­ku pla­no­wa­ne­go zaku­pu goto­we­go sys­te­mu oraz meto­dy zorien­to­wa­ne na przy­pad­ki uży­cia w pro­jek­tach budo­wa­nia sys­te­mów od zera” (tak zwa­nych dedy­ko­wa­nych). Pierwsze, opi­so­we, są od daw­na uzna­ne za złe więc nie będę się nad nimi tu roz­wo­dził i gene­ral­nie odra­dzam ich sto­so­wa­nie. Metody zorien­to­wa­ne na przy­pad­ki uży­cia są coraz czę­ściej uzna­wa­ne za nie­kom­plet­ne gdyż zatra­ca­ją biz­ne­so­wy kon­tekst pro­jek­tu zaś same przy­pad­ki uży­cia nic nie mówią o tak zwa­nych aspek­tach uży­cia sys­te­mu, jego słu­żeb­nej roli w pro­ce­sach biz­ne­so­wych (mowa tu o sys­te­mach wspo­ma­ga­ją­cych zarzą­dza­nie i pokrew­nych). Do tego przy­pad­ki uży­cia są z regu­ły two­rzo­ne z udzia­łem sze­re­go­wych pra­cow­ni­ków, przy­szłych użyt­kow­ni­ków sys­te­mu Ci zaś nie dość, że naj­czę­ściej nie mają poję­cia o cało­ścio­wej stra­te­gii fir­my to z regu­ły poda­ją infor­ma­cje słu­żą­ce ich par­ty­ku­lar­ne­mu chwi­lo­we­mu inte­re­so­wi a nie inte­re­so­wi całej organizacji.

RUP

Jedną z naj­czę­ściej spo­ty­ka­nych w fir­mach deve­lo­per­skich meto­dyk ana­li­zy i pro­jek­to­wa­nia jest Rational Unified Proces (RUP). Jest to typo­wy repre­zen­tant meto­dyk zorien­to­wa­nych na przy­pad­ki uży­cia i opi­su­je jedy­nie ogól­ne zasa­dy two­rze­nia obiek­to­we­go mode­lu sys­te­mu jakim jest tak­że dana orga­ni­za­cja. Metodyka ta bazu­je na nota­cji UML (Unified Modeling Language) ta zaś wspie­ra prak­tycz­nie tyl­ko obiek­to­we meto­dy ana­li­zy i pro­jek­to­wa­nia sys­te­mu a nie samej orga­ni­za­cji. UML nie zawie­ra nota­cji (typ dia­gra­mu) pozwa­la­ją­cej sku­tecz­nie mode­lo­wać orga­ni­za­cje w para­dyg­ma­cie pro­ce­so­wym. Diagram czyn­no­ści w UML sta­no­wi led­wie namiast­kę potrzeb­nych moż­li­wo­ści zaś jego rolą jest tak na praw­dę mode­lo­wa­nie algo­ryt­mów funk­cji (metod obiek­tów). Nawet pod­ręcz­ni­ki RUP’a odwo­łu­ją się do innych nota­cji takich jak eEPC czy od pew­ne­go cza­su BPMN (żr. UML 2.0 w akcji, pod­ręcz­nik opar­ty na pro­jek­tach i inne książ­ki o RUP). Jeżeli coś nowe­go poja­wi­ło się w RUP w kwe­stii two­rze­nia mode­li orga­ni­za­cji chęt­nie poznam tytuł i auto­ra książki.

O języ­kach i teo­rii komunikacji

Niedawno uka­za­ła się cie­ka­wa książ­ka (Inżynieria sys­te­mów infor­ma­cyj­nych, Paul Beynon-Davies), opi­su­je w dość przy­stęp­ny spo­sób daw­no zna­ną z teo­rii komu­ni­ka­cji spo­łecz­nej kwe­stię kon­tek­stu i odbio­ru mode­lu. Błędy w tej mate­rii są postrze­ga­ne, nie tyl­ko prze­ze mnie, jako pod­sta­wo­we źró­dło kło­po­tów w pro­jek­tach IT. Uogólniając nie ma zna­cze­nia czy dany model jest wyko­na­ny popraw­nie od stro­ny syn­tak­tycz­nej (czy popraw­nie połą­czo­no sym­bo­le) i seman­tycz­nej (czy uży­to wła­ści­wych sym­bo­li) w tej czy innej nota­cji. Znaczenie ma to, czy adre­sat popraw­nie i jed­no­znacz­nie go zro­zu­miał (semio­ty­ka mode­lu – to jak zna­ki zosta­ły ode­bra­ne i zro­zu­mia­ne przez obser­wa­to­ra) i nic inne­go się nie liczy.

Model ma dwa zada­nia w ana­li­zie: symu­la­cja rze­czy­wi­stej orga­ni­za­cji dla ana­li­ty­ka i pro­jek­tan­ta oraz udo­ku­men­to­wa­nie decy­zji orga­ni­za­cyj­nych dla mene­dże­rów. Ten dru­gi cel jest z regu­ły zanie­dby­wa­ny i w efek­cie mene­dże­ro­wie zama­wia­ją­cy sys­tem czę­sto pod­pi­su­ją doku­men­ta­cje, któ­rych tak na praw­dę nie rozu­mie­ją pod wpły­wem suge­stii (a bywa, że per­swa­zji!) pseu­do­ana­li­ty­ków dostaw­cy sys­te­mu, że nie muszą tego rozu­mieć ale muszą pod­pi­sać bo to wymóg pro­jek­tu. Nic bar­dziej błędnego!

Istotą opi­su wyma­gań na sys­tem jest kon­tekst całe­go pro­jek­tu i tej inwe­sty­cji a kon­tek­stem tym jest model biz­ne­so­wy zakres pro­jek­tu. Model biz­ne­so­wy moż­na wyko­nać nawet meto­da­mi for­mal­ny­mi za pomo­cą pseu­do­ko­du czy języ­ka rela­cji logicz­nych jed­nak model taki jest bez­war­to­ścio­wy, jeże­li nie sta­no­wi sobą zro­zu­mia­łe­go prze­ka­zu dla każ­de­go zaan­ga­żo­wa­ne­go w pro­jekt czy­taj szcze­gól­nie klien­ta biz­ne­so­we­go”. Kluczem do suk­ce­su jest tu mode­lo­wa­nie czy­li zobra­zo­wa­nie w spo­sób zro­zu­mia­ły dla każ­dej stro­ny w pro­jek­cie IT isto­ty biz­ne­su i jego kon­tek­stu w pro­jek­cie two­rze­nia i wdra­ża­nia opro­gra­mo­wa­nia. Model biz­ne­so­wy i wewnętrz­na struk­tu­ra zarzą­dza­nia orga­ni­za­cji to nie obiek­to­we mode­le a pro­ce­so­we mapy łań­cu­chów two­rze­nia war­to­ści w fir­mie. Model obiek­to­wy ma zasto­so­wa­nie dopie­ro pod­czas two­rze­nia mode­li infor­ma­cyj­nych czy­li struk­tu­ry danych prze­cho­wy­wa­nych i prze­twa­rza­nych w fir­mie a dane to nic inne­go jak repre­zen­ta­cja tych infor­ma­cji, któ­re fir­ma chce prze­twa­rzać oraz spo­sób w jaki chce to robić o czym wie­lu ana­li­ty­ków zda­je się zapo­mi­nać. Jak więc pro­wa­dzić ana­li­zy wymagań?

Na począ­tek moż­na chy­ba pole­cić dość dobrze udo­ku­men­to­wa­ne w lite­ra­tu­rze meto­dy ana­li­zy struk­tu­ral­nej, któ­rej czę­ścią jest mode­lo­wa­nia pro­ce­sów za pomo­cą Diagramów Przepływów Danych. Jako meto­da ana­li­zy i pozy­ski­wa­nia wyma­gań nie­co sie skom­pro­mi­to­wa­ła (bar­dzo pra­co­chłon­na i trud­na w obsza­rze kore­la­cji mode­lu pro­ce­sów i mode­lu danych) jed­nak uczy pro­ce­so­we­go podej­ścia do ana­li­zy. Jako doce­lo­we narzę­dzie pole­cam raczej współ­cze­sne mode­le pro­ce­sów biz­ne­so­wych zorien­to­wa­ne na pro­duk­ty pro­ce­sów (infor­ma­cje). Tu pole­cam prze­stu­dio­wa­nie dostęp­nej w sie­ci doku­men­ta­cji do takich nota­cji i narzę­dzi jak eEPC (pro­gram ARIS), BPMN (www​.omg​.org), ADONIS (wła­sna nota­cja) i wie­le innych w tym wie­le zaawan­so­wa­nych narzę­dzi CASE (Computer Aided System Engineering). Większość tych narzę­dzi ma wbu­do­wa­ną moż­li­wość uży­cia nota­cji BPMN i UML.

Dokumentacje te opi­su­ją głów­nie nota­cję jed­nak na dostęp­nych tam przy­kła­dach moż­na sie nie mało nauczyć. Naczelną zasa­dą mode­lo­wa­nia jed­nak zawsze będzie zro­zu­mia­łość mode­li dla człon­ków mode­lo­wa­nych orga­ni­za­cji. Po dru­gie mode­lo­wa­nie to sztu­ka, nie da się tego nauczyć z jed­nej książ­ki jak rze­mio­sła, nie ma goto­wych pro­ce­dur na wyko­na­nie dobre­go mode­lu. Modelowanie wyma­ga roz­le­głej wie­dzy i doświadczenia.

Na zakoń­cze­nie: nie mode­luj biz­ne­su jeże­li go nie rozumiesz

Na koniec dru­ga waż­na uwa­ga: nie da się mode­lo­wać orga­ni­za­cji i biz­ne­su nie zna­jąc tych dzie­dzin. Modelowanie pro­ce­sów biz­ne­so­wych, jak sama nazwa wska­zu­je, wyma­ga wie­dzy z zakre­su i mode­lo­wa­nia i pro­ce­sów biz­ne­so­wych czy­li zarzą­dza­nia i mar­ke­tin­gu. Dlatego oso­ba pra­gną­ca się nauczyć mode­lo­wa­nia biz­ne­so­we­go może nie musi koń­czyć MBA ale powin­na mieć dużą wie­dzę z zakre­su mar­ke­tin­gu i zarzą­dza­nia. Pamiętając tak­że, że w defi­ni­cji pro­ce­su biz­ne­so­we­go jest two­rze­nie war­to­ści” pole­cam prze­stu­dio­wa­nie lite­ra­tu­ry takiej jak try­lo­gia” M.E.Portera, a przy­naj­mniej jego Przewagę kon­ku­ren­cyj­ną” gdzie dokład­nie jest omó­wio­na teo­ria łań­cu­cha war­to­ści i pro­ce­sy biz­ne­so­we. Polecam tak­że 3. roz­dział (W jaki spo­sób infor­ma­cja wpły­wa na prze­wa­gę kon­ku­ren­cyj­ną, w tym pod­roz­dział Konkurowanie w epo­ce infor­ma­cji) M.E.Porter O kon­ku­ren­cji” gdzie opi­sa­no model łań­cu­cha war­to­ści w biz­ne­sie w posta­ci klu­czo­wych pro­ce­sów fir­my ryn­ko­wej. Jak ktoś ma czas to może zali­czyć tak­że mar­ke­ting” Kottlera to jed­nak jest bar­dziej ope­ra­cyj­ny opis zarzą­dza­nia. Polecam tak­że gorą­ca ZarządzanieP.Druckera.

Podsumowując: sys­te­my dla biz­ne­su two­rzo­ne są na proś­bę tego biz­ne­su by w tym biz­ne­sie poma­gać. Dlatego biz­nes na każ­dym kro­ku musi rozu­mieć opis tego co dosta­nie od ana­li­ty­ka wyma­gań zaś na począ­tek nale­ży opi­sać (zamo­de­lo­wać) sam biz­nes i do tego potrzeb­ne są mię­dzy inny­mi mode­le biz­ne­so­we i mode­le pro­ce­sów biznesowych.

Metodyki inży­nie­rii opro­gra­mo­wa­nia, sto­so­wa­ne tak­że w ana­li­zie wyma­gań na tak zwa­ne goto­we sys­te­my”, zorien­to­wa­ne na model biz­ne­so­wy i model dzie­dzi­ny sys­te­mu nale­żą do naj­sku­tecz­niej­szych i para­dok­sal­nie naj­rza­dziej sto­so­wa­nych. Dlaczego? Moim zda­niem wła­śnie dla­te­go, że w wie­lu przy­pad­kach pomi­ja sie etap rze­tel­nej ana­li­zy biz­ne­so­wej w pro­jek­tach IT pozwa­la­jąc, by opis wyma­gań wyko­nał od razu inży­nier bo to taniej”.

2010 r. Notatka: Zdaniem ana­li­ty­ków fir­my decy­du­ją­ce się na wdro­że­nie sys­te­mu ERP mogą unik­nąć roz­jeż­dza­ją­cych się ter­mi­nów i nad­mier­nie wyso­kich kosz­tów dzię­ki odpo­wied­nio prze­pro­wa­dzo­nej ana­li­zie przed­wdro­że­nio­wej. 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.” (źr. IDG, 2010r)

P.S. 2016 r. 

Osobom zain­te­re­so­wa­nym pole­cam opis jed­nej z meto­dyk ana­li­zy wyma­gań i pro­jek­to­wa­nia zorien­to­wa­nych na model biz­ne­so­wy i model dzie­dzi­ny sys­te­mu wraz z przy­kła­do­wym pro­jek­tem opi­sa­ny w mojej książ­ce Analiza Biznesowa.