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… 

Kim jest CIO i czym jest IT

Wpadł mi ręce ostat­ni numer IT-Magazine. Jest w nim bar­dzo cie­ka­wy arty­kuł Roberta Tulickiego-Sypołowskiego zaty­tu­ło­wa­ny Problem komu­ni­ka­cji IT z biz­ne­sem, czy­li nowa odsło­na sta­re­go pro­ble­mu”. Napisał w nim mię­dzy inny­mi (pole­cam cały arty­kuł), że Zadaniem dzi­siej­sze­go CIO jest wyko­rzy­sta­nie tech­no­lo­gii do budo­wa­nia i wspie­ra­nia stra­te­gii biz­ne­so­wej.” Pochyliłem się nad tym zda­niem, bo jako oso­ba regu­lar­nie zaj­mu­ją­ca się uspraw­nia­niem orga­ni­za­cji, a w tym odkry­wa­niem” wyma­gań na IT, regu­lar­nie z CIO mam do czy­nie­nia. (CIO – Chief Information Officer ? angiel­ski tytuł nada­wa­ny w dużych orga­ni­za­cjach oso­bom zarzą­dza­ją­cym dzia­łem informatyki).

Zdanie to jed­nak zanie­po­ko­iło mnie, bo jeże­li zga­dzam się z tym, że IT zawsze wspie­ra reali­za­cje stra­te­gii biz­ne­so­wej, to pyta­nie brzmi: kie­dy ją współ­two­rzy (budu­je)? Moja mała pole­mi­ka albo tyl­ko dodatek…

W jed­nym z ostat­nich arty­ku­łów napisałem:

Pamiętamy też czym jest wie­dza i infor­ma­cja. Tak więc, nie­za­leż­nie od tego czym się dana orga­ni­za­cja zaj­mu­je (bran­ża), cała istot­na wie­dza o niej to to, co zosta­ło zapi­sa­ne: infor­ma­cje i ich zapis czy­li wie­dza. Mówiąc wprost: fir­mę postrze­ga­my przez jej ?cień?, jakim są wszel­kie zapi­sy o tym co się w niej wyda­rzy­ło. Teraz jed­nak musi­my okre­ślić: co nale­ży zapi­sać, któ­re infor­ma­cje utrwa­lać i jak, by obraz ten był wystar­cza­ją­cy. To, co i jak jest zapi­sy­wa­ne, to ?sys­tem infor­ma­cyj­ny? orga­ni­za­cji. Jest on swo­istą ?jaski­nią Platona?. (Architektura kor­po­ra­cyj­na i doj­rza­łość).

Popatrzmy na poniż­szy diagram:

Kontekst - biznes - informacja - przetwarzanie

Mamy tu Zarząd orga­ni­za­cji, CIO, pro­ces Realizacji stra­te­gii orga­ni­za­cji czy­li jej pod­sta­wo­wą dzia­łal­ność, oraz Zasoby infor­ma­cyj­ne. Te ostat­nie nadal funk­cjo­nu­ją w posta­ci tra­dy­cyj­nej (papie­ro­wa) oraz elek­tro­nicz­nej (sys­te­my IT).

Pytanie jakie nale­ży sobie zadać to: za co odpo­wia­da (powi­nien odpo­wia­dać) CIO, za to co trzy­ma” tech­no­lo­gia IT czy za całość infor­ma­cji w orga­ni­za­cji? Patrząc na to przez pry­zmat tego co napi­sa­łem powy­żej (jaski­nia Platona), i jak widać na dia­gra­mie, nie jest to takie oczy­wi­ste. Jeżeli CIO zarzą­dza tyl­ko IT to zna­czy, że nie zarzą­dza cało­ścią infor­ma­cji. Jeżeli miał­by zarzą­dzać cało­ścią infor­ma­cji (co z utrzy­ma­niem jej spój­no­ści?) to zna­czy, że ma pod sobą” tak­że archi­wa papierowe.

Tu widzę pro­blem i takie mnie nacho­dzą wnioski:

  1. Jeżeli CIO to tyl­ko IT, to jest to oso­ba, któ­ra nie współ­two­rzy żad­nej stra­te­gi (poza tym, że może mieć głos dorad­czy, pamię­ta­my, że stra­te­gia to odpo­wie­dzial­ność Zarządu) ale na pew­no wspie­ra jej realizację.
  2. Jeżeli CIO ma zarzą­dzać całą infor­ma­cją w orga­ni­za­cji to nabie­ra to nowe­go zna­cze­nia i być może taki CIO powi­nien brać udział w two­rze­niu stra­te­gii orga­ni­za­cji ale wte­dy powi­nien być człon­kiem Zarządu.

