Knowledge Management – systemy wspomagające zarządzanie wiedzą GigaCon

Mamy przy­jem­ność zapro­sić Państwa na II edy­cję bez­płat­nej kon­fe­ren­cji, któ­ra jest szan­są na uzy­ska­nie lep­szych wyni­ków i prze­wa­gi nad konkurencją.

Konferencję Knowledge Management ? sys­te­my wspo­ma­ga­ją­ce zarzą­dza­nie wie­dzą GigaCon kie­ru­je­my do osób decy­du­ją­cych o spo­so­bie funk­cjo­no­wa­nia przed­się­bior­stwa, odpo­wie­dzial­nych za zarzą­dza­nie prze­pły­wem infor­ma­cji, zarzą­dza­nie wie­dzą oraz dobór roz­wią­zań i tech­no­lo­gii słu­żą­cych wspie­ra­niu tych pro­ce­sów; osób odpo­wie­dzial­nych za opty­mal­ne wyko­rzy­sta­nie posia­da­nych zaso­bów wiedzy.
Tematyka kon­fe­ren­cji:
- Systemy zarzą­dza­nia doku­men­ta­mi (docu­ment management)
- Systemy obie­gu pra­cy (work­flow)
- Systemy wspo­ma­ga­nia pra­cy gru­po­wej (gro­upwa­re)
- Hurtownie danych (data warehouse)
- Portale kor­po­ra­cyj­ne (enter­pri­se portals)
- Intranet – wewnętrz­ny internet
- Systemy wspo­ma­ga­nia decy­zji, sys­te­my ekspertowe
- Systemy do zarzą­dza­nia naucza­niem na odle­głość (e‑learning, wide­okon­fe­ren­cje, dyskusje
on-line)
- Systemy do zarzą­dza­nia bez­pie­czeń­stwem i ochro­na informacji
Nasza kon­fe­ren­cja przy­bli­ży suk­ces Państwa firmy.
WSTĘP BEZPŁATNY!
Rejestracja na stronie: 
Partner kon­fe­ren­cji:
DYSANT Software
Firmy zain­te­re­so­wa­ne pre­zen­ta­cją roz­wią­zań pod­czas kon­fe­ren­cji pro­si­my o kon­takt z organizatorem.
Kontakt:
Sławomir Krajewski
tel. 22/427 32 82
slawomir.krajewski@software.com.pl

Zarządzanie wiedzą

Byłem nie­daw­no na kon­fe­ren­cji zaty­tu­ło­wa­nej Knowlegde Management czy­li po pro­stu Zarządzanie Wiedzą (dla­cze­go pol­skie kon­fe­ren­cje w Polsce nazy­wa­ją się po angiel­sku?). Konferencja, jak w fil­mach Hitchcocka, zaczę­ła się moc­no a potem napię­cie rosło: pre­le­gent refe­ra­tu wpro­wa­dza­ją­ce­go stwier­dził, że nie trze­ba defi­nio­wać poję­cia ?wie­dza? by dys­ku­to­wać o zarzą­dza­niu wie­dzą. Ale opo­wiem kil­ka słów o samej kon­fe­ren­cji i tym co sam o tym, czy­li o zarzą­dza­niu wie­dza, sądzę.

Ja jed­nak zacznę od defi­ni­cji, naj­pro­ściej jest się­gnąć do słow­ni­ka języ­ka polskiego:

  • wie­dza: ?ogół wia­do­mo­ści zdo­by­tych dzię­ki bada­niom, ucze­niu się itp.; też: zasób infor­ma­cji z jakiejś dziedziny?
  • wia­do­mość: ?nowa infor­ma­cja o czymś?
  • infor­ma­cja: ?wia­do­mość o czymś lub zako­mu­ni­ko­wa­nie czegoś?
  • dane ?fak­ty, licz­by, na któ­rych moż­na się oprzeć w wywo­dach?, ?infor­ma­cje prze­twa­rza­ne przez kom­pu­ter? (źr. SJP PWN)

Co mamy: wie­dza to zbiór wia­do­mo­ści, te sta­no­wią prze­kaz o zda­rze­niach (fak­tach) po zapi­sa­niu sta­no­wią dane. Czym są dane? To wszyst­ko to, co może­my zapi­sać i utrwa­lić. Bogatszą ana­li­zę tak zwa­ne­go mode­lu infor­ma­cyj­ne­go i rela­cji pomię­dzy wia­do­mo­ścia­mi, infor­ma­cja i dany­mi opra­co­wa­łem na począt­ku tego roku (tekst do nabycia).

Wiedza i jej maga­zy­no­wa­nie ma sens, jeśli mamy moż­li­wość póź­niej­sze­go sko­rzy­sta­nia z niej. Problem w tym, że podob­no 80% danych to dane nie­struk­tu­ral­ne a więc nie pod­da­ją­ce się zapi­so­wi w posta­ci tabel i kolumn. Potrzebne więc jest jakieś bar­dziej wyra­fi­no­wa­ne narzę­dzie. Po dru­gie mamy pewien para­doks biznesowy:

  1. aby robić coś lepiej i osią­gnąć korzy­ści biz­ne­so­we potrzeb­na jest więk­sza wiedza,
  2. więk­sza wie­dza to wię­cej danych,
  3. gro­ma­dze­nie danych i zarzą­dza­nie nimi kosztuje,
  4. więk­sza wie­dza to więk­szy koszt,
  5. dodat­ko­wy koszt posia­da­nia więk­szej wie­dzy zjadł osią­gnię­te zyski z jej posiadania.

Tak więc moim zda­niem zarzą­dza­nie wie­dzą to nie tyl­ko jej gro­ma­dze­nie i udo­stęp­nia­nie, ale przede wszyst­kim selek­cja! Nasz mózg robi dokład­nie to samo: zapo­mi­na o wszyst­kim co nie jest bez­po­śred­nio uży­wa­ne do bie­żą­ce­go życia i przeżycia.

Na pew­no nie jest to miej­sce na stresz­cza­nie takich kon­fe­ren­cji ale w jed­nej z pre­zen­ta­cji poja­wi­ło się waż­ne stwier­dze­nie: reten­cja danych (gro­ma­dze­nie ich, tu w kon­tek­ście wie­dzy nale­ży rozu­mieć: celo­wo, wybiór­czo i w kon­tro­lo­wa­ny spo­sób). Jest to moim zda­niem dru­ga naj­waż­niej­sza cecha sys­te­mów zarzą­dza­nia wie­dzą (pierw­szą była powią­za­na z tym poję­ciem selek­cja danych).

Swego cza­su uwa­ża­łem, że naj­więk­szym sys­te­mem zarzą­dza­nia wie­dzą jest Internet i dobra wyszu­ki­war­ka. Teraz mam wra­że­nie, że brak tych wła­ści­wo­ści czy­li brak selek­cji wpro­wa­dza­nia i trzy­ma­nie na wiecz­ność wszyst­kie­go czy­ni z Internetu coraz więk­szy śmiet­nik. To samo cze­ka każ­dy sys­tem zarzą­dza­nia wie­dzą w fir­mie, jeże­li tych dwóch cech nie będzie posia­dał (świa­do­me wpro­wa­dza­nie danych i celo­we prze­cho­wy­wa­nie). W Internecie wszel­ka pró­ba selek­cji od razu wzbu­dza dys­ku­sje o cen­zu­ro­wa­niu sie­ci. W fir­mie nale­ży to ure­gu­lo­wać albo zapo­mnieć o Knowledge Management bo to ostat­nie sło­wo jest tu klu­czem: ?zarzą­dza­nie?.

Na kon­fe­ren­cji pre­zen­to­wa­ne były róż­ne pro­duk­ty, wszyst­kie pod hasłem ?Zarządzanie wie­dzą?. Jedna z pre­zen­ta­cji zawie­ra­ła listę tego ?jaką wie­dzą zarzą­dza ich sys­tem?. Były to: zada­nia, doku­men­ty, kalen­darz, SMS?sy, chat, e‑mail, ankie­ty, ludzie, pyta­nia i odpo­wie­dzi. Hm, wie­le tego. To jest wła­śnie chy­ba prze­sa­da. Gdzieś widzia­łem defi­ni­cje wie­dzy jako zbio­ru danych mają­cych war­tość dla użyt­kow­ni­ka. Ta defi­ni­cja bar­dziej mi się podo­ba. System ten, na jego szczę­ście, chy­ba jako jedy­ny pre­zen­to­wa­ny miał funk­cjo­nal­ność zarzą­dza­nia reten­cją danych.

Jak więc zarzą­dzać wiedzą?

Cóż, po pierw­sze naj­waż­niej­sze pyta­nie brzmi: po co! Absolutnie nie jest to kry­ty­ka zarzą­dza­nia wie­dzą a zada­nie sobie pyta­nia co chce­my osią­gnąć gdyż zarzą­dza­ne wie­dzą, czy­li po pro­stu kolek­cjo­no­wa­ny­mi dany­mi, to nie jest zbie­ra­nie cze­go­kol­wiek a zbie­ra­nie tego co nam poma­ga, a w każ­dym razie mogło by pomóc.

Zrobiłem swe­go cza­su mały eks­pe­ry­ment w domu: wszyst­ko cze­go nie uży­łem przez rok wyrzu­ca­łem jako zbęd­ne. I co? Oczyściłem piw­ni­cę w cią­gu roku i co cie­ka­we nie cier­pię z tego powo­du, gdyż fak­tycz­nie pew­ne rze­czy nie­po­trzeb­nie zaj­mo­wa­ły cen­ną prze­strzeń cia­snej piw­ni­cy, zaś to cze­go uży­wa­łem np. raz na pięć lat bez pro­ble­mu moż­na gdzieś wypo­ży­czyć i z regu­ły jest to ?lep­szy i now­szy model?.

