Мемлекеттік органдағы IT жаңғыртуға арналған RACI‑матрицасы: рөлдер мен мерзімдер

Неліктен IT жаңғырту жобаларында «ешкімнің» тапсырмалары пайда болады

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

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

Көбіне «ешкімнің» болып қалатындар: бастапқы деректерді дайындау (бөлмелер жоспарлары, жұмыс орындарының тізімі, ИБ талаптары), қолжетімділіктер мен жұмыс терезелері (өту рұқсаттары, сопровождение, өшірулер), жұмыстардың шекаралары (СКС, желі, сервер бөлмесі, электр) және сынақ хаттамалары, актілер мен орындау құжаттары. Әсіресе пилоттан кейін және финалдық қабылдауға дейінгі түзетулер — жоғары тәуекел аймағы: бәрі оны жасау керектігін түсінеді, бірақ «иесі» белгіленбеген болады.

Жиі кездесетін қателік: «жауапты адамдар тізімі» бар, бірақ ол басты сұраққа жауап бермейді — кім шешім қабылдайды және нәтиже үшін кім жауапты. Сондықтан RACI қажет: ол қатысудың түрлері бойынша рөлдерді бөледі. Кім жұмысты орындайды, кім нәтиженің жауапкершілігін алады, кімді міндетті түрде сұрау керек (мысалы, ИБ), ал кімді тек хабардар ету керек. Осылай әр тапсырмаға иесі пайда болады, ал жобада интегратор бірнеше мердігерді тартса да шешім қабылдау логикасы түсінікті болады (мысалы, GSE.kz қатысса да).

Жоба қатысушылары және әдетте жауап шекаралары қай жерде өтеді

IT жаңғыртуға әдетте 4–6 тарап қатысады. Мәселе сол «арада» ешкім жауапты болмайтын жерлерде басталады: кім бөлмеге қолжетімдікті береді, кім трассаларды келіседі, кім қабылдауға дайындықты растайды.

Тапсырыс беруші жағында көбіне бірнеше рөл болады. IT‑қызмет мақсаттарды құрастырады, архитектура бойынша шешім қабылдайды және нәтижені қабылдайды. Сатып алу бөлімі келісімшарттар мен жеткізілім мерзімдерін бақылайды. Қызмет көрсету мен эксплуатация бөлмелер, қуат, ғимаратқа кіру және кейін жабдықты кім қарайтыны үшін жауап береді.

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

СКС мердігері әдетте физикалық жұмыстарға жауапты: трассалар, лотоктар, шкафтар, розеткалар, маркировка, өлшеулер және соңғы хаттамалар. Бірақ оның нәтижесі жиі смежниктерге тәуелді: бөлмелерге қолжетімділік, өрт қауіпсіздігі талаптарымен келісімдер, жұмыс уақытындағы шектеулер.

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

«Ешкімнің» аймағы болмас үшін стыктарды алдын ала келісіңіз:

• бөлмелерге қолжетімділік, пропуск тәртібі, жұмыс терезелері;
• СКС схемасын және қосылу нүктелерін кім келісетіні;
• баптау үшін есептік жазбаларды және қолжетімділіктерді кім береді;
• өлшеу хаттамаларын және орындау құжаттамасын кім қабылдайды;
• қабылдауға дайындықты кім растайды.

Оңай мысал: СКС монтаждалған, бірақ сервер бөлмесі қуат бойынша дайын емес, ал ИБ желіге қосуға рұқсат бермей отыр. Егер осы тармақтар RACI‑де иесі көрсетілмесе, монтаж мінсіз болғанымен мерзім бұзылады.

RACI‑ге не жазу керек: тапсырмалар, шешімдер және нәтижелер

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

Жобада болуы тиіс артефакттардан бастаңыз. Бұл тек финалдық қабылдау ғана емес, келесі кезеңнің тоқтамауына қажет аралық нәтижелер: тексеру есебі, келісілген ТЗ, жобалық құжаттар жинағы, сатып алу спецификациялары, сынақ актілері, орындау құжаттары.

Содан кейін жобаны кезеңдерге бөліп, әр кезеңге негізгі тапсырмаларды жазыңыз. Әдетте бес кезең жеткілікті: тексеру, жобалау, сатып алу, енгізу, қабылдау. Тапсырмаларды осылай тұжырымдаңыз, олар өлшенетін нәтиже беретіндей: «СКС‑тың бөлмелер мен қосылу нүктелері келісілді» деген сияқты, «СКС‑ты зерттеу» емес.

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

Әр жолда мынадарды бекіту пайдалы:

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

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

R, A, C, I қарапайым тілмен

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

R (Responsible) — орындаушы. Нақты жұмысты орындайтын: ТЗ жазады, кабель тартады, сервер баптайды, акт дайындап, келісім үшін құжат жинайды. R бірнеше болуы мүмкін, егер тапсырма үлкен болса.

A (Accountable) — нәтиженің иесі. Ол нәтижені қабылдайды және тапсырманы соңына дейін жеткізгені үшін жауап береді. Негізгі ереже: әр тапсырмаға бір ғана A болуы тиіс. Әйтпесе шешім екі басшының арасында ілініп қалады.

