ArchiMate i TOGAF. Czy nie do zastąpienia?

W popu­lar­nym ser­wi­sie o archi­tek­tu­rze kor­po­ra­cyj­nej (Enterprise Architecture, EA), EA Voice, poja­wił się arty­kuł na temat współ­ist­nie­nia” nota­cji ArchiMate oraz BPMN i UML:

Archimate was deli­be­ra­te­ly desi­gned to be map­pa­ble to BPMN and UML, but not to repla­ce them. Not paral­lel uni­ver­ses but com­ple­men­ta­ry ones.

Archimate is for model­ling at an Enterprise Architecture level of deta­il and not at the Solution Architecture and Software deve­lop­ment level of deta­il. BPMN and UML have much more deta­il in them than ArchiMate. Conversely neither BPMN or UML can repla­ce ArchiMate either.

(źr. ArchiMate, BPMN and UML toge­ther | EA Voices).

W pierw­szym zda­niu czy­ta­my, że ArchiMate celo­wo został tak pomy­śla­ny by moż­li­we było mapo­wa­nie na BPMN i UML a nie zastę­po­wa­nie tych nota­cji. Słusznie, gdyż w moich oczach pró­ba wal­ki z tymi nota­cja­mi była by pró­bą samo­bój­czą, mie­dzy inny­mi dla­te­go, że nota­cje rodem z OMG (BPMN i UML nimi są) to spe­cy­fi­ka­cje dar­mo­we, któ­rych moż­na uży­wać komer­cyj­nie bez żad­nych opłat licen­cyj­nych, cze­go nie­ste­ty nie moż­na powie­dzieć o ArchiMate (rocz­ne opła­ty, Licencja ArchiMate).

Dalej czy­ta­my, że ArchiMate to poziom archi­tek­tu­ry kor­po­ra­cyj­nej w prze­ci­wień­stwie do BPMN i UML, któ­re słu­żą do mode­lo­wa­nia szcze­gó­łów archi­tek­tu­ry i imple­men­ta­cji. Tu nie­ste­ty nie wiem to zna­czy poziom archi­tek­tu­ry kor­po­ra­cyj­nej”, oba­wiam się, że to jakiś magicz­ny, nie­zde­fi­nio­wa­ny poziom hipo­te­tycz­nie zastrze­żo­ny” dla EA, TOGAF i ArchiMate. Tu moim zda­niem ma miej­sce jakaś wal­ka” o rząd dusz, The Open Group podej­mu­je pró­by zawłasz­cza­nia poję­cia EA i mode­lo­wa­nia wyż­szych pozio­mów abs­trak­cji. Diagram powy­żej, poka­zu­ją­cy, miej­sce ArchiMate na tle BPMN i UML, to pró­ba takie­go zawłaszczenia.

The Open Group zda­je się igno­ro­wać to, że poję­cie archi­tek­tu­ry kor­po­ra­cyj­ne to nie ich pomysł (ich pomy­łem jest TOGAF, jeden z wie­lu sys­te­mów ram EA). Ignorują tak­że to, że nota­cje BPMN i UML nie mają ogra­ni­cze­nia na budo­wa­nie wyż­szych warstw abs­trak­cji, że ist­nie­je od kil­ku lat nota­cja BMM, któ­ra dosko­na­le (moim zda­niem lepiej niż ArchiMate 2.1) radzi sobie z mode­lo­wa­niem pozio­mu moty­wa­cji biz­ne­so­wej, w tym czyn­ni­ków wpły­wu i ryzy­ka. OMG zadba­ło bar­dzo dobrze o peł­ną wza­jem­ną kom­pa­ty­bil­ność (zgod­ność i nie­sprzecz­ność wspól­nych dla swo­ich nota­cji pojęć) cze­go nie­ste­ty nie moż­na powie­dzieć o zgod­no­ści ArchiMate i BPMN czy UML (pro­ble­my z inter­pre­ta­cją i mapo­wa­niem pojęć ArchiMate: Aktor, Rola, inter­fejs biz­ne­so­wy czy funk­cja apli­ka­cji). Więc teza jako­by nie dało się zastą­pić ArchiMate inny­mi nota­cja­mi, w mode­lo­wa­niu Architektury Korporacyjnej, jest moim zda­niem moc­no naciągana.

Poniżej porów­na­nie jakie wyko­na­łem po poja­wie­niu się ArchiMate 2.0:

Trzy warstwy modelowania

Więcej na temat uży­cia nota­cji OMG w mode­lach archi­tek­tu­ry kor­po­ra­cyj­nej w arty­ku­le Architektura Korporacyjna z OMG. Tak więc mnie widzę w TOGAF/ArchiMate jakiejś szcze­gól­nej prze­wa­gi na inny­mi podej­ścia­mi. Niewątpliwie jed­nak pro­ces cer­ty­fi­ka­cji i licen­cjo­no­wa­nia to rynek, o któ­ry The Open Group wal­czy i to aku­rat rozumiem.

Strategia krótkoterminowa

Ty razem krót­ko. Natchnął mnie arty­kuł kole­gi, tu frag­ment tego artykułu:

Przede wszyst­kim nie ist­nie­je coś takie­go jak ?stra­te­gia krót­ko­ter­mi­no­wa?. Otóż jest to kla­sycz­ny oksy­mo­ron ? ?prze­no­śne zesta­wie­nie pojęć o prze­ciw­staw­nym, wyklu­cza­ją­cym się wza­jem­nie zna­cze­niu, np. spie­szyć się powo­li, sucha woda; anty­lo­gia, epi­tet sprzeczny?[1]. […] Nie daj­my sobie robić wody z mózgu. Nie ist­nie­ją te wszyst­kie ?stra­te­gie? albo nie są stra­te­gia­mi. To jest opis spo­so­bu dzia­ła­nia, plan dzia­łań, któ­ry nie jest stra­te­gią. Przyrównując do woj­ny, nie są to stra­te­gie, tyl­ko tak­ty­ki pozwa­la­ją­ce na wygra­nie poszcze­gól­nych bitew. Nie powin­no się tego sto­so­wać nawet w odnie­sie­niu do poje­dyn­czej kam­pa­nii. To kam­pa­nia komu­ni­ka­cyj­na powin­na być pod­po­rząd­ko­wa­na stra­te­gii mar­ke­tin­go­wej. (źr. Strategia krót­ko­ter­mi­no­wa | Filozofia marketingu).

W tym miej­scu, tra­dy­cyj­nie, przy­ta­czam słow­ni­ko­we defi­ni­cje pojęć:

stra­te­gia ?prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie? ?dział sztu­ki wojen­nej obej­mu­ją­cy przy­go­to­wa­nie i pro­wa­dze­nie woj­ny oraz poszcze­gól­nych jej kam­pa­nii i bitew? (Słownik języ­ka pol­skie­go).

tak­ty­ka ?spo­sób postę­po­wa­nia mają­cy dopro­wa­dzić do osią­gnię­cia celu? ?dzie­dzi­na sztu­ki wojen­nej obej­mu­ją­ca teo­rię i prak­ty­kę pro­wa­dze­nia wal­ki przez jed­nost­ki róż­nych rodza­jów wojsk? (Słownik języ­ka pol­skie­go).

Nie usu­wa­łem defi­ni­cji z dzie­dzi­ny woj­sko­wo­ści, bo te ter­mi­ny mają woj­sko­wy rodo­wód. Jak widać, jest pew­na róż­ni­ca mię­dzy stra­te­gią a tak­ty­ką. Tak więc woj­ny to raczej lata i ogól­ne zało­że­nia ich wygry­wa­nia – stra­te­gia ich pro­wa­dze­nia. Poszczególne bitwy są kon­se­kwen­cją zasto­so­wa­nej tak­ty­ki, to raczej tygo­dnie lub co naj­wy­żej mie­sią­ce. Patrząc więc teraz na te defi­ni­cje przez pry­zmat np. wie­dzy o II Wojnie Światowej, jaką mamy np. ze szko­ły pod­sta­wo­wej, widać, że zwrot stra­te­gia krót­ko­ter­mi­no­wa” brzmi podob­nie nie­mą­drze jak chwi­lo­wa woj­na światowa”.

Stosowanie okre­ślo­nych ter­mi­nów zgod­nie z ich wła­ści­wy­mi zna­cze­nia­mi ma głę­bo­ki sens. Rzecz w tym, by budo­wa­ny opis” (np. biz­nes plan, pro­spekt emi­syj­ny, kon­tekst pro­jek­tu IT), był nie tyl­ko powszech­nie zro­zu­mia­ły” ale o to by w ogó­le miał jakiś sens. Bo to, że ład­nie i mądrze brzmi” w kor­po­ra­cyj­nej doku­men­ta­cji to na dłuż­szą metę za mało.

Pojęcia te, stra­te­gia i tak­ty­ka, mają swo­je odzwier­cie­dle­nie tak­że w sfor­ma­li­zo­wa­nej for­mie w two­rze­niu mode­lu moty­wa­cji biz­ne­so­wej (BMM). Tu uży­to oba te ter­mi­ny i poka­za­no typo­wy kon­tekst ich użycia:

Startegia i taktyka

