CRM-автоматтандыру қалай құрылады: бытыраңқы деректерден жұмыс істейтін жүйеге дейін

CRM-автоматтандыру платформаны таңдаудан басталмайды. Ол деректерді талдаудан басталады.

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

Сырттай қарағанда қарапайым сценарийдің — мысалы, бірінші сатып алудан кейін дербестендірілген ұсыныс жіберудің — артында тұтас жүйе тұрады:

• сайт пен мобильді қосымша клиент әрекеттерін тіркейді
• есеп жүйесі тапсырыстар туралы ақпаратты береді
• каталогта тауарлар, санаттар және бағалар туралы мәліметтер сақталады
• CRM-платформа деректерді клиент профиліне біріктіреді
• автоматтандырылған сценарий берілген шарттарды тексереді
• коммуникация жүйесі арнаны таңдап, хабарламаны жібереді
• нәтижелер жүйеге қайтып, кейінгі аналитикада пайдаланылады.

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

1. Ақпараттық жүйелерді тексеру

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

Бір компанияда клиент туралы ақпарат бір уақытта мына жерлерде сақталуы мүмкін:

• интернет-дүкенде
• мобильді қосымшада
• ERP немесе есеп жүйесінде
• CRM-де
• адалдық бағдарламасында
• кассалық жүйеде
• байланыс орталығында
• деректер қоймасында
• email, SMS және Telegram коммуникация сервистерінде
• тауар каталогында
• жеке кестелер мен ішкі сервистерде.

Бұл ретте әртүрлі жүйелер бір объектіні әрқалай сипаттауы мүмкін.

Мысалы, интернет-дүкен тапсырысты себеттегі тауарлар жиынтығы ретінде, ERP сату құжаты ретінде, ал CRM-платформа нақты клиентке байланыстырылған purchase оқиғасы ретінде сақтауы мүмкін. Бір жүйеде тауар санаты category, екіншісінде product_group деп аталып, үшіншісінде тауар иерархиясының бірнеше деңгейі арқылы анықталуы мүмкін.

Сондықтан біз инвентаризациядан бастаймыз:

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

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

2. Мақсатты деректер моделін жобалау

Тексеруден кейін біз мақсатты деректер моделін — барлық қосылған жүйелер өзара әрекеттесетін ортақ тілді — жобалаймыз.

CRM-міндеттер үшін әдетте бірнеше негізгі мән пайдаланылады.

Клиент

Клиент профилінде мыналар болуы мүмкін:

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

Оқиға

Оқиға клиент жасаған әрекетті сипаттайды:

• тіркелу
• бетті немесе тауарды қарау
• тауарды себетке қосу
• тапсырыс рәсімдеу
• сатып алу
• қайтару
• промокод пайдалану
• хабарламаны алу немесе ашу
• сілтемеге өту
• клиент мәртебесінің өзгеруі.

Әр оқиғаның уақыты, клиент идентификаторы және қосымша атрибуттар жиыны болады. Мысалы, сатып алу үшін олар тапсырыс нөмірін, соманы, валютаны, тауарды, санатты, санын және қолданылған жеңілдікті қамтуы мүмкін.

Тауар және ассортимент

Тауар моделіне мыналар кіруі мүмкін:

• SKU идентификаторы
• атауы
• бренд
• санат және ішкі санат
• тауар нұсқасы
• баға
• қолжетімділік
• тауар мәртебесі
• ассортиментке қосылған күн
• қосымша тауар сипаттамалары.

Коммуникация

Жіберілімдер мен клиент реакциялары бөлек сипатталады:

• арна
• кампания
• хабарлама
• жіберілген күн
• жеткізу мәртебесі
• ашу
• өту
• қате
• жазылымнан бас тарту.

Bloomreach Engagement те деректерді клиенттер, оқиғалар, каталогтар және оларға байланысты атрибуттар айналасында құрады. Мұндай құрылым клиент профилін оның әрекеттер тарихымен және тауар контекстімен бір көріністе біріктіруге мүмкіндік береді. Bloomreach ресми құжаттамасы: Data structure

Мақсатты модель — жай ғана өрістер тізімі емес. Әр элемент үшін біз мыналарды анықтаймыз:

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

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

