code

Loeng 13 · Arendus- ja muutusprotsessid infosüsteemides

Arendustöö tüüpskeeme

Põhimõisted: arendus ja iseareng; muutus ja seisund (olukord); dünaamika ja stabiilsus; ehitamine ja kasutamine.

Infosüsteemi uurimine ja hindamine. Milline on meie huvi?

Infosüsteeme uurima asu­des peak­sime kõi­ge­pealt selgitama, milline on meie hu­vi? Kas tahame väl­ja sel­gi­ta­da, kui­das in­fo­süs­tee­me ehi­ta­da (instrumentaalne huvi)? Või hu­vi­tab meid hoo­pis see, mil­li­sed val­mis ehitatud info­süs­tee­mid te­ge­likult on?—palju neid on? kuidas neid ka­su­ta­takse? milliseid tu­le­musi ka­su­ta­mi­ne annab, jne. Teaduskeele järgi—huvi ja vaa­te­nurk võib olla pres­krip­tiivne (kir­ju­tab ette, kuidas peaks olema) või deskriptiivne (kir­jel­dab, kuidas nähtus tege­likult on). In­fo­süs­tee­mide vallas anna­vad pres­k­rip­tiiv­sed ja desk­rip­tiiv­sed vaa­te­nur­gad tihti teineteisele vastu­rääki­vaid tule­mu­si. Info­süs­tee­mid ei toi­mi, ei lähe käi­ma nii nagu ka­van­datud. (Pea­aegu igaüks neist 60% eba­õnnestunud tark­vara­projektidest tähendab—eba­õnnes­tu­nud, mit­te­toimivat info­süs­tee­mi). Võime kõnelda kahte lii­ki tege­lik­ku­sest—info­süs­tee­mid, nii na­gu need on kavandatud; info­süsteemid sel­lis­te­na, nagu need kujunevad tegelikus kasu­tuses.

Instrumentaalne huvi ei ole piisav

Info­süs­tee­mi­de arendajate—nen­dest enamik liigitavad end vahest IT ini­mes­teks (aga on ka juh­te, äri ja eri­nevate alade spetsialiste)—huvi infosüsteemide vas­tu on eel­kõi­ge instrumen­taal­ne. Küsi­mus püs­ti­ta­tak­se nii: kuidas te­ha info­süs­tee­mi? _Tunduvalt har­vem—_ kuidas ole­mas­olev süsteem toi­mib (ei toi­mi)? Kui­das süsteemi paremaks teha? Vajame ka in­fo­süs­tee­mide ole­mu­se ja toi­me sea­dus­pä­ra­sus­te mõist­mist. See aga eeldab süsteemi te­ge­mise huvi­posit­si­oo­nilt teatud eemal­du­mist, vaat­lust ning mõ­tes­ta­mist—Mis on in­fo­süs­tee­mid? Kui­das nad toimi­vad? Miks info­süs­tee­mid sa­ge­li ei toimi?

Protsesside tsüklilisusInfokäitlustsükkel

(information management cycle, information pro­ces­sing cycle) Info töötluse ja kasutuse operatsioonide ajaliselt järjestatud kogum; kindla eesmärgi saavutamiseks teostatud infokäitlusoperatsioonide jada. Infokäitlustsükkel annab harilikult protsessi küllaltki kõrge abstraktsiooniastmega kirjelduse.

Mõningaid tuntud infokäitlustsükleid:

Kon­kurentsiluure infokäitluse tsükkel (business intelligence cycle)

1. Otsustamine millist infot koguda (deciding what to collect)

2. Info kogumine (collecting the information)

3. Info töötlemine (converting information into intel­ligence)

   • Korrastamine ja koondamine (collating)

   • Kataloogimine (catalogueing)

   • Ühendamine muu infoga (integrate with other pieces of information)

   • Analüüs (analyze)

   • Tõlgendamine (interpret)

4. Edastamine ja esitamine (communicating the intelligence)

Luureinfo käitlustsükkel (intelligence cycle)

Big6™ infokäitlusmudel

1. Ülesande püstitamine (task definition)

   • Infoprobleemi määratlemine

   • Infovajaduse määratlemine

2. Infootsingu strateegia valimine (information seeking strategies)

   • Võimalike infoallikate väljaselgitamine

   • Paremate infoallikate väljavalimine

3. Info leidmine ja ligipääs (location and access)

   • Allikatele minek

   • Info kättesaamine infoallikatest

4. Info kasutamine (use of information)

   • Info otsene kasutamine (lugemine, kuulamine jms)

   • Vajaliku info väljavõtmine

5. Süntees (synthesis)

   • Kokkupanek mitmetest allikatest

   • Info esitamine

6. Hindamine (evaluation)

   • Saadud tulemi hindamine (effectiveness)

   • Läbitud protsessi hindamine (efficiency).

Infosüsteem kiiresti muutuvas keskkonnas

