Жабдықты жеткізу және енгізу жобасындағы жауапкершілік матрицасы

Неге тапсырмалар тараптар арасында тұрып қалады

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

Жабдықты жеткізу және енгізу жобасында мұндай болатын жерлер көп. Сатып алу — келісімшарт пен жеткізу мерзіміне жауапты, ИТ — сәйкесдік пен жүйеге енгізуге жауапты, ақпараттық қауіпсіздік (АҚ) — қауіпсіздік талаптарына, интегратор — баптауға, сервис — іске қосқаннан кейінгі қолдауға жауапты. Осы ролдер түйісетін жерінде анық иеленуші болмаса, мәселе шеңбер бойымен жүріп жатады.

Тек хат алмасу бұл мәселені шеше алмайды. Электрондық пошталар мен чатта талқылау көрінеді, бірақ кім шешім қабылдайтыны, кім келісетінін, кім тек ақпараттандыратынын анық білінбейді. Мерзімдер қысылған кезде хабарлар бір-біріне іле-сала жіберіле береді, бірақ жауапкершілік соның арқасында көбеймейді.

Көбінесе мерзімдер мен шешімдер төрт жерде жоғалады:

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

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

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

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

Жобаға кім қатысады және не үшін жауапты

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

Типтік жобада әдетте бес тарап қатысады.

• Сатып алу таңдау рәсімін, келісімшартты, жеткізу мерзімдерін, құжаттар топтамасын, кепілдікті және тараптардың формалды міндеттемелерін жүргізеді. Олар жүйені баптамайды, бірақ дәл осы жерде жеткізу, монтаж, ауыстыру және сервис мерзімдері бекітілуі тиіс.
• ИТ-командасы техникалық талаптарды қалыптастырады және шешімнің ағымдағы инфрақұрылымға сай келетінін тексереді. Бұл жаққа көбінесе үйлесімділік, енгізу жоспары, рұқсаттар, техникалық қабылдау және эксплуатацияға беру жүктеледі.
• Ақпараттық қауіпсіздік (АҚ) тәуекелдер мен қауіпсіздік ережелері үшін жауап береді. Мұнда рұқсаттарды келісу, желілік саясаттар, антивирус, журнал жүргізу, шифрлау және басқа да талаптар кіреді — бұларсыз іске қосу тоқтап қалуы мүмкін.
• Интегратор енгізудің практикалық бөлігін орындайды: жабдықты орнатады және баптайды, оны бар ортаға қосады, тесттер жүргізеді, іске қосу кезеңіндегі ескертулерді жояды.
• Сервис және қолдау енгізгеннен кейін әсіресе маңызды. Олардың аймағына пайдаланушы өтініштері, кепілдік жөндеу, бөлшектерді ауыстыру, профилактика, выезд, қашықтан диагностика және айқын эскалация жолдары кіреді.

Қай жерде жиі шекаралар шатасады

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

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

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

Матрица не шешуі тиіс

Жауапкершілік матрицасы — әр кезең бойынша алдын ала кім не істейтінін, кім шешім қабылдайтынын және жұмыс тұрып қалған жағдайда кімге жүгінетінін жазып қойған қарапайым кесте. Оның мақсаты — сұрақтардың сатып алу, ИТ, АҚ, интегратор мен сервис арасында "жүзбеуін" қамтамасыз ету.

Оның негізгі пайдасы формада емес, түсініктілік пен айқындықта. Техника келгенде, баптау басталғанда, қауіпсіздік бойынша ескертулер пайда болғанда немесе мерзімдер бұзылғанда командаға "кімнің аймағы" дегенге таласудың қажеті болмайды. Жауапты тұлға алдын ала белгіленген.

Ролдерді шатастыруға болмайды. Орындаушы жұмысты істейді: ОС орнатады, желіні тексереді, жеткізуді рәсімдейді, бөлшекті ауыстырады. Жауапты адам нәтиже үшін жауап береді: тапсырманы соңына дейін жеткізуі тиіс, тіпті өз қолымен бәрін жасамаса да. Келісуші шешімнің әрі қарай өтуіне рұқсат береді. Мысалы, АҚ рұқсаттарды бекітеді, сатып алу келісімшарт бойынша орынбасарлықты мақұлдайды.

Қарапайым түрде матрица алдын ала төрт сұрақты шешуі тиіс:

• кім әрекетті бастайды
• кім жұмысты орындайды
• кім нәтижені қабылдайды
• дау немесе ауытқушылық болғанда кім шешім қабылдайды

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

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

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

Матрицаны кезең-кезеңімен қалай жасауға болады

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

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

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

Рөлдерді қалай бөлу керек

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

Ыңғайлы тәртіп:

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

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

Простой тест бар. Матрицаны оны жасамаған адамға беріңіз. Егер ол бір минут ішінде кім қадам жасайтынын, кім нәтижені бекітетінін және жұмыстың келесі қадамға кімге берілетінін түсінсе — схема жұмысқа жақын. Егер "әдетте басқа тарап жасайды" сияқты фразалар қалса, матрицаны нақтылау қажет.

Жабдықты жеткізу, енгізу және қолдау үшін шаблон

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

Егер сіз IT-жобаға RACI қолдансаңыз, кезеңнің иесін A ретінде қарастыруға болады. Орындаушылар R, келісушілер C, хабарланатындар I ретінде жазылады. Бірақ толық RACI кестесі болмаса да, әр кезеңге бір жол жазу да дауларды айтарлықтай азайтады.

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

