Business Model Canvas

Modele biz­ne­so­we to temat rze­ka acz­kol­wiek, te mają­ce ambit­niej­sze uza­sad­nie­nie i opi­sa­ne czymś wię­cej niż tyl­ko pro­zą sta­no­wią już raczej uła­mek cało­ści. Stale śle­dzę lite­ra­tu­rę z tej dzie­dzi­ny i … mało się tu dzie­je nowe­go. To w sumie dobry to znak, bo jest symp­to­mem doj­rza­ło­ści dzie­dzi­ny wie­dzy. Tak, doj­rza­ło­ści. W zasa­dzie trud­no tu coś nowe­go wyna­leźć, raczej oka­zu­je się, że wszyst­kie dro­gi pro­wa­dzą do Rzymu”.

Wpadł mi nie­daw­no na ekran” bar­dzo cie­ka­wy arty­kuł. Autor zadał sobie trud wni­kli­we­go omó­wie­nia dwóch cie­ka­wych mode­li biz­ne­so­wych (dwóch podejść do mode­lo­wa­nia mode­lu biz­ne­so­we­go ;)). Popatrzmy:

Business Model Canvas

Model biz­ne­so­wy zapro­po­no­wa­ny przez Aleksa Osterwaldera jest zbu­do­wa­ny jako suma zaso­bów i czyn­no­ści, któ­re fir­ma orga­ni­zu­je i reali­zu­je celem dostar­cze­nia kon­kret­nej war­to­ści dla kon­kret­ne­go klien­ta. Sercem mode­lu Osterwaldera sta­je się pro­po­zy­cja war­to­ści. To wła­śnie wokół (1) pro­po­zy­cji war­to­ści dla (2) kon­kret­ne­go klien­ta budo­wa­na jest część przy­cho­do­wa i część kosz­to­wa biz­ne­su, któ­ra upo­rząd­ko­wa­na zosta­ła przez Aleksa wokół kil­ku klu­czo­wych ele­men­tów, takich jak: kana­ły dys­try­bu­cji i komu­ni­ka­cji, spo­so­by na budo­wę rela­cji, klu­czo­we czyn­no­ści, klu­czo­we zaso­by, klu­czo­wi part­ne­rzy, stru­mie­nie przy­cho­dów i struk­tu­ra kosz­tów. (za Rafał Kołodziej > Business Model Canvas czy Lean Canvas?).

Model sys­te­mo­wy

Popatrzmy na mój model opi­sa­ny w poprzed­nim poście. Na wła­sny uży­tek nazy­wam go Systemowy:

Przypomnę klu­czo­we tezy:

Powyższy dia­gram to model obra­zu­ją­cy łań­cuch war­to­ści i wpływ kon­ku­ren­cji na ana­li­zo­wa­ną fir­mę, a kon­kret­nie na ?war­tość doda­ną? jaką ofe­ru­je na ryn­ku. Kluczowe pyta­nie, ?Dlaczego zara­biasz?, wyma­ga zro­zu­mie­nia dla­cze­go nasz Odbiorca (Klient) nie zaopa­tru­je się bez­po­śred­nio u nasze­go dostaw­cy (zie­lo­na linia prze­ry­wa­na), co takie­go wno­si nasza fir­ma, że war­to przyjść do nas za to zapła­cić. Ważnym ele­men­tem są kana­ły zaopa­trze­nia i dys­try­bu­cji. Wskazują one kim są na praw­dę klien­ci i dostaw­cy. (za Model biz­ne­so­wy czy­li po co mi te pro­ce­sy przed wdro­że­niem ERP czy CRM?)

