CRM Veri Göçünde Alan Eşleştirme: CSV Başlıkları Otomatik Eşleşir mi?
Eski CRM'inizden bir CSV dosyası dışa aktardınız. Dosyanın ilk satırında sütun başlıkları duruyor: First Name, Company, Email — ya da Türkçe bir sistemden geliyorsa E-posta. Yeni CRM'in içe aktarma ekranı bu başlıkları okuyup her birine bir hedef alan öneriyor. Soru şu: bu öneriye ne kadar güvenebilirsiniz?
Bu sorunun dürüst cevabı "genelde çalışır" değil, "hangi dosyada" ile başlar. Kendi içe aktarma sihirbazımızın otomatik eşleştirmesini iki gerçek dışa aktarım biçimiyle sınadık ve iki ayrı sonuç aldık. Aynı yazılım, aynı ekran, farklı kaynak: birinde bütün başlıklar yerine oturdu, diğerinde başlıkların bir bölümü eşleşmedi ve iki başlık yanlış bir alana bağlandı.
Bu yazı ölçtüğümüz sayıları, iki sonuç arasındaki farkın nereden geldiğini, Türkçe başlıkların neden ayrı bir kalem olduğunu ve eşleşmeyi ekranda onaylarken tam olarak neye bakılacağını anlatıyor. Kapsamı da belli: yazı aktarım anında durur. Aktarımdan sonra kaydın kim tarafından, ne sıklıkta kullanıldığı ayrı bir konu ve burada geçmiyor.
Göçün kalitesini belirleyen soru "kaç sütun eşleşti" değil, "eşleşenlerin kaçı doğru alana gitti".
İçindekiler
Otomatik alan eşleştirme tam olarak neye bakıyor?
Bir içe aktarma sihirbazı dosyanın ilk satırını okur ve her sütun başlığını hedef nesnenin alan adlarıyla karşılaştırır. Eşleşme adların birbirine benzemesi üzerinden kurulur: Company başlığı firma adı alanına, Phone telefon alanına önerilir. Bu bir tahmindir ve tahminin dayanağı başlığın kendisidir — sütunun içindeki değerler değil.
Buradan iki şey çıkıyor. Birincisi, eşleştirmenin doğruluğu sizin verinizin değil, o dosyayı üreten sistemin başlık yazma alışkanlığının fonksiyonudur. Aynı 5.000 kişiyi iki farklı CRM'den dışa aktarırsanız veri aynıdır, eşleşme sonucu farklı olur.
İkincisi, başlık kısaldıkça ve genelleştikçe o başlığa aday olabilecek alan sayısı artar. Name başlığı bir kişi adı da olabilir firma adı da; Owner kayıt sahibi de olabilir hesap sahibi de. Eşleştirme size bir öneri gösterir, bir gerekçe göstermez.
Üçüncü bir nokta da var ve göç planı açısından en önemlisi o: eşleştirme sonucu bir kere ölçülüp rafa kalkacak bir özellik değil. Aynı kaynaktan aynı biçimde alınmış iki dosya benzer davranır, ama kaynak sistem bir sürüm sonrasında başlık metnini değiştirdiğinde eşleşme de değişir. "Geçen sefer eşleşmişti" cümlesi, bu seferki ekranı okumamak için gerekçe olmuyor.
Eşleştirmenin üç sonucu vardır ve ikisi hata sınıfına girer. İkisi arasındaki fark, göçün kalitesini belirleyen asıl fark:
Bir sütun başlığına üç şey olabilir
| Sonuç | Ne demek | Önizlemede nasıl yakalanır |
|---|---|---|
| Doğru eşleşme | Sütun, anlamca karşılığı olan alana bağlandı | Örnek satırlarda değer beklediğiniz kolonda durur |
| Eşleşmeme | Sütun için bir hedef alan önerilmedi | Eşleme ekranında hedefi boş kalan bir satır olarak görünür; üç sonucun en görünür olanı budur |
| Yanlış eşleşme | Sütun, benzer adlı başka bir alana bağlandı | Önizlemedeki örnek satırlarda, değerin hangi kolonda durduğu okunarak yakalanır |
Ölçüm: aynı ekran, iki kaynak, iki sonuç
Otomatik eşleştirmeyi iki gerçek dışa aktarım biçimiyle sınadık. Sonuçlar birbirine benzemedi.
Salesforce Lead dışa aktarımı: 19 başlığın 19'u doğru eşleşti.
HubSpot kişi dışa aktarımı: 17 başlığın 13'ü eşleşti, ikisi yanlış bir alana eşleşti ve City başlığı hiç eşleşmedi.
Aradaki fark yazılımın o gün iyi ya da kötü çalışmasından gelmiyor; iki dosyanın başlık satırları birbirine benzemiyordu. Ölçtüğümüz Salesforce Lead dosyasında başlıklar bizim alan adlarımızla büyük ölçüde aynı kelimeleri kullanıyordu; ölçtüğümüz HubSpot kişi dosyasında başlıkların bir bölümü başka kelimelerle yazılmıştı. Bunu iki ürünün dışa aktarımı hakkında genel bir kural olarak yazmıyoruz — hangi sağlayıcının başlıklarını nasıl ürettiğini ölçmedik, elimizde iki dosya var. Yani ölçtüğümüz şey "eşleştirme iyi mi kötü mü" değil, iki sözlüğün o dosyada ne kadar örtüştüğü.
Bu iki ölçümün sınırını da yazalım: her biri tek bir dosya biçiminin tek bir koşumu. Zoho'nun, Dynamics'in ya da yerel bir muhasebe programının dışa aktarımında kaç başlığın eşleşeceğini ölçmedik. Ölçmediğimiz için bir sayı da söylemiyoruz.
Alınacak ders sayılardan çok dağılımdadır. Sonuç dosyaya göre değişiyorsa, otomatik eşleştirme göç planınızda bir varsayım olamaz. Eşleşmeyi onaylamak için ekranda geçireceğiniz süre her dosyada aynıdır; değişen tek şey, o sürede kaç düzeltme yapacağınızdır.
Türkçe başlıklar: tireli "E-posta" eşleşmiyor
Türkçe başlıklı dosyalarda ölçtüğümüz somut bir kusur var: tireli yazılan "E-posta" başlığı otomatik eşleşmiyor. Bunun sebebini kodda aramadık; eşleşmediğini ölçtük, sebebini yazmıyoruz.
Pratik sonucu şu: Türkçe başlıklı bir dosya yüklüyorsanız, e-posta sütununun hedef alanını elle seçmeyi baştan işin bir adımı sayın. Ve önizlemede ilk bakılacak sütun odur — sonraki bütün iletişim o sütuna bağlanıyor.
Buradan çıkan makul refleks, başlık satırını dışa aktardıktan sonra elle düzenlemek olur. İşe yarar; ama bedelini bilerek yapın. Aktardığınız hâliyle kaynak dosya, göçten sonra "biz ne gönderdik" sorusunun tek cevabıdır. Düzenleme yapılacaksa kopya üzerinde yapılsın, orijinal dosya bir kenarda kalsın.
Bir de şu var: başlık satırını İngilizce bırakmak da tek başına bir çözüm değil. Ölçtüğümüz iki İngilizce başlık kümesi aynı sonucu vermedi. Başlık satırını hangi dilde bırakırsanız bırakın, eşleşmeyi ekranda okumak gerekiyor.
Eşleme ekranına gelmeden önce: hangi sütunlar taşınacak?
Eşleme ekranı bir karar ekranıdır, ama oraya vardığınızda kararların bir kısmı çoktan alınmıştır: dosyada hangi sütunların bulunacağına dışa aktarım sırasında karar verdiniz. Dışa aktarım aracına "bütün alanları ver" dediyseniz ekranda kırk küsur sütunla karşılaşırsınız ve kırkının her biri için bir hedef alan aramanız gerekir.
Sütun sayısını daraltmanın iki somut faydası var. Birincisi, eşleme ekranında okunacak satır sayısı düşer; biraz sonraki dört kontrol on beş sütunda kısa bir işken kırk sütunda öyle olmuyor. İkincisi ve asıl önemlisi: taşımadığınız sütun yanlış eşleşemez. Yanlış eşleşme riskini azaltmanın en ucuz yolu, eşleştirmeyi iyileştirmek değil, eşleştirilecek sütun sayısını azaltmaktır.
Bir sütunun taşınması gerekip gerekmediğine "elimde duruyor mu" diye değil, "yeni sistemde bu alanı kim, hangi ekranda görecek" diye karar verin. Hedef nesnede karşılığı olmayan bir sütun taşınırken iki yoldan biri seçilir: ya o alan yeni bir özel alan olarak açılır ya da değer bir not alanına sıkıştırılır. İkincisi veriyi kaybetmez ama değeri kendi alanında değil bir not metninin içinde bırakır; ertesi yıl "bu bilgi sistemde var mı" sorusunun cevabı belirsizleşir.
Bu liste teknik bir karar değil. Kendi kurduğumuz göçlerde işleyen sıra şu: taşınacak sütunların listesi, o alanları bugün fiilen kullanan kişilerle bir kere oturularak çıkarılır; dosya ondan sonra dışa aktarılır. Ters sırada gidildiğinde eşleme ekranı, kimsenin bilerek vermediği bir kapsam kararının alındığı yer hâline geliyor.
Dört adımlı içe aktarma sihirbazı
-
1
Yükle
Dosya seçilir. Kabul edilen biçimler .csv, .xls ve .xlsx; içe aktarmada dosya başına 25 MB ve iş başına 100.000 satır sınırı geçerlidir. Bu iki sınır içe aktarma işine aittir.
-
2
Alan eşle
Sütun başlıkları hedef alanlarla eşleştirilir. Sistemin önerdiği eşleşmeyi onaylar ya da hedef alanı elle değiştirirsiniz; öneri gelmeyen sütunun hedefini de bu adımda siz seçersiniz.
-
3
Önizle
İş çalışmadan önce örnek satırlar, bağlandıkları hedef alanlarla birlikte gösterilir. Eşleşmeyi onaylamadan önce doğrulayabileceğiniz son adım burasıdır.
-
4
Çalıştır
İş başlatılır. Dosyanın tamamını göndermeden önce aynı dosyanın küçük bir örneğiyle bir kez koşmak, eşleşme hatasını geri alınabilir ölçekte gösterir.
Eşleşmeyi onaylamadan önce: dört kontrol
Eşleme ve önizleme adımları birlikte çalışır: birincisi kararı gösterir, ikincisi kararın sonucunu. İkisini ayrı ayrı okumak, göçte elinizde olan tek gerçek denetim noktasıdır. Aşağıdaki dört kontrol, kendi kurduğumuz göçlerde işe yarayan kısa listedir.
- Hedefi boş kalan satırları sayın. Eşleme ekranında hedef alanı seçilmemiş her sütun bir karardır: ya elle bağlanacak ya bilerek dışarıda bırakılacak. Sayı sıfır değilse listeyi bir kâğıda çıkarın.
- Benzer adlı alan çiftlerini tek tek doğrulayın. Firma adı ile kişi adı, il ile ülke, kayıt sahibi ile hesap sahibi. Yanlış eşleşme bu çiftlerde çıkıyor.
- Örnek satırları soldan sağa okuyun, başlığa göre değil. Gözünüz başlığı doğrulamaya değil, değerin doğru yerde durduğunu doğrulamaya çalışsın. Bu iki farklı iştir ve ikincisi atlanır.
- Tarih ve para sütunlarında değerin kendisine bakın. Bu sütunlar eşleşse bile içindeki biçim taşınırken bozulabilir; önizlemede tek bir örneği okumak yeterli sinyali verir.
Bu dört kontrolün ortak yanı şu: hiçbiri yazılımın söylediğine değil, ekranda duran değere bakıyor. Otomatik eşleştirme bir öneridir; öneriyi doğrulayacak tek şey verinin kendisidir. Atlanmasının bedeli de gecikmeli geliyor — yanlış hedefe bağlanmış bir sütun aktarım anında hata üretmez, doğru görünür, ve bir rapor tutmadığında fark edilir.
Ölçekte ne oldu?
Otomatik eşleştirmenin sınırlarını yazdık; sihirbazın ölçekte ne yaptığını yazmak da dürüstlüğün diğer yarısı. Ölçüldü: bir müşteri kiracısında tek bir işte 1.681 firma aktarıldı ve kayıtlar duruyor.
Bu sayı, aracın büyük bir dosyayı taşıyabildiğini gösteriyor — ama tek başına bir söz değil. Yanında duran ikinci sayı aşağıdaki sınırlar bölümünde ve o sayı iyi haber değil. Doğru okuma ikisini birlikte okumak: araç ölçeği kaldırıyor, bir işin başarıyla bitmesi kendiliğinden olmuyor.
Bizim sınırlarımız
- Kutudan çıkan bir HubSpot, Salesforce, Zoho ya da Dynamics bağlantımız yok. Giden HTTP adres listemizde hiçbir rakip CRM sunucusu geçmiyor; veri bize iki sistem birbiriyle konuşarak değil, sizin dışa aktardığınız dosyayla geliyor.
- Sıfır veri kaybı garantisi vermiyoruz: erişebildiğimiz 8 kiracıda ölçtüğümüz 34 içe aktarma işinin 16'sı başarısız oldu.
- Otomatik eşleştirmenin doğruluğunu iki dışa aktarım biçiminde ölçtük. Üçüncü bir kaynağın başlıklarından kaçının eşleşeceğini bilmiyoruz ve o dosyayı görmeden bir oran söylemeyeceğiz.
- Büyük ya da karmaşık göçlerde sihirbaz tek başına yetmiyor. O durumda REST API üzerinden projeye özel bir aktarım yazıyoruz — yazan biziz; sizin bir ekrandan açacağınız bir seçenek değil.
- Yazılı bir çalışma süresi (SLA) taahhüdü vermiyoruz; kiracı adreslerini dışarıdan izleyen bağımsız bir servis kurulu değil.
Sık sorulan sorular
Eski CRM'imden aldığım CSV'nin sütunları yeni CRM'e otomatik eşleşir mi?
Türkçe başlıklı bir CSV yükleyebilir miyim?
Yanlış eşleşmiş bir sütunu nasıl fark ederim?
İçe aktarma başarısız olabilir mi, sıfır veri kaybı garantisi veriyor musunuz?
Excel'de sütun başlıklarını elle düzeltmek göçü kolaylaştırır mı?
Kutudan çıkan bir HubSpot ya da Salesforce göç aracınız var mı?
Bir CRM veri göçü ne kadar sürer?
İlgili içerikler
- Salesforce nedir — dışa aktarımını ölçtüğümüz platformun kendisi.
- CRM karşılaştırma — Türkiye'de kullanılan CRM yazılımları.
- Satış hattı (pipeline) nedir — göçten sonra fırsat kayıtlarının oturacağı yapı.
- Rapitek CRM ürün sayfası — nesneler, alanlar ve içe aktarma ekranı.
Dosyanızı ekranda birlikte eşleştirelim
Rapitek CRM'i kuran ekip, Salesforce döneminde 200'den fazla kurumsal CRM projesi tamamladı. Ürün yeni, ekip değil: alanları, aşamaları ve raporları biz yapılandırıyoruz, verinizi biz aktarıyoruz, ekibinize Türkçe eğitimi biz veriyoruz.
Keşifte dışa aktardığınız dosyanın başlık satırını birlikte okur, hangi sütunun elle eşleneceğini çıkarırız; çıkan kapsam yazılı olur.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
Kaynaklar
Bu yazıdaki dış olgular şu birincil kaynaklara dayanıyor:
