Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. Przypadki użycia i granice systemu

Pora na przy­pad­ki uży­cia i gra­ni­ce sys­te­mu. W poprzed­niej czę­ści (Diagram klas ? czy­li ?rein­ży­nie­ria? ana­li­zy biz­ne­so­wej) wska­za­łem na poten­cjal­ne ryzy­ka opi­su user sto­ry i narzę­dzie niwe­lu­ją­ce tę wadę czy­li model pro­ce­su jaki opi­sał Zamawiający (hipo­te­tycz­ny autor opi­su User sto­ry). Tworzenie mode­lu ma dwa zada­nia: wery­fi­ka­cja spój­no­ści i kom­plet­no­ści opi­su Zamawiającego oraz stwo­rze­nie pod­sta­wy do okre­śle­nia zakre­su pro­jek­tu i wyspe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych czy­li tak zwa­nych przy­pad­ków uży­cia. Czy tak się robi zawsze? Ja z zasa­dy (moja meto­dy­ka opra­co­wa­na na bazie doświad­czeń i lite­ra­tu­ry) trak­tu­ję KAŻDY opis, nawet w posta­ci struk­tu­ral­nej (tabe­le, punk­ty itp.), dostar­czo­ny przez Zamawiającego jako takie wła­śnie ryzy­kow­ne user sto­ry.

Czy to brak zaufa­nia dla Zamawiającego? Przecież to dla nie­go sys­tem, Zamawiający powi­nien umieć okre­ślić cze­go potrze­bu­je. Hm… każ­dy z nas potra­fi powie­dzieć do cze­go i jaki chce samo­chód, czy to zna­czy że potra­fi wyspe­cy­fi­ko­wać kon­struk­cję tego samo­cho­du? (mój mecha­nik jest bar­dziej dosad­ny, zawsze mówi: nie nic gor­sze­go od face­ta, któ­re­mu wyda­je się, że zna się na samo­cho­dach). Aby kupić goto­we opro­gra­mo­wa­nie o stan­dar­do­wej, powszech­nie sto­so­wa­nej funk­cjo­nal­no­ści, w zasa­dzie żaden ana­li­tyk nie jest nam potrzeb­ny. Jeżeli jed­nak chce­my coś, co choć trosz­kę ma paso­wać do nasze­go biz­ne­su i nie jest try­wial­ne nale­ży do tego podejść z więk­sza rezer­wą do wsze­la­kich oczy­wi­sto­ści, bo nie mówi­my już o prze­cięt­nym samo­cho­dzie ale o samo­cho­dzie, któ­rym wystar­tu­je­my w zawo­dach. Te zawo­dy to Wolny Rynek, star­cie z Konkurencją. Może nie zawsze jest to Formuła 1, ale też pra­wie nigdy nie jest to też jaz­da spa­ce­ro­wa na święta.

Wróćmy do nasze­go mode­lu pro­ce­sów. Ten, powsta­ły na bazie opi­su Zamawiającego pozwo­lił zna­leźć luki i nie­spój­no­ści, jest jed­nak zbyt szcze­gó­ło­wy. To rzad­ki u mnie przy­pa­dek ana­li­zy bot­tom-up (od szcze­gó­łu do ogó­łu) jed­nak pierw­sza sztyw­na zasa­da ana­li­ty­ka mówi: nie ist­nie­ją sztyw­ne zasa­dy ana­li­zy i pro­jek­to­wa­nia. Po drob­nych popraw­kach, uogól­nie­niu, model wyglą­da tak:

W zakre­sie pro­jek­tu mamy wszyst­kie czyn­no­ści, któ­re wraz z ich pro­duk­ta­mi sta­no­wią pro­ce­sy biz­ne­so­we, zosta­ły ona ozna­czo­ne ste­reo­ty­pem «usłu­ga apli­ka­cji» (ste­reo­ty­py nie są czę­ścią BPMN, moż­na je sto­so­wać do wska­za­nia powią­zań pomię­dzy obiek­ta­mi na mode­lach BPMN i UML gdzie będą im odpo­wia­da­ły przy­pad­ki użycia).

Po stro­nie Klienta (użyt­kow­ni­ka, dalej zwa­ne­go tak­że akto­rem) zasto­so­wa­no uprosz­cze­nie: jest mode­lo­wa­ny jak tak zwa­na czar­na skrzynka.

