Avtomatlaşdırma

İnteqrasiyalar: CRM, poçt, anbar

Məlumatların ikiqat daxil edilməsi sistemlərin əlaqəli olmadığının dəqiq əlamətidir. Mübadilənin adətən harada qırıldığını, nasazlıqda nə etmək lazım olduğunu və bunun niyə birdəfəlik iş olmadığını təhlil edirik.

8 sentyabr 2026

Əksər şirkətlərdə artıq bir neçə sistem var: müraciətləri olan sayt, CRM, poçt, məhsul və ya xidmət uçotu, mühasibatlıq. Hər biri ayrılıqda normal işləyir. Problem birləşmə yerlərində yaranır — məlumatların birindən digərinə keçməli olduğu, amma mübadilə buferi olan insan vasitəsilə keçdiyi yerdə. Əlaqənin dəqiq harada qırıldığını və bununla nə etmək lazım olduğunu təhlil edək.

Simptom kimi ikiqat daxiletmə

Əməkdaş eyni məlumatları iki dəfə daxil edirsə — bu, nizam-intizam məsələsi deyil, olmayan inteqrasiyadır. Əlamətləri kənardan asan görmək olar:

saytdan müraciət poçta gəlir, CRM-də kart isə əl ilə yaradılır;
məhsul qalıqları uçot sistemində aparılır, saytda isə gündə bir dəfə ixracla və ya zənglə yenilənir;
hesab bir proqramda verilir, ödəniş statusu isə digərində qeyd olunur;
göndəriş üçün müştəri siyahısı cədvələ ixrac və göndəriş xidmətinə yükləmə ilə toplanır.

İkiqat daxiletmənin qiyməti yalnız sərf olunmuş vaxt deyil. O, zəmanətlə uyğunsuzluqlar yaradır: bir sistemdə telefon hərf səhvi ilə, digərində sifariş ləğv edilib, saytda isə məhsul hələ də mövcuddur. Sonra daxiletmənin özündən baha başa gələn nəticələrlə iş başlayır.

Ayrıca effekt — mənbənin itməsi. Müraciət əl ilə köçürüləndə kampaniya işarəsi və ziyarətçi identifikatoru məktubda qalır və CRM-ə çatmır. Bu, başdan-başa analitikanı ən birinci addımda sındırır.

Əlaqə adətən harada qırılır

Mübadilənin sındığı yerlər kifayət qədər eynitiplidir.

Bir mahiyyət barədə fərqli təsəvvürlər. CRM-də müştəri telefonu olan kontaktdır. Uçot sistemində — rekvizitləri olan kontragent. Saytda — e-poçtu olan hesab. Qeydləri əlaqələndirmək üçün ümumi açar lazımdır. Onu əvvəlcədən müəyyən etməyiblərsə, uyğunlaşdırma ada və ya telefona görə gedir və gec-tez dublikatlar yaranır.

Fərqli formatlar. Artı ilə və artısız telefon, iki variantda tarix, qəpikli və qəpiksiz məbləğlər, ölçü vahidləri. Sınaq mərhələsində hər şey uyğun gəlir, müxtəlif mənbələrdən real məlumatlarda isə — yox.

Məcburi sahələr. Qəbul edən sistem göndərəndə sadəcə olmayan sahəni tələb edir. Mübadilə hər ikinci qeyddə çökür və müştəri şikayət edənə qədər bunu heç kim görmür.

Xarici sistemlərin məhdudiyyətləri. Demək olar ki, hər xidmətin sorğuların sayına limiti var. Min qeydin birdəfəlik ixracı ona dirənib yarıda dayana bilər.

Başqasının tərəfində dəyişikliklər. Xidmət mübadilə interfeysini yenilədi, cavab formatını dəyişdi və ya giriş açarını geri çağırdı. Sizin kodunuz bu zaman dəyişmədi — amma işləməyi dayandırdı.

Sinxronlaşdırma və onun konfliktləri

İstənilən inteqrasiyanın əsas sualı: məlumatlar hansı istiqamətə gedir və hər sahə üzrə kim əsasdır.

Birtərəfli mübadilə sadə və etibarlıdır. Saytdan müraciət CRM-ə gedir, geri heç nə qayıtmır — konflikt yoxdur. İkitərəfli sinxronlaşdırma bir dərəcə mürəkkəbdir, çünki qeydin mübadilə seansları arasında hər iki sistemdə dəyişdirildiyi hal yaranır.

Belə vəziyyətləri faktla təhlil etmək deyil, əvvəlcədən həll etmək lazımdır. Variantlar:

Hər sahə üçün həqiqət mənbəyi təyin etmək. Qalıqlar — yalnız uçot sistemindən, əlaqə məlumatları — yalnız CRM-dən, qiymət — yalnız qiymət siyahısından. Əsas olmayan sistemdə dəyişiklik ya qadağan edilir, ya da üzərinə yazılır.
Son dəyişikliyi qalib saymaq. Reallaşdırmada sadədir, amma nəzərə çarpmayan məlumat itkisinə gətirir: kiminsə dəyişikliyi səssizcə yox olacaq.
Konflikti qeydə almaq və insanı çağırmaq. Yavaş, amma heç nə itmir. Səhvin qiymətinin yüksək olduğu yerdə yerindədir.