3. Әртүрлі жүйелер деректерін сәйкестендіру

Мақсатты модель келісілгеннен кейін әр дереккөз үшін source-to-target mapping — сәйкестендіру кестесі жасалады.

Ол бастапқы жүйенің қай өрісі мақсатты модельдің қай өрісіне түсуі керегін және қандай түрлендіру орындалатынын көрсетеді.

Мысалы:

Осы кезеңде тек техникалық баптаумен шешілмейтін айырмашылықтар анықталады.

Мысалы:

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

Мұндай мәселелер әзірлеу басталғанға дейін тіркеліп, келісіледі. Әйтпесе техникалық тұрғыдан дұрыс интеграция бизнес-мағынасы қате деректерді бере бастайды.

4. Біріздендіру және нормализация

Әртүрлі көздерден алынған деректер тікелей қолдануға сирек дайын болады. CRM-жүйеге жүктелмес бұрын олар түрлендіріледі.

Біріздендіру мыналарды қамтуы мүмкін:

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

Нормализация деректердің сыртқы тазалығы үшін ғана маңызды емес. CLIENT@MAIL.COM, client@mail.com және client@mail.com мәндері бір мекенжайға қатысты болуы мүмкін, бірақ ортақ ережелер болмаса, жүйе оларды әртүрлі идентификатор деп қабылдауы мүмкін.

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

5. Деректерді тазалау және сапасын тексеру

Келесі кезең — алынған деректерге сенуге болатынын тексеру.

Біз сапаның бірнеше параметрін бағалаймыз.

Толықтық

Міндетті өрістер толтырылған ба? Сатып алуда клиент, күн, сома және тапсырыс идентификаторы бар ма? Тауарды каталогпен байланыстыруға бола ма?

Дұрыстық

Мән күтілетін түр мен диапазонға сәйкес келе ме? Тапсырыс сомасы теріс емес пе? Берілген тауар шынымен бар ма?

Үйлесімділік

Әртүрлі көздер клиентті, тапсырысты және тауарды бірдей түсіндіре ме? Валюталар, мәртебелер және уақыт белдеулері сәйкес пе?

Бірегейлік

Бір сатып алу бірнеше рет жүктеліп жатқан жоқ па? Бір клиентке бірнеше профиль жасалмаған ба?

Форматқа сәйкестік

Email рұқсат етілген форматта ма? Ел коды келісілген анықтамалыққа сәйкес пе? Күн дұрыс жазылған ба?

Өзектілік

Бастапқы жүйедегі өзгерістер CRM-де қаншалықты тез пайда болады? Бұл деректерді клиент әрекетінен бес минуттан кейін іске қосылуы тиіс сценарийде қолдануға бола ма?

Дәл осындай completeness, correctness, consistency, duplication және conformance өлшемдері деректер сапасын автоматтандырылған бақылау жүйелерінде қолданылады. Google Cloud: Data quality tasks

Тексеру нәтижесінде ережелер жиыны қалыптасады:

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

Маңыздысы: CRM-платформа бастапқы деректердегі барлық мәселені автоматты түрде түзетпейді. Bloomreach деректердің сапасы мен толықтығын импортқа дейін тексеру керегін тікелей көрсетеді. Bloomreach: Custom integrations

6. Клиенттерді сәйкестендіру және дедупликация

Ең күрделі кезеңдердің бірі — қай жазбалардың шынымен бір адамға қатысты екенін анықтау.

Клиентте мыналар болуы мүмкін:

• ішкі нөмір
• email
• телефон
• адалдық картасының нөмірі
• есептік жазба идентификаторы
• браузер cookie-і
• мобильді құрылғы идентификаторы
• бірнеше мекенжай және байланыс деректері.

Бұл ретте бір адам бірнеше құрылғы мен email-мекенжайды қолдануы, ал бір телефонды немесе компьютерді бірнеше адам пайдалануы мүмкін.

Сондықтан алдымен идентификаторлар жүйесі жобаланады.

Қатаң идентификаторлар

Бұл клиентке бірмәнді тиесілі болуы тиіс идентификаторлар, мысалы ішкі customer_id немесе есептік жазба нөмірі.

Жұмсақ идентификаторлар