Będziemy bazo­wa­li na defi­ni­cji pro­ce­su biz­ne­so­we­go: pro­ces biz­ne­so­wy to czyn­ność lub logicz­nie powią­za­ny łań­cuch czyn­no­ści prze­kształ­ca­ją­cy pro­dukt na swo­im wej­ściu w pro­dukt (jego stan) na wyj­ściu. Różnica pomię­dzy tymi pro­duk­ta­mi sta­no­wi war­tość wno­szo­ną biz­ne­so­wą przez pro­ces.

Po stro­nie Sklepu mamy więc teraz pro­ce­sy (czyn­no­ści): Rejestracja Zamówienia, Rejestracja wpła­ty, Pakowanie i wysył­ka oraz Utworzenie rapor­tu o sta­nie zamówienia.

Kolejna rzecz to gra­ni­ce sys­te­mu. Dwa zało­że­nia, któ­re wyda­ją się bar­dzo roz­sąd­ne: Firma posia­da sys­tem ERP oraz płat­no­ści elek­tro­nicz­ne będą przed­mio­tem out­so­ur­cin­gu. Tak więc wyma­ga­nia na sys­tem to:

  1. przyj­mo­wa­nie zamówień,
  2. przyj­mo­wa­nie płat­no­ści dro­ga elektroniczną,
  3. inte­gra­cja z ERP: sys­tem ten odpo­wia­da za księ­go­wa­nie fak­tur i zarzą­dza­nie magazynem,
  4. uży­cie zewnętrz­ne­go ope­ra­to­ra płat­no­ści elektronicznych.

Powyższe wyda­je się roz­sąd­ne i bywa czę­sto spo­ty­ka­ne (sta­ram się by ten przy­kład aż tak nie odbie­gał od rze­czy­wi­sto­ści ;)). Wymagania powin­ny być zwię­złe ale tez nie powin­ny wykra­czać poza opis co powin­no być moż­li­we z nowym sys­te­mem. Tak więc dia­gram przy­pad­ków jaki stwo­rzy­łem uży­cia wyglą­da tak:

Kilka słów na temat tego dia­gra­mu. Mamy przy­pa­dek uży­cia dla każ­dej aktyw­no­ści. Każdy przy­pa­dek uży­cia powi­nien zostać udo­ku­men­to­wa­ny co naj­mniej trze­ma elementami:

  1. stan począt­ko­wy (warun­ki początkowe)
  2. sce­na­riusz
  3. ocze­ki­wa­ny stan końcowy

Kontekst sta­no­wi model pro­ce­sów wiec nie musi­my tu pisać czym są poprze­dza­ne i jakich mają następ­ców poszcze­gól­ne przy­pad­ki uży­cia. Wystarczy w mode­lach zacho­wać tak zwa­ne tra­ce­abi­li­ty (ja sto­su­ję pro­stą zasa­dę: nazwa przy­pad­ku uży­cia jest taka sama jak czyn­no­ści na mode­lu pro­ce­sów, z któ­rej został wypro­wa­dzo­ny, nazwy te są uni­kal­ne). Nie musi­my tak­że two­rzyć dia­gra­mów sce­na­riu­szy nad­rzęd­nych łań­cu­chów przy­pad­ków uży­cia bo zastę­pu­je je wła­śnie model BPMN. Na koniec uwa­ga: przy­pa­dek uży­cia powi­nien być samo­wy­star­czal­ny, inny­mi sło­wy musi mieć sens jako sam jeden (sam z sie­bie słu­ży do wyko­na­nia jakiejś logicz­nej czyn­no­ści dają­cej przy­dat­ny produkt).

Scenariusz naj­pro­ściej i naj­sku­tecz­niej jest opi­sy­wać w posta­ci dia­lo­gu Aktor <-> System. Ja sto­su­ję np. pro­sta tabe­lę z kolum­na­mi Aktor i System:

AKTOR                            SYSTEM
Inicjuje pracę                   Wyświetla listę produktów
Zaznacza wybrane produkty i OK   Wyświetla treść zamówienia
Potwierdza zamówienie            Wyświetla dane o płatności
Wybiera system płatności i OK    Kończy i ewentualnie przekazuje sterowanie

