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”

Odsprzedaż sofware czyli czy można odzobaczyć to co się zobaczyło

Tym razem o logi­ce egze­kwo­wa­nia pra­wa autor­skie­go. W arty­ku­le o ana­li­zie sys­te­mo­wej obsza­ru praw autor­skich pre­zen­to­wa­łem mię­dzy inny­mi poniż­szy diagram:

Posłużę sie nim teraz, przy oka­zji ana­li­zy tego czym jest oprogramowanie. 

Materialną postać, gdzie war­tość ma egzem­plarz, ma dzie­ło takie jak np. rzeź­ba. Tu poję­cie repro­duk­cji (kopii ory­gi­na­łu) ma sens. Jednak opro­gra­mo­wa­nie, podob­nie jak muzy­ka, pro­za, poezja, foto­gra­fia, jest dzie­łem nie­ma­te­rial­nym. To, że jego egzem­pla­rze są mate­ria­li­zo­wa­ne” na nośni­ku ozna­cza jedy­nie to, że zosta­ło to dzie­ło utrwa­lo­ne. Czytaj dalej… Odsprzedaż sofwa­re czy­li czy moż­na odzo­ba­czyć to co się zoba­czy­ło”

Warsztaty analityczne – czyli malowanie trawy

W koń­czą­cym się roku trzy razy mia­łem do czy­nie­nia z nie mały­mi (czy­taj kosz­tow­ny­mi) doku­men­ta­mi zawie­ra­ją­cy­mi mode­le pro­ce­sów biz­ne­so­wych” i spe­cy­fi­ka­cję wyma­gań”. Wszystkie trzy mia­ły pew­ne wspól­ne cechy:

  1. były pro­ble­my z przy­dat­no­ścią tych doku­men­tów, co było powo­dem popro­sze­nia mnie o oce­nę i reko­men­da­cje w kwe­stii ich naprawy,
  2. wszyst­kie były pro­duk­tem zbio­ro­wych warsz­ta­tów pro­ce­so­wych” i warsz­ta­tów wyma­gań” z pra­cow­ni­ka­mi mode­lo­wa­nej firmy,
  3. żaden nie nada­wał się do uży­cia jako mate­riał do stwo­rze­nia opro­gra­mo­wa­nia, mimo, że wszyst­kie one były pro­duk­tem pierw­sze­go eta­pu pro­jek­tu o nazwie ana­li­za przed-wdrożeniowa”,
  4. wszyst­kie cier­pia­ły na pro­blem nad­mia­ru szcze­gó­łów, nie­jed­no­znacz­no­ści i bra­ku spójności.

Jedenaście lat temu (tak jede­na­ście!) napisałem:

Często fir­my ofe­ru­ją usłu­gę i pro­dukt Model (mapę) Procesów Biznesowych. Co dają? Dają nie­udol­nie zro­bio­ny opis pro­ce­dur, nie­słusz­nie nazwa­nych pro­ce­sa­mi. Setki sche­ma­tów obra­zu­ją­cych kto, co i jak robi. A po co to robi? Tego tam z regu­ły nie opi­sa­no! Dziesiątki i set­ki stron dia­gra­mów, któ­re lądu­ją na pół­ce i nie są uży­wa­ne pod­czas wdro­że­nia. Powstaje opra­co­wa­nie, któ­re jest nie­zro­zu­mia­łe przez zarząd fir­my zle­ca­ją­cej tę pra­cę. Zarząd nie przy­zna się, że nie rozu­mie bo podob­no to zna­na fir­ma dorad­cza lub wdro­że­nio­wa opra­co­wa­ła. A moim zda­niem, jeże­li Zarząd nie potra­fi zro­zu­mieć udo­ku­men­to­wa­ne­go obra­zu wła­snej fir­my to doku­ment jest do kitu a nie Zarząd. (Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

Dlaczego tak jest? Dlaczego tak bar­dzo popu­lar­ne są tego typu warsz­ta­ty a nie rze­tel­ne, dają­ce wyso­kiej jako­ści pro­duk­ty, analizy?

Obserwacja gry vs. reguły gry

To co się dzie­je na sto­le bilar­do­wym (meta­fo­ra z książ­ki M.Fowlera) moż­na opi­sać z pomo­cą praw fizy­ki i reguł gry w bilar­da. To co obser­wu­je­my na sza­chow­ni­cy (meta­fo­ra z blo­ga Paula Harmona) to wynik reguł gry, doświad­cze­nia i kla­sycz­nych zagry­wek. W obu przy­pad­kach docho­dzą też do gło­su wie­dza i umie­jęt­no­ści gra­czy. Piłka noż­na to regu­ły gry, pra­wa fizy­ki (tor pił­ki po kop­nię­ciu pił­ki) i umie­jęt­no­ści zawod­ni­ków. Można tu podać wie­le innych przy­kła­dów efek­tów łącz­ne­go ist­nie­nia okre­ślo­nych reguł oraz umie­jęt­no­ści ludzi.

Każda orga­ni­za­cja (fir­ma, urząd, inne) to ludzie z ich wie­dzą i umie­jęt­no­ścia­mi oraz regu­ły gry” czy­li obo­wią­zu­ją­ce Prawo i wewnętrz­ne regu­la­cje. I teraz poja­wia się pyta­nie: czym jest model orga­ni­za­cji? Przede wszyst­kim model to uprosz­cze­nie rze­czy­wi­sto­ści, jed­nak sto­pień tego uprosz­cze­nia nie jest przy­pad­ko­wy. To co uprasz­cza­my (pomi­ja­ne szcze­gó­ły) zale­ży od kon­tek­stu w jakim ten model będzie uży­ty, bo two­rze­nie mode­lu na jeden cel: uży­cie go w kon­kret­nym celu. Tu nie­ste­ty” wkra­cza nauka, mam na myśli podej­ście (meto­da nauko­wa w ana­li­zie).

Spójrzmy na to od koń­ca. Aby powsta­ło jakie­kol­wiek narzę­dzie wspo­ma­ga­ją­ce pra­cę np. ludzi wyko­nu­ją­cych swo­je obo­wiąz­ki w orga­ni­za­cji, narzę­dziem taki jest tak­że opro­gra­mo­wa­nie (czy­li apli­ka­cje), musi powstać opis tego narzę­dzia. Aplikacje to takie narzę­dzia, two­rzy­my je głów­nie z dwóch powo­dów: two­rzy­my elek­tro­nicz­ne wer­sje kar­to­tek (reje­strów) oraz two­rzy­my elek­tro­nicz­ne wer­sje okre­ślo­nych umie­jęt­no­ści (np. wyli­cza­nie pier­wiast­ków w kal­ku­la­to­rze). Tak więc aby zamó­wić u deve­lo­pe­ra Kartotekę musi ją opi­sać i to jest rela­tyw­nie pro­ste: two­rzy­my wzór Kartoteki, np. kar­to­te­ki pra­cow­ni­ka, książ­ki w biblio­te­ce itp. Nieco trud­niej jest opi­sać (udo­ku­men­to­wać) umie­jęt­ność, zresz­tą naj­pierw trze­ba ja jakoś zde­fi­nio­wać. Umiejętności, tu wyma­ga­ne, mogą być róż­ne: od umie­jęt­no­ści wery­fi­ka­cji danych wpro­wa­dza­nych do kar­to­tek aż do umie­jęt­no­ści wytwa­rza­nia nowych infor­ma­cji na bazie tych dostęp­nych w kar­to­te­kach. Np. utwo­rze­nie fak­tu­ry sprze­da­ży wyma­ga sko­rzy­sta­nia z kar­to­te­ki klien­tów, z kar­to­te­ki ofe­ro­wa­nych towa­rów i usług, kar­to­te­ki towa­rów dostęp­nych w maga­zy­nie, trze­ba tak­że posia­dać umie­jęt­ność popraw­ne­go wyli­cze­nia war­to­ści podat­ków na for­mu­la­rzu fak­tu­ry, mogą do tego dojść upu­sty zależ­ne od wie­lu czyn­ni­ków: war­to­ści zaku­pu, aktu­al­nych pro­mo­cji, sta­tus kupu­ją­ce­go i wie­le innych. Inny przy­kład: zare­je­stro­wa­nie nowe­go doku­men­tu w archi­wum wyma­ga sko­rzy­sta­nia z kar­to­te­ki doku­men­tów oraz umie­jęt­no­ści nada­nia doku­men­to­wi spe­cjal­ne­go zna­ku, sygnatury.

workshopI tu wpa­da­my w efekt krę­ce­nia fil­mu”. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­je pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elektronicznym!).