W kon­cep­cji Business Model Canvas mamy:

  1. Kluczowi part­ne­rzy (Key part­ners), jest to nasz kanał zaopatrzenia,
  2. Kluczowe aktyw­no­ści i klu­czo­we zaso­by to nic inne­go jako klu­czo­we pro­ce­sy, jak pisa­łem wcze­śniej pro­ces to coś co łączy dzia­ła­nia i zaso­by koniecz­ne dla ich zaist­nie­nia, w tym miej­scu do celów ana­li­zy budu­je­my model pro­ce­sów biznesowych,
  3. Wartość doda­na (Value pro­po­si­tion), sed­no biz­ne­su – to coś po co do nas przy­cho­dzą klienci,
  4. Kanał dys­try­bu­cji (Channels) nie wyma­ga chy­ba dodat­ko­wych komentarzy,
  5. Relacje z klien­tem (Customer rela­tion), tu jest mały dyso­nans w porów­na­niu z moim mode­lem, wyja­śnię go: rela­cje z klien­tem w moim odczu­ciu zawsze są czę­ścią war­to­ści doda­nej; moim zda­niem nie da się oddzie­lić pro­duk­tu od jego dostaw­cy gdyż zawsze będzie­my emo­cjo­nal­nie reago­wa­li na jakość obsłu­gi, nie wyobra­żam sobie by klien­ci wią­za­li się z pro­duk­tem mimo bar­dzo złej jako­ści obsłu­gi… owszem kanał dys­try­bu­cji może zano­ni­mi­zo­wać praw­dzi­we­go dostaw­cę (pro­du­cen­ta) ale tu powiem, że nasz pośred­nik wystę­pu­je w naszym imie­niu, zły pośred­nik to tak­że zła sprzedaż,
  6. Struktura kosz­tów (Cost struc­tu­re) jak naj­bar­dziej wpi­su­je się w opis kosz­tów zaso­bów wła­snych i kosz­tów mate­ria­łów (środ­ków) do pro­duk­cji (wytwo­rze­nia), któ­re ja rygo­ry­stycz­nie roz­dzie­lam bo moż­na mieć super źró­dło zaopa­trze­nia i paskud­nie wyso­kie kosz­ty własne.
  7. Strumień przy­cho­dów (Revenue stre­am), na moim mode­lu tego nie ma gdyż, co zazna­cza­łem w swo­im opi­sie, stru­mień przy­cho­dów to odwrot­ność stru­mie­nia” war­to­ści doda­nej, dla­te­go na moim mode­lu kie­ru­nek prze­pły­wu war­to­ści doda­nej repre­zen­tu­je auto­ma­tycz­nie prze­ciw­ny mu stru­mień zapła­ty”.

Osobiście wole mój model, gdyż w moich oczach, roz­dzie­le­nie pojęć kosz­tów zaso­bów i kosz­tów surow­ców jest łatwiej­sze do ana­li­zy i mode­lo­wa­nia top-down (mamy od razy odręb­ne dwa poję­cia). Po dru­gie moim zda­niem roz­dzie­la­nie pojęć war­to­ści doda­nej i stru­mie­nia przy­cho­dów może pro­wa­dzić do błęd­ne­go, moim zda­niem, wnio­sku o odręb­no­ści (nie­za­leż­no­ści) tych dwóch pojęć. Strumień przy­cho­dów to ten sam stru­mień co łań­cuch war­tość, tyl­ko skie­ro­wa­ny w prze­ciw­nym kie­run­ku (jest to ta sama strzał­ka, jej kie­ru­nek zaś zale­ży tyl­ko od tego czy w danym momen­cie jest mowa o war­to­ści doda­nej czy o zapła­cie za nią).

Poniżej dru­gi model omó­wio­ny przez cyto­wa­ne­go autora:

Lean Canvas

