MDM мастер-деректер орталығы: келісу, дубльден арылту және тарату

Мастер-деректер орталығы не үшін қажет және қандай мәселелерді шешеді

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

Мәселелер көбінесе адамдардың қамқорлығы жоқтығынан емес, дереккөздер өте көп болуынан туындайды. Бір контрагент бухгалтерияда, CRM-де және сатып алуда әртүрлі жазылып, мекен-жайы өзгеріп, ИИН немесе БИН қателікпен енгізілуі мүмкін. Уақыт өте дубльдер пайда болады, атрибуттар әркелкіленеді, және әр түрлі жүйелерде бір справочниктың «даулы» нұсқалары шығады.

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

Көбіне MDM-ге контрагенттер, тауарлар мен қызметтер, қызметкерлер мен ұйымдық құрылым, сондай-ақ орналасу нүктелері (мекен-жайлар, қоймалар, сату нүктелері) шығарылады.

Қашан MDM салу керек екенін көрсететін белгілер:

• есептерде жүйелер арасындағы сомалар «маны шықпайды» — әр түрлі справочниктер нәтижесінде
• бір клиент бірнеше рет әртүрлі атаулармен кездеседі
• карточкалардағы өзгерістер интеграциялар арқылы баяу таралып немесе жоғалады
• бизнес қай жүйенің «басты» екенін таластырады
• жаңа қосымшаны енгізу әр жолы деректерді қолмен тазалаудан басталады

Мысалы: сату бөлімі CRM-ге жаңа клиент енгізді, ал сатып алу оны басқа атаумен жеткізуші ретінде тіркеген. MDM болмаса уақытты салыстыруға жұмсайсыз, MDM бар болса — барлығына бір келісілген карточка болады.

Инвентаризация: қандай мастер-деректер бар және қайда сақталады

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

Дереккөздердің тізімін және әрқайсының рөлін бастаңыз. Қай жерде жазба алғаш пайда болатындығын, қай жерде оны өзгертуге болатынын және қайда тек оқуға арналғанын ажырату маңызды. Әдетте көрініс мынадай: ERP есепке алу справочниктерін және статустарын сақтайды; CRM — лидтер, клиенттер, контактілер және өзара әрекеттесу тарихы; бухгалтерия — реквизиттер, шоттар және салық белгілері. Тәуекел аймағы — Excel және пошта, онда уақытша тізімдер мен «қолмен» справочниктер сақталады, сондай-ақ сыртқы справочниктер мен реестрлер пайдаланылса.

Келесі қадам — объектінің карточкасын және бизнестің жұмыс істеуі үшін ең қажет атрибуттардың минималды жиынтығын құрастыру. Қазақстан үшін контрагенттерде жиі БИН, қажетті тілдердегі атау, заңды мекен-жай, банк реквизиттері, статус (белсенді, тексеруде, архив) болады. Тауарлар мен қызметтер үшін — кодтар, өлшем бірліктері, ҚҚС ставкалары, маркировка белгілері, өмірлік цикл статустары.

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

Арнайы сапа мәселелерін де жазып алыңыз: міндетті өрістер бос (БИН, мекен-жай, код), әртүрлі форматтар (артық бос орындар, регистр, телефон маскалары), негізгі реквизиттердегі қателер, справочниктерге сәйкес еместік (ел кодтары, ОКЭД, бірліктер), және қолмен түзетулерден кейін жүйелер арасындағы «шындықтың» айырмашылығы.

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

Басқару моделі: рөлдер, ережелер және жауапкершілік

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

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

Жұмыс схемасында әдетте мына рөлдер керек:

• дерек иесі (Data Owner): ережелер мен даулы жағдайларға соңғы шешімді қабылдайды
• дерек стюарды (Data Steward): күнделікті справочникты жүргізеді, өтініштерді тексереді, сапаны бақылайды
• бастамашы: жазбаны құру немесе өзгерту өтінішін жасайды және дәлелдер қосады
• келісуші: өзінің аймағында өзгерістерді растайды (мысалы, қаржы немесе қауіпсіздік)
• интеграциялар техвладельі: өзгерістердің басқа жүйелерге дұрыс жетуін қамтамасыз етеді

Негізгі ереже — «алтын жазба». Алдын ала кім басты нұсқаны анықтайтынын және қандай белгілер бойынша шешім қабылданатынын келісіңіз. Мысалы, заңды атау мен БИН-ды қаржы растайды, мекен-жайды жеткізу бөлімі растайды, контактілерді аккаунт-менеджер бекітеді. Қақтығыс автоматты шешілмесе, дерек иесіне беріледі.

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