İkinci vacib sual — mübadilə rejimi. Hadisə üzrə mübadilə (sistem dəyişiklik barədə özü xəbər verir) demək olar ki, dərhal aktual məlumat verir, amma qəbul edən tərəfin əlçatan olmasını tələb edir. Cədvəl üzrə mübadilə sadə və dayanıqlıdır, amma məlumatlar həmişə bir qədər geri qalır. Məhsul qalıqları üçün bu gecikmə kritik ola bilər, hesabatlılıq üçün — yox.

Və unudulan üçüncüsü: təkrar emal. Şəbəkə gözünü qırpdı, mesaj iki dəfə getdi. Mübadilə artıq emal edilmiş qeydi tanımağı bacarmırsa, sifariş dublikatları alacaqsınız. Hər ötürülən əməliyyatın təkrarda onu tanımaq mümkün olan identifikatoru olmalıdır.

Təkrarlardan müdafiəsi və konfliktlərin həlli qaydası olmayan inteqrasiya düz ilk şəbəkə nasazlığına qədər işləyir.

Mübadilə nasazlığında nə etməli

Nasazlıq müstəsna vəziyyət deyil, bir neçə sistemin birləşməsinin daimi iş rejimidir. Bundan çıxış edərək layihələndirmək lazımdır.

Nəzərdə tutulmalı olanlar:

Əməliyyatlar jurnalı. Nəyi ötürməyə çalışdılar, nə vaxt, hansı nəticə ilə. Jurnal olmadan insidentin təhlili təxminə çevrilir.
Növbə və təkrar cəhdlər. Uğursuz ötürmə atılmır, təxirə salınır və artan intervalla təkrarlanır.
Məsula bildiriş. İnsan problem barədə müştəridən deyil, sistemdən öyrənməlidir.
Əl ilə təkrar. Səbəb aradan qaldırıldıqdan sonra konkret əməliyyatı yenidən işə salmaq imkanı.
Tutuşdurma. İki sistemdə qeydlərin sayının və əsas məbləğlərin uyğun gəldiyinin dövri yoxlanması. Heç bir səhv verməmiş səssiz uyğunsuzluqları məhz tutuşdurma tutur.

Girişlər barədə ayrıca demək lazımdır. Açarların və tokenlərin etibarlılıq müddəti var, parollar dəyişir, girişə yenidən baxılarkən inteqrasiya hesabının hüquqları əlindən alına bilər. Bu açarların harada saxlandığını və kimin yenilədiyini əvvəlcədən bilməyə dəyər — giriş və təhlükəsizlik məsələləri burada avtomatlaşdırma ilə birbaşa kəsişir.

İnteqrasiya niyə birdəfəlik iş deyil

Sistemlərin birləşməsi dəyişən mühitdə yaşayır. Xarici xidmətlər dəyişir, öz prosesiniz dəyişir, yeni sahələr əlavə olunur, yeni anbar və ya ikinci hüquqi şəxs yaranır. Təhvil verilib unudulmuş inteqrasiya öz-özünə deqradasiyaya uğrayır.

Praktikada bu o deməkdir ki, inteqrasiyanın olmalıdır:

biznes və podratçı tərəfindən təyin edilmiş məsul;
istifadəçilərin iştirakı olmadan mübadilənin çökməsi barədə xəbər verən monitorinq;
sənədləşmə: hansı sahələr ötürülür, hansı istiqamətə, hansı qaydaya görə;
dəyişikliklərin istehsala çıxmazdan əvvəl yoxlandığı test mühiti;
yalnız hazırlanmaya deyil, dəstəyə də büdcədə nəzərdə tutulmuş resurs.

Sonuncu bəndi razılaşmalar mərhələsində ən çox nəzərə almırlar, sonra isə qəza rejimində müzakirə edirlər. Dəstəyi dərhal nəzərə almaq daha dürüstdür — bu, hostinq kimi sahiblik dəyərinin hissəsidir.

Başlamazdan əvvəl yoxlama siyahısı

Bütün sistemlər sadalanıb və onlar arasında hansı məlumatların getdiyi müəyyən edilib.
Hər sahə üçün həqiqət mənbəyi təyin edilib.
Qeydlərin sistemlər arasında uyğunlaşdırıldığı ümumi açar seçilib.
Mübadilə rejimi müəyyən edilib: hadisə üzrə və ya cədvəl üzrə, hansı tezliklə.
Konflikt və təkrar ötürmə zamanı davranış təsvir olunub.
Jurnal, təkrarlar növbəsi və nasazlıqda məsula bildiriş var.
Məlumatların müntəzəm tutuşdurulması qurulub.
Giriş açarlarının harada saxlandığı və kimin onları uzatdığı məlumdur.
Büdcədə müşayiət üçün sətir var.

Sistemlərin birləşməsi artıq yığılıbsa, amma müntəzəm ayrılırsa — tutuşdurma və jurnalla başlamağa dəyər: onlar real mənzərəni istənilən auditdən tez göstərir. Tapşırığı burada müzakirə etmək, belə işlərə necə yanaşdığımıza isə avtomatlaşdırma bölməsində baxmaq olar.