Dokumenty, któ­re dosta­ję do recen­zji, to czę­sto wła­śnie zapi­sy, wręcz ste­no­gra­my z takich spo­tkań, i nie ma zna­cze­nia czy to zapi­sy pro­zą” czy zapi­sy w posta­ci obraz­ko­wej z uży­ciem nota­cji BPMN czy UML (gdzie nota­cja jest wyko­rzy­sty­wa­na raczej jako biblio­te­ka sym­bo­li a nie narzę­dzie z jego syn­tak­ty­ką i seman­ty­ką). To doku­men­ty, któ­re sta­no­wią rodzaj ste­no­gra­mu z roz­mów, są jak fil­my nakrę­co­ne pod­czas roz­gry­wa­nia par­tii sza­chów lub bilar­da: miłe w oglą­da­niu, dłu­gie, kosz­tow­ne i kom­plet­nie nie­przy­dat­ne do napi­sa­nia kom­pu­te­ro­wej gry.

Do opi­sa­nia każ­dej z tych gier, a tak­że do opi­sa­nia tego jak funk­cjo­nu­je orga­ni­za­cja, wystar­czy doku­ment opi­su­ją­cy zasa­dy gry (regu­ły biz­ne­so­we) oraz mini­mal­ną wie­dzę i umie­jęt­no­ści gra­czy oraz to jakie i w jakiej kolej­no­ści rze­czy maja powstać czy­li model pro­ce­sów biz­ne­so­wych. Model pro­ce­sów jed­nak to nie jest film” opi­su­ją­cy czy­jąś pra­cę a logicz­ny łań­cuch aktyw­no­ści two­rzą­cych, każ­da, przy­dat­ny biz­ne­so­wi produkt.

Jaki opis powsta­nie po prze­pro­wa­dze­niu kil­ku dni warsz­ta­tów z gra­cza­mi, któ­rzy gra­ją od lat, zasa­dy gry zna­ją na pamięć, bywa ze podej­mu­ją pró­by łama­nia zasad dla osią­gnię­cia doraź­nych efek­tów? To będą dłu­gie, nie raz nie­spój­ne wywo­dy. Każdą z wymie­nio­nych gier opi­su­ją jed­nak jed­no­znacz­nie dwa bar­dzo krót­kie doku­men­ty: regu­ły gry oraz mini­mal­ne umie­jęt­no­ści i wie­dza każ­de­go z gra­czy. Z takim doku­men­tem każ­dy pro­jek­tant opro­gra­mo­wa­nia sobie pora­dzi bez problemu.

Niestety wie­le pro­duk­tów eta­pu pro­jek­tu o nazwie ana­li­za przed-wdro­że­nio­wa to tak zwa­ne malo­wa­nie tra­wy: kawał kosz­tow­nej i niko­mu nie przy­dat­nej pra­cy. Jakiś temu pisa­łem z innej okazji:

Niestety, pod­czas tak zwa­nych typo­wych ana­liz, opar­tych na wywia­dach i spo­tka­niach warsz­ta­to­wych, im wię­cej inte­rak­cji tym więk­sze pole do mani­pu­la­cji i per­swa­zji (świa­do­mej lub nie, ale jed­nak). Po dru­gie, nie ma żad­nej gwa­ran­cji, że nicze­go nie pomi­nię­to (w takich roz­mo­wach w zasa­dzie oma­wia­ne są rze­czy cie­ka­we i rzad­kie a pra­wie nigdy oczywiste). […]

Drugim pro­ble­mem i poważ­nym błę­dem jest uzna­nie, że ?sko­ro te ana­li­zy to spo­tka­nia i zapi­sy­wa­nie ich wyni­ków, to może to robić nie­mal­że każ­dy byle był komu­ni­ka­tyw­ny?. Bzdura. Po pierw­sze takie dzia­ła­nie to nie są ana­li­zy a ste­no­gra­my ze spo­tkań, po dru­gie są one zapi­sem subiek­tyw­ne­go oglą­du sytu­acji, jaki mają odpy­ty­wa­ni pra­cow­ni­cy danej fir­my (do tego z ich tyl­ko per­spek­ty­wy). (Nowoczesne tech­no­lo­gie w służ­bie zdro­wia, czy­li tele­me­dy­cy­na w pro­jek­tach IT).

Dlatego rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych partii.

klientsobiezyczyBardzo czę­sto sły­szę od deve­lo­pe­rów, ze więk­szość doku­men­tów jakie dosta­ją jest nie­przy­dat­na. Nie raz zasta­na­wiam się, dla­cze­go mimo to więk­szość usłu­go­daw­ców two­rzy tak nie­przy­dat­ne doku­men­ty? Najprawdopodobniej dla­te­go, że słu­cha­nie i ste­no­gra­fo­wa­nie jest łatwe… Z dru­giej stro­ny, nie raz nie­ste­ty sami zama­wia­ją­cy chcą takich wła­śnie doku­men­tów, Ci jed­nak są uspra­wie­dli­wie­ni, bo to nie oni są ana­li­ty­ka­mi. Ci ostat­ni sami decy­du­ją jaki­mi ana­li­ty­ka­mi są…

Drugim powo­dem jest dość powszech­ny brak umie­jęt­no­ści abs­trak­cyj­ne­go myśle­nia. Problem ten widać czę­sto na eta­pie mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: zamu­la­nie zbęd­ny­mi szcze­gó­ła­mi. Bardzo wie­lu ana­li­ty­ków ma skłon­no­ści do wgłę­bia­nia się w nie­istot­ne szcze­gó­ły, to wła­śnie objaw bra­ku umie­jęt­no­ści two­rze­nia abs­trak­cji. Do tego stop­nia, że powstał pomysł na sfor­ma­li­zo­wa­nie zaj­mo­wa­nie się tymi szcze­gó­ła­mi (Case Management). Ciekawa dys­ku­sja na ten temat poja­wi­ła się na LinkedIn. Ja ze swej stro­ny pole­cam arty­kuł (Case Managemet) oraz wypo­wie­dzi Paula Harmona w dyskusji:

At the pro­cess level, we want the abi­li­ty to descri­be and orga­ni­ze a gene­ric set of acti­vi­ties. We might be con­cer­ned, for exam­ple, with how we orga­ni­ze Hotel Guest Services. To be cle­ar what we mean by orga­ni­zing Hotel Guest Services, we might talk abo­ut a spe­ci­fic instan­ce in which a hotel orga­ni­zed guest servi­ces. One of the things we might deci­de, for exam­ple, was that the hotel wan­ted eve­ry­one to use the guest’s name. Thus, we might think of all of the acti­vi­ties in which employ­ees might inte­ract, and pon­der how we would pro­vi­de each set of employ­ees with each guest’s name. It obvio­usly would­n’t be a mat­ter of sim­ply noti­fy­ing one gro­up – like tho­se who take restau­rant rese­rva­tions of who is in what room – sin­ce, as Roger sug­ge­sts, a hotel guest could pro­ce­ed in any order, going to the pool, or to a con­fe­ren­ce ses­sion, or pro­ce­eding to make a restau­rant rese­rva­tion. In this case we are pro­ba­bly tal­king abo­ut put­ting infor­ma­tion into a data­ba­se from which vario­us employ­ees could easi­ly retrie­ve it. Processes are dyna­mic and com­plex, in part, becau­se the gene­ric pro­cess descrip­tion isn’t as pre­scrip­ti­ve as it would be in a pro­duc­tion line, whe­re the sta­tions are set and the beha­viors expec­ted at each sta­tion are well defi­ned. They are cases” becau­se each instan­ce of the pro­cess uses a dif­fe­rent set of acti­vi­ties in a dif­fe­rent order – as in the Rescue Hostage exam­ple. When we plan for a Rescue Hostage case or pro­ject if you pre­fer, we deve­lop a series of sce­na­rios, and prac­ti­ce a lar­ge set of acti­vi­ties. When the time comes to exe­cu­te the pro­cess, we begin by plan­ning for the spe­ci­fic instan­ce case. The idea that we start the pro­cess with a gene­ric: Plan for the Specific Rescue Effort, acti­vi­ty may be gene­ric, but any deta­iled exam­ple of it will be an instan­ce, sin­ce in the very natu­re of the plan­ning we are tailo­ring to the spe­ci­fic instan­ce. (Case Management Approaches | LinkedIn).

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.

Czego najbardziej brakuje systemom klasy ERP?

Przypomnę na począ­tek co pra­wie dwa lata temu napisałem:

Tak więc: jak dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża).

software

Tak więc jed­nak pole­cam: zasta­no­wić się nad potrze­ba­mi, zamó­wić wyko­na­nie ana­li­zy i doku­men­ta­cji wyma­gań i z tym doku­men­tem szu­kać dostaw­cy i nie dać wci­snąć sobie teo­rii, że duży może wię­cej?. Możliwe ale nie zapo­mi­naj­my, że duży to tak­że bez­wład­ny (pole­cam cały arty­kuł: Nigdy wię­cej ERP w jed­nym kawał­ku!)

No i mamy obecnie:

Przedstawiciele co trze­ciej bry­tyj­skiej fir­my (35 proc.) przy­zna­ją, że byli­by skłon­ni zastą­pić wyko­rzy­sty­wa­ny obec­nie sys­tem kla­sy ERP bar­dziej ela­stycz­nym roz­wią­za­niem o podob­nej funk­cjo­nal­no­ści. (źr. Czego naj­bar­dziej bra­ku­je sys­te­mom kla­sy ERP?)

Nasuwa się pyta­nie: czym je zastą­pić? Leży wła­śnie na moim sto­le książ­ka ([[Large-Scale Software Architecture. A prac­ti­cal guide using UML. Jeff Garland, Richard Anthony]]). I co my tu mamy? Przede wszyst­kim opi­nię i wska­zów­ki doświad­czo­nych pro­jek­tan­tów i developerów.

Książka jest tak dobra”, że w zasa­dzie moż­na ją w kawał­kach zacy­to­wać od dechy do dechy. Jednak i nie chce i nie moż­na tego robić :). W czym rzecz?

Duże oprogramowanie to nie jeden system

I tu leży pies pogrze­ba­ny. Kolejność zale­ca­na przez auto­rów książ­ki za każ­dym razem, nie­za­leż­nie od wiel­ko­ści projektu:

  1. ana­li­za i okre­śle­nie celu projektu
  2. ana­li­za biz­ne­so­wa, opra­co­wa­nie wymagań
  3. pro­jekt archi­tek­tu­ry roz­wią­za­nia (ogól­ny model dzie­dzi­no­wy), podział na kom­po­nen­ty (obsza­ry dziedzinowe)
  4. okre­sle­nie, któ­re kom­po­nen­ty (pod­sys­te­my) nale­ży wytwo­rzyć, a któ­re moż­na kupić na ryn­ku (tak zwa­ne COTS, ang. [[Commercial off-the-shelf]])
  5. spraw­dze­nie dostęp­no­ści i kosztów
  6. opra­co­wa­nie wyni­ko­we­go pro­jek­tu i wyma­gań na pod­sys­te­my dedykowane.

Praktyka poka­zu­je, że jed­nym z takich dużych COTS może być (i czę­sto jest) sys­tem ERP (jego wybra­na część). Najczęściej modu­ły pro­duk­cji, księ­gi głów­nej, kadro­we itp. Jednak zarzą­dza­nie sprze­da­żą czy spe­cy­fi­ka pro­ce­sów wewnątrz orga­ni­za­cji to coś co spę­dza sen z powiek dostaw­ców ERP bo to zawsze nie pasu­je”. Największym zaś, w moich oczach, nad­uży­ciem ofert na ERP jest twier­dze­nie, że wspo­ma­ga­ją zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi. Bo jeśli poma­ga­ją zarzą­dzać doku­men­ta­mi, co jest praw­dą, to raczej nie są w sta­nie kon­ku­ro­wać z sys­te­ma­mi work-flow bo to zupeł­nie inne­go rodza­ju sys­te­my i nie przy­pad­kiem powsta­ły jako oddziel­ne roz­wią­za­nia. Do tego doku­men­ty finan­so­wo-maga­zy­no­we to mniej­sza część wszyst­kich doku­men­tów w fir­mie, więc dla­cze­go ERP miał by być tu dobry”? A hur­tow­nie danych? To tak­że nie przy­pa­dek, że są osob­ny­mi sys­te­ma­mi. Dostawcy ERP per­ma­nent­nie uży­wa­ją akro­ni­mu Moduł BI w swo­ich ofer­tach zaś cicha­czem ofe­ru­ją dedy­ko­wa­ne sys­te­my BI i inte­gru­ją je.

Tak więc naj­czę­ściej oka­zu­je się, że nie­ste­ty głów­ną wadą sys­te­mów zin­te­gro­wa­nych ERP jest to, że są zin­te­gro­wa­ne (czy­taj nie­po­dziel­ne) co już nie raz tu pisa­łem i wycho­dzi, że nie ja jeden.