Өзгерістерді келісу процестері: өтініш ағынын қалай ұйымдастыруға болады

MDM қолмен хаосқа айналмасын десеңіз, өзгерістер анық ағын арқылы енгізілуі керек. Бұл деректерді кездейсоқ түзетуден қорғайды және жазба неліктен осылай көрінетінін тез түсіндіруге мүмкіндік береді.

Әдетте төрт типтегі өзгерістерді бөліп көрсетеді: жазба құру, атрибуттарды жаңарту (мекен-жай, ИИН, статус), дубльдерді біріктіру және жазбаны жабу (объект енді қолданылмауы тиіс, бірақ тарих сақталуы керек).

Негізгі өтініш ағыны

Жұмысқа жарайтын нұсқа:

• өтініш: бастамашы не өзгерту керек екенін және не үшін екенін сипаттайды, дереккөзді қосады (келісімшарт, пошта, ERP карточкасы)
• тексеріс: стюард толықтығын, форматты, міндетті өрістерді және потенциалды дубльдерді тексереді
• келісу: дерек иесі өзгерістің бизнес мәнін растады (мысалы, контрагент нақты жаңа ма, әлде бар филиал ба)
• орындау: MDM түзетуді енгізеді, сапа тексерістерін және дубльден арылтуды іске қосады
• жариялау: жазба финал статус алады және басқа жүйелерге таратылады

SLA, приоритеттер және ерекшеліктер

Анық мерзімдер мен жеделдету ережелері қажет. Мысалы, стандартты өтініштер 1–2 жұмыс күні ішінде өңделсін; шұғылдар негіздемемен және жауапты келісушімен жедел маршрутқа түссін. Ал қандай өзгерістер жедел жасалатынын алдын ала келісу маңызды (мысалы, алаяқтық анықталған контрагентті блоктау).

Аудит және өзгерістер журналы

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

Мысал: бухгалтерия жеткізушінің заңды мекен-жайын өзгертуін сұрайды. Стюард дубль пайда болмайтынын тексереді, дерек иесі дереккөзді растайды, содан соң MDM ERP, CRM және сатып алу жүйелеріне біркелкі жаңартуды жібереді.

Дедупликация: дубльдерді іздеу және біріктіру ережелері

Дедупликация есептер мен процестерде бір объектінің екі «әртүрлі» нұсқасының пайда болуын болдырмау үшін қажет. Әдетте екі түрлі іздеуден бастайды: нақты сәйкестіктер (ИИН/БИН, сериялы номер, номенклатура коды) және аты-жөні немесе мекен-жайы 1–2 таңба айырмашылығы бар ұқсас жазбалар.

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

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

Жиі қолданылатын ережелер:

• «қатаң кілт»: уникалды идентификатор сәйкес келсе (ИИН/БИН, GUID, инвентарлық номер) — бұл дубль
• «жұмсақ кілт»: атау + туған күн немесе атау + мекен-жай, немесе атау + телефон — сәйкестік пайызын есептеу
• нормализация: регистрді теңестіру, артық бос орындарды жою, мекен-жай қысқартуларын есепке алу, транслитерацияны ескеру

Жазбаларды біріктіру және қақтығыстарды шешу

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

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

Мысал: «ТОО Альфа» және «Альфа ТОО» БИН бойынша сәйкес келгенімен мекен-жайы әртүрлі. Жүйе басты профильді таңдап, байланыстарды көшіріп, екіншісін біріктірілген деп белгілейді, сол арқылы басқа жүйелер қайтадан дубль жасамайды.

Сапа және стандарттар: жарияламас бұрын не тексеру керек

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

Бірінші қабат — толықтық пен жарамдылық. Әр объект үшін міндетті өрістер мен ережелерді алдын ала бекітіңіз: қай справочниктер қолдануға болады, қандай мәндер рұқсат етілген, қандай комбинациялар тыйым салынған. Контрагент үшін маңызды: ИИН/БИН, тіркеу елі, түрі (заңды/жеке тұлға), есеп валютасы, статус.

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

Нормализацияның минималды жиынтығы

• мекен-жайлар: өрістердің бір тәртібі, біртекті қысқартулар, үй/корпус/офис бөлек сақталуы
• телефондар: E.164 форматы, ел коды мен ішкі нөмірді сақтау
• атаулар: регистр ережелері, артық бос орындарды жою, тырнақшалардың бір стилі
• өлшем бірліктері: бекітілген справочниктан ғана
• идентификаторлар: ИИН/БИН маскалары, ұзындық пен таңбалардың тексерісі

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

