ERM — тәуекелдерді басқару жүйесі: реестр, бағалау, жоспарлар және KPI

Қайдан бастау: ERM қандай мәселелерді шешеді

ERM — барша қауіп-қатерлерді бір кестеге жинау үшін емес. Оның мақсаты — тәуекелдерді көрінетін, салыстырмалы және басқарылатын ету: не маңыздырақ, кім жауапты, не жасалды және қай жерде басшылықтың шешімі керек.

Бір тізімдегі тәуекелдер әдетте тез ескіріп қалады. Онда контекст (тәуекел неге әсер етеді), статус (қазір не болып жатыр), иесі (кім әрекет етуі керек) және ең бастысы — басқарушы шешімдермен байланыс жоқ: қай процестерді, бақылауларды, бюджет пен мерзімдерді өзгерту қажет.

Басты назарды басшының алуы тиіс нәтижеге қойыңыз. Көбіне бұл «тәуекелдер тізімі» емес, қысқа сигналар жиынтығы: қай тәуекелдер топта, олардың деңгейі қалай өзгеріп жатыр, қай жерде әрекеттер мерзімі өтіп кетті, қай тәуекелдер аппетиттен асып, эскалация талап етеді, қандай жаңа инциденттер болды және олар картинаны қалай өзгертті.

Кейін бірінші кезеңнің шекарасын анықтаңыз. Жақсысы — басқаруға және өлшеуге болатын тәуекелдерден бастау және біртіндеп кеңейту. IT-сервистері критикалық ұйымдарда (мемлекеттік мекеме, банк, клиника) логично операциялық және ИТ тәуекелдерден бастау: сервистің тоқтауы, киберқауіптер, жабдық жеткізілімінің бұзылуы, өзгерістердегі қателер.

Пилот үшін қарапайым қосу ережесін бекіту ыңғайлы: 1–2 бөлімшені, 10–20 негізгі процесті және иесі бар, салдары анық (ақша, қолжетімділік, қауіпсіздік, талаптар) тәуекелдерді алыңыз. Стратегиялық және репутациялық тақырыптарды жүйелі жаңарту мен есеп беру тәртібі орнағаннан кейін қосқан дұрыс.

Рөлдер, циклдер және тәуекелдерді басқару деңгейлері

Жүйе есеп беру кестесіне айналып кетпеу үшін алдан-ала рөлдерді, жұмыс ырғағын және тәуекелдер жүргізілетін деңгейлерді бекітіңіз. Сонда әр тәуекелдің өз иесі болады, ал басшылыққа — түсінікті шолу.

Рөлдер: кім неге жауапты

Тәуекел карточкасында әдетте 3–4 рөл жеткілікті, бірақ оларды ат бойынша тағайындау керек:

• Тәуекел иесі — тәуекелді қабылдайтын және әрі қарай не істеуді шешетін басшы.
• Жауапты (орындаушы) — жүйеде тәуекелді жүргізіп, деректер жинап, іс-әрекеттер статустарын жаңартады.
• Келісуші — бағалау мен жоспардың дұрыстығын тексереді (мысалы, ИБ, қаржы, заң, комплаенс).
• Бақылаушы — хабарламалар алады және мәліметтерді пайдаланады (PMO, сапа қызметі, аудит).

Иесін мен орындаушыны бөлу маңызды. Мысалы, сервер инфрақұрылымының тоқтауы тәуекелінің иесі ИТ директоры болуы мүмкін, ал нақты резервтеу және тестілеу әрекеттерін эксплуатация басшысы орындайды.

Циклдар: қаншық жиі жаңарту керек

Ара-тұра тым жиі қарау шаршатады, ал өте сирек қарау реестрді мүгедек қылады. Негізгі жұмыс ырғағы әдетте мынадай:

• Ай сайын — статустар мен мерзімі өткен әрекеттердің қысқа тексерісі.
• Тоқсан сайын — ықтималдық пен зиянды қайта бағалау, бақылаулардың өзектілігін тексеру.
• Жыл сайын — бастамалар, бюджет пен мақсаттарды жоспарлау.