Tworzenie dia­gra­mów przy­pad­ków uży­cia w zasa­dzie war­to trak­to­wać tyl­ko jako spe­cy­fi­ka­cję kon­cep­cji zacho­wu­jąc zro­zu­mia­łość dla laika. Bąbelki powin­ny być tyl­ko spe­cy­fi­ka­cją funk­cjo­nal­ną i niczym ponad to. Ten dia­gram i tak nie zastą­pi dia­gra­mu klas, sekwen­cji czy tym bar­dziej opi­su pro­ce­su (tu był BPMN). Jak nie trud­no chy­ba już zauwa­żyć, doku­men­ta­cja zmie­rza w kie­run­ku kil­ku pro­stych mode­li (dia­gra­mów) zamiast jed­ne­go spa­ge­tii-mode­lu. Często spo­ty­kam się z doku­men­ta­mi, w któ­rych autor ana­li­zy wyma­gań wszyst­ko udo­ku­men­to­wał (sta­rał się) na dia­gra­mie przy­pad­ków uży­cia. To bywa straszne.

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

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

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

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

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

RUP

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

O języ­kach i teo­rii komunikacji

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

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

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

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

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

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

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

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

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

2010 r. Notatka: Zdaniem ana­li­ty­ków fir­my decy­du­ją­ce się na wdro­że­nie sys­te­mu ERP mogą unik­nąć roz­jeż­dza­ją­cych się ter­mi­nów i nad­mier­nie wyso­kich kosz­tów dzię­ki odpo­wied­nio prze­pro­wa­dzo­nej ana­li­zie przed­wdro­że­nio­wej. Eksperci pod­kre­śla­ją bowiem, że więk­szość kosz­tów gene­ro­wa­nych przez pro­jekt wdro­że­nio­wy nie ma nic wspól­ne­go z kosz­tem same­go opro­gra­mo­wa­nia. Średnio trzy czwar­te budże­tu pochła­nia­ją kosz­ty wdro­że­nia, mody­fi­ka­cji stan­dar­do­wej funk­cjo­nal­no­ści oraz moder­ni­za­cji sprzę­tu” – czy­ta­my w rapor­cie Panorama Consulting Group.” (źr. IDG, 2010r)

P.S. 2016 r. 

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

Czy juzkejsy zabijają innowacyjność?

Innowacyjność to prze­jaw twór­cze­go myśle­nia zaś pro­sta pra­co­wi­tość to tyl­ko dobre rze­mio­sło. Moim zda­niem na ryn­ku wygry­wa­ją odważ­ni twór­cy, rze­mieśl­ni­cy zawsze będą tyl­ko śred­nia­ka­mi. Wdrażanie sys­te­mów IT po to tyl­ko by coś uspraw­nić to rze­mio­sło. Można jed­nak wdra­żać sys­tem IT by tak­że pod­nieść kon­ku­ren­cyj­ność wno­sząc coś nowe­go do swo­jej ofer­ty czy­li two­rząc nową war­tość dla klien­tów na ryn­ku. Jak? Tworząc nowy model biz­ne­so­wy, w któ­rym sys­tem IT będzie ele­men­tem two­rzą­cym nową war­tość. Innowacyjność moim zda­niem to two­rze­nie nowych mode­li biz­ne­so­wych a nie pro­duk­cja kolej­nych ryn­ko­wych gadże­tów, któ­re według mnie są raczej skut­kiem tej inno­wa­cyj­no­ści a nie nią samą.


Badania wska­zu­ją, iż wdro­że­nie pro­ce­su inno­wa­cyj­ne­go jest klu­czo­wym ele­men­tem budo­wa­nia prze­wa­gi kon­ku­ren­cyj­nej. Skuteczność pro­jek­tów inno­wa­cyj­nych zale­ży jed­nak od wkom­po­no­wa­nia ich w kom­plek­so­wy sys­tem zarzą­dza­nia przed­się­bior­stwem. Co istot­ne inno­wa­cyj­ność prze­sta­je być koja­rzo­na wyłącz­nie z poję­ciem wyna­laz­ku jako rezul­ta­tu tra­dy­cyj­ne­go pro­ce­su badaw­czo-roz­wo­jo­we­go (R&D). Znacznie bar­dziej roz­po­wszech­nio­ne są nowe for­my dzia­łań inno­wa­cyj­nych: inno­wa­cyj­ność war­to­ści, inno­wa­cja w zarzą­dza­niu oraz inno­wa­cja w mode­lu biz­ne­so­wym przed­się­bior­stwa” – mówi Borys Stokalski, wice­pre­zes zarzą­du Infovide-Matrix (foto­gra­fia obok: Prezes Borys Stokalski pre­zen­tu­je wyni­ki badań nt. inno­wa­cyj­no­ści przed­się­biorstw, fot. Jarosław Żeliński)