Қандай жағдайлар жариялауды блоктайды

• міндетті өрістер толтырылмаған немесе маскалар бұзылған (ИИН/БИН)
• мән справочниктан емес (валюта, аймақ, өлшем бірлік)
• бірегейлік бұзылған (бірдей ИИН/БИН екі жазбада)
• критикалық өзгерістер үшін дерек иесінің растауы жоқ
• жарияламас бұрын дубльге тексерістен өтпеген

Практикадан мысал: сатып алу жүйесінде «GSE KZ» деп жеткізуші ашылған, бірақ БИН жоқ және телефон еркін форматта енгізілген болса, жариялау стандартқа дейін блокталады. Осылайша қате он жүйеде жеке түзетілмей, орталықтан шешіледі.

Форматтар келісімі: барлық жүйелермен қалай келісу керек

Мастер-деректер жүйелер арасында дұрыс өмір сүруі үшін форматтар келісімі қажет. Бұл — қандай өрістер берілетіні, олардың атауы, рұқсат етілген мәндері және қате не екенін анықтайтын қарапайым келісім. Келісім болмаса бір жүйе «ИНН» жібереді, екіншісі taxId күтеді, үшіншісі бос мекен-жай қабылдап, есептерді бұзады.

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

Тұрақтылық көріністен маңызды. Келісімді версиялап, мұқият өзгерту керек:

• үйлесімді емес өзгеріс (өрістің атын өзгерту, түрін ауыстыру) — жаңа мажорлық версия
• жаңа міндетті емес өрісті қосу — әдетте үйлесімді (минорлық версия)
• әр версияның енгізу күні мен қолдау мерзімі болуы тиіс
• өзгерістер дерек иесі + интеграция иесі арқылы қысқа келісуден өтеді

Идентификаторлар бөлігі бөлек тақырып. Глобалдық кілт (мысалы, masterId) және дереккөз кілттері (sourceSystem + sourceId) болу керек. Солайша жазбаларды сәйкестендіру жеңілдейді және көшіру кезінде байланыс жоғалмайды.

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

Мастер-деректерді басқа жүйелерге тарату: интеграция нұсқалары

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

Екі негізгі тәсіл бар. Push — орталық өзгерістерді жариялап, жазылым жасағандарға жібереді. Pull — жүйелер өздеріне қажет кезде ағымды деректерді сұрайды. Амал көп жағдайда аралас: өзгерістер push арқылы, ал толық справочникты pull режимінде сұрау немесе кесте бойынша жүктеу.

Каналды қалай таңдау керек

Көбіне хабарлар кезегі, API немесе файлдар қолданылады. Таңдау вендорға емес, міндет пен шектеулерге байланысты:

• хабарлар кезегі оқиғаларға (құрылды, жаңартылды, жабылды) ыңғайлы — жылдамдық пен сенімділік маңызды болса
• API pull және нақты тексерістер үшін пайдалы (мысалы, ИИН/БИН бойынша контрагент іздеу)
• файлдар (выгрузка) пакет сценарийлеріне, үлкен көлемдерге және ескі жүйелерге сай

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

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

Кері байланыс

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

• қабылдауды растау (ack) және жазбаның версиясы
• жеткізу қатесі мен себептері (формат, міндетті өрістердің жоқтығы, қол жетімсіздік)
• қайта жіберулер және дедлайн, одан кейін разбор қажет
• жіберулер журналы аудит үшін

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

Мысал сценарий: контрагентті өтініштен жариялауға дейін енгізу

Компания жаңа жеткізушіні сатып алу үшін қосады. Оны бір рет қана енгізіп, кейін ERP, бухгалтерия және сатып алу жүйелерінде бірдей қолдану қажет. Бұл MDM үшін типтік сценарий, бір объектінің әртүрлі нұсқаларының пайда болуын болдырмау үшін.

Процесс әдетте келесідей:

• бастамашы өтініш жасайды: атау, ИИН/БИН, заңды мекен-жай, банк реквизиттері, контактілер, ҚҚС статусы
• жүйе бастапқы тексеріс жасайды: міндетті өрістер, ИИН/БИН маскасы, символдар жарамдылығы, шоттардың дұрыстығы
• дубль іздеу іске қосылады: ИИН/БИН, атау және мекен-жай бойынша (қателерді ескере отырып)
• дубль табылса, өтініш біріктіруге немесе бар жазбаға байлануға жіберіледі
• кейін келісу жүреді: сатып алу қажеттілігін растайды, қаржы төлем реквизиттерін тексереді, комплаенс жұмыс істеуге рұқсат береді (бар болса)
• мақұлданған соң ғаламдық ID беріледі және жазба форматтар келісімі бойынша ERP мен бухгалтерияға жіберіледі

