Сериялық нөмірлерді сквозной есепке алу: КП‑дан CMDB‑ға дейін қателіксіз

Сериялық нөмірлерді қолмен жүргізгенде не бұзылады

Сериялық нөмірлерді қолмен есепке алу жиі «немқұрайдылықтан» емес, қайта-қайта бірдей деректерді көшіріп жазғандықтан қателіктерге апарады. Бір нөмір хаттан Excel-ге, Excel-ден накладная-ға, накладная-дан CMDB-ға көшіріледі. Әрбір көшірілім қателік мүмкіндігін арттырады. Нәтижесінде жеткізілім қабылданған сияқты болады, бірақ кейін нақты құрылғының дәл сіз сатып алған және есепке алынғаны екенін дәлелдеу қиынға соғады.

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

• сериялық нөмірлерді шатастыру (0/O, 1/I), артық символ қосу немесе көшіру кезінде қиып алу;
• бір сериялық нөмір екі түрлі жолға екі рет жазылады, әсіресе бір модельден тұрған «қаптар» келгенде;
• сериялық нөмір басқа номенклатура жолына түседі (модель бір, бірақ әртүрлі комплектация немесе партиялар);
• CMDB-ға «уақытша» сериялық нөмірсіз актив енгізіп, кейін толтыруды ұмыту немесе «ауызша» енгізу;
• бір тауарды әртүрлі атаулармен жазу, сондықтан құжаттар бойынша салыстыру сәйкес келмейді.

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

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

Әдетте тізбекке КП (спецификациясы бар), тапсырыс немесе шот, накладная немесе УПД, шығынға тіркелген сериялық нөмірлер реестрі (жүктеуге қосымша файл), қабылдау/қосу актісі, қоймалық жүйе немесе ERP және ITSM/CMDB кіреді. Астық сәйкес келмеушіліктер көбінесе шеттерде пайда болады: КП мен нақты жіберілім арасында, накладная мен акт арасында, сондай-ақ акт пен CMDB карточкасы арасында.

Сквозной есеп үшін минималды деректер моделі

Сериялық нөмірлерді барлық этап бойынша қолмен «қосып» отырмай өтуін қамтамасыз ету үшін ең маңыздысы — минималды деректер моделінде келісімге келу. Оны КП-де, есеп құжаттарында және CMDB-де барлығы бірдей түсінуі тиіс. Әйтпесе салыстыру «ұқсас жолдарды» іздеуге айналады.

Негізгі субъектілер жиі келесідей:

• тауар позициясы (модель/артикул, сипаттама, өлшеу бірлігі);
• экземпляр (сериялық нөмірі бар нақты құрылғы);
• құжат (КП, накладная, акт, тасымалдау);
• контрагент (жеткізуші, сатып алушы, тағайындаушы);
• объект (мекенжай, қойма, филиал, кабинет).

Мұндағы басты айырмашылық қарапайым. «Модель/артикул» — «не сатып аламыз?» деген сұраққа жауап береді, ал «сериялық нөмірі бар экземпляр» — «нақты не келді және қазір қайда?» дегенге жауап береді. Сан мен баға құжат жолында тұрады. Сериялық нөмір — экземпляр деңгейінде және ол пайда болған құжат жолымен бірмәнді байланыста болуы тиіс.

Сквозной трассировка үшін құжаттар қайта жасалғанда немесе деректер көшірілгенде өзгермейтін тұрақты идентификаторлар қажет:

• КП нөмірі (және нұсқа датасы);
• келісім/спецификация нөмірі;
• накладная нөмірі (немесе УПД);
• акт нөмірі (қабылдау/қосу);
• ішкі тапсырыс/өтініш нөмірі (ERP/ITSM).

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

КП: қандай өрістерді алдын ала дайындау керек

Сериялық нөмірлермен қателер көбіне қоймада емес, коммерциялық ұсыныста басталады. Егер КП-де нақты идентификаторлар мен ауыстыру ережелері болмаса, адамдар кейін «не келеді» деп болжауға тырысады. Қолмен тексерістер лотереяға айналады.