Problem jaki tu widzę, to przy­zwy­cza­je­nie w wie­lu orga­ni­za­cjach (w urzę­dach w szcze­gól­no­ści) do tego, że papie­ry” to dome­na archi­wi­stów, któ­rzy bro­nią swo­jej nie­za­leż­no­ści i odręb­no­ści jak nie­pod­le­gło­ści. Patrząc jed­nak z pozy­cji ustaw zrów­nu­ją­cych doku­ment papie­ro­wy z elek­tro­nicz­nym, jestem skłon­ny twier­dzić, że dłu­go tej nie­za­leż­no­ści nie utrzy­ma­ją. Sam fakt poja­wia­nia się sys­te­mów elek­tro­nicz­ne­go obie­gu doku­men­tów, z któ­rych prak­tycz­nie każ­dy ma kom­po­nent elek­tro­nicz­ne archi­wum doku­men­tów”, ta nie­za­leż­ność już jest fik­cją. Co jest i pozo­sta­nie moim zda­niem rola archi­wi­stów? Przede wszyst­kim meta­da­ne doku­men­tów czy­li ich kla­sy­fi­ka­cja. Podstawową rolą archi­wi­sty jest zarzą­dza­nie reten­cją i zagwa­ran­to­wa­nie łatwe­go dotar­cia do histo­rycz­nych doku­men­tów poprzez ich wła­ści­we kla­sy­fi­ko­wa­nie. Białe ręka­wicz­ki i zapach papie­ru to już coraz czę­ściej raczej relikt prze­szło­ści (któ­ry jed­nak jesz­cze potrwa).

Tak więc kim jest CIO? Czym jest IT? W naszym języ­ku utrwa­li­ło się I jako infor­ma­ty­ka (tech­no­lo­gia), w języ­ku angiel­skim I ozna­cza infor­ma­cję. Jeżeli CIO ma brać udział w two­rze­niu stra­te­gi, moim zda­niem musi zostać wynie­sio­ny do pozio­mu zarzą­du i zarzą­dzać infor­ma­cją a nie tyl­ko infor­ma­ty­ką czy­li pew­nym wycin­kiem infor­ma­cji. Czy to, CIO w zarzą­dzie, się komuś uda? Jeżeli nie, to CIO będzie tyl­ko zarząd­cą zaso­bów IT, naj­waż­niej­szych ale jed­nak jed­nych z wie­lu w organizacji.

Na zakoń­cze­nie. IT prak­tycz­nie wszę­dzie, to tyl­ko wyci­nek sys­te­mu infor­ma­cyj­ne­go. To jest czę­stym powo­dem pro­ble­mów w pro­jek­tach wdro­że­nio­wych. Dlatego zawsze suge­ru­ję, by ana­li­zy biz­ne­so­we były holi­stycz­nym” pro­jek­tem w fir­mach pro­wa­dzo­nym ponad IT”, a nie tyl­ko pro­jek­tem infor­ma­tycz­nym” przed czym nie­ste­ty wie­lu CIO się bro­ni, i tu widzę źró­dło owe­go kon­flik­tu IT vs. biznes”.

Tablice decyzyjne

Po dłu­gich poszu­ki­wa­niach w anty­kwa­ria­tach mam: Tablice decy­zyj­ne . Książka opi­su­je tabli­ce decy­zyj­ne jako narzę­dzie do mode­lo­wa­nia zacho­wa­nia sys­te­mów deterministycznych. 

Tablice te w peł­ni zastę­pu­ją znacz­nie bar­dziej skom­pli­ko­wa­ne drze­wa decy­zyj­ne, mode­lu­ją decy­zję (jej pod­ję­cie) jako jeden fakt a nie zło­żo­ny, kaska­do­wy pro­ces decy­zyj­ny . W dal­szej opis two­rze­nia i czę­ści przy­kła­dy uży­cia takich tablic.

Tablica decyzyjna

Odpowiadając na pyta­nia pod arty­ku­łem Tablice decy­zyj­ne ? fak­ty a nie pro­ce­sy, napi­sa­łem mię­dzy inny­mi, że regu­ła biz­ne­so­wa to nie regu­ła decy­zyj­na. Jeden z czy­tel­ni­ków podał jako przy­kład regu­ły biz­ne­so­wej wybór zwro­tu do osoby:

  • Płeć: męż­czy­zna ? powi­ta­nie: Pan;
  • Płeć: kobie­ta oraz Stan: mężat­ka ? powi­ta­nie: Pani;
  • Płeć: kobie­ta oraz Stan: wol­ny ? powi­ta­nie: Panna;

Powyższe to zbiór decy­zji podej­mo­wa­nych w odpo­wie­dzi na okre­ślo­ne zda­rze­nie. Takie decy­zje (i regu­ły ich podej­mo­wa­nia) moż­na zapi­sać w posta­ci tabli­cę decy­zyj­nej, powyż­sze nie jest regu­łą biz­ne­so­wą. Regułą biz­ne­so­wą było by: ?w listach adre­so­wa­nych imien­nie zawsze poprze­dza się imię i nazwi­sko oso­by wła­ści­wym zwro­tem grzecz­no­ścio­wym?. Reguły biz­ne­so­we to regu­ły zacho­wa­nia (się) systemu.

