Infosüsteem kui Masin

 

 

Infosüsteemi võib käsitada kui masinat. See meh­ha­nistlik, loogiline, ja rat­sio­naal­ne ettekujutus in­fo­süs­teemi ole­mu­sest, ees­mär­gist ja süsteemi tege­misest on vahest kõi­ge lihtsamalt kokku võetav väi­tega: In­fo­süs­teemi üles­andeks on in­fo allikatest saadava info tööt­le­mi­ne info kasutajate poolt nõutud kujule (ja töö­del­dud in­fo kät­te­toimetamine). Info­süs­teem peab toi­me­tama info ko­gu­mise info­alli­katest, selle info säi­li­ta­mise, vaja­liku tööt­luse ning infot va­ja­vatele osa­pool­te­le info väl­jas­tamise.

Info allikateks võivad ol­la ini­mesed, teised süs­tee­mid, vaa­del­da­vad, re­gist­ree­ri­ta­vad või mõõ­de­ta­vad näh­tu­sed jne. Info kasu­tajateks on ini­me­sed (süs­tee­mi ka­su­ta­jad), aga ka tei­sed infosüs­tee­mid, teh­ni­li­sed sead­med jne. Info­süsteem ko­gub, säi­li­tab, tööt­leb, edastab ning esi­tab infot. See on hea liht­ne klas­si­ka­li­ne vaade, mil­le­ga saab teha tegusaid süs­tee­me. Sel­lis­te meetodite ajalugu on pikk. Esi­me­seks mee­to­diks, mis püüdis raken­da­da info kui masina põhi­mõ­tet ter­ve ettevõtte ulatuses, võib lugeda IBM'i mee­to­dit Business Systems Planning. Uue­ma käsitlusena vt nt Peak & Guynes (2003). Või­me seda ette­kuju­tust ni­me­ta­da ka ette­kuju­tu­seks in­fo­süsteemist kui ma­si­nast. Näidetena kuvandi "in­fo­süs­teem kui masin" rakendamisest vt nt Ballou et al (1998) "info­toot­mis­süs­teemi" mudel, Meyeri ja Zacki (1996) analüüsitud "in­fot tootvad süs­tee­mid", Zacki (1999) kirjeldatud in­fo­süsteemide arhi­tek­tuu­ri­mu­de­lid, Gudwin'i (2002) teadmiste töötlemise mudelit.

Väga lihtne on seletada, mi­da tähendab meh­ha­nist­li­ku vaa­te sei­su­ko­halt "hea info­süs­teem". Süs­tee­mi hea­dus ja toi­mi­vus on mää­ra­tud sellega, kui­das süs­teem tuleb toime oma ees­mär­gi­ga—väljas­ta­da ka­su­ta­ja­te­le va­ja­lik­ku infot. Süs­teemi väljundi kva­liteet on ühest kül­jest mää­ra­tud sisendi kva­li­teediga (gar­ba­ge in, garb­age out põhi­mõte), teisest kül­jest—süs­tee­mi­si­ses­te in­fo­tööt­lus­prot­sesside ja -algo­rit­mide adek­vaat­su­se­ga.

Millised küsimused on olulised infosüsteemi tege­mi­sel mehhanistlikust et­te­kuju­tusest läh­tu­des? Val­dav enamus info­süs­tee­mi­de arenduse mee­todeid on ole­muselt mehhanistlikud. Võib valida ühe ole­mas­olevatest mee­to­ditest; võib kom­bineerida mitmeid mee­todeid. Lihtsa mehhanistliku süs­tee­mi­aren­dus­mee­todi võib ka ise koostada. Seda tüüpi mee­todites on võt­mesõnadeks täielikkus ja ülevaatlikkus. Suu­re­mas süsteemis võib kasutajate tüüpe olla pal­ju; vas­ta­valt on erilaadseid info­vajadusi pal­ju; info liikumise teed on keerukad ning vajavad kir­jel­da­mist; oluline on, et midagi ära ei unusta­taks. Selle tõt­tu pa­kuvad mee­to­did vahendeid info, info­vaja­dus­te, info lii­ku­mi­se ja tööt­luse kir­jel­dus­te ja mää­rat­luste täie­lik­ku­se kindlustamiseks. Ele­men­ti­de suure arvu ning kee­ru­ka­te seoste tõttu võivad koos­ta­tud loetelud olla eba­üle­vaat­li­kud. Meetodid pa­ku­vad vahendeid kogu­tud definitsioonide, nõud­miste jms üle­vaat­likuks ja süs­teemseks kä­sit­le­mi­seks.

Skeem infosüsteemi kui infotöötlusmasina aren­du­seks ja uurimiseks:

1. Kasutajad Kes on (loodava või olemasoleva) süs­teemi kasutajad?

2. Infovajadused Millist infot kasutajad vaja­vad? Mil­lise kvali­teedi­tase­mega infot vajatakse?

3. Infoallikad Millised infoallikad on ole­mas (või või­malikud)?

4. Süsteemi arhitektuur ja algoritmid De­kom­po­nee­rida süsteem (info haare infoallikatest, la­dus­ta­mi­ne, teisendamine ja transport info kasu­ta­ja­teni).

5. Toimivus Hinnata töötava süsteemi toi­mivust ja töö­kindlust.

 

 

Arendusprotsess kui masin   Masinavaate üheks kül­jeks on vaade aren­dus­protsessile kui ma­si­na­le. Aren­dus­protsessi funktsiooniks on luua püs­ti­ta­tud nõu­deid rahuldav süsteem.

Mil­lised probleemid, millised ras­kused võivad tek­ki­da info­süs­teemi te­ge­mi­sel—loo­gi­lis-rat­sio­naal­sest ette­kuju­tu­sest lähtudes?

Soovitava väljundi täpse mää­rat­lemise kulukus. Soo­vi­tava väl­jun­di mää­rat­le­mine võib ol­la ras­ke mit­mel põh­ju­sel. Üheks ta­kis­tu­seks võib ol­la lihtsalt väl­jun­di mää­rat­le­mise suur töö­maht. See ta­kis­tus on loo­mu­likult üle­ta­tav süs­tee­mi­aren­duse res­surs­side täien­da­va kulu­tuse­ga.

Kõik raskused ei ole suurest mahust tingitud. Info tarbimine ning info han­ki­mine on infosüsteemis sa­ge­li ajaliselt lahus. Võib mõel­da ning ilmselt ka lei­da näiteid infosüs­tee­mi­dest, milles infot min­nakse ot­si­ma alles siis, kui info­va­ja­dus tekib. Sagedasem on siis­ki tugev ajaline eris­tatus—kogutavat infot kasu­ta­takse mitte (ainult) koheselt, vaid ka hil­jem, sageli päris pika aja jooksul. Info kõiki või­ma­likke ka­su­tus­vii­se ja kasutusolukordi on aga raske ette näha. Tei­sest küljest—sageli ei ole kõik info­vaja­du­sed ette näh­ta­vad. Info­vaja­dused pea­vad ka ole­ma määratletud piisavalt konkreetselt, et tehno­loo­gilise süs­tee­me te­ge­misele saaks eesmärki seada.

Üheks lahenduseks võiks olla info ennetav va­ru­mine, võimalik et pii­ratud ala­del isegi kogu info va­ru­mine ja säilitamine. Täielikku infot ko­guv ning hoi­dev info­süsteem on väga atrak­tiivne mõte. Kuid seda õnnestub teostada, siis süs­teemi efektiivsus harilikult tõuseb hüppeliselt. Huvitavaks kaa­su­seks on IBM'i glo­baal­se haardega turuinfo kogumise süs­teem (Menon 2004). Paljusid in­fo­süs­teeme ei saa kahjuks täieliku in­fo põhimõtte järgi üles ehitada, kui läh­te­info hankimine on kulukas. Otstarbekat lahendust ai­tab ilmselt leida ma­jan­dusliku tasuvuse arvestus.

Info töötlemine, viimine kasutajatele sobivale ku­ju­le, on mahukas ja kee­ru­kas. Lahen­duseks on ilm­selt töö infosüsteemi kallal. Tihti on ras­kuste põh­jus sel­les, et mõnda info­tööt­lusoperatsiooni ei suudeta täie­li­kult au­to­ma­ti­see­ri­da. Töötluse struktuuri sisse jääv inim­töö muu­tub siis kergesti kitsas­ko­haks.

