PRAKTIKUM 14 | Infosüsteemi arendusplaani läbivaatus

Ülesanne 11 Infosüsteemi arenduse plaanimine: lahenduste läbivaatamine

LOENG 14 | Infosüsteemide tulevik: tehnoloogilised, majanduslikud ja sotsiaalsed trendid

Infotöötluse tuumpraktikad

Neli tuumpraktikat:

1. programmeerimine
2. süsteemne mõtlemine
3. modelleerimine
4. innovatsioon

Vt ACM "Great Principles of Computing" projekt; Denning P (2008) Great Principles of Computing, lk 15; http://swisseduc.ch/informatik/great-principles.html (sks k).

Trendid: poliitilised (Political), majanduslikud (Economic), sotsiaalsed (Social), tehnoloogilised (Technological), õiguslikud (Legal), keskkondlikud (Environmental)

Vt nt PEST(LE) analüüsimeetod.

Poliitilised trendid

1) Euroopa Liidu struktuuride tihenemine, lõimumise areng | Eestis loodavad infosüsteemid peavad omandama rahvusvahelise mõõtme.
2) Teenuste kiire, odava, turvalise arendamise vajadus. Siseriigis on infopoliitiliselt tõenäoliselt jätkuvalt aktuaalne teenuste teema, sh küsimused teenuste kiire, odava, turvalise arendamise kohta.

Majanduslikud trendid

1) Avaliku sektori IT-lahenduste korduvkasutamine (müük teistesse riikidesse) | Eestis on heaks tavaks saanud edukate avaliku sektorite IT lahenduste
Edasiandmine või müük teistesse riikidesse.
2) Kulude kokkuhoid inimtöö osakaalu vähendamise kaudu. | Automatiseerimisvõimalused?

Sotsiaalsed trendid

Rahvastiku vananemine

Tehnoloogilised trendid

1) Web 2.0 tehnoloogiate levik; üldine trend interaktiivsuse suunas.
2) Teadmussüsteemide ja -tehnoloogiate levik.
3) Eelmisega seotult: ontoloogiate ja semantikatehnoloogiate levik.
4) Metaandmete levik.
5) Mobiilse interneti ja arvutite levik.
6) Agenttehnoloogiate levik.

Keskkondlikud trendid

Näiteid Eestis infosüsteemide arenduse väljapaistvast praktikast Riigi Infosüsteemi Haldussüsteemi (RIHA) avalikust vaatest ligipääsetavate dokumentide hulgas.

Heiko Vainsalu, Oskando OÜ (2003) Maaparandusealal Tegutsevate Ettevõtjate Register. Disaini dokumentatsioon. https://riha.eesti.ee, ligipääsuks valida 'Infosüsteemid', 'Maaparandusalal tegutsevate ettevõtjate register', 'Tehniline kirjeldus', fail 'mater_disain_16_07_2003.pdf'. Arhitektuur (sh logimine). Olekudiagrammid. Navigatsiooni skeem. Kasutusjuhud. Kasutajaliidese prototüüp. Klassidiagramm. Andmebaasi disain. XML dokumentide disain.

Heiko Vainsalu, Oskando OÜ (2003) Maaparandusealal Tegutsevate Ettevõtjate Register. Analüüsi dokumentatsioon. https://riha.eesti.ee, ligipääsuks valida 'Infosüsteemid', 'Maaparandusalal tegutsevate ettevõtjate register', 'Tehniline kirjeldus', fail 'mater_analyys_15_07_2003.pdf'. Kontseptuaalne eskiismudel.

Jako Bucht, TietoEnator Eesti AS (2006) Taimetoodangu Inspektsiooni Järelevalve infosüsteemi arenduse analüüs https://riha.eesti.ee, ligipääsuks valida 'Infosüsteemid', 'Järelevalve infosüsteem', 'Tehniline kirjeldus', fail 'JIS_analüüs_TietoEnator.pdf'. Arhitektuuri kujundamine mitmeid alamsüsteeme hõlmavale infosüsteemile (komponentide struktuur lk 10). Protsessimudelid (nt lk 41). Loogilised andmemudelid (nt lk 53).

Marek Kullas, Softronic Baltic AS (2004) Taimetoodangu Inspektsiooni Järelevalve infosüsteemi spetsifikatsioon https://riha.eesti.ee, ligipääsuks valida 'Infosüsteemid', 'Järelevalve infosüsteem', 'Tehniline kirjeldus', fail 'TTI_JIS_Spetsifikatsioon 2.3.pdf'. Protsesside modelleerimine (lk 3 jj). Kasutajarollid (lk 17).

Taimetoodangu Inspektsioon (2009) Ettevõtte tunnustamine ning tootja mahepõllumajanduse registrisse kandmine. Teenusstandard https://riha.eesti.ee, ligipääsuks valida 'Infosüsteemid', 'Mahepõllumajanduse register', 'Tehniline kirjeldus', fail 'Maheettevõtte_tunnustamine_teenusstand_ver13.pdf'. Menetluse üksikasjalik kirjeldus, suunatud teenindatavale isikule.

IFI6068 ◦ Sissejuhatus infosüsteemidesse ◦ Sügissemester 2014

ÜLESANNE 11 | Infosüsteemi arenduse plaanimine (viimane ülesanne)

Valige infosüsteemi arendamise idee - soovitavalt varem tehtud iseseisvate tööde jätkuna - ning analüüsige lühidalt paari-kolme aspekti, mis tõenäoliselt saavad ettevõetavas arenduses oluliseks.

Selgitused

Infosüsteemi arenduses võib RASKUSPUNKTIKS kujuneda mitmesuguseid asju. Näiteks:

1. Ärimudel (business model) - kes maksab? Majanduslik külg. Tasuvus

2. Kvaliteet. Konkurents? Konkureerivate süsteemide analüüs. Süsteemi erijooned

3. Protsessimudel

4. Ajakava

5. Arendusmeeskond - kohustuste jaotus

6. Projekti etapid

7. Projekti vahe- ja lõpptulemused

8. Süsteemi arhitektuuri osas peamised otsused - strateegia

9. Arendustegevused

10. Ressurssiplaan

11. Riskide juhtimise plaan

12. Arendusplaani vormistamine.

ESITAMINE: Järgmises praktikumis (mis on ühtlasi ka viimane võimalus töid esitada). Töörühm: 1-3 inimest.

LOENG 13 | Arendus- ja muutusprotsessid infosüsteemides

SISUKORD

Arendustöö tüüpskeeme
Infosüsteemi uurimine ja hindamine. Milline on meie huvi?
Instrumentaalne huvi ei ole piisav
Protsesside tsüklilisus
Infosüsteem kiiresti muutuvas keskkonnas
Infosüsteem kui organism
Iseorganiseeruvad infosüsteemid
Infosüsteem organisatsioonilises kontekstis
Infosüsteemi (kõrval)efektid
Skeem infosüsteemi kontekstu­aal­seks analüüsiks
Juhtimise eesmärk
Infosüsteemi juhtimissüsteemi ülesehituse põhimõtted
Infosüsteemi olemasolust ei tu­le­ne veel süsteemi kasu­ta­mine
Vajame infot infosüsteemide kohta
Infosüsteemide kaardistamine
Süsteemi haaramine pole kerge
Head süsteemi on raske teha – ka raske näha
Üks kasutaja ei tunne kogu info­süs­tee­mi
Kas süsteemi uurimine üksi võib uuri­ta­vat süs­teemi muuta?
Infosüsteemi hindamine
Infosüsteemide populatsioon
Infosüsteemid on üksteisega seostes
Süsteem on sageli osa suuremast süsteemist
Info­teh­no­loogiline maas­tik
Lokaalse optimumi oht
Probleemid/harjutused
Kirjandus

1. Arendustöö tüüpskeeme

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

2. 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.

3. 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?

4. Protsesside tsüklilisus

Infokä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).

5. 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.

6. 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).

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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).

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. Ü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.

19. 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.

20. 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).

21. 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?

22. 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.

23. 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.

24. Info­teh­no­loogiline maas­tik

25. 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.

What Is Information Handling? http://vtc.ngfl.gov.uk.

www.big6.com.

Süsteemiarendust käivitavatest sündmustest

Kuidas saavad IT projektid organisatsioonis alguse?

Lihtne vastus oleks, et süsteeme tehakse vastavalt vajadusele. Süsteemi tegemise lähtepunktiks on vajadus(ed) infotöötlust tõhusamaks teha. Kui neid vajadusi tunnetatakse ja arenduse vajadus IT inimeste ja juhtkonna peades kindlama kuju võtab, siis jõutakse lõpuks ühel hetkel punkti, kus tehakse otsus IT vallas suurem töö ette võtta. Süsteemiarenduseks võib siin nimetada mitmesuguseid IT arenduse iseloomuga tegevusi: riistvara väljavahetamine uuema vastu, tarkvara ost ja kohaldamine, rätsepatööna tellitav tarkvaraarendus jms.

Kuid ettevõttes käiv IT arendus ei tavaliselt ühtlaselt kulgev protsess. Suuremaid projekte käivitatakse võib-olla kord aastas või isegi harvemini. Üheks põhjuseks on siin kahtlemata süsteemiarenduse ajaline kontsentreerimine kui tõhus arenduspraktika. Pidevalt arenduses olev süsteem ei ole hästikasutatav. Selle tõttu koondatakse arendusvajadusi ja realiseeritakse neid pakettidena (nn arenduse külmutamise ehk freezing printsiip). Süsteemiarenduse protsessi organisatsioonis iseloomustab seetõttu tsüklilisus – aktiivsemate ja rahulikumate perioodide vaheldumine.

Kuid kas arendusvajadused, vajadused infosüsteemide uuendamiseks kogunevad regulaarse rütmiga? Freezing-mudelis eeldatakse, et süsteemide kasutajatel tekib pidevalt uusi vajadusi, ideid, ettepanekuid muudatusteks. Neid muudatusvajadusi akumuleeritakse ja kui kogum on juba piisavalt suur, siis algatatakse IT arendusprojekti. Vaadates lähemalt süsteemiarenduse kulgu mõnes organisatsioonis pikemas ajamastaabis, võib siiski leida ka hoopis teistlaadi dünaamikat. Nimelt, kui vaadata konkreetseid organisatsioonis läbiviidud projekte organisatsioonis ja selle tegutsemiskeskkonnas samal ajal või enne IT projekti käivitumist aset leidnud olulisi sündmusi või arenguid, siis võib peaaegu leida mõne sündmuse organisatsiooni äristrateegias, töökorralduses või tehnoloogilises keskkonnas, mis on olulisel mõjutanud IT projekti alustamist – ja sageli olnud selle otseseks põhjuseks.



Millised on siis need „triggerid”, IT arendusprotsesse käivitavad sündmused?

Praktikas võime täheldada kõige mitmesugusemaid põhjusi.

Kriitiline sündmus kui arenduse käivitaja

Süsteemiarenduse käivitajaks võib olla kriitiline sündmus. Ettevõtte serveri kõvaketas „lendas” – ja see sai põhjuseks kiirele arendustegevusele – osteti varuserver. Infosüsteemi murti sisse – see motiveeris tõstma IT süsteemide turvataset, jne. Võime näha olukordi, kus vajadusest üksi ei piisa arenduse käivitamiseks; vaja on ka teatud käivitavat sündmust.

Muutused organisatsiooni struktuuris

Kriitilised sündmused on hästi nähtavad, kuid nende osa IT projektide käivitamisel on siiski tõenäoliselt väike. Üheks olulisemaks süsteemiarenduse käivitajaks näivad olevat muutused organisatsiooni struktuuris. Paljud lihtsamad infosüsteemid järgivad oma arhitektuurilt või moodulstruktuurilt organisatsiooni struktuuri. See tähendab, et iga osakond kasutab suhteliselt omaette süsteemiosa. Organisatsiooni struktuuri suurem ümberkorraldamine – mis on tänapäeval küllaltki sagedane – võib seetõttu kaasa tuua infosüsteemide ümberseadmise vajaduse.

Väga sagedased on IT projektid, mis on põhjustatud ettevõtete ühinemisest. Kui kaks ettevõtet ühinevad, siis on vaja liita ka nende infosüsteemid.

Teine oluline süsteemiarendust põhjustav nähtus on ettevõtte tegevusgeograafia laienemine. Mitme tegevuskohaga ettevõttes tekib harilikult kohapealsete osakondade või filiaalide koordineerimise vajadus; peakorter ja osakonnad on vaja siduda ka infosüsteemide kaudu.

Praktikas sõltub ühe või teise süsteemi arendamine sageli ka konkreetse otsustava isiku personaalsetest eelistustest. Organisatsiooni juhi (või osakonna juhi) vahetumine toob seetõttu küllalt sageli kaasa ka uuete IT projektide algatamise.

Muutused organisatsiooni strateegias

Väga oluliseks süsteemiarenduse põhjustajaks ja ka otseseks käivitajaks on muutused organisatsiooni strateegias. Suuremad organisatsioonid, eriti avaliku sektori organisatsioonid ja rahvusvahelised ettevõtted ehitavad oma juhtimise üles strateegilistele kavadele. Organisatsiooni strateegias püstitatakse tavaliselt pikaajalisi eesmärke (1-3 ja enam aastat), mille saavutamiseks on sageli vaja teha toetavaid IT rakendusi. Näiteks, ühes organisatsioonis on strateegilise planeerimise tsükli pikkuseks kolm aastat. Praegu kehtib strateegia aastateks 2004-2006; sellega seatakse organisatsioonile nii tegevussuunad üldiselt kui ka konkreetsed eesmärgid. Ühe strateegilise eesmärgi täitmiseks on organisatsioonis läbi viidud infosüsteemi arendusprojekt; praeguseks on see edukalt lõppenud.

Muutused tehnoloogilises keskkonnas

Arendustöö vajadus võib tekkida ka muutusest tehnoloogilises keskkonnas. Muutused tehnoloogilises keskkonnas võib jagada nn. suurteks trendideks, mille mõju ettevõttele on kahtlemata tugev, kuid mis avalduvad mitte äkitselt, vaid pikema aja jooksul – ja väiksema mastaabiga tehnoloogilisteks muutusteks, mis võivad aga ettevõtte jaoks olla vägagi kriitilise tähtsusega. Suurteks trendideks on tänapäeval kahtlemata traadita side, mobiilse arvutustehnika, geoinfo ja mitmete teiste valdkondade arengud.

Väiksemaks tehnoloogiliseks muutuseks on harilikult tarkvaratoote uue versiooni ilmumine. Infotehnoloogilised tooted arenevad suhteliselt kiiresti. Kui ettevõte on mõne oma olulistest IT süsteemidest rajanud mittestandardsele süsteemitarkvarale või platvormile, siis on IT osakonna jaoks alati väga oluliseks sündmuseks süsteemitarkvara uue versiooni ilmumine. Üleminek süsteemi uuele versioonile võib võtta isegi hüsteerilisi vorme (kui tuletada meelde Windowsi uute versioonide avaldamist 1990ndate teisel poolel).

Näiteks, üks organisatsioon kasutab ühise töökeskkonnana tarkvarasüsteemi, mille uus, peatselt ilmuv versioon ei toeta enam senist andmebaasisüsteemi. Organisatsioon kavatseb selle tõttu minna üle teisele andmebaasisüsteemile ja seda kogu organisatsiooni ulatuses. (Tahetakse vältida erinevate andmebaasisüsteemide koos kasutamist ühes organisatsioonis, sest see suurendab süsteemide hooldamise kulu.) Näeme, et muutus ühe produkti tehnoloogilises keskkonnas toob kaasa muutusvajaduse ka teistes süsteemides.

Muutused ettevõtte ärikeskkonnas

IT arenduse käivitajaks võivad olla ka muutused ettevõtte ärikeskkonnas. (Avaliku sektori organisatsioonis vastavalt – muutused ühiskondlikus-poliitilises situatsioonis). Eesti kontekstis oli IT arendustööde väga oluliseks käivitajaks Eesti liitumine Euroopa Liiduga. Mitmed infosüsteemid tuli ühendada EL vastavate süsteemidega, teistes aga teha muudatusi, et täita EL nõudeid.

Siit nähtub ka ärikeskkonna stabiilsuse vajadus. Ärikeskkonna üheks osaks on tegevuse õigusalane raamistik. Kui seadusandlust, näiteks raamatupidamisele seatavaid nõudeid, pidevalt muudetakse, siis tekib sellest nii riigiasutustele kui ka ettevõtetele oluline koormus süsteemide pideva täiendamise vajaduse tõttu.

Muutuseks ärikeskkonnas on ka uue IT rakenduse kasutuselevõtmine konkurendi poolt. Aladel, kus uue tehnoloogia kasutusvõimalused ei ole kaugeltki mitte selged, annab just konkurentide käitumine sageli ettevõtte juhile signaali, et ettevõte peab algatama uut arendusprojekti.

Näiteks, üks Eesti avaliku sektori organisatsiooni loomise käivitajaks olid konkreetne kriisisituatsioon, mis tõstis selgelt esile vajaduse uue organisatsiooni järele.

Muutused tööprotsessides

Süsteemiarendust peaks põhimõtteliselt esile kutsuma ka muutused ettevõtte tööprotsessides. Kuid siin võib täheldada tööprotsesside ja IT süsteemide üha tihedamat seotust. Muutused ettevõtte tööprotsessides ja muutused infosüsteemides ei ole sageli enam ajas eraldatud, vaid toimuvad üheaegselt. Ei ole enam nii, et kõigepealt muudetakse töökorraldust ja seejärel hakatakse vaatama, kuidas IT süsteeme uue tööprotsessiga tuleks kohandada. Kuna praktiliselt ühtki tööd ei saa enam teha ilma IT kasutamiseta või toeta, siis on sageli seos hoopis vastupidine – muutused IT süsteemides on initsiaatoriks ehk käivitavaks teguriks arengutele ettevõtte töökorralduses ja vahel isegi strateegias.

Muud põhjused

Süsteemiarendust käivitavaks teguriks võib – mõnevõrra tinglikult – lugeda ka soodsa finantseerimisvõimaluse tekkimise. Riihimaa (2004) kirjeldab IT projekte, mis on sündinud soodsa finantseerimisvõimaluse ajel (riiklikud abiprogrammid, europrojektid jt.) Süsteemi tegemist alustatakse, kui selle jaoks õnnestunud mõnest rahastamisallikast toetust saada.

Siia kategooriasse võib liigitada ka eksperimentaalsed IT projektid, millega ettevõte katsetab uut tehnoloogiat või selle uut rakendusviisi. Sellise projekti käivitajaks ei ole mitte niivõrd vajadus leida kiire ja kindel lahendus akuutsetele probleemidele, vaid pigem uute ideede ja võimaluste kontrollimine. Ettevõte peab otsima uusi arenguvõimalusi; selle tõttu ei saa süsteemiarenduses jääda lootma ainult ilmsetest vajadustest tingitud projektidele.

Oluliste sündmuste äratundmine

Süsteemiarendust esilekutsuvaid sündmusi peaks tundma – ja ära tundma. Kahjuks on andmeid ka sellistest projektidest, kus tehtud töö ei realiseerunud, sest olulisi muutusi projekti ümbritsevas keskkonnas ei võetud arvesse.

Sündmused ja pikaajalised trendid

Võib-olla ei ole õige keskenduda sündmustele. Võib-olla on see kunstlik ja tähelepanu peaks pöörama ka pikaajaliselt toimivatele mõjuritele (drivers) ja trendidele? Sündmused ja pikaajalised muutusprotsessid on omavahel kindlasti seotud. Sügavam analüüs võiks seetõttu üritada mõista mõlemaid. Hõlmab ju IT arendustöö pikaajaliste projektide kõrval ka väiksemaid töid ja alati ka jooksvat tegevust (süsteemide käitlemist, haldamist ja hooldamist).

Oluliste sündmuste diagramm

Organisatsiooni kontekstis olulisi sündmusi võib ülevaatlikult esitada alljärgneva diagrammi abil. Võib valida olulised dimensioonid, näiteks keskkond, organisatsioon, strateegia, tööprotsessid, tehnoloogia ja IT süsteemid ning kaardistada igas dimensioonis olulisemad toimunud ja ette nähtavad sündmused. Järgmiseks sammuks võiks olla sündmuste vaheliste seoste uurimine. Sellega võib leida mõndagi üllatavat. Igal juhul võib loota, et üldpilt ettevõttest ja IT osast selles saab selgemaks.

Mõnest seonduvast teooriast

Sabherwal, Hirschheim ja Goles (2001) kasutavad ettevõtte IT keskkonna pikaajalise arengudünaamika lahtimõtestamiseks nn. punkteeritud tasakaalu mudelit. Viimane vaatleb arengut protsessina, milles vahelduvad pikaajalised, aeglased arengute (evolutsiooniline areng) ja lühiajalised, hüppelised arengud (revolutsiooniline areng). Nende analüüsid juhud näitavad hästi IT arengute põhjuslikku seost muutustega organisatsiooni strateegias ja keskkonnas.

Oracle Stream Development Method on Oracle Corp. välja töötatud arendusmeetod, mille kohaselt arendustöö toimub neljas paralleelses „voos” (stream) korraga: organisatsioon, protsessid, tehnoloogia, kultuur. Infotehnoloogilise muutuse saavutamiseks on vaja muutusi ettevõtte organisatsioonis, tööprotsessides ja organisatsiooni kultuuris.

Phaal et. al. (2003) kasutavad oluliste sündmuste diagrammiga mõneti samalaadset esitust ettevõtte tehnoloogilise keskkonna arengutrendide ja sellest tulenevate ettevõtte jaoks strateegiliste võimaluste kaardistamiseks („tehnoloogiline teekaart”).

Kirjandus

Cassidy A. (1998) A Practical Guide to Information Systems Strategic Planning. St. Lucie Press.

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

Phaal, R. et al (2003) Starting-Up Roadmapping Fast. Research & Technology Management, 2, 52-58.

Riihimaa, J. (2004) Taxonomy of information and communication technology system innovations adopted by small and medium sized enterprizes. Ph.D. Diss. University of Tampere.

Sabherwal, R., Hirschheim, R., Goles, T. (2001) The Dynamics of Alignment: Insight from a Punctuated Equilibrium Model. Organization Science, 12, 2, 179-197.

Sauer, C., Willcocks, L. (2003) Establishing the Business of the Future: The Role of Organizational Architecture and Information Technologies. European Management Journal, 21, 4, 497-508.

PRAKTIKUM 13 | Infosüsteemi arendusplaani koostamine

Ülesanne 11 Nõuete dokumendi koostamine: lahenduste läbivaatamine

Ülesanne 12 Infosüsteemi arenduse plaanimine