Infosõda (information warfare) Vaenutegevus, milles vastaste ja nende ressursside füüsilise kah­ju­tuks­tegemine liigub tähtsuselt tagaplaanile, loovutades koha mit­me­su­gus­tele sõjalistele infoope­rat­sioonidele (infor­mat­ion operations). Infooperatsioonide hulka kuu­lu­vad: info kogumine vastase, kolmandate osa­poolte ning konf­lik­ti keskkonna kohta; kogutud info ana­lüü­si­mine jm tööt­lus; vastase in­fo­tööt­lus­süs­tee­mi­de rivist välja või ek­siteele viimine; oma in­fo­süs­tee­mide kait­se; vas­tas­poo­le, meedia ning avalikkuse suu­natud teavitamine, jt.

Olukorra tunnetuspilt (situational awareness) Ko­gu­tud luureinfo alusel loo­dud tervikpilt olukorrast ning sel­le arenemise võimalustest. Olukorra tun­ne­tus­pilt on eelduseks tegevuse plaanimisele.

Infosüsteem kui organism

Teiste kuvandite kõrval on mõeldav ka ettekujutus in­fo­süsteemist kui “elus­or­ga­nismist”. See mõte võib esmapilgul tunduda praktikast üpris kau­gel olevana. Kuid siiski—ideaalne süsteem peaks olema ju intelli­gent­ne; intelli­gents aga, vähemalt praegu veel, on inimese atribuut. Kogu tehis­intellekt (ar­vuti- ja süs­tee­miteaduse haru) koos oma mit­me­su­gus­te teh­ni­ka­tega (närvivõrgud, hägusloogika (fuzzy logic) kuni Micro­soft’i Intellisense’ini) on üles ehitatud võrd­lu­se­le inimese mõis­tu­sega. Kui kohtame info­süs­tee­mi kom­po­nentide seas intelligentseid agente, siis võime öelda, et kasutatud on elu metafoori. Elu metafoori ka­su­tatakse organisatsiooni- ja juh­ti­mis­tea­dus­tes. Vä­ga kõrgelt on hinnatud de Geus’i (1997) kä­sit­lust ette­võt­test kui elus­orga­nis­mist.

Mida võib anda elusorganismi metafoor? Kui vaat­le­me uurimis­ob­jek­ti elus­or­ga­nis­mi­na, siis mil­li­seid pa­ral­leele otsime? Mis on elus­orga­nis­mis ise­loomu­lik­ku, mida metafoorilises võrdluses ka­su­tada? Sise­struk­tuu­ri osas—spet­sia­liseerunud, kuid tihedas koos­töös toimivate orga­ni­te arhi­tek­tuur; vä­lis­struk­tuuri osas—kuuluvus öko­loo­gilistesse koos­lus­tes­se, ko­ha­nemise fun­da­men­taal­ne idee; dü­naa­mi­ka osas—sta­diaalne elu­käik. Ning muidugi—elus­olek, ener­gia, DNA, geenid, elu kui prot­sess. Int­ri­gee­ri­vad on vii­ma­sel ajal ilmunud artik­lid orga­ni­satsiooni “ener­giast” (Bruch & Ghoshal, 2003; Cross et al, 2003). Ilmselt on energia mõiste mingil määral rakendatav ka info­süs­tee­mis.

Produktiivsed ideed joo­nistuvad kohe välja. Ette­võt­tel on oma elu­käik; tark­va­ra—ning viimasel ajal ka riistvara—puhul laialt kasutatav elukäigu (life cycle) mõiste ei ole ju midagi muud, kui elu metafoori ka­sutamine. Ettevõte peab “toituma”; infosüsteem peab nor­maalseks toi­mi­miseks saama (si­send)infot. Vrdl uus internetitehnoloogia RSS—”RSS Feed” on vaa­del­dav toimumise me­ta­foorina. Infosüsteemid tarni­vad infot üks­tei­sele—A väljundit kasutab B, vii­mase väljundit oma­kor­da C. Kasutada saab toi­tu­mis­ahe­la ja metabolismi mõisteid (tähtis on jääkinfo kiire väljutamine organismist), kanda üle mõisteid ja vaat­lus­võtteid ökoloogiast jne. Vt siiski kriitilist diskussiooni ökoloogia mõis­te­süs­tee­mi ülekandmise prob­lee­mi­dest äristrateegiate ana­lüü­si valdkonda (Okey, 2004).

Iseorganiseeruvad infosüsteemid

Pal­ju­de­le elus­olen­di­tele ja nende koos­lustele on ise­loo­mu­lik tugev ise­organiseerumise võime. Info­süs­tee­mi pu­hul on sõ­nasta­mata eelduseks, et info­süsteem on loodud (välja töötatud) kel­le­gi poolt (läbinud kind­lat ees­märki omanud aren­dus­-, mitte aren­gu­prot­sessi). Kas on mõ­tet rääkida ka ise­enes­likult (il­ma sihipärase aren­dus­tegevuseta) ku­ju­ne­nud info­süs­tee­mist? Par­nas (1986) juhtis esimesena tä­he­le­pa­nu sellele, et süs­teemiarendajatel on tendents esitada süs­tee­mi­aren­dust kui ratsionaalset prot­sessi, kuigi ei saa rää­ki­da sirgjoonelisest, lähteülesandega determineeritud aren­dusprotsessist. Ka mitmed uue­mad aren­dus­mee­to­did (Extreme Programming jt) pi­gem üri­ta­vad an­da loomulikule, suuresti ettemääramatule aren­dus­protsessile amet­liku meetodi vormi ja legi­tiim­sust, vabastada seda kit­sen­davatest har­ju­mus­test ja te­oo­ria­test—kui aren­dus­protsessi “kehtestada”. Vrdl mõiste “or­ga­ni­sat­si­oo­ni strateegia” arenguga. Tra­dit­si­oo­ni­line vaade on olnud—strateegia on määratud ju­hi tahte ja otsu­se­ga (deliberate strategy) ; uuem sei­su­koht (Mintz­berg) on—strateegia kujuneb dü­naa­mi­liselt, paljude te­gu­ri­te mõjutusel (emergent strategy).

