Толық дайын жұмыс орындары бойынша келісім: жауапкершілік шекаралары

«Толық дайын жұмыс орны» деген не және қай жерде жиі дау туындайды

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

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

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

Простой мысал: қызметкерге жаңа ПК қойылды, Outlook қосылмайды. Мердігер: «пошта біздің аймақ емес», тапсырыс беруші: «жұмыс орны жұмыс істеуі керек». Мұндай дауды алдын ала келісімде профильді кім баптайтынын, рұқсаттарды кім беретіні және жұмыс қабілеттілігін кім растайтынын анықтасаңыз оңай шешуге болады.

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

Келісімнің пәнін қарапайым тілмен қалай жазу керек

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

Оңай әдіс — келісімнің мазмұнын рөлдер, жеткізу құрамы және анық «финиш» арқылы сипаттау.

Алдымен тараптар мен рөлдерді анықтаңыз. Әдетте тапсырыс беруші, мердігер/интегратор, жабдық өндірушісі және ПО вендорлары болады. Тіпті келісім бір мердігермен жасалған болса да, кім жабдық жеткізеді, кім енгізеді және лицензиялардың кімге тиесілі екенін нақты көрсету пайдалы.

Одан кейін нысанды өлшенетін өлшемдермен сипаттаңыз: жұмыс орындарының саны, түрлері, орындары, периферия және ерекше талаптар. Мысалы: 120 кеңсе ПК, 30 сенсорлы экранды моноблок, 10 инженерлік жұмыс станциясы, плюс принтерлер, сканерлер, гарнитуралар және 3 мекенжайға жеткізу.

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

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

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

Жауапкершіліктің қабаттары: жабдықтан бастап қолданбалы ПО‑ға дейін

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

Әдетте жеткілікті құрылым:

• Жабдық: ПК/монитор/периферия, кепілдік, сериялық нөмірлер, базалық тестілеу.
• BIOS/UEFI: нұсқалар, парольдер, Secure Boot/TPM, жүктеу тәртібі.
• ОС және базалық конфигурация: редакция, тіл, образ, есептік жазбалар, саясаттар.
• Драйверлер және жаңартулар: көздер, нұсқалар, жаңарту терезесі, қайта жүктеу ережелері.
• Қолданбалы ПО және пайдаланушы ортасы: бағдарламалар тізімі, нұсқалар, плагиндер, профильдер, ярлыктар.

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

Жеткізуге жатпайтын тәуелділіктерді де бөлек бекітіп қойыңыз: домен/AD, желі және VLAN, DNS/NTP, пошта, прокси, антивирус/EDR, DLP, басып шығару және принтер серверінің драйверлері. Олай болмаған жағдайда мердігер «баптаймыз» дейді, тапсырыс беруші «қол жеткізген жоқ» дейді және қабылдау тұра қалады.

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

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

ОС, драйверлер және жаңартулар: шекараны қай жерде өткізу

ОС‑қа қатысты ең жиі даулар «кім оны орнатуы керек және орнатудан кейін не бұзылса кім жауап береді» дегеннен басталады. Келісімде базалық конфигурация жеткізілімін және одан кейінгі қолдауды қай жерде бөлу керектігін алдын ала жазып қою қажет.

ОС: образ, редакция және активация

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

Редакция, тіл, разрядтылық, активация тәсілі (KMS, MAK, OEM) және кілттерді кім беретінін жеке жазып қойыңыз. Жиі қолданылатын схема: тапсырыс беруші лицензияларды және активация деректерін береді, мердігер орнатуды орындайды және қабылдау материалдарында активация фактісін растайды.

Драйверлер, патчтар және қауіпсіздік баптаулары

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

Жүйені қарапайым блокқа бөлу пайдалы:

• ОС: образты кім береді, редакция мен тілді кім бекітеді, орнатуды кім жасайды.
• Активация: кілттерді кім береді және сәтті активацияға кім жауап береді.
• Драйверлер: нұсқаларды кім таңдайды және типтік сценарийлерде (басып шығару, желі, дыбыс, камера) кім тестіледі.
• Жаңартулар: қабылдау күніне дейінгі қандай патчтар жеткізілімге кіреді, ал не SLA бойынша қызметке жатады.
• Қауіпсіздік баптаулары: саясаттарды кім бекітеді (шифрлау, қауіпсіздік агенттері), кім енгізеді және қандай енгізу «сәтті» деп есептеледі.

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

