Wprowadzenie

Od ponad 20 lat pro­wa­dzę ana­li­zy biz­ne­so­we, pro­jek­tu­ję infor­ma­tycz­ne sys­te­my prze­twa­rza­nia danych, zarzą­dza­ją­ce prze­pły­wem infor­ma­cji. Obserwuję sta­ły postęp narzę­dzi oraz roz­wój metod pro­wa­dze­nia ana­liz, ale tak­że brak (ale nie w 100%) postę­pu w uzy­ski­wa­nych efek­tach :

Czemu tak sie dzie­je? Metody reali­zo­wa­nia pro­jek­tów przez więk­szość dostaw­ców IT nie zmie­ni­ły sie od 30 lat: roz­mo­wy, wywia­dy, kodo­wa­nie, kosz­tow­ne narzę­dzia (C++, Java). Od 20 lat wie­my, że napi­sa­nie pro­gra­mu w C++/Java to dwu­krot­nie więk­sza pra­co­chłon­ność w porów­na­niu do iden­tycz­ne­go efek­tu uzy­ska­ne­go języ­ka­mi skryp­to­wy­mi . Stała popu­lar­ność C++/Java ma swo­je źró­dło: więk­szość dużych sys­te­mów w bran­ży fin/tech powsta­ła w latach 90-tych, nie są uno­wo­cze­śnia­ne a jedy­nie uzu­peł­nia­ne są o kolej­ne funk­cjo­nal­no­ści mimo, że nie jest tajem­ni­cą jak doko­nać migra­cji do now­szych tech­nio­lo­gii i archi­tek­tur .

Powody są dość pro­za­icz­ne: dopó­ki jest popyt, dostaw­cy tech­no­lo­gii nie mają żad­ne­go inte­re­su w uno­wo­cze­śnia­niu swo­ich pro­duk­tów i sprze­da­ją per­ma­nent­ny dług tech­no­lo­gicz­ny .

Skąd się u wie­lu użyt­kow­ni­ków tech­no­lo­gii IT bie­rze dług tech­no­lo­gicz­ny już w momen­cie pod­pi­sa­nia umo­wy na wdro­że­nie? Stąd, że zle­co­no ana­li­zę przed­wdro­że­nio­wą wyma­gań dostaw­cy tech­no­lo­gii, a w jego inte­re­sie jest dostar­czyć to co ma, a nie to cze­go potrze­bu­je klient.

(https://​it​-con​sul​ting​.pl/​2​0​1​1​/​1​1​/​2​0​/​c​z​e​g​o​-​n​a​j​w​i​e​k​s​z​e​-​f​i​r​m​y​-​t​e​c​h​n​o​l​o​g​i​c​z​n​e​-​n​i​e​-​m​o​w​i​a​-​s​w​o​i​m​-​k​l​i​e​n​t​om/)

Dlatego nadal mówi się i pisze, by nie powie­rzać dostaw­com tech­no­lo­gii prac nad ana­li­za­mi wyma­gań i zarzą­dza­nia wdrożeniami: 

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy sys­te­mów mogą być cen­nym ele­men­tem cyfro­wej trans­for­ma­cji, ale nigdy nie powin­ni mieć cał­ko­wi­tej, nie­kon­tro­lo­wa­nej wła­dzy nad całym przedsięwzięciem

(https://​www​.techra​dar​.com/​n​e​w​s​/​w​h​a​t​-​h​e​r​t​z​-​v​-​a​c​c​e​n​t​u​r​e​-​t​e​a​c​h​e​s​-​u​s​-​a​b​o​u​t​-​f​a​i​l​u​r​e​-​i​n​-​s​y​s​t​e​m​s​-​d​e​v​e​l​o​p​m​e​n​t​-​p​r​o​j​e​cts)

Tak więc pozo­sta­je zro­bić to same­mu, ale jak? Wiemy też na pew­no, że nie jest dobrym pomy­słem prze­pro­wa­dze­nie wewnętrz­nych warsz­ta­tów z pra­cow­ni­ka­mi i samo­dziel­ne spi­sa­nie ​„wyma­gań”, gdyż tak powsta­ją naj­bar­dziej nie­spój­ne i nie­kom­plet­ne opi­sy wyma­gań . Więc jak?

Ideałem jest zaan­ga­żo­wa­nie zewnętrz­ne­go ana­li­ty­ka pro­jek­tan­ta, z zastrze­że­niem że nie może on być dostaw­cą sys­te­mu. Jest to meto­da zna­na od lat, ale nadal rzad­ko sto­so­wa­na z uwa­gi na to, że ​„mało kto tak robi”, oraz z powo­du powszech­ne­go prze­ko­na­nia, że ​„dostaw­ca ma lep­sze­go ana­li­ty­ka i pro­jek­tan­ta” (mimo, że teza taka nie ma żad­ne­go uza­sad­nie­nia w fak­tach ). Powodem jest tak­że to, że zaufa­nie do osób z zewnątrz w wie­lu fir­mach jest bar­dzo małe, co powo­du­je, że nie każ­dy zarząd decy­du­je się na taką współpracę. 

Orientacja na artefakty

Jak już wspo­mnia­no wywia­dy z pra­cow­ni­ka­mi dają jako pro­dukt nie­spój­ny i nie­kom­plet­ny opis orga­ni­za­cji. Dlatego od wie­lu lat mówi się, że orga­ni­za­cje dosko­na­le opi­su­ją arte­fak­ty jakie ona ona wytwa­rza i to na ich pod­sta­wie, a nie na pod­sta­wie wywia­dów, nale­ży pro­wa­dzić ana­li­zy i pro­jek­to­wać sys­te­my. Czym są te artefakty?

Artefakt to kon­kret­ny, moż­li­wy do ziden­ty­fi­ko­wa­nia, samo­opi­su­ją­cy się frag­ment infor­ma­cji, któ­ry może być wyko­rzy­sta­ny przez oso­bę pro­wa­dzą­cą dzia­łal­ność gospo­dar­czą do jej pro­wa­dze­nia. Czasami okre­śla­my arte­fak­ty jako doku­men­ta­cję biz­ne­so­wą, a nie­któ­rzy ludzie biz­ne­su wyda­ją się pre­fe­ro­wać tę ter­mi­no­lo­gię. Aby arte­fak­ty były przy­dat­ne do rze­czy­wi­ste­go pro­wa­dze­nia biz­ne­su, w prze­ci­wień­stwie do abs­trak­cyj­ne­go mode­lu do ana­li­zy, muszą być roz­po­zna­wal­ne; to zna­czy, muszą zawie­rać infor­ma­cje w jed­nym miej­scu. Wszyscy sły­sze­li­śmy zwy­kłe stwier­dze­nie fru­stra­cji: ​„Ale ja nie mam tu wszyst­kich potrzeb­nych infor­ma­cji”. Wymagania doty­czą­ce bycia wraż­li­wym na potrze­by biz­ne­su i samo­opi­su­ją­cym się są napę­dza­ne bar­dzo moc­no z per­spek­ty­wy poznaw­czej wła­ści­cie­la biz­ne­su. Artefakty są trak­to­wa­ne jako jedy­na jaw­na infor­ma­cja zawar­ta w biz­ne­sie; to zna­czy, że jest to zbiór zapi­sów biz­ne­so­wych repre­zen­tu­ją­cych zawar­tość infor­ma­cyj­ną biznesu.

Innymi sło­wy: arte­fak­ty to doku­men­ty ope­ra­cyj­ne i ich treść, prze­twa­rza­ne i wytwa­rza­ne w toku funk­cjo­no­wa­nia orga­ni­za­cji, oraz wszel­kie śla­dy i skut­ki tego przetwarzania. 

Podejście skon­cen­tro­wa­ne na arte­fak­tach biz­ne­so­wych trak­tu­je dane jako inte­gral­ną część pro­ce­sów biz­ne­so­wych, a pro­ce­sy biz­ne­so­we i ich ope­ra­cje defi­niu­je w kate­go­riach współ­dzia­ła­ją­cych klu­czo­wych arte­fak­tów biz­ne­so­wych (BA, busi­ness arti­fact). Każdy typ BA jest cha­rak­te­ry­zo­wa­ny przez model infor­ma­cyj­ny i model cyklu życia. Model infor­ma­cyj­ny reje­stru­je wszyst­kie istot­ne z punk­tu widze­nia biz­ne­su infor­ma­cje o instan­cji BA w mia­rę jej prze­miesz­cza­nia się w przed­się­bior­stwie. Cykl życia okre­śla wszyst­kie moż­li­we ewo­lu­cje instan­cji BA w cza­sie. Jako przy­kład BA, roz­waż­my bank CheckingAccount, któ­ry reje­stru­je wszyst­kie infor­ma­cje o kon­cie od momen­tu jego otwar­cia przez klien­ta do momen­tu jego osta­tecz­ne­go zamknię­cia i zar­chi­wi­zo­wa­nia, z cyklem życia reje­stru­ją­cym wszyst­kie istot­ne sta­ny kon­ta, moż­li­we przej­ścia, ope­ra­cje, itp.

Metody ana­li­zy i pro­jek­to­wa­nia opar­te na arte­fak­tach są tak­że w lite­ra­tu­rze opi­sy­wa­ne jako evi­den­ce-based sys­tem engi­ne­ering .

Klasyczna meto­da pro­wa­dze­nia ana­li­zy nadal w cenie i nie raz już tu była opi­sa­na, a czy jest jakaś alter­na­ty­wa? Tak! Jest świa­teł­ko w tunelu!

Prawnik jako analityk

Tak! Od kil­ku lat eks­pe­ry­men­tu­ję z Regulaminami (regu­la­mi­ny sprze­da­ży, świad­cze­nia usług, itp.) jako pod­sta­wo­wy­mi źró­dła­mi potrzeb biz­ne­so­wych. I oka­zu­je się, że bar­dzo czę­sto sta­no­wią one pra­wie dosko­na­łą spe­cy­fi­ka­cję potrzeb, na pod­sta­wie któ­rej moż­na nie raz zapro­jek­to­wać nawet 80 – 90% cało­ści sys­te­mu! Owszem bywa­ją nie­spój­ne regu­la­mi­ny, ale to się zda­rza bar­dzo rzad­ko. Najczęściej opra­co­wa­nie takie­go regu­la­mi­nu zle­ca się praw­ni­kom, a Ci bar­dzo skru­pu­lat­nie ana­li­zu­ją wszel­kie obo­wiąz­ki i ryzy­ka na każ­dym eta­pie reali­za­cji obsłu­gi klien­tów czy też reali­za­cji zadań wewnętrz­nych (poza regu­la­mi­na­mi obsłu­gi klien­tów mamy też róż­ne regu­la­mi­ny wewnętrzne). 

W efek­cie zamiast pra­co­wać z nie­spój­na i peł­ną sprzecz­no­ści (typo­we efek­ty warsz­ta­tów i burz mózgów) listą życzeń pra­cow­ni­ków orga­ni­za­cji, zna­cze­nie efek­tyw­niej pra­cu­je się z Regulaminem. Jeżeli ma powstać sklep inter­ne­to­wy będzie to np. Regulamin Sklepu Internetowego, jeże­li ma postać sys­tem CRM dosko­na­ły mate­ria­łem będzie wewnętrz­ny Regulamin Obsługi Klienta. Jeżeli ma powstać sys­tem zarzą­dza­nia prze­pły­wem fak­tur kosz­to­wych nale­ży zacząć pra­ce od opra­co­wa­nia Regulaminu Przepływu Faktur Kosztowych (tu raczej dział księ­go­wo­ści będzie wiódł prym). 

Przyjęcie zało­że­nia, że na pod­sta­wie regu­la­mi­nów moż­na zapro­jek­to­wać opro­gra­mo­wa­nie jest spraw­dzo­ne, warun­kiem jest: (1) zakres pro­jek­tu to obszar opi­sa­ny tymi regu­la­mi­na­mi, (2) zakres pro­jek­tu to obszar admi­ni­stra­cyj­ny (obsłu­ga zapy­tań i zamó­wień to też ten obszar, nie przy­pad­kiem zwa­ny nie raz back-offi­ce), (3) regu­la­mi­ny nie odno­szą się do (nie zawie­ra­ją w tre­ści) nazw i cech narzę­dzi i opro­gra­mo­wa­nia a jedy­nie do czyn­no­ści, reguł ich wyko­na­nia i wzo­rów doku­men­tów. Ten ostat­ni waru­nek jest naj­waż­niej­szy i nie­ste­ty czę­sto nie jest speł­nio­ny, w toku ana­li­zy sta­je reko­men­da­cją do zmiany. 

Dwa alter­na­tyw­ne warianty:

Wariant 1 to stan­dar­do­we podej­ście: decy­zja o pro­jek­cie i pla­no­wa­nie i ana­li­za biz­ne­so­wa. Na pod­sta­wie wyni­ków ana­li­zy biz­ne­so­wej i reko­men­da­cji praw­ni­cy (Organizacja ana­li­zo­wa­na) opra­co­wu­ją Regulamin (usłu­gi, por­ta­lu itp.), całość sta­no­wi sobą wyma­ga­nia i pro­jek­to­wa­ny jest doce­lo­wy sys­tem. Tu opra­co­wa­nie Regulaminu pole­ga na wyko­rzy­sta­niu wyni­ków ana­li­zy biznesowej. 

Wariant 2 to rzad­sze podej­ście, pole­ga­ją­ce na wyko­rzy­sta­niu wcze­śniej wyko­na­nej pra­cy nad opra­co­wa­niem Regulaminu. To sytu­acja w któ­rej taki wypra­co­wa­ny Regulamin już ist­nie­je, albo – do cze­go nie raz zachę­cam moich klien­tów – Regulamin jest opra­co­wa­ny celo­wo jako ele­ment przy­go­to­wa­nia mate­ria­łów do ana­li­zy. Dość czę­sto w orga­ni­za­cji jest dział praw­ny lub ma ona sta­łą obsłu­gę praw­ną. Są to oso­by zna­ją­ce fir­mę, i prak­ty­ka poka­zu­je, że mają duża wie­dzę o swo­im klien­cie. Mają też tę zale­tę nie są to emo­cjo­nal­nie zwią­za­ni z fir­mą jej mene­dże­ro­wie. Prosze nie zapo­mi­nać, że pra­cow­ni­cy fir­my zaan­ga­żo­wa­ni w pro­ces zbie­ra­nia wyma­gań na przy­szły sys­tem infor­ma­tycz­ny są emo­cjo­nal­nie zwią­za­ni ze swo­im obec­nym sta­no­wi­skiem i dotych­cza­so­wym sty­lem pra­cy, mają więc pewien kon­flikt inte­re­su i nie zawsze są obiek­tyw­ni. Czy to ich zła wola? Nie, to emo­cje któ­re są ryzy­kiem pro­jek­tu, a nie złą wolą tych ludzi. 

Podsumowanie

Ścisła współ­pra­ca z dzia­łem praw­nym fir­my ana­li­zo­wa­nej potra­fi przy­nieść duże korzy­ści. Bardzo czę­sto są to ludzie dobrze zna­ją­cy fir­mę, oby­ci w opra­co­wy­wa­niu zasad świad­cze­nia usług, reguł postę­po­wa­nia. Regulaminy to doku­men­ty na dość wyso­kim pozio­mie for­ma­li­za­cji, co bar­dzo poma­ga w pra­cy z nimi. Projektowanie na ich pod­sta­wie logi­ki biz­ne­so­wej sys­te­mu infor­ma­tycz­ne­go jest znacz­nie łatwiej­sze niż na pod­sta­wie opi­sów przy­go­to­wa­nych przez tak zwa­ny ​„biz­nes”.

Od kil­ku lat testu­ję tę meto­dę pro­jek­to­wa­nia sys­te­mów, w ww. obsza­rach spraw­dza się bar­dzo dobrze. W cza­sie pro­wa­dze­nia zajęć labo­ra­to­ryj­nych ze stu­den­ta­mi na kie­run­ku Inżynieria Oprogramowania uczą się oni wychwy­ty­wa­nia w Regulaminach sfor­mu­ło­wań, któ­re sta­no­wią mate­riał na słow­nik pojęć i regu­ły biz­ne­so­we, na akto­rów i nie raz nawet na modu­ły apli­ka­cji. Są to meto­dy opar­te na onto­lo­gicz­nych ana­li­zach tek­sto­wych . W połą­cze­niu z meto­da­mi opi­su reguł biz­ne­so­wych z uży­ciem tablic decy­zyj­nych, sta­no­wią bar­dzo dobre narzę­dzie do pra­cy nad arte­fak­ta­mi jaki­mi są tek­sty biz­ne­so­we, a regu­la­mi­ny do takich nale­żą .

Przykładowe analizy na podstawie Regulaminu

Poniżej do pobra­nia dwa pli­ki pdf, opra­co­wa­nia wyko­na­ne w cało­ści tyl­ko na pod­sta­wie Regulaminu. Pierwszy to pro­jekt aplikacji” 

Analiza Regulaminu Świadczenia Usługi

1 file(s) 1.45 MB

Pobierz

Drugi to wynik ana­li­zy Regulaminu i reko­men­da­cje do popra­wy jego jakości: 

Biblioteka Demo

1 file(s) 21.63 MB

pobierz

Źródła