Nie dać się szantażować swojemu własnemu dostawcy oprogramowania

Prawie dwa lata temu pisałem:

Pewien lider na ryn­ku dostaw­ców sys­te­mów ERP, ma zapis w umo­wie mówią­cy, że przej­mu­je pra­wa autor­skie do cało­ści pomy­słów i kodu (funk­cjo­nal­no­ści) jaki powsta­ną pod­czas prac z klien­tem nad dosto­so­wa­niem dostar­cza­ne­go sys­te­mu ERP (czy­li tak zwa­na kasto­mi­za­cja). Czyli know-how zama­wia­ją­ce­go idzie do kon­ku­ren­cji ? fir­ma ta chwa­li się na ryn­ku, że ma refe­ren­cyj­ne bran­żo­we rozwiązania ?

Byli bar­dzo zasko­cze­ni (i wście­kli) gdy dowie­dzie­li się, że zgod­nie z umo­wą ana­li­zę i pro­jekt imple­men­ta­cji (model PIM) nowych funk­cjo­nal­no­ści, któ­rych nie ma ich ERP, robię ja. Ich tłu­ma­cze­nie, że tyl­ko oni maja wie­dzę by to robić bo to ich ERP było nie do obro­ny: poka­za­łem im opis ich wła­sne­go sys­te­mu, jego meto­dy­ki wdro­że­nia i infor­ma­cję, że jest wyko­na­ny zna­nym narzę­dziem i w zna­nej tech­no­lo­gii, i że pro­jekt jaki ode mnie dosta­ną będzie wystar­cza­ją­cy i pra­wi­dło­wy by go zaim­ple­men­to­wać w tym ERP. Niestety, tu nie prze­ję­li wie­dzy i pomy­słów zama­wia­ją­ce­go. Tak się da zro­bić, trze­ba nie dać się szan­ta­żo­wać swo­je­mu wła­sne­mu dostawcy.

To dla­te­go dostaw­cy Ci (nie tyl­ko ERP i inne goto­we sys­te­my, tak­że fir­my two­rzą­ce opro­gra­mo­wa­nie dedy­ko­wa­ne) zro­bią wszyst­ko, by zasta­na u klien­ta ana­li­za poszła do kosza i naci­ska­ją na to, by ana­li­zę wyma­gań (przed­wdro­że­nio­wą) powta­rzać ręka­mi ich pra­cow­ni­ków. Nie praw­dą jest, że ana­li­zę wyma­gań może popraw­nie zro­bić wyłącz­nie dostaw­ca opro­gra­mo­wa­nia. Dostawca goto­we­go sys­te­mu ma wyko­nać ana­li­zą pokry­cia wyma­gań przez dostar­cza­ne przez sie­bie opro­gra­mo­wa­nie (opi­sa­na tu kie­dyś ana­li­za gap/fit). Deweloperzy, dostaw­cy spo­koj­nie mogą wyko­nać imple­men­ta­cję wyma­ga­nych nowych funk­cjo­nal­no­ści na bazie popraw­ne­go pro­jek­tu. Problem mają w tym, że wte­dy nie mogą go prze­jąć. (Prawo autor­skie, szpie­go­stwo prze­my­sło­we i pro­jek­to­wa­nie).

Artykuł ten sta­le na budzi wie­le kon­tro­wer­sji i pytań oraz sprze­ci­wów, głów­nie jed­nak ze stro­ny dostaw­ców opro­gra­mo­wa­nia. Obserwuje inny cie­ka­wy symp­tom: kupu­ją­cy sys­te­my ERP wie­rzą, że dostaw­ca opro­gra­mo­wa­nia ERP w jakiś cudow­ny spo­sób napra­wi ich fir­mę i nale­ży się go słu­chać. Zresztą pra­wie każ­dy dostaw­ca ERP tak mówi. To tak­że jest mit. Artykuł ten doty­czy nie­uczci­wych prak­tyk a nie wszyst­kich dostaw­ców opro­gra­mo­wa­nia ERP”.

Zaczynam dostrze­gać coraz więk­sze podo­bień­stwo pomię­dzy kor­po­ra­cja­mi far­ma­ceu­tycz­ny­mi i dostaw­ca­mi kom­plek­so­wych sys­te­mów ERP, jed­ni i dru­dzy twier­dzą, że:

  1. kupu­jąc ich pro­dukt gdy Cię boli, ból przejdzie,
  2. kupu­jąc ich pro­dukt gdy Cię jesz­cze nie boli, nie zabo­li Cię w przy­szło­ści (inni bio­rą, ich nie boli), po zaży­ciu nie ma moż­li­wo­ści spraw­dze­nia co by było gdy­by­śmy nie zaży­wa­li ale mówią, że na wszel­ki wypa­dek nale­ży zaży­wać (słyn­ne rekla­my wita­min, suple­men­tów die­ty a nawet pasty do zębów),
  3. nie trze­ba iść do leka­rza na kon­sul­ta­cje, nasze pro­duk­ty kupisz bez nich (bez recepty),
  4. jeże­li ktoś mówi, że nasze lekar­stwo nie dzia­ła to na pew­no kła­mie, nie słu­chaj go,
  5. owszem, wie­lu ludzi po zaży­ciu naszych leków mia­ło kło­po­ty, nie­któ­rzy zmar­li, ale to tyl­ko dla­te­go, że nie czy­ta­li ulotki.

Dostrzegam tak­że to, że wie­lu mene­dże­rów daje się szan­ta­żo­wać dostaw­com ERP, któ­rzy zaraz po pod­pi­sa­niu umo­wy zaczy­na­ją sta­wiać warun­ki jak­by zapo­mi­na­li kto komu i za co pła­ci. Zresztą bar­dzo czę­sto są to umo­wy o bar­dzo złej tre­ści, gorą­co odra­dzam zawie­ra­nie umów z dostaw­ca­mi opro­gra­mo­wa­nia tyl­ko ze wspar­ciem wła­snych praw­ni­ków na bazie wzo­ru umo­wy dostaw­cy opro­gra­mo­wa­nia. Z całym dla nich sza­cun­kiem, Wasi praw­ni­cy są na pew­no spe­cja­li­sta­mi z Waszej bran­ży czy pra­wa gospo­dar­cze­go, ale mało któ­ry ma dosko­na­łe oby­cie w bran­ży IT i pra­wie autor­skim. Na tej nie­wie­dzy żeru­ją dostaw­cy opro­gra­mo­wa­nia, któ­rzy czę­sto szan­ta­żu­ją swo­ich klien­tów licen­cja­mi i ogra­ni­cze­nia­mi dostę­pu do kodu.

Jak zapanować nad dostawcą

Najpierw krót­ki opis tego co Państwo kupu­je­cie. Poniżej struk­tu­ra każ­de­go dobrze zapro­jek­to­wa­ne­go oprogramowania:

Model architektury MVC

A więc krót­ko, żeby nie zanu­dzać: Każde opro­gra­mo­wa­nie jest mniej lub bar­dziej goto­we (zary­zy­ku­je, że jest goto­we w ponad 90%), doty­czy to tak­że tak zwa­ne­go opro­gra­mo­wa­nia dedy­ko­wa­ne­go. Oprogramowanie w cało­ści dedy­ko­wa­ne róż­ni się od tak zwa­ne­go goto­we­go tyl­ko tym, że nie ma jesz­cze Logiki biz­ne­so­wej dostar­czo­nej”. Dostawca opro­gra­mo­wa­nia w zasa­dzie musi zro­bić dwie rze­czy: skon­fi­gu­ro­wać śro­do­wi­sko, któ­re dostar­cza w tym ewen­tu­al­nie inte­gro­wa­ne opro­gra­mo­wa­nie (powy­żej wszyt­ko to co nie­bie­skie) oraz stwo­rzyć kod jesz­cze nie ist­nie­ją­cy czy­li Logikę biz­ne­so­wą dedy­ko­wa­ną (imple­men­ta­cja). W przy­pad­ku dostaw­cy pakie­tu ERP tej goto­wej logi­ki jest na praw­dę bar­dzo dużo.