Қолданбалы ПО: тізім, нұсқалар, баптаулар және үйлесімділік

«Қолданбалы ПО орнату» келісімге кіргенде дау әдетте орнатудан емес, күткен нәтижеден туындайды: қандай нұсқалар қажет, қандай плагиндер міндетті, не «жұмыс істейді» деп есептеледі және үйлесімділік кімге жауапты.

ПО құрамын қалай сипаттау керек

Практикалық тәсіл — ПО тізімін пайдаланушы рөлдері бойынша бекіту (мысалы: бухгалтерия, қоңырау орталығы, инженерлер, басшылар). Сонда стандартты жиынтық (офис пакет, браузер, PDF) және арнайы қосымшалар айқын көрінеді.

Келісімде дистрибутивтерді кім береді, кілттер/жазылымдар кімге тиесілі, орнату орындарын кім тіркейді (қай ПК‑ге не орнатылған) және өзгерістерді (жаңарту, ауыстыру, жою) кім мақұлдайтыны көрсету ыңғайлы.

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

Үйлесімділік пен баптаулар

Алдын ала қолдау көрсетілетін нұсқалар тізімін және шағын пилотты келісіңіз: 1–2 жұмыс орнында қосымшаның іске қосылуын, басып шығару мен желіге қолжетімдігін, ЭЦҚ немесе сертификаттармен жұмысын тексеріңіз.

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

Лицензиялар және пайдалану құқығы: екі тарапқа да тәуекел тудырмау

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

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

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

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

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

Жұмыстың кезең-кезеңімен схемаcы: дайындықтан енгізуге дейін

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

Бастапқыда жоспарлаудан бастаңыз. Мердігер тапсырыс берушінің ортасын болжау мүмкін емес, сондықтан бастапқы деректерді алдын ала санап шығып, оларды беруге жауапты тұлғаны анықтаңыз: есептік жазбалар мен рөлдер (локальды немесе домендік), желі параметрлері (VLAN, DNS, прокси, Wi‑Fi, жаңартулар репозитарийіне қолжетімділік), ақпараттық қауіпсіздік талаптары (антивирус, шифрлау, USB‑қа шектеу, журналдар), ПО тізімі нұсқаларымен және дистрибутив көздерімен, жұмыс терезесі мен объектілерге кіру ережелері.

Содан кейін эталон жасалады. Мердігер «алтын образ» немесе орнату пакет жинайды: ОС, драйверлер, базалық баптаулар, қажетті агенттер және міндетті қосымшалар. Пилотты алдын ала анықтаңыз, мысалы, типтік бөлімдегі 3–5 жұмыс орны. Пилоттан кейін нұсқалар мен хэштер тіркеліп, тираждау қайталанатын болады.

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

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

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

Қабылдау артефактілері: тапсырыс берушінің қолында не қалуы керек

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

Минималды артефакт жиынтығын келісімшартта немесе оның қосымшасында бекіткен жөн:

• Жабдық реестрі: модель, конфигурация, сериялық нөмірлер, кепілдік, пайдалануға енгізу күні, әр жұмыс орнын қайда орнатқаны.
• ПО реестрі: не орнатылғаны, нұсқалары, қайдан алынғаны (дистрибутив), лицензияларды кім жеткізгені және қандай негізде қолданылатыны.
• Акттар мен хаттамалар: қабылдау актісі, келісілген тексерулер бойынша сынақ хаттамасы, ақаулар ведомостығы мен түзету мерзімдері.
• Эксплуатациялық құжаттар: пайдаланушыға қысқа нұсқаулық, әкімші нұсқаулығы, қалпына келтіру және жаңарту схемасы.
• Ақпараттық қауіпсіздік материалдары: қандай саясаттар қолданылғаны, қандай агенттер орнатылған (EDR, DLP және т.б.), қандай ерекшеліктер жасалған және оларды кім мақұлдағаны.

Кішкене мысал: мердігер 200 жұмыс орнын тапсырды, екі аптадан кейін бухгалтерия «басып шығармайды» деп шағымданады. Егер жабдық реестрі мен сынақ хаттамасы болса, қай драйвер және қандай принтер моделі тексерілгені көрініп, не табысты тест деп есептелгені анықталады. Дауды тез арада нақты жауаптыға айналатын тапсырмаға ауыстыруға болады.

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