W ubie­głym roku skoń­czy­łem pro­jekt dla fir­my [[Galeco Sp. z o.o.]]. W dużym uprosz­cze­niu pro­jekt wyglą­dał tak:

  1. Analiza biz­ne­so­wa: model biz­ne­so­wy, opty­ma­li­za­cja pro­ce­sów, okre­śle­nie klu­czo­wych czyn­ni­ków sukcesu,
  2. Określenie wyma­gań na opro­gra­mo­wa­nia w kon­tek­ście klu­czo­wych czyn­ni­ków sukcesu.
  3. Opracowanie archi­tek­tu­ry sys­te­mu infor­ma­cyj­ne­go Galeco.
  4. Wskazanie miejsc, w któ­rych moż­na użyć goto­we­go oprogramowania
  5. Zaprojektowanie wyma­gań na opro­gra­mo­wa­nie (pod­sys­te­my itp.), któ­re są potrzeb­ne Galeco a nie są dostęp­ne jako goto­we na rynku.

I ta wła­snie kolej­ność jest lep­sza. Pozornie to samo osią­gnie­my gdy wpu­ści­my dostaw­cę sys­te­mu ERP i on po ana­li­zie powie cze­go (jakich wyma­gań) jego sys­tem nie reali­zu­je. Jednak:

  1. Dostawca goto­we­go sys­te­mu nie ma żad­nej moty­wa­cji (wręcz prze­ciw­nie) do wska­zy­wa­nia innych niż swo­je roz­wią­zań (stąd per­ma­nent­nie poja­wia­ją się w ofer­tach i pro­jek­tach tak zwa­ne kasto­mi­za­cje, któ­re są powszech­nie ofe­ro­wa­ne przez sprze­daw­ców a odra­dza­ne przez pro­du­cen­tów tego opro­gra­mo­wa­nia ERP).
  2. U dostaw­cy ERP natych­miast poja­wia się syn­drom młot­ko­we­go: jak ktoś ma w ręku mło­tek natych­miast wszyst­ko co zoba­czy koja­rzy mu się z gwoździem.

Wystarczy odwró­cić kolej­ność dzia­łań: zamiast wybie­rać dostaw­cę ERP, któ­ry powie na czym wymię­ka jego sys­tem, war­to naj­pierw zapro­jek­to­wać całość a potem popy­tać kto i w czym czu­je się świet­nie. Tu jed­nak poja­wia się pro­blem: dostaw­ca goto­we­go sys­te­mu nie zaro­bi na kasto­mi­za­cji ale chy­ba o to cho­dzi by było od razu dobre a nie w nie­skoń­czo­ność dostosowywane.

Dlaczego pro­du­cen­ci odra­dza­ją (meto­dy­ki zale­ca­ne przez pro­du­cen­tów nie sto­so­wa­ne w Polsce!) inge­ren­cje w ich goto­we opro­gra­mo­wa­nie? Bo taka inge­ren­cja odci­na natych­miast użyt­kow­ni­ka od moż­li­wo­ści wyko­na­nia pro­ste­go upgra­de­’u! Kolejna, nowa wer­sja sys­te­mu wdro­żo­ne­go z tak dużym tru­dem (i kosz­tem) kasto­mi­za­cji wyma­ga kom­plet­ne­go pro­jek­tu od zera, powtó­rze­nia od począt­ku całej pier­wot­nej pra­cy nad wdrożeniem.

Jak tego unik­nąć? To pro­ste, posłu­chać pro­du­cen­tów opro­gra­mo­waw­szy ERP:

  1. Opracować wła­sne wymagania.
  2. Dać dostaw­com sys­te­mów ERP by wyko­na­li tak zwa­ną ana­li­zę gap/fit (co nasz sys­tem ma a cze­go nie ma).
  3. Wybrać naj­ko­rzyst­niej­szą ofer­tę, wdro­żyć sys­tem szyb­ko (bo bez kastomizacji).
  4. Zaprojektować bra­ku­ją­ce funk­cjo­nal­no­ści i zamó­wić ich imple­men­ta­cję, zin­te­gro­wać z dostar­czo­nym ERP.

Teraz upgra­de ERP to pro­ste wgra­nie nowej wer­sji (no pra­wie ale o nie­bo łatwiej i taniej!) Po dru­gie nie nara­ża­my się na pre­sję dostaw­cy ERP i nie uza­leż­nia­my od nie­go w 100% (zja­wi­sko okre­śla­ne jako «ven­dor lock-in». Tak zapro­jek­to­wa­ny sys­tem sta­je się sys­te­mem otwar­tym, pozwa­la­ją­cym wymie­nić lub dodać funk­cjo­nal­no­ści bez inge­ren­cji w pozo­sta­łe. I nie­za­leż­nie od tego jak uni­wer­sal­ny” jest sys­tem ERP zawsze będzie gor­szy od kil­ku dobrze dobra­nych ale nie­za­leż­nych kom­po­nen­tów. Gorszy nie dla­te­go, że brzyd­szy” ale dla­te­go, że będzie kulą u nogi fir­my, któ­ra powin­na jed­nak reago­wać na zmia­ny na ryn­ku w cią­gu tygo­dni a nie lat… Po dru­gie mody­fi­ka­cja jakie­go­kol­wiek opro­gra­mo­wa­nia zawsze wyma­ga testo­wa­nia cało­ści, tak więc im mniej­sze kawał­ki mamy tym szyb­ciej i taniej wpro­wa­dza się do nich zmia­ny bo ich odda­nie do użyt­ku po mody­fi­ka­cji jest łatwiej­sze i szyb­sze zarazem.

Pamiętajmy pew­ną sta­rą rekla­mę: Banki od wszyst­kie­go są do niczego”.…

Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. model dziedziny

Przyszła w koń­cu pora na model dzie­dzi­ny sys­te­mu i model sekwen­cji dla przy­pad­ków uży­cia. Wspomnę tak­że o wyma­ga­niach nie­funk­cjo­nal­nych? W poprzed­nim arty­ku­le: Diagram klas ? czy­li ?rein­ży­nie­ria? ana­li­zy biz­ne­so­wej c.d. Przypadki uży­cia i gra­ni­ce sys­te­mu opi­sa­łem pro­ces do powsta­nia opi­su przy­pad­ków uży­cia. Mamy za sobą pod­sta­wo­wą pra­cę z dzie­dzi­ny jaką jest [[ana­li­za sys­te­mo­wa]]. Postawiliśmy pro­blem do roz­wią­za­nia: jakie opro­gra­mo­wa­nie powin­no powstać. Pod poję­ciem jakie nale­ży rozu­mieć: co powin­no ono robić. Opracowano model, prze­te­sto­wa­no go. Oceniono dwa warian­ty (w dużym skró­cie ;)), w dru­gim warian­cie obsłu­ga płat­no­ści zosta­ła zle­co­na part­ne­ro­wi ([[out­so­ur­cing]]) i pod­ję­to racjo­nal­ną decy­zje o wybo­rze tego wariantu.