Ise­or­ga­niseeruvate süsteemide vastu on huvi vii­ma­sel ajal tõusnud—kas see võib hakata avaldama praktilist mõju info­süs­tee­mi­de aren­du­sele? Üks uu­ri­mis­suund ammutab ideid elusloodusest: üri­ta­tak­se kont­sep­tua­li­see­ri­da teatud elus­süs­tee­mi­de (si­pel­ga­te, termiitide kooslused) toi­mi­mis­print­sii­pe, loo­tu­ses saada malle iseorganiseerumist ka­su­ta­va­te juhtimis- ja ka arvutisüsteemide ehita­mi­seks (Ticoll, 2004). Tei­ne uurimissuund püüab lahti mõ­tes­ta­da juba tek­ki­nud iseorganiseerumise (või vä­he­malt de­tsent­ra­li­see­ritud juhtimise) ele­men­te ka­su­ta­vaid äri- ja ar­vu­ti­süsteeme. Näiteks uuritakse va­ba­vara aren­dus­mee­to­deid—miks Linux’i aren­dus­prot­sess toimib nii edukalt? Millest tekib ise­or­ga­ni­see­ru­misvõime? Paind­likkus ja are­nemine on võimalik ainult süs­tee­mis, milles on õnnestunud ühitada or­ga­nisatsioon (or­ganisee­ri­tus) ja kaost.

Infosüsteem organisatsioonilises kontekstis

Iga süsteemi, sealhulgas info­süs­teemi, uuri­mi­ne saab kulgeda kah­te liini pidi. Esiteks, võib minna süsteemi sis­se. Peamised küsimused on siis: Mil­listest ele­men­tidest süs­teem koos­neb? Kuidas ele­men­did on üks­tei­sega seotud? Mil­­li­ne on süsteemi struk­tuur (arhi­tektuur)? Kuidas süsteem funkt­sio­neerib? Teine võimalus on vaadata kesk­kon­da, konteksti, milles süs­teem toi­mib. Pea­mi­sed küsi­mused on sel juhul: Milline on süsteemi ümb­rus? Millised nõu­ded kesk­kond süs­tee­mi­le seab? Millist funkt­siooni süs­teem oma keskkonnas täi­dab? Info­süs­teemi ei saa vaadata la­hus or­ga­ni­sat­si­oo­ni kon­teks­tist.

Organisatsioon on info­süs­teemi jaoks nn ülemsüsteem (super­syst­em), info­süs­teem on vaa­del­dav organisatsiooni suh­tes alam­süstee­mina (sub­system). Kuid ka orga­ni­sat­sioonil on oma ümb­rus. Or­ga­ni­satsioon või ette­võte on mõ­ju­tatud oma kesk­konnast, mil­le mõju ula­tub kahtle­mata ka info­süs­tee­mi­ni. Ettevõtte kon­ku­rent­si­seisund ja majan­dus­ha­ru teh­noloogiline areng mõ­ju­tavad olu­li­selt se­da, mil­li­seid info­süsteeme ette­võ­te ot­sus­tab ehitada. Selle tõt­tu on ots­tar­be­kas mu­de­lit täius­tada, lisa­da ise­seisva ele­mendina orga­ni­sat­si­oo­ni kesk­konna.

Kaardistanud info­süs­tee­mi ülem­süs­teemi ja ülem-ülem­süs­tee­mi, ilm­ne­vad mit­med olu­li­sed küsi­mu­sed: Kui­das info­süs­teem sobi­tub (fit) or­ga­nisat­si­ooni kui ter­vik­süs­tee­mi? Mis võimaldab et­te­võttel üldse info­süsteemi te­ha (mil­li­seid eeldusi ja tingi­musi on vaja)? Kas info­süs­tee­mi õnnes­tumiseks pii­sab ainult tööst süs­tee­mi kal­lal—või on va­ja muu­ta mida­gi ka süs­tee­mi kesk­konnas? Milli­ne on info­süs­teemi pa­nus or­ga­ni­sat­si­ooni edu­kus­se? Kas info­süs­teem on nn stra­tee­gi­li­se täht­su­sega; või on on in­fo­süsteem ai­nult äri­prot­ses­si­de toeks? Küsi­mu­si tekib pal­ju; nende süste­maati­liseks käsit­lemiseks on mõtet mude­lit täien­da­da.