Негізі — әр позиция үшін анық жазылған КП жолы. Онда айқын атауы, модель мен Part Number (PN), сан, баға, жеткізу шарттары, мерзім және кепілдік болуы тиіс. Модель мен PN барлық КП, накладная және акт нұсқаларында бірдей жазылғаны маңызды — «ұтымды қысқартулар» қолданбау. Бұл табыстың жартысы.

Құжаттарды дұрыс сопоставлять ету үшін КП-те «күтім» мен «факт» арасындағы байланысты беретін нәрсені қосыңыз. Егер сериялық нөмірлер алдын ала белгілі болса (сирек, бірақ резервтеу кезінде болады) — әр жол бойынша күтілетін SN тізімін көрсетіңіз. Егер жоқ болса — жеткізуші SN реестрін қашан және қандай түрде береді (мысалы, накладная-ға қосымша бөлек файл, бір реестр барлық жіберілімге, КП жолдарына байланыстырумен) деген ережені бекітіңіз.

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

• КП позициясының коды (бірегей жол ID, «№1, №2» емес, тұрақты код);
• КП нұсқасы (v1, v2 және дата), қай редакция келісілгені анық болу үшін;
• жауапты менеджер және ауыстырулар мен комплектация туралы сұрақтар үшін байланыс тұлғасы;
• «сериялық есеп міндетті» белгісі критикалық SN бар позициялар үшін.

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

Практикалық мысал: серверлер мен жұмыс станцияларын тапсырыс бересіз. Жеткізуші «қолда бармен» ауыстыру ұсынады. Егер ауыстыру КП нұсқасында бекітілмесе, кейін накладная мен CMDB не қабылданғанын талқылайды. Бір қысқа ереже КП-де жеткізілімге дейін дау қалады.

Накладные және сериялық нөмір реестрі: қалай болуы керек

Накладная — жіберілім мен қабылдаудың фактін тіркейді, КП-дегідей күту емес. Құжат бухгалтерия, қойма және IT үшін бірдей оқылатындай болуы маңызды.

Қолмен енгізулер басталатын минималды өрістер:

• номенклатура (код және атауы), өлшеу бірлігі, саны;
• сериялық нөмір (поштучно), қажет болса партнөмір/модель;
• партия/жіберілім (накладная нөмірі, дата, жеткізуші);
• қойма, алушы/бөлімше, қабылдау орны;
• негізге сілтеме (тапсырыс/КП/келісім нөмірі).

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

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

Комплекттермен (мысалы, жұмыс станциясы + аксессуарлар) деңгейлерді араластырмау маңызды. Накладная-да базалық құрылғы оның сериялық нөмірімен айқын көрсетілуі тиіс, ал компоненттер бөлек көрсетіліп, «комлект құрамында» немесе «ата-аналық сериялық нөмір» өрісі арқылы осы құрылғыға байлануы керек. Сонда қызмет көрсету және инвентаризация кезінде не келгені және не кейін ауыстырылғаны көрінеді.

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

Актілер: фактіні қай жерде тіркеу керек

Акт — «не келуі керек» емес, «не нақты қабылданды және қандай күйде» дегенді тіркеу үшін қажет. Егер актіге КП немесе накладная-дан алынған деректер тексерусіз енгізілсе, қате әрі қарай жүйеде жүреді және кейін оны CMDB-дан табу қиынға соғады.

Актідегі маңызды өрістер қабылдау фактісі бойынша бейімделуі тиіс. Міндетті түрде тіркелетіндер:

