Otomasyon

Entegrasyonlar: CRM, e-posta, depo

Çift veri girişi, sistemlerin bağlı olmadığının kesin işaretidir. Veri alışverişinin genellikle nerede koptuğunu, arızada ne yapılacağını ve bunun neden tek seferlik bir iş olmadığını ele alıyoruz.

Çoğu şirkette zaten birkaç sistem çalışır: talepleri olan bir site, CRM, e-posta, ürün veya hizmet kaydı, muhasebe. Her biri tek başına düzgün çalışır. Sorun birleşim noktalarında ortaya çıkar — verilerin birinden diğerine geçmesi gereken ama panosuyla bir insan aracılığıyla geçtiği yerlerde. Bağlantının tam olarak nerede koptuğunu ve bununla ne yapılacağını ele alalım.

Belirti olarak çift giriş

Bir çalışan aynı verileri iki kez giriyorsa bu bir disiplin sorunu değil, eksik bir entegrasyondur. İşaretleri dışarıdan kolayca fark edilir:

  • siteden gelen talep e-postaya düşüyor, CRM kaydı ise elle açılıyor;
  • ürün stokları muhasebe sisteminde tutuluyor, sitede ise günde bir kez aktarımla veya telefonla güncelleniyor;
  • fatura bir programda kesiliyor, ödeme durumu başka birinde işaretleniyor;
  • e-posta gönderimi için müşteri listesi tabloya aktarılıp e-posta servisine yüklenerek hazırlanıyor.

Çift girişin bedeli yalnızca harcanan zaman değildir. Tutarsızlık doğurması garantidir: bir sistemde telefon yazım hatalı, diğerinde sipariş iptal edilmiş, sitede ise ürün hâlâ stokta. Ardından sonuçlarla uğraşmak başlar ve bu, girişin kendisinden daha pahalıya gelir.

Ayrı bir etki, kaynağın kaybolmasıdır. Talep elle aktarıldığında kampanya etiketi ve ziyaretçi kimliği e-postada kalır ve CRM'e ulaşmaz. Bu, uçtan uca analitiği daha ilk adımda bozar.

Bağlantı genellikle nerede kopar

Veri alışverişinin bozulduğu yerler oldukça tek tiptir.

Aynı varlığa farklı bakışlar. CRM'de müşteri telefonu olan bir kişidir. Muhasebe sisteminde şirket bilgileri olan bir cari hesaptır. Sitede e-postası olan bir hesaptır. Kayıtları bağlamak için ortak bir anahtar gerekir. Önceden belirlenmediyse eşleştirme ada veya telefona göre yapılır ve er ya da geç kopyalar belirir.

Farklı formatlar. Artılı ve artısız telefon, iki farklı biçimde tarih, kuruşlu ve kuruşsuz tutarlar, ölçü birimleri. Testlerde her şey tutar, farklı kaynaklardan gelen gerçek verilerde tutmaz.

Zorunlu alanlar. Alan sistem, gönderen sistemde hiç olmayan bir alanı zorunlu tutar. Alışveriş her ikinci kayıtta düşer ve müşteri şikâyet edene kadar kimse görmez.

Dış sistemlerin kısıtları. Neredeyse her servisin istek sayısı sınırı vardır. Bin kaydın tek seferde aktarımı bu sınıra takılıp ortada durabilir.

Karşı taraftaki değişiklikler. Servis alışveriş arayüzünü güncelledi, yanıt formatını değiştirdi veya erişim anahtarını iptal etti. Kodunuz değişmedi — ama çalışmayı bıraktı.

Senkronizasyon ve çakışmaları

Her entegrasyonun kilit sorusu: veriler hangi yöne gidiyor ve her alan için kim ana kaynak.

Tek yönlü alışveriş daha basit ve güvenilirdir. Siteden gelen talep CRM'e gider, geriye hiçbir şey dönmez — çakışma yoktur. İki yönlü senkronizasyon bir derece daha zordur, çünkü bir kaydın alışveriş oturumları arasında iki sistemde de değiştirildiği durum ortaya çıkar.

Bu durumlar sonradan değil, önceden çözülmelidir. Seçenekler:

  1. Her alan için gerçeğin kaynağını atamak. Stoklar — yalnızca muhasebe sisteminden, iletişim bilgileri — yalnızca CRM'den, fiyat — yalnızca fiyat listesinden. Ana olmayan sistemdeki değişiklik ya yasaklanır ya da üzerine yazılır.
  2. Son değişikliği kazanan saymak. Uygulaması basit ama fark edilmeyen veri kaybına yol açar: birinin değişikliği sessizce kaybolur.
  3. Çakışmayı kaydedip insanı çağırmak. Yavaş ama hiçbir şey kaybolmaz. Hatanın bedelinin yüksek olduğu yerlerde uygundur.