Деңгейлер және эскалация ережелері

Тәуекелдерді әртүрлі қабаттарда ұстаңыз: корпоративтік, процесс, жоба, ИТ және ИБ. Эскалация команда шеңберінен шығатын кезде қажет: күтілетін зиян лимиттен асады, бірнеше бөлімшені зақымдайды немесе приоритет пен бюджет туралы шешімді талап етеді. Мұндай жағдайда тәуекел тәуекел комитетіне көтеріледі, ал критикалық және қоғамдық салдарға ие болса — CEO деңгейіне.

Тәуекелдер реестрінің құрылымы: карточка өрістері

Тәуекел карточкасы қысқа және барлық жерде бірдей болуы керек. Салыстырмашылық маңыздырақ, «мінсіз сипаттама» емес.

Міндетті өрістер

Тәуекелді табу, тағайындау және қайта қарау мүмкін болу үшін ең қажеттілерден бастаңыз:

• Тәуекел ID (бірегей) және қысқа атауы
• қарапайым тілмен сипаттама: не болуы мүмкін және қай жерде
• контекст: процесс, бөлімше, актив немесе сервис, география, негізгі контрагенттер
• иелер: тәуекел иесі және бақылау иесі (егер бақылау болса)
• келесі қайта қарау күні және статус (актив, жабық, қайта қарауда)

Содан кейін себептер мен салдарды 2–3 тармақпен шектеңіз. Себеп «неге бұл мүмкін» сұғына жауап берсе, салдар «не зардап шегеді» деп көрсетеді. Мысалы: «сервер сандық сақтау жүйесінің (СХД) ақауы» (себеп) және «филиалдар үшін критикалық сервистің тоқтауы» (салдар).

Фильтрация және есептер үшін өрістер

Реестр күнделікті практикада жұмыс істеуі үшін бірден классификация мен тегтер енгізіңіз:

• категория (қаржы, комплаенс, ИТ, кадр және т.б.)
• тип (стратегиялық, операциялық, ИТ, жоба)
• критикалықтік немесе приоритет (сұрыптау үшін)
• байланысты активтер немесе сервистер (сөздіктегі бірдей атаулар)
• тегтер (мысалы: «жабдықтаушы», «ДЦ», «мемсатып алулар») жылдам сұрыптау үшін

Осындай формат бір сервисті немесе бөлімшені тез есептеу мүмкіндігін береді және деректерді қолмен тазалауға уақыт жоғалтпайды.

Тәуекелді бағалау: шкалалар, матрица және тәуекелге төзімділік

Бағалаулар пікір жинағына айналмас үшін біркелкі шкалалар мен есептеу ережелерін келіскен жөн. Ең түсінікті нұсқа — ықтималдық пен әсер үшін 1–5 шкаласы және балдарды приоритетке аударатын матрица.

1–5 шкаласы: оларды қалай сипаттау керек

Ықтималдықты жиілікке байлаңыз (мысалы, жыл ішінде қанша рет), «сирек» сияқты сөздерге сенбеу үшін:

• 1: дерлік мүмкін емес (5+ жылда 1 рет)
• 2: төмен ықтималдық (2–5 жылда 1 рет)
• 3: мүмкін (шамамен жылына 1 рет)
• 4: ықтимал (жыл ішінде бірнеше рет)
• 5: дерлік міндетті (ай сайын немесе жиірек)

Әсерді бір санмен «жалпы» жазудың орнына өлшенетін категорияларға бөліп сақтаңыз. Ыңғайлысы — жеке бағалау қаржы, тоқтау (SLA/сағат), комплаенс (айыппұлдар), репутация (жариялылық, охват), қауіпсіздік (жарақаттар, критичность) бойынша.

Присущий және остаточный тәуекел

