Architektura korporacyjna z OMG​.org

Swego cza­su, gdy dowie­dzia­łem się, że nota­cja ArchiMate ma jed­nak być chro­nio­na pra­wa­mi autor­ski­mi przez The Open Group a koszt cer­ty­fi­ka­cji TOGAF to cał­kiem nie­zły haracz, napisałem:

Przyznaję, że rezy­gnu­ję z tej nota­cji jak i z TOGAF?a jako meto­dy­ki. W dwóch pro­jek­tach spraw­dzi­ła się moja hipo­te­za: mode­lo­wa­nie i ana­li­za war­stwy biz­ne­so­wej i IT oraz oce­na wza­jem­nych zależ­no­ści nie wyma­ga nowej nota­cji a dobrze wyko­na­ne­go mode­lu w już zna­nych, wystar­czą nota­cje BMM, BPMN, UML oraz narzę­dzie potra­fią­ce zarzą­dzać rela­cja­mi pomię­dzy obiek­ta­mi na tych mode­lach? zary­zy­ku­ję tezę, że jest to efek­tyw­niej­sze niż two­rze­nie kolej­nych dzie­sią­tek dia­gra­mów ArchiMate. (Pokazać wię­cej z sen­sem? ).

Podstawowym powo­dem jest to, że skąd­inąd dobry pomysł, jakim jest sama archi­tek­tu­ra kor­po­ra­cyj­na, jest obkła­da­ny ide­olo­gią (mar­ke­ting?!) i opła­ta­mi, któ­rych nie rozu­miem (albo raczej rozu­miem, ale nie mam ocho­ty ich pono­sić ;)), moi klien­ci nie raz tak­że nie).

Cóż to jest ta Architektura Korporacyjna (dalej Architektura lub AK)? Ogólnie:

Based on this bro­ade­ning of sco­pe, Enterprise Architecture now covers:

  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Infrastructure Architecture

(pole­cam cały, krót­ki wpis na Business Analyst Interview Questions | Modern Analyst > What is Enterprise Architecture?).

Przytoczę tu pro­stą i bar­dzo dobrą moim zda­niem defi­ni­cję zaczerp­nię­tą z refe­ra­tu [[dr. Andrzeja Sobczaka (SGH)]]:

Architektura kor­po­ra­cyj­na – for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji (obej­mu­ją­cych ludzi, pro­ce­sy, infor­ma­cje i tech­ni­kę), wza­jem­nych rela­cji pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­pia i wytycz­ne odno­śnie do zarzą­dza­nia pro­jek­to­wa­niem i zarzą­dza­nia zmia­ną tych kom­po­nen­tów w czasie.

Moim zda­niem nie trze­ba nic wię­cej doda­wać. Dla porząd­ku przy­to­czę defi­ni­cję sło­wa pryn­cy­pium ze słow­ni­ka j.polskiego:

pryn­cy­pium, prin­ci­pium [wym. princ-ipium] ?naj­waż­niej­sza dla kogoś lub dla cze­goś zasa­da albo war­tość? (Portal Wiedzy PWN – słow­ni­ki, ency­klo­pe­die, pod­ręcz­ni­ki aka­de­mic­kie, książ­ki spe­cja­li­stycz­ne, repe­ty­to­ria, porad­ni­ki, prze­wod­ni­ki).

Te pryn­cy­pia, to moim zda­niem uzna­nie for­ma­li­zmu w budo­wie mode­li i sfor­ma­li­zo­wa­ne zarzą­dza­nie ich zmianą.

Narzędzia OMG​.org

Co mamy w skrzyn­ce narzę­dzio­wej OMG” (www​.omg​.org)? Ludzie i pro­ce­sy to nic inne­go jak BPMN i struk­tu­ra orga­ni­za­cyj­na (ta dru­ga w BPMN lub jako sfor­ma­li­zo­wa­ny [[orga­ni­gram]]). Informacje i tech­ni­ka to nic inne­go jak UML i dia­gra­my struk­tu­ral­ne. Nie roz­wo­dząc się, całość wyglą­da ogól­nie tak:

Architektura korporacyjna - struktura

Powyższy dia­gram obrazuje:

  • kolej­ne wyma­ga­ne w AK war­stwy (doda­no na szczy­cie tak zwa­ną moty­wa­cję biznesową),
  • mapo­wa­nie zstępujące

W efek­cie, mają zasto­so­wa­nie wska­za­ne narzę­dzia (dia­gra­my, mode­le). Z ich pomo­cą może­my nie tyl­ko opra­co­wać model Architektury Korporacyjnej ale tak­że nad­zo­ro­wać go, budu­jąc macie­rze mapowania.

Tu poja­wia się poję­cie prag­ma­ty­ki w sto­so­wa­niu języ­ka (nota­cji). Ta prag­ma­ty­ka to wspo­mnia­ne już pryn­cy­pia pro­ce­so­we i obiek­to­we, oraz wska­za­ne na dia­gra­mie powy­żej uży­cie pojęć w każ­dej z wymie­nio­nych nota­cji, czy­li co i na co mapu­je­my. Mapowanie wyma­ga dopre­cy­zo­wa­nia seman­ty­ki mode­li czy­li defi­ni­cji pojęć. Jak? Najprościej nie kom­bi­no­wać np. z przy­pad­ka­mi uży­cia na biz­ne­so­we, sys­te­mo­we i inne bo to zupeł­nie nie potrzeb­ne i nie pozwa­la na pro­ste mapowanie.

Jawne mapowanie na diagramach pomiędzy warstwami

Notacja ArchiMate ma moż­li­wość (taki jest jej pośred­ni cel) jaw­ne­go poka­za­nia mapo­wa­nia pomię­dzy obiek­ta­mi warstw na dia­gra­mach. W przy­pad­ku UML też jest to for­mal­nie moż­li­we od wer­sji 2.0, zaś mapo­wa­nia BPMN->UML doko­nu­je się w doku­men­ta­cji (typo­we śla­do­wa­nie Czynność -> Przypadek użycia).

Otóż mapo­wa­nie moż­na poka­zać na wie­le spo­so­bów. Moim zda­niem robie­nie tego na dia­gra­mach, po pierw­sze nie­co je zaciem­nia, po dru­gie i tak nie eli­mi­nu­je przy­dat­no­ści stwo­rze­nia macie­rzy mapo­wa­nia. Ta dru­ga może być wyge­ne­ro­wa­na auto­ma­tycz­nie, jeże­li tyl­ko uży­wa­my dobre­go narzę­dzia CASE (bez nie­go zresz­tą nie wyobra­żam sobie wyko­na­nia żad­ne­go więk­sze­go mode­lu przy zacho­wa­niu roz­sąd­nej pracochłonności).

Po dru­gie nawet śred­ni model, mają­cy kil­ka­dzie­siąt obiek­tów, będzie wyma­gał dużej ilo­ści dodat­ko­wych dia­gra­mów obra­zu­ją­cych samo mapo­wa­nie, któ­re to dodat­ko­we dia­gra­my nie wno­szą war­to­ści doda­nej do pro­jek­tu, bo macierz gene­ro­wa­na auto­ma­tycz­nie z repo­zy­to­rium narzę­dzia CASE i tak jest łatwiej­sza w uży­ciu i per­cep­cji, sta­no­wi też nie­ja­ko auto­ma­tycz­ny wali­da­tor” czy jest ono – mapo­wa­nie – popraw­ne i kompletne.

TOGAF – subiektywnych słów kilka

O tym krót­ko. Wiem, że sta­no­wi swe­go rodza­ju gotow­ca”, ale czy skór­ka war­ta wypraw­ki? Celem budo­wa­nia AK nie jest wdro­że­nie TOGAF”a” (czy też Siatki Zachmann’a), celem jest … no wła­śnie co? O tym na końcu.

W przy­pad­ku TOGAF v 8.x mamy czte­ry obsza­ry modelowania:

  • Business Architecture
  • Data Architecture
  • Applications Architecture
  • Technology Architecture

(źr. The Open Group Architecture Framework Version 8.1.1., nowa wer­sja TOGAF 9, w porów­na­niu z powyż­szym, roz­cią­ga się na ele­men­ty moty­wa­cji biznesowej).

Nie będę się roz­pi­sy­wał na temat wszyst­kich warstw. Kilka słów o jed­nej: Architektura Danych.

TOGAF i ArchiMate (jak ja rozu­miem obie spe­cy­fi­ka­cje) ope­ru­je poję­ciem danych, oddzie­lo­nych od logi­ki biz­ne­so­wej. Obecnie sto­so­wa­ne meto­dy i narzę­dzia w pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia opar­te są na para­dyg­ma­cie obiek­to­wym, któ­ry kom­plet­nie igno­ru­je poję­cie wydzie­lo­nych danych jako takich. Mam tu na myśli bazy danych (w szcze­gól­no­ści rela­cyj­ne). Bazy danych, w meto­dach obiek­to­wych, to ele­men­ty imple­men­ta­cji, więc są one poza obsza­rem ana­li­zy i pro­jek­to­wa­nia. Przedmiotem prze­twa­rza­nia w para­dyg­ma­cie obiek­to­wym są obiek­ty biz­ne­so­we wraz z ich wewnętrz­ną logi­ką i zachowaniami.