Ash Maurya nie­co ina­czej pod­szedł do logi­ki mode­lu Aleksa, budu­jąc go wokół dwóch pod­sta­wo­wych tema­tów (1) pro­dukt i (2) rynek, któ­rych spo­iwem pozo­sta­je pro­po­zy­cja war­to­ści (dla przy­po­mnie­nia: dla Aleksa tymi dwo­ma głów­ny­mi tema­ta­mi były: (1) zaso­by-orga­ni­za­cja; (2) rynek. Ash wycho­dzi z zało­że­nia, że w przy­pad­ku start-up’ów zaso­by i orga­ni­za­cja nie są tak waż­na, jak pomysł na pro­dukt, roz­wią­zu­ją­cy pew­ne okre­ślo­ne pro­ble­my klien­ta i zapew­nia­ją­cy kon­kret­ną prze­wa­gę kon­ku­ren­cyj­ną. (za Rafał Kołodziej > Business Model Canvas czy Lean Canvas?)

Proszę zwró­cić uwa­gę, że od stro­ny poję­cio­wej w zasa­dzie nie róż­ni się od poprzed­nie­go. Pole ozna­czo­ne cyfrą 7 to kal­ka z mode­lu pię­ciu sił Portera: oce­na wpły­wu pro­duk­tów kon­ku­ren­cyj­nych i sub­sty­tu­tów. Reszta prak­tycz­nie niczym się nie róż­ni. Polecam lek­tu­rę całe­go arty­ku­łu Pana Kołodzieja.

Podsumowując: war­to­ścią doda­ną mają­cą, war­tość ryn­ko­wą dla odbior­cy (klien­ta) jest to co powo­du­je, że ONI przy­cho­dzą do nas :). Jest to nasz pro­dukt ale MY (dostaw­ca) jeste­śmy czę­ścią tego pro­duk­tu! Dowodem na to jest poję­cie mar­ki, koja­rzy­my ją z dostaw­ca (pro­du­cen­tem). Nie ma zna­cze­nia sam brą­zo­wy napój z bąbel­ka­mi, one wszyst­kie sma­ku­ją podob­nie, zna­cze­nie na tak­że Nazwa i Logo repre­zen­tu­ją­ce Konkretnego Producenta.

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

O mode­lach biz­ne­so­wych jesz­cze będzie …

computer model real world

Czynniki sukcesu w projektach programistycznych

Listopadowy numer Software Develper Journal zawie­ra bar­dzo cie­ka­wy arty­kuł: Czynniki suk­ce­su w pro­jek­tach pro­gra­mi­stycz­nych.

Wnioski z ankiet:

Wymagania i ich odpo­wied­nie prze­twa­rza­nie to klu­czo­we zagad­nie­nie w pro­jek­tach. Popełniane w tym obsza­rze błę­dy to głów­ne źró­dło pro­ble­mów w pro­jek­tach. Dlaczego tak się dzie­je? Oto głów­ne przy­czy­ny wska­za­ne przez oso­by badane:
  1. nie­zna­jo­mość metod i tech­nik zbie­ra­nia wymagań;
  2. trud­no dotrzeć do informacji;
  3. oso­by dostar­cza­ją­ce wyma­ga­nia są rzad­ko dostępne;
  4. nie­pre­cy­zyj­ne wymagania.

Wydają się oczy­wi­ste, a że z fak­ta­mi nie dys­ku­tu­je­my uzna­je­my je.

Ad.1. To chy­ba powszech­na bolącz­ka wie­lu dostaw­ców IT. Najczęściej obser­wu­ję meto­dę pole­ga­ją­ca na zbie­ra­niu wyma­gań” meto­dą pyta­nia cze­go Pan/Pani ocze­ku­je od sys­te­mu” i ta for­ma jest gwoź­dziem do trum­ny pro­jek­tu. Dlaczego? Odpowiedź zawar­ta jest w pozo­sta­łych trzech pun­kach: wywia­dy cier­pią bo trud­no dotrzeć do danych i ich posia­da­czy a ci ostat­ni naj­czę­ściej poda­ją wyma­ga­nia z gło­wy” co daje w efek­cie ład­nie sfor­ma­to­wa­ny ale nie­pre­cy­zyj­ny opis.

