Veriyi yeniden yazmayı bırakın. Sistemleriniz birlikte çalışsın.
Bir sipariş, gelen kutuları ve tablolar arasında tur atmak zorunda kalmamalı. Bir sistem entegrasyonunu gerçekten kullanışlı kılan, veriler ve hatalar üzerine net anlaşmalardır.
Tek bir siparişi organizasyonunuz içinde takip edin
Hayali bir toptancıyı ele alalım. Bir müşteri çevrimiçi sipariş veriyor, bir çalışan müşteriyi muhasebe sisteminde oluşturuyor ve planlama ekibine teslimat bilgilerini içeren bir e-posta gidiyor. Adres değiştiğinde biri hangi sistemlerin hâlâ güncellenmesi gerektiğini bulmak zorunda kalıyor. API, yazılımlara veri alışverişi için üzerinde anlaşılmış bir yol sunar. Bununla örneğin bir siparişi muhasebe sistemine aktarabilirsiniz. Değer, devrin bütününde yatar: doğru veri doğru yere ulaşır ve çalışanlar bunun başarılı olup olmadığını görebilir.
Hangi sistemin kaynak olduğuna karar verin
İki sistem aynı veriyi değiştirebiliyorsa, hangi değişikliğin geçerli olduğunu kararlaştırmanız gerekir. Her bilgi türü için nerede yönetildiğini kayda geçirin. Örneğin iletişim kişileri için CRM esas alınırken fatura durumunu muhasebe yönetebilir. Kayıtları birbirine bağlamak için sabit bir tanımlayıcı kullanın; iki müşterinin adı aynı olabilir. Boş alanlar, silinen kayıtlar ve farklı yazım biçimleriyle nasıl başa çıkacağınızı da kararlaştırın. Bir sistemdeki boş telefon alanı, diğer sistemdeki doğru bir numarayı yanlışlıkla silmemelidir.
| Veri | Yönetildiği yer |
|---|---|
| İletişim kişileri | CRM |
| Fatura durumu | Muhasebe |
| Kayıtları birbirine bağlama | Ad değil, sabit bir tanımlayıcı |
İşe uygun bir hız seçin
Her değişikliğin anında her yerde görünmesi gerekmez. Günlük bir rapor için planlanmış bir veri aktarımı yeterli olabilir. Sipariş işlemede ise daha hızlı bir güncelleme önemli olabilir. Bu tercih hem sürece hem de ilgili yazılımların neler yapabildiğine bağlıdır. Hangi verilerin erişilebilir olduğunu, hangi yetkilerin gerektiğini ve bir sağlayıcının kaç isteğe izin verdiğini önceden kontrol edin. Ürün açıklamasında API geçmesi, istediğiniz her işlemin desteklendiği anlamına gelmez. Tüm çalışma şeklinizi buna dayandırmadan önce söz konusu devri özel olarak inceleyin.
Başarısız devri de tasarlayın
Bir entegrasyon, geçici olarak erişilemeyen bir sistemle veya zorunlu bir alanı eksik bir siparişle başa çıkabilmelidir. Hangi hataların otomatik olarak yeniden denenebileceğini, hangilerinin önce ilgi gerektirdiğini belirleyin. Tekrar denemenin aynı siparişi iki kez oluşturmasını önleyin; örneğin sabit bir sipariş referansını kontrol ederek. Neyin beklediğini, neyin işlendiğini ve neyin başarısız olduğunu görünür kılın. “Bir şeyler ters gitti” gibi bir mesaj pek yardımcı olmaz. Sorumlu çalışan hangi devrin takıldığını ve devam etmek için neyin gerektiğini anlayabilmelidir.
| Referans | Durum | Açıklama |
|---|---|---|
| ORDER-1041 | İşlendi | Muhasebeye aktarıldı. |
| ORDER-1042 | Bekliyor | Muhasebe geçici olarak erişilemiyor. Yeni deneme planlandı. |
| ORDER-1043 | Başarısız | Zorunlu alan eksik. Bir çalışanın ilgilenmesi gerekiyor. |
| ORDER-1041 | Atlandı | Tekrarlanan deneme sipariş referansından tanındı; yeniden oluşturulmadı. |
Neyin beklediği, neyin işlendiği ve neyin başarısız olduğu tek bir görünümde. Böylece sorumlu çalışan hangi devrin takıldığını görür.
Entegrasyona yalnızca ihtiyacı olanı verin
Sipariş verilerini okuyan bir entegrasyonun, bir yazılımın diğer tüm bölümlerine erişmesi gerekmez. Hangi işlemlerin gerektiğini belirleyin ve erişim yetkilerini, sağlayıcının desteklediği ölçüde buna göre ayarlayın. Erişim anahtarlarına parola gibi davranın ve bunları kimin yönettiğini ve yenilediğini kayda geçirin. Hata mesajlarında sakladığınız verilerde de ölçülü olun. Başarısız bir devri incelemek için bir sipariş referansı, tüm müşteri verilerinin eksiksiz bir kopyasından çoğu zaman daha kullanışlıdır.
Tek bir devir ve bir sorumluyla başlayın
Sık gerçekleşen ve sonucu kolayca kontrol edilebilen bir veri akışı seçin. Normal bir sipariş, mükerrer bir gönderim, bir değişiklik ve eksik bir talep örnekleriyle test edin. Uyarıları kimin takip edeceğini ve bir sağlayıcı bir şeyi değiştirdiğinde entegrasyonun bakımını kimin yapacağını kararlaştırın. Kullanıma aldıktan sonra elle yapılan düzeltmelerin sayısını ve işleme süresini eski durumla karşılaştırın. Böylece entegrasyonun nerede yardımcı olduğunu ve nerede hâlâ ilgi gerektiğini görürsünüz. Güvenilir otomasyon, her şey kendiliğinden yürümese de ekibinize genel bir bakış kazandırır.
Özel yazılımYeni bir sekme pek çok sorunu çözer. Ta ki hangi sürümün doğru olduğunu kimse bilmeyene ve tüm planlamayı tek bir çalışan ayakta tutana kadar. Daha iyi bir yazılıma hazır bir süreci böyle tanırsınız.
Yazıyı okuyun
Web sitesiZiyaretçiniz işletmenizi henüz tanımıyor. Net bir vaat, görünür kanıtlar ve mantıklı bir sonraki adım; büyük sözlerle dolu bir ana sayfadan çok daha fazla işe yarar.
Yazıyı okuyun