Бұл cookie, құрылғы немесе әрекеттерді байланыстыруға көмектесетін, бірақ адамды әрдайым бірмәнді анықтай бермейтін басқа техникалық идентификаторлар.

Одан кейін сәйкестендіру ережелері жасалады:

• бірдей ішкі идентификатор
• бірдей расталған email
• қосымша белгілер сәйкес келгендегі бірдей телефон
• анонимді cookie мен авторизацияланған профиль арасындағы байланыс
• аты-жөні, туған күні және байланыс деректерінің комбинациясы
• корпоративтік немесе отбасылық есептік жазбаларға арналған арнайы ережелер.

Дедупликация — бірдей жолдарды жай ғана өшіру емес. Бұл мәндерді сәйкестендіру процесі: жүйе жазбаларды салыстырып, олардың қайсысы бір объектіні сипаттайтынын анықтайды. Сәйкестік қатаң ережелермен немесе ықтималдық модельдерімен белгіленуі мүмкін. AWS Entity Resolution: Matching workflow

Bloomreach клиентті сәйкестендіру үшін hard ID, ал құрылғылар мен браузерлерді байланыстыру үшін soft ID пайдаланады. Платформа үйлесімді идентификаторларды тапқанда, профильдер оқиғалар тарихымен бірге біріктірілуі мүмкін. Алайда қайшы келетін қатаң идентификаторларды автоматты түрде біріктіруге болмайды — бұл әртүрлі адамдардың деректерін араластыру қаупін тудырады. Bloomreach: Customer identification, Bloomreach: Merging

Сондықтан біз бөлек жобалаймыз:

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

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

7. Интеграцияға техникалық тапсырма дайындау

Деректер моделі мен өңдеу ережелері келісілгеннен кейін техникалық тапсырма дайындаймыз.

Толыққанды интеграциялық ТТ өрістер тізімін ғана сипаттамайды. Ол жүйелер арасындағы бүкіл келісімді бекітеді:

1. Деректер көздері мен алушылар

   Қандай жүйелер ақпарат алмасады және әр тарап қай бөлікке жауап береді.

2. Берілетін мәндердің құрамы

   Клиенттер, оқиғалар, тапсырыстар, тауарлар, келісімдер, мәртебелер және басқа объектілер.

3. Деректер құрылымы

   Өріс атаулары, түрлері, міндеттілігі, рұқсат етілген мәндер және мысалдар.

4. Түрлендіру ережелері

   Күндер, валюталар, анықтамалықтар, идентификаторлар және есептелетін көрсеткіштер форматтары.

5. Беру тәсілі

   API, webhook, SDK, дерекқорға тікелей қосылу, SFTP, бұлттық сақтау немесе пакеттік импорт.

6. Жиілік

   Нақты уақыт режимінде, бірнеше минут сайын, күн сайын немесе оқиға бойынша.

7. Жаңарту ережелері

   Толық жүктеу, инкременттік жаңарту, жазбаны ішінара өзгерту немесе өзгерістер ағыны.

8. Қателерді өңдеу

   Жауап кодтары, қайталау әрекеттері, журналдау, хабарламалар және қайта өңдеу.

9. Қайталаудан қорғау

   Операция идентификаторы, идемпотенттілік ережелері және жүктеуді қауіпсіз қайталау.

10. Қауіпсіздік

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

11. Қабылдау критерийлері

    Интеграцияның толықтығы, дәлдігі, жылдамдығы және тұрақтылығы қалай тексеріледі.

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

8. Интеграция тәсілін таңдау

Архитектура жүйелердің мүмкіндіктеріне және қажетті жаңарту жылдамдығына байланысты.

SDK және web tracking

Сайттан немесе мобильді қосымшадан әрекеттерді беру үшін қолданылады: қараулар, авторизация, себетке қосу және басқа цифрлық оқиғалар.

API

Жүйелер арасында деректерді нақты уақытқа жақын режимде басқарылатын түрде алмасуға қолайлы.

Webhooks

Дереккөз оқиға болғаннан кейін деректерді жібереді. Мысалы, тіркелгеннен, сатып алғаннан немесе тапсырыс мәртебесі өзгергеннен кейін.

Дерекқорлар және қоймалар

CRM-платформа SQL-дерекқорлардан, BigQuery, Snowflake және басқа қоймалардан деректер ала алады.

Файлдық алмасу

CSV немесе XML файлдары SFTP, Amazon S3, Google Cloud Storage, Azure Storage немесе басқа қорғалған арна арқылы беріледі. Бұл тәсіл тұрақты пакеттік жүктеулерге қолайлы.

Change Data Capture

CDC бүкіл кестені емес, өзгерістер ағынын беруге мүмкіндік береді: жазбаны қосу, жаңарту немесе жою. Мысалы, Debezium бастапқы дерекқордағы INSERT, UPDATE және DELETE операцияларын тіркеп, оларды қосылған жүйелерге оқиға түрінде береді. Debezium: Change Data Capture

Bloomreach SDK, API, CSV/XML, SQL-дерекқорлар және бұлттық қоймалар арқылы деректер қабылдауды қолдайды. Платформаның өзі техникалық мүмкіндік болған кезде клиенттер, тапсырыстар және тауарлар туралы деректерді нақты уақытта беруді ұсынады. Bloomreach: Technical overview, Bloomreach: Data imports

9. Іске асыру және конфигурациялау

ТТ келісілгеннен кейін техникалық іске асыру басталады.

Жоба архитектурасына қарай мыналар орындалады:

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

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

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

10. Тестілеу

Бүкіл процестің дұрыстығы расталғанда ғана интеграция дайын деп есептеледі.

Біз тестілеудің бірнеше деңгейін жүргіземіз.

Құрылымды тексеру

Барлық өрістер беріле ме? Олар келісілген түрлер мен форматтарға сәйкес келе ме?

Бизнес-мағынаны тексеру

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

Сәйкестендіруді тексеру

Дубльдер жасалып жатқан жоқ па? Әртүрлі құрылғылардағы әрекеттер дұрыс біріктіріле ме? Әртүрлі клиенттердің деректері араласып кетпей ме?

Көлемдерді тексеру

Дереккөз бен қабылдаушы жүйедегі клиенттер, тапсырыстар және оқиғалар саны сәйкес келе ме?

Қайта жүктеуді тексеру

Импортты немесе API-сұрауды қайта іске қосқанда дубльдер пайда болмай ма?

Кідірістерді тексеру

Сценарий іске қосылғанға дейін деректер CRM-ге жетіп үлгере ме?

Теріс тесттер

Өріс бос болса, санат белгісіз болса, күн қате болса, API қолжетімсіз болса немесе деректер ішінара жүктелсе не болады?

Толық тізбекті тестілеу

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

Осыдан кейін ғана интеграция жұмыс ортасына көшіріледі.

11. Іске қосу, мониторинг және дамыту

Іске қосылғаннан кейін ақпараттық жүйемен жұмыс аяқталмайды.

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

Біз мыналарды бақылаймыз:

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

Бизнес-процесс өзгерген кезде деректер моделін, техникалық талаптарды және жүйе конфигурациясын жаңартамыз.

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

Бізге қандай міндеттермен жүгінуге болады

Бізге мына жағдайларда жүгінуге болады:

• клиенттік деректер бірнеше жүйеде орналасып, бірыңғай профильге біріктірілмесе
• CRM толық емес немесе қате деректер алса
• базада клиент дубльдері болса
• коммуникацияларды сатып алулармен сенімді байланыстыру мүмкін болмаса
• Bloomreach Engagement-ті енгізу немесе қайта баптау қажет болса
• жаңа дереккөзді немесе арнаны қосу керек болса
• деректер моделін және интеграцияға ТТ әзірлеу қажет болса
• клиенттерді, оқиғаларды, тапсырыстарды немесе каталогты беруді ұйымдастыру керек болса
• деректер сапасына байланысты сегменттер мен сценарийлер дұрыс жұмыс істемесе
• қайталама сатылымдарды, cross-sell, қайта белсендіруді немесе клиенттердің кетуін болдырмауды автоматтандыру қажет болса
• қолданыстағы CRM-архитектураны тексеріп, өзгерту қажет болса
• аналитиканы және автоматтандырылған сценарийлерді бағалауды баптау қажет болса.

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

Бизнес не алады

CRM-автоматтандырудың нәтижесі — жай ғана бапталған платформа емес.

Бизнес мыналарды алады:

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

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