Zostałem zapro­szo­ny na bar­dzo cie­ka­we spo­tka­nie jakim było śnia­da­nie pra­so­we zor­ga­ni­zo­wa­ne prze [[Infovide-Matrix]] 30 maja 2007 (za co bar­dzo fir­mie dzię­u­ję). Było ono dla mnie cie­ka­we z dwóch pod­sta­wo­wych powo­dów: po pierw­sze fir­ma jest mi bar­dzo bli­ska men­tal­nie gdyż tak­że jest wyznaw­cą” myśle­nia inno­wa­cyj­ne­go w swo­ich pro­jek­tach. Drugi powód to fakt, że Pan [[Prezes Borys Stokalski]], któ­re­go zawsze słu­cham z zacie­ka­wie­niem, w swo­ich pre­zen­ta­cjach pre­zen­tu­je otwar­ty spo­sób myśle­nia nie ska­żo­ny refe­ren­cyj­ny­mi mode­la­mi (któ­re moim zda­niem na pew­no są histo­rią god­ną ana­li­zy ale nie koniecz­nie mate­ria­łem do małpowania).

Uważam, że zakup nawet naj­lep­szych pędz­li i naj­droż­szy nawet kurs ich uży­wa­nia z niko­go jesz­cze nie uczy­nił obli­ga­to­ryj­nie nawet śred­nio dobre­go mala­rza (choć są wyjąt­ki). Dlaczego więc inne zaku­py mia­ła­by uczy­nić z kogo­kol­wiek mistrza? Rozmawiając z nie­któ­ry­mi moimi poten­cjal­ny­mi klien­ta­mi mam wra­że­nie, że nie­któ­rzy mene­dże­ro­wie szu­ka­ją jakie­goś Świętego Graala biz­ne­su, któ­re­go zdo­by­cie da im moc i siłę spraw­dzą do osią­gnię­cia suk­ce­su ryn­ko­we­go. Pojawiają się na ryn­ku takie atra­py” tych Graali jak sys­te­my ERP, nor­my jako­ści, ITIL, zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi i inne. Historia jed­nak zna wie­le przy­pad­ków ban­kructw posia­da­czy sys­te­mów ERP mają­cych cer­ty­fi­kat jako­ści ISO9000. Jeżeli w ogó­le ist­nie­je taki ryn­ko­wy Święty Graal to jest nim wła­śnie innowacyjność.

Uważam, że tym co wyróż­nia fir­my na ryn­ku jest ich inność. Teoria łań­cu­cha war­to­ści na ryn­ku ([[M.E.Porter, Przewaga kon­ku­ren­cyj­na]]) jasno wska­zu­je na dwa źró­dła prze­wa­gi kon­ku­ren­cyj­nej fir­my: są to war­tość wpro­wa­dza­na na rynek (trze­ba być dobrym w swo­im fachu) oraz indy­wi­du­alizm (trze­ba robić coś spe­cy­ficz­ne­go). To ostat­nie jest efek­tem inno­wa­cyj­no­ści fir­my, przy czym pierw­sze moim zda­niem jest skut­kiem dru­gie­go. Dlatego lide­rzy ryn­ku to inno­wa­cyj­ne fir­my a nie tyl­ko pracowite.

Troszkę o chyba złych projektach

W tym miej­scu powiem kil­ka słów o nie­któ­rych ana­li­zach przed­wdro­że­nio­wych. Wiele z nich moim zda­niem pro­wa­dzi do klę­ski zamiast do sukcesu.