I teraz:

  1. Dostawca udzie­li Ci licen­cji na wszyst­ko co nie­bie­skie, tu nale­ży spraw­dzić czy jest auto­rem wszyst­kie­go (co jest mało praw­do­po­dob­ne) czy tyl­ko części.
  2. Najgłupszym pomy­słem jest zgo­da na dosto­so­wy­wa­nie Logiki dostar­czo­nej do swo­ich potrzeb bo: 
    1. jest to bar­dzo kosz­tow­ne (inge­ren­cja w ogrom­ny ist­nie­ją­cy kod wyma­ga bar­dzo dużo zmian w tym testów)
    2. całe Twoje know-how sta­je się wła­sno­ścią dostaw­cy opro­gra­mo­wa­nia, Twoja Logika biz­ne­so­wa wzbo­ga­ci­ła kod dostaw­cy, prak­tycz­nie nie możesz zabro­nić jej dal­szej sprzedaży. 
  3. Najlepszym pomy­słem jest wcze­śniej­sze udo­ku­men­to­wa­nie i zawar­cie w kontr­ak­cie oddziel­nej czę­ści opro­gra­mo­wa­nia: Logiki biz­ne­so­wej dedy­ko­wa­nej, do któ­rej zacho­wu­jesz peł­nię praw i abso­lut­nie nie prze­ka­zu­jesz tych praw wyko­naw­cy opro­gra­mo­wa­nia, to że napi­sał ten kod na bazie doku­men­ta­cji jaką mu dostar­czysz, nie daje deve­lo­pe­ro­wi żad­nych praw do tej czę­ści kodu (Logiki biz­ne­so­wej dedy­ko­wa­nej, ale to wyma­ga dobrze napi­sa­nej umo­wy!) gdyż wte­dy pro­gra­mi­sta two­rzy utówr zależ­ny i nie naby­wa do nie­go żad­nych praw, w umie nale­ży dodat­ko­wo zawrzeć klau­zu­lę o ochro­nie know-how. Wiem, że więk­szość pro­gra­mi­stów mówi, że to nie praw­da, zapew­niam Cie, że mam rację – spraw­dzo­ne w praktyce.

Gdzie tkwi pod­stęp: Logika Biznesowa Dedykowana MUSI być udo­ku­men­to­wa­na osob­no w spo­sób jed­no­znacz­ny, nie dają­cy pro­gra­mi­ście pola do wła­snej inter­pre­ta­cji, a to wyma­ga opi­sa­nia tego meto­da­mi for­mal­ny­mi. Logika biz­ne­so­wa dedy­ko­wa­na musi być odręb­nym TWOIM kodem (w umo­wie pra­wa mająt­ko­we do nie­go oraz umo­wa o ochro­nie Twojego know-how). Ale to podob­no dużo kosz­tu­je! Nie, dostaw­ca opro­gra­mo­wa­nia z regu­ły i tak na Twój koszt to w jakiejś for­mie zro­bi! Dodatkowo prak­ty­ka poka­zu­je, że zapro­jek­to­wa­nie i wyko­na­nie odręb­nej Logiki biz­ne­so­wej dedy­ko­wa­nej, kosz­tu­je zawsze mniej (nie raz znacz­nie mniej!) niż koszt dosto­so­wy­wa­nia ogrom­nej ist­nie­ją­cej już logi­ki dostar­czo­nej. Większość kupu­ją­cych sys­te­my ERP z powo­du bra­ku tej wie­dzy i pod naci­skiem dostaw­cy opro­gra­mo­wa­nia, przyj­mu­je nie­ko­rzyst­ną dla sie­bie meto­dę wdro­że­nia i pod­pi­su­jąc wcze­śniej nie­ko­rzyst­ną dla sie­bie umo­wę (kasto­mi­za­cja opro­gra­mo­wa­nia). Większość wdro­żeń jest pro­wa­dzo­na w spo­sób, któ­ry odra­dzam, owszem ale (ten cytat dla docie­kli­wych) więk­szość firm IT dora­da wła­śnie kastomizację:

…powszech­ność jakie­goś poglą­du to bar­dzo sła­by, by nie rzec – żaden dowód jego praw­dzi­wo­ści. Powszechne bywa­ją cho­ciaż­by mity, któ­re ex defi­ni­tio­ne nie mają nic wspól­ne­go z prawdą. […]

Dlatego wła­śnie Sokrates przy­wią­zy­wał tak wiel­ką wagę do tego, aby pre­cy­zyj­nie i jed­no­znacz­nie defi­nio­wać ter­mi­ny i poję­cia, jakich uży­wa­my w dys­ku­sji i odrzu­cać to, co w naszym ich rozu­mie­niu jest przy­pad­ko­we, nie­pew­ne i sta­no­wi efekt nie naszej fak­tycz­nej wie­dzy, lecz jedy­nie podzie­la­ne­go z inny­mi ludź­mi ste­reo­ty­pu doty­czą­ce­go przed­mio­tu roz­mo­wy. (Czy powszech­ność jakie­goś poglą­du jest wprost pro­por­cjo­nal­na do jego praw­dzi­wo­ści?).

I na koniec: wybie­ra­jąc goto­we opro­gra­mo­wa­nie na praw­dę nie ma sen­su wypi­sy­wa­nie setek wyma­gań. Należy zre­zy­gno­wać z wie­lo­dnio­wych wywia­dów i spi­sy­wa­nia setek życzeń. Lepszym podej­ściem jest ana­li­za tego jak orga­ni­za­cja dzia­ła, ziden­ty­fi­ko­wa­nie obsza­rów stan­dar­do­wych” oraz tych, któ­re są Państwa spe­cjal­no­ścią” (Logika biz­ne­so­wa dedy­ko­wa­na), potem wybrać naj­bar­dziej pasu­ją­cy pakiet opro­gra­mo­wa­nia i nauczyć się go uży­wać (wdro­żyć do uży­cia). Brakującą logi­kę zle­cić jako dedy­ko­wa­ny pod-pro­jekt (ale na bazie wcze­śniej wyko­na­ne­go dla sie­bie pro­jek­tu) i stać się wła­ści­cie­lem powsta­łe­go opro­gra­mo­wa­nia. Podejście pole­ga­ją­ce na uzna­niu, że nowe opro­gra­mo­wa­nie nale­ży dosto­so­wać do potrzeb użyt­kow­ni­ków z regu­ły koń­czy się spro­wa­dze­niem nowe­go, nie raz bar­dzo war­to­ścio­we­go, opro­gra­mo­wa­nia do tego co sta­re i zna­ne i to na koszt kupu­ją­ce­go z bar­dzo mier­nym skutkiem.

Produkty w procesie analizy wymagań

W arty­ku­le Inżynieria wyma­gań mię­dzy inny­mi opu­bli­ko­wa­łem tak­so­no­mię wyma­gań, jej roz­wi­nię­ta postać:

taksonomia wymagań

Temat wyma­gań regu­lar­nie wypły­wa na forach dys­ku­syj­nych i na kon­fe­ren­cjach. Ostatnio w podob­nej for­mie poja­wił się na pew­nym forum ser­wi­su LinkedIn i na dzi­siej­szej kon­fe­ren­cji. Na forum padło pyta­nie: co wybrać jako doku­men­ta­cje wyma­gań: SRS czy Use Case (odpo­wied­nio [[Software Requirements Specification]] czy­li [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie]] i Przypadki Użycia opro­gra­mo­wa­nia). Na dzi­siej­szej kon­fe­ren­cji zaś praw­nik, pod­czas swo­je­go refe­ra­tu, zwró­cił uwa­gę na fakt, że od stro­ny umów, pro­jek­ty – od ana­li­zy przed­wdro­że­nio­wej do dostar­cze­nia zamó­wio­ne­go opro­gra­mo­wa­nia – nale­ży dzie­lić pro­jekt na fazy będą­ce, zależ­nie od celu, umo­wą efek­tu (umo­wa o dzie­ło) i umo­wą sta­ran­ne­go dzia­ła­nia (umo­wa zlecenia).

Problem w tym, że SRS – czę­sto rozu­mia­ne jako doku­ment o struk­tu­rze opi­sa­nej w [[reko­men­da­cji IEEE830]], zawie­ra w pew­nej for­mie przy­pad­ki uży­cia (ale nie ich sce­na­riu­sze) rozu­mia­ne jako opis funk­cjo­nal­no­ści. Do tego reko­men­da­cja ta nie jest stan­dar­dem zawar­to­ści doku­men­tu a rekomendacją. 

SRS_IEEE830-1998Topics

Pojęcie przy­pad­ku uży­cia ma co naj­mniej dwie zupeł­nie róż­ne defi­ni­cje: jed­ną rodem z książ­ki Alistair’a Cockbourna Jak pisać efek­tyw­ne przy­pad­ki uży­cia”, dru­ga w spe­cy­fi­ka­cji nota­cji UML. Osobiście pre­fe­ru­ję te dru­gą i tyl­ko o nie będzie tu mowa (Cockbourn zresz­tą jaw­nie wyra­ża nie­chęć do UML w swo­jej książce).

Dla upo­rząd­ko­wa­nia dal­szej tre­ści przyj­mu­ję, że poję­cie przy­pa­dek uży­cia opro­gra­mo­wa­nia i funk­cjo­nal­ność opro­gra­mo­wa­nia są toż­sa­me (a kon­kret­nie przy­pa­dek uży­cia opi­su­je spo­sób reali­za­cji funk­cjo­nal­no­ści): obie okre­śla­ją to jaki efekt chce osią­gnąć (do cze­go użyć), w kon­kret­nym przy­pad­ku, użyt­kow­nik opro­gra­mo­wa­nia (kon­kret­na funk­cja jaką peł­ni opro­gra­mo­wa­nie, to jego moż­li­wy przy­pa­dek użycia).