Jak widać (powyż­szy dia­gram wyko­na­ny zgod­nie z regu­ła­mi nota­cji BMM (http://​www​.omg​.org/​s​p​e​c​/​B​MM/) for­mal­ne, stan­dar­do­we defi­ni­cje i ich uży­cie w tym mode­lu, tak­że poka­zu­ją, że tak­ty­ka to dzia­ła­nia reali­zo­wa­ne w rela­tyw­nie krót­kim okre­sie, celem jest wspie­ra­nie przy­ję­tej stra­te­gii orga­ni­za­cji. Ta ostat­nia, to dłu­go­ter­mi­no­wo usta­la­ne regu­ły biz­ne­so­we, któ­re wyzna­cza­ją tak­ty­kę dzia­ła­nia. Strategia dzia­ła­nia jest kon­se­kwen­cją misji orga­ni­za­cji, wspie­ra reali­za­cję celów. Taktyka to osią­ga­nie kon­kret­nych i mie­rzal­nych dzia­łań na rzecz celów biznesowych.

Kolejnym eta­pem ana­li­zy biz­ne­so­wej i pla­no­wa­nia jest ana­li­za SWOT, któ­rą tak­że doku­men­tu­je­my (moż­na) nota­cją BMM, co opi­sa­łem już wcze­śniej w arty­ku­le A po co nam ten SWOT.

Architektura korporacyjna a strategia wzrostu

Jakiś czas temu zna­la­złem taką oto statystykę:

Pod koniec 2012 roku fir­ma ana­li­tycz­na Gartner prze­pro­wa­dzi­ła ogól­no­świa­to­we bada­nia wśród 333 osób pia­stu­ją­cych funk­cje pre­ze­sa, pre­zy­den­ta lub dyrek­to­ra generalnego.

Gartner chart priorytety zarządzającej kadry 2013

Zdaniem ana­li­ty­ków Gartnera jest to moż­li­we jedy­nie poprzez skon­cen­tro­wa­nie się na klien­cie ? czy­li nale­ży zaini­cjo­wać dzia­ła­nia (nie tyl­ko infor­ma­tycz­ne, lecz przede wszyst­kim orga­ni­za­cyj­ne) w orga­ni­za­cji okre­ślo­ne pozwa­la­ją­ce stać się jej ?custo­mer cen­tric?. (Czym jest ?Customer Centric Enterprise Architecture?? | Architektura Korporacyjna).

A teraz zostaw­my Gartnera i zasta­nów­my się nad powyż­szą ankie­tą. Załóżmy, że model moty­wa­cji biz­ne­so­wej moż­na uznać za dobrze tłu­ma­czą­cy związ­ki pomię­dzy cela­mi fir­my a strategią:

BMMOvierwiev

Patrząc na powyż­sze moż­na przy­jąć, że dzia­ła­nia ope­ra­cyj­ne na pew­no mają wpływ na sku­tecz­ność dzia­łań z zakre­su wzro­stu jako­ści i sku­tecz­no­ści w obsłu­dze klien­tów. Patrząc zaś na wyni­ki ankiet moż­na uznać, że prio­ry­te­tem jest wzrost, a wzrost fir­my to głów­nie wzrost przy­cho­dów. Jeżeli uznać, że ankie­to­wa­ni nie mie­li na myśli kosme­tycz­nych wzro­stów a rynek jest nasy­co­ny, to moim zda­niem, duży wzrost” jest moż­li­wy głów­nie poprzez prze­ję­cia. Strategia prze­jęć nie­wie­le ma jed­nak wspól­ne­go z wewnętrz­ną spraw­no­ścią operacyjną.

Tak więc oso­bi­ście nie widzę bez­po­śred­nie­go związ­ku pomię­dzy archi­tek­tu­rą kor­po­ra­cyj­ną (któ­rej wdra­ża­nie jest raczej tak­ty­ką osią­ga­nia więk­szej spraw­no­ści ope­ra­cyj­nej) a stra­te­gią (znacz­ne­go) wzro­stu… ale może to temat do cie­ka­wej dyskusji…

Na szczę­ście dla archi­tek­tu­ry kor­po­ra­cyj­nej” pozo­sta­łe prio­ry­te­ty: docho­do­wość, klient, kosz­ty, mar­ke­ting i sprze­daż, to jak naj­bar­dziej ele­men­ty zależ­ne od spraw­no­ści ope­ra­cyj­nej a tu budu­je­my tak­ty­ki osią­ga­nia celów stra­te­gicz­nych. Architektura Korporacyjna, to jest, jej budo­wa i wdra­ża­nie, to jed­na z moż­li­wych tak­tyk. Jaka stra­te­gie wspie­ra? W przy­pad­ku tak­ty­ki obni­ża­nia kosz­tów w obsza­rze wdra­ża­nia nowych roz­wią­zań i zarzą­dza­nia ich zmia­ną, AK jak naj­bar­dziej wpi­su­je się tę tak­ty­kę. Ograniczając się do sys­te­mów infor­ma­cyj­nych, obec­ny rynek jest zmien­ny i zmie­nia­ją się tak­ty­ki sprze­da­ży firm, zarzą­dza­nia pro­duk­ta­mi. Zmiana tej tak­ty­ki pra­wie zawsze nie­sie za sobą potrze­bę wpro­wa­dze­nia zmian do sys­te­mu infor­ma­cyj­ne­go fir­my. Każdorazowe pro­wa­dze­nie kolej­nej nowej ana­li­zy przed-wdro­że­nio­wej” to tak na praw­dę mar­no­tra­wio­ne środ­ki, bo kolej­na nowa ana­li­za wyma­gań w sytu­acji gdy wpro­wa­dza­my jedy­nie zmia­nę, to trosz­kę jak zama­wia­nie nowe­go pro­jek­tu archi­tek­to­nicz­ne­go tyl­ko po to, by prze­sta­wić kil­ka ścian i wsta­wić nową w domu, któ­ry już stał i pozostanie.

Proszę zauwa­żyć, że prak­tycz­nie każ­da ana­li­za przed-wdro­że­nio­wa ma w swo­im zakre­sie ana­li­zę sta­nu obec­ne­go”. Czy na praw­dą każ­dy kolej­ny dostaw­ca musi to robić od zera? Nie sądzę. W zasa­dzie stan obec­ny” powi­nien być doku­men­tem na tacy” po stro­nie zama­wia­ją­ce­go nowe opro­gra­mo­wa­nie. Ale utrzy­my­wa­nie takiej doku­men­ta­cji kosz­tu­je! Owszem, ale kosz­tu­je znacz­nie mniej niż każ­do­ra­zo­we jej wytwa­rza­nie od zera…

A po co nam ten SWOT

W poprzed­nim arty­ku­le (Ile jest tych wyma­gań na sys­tem ERP) pisa­łem, że nad­mier­ne sku­pia­nie się na szcze­gó­łach nie tyl­ko nie wno­si nicze­go do pro­jek­tu ale nie raz wręcz go nisz­czy. Dotyczy to zresz­tą ogól­nie pro­jek­tów ana­li­tycz­nych, nie tyl­ko w dzie­dzi­nie IT.

Na stro­nach jed­ne­go z bar­dziej poczyt­nych ser­wi­sów o ana­li­zie IT – http://​www​.moder​na​na​lyst​.com – poja­wił się jakiś czas temu cie­ka­wy arty­kuł o ana­li­zie SWOT. Autor opi­su­je jak tę ana­li­zę prze­pro­wa­dzić, ja opi­szę jak jej użyć w ana­li­zie sys­te­mo­wej orga­ni­za­cji i spe­cy­fi­ko­wa­niu wyma­gań. We wstę­pie arty­ku­łu czytamy:

Much of the busi­ness of busi­ness ana­ly­sis is in the deta­ils, and most busi­ness ana­ly­sts are by natu­re deta­iled, sys­te­ma­tic thin­kers. Occasionally most orga­ni­za­tions, tho­ugh, have times when they can?t see the forest for the tre­es. That is when the high-level, bro­ad-ran­ge view that SWOT Analysis affords is just as use­ful in avo­iding costly errors as unam­bi­gu­ous requ­ire­ments. (What is SWOT Analysis?).

W dużym uprosz­cze­niu: wie­lu ana­li­ty­ków sku­pia się od razu na szcze­gó­łach, bo to natu­ral­ne ele­men­ty nasze­go bez­po­śred­nie­go oto­cze­nia, nie potra­fią spoj­rzeć na orga­ni­za­cję z dale­ka, nie potra­fią dostrzec lasu patrząc na poje­dyn­cze drze­wa”. Analiza SWOT pozwa­la spoj­rzeć na pro­blem z innej, wyż­szej per­spek­ty­wy, sze­rzej, dzię­ki cze­mu jest bar­dzo uży­tecz­na w uni­ka­niu kosz­tow­nych błę­dów jaki­mi są nie­jed­no­znacz­ne wymagania. 

Jednym z zabój­ców pro­jek­tów” (a kon­kret­nie ich budże­tów i har­mo­no­gra­mów) są tak zwa­ne wyma­ga­nia osie­ro­co­ne i wyma­ga­nia nie­od­kry­te na eta­pie ana­li­zy. Są to odpo­wied­nio wyma­ga­nia zgło­szo­ne do spe­cy­fi­ka­cji i zre­ali­zo­wa­ne, z któ­rych następ­nie nikt nie korzy­sta, oraz te odkry­wa­ne dopie­ro na eta­pie wdro­że­nia. Nie da się zapro­jek­to­wać” lasu myśląc o drze­wach bo celem jest las, a nie kon­kret­ne drzewa. 

Jeden pro­jekt może mieć jeden cel, jeże­li jed­nak celem” ma być każ­dy kolej­ny krok, podróż nigdy się nie kończy.

Wymagania o jakich pisa­łem w poprzed­nim arty­ku­le to wyma­ga­nia wobec roz­wią­za­nia, któ­rym było jakieś opro­gra­mo­wa­nie”. Jednak to dru­gi etap ana­li­zy. Generalnie naj­pierw ana­li­zu­je się i defi­niu­je wyma­ga­nia biz­ne­so­we, a potem dopie­ro wyma­ga­nia wobec roz­wią­za­nia, wie­dząc już jakie warun­ki musi ono speł­niać. Przykładowym wyma­ga­niem biz­ne­so­wym może być pod­nie­sie­nie jako­ści obsłu­gi klien­ta (co by to tu teraz nie mia­ło zna­czyć), a dopie­ro reko­men­do­wa­nym roz­wią­za­niem może być, np. opro­gra­mo­wa­ne CRM albo reor­ga­ni­za­cja dzia­łu sprze­da­ży (co z resz­tą wie­le firm robi znacz­nie czę­ściej niż kupu­je nowy CRM ;)).

Wiele firm rzu­ca się na pro­jek­ty od razu z zało­że­niem, że musi­my mieć nowe opro­gra­mo­wa­nie”. Co nie raz bywa dużym błę­dem i masą zmar­no­wa­nych środ­ków. Jak się przed tym ustrzec?

Warto popa­trzeć na orga­ni­za­cję i kon­kret­ny pro­blem z pew­nej per­spek­ty­wy, z wyż­sze­go pozio­mu abs­trak­cji, niż tyl­ko sto­jąc mię­dzy biur­ka­mi widząc kon­kret­ne spra­wy i ludzi się nimi zaj­mu­ją­cy­mi. Narzędziem pozwa­la­ją­cym wznieść” się na wyż­szy poziom abs­trak­cji jest wła­śnie ana­li­za SWOT. Analiza ta pole­ga na ziden­ty­fi­ko­wa­niu czte­rech klu­czo­wych ele­men­tów wpły­wa­ją­cych na orga­ni­za­cję : czyn­ni­ki zewnętrz­ne jaki­mi są oka­zje i zagro­że­nia oraz czyn­ni­ki wewnętrz­ne czy­li sil­ne i sła­be stro­ny orga­ni­za­cji. Tu waż­na infor­ma­cja, ana­li­za SWOT to ana­li­za cze­goś kon­kret­ne­go” w okre­ślo­nym śro­do­wi­sku”. Czynniki wewnętrz­ne opi­su­ją to coś”, zaś czyn­ni­ki zewnętrz­ne opi­su­ją śro­do­wi­sko tego cze­goś”. Można tak ana­li­zo­wać orga­ni­za­cję (np. fir­ma i jej oto­cze­nie ryn­ko­we) czy też pro­duk­ty pro­jek­tów (np. kon­kret­ne opro­gra­mo­wa­nie w fir­mie) ale nie sam pro­jekt wdro­że­nio­wy czy pro­ces (one nie są czymś”).

Analiza SWOT może być ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji. Analiza SWOT to np. wstęp do opra­co­wa­nia reko­men­da­cji w odpo­wie­dzi na pro­blem biz­ne­so­wy. SWOT to iden­ty­fi­ka­cja i wpływ okre­ślo­nych ele­men­tów, pozo­sta­je oce­na tego jaki, i na co. Dlatego ana­li­za SWOT sta­ła się czę­ścią tak zwa­ne­go Modelu Motywacji Biznesowej (BMM). Model ten pozwa­la lepiej zro­zu­mieć oto­cze­nie pro­ble­mu” oraz śla­do­wać” ele­men­ty ziden­ty­fi­ko­wa­ne w ana­li­zie SWOT na kon­kret­ne pro­ce­sy biz­ne­so­we i struk­tu­rę organizacyjną.

SWOT

(dia­gram BMM: ana­li­za SWOT i przej­ście na pro­ce­sy biz­ne­so­we opr. wła­sne autora).

Z poprzed­nich moich arty­ku­łów wie­my, że wyma­ga­nia wobec roz­wią­za­nia (w tym wobec opro­gra­mo­wa­nia) mają swo­je źró­dło w pro­ce­sach biz­ne­so­wych i ich wyko­naw­cach. Jednak spi­sa­nie ich w posta­ci dekla­ra­tyw­nej listy pod­czas warsz­ta­tów i wywia­dów, pro­wa­dzi do powsta­nia dłu­giej i prak­tycz­nie nie­we­ry­fi­ko­wal­nej listy o jakiej pisa­łem w Ile jest tych wyma­gań na sys­tem ERP.

Lekarstwem na pro­blem jest wery­fi­ka­cja (two­rze­nie) listy wyma­gań wobec roz­wią­za­nia. Weryfikacja (dia­gram powy­żej) pole­ga na tak zwa­nym śla­do­wa­niu. Śladowanie to wywo­dze­nie każ­de­go wyma­ga­nia z pier­wot­nej potrze­by, jaką jest tak­ty­ka, któ­rą przy­ję­to by osią­gnąć cel. Taktyka ma swo­je źró­dło w stra­te­gii (tak­ty­ka imple­men­tu­je stra­te­gię). Strategia (jej skon­stru­owa­nie) jest odpo­wie­dzią na oka­zję ryn­ko­wą, któ­ra jest przy­czy­ną, dla któ­rej podej­mu­je­my dzia­ła­nia ryn­ko­we. Okazja ryn­ko­wa daje szan­sę na zysk” (pro­dukt dają­cy docho­dy) w posta­ci dostar­cze­nia swo­je­mu oto­cze­niu war­to­ści doda­nej. Warto tu zwró­cić uwa­gę na to, że ele­men­ty ana­li­zy SWOT tak­że powin­ny mieć swo­je uza­sad­nie­nie w posta­ci iden­ty­fi­ka­cji zewnętrz­nych i wewnętrz­nych czyn­ni­ków wpły­wu. Słabe stro­ny oraz zagro­że­nia powin­ny iden­ty­fi­ko­wać ryzy­ka pro­jek­tu. Analizę uzna­je­my za zakoń­czo­ną po ziden­ty­fi­ko­wa­niu wszyst­kich zna­nych klu­czo­wych czyn­ni­ków wpły­wu i ryzyk. Analiza taka jest ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji.

Wielu wła­ści­cie­li firm, ich zarzą­dy, pomi­ja ten etap w pro­jek­tach z uwa­gi na swo­je prze­ko­na­nie, że ich dotych­cza­so­we dzia­ła­nia i chęć ich kon­ty­nu­acji, nie wyma­ga­ją żad­nej korek­ty, ocze­ku­ją poda­nia na tacy opi­su narzę­dzia, któ­re­go – jak sądzą – potrze­bu­ją. Zachowują się jak pacjen­ci, któ­rzy mimo, że ostat­nie bada­nia robi­li wie­le lat temu, nie dopusz­cza­ją myśli, że lekarz może im prze­pi­sać na gorącz­kę coś inne­go niż kolej­ną aspi­ry­ną. Bywa, że zbyt póź­no odkry­wa­ją, że tym razem to nie było kolej­ne przeziębienie.

Praktyka poka­zu­je, coś bar­dzo cie­ka­we­go: zamiast pro­wa­dzić żmud­ne i kosz­tow­ne wywia­dy, sesje warsz­ta­to­we, burze mózgów, któ­rych pro­duk­tem jest dłu­ga lista dość przy­pad­ko­wych pomy­słów na wyma­ga­nia”, war­to docho­dzić do listy wyma­gań meto­dą od ogó­łu do szcze­gó­łu, wła­śnie od pozio­mu ana­li­zy SWOT (opar­tej na wizji i misji orga­ni­za­cji). Takie podej­ście od razu, naj­krót­szą dro­gą, pro­wa­dzi – przez model pro­ce­sów biz­ne­so­wych – do bar­dzo spój­nej i kom­plet­nej, bez nad­mia­ro­wych (osie­ro­co­nych) wyma­gań, spe­cy­fi­ka­cji wyma­gań wobec roz­wią­za­nia. Każde wyma­ga­nie ma swo­je uza­sad­nie­nie (śla­do­wa­nie) w stra­te­gii, nie ma ryzy­ka, że coś pomi­nie­my, bo tu wery­fi­ka­to­rem jest model pro­ce­su (kom­plet­na i spraw­dzo­na lista czyn­no­ści). Koszty uzy­ska­nia spe­cy­fi­ka­cji wyma­gań tą meto­dą, są znacz­nie niż­sze niż tra­dy­cyj­ny­mi (wywia­dy) meto­da­mi bo: nie anga­żu­je­my cza­su całych zespo­łów pra­cow­ni­ków na wywia­dy i warsz­ta­ty, ryzy­ko bar­dzo kosz­tow­nych pomi­nięć i nad­mia­rów jest mini­mal­ne, licz­ba ite­ra­cji w takim pro­jek­cie zbli­ża się do JEDNEJ! i nie trze­ba odkry­wać wyma­gań meto­dą kosz­tow­nych pro­to­ty­pów na eta­pie przed­wcze­snej imple­men­ta­cji. Jedyny pro­blem” to jej prze­pro­wa­dze­nie, mimo poku­sy”, roz­po­czę­cia pro­jek­tu od razu bo nie ma cza­su na ana­li­zę, i szko­da na to pieniędzy”.

klient, CRM, wróg, sprzedaż, wróg

Słownik pojęć biznesowych czyli po co nam przestrzeń nazw

Niedawno jeden z arty­ku­łów zakoń­czy­łem akapitem:

Pierwszy etap ana­li­zy biz­ne­so­wej to mię­dzy inny­mi opra­co­wa­nie biz­ne­so­we­go słow­ni­ka pojęć (model poję­cio­wy)… (Słownik pojęć biz­ne­so­wych: naj­bar­dziej pod­sta­wo­we wyma­ga­nie).

Nie każ­da jed­nak ana­li­za to ana­li­za, któ­rej celem jest opi­sa­nie wyma­gań i pro­jek­to­wa­nie opro­gra­mo­wa­nia. Jednak każ­da ana­li­za pro­ble­mu, pro­wa­dzo­na jako ana­li­za sys­te­mo­wa, ma usta­lo­ne eta­py postępowania:

  1. for­mu­ło­wa­nie problemu,
  2. opra­co­wa­nie mode­lu ana­li­zo­wa­ne­go zja­wi­ska (w tym dowód jego poprawności!),
  3. wykry­cie i testo­wa­nie wariantów,
  4. ana­li­za wyni­ków i rekomendacje,
  5. pro­jek­to­wa­nie rozwiązania.

Powyższe to, opar­te na kla­sycz­nej ana­li­zie sys­te­mo­wej, postę­po­wa­nie. Dzisiaj sku­pię się głów­nie na punk­cie opra­co­wa­nie mode­lu” gdyż bazą do jego two­rze­nia jest wła­śnie słow­nik pojęć. 

Jak nie raz tu pisa­łem, mode­le two­rzo­ne są z uży­ciem nota­cji. Notacja to sys­tem poję­cio­wy, pew­na prze­strzeń nazw (ang. name­spa­ce). Notacje mogą być gra­ficz­ne, wte­dy każ­de poję­cie ma przy­po­rząd­ko­wa­ny okre­ślo­ny uni­kal­ny sym­bol, two­rzo­ne z nich kon­struk­cje to dia­gra­my, będą­ce odpo­wied­ni­kiem zdań (popraw­ny dia­gram coś mówi”). Tak więc tyle krót­kie­go wprowadzenia.

Gdzie te słowniki?

Pierwszym eta­pem ana­li­zy sys­te­mo­wej jest zde­fi­nio­wa­nie pro­ble­mu, ten jest zwią­za­ny zawsze z okre­ślo­nym przed­mio­tem. Przedmiot ana­li­zo­wa­ny – sys­tem – musi mieć ści­śle okre­ślo­ne gra­ni­ce oraz jed­no­znacz­ny opis będą­cy mode­lem tego sys­te­mu. Aby taki opis mógł powstać, jak się zapew­ne już domy­śla­my, musi­my dys­po­no­wać zbio­rem jed­no­znacz­nych pojęć go opi­su­ją­cych – musi­my mieć ade­kwat­ną do pro­ble­mu i jego dzie­dzi­ny prze­strzeń nazw. Model sys­te­mu to jed­no­znacz­na defi­ni­cja tego czym jest i jak się zacho­wu­je (jak reagu­je na bodź­ce). Opis taki wyko­na­ny języ­kiem natu­ral­nym, nie nada­je się do ana­li­zy, język natu­ral­ny nie jest for­mal­ną prze­strze­nią nazw, i z regu­ły nie pozwa­la na jed­no­znacz­ne opi­sa­nie cze­goś (w złym mode­lu poję­cio­wym zna­cze­nia pojęć nie pokry­wa­ją całej prze­strze­ni, nakła­da­ją się).

przestrzen nazw

Tak więc do opra­co­wa­nia mode­lu wyma­ga­na jest nota­cja. Skąd ja wziąć? Jak ją wybrać? Jak widać, nota­cja musi być dosto­so­wa­na do dzie­dzi­ny pro­ble­mu. Notacje stan­dar­do­we, z regu­ły, są dość ogól­ne gdyż muszą zacho­wy­wać pew­ną uni­wer­sal­ność. Notacje stan­dar­do­we są dzie­dzi­no­we i tu dzie­dzi­ną tą jest okre­ślo­ny para­dyg­mat. Najbardziej zna­ny­mi nota­cja­mi sto­so­wa­ny­mi w ana­li­zie sys­te­mo­wej z obsza­ru zarzą­dza­nia i sys­te­mów infor­ma­cyj­nych są UML i BPMN. UML repre­zen­tu­je para­dyg­mat obiek­to­wy mówią­cy, że świat skła­da się ze współ­pra­cu­ją­cych obiek­tów mają­cych okre­ślo­ne cechy i moż­li­wo­ści (umie­jęt­no­ści). BPMN repre­zen­tu­je para­dyg­mat pro­ce­so­wy mówią­cy, że świat to zacho­dzą­ce w cza­sie pro­ce­sy two­rze­nia lub prze­kształ­ca­nia rze­czy­wi­sto­ści (nale­ży jed­nak dodać, że UML to tak­że dia­gra­my dyna­mi­ki sys­te­mu, mają­ce zwią­zek z para­dyg­ma­tem pro­ce­so­wym, nie nale­ży jed­nak mylić tego z poję­ciem pro­ces biznesowy”).

Poza tymi dwo­ma nota­cja­mi (moim zda­niem głów­ny­mi) mamy wie­le innych, spe­cy­ficz­nych dla okre­ślo­nych dzie­dzin i para­dyg­ma­tów, sys­te­mów poję­cio­wych (np. BMM czy SBVR).

Tak więc każ­da ana­li­za, powin­na być poprze­dzo­na wybo­rem nota­cji, któ­re zosta­ną w niej uży­te. Na pew­nym okre­ślo­nym pozio­mie abs­trak­cji wystar­czą poję­cia dostęp­ne w nota­cjach stan­dar­do­wych. Nie raz może się jed­nak zda­rzyć, że ana­li­za pro­ble­mu doty­ka szcze­gó­łów, któ­rych roz­róż­nia­nie nie jest moż­li­we z pomo­cą stan­dar­do­wej nota­cji. Każdy kon­kret­ny pro­blem ma swo­je kon­kret­ne śro­do­wi­sko dzie­dzi­no­we, może się zda­rzyć, że bar­dziej szcze­gó­ło­we niż uni­wer­sal­ne nota­cje. Wtedy nale­ży roz­sze­rzyć zasto­so­wa­ną nota­cję (prze­strzeń poję­cio­wą). Rozszerzanie to jed­nak wyma­ga prze­strze­ga­nia pew­nej zasa­dy: roz­sze­rze­nie to może pole­gać wyłącz­nie na zastę­po­wa­niu sta­rych” pojęć zesta­wem ich spe­cja­li­za­cji („sta­re” poję­cie sta­je się abs­trak­cją) oraz zestaw takich spe­cja­li­za­cji tak­że musi sta­no­wić lokal­ną prze­strzeń nazw. Taka dodat­ko­wa prze­strzeń nazw nazy­wa się pro­fi­lem nota­cji. Tworzenie pro­fi­li jest dość trud­nym zaję­ciem z uwa­gi na wymóg zacho­wa­nia opi­sa­nych for­ma­li­zmów prze­strze­ni poję­cio­wych (pro­fil tak­że musi mieć okre­ślo­na seman­ty­kę i syn­tak­ty­kę, któ­ra to nie może koli­do­wać z tą w nota­cji bazowej).

I tu docho­dzi­my do sed­na: aby stwo­rzyć pro­fil nota­cji – co cza­sa­mi bywa nie­zbęd­ne dla jako­ści ana­li­zy – nale­ży naj­pierw zbu­do­wać słow­nik pojęć z dzie­dzi­ny ana­li­zo­wa­ne­go pro­ble­mu, spraw­dzić czy zasto­so­wa­na nota­cja pozwa­la na roz­wią­za­nie posta­wio­ne­go pro­ble­mu z uży­ciem stan­dar­do­wej wer­sji nota­cji. Bez takie­go słow­ni­ka ana­li­za może być nie­wy­ko­ny­wal­na, albo jej jakość będzie bar­dzo niska – czy­taj: uży­cie jej wyni­ków będzie bar­dzo ryzykowne.

Takie pro­fi­le ma np. nota­cja BPMN w celu prze­cho­dze­nia z mode­li abs­trak­cyj­nych na wyko­ny­wal­ne, stan­dar­do­wo ope­ru­je się np. jed­nym poję­ciem czyn­ność, jeże­li potrzeb­ne jest ich roz­róż­nia­nie, prze­cho­dzi­my na sto­so­wa­nie sym­bo­li ozna­czo­nych jako czyn­ność ode­bra­nia komu­ni­ka­tu, czyn­ność wysła­nia komu­ni­ka­tu, czyn­ność manu­al­na, itp.. Dla nota­cji UML powsta­ło wie­le pro­fi­li np. dla kon­kret­nych języ­ków pro­gra­mo­wa­nia i ich środowisk.

Krótka lista pięciu rzeczy, które nie są regułami biznesowymi

Częsty pro­blem, z jakim się spo­ty­kam, to zja­wi­sko utra­ty pano­wa­nia nad zło­żo­no­ścią” (ana­li­zy, doku­men­ta­cji, itp.). Winnymi są zresz­tą sami zama­wia­ją­cy, nie­po­tra­fią­cy myśleć abs­trak­cyj­nie. Nie cho­dzi o to, że powin­ni umieć, cho­dzi o to, że nie uzna­ją tego, nie potra­fią. Paradoksalnie, pro­gra­mi­ści w więk­szo­ści tak­że nie potra­fią myśleć abstrakcyjnie.

Beneficjenci opro­gra­mo­wa­nia sta­ra­ją się opi­sać swo­je ocze­ki­wa­nia przez pry­zmat swo­jej szcze­gó­ło­wej wie­dzy o pra­cy jaką wyko­nu­ją, pomi­ja­jąc w swych opi­sach nie­ste­ty jej oczy­wi­ste” dla nich ele­men­ty (z regu­ły naj­waż­niej­sze). Programiści zaś patrzą na swo­ją pra­cę dokład­nie tak samo: chcą usły­szeć co mają zapro­gra­mo­wać”. Pierwsi godzi­na­mi opo­wia­da­ją o zna­nych im przy­pad­kach i meto­dach wytwo­rze­nia jed­ne­go doku­men­tu, dru­dzy już w pierw­szej minu­cie spo­tka­nia z klien­ta­mi pyta­ją o typ pola” tej formatki.

W efek­cie zama­wia­ją­cy wyar­ty­ku­łu­je set­ki wyma­gań a deve­lo­per zada pyta­nia o kolej­ne bra­ku­ją­ce set­ki szcze­gó­łów tych setek wyma­gań. Zupełnie nie­po­trzeb­nie w pierw­szych fazach projektu.

Wśród wie­lu takich szcze­gó­łów są róż­ne­go rodza­ju ogra­ni­cze­nia nazy­wa­ne regu­ła­mi biz­ne­so­wy­mi. Poniżej przy­kła­do­we śmie­cio­we” zapi­sy w wymaganiach:

1. Assigning valu­es to variables.

2. Asserting man­da­to­ry GUI fields.

3. Specifying which data can be vie­wed by which users.

4. Expressing which docu­ments are to be routed to which queues.

5. Orchestrating tasks assi­gn­ments in an exe­cu­tion environment.

(źr. A Quick 5‑Item List of What Are Not Business Rules! ? Ron Ross on Business Rules).

Po pierw­sze są to albo ele­men­ty zwią­za­ne z imple­men­ta­cja (czy­li ostat­ni etap pra­cy) albo ele­men­ty sce­na­riu­szy pra­cy z GUI. Ani jed­no ani dru­gie to nie regu­ły biz­ne­so­we, bo te – jak sama nazwa wska­zu­je – ogra­ni­cza­ją (regu­lu­ją) dzia­ła­nia biz­ne­so­we (ludzi) a nie opro­gra­mo­wa­nia. Oprogramowanie to tyl­ko narzę­dzie pra­cy, ma okre­ślo­ne cechy i funk­cjo­nal­no­ści i nie może koli­do­wać z biz­ne­sem (jego regu­ła­mi), to tyl­ko narzę­dzie w rękach ludzi.

Reguły biznesowe

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​B​u​s​i​n​e​s​s​A​n​a​l​y​s​t​H​u​m​o​r​/​t​a​b​i​d​/​2​1​8​/​D​e​f​a​u​l​t​.​a​s​p​x​?​A​r​t​i​c​l​e​T​y​p​e​=​A​r​t​i​c​l​e​V​i​e​w​&​A​r​t​i​c​l​e​I​D​=​2​471

Reguła biz­ne­so­wa nie powin­na zawie­rać w sobie kry­te­riów podej­mo­wa­nia decy­zji. Reguła biz­ne­so­wa nie jest ele­men­tem algo­ryt­mi­za­cji, wska­zu­je kie­dy i co, a nie jak, ma być wyko­na­ne. Należy zawsze pamię­tać, że model orga­ni­za­cji, sys­tem któ­re­go ele­men­ta­mi są tak­że ludzie, nie może od tych ludzi abs­tra­ho­wać. Dlatego dia­gra­my zawie­ra­ją­ce wręcz algo­ryt­micz­ną szcze­gó­ło­wość być może mają sens, tam gdzie szu­ka­my 100%-towej auto­ma­ty­za­cji, albo nie mają żad­ne­go sensu.

Na stro­nie Business Rules Group moż­na prze­czy­tać Manifest Reguł Biznesowych (tak­że w pol­skiej wer­sji ;)). Dlaczego aku­rat to pole­cam? Bo kon­sor­cjum to wpro­wa­dzi­ło do OMG stan­dard Semantics Of Business Vocabulary And Business Rules (SBVR), któ­ry jest zhar­mo­ni­zo­wa­ny z inny­mi nota­cja­mi, w szcze­gól­no­ści z BMM, BPMN i UML. Dzięki temu poję­cie regu­ły biz­ne­so­wej ma tę sama defi­ni­cję na wyso­kim pozio­mie abs­trak­cji ana­li­zy biz­ne­so­wej i na pozio­mie np. busi­ness rules engi­ne” na pozio­mie implementacji.