Jaki jest więc sens brnię­cia wstecz do cza­sów ana­li­zy struk­tu­ral­nej (odręb­nie ana­li­zo­wa­ne i imple­men­to­wa­ne dane i funk­cje ich przekształcania)?

Przypomnę tu tyl­ko deli­kat­nie, że np. celem pro­ce­su sprze­da­ży nie są dane zapi­sa­ne na Fakturze VAT a pozy­ska­nie środ­ków ze sprze­da­ży pro­duk­tów, obiekt biz­ne­so­wy Faktura VAT wraz z regu­ła­mi nali­cza­nia podat­ku, to jakaś mate­ria­li­za­cja tego fak­tu a nie cel sam w sobie. Powoływanie się więc na dane” w moich oczach nie jest żad­nym postę­pem”.

Na zakończenie

Mamy więc pomysł o wdzięcz­nej nazwie Architektura Korporacyjna. Jej defi­ni­cję, moim zda­niem, moż­na spro­wa­dzić do treści:

Architektura Korporacyjna to model i jego doku­men­ta­cja, zawie­ra­ją­cy całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie pro­duk­tu (J.Żeliński)

Po nam to? Po co nam taka doku­men­ta­cja? Przykłady korzy­ści z jej posiadania:

  • mamy na tacy” model sys­te­mu zależ­no­ści (w tym ana­li­za wpły­wu) pozwa­la­ją­cy natych­miast oce­nić ryzy­ka zwią­za­ne z wza­jem­nym wpły­wem na sie­bie pro­ce­sów, ludzi, zaso­bów (np. jakie skut­ki będzie mia­ło wyłą­cze­nie kon­kret­ne­go ser­we­ra czy spóź­nie­nie do pra­cy kon­kret­ne­go pracownika),
  • mamy na tacy” wyma­ga­nia na opro­gra­mo­wa­nie, bez nie­po­trzeb­ne­go zwin­ne­go” ich poszu­ki­wa­nia meto­dą prób i błę­dów, nie­za­leż­nie od tego czy kupu­je­my nowe czy wymie­nia­my (nie­ste­ty, tak zwa­ne zwin­ne meto­dy to nie raz bar­dzo duże kosz­ty zarzu­co­nych bocz­nych ście­żek” odkry­wa­nych burzą mózgów),
  • od razu zauwa­ży­my, że idea posia­da­nia mono­li­tycz­ne­go sys­te­mu ERP II nie bar­dzo ma sens, usztyw­nia orga­ni­za­cje oraz two­rzy potęż­ny [[„sin­gle point of failu­re”]] (zło­śli­wi doda­ją sin­gle point of big cost” :)),
  • i naj­waż­niej­sze: jak tyl­ko prze­pro­wa­dzi­my ana­li­zę i wyko­na­my model AK, szyb­ko wychwy­ci­my tak zwa­ne osie­ro­co­ne wyma­ga­nia na opro­gra­mo­wa­nie, osie­ro­co­ne sta­no­wi­ska pra­cy, osie­ro­co­ne pro­ce­du­ry, … (osie­ro­co­ne: nie­wy­ko­rzy­sty­wa­ne), to nie raz źró­dło samo w sobie – eli­mi­na­cja sie­rot” – ogrom­nych oszczęd­no­ści juz na samym począt­ku projektu,
  • i inne …

Jak tym zarzą­dzać? Na pew­no nie ręcz­nie, bez opro­gra­mo­wa­nia CASE w zasa­dzie nie­re­al­ne. Czy to kosz­tow­ne? Hm… kła­nia się ana­li­za ROI, każ­da orga­ni­za­cja ma swój próg ren­tow­no­ści. Jednak od sie­bie powiem tak: oszczęd­no­ści poja­wia­ją się natych­miast w posta­ci iden­ty­fi­ka­cji sie­rot”. Kolejny etap oszczęd­no­ści to reor­ga­ni­za­cja kosz­tów i ryzyk zarzą­dza­nia orga­ni­za­cją, kosz­tów posia­da­nia opro­gra­mo­wa­nia, kosz­tów jego roz­wo­ju, kosz­tów zaku­pu i two­rze­nia. Dobra wia­do­mość: począ­tek każ­dy już ma w posta­ci pro­wa­dzo­nej doku­men­ta­cji w dzia­le HR.

Jak więc wyglą­da­ją narzę­dzia rodem z OMG, któ­re w zupeł­no­ści wystarczą??

Jest to zestaw nota­cji (BMM, BPMN, UML), któ­ry ma nie­mal­że każ­dy pakiet CASE. Notację ArchiMate mają nie­ste­ty tyl­ko nie­któ­re z nich, a jak The Open Group zacznie egze­kwo­wać opła­ty licen­cyj­ne to będzie chy­ba tyl­ko gorzej (co cie­ka­we sami twó­cy ArchiMate piszą, że uszcze­gó­ło­wie­nie mode­lu AK wyko­na­ne­go z pomo­cą ArchiMate wyma­ga uży­cia nota­cji UML). Koszty jed­nej licen­cji pakie­tu CASE (nie raz wystar­czy mieć jed­ne­go Architekta w orga­ni­za­cji) w wie­lu przy­pad­kach nie prze­kra­cza­ją 1000USD. Jeżeli więc uda się unik­nąć kolej­nej ana­li­zy wyma­gań za kil­ka­dzie­siąt tysię­cy to już ROI mamy w kieszeni.

A po co te for­ma­li­zmy (pryn­cy­pia)? Na eta­pie ana­li­zy i mode­lo­wa­nia pozwa­la­ją wery­fi­ko­wać popraw­ność mode­li i całej struk­tu­ry. Na eta­pie zarzą­dza­nia zmia­ną pano­wać nad kosz­ta­mi zmian i ryzy­ka­mi w rodza­ju i czasopisma”…:)

Druga dobra wia­do­mość: spo­koj­nie moż­na to (rola Architekta) out­so­ur­so­wać, będzie jesz­cze taniej.

Business Model Canvas vs. Business Motivation Model

Prawie rok temu pisałem:

Otóż klu­czo­wą cechą mode­lu dla potrzeb ana­li­zy sys­te­mo­wej jest trak­to­wa­nie go, pojęć z któ­rych się skła­da, jako pew­nej prze­strze­ni nazw (con­cep­tów) speł­nia­ją­cych pod­sta­wo­wą zasa­dę wza­jem­ne­go wyklu­cza­nia się defi­ni­cji pojęć. Dlatego nie łączę nigdy kosz­tów razem, roz­dzie­lam kosz­ty zaso­bów i kosz­ty mate­ria­łów słu­żą­cych do wytwo­rze­nia pro­duk­tów (pierw­sze nale­żą do nas, amor­ty­zu­je­my je, dru­gie kupu­je­my w pro­ce­sie zaopa­trze­nia by cał­ko­wi­cie je zużyć). Aktywności i zaso­by zaś łączę poję­ciem Proces Biznesowy, któ­ry mode­lu­je ści­sły zwią­zek pomię­dzy zaso­ba­mi (w tym role) a ich wytwo­ra­mi. To pozwa­la budo­wać zstę­pu­ją­cą hie­rar­chie dekom­po­zy­cji, uszcze­gó­ła­wia­ją­ce każ­de z tych pojęć. (Business Model Canvas).

Niedawno pod­czas pro­jek­tu nadzia­łem się” na pro­blem śla­do­wa­nia. Śladowanie to wywo­dze­nie obiek­tów biz­ne­so­wych (pojęć, potrzeb, wyma­gań itp.) kolej­nych eta­pów ana­li­zy z eta­pów je poprze­dza­ją­cych. Jednym z doku­men­tów jaki otrzy­ma­łem jako źró­dło był model biz­ne­so­wy w kon­wen­cji „[[Business Model Canvas]]” i poja­wił się pro­blem, na któ­ry zwró­ci­łem uwa­gę w cyto­wa­nym na począt­ku artykule…nie dało się z nie­go wypro­wa­dzić dal­szych działań”.

Model ten ma nastę­pu­ją­ca postać:

porów­naj­my go z tym:

Definicja pro­ce­su: czyn­ność lub łań­cuch czyn­no­ści prze­kształ­ca­ją­ca wej­ście w wyj­ście wno­sząc war­tość doda­ną, odby­wa się w śro­do­wi­sku ogra­ni­czeń i wyma­ga­nych zasobów.

Jeżeli dodać infor­ma­cję, że wej­ście pro­ce­su zasi­la dostaw­ca” a wyj­ście pro­ce­su to pro­dukt dla odbior­cy”, docho­dzi­my do wnio­sku, że model biz­ne­so­wy w kon­wen­cji Business Model Canvas”, to nic inne­go jak opis pro­ce­su defi­niu­ją­ce­go klu­czo­we dzia­ła­nia ryn­ko­we ana­li­zo­wa­ne­go podmiotu.

Milczącym zało­że­niem jest fakt, że rze­czy istot­ne w «biz­ne­sie” się doku­men­tu­je (nie tyl­ko dowo­dy księ­go­we ale tak­że np. zapy­ta­nia, ofer­ty itp.).