Popatrzmy na eta­py pro­jek­tu, któ­re wyróż­nio­no na bazie tego, jakiej wie­dzy potrze­bu­je­my na każ­dym z tych eta­pów, by zapla­no­wać kolejny.

Etapy projektu

Jako pierw­sze powsta­ją wyma­ga­nia biz­ne­so­we opra­co­wa­ne na bazie oce­ny sytu­acji biz­ne­so­wej. Są one albo wła­snym pro­duk­tem Zamawiającego albo pro­duk­tem zatrud­nio­ne­go do tego celu eks­per­ta. Na bazie wyma­gań biz­ne­so­wych (celów biz­ne­so­wych) wyko­nu­je się ana­li­zę wyko­ny­wal­no­ści tych celów, powsta­je pomysł roz­wią­za­nia pro­ble­mu (osią­gnię­cia celu) w posta­ci wyma­gań wobec reko­men­do­wa­ne­go roz­wią­za­nia. Jeżeli ist­nie­je (zna­le­zio­no) na ryn­ku roz­wią­za­nie (pro­dukt lub stan­dar­do­wą usłu­gę) zosta­je ono zaku­pio­ne i wdro­żo­ne. Jeżeli nie (doty­czy nie tyl­ko cało­ści ale i czę­ści wyma­gań) nale­ży roz­wią­za­nie naj­pierw zapro­jek­to­wać a potem dopie­ro zle­cić wyko­na­nie i wdro­że­nie (a wcze­śniej na bazie pro­jek­tu wycenić).

Każdy z tych pro­duk­tów to przed­miot osob­nej umo­wy (lub jej eta­pu). Zależnie od stop­nia nie­wie­dzy” po stro­nie Zamawiającego, może to być umo­wa o dzie­ło lub zle­ce­nia. Jednak zale­ca się (praw­ni­cy zale­ca­ją) by, zawsze tam gdzie anga­żo­wa­ny jest eks­pert (usłu­go­daw­ca) zewnętrz­ny, sto­so­wać umo­wy o dzie­ło (umo­wa efek­tu), gdyż pozwa­la to pano­wać i nad cza­sem i nad budże­tem pro­jek­tu oraz w przy­pad­ku spo­ru sądo­we­go, moż­li­we było okre­śle­nie przed­mio­tu spo­ru (opis tego co mia­ło zostać wytwo­rzo­ne – dzieło).

Do zawar­cia umo­wy o dzie­ło koniecz­ny jest opis tego co ma powstać (opis dzie­ła). Patrząc od koń­ca: zawie­ra­jąc umo­wę z dostaw­cą opro­gra­mo­wa­nia mamy wyma­ga­nia wobec pro­duk­tu goto­we­go (w momen­cie zaku­pu speł­nia je lub nie) lub wyko­na­ny pro­jekt tego co ma powstać. Aby powstał pro­jekt musi­my mieć okre­ślo­ne wyma­ga­nia wobec roz­wią­za­nia i wyma­ga­nia (cele) biz­ne­so­we. Najtrudniej jest wyce­nić etap ana­li­zy sytu­acji biz­ne­so­wej bo tu w zasa­dzie nie wie­my jaka ta sytu­acja jest. Wymagania biz­ne­so­we, by powsta­ły, wyma­ga­ją pozy­ska­nia wie­dzy o tym jak funk­cjo­nu­je orga­ni­za­cja Zamawiającego i jakie zmia­ny pla­nu­je. To etap ana­li­zy biz­ne­so­wej (model moty­wa­cji biz­ne­so­wej i mode­le pro­ce­sów biz­ne­so­wych). W tym wypad­ku będzie to raczej umo­wa sta­ran­ne­go dzia­ła­nia z eks­per­tem, któ­ry tę ana­li­zę (i mode­le) wykona.

Pewnym roz­wią­za­niem pro­ble­mu ryzy­ka umo­wy czas i mate­riał” (nie wie­my kie­dy i jakim kosz­tem powsta­nie ocze­ki­wa­ny pro­dukt), jest okre­śle­nie tego jaki kon­kret­nie pro­dukt ma powstać (opis tego, jak stwier­dzi­my, że pra­ce wyko­na­no popraw­nie) i okre­śle­nia cza­su jaki sobie na to daje­my. Wymaga to pew­nej inwe­sty­cji, poświę­ce­nia cza­su na to, ale opła­ci się bo moc­no obni­ża­my ryzy­ko projektu.

Konkluzja praw­ni­ka, by zawie­rać umo­wy o dzie­ło jeże­li tyl­ko jest to moż­li­we, jest moim zda­niem słusz­na. Tam gdzie nie mamy wystar­cza­ją­cej wie­dzy by zawie­rać takie umo­wy, war­to zain­we­sto­wać czas by okre­ślić jed­nak przed­miot umo­wy, gdyż umo­wa zle­ce­nia z eks­per­tem (dostaw­cą opro­gra­mo­wa­nia) powo­du­je, że Zamawiający kom­plet­nie nie panu­je nad umo­wą: nie wie jakie­go pro­duk­tu ocze­ki­wać, satys­fak­cja z wyko­na­nej pra­cy może nadejść w trud­nym do prze­wi­dze­nia czasie.

Druga uwa­ga: jeże­li cały pro­ces, od pierw­szej ana­li­zy do dostar­cze­nia pro­duk­tu, reali­zu­je jed­na fir­ma, mamy do czy­nie­nia z sytu­acją, w któ­rej dostaw­ca sam kon­tro­lu­je sta­wia­ne mu wyma­ga­nia bo sam sobie defi­niu­je to co ma następ­nie wytwo­rzyć. Taki brak kon­tro­li rodzi poważ­ne ryzy­ko nierzetelności.

Bo banki od wszystkiego są do niczego czyli złe modele dziedziny

Ten arty­kuł to odpo­wiedź na pew­ną dys­ku­sję roz­po­czę­tą od tezy, że na wie­lu stro­nach WWW (w nie­któ­rych książ­kach tak­że) mamy nie­ste­ty do czy­nie­nia z pseudowiedzą…

W arty­ku­le Cholerny dia­gram klas pisa­łem o mode­lu dzie­dzi­ny. Modelowana jest dia­gra­mem klas (nota­cja to narzę­dzie), zawie­ra logi­kę biz­ne­so­wą. W kon­wen­cji DDD ([[Domain Driven Design]]), model ten jest szkie­le­tem kom­po­nen­tu Model we wzor­cu MVC.

Tym razem napi­sze kil­ka słów o poje­dyn­czych kla­sach w mode­lu dzie­dzi­ny. Błąd numer jeden: kla­sy w mode­lu dzie­dzi­ny odwzo­ro­wu­ją poję­cia mode­lu poję­cio­we­go! Nie, model poję­cio­wy (słow­nik pojęć ich wza­jem­nych związ­ków) to nie model dzie­dzi­ny sys­te­mu. Tak się pro­jek­to­wa­ło encje w mode­lach rela­cyj­nych baz danych, prze­no­sze­nie tych doświad­czeń na grunt obiek­to­wy to powszech­na, cięż­ka cho­ro­ba, to rak toczą­cy te pro­jek­ty. Owszem, jeże­li ktoś zade­kla­ru­je, że two­rzy sys­tem meto­da­mi struk­tu­ral­ny­mi już może prze­stać czy­tać, ale niech uży­wa nota­cji i dia­gra­my ERD a nie UML i nie nazy­wa tego meto­da­mi obiek­to­wy­mi ana­li­zy i projektowania.

Niestety przy­kła­dy dia­gra­mów klas” na stro­nach wie­lu firm dorad­czych, szko­le­nio­wych i stro­nach wie­lu kon­sul­tan­tów”, «tre­ne­rów” itp. poka­zu­ją, że duch ana­li­zy struk­tu­ral­nej nadal żyje oraz, że myle­nie nota­cji UML z meto­da­mi obiek­to­wy­mi ana­li­zy i pro­jek­to­wa­nia jest powszech­ne. Przypomnę tu tyl­ko, że dia­gram klas to nota­cja, któ­rej moż­na użyć do wie­lu rze­czy, w tym do mode­lo­wa­nia pojęć, struk­tu­ry kodu opro­gra­mo­wa­nia obiek­to­we­go (zgod­ne­go z obiek­to­wym para­dyg­ma­tem, a nie tyl­ko korzy­sta­ją­ce­go z pole­ce­nia class w uży­tym języ­ku pro­gra­mo­wa­nia), sta­tycz­nych mode­li orga­ni­za­cji i wie­lu innych. Tak więc zda­nie pro­szę zro­bić dia­gram klas” nie zna­czy nic, to coś jak weź samo­chód o pojeź­dzij trosz­kę”, z trans­por­tem nie ma to nic wspólnego.