• әр құрылғы бойынша расталған сериялық нөмірлер (SN) — тек физикалық тексерістен кейін;
• күйі: жаңа/бұзылған, ашылған белгілері, қаптамадағы мәселелер;
• комплектілік: қуат блогы, бекітпелер, рельстер, лицензиялар, керек-жарақтар (жабдық түріне байланысты);
• орын: қойма (жолақ) немесе нақты объект/кабинет, егер қабылдау бірден объектіде болса;
• жауапты: кім тексерді (аты-жөні, бөлім) және дата/уақыт.

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

«Кім кінәлі?» деген даулар болмас үшін рөлдерді алдын ала бекітіңіз. Логистика накладная-мен сәйкестігін және бастапқы тексеруді орындайды. IT эксплуатацияға енгізуді, байлаулардың дұрыстығын және конфигурация сәйкестігін бақылайды. МОЛ активтің жауапкершілігін қабылдап, көрсетілген жерде екеніне қол қояды. SN бойынша айырмашылық табылса, оны «кейін жүйеде түзетеміз» деп ұмытып қалмастан, актіге жазып қою керек.

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

CMDB: салыстыруға нақты көмектесетін өрістер

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

Салыстыру үшін қажетті минимум

Өрістер үш сұраққа жауап беруі тиіс: бұл не, қайдан келді және қазір қайда.

• сериялық нөмір (SN) — бірлік идентификаторы ретінде;
• модель/артикул (пересорт пен ауыстыруды анықтау үшін);
• қазіргі иесі (бөлімше немесе материалдық жауапты тұлға);
• орналасу (қойма, кабинет, объект, стойка);
• өмірлік цикл статусы.

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

«актив — құжат» байланысы (ең маңызды)

Дауларды болдырмау үшін «жеткізуші әкелді» деп қана жазбай, нақты құжат жолына байлау қажет. CMDB-да өрістер болсын: накладная және/немесе акт нөмірі, қабылдау датасы және құжат жолының идентификаторы. Егер есеп жүйесі ішкі жол ID-ін сақтаса, дәл сол ID-ді сақтаңыз, тек мәтіндік сипаттамамен шектелмей. Бұл автоматты түрде салыстыруға мүмкіндік береді: накладная-ның бір жолына қанша актив жасалды және барлығының SN-лары сәйкес пе.

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

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

Қадамдық салыстыру схемасы: КП-дан CMDB-дағы активтерге дейін

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

Байланыстыруға тиіс базалық тізбек

Номенклатураны қалыпқа келтіруден бастаңыз. Әр позиция үшін модель/PN, қысқа документтік атау және өлшеу бірлігі (дана, комплект) сәйкес келуі қажет. Егер КП-де «ПК жинақталған» деген жазба, ал накладная-да «системный блок + монитор» болса, кейін сериялық нөмірлер жолдар арасында «жылжиды».

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

• «КП жолы -> тапсырыс жолы -> накладная жолы» (код/PN және сан бойынша байланыстыру, мәтіндік атау бойынша емес);
• сериялық нөмірлер реестрін накладная-ға тартыңыз: SN-дар факт ретінде жүктелуі керек, CMDB-ға қолмен енгізбеу;
• автоматты түрде айырмашылықтарды белгілеңіз: артық SN, жетіспейтін SN, дубликаттар, дұрыс емес типтегі SN (мысалы, монитор SN-і системный блок жолына түсу);
• актімен фактіні растаңыз: актіде әр жол бойынша соңғы SN болуы тиіс, КП-дағы күткен мәндер емес;
• растау негізінде CMDB-да активтерді жасаңыз немесе жаңартыңыз: модель, PN, жеткізілім құжаты, кепілдік, статус «қоймада/эксплуатацияда».

Есепке қоюдан кейін бөлуді немесе орнатуды жасағанда локация, иесі (бөлім/МОЛ) және статус жаңартылуы керек. Егер бұл жасалмаса, CMDB тез шындықпен сәйкес келмейді.

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

80% қателікті жоятын автоматты тексерістер

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

Әр жерде қосуға лайық негізгі тексерістер

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