Organisatsiooni seisukohalt on mõtet alus­tada küsimusest: Mil­leks organi­sat­si­oo­nid teevad info­süs­tee­me? Loodetakse, et info­süs­tee­mi kasutamine aitab or­ga­nisat­si­oo­nis infokäitlust pare­mi­ni, efektiiv­se­malt teha, tõstab tööviljakust, aitab rohkem kliente tee­nin­dada, jne—kokkuvõttes annab majandus­likku efekti. Näeme, et infosüsteem peab tegema päris mitut asja, and­ma mit­me­sugust efekti. Kahjuks kõik need lootused alati ei täitu.

Esimeseks efek­tiks, mida info­süs­teem an­nab (kuid mi­da ena­masti efek­­tina tä­he­le ei pan­da), on info­süsteemi ka­su­ta­mine (või mit­te­ka­su­ta­mi­ne, mitte­plaa­ni­tud ka­suta­mine, igno­ree­rimine, sa­bo­taazh). Info­süs­tee­mi ka­su­ta­mi­ne on mitme­ta­hu­line mõis­te. Kui süsteemi kasu­ta­tak­se, siis on küsimus selles, kui­das süsteemi kasu­tatakse—millal, kes, millisel ees­märgil jne. Süsteem või­dakse kasu­tada teisiti kui plaani­tud viisil (vahel positiivsete, va­hel ne­ga­tiiv­sete taga­järge­de­ga).

Teiseks, süsteemi kasutamine teki­tab finantstulemuse, mõju­tab töö­ta­jaid, kes süsteemi ka­su­ta­vad; sa­mu­ti võib mõjutada teiste süs­tee­mi­de arengut orga­ni­sat­sioonis. Kol­man­daks, süs­­tee­mi kasu­ta­mi­ne toob kaa­sa koha­ne­misi, muu­tu­si nii ko­gu organisatsioonis kui ka süs­teemis endas. Info­süs­tee­mi mõ­ju or­ga­ni­sat­si­oo­ni­le aval­dub pikema aja jook­sul, orga­ni­sat­siooni ja info­süs­teemi inter­aktsiooni käi­gus.

Infosüsteemi (kõrval)efektid

Tra­dit­si­oo­ni­liselt mõistetakse info­süs­­teemi efekte järg­mi­selt: infosüsteemil on üks ka­su­tus­ees­märk–info­tööt­luse (laias mõttes) kor­­ral­damine; lisaks on infosüsteemil mit­me­su­gu­­seid (kõrval)efekte. Infosüsteemi ka­sutamise ees­märk on teatud info­tööt­lus­ope­rat­si­oo­ni­de teos­­ta­mi­ne, kuid lisaks sellele avaldab info­süs­teem veel mit­me­su­gust mõju or­ganisatsiooni eri­ne­vatele ele­men­ti­dele ja as­pek­ti­de­le. Info­süsteemi kasutamise kõr­valefektidena toi­mu­vad organi­sat­si­oo­nis mit­mesugused, eri­neva ulatusega muu­tu­sed. Need mõ­jud, muutused ja efektid on harilikult ette­plaa­ni­ma­ta ja reeg­lina eba­soo­vi­ta­vad.

Organisatsiooni ele­men­tidest eris­ta­me sel­les mudelis viit: or­gani­sat­si­ooni stra­teegia, or­ga­nisatsiooni struk­tuur, äri­prot­sessid, or­ga­ni­sat­siooni kultuur ja IT infrastruktuur.

Skeem infosüsteemi kontekstu­aal­seks analüüsiks

Süsteemi struktuur

1 Infosüsteemi struktuur Infosüsteemi arhitektuur, tehnoloogilised lahen­du­sed, omadused, jõudlus jm.

Süsteemi kasutamine

2 Süsteemi kasutamine Infosüsteemi plaanitud ja tegelik kasutamine.

Süsteemi seos organisatsioonilise keskkonnaga

3 Strateegia Millised on organisatsiooni tegevuse eesmärgid, valikud, te­ge­vuse filosoofia jne? Millised strateegia elemendid omavad süsteemi tege­mi­se seisukohalt tähtsust?

4 Organisatsiooni struktuur Milliseid allüksusi ning inimesi süsteem hakkab puutuma?

5 Äriprotsessid Milliseid äri- ja tööprotsesse loodav süsteem on mõeldud toe­tama? Kas ja kuidas neid protsesse mõistetakse? Mida nendest prot­ses­sidest on teada? Millised probleemid on protsessidega? Mida tahetakse pa­re­maks teha?

6 Kultuur Millised on organisatsiooni kultuuri elemendid, mis omavad süs­tee­mi õnnestumise seisukohalt tähtsust?

7 IT infrastruktuur Milline on organisatsiooni infotehnoloogiline keskkond? Millised alusvõrgud, serverid, ühendused on kasutatavad? Milliseid teh­no­loogiaid süsteemis plaanitakse kasutada? Millised on tei­sed, olemas­olevad või paralleelselt arendatavad süsteemid? Kui palju ja kui­das tuleb lii­des­tu­da või lõimuda teiste süsteemidega?

8 Arendusprotsess Millist arendusmeetodit kasutatakse? Kas arendatakse oma jõududega või ostetakse sisse? Kuidas plaanitakse korraldada süs­tee­mi han­ge? Eelarve jms.

