Kas ir lietotāju lomas un piekļuves tiesības uzņēmuma sistēmā?

Lietotāju lomas ir viens no pamatelementiem jebkurā nopietnā uzņēmuma sistēmā. Tās nosaka, vai lietotājs drīkst tikai skatīt datus, veidot ierakstus, labot informāciju, apstiprināt darbības, eksportēt datus vai administrēt sistēmu. Bez skaidra tiesību modeļa sistēma var kļūt nedroša un grūti pārvaldāma.

Vienkāršs piemērs ir CRM. Pārdevējs var redzēt savus klientus un darījumus. Pārdošanas vadītājs var redzēt komandas datus. Grāmatvedība var redzēt rēķinu informāciju, bet ne obligāti visus pārdošanas komentārus. Administrators var mainīt iestatījumus. Šāds sadalījums palīdz aizsargāt datus un saglabāt atbildību.

Tiesības var būt balstītas uz lomām, nodaļām, klientu grupām, projektiem vai datu statusiem. Sarežģītākās sistēmās ir nepieciešami apstiprināšanas līmeņi: viens darbinieks sagatavo, cits pārbauda, vadītājs apstiprina. Tas ir svarīgi cenu izmaiņām, līgumiem, izdevumiem vai sensitīviem klientu datiem.

Ieguvumi ir drošība, mazāks kļūdu risks un skaidra atbildība. Ja katrs redz tikai to, kas nepieciešams darbam, samazinās nejaušas informācijas noplūdes un kļūdainas izmaiņas. Darbību vēsture ļauj noskaidrot, kas un kad mainījis konkrētu ierakstu.

Pārāk sarežģīts tiesību modelis var kļūt par trūkumu. Ja katrai nelielai darbībai vajadzīgs īpašs izņēmums, sistēmas administrēšana kļūst smaga. Tāpēc jāatrod līdzsvars starp drošību un praktisku lietošanu. Mazākiem uzņēmumiem sākumā var pietikt ar dažām lomām, kuras vēlāk paplašina.

Biežākās kļūdas ir visiem dot administratora tiesības, neveidot darbību žurnālu vai aizmirst tiesību pārskatīšanu, kad darbinieks maina amatu. Vēl viena kļūda ir tiesības definēt tikai tehniski, nevis pēc reālām atbildībām uzņēmumā.

Ieviešana sākas ar lietotāju grupu un procesu analīzi. Jānosaka, kādi dati ir sensitīvi, kuriem darbiniekiem tie vajadzīgi un kādas darbības jāapstiprina. Izmaksas ietekmē lomu skaits, datu segmentācija, audita prasības un integrācija ar esošiem lietotāju kontiem. Devera individuālās sistēmās tiesību modeli projektē jau arhitektūras posmā, nevis pievieno to kā pēdējo funkciju.

Tiesību modelī jāparedz arī dzīves cikls. Darbinieks var pievienoties uzņēmumam, mainīt amatu, aiziet atvaļinājumā vai pamest uzņēmumu. Katrā situācijā piekļuves jāspēj ātri mainīt. Ja šis process nav sakārtots, sistēmā paliek lieki vai bīstami konti. Dažos uzņēmumos vajadzīga arī datu redzamība pēc struktūrvienības vai filiāles. Piemēram, reģiona vadītājs redz tikai savas komandas klientus, bet valdes loceklis redz kopējo ainu. Šādas prasības jāzina pirms izstrādes, jo vēlāk tās var būt grūtāk pievienot. Jādomā arī par eksportiem. Dažreiz lietotājs drīkst skatīt datus sistēmā, bet nedrīkst eksportēt visu klientu sarakstu. Eksporta tiesības bieži tiek aizmirstas, lai gan tās ir būtiskas datu drošībā. Tas pats attiecas uz masveida labojumiem un dzēšanu. Labs tiesību modelis ir saprotams administratoram. Ja katras tiesības ir pārāk smalkas un slikti nosauktas, ikdienas pārvaldība kļūst riskanta. Tāpēc lomas jāveido pēc reāliem amatiem un atbildībām, nevis tikai tehniskām funkcijām.

Ieviešanas plānā jāiekļauj ne tikai izstrāde, bet arī uzņēmuma iekšējā sagatavošanās. Jānosaka procesa īpašnieks, jāapstiprina datu struktūra, jāizvēlas lietotāji testēšanai un jāvienojas, kā tiks pieņemti lēmumi par izmaiņām. Bez šīs pārvaldības pat tehniski labs risinājums var kļūt sarežģīti ieviešams. Pēc palaišanas jāparedz mērīšana un uzlabojumi. Sistēma jāvērtē pēc tā, vai tā samazina manuālu darbu, kļūdas un neskaidrības, nevis tikai pēc tā, vai funkcijas ir izstrādātas. Lietotāju jautājumi, kavētie procesi un apietie soļi ir vērtīga informācija nākamajām izmaiņām. Devera individuālas programmatūras projektos šādu pieeju izmanto, lai sistēma nebūtu vienreizējs IT projekts, bet ilgtermiņa darba instruments uzņēmumam.