Jak widać jest wie­le podo­bieństw pomię­dzy mode­lem Business Model Canvas a mode­lem pro­ce­su uwzględ­nia­ją­cym zaso­by i ogra­ni­cze­nia. Oba maja jed­ną wadę: poka­zu­ją wyłącz­nie to co jest robio­ne”. W ana­li­zach biz­ne­so­wych wyma­ga­na jest jed­nak wie­dza nie tyl­ko o pro­ce­sie, celu i środ­kach (fir­ma jako pro­ces ryn­ko­wy). Model pro­ce­su to model mówią­cy tak teraz pra­cu­je­my”, takich mamy klien­tów, takich dostaw­ców, takie pra­wo itp. Gdzie problem?

Jeżeli uznać sta­rą praw­dę mówią­cą: kto stoi w miej­scu ten się cofa” docho­dzi­my do wnio­sku, że model do ana­li­zy np. pla­no­wa­nych zmian nie może być tyl­ko jed­nym pro­ce­sem (mapą pro­ce­sów). Nie roz­wią­zu­je pro­ble­mu model pro­ce­sów as-is i to-be (model obec­ny i model pla­no­wa­ny) bo zni­ka nam (nie jest tu uwzględ­nia­na) infor­ma­cja o przej­ściu” z jed­ne­go do drugiego.

Dlatego przy­da­je się model (i sys­tem poję­cio­wy) BMM (Business Motivation Model), któ­ry nie tyl­ko defi­niu­je pla­no­wa­ny stan przy­szły (opis sta­nu doce­lo­we­go – END), ale każe” się zasta­no­wić i udo­ku­men­to­wać to jak go osią­gnąć, poja­wia się stra­te­gia i tak­ty­ka osią­gnię­cia sta­nu oczekiwanego.

Model BMM to model ana­li­tycz­ny, sta­no­wi nie­ja­ko listę kon­tro­l­ną tego co nale­ży poznać i zro­zu­mieć”, żeby zacząć pla­no­wać osią­gnię­cie ocze­ki­wa­ne­go sta­nu orga­ni­za­cji. Po pierw­sze nale­ży zde­fi­nio­wać ten ocze­ki­wa­ny stan i okre­ślić to, jak stwier­dzi­my że został osią­gnię­ty – miara.

Struktura mode­lu BMM:

i naj­waż­niej­sze: mamy śla­do­wa­nie na pro­duk­ty dal­szej pra­cy (Referenced ele­ments… u dołu i po lewej stro­nie dia­gra­mu): kolej­ny etap ana­li­zy biz­ne­so­wej to opra­co­wa­nie mode­li pro­ce­sów biz­ne­so­wych, struk­tu­ry orga­ni­za­cyj­nej i ziden­ty­fi­ko­wa­nie (spe­cy­fi­ka­cja) reguł biz­ne­so­wych. Całość powin­na być opar­ta” na wspól­nym dla całe­go pro­jek­tu ana­li­tycz­ne­go (i orga­ni­za­cji) słow­ni­ku pojęć.

Jak widać, kla­sycz­ny” model biz­ne­so­wy poka­zu­je tyl­ko co jest przed­mio­tem dzia­łal­no­ści i klu­czo­wym źró­dłem zysku”. Model taki jest mode­lem pro­ce­su, ten pro­ces jed­nak to tyl­ko opis tego co, jaką war­tość doda­ną, dana orga­ni­za­cja dostar­cza swo­im klien­tom i gdzie się zaopa­tru­je. Model to-Be opi­su­je stan pożą­da­ny, nie daje żad­nej wie­dzy o tym, jak do nie­go dojść. Model As-is i To-be ma lukę pomię­dzy tymi As-Is i To-be. Tę lukę wypeł­nia moim zda­niem kom­plet­ny model BMM – każe opra­co­wać” stra­te­gię, tak­ty­kę, ana­li­zę SWOT, ryzy­ka i inne mają­ce wpływ na osią­gnię­cie celu, a nawet na to czy jest on w ogó­le osiągalny.

Po co to wszyst­ko? Bo dobra ana­li­za, powin­na być sama dla sie­bie dowo­dem słusz­no­ści jej wyni­ków (dla­te­go nie raz tu napi­sa­łem, że powin­na być pro­wa­dzo­na meto­dą nauko­wą”).

Co jest wadą większości analiz biznesowych?

To, że są one tak na praw­dę tyl­ko upo­rząd­ko­wa­nym zapi­sem wywia­dów z klien­tem a nie fak­tycz­ną ana­li­zą orga­ni­za­cji i jej potrzeb (bo nie koniecz­nie jej pra­cow­ni­ków!) i celów biz­ne­so­wych. Jakie są tre­ści tek­sto­we­go lub tabe­la­rycz­ne­go zapi­su wywia­dów? NIEJEDNOZNACZNE! Jakie są nie­sfor­ma­li­zo­wa­ne, swo­bod­nie two­rzo­ne dia­gra­my pro­ce­sów? NIEJEDNOZNACZNE! Jakie są słow­ne opi­sy struk­tu­ry opro­gra­mo­wa­nia jakie ma powstać? NIEJEDNOZNACZNE!

Co zro­bić? Używać już na eta­pie ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia sfor­ma­li­zo­wa­nych narzę­dzi takich jak stan­dar­do­we nota­cje i meto­dy­ki, wte­dy opi­sy będą JEDNOZNACZNE. Czy to trud­ne? Tak, w koń­cu te 70% pora­żek to nie przy­pa­dek? ( czy­taj cały arty­kuł: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność z doku­men­tów ana­li­tycz­nych!).

Dlaczego tak jest? Bo opro­gra­mo­wa­nie jest two­rzo­ne z pomo­cą języ­ków pro­gra­mo­wa­nia a te SĄ sfor­ma­li­zo­wa­ne. Nie da się skom­pi­lo­wać do posta­ci sys­te­mu ERP luź­nej pro­zy”. Napisałem to w Listopadzie 2011, dzi­siaj ciąg dal­szy. Na począ­tek dodam jesz­cze moją kon­klu­zję z pew­nej konferencji:

Tak więc język for­mal­ny, uży­ta nota­cja, czy­ni pro­jekt war­to­ścio­wym [jed­no­znacz­nym]. Bez tego raczej nie zna­czy on po pro­tu nic. (Modelowanie pro­ce­sów biz­ne­so­wych – dla­cze­go mają sens tyl­ko meto­dy for­mal­ne i uzna­ne nota­cje).

Jak to mówią: moc­ne sło­wa, ale nie zapo­mi­naj­my, że mało któ­ry pro­jekt biz­ne­so­wy IT koń­czy się w ter­mi­nie i zamy­ka w zało­żo­nym budże­cie. Zastanówcie jak były doku­men­to­wa­ne Wasze nie­uda­ne” projekty…

O notacjach

Króciutko, żeby się nie powta­rzać. Notacja to pewien język wyra­zu, prze­strzeń nazw zawie­ra­ją­ca skoń­czo­ną licz­bę pojęć o ści­śle zde­fi­nio­wa­nych zna­cze­niach. Notacji mamy na ryn­ku wie­le. Czy to jakiś pro­blem? W pew­nym sen­sie tak, bo po pierw­sze języ­ki te nie­co nakła­da­ją się na sie­bie (nakła­da­ją się na sie­bie prze­strze­nie nazw) ale nie dają się na sie­bie w spo­sób jed­no­znacz­ny tłu­ma­czyć. Języki te nie zastę­pu­ją się wza­jem­nie. Są w uży­ciu” nota­cje (sys­te­my two­rze­nia dia­gra­mów) nie­sfor­ma­li­zo­wa­ne, trud­no je w ogó­le nazy­wać nota­cją. To po pro­tu biblio­te­ki sym­bo­li do two­rze­nia sche­ma­tów blo­ko­wych a te nie koniecz­nie są mode­la­mi”. Przykładem może być bar­dzo popu­lar­ny MS Visio z wie­lo­ma biblio­te­ka­mi sym­bo­li. Niestety tak powsta­ją­ce dia­gra­my są zapew­ne ilu­stra­cją dla tek­stu ale nie są żad­nym modelem.

Opisze tu wybra­ne nota­cje, te któ­rych uży­wam i uzna­je za pewien stan­dard de’fac­to. Nie będzie to żad­ne szko­le­nie z nota­cji”, bo nie jest to ani miej­sce ani dobry spo­sób na szko­le­nia (na te ser­decz­nie zapra­szam zain­te­re­so­wa­nych na sale wykła­do­wą :)). Powiemy sobie o [[ArchiMate]], [[BMM]], [[BPMN]], [[UML]].

Co, kiedy i do czego

To co tu teraz napi­szę nie jest żad­nym dogma­tem. To efekt doświad­czeń, prac badaw­czych i pew­nych przemyśleń.

Każda orga­ni­za­cja to bar­dzo zło­żo­ny orga­nizm. Stopień zło­żo­no­ści jest duży jeże­li wziąć pod uwa­gę fakt, że nie­jed­na zatrud­nia dzie­siąt­ki pra­cow­ni­ków, two­rzy tysią­ce doku­men­tów, obsłu­gu­je set­ki spraw i uży­wa dzie­sią­tek narzę­dzi (w tym opro­gra­mo­wa­nie) wspo­ma­ga­ją­cych tę pra­cę . Czy to w ogó­le da się jakoś opi­sać? Owszem. Jak?