Екі мән есептеңіз: присущий (бақылауларға дейін) және остаточный (ағымдағы бақылаулардан кейін). Формула қарапайымды болуы мүмкін: ықтималдық x әсер. Мақсат — баллдың қандай бақылаулармен азайып жатқанын көрсету, сондықтан көбейту тек формальді емес, мәні болуы керек.

Тәуекелге төзімділік (аппетит) матрица порогтарын және эскалация ережелерін анықтайды. Көбінесе светофор қолданылады:

• Жасыл: қабылдап, иесінің деңгейінде бақылауда ұстаймыз
• Сары: әрекет жоспары және қайта қарау мерзімі қажет
• Қызыл: міндетті эскалация және басшылық шешімі

Порогтар мен бекіту құқығын (процесс иесі, тәуекел комитеті, басқарма) методологияда бекітіңіз.

Бағалаулар «ағымды» болмауы үшін қабылданған болжамдар мен дереккөздерді жазып қойыңыз: инциденттер мен метрикалар, аудит нәтижелері, жеткізуші статистикасы немесе сараптамалық бағалау — сарапшы мен датасын көрсету арқылы. Бұл қайта қарауды жеңілдетеді және даулы тәуекелдерді фактілерге сүйене отырып талқылауға көмектеседі.

Контролдер және олардың тәуекелдермен байланысы

Контроль — тәуекелдің ықтималдығын немесе зиянын төмендететін нақты әрекет немесе ереже. Тәуекел (не болуы мүмкін) мен бақылауды (оның алдын алу немесе уақытында анықтау үшін не істейміз) айқын бөлу маңызды.

Контролдерді тағайындалуына қарай бөлу ыңғайлы: профилактикалық (мәселенің пайда болуына жол бермейді), детективтік (ауытқуды тез анықтайды) және түзетуші (салдарды азайтады және қалпына келтіруді жеделдетеді).

Контролды тексеріп, жетілдіру үшін әдетте мына өрістер жеткілікті:

• ID және атауы (қысқа және біркелкі)
• сипаттама: не істейді және қай процесс үшін
• иесі: орындауға кім жауапты
• периодичность: күнделікті, аптасына, оқиғамен
• орындалғанының дәлелдері: не растайтындығы

Тәуекелдер мен контролдер арасындағы байланыс көп-көпке болады. Бір бақылау бірнеше тәуекелді төмендетуі мүмкін (мысалы, өзгерістерді басқару — тоқтау тәуекелін, қауіпсіздік бұзылуы тәуекелін және сәйкессіздік тәуекелін азайтады). Керісінше, бір тәуекел әдетте бірнеше бақылаумен жабылады: бірі алдын алады, бірі анықтайды, үшіншісі қалпына келтіреді.

Контрол тиімділігін бірнеше өлшем бойынша бағалаңыз, әйтпесе реестр тез формальдылыққа айналады: дизайн (сценариді жаба ма), орындау (график бойынша орындалады ма), дәлелдемелер (орындалғанын растайтын құжаттар бар ма), бір адамға тәуелді ме (тұрақтылық).

Тексерулер үшін «галочка» емес артефактілер сақтаңыз: журналдар, мониторинг есептері, тест хаттамалары, нәтижелі таңдамалы тексерулер, бэкап растамалары. Мысалы: егер тәуекел — критикалық сервистің тоқтауы болса, детективтік бақылау — айлық қолжетімділік есебі, түзетуші — қалпына келтіру тесті хаттамасы (күн, уақыт, нәтиже).

Әрекет жоспарлары: іс-әрекеттер мен жауапкершілікті қалай сипаттау керек

Әрекет жоспары тәуекелді қатардағы жолдан нақты тапсырмалар жиынтығына айналдырады. Ол мини-жоба сияқты оқылуы керек: не істейміз, кім істейді, қашан және нәтижені қалай бағалаймыз.