Jednym z naj­czę­ściej sto­so­wa­nych spo­so­bów okre­śla­nia wyma­gań na sys­tem jest pro­ces pole­ga­ją­cy na ankie­to­wa­niu pra­cow­ni­ków, two­rze­niu Przypadków Użycia i na ich pod­sta­wie opra­co­wy­wa­ne są wyma­ga­nia na nowy sys­tem. Co mamy? Opis pra­cy ludzi w fir­mie bez peł­ne­go zro­zu­mie­nia celo­wo­ści tej pra­cy i jej wpły­wu na pozy­cje ryn­ko­wą bada­nej fir­my. Są na szczę­ście opi­sa­ne w lite­ra­tu­rze meto­dy ana­li­zy (jakiś czas temu bałem się już, że to ja jestem odszcze­pień­cem) pole­ga­ją­ce na zro­zu­mie­niu i opi­sa­niu fir­my, przy­pad­ki uży­cia są nawet dopie­ro czwar­tym kro­kiem ana­li­zy ale nie pierw­szym! (np. meto­da Catalysis, któ­rą sto­su­ję). Co osią­ga­my tą meto­dą? Po pierw­sze ana­li­za jest mniej pra­co­chłon­na, gdyż począt­ko­wo bio­rą w niej udział tyl­ko wybra­ne oso­by z wyż­sze­go kie­row­nic­twa. Po dru­gie wyni­ki ana­li­zy nie są zafał­szo­wa­ne subiek­ty­wi­zmem pra­cow­ni­ków niż­szych szcze­bli, któ­rych natu­ral­nym celem jest zacho­wa­nie sta­tus quo. Analizę taką dobrze jest poprze­dzić ana­li­zą ryn­ko­wą fir­my i stwo­rze­niem nawet ogól­nej stra­te­gii pod­no­sze­nia kon­ku­ren­cyj­no­ści fir­my. W koń­cu nowy sys­tem ma być narzę­dziem, któ­re ma się zwró­cić (gdzie ren­tow­ność pro­jek­tów IT?!). Mając stra­te­gię mamy pod­sta­wy do okre­śle­nia prio­ry­te­tów pod­czas wdrożenia.

Załóżmy, że z ana­li­zy wyma­gań otrzy­ma­my np. 100 wyma­gań funk­cjo­nal­nych a ana­li­za ren­tow­no­ści poka­że, że pro­jekt będzie ren­tow­ny przy budże­cie na 76 z nich. Jak tu doko­nać wybo­ru, któ­rych wyma­gań zanie­chać? Mając model pro­ce­so­wy fir­my, czy­li wewnętrz­ny łań­cuch war­to­ści, zna­jąc nawet sza­co­wa­ną war­tość wno­szo­ną przez każ­dy pro­ces biz­ne­so­wy, mamy pod­sta­wy do oce­ny, któ­re pro­ce­sy wyłą­czyć z pro­jek­tu lub ogra­ni­czyć ich wspar­cie. To jed­nak wyma­ga innej ana­li­zy, nie za pomo­cą tyl­ko przy­pad­ków uży­cia. Tu potrzeb­ne jest zro­zu­mie­nie ryn­ko­we­go celu fir­my: mode­lu biz­ne­so­we­go. Tego jed­nak nie uczą na kie­run­kach informatycznych.

Klienci kupują usługi, nie produkty

Kolejnym wnio­skiem z teo­rii łań­cu­cha war­to­ści jest zro­zu­mie­nie rela­cji pomię­dzy nabyw­cą a sprze­da­ją­cym. Nabywca tak na praw­dę nie pła­ci za pro­dukt tyl­ko za usłu­gę. Zawsze. Nawet kupu­jąc pastę do zębów tak na praw­dę pła­ci­my wła­ści­cie­lo­wi skle­pu za to, że mamy czym umyć zęby. To wła­ści­ciel skle­pu rekla­mu­jąc się, sytu­ując sklep w kon­kret­nym miej­scy i zaopa­tru­jąc go, daje nam moż­li­wość naby­cia pasty do zębów takiej jaką chce­my (jaka by ona nie była).

Co jest dla nas cen­ne w takim skle­pie? Tu wyma­ga­na jest ana­li­za bo poza samą pastą war­tość dla nas ma (praw­do­po­dob­nie): moż­li­wość wybo­ru spo­śród róż­nych past, wia­ra w rze­tel­ność skle­pu, szyb­ka i spraw­na obsłu­ga, ceny sto­sow­ne do miej­sca, jako­ści i mar­ki towa­ru, i inne. Analizując taki sklep i wie­dząc, że wła­ści­ciel ma ogra­ni­czo­ne środ­ki na infor­ma­ty­za­cję ana­li­za wyma­gań powin­na moim zda­niem dać np. odpo­wiedź na pyta­nie: sku­pić się na spraw­nej obsłu­dze przy kasie czy na spraw­nym zarzą­dza­niu zawar­to­ścią poszcze­gól­nych pólek sklepowych?