Organizacje się nie tyle opi­su­je” co raczej mode­lu­je. Ich model to uprosz­cze­nie, pozwa­la­ją­ce zro­zu­mieć spo­sób jej dzia­ła­nia. Problem jed­nak w tym, że orga­ni­za­cja to wie­le róż­nych aspek­tów jej dzia­ła­nia. Dla każ­de­go z nich powstał inny język opi­su, powo­dem jest (tak sądzę), po pierw­sze róż­ny odbior­ca na każ­dym pozio­mie szcze­gó­ło­wo­ści, a po dru­gie róż­ne para­dyg­ma­ty (pro­ce­so­wy, obiek­to­wy czy sys­tem ana­liz wpły­wu). Kto inny czy­ta opis stra­te­gii biz­ne­so­wej a kto inny opis tech­nicz­ny sys­te­mu ERP, jed­nak oba te aspek­ty są jakoś powią­za­ne (powin­ny być ;)) i to tak­że powin­no dać się opi­sać. Z tego powo­du pierw­szym podzia­łem mode­li są: mode­le logicz­ne (abs­trak­cja) i wyko­naw­cze (spe­cy­fi­ka­cja). Na to nakła­da się sfe­ra biz­ne­so­wa (zarzą­dza­nie) oraz tech­nicz­na (zaso­by w tym narzędzia).

Nie znaj­dzie­cie tu pań­stwo defi­ni­cji tych nota­cji, odsy­łam na stro­ny orga­ni­za­cji stan­da­ry­zu­ją­cych ([[Object Management Group]] oraz [[The Open Group]]). Pokaże do cze­go dosze­dłem na bazie dzie­sią­tek pro­jek­tów małych i dużych, dla real­nych przed­się­biorstw i fik­cyj­nych badaw­czych. Posłużę się kla­sycz­nym chy­ba już mode­lem ana­li­zy zstę­pu­ją­cej, w posta­ci pira­mi­dy obra­zu­ją­ce trzy pozio­my abs­trak­cji opi­su orga­ni­za­cji (im niżej tym wię­cej szcze­gó­łów zawie­ra dokumentacja):

Na naj­wyż­szym pozio­mie abs­trak­cji mamy stra­te­gię, tu poja­wia się tak zwa­ny model moty­wa­cji i ana­li­za wpły­wu. Obecnie uży­wam na tym pozio­mie nota­cji (języ­ka mode­lo­wa­nia) [[Business Motivation Model]]. Zawiera takie poję­cia jak cel biz­ne­so­wy, środ­ki osią­ga­nia celu ale tak­że bar­dzo waż­ne na tym eta­pie takie ele­men­ty jak czyn­ni­ki wpły­wu, ana­liz a SWOT, ryzy­ka czy stra­te­gie i taktyki.

Na tym pozio­mie od tego roku moż­na sto­so­wać nota­cję [[ArchiMate]], jed­nak w moim prze­ko­na­niu jest ona w tym obsza­rze zbyt sil­nie ukie­run­ko­wa­na na meto­dy­kę i struk­tu­ry opi­su [[TOGAF]], jest w moich oczach w tej sfe­rze uboż­sza, bra­ku­je jej wie­lu pojęć obsłu­gi­wa­nych” przez BMM.

Jeżeli nie widzę nic złe­go w sto­so­wa­niu kil­ku nota­cji w jed­nym pro­jek­cie (jest to w zasa­dzie koniecz­ność), to z zasa­dy uży­wam wyłącz­nie jed­nej nota­cji na jed­nym pozio­mie abs­trak­cji (war­stwie jak wyżej). Używanie na jed­nym pozio­mie np. dwóch róż­nych nota­cji pro­wa­dzi co naj­mniej do bra­ku spój­no­ści mode­li gdyż poję­cia róż­nych nota­cji róż­nią się swo­im zasię­giem (poszcze­gól­ne poję­cia mają nie­co inne znaczenia).

Na pozio­mie pro­ce­sów biz­ne­so­wych, sto­su­ję zamien­nie BPMN albo ArchiMate. Z każ­dym kolej­nym pro­jek­tem skła­niam się jed­nak do uży­wa­nia na tym pozio­mie ArchiMate. Powodem jest to, że BPMN ofe­ru­je wyłącz­nie czy­ste poję­cia z defi­ni­cji pro­ce­su (czyn­ność, dane, zda­rze­nie, rola, pula, bram­ki). Na tym pozio­mie jed­nak nie raz nale­ży wyra­zić roz­dziel­nie takie poję­cia jak rola i aktor (np. klient i kon­tra­hent mogą peł­nić rolę zama­wia­ją­ce­go w pro­ce­sie) albo odręb­ne poję­cia takie jak funk­cje biz­ne­so­we (aktor wraz z zaso­ba­mi jakich uży­wa peł­ni funk­cję admi­ni­stra­cji wewnętrz­nej) albo usłu­gi powią­za­ne z pro­ce­sa­mi (pro­ces sprze­da­ży powią­za­ny z usłu­gą obsłu­gi klien­ta). Przykłady moż­na mnożyć.

Realizacja pro­ce­sów to suche” łań­cu­chy czyn­no­ści i twar­da logi­ka ich sce­na­riu­szy. Tu dosko­na­le spraw­dza się BPMN i pier­wot­ny cel powsta­nia tej nota­cji: mode­lo­wa­nie skryp­tów BPEL ([[Business Process Execution Language]], a obec­nie głów­nie [[XPDL]]). W tej war­stwie BPMN nie ma kon­ku­ren­cji, jest w 100% zgod­ny z XPDL (język opi­su pro­ce­sów zale­ca­ny przez [[Workflow Management Coalition, WfMC]]). Podejmowane są pró­by sto­so­wa­nia UML (Diagram czyn­no­ści) ale nie wró­żę tej meto­dzie suk­ce­su i nie pole­cam jej (powo­dy na koń­cu tekstu).

Tu dodat­ko­wa mała uwa­ga. Nawet na pozio­mie wyko­naw­czym pro­ce­su rzad­ko poja­wia się potrze­ba, mode­lo­wa­nia expli­ci­te” każ­dej czyn­no­ści, z dokład­no­ścią nie­mal­że algo­ryt­micz­ną. W więk­szo­ści wypad­ków zupeł­nie wystar­czy model celo­wo­ści dzia­łań” i ich sce­na­riu­sze, algo­rytm postę­po­wa­nia potrzeb­ny jest tyl­ko maszy­nie. Na stro­nach BPM Research dostęp­ne są wyni­ki badań poka­zu­ją­ce to zja­wi­sko: The ave­ra­ge sub­set of BPMN used in the­se models con­si­sted of just 9 dif­fe­rent sym­bols. That means that the ave­ra­ge BPMN model uses less than 20% of the ava­ila­ble voca­bu­la­ry. (Najczęściej uży­wa­ny w mode­lach zestaw pojęć BPMN to 9 sym­bo­li. Oznacza to, że w mode­lach BPMN uży­wa­nych jest nie­ca­łe 20% zde­fi­nio­wa­nych w tej nota­cji pojęć). Polecam dostęp­ny na tych stro­nach wykres.

Można się spo­tkać z poję­ciem trzech pozio­mów mode­lo­wa­nia pro­ce­sów (Bruce Silver blog): war­stwa opi­so­wa, war­stwa mode­li ana­li­tycz­nych, war­stwa mode­li wyko­naw­czych. w zasa­dzie nie odbie­ga to od powyż­sze­go mode­lu jed­nak autor pro­po­nu­je tu w war­stwie pierw­szej (opis) two­rze­nie ogól­nych mode­li z zanie­dba­niem reguł nota­cji. Tu jed­nak nie­ste­ty nara­ża­my się na nie­jed­no­znacz­no­ści. Ja widać nie ja jeden dostrze­gam potrze­bę podzia­łu na pozio­my abs­trak­cji w mode­lo­wa­niu i ana­li­zie. Propozycja Bruce’a Silvera jest jak naj­bar­dziej war­ta naśla­do­wa­nia, z tym jed­nak, że lep­szym pomy­słem jest, moim zda­niem, wybra­nie nota­cji dosto­so­wa­nej do pozio­mu abs­trak­cji, dla­te­go na pozio­mi opi­so­wym (ja jed­nak wole nazwę model biz­ne­so­wy lub łań­cuch war­to­ści, to nada­je kon­kret­ny sens temu mode­lo­wi) sto­su­ję oraz czę­ściej ArchiMate by nie musieć łamać zasad sys­te­mu poję­cio­we­go danej nota­cji (jak sam Bruce Silver przy­znał, wyma­ga to wyłą­cze­nia kon­tro­li popraw­no­ści modelu).

Warstwa archi­tek­tu­ry sys­te­mów IT. Tu w zasa­dzie rów­no­praw­nie moż­na uży­wać ArchiMate i UML (głów­nie dia­gram kom­po­nen­tów i dia­gram wdro­że­nia). Jednak koja­rząc logi­kę biz­ne­so­wą (poziom pro­ce­sów biz­ne­so­wych) z archi­tek­tu­rą apli­ka­cji (sys­tem IT), nale­ży zasto­so­wać jed­ną nota­cję dla obu warstw by zacho­wać spój­ność poję­cio­wą mode­lu, a to daje nam wła­śnie ArchiMate (to są już pro­jek­ty doty­ka­ją­ce” archi­tek­tu­ry korporacyjnej).

