Мемлекеттік ұйымдарға ПК сатып алу чек‑листі: құжаттар мен кепілдік

Неліктен чек‑лист қажет және қай жерде келіспеушіліктер жиі туындайды

Мемлекеттік ұйымдарға ПК сатып алу чек‑листі формальдылық үшін емес. Ол құжаттардағы түсініксіздіктерді алдын ала алып тастауға көмектеседі, осылайша сатып алуды қайта жіберіп немесе қабылдауда «түрлі түсіну» салдарынан даулар туындамайды.

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

Ескертулер мен қайтарулар әдетте өтініш немесе қабылдау алдында ұсақ көрінетін детальдардан туындайды. Типтік жағдайлар:

• ТЗ‑да «жаман емес» деп жазылған, бірақ қалай тексерілетіні көрсетілмеген;
• локалдық құрамға қойылатын талаптар бекітілмеген;
• алдын ала орнатылған ПО‑ға қатысты құжаттар ұмытылған;
• кепілдік жалпылама сөздермен жазылып, реакция мерзімі мен өтініш тәртібі анықталмаған.

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

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

Жеткізушіден сұралатын құжаттар: өтініш жасамас бұрын не жинау керек

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

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

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

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

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

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

Локалдық құрам мен шығу тегі: қалай дұрыс жазу керек

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

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

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

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

Локалдық құрамның үлесін және аралас шығу тегін қалай сипаттау керек

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

Импорттық компоненттер локальды жинау, тестілеу және кепілдік қызметімен үйлессе рұқсат етілгенін бөлек жазып қойыңыз — егер бұл сіздің ережелеріңізге сай болса. ПК үшін процессор мен жад импортталса, ал жинақтау мен сапа бақылауы жергілікті болса, бұл жиі қолданылатын модель.

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

ПК, моноблоктар және жұмыс орындарына арналған ТЗ қалай құрастыру керек

Чек‑лист нақты көмектесуі үшін ТЗ «орташа компьютер» емес, нақты жұмыс ролдеріне бағытталуы тиіс. Сонда жеткізуші міндетін түсінеді, ал қабылдау ұсақ детальдардан дау туындатпайды.

2–3 пайдаланушы профилінен бастаңыз. Мысалы: ЦОН немесе канцелярия операторы (типтік офис тапсырмалар), бухгалтерия (көп кестелер мен периферия), ауыр қолданбалармен жұмыс істейтін маман (жұмыс станциясы). Әр профиль үшін спецификацияда жеке позиция және сан көрсетіңіз.

Минималды параметрлерде не жазу керек

Брендке байламай, өлшенетін көрсеткіштер жазыңыз. Әдетте негізгі түйіндерді және жиі үнемдеу үшін қысқартылатын бөлшектерді көрсеткен жеткілікті: процессор классы/поколені немесе өнімділік деңгейі; ОЗУ көлемі және кеңейту мүмкіндігі; SSD және минималды көлем, қажет болса екінші диск ұясының болуы; желі (проводтық, қажет болса Wi‑Fi/BT), міндетті TPM/қауіпсіздік құралдары; порттар (міндетті USB түрлері, видео шығысы), картридер немесе COM — тек қажет болса; форм‑фактор және комплект (системный блок, мини‑ПК, моноблок, клавиатура/ышқан).

Моноблоктар алынса, экранды бөлек сипаттаңыз: диагональ, рұқсат, матрица түрі, реттеу мүмкіндіктері. Сенсорлықты тек нақты процесс талап етсе ғана сұраңыз.

Қолайлы үйлесімділік пен шектеулер

Техниканың қандай құрылғылармен «сыртқы конфигурациясыз» жұмыс істеу керек екенін жазыңыз: принтерлер, сканерлер, токендер мен ЭЦП, бар мониторлар мен док‑станциялар. Драйверлардың болуы және сіздің ОС‑ты қолдауы туралы талап қосу пайдалы.

Егер орын мен шудың шектеулері бар болса, өлшем/шулы деңгей талаптарын бекітіңіз. Қажет болмаса, артық талаптардан сақтаныңыз — олар жеткізушілер үшін себеп болады.

Мысалы: фронт‑офиске сенсорлы экранмен моноблок және токен ЭЦП‑мен сәйкестігі міндетті, ал серверлік бөлмеге — жұмыс станциясы позициясы, ОЗУ мен диск үшін резерв қалдырылған. Бұл ұсыныстарды салыстыруды және қабылдауды жеңілдетеді.

ПО және алдын ала орнату: қабылдауда дау болдырмау үшін

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

Лицензияларды нақты сипаттаңыз. «ОС Windows немесе эквивалент» деген жеткіліксіз. Лицензия түрін (OEM, қораптық, корпоративтік, жазылым), санын, байланысу түрін (құрылғыға немесе пайдаланушыға) және жеткізу кезінде берілетін құжаттарды көрсетіңіз. Практикада бастапқы құжаттар пакетiн, заңдылықты растайтын құжаттарды және кілттер/идентификаторлар тізімін талап ету ыңғайлы, егер бұл сіздің саясатыңызға сай болса.

Жүйе образы: барлық ПК‑да бірдей не болу керек

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

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

ПО‑ны қабылдауда қалай тексеруге болады

Акт қабылдауына қысқа тексерілетін тармақтар қосыңыз:

• ОС жүктеледі, тіл және редакция ТЗ‑ға сәйкес;
• офис пакеті орнатылған немесе орнатылым тапсырыс берушінің тарапынан орындалатыны көрсетілген;
• активация орындалған немесе активация тәртібі берілген;
• драйверлар орнатылған, белгісіз құрылғылар жоқ;
• лицензиялар мен орнатылған ПО тізімі тапсырылған.

Кепілдік және сервис: алдын ала бекітілген жақсы тармақтар

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

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

Договор мен қосымшаларда не жазу керек

Қысқа, өлшенетін формулировкалар тиімді:

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

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

Қандай растаулар мен есеп беру сұрау керек

Әдетте жеткілікті: өтініш формасы, диагностика актісі, жөндеу/ауыстыру актісі, сериялық нөмірлер көрсетілген құжаттар, өтініш жабылу мерзімі және біріккен байланыс арнасы.

Мысалы: емхана 60 ПК алады. Құжатта 1 жұмыс күні ішінде инженер шығуы және 5 күннен артық жөндеу болса, баламалы құрылғы беру шарты көрсетілген. Қабылдауда дау болған жоқ, себебі әрекет тәртібі алдын ала түсінікті әрі сервис актілерімен расталған.

Жеткізу және қабылдау: сәйкес келмеулерді қалай болдырмауға болады

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

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

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

Қабылдау тәртібі қарапайым қадамдармен сипатталсын:

• орын саны, опись және сериялық нөмірлер құжаттармен салыстырылсын;
• кездейсоқ бірнеше қорап ашылып, комплектация тексерілсін;
• қосып қосып қоспай іске қосып, порттар мен экранды тексеру (моноблоктар үшін);
• жүйеде сипаттамаларды тексеріп (CPU, RAM, диск) спецификациямен салыстыру;
• нәтижелер актіде көрсетілсін.

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

Қайтаруларсыз сатып алу дайындығының қадамдық жоспары

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

1) Қолданушылардың типтік профильдері арқылы қажеттілікті анықтаңыз

Пайдаланушылардың күнделікті атқаратын жұмыстарын жинаңыз және 2–4 жұмыс профиліне бөліңіз (мысалы: «офис», «графикамен жұмыс», «екі мониторлы оператор», «стойка/серверная»). Бұл ТЗ жазуды және санды есептеуді жеңілдетеді.

2) Міндетті талаптарды ИТ және ИБ‑пен келісіңіз

Нақты қажетті минимумды бекітіңіз: инфрақұрылыммен үйлесімділік, порттар, желі, периферия талаптары, предустановка саясаты. ИБ‑дан тексерілетін тармақтарды (мысалы, TPM болуы, BIOS/UEFI паролдері) талап етіңіз, жалпы сөздер емес.

3) Тексеруге болатын растамаларды ғана сұраңыз

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

4) Қабылдауды өлшенетін критерийлерге негіздеңіз

Компьютер техникасын қабылдау модель/конфигурация сәйкестігіне, сериялық нөмірлерге, комплектацияға, нақты сипаттамаларға (ОЗУ, диск), орау күйіне, қосу тестінің нәтижесіне және кепілдік құжаттарына сүйенуі керек.

5) Договордағы дау тудыратын тармақтарды тексеріңіз

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

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

ТЗ мен шартта жиі кездесетін қателіктер, дауға әкелетін себептер

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

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

Тағы бір қате — бір тармақта құрылғы сипаттамасы мен жеткізуші талаптарын араластыру. Бұл қабылдауда не тексерілетіні анық емес етеді: комплект пе, әлде сервис желісі ме?

Соғұрлым жиі дауға алып келетін формулировкалар:

• «Не хуже», «современный», «совместимо со всем» — тексеру критерийсіз;
• локалдық шығу талаптары құжатсыз;
• қабылдау «жеткізу фактісі бойынша» делінген, бірақ кім қол қоятыны, қандай тест жасалатыны және не несоответствие саналатыны көрсетілмеген;
• кепілдік «12–36 ай» деп жазылған, бірақ жауап беру және ауыстыру мерзімдері жоқ;
• ПО шарттары анықталмаған: не орнатылған, кім жауапты және қалай версия тіркеледі.

Практикалық мысал: мекеме «3 жыл кепілдік» деп жазып, инженер шығу мерзімін көрсетпеген. Жеткізуші жөндеуді басқа қалада жасауға құқылы екенін айтса, тапсырыс беруші орнында қызмет күткен. Нәтиже — хат алмасу және шартты аяқтауда кешігулер.

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

Қысқа чек‑лист: жарияламас бұрын және қабылдамастан бұрын тексеру

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

Жарияламас бұрын

Өткізу мәтінін сол күнгі қабылдауды елестетіп тексеріңіз.

• Талаптар өлшенеді: процессор деңгейі, ОЗУ көлемі, диск түрі/көлемі, интерфейстер, диагональ мен рұқсат (моноблоктар үшін), TPM барлығы (қажет болса), комплект кабельдер мен периферия.
• Құжаттар пакеті түсінікті: дәл қандай құжаттар, қандай түрде (скан/негізгі), қай кезеңде (өтініште немесе жеткізу кезінде).
• Локалдық құрам мен шығу тегі анық жазылған: қандай растамалар қабылданады және кім шығарады.
• Кепілдік нақты сандармен: мерзім, жауап беру уақыты, жөндеу/ауыстыру мерзімі, сервис географиясы, подменді қор болу‑болмауы.
• Қабылдау критерийлері алдын ала жазылған: несоответствие деген не және ішінара ақауларда не істеу керектігі.