Алдымен стратегияны таңдаңыз: болдырмау (әлсіз процесті жою), төмендету (бақылауды қосу немесе процесті өзгерту), беру (сақтандыру, мердігермен келісім) немесе қабылдау (саналы түрде қалдыру, бірақ мониторинг пен лимиттермен). Бұл әртүрлі әрекеттер санын негізсіз көбейтпеуге көмектеседі.

План карточкасында әдетте мыналар жеткілікті:

• әрекеттер: себепке байланыстырылған қысқа қадамдар (симптомға емес)
• жауаптылар: әрекет иесі және келісуші
• мерзімдер мен бюджет: күн, еңбек шығындары, сатып алулар, сыртқы мердігер
• күтілетін әсер: орындалғаннан кейін ықтималдық немесе зиян қалай өзгереді
• дәлелдер: жұмыс қабылдау үшін не қосу керек (акт, тест хаттамасы, бұйрық, есеп)

Тәуелділіктер мен блокерлерді бөлек көрсетіңіз: сатып алу рәсімдері, мердігер дайындығы, терезелерді өзгерту, ИБ келісімі, дерекке қолжетімділік. Тәуелділікті белгілмесеңіз, жоспар жиі «күтпеген» себеппен бұзылады.

Аяқталу критерийлерін тексерілетін етіп етіп жазыңыз. "Резервтік көшіру орнатылды" — жеткіліксіз. "Күнделікті бэкап 14 күн қатарынан орындалды, есептер бар, тест ортасында қалпына келтіру өткізілді" — жақсы.

Статустарды қарапайым ұстаңыз: жоспарланған, іске асырылуда, мерзімі өтті, аяқталған, тоқтатылған (себебімен). Егер тапсырма тоқтатылса, оның орнына не қойылғанын немесе неге тәуекел қазір қабылданғанын көрсетіңіз.

Қысқа мысал: сервер торапында бір түйіннің ақауы салдарынан критикалық сервис тоқтап қалу тәуекелі. Төмендету жоспары — резервтік түйін сатып алу, кластер орнату және қалпына келтіру жаттығуларын өткізу. Әсерді алдын ала бекітіңіз, сонда аяқталғаннан кейін тәуекел шын мәнінде төмендегені көрінеді.

Инциденттермен байланыс: реестрдің тірі болуын қамтамасыз ету

Реестр бөлек өмір сүрсе, ол жиі «ұйып» қалады. Сондықтан инциденттер тіркеліп, олар тәуекелдерге, бақылауларға және жауаптыларға байланыстырылуы маңызды.

Инцидент — бұрын болған немесе болуы мүмкін зиян тудырған жағымсыз оқиға: сервистің тоқтауы, мерзімнің бұзылуы, жабдықтың ақауы, деректердің ағуы. «Оқиға» — бейтарап бақылау (мысалы, жүктеменің уақытша өсуі), ал «мәселе» — түпкі себеп, оны жою керек.

Практикалық байланыстыру осылай көрінеді: инцидент нақты тәуекелге байланған (не іске асты), бақылауға байланған (не төтеп беруі немесе анықтауы тиіс) және тәуекел иесіне (шешім кімнің міндетінде) тіркелген. Мысалы, интегратордың дата-центрінде критикалық жүйе тоқтаған кезде инцидент «Критикалық сервистің тоқтауы» тәуекеліне, «Мониторинг пен резервтеу» бақылауына және сервис иесіне байланады.

Инцидент карточкасында тек шешім қабылдауға көмектесетін ақпарат болуы керек:

• күн мен уақыт, қайдан (мониторинг, пайдаланушы, аудит)
• әсері: тоқтау, охват, тікелей және жанама шығындар
• себеп (алғашқы және расталған), не істелмеді
• әрекеттер: шұғыл не істелді және тұрақты түрде не түзету қажет
• сабақ: бақылаулар мен нұсқаулықта не өзгерту керек

Жұмыс циклі қысқа болуы тиіс: тіркеу, тергеу, түзетуші әрекеттер, әсерді тексеру, жабу және байланысты тәуекелді жаңарту.