Najniżej mamy war­stwę spe­cy­fi­ka­cji sys­te­mu IT, jego struk­tu­rę (albo jak to woli model reali­za­cji sys­te­mu IT). Na tym pozio­mie w uży­ciu nota­cja UML, któ­ra do tego powsta­ła. Jeżeli uznać fakt, że meto­dy struk­tu­ral­ne ode­szły do lamu­sa (nota­cje DFD) a mode­le rela­cyj­nych baz danych są na zbyt niskim, inży­nier­skim pozio­mie (nota­cja ERD), to UML jako język obiek­to­wy, nie ma w tym obsza­rze kon­ku­ren­ta. Poniżej typo­wy zakres (pakie­ty, w nich są loko­wa­ne arte­fak­ty” pro­duk­tu ana­li­zy) moich projektów:

Powyższy dia­gram obra­zu­je struk­tu­rę mode­li (pod spodem odpo­wia­da­ją­ce mu drze­wo kata­lo­gów, dia­gram powyż­szy do dia­gram pakie­tów UML).

Powyższy dia­gram to tak­że podział z per­spek­ty­wy adre­sa­ta doku­men­ta­cji: dla tak zwa­ne­go biz­ne­su adre­so­wa­ne są trzy war­stwy licząc od góry. Dla wyko­naw­ców sys­te­mów ostat­nia: wykonawcza.

Na zakończenie kilka słów o UML

Notacja ta powsta­ła jako uni­wer­sal­na ([[Unified Modeling Language]], Uniwersalny Język Modelowania) jed­nak tu chy­ba auto­rzy tej nota­cji dotknę­li pro­ble­mu coś co jest do wszyst­kie­go jest do nicze­go”. Mimo tego, że z pomo­cą sys­te­mu tak zwa­nych pro­fi­li w UML moż­li­we jest wyra­że­nie w tej nota­cji pojęć każ­dej z pozo­sta­łych wymie­nio­nych, nie jest to dobry pomysł. Mam nadzie­ję, że nie zacho­ru­je na to” [[The Open Group i ArchiMate]] (poja­wi­ła się wspo­mnia­na ArchiMate 2.0).

Dlaczego UML nie powi­nien być uży­wa­ny do wszyst­kie­go? Notacja ta jest ska­żo­na” tak zwa­nym obiek­to­wym para­dyg­ma­tem, bar­dzo trud­nym do przy­swo­je­nia dla osób nie oby­tych z meto­da­mi obiek­to­wy­mi w inży­nie­rii opro­gra­mo­wa­nia. Po dru­gie sys­tem gra­ficz­ny w UML nie uła­twia odbio­ru, per­cep­cji mode­li gdyż więk­szość pojęć jest obra­zo­wa­na pro­sto­ką­tem z róż­ny­mi ety­kie­ta­mi. Zjawisko to (zro­zu­mia­łość gra­ficz­nych sys­te­mów komu­ni­ko­wa­ni tre­ści) opi­su­je nauka jaką jest [[Semiotyka]]. Nie jest to miej­sce na jej opis, jed­nak wyka­zu­je ona, że sto­so­wa­nie np. UML do komu­ni­ko­wa­nia cze­go­kol­wiek ludziom z tak zwa­ne­go biz­ne­su”, nie mają­cym nic wspól­ne­go z obiek­to­wym para­dyg­ma­tem, nie jest dobrym pomy­słem, a doku­men­ty opi­su­ją­ce orga­ni­za­cję w koń­cu mają im służyć.

Semiotyka uczy nas”, że każ­de poję­cie (kon­cept) dla moż­li­wie naj­lep­szej zro­zu­mia­ło­ści dla odbior­cy, powi­nien być repre­zen­to­wa­ny innym zna­kiem (kształ­tem), naj­le­piej koja­rzą­cym się z repre­zen­to­wa­nym zna­cze­niem (co zna­czy ten znak).

Innym razem na kil­ku przy­kła­dach, poka­żę mode­le w ArchiMate…

Agilian nowa wersja. Burza mózgów sformalizowana …

Niedawno napi­sa­łem:

Burze mózgów mają sens, jak naj­bar­dziej, ale w przy­pad­ku zespo­łu spe­cja­li­stów. Jeżeli zacho­dzi ryzy­ko, że jeden spe­cja­li­sta w danej dzie­dzi­nie, będzie pra­co­wał nad uzy­ska­niem roz­wią­za­nia zbyt dłu­go na co nie ma cza­su, zamiast jed­ne­go spe­cja­li­sty ?sadza­my? kil­ku (słyn­na sce­na w Apollo 13). Jest bar­dzo praw­do­po­dob­ne, że któ­ryś z nich wpad­nie na wła­ści­wy pomysł szyb­kiej niż kole­dzy. (Burza mózgów ? home­opa­tia w ana­li­zie).

I pro­szę pisze­my i roz­ma­wia­my o tym, z dru­giej stro­ny mamy for­mal­ne UML, BPMN itp. i jakoś sta­le bra­ku­je łącz­ni­ka”. Z zasa­dy nie rekla­mu­ję opro­gra­mo­wa­nia. Uważam, że jego sprze­da­wa­nie to inna kom­pe­ten­cja. Jednak nie da się ukryć, że jestem użyt­kow­ni­kiem cze­goś”. Czym to jest? Pakiet typu CASE ([[Computer-Aided Software Engineering, Computer-Aided Systems Engineering]]) jakim jest [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgra­de i… mamy burzę mózgów :):

Narzędzie przy­dat­ne bo mając rzut­nik moż­na spo­koj­nie zarzu­cić tabli­cę i jej fotografowanie :).

Od pew­ne­go już cza­su pakiet ten pozwa­la na two­rze­nie dia­gra­mów [[ArchiMate]]. Notacja ta, to narzę­dzie do mode­lo­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej. Co to? Ogólnie jest to odpo­wiedź na pyta­nie: jak zarzą­dzać zależ­no­ścia­mi pomię­dzy biz­ne­sem, pro­ce­sa­mi i infra­struk­tu­rą IT. Można np. tak:

Diagram ArchiMate Sprzedaż

Swego cza­su pisa­łem już o mode­lach BMM uży­wa­nych na eta­pie ana­li­zy biz­ne­so­wej i doku­men­to­wa­nia jej efektów:

BMMOvierwiev

Ktoś może zapy­tać po co to wszyst­ko w pakie­cie do ana­li­zy i mode­lo­wa­nia? Bo klu­czo­wym mier­ni­kiem jako­ści ana­li­zy, jej doku­men­ta­cji i mode­li jest spój­ność i pano­wa­nie nad cało­ścią. Jedynym spo­so­bem osią­gnię­cia tego, rela­tyw­nie niskim nakła­dem pra­cy, jest zbio­ro­we, spój­ne zarzą­dza­nie każ­dym ele­men­tem doku­men­ta­cji. Wtedy może­my zwe­ry­fi­ko­wać doku­men­ta­cję i zba­dać wpływ każ­de­go obiek­tu na inne w ramach całej dokumentacji:

Macierz procesu zadnia-role

Można tak­że zbu­do­wać macierz powią­zań pomię­dzy dowol­nie wybra­nym zesta­wem obiek­tów w całej dokumentacji.

To pozwa­la owe kar­tecz­ki powią­zać z mode­la­mi pro­ce­sów i dzie­dzi­ny, spraw­dzić czy potra­fi­my uza­sad­nić każ­dy ele­ment w wyma­ga­niach i wychwy­cić te nie­ob­słu­żo­ne. Do tego ana­li­za ryzyk (ana­li­zy wpły­wu) sta­ja wręcz banal­ne”, bo sta­no­wią po pro­tu raport z tak opra­co­wa­nej doku­men­ta­cji i mode­li. Jeżeli jest ona kom­plet­na i spój­na to mamy te dane na tacy”.

Po co nam CASE?

Bo