9 Organisatsiooni keskkond Millised olulised muutused on toimumas ja ette näha süsteemi tegevuskeskkonnas? Kas ja kuidas need muutused omavad tähtsust süsteemi tegemise seisukohalt?

Süsteemi mõjud ja efektid

10 Mõju strateegiale Kuidas loodav süsteem hakkab mõjutama orga­ni­sat­si­oo­ni strateegiat?

11 Mõju organisatsiooni struktuurile Kas ja milliseid muutusi toob süsteem kaasa töökohtade struktuuris?

12 Mõju äriprotsessidele Milliseid muutusi ja ümberkorraldusi toob loodav süsteem kaasa organisatsiooni äri- ja tööprotsessides?

13 Kultuurilised muutused Millist kultuurilist muutust on vaja süsteemi käi­vi­tamiseks ja tööshoidmiseks? Milliseid kultuuri arenguid võib prog­noo­si­da?

14 Mõju IT infrastruktuurile Milliseks täienduseks on loodav süsteem orga­ni­satsiooni IT maastikule? Milliseid teisi süsteemi saab loodava süsteemi põhjal tulevikus välja arendada? Kuidas süsteem mõjutab teisi olemas­ole­vaid ja arendatavaid infosüsteeme?

15 Mõju konkurentsipositsioonile Kuidas süsteem aitab organisatsioonil toi­me tulla organisatsiooni keskkonnas?

16 Infosüsteemi muutused kasutamise käigus (Retrospektiivselt) Kuidas in­fo­süsteem on kasutamise käigus muutunud? Milliseid veaparandusi ja täien­dusi on tehtud? jne.

Juhtimise eesmärk

Juhtimise eesmärk on juhitavas objektis leiduvate võimaluste, potentsiaali maksi­maalne ava­mi­ne ja ärakasutamine. Märksõnadena võib nimetada:

° tulemuslikkus (väline efektiivsus)

° efektiivsus (väline efektiivsus)

° kumulatiivsus

° tasakaalustatus

° seostatus

° kohanemine

° olukorra tunnetamine, ärakasutamine, kontroll.

Süsteemset käsitlust tasub ra­ken­da­da ka infosüsteemi juh­ti­mi­se (arenduse, hil­jem hool­duse) süsteemi tegemisel.

Infosüsteemi juhtimissüsteemi ülesehituse põhimõtted

Infosüsteemi organi­sat­siooniline kontekst võib olla kir­jeldatud mit­me­su­gus­tes dokumentides (stra­tee­gi­ad, kontseptsioonid, põhikirjad ja põ­hi­mää­ru­sed, seadused, käsk­kir­jad, memod jne.) Kogu materjal, mis infosüsteemi aren­dusele mõju avaldab, tuleks identifitseerida ja süstematiseerida. Ees­ku­ju­dena võib häid ideid saada kasvõi mõnede aren­­dus­mee­to­di­te ja -raa­mis­ti­ke struktuurist. Paistab, et suh­te­li­selt suu­re infohulga kergesti aru­saa­da­vaks ja ka­su­ta­tavaks tegemiseks ei ole paremat moodust kui hierarhiline esi­tus (ka arvutisüsteemid on or­ga­ni­see­ri­tud abstraktsioonitasandite kau­pa).

Infosüsteemi olemasolust ei tu­le­ne veel süsteemi kasu­ta­mine

Rat­sio­naal­selt mõeldes ei tohiks info­süs­tee­mi­de kasutamine (õigemine mitte- või vaeg­kasu­ta­mine) olla üldse prob­lee­miks. Kui süsteemi läh­te­ülesanne on õi­ges­ti püstitatud ja süsteem on kom­pe­tentselt koos­tatud, siis võiks ju oo­da­ta, et süsteemi leiab ka plaa­ni­tule vastavat kasuta­mist. Tegelikkus on kee­ru­li­sem. Üksikisiku ta­san­dil on tä­hel­datud, et pal­jud inimesed os­ta­vad en­dale mood­said elekt­roo­ni­li­si per­so­naal­seid info­tööt­lus­seadmeid (or­ga­ni­zer’id, pihu­ar­vu­tid, kaamerad jm), millest osa ka­sutus jääb vähe­seks. Kas kõik koju os­te­tud tervise­spordi­va­hen­did leiavad plaa­nitud ka­su­tamist? Kas kõik os­te­tud di­eedi (tervisliku toi­tu­mi­se) “süsteemid” võe­tak­se ka­su­tu­sele? jne.

Teisest küljest—kasu­tu­sel võib olla süs­teeme, mil­le olemasolust teavad ainult kasutajad ise. Info­süs­tee­mi kasu­tu­se mõõtmine on kül­lalt­ki komp­lit­seeritud prob­leem. Kui mida­gi arvuti abil tehakse, siis on reeg­lina hõlbus regist­reerida toimingu liiki, aega ja teisi parameetreid. Info­süs­teemi enda va­hen­ditega võib saa­da päris korraliku kvanti­ta­tiiv­se üle­vaa­te in­fo­süsteemi tege­li­kust kasuta­mi­sest. Mida info­süs­teem aga ei re­gist­ree­ri, on kasutaja mõt­ted, ar­va­mus ja emot­sioonid süsteemi kasuta­mi­sel. Ka­su­tusnivoo väl­ja­sel­gita­mi­ne logide, info­süs­tee­mist saadava sta­tis­ti­ka jms abil ei anna ko­gu infot, mida süsteemi ka­su­ta­mise kohta ta­hak­sime saada. Sageli on ob­jek­tiiv­se info kogumine infosüsteemi kasu­ta­mi­se kohta pii­ra­tud eetiliste ja jurii­di­liste takis­tustega.