Po tej decy­zji mamy zamknię­ty zakres wyma­gań: sys­tem ma reje­stro­wać zamó­wie­nia i pozwa­lać na natych­mia­sto­we doko­na­nie płat­no­ści. Wiemy tak­że, że nasz sys­tem jest czę­ścią więk­szej cało­ści. Outsourcing to decy­zja hipo­te­tycz­ne­go spon­so­ra pro­jek­tu na bazie otrzy­ma­nych infor­ma­cji. Koniec ana­li­zy biznesowej.

Pora iść dalej. Tym razem pro­blem brzmi: kto i w jakiej tech­no­lo­gii ma wyko­nać to opro­gra­mo­wa­nie. Znowu przy­da­ły by się warian­ty czy­li róż­ne ofer­ty wyko­na­nia tego opro­gra­mo­wa­nia. Czego nam bra­ku­je by ofer­ty były porów­ny­wal­ne? Modelu tego co nale­ży wyko­nać! Czy moż­na jako ele­ment takie­go zapy­ta­nia dać model przy­pad­ków uży­cia? Z jed­nej stro­ny moż­na powie­dzieć, że owszem. W koń­cu mamy dokład­ny opis tego, jaki­mi cecha­mi (funk­cjo­nal­no­ści) ma się cha­rak­te­ry­zo­wać to co otrzy­ma­my. I robi tak więk­szość firm. Gdzie widzę kło­pot? Zapewne część czy­tel­ni­ków zauwa­ży­ła już, że pomi­ną­łem wyma­ga­nia poza-funkcjonalne.

Dygresja budowlana – pouczająca przygoda

Wyobraźmy sobie, że chce­my zle­cić budo­wę domu. Jego funk­cjo­nal­no­ści to mię­dzy inny­mi: oddziel­ne miej­sca do spa­nia oraz czy­ta­nia i oglą­da­nia tele­wi­zji (tak zwa­ny salon). Kuchnia złą­czo­na z salo­nem. Łazienka na każ­dym pię­trze. Wejście z zewnątrz do salo­nu poprzez mały przed­po­kój. Garaż połą­czo­ny z przed­po­ko­jem. I jesz­cze wie­le innych. Wymagania poza-funk­cjo­nal­ne, tych może być ogrom! Dom ma być ład­ny, nie może być podob­ny do domu sąsia­da, musi speł­niać wyma­ga­nia pra­wa budow­la­ne­go, kolo­ry­sty­ka dachu powin­na być sko­re­lo­wa­na z ele­wa­cją, bie­żą­ce kosz­ty ogrze­wa­nia powin­ny być moż­li­wie jak naj­niż­sze, dom powi­nien dać się w przy­szło­ści łatwo roz­bu­do­wać o dwa nowe pomiesz­cze­nia. Dom powi­nien być przy­go­to­wa­ny do poten­cjal­nej insta­la­cji kom­pu­te­ra w każ­dym poko­ju. Powinno być moż­li­we zain­sta­lo­wa­nie kli­ma­ty­za­cji w cią­gu trzech lat od zakoń­cze­nia inwestycji.

Taki doku­ment może mieć dzie­siąt­ki stron, wery­fi­ka­cja jego tre­ści (spój­ność, tech­nicz­na nie­sprzecz­ność, inne) może być trud­na. Opracowanie go w gro­nie np. czte­ro­oso­bo­wej rodzi­ny będzie wyzwa­niem już tyl­ko w kate­go­riach nego­cja­cji ;). Żeby zabez­pie­czyć się przed inter­pre­ta­cją” wyko­naw­cy doku­ment będzie obra­stał w szcze­gó­ły, ale takie o któ­rych pomy­ślą auto­rzy doku­men­tu: rodzi­na. Jakie mają w tym doświad­cze­nie? Większość tych ocze­ki­wań to wła­snie poza funk­cjo­nal­ne życzenia!.

Jak unik­nąć tej bene­dyk­tyń­skiej pra­cy, któ­rej ryzy­ko rośnie wraz z roz­ro­stem doku­men­tu? Idziemy do archi­tek­ta. Nasza rodzi­na idzie do archi­tek­ta, ten na bazie powyż­szych opo­wie­ści dopro­wa­dza do jakiejś kon­cep­cji roz­wią­za­nia (pro­jekt wstęp­ny, kon­cep­cyj­ny). W momen­tach spo­ru peł­ni role media­to­ra (łazien­ka ma być przy salo­nie czy przy poko­ju dzie­ci), poka­zu­je na mode­lu (pro­jekt kon­cep­cyj­ny, któ­ry ewo­lu­uje w trak­cie takiej roz­mo­wy) wady i zale­ty obu roz­wią­zań, pozwa­la rodzi­nie pod­jąć świa­do­mą decy­zje. Zaletą wizy­ty u archi­tek­ta, zanim zapy­ta­my jakie­go­kol­wiek deve­lo­pe­ra, jest to, że archi­tekt jest wol­ny od jakich­kol­wiek uprze­dzeń czy przy­zwy­cza­jeń. W każ­dej dzie­dzi­nie inży­nie­rii wyko­naw­cy są wyspe­cja­li­zo­wa­ni, jeśli damy im wybór, będą sto­so­wa­li tech­no­lo­gie naj­mniej ryzy­kow­ne dla sie­bie (naj­le­piej pozna­ne) a nie opty­mal­ne dla inwe­sto­ra i to jest oczy­wi­ste.

Dlatego war­to naj­pierw iść do archi­tek­ta, ten nie­ska­żo­ny tech­no­lo­gia­mi (bo nie ma w tym żad­ne­go inte­re­su), opra­cu­je nam pro­jekt funk­cjo­nal­ny, ale zawie­ra­ją­cy pew­ne szcze­gó­ły roz­wią­zań (np. zabro­ni budo­wy beto­no­wej ścia­ny w miej­scu gdzie my ocze­ku­je­my przy­szłej roz­bu­do­wy). Popatrzymy na coś, co potra­fi­my szyb­ko oce­nić nie tyl­ko od stro­ny wyma­gań funk­cjo­nal­nych (musz­la pod pół­ką speł­nia sta­wia­ne jej wyma­ga­nia ale czy jest to wygod­ne?) Na pro­jek­cie od razu wychwy­ci­my, cze­go w tek­ście opi­su raczej nigdy: ele­men­ty este­ty­ki, wygo­dy, pod­ję­te kom­pro­mi­sy będą dla wszyst­kich zro­zu­mia­łe i nie będą w przy­szło­ści podważane.

Diagram klas czy model dziedziny – co ma powstać?

(pro­gra­mi­ści mogą to pominąć)

Otóż [[dia­gram klas]] ([[UML]]) to narzę­dzie podob­ne do rysun­ku tech­nicz­ne­go. Ważne jest to co on przed­sta­wia i to nale­ży naj­pierw zde­fi­nio­wać (dopó­ki nie wiem czy mam napi­sać: książ­kę czy roz­dział pod­ręcz­ni­ka, nie wiem co mam w tym języ­ku wyra­zić). Tak więc coś nale­ży zało­żyć. Podstawowym zało­że­niem jakie tu przyj­mę jest: nie two­rzy­my opro­gra­mo­wa­nia od zera. A wiec od cze­go? Wiele firm pro­gra­mi­stycz­nych uży­wa goto­wych szkie­le­tów opro­gra­mo­wa­nia, tak zwa­nych [[framework]]ów. Są to goto­we, naj­czę­ściej dzie­dzi­no­we (adre­so­wa­ne dla kon­kret­nej dzie­dzi­ny zasto­so­wań) biblio­te­ki pod­pro­gra­mów (klas w tech­no­lo­giach obiektowych).

