Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Czytaj dalej… Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie”

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ą”).

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.