Vajame infot infosüsteemide kohta

In­fo­süs­tee­mi­de uurimiseks va­ja­me mitmesugust infot in­fo­süs­tee­mide enda kohta. (Info info­süs­tee­mi koh­ta on kä­si­tatav me­tainfona). Selle info ko­gu­mine on aga võrd­le­misi töömahukas.

Infosüsteemide kaardistamine

Kas iga or­ga­nisatsioon teab, mil­liseid info­süs­tee­me or­ga­ni­sat­si­oonis ka­su­ta­tak­se? Eesti riigis on loo­dud and­me­ko­gu­de register (sisuliselt info­süs­teem arve­pida­mi­seks in­fo­süs­teemide kohta). Teada on projekte, kus ette­võ­te on kaardistanud oma info­süs­tee­mid. Raskus te­kib siis, kui süsteem koos­neb pal­ju­dest moo­du­li­test, mi­da käsitatakse iseseisvate rakendustena või süs­tee­mi­dena. Kir­jan­du­sest on leida mitmeid näiteid, kus ette­võte on kao­ta­nud üle­vaa­te ka­su­tatavate info­süs­tee­mi­de kohta. Herbold (2002) kir­jel­dab info­süs­tee­mi­de maastiku “vo­ha­mist” seoses ettevõtte kiire kas­vu­ga, üle­vaat­lik­kuse ka­ha­nemist, infosüsteemide konsolideerimist väi­ke­seks ar­vuks süs­tee­mi­deks. Arvestus muu­tub tun­du­valt kee­ru­kamaks, kui mit­te piir­duda organi­sat­si­oo­ni­siseste infosüsteemi­dega, vaid püüda saada üle­vaa­det ka välistest või ühistest infosüsteemidest, mi­da orga­ni­sat­sioon ja selle töö­ta­jad kasu­tavad. Üle­vaa­de kasuta­ta­va­test info­süs­tee­mi­dest on ka­su­lik tur­va­ana­lüüside lä­bi­vii­mi­sel, aga samu­ti nii äri- ja töö­prot­ses­si­de pa­ren­da­mi­sel kui ka IT kesk­kon­na tehnilise toimivuse pa­ren­da­misel. Ideaal­seks üle­vaateks võiks olla ette­võtte info­süs­tee­mi­de täielik kaart. In­fo­süsteemide “in­ven­ta­ri­see­ri­mine” on ku­ju­nemas üld­tun­nus­tatud va­ja­du­seks.

Süsteemi haaramine pole kerge

Üks raskuste põh­jusi on ka sel­les, et süs­teem on alati mi­da­gi roh­ke­mat, kui komponentide sum­ma. Täht­sad on nii komponendid, nen­de komponentide ühen­da­mi­se viis ning ka süs­teemi keskkond.

Head süsteemi on raske teha – ka raske näha

Häs­ti toimiva süs­tee­mi edu võtit ei ole kerge mõis­ta. Kerge ei ole ka mõista, miks süs­teem ei toi­mi. Just-in-time tootmis­süsteemi leiutaja T.Ohno on mär­ki­nud, et kan­ban süsteemi juuru­ta­mine Toyota au­to­tehases võt­tis kümme aastat. In­fo­teh­noloogiliselt on kanban süsteem pri­mi­tiiv­ne—minimaalse info­si­suga papp­kaardi­ke­si kasutatakse toot­mis­ette­võt­tes all­ük­sus­te töö teatud vii­sil koordi­neerimiseks. USA uu­ri­jad Bowen ja Spears (1999, 2004) leidsid, et Amee­ri­ka ette­võt­ted, kes uuri­sid vä­ga põhjalikult Toyota toot­mis­süs­teemi, soovides se­da oma tehastes ra­ken­da­da, ei suutnud pikka aega mõista süs­tee­mi ole­must. Nähti—ning püüti ole võt­ta süsteemi suh­te­li­selt pin­na­peal­seid atri­buu­te (kanban kaartide vorm jne), kuid see, et Toyota toot­mis­süs­teem sunnib töö­ta­jaid praktiliselt igas töö­prot­ses­si sammus eks­pe­ri­men­tee­ri­ma (nn väi­ke­sed eksperimendid), jäi pik­ka aega var­ju. Süsteemi toimivuse või mittetoimivuse põh­ju­si ei ole liht­ne leida.

Üks kasutaja ei tunne kogu info­süs­tee­mi