C (Consulted) — міндетті түрде алдын ала сұралатындар. Олардың талаптары орындау әдісіне әсер етеді. Мысалы, ИБ қызметін уақытында қоспасаңыз, кейін тыйымдар мен қайта жұмысты көруге тура келеді.

I (Informed) — хабардар болушылар. Оларды шешімдер үшін сұрамайды, бірақ факт бойынша немесе бақылау нүктелерінде хабардар етеді: бөлім басшысы, бухгалтерия, эксплуатация қызметі.

Анықтау сұрақтары:

• R: «Кімдікі орындалу?»
• A: «Кім қабылдайды және кейін кімнен сұрайды?»
• C: «Кімді алдын ала сұрау керек, қайта істемес үшін?»
• I: «Кімді статус туралы хабардар ету маңызды?»

Мысал: «Жаңа сервер бөлмесіне серверлерді қосу схемасын дайындау және келісу». R — интегратор (схеманы дайындайды), C — ИБ және эксплуатация (талаптарын береді), A — тапсырыс берушінің жоба менеджері (бекітеді), I — департамент басшысы (бақылау нүктесінде статус алады).

RACI‑ні бір жұмыс кездесуде қалай жинау қажет

60–90 минуттық бір кездесу әдетте матрицаны теориядан жұмыс құралына айналдыруға жеткілікті. Қатысушылар ретінде нақты шешім қабылдайтын және жұмысты орындайтындарды шақырыңыз: тапсырыс беруші (процестің иесі), интегратор, СКС мердігері, ИБ және эксплуатация.

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

Талқылауға ыңғайлы тәртіп:

1. Жобаның шекарасын және кезеңдер бойынша нәтижелер тізімін бекіту.
2. Тапсырмаларды жоғарыдан төмен қарастырып, R (орындаушы) және A (бекітуші) тағайындау.
3. C (кеңесшілер) және I (хабарландырулар) қосу.
4. Формалды құжат немесе қол қою қажет жерлерді белгілеу.
5. Матрицаны кім жүргізетіні және өзгертулер қалай енгізілетінін келісу.

Арнайы стыктарды талқылаңыз: кім пропуск пен сопровождение сұрауын бастайды, кім уақытша сегмент өшіруін келіседі, СКС жұмыстарынан кейін порт схемасын кім әзірлейді, қабылдау пакетін кім жинайды.

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

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

IT жаңғырту кезеңдері бойынша рөлдерді бөлу шаблоны

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

Рөлдер (матрицада қалай атайды)

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

Кезеңдер бойынша шаблон (ең аз қажетті элементтер)

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

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

Матрицаға енгізілетін тапсырмалар мысалы: СКС, ИБ, желі, серверлер, қабылдау

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

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

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

Қабылдауға матрицада тек «сынақтар өткізу» емес, нақты мыналар енгізілуі тиіс:

• сынақ сценарийлері және «қабылданды/қабылданбады» критерийлері;
• комиссия құрамы және хаттамаға жауапты;
• стенд, қолжетімділіктер және тест деректерін кім береді;
• кемшіліктерді кім және қандай мерзімде жояды;
• финалдық актіні кім қояды.

Егер жобаға жүйелік интегратор қатысса, өзгертулер журналы мен сұрақтарды жинау бір орынға бекітілсін. Бұл СКС, желі, серверлер және ИБ әртүрлі чаттар мен мерзімдерге ыдырап кетпеуі үшін маңызды.

RACI‑ны жобалық құжаттарда және күнделікті жұмыста қалай бекіту

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

ТЗ‑ға, жоспар‑графикке және қабылдауға енгізу

Пайдалы тәсіл — RACI‑ны адамдарға байлаудың орнына рөлдерге байлау және рөлдерді тексерілетін нәтижелерге бекіту. ТЗ мен жоспар‑графикте әр жұмыстың жанында: кім дайындайды (R), кім бекітеді (A), кімді міндетті түрде сұрау керек (C) және кімді хабардар ету қажет (I) деп көрсетіңіз.

Әдетте төрт жерде бекіткен жеткілікті:

• ТЗ: әр нәтиженің (схема, акт, есеп, конфигурация) жанында A және қабылдау критерийлері көрсетіледі.
• Жоспар‑график: әр тапсырмада «A (утверждает)» өрісі және мерзім қауіп астында болғанда эскалация ережесі болады.
• Келісімшарттар мен қосымшалар: A жауапкершілігін этаптар мен қабылдау шарттарымен байланыстыру.
• Қабылдау хаттамалары: рөлдер мен финалдық қол қою құқығын алдын ала жазып қою.

Тағы бір ереже: әр нәтиженің тек бір A‑сы болуы тиіс. Егер екі адам бекіте алатын болса, шешім ілініп қалады.

Өзгерістерді басқару және күнделікті коммуникация