Pojawia się pró­ba dia­gno­zy. Pełna tak zwa­na śla­do­wal­ność wyma­gań (nazwa­na tu hiper­tra­ce­bi­li­ty) jest podob­no kosz­tow­na i trud­na do utrzy­ma­nia. Zaraz potem: nie­dba­łość w defi­nio­wa­niu wyma­gań – no to w koń­cu dokład­nie czy nie? Kolej na ana­li­ty­ków: zrzu­ca­nie odpo­wie­dzial­no­ści ? ana­li­ty­cy two­rzą doku­ment wyma­gań i wypy­cha­ją go do pro­gra­mi­stów. Oczywiście jest to pro­blem, co z tym? Analityk powi­nien pono­sić odpo­wie­dzial­ność za swój pro­dukt do koń­ca pro­jek­tu. Założenie, że moż­na stwo­rzyć skoń­czo­ny doku­ment wyma­gań. Otóż moż­na ale o tym za chwi­lę. Poza waż­ny­mi ele­men­ta­mi zarzą­dza­nia takim pro­jek­tem, w tym zarzą­dza­niem zespo­łem auto­rzy wska­za­li jed­ną z głów­nych moim zda­niem przy­czyn: brak doku­men­tu HLD (pro­jek­tu wysokopoziomego).

Otóż nie da się czymś tak zło­żo­nym jak opro­gra­mo­wa­nie (zakła­dam, że to nie try­wial­ny sys­tem), zarzą­dzać na pozio­mie deta­licz­nych szcze­gó­łów. Jedynym spo­so­bem jest uprasz­cza­nie i pra­ca z abs­trak­cja­mi. Czym są owe abs­trak­cje? Modele! Już w 1984 roku zauwa­żo­no, że:

I just read an idea by [[Stephen Hawking]] and [[Leonard Mlodinow]], cal­led [[Model-Dependent Realism]][2]: ?the idea that a phy­si­cal the­ory or world pic­tu­re is a model (gene­ral­ly of a mathe­ma­ti­cal natu­re) and a set of rules that con­nect the ele­ments of the model to obse­rva­tions.? (za Model-Dependent Realism: Is This the Worldview of Software Engineering? ? THINK IN MODELS).

I nie cho­dzi tu o to, że inży­nie­ria opro­gra­mo­wa­nia, to jakiś zło­żo­ny model mate­ma­tycz­ny. Chodzi w ogó­le o posłu­gi­wa­nie się mode­la­mi – abs­trak­cja­mi – na każ­dym eta­pie pro­jek­tu. To jedy­ny spo­sób by ogar­nąć pro­jekt” w cało­ści. Tak samo jak nie da się myśleć o samo­cho­dzie w kon­tek­ście tysię­cy jego pod­ze­spo­łów, tak nie da się tak myśleć o czym­kol­wiek podob­nie złożonym.

ad.2. Docieranie do infor­ma­cji para­dok­sal­nie nie jest trud­ne, jest ich po pro­tu mało w fir­mach. Bardzo czę­sto postę­po­wa­nie poszcze­gól­nych wyko­naw­ców jest efek­tem ich doświad­cze­nia, kom­pe­ten­cji oraz przy­zna­nych upraw­nień. Problemem, a może raczej wyzwa­niem jest zapi­sa­nie czę­ści tych reguł”.

ad.3. To dla mnie kurio­zal­ny powód. Jest raczej dowo­dem sła­bo­ści kie­row­ni­ka pro­jek­tu (bo nie analityka).

ad.4. Zacytuje dla przy­po­mnie­nia: nie­pre­cy­zyj­ne wyma­ga­nia”. Od tego jest ana­li­ty­ka by były pre­cy­zyj­ne. Problem ten poja­wia się czę­sto w sytu­acji gdy owym ana­li­ty­kiem” jest dostaw­ca opro­gra­mo­wa­nia, któ­ry cze­ka na wyma­ga­nia” mimo, że zawarł w ofer­cie i umo­wie pozy­cję ana­li­za wymagań”.

Raport: Zarządzanie wymaganiami 2011

Na stro­nach zaprzy­jaź­nio­ne­go ser­wi­su Inżynieria opro­gra­mo­wa­nia poka­za­ły się naj­śwież­sze dane (za 2011 rok) na temat kło­po­tów w pro­jek­tach pro­gra­mi­stycz­nych”. Wykonajmy mały eks­pe­ry­ment pole­ga­ją­cy na zesta­wie­niu dwóch pierw­szych pozy­cji wybra­nych poni­żej kate­go­rii. Najpierw ich peł­ne zestawienie:

Z rapor­tu wyni­ka, iż naj­więk­szą trud­no­ścią oka­zu­je się (moż­na było zazna­czyć kil­ka odpowiedzi):

  • 72,9 % – jasne zro­zu­mie­nie tego cze­go tak napraw­dę klient potrzebuje,
  • 58,9 % – udo­ku­men­to­wa­nie wymagań,
  • 50,7 % – zbu­do­wa­nie aplikacji/systemu na pod­sta­wie usta­lo­nych wymagań,
  • 46,9 % – usta­le­nie prio­ry­te­tów wymagań,
  • 43,7 % – prze­ka­za­nie wyma­gań zespo­ło­wi (komu­ni­ka­cja wewnątrz zespołu).

Najczęstsze spo­so­by prze­cho­wy­wa­nia wyma­gań (moż­na było zazna­czyć kil­ka odpowiedzi):

  • 83,2 % – doku­men­ty typu word i excel,
  • 42 % – email,
  • 31,4 % – narzę­dzia do zarzą­dza­nia wyma­ga­nia­mi (typu [[JIRA]]),
  • 31,1 % – prze­ka­zy­wa­ne ust­nie pod­czas codzien­nych spotkań,
  • 21,6 % – narzę­dzia case do zarzą­dza­nia wymaganiami,
  • 21,6 % – zapi­ski na tabli­cy, żół­te karteczki,
  • 11,3 % – por­ta­le typu wiki,
  • 6,6 % – inne.

Diagramy naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi (moż­na było zazna­czyć kil­ka odpowiedzi):

  • 71,4 % – mode­le procesów,
  • 50,1 % – prototypy,
  • 47,5 % – mode­le inter­fej­su użytkownika,
  • 46,5 % – dia­gra­my przy­pad­ków użycia,
  • 31,1 % – dia­gram aktywności,
  • 30,1 % – schematy/odręczne rysunki,
  • 6,6% % – inne.

(za Raport: Zarządzanie wyma­ga­nia­mi 2011 | Inżynieria Oprogramowania).

A teraz zrób­my z tego wyzna­nie na spo­wie­dzi hipo­te­tycz­ne­go kie­row­ni­ka pro­jek­tu” (po dwa pierw­sze powo­dy z powyż­szych statystyk):

Ponad 80% pro­jek­tów pro­gra­mi­stycz­nych ma prze­kro­czo­ne ter­min i budżet. Największą trud­no­ścią w tych pro­jek­tach oka­za­ło się jasne zro­zu­mie­nie tego, cze­go tak napraw­dę klient potrze­bu­je, oraz udo­ku­men­to­wa­nie jego wyma­gań. Do prze­cho­wy­wa­nia wyma­gań uży­ty był głów­nie word i excel oraz ema­il. Przyznajemy jed­nak, że dia­gra­my naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi to mode­le pro­ce­sów i pro­to­ty­py, jed­nak nie sto­su­je­my ich. ( 2011 State of Requirements Management Report.)

Jak widać brzmi zna­jo­mo z dwóch powo­dów: pro­ble­my zna­ne każ­de­mu i powo­dy nie­ste­ty tak­że. Ciśnie mi się na usta a nie mówiłem”…

Czyli jed­nak wie­my że pro­ble­mem pro­jek­tów z zakre­su inży­nie­rii opro­gra­mo­wa­nia są zbyt pro­ste meto­dy i narzę­dzia zarzą­dza­nia wyma­ga­nia­mi (pakiet biu­ro­wy), któ­re w więk­szo­ści są sto­so­wa­ne. Wiemy, że mode­lo­wa­nie jest naj­sku­tecz­niej­sza meto­dą ana­li­zy i pro­jek­to­wa­nia a mimo to nie sto­su­je się tych metod szu­ka­jąc sta­le dro­gi na skróty”.