Kaks vaat­lejat, kes küsi­vad or­ga­nisatsiooni eri­ne­vatelt töö­ta­jatelt, mitu info­süs­teemi organisatsi­oo­nis on, saa­vad vastuseks tõenäoliselt erinevad ar­vud. Mis on sel­le põh­ju­seks? Tüü­pi­lises ettevõttes on vä­hes­tel töö­tajatel ülevaade kõi­gist ette­võt­te in­fo­süs­tee­mi­dest, isegi nende olemasolust. (Oluline kü­simus: kel­lel üldse on ülevaade ettevõtte kogu in­fo­süsteemide koos­lu­sest? Mis võib olla põh­ju­seks, et ettevõttel ei ole ülevaadet oma süsteemidest?) Info­süs­tee­mi­del on sa­ge­li palju kasutajaid, sealjuures kasutab iga ük­sik kasuta­ja tüü­pi­liselt ai­nult väikest osa infosüsteemi võima­lus­test. Sellest tule­neb kaks prak­ti­list prob­lee­mi: a) kasutaja vajab otseseks ka­su­ta­mi­seks ai­nult osa süs­tee­mi võimalustest, kuid süsteemi mõist­mi­seks ja õi­geks ka­su­ta­miseks ena­mat—üle­vaa­det süs­tee­mi arhi­tek­tuu­rist, kont­sept­si­oo­nist jms.; b) kasu­ta­jate tead­mine info­süs­tee­mi kui tervi­ku kohta on sa­ge­li lünklik, mis takistab süs­tee­mi efek­tiiv­set ka­su­ta­mist. Erinevatel kasu­ta­ja­tel on sageli eri­nevad huvid, tööharjumused, per­so­naalne stiil jms. Ühe kasutaja arva­mus annab ainult väga esi­algse pildi süs­teemi ole­mu­sest ja seisust.

Kas süsteemi uurimine üksi võib uuri­ta­vat süs­teemi muuta?

Idee, et ob­jekti kir­jel­da­mi­ne muu­dab ob­jekti, on kasutusel mitmel pool—or­ga­ni­sat­si­oo­ni­tea­duses, antropoloogias, kvant­füü­si­kas. J.Lot­man mär­gib, pidades silmas kultuurilisi fe­no­mene: “üks ja see­sama süs­teem võib olla luustunud või peh­me­ne­nud seisundis. Sel­le juures võib ainu­üksi kir­jel­da­mise fakt viia süsteemi ühest ole­kust teise.” Kas info­süs­tee­mi vaatleja peaks selle huvitava, pa­ra­dok­saalse nähtusega arvestama? Ilmselt küll; ja mitmel põh­ju­sel. Info­süs­tee­mi kon­teks­tis kasuta­tak­se kirjel­da­mist kahel ta­san­dil: 1) mo­del­lee­ri­ta­va “reaalsuse” kir­jel­da­mi­ne; 2) in­fo­süsteemi enda kirjel­da­mine (do­ku­men­tee­ri­mine, kasutuse kir­jel­da­mi­ne). Süs­teemi tege­mine ongi suu­rel määral kir­jel­da­mi­ne. Pärast ärakirjeldamist on objekt küll endine, kuid tema kon­tekst (kesk­kond) on muutunud.

Infosüsteemi hindamine

Vt mahukas kirjandus infosüsteemide auditeerimise kohta. Süs­tee­mi hinda­mi­se kiir­mee­to­di­te kohta vt. nt. Goodson (2002).

Infosüsteemide populatsioon

Väga oluline on vaadata infosüsteemi ka teiste infosüsteemide kon­tekstis. Piir­dun siin ainult esimeste huvipakkuvate küsi­mus­tega. Kah­juks ei suuda paljud ettevõtted nen­de­le küsimustele ra­hul­da­vaid vastuseid anda! Kas et­te­võt­tes on mi­tu info­süs­tee­mi? Mil­lal süs­tee­mid on tek­ki­nud? Mil­lises elu­faa­sis on süs­teem? Mil­li­se aren­dus­filo­soo­fia alusel süs­teeme aren­da­tak­se? Kui pikk on info­süs­teemi kesk­mine elu­iga? Kas süs­tee­me vahe­ta­takse sa­ge­li uute vastu väl­ja? Kui­das süs­tee­mid arene­vad? Kas et­te­võtte info­süs­tee­mi­de koos­lus on opti­maal­ne? Kas kõik olulised te­ge­vus­alad on info­süs­tee­mi­de­ga toe­ta­tud? Kas mõni olu­line infosüsteem on puu­du? Miks? Mil­lises jär­je­kor­ras info­süs­teeme aren­da­tak­se? Kas oleks ots­tar­be­kas omada mit­me väik­se­ma süsteemi ase­mel üht suurt, integreeritud in­fo­süs­tee­mi? Mil­li­ne on orga­ni­sat­siooni (majan­dus­ha­ru, riigi) info­süs­tee­mi­de maas­tik?

Infosüsteemid on üksteisega seostes