Do pobra­nia opra­co­wa­nie na temat tego czym są potrze­by infor­ma­cyj­ne: A019_Potrzeby_informacyjne_firmy

Potrzeby informacyjne firmy ? Zarządzanie wiedzą

Wprowadzenie

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miejsca.

Potrzeby informacyjne firmy

Czym są? Aby okre­ślić potrze­by infor­ma­cyj­ne fir­my musi­my wska­zać (opi­sać) to jaką wie­dzę chce­my posia­dać. To jest naj­trud­niej­sze. Potem, budu­je­my listę fak­tów, któ­rych reje­stra­cja jest wyma­ga­na do zgro­ma­dze­nia potrzeb­nej wie­dzy. Kolejnym kro­kiem jest okre­śle­nie jakie dane są wyma­ga­ne do opi­su tych fak­tów. Następnie budu­je­my model poję­cio­wy i struk­tu­rę danych opi­su­ją­cych te fak­ty. Na koniec imple­men­tu­je­my ten model danych two­rząc Bazę Danych.

Poniżej opi­sa­łem to w jaki spo­sób powsta­ła aku­rat taka kolej­ność i to, że Wiedza nie ist­nie­je, ist­nie­ją dane. Z mode­lem sta­je się to nie­co prostsze.

Definicje

Informacja – 1. ?wia­do­mość o czymś lub zako­mu­ni­ko­wa­nie cze­goś?, 2. ?dział infor­ma­cyj­ny urzę­du, insty­tu­cji?, 3. ?dane prze­twa­rza­ne przez kom­pu­ter? (źr. Słownik PWN)

Informacja – Informacja (łac. infor­ma­tio – wyobra­że­nie, poję­cie) to poję­cie o wie­lu defi­ni­cjach w róż­nych dzie­dzi­nach. Zasadniczo mamy dwa pod­sta­wo­we punk­ty widze­nia na infor­ma­cję. Pierwszy, któ­ry moż­na nazwać obiek­tyw­nym i wywo­dzi się z fizy­ki i mate­ma­ty­ki, gdzie infor­ma­cja ozna­cza pew­ną wła­sność fizycz­ną lub struk­tu­ral­ną obiek­tów, i dru­gi, subiek­tyw­ny (kogni­ty­wi­stycz­ny), gdzie infor­ma­cją jest to, co umysł jest w sta­nie prze­two­rzyć i wyko­rzy­stać do wła­snych celów. (źr. Wikipedia).

Dane – 1. ?fak­tylicz­by, na któ­rych moż­na się oprzeć w wywo­dach?, 2. ?infor­ma­cje prze­twa­rza­ne przez kom­pu­ter? (źr. Słownik PWN)

Dane (ang. data; z łac. datum – to, co jest dane) ? w infor­ma­ty­ce zbio­ry liczb i tek­stów o róż­nych for­mach. Są one uży­wa­ne przez kom­pu­te­ry do obli­czeń oraz są pre­zen­to­wa­ne, czy też prze­twa­rza­ne cyfro­wo. Takie tema­tycz­ne zbio­ry infor­ma­cji są nazwa­ne baza­mi danych. Bazy Danych są pod­sta­wo­wą czę­ścią sys­te­mów zarzą­dza­nia infor­ma­cją, sys­te­mów zarzą­dza­nia pro­jek­ta­mi czy kata­lo­gów pro­duk­tów. Układ danych przy­no­szą­cy kon­kret­ną infor­ma­cję to komu­ni­kat. (źr. Wikipedia).

Wiedza – 1. ?ogół wia­do­mo­ści zdo­by­tych dzię­ki bada­niom, ucze­niu się itp.; też: zasób infor­ma­cji z jakiejś dzie­dzi­ny?, 2. ?zna­jo­mość cze­goś? (źr. Słownik PWN)

Wiedza – ter­min uży­wa­ny powszech­nie, dotych­czas nie posia­da jesz­cze ogól­nie uzna­nej defi­ni­cji. Za kla­sycz­ną uzna­je się defi­ni­cję Platona z dia­lo­gu Teajtet, gdzie Sokrates w roz­mo­wie z Teajtetem docho­dzi do sfor­mu­ło­wa­nia defi­ni­cji, że wie­dza to praw­dzi­we, uza­sad­nio­ne prze­ko­na­nie. Nowa Encyklopedia Powszechna defi­niu­je wie­dzę jako ?ogół wia­ry­god­nych infor­ma­cji o rze­czy­wi­sto­ści wraz z umie­jęt­no­ścią ich wyko­rzy­sty­wa­nia?. (źr. Wikipedia)

Na bazie tych defi­ni­cji moż­na stwo­rzyć nastę­pu­ją­cy model pojęciowy:

? Fakty są komu­ni­ko­wa­ne przez wia­do­mo­ści, wia­do­mość komu­ni­ku­je fakt

? Fakty nio­są infor­ma­cje, infor­ma­cja to poj­mo­wa­nie faktów

? Informacja sta­no­wi widzę, wie­dza to zbiór informacji

Informacja a wiedza

Jak widać rela­cje te nie są skom­pli­ko­wa­ne jed­nak ich obraz poka­zu­je, że samo stwier­dze­nie ?baza wie­dzy? czy ?sys­tem infor­ma­cyj­ny? nabie­ra nie­co innej per­spek­ty­wy. Proszę zwró­cić uwa­gę na to, że nie ma tu bez­po­śred­nie­go powią­za­nia Wiadomości z Wiedzą. Można jed­nak powie­dzieć, że wia­do­mo­ści, jako opis fak­tów, nio­są infor­ma­cje, któ­re budu­ją naszą wie­dzę.

Czym są dane?

Otóż powyż­sze czte­ry poję­cia są tak na praw­dę nie­ma­te­rial­ne. Funkcjonują w naszych umy­słach. Dopiero ich utrwa­le­nia w posta­ci zapi­su na trwa­łym nośni­ku (ot choć­by pió­rem na papie­rze) czy­ni z fak­tów dane.

Mamy więc kolej­ny ele­ment tego mode­lu: Dane repre­zen­tu­ją Fakty, Fakty są doku­men­to­wa­ne przez Dane.

Jaki z tego wnio­sek? Pierwszy jaki się nasu­wa to to, że poję­cie Bazy Wiedzy jest trosz­kę ?nacią­ga­ne?. Dlaczego? Bo Wiedza to spo­sób inter­pre­ta­cji otrzy­my­wa­nych Wiadomości przez czło­wie­ka a pro­ces ten jest subiek­tyw­ny i zale­ży od kon­tek­stu prze­ka­za­nych wia­do­mo­ści. Kontekst zaś budu­ją wia­do­mo­ści poprze­dza­ją­ce. Podam przykład.

Wiadomość: ?w wyni­ku zde­rze­nia samo­cho­dów zgi­nę­ła jed­na oso­ba?. Na jej pod­sta­wie zbu­du­je­my sobie obraz koli­zji na dro­dze i ludz­kiej tra­ge­dii. Wiadomość ta jed­nak poprze­dzo­na (np. audy­cją radio­wą poda­ną godzi­nę wcze­śniej) prze­ka­zem o tre­ści ?Na dro­dze eks­pre­so­wej nr 48, w wyni­ku oblo­dze­nia, miał miej­sce wiel­ki karam­bol, zde­rzy­ło się 37 samo­cho­dów? wywo­ła nie­mal­że ulgę, że w takiej wiel­kiej kata­stro­fie zgi­nę­ła tyl­ko jed­na osoba.

Skoro więc nasza wie­dza bazu­je na wia­do­mo­ściach a ich inter­pre­ta­cja (poj­mo­wa­nie) bazu­je na kon­tek­ście to czym jest ta Wiedza? Kluczem tu są dane, to jak są maga­zy­no­wa­ne. Inaczej mówią to jak są repre­zen­to­wa­ne po ich utrwa­le­niu (rysu­nek powyżej).

Powoli nasu­wa się już chy­ba świa­do­mość tego, że dobra baza wie­dzy (czym by nie była) musi prze­cho­wy­wać dane opi­su­ją­ce i fak­ty i ich kon­tekst. Po dru­gie spo­sób repre­zen­ta­cji danych (ich zapi­su, utrwa­la­niu) powi­nien być jak naj­mniej podat­ny na ich subiek­tyw­ną inter­pre­ta­cję. Jak to osiągnąć?

Model pojęciowy jako model rzeczywistości

Dobrnęliśmy do poję­cia repre­zen­ta­cji danych. Najprostszą repre­zen­ta­cją danych jest nie­struk­tu­ral­ny tekst, popu­lar­nie zwa­ny pro­zą . Proszę zwró­cić uwa­gę na to, że nawet ten tekst to dane. Jaki z nim pro­blem? Ano trud­no jest w tej posta­ci wska­zać wia­do­mość, fakt, infor­ma­cję czy w koń­cu odpo­wie­dzieć na pyta­nie gdzie jest tu ta Wiedza. Wyobraźmy sobie dodat­ko­wo, że ten tekst (ten arty­kuł) pozba­wio­no ilu­stra­cji. Stałby się prak­tycz­nie tak nie­jed­no­znacz­ny, że każ­dy jego czy­tel­nik miał by pra­wo do jego wła­snej inter­pre­ta­cji (na szczę­ście są tu te dia­gra­my, dostęp­ne w wer­sji PDF, adres URL peł­nej wer­sji arty­ku­łu na koń­cu tekstu).

Powstaje potrze­ba takie­go zapi­su danych by były one zapi­sem fak­tów i nio­sły jed­nak ich kon­tekst, na tyle na ile to moż­li­we. Jaki to zapis?

Struktura informacji

Aby dane były moż­li­wie jed­no­znacz­ne i nio­sły kon­tekst muszą być zapi­sa­ne w spo­sób struk­tu­ral­ny i muszą mieć zde­fi­nio­wa­ną ich inter­pre­ta­cję czy­li tak zwa­ne meta­da­ne. Co to oznacza?

Za słow­ni­kiem języ­ka pol­skie­go: struk­tu­ra – 1. ?układ i wza­jem­ne rela­cje ele­men­tów sta­no­wią­cych całość?, 2. ?całość zbu­do­wa­na w pewien spo­sób z poszcze­gól­nych elementów?

Dodatkowo za WIKI: Metadane ? czy­li ?dane o danych?, [?]w przy­pad­ku bazy danych, meta­da­ny­mi są defi­ni­cje tabel, wido­ków, klu­czy itp. nato­miast dany­mi ? zawar­tość tych tabel, wido­ków (czy­li rekor­dy). W sys­te­mach zarzą­dza­nia doku­men­ta­mi meta­da­ne okre­śla się mia­nem metry­ki dokumentu.

Tak wiec mamy już wstęp­ną odpo­wiedź. Ale może przykład:

?Po jutrze, godzi­nę po Wiadomościach odbę­dzie spo­tka­nie człon­ków klu­bu twór­ców nie­jed­no­znacz­nych tek­stów w miej­scu tym samym co ostat­nio. Będziemy roz­ma­wia­li mię­dzy inny­mi o tym jak jesz­cze wydaj­niej zanu­dzać czy­tel­ni­ka, roz­wa­żać aspek­ty wpły­wu nud­nych tek­stów na sto­pień sen­no­ści adre­sa­ta prze­ka­zu oraz oce­ni­my wpływ naszych prac na tak zwa­ne zamu­la­nie sie­ci Internet.?.

Taki prze­kaz pozba­wio­ny kon­tek­stu jakim jest mię­dzy inny­mi dokład­ny czas nada­nia tej wia­do­mo­ści prak­tycz­nie nie nada­je się do jakiej­kol­wiek inter­pre­ta­cji (co nie zmie­nia fak­tu, że w takiej posta­ci czę­sto poda­wa­ne są zapo­wie­dzi spo­tkań w zapro­sze­niach prze­ka­zy­wa­nych pocz­tą elektroniczną)

Zapis struk­tu­ral­ny wyglą­dał by tak:

[Rodzaj zda­rze­nia]: Spotkanie

[Uczestnicy]: człon­ko­wie Klubu Twórców Niejednoznacznych Tekstów

[Termin]: 2008-10-06, godzi­na 20:00

[Miejsce]: klub Grafoman przy uli­cy Nudnej 24

[Treść]: Będziemy roz­ma­wia­li mię­dzy inny­mi o tym jak jesz­cze wydaj­niej zanu­dzać czy­tel­ni­ka, roz­wa­żać aspek­ty wpły­wu nud­nych tek­stów na sto­pień sen­no­ści adre­sa­ta prze­ka­zu oraz oce­ni­my wpływ naszych prac na tak zwa­ne zamu­la­nie sie­ci Internet.

Powyżej mamy struk­tu­ral­ny tekst (skła­da się z oddziel­nych powią­za­nych czę­ści), i meta­da­ne któ­ry­mi są nazwy (opi­sy) po lewej stro­nie dwu­krop­ków w kwa­dra­to­wych nawia­sach. Gdyby był to doku­ment (treść) w wer­sji ory­gi­nal­nej to pierw­sze czte­ry ele­men­ty tej struk­tu­ry mogły by sta­no­wić tak zwa­ną metry­kę całe­go doku­men­tu. Metryka doku­men­tu to nic inne­go na struk­tu­ral­ny opis zawar­to­ści (naj­czę­ściej skró­co­ny) nie­struk­tu­ral­ne­go tek­stu. Tak więc mamy opis tego co nazy­wa­my repre­zen­ta­cją danych.

Zaczynają się schody ? model dziedziny

Na począ­tek model danych. Model danych (bazy danych) to zbiór zasad (spe­cy­fi­ka­cji), opi­su­ją­cych struk­tu­rę danych w bazie danych. [?] Definiuje się tę struk­tu­rę danych poprzez spe­cy­fi­ka­cję repre­zen­ta­cji dozwo­lo­nych w mode­lu obiek­tów (encji) oraz ich związ­ków. (źr. WIKI)

Model danych to opis struk­tur, któ­re posłu­żą do kolek­cjo­no­wa­nia danych. Jest więc to nic inne­go jak struk­tu­ra obra­zu­ją­ca poję­cia i powią­za­nia mię­dzy nimi. Opisem takich struk­tur są mię­dzy inny­mi dia­gra­my takie jak te w tym arty­ku­le (co nie zmie­nia fak­tu, że są ludzie opi­su­ją­cy struk­tu­ry danych prozą).

[…] Jedyne co nam teraz pozo­sta­ło to imple­men­ta­cja mode­lu danych czy­li stwo­rze­nie bazy danych:

Obecnie coraz czę­ściej moż­na się spo­tkać z mode­la­mi obiektowymi.

Czy baza danych to wiedza?

[…]

Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta informacja?.

Przemyślenia zwią­za­ne z tą ostat­nią defi­ni­cją pozo­sta­wiam Państwu. Ciąg dal­szy może nastąpi?

Pobierz kom­plet­ne opracowanie:

Dokumenty czy niedokumenty.… czyli zarządzanie informacją i jej standaryzacja

Nie raz tu już pisa­łem, że ana­li­zy i pro­jek­ty zwią­za­ne bez­po­śred­nio z wyma­ga­nia­mi na opro­gra­mo­wa­nie to tyl­ko” ok. 3/4 moich pro­jek­tów. Jednak nawet, jeże­li pro­jekt nie jest nazwa­ny” infor­ma­tycz­nym, to zawsze jest infor­ma­cyj­ny” w rozu­mie­niu zarzą­dza­nia infor­ma­cją (tak­że zarzą­dza­nie wie­dzą). Tym razem kil­ka słów na temat doku­men­tów. Stanowią one pod­sta­wo­wą jed­nost­kę infor­ma­cji (i danych) w każ­dym sys­te­mie biz­ne­so­wym. Są tak­że źró­dłem danych dla hur­tow­ni danych.

Wstęp

Wiele pro­jek­tów zwią­za­nych z doku­men­ta­mi jest spro­wa­dza­nych do problemu:

jakie mamy doku­men­ty i co z nimi robimy?”

Zaniedbuje się bar­dzo waż­ny ele­ment: odpo­wiedź na pytanie:

czy nasze obec­ne doku­men­ty, ich ilość i treść, są właściwe?”

Otóż prak­ty­ka poka­zu­je, że dość czę­sto pro­ble­mem są doku­men­ty opra­co­wa­ne kie­dyś tam”. Inicjuje się pro­jekt z róż­ny­mi wyma­ga­nia­mi ale niko­mu nie przy­cho­dzi do gło­wy by zasta­no­wić się nad tym czy obec­ne doku­men­ty, w ich obec­nej posta­ci, są dobrym pomy­słem i powin­ny takie pozostać.

Czy doku­men­ty są nie­zmie­nial­nym bytem? Nie, nie są.

Każda orga­ni­za­cja obra­ca skoń­czo­ną licz­bą doku­men­tów, są to róż­ne­go rodza­ju for­mu­la­rze, w naj­ogól­niej­szym przy­pad­ku doku­men­tem jest po pro­stu każ­da treść, tak­że zwy­kła pro­za” np. notat­ka. Warto jed­nak zwró­cić uwa­gę na to, że nawet ona ma pew­ną struk­tu­rę: np. auto­ra, adre­sa­ta, temat, datę i treść. Dokumenty to okre­ślo­na kon­kret­na treść utrwa­lo­na z okre­ślo­ne­go powo­du (w prze­ciw­nym wypad­ku doku­ment nie by powstał). Osiem lat temu opi­sy­wa­łem kwe­stie róż­ni­cy mię­dzy doku­men­tem, wie­dzą, infor­ma­cją a danymi:

Czy baza danych to wie­dza?[?] Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta infor­ma­cja?. (Źródło: Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting)

Dzisiaj co nie­co o tym, dla­cze­go od cza­su do cza­su war­to się pochy­lić nad wzo­ra­mi doku­men­tów i czy cza­sem nie zmie­nić nie­co podej­ścia do nich.

Dokumenty w organizacji

Swego cza­su u jed­ne­go z moich klien­tów odkry­łem” cie­ka­wy doku­ment. Była to fak­tu­ra z doda­nym zesta­wem danych odpo­wia­da­ją­cym doku­men­tom WZ oraz ana­lo­gicz­nym zesta­wie­niem doty­czą­cym opa­ko­wań zwrot­nych. Ten super doku­ment był pomy­słem z przed wie­lu lat oso­by odpo­wie­dzial­nej za wyda­wa­nie i zarzą­dza­nie opa­ko­wa­nia­mi zwrot­ny­mi w maga­zy­nie. Uzasadnienie brzmia­ło: na jed­nym doku­men­cie będą wszyst­kie infor­ma­cje zwią­za­ne z kon­kret­ną sprze­da­żą i dosta­wą. Brzmi ład­nie jed­nak: prak­tycz­nie każ­dy kto miał z tym doku­men­tem do czy­nie­nia, w toku obsłu­gi zamó­wie­nia, dosta­wał nad­mia­ro­we dane, nie raz nie­jaw­ne (nie­któ­re) ceny, szcze­gó­ły zawar­to­ści paczek, war­tość towa­ru (po co ta wie­dza kie­row­com), ilo­ści i sal­da (tak) opa­ko­wań zwrot­nych (jak się oka­za­ło doku­ment nie raz poma­gał w nad­uży­ciach, nie­któ­rzy pra­cow­ni­cy zaś zama­zy­wa­li cza­sa­mi część danych prze­ka­zu­jąc doku­ment dalej, by ich nie ujaw­niać). Ale naj­więk­szym pro­ble­mem było to, że ta oso­ba uczy­ni­ła z tego wzo­ru doku­men­tu wyma­ga­nie wobec opro­gra­mo­wa­nia ERP. Jak się nie trud­no domy­śleć, żaden ryn­ko­wy sys­tem nie ma takie­go doku­men­tu stan­dar­do­wo, dostaw­ca ERP uznał to wyma­ga­nie bez zastrze­żeń, co przy­czy­ni­ło się do wie­lu mody­fi­ka­cji opro­gra­mo­wa­nia tak­że w innych miej­scach, znacz­ne­go wzro­stu budże­tu (współ­dzie­lo­na baza danych pro­pa­gu­je zmia­ny prak­tycz­nie na całą apli­ka­cję). Nie będę tu opi­sy­wał dal­szych losów tego wzo­ru doku­men­tu bo celem moim było jedy­nie poka­za­nie pro­ble­mu na real­nym przykładzie.

Każdy pro­jekt, czy to wdro­że­nie nowych zasad zarzą­dza­nia czy nowe­go opro­gra­mo­wa­nia, zwią­za­ny z zarzą­dza­niem orga­ni­za­cją, to (powi­nien być) tak­że co naj­mniej prze­gląd doku­men­tów i ich obie­gu. Kluczowym ele­men­tem tego prze­glą­du powin­na być ana­li­za tre­ści tych doku­men­tów, ich opty­mal­ność, nie tyl­ko obie­gu ale tak­że tre­ści i jej struk­tu­ry. Owszem, wie­le doku­men­tów ma narzu­co­ną struk­tu­rę np. w odpo­wied­niej usta­wie, jed­nak są to mini­mal­ne zawar­to­ści (np. fak­tu­ra) nie ma zaka­zu uzu­peł­nie­nia tej struk­tu­ry i np. doda­nia do fak­tu­ry nume­ru zamó­wie­nia, z któ­rym jest związana.

Ogólnie moż­na okre­ślić pew­ne pra­wi­dło­wo­ści: jeże­li doku­men­ty są prze­cią­ża­ne tre­ścią, czy­li idzie­my w kie­run­ku małej ilo­ści doku­men­tów zawie­ra­ją­cych dużo danych, rośnie zło­żo­ność reguł pra­cy z takim doku­men­tem. Jeżeli zaś idzie­my w kie­run­ku doku­men­tów bar­dzo pro­stych”, rośnie ilość ich typów i rośnie licz­ba reguł koja­rzą­cych te doku­men­ty ze sobą w celu ich uży­cia. Ogólnie obra­zu­je to poniż­szy diagram:

Liczba dokumentów vs ilośc treści na nich

Tak więc skraj­nym roz­wią­za­niem będzie stwo­rze­nie jed­ne­go doku­men­tu, na któ­rym będą wszyst­kie infor­ma­cje np. zwią­za­ne z danym zamó­wie­niem. Drugą skraj­no­ścią jest podzie­le­nie infor­ma­cji na odręb­ne małe nie­po­dziel­ne już grup­ki, jak to ma miej­sce w znor­ma­li­zo­wa­nych rela­cyj­nych bazach danych. Jeżeli mega­do­ku­men­ty to raczej bar­dzo rzad­kie zja­wi­sko, to przy­pa­dek dru­gi jest dość powszech­ny. To co nazy­wa­my czę­sto doku­men­tem to tu tak na praw­dę nie­ist­nie­ją­cy byt w rela­cyj­nej bazie danych, gene­ro­wa­ny ad-hoc w locie” z sze­re­gu roz­drob­nio­nych tablic danych. Innymi sło­wy nie są to sta­łe struk­tu­ry” a pew­na okre­ślo­na zło­żo­na logi­ka, two­rzą­ca z pro­stych danych pobie­ra­nych z tablic, kon­kret­ne zesta­wy infor­ma­cji np. fak­tu­ry (to dla­te­go czę­sto w języ­ku dostaw­cy” fak­tu­ra to raport a nie doku­ment!). Ta zło­żo­na logi­ka reali­zo­wa­na jest (wyko­ny­wa­na w pamię­ci kom­pu­te­ra) za każ­dym razem gdy odwo­ła­my się do takie­go dokumentu.

Optymalna sytu­acja to rodzaj kom­pro­mi­su pomię­dzy zło­żo­no­ścią logi­ki two­rze­nia i korzy­sta­nia z doku­men­tu a jego zawar­to­ścią. Na powyż­szym dia­gra­mie jest to obszar sta­no­wią­cy oko­li­ce mini­mum krzy­wej opi­su­ją­cej zależ­ność pomię­dzy licz­bą doku­men­tów a zło­żo­no­ścią ope­ro­wa­nia nimi. Nie ma pro­stej regu­ły na opra­co­wy­wa­nie i opty­ma­li­za­cje tre­ści i licz­by doku­men­tów jed­nak są pew­ne spraw­dzo­ne dobre prak­ty­ki, a mia­no­wi­cie jeden doku­ment, o okre­ślo­nej struk­tu­rze, powi­nien zawie­rać dane o okre­ślo­nym zda­rze­niu w okre­ślo­nym kon­tek­ście [powsta­je teraz publi­ka­cja na ten temat, wyda­je się moż­na to jed­nak zde­fi­nio­wać, przyp auto­ra 2019]. Dokumenty te, podob­nie jak fak­ty któ­re doku­men­tu­ją, mogą mieć każ­dy wła­sny i róż­ny od innych cykl życia, dla­te­go czę­sto bywa bar­dzo szko­dli­we roz­dzie­la­nie” ich na pola bazy danych i pozby­cie się redundancji.

Przykładem mogą być: zamó­wie­nie jako udo­ku­men­to­wa­nie fak­tu zawar­cia umo­wy na dosta­wę, fak­tu­ra jako udo­ku­men­to­wa­nie fak­tu sprze­da­ży (prze­nie­sie­nia wła­sno­ści) oraz doku­ment WZ doku­men­tu­ją­cy fakt wyda­nia z maga­zy­nu okre­ślo­nych pro­duk­tów. Bardzo czę­sto spe­cy­fi­ka­cja tego co wyda­no z maga­zy­nu nie jest toż­sa­ma z tre­ścią fak­tu­ry (sprze­da­no odku­rzacz a wyda­no odku­rzacz i zapa­so­we wor­ki), na zamó­wie­niu mógł być wyszcze­gól­nio­ny odku­rzacz, wor­ki oraz wyma­ga­ne koń­ców­ki (któ­re są np. u pro­du­cen­ta pako­wa­ne w stan­dar­dzie więc nie ma ich ani na fak­tu­rze ani na WZ). Dlatego ma głę­bo­ki sens by te doku­men­ty były jed­nak osob­ny­mi doku­men­ta­mi” a nie zacho­wy­wa­ny­mi w bazie danych dany­mi jako odręb­ne pola pozba­wio­ne redun­dan­cji, wyma­ga­ją­ce skom­pli­ko­wa­nej logi­ki (pole­ce­nia SQL) by je (te doku­men­ty”) poka­zać na ekra­nie czy wydrukować.

To dość try­wial­ny przy­kład, bo opi­sa­ne doku­men­ty są wyma­ga­ne prze­pi­sa­mi jako dowo­dy księ­go­we, jed­nak każ­da więk­sza orga­ni­za­cja ma swo­je wewnętrz­ne doku­men­ty, na któ­rych ilość i treść ma peł­ny wpływ. Po dru­gie nawet te doku­men­ty są czę­sto wła­śnie zapi­sy­wa­ne w rela­cyj­nych bazach danych jako roz­pro­szo­ne po małych tabe­lach dane, wyma­ga­ją­ce skom­pli­ko­wa­nych ope­ra­cji łącze­nia w jeden doku­ment”, każ­do­ra­zo­wo przy pró­bie jego uży­cia. Tu zacho­dzi bar­dzo duże ryzy­ko, że postać i treść takie­go doku­men­tu ule­gnie zmia­nie np. po reor­ga­ni­za­cji bazy danych. Takich doku­men­tów” nie da się (w tej posta­ci) pod­pi­sać elek­tro­nicz­nie, bo one po pro­tu fizycz­nie na praw­dę nie istnieją.

A jak ina­czej? Nie ma żad­ne­go pro­ble­mu by dowol­ny doku­ment sta­no­wił sobą jed­no­li­ty byt np. zestaw danych w for­ma­cie XML, sko­ja­rzo­ny ewen­tu­al­nie ze swo­ją posta­cią goto­wą do dru­ku albo np. plik PDF sko­ja­rzo­ny z meta­da­ny­mi opi­su­ją­cy­mi go (wybór jest na praw­dę duży). Nie nale­ży zapo­mi­nać, że poza doku­men­ta­mi, któ­re są two­rzo­ne w orga­ni­za­cji ope­ru­je­my doku­men­ta­mi obcy­mi, otrzy­ma­ny­mi z zewnątrz i wypa­da­ło by mieć taki doku­ment w posta­ci takiej jaką prze­słał nam ich twór­ca. Owszem poja­wia się redun­dan­cja danych ale ona nie sta­no­wi sobą nic złe­go. Ogromną korzy­ścią takie­go podej­ścia jest roz­wią­za­nie pro­ble­mu pole­ga­ją­ce­go na nie­moż­no­ści roz­dzie­le­nia doku­men­tów” i logi­ki ope­ro­wa­nia nimi jeże­li są zapi­sa­ne w posta­ci odręb­nych pól w rela­cyj­nej bazie danych. Np. sta­je się nie­moż­li­we pozo­sta­wie­nie fak­tur i wynie­sie­nie doku­men­tów maga­zy­no­wych do odręb­ne­go sys­te­mu (w tym zmia­na ich struk­tu­ry) co ma miej­sce nie raz przy wdra­ża­niu sys­te­mów WMS (sys­te­my logi­stycz­no-maga­zy­no­we). Takie ope­ra­cji pra­wie żaden duży zin­te­gro­wa­ny ERP nie wytrzy­ma (usły­szy­my raczej, że my dosto­su­je­my do Państwa potrzeb nas moduł magazynowy…).

Podejście takie ma tak­że inna cie­ka­wą zale­tę: jeże­li udo­ku­men­tu­je­my osob­no struk­tu­ry doku­men­tów i logi­kę ope­ro­wa­nia nimi (tak­że ich two­rze­nia), to otrzy­ma­my obiek­to­wy model orga­ni­za­cji: model poka­zu­ją­cy wza­jem­ną współ­pra­cę obiek­tów biz­ne­so­wych (doku­men­tów) odpo­wie­dzial­nych za prze­cho­wy­wa­nie infor­ma­cji, obiek­tów odpo­wie­dzial­nych za reje­stro­wa­nie tych infor­ma­cji, obiek­tów mają­cych wie­dzę jak ope­ro­wać tymi infor­ma­cja­mi, obiek­tów udo­stęp­nia­ją­cych to wszyst­ko zgod­nie z okre­ślo­ną logi­ką. Poniżej obiek­to­wy model na któ­rym od pra­wej mamy: doku­men­ty z ich tre­ścią oraz logi­kę ich two­rze­nia i udo­stęp­nia­nia (repo­zy­to­ria czy­li kuwet­ki na doku­men­ty), logi­kę korzy­sta­nia z infor­ma­cji w repo­zy­to­riach, tak­że ich wza­jem­ne­go koja­rze­nia (samo­dziel­ne usłu­gi) oraz logi­kę dostę­pu do tego sys­te­mu (reali­za­cja sce­na­riu­szy przy­pad­ków uży­cia). Jeżeli w toku ana­li­zy uzna­my, że jakieś ele­men­ty tej logi­ki to zada­nia pod­da­ją­ce się w 100% algo­ryt­mi­za­cji, to poniż­szy model jest jed­no­cze­śnie mode­lem logi­ki apli­ka­cji i nazy­wa­my go Modelem Dziedziny Systemu. Nie jest to abso­lut­nie żad­na baza danych, poniż­sze repo­zy­to­ria nicze­go nie współ­dzie­lą (moż­na je w dowol­nym momen­cie zamie­niać na inne bez kon­se­kwen­cji dla resz­ty systemu).

Obiektowy model dziedziny Zasada SOLID

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. (Źródło: Krzywe i kosz­ty? archi­tek­tu­ry | | Jarosław Żeliński IT-Consulting

Prawie zawsze obser­wu­ję, że pod­sta­wo­wym domyśl­nym zało­że­niem wdro­żeń sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie, jest uzna­nie a prio­ri nie­zmien­no­ści struk­tu­ry i wzo­rów dokumentów. 

Z doświad­cze­nia mogę powie­dzieć, że ana­li­za i opty­ma­li­za­cja tre­ści doku­men­tów wewnętrz­nych może przy­nieść bar­dzo duże korzy­ści prze­kła­da­ją­ce się na duży wzrost wewnętrz­nej efek­tyw­no­ści i jako­ści pra­cy, a w przy­pad­ku wdro­żeń opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, pozwa­la nie raz cał­ko­wi­cie unik­nąć bar­dzo kosz­tow­nych i ryzy­kow­nych kasto­mi­za­cji. Zaryzykuje tezę, że kil­ka pro­jek­tów w ten spo­sób wręcz uratowałem… 

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Zarządzanie wymaganiami

Wczoraj pod­czas dru­gie­go dnia dnia kon­fe­ren­cji EOIF jeden z refe­ra­tów (Zarządzanie wyma­ga­nia­mi biz­ne­so­wy­mi dla sys­te­mów IT wspie­ra­ją­cych elek­tro­nicz­ny obieg infor­ma­cji, Sylwia Raczko, Carrywater Group S.A.). Nie podej­mę pró­by powtó­rze­nia go, nie taki mam cel. Będzie tu kil­ka słów ode mnie. Ale po kolei.

Etap pierwszy to analiza otoczenia projektu

Najczęściej pomi­ja­ny etap w pro­jek­tach. Moim zda­niem z dwóch powo­dów. Mało któ­ry spon­sor pro­jek­tu ma świa­do­mość jakie ryzy­ka nie­sie brak wie­dzy o oto­cze­niu pro­jek­tu, bo jako spon­sor już uwie­rzył w jego suk­ces (cho­ro­ba zna­na jako emo­cjo­nal­ne podej­ście do wła­snych pomy­słów). Drugi powód to fakt, że wie­lu inte­re­sa­riu­szy pro­jek­tu ma inte­res w tym, by te ryzy­ka nie zosta­ły ujaw­nio­ne. ten etap to pierw­szy ele­ment, któ­re­go reali­za­cja napo­ty­ka opo­ry, a moim zda­niem powi­nien być wyko­na­ny nie raz przez zawar­ciem głów­nej umo­wy, gdyż może się oka­zać, że pro­jekt jest z góry ska­za­ny na porażkę.

Z per­spek­ty­wy każ­de­go sys­te­mu (sys­tem to nie tyl­ko opro­gra­mo­wa­nie, to tak­że sys­tem zarzą­dza­ni jako­ścią czy nowy sys­tem raba­to­wy) nale­ży opra­co­wać model uwzględ­nia­ją­cy tych, któ­rzy będę z nie­go bez­po­śred­nio korzy­sta­li (akto­rzy) oraz tych, któ­rzy odczu­ją skut­ki jego wdro­że­nia a mają wpływ na jego powsta­wa­nie. Taka ana­li­za wpły­wu pozwo­li oce­nić ryzy­ka gene­ro­wa­ne przez każ­de­go inte­re­sa­riu­sza i wła­ści­wie na nie zare­ago­wać. Jednym z pro­duk­tów takiej ana­li­zy jest plan komu­ni­ka­cji. Mamy więc na tym eta­pie produkty:

  1. model oto­cze­nia sys­te­mu (pro­jek­tu),
  2. ana­li­za ryzyka,
  3. plan komu­ni­ka­cji.

Więcej o tym eta­pie w arty­ku­le Udziałowcy pro­jek­tu czy­li któ­ry dia­gram UML (czy­taj).

Etap drugi analiza i specyfikowanie wymagań

Ten etap jest naj­więk­szą czę­ścią pro­jek­tu ana­li­tycz­ne­go. Jak zebrać wyma­ga­nia to tema rze­ka. Ogólnie meto­dy ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań moż­na podzie­lić na dwie grupy:

  1. meto­dy formalne,
  2. meto­dy nieformane.

Pierwsze opie­ra­ją się na zasto­so­wa­niu sfor­ma­li­zo­wa­nych sys­te­mów poję­cio­wych i wery­fi­ko­wal­nym pro­ce­sie ana­li­tycz­nym czy­li po pro­tu na sto­so­wa­niu okre­ślo­nych nota­cji (z regu­ły BMM i BPMN) oraz ana­li­zy systemowej.

Drugie bazu­ją na spo­tka­niach, warsz­ta­tach, mode­ro­wa­nych sesjach. Ich głów­ną cechą jest uzna­nie, że tak zebra­ne dane są wia­ry­god­ne: uzna­nie a prio­ri, że zama­wia­ją­cy się nie myli i ma rację. Jakkolwiek to brzmi, nie jest to takie oczy­wi­ste. Wykazanie nie­sprzecz­no­ści tak zebra­nych wyma­gań jest wyko­nal­ne ale już ich spój­ność i kom­plet­ność jest nie do wyka­za­nia bo nie ist­nie­je test kom­plet­no­ści opo­wia­da­nia”, sko­ro nie moż­na wyka­zać (prze­te­sto­wać) kom­plet­no­ści to tym bar­dziej nie da się wyka­zać spójności.

Metody for­mal­ne bazu­ją na ana­li­zie od ogó­łu do szcze­gó­łu” orga­ni­za­cji i opra­co­wa­niu jej kom­plet­ne­go mode­lu (na wyma­ga­nym dla danej ana­li­zy pozio­mie szcze­gó­ło­wo­ści). Model taki sta­je się narzę­dziem testo­wa­nia wyma­gań, np. mając mode­le wszyst­kich pro­ce­sów biz­ne­so­wych może­my spraw­dzić, czy nie pomi­nę­li­śmy jakichś istot­nych dzia­łań, któ­re wyma­ga­ły by uję­cia w wymaganiach.

Bardzo waż­na rze­czą jest jest podzie­le­nie wyma­gań na biz­ne­so­we i funk­cjo­nal­ne bo to nie to samo (czy­taj Produkty w pro­ce­sie ana­li­zy wyma­gań). Pani Raczko przy­wo­ła­ła defi­ni­cję Rona Ross’a, jed­nak chy­ba zbyt upro­ści­ła ory­gi­nał spro­wa­dza­jąc sło­wo sys­tem” do opro­gra­mo­wa­nie”. Znany mi ory­gi­nał brzmi:

We defi­ne a busi­ness requ­ire­ment as ?some­thing cal­led for or deman­ded by a busi­ness model that a sys­tem model must support?

We defi­ne a sys­tem model as fol­lows a model that pro­vi­des a design for an auto­ma­ta­ble sys­tem that is com­pu­ta­tio­nal­ly competent.

(źr. What?s the Difference Between Business Requirements and Functional Requirements?)

Rzecz w tym, że sło­wo com­pu­ta­tio­nal” ozna­cza wyli­czal­ność” w rozu­mie­niu da się wyli­czać auto­ma­tycz­nie (raczej w sen­sie algo­ryt­micz­nym). To nie koniecz­nie musi być kom­pu­ter, mogą to być okre­ślo­ne do wdro­że­nia pro­ce­du­ry (przy­po­mnę, że przed­mio­tem pro­jek­to­wa­nia może być sys­tem zarzą­dza­nia jako­ścią lub sys­tem raba­to­wy sprze­da­ży). Warto zwró­cić uwa­gę, że Ross nie użył sło­wa requ­ire­ment” (wyma­ga­nia) w odnie­sie­niu do sys­te­mu a model”. Ross tak­że słusz­nie zauwa­ża, że wiki­pe­dia zrów­nu­je poję­cie wyma­gać z wyma­ga­nia­mi funk­cjo­nal­ny­mi co jest i moim zda­niem błę­dem. Prawdopodobnie to uprosz­cze­nie w pre­zen­ta­cji zosta­ło doko­na­ne z uwa­gi na tema­ty­kę kon­fe­ren­cji, uwa­żam jed­nak, że jest groź­ne. Mam wszyst­kie książ­ki Ross’a i wyda­je mi się, że nie zrów­nu­je on poję­cia sys­tem z oprogramowaniem.

Wymagania biz­ne­so­we w sto­sun­ku do wyma­gań sys­te­mo­wych” cechu­je inna bar­dzo waż­na róż­ni­ca: treść wyma­gań biz­ne­so­wych MUSI być w 100% zro­zu­mia­ła dla zama­wia­ją­ce­go, napi­sa­na jego języ­kiem. Model sys­te­mu, jako wyma­ga­nia na sys­tem, może być (i z regu­ły jest) już wie­dzą tajem­ną” zro­zu­mia­łą tyl­ko dla dostaw­cy systemu.

Zarządzanie zmianą wymagań

To kolej­ne nie­chcia­ne dziec­ko w pro­jek­tach. Jeżeli zgo­dzi­my się, że zmia­na wyma­gań jest nor­mą” to brak wie­dzy (zapi­sów) o tych zmia­nach potra­fi zabić pro­jekt. Problem, któ­ry ja widzę w wie­lu pro­jek­tach to: im łatwiej zgło­sić i egze­kwo­wać zmia­nę w wyma­ga­niach tym wię­cej tych zmian jest. Nie cho­dzi o to by tych zmian zaka­zy­wać, cho­dzi o to by były one za każ­dym razem prze­my­śla­ne, a cho­dzi głow­nie o wpływ zmian na ter­min i budżet projektu.

Ja tak­że widzę tu dużą róż­ni­cę. Z moich obser­wa­cji wyni­ka, że pro­jek­ty, w któ­rych zasto­so­wa­no zwin­ne meto­dy zarzą­dza­nia nimi, bar­dzo czę­sto tra­cą kon­tro­lę nad zakre­sem pro­jek­tu. Po pierw­sze dla­te­go, że wpro­wa­dza­nie zmian bez ich doku­men­to­wa­nia i świa­do­me­go prze­pro­jek­to­wy­wa­nia sys­te­mu, pro­wa­dzi do nie­kon­tro­lo­wa­ne­go przy­ro­stu pra­cy. Po dru­gie pro­jek­ty zwin­ne cechu­je to, że nie mają opi­sa­ne­go zakre­su pro­jek­tu a jedy­nie wizje pro­duk­tu jaki ma powstać, w efek­cie jedy­nym ele­men­tem pro­jek­tu jakim zarzą­dza kie­row­nik pro­jek­tu jest prak­tycz­nie tyl­ko budżet gdyż zakres jako taki nie ist­nie­je a har­mo­no­gram to tyl­ko na bie­żą­co defi­nio­wa­ne etapy.

Zarządzanie wymaganiamiUogólniając nie­co: w meto­dach kla­sycz­nych ist­nie­je sztyw­na gra­ni­ca pomię­dzy fazą ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań a fazą ich imple­men­ta­cji. W meto­dach zwin­nych mamy pętlę zgła­sza­nia zmian (i nowych wyma­gań), któ­ra z regu­ły nie jest dokumentowana.

Czy to powo­du­je, że w meto­dach kla­sycz­nych odci­na­my sobie moż­li­wość zasto­so­wa­nia nowych pomy­słów? Absolutnie nie, nowe pomy­sły są mate­ria­łem na nowy pro­jekt. Zgłaszane zmia­ny są ana­li­zo­wa­ne i albo są akcep­to­wa­ne bo mają mały lub żaden wpływ na budżet i har­mo­no­gram, albo są odkła­da­ne na etap eks­plo­ata­cji i roz­wo­ju” w cyklu życia pro­duk­tu (nowy cel pro­jek­tu i nowy pro­jekt). Pani Raczko stwier­dzi­ła, że jej doświad­cze­nie wska­zu­je, że pro­jek­ty pro­wa­dzo­ne meto­dą kla­sycz­ną są z regu­ły szyb­ciej koń­czo­ne, ale doty­czy to raczej więk­szych pro­jek­tów. Moje doświad­cze­nia są ana­lo­gicz­ne. Granicą któ­rą kie­dyś obli­cza­łem, po prze­kro­cze­niu któ­rej war­to zre­zy­gno­wać z metod zwin­nych, jest budżet prze­kra­cza­ją­cy 100 tys. zł. Jak widać nie są to aż tak wiel­kie pro­jek­ty. Jednak dla każ­dej fir­my utra­ta 100 tys. zł (nie­uda­ny pro­jekt) sta­no­wi bar­dzo odczu­wal­ny wydatek.

Jak wyglą­da taka zmiana?

Zarządzanie zmianą

Kluczowe korzy­ści to kom­plet­na doku­men­ta­cja pro­jek­tu, jest ona nie tyl­ko pomoc­na po jego zakoń­cze­niu, ale tak­że w trak­cie jego trwa­nia, gdyż sta­no­wi narzę­dzie kon­tro­li budże­tu. Bardzo złym mier­ni­kiem postę­pu pro­jek­tu jest dekla­ro­wa­nie zuży­wa­nych zaso­bów (robo­czo­go­dzi­ny lub dni), w zwin­nych meto­dach to w zasa­dzie jest to jedy­ny mier­nik. Jeżeli zaś dys­po­nu­je­my doku­men­ta­cją każ­dej zmia­ny, jest ona znacz­nie bar­dziej wia­ry­god­nym mier­ni­kiem postę­pu pro­jek­tu, gdyż zarzą­dza­my pro­jek­tem zada­nio­wo a nie zaso­bo­wo. W meto­dach zwin­nych nie da się wyko­nać ana­li­zy wpły­wu zmia­ny na cały pro­jekt, bo nie ist­nie­je doku­men­ta­cja całe­go sys­te­mu (jego model), on dopie­ro powsta­je w trak­cie trwa­nia pro­jek­tu. Tak więc w zasa­dzie nie ist­nie­je poję­cie ana­li­zy ryzy­ka zgła­sza­nej zmia­ny w meto­dach zwin­nych. W meto­dzie kla­sycz­nej, mamy udo­ku­men­to­wa­ny, każ­dy etap pro­jek­tu co, poza ewen­tu­al­ny­mi spo­ra­mi o zakres, pozwa­la pano­wać nad spój­no­ścią i nie­sprzecz­no­ścia zgła­sza­nych zmian wyma­gań, gdyż spe­cy­fi­ka­cja – jako całość – przez cały czas trwa­nia pro­jek­tu (a nie tyl­ko na począt­ku) ma być kom­plet­na, spój­na i niesprzeczna.

Na koniec narzędzia

W tej kwe­stii jed­no jest pew­ne: jeże­li już uzna­my, że wyma­ga­nia­mi zarzą­dza­my, to robie­nie tego narzę­dzia­mi biu­ro­wy­mi (edy­tor tek­stu, arkusz kal­ku­la­cyj­ny, pro­ste opro­gra­mo­wa­nie do dia­gra­mów typu Visio) strasz­nie pod­nie­sie pra­co­chłon­ność pro­jek­tu (czy­taj o sabo­ta­żu doku­men­ta­cyj­nym). Klienci, któ­rzy uwa­ża­ją, że wol­no użyć tyl­ko narzę­dzi, któ­rych sami na co dzień uży­wa­ją, sami sobie robią krzyw­dę, bo zgła­sza­nie zmian nie pole­ga na mody­fi­ka­cji cudzych doku­men­tów pro­jek­to­wych, a na two­rze­niu wła­snych (czy­taj o zgła­sza­niu zmian).

Biorąc pod uwa­gę fakt, że wyma­gań w śred­nim nawet pro­jek­cie jest co naj­mniej kil­ka­dzie­siąt, utrzy­ma­nie ich spój­no­ści i ana­li­za wpły­wu każ­dej zmia­ny na cały pro­jekt sta­je się bene­dyk­tyń­ską pra­cą, naj­czę­ściej szyb­ko zarzu­ca­ną wła­śnie z powo­du pra­co­chłon­no­ści (a nie bra­ku jej sen­su). Dlatego w zasa­dzie brak narzę­dzia CASE do zarzą­dza­nia wyma­ga­nia­mi (są z regu­ły czę­ścią narzę­dzi do ana­li­zy i mode­lo­wa­nia) w zasa­dzie w moich oczach dys­kwa­li­fi­ku­je usługodawcę.

Z powyż­sze­go pły­nie tak­że kolej­ny wnio­sek: autor spe­cy­fi­ka­cji wyma­gań, powi­nien kon­ty­nu­ować pro­jekt jako oso­ba zarzą­dza­ją­ca wyma­ga­nia­mi, i bar­dzo dobrze jest jeże­li pra­cu­je po stro­nie Zamawiającego, gdyż sta­no­wi natu­ral­ny mecha­nizm kon­tro­li pra­cy dostaw­cy np. opro­gra­mo­wa­nia. Zamawiający nie ma innej moż­li­wo­ści real­ne­go, mery­to­rycz­ne­go nad­zo­ru nad dostaw­cą, to Zamawiający powi­nien zarzą­dzać wyma­ga­nia­mi bo to w koń­cu jego wymagania!

Wszystkie drogi prowadzą do Rzymu – zarządzanie jakością

Zaskoczył mnie ostat­nio jeden z moich czy­tel­ni­ków: zapy­tał mnie:

Od lat śle­dzę Pana blog i osią­gnię­cia w zakre­sie ana­li­zy sys­te­mo­wej i biz­ne­so­wej. Mimo, że nie zaj­mu­ję się zawo­do­wo mode­lo­wa­niem wyma­gań na opro­gra­mo­wa­nie sta­ra­łem się zro­zu­mie Pana podejście:

1) W pierw­szym eta­pie wyko­nu­je­my ana­li­zę biz­ne­so­wą pro­ble­mu klien­ta korzy­sta­jąc z BMM

2) Jeśli docho­dzi­my na tej pod­sta­wie do wnio­sku, że wła­ści­wym podej­ściem jest wytwo­rze­nie opro­gra­mo­wa­nia prze­pro­wa­dza­my ana­li­zę sys­te­mo­wą korzy­sta­jąc z UML i two­rzy­my model dzie­dzi­ny sys­te­mu, któ­ry jest pod­sta­wą do pro­jek­to­wa­nia i wytwa­rza­nia dedy­ko­wa­ne­go oprogramowania

Czy dobrze zrozumiałem?

Odpisałem, że tak, jed­nak war­to robić pomię­dzy punk­ta­mi 1) i 2) model fir­my opi­su­ją­cy jak ona dzia­ła, gdyż takie pro­jek­ty są bar­dzo dobry­mi momen­ta­mi na ewen­tu­al­ne reor­ga­ni­za­cje. I tu pada­ją tezy zwią­za­ne z mode­lo­wa­niem organizacji:

Przenosząc to na grunt wła­snym pro­ble­mów zawo­do­wych pró­bu­ję ana­lo­gicz­nie stwo­rzyć model postę­po­wa­nia w pro­ble­mach orga­ni­za­cyj­nych roz­wią­zy­wa­nych za pomo­cą stwo­rze­nia odpo­wied­nich pro­ce­dur postę­po­wa­nia (n.p. przy wdra­ża­niu sys­te­mów zarzą­dza­nia zgod­nych z ISO 27001, ISO 20000 i ISO 22301):

1) Podobnie jak powy­żej wyko­nu­je­my ana­li­zę biz­ne­so­wą pro­ble­mu klien­ta korzy­sta­jąc z BMM

2) Po stwier­dze­niu, że pro­blem moż­na roz­wią­zać zbio­rem pro­ce­dur prze­pro­wa­dza­my ana­li­zę orga­ni­za­cyj­ną (?) korzy­sta­jąc z BMPN i tworzymy??

No wła­śnie ? czy spo­tkał się Pan z odpo­wied­ni­kiem mode­lu dzie­dzi­ny sys­te­my w ?inży­nie­rii wyma­gań na orga­ni­za­cję?? Czyli ze zbio­rem wyma­gań na pro­ce­du­ry, któ­re powin­ny zostać wdro­żo­ne, aby roz­wią­zać okre­ślo­ny pro­blem biznesowy?

Niestety w Polsce nie spo­tka­łem, spo­ty­kam się jed­nak w lite­ra­tu­rze z teza­mi, że wdro­że­nie jakich­kol­wiek norm, nie tyl­ko jako­ści, powin­no być tak­że poprze­dzo­ne ana­li­zą. Innymi sło­wy nor­my jako­ści powin­ny być wdra­ża­ne jako odpo­wiedź (roz­wią­za­nie) na okre­ślo­ne wyma­ga­nia, a nie dla same­go fak­tu ich wdra­ża­nia. Owszem, bywa, że wyma­ga­niem jest np. wymóg prze­tar­go­wy (ofer­ty mogą skła­dać tyl­ko fir­my mają­ce okre­ślo­ny cer­ty­fi­kat), jed­nak moda na jakość, mimo że nie prze­mi­nę­ła cał­ko­wi­cie, powo­li prze­cho­dzi w racjo­nal­ne powo­dy wdra­ża­nia norm jakości.

Sam zresz­tą wdra­żam pew­ne pro­ce­du­ry w każ­dym moim pro­jek­cie, np. zaka­zu­ję” wymia­ny doku­men­tów ema­ilem, są współ­dzie­lo­ne w repo­zy­to­rium pozwa­la­ją­cym na ich wer­sjo­no­wa­nie i komen­to­wa­nie (skrzyn­ki mailo­we to jeden z naj­gor­szych spo­so­bów zarzą­dza­nia doku­men­ta­cją pro­jek­to­wą, nie tyl­ko z powo­du bra­ku pouf­no­ści). Uwagi do doku­men­tów naka­zu­ję” zgła­szać pisem­nie osob­na notat­kę, a nie w macie­rzy­stym doku­men­cie meto­dą nano­sze­nia i reje­stra­cji zmian. W tym przy­pad­ku po pro­stu nikt nie panu­je nad tre­ścią doku­men­tu, roz­my­wa się jego autor­stwo (a jako oso­ba reali­zu­ją­ca umo­wę o dzie­ło nie mogę do tego dopusz­czać), no nie moż­na mieć pew­no­ści, że ktoś okre­ślo­nych uwag nie zaakc­pe­to­wał”, cze­go już nie widać, a wyszu­ki­wa­nie zmian w nawet śred­niej wiel­ko­ści doku­men­cie, potra­fi być żmud­ne. (prze­czy­taj o wadach pra­cy z narzę­dzia­mi biu­ro­wy­mi w pro­jek­tach).

Procedury to efekt wyma­gań jakie ja sta­wiam przed pro­ce­sem ana­li­zy i pro­jek­to­wa­nia, mie­dzy innymi:

  1. musi być zacho­wa­ne jed­no­oso­bo­we autor­stwo doku­men­tów (każ­dy doku­ment ma wyłącz­nie jed­ne­go auto­ra): wpro­wa­dza­nie do nie­go zmian przez inne oso­by jest niedopuszczalne, 
  2. musi być dostęp do histo­rii prac nad doku­men­tem: uwa­gi do tre­ści, w tym pro­po­zy­cje zmia­ny, do doku­men­tów są zgła­sza­ne wyłącz­nie w try­bie zgła­sza­nia zmian” (każ­dy taki doku­ment ma tak­że jed­ne­go auto­ra: oso­bą zgłaszającą
  3. tyl­ko uza­sad­nio­ne zmia­ny pod­le­ga­ją roz­pa­try­wa­niu: każ­da uwa­ga do recen­zo­wa­nej tre­ści musi zawie­rać uza­sad­nie­nie (jakie ryzy­ko nie­sie obec­na treść, jak ją zmienić).
  4. doku­men­ty nie mogą ginąć, nie mogą byś usu­wa­ne, kolej­ne wer­sje muszą być ozna­cza­ne nume­rem wer­sji, każ­dy czło­nek zespo­łu pro­jek­to­we­go musi mieć iden­tycz­ne infor­ma­cje: musi być wdro­żo­ne współ­dzie­lo­ne repo­zy­to­rium pli­ków pro­jek­to­wych, doku­men­ty są zna­ko­wa­ne cza­sem i godzi­ną dostarczenia.
  5. musi być moż­li­wa pra­ca zdal­na bez koniecz­no­ści insta­lo­wa­nia na kom­pu­te­rze jakie­go­kol­wiek dodat­ko­we­go opro­gra­mo­wa­nia: repo­zy­to­rium pli­ków powin­no pra­co­wać poprzez prze­glą­dar­kę WWW.

Tak więc mamy okre­ślo­ne wyma­ga­nia i ich reali­za­cję (opis wyma­ga­nia i pro­ce­du­ra po dwu­krop­ku). Normalnym try­bem w więk­szych pro­jek­tach, pro­wa­dzo­na jest ana­li­za fir­my i budo­wa­ny jest jej model pro­ce­so­wy. Na nim wyszu­ku­je­my” miej­sca stwa­rza­ją­ce ryzy­ka, opi­su­je­my je. Jeżeli uzna­my, że chce­my te ryzy­ka eli­mi­no­wać lub zmniej­szać, mamy tym samym wyma­ga­nia biz­ne­so­we. Kolejny krok to opra­co­wa­nie roz­wią­za­nia, w moim przy­pad­ku powy­żej, były to trzy pro­ce­du­ry oraz wyma­ga­nie na elek­tro­nicz­ne repo­zy­to­rium. Można więc sobie wyobra­zić, że w kate­go­riach całej fir­my powsta­ną wyma­ga­nia, któ­re moż­na zre­ali­zo­wać wdra­ża­jąc kon­kret­ną nor­mę ISO.

Zastanawiam się rów­nież co taki model powi­nien zawie­rać? (ana­lo­gicz­nie do mode­lu dzie­dzi­ny systemu):

- listę ról (odpo­wied­nik obiektów/klas?)

- listę umie­jęt­no­ści danej roli (odpo­wied­nik cech obiektu/klasy?)

- listę pro­ce­dur jakie uży­wa dana rola (odpo­wied­nik metod obiektu/klasy?)

Powyższe to raczej mate­riał na model pro­ce­so­wy. Prawdą jest, że role to pew­ne obiek­ty w sys­te­mie jakim jest orga­ni­za­cja, jed­nak już ich umie­jęt­no­ści i pro­ce­du­ry to wie­dza o tym jak wyko­nać daną pra­ce, pro­ce­du­ra (jej utwo­rze­nie) to mini­ma­li­za­cja ryzy­ka, że pra­ca ta zosta­nie wyko­na­na źle. I tu przy­to­czę mój model pro­ce­su w organizacji:

Jak opisać firmę wewnątrz: model procesów biznesowychTak więc każ­dy ele­men­tar­ny pro­ces zawie­ra ele­men­ty, o któ­rych wspo­mi­na mój czy­tel­nik. Owszem model obiek­to­wy jest tu moż­li­wy do wyko­na­nia ale będzie to sta­tycz­na struk­tu­ra (któ­ra tak­że bywa potrzeb­na jako model) jed­nak model orga­ni­za­cji w posta­ci pro­ce­sów, to fun­da­ment tej doku­men­ta­cji. Proszę zwró­cić uwa­gę, że to co jest wokół pro­ce­su (pro­ce­du­ry, regu­ły biz­ne­so­we, struk­tu­ra orga­ni­za­cyj­na, zakre­sy kom­pe­ten­cji, inne) to w więk­szo­ści ele­men­ty doku­men­ta­cji sys­te­mów zarzą­dza­nia jako­ścią. Mając model pro­ce­su, po jego ewen­tu­al­nej opty­ma­li­za­cji, mamy bar­dzo dobry mate­riał do opra­co­wa­nia wyma­gań na System Zarządzania Jakością: wie­my jakie dokład­nie doku­men­ty mają powstać a jakie nale­ży zmo­dy­fi­ko­wać, wie­my po co powstają.

Zaletą takie­go postę­po­wa­nia jest moż­li­wość uza­sad­nie­nia biz­ne­so­we­go (śla­do­wa­nie) każ­de­go wyma­ga­nia. Innymi sło­wy, jeste­śmy w sta­nie wyka­zać, że każ­da pro­po­no­wa­na nowa lub zmie­nio­na pro­ce­du­ra, wspie­ra okre­ślo­ny cel biz­ne­so­wy oraz wyni­ka z napra­wy” okre­ślo­ne­go procesu.

Po prze­czy­ta­niu powyż­sze­go, w kolej­nym liście mój czy­tel­nik pisze porządkując:

Chciałbym się jesz­cze podzie­lić jed­ną obser­wa­cją a pro­pos ISO ? być może uzna Pan ją za błędną ?

Otóż aku­rat nor­ma ISO 27001, z któ­rą mam aktu­al­nie do czy­nie­nia defi­niu­je coś takie­go co nazy­wa prze­pro­wa­dze­niem ana­li­zy ryzy­ka, a efek­tem ma być plan postę­po­wa­nia z ryzy­kiem. Na począt­ku nie mogłem sobie tego wyobra­zić, ale po Pańskiej odpo­wie­dzi spra­wa wyda­je się jasna:

- na pod­sta­wie ana­li­zy orga­ni­za­cji defi­niu­je­my kla­sy­fi­ka­cję infor­ma­cji ? to defi­niu­je nor­ma ([…] punk­tem wyj­ścia są doku­men­ty i arte­fak­ty (fizycz­na reprezentacja/lokalizacja doku­men­tów), któ­re zawie­ra­ją infor­ma­cje. Przykładowo umo­wa z kon­tra­hen­tem i ofer­ta (doku­men­ty) zawie­ra wyce­nę usłu­gi (infor­ma­cja), któ­ra powin­na być chro­nio­na na okre­ślo­nym pozio­mie. Związanie doku­men­tów i ich repre­zen­ta­cji za pomo­cą ?infor­ma­cji? pozwa­la usta­lić poziom ochro­ny okre­ślo­nych doku­men­tów i ich fizycz­nych repre­zen­ta­cji i loka­li­za­cji. Z kolei poziom ochro­ny infor­ma­cji jest czy­stym wyma­ga­niem biz­ne­so­wym ? to biz­nes okre­śla jakie ?infor­ma­cje? nale­ży ?jak? chro­nić. Model ?infor­ma­cji? powi­nien pozwo­lić na pod­sta­wie kla­sy­fi­ka­cji usta­lo­nej z biz­ne­sem okre­ślić poziom ochro­ny doku­men­tów i ich fizycz­nych realizacji/lokalizacji. Stąd już pro­sta dro­ga do okre­śle­nia ryzy­ka zwią­za­ne­go z prze­twa­rza­niem doku­men­tów i spo­so­bów zabez­pie­cze­nia. Prosty przy­kład ? umo­wa (doku­ment) pozba­wio­na infor­ma­cji o warun­kach han­dlo­wych (tajem­ni­ca przed­się­bior­stwa) może mieć niż­szy poziom ochro­ny (wyni­ka­ją­cy wyłącz­nie z praw autor­skich) niż umo­wa z tymi infor­ma­cja­mi?)

- potem okre­śla­my jak są prze­twa­rza­ne infor­ma­cje, któ­re chce­my chro­nić two­rząc model orga­ni­za­cji za pomo­cą BPMN

- ana­li­zu­jąc ten model może­my usta­lić miej­sca w mode­lu prze­twa­rza­nia, gdzie wystę­pu­je ryzy­ko utra­ty bez­pie­czeń­stwa i gdzie nale­ży wdro­żyć pro­ce­du­ry kontrolne

- wte­dy mamy listę pro­ce­dur do wdro­że­nia dla kon­sul­tan­ta ISO.

Podsumowując nor­ma narzu­ca wyko­na­nie ana­li­zy orga­ni­za­cyj­nej i okre­śle­nie wyma­gań na pro­ce­du­ry. Niestety załącz­ni­ki do nor­my poda­ją przy­kła­dy takich pro­ce­dur, więc uprosz­czo­ne podej­ście kon­sul­tan­tów ISO spro­wa­dza­ło­by się do wdro­że­nia pro­ce­dur ?gotow­ców? według załącz­ni­ka do nor­my, z pomi­nię­ciem zro­zu­mie­nia co, jak i dla­cze­go nale­ży chronić.

Oczywiście punk­tem wyj­ścia jest doku­men­ta­cja klien­ta, a więc wspo­mnia­ne doku­men­ty HR, opi­sy sta­no­wisk, obo­wiąz­ków, archi­tek­tu­ra danych/systemów. Zrozumiałem, że na tej pod­sta­wie two­rzy­my dia­gram fak­tów (na pod­sta­wie, któ­re­go moż­na wyge­ne­ro­wać słow­nik) i dalej ana­li­zu­je­my jak dzia­ła orga­ni­za­cja i co nale­ży zabezpieczać.

No i mamy, naj­praw­do­po­dob­niej, goto­wy spo­sób postę­po­wa­nia. Co cie­ka­we dopie­ro po prze­czy­ta­niu tego listu zda­łem sobie spra­wę, że w wie­lu pro­jek­tach wyko­ny­wa­łem powyż­sze pra­ce, w róż­nym zakre­sie (ja już nie two­rzy­łem typo­wych dla ISO pro­ce­dur) z zupeł­nie inne­go powo­du: popra­wa jako­ści dzia­ła­nia fir­my, zanim zosta­nie wdro­żo­ne opro­gra­mo­wa­nie. Po co? Żeby nie infor­ma­ty­zo­wać bała­ga­nu. Jak widać, do pod­no­sze­nia jako­ści pro­wa­dzi wie­le dróg.

(cyta­ty pocho­dzą z listu Pana Michała Gładysza)