RACI матрицасы: жауапкершілікті бекітуге қарапайым әдіс

Жұмыс орындары бойынша келісімде рөлдер анықталмаса, кез келген қате дау тудырады: «бұл сіздің аймақ» және «бұл біздің инфрақұрылымда». RACI матрицасы кім жұмысты орындайтынын (R), соңғы шешімді қабылдап жауаптыны (A), кеңес алатындарды (C) және хабардар ететіндерді (I) көрсетеді.

RACI‑ны жұмыс қабаттары бойынша құраңыз: ОС және образ, драйверлер, домен және есептік жазбалар, желі және Wi‑Fi, ақпараттық қауіпсіздік (антивирус, саясаттар, шифрлау), қолданбалы ПО, басып шығару және сканерлеу.

Жұмыс станциясы үшін мысал жолдары (қысқаша):

• ОС: орнату және баптау — R: мердігер, A: тапсырыс беруші, C: тапсырыс берушінің ақпараттық қауіпсіздік қызметі, I: қолдау қызметі
• Драйверлер: чипсет, видео, басып шығару — R: мердігер, A: тапсырыс беруші, C: өндіруші/вендор, I: пайдаланушылар
• Домен және рұқсаттар — R: тапсырыс беруші, A: тапсырыс беруші, C: мердігер, I: пайдаланушылар
• Тізім бойынша қолданбалы ПО — R: мердігер, A: тапсырыс беруші, C: қосымша иесі, I: ақпараттық қауіпсіздік
• Белгілі желіде басып шығару — R: тапсырыс беруші, A: тапсырыс беруші, C: мердігер, I: пайдаланушылар

RACI‑ны кезеңдерге байлаңыз: пилот (образ пен ПО нақты тапсырмаларда жұмыс істейтінін тексеру), тираждау (жаппай орнату және сериялық нөмірлерді тіркеу), қабылдау (чек‑тізім және артефактілер бойынша), кепілдік (кім инцидент қабылдайды, реакция уақыттары, не ақау саналады, не өзгеріс).

Ең құндысы — ерекшеліктер мен «күлгін аймақтарды» жазып қою. Мысалы: ОС жаңартулары қабылдаудан кейін кімнің міндетіне өтеді, драйвер мен корпоративтік ИБ саясаты арасындағы қайшылық болғанда қалай әрекет ету, қосымша сирек құқықтарды немесе ескі құрамдас бөлікті талап етсе не істеу. Формулировкалар айқын болсын: «мердігер X істейді Y жағдайында; егер Y болмаса жауапкершілік тапсырыс берушінің; мердігер Z күн ішінде консультация береді».

Егер жұмыс орындары дайын жабдық ретінде жеткізілсе (ПК, моноблок немесе VDI‑ге арналған серверлік бөлік), RACI аппарат пен инфрақұрылым шетінде әсіресе маңызды. Сонда өндіруші/интегратордың жауапкершілігі қай жерде аяқталатыны және тапсырыс берушінің ИТ‑қызметінің жауапкершілігі қай жерде басталатыны оңай келіседі.

Шынайы мысал: «жұмыс орны жұмыс істемейді» туралы қалай дау туындайды

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

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

Нені әдетте бұзады және шекара қайда орналасады

1. «ОС орнатылды, бірақ белсендірілмейді». Көп жағдайда мердігер ОС орнатады, бірақ кілт, KMS/MAK және активация серверіне қолжетімдікті тапсырыс беруші береді. Келісімде кілттер мен қолжетімдікті кім, қай мерзімде беретіні жазылмаса, жұмыс орындарының тұрауы тұр.

2. «Драйвер бар, бірақ периферия жұмыс істемейді». Мердігер келісілген модельдегі драйверлерді орнатуға жауапты, ал тапсырыс беруші сол модельдерді алдын ала тізімдеп, тест үшін қолжетімді етіп қоюы тиіс.

3. «Қосымша қателігі». Мұнда орнату — мердігердің, базалық баптау — ТЗ бойынша, лицензия — кім сатып алғаны және кімге берілгені, үйлесімділік — ОС пен тәуелді компоненттер нұсқаларымен шектелгені және ИБ‑шектеулер (EDR, ақ тізімдер) болуы мүмкін. Ақпараттық қауіпсіздік саясаттарын өзгертуге тек тапсырыс берушінің өкілі құқылы болуы тиіс.

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