• SN бірегейлігі: ұйым бойынша және бір модель ішінде дубликаттарды тексеру (кейде әртүрлі желілерде бірдей префикстер шатасады);
• поштучный салыстыру: тек «10 дана» деп жазбау, әрбір SN мен әрбір позицияның КП, накладная, акт және CMDB арасында сәйкестігін тексеру;
• форматты бақылау: ұзындығы, рұқсат етілген символдар, біркелкі регистр, басы мен соңындағы пробелдерді тыйым салу, O/0 және I/1 сияқты жиі шатастырылатын символдарға кеңестер;
• «бір SN — бір актив» ережесі: SN-ді қайта пайдалану тыйым салынады, тіпті жазып тастағаннан кейін, және бір SN-ді екі активке байлау мүмкін емес;
• модельдің автосалыстырмасы: егер SN бір модельге байланған болса, ал құжатта басқа модель көрсетілсе, бұл түзетуді талап етуі тиіс, кейін «реттейміз» деп қалдырмау.

Ерекшеліктер туралы есеп: қабылдауға және IT-ға нені көрсету

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

Есепте әдетте келесі өрістер жеткілікті:

• ерекшелік түрі: SN жоқ, артық SN, дубликат SN, модель ауыстырылған, CMDB-пен конфликт;
• қай жерде табылған: КП, накладная, акт, CMDB;
• жол идентификаторы: позиция/жол нөмірі;
• SN (келген пішіні) және SN (нормализацияланған түрі);
• ұсынылатын әрекет: түзету сұрау, ауыстыру рәсімдеу, актив құру, жабуды блоктау.

Тексеру «кіруде» тұрса, қабылдау болжамнан айырылып кетпейді. CMDB фактілермен толтырылады, күткен мәндермен емес.

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

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

Әдетте қай жерде үзіліс болады

• Сериялық нөмірлерді фото немесе PDF-тен «көпіріп» енгізу. Шешім: форматты тексеретін шаблон (Excel/форма) арқылы енгізу, басындағы/соңындағы пробелдерді тыйым салу және шатасатын символдарға ескерту (O/0, I/1), регистрді нормализациялау.
• Құрылғының SN-і мен компоненттердің SN-ін бір өріске араластыру. Шешім: жеке өрістер (Device SN, PSU SN, SSD SN) және қай компоненттер бөлек актив болып саналатынын анық ережелер.
• «құжат жолы -> нақты актив» байланысының болмауы. Шешім: КП/накладная/акт әр жолында бірегей Line ID сақтау және оны CMDB карточкасына тасымалдау.
• Тек «жалпы саны» бойынша салыстыру (мысалы, 20 ноутбук) және поштучный бақылаудың жоқтығы. Шешім: әр бірлік үшін SN және салыстыру статусы (сәйкес/айырмашылық/табасыз) болмаса қабылдау жабылмайды.
• Активтерді қайта құрудың орнына жаңарту. Шешім: «бір сериялық нөмір — бір карточка» ережесі; қайталанатын жеткізілім немесе қозғалыс кезінде статус, орналасу, иесі өзгертіледі, дубль жасалмайды.

Қысқа мысал: интегратор накладная мен жеке SN реестрін алады. Егер SN-дарды сканнан енгізіп, Line ID-ге байламаса, CMDB-де дубльдер пайда болуы мүмкін, ал бір сервер «иесіз» қалып қоюы ықтимал. Егер SN нормализацияланған, құжат жолына байланған және поштучный тексерістен өткен болса, айырмашылық актіге қол қоюға дейін көрінеді.

Негізгі идея қарапайым: «не сатып алынған» ғана емес, «қай нақты бірлік келгенін» тіркеңіз және бұл байланысты барлық құжаттар мен CMDB-де бір кілтпен сақтаңыз.

Мысал сценарий: жеткізу және есепке қою қолмен шатасусыз

Жеткізу: 50 ПК, 10 монитор және 5 сервер екі объектіге қабылданады (офис және резервтік орын). Мақсат — CMDB-да жазбалар пайда болғанға дейін сериялық нөмірлер құжаттарда расталсын, «ауызша» емес.

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

• құжат нөмірі (накладная), дата;
• позиция (ПК/монитор/сервер), модель, саны (әр жолда әрқашан 1);
• сериялық нөмір (SN);
• арналатын алаң/қойма (Объект А немесе Объект Б);
• ескерту (егер ауыстыру бар болса).

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

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

Шығу нәтижесінде CMDB-да әр құрылғыда SN, модель, алаң, енгізу күні және құжат идентификаторлары (КП/накладная/акт) бар активтер жасалады. Ертең айырмашылық табылса, қай құжатта пайда болғаны және оны кім растағаны көрінеді.

Қабылдауды жабардан бұрын қысқа чек-лист

Қабылдауды қол қою және жеткізілімді жүйеде «жабу» алдында 10 минут дегдей соңғы тексеріс жасаңыз. Бұл кейінгі ұзақ тергеулерден арзан және жылдам сақтайды: құрылғы қайда, неге CMDB-де басқа және оны кім түзетуі керек — деген сұрақтарды.

Деректер мен құжаттар бойынша тексерістер

Жоғарыдан төмен тексеру ыңғайлы: алдымен сериялық нөмірлер, кейін саны, кейін жауапты.

• Әр активте SN және модель толтырылған, негіз құжаты бар (накладная және/немесе акт). Құжатсыз актив қабылданған саналмайды.
• Барлық SN бірегей: жеткізілім ішінде және бұрынғы жазбаларда дубль жоқ. SN форматы (ұзындық, символдар, пробелдердің жоқтығы) тексерістен өтеді.
• Сандар КП, накладная, акт және CMDB арасында поштучно сәйкес келеді. Егер сәйкес келмесе, рәсімделген ерекшелік болуы тиіс: модель ауыстыру, пересорт, брак, жеткізілмеген.
• Әр актив үшін «қайда және кімде» анық: локация, иесі немесе МОЛ, статус (қоймада, берілді, жөндеуде, қорда).
• Шешілмеген айырмашылықтар тізімі бар: не сәйкес келмейді, кім жауапты, мерзім және қажетті әрекет (жазбаны түзету, түзетілім құжат сұрау, қайтару рәсімдеу).

Жылдам мысал

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

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

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

Ережелерді бекітіп, процесс иесін тағайындаңыз

Процессті иеленетін тұлғаны тағайындаңыз (жиі сатып алу немесе IT-есеп) және сериялық нөмірлермен жұмыс ережелерін келісіңіз. Әр қадам үшін жауапты және қате пайда болғанда нақты әрекет болуы керек.

Әдетте жеткілікті болады:

• реестрге SN-ды кім толтырады (жеткізуші, қойма, қабылдау) және қашан;
• кім SN-дардың құжаттармен сәйкестігін растайды (қабылдау, бухгалтерия, IT);
• кім SN-ды түзетуге құқылы және түзету себебі қалай тіркеледі;
• әр кезеңде «шындық көзі» не болып саналады (КП, накладная, акт, CMDB);
• қолданылатын статустар (мысалы: «күтілуде», «қабылданды», «айырмашылық», «активте»).

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

Автоматтандыру: интеграциялар мен пилот

ERP/бухгалтерлік жүйе мен ITSM/CMDB арасындағы интеграцияларды қосыңыз — сонда сериялық нөмірлер қайта-қайта қолмен жазылмай, тасымалданып және тексеріліп отырады. Ерекшеліктер бойынша есептер: қай SN жоқ, қайсысы дубль, модельге сәйкес келмейді, акт жоқ.

Жақсы бастапқы сценарий — бір техника категориясын (мысалы, ноутбуктер немесе серверлер) таңдап, 2–4 жеткізілімде пилот өткізу, статустарды және ережелерді пысықтау, сосын барлық сатып алуларға кеңейту.

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