Powyższe to sys­tem podej­mo­wa­nia decy­zji o tym, jaki to powi­nien być zwrot. Jest to o tyle istot­ne, że regu­ła biz­ne­so­wa, jako regu­ła zacho­wa­nia, w nie­zmie­nio­nym brzmie­niu może obo­wią­zy­wać np. wszyst­kie oddzia­ły fir­my w innych kra­jach, ale tabli­ca decy­zyj­na to pro­ce­du­ra doko­na­nia wybo­ru wła­ści­we­go zwro­tu, będzie inna dla każ­de­go kra­ju (a kon­kret­nie każ­de­go języ­ka). Poniżej tabli­ca decy­zyj­na dla tego przy­kła­du (dla j.polskiego ;)):

DecyzjaPanPaniPanna

Tablica ta zosta­ła pod­da­na nor­ma­li­za­cji, to jest usu­nię­to waru­nek Jest płci męskiej, gdyż wiersz ten zawie­rał pro­stą nega­cje wier­sza Jest płci żeń­skiej (zakła­da­my, że nie roz­pa­tru­je­my rodza­ju nija­kie­go). Tablica taka (po nor­ma­li­za­cji) jest, jak widać, prost­sza od trzech warun­ków z przy­kła­du opi­so­we­go” sys­te­mu decy­zji. Powyższa tabli­ca jest tabli­ca zupeł­ną (wyszcze­gól­nio­no wszyst­kie kom­bi­na­cje Warunków) wiec moż­na jej użyć do auto­ma­ty­za­cji pro­ce­su np. adre­so­wa­nia kore­spon­den­cji (wię­cej o tym w dal­szej czę­ści). Wersja rów­no­waż­na uprosz­czo­na tej samej tablicy:

TabDecUprZwrot

Proponuję czy­tel­ni­kom same­mu zna­leźć zasa­dę doko­na­ne­go uprosz­cze­nia :). Ciekawe omó­wie­nie i przy­kła­dy tablic decyzyjnych:

Przykład korzy­ści z uży­cia tablic decy­zyj­nych zamiast opisu:

https://​www​.visu​al​-para​digm​.com/​p​r​o​d​u​c​t​/​a​r​t​i​c​l​e​s​/​d​e​c​i​s​i​o​n​-​t​a​b​l​e​-​e​x​p​l​a​i​n​ed/

Reguły biznesowe a reguły decyzyjne

W grud­niu ubie­głe­go roku pisałem:

Bardzo czę­sto spo­ty­kam się z ogrom­ną zło­żo­no­ścią (licz­ba i ich podzia­ły) wyma­gań. Problem tkwi nie raz w tym, że ?naro­sła? przez lata ?ster­ta zarzą­dzeń?, któ­ra zamiast zostać naj­pierw upo­rząd­ko­wa­na, jest ?wprost? trak­to­wa­na jako ?wyma­ga­nia?. Takie podej­ście to krok w stro­nę klę­ski pro­jek­tu. (Reguły biz­ne­so­we ? pro­jekt zabi­ja ich bez­sen­sow­na ilość? ).

W tam­tym tek­ście nie opi­sa­łem jed­nak o róż­ni­cy pomię­dzy regu­łą a decy­zją. Przyszła pora i na to.

Postaram się zwró­cić uwa­gę na to, że mode­lo­wa­nie biz­ne­so­we z peł­nym zro­zu­mie­niem, to nie suchy zapis wie­dzy pozy­ska­nej w roz­mo­wach czy wywia­dach. To dąże­nie do zro­zu­mie­nia. Powyższe poka­zu­je, że jest róż­ni­ca pomię­dzy regu­łą a decy­zją, nawet jeże­li ta dru­ga jest naka­za­na” tą pierw­szą. Czy to ważne?

Wiele firm ma pro­ble­my zarząd­cze nie dla­te­go, że są źle zarzą­dza­ne, ale dla­te­go, że sto­pień zło­żo­no­ści tych firm jest zbyt duży by podej­mo­wać je na wyczu­cie. W obec­nych cza­sach decy­zje muszą być podej­mo­wa­ne w rela­tyw­nie krót­kim cza­sie bo rynek nie cze­ka, jed­nak jakość tych decy­zji nie powin­na być zła. Dlaczego bywa zła? Bo decy­zje są nie raz podej­mo­wa­ne z nie­peł­nym zro­zu­mie­niem sytu­acji. Podejmowana decy­zja, by była moż­li­wie naj­lep­sza, wyma­ga peł­ne­go zro­zu­mie­nia, tego cze­go doty­czy (co chy­ba nie jest dziw­ne). Jeżeli doty­czy fir­my, nie powin­no się podej­mo­wać decy­zji bez peł­ne­go zro­zu­mie­nia poten­cjal­ne­go wpły­wu tej decy­zji na fir­mę. W prze­ciw­nym wypad­ku skut­ki są dość loso­we, czy­li nie zarzą­dza­my a sta­ra­my się zarządzać.

Przytoczony na począt­ku przy­kład doty­czą­cy zwro­tów grzecz­no­ścio­wych, poka­zu­je cien­ką gra­ni­cę pomię­dzy regu­łą a decy­zją. Jak zwy­kle u mnie ;), naj­pierw patrzy­my do słow­ni­ka j.polskiego (PWN):

regu­ła: <zasa­da postę­po­wa­nia usta­lo­na przez kogoś lub przy­ję­ta na mocy zwyczaju>