Info efektiivse esituse probleem   Hea in­fo­süsteem peaks info esitama kasutajale sobivas vor­mis ja ku­jun­duses. Kuidas aga määrata, mis on "sobiv vorm" ja "hea kujun­dus"? Mõned uurimused (Burke et al, 1999) on näi­da­nud, et rikkamat mee­diu­mit (otsest, face-to-face suhtlust) ka­su­ta­va rühma efektiivsus võib olla madalam kui väljendusrikkuse poolest vae­se­mat info­ka­na­lit (elektroonilist vest­lus­ringi) ka­su­ta­val rühmal? Kui süsteemi väljundit ka­su­tatakse sel­leks, et tar­bi­ja käi­tumist mõju­ta­da, panna inimest ostma üht või teist asja, või uskuma ühte või teist ideed, siis on info esi­tus, kujundus vä­ga olu­li­ne. Väik­sem­gi detail võib ter­viku üldpilti ja toi­met inimesele muu­ta. Nor­maal­ne süsteem esitab vajalikku infot, mõist­li­kul kujul; suu­re­pä­ra­ne süsteem esitab võib-ol­la sa­ma infot, kuid millegi poolest tõhu­sa­mal, mõ­ju­sa­mal viisil. Vahe tunnetamine hea ja suu­re­pärase süs­tee­mi va­hel on võib-olla lihtne, kuid sel­le vahe loo­mine on keeru­li­ne. Mitte ainult info esitusviis (ku­va kujundus jms), vaid ka info ja süsteemi kasu­ta­mi­ne üldse võivad suurel määral sõltuda inimese tüü­bist. Kas infosüsteeme tuleks siis teha konk­reet­se­tele ka­su­tajatele? (vt Dueck, 2001)

Soovitava väljundinfo sisulise eris­ta­mi­se ja määratlemise raskus   Nn tead­mus­töötaja (know­ledge worker) vajab tööks väga mit­me­su­gust infot. Suur osa sel­lest infost on loogiliselt-ratsionaalselt määratletav ai­nult osaliselt.

Soovitava (või lubatava) väljundinfo suhtes kokkuleppe saavutamise raskus   Lõppkokku­võttes on info kasutajaks küll konk­reetne ini­mene, kuid ini­mest ei saa infosüsteemi kon­teks­tis võtta eral­di­seis­va­na. Eri­juhuks on nn ühe kasutaja infosüsteemid. Näiteks kodus inimese poolt oma hobi toetuseks teh­tud süs­teem; või töökohas—ainult ühe töötaja poolt ka­su­ta­tav süsteem. Need on siiski ainult paljuski hü­po­teetilised erijuhud. Info­süs­tee­mi­del on reeglina mit­meid või palju inim­kasutajaid. Üksikkasutaja kuu­lub üh­te või mitmesse sotsiaal­ses­se rühma, or­ga­ni­sat­si­ooni struktuuri­üksusesse, or­ga­ni­satsiooni ter­vi­ku­na, ühis­kon­da jne. Nendel or­ganisatsi­oonilistel-sotsiaal­se­tel struk­tuuridel ei ole üks­kõik, milline info infosüsteemis liigub, kes ja kui­das seda infot kasutab. Sotsio­loog, psüh­holoog või politoloog, kes uurib või­mu, kommunikatsiooni ja su­hete meh­hanisme tänapäeva organisatsioonis va­jab ka organi­sat­si­ooni in­fo­süsteemi uurimist. In­fo­süsteemi kasutajaks tuleb lu­ge­da mitte ai­nult ük­sik­isi­kut, vaid ka orga­ni­sat­si­oo­ni tervikuna. In­fo­süs­tee­mi ka­su­ta­jaks võib olla ük­sik inimene (ka­su­ta­ja), aga ka inimeste rühm, tei­ne in­fo­süsteem, teine äri­süs­teem jne.

Infosüsteemi väljundi määramine võib eeldusena nõu­da mõistete kok­ku­lep­pi­mist. Ratsio­naal­ne-meh­ha­nistlik vaade käsitleb infot neut­raal­se­na. Kui sel­li­se käsit­lu­se­ga saab hakkab, on hea—info­süs­tee­mi te­ge­mi­ne on lihtne. Veidigi laie­mas kontekstis te­ki­vad prob­lee­mid. See, mil­list infot süs­teem käitleb, kel­le­le millist infot välja annab jne on tihti or­ga­ni­sat­si­oo­ni­sot­si­aal­se, or­ga­ni­sat­si­oo­ni­kul­tuu­ri­li­se ja orga­ni­sat­si­oo­ni­po­lii­ti­lise kokkuleppe (aga ka komp­ro­missi, võitluse, do­mi­natsiooni) otsustada. Info­süsteem võib olla selleks foo­kus­punk­tiks, kus ilm­neb eriti ilmekalt erinevate huvi­grup­pide suun­du­mus­te, vaa­de­te, ideo­loo­gia­te ja huvide põrkumine. Toimi­va in­fo­süsteemi saa­miseks ei piisa sel­le tõttu ainult kavandamise ja teostuse tehnilisest täius­lik­ku­sest. Info­süs­tee­mi toimi­mi­sest (või mitte­toi­mi­misest) huvi­ta­tud osa­pool­te huvid peavad ole­ma ühel või teisel viisil ühi­ta­tud, har­moniseeritud. Huvide ühitamiseks ei ole kah­juks üld­tunnustatud, uni­versaalset, ratsionaalset mee­todit. Huvide ühi­ta­mi­ne on poliitilise ole­musega prot­sess, milles osa­pooled võivad kasutada ratsio­naal­seid mee­todeid, aga võivad ka mitte kasu­ta­da.