Қай жолдарды бөлек қосу қажет

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

Кіші команда үшін шаблонды үш блокқа дейін оңайлату керек: тапсырыс беруші, ИТ/АҚ, мердігер. Бірақ ереже сол: әр тапсырмаға бір иесі, бір анық нәтиже және бір эскалация мерзімі болуы тиіс. Әйтпесе қарапайым жұмыс орнын ауыстыру да ұзын хат алмасуға айналады.

Нақты сценарийге мысал

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

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

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

Бөлек блок — рұқсаттар мен АҚ талаптары. Ақпараттық қауіпсіздік қызметін техника келгеннен кейін ғана қосуға болмайды. Олар алдын ала саясаттарды келіседі: кім жергілікті түрде жұмыс істеуі мүмкін, VPN қажет пе, қандай USB-порттар құлыпталатындығы, пароль, пошта және қашықтан қолжетімділік ережелері. ИТ бұл баптауларды енгізеді, ал интегратор оларды өз бетімен өзгертпеуі тиіс.

Іске қосу сәтінде кім жауапты

Эксплуатацияға беру ауада қалмауы тиіс. Тапсырыс беруші, әдетте ИТ арқылы, жұмыс орны пайдалануға дайын екенін растайды. Интегратор техника орнатылып, іске қосылғаны үшін жауапты. Вендор немесе сервис серіктесі жабдықтың кепілдік ақаулары үшін жауапты.

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

• ПК қосылмайды — сервис немесе жабдық жеткізуші
• желі бар, бірақ жүйелерге қолжетімділік жоқ — ИТ және АҚ
• қажет ПО орнатылмаған — ИТ немесе интегратор (кім образды дайындағанына байланысты)
• басқа модель немесе комплект жетіспейді — сатып алу және жеткізуші
• жұмыс орны қате жинақталған, монитор немесе периферия қосылмаған — интегратор

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

Жиі қателіктер және даулы аймақтар

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

Ең жиі дау былай шығады: "біз бұл жұмысты басқа тарап жасайды деп ойладық". Егер бір тапсырмада бірнеше "жауапты" болса, іс жүзінде жауапты жоқ болады. Біреу келіседі, екіншісі қатысады, үшіншісі хат күтеді, ал мерзім оттайды.

Қай жерде жиі дау туындайды

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

Екінші қате — АҚ-ты кеш қосу. Қауіпсіздік қызметі сатып алудан кейін немесе тіптен монтаждан кейін қосылғанда образдар, рұқсат ережелері, журнал жүргізу немесе желілік шектеулер келісілмеген болып шығады. Сол кезде ИТ сатып алуды айыптайды, сатып алу — интеграторды, ал жоба уақыты шығындалады.

Үшінші мәселе — сервис тек даудан кейін есіне түседі. Ақау болмайынша, ешкім өтінішті кім қабылдайтынын, бастапқы диагностика кім істейтінін, бөлшектерді кім ауыстыратынын және жүйенің толық қалпына келгенін кім растайтынын анықтамайды. Соңында инцидент ішкі ИТ, мердігер және сервис арасында тұрып қалады.

Кепілдік және ақылы жұмыстарды араластыру да даулардың көзі. Мысалы, сервер орнатылды, кейін қайта баптау немесе басқа шкафқа ауыстыру қажет болды. Тапсырыс беруші бұл кепілдікке кіреді деп ойлайды, мердігер — бөлек қызмет деп есептейді. Егер шекара алдын ала жазылмаса, дау почти міндетті.

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

Алдын ала не нәрсеге тоқталу керек

Бастамас бұрын бес нүктені тексеріп алған жөн:

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

Егер бұл мәселелер алдын ала шешілсе, дау туындайтын жағдайлар айтарлықтай азаяды. Ал дау болса да, команда хат алмасып кінә іздемейді — шешім рөлдер мен процеске сәйкес алдын ала бекітілген болады.

Жоба басталмас бұрын қысқа чек-лист

Тіпті жақсы матрица формальды бекітілсе және бірінші сәтсіздіктен кейін ғана ашылса көмектеспейді. Бастамас бұрын бірнеше пункттен тез өтіп, сұр аймақтарды жою дұрыс.

Міндетті чек-лист:

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

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

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

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

Схема жұмыс істеуі үшін келесі қадамдар

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

Ол жасалмаса, құжат формализмге айналады. Практикада команда қайтадан кім өтініш ашатынын, кім ауыстыруды келісетінін және іске қосу кешігуіне кім жауапты екенін талқылайды.

Дереу не бекіту керек

Матрицаны бекіткеннен кейін қысқа жалпы ролдерді талқылау жүргізіңіз. Әдетте 30–40 минут жеткілікті, бірақ кездесуге негізгі қатысушылар болуы тиіс: сатып алу, ИТ, АҚ, интегратор, сервис және қажет болса бизнес-тапсырыс беруші.

Осындай талқылауда кестенің барлық жолымен емес, ең тәуекелді сәттер арқылы өту жақсы:

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

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

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

Қашан схеманы қайта қарау керек

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

Күрделі жобаларда серіктестің ішкі құрылымымен ролдерді алдын ала салыстыру пайдалы. Егер серіктестің өз өндірісі, интеграция және сервисі бар болса, GSE.kz мысалы сияқты, бұл кезеңдерді матрицада айқын көрсету керек, жалпы формулировкаларда қалдырмау қажет.

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