Dlaczego dostaw­cy opro­gra­mo­wa­nia nie sto­su­ją metod powszech­nie jed­nak uzna­wa­nych za sku­tecz­ne? Czy to przy­pad­kiem nie jest tak, jak z Lotto? Powszechnie wia­do­mo, że praw­do­po­do­bień­stwo wygra­nia jest bli­skie zeru a mimo to wie­lu pró­bu­je, bo gdy­by się uda­ło to nie trze­ba się naro­bić by mieć … 

Dlatego, by się nie powta­rzać, jako kon­ty­nu­ację tego arty­ku­łu pro­po­nu­ję opis metod ana­li­zy wyma­gań i pro­jek­to­wa­nia. Nie jest tania ale jest skuteczna…

Na koniec tro­chę humo­ru 🙂 na temat zbie­ra­nia wyma­gań meto­dą warsz­ta­tów”:

Technokracja i wdrożenia systemów – modelowanie

[foru­mo­wicz] Nauki ści­słe to przede wszyst­kim wie­dza o funk­cjo­no­wa­niu świa­ta oraz nauko­wa meto­da ana­li­zo­wa­nia zja­wisk opar­ta o dowód.

Przysłuchuje się tej dys­ku­sji (doty­czy­ła pew­nej tezy zwią­za­nej z ana­li­zą wyma­gań) i nasu­nę­ła mi się pew­na myśl. Padają [w dys­ku­sjach] czę­sto powyż­sze sło­wa opar­ta o dowód”. Jest to sku­pie­nie się na mate­ma­tycz­nej defi­ni­cji dowo­du. Jest jed­nak na świe­cie wie­le zja­wisk nie pod­da­ją­cych się deta­licz­ne­mu bada­niu bo ich zło­żo­ność jest czymś nie dają­cym się opi­sać w roz­sąd­nym cza­sie” – to myśl z książ­ki Sommervill’a. To mię­dzy inny­mi dzię­ki temu odrzu­co­no for­mal­ne (opar­te na wzo­rach) meto­dy pro­jek­to­wa­nia opro­gra­mo­wa­nia. Drugim powo­dem jest to, że nie ist­nie­je obec­nie spo­sób jed­no­znacz­ne­go i odwra­cal­ne­go prze­kształ­ce­nia sfor­ma­li­zo­wa­nych wyma­gań” w dzia­ła­ją­cy kod.

Naukowa meto­da to deduk­cja, to prze­pro­wa­dze­nie badań, wypro­wa­dze­nie wnio­sków i uję­cie ich w posta­ci mode­lu bada­ne­go zja­wi­ska twier­dząc, że tak wła­śnie jest”. Tu nie wystę­pu­ję poję­cie dowo­du, zna­ne z mate­ma­ty­ki ale uzna­je się, że dopó­ki model w odpo­wie­dzi na rze­czy­wi­ste bodź­ce daje zgod­ne z rze­czy­wi­sty­mi (obser­wo­wa­ne w rze­czy­wi­sto­ści) odpo­wie­dzi, jest uzna­wa­ny za pra­wi­dło­wy. W takim przy­pad­ku to nie autor posta­wio­nej i popar­tej fak­ta­mi i mode­lem hipo­te­zy, musi udo­wad­niać jej pra­wi­dło­wość, ale opo­nen­ci muszą wska­zać bodziec dają­cy inny niż rze­czy­wi­sty sku­tek, by tę tezę obalić.

Tak się postę­pu­je w sytu­acji gdy zło­żo­ność bada­ne­go przed­mio­tu jest nie do ogar­nię­cia”, a do takiej kate­go­rii nale­żą nie tyl­ko wie­dza huma­ni­stycz­na, ale tak­że rynek, zarzą­dza­nie i pro­jek­to­wa­nie opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go to zarzadzanie.