Өзгерістер мерзімдерді жұмсауын болдырмау үшін қарапайым схеманы келісіңіз: өзгеріс инициаторы өтініш жазады (R), интегратор әсерін бағалайды (R/C), тапсырыс беруші мақұлдайды немесе кері қайтарады (A), ИБ тек тәуекелге әсер ететіндерді келіседі (C), қалғандары хабарландырылған болады (I).

Статус үшін қысқа ырғақ пайдалы:

• аптасына бір рет: этаптар бойынша жалпы статус, тәуекелдер және шешімдер A‑ларға;
• аптасына 2–3 рет: критикалық жұмыстар бойынша жұмыс статусы (СКС, желі, серверлер);
• блоктау күні: «не тоқтап тұр, кім A, қандай уақытқа дейін шешім керек» деп хабарландыру;
• шешімнен кейін: хаттамаға жазып, жоспар‑графикті жаңарту.

Егер ИБ доработку талап етсе және мерзімдер қысқа болса, барлық жұмыстарды тоқтатпаңыз. Ағынды бөліңіз: қауіпсіздікке әсер ететін тапсырмалар ИБ арқылы өтсін, ал параллельде қауіпсіз дайындық жұмыстары (жеткізу, монтаж енгізусіз, схемаларды рәсімдеу) орындалсын. Уақытша компромисс жазбаша бекітіліп, A мерзімін анықтасын.

Жиі кездесетін қателер: неге тапсырмалар жоғалып, мерзімдер бұзылады

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

Классикалық қате — бір тапсырмада бірнеше A болуы немесе A мүлде жоқ болуы. Егер «қабылдауды тапсырыс беруші де, интегратор да жүзеге асырады» деп жазсаңыз, дау туындағанда ешкім жауап бермейді. Әр нәтиженің бір A‑сы болуы және оның «принято/не принято» деп айтуға құқығы болу керек.

Екінші мәселе — ИБ‑ті кеш қосу. Финалда сегментация, журналдар, қолжетімділіктер, сертификаттар, домен баптаулары немесе СЗИ талаптары пайда болып, қабылдау блокталуы мүмкін. ИБ‑ны жобалау кезеңінде C ретінде қосып, өзгерістер туралы уақытылы хабардар етіңіз.

Үшінші қате — СКС: «кабель төсалды, значит дайын». Өлшеу хаттамалары, маркировка, схемалар және орындау құжаттары болмаса, объектіні тапсыру мүмкін емес, эксплуатация кейін жүйені ұстай алмайды.

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

Тапсырмалардың жоғалып жатқанын көрсететін белгілер:

• қабылдау критерийлері «жұмыс істеуі тиіс» сияқты жалпылама айтылады;
• тестілеу жоспарланбайды және ешкім қол қоймайды;
• жұмыс терезелері соңғы сәтте келісіледі;
• құжаттар кейінірек толтырылатыны туралы сөз болады;
• шешімдер иесіз хаттарда қабылданады.

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

Қысқа чек‑лист: RACI‑ның іске қосуға дайын екенін қалай тексеруге болады

Жұмысты бастамас бұрын матрицада «күлгін аймақтар» қалмағанын тез тексеріңіз:

• Әр нәтиженің жанында бір ғана A және нақты көрсетілген R бар.
• СКС, желі, ИБ және эксплуатация арасындағы стыктар жеке жолдарда айқын көрсетілген (мысалы: «порттарды маркировкалау және схемалар», «МЭ ережелері бойынша өтініштер», «сервер бөлмесіне қолжетімділік беру», «жұмыс терезелері және қалпына келтіру»).
• Қабылдау үшін міндетті құжаттар тізімі жасалған және әр құжатқа кім дайындайтыны, кім келісетіні және кім қол қоятын көрсетілген.
• Келісімдер үшін мерзімдер мен эскалация механизмі бар: егер C уақытында жауап бермесе, қандай әрекет болады.
• Өзгерістер болғанда RACI‑ны жаңарту ережесі бар: жаңа мердігер, жауапты ауыстыру, ауқымды кеңейту, ИБ талаптарының қосылуы.

Жылдам тест: 2–3 тәуекелді тармақты (мысалы, жаңа серверлерді енгізу, әрекет режиміндегі ғимаратта СКС‑ке қолжетімділік, ИБ‑пен келісім) таңдаңыз және қатысушылардан олардың нақты ненің «шығуы» керек екенін және мерзімін сұраңыз. Егер жауаптар матрицадағы мәліметтермен сәйкес келіп, «бұл біздің емес» деген жауап болмаса, жұмыс бастауға болады.

Егер интегратор жобаны басқарып жатса, матрицаның иесін бірден бекіткен дұрыс: кім түзетулер жинайды және әр өзгерістен кейін өзекті нұсқаны таратады. Үлкен жобаларда, интегратор жеткізу, енгізу және қолдауды бір циклмен жабатын болса, RACI‑ның иесі жобалық басқару жағында болуы логикалық: мысалы, GSE.kz өндіруші және жүйелік интегратор ретінде мердігерлерді үйлестіруді өз мойнына алса, RACI жүргізуді де өзіне бекітсе ыңғайлы болады.