Инциденттер бағалауды жылжытуы тиіс: қайталанса ықтималдықты жоғарылату, зиянды нақты фактілерге сүйене отырып нақтыландыру, жоспарлар мен бақылауларға талаптарды өзгерту. Сол кезде реестр компанияның қай жерде ақша және уақыт жоғалтып жатқан жерінің жұмыс картасы болады.

KPI және KRI байланысы: жалпыламай, өлшенетін болсын

Жүйе «қауіптер туралы кесте» емес болғанда әр тәуекелдің өлшенетін сигналдары мен айқын динамикасы болады. Бұл үшін екі топ метрика керек: KRI (тәуекелдің ерте индикаторлары) және KPI (нәтиже немесе іс-әрекетті орындау көрсеткіштері).

KRI «тәуекел жақындап келе ме?» дегенге жауап береді. Оларды порогтар мен трендтер ретінде қойыңыз, өлшеу жиілігі түсінікті болуы тиіс: критикалық сервистер үшін күнделікті, уязвимділіктер үшін апталық, кадрлық пен қаржылық факторлар үшін айлық. KRI оқиғаға дейінгі белгі болуы керек, «өрттен кейін есеп» емес.

Байланыс әдетте мынадай: тәуекел -> KRI (оқиғаға дейін өсетін нәрсе), бақылау -> KPI орындау (бақылауды уақытында орындаймыз ба), әрекет жоспары -> прогресс KPI (мерзім мен әсер бойынша үлгеріп жатырмыз ба). Осылайша карточка бағалау ғана емес, сонымен қатар «пульс» көрсетеді.

ИТ пен операцияларда жиі қолданылатын метрика мысалдары:

• критикалық сервистердің SLA: SLA шегіндегі уақыт үлесі және орташа қалпына келтіру уақыты (MTTR)
• инцидентке реакция уақыты: жұмыс басталғанға дейінгі медиана және регламент бойынша эскалацияланған инциденттердің үлесі
• патчтар: мерзімінде жаңартылған жүйелер пайызы және мерзімі өткен критикалық уязвимділіктер долясы
• бэкап: сәтті аяқталған бэкаптар пайызы және қалпына келтіру тексерісінің нәтижелері
• жоспарлар: әрекет жоспарындағы тапсырмалардың мерзімінде жабылу пайызы және иелер бойынша мерзімі өткендер саны

Әр метриканын иесі және дерек көзі болуы тиіс: мониторинг пен Service Desk, уязвимділік есептері, бэкап журналдары, тапсырма жүйелері немесе міндетті тексерілген қолмен енгізу. Әйтпесе KPI мен KRI тез «әдемі сандарға» айналып, оларға сенім жоғалады.

Қадамдық: ERM жүйесін нөлден қалай жобалау керек

Экраннан емес, келісімдерден бастаңыз. Жүйе практикалық сұраққа жауап беруі тиіс: қай тәуекелдер мақсаттарға кедергі келтіреді, кім жауапты және жағдай нашарлаған кезде не істейміз.

1. Негізді қалыптастырыңыз: мақсаттар, тәуекел категориялары (қаржы, ИТ, операциялық, комплаенс), ықтималдық пен әсер шкалалары, тәуекелге төзімділік порогтары және эскалация триггерлері.

2. Деректер мен байланыстарды сипаттаңыз. Әдетте бес субъект жеткілікті: тәуекел, бақылау, әрекет жоспары, инцидент, метрика (KPI/KRI). Олардың қалай байланысты болатынын бірден шешіңіз: бір тәуекелде бірнеше бақылау мен жоспар болуы мүмкін, ал инцидент бір немесе бірнеше тәуекелге жатуы мүмкін.

3. Реестр тірі болу үшін процестерді бекітіңіз: құру және бастапқы бағалау, иесін және бақылауларды бекіту, күнтізбелік және оқиғаларға байланысты тұрақты қайта қарау, порогтардан асқанда эскалация, жабу немесе бақылауға енгізу.