Jeżeli jed­nak uzna­my, że pro­wa­dzi­my ana­li­zę obiek­to­wą to zna­czy, że model rze­czy­wi­sto­ści (mode­lo­wa­nej) budu­je­my jako zespół współ­pra­cu­ją­cych obiek­tów reali­zu­ją­cych okre­ślo­ny cel”. Wtedy dia­gram klas to nie żad­ne dane, encje i inne nie­obiek­to­we pomy­sły (znam takich co mode­lu­ją klu­cze rela­cyj­ne w dia­gra­mach klas a to już jest tra­ge­dia nie­ste­ty, jest nawet wyda­na w Polsce książ­ka z taki­mi przy­kła­da­mi!). Projekt zaczy­na­my od klas i ich ope­ra­cji a nie od atrybutów!

Uwaga dodat­ko­wa. Sprawdzoną meto­dą ana­liz (w ogó­le) jest ana­li­za sys­te­mo­wa, jest to:

meto­da roz­wią­zy­wa­nia zło­żo­nych pro­ble­mów wyko­rzy­stu­ją­ca podej­ście sys­te­mo­we (holi­stycz­ne). Polega na trak­to­wa­niu ana­li­zo­wa­nej orga­ni­za­cji (zja­wi­ska) jako zło­żo­ne­go sys­te­mu, któ­re­go poszcze­gól­ne czę­ści pra­cu­ją” na powo­dze­nie cało­ści”. Obejmuje ona czte­ry zasad­ni­cze eta­py roz­wią­zy­wa­nia pro­ble­mu: (1) iden­ty­fi­ka­cja i sfor­mu­ło­wa­nie pro­ble­mu, (2) bada­nie (ana­li­zo­wa­nie) sytu­acji pro­ble­mo­wej (gro­ma­dze­nie infor­ma­cji, wyja­śnia­nie kwe­stii, ana­li­zo­wa­nie fak­tów itp., (3) ana­li­za pro­ble­mu (dekom­po­zy­cja zło­żo­ne­go pro­ble­mu na mniej­sze), (4) pro­jek­to­wa­nie roz­wią­za­nia (budo­wa mode­li, spe­cy­fi­ka­cje, symu­la­cja, warian­ty itp.).

Jak widać podo­bień­stwo para­dyg­ma­tu obiek­to­we­go i ana­li­zy sys­te­mo­wej jest bar­dzo duże, żeby nie powie­dzieć uderzające.

Tak więc ana­li­za i mode­lo­wa­nie (na eta­pie ana­li­zy) to roz­ło­że­nie ana­li­zo­wa­nej orga­ni­za­cji (ana­li­zo­wa­ne­go śro­do­wi­ska) na pro­ste obiek­ty, każ­dy o pro­stej odpo­wie­dzial­no­ści”. Wyłania się obraz mode­li skła­da­ją­cych się z tych czę­ści, któ­re pra­cu­ją na powo­dze­nie cało­ści”. Jakie powin­ny być owe czę­ści? Teraz pora na dwa cyta­ty z blo­gów pew­nych pro­gra­mi­stów (lubię dobrych pro­gra­mi­stów, bo przy­ta­ku­ją mi lub negu­ją a nie raz moc­no uczą poko­ry to co myślę czy­li nie błą­dzę w chmurach):

Single Responsibility Principle mówi, że kla­sa powin­na robić jed­ną rzecz, mieć jed­ną odpo­wie­dzial­ność. Jeśli ma jed­ną odpo­wie­dzial­ność to nie powin­na raczej grze­bać we wszyst­kich war­stwach. Wątpliwe jest aby kla­sa, któ­ra ma jed­ną odpo­wie­dzial­ność musia­ła się­gać do bazy danych i inter­fej­su użyt­kow­ni­ka i pli­ków i logi­ki biz­ne­so­wej i Bóg raczy wie­dzieć gdzie jesz­cze. (za using – papie­rek lak­mu­so­wy Twojej archi­tek­tu­ry | arek onli­ne | Arkadiusz Benedykt).

…naj­bar­dziej traf­ną meta­fo­rą obiek­tów pro­gra­mi­stycz­nych jest orga­nizm bio­lo­gicz­ny. Podobnie jak komór­ki, obiek­ty nie wie­dzą”, co dzie­je się wewnątrz innych obiek­tów, ale komu­ni­ku­ją się z nimi reali­zu­jąc bar­dziej zło­żo­ne cele. W prze­ci­wień­stwie do takie­go orga­ni­zmu pro­gram mono­li­tycz­ny przy­po­mi­na mecha­nizm zegar­ka, zawie­ra­ją­cy nie­prze­li­czal­ną (sic!) licz­bę try­bi­ków. Trybiki nie mają żad­nej inte­li­gen­cji i są bez­u­ży­tecz­ne poza mecha­ni­zmem, w któ­rym pra­cu­ją. Taki pro­jekt nie ma szans powo­dze­nia. Budując mecha­ni­zmy zega­ro­we, docho­dzisz w koń­cu do takiej zło­żo­no­ści, że całość prze­sta­je funk­cjo­no­wać. (Holistycznie o inży­nie­rii opro­gra­mo­wa­nia: Bo naj­waż­niej­sza jest odpo­wie­dzial­ność Synu…).

i nie­ste­ty to co widu­ję na wie­lu stro­nach WWW, w pro­jek­tach itp. (dru­ga wada czę­sto spo­ty­ka­nych mode­li dziedzinowych):

Dopisujemy kolej­ne meto­dy a tym­cza­sem kla­sa puch­nie. Przy osią­gnię­ciu masy kry­tycz­nej, wpro­wa­dze­nie jakiej­kol­wiek zmia­ny, nawet tej naj­mniej­szej powo­du­je, że spę­dza­my godzi­ny na debu­go­wa­niu kodu i spraw­dza­niu dla­cze­go nie zawsze dzia­ła tak jak byśmy tego chcie­li. (Single Responsibility Principle | arek onli­ne).

Swego cza­su na jed­nej z kon­fe­ren­cji o ana­li­zie wyma­gań, mówi­łem o potrze­bie zro­zu­mie­nia funk­cjo­no­wa­nia ana­li­zo­wa­nej orga­ni­za­cji (fir­my) o i tym jak to udokumentować:

…wszyst­ko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia, sno­oker – naj­trud­niej­sza gra w bilar­da – to to tyl­ko pro­ste kule i kij. Nawet naj­więk­szą orga­ni­za­cję moż­na, w toku ana­li­zy, roz­ło­żyć na skoń­czo­ną licz­bę ról i reguł ich postę­po­wa­nia by zro­zu­mieć jej funk­cjo­no­wa­nie. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji o sys­te­mach ERP).

Analiza biz­ne­so­wa to etap opi­su (zro­zu­mie­nia) mode­lo­wa­nej orga­ni­za­cji (mode­le pro­ce­sów itp.). Potem, powsta­je model roz­wią­za­nia, któ­rym jest nie raz wła­śnie opro­gra­mo­wa­nie, jego logi­ka (patrz powyż­szy cytat) to obiek­to­wy model dzie­dzi­ny sys­te­mu”, a nie jakiś dia­gram klas nafa­sze­ro­wa­ny atry­bu­ta­mi i pozba­wio­ny ope­ra­cji bo jest dokład­nie odwrotnie:

zly modelAnemic Domain Model: This is one of tho­se anti-pat­terns tha­t’s been aro­und for quite a long time, yet seems to be having a par­ti­cu­lar spurt at the moment. I was chat­ting with Eric Evans on this, and we’ve both noti­ced they seem to be get­ting more popu­lar. As gre­at boosters of a pro­per Domain Model, this is not a good thing. (AnemicDomainModel).

Dla kon­tra­stu cytat z jed­nej ze stron WWW pew­nej fir­my szkoleniowej:

Zwróćmy uwa­gę, że na mode­lu dzie­dzi­ny nie umiesz­cza­my klas imple­men­tu­ją­cych logi­kę apli­ka­cji, jej inter­fejs użyt­kow­ni­ka czy war­stwę dostę­pu do danych. Nie war­to też na mode­lu dzie­dzi­ny umiesz­czać metod. (Diagramy klas – model dzie­dzi­ny i pro­jekt apli­ka­cji).

I tyle mam dzi­siaj do powie­dze­nia o nie­któ­rych kon­sul­tan­tach i wykła­dow­cach … (a tu trosz­kę praw­dy)

P.S.

Bardzo czę­sto spo­ty­kam się z tezą, że model dzie­dzi­ny powi­nien opra­co­wy­wać archi­tekt by doko­nać ewen­tu­al­nych opty­ma­li­za­cji jesz­cze przed imple­men­ta­cją. Stawianie takich tez ma w moich oczach dwa głów­ne źró­dła: dostaw­ca usłu­gi (deve­lopr) szu­ka oka­zji by pro­jekt nagiąć do swo­ich potrzeb, do posia­da­nych goto­wych kom­po­nen­tów nie speł­nia­ją­cych jed­nak wyma­gań. Innym powo­dem jest zwy­kła nie­wie­dza. O opty­ma­li­za­cji kil­ka pro­stych tez usta­mi pro­gra­mi­sty: 3 zasa­dy opty­ma­li­za­cji. Więc powtó­rzę: na eta­pie ana­li­zy i pro­jek­to­wa­nia nicze­go nie uprasz­cza­my ani nie opty­ma­li­zu­je­my bo nie wie­my czy w ogó­le zaist­nie­je taka potrze­ba, a opty­ma­li­za­cja ZAWSZE psu­je model.