Типтік қателік — қабылдаушы жүйе форматқа байланысты жазбаны қабылдамайды. Мысалы, келісімде bankAccount өрісі 20 цифрлы жол ретінде көрсетілген, ал өтініште шот пробелмен немесе KZ префиксімен енгізілген.

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

MDM енгізуде жиі кездесетін қателіктер

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

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

Үшінші қателік интеграцияға байланысты: форматтар келісімін версияламайды. Команда өрісті өзгертіп тастағанда (мысалы, «ФИО»-ны үш өріске бөлу) кенеттен ERP, CRM немесе бухгалтерияға жүктеулер бұзылады. MDM-ге сенім төмендеп, жүйелер оны айналып өтеді.

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

Осы тұзақтарға түспеу үшін қарапайым қағидаларды ұстаныңыз:

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

Мысал: сатып алу бөлімі жеткізушіні тіркеп, келісім бөлімі реквизиттерді өзгертсе, домен иесі «контрагенттер» айқын болмаса жүйелерде екі түрлі «шындық» ала аласыз. MDM мұны алдын ала келісілген ережелермен шешуі тиіс, чаттағы хат алмасулармен емес.

MDM орталығының дайын-жайының қысқа чек-листі

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

MDM-дің ұшып кетпеуі үшін минимум

• домендер анықталған (мысалы, контрагенттер, қызметкерлер, құрал-жабдық) және әр домен үшін міндетті атрибуттар тізімі
• рөлдер бекітілген: дерек иесі, стюард, келісушілер, техподдержка; өтініштің құрудан жариялауға дейінгі жолы түсінікті
• дедупликация ережелері бар: қай өрістер салыстырылады, қай шекті «дубль» деп санаймыз, біріктіру процесі
• дубльдерді біріктіру аудитпен жасалады: кім біріктірді, не өзгерді, қате болғанда шешімді қалай қайтаруға болады
• тарату форматы келісімі сипатталған: өрістер атауы, типтері, справочниктер, міндеттілік, толтыру ережелері

Интеграция және сапаны бақылау

• форматтар келісімін версиялау жоспары бар: қандай өзгеріс үйлесімді, жүйелер қалай хабарланады, ауысуға қанша уақыт беріледі
• 1–2 жүйеге тесттік тарату контуры дайын, онда алмасуды қауіпсіз тексеруге болады
• қателерді мониторингілеу орнатылған: жеткізілмеген хабарлар, қабылданбаған жазбалар, міндетті өрістердің бұзылуы, дубльдердің өсуі

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

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

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

Практикалық старт — бір домен (контрагенттер немесе қызметкерлер) және екі жүйе-алаушы (мысалы, ERP және CRM). Бұл жеткілікті күрделілік көрсетіп, әлде қайда мәселелерді көруге мүмкіндік береді, бірақ жобаны ұзаққа созбайды.

6–10 апталық пилот жоспары

• домен мен дерек иесін таңдаңыз (соңғы шешімді кім қабылдайтынын)
• өтініш ағынын сипаттаңыз: құру, өзгерту, блоктау, жабу
• форматтар келісімін келісіңіз: міндетті өрістер, справочниктер, қате кодтары
• эксплуатация талаптарын дайындаңыз: SLA, мониторинг, журнал жүргізу
• прогон жасаңыз: тест деректер, инциденттер, себептерді талдау

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

Интегратор процесс, архитектура және эксплуатацияны бір уақытта жинауға қажет жерлерде пайдалы болады. Мысалы, GSE.kz (gse.kz) жүйелік интегратор ретінде MDM контурасын құруға, дата-орталық инфрақұрылымын дайындауға және қолдауға көмектесе алады, қажет болса серверлер мен жұмыс станцияларына дейін қамтамасыз етеді.

Бастамас бұрын серіктен нақты не күтетіндігіңізді бекітіңіз:

• пилоттың дайындық критерийлері және деректер сапасы метрикалары
• резервтеу және қалпына келтіру схемасы
• мониторинг пен оповещениелер ережелері
• инциденттер мен өзгерістер регламенті (кім және қанша уақытта жауап береді)
• журналдарды сақтау және қорғау талаптары