Oczekiwanie więc, że coś w pro­jek­cie (mode­lu pro­duk­tu) nale­ży udo­wod­nić jest moim zda­niem błę­dem. Proszę zwró­cić uwa­gę np. na psy­cho­lo­gię. Stawia się hipo­te­zy dot. dzia­ła­nia ludz­kie­go mózgu, budu­je się jego mode­le kon­tek­sto­we (inne dla zja­wi­ska pamię­ci, inne dla wzro­ku czy słu­chu). Modele te są uzna­wa­ne jako praw­da tak dłu­go jak tłu­ma­czą mecha­nizm obser­wo­wa­ne­go zjawiska.

Skupienie się więc na mate­ma­tycz­nym dąże­niu do dowo­dze­nia, w sen­sie jakie­goś wzo­ru, jest moim zda­niem błę­dem. Prosty przy­kład, mnie szcze­gól­nie iry­tu­ją­cy a tu nie raz oma­wia­ny. Podpis czło­wie­ka łatwo pod­ro­bić, pod­pis elek­tro­nicz­ny prak­tycz­nie nie. Dlaczego? Bo inży­nier­ski umysł uznał, że zamien­ni­kiem pod­pi­su odręcz­ne­go będzie nie­da­ją­ca szan­sy pod­ro­bie­nia tech­no­lo­gia – typo­wy przy­kład lep­sze wro­giem gor­sze­go”. Osiągnięty obec­nie efekt ryn­ko­wy to zigno­ro­wa­nie pod­pi­su elek­tro­nicz­ne­go i to nie dla­te­go, że nie daje szan­sy” pod­ró­by ale dla­te­go, że jest za dobry i przy tym zbyt kosztowny.

Tak więc nie praw­dą jest moim zda­niem, że nale­ży udo­wod­nić cze­goś, by to uznać za dobre”. Są rze­czy, któ­rych nie da się dowieść, co nie zna­czy, że (te mode­le) są złe i nie nale­ży ich uży­wać. W samej mate­ma­ty­ce mamy np. twier­dze­nie Fermata, nie ma mate­ma­tycz­ne­go dowo­du ale nadal nie zosta­ło obalone…

Inny przy­kład, z moje­go podwór­ka i przy oka­zji będą­cy czę­sto przed­mio­tem spo­ru i z pro­gra­mi­sta­mi i z pra­cow­ni­ka­mi ich klien­tów. Jeżeli two­rzę model pro­ce­so­wy orga­ni­za­cji i wypro­wa­dzam z nie­go wyma­ga­nia na opro­gra­mo­wa­nie nie muszę niko­mu udo­wad­niać, że to dobry model (model pro­ce­sów, któ­ry tak na praw­dę opi­su­je jak zacho­wa się mode­lo­wa­na orga­ni­za­cja w odpo­wie­dzi na zada­ne zda­rze­nie np. gospo­dar­cze). Osoba uwa­ża­ją­ca, że ten model jest zły musi wska­zać sytu­ację (zda­rze­nie), w któ­rej ten model da nie­praw­dzi­wy wynik (efekt, zda­rze­nie) by zane­go­wać go jako model tegoż zja­wi­ska (tu orga­ni­za­cji). I tak wyglą­da obro­na” wyni­ków ana­li­zy: albo jest nie­pod­wa­żal­na albo jest zła.

W jed­nej z ksią­żek z obsza­ru psy­cho­lo­gi (PODSTAWY KOMUNIKACJI SPOŁECZNEJ Griffin Em) zawar­ta jest cie­ka­wa teza: bada­nia i naukow­ców moż­na podzie­lić na dwie grupy:

1. inte­pre­ta­cjo­ni­ści (induk­cja),

2. bada­cze sys­te­mo­wi (deduk­cja).

Ci pierw­si to ludzie, któ­rzy bada­jąc zja­wi­sko wyko­nu­ją dzie­siąt­ki, set­ki a nie raz i tysią­ce pomia­rów (ankiet) twier­dząc, że to one (te bada­nia) potwier­dza­ją, swą duża ilo­ścią praw­dzi­wość twierdzenia”.