4. Рөлдер мен қолжетімділікті анықтаңыз: тәуекел иесі, тәуекел-координатор, контролер, бекітуші. Өзгерістер журналы, қайта бағалау комментарийлері және шешімдер тарихы пайдалы болады.

Пилотты тәуекелдер сезілетін 1–2 процессте іске қосыңыз (мысалы, критикалық ИТ-сервис немесе сатып алулар). 3–4 аптадан кейін фактілерді жинаңыз: қай өрістер толтырылмайды, қандай жерде келісу баяулайды, қандай хабарламалар шынымен қажет және модельді нақты жұмысқа қарай түзетіңіз.

ERM енгізгенде жиі кездесетін қателіктер

Ең жиі қате — тәуекелді бұрын болған проблемамен шатастыру. Реестрге «сервер құлады» немесе «жеткізілім мерзімі өтті» сияқты жазбалар түседі, бірақ қайталану шарттары, себептер және шаралар жоқ. Мұндай тізім шағымдар журналына айналады.

Екінші себеп — бағалауларға нақты критерийлердің болмауы. Бір басшы ықтималдыққа «4» қояды, себебі «жиі сияқты», ал екіншісі «2» қояды, өйткені «өткен жылы болған жоқ» — матрица болжам ойынына айналады. Анық шкалалар, мысалдар мен аппетит порогтары қажет.

Үшінші қате — иесі және мерзімсіз жоспарлар. Егер карточкада жауапты және бақылау күні болмаса, әрекеттер жылдар бойы "атқарылады" күйінде тұра береді.

Тағы бір ығыс — тек присущий тәуекелді есептеп, бақылаулардан кейінгі остаточный көрсеткішті көрсетпеу. Бұл басқарманы қорқытады және артық жобаларға әкеп соғуы мүмкін, ал шын мәнінде жағдай бақылауда болуы мүмкін.

Соңында, метрикалар көбіне шешімдерден бөлек тұрады: KPI мен KRI бар, бірақ олар бюджеттік және тапсырма приоритеттерін өзгертпейді.

Қысқа тексеріс парағы: реестр мен процестер сапасының 10 минуттық чек-листі

Егер реестр толтырылса да пайдаланылмаса, мәселе әдетте формада емес — тәртіпте: кім жаңартады, қашан және қандай оқиғаларға сүйенеді.

5 тексеріс, 10 минут ішінде

Соңғы тоқсан бойынша реестрді қараңыз:

• әр карточкада иесі көрсетілген (лауазым бойынша), келесі қайта қарау күні және ағымдағы статус бар
• "қызыл" тәуекелдерге мерзімді және жауапты бар немесе тәуекелді қабылдау туралы жазбаша шешім бар
• әр маңызды тәуекелге кем дегенде бір бақылау тағайындалған және оның қаншалықты жұмыс істейтіні көрсетілген
• инциденттер тәуекелдерге байланған және карточка деректерін шын мәнінде өзгерткен (деңгей, ықтималдық, зиян, жоспар статусы)
• шағын метрикалар жиынтығы бар (әдетте 5–10) және оларды жаңарту кестесі

Процесс жұмыс істейтінінің белгісі

Бір жақында болған инцидентті (мысалы, критикалық сервистің 2 сағаттық тоқтауы) алып қарайық. Егер тез жауап бере алмасаңыз: қай тәуекел іске асты, қай бақылаулар тоқтатпады, қай KPI/KRI өзгерді және әрі қарай не істеледі — онда реестр шындықпен байланыста емес.

Жақсы мақсат бастау үшін: ай сайын басшы 10 негізгі тәуекелді ашып, иелерді, әрекеттерді, фактілерді (инциденттер) және сандарды (метрикалар) қосымша қоңыраусыз көруі керек.

Мысал сценарий: критикалық сервистің тоқтауы және бұл қалай ERM-ге түседі