Obejmują zazwy­czaj typowe,uniwersalne funk­cjo­nal­no­ści takie jak logo­wa­nie, wyświe­tla­nie tre­ści na ekra­nie, zapis do bazy danych (a tak na praw­dę utrwa­la­nie, bo baza danych to nie jedy­ny spo­sób) , ste­ro­wa­nie zacho­wa­niem się apli­ka­cji, ele­men­ty bez­pie­czeń­stwa i wie­le innych. Funkcjonalności więk­szo­ści biz­ne­so­wych apli­ka­cji moż­na podzie­lić na trzy gru­py: ste­ro­wa­nie pro­gra­mem, obsłu­ga inter­fej­su użyt­kow­ni­ka oraz funk­cjo­nal­no­ści spe­cy­ficz­ne dla dzie­dzi­ny (miej­sca) zasto­so­wa­nia. Mamy więc dzie­dzi­nę pro­ble­mu, inter­fejs użyt­kow­ni­ka i ste­ro­wa­nie cało­ścią. Innymi sło­wy mamy: Model, View (wido­ki), Controller (ste­ro­wa­nie) czy­li naj­po­pu­lar­niej­szy obiek­to­wy wzo­rzec pro­jek­to­wy apli­ka­cji o wdzięcz­nej nazwie [[MVC]].

Wniosek z tego taki, że jeśli zało­ży­my, że taki szkie­let zosta­nie uży­ty (a może­my to zapi­sać w wyma­ga­niach poza-funk­cjo­nal­nych dla wyko­naw­cy) to pozo­sta­je po zakoń­czo­nej ana­li­zie biz­ne­so­wej doko­nać ana­li­zy obiek­to­wej i zapro­jek­to­wać [[model dzie­dzi­ny sys­te­mu]]. Narzędziem do jego poka­za­nia jest wła­śnie dia­gram klas nota­cji UML.

Model dziedziny systemu Zamówienia

Tak więc wszyst­ko jasne 🙂 wiec do robo­ty. Pierwszy etap to opra­co­wa­nie listy obiek­tów biz­ne­so­wych. Tu wkra­cza kolej­na meto­da, któ­ra sto­su­ję: obiek­ty dzie­li­my na narzę­dzia i przed­mio­ty prze­twa­rza­ne z pomo­cą tych narzę­dzi, pamię­ta­my, że tego wszyst­kie­go ktoś uży­wa: nasz aktor. Prosty przy­kład: Do wysta­wie­nia fak­tu­ry potrzeb­ne są: for­mu­larz fak­tu­ry (oczy­wi­ste) i fak­tu­rzy­sta (ktoś musi wie­dzieć co nale­ży zro­bić). Pierwszy sto­pień inno­wa­cji: kal­ku­la­tor dla fak­tu­rzy­sty. Kolejny sto­pień to elek­tro­nicz­ny for­mu­larz. Obiekty biz­ne­so­we: wzór for­mu­la­rza fak­tu­ry, kal­ku­la­tor, fak­tu­rzy­sta oraz oczy­wi­ście kuwet­ka na wysta­wio­ne fak­tu­ry. Dlaczego tak?

Kolejna meto­da ana­li­zy i pro­jek­to­wa­nia powią­za­na z wzor­cem MVC: [[Domain Driven Design]] (pro­jek­to­wa­nie opro­gra­mo­wa­nia bazu­ją­ce na mode­lu dzie­dzi­ny sys­te­mu) czy­li DDD. O co tu cho­dzi? Ogólnie o to by pro­jek­to­wać opro­gra­mo­wa­nie dość wier­nie symu­lu­jąc (a raczej odwzo­ro­wu­jąc) pozna­ną rze­czy­wi­stość. Dlaczego? Bo osią­ga­my bar­dzo waż­ną korzyść: nawet jeże­li nie uda nam się odkryć sen­su ist­nie­nia jakie­goś obiek­tu, mimo wszyst­ko mode­lu­je­my go bez uprosz­czeń, dzię­ki temu w przy­szło­ści, roz­wi­ja­jąc sys­tem, nie nadzie­je­my się na pro­blem wywo­ła­ny takim uprosz­cze­niem gdyż takie począt­ko­we uprosz­cze­nie sta­je się nie raz poważ­nym ogra­ni­cze­niem. Druga zale­ta: model taki jest rela­tyw­nie łatwiej­szy do per­cep­cji niż model z uprosz­cze­nia­mi, w szcze­gól­no­ści total­nie nie­straw­ny dla zwy­kłych ludzi (czy­ta: nie­we­ry­fi­ko­wal­ny przez zama­wia­ją­ce­go) [[model rela­cyj­ny w trze­ciej posta­ci nor­mal­nej]]. Tu bar­dzo prze­pra­szam czy­tel­ni­ków biz­ne­so­wych, że uży­łem nie­zro­zu­mia­łych zapew­ne dla nich pojęć, ale to wła­śnie poka­zu­je, że na tym eta­pie zama­wia­ją­cy tra­ci kon­takt (zro­zu­mie­nie) z wyko­naw­ca tego co sam zamó­wił zamawiający.

Z mode­lu pro­ce­su dowia­du­je­my się, że nastę­pu­ją­ce obiek­ty bio­rą udział w reali­za­cji potrzeb­nych nam funk­cjo­nal­no­ści: Formularz Zamówienia i koniec! Na pew­no? Nie 🙂 bo chce­my by jed­nak by był to auto­ma­tycz­ny sys­tem inter­ne­to­wy, wiec potrzeb­ny jest Zarządca. On wie: jak przyj­mo­wać Zamówienia oraz skąd brać dane i gdzie je wysy­łać. Klient (zama­wia­ją­cy) jest tu akto­rem i nie jest on abso­lut­nie obiek­tem biz­ne­so­wym do imple­men­ta­cji. Mamy więc dwa obiek­ty biz­ne­so­we: Zarządca i FormularzZamówienia. Do tego mamy inter­fej­sy dla ERP i do Płatności. A gdzie baza danych? Nie ma! Co robić? Wiem! Kuwetka :), potrzeb­na mi kuwet­ka. Baza danych to dla biz­ne­su sło­wo obrzy­dli­we i nie uży­wa­my go. Mamy więc: Zarządca, Kuwetka, FormularzZamówienia, .… aaaaaaaa, a same Zamówienia? :). Komplet:

  1. FormularzZamówienia
  2. GeneratorDruczków
  3. Kuwetka
  4. Zarządca
  5. Zamówienia