İkinci önemli soru alışveriş modudur. Olaya dayalı alışveriş (sistem değişikliği kendisi bildirir) neredeyse anında güncel veri verir ama alan tarafın erişilebilir olmasını gerektirir. Zamanlanmış alışveriş daha basit ve dayanıklıdır ama veriler her zaman biraz geriden gelir. Ürün stokları için bu gecikme kritik olabilir, raporlama için değildir.

Ve unutulan üçüncüsü: yeniden işleme. Ağ gidip geldi, mesaj iki kez gönderildi. Alışveriş zaten işlenmiş bir kaydı tanıyamıyorsa kopya siparişler alırsınız. Aktarılan her işlemin, tekrarda onu tanımayı sağlayan bir kimliği olmalıdır.

Tekrarlara karşı koruması ve çakışma çözüm kuralı olmayan bir entegrasyon, tam olarak ilk ağ arızasına kadar çalışır.

Alışveriş arızasında ne yapmalı

Arıza istisnai bir durum değil, birkaç sistemden oluşan bir yapının olağan çalışma modudur. Tasarım buna göre yapılmalıdır.

Öngörülmesi gerekenler:

  • İşlem günlüğü. Neyin, ne zaman, hangi sonuçla aktarılmaya çalışıldığı. Günlük olmadan olay incelemesi tahmin oyununa dönüşür.
  • Kuyruk ve tekrar denemeler. Başarısız aktarım atılmaz, ertelenir ve artan aralıklarla tekrarlanır.
  • Sorumluya bildirim. İnsan sorunu müşteriden değil sistemden öğrenmelidir.
  • Elle tekrar. Neden giderildikten sonra belirli bir işlemi yeniden başlatabilme.
  • Mutabakat. İki sistemdeki kayıt sayılarının ve temel toplamların tuttuğunun periyodik kontrolü. Tek bir hata vermemiş sessiz tutarsızlıkları tam olarak mutabakat yakalar.

Erişimler hakkında ayrıca söylemek gerekir. Anahtarların ve token'ların süresi vardır, şifreler değişir, bir erişim gözden geçirmesinde entegrasyon hesabının hakları alınabilir. Bu anahtarların nerede saklandığını ve kimin yenilediğini önceden bilmek gerekir — erişim ve güvenlik konuları burada otomasyonla doğrudan kesişir.

Entegrasyon neden tek seferlik bir iş değildir

Sistemler yapısı değişen bir ortamda yaşar. Dış servisler değişir, kendi süreciniz değişir, yeni alanlar eklenir, yeni bir depo veya ikinci bir tüzel kişi ortaya çıkar. Teslim edilip unutulan bir entegrasyon kendi kendine bozulur.

Pratikte bu, entegrasyonun şunlara sahip olması gerektiği anlamına gelir:

  • işletme tarafında ve yüklenici tarafında atanmış bir sorumlu;
  • kullanıcılar olmadan alışverişin düştüğünü bildiren izleme;
  • dokümantasyon: hangi alanlar, hangi yöne, hangi kurala göre aktarılıyor;
  • değişikliklerin canlıya çıkmadan önce kontrol edildiği bir test ortamı;
  • yalnızca geliştirme için değil destek için de bütçelenmiş kaynak.

Son madde anlaşma aşamasında en sık göz ardı edilir ve sonra acil durum modunda tartışılır. Desteği baştan bütçelemek daha dürüsttür — barındırma gibi, sahip olma maliyetinin bir parçasıdır.

Başlamadan önce kontrol listesi

  • Tüm sistemler listelendi ve aralarında hangi verilerin gidip geldiği belirlendi.
  • Her alan için gerçeğin kaynağı atandı.
  • Kayıtların sistemler arasında eşleştirileceği ortak anahtar seçildi.
  • Alışveriş modu belirlendi: olaya dayalı mı zamanlanmış mı, hangi sıklıkla.
  • Çakışmada ve tekrarlanan aktarımda davranış tarif edildi.
  • Günlük, tekrar kuyruğu ve arızada sorumluya bildirim var.
  • Düzenli veri mutabakatı ayarlandı.
  • Erişim anahtarlarının nerede saklandığı ve kimin yenilediği biliniyor.
  • Bütçede destek için bir kalem var.

Sistemleriniz zaten bağlıysa ama düzenli olarak birbirinden ayrışıyorsa, mutabakat ve günlükle başlamak gerekir: gerçek tabloyu her denetimden daha hızlı gösterirler. Görevinizi buradan konuşabilir, bu tür işlere nasıl yaklaştığımızı otomasyon bölümünde görebilirsiniz.