Modelowanie struktury organizacyjnej – widać światełko w tunelu

Pisząc recen­zję książ­ki Modelowanie biz­ne­so­we napi­sa­łem, że kom­plet­ny model orga­ni­za­cji to:

słow­nik pojęć (Glossary), model struk­tu­ry orga­ni­za­cyj­nej, regu­ły biz­ne­so­we (spe­cy­fi­ka­cja) oraz model pro­ce­sów biz­ne­so­wych korzy­sta­ją­cy z trzech poprzed­nich. Całość sta­no­wi dopie­ro kom­plet­ny model organizacji.

W Listopadzie ubie­głe­go roku tak­że pisa­łem o mode­lo­wa­niu struk­tu­ry organizacyjnej.

Osobiście uwa­żam, że mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML nie jest dobrym pomy­słem. Są do tego ?prost­sze? narzę­dzia, nie przy­pad­kiem te lep­sze narzę­dzia CASE mają do tego dedy­ko­wa­ny dia­gram. Niestety nie ma tu dedy­ko­wa­nej nota­cji, dla­te­go bar­dzo waż­ne jest by słow­nik pojęć w mode­lu zawie­rał takie poję­cia jak pra­cow­nik, komór­ka orga­ni­za­cyj­ne itp. Dobrym pomy­słem jest zde­fi­nio­wa­nie wła­snej kon­wen­cji (dia­gram, sym­bo­le, defi­ni­cje pojęć) np. jak ta na począt­ku arty­ku­łu. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Są wido­ki by ten brak został uzu­peł­nio­ny. OMG pra­cu­je nad for­mal­nym meta­mo­de­lem ([[Organisation Structure Metamodel]]) do mode­lo­wa­nia struk­tur orga­ni­za­cyj­nych. Specyfikacja jesz­cze nie zosta­ła opu­bli­ko­wa­na, jest na eta­pie RFP, ale mamy przecieki :).

Ogólnie szkie­let tego meta­mo­de­lu ma nastę­pu­ją­cą postać:

Profil Organisation Structure Metamodel

Powyższy dia­gram przed­sta­wia pro­fil czy­li model poję­cio­wy, któ­ry może słu­żyć do budo­wy dia­gra­mu struk­tu­ry orga­ni­za­cyj­nej. Powyższe poję­cia to sys­tem ste­reo­ty­pów, czy­li znacz­ni­ków”. Przykładowy sche­mat struk­tu­ry orga­ni­za­cyj­nej z uży­ciem tych ste­reo­ty­pów mógł­by mieć poniż­szą postać (dia­gram więk­sze są dzie­lo­ne na pod­rzęd­ne struktury):

Model Struktury Organizacyjnej

Kilka słów komen­ta­rza. Szkieletem każ­dej takiej struk­tu­ry jest sys­tem komó­rek orga­ni­za­cyj­nych. Ta część z regu­ły nie budzi wąt­pli­wo­ści i nie stwa­rza pro­ble­mów, do cza­su gdy zacho­wu­je drze­wia­stą struk­tu­rę (każ­dy ma tyl­ko jed­ne­go prze­ło­żo­ne­go). Problemem poja­wia się, gdy zaczy­na­my mówić o kom­pe­ten­cjach, rolach i funk­cjach osób zaj­mu­ją­cych poszcze­gól­ne sta­no­wi­ska i pró­bie mode­lo­wa­nie funk­cjo­no­wa­nia organizacji.

Typowym pro­ble­mem, z jakim spo­ty­kam się poma­ga­jąc two­rzyć lub audy­tu­jąc mode­le pro­ce­sów biz­ne­so­wych czy np. ana­li­zy cią­gło­ści dzia­ła­nia, jest mapo­wa­nie ról w pro­ce­sach na struk­tu­rę orga­ni­za­cyj­ną oraz zarzą­dza­nie kompetencjami.

Mamy tu do czy­nie­nia z pro­ble­mem jakim jest to, że jed­ną rolę w pro­ce­sie może peł­nić wie­le osób (sta­no­wisk). Klasyką jest np. to, że fak­tu­rę może wysta­wić nie tyl­ko Fakturzysta ale np. każ­dy pra­cow­nik dzia­łu księ­go­wo­ści i dyr. sprze­da­ży. Porażką mode­la­rza” będzie nary­so­wa­nie dia­gra­mu, na któ­rym będzie, dla każ­de­go z powyż­szych sta­no­wisk, dedy­ko­wa­ny tor w pro­ce­sie i jakaś logi­ka bra­mek” poka­zu­ją­ca kie­dy kto wysta­wi tę fak­tu­rę. Z dru­giej stro­ny z regu­ły nie­praw­dą jest, że nikt poza fak­tu­rzy­stą nie może wysta­wić fak­tu­ry. Wystarczy jed­nak stwo­rzyć blo­czek” Rola lub Kompetencje (zależ­nie od sytuacji)->Wystawianie fak­tur i sko­ja­rzyć z wła­ści­wy­mi sta­no­wi­ska­mi, a blo­czek ten dopie­ro mapo­wać na role w pro­ce­sach. Uzyskamy dzię­ki temu praw­dziw­szy” model, uzy­sku­je­my moż­li­wość jed­no­znacz­ne­go mapo­wa­nia (śla­do­wa­nie: «tra­ce») ele­men­tów struk­tu­ry orga­ni­za­cyj­nej na model pro­ce­sów biz­ne­so­wych, być może na model dzie­dzi­ny. Możliwe sta­nie się testo­wa­nie popraw­no­ści modelu.

Praktycznie żaden dia­gram struk­tu­ry orga­ni­za­cyj­nej, jaki moż­na spo­tkać w doku­men­tach więk­szo­ści firm i spół­ek, nie nada­je się do nicze­go poza ilu­stro­wa­niem doku­men­tów w jakich jest umiesz­cza­ny. Nie ma w tym nic złe­go, do cza­su gdy nie docho­dzi do ana­li­zy funk­cjo­no­wa­nia takiej organizacji.

Ktoś zapy­ta: po co te zaba­wy, komu to prze­szka­dza? Odpowiedź jest pro­sta: dia­gram, któ­ry nie pozwa­la na ana­li­zę zależ­no­ści, ana­li­zę wpły­wu, testo­wa­nie jed­no­znacz­no­ści nie jest żad­nym mode­lem, nie jest przy­dat­ny do ana­li­zy. Można nim co naj­wy­żej ład­nie zilu­stro­wać doku­men­ty ale na pew­no nie nada­je się do ana­li­zy a przy­po­mnę, że:

nauka mówi dość jasno: aby prze­wi­dy­wać reak­cje bada­ne­go przed­mio­tu nale­ży zro­zu­mieć jak funk­cjo­nu­je i opra­co­wać jego model. Po dro­dze nale­ży udo­wod­nić, praw­dzi­wość modelu.

Zaś:

Samo utwo­rze­nie map (bo nie mode­li) w posta­ci dia­gra­mów z pomo­cą wywia­dów, sesji warsz­ta­to­wych i obser­wa­cji, da pro­dukt podob­ny do zdję­cia lot­ni­cze­go rze­ki: wie­my któ­rę­dy pły­nie, ale kom­plet­nie nie rozu­mie­my dla­cze­go aku­rat tak.

Tak więc, jeże­li ana­li­za ma posłu­żyć wdro­że­niu jakie­go­kol­wiek opro­gra­mo­wa­nia czy zmian orga­ni­za­cyj­nych, to pomo­gą nam w tym tyl­ko mode­le a nie obraz­ki”…

Na kon­fe­ren­cjach i forach toczą się sta­le dys­ku­sje na ten temat. Większość firm dorad­czych, infor­ma­tycz­nych oraz ich ana­li­ty­cy bro­nią tezy, że celem ana­li­zy jest zebra­nie infor­ma­cji w posta­ci doku­men­tów i zesta­wień. Niestety takie doku­men­ty są kom­plet­nie nie­przy­dat­ne, mają war­tość nagra­nia (patrz wyżej zdję­cie lot­ni­cze), nie da się na ich posta­wie wycią­gać żad­nych pozwa­la­ją­cych na dowo­dze­nie ich słusz­no­ści, wnio­sków nie licząc może oce­ny este­ty­ki edytorskiej.

Wiele się pisze o tym, że mode­lo­wa­nie słu­ży do doku­men­to­wa­nia pro­jek­tów. Otóż nie. Do doku­men­to­wa­nia pro­jek­tów słu­ży ryso­wa­nie, mode­lo­wa­nie słu­ży do pro­wa­dze­nia ana­liz poprzez testy mode­li, symu­la­cje i ana­li­zę sce­na­riu­szy. (Sabotaż doku­men­ta­cyj­ny).