Nie zapo­mi­na­my, że mamy Framework i inter­fej­sy (ERP i Płatności). Pojawił się jesz­cze GeneratorDruczków. Skąd się wziął? Kolejna meto­da pro­jek­to­wa­nia: [[Role, odpo­wie­dzial­ność, współ­pra­ca]]. Otóż, war­to Zarządcę zwol­nić z obo­wiąz­ku posia­da­nia wie­dzy o aktu­al­nych wzo­rach doku­men­tów. Te wie­dzę o aktu­al­nie sto­so­wa­nych wzo­rach doku­men­tów (i rolę) posia­da GeneratorDruczków. I mógł by ktoś powie­dzieć, że nie­po­trzeb­nie kom­pli­ku­je pro­gram. Owszem, skom­pli­ko­wał się. Jeśli jed­nak w pro­gra­mie poja­wią się kie­dyś nowe funk­cjo­nal­no­ści, inni Zarządcy, wszy­scy będą pobie­ra­li drucz­ki z jed­ne­go miej­sca bez zasta­na­wia­nia się czy są wła­ści­we bo mamy tyl­ko jed­no ich źró­dło, któ­re odpo­wia­da za to by zawsze były właściwe.

Jak wyglą­da dia­gram klas:

Diagram klas, model dziedziny systemu

Tak więc co my tu mamy, po kolei: Klient (nasz aktor) kon­tak­tu­je się wyłącz­nie z Zarządcą, któ­ry go obsłu­gu­je. Zarządca korzy­sta z usług GeneratoraDruczków, Kuwetki, zewnętrz­nych sys­te­mów poprzez inter­fej­sy. Koniec. Co dalej? Ano wypa­da­ło by poka­zać jak Zarządca, zda­niem pro­jek­tan­ta (:)) reali­zu­je nasz przy­pa­dek uży­cia. Na potrze­by usys­te­ma­ty­zo­wa­nia pro­jek­tu przy­to­cze jesz­cze raz sce­na­riusz w fir­mie trosz­kę sformalizowanej:

uc_scenariusz

Taka postać sce­na­riu­sza (dia­log) pozwa­la upew­nić się, że zama­wia­ją­cy i pro­jek­tant myślą tak samo. Mały komen­tarz: Klient ma przed sobą Ekran Startowy i wybie­ra opcję (pole­ce­nie) Nowe Zamówienie. System pyta o NIP, Klient wpi­su­je NIP i potwier­dza. Możliwe jest nie wpi­sa­nie NIP. System wyświe­tla for­mat­kę nowe­go zamó­wie­nia. Formatka ma wypeł­nio­ne dane Zamawiającego lub nie, jeśli nie poda­no NIPu albo nie zna­le­zio­no go na liście kon­tra­hen­tów. Klient wpro­wa­dza dane poprzez zazna­cze­nie tego co chce zamó­wić, wpi­su­je ilo­ści itp. na koniec potwier­dza. System spraw­dza i wyświe­tla kom­plet­ne zmó­wie­nie. Klient zatwier­dza lub rezy­gnu­je (pomi­ną­łem, ewen­tu­al­ną edy­cję dla uprosz­cze­nia, jeże­li fir­ma ofe­ru­je tysią­ce pro­duk­tów tak­że będzie inaczej :)).

W tym momen­cie Klient ma jed­no lub wię­cej zamó­wień do opła­ce­nia, w kolej­nym przy­pad­ku uży­cia może zazna­czyć zamó­wie­nia do opła­ce­nia i wybrać opcję Inicjacja Płatności, System przy­go­tu­je nie­zbęd­ne dane i prze­ka­że ste­ro­wa­nie do Systemu obsłu­gi Płatności. Nie będzie tu tego opi­su, celem arty­ku­łu jest poka­za­nie meto­dy a nie wyko­na­nie kom­plet­ne­go projektu.

Powyższy sce­na­riusz posłu­ży teraz do prze­te­sto­wa­nia i uzu­peł­nie­nia mode­lu dzie­dzi­ny i uzu­peł­nie­nia go (ten etap nazy­wa­ny jest czę­sto [[pro­of-of-con­cept]]). Narzędziem do testo­wa­nia będzie dia­gram sekwencji:

[sin­gle­pic id=73 w=320 h=240 float=center]

Samo wyko­na­nie powyż­sze­go dia­gra­mu pozwa­la na spraw­dze­nie popraw­no­ści pomy­słu i jego logi­ki oraz od razu daje nam moż­li­wość wery­fi­ka­cji atry­bu­tów i ope­ra­cji. Po tym teście (opra­co­wa­nie tego dia­gra­mu jest testem kon­cep­cji) uzu­peł­nia­my model dzie­dzi­ny o atry­bu­ty i ope­ra­cje. Diagram klas to sta­tycz­ny opis, któ­ry sam z sie­bie nicze­go nie mówi o współ­pra­cy obiek­tów. Jego popraw­na inter­pre­ta­cja (nie licząc sys­te­mu pojęć) jest nie­moż­li­wa bez tego mode­lu dyna­mi­ki (dia­gram sekwen­cji to model dyna­mi­ki sys­te­mu). Zaryzykował bym nawet tezę, że sam dia­gram klas nie nie­sie pra­wie żad­nej infor­ma­cji wykonawcy.

Model dzie­dzi­ny wzbo­ga­cił się:

model-dziedziny_0

Podsumowanie

Przytoczę ponow­nie cyto­wa­ny dia­gram klas:

uml2_diagram_klas6_modelowaniewordpresscom

Powyższy dia­gram w moim mnie­ma­niu jest raczej pew­nym mode­lem poję­cio­wym. Bez kil­ku słów o meto­dy­ce pro­jek­to­wa­nia trud­no go w ogó­le oce­niać dla­te­go poka­za­łem swój dia­gram klas, i spo­sób w jaki powstał. Kluczowe różnice:

  1. W moim mode­lu typ płat­no­ści będzie atry­bu­tem Zamówienia
  2. Obiekt Zamówienie, poza zawar­to­ścią dru­ku zamó­wie­nia, obsłu­gu­je tak­że inne dodat­ko­we zada­nia (pamię­ta­nie o spo­so­bie płat­no­ści, przy­go­to­wa­nie seria­li­za­cji XML do wsa­dze­nia” obiek­tu do ERP, może coś jeszcze…)
  3. Klient w ogó­le się nie poja­wia, chy­ba już wia­do­mo dlaczego…
  4. Pozycja zamó­wie­nia zosta­ła ukry­ta” w zamó­wie­niu, zależ­nie od kon­cep­cji były by to ele­men­ty agre­ga­tu (pozy­cje­za­mó­wie­nia u mnie były by w rela­cji kom­po­zy­cji do obiek­tu bazo­we­go DrukZamówienia), nie ma kla­sy Produkt (maga­zyn), jest to obiekt za któ­ry odpo­wia­da sys­tem ERP.
  5. U mnie poja­wia się Kuwetka, obiekt odpo­wie­dzial­ny za skła­do­wa­nie Zamówień, pyta­nia o kon­kret­ne Zamówienie, ostat­nie zamó­wie­nie, zesta­wie­nie zamó­wień za okres to poten­cjal­ne ope­ra­cje obiek­tu Kuwetka.
  6. Pojawia się tak­że Zarządca, obiekt odpo­wie­dzial­ny za obsłu­gę przy­pad­ku uży­cia (byc może tak­że innych). Na dia­gra­mie sekwen­cji poja­wi­ła się kla­sa System obsługi…jest to abs­trak­cja ele­men­tu View wzor­ca MVC.