decy­zja: <posta­no­wie­nie będą­ce wyni­kiem doko­na­nia wyboru>

idzie­my dalej:

zasa­da: <pra­wo rzą­dzą­ce jaki­miś pro­ce­sa­mi, nor­ma postępowania>

wybór: <wybra­nie jed­nej z kil­ku możliwości>

Mamy bazę poję­cio­wą. Można więc napi­sać, że regu­ła biz­ne­so­wa to usta­lo­na zasa­da postę­po­wa­nia, zaś decy­zja biz­ne­so­wa to doko­na­nie wybo­ru jed­nej spo­śród zna­nych moż­li­wo­ści wybo­ru. Nie jest to to samo, co, mam nadzie­ję, obra­zu­je przy­kład ze zwro­ta­mi grzecz­no­ścio­wy­mi. Tak więc obli­ga­to­ryj­ne uży­wa­nie zwro­tów grzecz­no­ścio­wych to obo­wią­zu­ją­ca zasa­da – regu­ła biz­ne­so­wa (zacho­wa­nie). Wybór wła­ści­we­go zwro­tu spo­śród zna­nych moż­li­wych, to decy­zja o wybo­rze. Może być ona wyni­kiem wie­dzy posia­da­nej lub udo­ku­men­to­wa­nej (w posta­ci np. tabli­cy decyzyjnej).

Proszę zwró­cić uwa­gę, że jeże­li regu­ła decy­zyj­na nie jest oczy­wi­sta to war­to ją narzu­cić” w fir­mie, wte­dy wybór wła­ści­we­go zwro­tu jest już ele­men­tem pew­nej wie­dzy fir­mo­wej. Tę wie­dzę jed­nak moż­na posia­dać lub nie. Jeżeli tyl­ko ist­nie­je ryzy­ko wybo­ru (przez np. pra­cow­ni­ków) złej for­my grzecz­no­ścio­wej, to nale­ży ją wła­śnie z góry narzu­cić (tabli­ca decy­zyj­na czy­li wie­dza udo­ku­men­to­wa­na). W przy­pad­ku imple­men­to­wa­nia tego mecha­ni­zmu, np. w sys­te­mie CRM, musi­my tę wie­dzę udo­ku­men­to­wać w spo­sób jed­no­znacz­ny, a do takich wła­śnie spo­so­bów nale­ży narzę­dzie jakim jest tabli­ca decyzyjna.

Analiza firmy

Po co się robi ana­li­zy biz­ne­so­we orga­ni­za­cji? Nie po to by zapi­sać set­ki stron! Analizę pro­wa­dzi­my by zro­zu­mieć te ana­li­zo­wa­ne orga­ni­za­cje. Po co? By następ­ne podej­mo­wa­ne decy­zje byłe mniej ryzy­kow­ne, bar­dziej świa­do­me. Taką decy­zją jest wpro­wa­dze­nie zmia­ny orga­ni­za­cyj­nej, okre­śle­nie wyma­ga­nia na opro­gra­mo­wa­nie, zawar­cie nowej umo­wy anga­żu­ją­cej zaso­by orga­ni­za­cji, wie­le innych.

Podejmijmy pró­bę upo­rząd­ko­wa­nia opi­sa­nych tu pojęć:

reguły a decyzje i procesy

Diagram ten (tzw. dia­gram fak­tów dla sys­te­mu poję­cio­we­go, słu­ży mię­dzy inny­mi do testo­wa­nia spój­no­ści sys­te­mu poję­cio­we­go – prze­strze­ni nazw) poka­zu­je (mam nadzie­ję jasno) poję­cia i wią­żą­ce je fak­ty (kształ­to­wa­nie, two­rze­nie cze­goś itp. to fak­ty zwią­za­ne z tymi poję­cia­mi). Zaznaczyłem dodat­ko­wo linię podzia­łu (kre­ska prze­ry­wa­na) pomię­dzy tym co jest opi­sem (mode­lem) pro­ce­su (spe­cy­fi­ka orga­ni­za­cji) oraz tym cze­go ocze­ku­je się od zaan­ga­żo­wa­nych zaso­bów. Nietrudno się domy­ślić, że regu­ły biz­ne­so­we to zasa­dy orga­ni­za­cyj­ne, spe­cy­ficz­ne dla niej. Decyzje to pra­ca ludzi, któ­rzy tych zasad muszą prze­strze­gać a decy­zje te muszą, w związ­ku z tym, być podejmowane.

Obecnie nie raz pla­nu­je­my auto­ma­ty­za­cję wybra­nych czyn­no­ści. Na czym ona pole­ga? Na tym, że tam gdzie regu­ły decy­zyj­ne moż­na opi­sać w posta­ci zupeł­nej (zna­my wszyst­kie moż­li­we sytu­acje i przy­po­rząd­ko­wu­je­my im kon­kret­ne decy­zje – [[tabli­ca decy­zyj­na zupeł­na]]), moż­na sobie pozwo­lić na zastą­pie­nie czło­wie­ka maszy­ną. Tą maszy­ną może być oczy­wi­ście np. kom­pu­ter i odpo­wied­nie oprogramowanie.