Мысалы: ұйымда пациенттерді жазу немесе төлем қабылдау сияқты критикалық сервис бар. Ол сервер бөлмесіндегі серверде жұмыс істейді. Қуат блогының немесе дискілік подсистема ақауынан сервис 2 сағат тоқтайды.

Жүйеде бұл алдымен тәуекел ретінде, кейін инцидент ретінде көрініс табады, ол бағалау мен жоспарларды нақтылайды.

Тәуекел карточкасында қалай көрінеді

Карточка әлі орын алмаған оқиғаны сипаттайды:

• оқиға: жабдық ақауынан критикалық жүйенің тоқтауы
• себеп: бөлшектердің тозуы, қызу, техникалық қызмет көрсету қателері, запчастьтардың жоқтығы
• салдарлар: сервистің тоқтауы, кіріс жоғалу, SLA бойынша айыппұлдар, репутациялық зиян
• присущий тәуекел: бақылауларсыз ықтималдық пен зиян
• остаточный тәуекел: ағымдағы бақылаулардан кейінгі бағалау

Бақылаулар тәуекелмен байланыстырылады: не ықтималдықты немесе зиянды төмендетеді — мониторинг (температура, дискілер, қуат), резервтеу (RAID, қосымша қуат блогы, кластер), регламенттер және қалпына келтіру тесттері.

Инцидент және KPI/KRI байланысы

Тоқтау орын алғанда инцидент жазылады, тәуекелге байланады: тоқтау фактісі мен ұзақтығы, тікелей зиян, зардап шеккен процестер, бастапқы себеп (мысалы, қуат блогының сәтсіздігі және запас бөлшектердің болмауы), түзетуші әрекеттер (ЗИП сатып алу, резервтеу схемасын өзгерту, температура бақылауын күшейту) және жауаптылар мерзімдерімен.

Реестр «тірі» болсын десеңіз, метрикалар тұрақты жаңартылып отыруы керек:

• KPI: сервистің қолжетімділігі (%), орташа қалпына келтіру уақыты (MTTR)
• KRI: мониторингте табылған критикалық ескертулер саны, қалпына келтіру тесттерінің сәттілігі пайызы, мерзімі өткен жаңартулар пайызы

KRI нашарласа, тәуекел қайта қаралады, әрекет жоспарлары нақтыланады.

Келесі қадамдар: пилот, есеп беру және енгізуді қолдау

Алғашқы 4–6 апта пилот ретінде жүргізілуі тиіс: мақсат — "бәрін енгізу" емес, жүйенің басшылыққа түсінікті шешімдер беріп, командаларға тезірек әрекет етуге көмектесетінін дәлелдеу.

Бастапқы жиынтығын қарапайым ұстаңыз: бірегей шаблондар (тәуекел, бақылау, жоспар, инцидент, метрика), тағайындалған иелер және ең кемі 3 айға арналған қайта қарау күнтізбесі. Пилот қайда тұратынын алдын ала шешіңіз: тәртіп болса, кесте жеткілікті; егер құқықтар мен өзгеріс журналдары маңызды болса, корпоративтік платформа қажет.

Келесі анықтайтын нәрсе — есеп беру. Бір беттің 1–2 парақтан тұратын пакетін жасаңыз және оны кестеге сай шығарыңыз (мысалы, айына бір рет): остаточны деңгей бойынша топ-10 тәуекел және не өзгерді, мерзімі өткен жоспарлар себептерімен, негізгі KRI трендтері және порогтардың бұзылуы, кезеңдегі 3–5 инцидент және олар қандай тәуекелдерді растады.

Егер ERM үшін платформа, құқықтар, интеграциялар және аналитикалық есептер керек болса, бұл жиі инфрақұрылым мен қолдауға тіреледі. Мұндай тапсырмаларда жүйелік интегратор ретінде GSE.kz (gse.kz) көмектесе алады: олар ИТ-орта жобалайды және қолдайды, серверлер мен жұмыс станцияларын сенімділік және сатып алу талаптарына сай жергілікті өндірілген қатарлардан таңдауға болады.