Niewątpliwą zale­tą takiej pisa­nej obraz­ko­wej ana­li­zy” jest to, że nie wyma­ga ona abso­lut­nie żad­nych kom­pe­ten­cji poza umie­jęt­no­ścią komu­ni­ka­cji. Takim ana­li­ty­kiem może być nie­mal­że każ­dy (łatwa rekru­ta­cja, niski koszt), ale czy taki jest cel ana­liz poprze­dza­ją­cych pro­jek­ty, war­te set­ki tysię­cy zło­tych a nie raz miliony?

Na zakoń­cze­nie dodam, że naj­gor­szym spo­so­bem jaki znam i jaki nie­ste­ty czę­sto spo­ty­kam, na mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej, jest uży­cie dia­gra­mu klas lub dia­gra­mu przy­pad­ków uży­cia i mode­lo­wa­nie z zasto­so­wa­niem dzie­dzi­cze­nia (klas lub aktorów).

Studiowanie zakre­sów obo­wiąz­ków pra­cow­ni­ków firm jaw­nie poka­zu­je, że to nie praw­da. Wielu mene­dże­rów dzia­łów nie ma kom­pe­ten­cji swo­ich pod­wład­nych, nie raz szef dzia­łu praw­ne­go nie ma, i nie musi mieć, upraw­nień rad­cow­skich czy adwo­kac­kich, w wie­lu więk­szych sekre­ta­ria­tach, upo­waż­nie­nia do pew­nych pod­pi­sów są przy­dzie­la­ne indy­wi­du­al­nie i szef (sze­fo­wa) tego dzia­łu nie ma tych wszyst­kich upo­waż­nień. Szef kan­ce­la­rii taj­nej może mieć upraw­nie­nia do infor­ma­cji taj­nej nada­ne przez ABW, któ­rych to upraw­nień nie ma nie raz, jego prze­ło­żo­ny. Przykładów na fał­szy­wość dzie­dzi­cze­nia upraw­nień w struk­tu­rze orga­ni­za­cyj­nej moż­na podać tak ogrom­ną ilość, że dość czę­ste sto­so­wa­nie tej kon­struk­cji wyda­je mi się niezrozumiałe.

W efek­cie pro­jek­tu­jąc opro­gra­mo­wa­nie i sto­su­jąc meto­dę dzie­dzi­cze­nia dla akto­rów sys­te­mu powie­la­my te nie­praw­dę w sys­te­mie co rodzi nie raz ogrom­ne kło­po­ty. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Na zakoń­cze­nie pole­cam cie­ka­wy arty­kuł na temat mode­lo­wa­nia ról w opro­gra­mo­wa­niu.

Wdrożenie ERP – koszt czy zysk?

Wpadł mi nie­daw­no w ręce arty­kuł na temat wdro­żeń, fragment:

Warto wybie­rać pro­gra­my ela­stycz­ne i umoż­li­wia­ją­ce reago­wa­nie na indy­wi­du­al­ne potrze­by przed­się­bior­stwa, wyni­ka­ją­ce np. ze spe­cy­fi­ki bran­ży, zło­żo­no­ści struk­tu­ry orga­ni­za­cyj­nej, czy tery­to­rial­ne­go roz­pro­sze­nia oddzia­łów fir­my. Zwłaszcza dla firm z sek­to­ra MSP, któ­re na zmien­ne potrze­by ryn­ku muszą być szcze­gól­nie wyczu­lo­ne, moż­li­wość szyb­kie­go gene­ro­wa­nia dyna­micz­nych i wie­lo­wy­mia­ro­wych rapor­tów wyda­je się być bar­dzo istot­na. Nawet nie­wiel­kie odchy­le­nia od pla­no­wa­nych war­to­ści (np. w sprze­da­ży dane­go rodza­ju pro­duk­tów) mogą mieć tutaj kolo­sal­ne zna­cze­nie. Dlatego apli­ka­cje o wyso­kim stop­niu mody­fi­ko­wal­no­ści mają ogrom­ną prze­wa­gę nad roz­wią­za­nia­mi ?zamknię­ty­mi? dając gwa­ran­cję szyb­kie­go zwro­tu z inwestycji. […]

Przytaczam ten cytat, bo czę­sto mie­wam na kon­fe­ren­cjach pyta­nia wła­śnie od wła­ści­cie­li firm zali­cza­nych do MŚP: Czy nam się to może opłacić?”.

Przede wszyst­kim jest to pyta­nie posta­wio­ne na gło­wie, bo bra­ku­je tu waż­nej poprze­dza­ją­cej infor­ma­cji w rodza­ju mamy kło­pot z…”. Mimo czę­sto spo­ty­ka­nej tezy: nie da się obec­nie zarzą­dzać fir­mą bez sys­te­mu ERP” życie poka­zu­je, że da się i to nie raz nie­źle. Wśród firm MSP sys­tem ERP posia­da znacz­nie mniej niż 50% tych firm!

Ale pyta­nia się poja­wia­ją, więc coś jest na rze­czy. Co? Jak zapy­tam Czemu Państwo o to pyta­cie” , to pada­ją naj­czę­ściej dwie odpo­wie­dzi: czy­ta­li­śmy, że to poma­ga” oraz mamy pro­ble­my z … czy sys­tem ERP nam w tym pomoże?”

Pierwsze pyta­nie to taki deli­kat­ny kon­for­mizm w rodza­ju inni mają to może i my. Tak nie­ste­ty reagu­ją fir­my, ich zarzą­dy, któ­re nie mają pomy­słu na roz­wój (a nie raz na ist­nie­ją­ce pro­ble­my) i mają nadzie­je, że wdro­że­nie sys­te­mu ERP w magicz­ny spo­sób ulep­szy zarzą­dza­nie fir­mą. Być może uspraw­ni ale na pew­no nie ulep­szy. Nie wol­no zapo­mi­nać, że opro­gra­mo­wa­nie to tyl­ko narzę­dzie. Niestety wie­lu dostaw­ców nęci klien­tów opo­wie­ścia­mi, że sys­tem nasz ma wbu­do­wa­ne refe­ren­cyj­ne pro­ce­sy biz­ne­so­we, zgro­ma­dzo­ne doświad­cze­nie z całe­go świa­ta, jego wdro­że­nie spo­wo­du­je …” i tu cała masa obiet­nic. Niestety fir­ma­mi zarzą­dza­ją ich Zarządy a nie jakieś tam ERP.

Pojawia się poję­cie zamknię­te sys­te­my” oraz mody­fi­ko­wal­ność”. Tu tkwi naj­więk­sza pułap­ka! Firmy MSP to fir­my, któ­re na ryn­ku sta­no­wią pew­ną masę”, jest ich bar­dzo dużo i ofe­ru­ją bar­dzo zbli­żo­ne do sie­bie pro­duk­ty i usłu­gi (wyłą­cza­jąc pro­duk­ty niszo­we). Taka fir­ma kon­ku­ru­je głów­nie ceną czy­li budu­je zysk mini­ma­li­zu­jąc swo­je kosz­ty. W stra­te­gi takiej fir­my klu­czo­we są: jakość zarzą­dza­nia i spraw­ność orga­ni­za­cyj­na. Paradoks pole­ga na tym, że w małych pod­mio­tach gospo­dar­czych nor­mą jest to, że wie­le osób sku­pia na sobie wię­cej niż jed­ną rolę, np. sprze­daw­ca jest logi­sty­kiem i fak­tu­ru­je, dyrek­tor han­dlo­wy zarzą­dza sprze­da­żą ale nie raz tak­że całą ofer­tą produktową.

Rozbudowane sys­te­my ERP mają czę­sto wła­śnie wbu­do­wa­ne sztyw­ne refe­ren­cyj­ne pro­ce­sy biz­ne­so­we”, co wyma­ga wie­lu odręb­nych ról, a taki wymóg potra­fi taką nie­jed­ną mniej­szą fir­mę zabić. W fir­mach MSP znacz­nie lepiej spraw­dza­ją się sys­te­my mają­ce nawet roz­bu­do­wa­ne funk­cjo­nal­no­ści ale wła­śnie nie ogra­ni­czo­ne wbu­do­wa­ny­mi pro­ce­sa­mi”. W fir­mach, w któ­rych pro­ce­sy są w gło­wach” pra­cow­ni­ków o dość sze­ro­kich kom­pe­ten­cjach, nie spraw­dza­ją się kor­po­ra­cyj­ne sys­te­my”, tu potrzeb­na boga­ta skrzyn­ka narzę­dzio­wa” ze swo­bo­dą wybo­ru narzę­dzi pracy.

Pokusa wdro­że­nia sys­te­mu połą­czo­ne­go z mody­fi­ko­wa­niem pod potrze­by klien­ta” ład­nie brzmi, ale nawet gdy­by się to uda­ło, to sys­tem taki usztyw­ni fir­mę, zabie­rze więc jej klu­czo­wą zale­tę: zwin­ność! Tak więc dla MSP owszem nawet duży sys­tem ERP ale z boga­tym menu i swo­bo­dą dostę­pu do niego.