Powyższy pro­jekt jest bar­dzo uprosz­czo­ny i na pew­no ma wie­le wad, kil­ka ite­ra­cji pro­jek­to­wa­nia i testów war­to by jesz­cze prze­pro­wa­dzić. Celem moim jed­nak było poka­za­nie samej meto­dy ana­li­zy i pro­jek­to­wa­nia, tego do cze­go moż­na użyć nota­cji UML. Pokazać, że moż­na zapro­jek­to­wać logi­kę opro­gra­mo­wa­nia i ją prze­te­sto­wać nie pisząc nawet linij­ki kodu.

Na koniec chcia­łem poka­zać, że w pro­jek­tach dedy­ko­wa­nych, jeże­li jest nawet cień ryzy­ka, że wyko­naw­ca będzie błą­dził reali­zu­jąc nasz pro­jekt (nie ocze­kuj­my od pro­gra­mi­stów, że będą zna­li i rozu­mie­li naszą fir­mę, nie taka jest ich rola) war­to wyko­nać taki wła­śnie pro­jekt. Po pierw­sze prze­te­stu­je­my nasze życze­nia, po dru­gie powsta­nie mate­riał, na bazie któ­re­go kil­ku wyko­naw­ców doko­na wyce­ny z nie­wiel­kim błę­dem i bez dużych narzu­tów na nie­spo­dzian­ki. Czy takie pro­jek­ty robią deve­lo­pe­rzy? Ich o to pytaj­cie. Czy ma to sens? Testowanie dia­gra­mów jest co naj­mniej o rząd wiel­ko­ści tań­sze niż testo­wa­nie pro­to­ty­pów przez programistów.

Kto powi­nien opra­co­wać taki pro­jekt? Osobiście uwa­żam, że nie powi­nien to być wyko­naw­ca pro­jek­tu. Powodem jest po pierw­sze to, o czym wspo­mnia­łem: każ­dy się spe­cja­li­zu­je w jakiejś jed­nej tech­no­lo­gii. Po dru­gie w przy­pad­ku jakich­kol­wiek pro­ble­mów Zamawiający, jako nie­spe­cja­li­sta, nie ma żad­nej moż­li­wo­ści mery­to­rycz­nej oce­ny wyko­naw­cy, nawet gdy­by był szko­dli­wy dla zama­wia­ją­ce­go. Nie twier­dzę, że wszy­scy deve­lo­pe­rzy to nie­kom­pe­tent­ni nacią­ga­cze ale też nie dam gło­wy, że takich nie ma. Sugeruję naśla­do­wa­nie ryn­ku budow­la­ne­go: zarzą­dza­nie ryzy­kiem czy­li oddzie­le­nie pro­jek­to­wa­nia od wykonania.

Developer tak­że odno­si tu pew­ną korzyść: jest zwol­nio­ny z odpo­wie­dzial­no­ści i posą­dza­nia go o kom­bi­no­wa­nie, zysku­je dodat­ko­wo media­to­ra pomię­dzy sobą i zama­wia­ją­cym. Minus jest taki, że wyna­gro­dze­nie za ana­li­zę i pro­jekt nie wpły­nie do jego kie­sze­ni ale cóż… to koszt kom­for­tu pra­cy ale z regu­ły nie prze­kra­cza on 10 – 20% budże­tu na powsta­nie oprogramowania.

Podsumowanie drugie

Czy to ma sens w przy­pad­ku goto­wych ERP? Moim zdaniem:

  1. Ingerencja (tak zwa­na kasto­mi­za­cja) w goto­we opro­gra­mo­wa­nie ERP koń­czy się bar­dzo czę­sto desta­bi­li­za­cją pier­wot­nie dobre­go oprogramowania.
  2. Jeżeli sys­tem ERP jest zamknię­ta bry­łą (z regu­ły świad­czy o tym fakt pra­cy na rela­cyj­nej, znor­ma­li­zo­wa­nej bazie danych) nie war­to go kastro­mi­zo­wać bo to kosz­tow­ny i bar­dzo ryzy­kow­ny pro­ces, do tego pozba­wia­my się moż­li­wo­ści pro­ste­go jego upgrade’owania.

Brakujące w fir­mie funk­cjo­nal­no­ści lepiej two­rzyć osob­no, jako dedy­ko­wa­ne pro­jek­ty bo to po pierw­sze chro­ni inwe­sty­cję w ERP, po dru­gie z regu­ły kosz­tu­je znacz­nie mniej i znacz­nie szyb­ciej jest goto­we do uży­cia (stwo­rze­nie małe­go opro­gra­mo­wa­nie jest dużo prost­sze niż mody­fi­ka­cja duże­go). Po dru­gie poja­wia­ją się już sys­te­my ERP mają­ce struk­tu­rę wła­snie szkie­le­tu opar­te­go na wzor­cu MVC i zapro­jek­to­wa­nie nowej funk­cjo­nal­no­ści pole­ga na ana­li­zie i pro­jek­to­wa­niu takim jak wyżej opi­sa­ne, z tą róż­ni­cą że imple­men­ta­cja ma miej­sce w śro­do­wi­sku tego ERP a nie w śro­do­wi­sku odręb­ne­go narzę­dzia pro­gra­mi­stycz­ne­go. Tak więc, paradoksalnie,

powyż­sze ana­li­za i pro­jek­to­wa­nie powin­ny być zawsze pierw­szym eta­pem pro­jek­tu pro­gra­mi­stycz­ne­go nie­za­leż­nie od tego czy ma powstać nowe opro­gra­mo­wa­nie czy tyl­ko nowe funk­cjo­nal­no­ści do ist­nie­ją­ce­go.

A gdzie się podzia­ły wyma­ga­nia pozafunkcjonalne?

Generalnie w mojej meto­dy­ce są one ogra­ni­cze­nia­mi doku­men­to­wa­ny­mi dla każ­de­go przy­pad­ku uży­cia indy­wi­du­al­nie. Powstaje repo­zy­to­rium ogra­ni­czeń i mapo­wa­nie ich na przy­pad­ki uży­cia. Bardzo restryk­cyj­ne ogra­ni­cze­nia (np. wyso­ka dostęp­ność) mogą być wydzie­lo­ne z ich przy­pad­ka­mi uży­cia do osob­ne­go pod­sys­te­mu i imple­men­to­wa­ne nawet na osob­nej plat­for­mie jeśli taka będzie potrze­ba zwią­za­na z ren­tow­no­ścią. To jed­nak temat na osob­ny artykuł :).

Konkluzja biz­ne­so­wa: Nowy sys­tem infor­ma­tycz­ny to inte­rak­cja fir­my i opro­gra­mo­wa­nia, musi być trak­to­wa­na łącz­nie jako jeden sys­tem zło­żo­ny z ludzi i narzę­dzi w ich oto­cze­niu. Dlatego decy­zja biz­ne­so­wa o out­so­ur­cin­gu płat­no­ści i inte­gra­cji z ERP powin­na być moim zda­niem inte­gral­ną czę­ścią i pro­duk­tem ana­li­zy biz­ne­so­wej w pro­jek­cie informatycznym.