Korzyści ze sto­so­wa­nia stan­dar­du SBVR to przede wszyst­kim pano­wa­nie nad szcze­gó­ła­mi od same­go począt­ku pro­jek­tu. Od same­go począt­ku ana­li­zy i pro­jek­to­wa­nia logi­ki sys­te­mu nale­ży sku­pić się na tym co i po co” a nie jak”. Zajmowanie się pyta­nia­mi jak” (naj­gor­sze pyta­nie ana­li­zy: jak Państwo to robią) na samym począt­ku, pro­wa­dzi do zgro­ma­dze­nia ogrom­nej ilo­ści nad­mia­ro­wych szcze­gó­łów, któ­re zamu­la­ją pra­ce wszyst­kich człon­ków zespo­łu pro­jek­to­we­go. Szczegóły, te któ­rych zna­jo­mość fak­tycz­nie wno­si war­tość, nale­ży ana­li­zo­wać na koń­cu, wte­dy – mając szkie­let całe­go pro­jek­tu – wie­my któ­re mają jakie­kol­wiek zna­cze­nie. Po dru­gie więk­szość szcze­gó­łów obec­nie wyko­ny­wa­nej pra­cy i tak ule­gnie zmia­nie w związ­ku z wdra­ża­niem nowe­go narzędzia.

Tak więc: od ogó­łu do szcze­gó­łu, sys­te­ma­tycz­nie i z peł­nym zro­zu­mie­niem na każ­dym eta­pie, a nie spi­sze­my wszyst­ko co wie­my a potem zobaczymy”.