Korzystanie pośrednie nową obawą użytkowników systemów ERP

Niedawno bla­dy strach padł na użyt­kow­ni­ków opro­gra­mo­wa­nie SAP AG za spra­wą pew­ne­go pro­ce­su i wyroku: 

Po nie­daw­nym orze­cze­niu bry­tyj­skie­go Sądu Najwyższego, któ­ry potwier­dził pra­wo fir­my SAP do nali­cza­nia opłat za pośred­nie korzy­sta­nie z sys­te­mów SAP przy uży­ciu takich apli­ka­cji innych firm jak Salesforce, WorkDay i QlikView, korzy­sta­nie pośred­nie jest obec­nie wymie­nia­ne przez klien­tów fir­my SAP jako głów­na oba­wa w obsza­rze zarzą­dza­nia licen­cja­mi SAP i kon­tro­lo­wa­nia ich kosz­tów. […] W ostat­nich tygo­dniach ryzy­ko zwią­za­ne z korzy­sta­niem pośred­nim ? dotych­czas głów­nie teo­re­tycz­ne ? sta­ło się rze­czy­wi­sto­ścią, któ­ra może zmu­sić wie­le przed­się­biorstw do ponie­sie­nia milio­no­wych nie­za­bu­dże­to­wa­nych kosz­tów dodat­ko­wych licen­cji SAP. (Źródło: Korzystanie pośred­nie głów­ną oba­wą klien­tów SAP – ERP​-view​.pl

Cóż to jest to korzy­sta­nie pośred­nie” i w czym problem? 

In this instan­ce, the third par­ty sys­tems are acces­sing the SAP envi­ron­ment, pul­ling data and often wri­ting it back via a con­nec­tion to the SAP envi­ron­ment. Here a ?user? must be set up to gain access to the SAP sys­tem. On the sur­fa­ce then it can appe­ar like only one user (or a small num­ber of users) is per­for­ming actions on the SAP sys­tem. In reali­ty tho­ugh, the ?user? will be per­for­ming far more tasks than is possi­ble for a sin­gle per­son to under­ta­ke. (Źródło: SAP Audits ? Is it impos­si­ble to gau­ge finan­cial expo­su­re? – IT Asset Knowledgebase) 

Generalnie cho­dzi o to, że inte­gro­wa­ne ze sobą apli­ka­cje wymie­nia­ją dane i zle­ca­ją sobie” usłu­gi, i tu war­to wie­dzieć co (dane, logi­ka apli­ka­cyj­na) jest chro­nio­ne pra­wa­mi autor­ski­mi i co sta­no­wi know how. Problem tkwi w popraw­nym zde­fi­nio­wa­niu przed­mio­tu (obiek­tu) prze­twa­rza­nia, przed­mio­tu pra­wa autor­skie­go i tego co sta­no­wi know-how. 

W tek­ście Ochrona know-how orga­ni­za­cji ana­li­zo­wa­nej pisa­łem dość dokład­nie o pra­wach autor­skich i know-how. Tu kil­ka klu­czo­wych pojęć. 

USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych mówi:

Art. 1. 1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).

Art. 2.
1. Opracowanie cudze­go utwo­ru, w szcze­gól­no­ści tłu­ma­cze­nie, prze­rób­ka, adap­ta­cja, jest przed­mio­tem pra­wa autor­skie­go bez uszczerb­ku dla pra­wa do utwo­ru pierwotnego.
2. Rozporządzanie i korzy­sta­nie z opra­co­wa­nia zale­ży od zezwo­le­nia twór­cy utwo­ru pier­wot­ne­go (pra­wo zależ­ne), chy­ba że autor­skie pra­wa mająt­ko­we do utwo­ru pier­wot­ne­go wyga­sły. W przy­pad­ku baz danych speł­nia­ją­cych cechy utwo­ru zezwo­le­nie twór­cy jest koniecz­ne tak­że na spo­rzą­dze­nie opracowania.
2. (1) Ochroną obję­ty może być wyłącz­nie spo­sób wyra­że­nia; nie są obję­te ochro­ną odkry­cia, idee, pro­ce­du­ry, meto­dy i zasa­dy dzia­ła­nia oraz kon­cep­cje matematyczne.

USTAWA z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji, mówi, że:

Art. 11.
4. Przez tajem­ni­cę przed­się­bior­stwa rozu­mie się nie­ujaw­nio­ne do wia­do­mo­ści publicz­nej infor­ma­cje tech­nicz­ne, tech­no­lo­gicz­ne, orga­ni­za­cyj­ne przed­się­bior­stwa lub inne infor­ma­cje posia­da­ją­ce war­tość gospo­dar­czą, co do któ­rych przed­się­bior­ca pod­jął nie­zbęd­ne dzia­ła­nia w celu zacho­wa­nia ich poufności.

Tak więc mamy klu­czo­we poję­cie: utwór oraz know-how. Utworem jest uni­kal­na treść zaś know-how to nie­ujaw­nio­ne i chro­nio­ne (!) infor­ma­cje (tre­ści) tech­nicz­ne, orga­ni­za­cyj­ne lub gospodarcze.

Czym jest owo pośred­nie korzy­sta­nie z sys­te­mu SAP”? Drugi tekst wyja­śnia: acces­sing the SAP envi­ron­ment, pul­ling data and often wri­ting it back via a con­nec­tion to the SAP envi­ron­ment. Here a ?user? must be set up to gain access to the SAP sys­tem”. Czyli pobie­ra­nie i zapi­sy­wa­nie danych”, użyt­kow­nik by mógł tego doko­nać” musi mieć dostęp Systemu SAP.