Po dru­gie wiel­kie zin­te­gro­wa­ne zwie­rzę” będzie się wdra­ża­ło dłu­go bo jest wiel­kie. Znacznie bez­piecz­niej­szą dla MSP stra­te­gią jest wdra­ża­nie funk­cjo­nal­no­ści ERP eta­pa­mi, miesz­czą­cy­mi się w gra­ni­cach roku budże­to­we­go, nawet jeże­li mia­ło by to ozna­czać, że poszcze­gól­ne modu­ły będą pocho­dzi­ły od róż­nych dostaw­ców (pisa­łem o tym nie raz tu).

Nie ma moż­li­wo­ści łatwe­go udzie­le­nia odpo­wie­dzi na przy­to­czo­ne dwa pyta­nia na zada­wa­ne na kon­fe­ren­cjach bez zro­zu­mie­nia tego co tra­pi daną fir­mę. Jednak nasz kraj przo­du­je w sprze­da­ży leków bez recep­ty i mam wra­że­nie, że ana­lo­gicz­ne zja­wi­sko ma miej­sce na ryn­ku opro­gra­mo­wa­nia: po co nam jakaś ana­li­za czy audyt, idzie­my i kupu­je­my tego erpa” bo Goździkowa mówi”, że poma­ga a fir­ma sprze­da­ją­ca też obie­ca­ła, że pomoże.

W tym miej­scu jest pora na kolej­ny cytat z tego artykułu:

Nawet naj­lep­szy pro­dukt moż­na zepsuć złym wdro­że­niem. Odbiorcę usłu­gi nie inte­re­su­je, że klient tra­fił na nie­rze­tel­nych wdro­że­niow­ców, któ­rzy w sytu­acji kry­zy­so­wej roz­kła­da­ją bez­rad­nie ręce. Niestety naj­częst­szy­mi przy­czy­na­mi są źle prze­pro­wa­dzo­na ana­li­za przed­wdro­że­nio­wa i nie­ste­ty zbyt małe doświad­cze­nie part­ne­ra wdro­że­nio­we­go.

(Wdrożenie ERP – koszt czy zysk? | it​.nf​.pl).

Tak więc wdro­że­nie ERP zawsze jest kosz­tem, a czy tak­że zyskiem to już zale­ży od kupującego…

Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.

Niestety fir­my ofe­ru­ją­ce goto­we opro­gra­mo­wa­nie, poka­zu­ją jedy­nie menu, na któ­rym zoba­czy­my np. Cennik, ale bez wie­dzy jak wyglą­da wnę­trze, nie ma żad­nej moż­li­wo­ści oce­ny przy­dat­no­ści kon­kret­ne­go pro­gra­mu (nie licząc prób­nej eks­plo­ata­cji). To wyj­dzie naj­czę­ściej (jego wewnętrz­ny model i ogra­ni­cze­nia jakie powo­du­je) dopie­ro pod­czas wdro­że­nia, a to już za póź­no. Pojawia się tak zwa­na kasto­mi­za­cja jako zale­ce­nie w efek­tach ana­li­zy przed­wdro­że­nio­wej (wyko­na­nej dopie­ro po zawar­ciu umo­wy przez dostaw­ce pro­gra­mu czy­li już za póź­no!). Ale teraz to już po pro­stu tak zwa­na rzeź­nia. Przejście, w goto­wym opro­gra­mo­wa­niu, pomię­dzy opi­sa­ny­mi niżej mode­la­mi wyma­ga jego grun­tow­nej prze­rób­ki, lub nego­cja­cji: z któ­rych wyma­gań kupu­ją­cy zrezygnuje.

Przeciętny sys­tem ERP to naście setek funk­cjo­nal­no­ści, nie da się racjo­nal­nie (ale da się w ogó­le, widu­je takie spe­cy­fi­ka­cje) i nie ma sen­su two­rzyć takiej listy. Sposobem mini­ma­li­zu­ją­cym ryzy­ko złe­go wybo­ru jest dobra ana­li­za biz­ne­so­wa w celu wychwy­ce­nia tych obsza­rów fir­my, któ­re są jej spe­cy­fi­ką oraz opra­co­wa­nie dla tego obsza­ru mode­lu dzie­dzi­ny, a nie listy funk­cjo­nal­no­ści. Nowe funk­cjo­nal­no­ści spo­koj­nie moż­na dodać”, jest to łatwe, pod warun­kiem, że model dzie­dzi­ny sys­te­mu i jego imple­men­ta­cja jest wła­ści­wy”. W dru­gą stro­nę kom­plet­nie to nie działa. 

Bardzo czę­sto obser­wu­ję w pro­jek­tach pew­ne nie­do­mó­wie­nie”, pole­ga ono na nazy­wa­niu bytów” w opro­gra­mo­wa­niu tak jak coś rze­czy­wi­ste­go. W czym pro­blem? Po kolei, bo pro­blem, że tak powiem jest sze­rzej dostrzegany”:

The ?Real? World. The pro­blem with the ?real? world is that you are limi­ted by the laws of phy­sics. (za Don?t try to model the real world, it doesn?t exist. – Udi Dahan).

There are dif­fe­rent ope­ra­tions on the hard disk in dif­fe­rent spa­ces: in the phy­si­cal spa­ce, such as the motor rota­tion and the magne­tic head move­ment; in the com­pu­ta­tio­nal spa­ce, such as the data acces­sing; in the con­cep­tu­al spa­ce, such as the thin­king acti­vi­ties. There is a natu­re of the three spa­ces: each spa­ce has its own ope­ra­tions by its own mechanisms.

(za Some Basic Topics and Judgment of Ownership to the Three Spaces ? THINK IN MODELS ).

Udi Dahan suge­ru­je zasta­na­wia­nie się nad tym, jaki jest kon­tekst uży­cia, np. jeże­li szklan­ka jest pro­duk­tem to mode­lu­je­my ją przez pry­zmat tego, że to coś co ma nazwę, cenę itp., jako kon­tekst ogra­ni­cza­ją­cy wier­ność mode­lo­wa­nia wska­zu­je np. pra­wa fizy­ki. TY (autor blo­ga THINK IN MODELS) poszedł w stro­nę trzech prze­strze­ni (nazw): fizycz­na, poję­cio­wa (con­cep­tu­al) i apa­lik­cyj­na (com­pu­ta­tio­nal). Jak widać jest pro­blem w nazwa­niu (zro­zu­mie­niu) rela­cji pomię­dzy mode­lem poję­cio­wym a bytem w opro­gra­mo­wa­niu. Myślę, że zało­że­nie brzmią­ce, że model dzie­dzi­ny repre­zen­tu­je” świat rze­czy­wi­sty jest mylą­cy, jeże­li nie okre­śli­my kon­tek­stu i prag­ma­ty­ki. Pokażę to na innym przykładzie:

Celem jest opra­co­wa­nie mode­lu dzie­dzi­ny sys­te­mu, jest to ser­ce sys­te­mu (przy­po­mi­nam [[wzo­rzec MVC]]). Praca ręcz­na” to np. wpro­wa­dza­nie danych do kart maga­zy­no­wych. Mamy krze­sło oraz kar­to­te­kę pro­duk­tu zawie­ra­ją­cą wybra­ne cechy tego krze­sła: poza nazwą (krze­sło), zapew­ne będzie cena, kolor itp.

Teraz pora na ana­li­zę biz­ne­so­wą i mode­lo­wa­nie dzie­dzi­ny sys­te­mu. Tworzymy kla­sę Dane pro­duk­tu oraz Usługa (to enig­ma­tycz­na nazwa kla­sy ale…), któ­ra będzie wie­dzia­ła” co wol­no robić i jak, z kar­ta­mi produktów.

Klasa Dane pro­duk­tu jest reali­za­cją praw­dzi­wej kar­to­te­ki w sys­te­mie, kla­sa Usługa repre­zen­tu­je pew­ną umie­jęt­ność użyt­kow­ni­ka (zapew­ne jakieś żmud­ne obli­cze­nia i spraw­dze­nia, to ele­ment auto­ma­ty­za­cji, war­tość doda­na two­rzo­ne­go opro­gra­mo­wa­nia). Tak więc w mode­lu dzie­dzi­ny poja­wi się repre­zen­ta­cja kar­to­te­ki pro­duk­tu a nie pro­dukt! Komputer wspie­ra zarzą­dza­nie maga­zy­nem, ale nie zarzą­dza towa­ra­mi w nim, tyl­ko zastę­pu­je (uspraw­nia) ręcz­nie pro­wa­dzo­ne kartoteki.