Uważam, że obec­nie wszyst­ko na ryn­ku jest usłu­gą, nie tyl­ko napra­wa butów u szew­ca ale tak­że ich pier­wot­ny zakup w skle­pie z dobra obsłu­gą. Skoro tak, to gdzie jest miej­sce na inno­wa­cyj­ność? Wydaje się, że budo­wa­nie nowych war­to­ści dla klien­tów jest tym Graalem. Ale to nie jest przed­miot czy meto­da, Graalem jest nowy pomysł a nie ten sko­pio­wa­ny od konkurenta.

Ludzie naj­bar­dziej boją sie ryzy­ka pomył­ki. To z tego powo­du mar­ko­we pro­duk­ty są droż­sze (kto z Pańswta idzie do skle­pu z prze­świad­cze­niem, że kupi cokol­wiek byle naj­tań­sze?). Marki dają wia­rę, w to że mniej ryzy­ku­je­my i jeste­śmy za tę wia­rę skłon­ni dodat­ko­wo zapła­cić. Jednak nie zapo­mi­naj­my, że mar­ka to nie sztucz­ny wytwór jej wła­ści­cie­la. Marka to efekt budo­wa­nia tej wia­ry.

Innowacje

Skąd się bio­rą faj­ne pomy­sły? Nie jest tajem­ni­cą, że naj­lep­sze rekla­my powsta­ją w agen­cjach kre­atyw­nych a nie w dzia­łach mar­ke­tin­gu firm rekla­mu­ją­cych swo­je pro­duk­ty. Przytoczone na począt­ku bada­nie poka­za­ło, że suk­ce­sy osią­ga­ją fir­my, któ­re inno­wa­cyj­ność wpi­sa­ły w swo­je stra­te­gie. Okazuje się jed­nak, że pro­ces inno­wa­cyj­no­ści nie ozna­cza zaan­ga­żo­wa­nia tyl­ko wła­snych zaso­bów. Na spo­tka­niu przy­to­czo­no przy­kład, w któ­rym pew­na fir­ma pro­du­ku­ją­ca sprzęt spor­to­wy, po kil­ku mie­sią­cach pra­cy, wypra­co­wa­ła nowy inno­wa­cyj­ny pro­dukt. Na ten sam pomysł wpa­dli pra­cow­ni­cy bro­wa­ru na warsz­ta­tach twór­czych w cią­gu zale­d­wie kil­ku godzin. O czym to świad­czy? O tym, że inno­wa­cyj­ność to mię­dzy inny­mi nie­skrę­po­wa­ne nawy­ka­mi otwar­te myśle­nie. W fir­mie powin­ny być wdro­żo­ne pro­ce­sy nakie­run­ko­wa­nie na two­rze­nie nowych pro­duk­tów. Jednak nie zna­czy to, że muszą to robić pra­cow­ni­cy tej samej fir­my. Jak sie oka­zu­je nie raz nawet nie powinni.

Inny spo­sób? Znalazła go fir­ma Google. Tam pro­ces inno­wa­cyj­no­ści pole­ga na nie­ogra­ni­cza­niu swo­ich pra­cow­ni­ków. Nie ma tam dzia­łu inno­wa­cyj­no­ści” mają­ce­go mono­pol na pomy­sły. Innowacyjność jest w Google wpi­sa­na w styl pra­cy pra­cow­ni­ków, nie ma zaka­zu mie­wa­nia pomy­słów, są one set­ka­mi reali­zo­wa­ne zaś rynek (użyt­kow­ni­cy por­ta­lu) doko­nu­ją wybo­ru. Wybór ten jest mani­fe­sto­wa­ny popu­lar­no­ścią dane­go pomy­słu (usłu­gi, funkcjonalności).

Model biznesowy jako kluczowe wymaganie na system IT