Ci dru­dzy to ludzie, któ­rzy bada­ją (obser­wu­ją) zja­wi­sko tyl­ko tyle razy, by móc posta­wić tezę wyja­śnia­ją­cą w posta­ci mode­lu tego zja­wi­ska. Model jest uzna­wa­ny za popraw­ny tak dłu­go, jak dłu­go zacho­wu­je się” tak jak bada­ny przedmiot.

Różnica pole­ga na tym, że inte­pre­ta­cjo­nizm to tyl­ko bada­nie histo­rii, na pyta­nie o coś nie­zna­ne­go z histo­rii a co będzie gdy” inter­pre­ta­cjo­ni­sta odpo­wie to trze­ba zba­dać”. Jest tak dla­te­go, że inte­pre­ta­cjo­nizm pozwa­la co naj­wy­żej odpo­wie­dzieć na pyta­nie z jakim praw­do­po­do­bień­stwem histo­ria się może powtórzyć.

Na to samo pyta­nie badacz sys­te­mo­wy (meto­da nauko­wa) odpo­wie pro­gno­zą pole­ga­ją­cą na tym, że potrak­tu­je stwo­rzo­ny model tym czymś” z pyta­nia i powie jak zare­ago­wał model i jaką da odpo­wiedź nawet wte­dy gdy będzie to nowy bodziec nie zna­ny z histo­rii (co jest prze­wa­gą deduk­cji nad indukcją).

Jaka jest tu róż­ni­ca? Ci pierw­si zawsze zada­ją pyta­nie kto prze­pro­wa­dził bada­nie potwier­dza­ją­ce to co mówisz” (moim zda­niem nie zawsze mają­ce sens bo np. jak fir­ma wdra­ża jakieś opro­gra­mo­wa­nie to robi to pierw­szy raz i tyl­ko mode­le dają szan­se odpo­wie­dzi co będzie gdy…) Ci dru­dzy zaś, ana­li­ty­cy sys­te­mo­wi, sto­su­ją­cy nauko­we meto­dy, potra­fią z dużym praw­do­po­do­bień­stwem przewidywać.

Są np. takie dzie­dzi­ny jak kur­sy akcji i tu jest moim zda­niem przy­kład poraż­ki inter­pre­ta­cjio­ni­stów: ana­li­za tech­nicz­na (typo­we bada­nia inte­pre­ta­cyj­ne) nie uczy­ni­ła z niko­go boga­cza. O czym to świad­czy? O tym, że sys­te­my gospo­dar­cze są zbyt zło­żo­ne by tak je badać, tak­że o tym że dłu­go jesz­cze będzie to lote­ria (w kate­go­riach ryn­ku spe­ku­la­cji czy­li krót­kich inwe­sty­cji). Można jed­nak rozu­mie­jąc mecha­nizm zja­wi­ska spo­łecz­ne­go i makro­eko­no­micz­ne­go prze­wi­dy­wać pew­ne zacho­wa­nia, i tu dosko­na­łym przy­kła­dem jest np. pra­wo (mecha­nizm) popy­tu i podaży.

Użytkownicy rów­nań, wzo­rów, regu­łek i algo­ryt­mów mają inkli­na­cję do wyobra­ża­nia sobie tak­że życia spo­łecz­ne­go jako pod­le­ga­ją­ce­go koniecz­nym pra­wom, mecha­ni­zmom i tech­ni­kom, co czy­ni ich ? zda­niem Marthy Nussbaum – nie­bez­piecz­ny­mi dla demo­kra­cji oraz plu­ra­li­stycz­ne­go, otwar­te­go spo­łe­czeń­stwa wol­nych oby­wa­te­li. Kształcenie nasta­wio­ne na tech­ni­kę i biz­nes pro­du­ku­je ludzi, któ­rzy są kon­for­mi­stycz­ni, pokor­ni wobec wła­dzy i nie myślą kry­tycz­nie o pro­pa­gan­dzie, któ­rą im pod­su­wa­ją poli­ty­cy. Nie potra­fią też zro­zu­mieć cier­pie­nia i uczuć ludzi, któ­rzy się od nich różnią”.

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: