E-ITS rakendamine tundub tihti alguses teoreetiline. Praktikas algab see aga väga konkreetse küsimusega: mida organisatsioon päriselt teeb ja millest see tegevus sõltub?

Sellepärast on äriprotsesside määratlemine infoturbe jaoks nii oluline. Enne kui saab midagi kaitsta, tuleb aru saada, millised tegevused loovad organisatsioonis väärtust, kes nende eest vastutab ja milliste süsteemide ning andmete najal need toimivad.

Mis on äriprotsess E-ITS kontekstis?

Lihtsas sõnastuses on äriprotsess korduv tegevuste jada, mis aitab täita organisatsiooni eesmärki või pakkuda teenust.

Siin on oluline teha vahet kahel mõistel:

  • teenus kirjeldab, mida organisatsioon välisele kliendile või kodanikule pakub
  • protsess kirjeldab, kuidas see teenus sisemiselt ära tehakse

Näiteks võib kohaliku omavalitsuse teenus olla “sotsiaalabi tagamine”, aga selle teenuse sees toimuv protsess on “sotsiaaltoetuste taotluste menetlemine”.

Infoturbe vaatest tuleb keskenduda protsessidele, sest just nende ümber hakkad hiljem kaardistama varasid, sõltuvusi ja kaitsetarvet.

Miks on äriprotsessid E-ITS selgroog?

Äriprotsessid seovad omavahel:

  • organisatsiooni eesmärgid
  • pakutavad teenused
  • kasutatavad infosüsteemid ja andmed
  • riskid ja kaitsemeetmed

Kui see seos puudub, jääb infoturve liiga tehniliseks ja lahti seotuks sellest, mida organisatsioon päriselt kaitsta üritab.

1. Lähtu organisatsiooni eesmärkidest

Kaardistamist tasub alustada kõrgemalt tasemelt. Vaata, mis on organisatsiooni põhiülesanded ja miks ta olemas on.

Selleks sobivad näiteks:

  • põhimäärus
  • seadusest tulenevad ülesanded
  • strateegilised eesmärgid

Hea algusküsimus on lihtne: mida me teeme ja miks see oluline on?

Näiteks kohaliku omavalitsuse puhul annavad suuna juba seadusest tulenevad ülesanded nagu sotsiaalabi, ruumiline planeerimine, kommunaalmajandus või jäätmehooldus.

2. Koosta äriprotsesside nimekiri

Kui põhieesmärgid on teada, tuleb need jagada konkreetseteks protsessideks.

Praktiline rusikareegel on, et ühe teenuse taga on tavaliselt 1-5 peamist protsessi. See aitab vältida kahte levinud äärmust:

  • kirjeldus jääb liiga üldiseks
  • kirjeldus läheb liiga detailseks

Näited:

  • Teenus: sotsiaalabi ja -teenused

    • Protsess: sotsiaaltoetuste taotluste menetlemine
    • Protsess: lastekaitse juhtumite lahendamine
    • Protsess: eakate koduteenuste korraldamine

  • Teenus: ruumiline planeerimine

    • Protsess: ehitus- ja kasutuslubade menetlemine
    • Protsess: detailplaneeringute algatamine ja kehtestamine

Kui kirjelduse juures jääb küsimus, kas tegemist on teenuse või protsessiga, küsi:

  • kas see ütleb, mida me pakume või kuidas me seda teeme?
  • kas see kirjeldab välist väärtust või sisemist tegevuste ahelat?

3. Seo protsessid IT-süsteemide ja varadega

Kui protsessid on kirjas, tuleb need ühendada nende tegelike sõltuvustega.

Iga protsessi kohta tasub vähemalt läbi mõelda:

  • milliseid infosüsteeme see kasutab
  • milliseid andmeid või registreid see töötleb
  • millistest tehnilistest varadest see sõltub

Näiteks protsess “sotsiaaltoetuste taotluste menetlemine” võib sõltuda:

  • STAR-ist
  • dokumendihaldussüsteemist
  • rahvastikuregistri päringutest
  • sotsiaaltöötajate arvutitest
  • toimivast võrguühendusest

Selline kaart teeb infoturbe päriselt juhitavaks, sest siis on näha, millised ärilised tegevused katkeksid, kui mõni konkreetne vara või süsteem rivist välja läheb.

Äripoole omanik peab olema selge

E-ITS loogika järgi ei saa protsess jääda lihtsalt IT hallata. Igal protsessil peab olema äripoole omanik, kes mõistab selle eesmärki, mõju ja väärtust.

See on oluline, sest:

  • IT ei saa üksi otsustada protsessi ärilise tähtsuse üle
  • kaitsetarve peab peegeldama reaalse töö mõju
  • riskid tuleb siduda organisatsiooni tegevusega, mitte ainult tehnilise infrastruktuuriga

Lisaks äripoole omanikule on kasulik määrata ka tehniline haldur, kes tunneb protsessi toetavaid süsteeme ja varasid.

Levinumad vead

Äriprotsesside kaardistamisel kipuvad korduma samad eksimused:

  1. teenust ja protsessi käsitletakse sama asjana
  2. protsessile ei määrata ärilist omanikku
  3. protsessid jäävad kas liiga laiadeks või lähevad liiga pisikesteks tükkideks
  4. kaart tehakse valmis ühe projektina ja seda ei uuendata enam

Viimane on eriti oluline. Äriprotsesside kirjeldus ei ole ühekordne dokument, vaid juhtimissüsteemi elav osa. Uued tööriistad, uued teenused ja muutuvad vastutused peavad sinna jooksvalt sisse minema.

Millist infot iga protsessi kohta dokumenteerida?

Kasulik miinimum igale protsessile:

  • nimi
  • tüüp, näiteks põhi- või tugiprotsess
  • eesmärk
  • lühikirjeldus
  • äripoole omanik
  • tehniline haldur
  • alusdokumendid või õiguslik alus
  • töödeldavad andmed
  • seotud infosüsteemid ja varad
  • koostööpartnerid või muud osapooled

Kui see info on koos, muutub järgmiste sammude tegemine palju lihtsamaks, sest sul on juba olemas alus varade, teenusepakkujate ja riskide sidumiseks.

Kuidas Kordon aitab

Excelis ja eraldi dokumentides saab alustada, kuid üsna kiiresti muutub keeruliseks hallata protsesside, varade, riskide ja vastutajate seoseid ühes kohas.

Kordon aitab teha sellest ühise mudeli, kus iga protsessi juurde saab siduda:

  • omaniku ja tehnilise halduri
  • alusdokumendid
  • varad ja infosüsteemid
  • partnerid
  • seotud riskid ja kontrollid

Selle eelis on lihtne: infot ei pea hoidma erinevates tabelites. Kui mingi süsteem muutub või tekib intsident, on kohe näha, milliseid protsesse see mõjutab.

Kokkuvõte

Äriprotsesside määratlemine on üks kõige olulisemaid samme E-ITS rakendamisel, sest see annab infoturbele reaalse ärilise konteksti.

Hea lähtekoht on:

  • alusta organisatsiooni eesmärkidest
  • jaga teenused sisemisteks protsessideks
  • seo protsessid süsteemide, andmete ja varadega
  • määra igale protsessile selge omanik
  • hoia dokumentatsiooni ajakohasena

Kui see alus on paigas, muutuvad ka varade register, riskianalüüs ja kaitsemeetmete valik palju loogilisemaks.