Model biz­ne­so­wy jest moim zda­niem tym, co two­rzy war­tość na ryn­ku. Nie jest żad­nym suk­ce­sem sama pasta do zębów. Sukcesem jest zaofe­ro­wa­nie wła­ści­wej pasty wła­ści­wej oso­bie, we wła­ści­wym miej­scu i cza­sie, po wła­ści­wej cenie a to jest wła­śnie defi­ni­cja mode­lu biz­ne­so­we­go (tak zwa­ne [[czte­ry P w mar­ke­tin­gu: Product, Place, Price, Promotion]]). Mistrzostwem inno­wa­cji jest zaś samo­dziel­ne stwa­rza­nie takich miejsc i potrze­by posia­da­nia tej pasty u klien­tów!. Nie jest to miej­sce na wykła­dy z mar­ke­tin­gu jed­nak war­to tu pod­kre­ślić, że tym co two­rzy war­tość jest wła­śnie okre­śle­nie co, gdzie, komu i na jakich warun­kach zaoferujemy.

Niezbędnym warun­kiem jest też zro­zu­mie­nie seg­men­ta­cji ryn­ku. Podstawową wie­dzą uzu­peł­nia­ją­cą sku­tecz­ną stra­te­gię jest wie­dza cze­go i komu nie ofe­ro­wać! Praktyka poka­zu­je, że jed­nym z czyn­ni­ków prze­wa­gi kon­ku­ren­cyj­nej są zaso­by dosto­so­wa­ne do mode­lu biz­ne­so­we­go, pro­ce­sów wewnętrz­nych. Brak dosto­so­wa­nia tych zaso­bów może być gwoź­dziem do trum­ny zachłan­nych mene­dże­rów. Klasycznym przy­kła­dem są pew­ne linie lot­ni­cze, któ­re mając mar­kę i zyski na ryn­ku dro­gich” prze­lo­tów posta­no­wi­ły wejść na rynek tanich linii. Niestety zaso­by tej fir­my były przy­go­to­wa­ne do kon­ku­ro­wa­nia na ryn­ku tra­dy­cyj­nych lotów i fir­ma nie była w sta­nie kon­ku­ro­wać z mają­cy­mi inne (tań­sze) zaso­by firm wyspe­cja­li­zo­wa­nych w tanich usłu­gach. Poniosła kleskę.

Podobne zja­wi­sko moż­na zaob­ser­wo­wać w przy­pad­ku zaso­bów jaki­mi są sys­te­my IT. Osobiście nie wie­rze, że duży sys­tem dla duże­go” może przy­nieść korzy­ści dużo mniej­szej fir­mie. Raczej ją przy­tło­czy a bench­mar­king (inni, duzi mają taki sys­tem, jak ja taki będę miał to dołą­czę do lide­rów) jest tu według mnie raczej złą prak­ty­ką. Byłem świad­kiem wdro­że­nia pew­ne­go zna­ne­go sys­te­mu adre­so­wa­ne­go dla dużych firm w sto­sun­ko­wo małej fir­mie. Liczba funk­cjo­nal­no­ści i ekra­nów” to potwier­dza­ła. Okazało się, że w dużej fir­mie, gdzie na na jeden ekran” (rolę) przy­pa­da­ło kil­ku pra­cow­ni­ków sys­tem się spraw­dzał. Jednak w fir­mie mniej­szej, koniecz­ność korzy­sta­nia z wie­lu roz­bu­do­wa­nych i róż­nych opcji przez jed­ną oso­bą peł­nią­ca w fir­mie wie­le ról, spo­wo­do­wa­ła, że stał sie gehen­ną obni­ża­jąc bar­dzo wydajność.

Tak więc, model biz­ne­so­wy, udo­ku­men­to­wa­ne pro­ce­sy i role powin­ny być klu­czo­wym wyma­ga­niem jakie sta­wiać nale­ży sys­te­mom IT. Powinny one wspie­rać model biz­ne­so­wy i stra­te­gię fir­my a nie być tyl­ko nowym faj­nym i wize­run­ko­wym zaso­bem. Moim zda­niem wyma­ga­nia na sys­te­mem powin­ny być ocze­ki­wa­niem wspar­cia dla mode­lu biz­ne­so­we­go a nie tyl­ko pro­stą listą kil­ku tysię­cy funkcjonalności.

Zapraszam do zapo­zna­nia się ze stresz­cze­niem rapor­tu z bada­nia wyko­na­ne­go przez Infovide-Matrix