Қабылдаудан кейінгі инциденттерді қалай рәсімдеу

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

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

Келісімдер мен ТЗ‑да жиі жіберілетін қателер, кейін қымбатқа түсетіндері

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

Жиі кездесетін қателер:

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

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

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

Қол қою алдында және қабылдаудан бұрын жылдам чек‑тізім

Келісімшартқа қол қою алдында қысқа тексеруді өткізіңіз. Ол мердігер ұсынуға тиіс нәрсені тапсырыс беруші өзінен бөлуге көмектеседі және қабылдаудағы дау қаупін төмендетеді.

Қол қою алдында келісімшарт пен ТЗ‑да мына нәрселердің нақты көрсетілгенін тексеріңіз:

• Жұмыс орнының құрамы қабаттар бойынша: жабдық, ОС, драйверлер, жаңартулар, домен/есептік жазбалар, желі, басып шығару, базалық ИБ саясаттары және қолданбалы ПО тізімі.
• Қай жағынан үйлесімділікке кім жауапты: мысалы, «1С/банк клиент» тек нақты ОС нұсқасымен жұмыс істей алады немесе антивирустың ерекшеліктерін қажет етеді.
• Өзгерістерді басқару қалай жүргізілетіндігі: образ нұсқалары, саясаттар, ерекшеліктер және көлем өзгерісі қалай келісілетіні.
• ПО лицензиялары: лицензия түрі, кімге рәсімделеді, қандай құжаттар тапсырылады және оларды кім ұстайды.
• Енгізуден кейінгі қолдау: қай жерге жүгінеміз, реакция уақыты, жұмыс терезесі, эскалация тәртібі және кепілдік жағдайы ненің қатарына жататыны.

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

Қабылдауда мына нәрселерді сұраңыз және тексеріңіз:

• Жабдық реестрі (сериялық нөмірлер, комплектация, кабинет/пайдаланушымен сәйкестендіру, қажет болса).
• Сынақ протоколдары мен актілер: доменге кіру, желілік ресурстарға қолжетімділік, басып шығару нақты принтермен, жаңартулар, ИБ‑тексеру.
• Орнатылған ПО тізімі нұсқаларымен және негізгі баптауларымен, соның ішінде ерекшеліктер мен рұқсаттар.
• Пайдаланушы мен әкімшіге нұсқаулықтар: қалай қалпына келтіру, қайта орнату, периферияны қосу және қайда хабарласу керек.
• Рұқсаттар мен парольдар: тиісті форматта сақталуы (мысалы, мөрленген конверт немесе корпоративті құпия менеджері арқылы) және меншік иесі көрсетілген.

Егер мердігер қызмет көрсетуді де өз мойнына алатын болса, қай өтініштер қолдау қызметі арқылы, ал қайсысы енгізу тобына өтетіні алдын ала келісілгеніне көз жеткізіңіз. Бұл тапсырмаларды тараптар арасында «салуды» қысқартады.

Келесі қадамдар: қалай дайындалу және жұмыс форматын таңдау

Алдын ала енгізілетін қысқа бастапқы деректерден бастаңыз. Компьютерде пайдаланушы қалай жұмыс істейтінін неғұрлым нақты сипаттасаңыз, қабылдаудағы тосынсыйлар азаяды. Міндетті және қалаулы талаптарды бірден бөліп қойыңыз.

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

Одан кейін үш негізгі қосымша құжатты келісімге тіркеңіз: қабаттар бойынша RACI, қабылдау критерийлері және қабылдау артефактілері тізімі (образдар, ведомосттар, актілер, нұсқаулықтар, лицензия есебі). Егер бұл қосымшада болмаса — дау мүмкіндігі жоғары.

Масштабтау алдында 2–5 жұмыс орнында пилот өткізіңіз. «Қиын» рөлдерді таңдап, нақты тапсырмаларды орындап, қысқа хаттама жасаңыз: не қабылданды, не жөнделуі тиіс, кім және қандай мерзімде.

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

Егер сізге жабдық жеткізу және енгізу қажет болса, әдетте циклды толық жабатын мердігерді таңдау ыңғайлы әрі кейін паркіні қолдау оңай болады. Мысалы, GSE.kz (gse.kz) Қазақстанда компьютелер, моноблоктар және серверлер шығарады және жүйелік интегратор ретінде қатысып, «темірді» жеткізу, енгізу және одан кейінгі қолдауды бір орында шеше алады.