Ratsionaalses infosüsteemi arenduses on mää­rat­lu­se täie­lik­kuse (Kas ko­gu loodav süsteem sai kir­jeldatud?) kõrval suu­reks mu­re­allikaks in­fo­vaja­dus­te dünaami­li­ne areng, muutumine süs­tee­mi aren­duse ja ka­sutamise vältel. Mis võib tähendada, et süsteemi läh­teülesannet ei jõuta spetsifitseerida—muu­tu­sed nõudmistes on kiiremad, kui nende kirja­pa­nemise tempo.

Mehhanistlik ettekujutus infosüsteemist on või­mas töö­vahend. Ütle mulle täp­selt, millist infot tahad, ja ma teen sul­le infosüsteemi. (Ja ko­ge­ne­ma­tu süs­tee­mi­tellija saab "just sellise süsteemi nagu ta soovis"). Kui seda liini õnnestub järgida, on hea. Ek­sis­tee­rib siiski rida raskusi, piiranguid (ülal kä­sit­le­tud), mis või­vad osutuda nii tõsisteks, et in­fo­süs­tee­mi tege­mi­ne loo­gi­lise-ratsionaalse ette­kuju­tuse järgi eba­õn­nes­tub. Arendustöö saab üles ehitada loo­gi­li­selt vä­ga sel­ge, struk­tuurse meetodi järgi. Süsteemi saab teha "op­timaal­seks". Kuid sel­li­ne infosüsteem toi­mi­mist saab kindla peale loota ai­nult teatud oma­dus­tega kesk­konnas. Ratsionaalne süsteem toimib, kui keskkond on samuti rat­sio­naal­ne; või, kui seos kesk­konnaga on suh­teliselt nõrk ning kind­lalt piiritletud.

Küsimus vaate "infosüsteem kui masin" ra­ken­da­mi­se piiridest taan­dub kü­si­musele inimese rat­sio­naal­se tegevuse piiridest. Kas saame oma otsuste ja te­ge­vuse kõiki tagajärgi ette näha? Kas suudame ot­sus­tada, milline info ja mil­li­ne info töötlemine võib olla tulevikus kasu­lik? Tähele­panu­väärne on ka see, et loo­giline-ratsio­naal­ne mee­tod küsib küll "Millist infot on vaja?", kuid jätab vaat­luse alt välja kü­si­muse "Mil­leks infot on vaja?"

Kirjandus

Ballou D. et al. (1998) Modeling Information Manufacturing Systems to Determine In­for­mat­ion Product Quality. Mana­ge­ment Science, 44, 4, 462-484.

Burke, K., Chi­dam­baram, L. (1999) How much bandwidth is enough? A Longitudinal exam­inat­ion of media cha­rac­te­ris­tics and group outcomes? MIS Quar­terly, 23, 4, 557-580.

Dueck, G. (2001) Views of know­ledge are hum­an views. IBM Systems Journal, 40, 4, 885-888.

Gil­mour, D. (2003) How to Fix Know­ledge Management. Harv­ard Busi­ness Review, October, 16-17.

Gudwin, R. (2002) Semio­tic Syn­thesis and Semionic Networks, SEED, 2, 2, 55-83.

Menon, A., Tomkins, A. (2004) Learning About the Market's Periphery: IBM's WebFountain. Long Range Planning, 37, 153-162.

Peak, D., Guy­nes, C. (2003) The IT Alignment Planning Process. Jour­nal of Computer Information Systems. Fall, 9-15.

Meyer, M.; Zack, M. (1996) The Design and De­ve­lopment of Information Products. Sloan Management Review, 37, 3, 43-59.

Zack, M. (1999) Ma­nag­ing Codified Know­ledge. Sloan Management Re­view, 40, 4, 45-58.