Jednak sam fakt ist­nie­nia dostę­pu i korzy­sta­nia z nie­go, nie ozna­cza korzy­sta­nia z cudzych war­to­ści intelektualnych!

Najpierw model takie­go przypadku:

Użytkownik bez­po­śred­ni Systemu to stan­dar­do­wy”, licen­cjo­no­wa­ny użyt­kow­nik. Aplikacja pośred­ni­czą­ca tak­że korzy­sta z licen­cjo­no­wa­ne­go dostę­pu (API). Jak, i z cze­go (i czy), korzy­sta Użytkownik pośred­ni Systemu?

Żeby wska­zać to, z cze­go korzy­sta zewnętrz­ny użyt­kow­nik (aktor) Systemu, nale­ży zaj­rzeć” do wnę­trza sys­te­mu. Architektura Systemu i inte­gra­cji ma taką postać:

Na tym dia­gra­mie mamy trzy klu­czo­we ele­men­ty (tu arte­fak­ty) repre­zen­tu­ją­ce war­to­ści inte­lek­tu­al­ne chro­nio­ne pra­wem: Logika biz­ne­so­wa, Zebrane dane i Strukturę danych. Logika biz­ne­so­wa to spo­sób (meto­dy) prze­twa­rza­nia infor­ma­cji (danych) zawar­te w pro­gra­mie kom­pu­te­ro­wym, sta­no­wią (mogą sta­no­wić) know-how fir­my, sam pro­gram kom­pu­te­ro­wy (jego treść) to usta­lo­ny utwór. Prawo autor­skie chro­ni bazy danych (zebra­ne i upo­rząd­ko­wa­ne dane) zaś struk­tu­ra danych (pro­jekt, model danych) to tak­że utwór chroniony.

Zintegrowana z Systemem apli­ka­cja korzy­sta z API Systemu. API stan­dar­do­wo pozwa­la np: na pobra­nie obiek­tu, wsta­wie­nie obiek­tu oraz wyko­na­nie ope­ra­cji z uży­ciem logi­ki biznesowej. 

Zasadnicze pyta­nie brzmi: co w Systemie sta­no­wi pro­dukt dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze”? Na pew­no jest to opro­gra­mo­wa­nie jako takie oraz struk­tu­ra (model) danych oraz baza danych, czy­li zebra­ne dane (z uwa­gi na ich uni­kal­ną struk­tu­rę, model, w bazie danych). Jednak pro­gram reali­zu­je okre­ślo­ną logi­kę biz­ne­so­wą (ope­ra­cje na danych) i prze­twa­rza okre­ślo­ne obiek­ty biz­ne­so­we, czy­li okre­ślo­ne zesta­wy danych takie jak fak­tu­ra czy doku­ment maga­zy­no­wy WZ. Ogólnie ope­ra­cje z uży­ciem Systemu (apli­ka­cji) mają np. taką postać:

Jest to przy­kład moż­li­we­go dia­lo­gu użyt­kow­ni­ka (aktor) z apli­ka­cją (System). Dialog taki, nie­za­leż­nie od stop­nia kom­pli­ka­cji, będzie się skła­dał z ope­ra­cji będą­cych logi­ką biz­ne­so­wą (czy­li spe­cy­fi­ką dzie­dzi­ny) lub tech­nicz­ną (spe­cy­fi­ką tech­no­lo­gii imple­men­ta­cji). Przedmiotem prze­twa­rza­nia będą okre­ślo­ne obiek­ty biz­ne­so­we (nazwa­ne zesta­wy danych), komu­ni­kat na ekra­nie tak­że może być takim obiek­tem (jeże­li tym komu­ni­ka­tem jest treść doku­men­tu a nie tyl­ko tekst mówią­cy, że coś zosta­ło wyko­na­ne np. bez błędu).

Tu jed­nak mamy do czy­nie­nia z opro­gra­mo­wa­niem wspie­ra­ją­cym mię­dzy inny­mi ope­ra­cje opi­sa­ne w usta­wach (księ­go­we). Niewątpliwie pra­wo chro­ni struk­tu­rę danych, dane zebra­ne w bazie danych oraz know-how, to któ­re jest nie­zna­ne innym”. Jednak pra­wo nie chro­ni idei, nie chro­ni też tego co jest powszech­nie zna­ne”. Warto tak­że wie­dzieć, że wdro­że­nie w toku któ­re­go mia­ła miej­sce tak zwa­na kasto­mi­za­cja, wno­si” know-how przy­szłe­go użyt­kow­ni­ka do kodu, i za korzy­sta­nie z tej logi­ki dostaw­ca opro­gra­mo­wa­nia nie ma pra­wa brać wyna­gro­dze­nia. Pod warun­kiem jed­nak, że kod reali­zu­ją­cy to wnie­sio­ne know-how jest jaw­nie wydzielony! 