Suur­tel süs­tee­mi­del on ten­dents or­gani­see­ru­da alam­süs­tee­mi­de (ja ülem­süs­teemide) hier­ar­hi­liste seoste vor­mis. Info­süs­tee­mi osi (alam­süsteeme) võidakse see­tõt­tu ni­me­ta­da samuti info­süs­teemideks. Prob­lee­mid te­ki­vad siis, kui süs­teem ja alam­süs­teem kan­na­vad sama ni­me; või kui kaks erinevat süsteemi on teine­teise alam­süs­tee­mi­deks. Eksitusi tekitab ka see, kui in­fo­süs­teemi esi­mese taseme alam­süs­tee­me on kok­ku le­pi­tud ni­me­tada näi­teks moo­du­liteks, kuid sel­le kõrval on käi­bel ka terminid infosüsteem, prog­ramm, jne. Vahet tuleks teha ühe või teise ob­jekti juhusliku valesti nimetamise ja tegeliku süs­teemi puu­dumise va­hel. Va­hel näitab terminite info­süs­teem, moodul jt. kõikuv kasu­ta­mi­ne, et süs­tee­mi tegelikult ei olegi.

Süsteem on sageli osa suuremast süsteemist

In­fo­süs­teemide maas­ti­kus­se kont­septuaalse selguse too­mi­sel tundub produk­tiiv­ne ole­vat nn “süs­tee­mi­de süs­tee­mi” (system of systems) ideoloogia. Infosüsteemi võib ol­la liht­sam uu­ri­da koos teiste et­te­võt­te info­süs­tee­mi­dega.

Info­teh­no­loogiline maas­tik

Lokaalse optimumi oht

Lo­kaal­se optimeerimise oht on info­süs­tee­mi­de juu­res päris suur. Suh­teliselt _lihtne on teha süs­teem­ne, tõhus la­hendus _ühe, kind­lalt piiritletud tööprotsessi või lõigu jaoks. Ette­võt­te kui ter­vi­ku ta­san­dil avalduvad vahest ühed eba­meel­di­vamad info­süs­tee­mide probleemid mit­te nii­võrd ük­sikutes süsteemides eral­di, vaid:

• info­süs­tee­mi­de in­teg­ree­ri­mi­se probleemidena

• töötluses, mi­da oleks saa­nud vältida; nt süs­teemi A väljund on sisendiks süs­tee­mi­le B; kümme kor­da oda­vam oleks ol­nud seada A väljund sel­li­seks, na­gu B vajab; sel­le asemel tuli prog­ram­mee­ri­da süs­tee­mis B suu­res ma­hus—et töö­del­da sis­se­tulnud info va­ja­li­kule kujule

• funkt­si­oo­nide dub­lee­ri­mi­ses

• and­me­te üle­kand­mi­se ja teisenduste prob­lee­mi­des in­fo­süs­tee­mide välja­va­he­ta­mi­sel ja uu­te li­sa­misel.

Probleemid/harjutused

1. Infokäitlustsükli kindlakstegemine Vali mittetriviaalne tegevus või tegevusala ning selgita välja, kuidas selle tegevuse infotöötlust võiks väikeseks arvuks loogiliselt seotud etappideks (infokäitlustsükliks jagada). Tulemused: infokäitlustsükli skeem + selgitused.

Kirjandus

Burton, H., Pennotti, M. (2003) The Enterprise Map: A System for Implementing Stra­te­gy and Achieving Oper­ational Excellence. Engineering Management Journal, 15, 3, 15-20.

Bowen, H., Spear, D. (1999) Decoding the DNA of the Toyota Production System, Harvard Business Review, 77, 5, 96-106.

Bruch, H., Ghoshal, S. (2003) Unleashing Organizational Energy. Sloan Management Review, 45, 1, 45-51.

Cassidy A. (1998) A Practical Guide to Information Systems Strategic Planning. St. Lucie Press., Ch 4 Under­stand­ing and Communicating the Current In­for­mation Systems Situation.

CIA. Intelligence Cycle. www.cia.gov.

Competitor Analysis–A Brief Guide. www.marketing-intelligence.co.uk.

Cross, R., Baker, W., Parker, A. (2003) What Creates Energy in Orga­ni­za­t­ions? Sloan Management Review, 44, 4, 51-56.

Geus, A., Senge, P. (1997) The Living Company.

Goodson R. (2002) Read a Plant—Fast. Harvard Business Review, May 2002, 3-11.

Herbold, R. (2002) Inside Microsoft. Balancing Creativity and Discipline. Harvard Busi­ness Review, January 2002, 73-79.

Лотман, Ю. (1992) Динамическая модель семиотической системы. Избранные статьи, т. 1, Aleksandra, c. 98.

Newell, S. et al (2003) Imple­ment­ing enterprise resource plan­ning and knowledge manage­ment systems in tan­dem: fost­ering efficiency and innovation comple­ment­ari­ty. Infor­mat­ion and Orga­ni­zat­ion, 13, 25-52.

McFarlan, F., McKenney, J., Pyburn, P. (1983) The information archipelago—plotting a course. Harvard Business Review, 145-156.

Okey, T. (2004) Strategy as Ecology. Harvard Business Review, 82, 9, 132—Iansiti, M., Levien, R., vastus, samas välja­andes, 132-133.

Parnas, D. & Clements, P. (1986) A rational design process: How and why to fake it. IEEE Trans­actions on Software Engi­nee­ring, 12, 2, 251-257.

Spear, S. (2004) Learning to Lead at Toyota, Harvard Business Review, 82, 5, 78-86.

Ticoll, D. (2004) Get Self-Or­ga­nized. Harvard Business Review, 82, 9, 18-19.

CC BY-NC-SA 4.0 Priit Parmakson 2017