Proszę zwró­cić tak­że uwa­gę na to, że linia podzia­łu pomię­dzy pro­ce­sa­mi a zaso­ba­mi to tak­że linia podzia­łu pomię­dzy pro­ce­sa­mi a ich imple­men­ta­cją. Podział zna­ny już z poniż­sze­go dia­gra­mu (źr. http://​www​.bptrend​sas​so​cia​tes​.com/):

Na zakończenie

Analiza biz­ne­so­wa orga­ni­za­cji poprze­dza­ją­ca np. wdro­że­nie nowe­go opro­gra­mo­wa­nia, powin­na pole­gać na wyko­na­niu audy­tu i upo­rząd­ko­wa­niu reguł decy­zyj­nych oraz opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych by je zwe­ry­fi­ko­wać. Drugi krok to oce­na, jakiej wie­dzy ocze­ku­je­my od ludzi (ich umie­jęt­no­ści i wie­dza). Dokumentujemy ją z oba­wy przed błę­dem ludz­kim”. Tu zwra­cam uwa­gę na to, że wyma­ga­niem na opro­gra­mo­wa­nie może być tabli­ca decy­zyj­na, jeże­li pla­nu­je­my auto­ma­ty­za­cję jakiejś czyn­no­ści. Proces biz­ne­so­wy nie jest wyma­ga­niem, to co naj­wy­żej kon­tekst wyko­ny­wa­nych czynności.

Know-how

Swego cza­su, w arty­ku­le o mode­lo­wa­niu pro­ce­sów biz­ne­so­wych napi­sa­łem, że:

Biznesowy know-how ? naj­cen­niej­szą rzecz w fir­mie. I po to war­to wyko­nać ana­li­zą biz­ne­so­wą: poznać i udo­ku­men­to­wać swo­ją prze­wa­gę czy­li fir­mo­we know-how. (Modelowanie biz­ne­so­we c.d. ? know-how, gdzie ono jest?).

Jednym z klu­czo­wych ele­men­tów owe­go know-how jest wła­śnie wie­dza będą­ca wyni­kiem zbie­ra­ne­go doświad­cze­nia. Znajomość swo­jej histo­rii i wycią­ga­ne z niej wnio­ski to bar­dzo czę­sto wie­dza o tym, któ­re decy­zje jakie skut­ki dla fir­my przy­nio­sły. Kolekcjonowanie tej wie­dzy to nic inne­go jak budo­wa­nie i kon­ser­wo­wa­nie” tablic decy­zyj­nych. Typowym przy­kła­dem takich pil­nie strze­żo­nych tablic są sys­te­mu sco­rin­go­we ban­ków i ubez­pie­czy­cie­li, sys­te­my oce­ny wia­ry­god­no­ści kon­tra­hen­tów i wie­le innych. Nie nale­ży zapo­mi­nać, że sys­te­my decy­zyj­ne wyma­ga­ją okre­śle­nia reguł (biz­ne­so­wych) mówią­cych kie­dy je stosować.

Jeszcze o systemach

Dla przy­po­mnie­nia przy­to­czę pro­stą defi­ni­cje systemu:

System ? obiekt fizycz­ny lub abs­trak­cyj­ny, w któ­rym moż­na wyod­ręb­nić zespół lub zespo­ły ele­men­tów wza­jem­nie powią­za­nych w ukła­dy, reali­zu­ją­cych jako całość funk­cję nad­rzęd­ną lub zbiór takich funk­cji (funk­cjo­nal­ność). Z uwa­gi na fakt, że wyod­ręb­nie­nie wszyst­kich ele­men­tów przy­na­le­żą­cych do sys­te­mu bywa w prak­ty­ce nie­kie­dy bar­dzo trud­ne, dla­te­go do bada­nia sys­te­mów wyko­rzy­stu­je się ich uprosz­czo­ne mode­le. Elementy przy­na­le­żą­ce do jed­ne­go sys­te­mu nie mogą jed­nak sta­no­wić jed­no­cze­śnie ele­men­tów przy­na­leż­nych do inne­go sys­te­mu (na pod­sta­wie: Bertalanffy, L. von, Ogólna teo­ria sys­te­mów. Podstawy, roz­wój, zasto­so­wa­nia. PWN, Warszawa 1984).

Tu, orga­ni­za­cje, bada­nym sys­te­mem są zaso­by i tre­ści jakie są w nich prze­twa­rza­ne czy­li wza­jem­nie powią­za­ni ludzie, maszy­ny i doku­men­ty. Organizacje np. na ryn­ku, to tak­że sys­tem, sys­tem nad­rzęd­ny, któ­ry tak­że nale­ży rozu­mieć. Ten mode­lu­je­my jed­nak na eta­pie ana­li­zy stra­te­gii np. ryn­ko­wej. Po co to wszyst­ko? Poprawny model zbu­do­wa­ny sfor­ma­li­zo­wa­ny­mi meto­da­mi to narzę­dzie podej­mo­wa­nia decy­zji, tym lep­szych im lep­szy model.

Nie jest to, mode­lo­wa­nie, łatwe jak widać. Wymaga, poza samą umie­jęt­no­ścią ana­li­zy i sfor­ma­li­zo­wa­ne­go jej doku­men­to­wa­nia, tak­że duże­go doświad­cze­nia oraz zna­jo­mo­ści i rozu­mie­nia pro­ce­su zarzą­dza­nia orga­ni­za­cją. Tam gdzie dana orga­ni­za­cja jest pod­mio­tem ryn­ko­wym, tak­że zasad rzą­dzą­cych rynkiem.

Najważniejsze w tym jest to, że samo udo­ku­men­to­wa­nie cze­goś np. na pod­sta­wie czy­je­goś opi­su, bez spraw­dze­nia czy opis jest jed­no­znacz­ny, nie ma w nim sprzecz­no­ści i czy jest zupeł­ny (opi­su­je wszyst­ko), nie nie­sie żad­nej war­to­ści, a nie raz nawet wpro­wa­dza w błąd.

TabliceDecyzyjnePWN1971

(UWAGA! Artykuł to część mojej pra­cy nauko­wej, wszel­kie pra­wa do jego tre­ści są zastrze­żo­ne, wni­kli­wym ana­li­ty­kom do poczy­ta­nia: Solomon L. Pollack, Harry T. Hicks, Jr, William J. Harrison: Tablice decy­zyj­ne, PWN Warszawa 1975).

Literatura

Vasilecas, O., & Smaizys, A. (2007). Business Rule Based Configuration Management and Software System Implementation Using Decision Tables. Local Proceedings of ADBIS, 2007, 27 – 37.
Pollack, S. L., Hicks, H. T., & Harrison, W. J. (1975). Tablice decy­zyj­ne. PWN.
Vanthienen, J. A. N., & Dries, E. (1992). Developments in deci­sion tables: Evolution, appli­ca­tions and a pro­po­sed stan­dard. DTEW Research Report 9227.
Vanthienen, J., & Wets, G. (1992). Mapping Decision Tables to Expert System Shells: An Implementation in AionDS. Onderzoeksrapport 9228.

Analiza danych i podejmowanie decyzji: pięta achillesowa współczesnych organizacji

Zaczęło się od pro­wo­ka­cyj­ne­go arty­ku­łu Chrisa Andersona ?The End of Theory: The Data Deluge Makes the Scientific Method Obsolete? . Redaktor naczel­ny mie­sięcz­ni­ka Wired udo­wad­niał w nim, że zalew dany­mi (okre­śla­ny po angiel­sku mia­nem ?data delu­ge? lub ?big data?) wywo­ła­ny, z jed­nej stro­ny sta­łym spad­kiem kosz­tów prze­cho­wy­wa­nia infor­ma­cji, a z dru­giej, upo­wszech­nie­niem ser­wi­sów Web 2.0, słu­żą­cych kre­owa­niu i współ­dzie­le­niu wie­dzy, wkrót­ce zmu­si nowo­cze­sne orga­ni­za­cje do rezy­gna­cji z wyra­fi­no­wa­nych narzę­dzi do ana­li­zy sta­ty­stycz­nej. A w dal­szej per­spek­ty­wie może ozna­czać wery­fi­ka­cję dotych­cza­so­wych metod nauko­wych i badaw­czych. (źr. Blog Jacka Murawskiego dyrek­to­ra gene­ral­ne­go pol­skie­go oddzia­łu Microsoft.)

Jest to kolej­ny głos mówią­cy o zale­wie śmie­cio­wych danych. Pisałem swe­go cza­su o pro­ble­mach z migra­cją danych pod­czas wdra­ża­nia nowych sys­te­mów. Problemem nie jest sama migra­cja (prze­nie­sie­nie danych ze sta­re­go sys­te­mu do nowe­go) a to, co prze­nieść. Niestety naj­czę­ściej z bra­ku pomy­słu” prze­no­si się wszyst­ko” co powo­du­je, że rośnie licz­ba śmie­ci zaś rela­tyw­nie spa­da odse­tek danych fak­tycz­nie przydatnych.

W efek­cie ma miej­sce para­dok­sal­ne zja­wi­sko: rosną kosz­ty zarzą­dza­nia dany­mi a ich war­tość (przy­dat­ność) male­je. Np. dane księ­go­we i podob­ne – struk­tu­ral­ne – moż­na prze­no­sić do hur­tow­ni danych. Tu pro­ces ich czysz­cze­nia roz­wią­zu­je część pro­ble­mu, bo to tyl­ko ich porząd­ko­wa­nie. Pozostaje pro­blem cze­go nie prze­no­sić”. Dochodzi pro­blem danych nie­struk­tu­ral­nych takich jak róż­ne­go rodza­ju doku­men­ty (ofer­ty, robo­cze doku­men­ta­cje pro­jek­to­we itp.).

Cały ten pro­blem ma nazwę: [[reten­cja danych]]. Pojawiają się gło­sy by w fir­mach wpro­wa­dzić pro­ces zna­ny z urzę­dów i sys­te­mu Archiwów Państwowych: nada­wa­nie kate­go­rii archi­wal­nej każ­dej dokumentacji.

Problem nie jest pro­sty, mam wra­że­nie, że czę­sto igno­ro­wa­ny bo dys­ki twar­de tanie­ją”, jed­nak nie ma pro­ble­mu z tym by coś wynieść na strych, pro­blem w tym by to po kil­ku latach odna­leźć”. Kolejny pro­blem to psy­cho­lo­gia i czy­sta ludz­ka wyobraź­nia: po latach mamy nie raz wra­że­nie, że coś co zacho­wa­li­śmy kie­dyś nadal ma war­tość taką jak w dniu zacho­wa­nia, co z regu­ły oka­zu­je się nie­praw­dą. Rzecz w tym, że war­tość danych ope­ra­cyj­nych male­je z upły­wem cza­su (dez­ak­tu­ali­zu­ją się dane o cenach, warun­kach han­dlo­wych itp.). Można zary­zy­ko­wać tezę, że po roku więk­szość z nich (szcze­gó­ły) jest nie­przy­dat­na. Co naj­wy­żej war­tość ma sam fakt, że do jakichś kon­tak­tów docho­dzi­ło, jaki był ich cel itp.

Jak sobie z tym radzić? Narzędzie poma­ga­ją­ce w tym, zawar­te jest w więk­szo­ści dobrych sys­te­mów zarzą­dza­nia prze­pły­wem pra­cy i doku­men­tów. Każdy taki sys­tem ma tak zwa­ne [[repo­zy­to­rium doku­men­tów]]. Jest to archi­wum pli­ków (doku­men­ty, zdję­cia, pli­ki źró­dło­we, itp.), dużą war­to­ścią repo­zy­to­riów jest to, że maja tak zwa­ny sys­tem meta­da­nych. [[Metadane]] to struk­tu­ral­ny opis nie­struk­tu­ral­nej zawar­to­ści prze­cho­wy­wa­nych plików.

Właściwy pro­jekt tych meta­da­nych ([[tak­so­no­mia]]) pozwa­la na stwo­rze­nie dwóch dodat­ko­wych cech przy­dat­nych w sys­te­mach [[busi­ness inteligence]]:

  1. meta­da­ne (jako dane struk­tu­ral­ne) mogą być migro­wa­ne do hur­tow­ni danych,
  2. meta­da­ne nadal zacho­wu­ją klu­czo­we infor­ma­cje po usu­nię­ciu pli­ków źró­dło­wych (z regu­ły dużych i nie­przy­dat­nych, np. po latach nadal będzie­my wie­dzie­li jak czę­sto kon­tak­to­wał się z nami klient i po co, mimo bra­ku dostę­pu do już bez­war­to­ścio­wych danych o szcze­gó­łach tych kontaktów).

Warto two­rzyć dobrze prze­my­śla­ne sys­te­my meta­da­nych dla sys­te­mów archi­wi­za­cji doku­men­tów, gdyż pozwa­la to z jed­nej stro­ny spiąć” archi­wum doku­men­tów z hur­tow­nią danych z dru­giej pozbyć się” śmie­ci. Tempo przy­ro­stu danych sta­le rośnie gdyż biz­ne­so­we opro­gra­mo­wa­nie, auto­ma­ty­zu­jąc wie­le naszych czyn­no­ści, wytwa­rza je w tem­pie w jakim czło­wiek nigdy nie był by w sta­nie. Po dru­gie nara­sta zja­wi­sko powie­la­nia, co nazy­wam to syn­dro­mem copy&paste”. Wiele doku­men­tów (o zgro­zo tak­że tych podob­no autor­skich”) powsta­je coraz czę­ściej meto­dą powie­la­nia tego co znaj­dzie się w fir­mo­wych archi­wach (wie­dza kor­po­ra­cyj­na czy­li po pro­stu jej zanik, bo wie­dza to umie­jęt­ność napi­sa­nia cze­goś a nie sko­pio­wa­nia) czy w sieci.

Moja prak­ty­ka (to co dosta­je do audy­tu u klien­tów) poka­zu­je, że doku­men­ty wytwo­rzo­ne od zera” prak­tycz­nie zawsze mają więk­szą war­tość mery­to­rycz­ną niż te wytwo­rzo­ne na bazie tak zwa­nej wie­dzy kor­po­ra­cyj­nej”. Do tego docho­dzi ryzy­ko prze­nie­sie­nia, pod­czas kopio­wa­nia, tre­ści nie­chcia­nych. Kopiując dzie­siąt­ki stron sta­rej ofer­ty” lub poprzed­nie­go opra­co­wa­nia dorad­cze­go”, two­rząc w ten spo­sób kolej­ne indy­wi­du­al­ne autor­skie opra­co­wa­nie” nara­zić się moż­na nie tyl­ko na ujaw­nie­nie tajem­ni­cy, ale tak­że na zwy­kłe ośmie­sze­nie. Dlatego nie tyl­ko sys­tem zarzą­dza­nia doku­men­ta­mi i wie­dzą nale­ży dobrze zapro­jek­to­wać, ale tak­że pro­ces two­rze­nia nowych tre­ści. W prze­ciw­nym wypad­ku nara­ża­my się na budo­wę wiel­kie­go, ośmie­sza­ją­ce­go fir­mę, śmietnika.

Terminem bli­sko sko­ja­rzo­nym z ana­li­zą dzie­dzi­ny i pro­jek­to­wa­niem tak­so­no­mii jest [[onto­lo­gia]]. Tu dla uła­twie­nia cytat z wikipedii:

Termin onto­lo­gia” w infor­ma­ty­ce i podej­ściu systemowym

Termin onto­lo­gia” cie­szy się coraz to wiek­szą popu­lar­no­ścią w infor­ma­ty­ce (np. w budo­wie sie­ci seman­tycz­nych) oraz bada­niach nad sztucz­ną inte­li­gen­cją gdzie ozna­cza to co jest” i może slu­życ jako plat­for­ma ter­mi­no­lo­gicz­na do for­mal­nej budo­wy infor­ma­cji, pre­fe­ren­cji i wie­dzy (Model IPK).

Ontologia” w kon­tek­ście infor­ma­tycz­nym poja­wi­ła się już w roku 1967 w bada­niach doty­czą­cych mode­lo­wa­nia danych, ale dopie­ro w dobie zale­wu infor­ma­cją dostęp­ną w Internecie i koniecz­no­ścią jej prze­twa­rza­nia zysku­je szer­sze zain­te­re­so­wa­nie. Według Gadomskiego, onto­lo­gia w uogól­nio­nym sen­sie sys­te­mo­wym zaj­mu­je się opi­sy­wa­niem ?tego co jest? lub ?moze być? w danej dzie­dzi­nie zain­te­re­so­wa­nia Meta-teo­ria TOGA, w pew­nym frag­men­cie rze­czy­wi­sto­ści lub w ramach jakiejs teo­rii, mniej lub bar­dziej dokład­nie okre­ślo­nym dla dane­go agen­ta inte­li­gent­ne­go lub robo­ta dla osia­gnie­cia zada­ne­go celu. Aby zapew­nić jed­no­znacz­ność prze­ka­zu wie­dzy na temat okre­ślo­nej rze­czy­wi­sto­ści, na zada­nym pozio­mie og?lnosci, wyko­rzy­stu­je się kate­go­ry­za­cję oraz hie­rar­chi­za­cję. W niniej­szym kon­tek­ście, poję­cia te moż­na zde­fi­nio­wać następująco:

  • kate­go­ry­za­cja ? zdol­ność przy­po­rząd­ko­wa­nia sym­bo­lu wystę­pu­ją­ce­go w komu­ni­ka­cie do okre­ślo­nej gru­py obiek­tów wystę­pu­ją­cych w zada­nej dzie­dzi­nie np. ?kot? ? kla­sa kotów, poję­cie kot.
  • hie­rar­chi­za­cja ? umiej­sco­wie­nie okre­ślo­nej kla­sy w hie­rar­chicz­nej struk­tu­rze. Instancja kla­sy poza oczy­wi­sty­mi cha­rak­te­ry­sty­ka­mi wyni­ka­ją­cy­mi z przy­na­leż­no­ści do kla­sy posia­da tak­że cechy dzie­dzi­czo­ne z klas nadrzędnych.

W uje­ciach sys­te­mo­wym, kogni­tyw­nym i infor­ma­tycz­nym poję­cie «onto­lo­gia» jest poję­ciem rela­tyw­nym, naj­ogol­niej, dana onto­lo­gia zale­ży od dzie­dzi­ny, agen­ta inte­li­gent­ne­go kto­ry ją uży­wa i jego celu.

Aby wyraź­niej pod­kre­ślić cechy cha­rak­te­ry­stycz­ne tzw. top-onto­lo­gii (onto­lo­gii uniwersalnej/ogolnej, onto­lo­gii świa­ta), nale­ży przed­sta­wić kil­ka obec­nie dys­ku­to­wa­nych postu­la­tów doty­czą­cych jej funk­cjo­nal­nych cech :

  1. nie sta­no­wi listy, kata­lo­gu czy tak­so­no­mii obiek­tów, stwa­rza nato­miast for­mal­ne prze­słan­ki, wedle któ­rych tako­we mogą być budowane
  2. jest ode­rwa­na od teo­rii pozna­nia (epi­ste­mo­lo­gii), powią­za­na jest z obiek­tem, a nie jego subiek­tyw­nym odbiorem
  3. musi uchwy­cić rze­czy­wi­stość na róż­nych pozio­mach ato­mi­za­cji, jak rów­nież rela­cje pomię­dzy tymi warstwami
  4. uzna­nie bra­ku moż­li­wo­ści stwo­rze­nia jed­nej ogól­nej onto­lo­gii, ist­nie­nie wie­lu ontologii
  5. w prze­ci­wień­stwie do nauki rela­cje mię­dzy obiek­ta­mi nie są uję­te funk­cyj­nie (zależ­no­ści nie są ilościowe)
  6. nauka roz­po­czy­na pro­ces od mie­rze­nia i pre­dyk­cji, onto­lo­gia zaś od budo­wa­nia taksonomii

(za Ontologia ? Wikipedia, wol­na ency­klo­pe­dia.)

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