Nie ma jed­no­znacz­nej odpo­wie­dzi na pyta­nie czy w danym przy­pad­ku ma miej­sce korzy­sta­nie pośred­nie z opro­gra­mo­wa­nia, nie­wąt­pli­wie sam fakt inte­gra­cji nie sta­no­wi korzy­sta­nia pośred­nie­go. Nie jest tez praw­dą, ze sam fakt inte­gra­cji auto­ma­tycz­nie impli­ku­je korzy­sta­nie pośred­nie wyma­ga­ją­ce opła­ty licen­cyj­nej. Kluczem do stwier­dze­nia tego jest wie­dza o archi­tek­tu­rze sys­te­mu, o archi­tek­tu­rze cało­ści inte­gra­cji i o tym jakie ope­ra­cje i gdzie są wyko­ny­wa­ne. Na szczę­ście to dostaw­ca Systemu musi uza­sad­nić swo­je rosz­cze­nia doty­czą­ce wła­sno­ści inte­lek­tu­al­nej, jed­nak korzy­sta­ją­cy z tego Systemu – jeże­li nie potra­fi podać kontr­ar­gu­men­tów – nie jest w sta­nie się obro­nić. Niestety naj­więk­szym pro­ble­mem jest wdro­że­nie pole­ga­ją­ce na kasto­mi­za­cji, gdyż docho­dzi do wple­ce­nia” nowej logi­ki biz­ne­so­wej do już ist­nie­ją­cej w dostar­cza­nym oprogramowaniu.

Skutek jest taki, że dostaw­ca opro­gra­mo­wa­nia ma pod­sta­wy praw­ne do ochro­ny kodu jaki dostar­czył, jed­nak kupu­ją­cy nie ma żad­nych pod­staw (doku­men­ty, pro­jekt itp.) by chro­nić swo­je know-how i by nie pła­cić za swo­je wła­sne know-how wło­żo­ne” w toku wdro­że­nia, do wdra­ża­ne­go oprogramowania. 

Dlatego war­to restryk­cyj­nie pro­wa­dzić pro­ces ana­li­zy i pro­jek­to­wa­nia, to jest umie­jęt­nie udo­ku­men­to­wać pro­jekt tak, by gra­ni­ca pomię­dzy war­to­ścia­mi inte­lek­tu­al­ny­mi dostaw­cy i nabyw­cy opro­gra­mo­wa­nia była jasno okre­ślo­na. I nie jest to rola praw­ni­ka a archi­tek­ta cało­ści sys­te­mu, któ­ry musi tak­że znać i rozu­mieć praw­ne aspek­ty tej architektury. 

Czy wdrożenie zawsze wymaga reorganizacji?

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi ini­cjo­wa­ny­mi przez śred­nie kadry kie­row­ni­cze dużych firm i urzę­dów, czę­sto mają one pew­ną wspól­ną cechę: nie może­my nic zmie­niać w stra­te­gii orga­ni­za­cji ale chce­my uspraw­nić pra­cę w naszym wydzia­le”. To z regu­ły bar­dzo cen­na ini­cja­ty­wa ale tak­że dobra dro­ga do poraż­ki pro­jek­tu. W urzę­dach czę­sto na gra­ni­cy łama­nia pra­wa… a nie raz z jego łama­niem. 

Projekty w admi­ni­stra­cji publicz­nej mają dodat­ko­wą spe­cy­fi­kę: zasa­dy usta­la pra­wo­daw­ca a nie mene­dżer orga­ni­za­cji. Bardzo dobrze opi­sał to zja­wi­sko prof. Bolesław Szafrański wska­zu­jąc przy­czy­nę wie­lu pora­żek wdro­żeń w admi­ni­stra­cji. Opisał trzy-eta­po­wy refe­ren­cyj­ny (i zale­ca­ny) pro­ces wdra­ża­nia nowych roz­wią­zań, a na jego tle, w swo­im opra­co­wa­niu, wska­zał dostrze­żo­ne zanie­dba­nia administracji:

(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, Architektura kor­po­ra­cyj­na ? pro­ble­my nie tyl­ko pojęciowe”)

Cytuję to opra­co­wa­nie, bo model ten jest bar­dzo podob­ny do ogól­nej trój­war­stwo­wej kon­cep­cji orga­ni­za­cji. Prof Szafrański zwra­ca uwa­gę na to (z czym się zga­dzam), że kolej­ność podej­mo­wa­nia decy­zji i dzia­łań, powin­na być nastę­pu­ją­ca: opra­co­wa­nie nowej lub zmie­nio­nej stra­te­gii (Dokument stra­te­gicz­ny), opra­co­wa­nie tak­ty­ki dzia­ła­nia (Model ope­ra­cyj­ny dzia­ła­nia) oraz opra­co­wa­nie pla­nu wdro­że­nia IT (Fundament dzia­łal­no­ści, w kon­tek­ście Architektury Korporacyjnej). Oczywiście nic nie stoi na prze­szko­dzie, by ini­cja­ty­wa wyszła od dołu”.

W swo­im opra­co­wa­niu prof. Szafrański wska­zu­je, że wdro­że­nie nowej stra­te­gii wyma­ga spraw­dze­nia i ewen­tu­al­ne­go opra­co­wa­nia nowych mecha­ni­zmów, pro­ce­dur, pra­wa, pozwa­la­ją­ce­go nie tyl­ko wdro­żyć nową stra­te­gię ale tak­że sku­tecz­nie ją wymu­sić”.

Jeżeli powyż­szy model uogól­nić do posta­ci obra­zu­ją­cej zwią­zek pomię­dzy: stra­te­gią ryn­ko­wą orga­ni­za­cji, wewnętrz­ną tak­ty­ką reali­za­cji misji oraz tym jak zosta­ły one zaim­ple­men­to­wa­ne, to powsta­nie taki oto dia­gram (po pra­wej zna­ne od lat opra­co­wa­nie Business Process Trends):