Dzięki narzę­dziom CASE pro­jek­ty two­rzy się dokład­niej, a pra­ca nad dia­gra­ma­mi, spraw­dza­nie ich popraw­no­ści oraz śle­dze­nie wyko­na­nych testów jest prost­sze i szyb­sze. (wie­cej: http://​www​.eio​ba​.pl)

Tak więc gorą­co pole­cam sto­so­wa­nie narzę­dzi (lista narzę­dzi CASE). Zaryzykował bym nawet tezę, że brak takich narzę­dzi u ana­li­ty­ka to jak by sto­larz pra­cu­ją­cy wyłącz­nie siekierą…

Plan rozwojowy - diagram BMM

Większa elastyczność i lepsza obsługa klienta na szczycie listy życzeń użytkowników systemów ERP

Sille Gavnholt Jygert, Konsultant i Kierownik Programów w fir­mie ana­li­tycz­nej Frost & Sullivan, potwier­dza: ?Jeżeli cho­dzi o wdro­że­nia sys­te­mów ERP, coraz więk­sze­go zna­cze­nia nabie­ra efek­tyw­ność, a nie kosz­ty; teraz cho­dzi bar­dziej o wyko­ny­wa­nie wła­ści­wych dzia­łań we wła­ści­wy spo­sób. Często ozna­cza to potrze­bę więk­szej ela­stycz­no­ści we wdro­że­niu i wyko­rzy­sta­niu sys­te­mu ERP. Uważamy, że ist­nie­ją trzy głów­ne obsza­ry, w któ­rych użyt­kow­ni­cy mogą odnieść korzy­ści ze zwięk­sze­nia ela­stycz­no­ści sys­te­mów ERP:

  1. Większa kon­cen­tra­cja na pro­ce­sach i zmia­nach, któ­re sys­tem ERP ma wspierać.
  2. Nowe mode­le usług wdro­że­nio­wych i wspar­cia: coraz czę­ściej dostaw­cy będą musie­li zapew­niać wspar­cie dla kon­kret­nych pro­ble­mów biz­ne­so­wych, a nie dla okre­ślo­nych tech­no­lo­gii, aby móc dzia­łać w coraz szyb­ciej zmie­nia­ją­cym się środowisku.
  3. Obsługa klien­tów: poja­wią się nowe mode­le pozwa­la­ją­ce reali­zo­wać pro­ces biz­ne­so­wy i sil­niej anga­żo­wać użyt­kow­ni­ków, poma­ga­jąc im przez to efek­tyw­niej wyko­rzy­sty­wać sys­tem w roz­wią­zy­wa­niu pro­ble­mów biznesowych.

Według Jamesa Greavesa, Dyrektora ds. IT w fir­mie pro­jek­to­wej Portsmouth Aviation, zdol­ność zacho­wa­nia ela­stycz­no­ści i reago­wa­nia na zmie­nia­ją­ce się wyzwa­nia biz­ne­so­we to jeden z klu­czo­wych atry­bu­tów poszu­ki­wa­nych u dostaw­ców i w sys­te­mach ERP. (źr. Większa ela­stycz­ność i lep­sza obsłu­ga klien­ta na szczy­cie listy życzeń użyt­kow­ni­ków sys­te­mów ERP).

Jeśli potrak­to­wać powyż­sze jako znak cza­su”, to ma to duże znacz­nie jako wpływ na spo­so­by i meto­dy pro­wa­dze­nia ana­liz wyma­gań i oce­ny potrzeb – narzu­ca duże wyma­ga­nia na jej jakość.

System ERP to przede wszyst­kim narzę­dzie. Jeżeli wdra­ża­my je, to z myślą o kon­kret­nych korzy­ściach. Popatrzmy na nie w kon­tek­ście warun­ków uzy­ska­nia powyż­szych korzyści:

Ad. 1. Nowe narzę­dzia IT wdra­ża­ne są (powin­ny) jako odpo­wiedź na potrze­bę nowych zaso­bów. Ta potrze­ba powin­na być uza­sad­nio­na biz­ne­so­wo. Praktyka poka­zu­je, że naj­efek­tyw­niej­sze wdro­że­nia to efekt zmian zapla­no­wa­nych jako ele­ment reali­za­cji nowej stra­te­gii fir­my. To z regu­ły nowe lub zmie­nio­ne pro­ce­sy biz­ne­so­we i mode­le biznesowe.

Ad.2. Tu nasu­wa się tyl­ko jed­no: ana­li­za sys­te­mo­wa i model usłu­go­wy sys­te­mu, nie tyle SOA jako [[Service Oriented Architecture]] ale tak­że jako poprze­dza­ją­ca to [[Service Oriented Analysis]]. Zidentyfikowany pro­blem biz­ne­so­wy na eta­pie ana­li­zy wyma­gań zamie­nia się (powi­nien) w wyma­ga­nie w spe­cy­fi­ka­cji wyma­gań na system.

Ad.3. Modele biz­ne­so­we zmie­rza­ją w kie­run­ku uczy­nie­nia klien­ta udzia­łow­cem, pro­gra­my lojal­no­ścio­we to pro­wa­dze­nie do tego, by klient czuł się zwią­za­ny z dostaw­cą, by czuł, że kupu­jąc utrzy­mu­je go, sta­je się źró­dłem gwa­ran­cji jego dal­sze­go ist­nie­nia. Przyczynia się do tego by ulu­bio­na mar­ka zacho­wa­ła się na ryn­ku. Tu wkra­cza­my w ele­men­ty pro­ce­sów biz­ne­so­wych powią­za­nych z sys­te­ma­mi CRM.

Nie da się tu, za mało miej­sca, opi­sać cało­ści szcze­gó­łów tych zagad­nień, mogę co naj­wy­żej wska­zać jak moż­na gryźć” pro­blem. A pro­blem tkwi w zło­żo­no­ści współ­ist­nie­nia: pro­ce­dur, ludzi, uży­wa­ne­go opro­gra­mo­wa­nia, pla­nów biz­ne­so­wych i mar­ke­tin­go­wych itp. Złożoność ta jest trud­na do ogar­nię­cia umy­słem czło­wie­ka, samo zapi­sa­nie w posta­ci tek­stu memo­ria­łu Tak będzie­my to robić” to sta­now­czo za mało. Dlaczego? Bo istot­ne jest nie tyl­ko to ile ele­men­tów wcho­dzi w skład pro­ble­mu” a to jak są ze sobą powią­za­ne oraz co i na co ma wpływ. Zrozumienie tkwi nie w tym, że wiem ile w lesie jest drzew i wil­ków a w tym, że wiem dla­cze­go i kie­dy wil­ki się cho­wa­ją za drze­wa­mi. Dlatego spis z inwen­ta­rza nie pomaga.

Poniżej dia­gram (a raczej jego namiast­ka) poka­zu­ją­cy jak opi­sać model poka­zu­ją­cy te oddzia­ły­wa­nia i wpływy:

Plan rozwojowy - diagram BMM
Plan roz­wo­jo­wy – dia­gram BMM

Celem takich dia­gra­mów nie jest tyl­ko two­rze­nie obraz­ków. To narzę­dzie ana­li­zy, któ­re zmu­sza do zada­wa­nia wła­ści­wych pytań, wła­ści­wym oso­bom. Jako, że model BMM sta­no­wi kom­plet­ny sys­tem poję­cio­wy a przy oka­zji tak­że ma swo­ją sym­bo­licz­ną wer­sje (nota­cja), pozwa­la two­rzyć nie­skom­pli­ko­wa­ne dia­gra­my i sku­pić się na tym co waż­ne a po dru­gie poka­zać sys­tem w spo­sób łatwy do wery­fi­ka­cji i zro­zu­mie­nia. Stworzenie spój­ne­go tek­stu na pod­sta­wie takie­go dia­gra­mu jest już łatwe, w dru­gą stro­nę to nie­ste­ty nie dzia­ła (łatwo jest słow­nie opi­sać skom­pli­ko­wa­ną tra­sę wyciecz­ki mając plan mia­sta w rękach, zro­bie­nie tego na bazie wyobraź­ni jest dużo trud­niej­sze, dla­te­go jed­nak war­to posia­dać mapę).

Powyższy dia­gram, model moty­wa­cji, tu two­rzo­ny jest w kon­tek­ście pro­jek­tu. Dlatego tu nie opi­su­je całej fir­my a jedy­nie zwią­za­ne z celem ele­men­ty. Cele jest reali­za­cja kon­kret­nej wizji.

Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Na stro­nach http://​www​.omg​.org/ poja­wi­ła się nowa spe­cy­fi­ka­cja nota­cji [[Business Motivation Model]] (BMM) (źr. BMM.) Notacja ta powsta­ła w celu umoż­li­wie­nia for­mal­ne­go mode­lo­wa­nia biz­ne­spla­nów, a kon­kret­nie mode­li biz­ne­so­wych. Notacja powsta­ła z ini­cja­ty­wy [[Business Rules Group]] (http://​www​.busi​nessru​les​gro​up​.org/​h​o​m​e​-​b​r​g​.​s​h​tml). Manifest tej orga­ni­za­cji zawie­ra tak zwa­ne Zasady Autonomii Reguł (tu w języ­ku pol­skim: http://​www​.busi​nessru​les​gro​up​.org/​b​r​m​a​n​i​f​e​s​t​o​/​B​R​M​a​n​i​f​e​s​t​o​P​L​.​pdf).

BMM ujmu­je wyma­ga­nia biz­ne­so­we w róż­nych wymia­rach, w celu uza­sad­nie­nia dla­cze­go biz­nes chce coś robić, do cze­go dąży, jak zamie­rza to osią­gnąć oraz jak oce­nia rezultaty.”

Po co nowa notacja?

Swego cza­su (rok 2006) pisa­łem o mode­lach biz­ne­so­wych w kon­tek­ście stra­te­gii ryn­ko­wej w arty­ku­le Model biz­ne­so­wy – co to za zwie­rze. Wtedy pisa­łem o tym, że stra­te­gia ma zna­cze­nie i wie­le tłu­ma­czy. Wtedy tak­że dotkną­łem pro­ble­mu słow­nic­twa i sys­te­mu pojęć. Samo zde­fi­nio­wa­nie stra­te­gii nie jest pro­ste, zde­fi­nio­wa­nie poję­cia stra­te­gii zmia­ny jest jesz­cze więk­szym wyzwaniem.

Obszar biz­ne­so­wy jest bar­dzo ubo­gi w [[meto­dy for­mal­ne]]: for­mal­ne nota­cje, sfor­ma­li­zo­wa­ne języ­ki opi­su. W zasa­dzie dys­po­nu­je­my tyl­ko [[nota­cją BPMN]] (mode­le pro­ce­so­we i mode­le współ­pra­cy pro­ce­sów) oraz [[nota­cją ArchiMate]] (mode­le archi­tek­tu­ry kor­po­ra­cyj­nej). [[Notacja eEPC]], koja­rzo­na głów­nie z [[narzę­dziem ARIS]] i fir­mą ISD Scherr odcho­dzi powo­li do histo­rii, o nota­cjach nie­stan­dar­do­wych nawet nie piszę bo od daw­na idą w zapomnienie.

Dla odmia­ny, w sze­ro­ko poję­tej dzie­dzi­nie inży­nie­rii opro­gra­mo­wa­nia, mamy [[nota­cje obiek­to­wą UML]] i jej trzy­na­ście typów dia­gra­mów, mamy nadal uży­wa­ne, zna­ne z ana­li­zy struk­tu­ral­nej nota­cje [[ERD]] i [[DFD]].

[[Notacja BMM]] uzu­peł­nia biz­ne­so­wy sys­tem nota­cyj­ny o obszar poję­cio­wy mode­li biz­ne­so­wych i biz­ne­spla­nów. Pozwala w spo­sób for­mal­ny je opi­sać. [[Przestrzeń nazw]], pod­sta­wo­we poję­cia opi­sa­ne w BMM:

  1. Ends (stan ocze­ki­wa­ny) iden­ty­fi­ku­ją cechy opi­su­ją­ce źró­dła moty­wa­cji (cele) two­rze­nia biznesplanu,
  2. Means (środ­ki) iden­ty­fi­ku­ją narzę­dzia i środ­ki jakich pla­nu­je­my użyć by dopro­wa­dzić do ocze­ki­wa­ne­go (pla­no­wa­ne­go) stanu.
  3. Assessement (uwa­run­ko­wa­nia, ogra­ni­cze­nia) iden­ty­fi­ku­ją wie­dzę o warun­kach pro­jek­tu (w szcze­gól­no­ści ana­li­za SWOT)
  4. Influence (wpływ) iden­ty­fi­ku­ją pozna­ne czyn­ni­ki mogą­ce mieć (mają­ce) wpływ na osią­gnie­cie celu,
  5. Organisation (orga­ni­za­cja) iden­ty­fi­ku­je zaso­by i pro­ce­sy zaan­ga­żo­wa­ne w osią­gnię­cie celu
Całość sta­no­wi rodzaj listy kon­tro­l­nej” zro­zu­mie­nia posta­wio­ne­go pro­ble­mu, jakim jest pro­jekt biz­ne­so­wy, pozwa­la upew­nić się, że zna­my i rozu­mie­my to co ma na nie­go wpływ:

Business Motivation Model (źr. wiki)

Notacja zawie­ra tak­że ele­men­ty ste­ru­ją­ce biz­ne­sem takie jak [[regu­ły biz­ne­so­we]] i zasa­dy zarzą­dza­nia. Zestaw pojęć defi­niu­ją­cych ele­men­ty biz­ne­spla­nów, cechu­je się neu­tral­no­ścią meto­do­lo­gicz­ną oraz pozwa­la jed­no­znacz­nie opi­sać nasza wie­dzę o pro­jek­cie. Oznacza to, że słow­nik pojęć nie jest dedy­ko­wa­ny żad­nej kon­kret­nej meto­dy­ce, a jest jedy­nie for­mal­nym słow­ni­kiem ([[seman­tycz­na prze­strze­nią nazw]]). Powyższe poję­cia są wywie­dzio­ne z zasad­ni­czych pojęć z dzie­dzi­ny mode­lo­wa­nia pro­ce­sów: pro­ces biz­ne­so­wy, regu­ła biz­ne­so­wa, jed­nost­ka orga­ni­za­cyj­na. Bazują one odpo­wied­nio na spe­cy­fi­ka­cjach: BPMN (nota­cja [[OMG Business Process Modeling Notation]]), spe­cy­fi­ka­cji [[OMG Semantics of Business Vocabulary and Business Rules]], oraz RFP [[OMG Organization Structure Metamodel]]. Oznacza to, że nota­cja BMM nie zastę­pu­je ich, a jest dla nich nad­rzęd­na abs­trak­cją. Tak więc pro­ces, jako poje­dyn­cze poję­cie na dia­gra­mie BMM, może zostać szcze­gó­ło­wo opi­sa­ny (model) na innym dia­gra­mie (doku­men­cie), jed­nak defi­ni­cja poję­cia pro­ces biz­ne­so­wy jest taka sama w obu nota­cjach (pro­ces biz­ne­so­wy zawsze musi zna­czyć to samo!).

Poniżej ogól­ny widok pojęć opi­sy­wa­nych nota­cją BMM:

przy­kład two­rze­nia dia­gra­my (klik­nij), oraz model seman­ty­ki i syntaktyki:

BMM nie jest żad­nym narzę­dziem ani meto­dy­ką zarzą­dza­nia czy mode­lo­wa­nia pro­ce­so­we­go, zarzą­dza­nia pro­jek­ta­mi ani spe­cy­fi­ka­cją wzor­co­we­go mode­lu biz­ne­so­we­go. To nota­cja, któ­ra sta­no­wi sobą dobrze zde­fi­nio­wa­ny słow­nik poję­cio­wy (seman­ty­kę) oraz związ­ki pomię­dzy tymi poję­cia­mi (syn­tak­ty­kę, pamię­taj­my, że połą­czo­ne poję­cia nabie­ra­ją kolej­ne­go nowe­go zna­cze­nia, np. kil­ka sko­ja­rzo­nych osób ozna­cza zespół, oso­ba to pro­ste poję­cie, oso­by połą­czo­ne jakimś związ­kiem to grupa).

Wśród wie­lu orę­dow­ni­ków nota­cji UML domi­nu­je teza, że owo Unified (Uniwersalna) w skró­cie UML czy­ni tę nota­cję zdol­ną do mode­lo­wa­nia wszyst­kie­go, jej kolej­ne zasto­so­wa­nia i roz­sze­rze­nia moż­na same­mu opra­co­wać w posta­ci tak zwa­ne­go [[pro­fi­lu UML]]. Owszem, w zasa­dzie teza ta jest praw­dzi­wa jed­nak jest pew­ne ale. Po pierw­sze taki pro­fil to prak­tycz­nie nowa nota­cja: nowe poję­cia (seman­ty­ka) i zasa­dy (syn­tak­ty­ka). Te wyma­ga­ją od stro­ny for­mal­nej wyka­za­nia, że poję­cia (obra­zo­wa­ne z pomo­cą sym­bo­li, zna­ków nota­cji) są roz­łącz­ne, i że seman­tycz­nie (zna­cze­nia­mi) pokry­wa­ją całą mode­lo­wa­ną dzie­dzi­nę. Zapewnienie tego nie jest try­wial­nym problemem.

Tak więc nie tak zno­wu nowa, nota­cja BMM jest przy­dat­na, a dla wie­lu sto­su­ją­cych [[meto­dy for­mal­ne ana­li­zy sys­te­mo­wej]] w tym mode­lo­wa­nie, wręcz potrzeb­na. Nie bra­ku­je gło­sów kry­tycz­nych na temat BMM (np. na blo­gu MSDN), jed­nak oso­bi­ście pod­kre­ślam: nota­cja to nie spo­sób na ana­li­zę a jej narzę­dzie. Notacja nie ma roz­wią­zy­wać wszyst­kich pro­ble­mów, to nie jest srebr­na kula (ang. [[silver bul­let solu­tion]]), któ­rej nie­ste­ty wie­lu nadal szu­ka. Notacja ma poma­gać w roz­wią­zy­wa­niu pro­ble­mów, a to ogrom­na różnica.

Jeżeli kogoś inte­re­su­je nie­co wię­cej szcze­gó­łów o nota­cjach i ich two­rze­niu zapra­szam do dal­szej lektury.

Po co trud­ne” nota­cje sko­ro moż­na pisać po ludzku”

Czy nota­cje mają za cel zastą­pie­nie popu­lar­nej pro­zy? Absolutnie nie! Notacje słu­żą do budo­wy mode­li, któ­re testu­je­my, wery­fi­ku­je, wali­du­je­my. To tak jak z naszym miesz­ka­niem: może­my je w dowol­ny spo­sób opi­sać, mniej lub naj­bar­dziej kwie­ci­stym języ­kiem. Jednak dobry archi­tekt zawsze, nawet na wła­sny uży­tek, stwo­rzy zestaw rysun­ków i wizu­ali­za­cji, by upew­nić się że o niczym nie zapo­mniał. Z pro­jek­tu tech­nicz­ne­go dopie­ro stwo­rzy ład­nie opi­sa­ną pro­zą (języ­kiem natu­ral­nym, zro­zu­mia­łym dla każ­de­go) listę czę­ści i pod­ze­spo­łów, jed­nak ryzy­ko, że tak stwo­rzo­na spe­cy­fi­ka­cja będzie nie­kom­plet­ne teraz jest minimalne.

Zapewne wie­lu z Państwa było w skle­pie IKEA po meble, być może ktoś z Państwa sam je mon­to­wał. Liczba ele­men­tów, łączeń, paso­wań, łącz­ni­ków itp. jest ogrom­na już w śred­niej wiel­ko­ści zesta­wie mebli kuchen­nych. Czy wyobra­ża­cie sobie Państwo zapro­jek­to­wa­nie takich mebli bez spraw­dze­nia na rysun­kach tech­nicz­nych czy nicze­go nie bra­ku­je i czy wszyst­ko do sie­bie pasu­je? A teraz wyobraź­cie sobie Państwo, że więk­szość firm w któ­rych pra­cu­je­cie jest dale­ko bar­dziej skom­pli­ko­wa­na, a mimo to wie­lu ana­li­ty­ków podej­mu­je pró­by opi­sa­nia ich pro­sty­mi sło­wa­mi… jest to nie­mal­że nie­moż­li­we bez popeł­nie­nia wie­lu błędów.

Czym są formalne notacje

Swego cza­su napi­sa­łem w arty­ku­le o nota­cjach i modelowaniu:

Jednym z tych [pod­sta­wo­wych w sto­sun­ku do mode­li i uży­wa­nych w nich nota­cji] wyma­gań jest spój­ny i peł­ny model poję­cio­wy. Tak zwa­na prze­strzeń nazw (w nota­cji jest to lista sym­bo­li i defi­ni­cje ich zna­czeń) powin­na być ?wypeł­nio­na? defi­ni­cja­mi cał­ko­wi­cie, zaś obsza­ry defi­nio­wa­nych pojęć nie mogą na sie­bie nacho­dzić. (źr. Modelowanie pro­ce­sów biz­ne­so­wych).

Nieco bli­żej o tym. Notacja to model poję­cio­wy, zestaw sym­bo­li i ich zna­czeń (seman­ty­ka) oraz gra­ma­ty­ka łącze­nia tych pojęć (tak zwa­na syn­tak­ty­ka czy­li dopusz­czal­ne związ­ki pomię­dzy poję­cia­mi i ich zna­cze­nia). W czym pro­blem? Poniżej dia­gram go obrazujący.

Slajd10

Zestaw wszyst­kich słów-sym­bo­li to lista dopusz­czal­nych w mode­lu (opi­sie) pojęć i jest to wła­śnie tak zwa­na seman­ty­ka nota­cji (prze­strzeń nazw). Koło ozna­cza wybra­ną dzie­dzi­nę (np. mode­le biz­ne­so­we i biz­ne­spla­ny). Kółeczka z krzy­ży­ka­mi to poję­cia (obra­zo­wa­ne w nota­cjach sym­bo­la­mi, iko­na­mi nota­cji), dopusz­czal­ne sło­wa ze słow­ni­ka, któ­re­go chce­my użyć do opi­sa­nia cze­goś w danej dzie­dzi­nie (zwa­nej tak­że domeną).

Po lewej stro­nie mamy namiast­kę nie­for­mal­ne­go, potocz­ne­go języ­ka: to co widzi­my, poję­cia, byty czy­li krzy­ży­ki oraz sło­wa pozwa­la­ją­ce na ich nazwa­nie (ciem­niej­sze obsza­ry). Język potocz­ny cha­rak­te­ry­zu­je się tym, że zawie­ra sło­wa okre­śla­ją­ce róż­ne poję­cia (dwa krzy­ży­ki w jed­nym polu zna­cze­nio­wym, np. zamek to budow­la ale tak­że mecha­nizm zamknię­cia drzwi), poja­wia­ją się róż­ne sło­wa na jed­no zna­cze­nie (krzy­żyk nale­żą­cy do dwóch róż­nych obsza­rów, np. gar­nek i saga­nek to nie raz to samo naczy­nie). Pojawiają się tak­że byty nie mają­ce ozna­cza­ją­cych je słów (w danym języ­ku oczy­wi­ście, krzy­żyk nie przy­po­rząd­ko­wa­ny do żad­ne­go pola, np. inter­fejs, któ­ry nie ma swo­je­go odpo­wied­ni­ka w języ­ku pol­skim, uży­wa­my sło­wa angielskiego).

Taka sytu­acja, opi­sa­ne nie­jed­no­znacz­no­ści, powo­du­je, że typo­wy prze­kaz tek­sto­wy jest prze­ka­zem nie­jed­no­znacz­nym: czy­ta­ją­cy może odczy­tać z tek­stu coś inne­go niż to co miał na myśli jego autor. Nie da się go, takie­go tek­stu, zwe­ry­fi­ko­wać od stro­ny spój­no­ści i kom­plet­no­ści opi­sy­wa­nej rzeczywistości.

Po pra­wej stro­nie mamy sytu­ację ide­al­ną: pojęć jest dokład­nie tyle ile zna­czeń (słów), każ­de poję­cie ma tyl­ko jed­no zna­cze­nie zaś tak zwa­na prze­strzeń nazw (obszar, do któ­re­go nale­żą, miesz­czą­cy wszyst­kie poję­cia danej dzie­dzi­ny) jest zupeł­nie opi­sa­ny (brak obsza­ru, zna­cze­nia, nie obję­te­go zadnym sło­wem). Opisanie cze­goś języ­kiem” (sło­wa­mi) z takiej prze­strze­ni nazw czy­ni prze­kaz jed­no­znacz­ny w 100% (nie ist­nie­ją w danej prze­strze­ni syno­ni­my i nie ma pojęć nie­zde­fi­nio­wa­nych). Jak być może nie trud­no się domy­śleć, opra­co­wa­nie sys­te­mu poję­cio­we­go speł­nia­ją­ce­go powyż­sze wyma­ga­nia, nie jest łatwe.

Dobra nota­cja ma jesz­cze jed­ną istot­ną cechę: sym­bo­le obra­zu­ją­ce poszcze­gól­ne poję­cia powin­ny się z nimi koja­rzyć nie­za­leż­nie od języ­ka natu­ral­ne­go. To nazy­wa­my [[semio­ty­ką]]. Jest to nauka o tym jak czło­wiek postrze­ga (rozu­mie, odbie­ra) poszcze­gól­ne zna­ki gra­ficz­ne (sym­bo­le, iko­ny). To tak­że powo­du­je, że dąży się do stan­da­ry­za­cji czy­li nie mno­że­nia nad­mia­ru sys­te­mów nota­cyj­nych (patrz [[brzy­twa Ockhama]]). To dla­te­go two­rze­nie wła­snych nota­cji jest trosz­kę pozba­wio­ne sen­su: jest bar­dzo trud­ne i odda­la nas od standardów.

Na zakończenie

Stosowanie ana­li­zy sys­te­mo­wej, mode­lo­wa­nia oraz for­mal­nych nota­cji do two­rze­nia mode­li, powo­du­je, że wyni­ki ana­liz są dale­ko bar­dziej wia­ry­god­ne. Z regu­ły celem pra­cy ana­li­ty­ka biz­ne­so­we­go czy pro­jek­tan­ta jest opra­co­wa­nie opi­su reko­men­do­wa­ne­go roz­wią­za­nia. Może nim być doce­lo­wy model orga­ni­za­cji czy też opis opro­gra­mo­wa­nia jakie nale­ży dostar­czyć (bo nie zawsze wytwo­rzyć!). W pro­ce­sie for­mal­nej ana­li­zy sys­te­mo­wej (nie jest to ana­li­za sys­te­mu infor­ma­tycz­ne­go, to ana­li­za dowol­ne­go sys­te­mu), powsta­ją mode­le, któ­re testujemy.

Taki model to naj­pierw hipo­te­za, a po wery­fi­ka­cji, jest to opis roz­wią­za­nia (pro­jekt tego co ma powstać). Idealną sytu­acją była by taka, a któ­rej mamy narzę­dzia do mode­lo­wa­nia każ­dej ana­li­zo­wa­nej dzie­dzi­ny. W kla­sycz­nej inży­nie­rii jest to rysu­nek tech­nicz­ny i zasa­dy obli­cza­nia wytrzy­ma­ło­ści, sfor­ma­li­zo­wa­ny sys­tem two­rze­nia sche­ma­tów elek­trycz­nych i elek­tro­nicz­nych i wie­le innych (zależ­nie od dzie­dzi­ny), nota­cje UML w inży­nie­rii opro­gra­mo­wa­nia. W sfe­rze zarzą­dza­nia mie­li­śmy do nie­daw­na bia­ła pla­mę, teraz mamy już BMM czy ArchiMate.

Moim zda­niem utrzy­my­wa­nie, że moż­na coś sku­tecz­nie ana­li­zo­wać meto­da­mi nie­for­mal­ny­mi świad­czy raczej o nie­wie­dzy i bra­ku kom­pe­ten­cji. Bo jak ina­czej nazwać nara­ża­nie adre­sa­ta pro­jek­tu (nie raz klien­ta) na masę nie­spój­no­ści owo­cu­ją­cych lawi­no­wo rosną­cy­mi kosz­ta­mi reago­wa­nia na nie­prze­wi­dzia­ne szcze­gó­ły? Nie raz sły­sza­łem, że to trud­ne, tyl­ko dla jajo­gło­wych, kosz­tow­ne. Owszem, ale nie zapo­mi­naj­my, że ana­li­za to nie coś co każ­dy sobie sam może zro­bić. Dobra ana­li­za nigdy nie jest kosz­tow­niej­sza niż poten­cjal­ne, ryzy­ko­wa­ne stra­ty – opła­ci się zawsze.

Prezentacja opi­su­ją­ca klu­czo­we ele­men­ty nota­cji BMM

Przykład uży­cia nota­cji BMM: spo­sób mode­lo­wa­nia.

Skrócony opis – klu­czo­we pojęcia.