BDAR programinės įrangos palyginimas turėtų baigtis dokumentuotu pasirinkimu: kokius darbus organizacija turi atlikti, ką kiekvienas pasiūlymas iš tikrųjų leidžia padaryti ir kokios sąlygos lieka neišspręstos. Bendras funkcijų sąrašas ar pardavėjo demonstracija tokio sprendimo nepakeičia. Vienodas praktinis bandymas leidžia atskirti naudingą funkciją nuo pažado, kuriam dar reikia papildomo modulio, konsultanto arba paties kliento darbo.
Šiame vadove pateikiamas pasiūlymų vertinimo metodas, o ne nepatikrintas gamintojų reitingas ar kainoraštis. Jį galite taikyti specializuotai privatumo platformai, platesnei rizikos valdymo sistemai ir jau naudojamų dokumentų bei lentelių procesui. Rezultatas turėtų būti suprantamas ne tik pirkimą atlikusiam žmogui, bet ir vadovui, kuris vėliau turės pagrįsti pasirinktą apimtį bei išlaidas.
Pirmiausia susitarkite, ką lyginate
Aprašykite organizacijas, procesus ir naudotojus, kurie pateks į pirmą įdiegimo etapą. Jei vienas tiekėjas skaičiuoja vieną juridinį asmenį, o kitas visą grupę, jų pasiūlymai dar nėra palyginami. Nurodykite kalbas, veiklos įrašų apimtį, prašymų kanalus ir reikalingas integracijas. Sąmoningai atskirkite pradinį poreikį nuo galimo vėlesnio išplėtimo.
Surašykite kelias dabartines problemas ir joms tinkamą rezultatą. Pavyzdžiui, pasenusių tiekėjų duomenų problema sprendžiama tada, kai pakeitimas pasiekia atsakingą žmogų ir susijusius dokumentus. Papildoma lentelė savaime šio rezultato neįrodo. Vertinimo kriterijuje turi būti matomas norimas darbo pokytis, o ne vien programos meniu pavadinimas ar pardavėjo naudojamas terminas.
Mažai komandai pirmiausia pravers MVĮ poreikių ir pradinės apimties vadovas. Didesnėje grupėje papildomai patikrinkite, kaip atskiriami valdytojai, jų dokumentai ir prieigos. Bendras prisijungimas neturėtų reikšti, kad vienos bendrovės darbuotojas automatiškai mato kitai bendrovei skirtus prašymus ar jautrius incidento įrodymus.
Mokama programa nėra universali BDAR pareiga. Esamus kontroliuojamus dokumentus verta palikti palyginime, jeigu jie leidžia atlikti reikalingus darbus ir pateikti įrodymus. Taip nustatysite, už kokį konkretų pagerinimą mokate. Jei dabartinis procesas netinkamas, aprašykite faktinę spragą, o ne iš anksto priskirkite trūkumus visoms skaičiuoklėms ar visoms nedidelėms sistemoms.
Atskirkite būtinus reikalavimus nuo pageidavimų
Būtinas kriterijus reiškia, kad be jo pasiūlymas negali būti priimtas numatytai apimčiai. Tai gali būti tinkamas teisinis tvarkymo pagrindas, prieigos atskyrimas ar galimybė gauti savo dokumentus paslaugai pasibaigus. Pageidaujamas patogumas, pavyzdžiui, konkreti lentelės išvaizda, neturėtų kompensuoti esminės spragos vien todėl, kad surenka daug balų.
Kriterijus formuluokite patikrinamai. Vietoj „geras eksportas“ nurodykite, kokius įrašus, ryšius, priedus ir sprendimų istoriją turite gauti. Vietoj „paprasta naudoti“ paprašykite būsimo naudotojo atlikti apibrėžtą užduotį. Tada bus aišku, kuo remiasi vertinimas ir ką tiekėjas turi parodyti, kad atsakymas būtų pripažintas pakankamu.
Likusiems kriterijams galite suteikti svorius pagal savo veiklą. Hipotetiškai įmonei, kuri dažnai keičia tiekėjus, sutarčių ir susijusių veiklų ryšiai gali būti svarbesni už gražias bendras suvestines. Kita organizacija gali daugiau dėmesio skirti prašymų koordinavimui. Svorius patvirtinkite prieš demonstracijas, kad jie nebūtų pritaikyti jau patikusiam pardavėjui.
Nežinomą atsakymą žymėkite kaip nepatikrintą. Jo nereikia automatiškai vertinti nei kaip tinkamos funkcijos, nei kaip įrodyto trūkumo. Nustatykite, kokio dokumento ar bandymo trūksta ir kas iki sprendimo jį gaus. Toks atvirų klausimų sąrašas yra naudingesnis už tariamai tikslią bendrą balų sumą, paremtą nevienodo patikimumo informacija.
Naudokite vienodus įrodymų lygius
Pasiūlyme atskirkite tai, kas parodyta veikiančioje aplinkoje, kas patvirtinta sutarties dokumentuose ir kas tik planuojama. Žadama ateities funkcija negali būti vertinama taip pat kaip dabar patikrintas veiksmas. Jei ji būtina, nustatykite priėmimo sąlygą ir pasekmes jos neįgyvendinus, užuot pasikliovę neapibrėžtu plėtros planu.
Išsaugokite bandymo datą, naudotą produkto versiją, pasirinktą planą ir svarbias prielaidas. Demonstracija gali vykti kitoje konfigūracijoje nei siūloma prenumerata. Paprašykite tiekėjo aiškiai nurodyti papildomas licencijas ar paslaugas. Tai padeda vėliau suprasti, ar neatitikimas kyla dėl programos, sutartos apimties, ar nebaigto parengimo.
Dokumentuotas dviejų pasiūlymų palyginimo scenarijus gali padėti suvienodinti klausimus. Vis dėlto galutinį atsakymą reikia tikrinti pagal savo duomenis ir galiojantį pasiūlymą. Kitos organizacijos patirtis arba bendras rinkos aprašymas neįrodo, kad tas pats funkcijų rinkinys bus įtrauktas į jūsų sutartį.
Bandomajam vertinimui naudokite išgalvotus ar tinkamai nuasmenintus duomenis. Tikri prašymai ir incidentų dokumentai gali atskleisti daug jautrios informacijos dar nepasirinktam paslaugos teikėjui. Jei realių duomenų bandymas būtinas, prieš perdavimą nustatykite tinkamas sąlygas, prieigas ir pašalinimą. Pirkimo bandymas neturėtų pats sukurti nevaldomos duomenų kopijos.
Patikrinkite veiklos įrašo pakeitimą
Pirmas scenarijus gali būti esamo proceso perkėlimas į kitą paslaugą. Paprašykite pakeisti tiekėją ir parodyti susijusią veiklą, gavėjus bei dokumentų peržiūrą. Veiklos įrašų programinės įrangos vadovas padeda nustatyti tinkamą informacijos struktūrą. Vien automatiškai sugeneruotas dokumentas neparodo, kaip jis bus prižiūrimas po pakeitimo.
Teisinį laukų minimumą tikrinkite pagal BDAR 30 straipsnį. Valdytojo ir tvarkytojo įrašai skiriasi. Papildomi laukai gali būti naudingi, tačiau programos klausimynas neturėtų pateikti visų savo laukų kaip pažodinio teisinio minimumo. Ypač svarbu nepaslėpti nežinomų terminų ar gavėjų už automatiškai užpildytų bendrų atsakymų.
Mažiau nei 250 darbuotojų turinčių organizacijų išimtis vertinama atitinkamos veiklos atžvilgiu. Ji netaikoma, kai tvarkymas nėra nereguliarus, gali kelti reglamente nurodytą pavojų teisėms ir laisvėms arba apima 9 ar 10 straipsnio duomenis. Vien darbuotojų skaičiaus laukas todėl negali patikimai nuspręsti, kad įrašų nereikia.
Patikrinkite, kas pakeitimą pateikia, kas peržiūri ir kas patvirtina. Jeigu sistema leidžia visiems iškart perrašyti galiojantį įrašą, įvertinkite, ar tai tinka jūsų atsakomybės modeliui. Reikalinga istorija turi paaiškinti ankstesnį sprendimą ir jo pagrindą, o ne tik parodyti paskutinio failo įkėlimo datą.
Sutarties peržiūra turi parodyti trūkstamas sąlygas
Antram scenarijui pateikite išgalvotą tvarkymo susitarimą su sąmoningai praleista pagalbos ar subtvarkytojų sąlyga. Paprašykite parodyti, kaip trūkumas pažymimas, kas jį patikrina ir kur išsaugomas sprendimas. 28 straipsnio sutarties reikalavimai padeda atskirti teisiškai reikšmingą patikrą nuo paprasto dokumento saugojimo.
28 straipsnis leidžia rašytinę sutartį arba kitą pagal Sąjungos ar valstybės narės teisę privalomą teisės aktą, įskaitant elektroninę formą. Įprastame komerciniame pirkime tikrinama sutartis. Konfidencialumo pareiga gali kilti iš įsipareigojimo arba tinkamos įstatyminės pareigos. Automatinis vertinimas neturėtų klaidingai atmesti teisėtos alternatyvos vien todėl, kad nėra konkretaus šablono sakinio.
Subtvarkytojų atveju tikrinamas reikalingas leidimas, atitinkamų pareigų perdavimas privalomu susitarimu ar teisės aktu ir pradinio tvarkytojo atsakomybė valdytojui už subtvarkytojo pareigų vykdymą. Vien tiekėjų sąrašas šių klausimų neišsprendžia. Paprašykite paaiškinti, kaip pasikeitimas pasieks jūsų komandą ir kaip bus dokumentuota jos reakcija.
DI pagalbą vertinkite pagal pateikiamą pagrindą. Naudingas rezultatas nurodo konkrečią dokumento vietą, neaiškumą ir peržiūros poreikį. Bendras žalias atitikties ženklas be paaiškinimo apsunkina sprendimo patikrą. Taip pat nustatykite, ar įkelti dokumentai naudojami kitais tikslais, kas turi prieigą ir ar galima valdyti jų saugojimą.
Prašymai, vertinimai ir incidentai reikalauja skirtingų eigų
Prašymų valdymo bandyme įtraukite laišku gautą mišrų prašymą ir atsakingo žmogaus nebuvimą. Sistema turėtų padėti išsaugoti gavimo datą, paskirti pavaduotoją ir pagrįsti atsakymą. Terminas neturėtų prasidėti iš naujo vien dėl perkėlimo į kitą modulį ar užduoties priskyrimo kitam skyriui.
BDAR 12 straipsnio pagrindinis terminas yra vienas mėnuo nuo gavimo, o ne visiems atvejams nustatytos trisdešimt dienų. Pratęsimas dar dviem mėnesiais galimas prireikus pagal sudėtingumą ir prašymų skaičių, apie jį ir priežastis pranešant per pradinį mėnesį. Atsisakymo atveju priežastys ir skundo bei teisminės gynybos informacija pateikiamos nedelsiant, ne vėliau kaip per mėnesį.
PDAV scenarijus turėtų apimti naujos veiklos rizikos vertinimą ir vėlesnį pakeitimą. Patikrinkite, ar matomi naudoti faktai, priemonės, likusi rizika ir atsakingų žmonių išvados. Automatinis balas gali padėti orientuotis, tačiau neturėtų pakeisti privalomo vertinimo ar teisinio sprendimo, kada jis reikalingas.
Incidento bandyme atskirkite techninį sutrikimą nuo asmens duomenų saugumo pažeidimo. Pastarasis dokumentuojamas visais atvejais. Institucijai pranešama nepagrįstai nedelsiant ir, jei įmanoma, per 72 valandas nuo sužinojimo, nebent mažai tikėtinas pavojus teisėms ir laisvėms; pavėlavimas paaiškinamas. Didelio pavojaus informavimas žmonėms pagal 34 straipsnį vertinamas atskirai.
Pažeidimo pranešimo proceso vadovas padeda parengti konkretų bandymą. Paprašykite parodyti sprendimą nepranešti, dalinį pranešimą ir vėlesnį papildymą. Vien sugeneruotas failas nėra įrodymas, kad institucija jį gavo. Turi būti aišku, kas faktiškai pateikia informaciją ir išsaugo pateikimo patvirtinimą.
Saugumas ir duomenų vieta turi būti patikrinami
Paprašykite aprašyti prieigos valdymą, autentifikavimą, veiksmų žurnalus ir darbuotojo paskyros panaikinimą. Patikrinkite, ar sistemos administratorius gali matyti turinį, kurio jam nereikia, ir kaip tokia prieiga kontroliuojama. Bendras saugumo sertifikatas gali būti naudingas įrodymas, tačiau svarbi jo apimtis, galiojimas ir ryšys su perkama paslauga.
ES serverio vieta pati savaime neatmeta perdavimo į trečiąsias šalis. Vertinkite palaikymo prieigas, subtvarkytojus ir duomenų srautus. Tarptautinio perdavimo vertinimas turi remtis tikra paslaugos grandine. Jei tiekėjas pateikia tik infrastruktūros regioną, paprašykite likusios informacijos prieš laikydami šį kriterijų išspręstu.
Palyginkite atsarginių kopijų, atkūrimo ir galutinio pašalinimo sąlygas. Aktyvios paskyros ištrynimas nebūtinai tuo pačiu momentu pašalina visas atsargines kopijas. Reikia suprasti jų paskirtį, prieigas, ciklą ir duomenų atkūrimo poveikį. Šiuos atsakymus susiekite su savo saugojimo ribojimo sprendimais, o ne tik su tiekėjo standartiniu nustatymu.
Skaičiuokite visą sutartą apimtį
Bendros kainos vertinime atskirkite prenumeratą, parengimą, migraciją, mokymus, integracijas, palaikymą ir pasitraukimą. Patikrinkite, pagal ką didėja mokestis: naudotojus, juridinius asmenis, saugomą informaciją ar atliktus veiksmus. Vienoda mėnesinė suma gali slėpti skirtingus apribojimus, todėl reikalingas konkretus pasiūlymas su aiškiomis prielaidomis.
Darbuotojų laiką matuokite savo bandyme. Užfiksuokite faktų rinkimą, įvedimą, klaidų taisymą ir galutinę peržiūrą. Nereikia iš anksto numatyti universalaus sutaupymo procento ar rinkos valandų vidurkio. Jei sistema sutrumpina įvedimą, bet labai apsunkina patvirtinimą, bendras rezultatas gali skirtis nuo demonstracijoje matomo vieno greito veiksmo.
Atitikties pirkimo nereikėtų pateisinti tariamu garantuotu baudos išvengimu. VDAI sprendimų kontekstas gali padėti suprasti rizikas, tačiau konkrečios bylos aplinkybės ir stadija tikrinamos pirminiame šaltinyje. Programos kaina ir galimas pažeidimo padarinys nėra pakankamas atsipirkimo skaičiavimas, ypač kai nežinoma tikimybė ir sprendimo poveikis.
Kaip išspręsti prieštaringus vertinimo rezultatus
Įsivaizduokite tris vienodai pateiktus pasiūlymus: specializuotą privatumo sistemą, platesnę rizikos platformą ir jūsų turimų dokumentų proceso patobulinimą. Tai galimos vertinimo kategorijos, o ne konkrečių gamintojų funkcijų teiginiai. Kiekvienam kandidatui duokite tą patį pradinį duomenų rinkinį ir tą pačią užduotį. Nepridėkite sudėtingesniam produktui papildomų balų vien už funkcijas, kurios jūsų apimčiai nereikalingos.
Tarkime, pirmas pasiūlymas gerai atlieka veiklos įrašo pakeitimą, bet jo eksportas dar neparodytas. Antras pasiūlymas eksportą demonstruoja, tačiau darbuotojui sunku nustatyti atsakingą asmenį. Trečias leidžia atlikti abu veiksmus rankiniu būdu, bet reikalauja daugiau koordinavimo. Šioje hipotetinėje situacijoje negalima sąžiningai paskelbti laimėtojo vien pagal vieną greičiausią veiksmą. Pirmiausia reikia pašalinti nežinomą esminį kriterijų ir įvertinti realią likusio darbo apimtį.
Jeigu eksportas privalomas, pirmam kandidatui suteikite galimybę jį parodyti iki nustatyto sprendimo momento. Antram patikrinkite, ar sunkumą išsprendžia aiškus parengimas, ar jis kyla iš netinkamo atsakomybės modelio. Trečiam įvertinkite, kas palaikys rankinį koordinavimą darbuotojui išėjus atostogų. Taip kriterijai virsta konkrečiais papildomais klausimais, o ne bendromis nuomonėmis apie produkto kategoriją.
Vertintojų nesutarimą išsaugokite kaip naudingą informaciją. Teisininkas gali vertinti sprendimo paaiškinimą, IT specialistas duomenų srautą, o naudotojas kasdienį patogumą. Jie nebūtinai klysta, jei renkasi skirtingai: gali vertinti skirtingas pasekmes. Paprašykite kiekvieno susieti savo argumentą su tuo pačiu scenarijumi ir pasiūlyti patikrinimą, kuris padėtų išspręsti nesutarimą.
Prieš galutinį sprendimą pakeiskite vieną reikšmingą prielaidą. Pavyzdžiui, patikrinkite, kaip pasiūlymas veiktų prisijungus dar vienam juridiniam asmeniui ar pasikeitus išorės konsultantui. Tai nėra kvietimas pirkti visas būsimas funkcijas. Toks jautrumo patikrinimas padeda nustatyti, ar sutartis turi aiškią plėtros ribą ir ar nedidelis tikėtinas pokytis nesukeltų neproporcingos priklausomybės.
Palyginimo rezultatas gali būti ir sprendimas kol kas nepirkti. Jei problema yra neaprašyti procesai ir nepaskirti atsakingi žmonės, pradinis darbas gali būti organizacinis. Užrašykite, kokios sąlygos lemtų naują vertinimą: didesnis darbo kiekis, papildomi valdytojai ar būtinybė valdyti daugiau susijusių įrašų. Toks sprendimas yra pagrįstas, jei esamas procesas leidžia vykdyti pareigas ir jo ribos sąmoningai prižiūrimos.
Galiausiai numatykite patikrą po sutarto pradinio etapo. Palyginkite pažadėtą rezultatą su tikru darbu, naudodami tas pačias sąvokas ir įrodymus. Jei naudotojai grįžo prie atskirų failų, išsiaiškinkite priežastį: gal trūksta mokymo, funkcijos ar turinio savininko. Ši informacija leidžia taisyti konkretų procesą, užuot vien didinus licencijų skaičių ar skelbiant visą projektą nesėkmingu.
Priėmimas ir pasitraukimas yra pasirinkimo dalis
Prieš pasirašydami nustatykite, kokie bandymai patvirtins parengimą darbui. Įtraukite ne tik naujo įrašo sukūrimą, bet ir taisymą, atsakingo žmogaus pakeitimą bei eksportą. Migracijos rezultatą tikrinkite pagal kelis skirtingus senus įrašus. Jei perkelti duomenys praranda ryšius ar priedus, vien failų skaičiaus sutapimas dar neįrodo sėkmingo perkėlimo.
Nustatykite, kokį rezultatą gausite nutraukę sutartį: failus, struktūrinius duomenis, istoriją ir naudojimui reikalingus paaiškinimus. Paklauskite, kiek laiko jie bus prieinami ir kaip patvirtinamas likusių kopijų tvarkymas. Tokia peržiūra ypač svarbi tada, kai sistema ilgainiui tampa pagrindine vieta, kurioje saugomi organizacijos sprendimų įrodymai.
Galutiniame sprendime užrašykite pasirinktą apimtį, atmestas alternatyvas ir likusias sąlygas. Pavyzdžiui, pasiūlymas gali būti priimtas tik patvirtinus eksportą arba sutarties pataisą. Nurodykite sprendimo savininką ir situacijas, kurios paskatins peržiūrą. Tai leidžia vėliau patikrinti, ar programos naudojimas tebėra suderintas su pradine pirkimo priežastimi.
Dažniausiai užduodami klausimai
Kuris sprendimas geriausias visoms organizacijoms?
Universalaus laimėtojo negalima nustatyti be veiklos ir patikrintos pasiūlymo apimties. Geriausias konkrečiam pirkimui yra sprendimas, kuris atitinka būtinus reikalavimus ir pagrindžia savo naudą vienodame bandyme. Pardavėjo dydis ar platus modulių sąrašas savaime neįrodo nei tinkamumo, nei netinkamumo jūsų procesui.
Ar programa pakeičia duomenų apsaugos pareigūną?
Ne. Pareigūno skyrimo pareiga vertinama pagal taikomus BDAR kriterijus. Programinė įranga gali padėti atlikti darbus, tačiau nepakeičia privalomo vaidmens, nepriklausomumo ir atsakingo sprendimo. Jei perkama ir konsultavimo paslauga, jos turinį, prieinamumą bei atsakomybę reikia nustatyti atskirai nuo techninės prenumeratos.
Ar verta kartu pirkti NIS2 ir DORA funkcijas?
Tik kai nustatyta atitinkama taikymo sritis ir konkretus poreikis. NIS2 įrankio atranka ir DORA pasiūlymo patikra reikalauja atskirų scenarijų. Bendri duomenys gali būti naudingi, tačiau skirtingų teisinių režimų terminai, gavėjai ir sprendimai netampa vienodi vien dėl bendros platformos.