Jeżeli pomiąć for­mę praw­ną, każ­da orga­ni­za­cja ma stra­te­gię i każ­da jakoś ją reali­zu­je (imple­men­tu­je: ma pra­cow­ni­ków a Ci umie­jęt­no­ści i zakre­sy obo­wiąz­ków). Mało któ­ra orga­ni­za­cja ma tak zwa­ny model ope­ra­cyj­ny”, czy­li to co łączy stra­te­gię i ludzi z ich obo­wiąz­ka­mi i uzy­ski­wa­ny­mi efek­ta­mi pra­cy. Czym jest taki model? To model pro­ce­sów biz­ne­so­wych: środ­ko­wa war­stwa” powyż­sze­go dia­gra­mu po prawej.

Rozwijające się ewo­lu­cyj­nie orga­ni­za­cje zawsze doku­men­tu­ją deta­le prac (infor­ma­cje w pro­ce­du­rach zarzą­dza­nia jako­ścią i tak zwa­nych doku­men­tach kadro­wych), czę­sto doku­men­tu­ją to, jaką rolą peł­ni orga­ni­za­cja w swo­im oto­cze­niu (misja, wizja, stra­te­gie itp.) i bar­dzo rzad­ko doku­men­tu­ją wewnętrz­ny łań­cuch war­to­ści czy­li pro­ce­sy biz­ne­so­we oraz, no naj­waż­niej­sze, logi­ka tego jak to wszyst­ko dzia­ła” w środ­ku (i czy dzia­ła z sen­sem). Wadą więk­szo­ści tego typu pro­jek­tów, jakie obser­wu­ję, jest sku­pia­nie się na deta­lach i pomi­ja­nie pryn­cy­piów. W efek­cie pro­jekt pochła­nia wie­le pra­cy i nadal nie mamy zro­zu­mie­nia cało­ści (w lit. ang. big pic­tu­re”), osią­ga­ne efek­ty są losowe. 

Pokażę na dość pro­stym przy­kła­dzie o czym mowa (pole­cam ww. opra­co­wa­nie prof. Szafrańskiego, opi­sał w nim błę­dy popeł­nio­ne w przy­pad­ku infor­ma­ty­za­cji Państwa). 

Poniższy dia­gram to uprosz­czo­ny model orga­ni­za­cji z zain­sta­lo­wa­nym sys­te­mem EOD (Elektroniczny Obieg Dokumentów) oraz zacho­wa­nym, nadal wyko­rzy­sty­wa­nym po sta­re­mu” opro­gra­mo­wa­niem pocz­ty elektronicznej. 

Linie cią­głe to dro­ga jaką poko­nu­ją doku­men­ty z uży­ciem EOD. Linie prze­ry­wa­ne to pocz­ta elek­tro­nicz­na. Jeżeli zosta­nie w jakiejś orga­ni­za­cji zain­sta­lo­wa­ny EOD (celo­wo nie uży­wam sło­wa wdro­żo­ny”) i nie zosta­nie z niej usu­nię­ty ema­il jako narzę­dzie alter­na­tyw­nej wewnętrz­nej komu­ni­ka­cji, to użyt­kow­nik będzie sam decy­do­wał, o tym któ­rym kana­łem prze­ka­że daną treść. W efek­cie EOD, któ­ry miał mieć wszyst­ko” nie ma wszyst­kie­go, dane w EOD są nie­wia­ry­god­ne i nie­kom­plet­ne. Jeżeli jest to urząd, to metry­ka spra­wy w zasa­dzie nie ma sen­su, celem jej two­rze­nia była moż­li­wość odtwo­rze­nia peł­ne­go prze­bie­gu spra­wy, a tu urzęd­nik sam decy­du­je, któ­re infor­ma­cje i doku­men­ty prze­ka­zu­je kana­łem for­mal­nym (EOD), a któ­re na boku”. Czy wszyst­ko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tyl­ko uzna­nio­wym archi­wum dokumentów. 

Aby sku­tecz­nie wdro­żyć EOD nale­ży naj­pierw opra­co­wać nowy model ope­ra­cyj­ny dzia­ła­nia orga­ni­za­cji, model uwzględ­nia­ją­cy nowe narzę­dzie pra­cy, model któ­ry w spo­sób sys­te­mo­wy wyeli­mi­nu­je nie­po­żą­da­ne ele­men­ty złe­go sta­re­go sys­te­mu”. Dla przy­kła­du powy­żej nale­ży wyeli­mi­no­wać kana­ły komu­ni­ka­cyj­ne ozna­czo­ne linią prze­ry­wa­ną. Domyślam się, że wie­lu czy­tel­ni­ków myśli teraz no jak to tak bez maila?!”. Po wdro­że­niu EOD, wewnętrz­ny mail jest już nie potrzeb­ny (a nawet jest szko­dli­wy), a na zewnątrz nadal jest narzę­dziem komu­ni­ka­cji fir­ma-fir­ma (tak np. dzia­ła mój sys­tem komu­ni­ka­cji z klien­ta­mi). Bardzo czę­sto spo­ty­kam urzę­dy i fir­my, w któ­rych obieg ema­il i obieg for­mal­ny” to uzna­nio­wość pra­cow­ni­ków. Te wdro­że­nia nie speł­nia­ją pod­sta­wo­wej roli sys­te­mów EOD: śle­dze­nie spraw, sta­ty­sty­ki zaję­to­ści pra­cow­ni­ków, wychwy­ty­wa­nie wąskich gar­deł, łatwe zastę­po­wa­nie się pra­cow­ni­ków, moż­li­wość skon­tro­lo­wa­nia i prze­ję­cia spra­wy w dowol­nym momen­cie, peł­na histo­ria wymia­ny informacji. 