W opi­sa­nej meto­dzie ana­li­za pole­ga na zro­zu­mie­niu tego co tak na praw­dę repre­zen­tu­je sobą pro­jek­to­wa­ne opro­gra­mo­wa­nie. Nie two­rzy­my więc kla­sy Produkt, bo pro­duk­tem tym jest krze­sło, któ­re jest i będzie real­nym krze­słem. Tworzymy kla­sę Dane pro­duk­tu, bo tak na praw­dę obiekt reali­zu­je (zastę­pu­je w apli­ka­cji) papie­ro­wą kar­tę, dane kon­kret­ne­go pro­duk­tu. Usługa to ta część pro­gra­mu, któ­ra wyko­na coś za użyt­kow­ni­ka (wyrę­czy go, wes­prze go).

Tą meto­dą ana­li­zy i mode­lo­wa­nia nie popa­da­my w pro­blem mode­lu poję­cio­we­go repre­zen­tu­ją­ce­go (tu) krze­sło, bo krze­sła nie odwzo­ru­je­my w kodzie, co naj­wy­żej coś co je repre­zen­tu­je w pew­nym kon­tek­ście (jego opis a może model 3D w pro­gra­mie CAD/CAM ale nie drew­nia­ne krzesło).

Tak więc nie Produkt a Opis pro­duk­tu, nie User a Dane użyt­kow­ni­ka, nie Pracownik a Dane pra­cow­ni­ka itp. A usłu­gi? Koniecznie Twórca kart pro­duk­tu, Zarządca kar­to­te­ki itp, bo kar­ta sama się nie utwo­rzy, jeże­li te kar­ty powsta­ją zgod­nie z jakimś sce­na­riu­szem (pro­ce­du­rą), to Usługa go nad­zo­ru­je, Wie jaki to sce­na­riusz i reali­zu­je go lub pomo­że w tym użyt­kow­ni­ko­wi programu.

Tyle o mode­lach, a teraz pole­cam stu­dio­wa­nie DDD ([[Domain Driven Design]]) …:) bo ana­li­za i mode­lo­wa­nie dzie­dzi­ny sys­te­mu to cięż­ka i trud­na pra­ca pole­ga­ją­ca na zro­zu­mie­niu i uchwy­ce­niu isto­ty rze­czy. Dlatego leży na mojej pół­ce, na bar­dzo eks­po­no­wa­nym miej­scu [[książ­ka Kazimierza Ajdukiewicza: Język i pozna­nie]]. Należy wła­ści­wie inter­pre­to­wać sło­wa (zna­cze­nia jakie niosą).

Jakie są prak­tycz­ne efek­ty takich prze­my­śleń? Poniżej pewien hipo­te­tycz­ny model manu­fak­tu­ry meblowej:

W tym przy­pad­ku: model krze­sła jako wzo­rzec jego kon­struk­cji agre­gat Krzesło skła­da­ją­cy się z czte­rech nóg, sie­dzi­ska i opar­cia (tu fak­tycz­nie mode­lu­je” krze­sło). W maga­zy­nie (Zarządca maga­zy­nu) mamy ele­men­ty skła­do­we kzre­seł (w rozu­mie­niu dane o tych czę­ściach w maga­zy­nie) i goto­we wyro­by. Do skła­da­nia ofert potrzeb­ny jest Cennik, tu potrzeb­ne są dane pro­duk­tu (a nie one same). Zarządzanie cen­ni­ka­mi korzy­sta z usług Zarządcy maga­zy­nu w celu pozy­ska­nia wie­dzy o dostęp­no­ści pro­duk­tów, ale nie koniecz­nie taki para­metr jak cena musi być u Magazyniera!

Ten model ope­ru­je poję­ciem egzem­pla­rza w maga­zy­nie (obiek­tów jest tyle ile egzem­pla­rzy w maga­zy­nie). Jest to kon­cep­cja może rza­dziej sto­so­wa­na w meblar­stwie, ale czę­sto np. w AGD (koniecz­ność ope­ro­wa­nia nume­rem seryj­nym egzem­pla­rza) do obsłu­gi gwarancji.

Inne roz­wią­za­nie:

Podstawowa róż­ni­ca to rezy­gna­cja z obsłu­gi egzem­pla­rzy na rzecz kar­to­tek pro­duk­tów. W tym przy­pad­ku mode­lu­je­my kar­tę z ilo­ścią rze­czy w maga­zy­nie (kar­ta taka jest jed­na dla każ­de­go produktu).

To tyl­ko pro­sty przy­kład, któ­ry obra­zu­je, że nie ist­nie­je coś takie­go jak refe­ren­cyj­ny model” dla każ­de­go (pra­wie każ­de­go). Specyfika pra­cy danej fir­my może się prze­nieść na pro­jekt. Co cie­ka­we, oba mode­le nie są wymien­ne (mimo bar­dzo podob­ne­go wyglą­du np. w doku­men­ta­cji). Jeżeli pierw­szy model (egzem­pla­rze) będzie­my pró­bo­wa­li wdra­żać w fir­mie posłu­gu­ją­cej się kar­to­te­ką będzie pro­blem, któ­rej kla­sy użyć jako kar­to­te­ki? Kosztowna kasto­mi­za­cja? Drugi model jest bez­u­ży­tecz­ny tam, gdzie wyma­ga­na jest wie­dza o egzem­pla­rzach (np. do celów reklamacji).

Na koniec dodam: imple­men­ta­cja tego sys­te­mu z uży­ciem bazy rela­cyj­nej SQL i znor­ma­li­zo­wa­nie jej znisz­czy ten model i ogra­ni­czy (o ile nie unie­moż­li­wi) jego przy­szły roz­wój lub zmia­ny . Tu są i mają być redun­dan­cje oraz brak trwa­łych połą­czeń (aso­cja­cje). Jedyne aso­cja­cje to kom­po­zy­cja. Związek pomię­dzy cen­ni­kiem a sta­nem w maga­zy­nie pole­ga wyłącz­nie na zapy­ta­niu” (rela­cja uży­cia w UML) Zarządcy maga­zy­ny ile ma krzeseł.

(Powyższe mode­le to poglą­do­we kon­struk­cje, nie nale­ży ich trak­to­wać jako kom­plet­ne pro­jek­ty. Gorąco pole­cam książ­kę: [[Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approa, Heinz Züllighoven, Morgan Kaufmann; 1 edi­tion, October 13, 2004]])

Po co to? Bo zły model to złe oprogramowanie.…

Duży sys­tem ERP to set­ki i tysią­ce jego przy­pad­ków uży­cia, nie ma sen­su ich spe­cy­fi­ko­wa­nie podob­nie jak nie ma sen­su pyta­nie o nie przy­szłych użyt­kow­ni­ków tego sys­te­mu bo nie są w sta­nie ich wyli­czyć. Ma jed­nak sens zro­zu­mie­nie tego jak fir­ma dzia­ła. Po raz kolej­ny posłu­żę się meta­fo­rą [[Martina Fowlera]]: grę w sno­oke­ra moż­na opi­sać rela­cjo­nu­jąc (zapi­su­jąc) set­ki kolej­nych par­tii, ale i tak nigdy nie wyspe­cy­fi­ku­je­my nawet ułam­ka moż­li­wych zagrań. Zdecydowanie lep­szą meto­dą jest przyj­rze­nie się kil­ku par­tiom i wychwy­ce­nie cech bili, ich ilo­ści, wymia­rów sto­łu oraz reguł gry, bo to będzie zgod­ne nie tyl­ko z histo­rią ode­gra­nych par­tii sno­oke­ra ale z każ­da przy­szłą partią.

Dlatego zamiast pro­wa­dze­nia żmud­nych wywia­dów i two­rze­nie nie­sku­tecz­nej listy setek szcze­gó­ło­wych opi­sów moż­li­we­go uży­cia opro­gra­mo­wa­nia, lepiej jest zro­zu­mieć orga­ni­za­cję, stwo­rzyć jej model (dzie­dzi­ny) i wyspe­cy­fi­ko­wać jakie usłu­gi ma to opro­gra­mo­wa­nie świad­czyć użyt­kow­ni­ków teraz (bo tak nale­ży rozu­mieć poję­cie przy­pad­ku uży­cia sys­te­mu). Poprawny model dzie­dzi­ny pozwo­li tak­że na obsłu­gę przy­szłych wyma­gań mimo, że nie zna­my ich teraz. Podobnie jak stół bilar­do­wy: nie zna przy­szłych ude­rzeń ale wie­my, że na pew­no zosta­ną obsłu­żo­ne”.

Na koniec nowy doda­tek, cytat z pew­ne­go bloga :):

Podstawową war­to­ścią biz­ne­so­wą jest nasza apli­ka­cja. To tutaj jest miej­sce na logi­kę biz­ne­so­wą i na umiesz­cze­nie wszyst­kie­go tego co chce­my aby apli­ka­cja robi­ła. To jak dostar­czy­my tą apli­ka­cję użyt­kow­ni­ko­wi jest spra­wą wtór­ną ? dostar­czy­my w sen­sie jak użyt­kow­nik będzie kon­su­mo­wał nasz pro­dukt. (Koncepcja ela­stycz­nej archi­tek­tu­ry | arek onli­ne | Arkadiusz Benedykt).