Takie wdro­że­nia to wła­śnie bar­dzo czę­sto ini­cja­ty­wy na śred­nich szcze­blach, gdzie mogą powstać decy­zje o wyda­niu środ­ków na takie wdro­że­nie, ale nie ma żad­nych szans na decy­zje o opra­co­wa­niu i wdro­że­niu zmian ope­ra­cyj­nych w ska­li orga­ni­za­cji (np. aktu­ali­za­cja instruk­cji kan­ce­la­ryj­nej w urzę­dzie, bez cze­go wdro­że­ni EOD nie ma tu żad­ne­go sensu).

Celowo poda­łem ten przy­kład, bo typo­wym powo­dem nie­po­wo­dzeń wdro­żeń sys­te­mów EOD czy CRM (te sys­te­my mają naj­gor­szą sta­ty­sty­kę nie­po­wo­dzeń, a są bar­dzo podob­ne do sie­bie), jest brak opra­co­wa­ne­go i wdro­żo­ne­go sku­tecz­ne­go nowe­go ope­ra­cyj­ne­go mode­lu dzia­ła­nia orga­ni­za­cji po wdro­że­niu”. Takim mode­lem są mode­le pro­ce­sów biz­ne­so­wych, ale nie w posta­ci mon­stru­al­nych ilo­ści deta­licz­nych dia­gra­mów (te są tu do nicze­go nie przy­dat­ne). Nie znam przy­pad­ku, by takie obraz­ki” się do cze­go­kol­wiek przy­da­ły. Chodzi o mode­le sfor­ma­li­zo­wa­ne, o ści­śle usta­lo­nym pozio­mie gra­da­cji pro­ce­sów. Ile dia­gra­mów powin­no być”? Tylko i aż tyle, ile trze­ba do roz­wią­za­nia pro­ble­mu… co opi­sa­łem mię­dzy inny­mi tu.

Powyższe ma tak­że inny istot­ny aspekt: pla­no­wa­nie i wdra­ża­nie zmian. Typowy roz­wój orga­ni­za­cji prze­bie­ga w spo­sób ewo­lu­cyj­ny, dość powol­ny. Nie wyma­ga żad­nych dodat­ko­wych zabie­gów poza prze­my­śla­nym wpro­wa­dza­niem nowych, poje­dyn­czych zarzą­dzeń czy drob­nych zmian orga­ni­za­cyj­nych. Jednak pró­by wdro­że­nia znacz­nych zmian w krót­kim cza­sie, z regu­ły skut­ku­ją nie­ocze­ki­wa­ny­mi efek­ta­mi, nie zawsze pożą­da­ny­mi. Moda” na re-inży­nie­rię pro­ce­sów biz­ne­so­wych w latach 90-tych prze­mi­nę­ła tak szyb­ko jak się poja­wi­ła. Dzisiejszy sil­nie kon­ku­ren­cyj­ny rynek nie daje cza­su na powol­ne, ewo­lu­cyj­ne zmia­ny. Bezpieczne zaś wpro­wa­dza­nie takich zmian nie jest moż­li­we bez przy­go­to­wa­nia. Opisane powy­żej pla­ny ope­ra­cyj­ne i ich testy, to nic inne­go jak wła­śnie przy­go­to­wa­nie się do takich zmian. Mając dobrze opra­co­wa­ne mode­le pro­ce­sów i archi­tek­tu­ry IT (jako całość Architektura Biznesowa/Korporacyjna), może­my prze­wi­dzieć i prze­te­sto­wać, więk­szość skut­ków pla­no­wa­nych zmian, i powo­li ale coraz wię­cej firm to robi… 

What’s New in Visual Paradigm 13.2? Czyli co nowego…

Kolejna odsło­na w roz­wo­ju opro­gra­mo­wa­nia CASE fir­my Visual Paradigm. Agile, pierw­szych katach chur­ra opty­mi­zmu, zaczy­na trosz­kę się kry­sta­li­zo­wać co zauwa­żył już [[Scott Ambler]] 12 lat temu:

książ­ka trak­tu­ją­ca o tym, że zwin­ność nie ozna­cza bała­ga­nu i pospo­li­te­go rusze­nia. Scott Ambler to kolej­ny auto­ry­tet w inży­nie­rii opro­gra­mo­wa­nia. I mimo, że niko­go nie ma sen­su mał­po­wać, na pew­no war­to się uczyć? (Źródło: Agile Modeling. Effective Practices for Modeling and Documentation | | Jarosław Żeliński IT-Consulting)

Visual-Paradigm to tak­że zestaw narzę­dzi Agile pozwa­la­ją­cych z jed­nej stro­ny zwin­nie zarzą­dzać pro­jek­to­wa­niem i pro­jek­tem (to nie jest to samo) z dru­giej nie zanie­dby­wać ana­li­zy i mode­lo­wa­nia tam gdzie to jed­nak pomaga.

Nowe ele­men­ty v.13.2.:

  1. Kanban Board to nowe narzę­dzie pozwa­la­ją­ce zarzą­dzać zakre­sem pro­jek­tu i jego reali­za­cją. Kanban to opra­co­wa­na w latach pięć­dzie­sią­tych w Japonii meto­da ste­ro­wa­nia pro­duk­cją. Słowo kan­ban w wol­nym tłu­ma­cze­niu moż­na w poniż­szym przy­pad­ku oddać jako ?spis widocz­ny?. Tu prak­tycz­nie ozna­cza to co zna­my pod nazwą bac­klog” tyle, że wer­sji widocz­nej” jako tabli­cę postę­pu prac: bil­bo­ard dostęp­ny dla człon­ków zespołu.
  2. User Story Estimation to nowy para­metr obiek­tów user sto­ry”. Generalnie tu (w tym narzę­dziu) user sto­ry to nie pro­za użyt­kow­ni­ka” a sfor­ma­li­zo­wa­na wer­sja zna­na jako sza­blon ja jako .… chciał­bym osią­gnąć.… mając do dys­po­zy­cji …”, histo­ryj­ki te są para­me­try­zo­wa­ne mie­dzy inny­mi (teraz) esty­ma­cja cza­su ich imple­men­ta­cji co bar­dzo uła­twia zarza­dza­nie projektem.
  3. Kroki wyma­ga­ją­ce potwier­dze­nia, nowa cecha spe­cy­fi­ka­cji przy­pad­ków uży­cia, bar­dzo waż­na rzecz w spe­cy­fi­ko­wa­niu przy­pad­ków uży­cia to wska­za­nie tych kro­ków sce­na­riu­szy, któ­re wyma­ga­ją potwier­dze­nia przez system.
  4. Szybki pod­gląd (tak­że zesta­wie­nie) histo­ry­jek użyt­kow­ni­ka, w toku pro­jek­tu klu­czo­we jest śle­dze­nie pro­jek­tu, któ­ry nie raz ma set­ki deta­li w zakre­sie, od teraz dys­po­nu­je­my odpo­wied­ni­mi zesta­wie­nia­mi i pod­su­mo­wa­nia­mi, to jedy­ny spo­sób na spraw­ne zarza­dza­nie zakre­sem projektu.
  5. Makiety ekra­nów to kolej­ny bar­dzo waż­ny ele­ment komu­ni­ka­cji z zama­wia­ją­cym i defi­nio­wa­niem zakre­su pro­jek­tu, roz­bu­do­wa­na zosta­ła pale­ta ele­men­tów i ich cech.
  6. CMMN (Case Management Model and Notation) to nota­cja opu­bli­ko­wa­na for­mal­nie w 2014 roku. Notacja BPMN ma za cel mode­lo­wa­nie pro­ce­sów biz­ne­so­wych czy­li powta­rzal­nych zacho­wań orga­ni­za­cji, CMMN to narzę­dzie do mode­lo­wa­nia kon­kret­nych (ziden­ty­fi­ko­wa­nych) aktyw­no­ści, nie prze­wi­dzia­nych w mode­lach pro­ce­sów, tak­że do mode­lo­wa­nia pro­po­no­wa­nych (zaak­cep­to­wa­nych) roz­wią­zań, w przy­pad­ku gdy dana aktyw­ność stwa­rza problem.
  7. Zarządzanie pli­ka­mi w repo­zy­to­rium TeamWork (ser­wer) z pozio­mu prze­glą­dar­ki diagramów.
  8. Tymczasowe dia­gra­my ana­li­zy wpły­wu. Do tej pory były zawsze zapa­mię­ty­wa­ne co w dużych pro­jek­tach skut­ko­wa­ło dużą ich licz­bą i prze­cią­ża­niem pro­jek­tu, teraz mogą one być two­rzo­ne w locie” bez koniecz­no­ści ich zachowywania.

Źródło: What’s New in Visual Paradigm 13.2? 

Narzędzie potęż­nie­je z każ­dą kolej­ną wer­sją. Obecnie ofe­ro­wa­ne jest w dwóch wersjach:

  1. Visual-Paradigm (VP) jako narzę­dzie adre­so­wa­ne do wspie­ra­nia pro­ce­sów inży­nie­rii oprogramowania.
  2. ArchiMetric to roz­sze­rze­nie pakie­tu VP, to narzę­dzie wspie­ra­ją­ce pro­wa­dze­nie ana­liz sys­te­mo­wych orga­ni­za­cji, sze­ro­ko poję­te­go mode­lo­wa­nia archi­tek­tu­ry biz­ne­so­wej (kor­po­ra­cyj­nej).

W 2005 roku wybra­łem to narzę­dzie cał­ko­wi­cie przy­pad­ko­wo, kie­ro­wa­łem się cza­sem od momen­tu zamó­wie­nia do uzy­ska­nia licen­cji, bo dzia­ło się w toku bar­dzo waż­ne­go pro­jek­tu, w któ­rym nie mogłem sobie pozwo­lić ani na prze­rwę ani na zna­ki wod­ne eva­lu­ation ver­sion” w doku­men­tach w cza­sie ocze­ki­wa­nia na licen­cje. Po tych latach korzy­sta­nia z VP i porów­ny­wa­nia pra­cy z inny­mi narzę­dzia­mi spo­ty­ka­ny­mi w pro­jek­tach, nadal mam prze­ko­na­nie, że nie­świa­do­mie doko­na­łem wte­dy chy­ba naj­lep­sze­go moż­li­we­go wyboru.

Więcej o nowin­kach w aplikacji:

Visual Paradigm 13.2 intro­du­ces a num­ber of new featu­res, which includes:

(źr. https://​www​.visu​al​-para​digm​.com/​a​b​o​u​t​u​s​/​n​e​w​s​r​e​l​e​a​s​e​s​/​v​p​1​3​2​.​jsp)

Wymagania biznesowe i Siatka Zachmana

Cztery lata temu pisa­łem o książ­ce Ronalda Rossa Building Business Solutions”:

Druga to pozy­cja nowa, cało­ścio­wo opi­su­ją­ca podej­ście pole­ga­ją­ca na mode­lo­wa­niu orga­ni­za­cji w ana­li­zie biz­ne­so­wej (zawie­ra część mate­ria­łu pierw­szej) . Zwraca uwa­gę na fakt, że nie cho­dzi w ana­li­zie o two­rze­nie mnó­stwa dia­gra­mów a o to, by zro­zu­mieć jak orga­ni­za­cja funk­cjo­nu­je opi­su­jąc to, oraz stwo­rzyć model, któ­ry pozwo­li na pro­gno­zo­wa­nie zacho­wa­nia orga­ni­za­cji w odpo­wie­dzi na bodź­ce, nawet te któ­re jesz­cze nie zaist­nia­ły. (Źródło: Business Rule Concepts ? czy­li jak ?wyłu­skać isto­tę rze­czy? | | Jarosław Żeliński IT-Consulting)

Niedawno wpadł mi w skrzyn­kę kolej­ny wpis na blo­gu R.Rossa:

Zachman?s basic pre­mi­se is that whe­ne­ver you engi­ne­er any­thing of com­ple­xi­ty, no mat­ter what ? a com­plex machi­ne, a sky­scra­per, a micro­chip, a spa­ce­craft, a pro­duct, a busi­ness (an enter­pri­se), or some part of a busi­ness (a busi­ness capa­bi­li­ty) ? the­re are two basic aspects that need to be addres­sed. These two aspects cor­re­spond to the columns and rows of the Framework. (Źródło: What the Zachman Architecture Framework Is ? And How It Relates to Business Rules & Business Analysis | Ronald Ross | LinkedIn, Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edi­tion, by Ronald G. Ross & Gladys S.W. Lam, 2015)

I oka­zu­je się, że zawsze war­to wra­cać do ksią­żek :). Od daw­na pra­cu­je nad uwol­nie­niem spon­so­rów pro­jek­tów od wyma­ga­nia by rozu­mie­li tech­no­lo­gię i teo­rie sys­te­mów. W lite­ra­tu­rze nie raz mozna spo­tkać poję­cie wyma­gań biz­ne­so­wych, pisa­łem o tym trzy lata temu:

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofer­to­wych). (Źródło: Inżynieria wyma­gań | | Jarosław Żeliński IT-Consulting)

Wymieniona wyżej książ­ka Rossa zawie­ra roz­dział Understanding Business Requirements i takie jego sło­wa pod tym tytułem:

RonRossBuildingBusinessSolution_17_1

Model biz­ne­so­wy two­rzy­my by opi­sać daną dzia­łal­ność, może być on tak­że uży­ty do stwo­rze­nia wyma­gań biz­ne­so­wych.” Nieco dalej czytamy:

RonRossBuildingBusinessSolution_17_2

Bardzo waż­ne: wyma­ga­nia biz­ne­so­we defi­niu­je­my wobec sys­te­mu a nie wobec biz­ne­su (fir­my). I to fak­tycz­nie jest powo­dem wie­lu nie­po­ro­zu­mień. W tym samym roz­dzia­le Ross powo­łu­jąc się na Siatkę Zachmana przy­wo­łu­je definicje:

RonRossBuildingBusinessSolution_17_3

Od dłuż­sze­go cza­su sto­su­ję w pro­jek­tach poję­cie Wymagań Biznesowych (opi­sa­ne w cyto­wa­nym wyżej, moim arty­ku­le Inżynieria wyma­gań), i po raz kolej­ny zno­wu, skła­niam się do pró­by wyko­rzy­sta­nia siat­ki Zachmana w tym celu, gdyż jeże­li ten szkie­let archi­tek­to­nicz­ny (Siatka Zachmana to tak zwa­ny szkie­let archi­tek­to­nicz­ny archi­tek­tu­ry kor­po­ra­cyj­nej) fak­tycz­nie pozwo­li spraw­nie zarzą­dzać wyma­ga­nia­mi i ich śla­do­wa­niem, to war­to z tego sko­rzy­stać, na razie porów­nu­je się (nakła­da się) ten szkie­let z MDA i jak widać jest świa­teł­ko w tunelu :):

MDA2Zachman

Dla uła­twie­nia siat­ka Zachmana w pol­skiej wer­sji (kard z pakie­tu Visual-Paradigm).

Siatka Zachmana zakres analizy

Visual Paradigm 13.0 Opublikowany

Narzędzie, któ­re­go uży­wam od 2005 roku (rezy­gnu­jąc wte­dy z MS Visio bo topor­ny i wyrzu­ca­jąc demo EA SPARX bo topor­ny i nie­zgod­ny z UML), sta­je się coraz lep­sze. To co powo­du­je, że nadal nie pla­nu­ję zmie­niać narzę­dzia to mega ergo­no­mia pra­cy, 100% zgod­no­ści ze spe­cy­fi­ka­cja­mi OMG, a przede wszyst­kim ser­wer pra­cy gru­po­wej VPository, co razem daje mega plat­for­mę ana­li­tycz­no-komu­ni­ka­cyj­ną dla ana­li­ty­ka i klienta.

W nowej wersji:

Czytaj dalej… Visual Paradigm 13.0 Opublikowany”

Zarządzanie zmianami biznesowymi

Na blo­gu prof. Andrzeja Sobczaka uka­zał się kolej­ny cie­ka­wy arty­kuł, w któ­rym auto­ra zauwa­ża, że:

Presja na uzy­ski­wa­nie jak naj­lep­szych wyni­ków w jak naj­krót­szym cza­sie powo­du­je bar­dzo duży nacisk na tzw. Time 2 Market (T2M) ? czy­li jak naj­szyb­sze wpro­wa­dza­nie pro­duk­tu na rynek (biz­nes coraz czę­ściej godzi się, że będzie to pro­dukt nie do koń­ca prze­te­sto­wa­ny, dopra­co­wa­ny,? ? ale będą dzię­ki temu pierw­si na ryn­ku i wyprze­dzą w ten spo­sób kon­ku­ren­cję ? zgod­nie z zasa­dą ?kto nie ryzy­ku­je, ten nie pije szampana?).

Dążenie do skró­ce­nia T2M powo­du­je, że zmia­ny reali­zo­wa­ne w orga­ni­za­cjach (czy to biz­ne­so­we, czy też tech­no­lo­gicz­ne) mają cha­rak­ter nie­sko­or­dy­no­wa­ny, punk­to­wy, meto­dą ?na sznur­ki?. Skutkuje to tym, że reali­za­cja tych zmian pro­wa­dzi do upra­wie­nia reali­za­cji frag­men­tu pro­ce­su biz­ne­so­we­go, pozwa­la na wpro­wa­dze­nie nowe­go pro­duk­tu na rynek, dostar­cza nowej funk­cjo­nal­no­ści dla departamentu/linii biz­ne­so­wej. Ale orga­ni­za­cja roz­pa­try­wa­na jako całość tra­ci na tym. Po pierw­sze rosną kosz­ty utrzy­ma­nia tak wdro­żo­nych roz­wią­zań (czy to orga­ni­za­cyj­nych, czy też IT). Po dru­gie coraz wię­cej cza­su poświę­ca­ne jest na koordynację/uzgadnianie/wyjaśniania ele­men­tów, któ­re od same­go począt­ku powin­ny ?skła­dać się? w jed­ną całość. Wreszcie orga­ni­za­cja postrze­ga­na holi­stycz­nie zmniej­sza swo­ją ela­stycz­ność (rośnie jej entro­pia) (Źródło: Manifest nowe­go ładu zarzą­dza­nia zmia­na­mi biz­ne­so­wy­mi | Architektura Korporacyjna)

Myślę, że naci­ski na skra­ca­nie T2M to tyl­ko czyn­nik narzu­ca­ją­cy wyma­ga­nia. SJP mówi, że stra­te­gia to ?prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie?. Czym jest więc archi­tek­tu­ra kor­po­ra­cyj­na (AK) dla stra­te­gii? A może czym powin­na być stra­te­gia dla AK? AK zawie­ra w sobie archi­tek­tu­rę apli­ka­cji, któ­re są jej ? AK- czę­ścią. Jeżeli uzna­je­my (jeże­li) pryn­cy­pia takie jak ?apli­ka­cja powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­sze­rze­nia?, to dla­cze­go by nie uznać, że ?archi­tek­tu­ra kor­po­ra­cyj­na (tak­że) powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­sze­rze­nia?? Wtedy stra­te­gia orga­ni­za­cji sta­no­wi­ła by rodzaj poli­ty­ki two­rze­nia i roz­sze­rza­nia AK. Oczekujemy zwin­no­ści od apli­ka­cji, ocze­kuj­my tez od AK?.

Czy to się da? Myślę, że tak. W koń­cu dowol­nie zło­żo­ny sys­tem IT moż­na spro­wa­dzić do rela­tyw­nie małej licz­by kom­po­nen­tów (to tyl­ko kwe­stia pozio­mu her­me­ty­za­cji szcze­gó­łów). Z dru­giej stro­ny podział sys­te­mu na odręb­ne apli­ka­cje jest sztucz­ny, wyni­ka wyłącz­nie z zakre­su pro­jek­tu ich dostaw­ców. To zna­czy, że poszcze­gól­ne kom­po­nen­ty moż­na podzie­lić na te wol­no-zmien­ne klu­czo­we, tak zwa­ne dome­no­we, kom­po­nen­ty obsłu­gu­ją­ce sce­na­riu­sze biz­ne­so­we oraz te obsłu­gu­ją­ce dia­log użyt­kow­ni­ka z sys­te­mem i ofe­ru­ją­ce użyt­kow­ni­kom usłu­gi apli­ka­cyj­ne (np. por­ta­le intra­ne­to­we). Szybkozmienny biz­nes nie raz wymu­si nowe usłu­gi, to czy będzie to zmia­na w ist­nie­ją­cym czy nowy kom­po­nent to poli­ty­ka budo­wy i zarzą­dza­nia zmia­ną AK, powin­na ona pomóc pod­jąć decy­zje czy będzie on zamiast wpro­wa­dza­nia kolej­nej (po co??) mody­fi­ka­cji, efe­me­ry­dą reali­zu­ją­cą okre­ślo­ną logi­kę biz­ne­so­wą w okre­ślo­nym, mają­cym począ­tek i koniec, okre­sie czasu.

Strategia orga­ni­za­cji to dłu­go ter­mi­no­we cele i poli­ty­ka ich reali­za­cji, kon­kret­ne rocz­ne czy kwar­tal­ne dzia­ła­nia to tak­ty­ki a nie stra­te­gia… Co więc robić? Przede wszyst­kim opi­sać stra­te­gię i poli­ty­kę jej reali­za­cji (stra­te­gia to plan ale poli­ty­ka to regu­ły dzia­ła­nia a nie opis dzia­łań). Polityka ta powin­na wyzna­czać tak­że spo­sób budo­wy AK, któ­ra musi pozwo­lić na reali­zo­wa­nie stra­te­gii. Mają poli­ty­kę, zbu­do­wać AK w zgo­dzie mię­dzy inny­mi z zasa­dą, że ?archi­tek­tu­ra kor­po­ra­cyj­na powin­na być zamknię­ta na zmia­ny i otwar­ta na rozszerzenia?.