Bayi ağı kuran bir firmada aynı müşteri üç farklı bayinin listesinde bulunabilir. Bir bayi telefonda randevu aldığını yazar, diğeri aynı kişiye eski bir teklifi yollar, merkez ise hangi bayinin ne sattığını ay sonunda Excel’den toplamaya çalışır. Sorunun kaynağı çoğu zaman verinin tek bir yerde durmamasıdır.
Bu yazıda bayi yönetim yazılımının nasıl kurulması gerektiğini anlatıyorum: merkezin neleri görmesi, bayinin neleri yalnız kendi görmesi ve bunun teknik olarak nasıl ayrıldığı. Anlattığım yapı, XPEL Türkiye bayi ağı için geliştirdiğimiz XPEL CRM üzerinden. Yazılım şu an demo ve beta aşamasında; bu yüzden onu tasarlanmış ve geliştirilmekte olan bir sistem olarak anlatıyorum.
Bayi ağında veri neden tek yerde durmaz?
Tek bir işletmede veri zaten tek kişinin elindedir. Bayi ağında her bayi kendi atölyesinin, kendi müşterisinin ve kendi cirosunun sahibidir. Merkez ise markayı, fiyat disiplinini ve kalite standardını yönetmek ister. İki taraf da aynı veriye ihtiyaç duyar ama aynı ölçüde görmemesi gerekir.
Excel ile başlayan bu düzen bir süre çalışır. Bayi sayısı beşi geçtiğinde ise dosya sürümleri çatallanır, hangi tabloda hangi müşteri olduğu tartışma konusu olur. Ben bu noktada genelde şunu soruyorum: merkez bir sabah bir bayinin müşteri listesini açtığında, bu bayinin bunu bilmesini ister misiniz? Cevap çoğu zaman hayır olur. Bu yüzden sorunu ekran tasarımıyla değil, veri ayrımıyla çözmek gerekir.
Çok kiracılı ne demek?
Çok kiracılı (multi-tenant) yapıda tek bir yazılım kurulumu birden fazla bağımsız kurumu barındırır. Her kiracı kendi kayıtlarıyla çalışır ve diğerlerinin verisi ona görünmez. Bankacılık uygulamalarının çalışma mantığına benzer: aynı uygulama, herkes yalnızca kendi hesabını görür.
Bayi ağında bu mantık iki katmanlı kurulur. Bayiler birer kiracıdır ve yalnızca kendi kayıtlarını görür. Merkez ise ayrı bir yetkiye sahiptir: tüm bayilerin kayıtlarına üst düzeyden bakar, raporlarını çıkarır, rolleri tanımlar. Asıl mesele, bu ayrımın sayfada bir filtre olarak kalmayıp veritabanı kurallarında ve sunucu tarafındaki yetki kontrolünde yapılmasıdır. Filtre atlanabilir; veri katmanındaki kural atlanamaz.
Bu nedenle XPEL CRM’in tasarımında her kaydın hangi bayiye ait olduğu baştan işaretlenir. Bir bayinin oturumu başka bir bayinin kaydını istese bile sistemin bu isteği reddetmesi gerekir. Bu kural bir ekran kodunda değil, veri erişim kurallarında tanımlanmalıdır.
Merkez ve bayi neyi görür?
Aşağıdaki tablo, bayi ağı yazılımında rollerin kabaca nasıl ayrıldığını gösterir. Burada asıl konu görünürlüktür.
| Rol | Ne görür | Ne yapar |
|---|---|---|
| Merkez | Tüm bayilerin müşteri, araç, iş emri ve randevu kayıtları | Dashboard ve raporları izler, rol matrisini yönetir |
| Bayi | Yalnızca kendi müşterileri ve kendi iş emirleri | Kendi randevu, cari ve tahsilat kayıtlarını yönetir |
| Çalışan (bayi içi) | Bayisinin tanımladığı kapsam kadar | Yetkisi verilen modülde çalışır |
Üçüncü satırı tabloya koymak tesadüf değil. Bayi içinde de her çalışanın her kaydı görmesi gerekmez. Bir servis danışmanı kasa ekranına bakmak zorunda değildir. Rol matrisi bu ayrımı tek yerden yönetir ve değişiklikler de kayıt altında tutulmalıdır.
Bir bayi yönetim yazılımında hangi modüller olmalı?
Her bayi ağı aynı modüllere ihtiyaç duymaz; ama çoğunda şu başlıklar çıkar. Kapsamı küçük tutmak, ilk sürümü hızlı çıkarmanın en güvenli yoludur.
- Müşteri kaydı: iletişim bilgisi, geçmiş işler ve notlar, bayi bazlı
- Araç ya da ürün kaydı: hangi müşteriye hangi araç ya da ürünle hizmet verildiği
- İş emri: teklif, onay, işlem ve teslim adımları
- Randevu takvimi: bayi bazlı, çakışma kontrolü olan
- Cari ve tahsilat: borç, ödeme ve taksit takibi
- Dashboard ve raporlar: merkez için bayi karşılaştırması, bayi için kendi günlük durumu
XPEL CRM bu modüllerin çoğunu kapsıyor; ön görüşme, özel takvim ve taksit takibi de sistemde yer alıyor. Yine de bir firmanın ilk ay gerçekten hangi ekrana ihtiyaç duyduğunu, bayilerin mevcut günlük iş akışından çıkarmak gerekir. Listeyi masaya koyup “bu olmadan iş durur mu?” diye sormak, en çok zaman kazandıran sorudur.
Bu konuda daha geniş bir çerçeve için özel yazılım nedir yazımızda hazır program ile firmaya özel yazılımın farkını ayrıntılı anlattık.
Teknik tercih: React, TypeScript ve Firebase
XPEL CRM React ve TypeScript ile yazıldı. TypeScript burada önemli bir güvencedir: bayi sayısı ve modül sayısı arttıkça, bir alanın adını değiştirdiğinizde hangi ekranın bozulacağını derleme anında görmek, yayın sonrası hata ayıklamaktan çok daha ucuzdur.
Arka uçta Firebase kullanıldı: kimlik doğrulama, Firestore veritabanı ve Cloud Functions. Bu seçim, sunucu bakımını minimuma indirir ve bayi bazlı yetki kurallarını veritabanı tarafında tanımlamayı kolaylaştırır. Her seçimin bir bedeli var. Firebase’de veri modelini baştan iyi kurmak gerekir, çünkü sonradan büyük bir veri taşıması yapmak zahmetlidir. Kayıtların bayi kimliğiyle nasıl ilişkilendiği bu yüzden modelin ilk kararlarından biri olmalıdır.
Bu tür bir yazılımın tekniğini bilmeden değerlendirmek zor. Ama yazılım firmasına sorabileceğiniz üç soru var: veri hangi bulutta duruyor, bayi verisi birbirinden nasıl ayrılıyor ve kaynak kod kimde kalıyor. Son soru için yazılım sözleşmesi ve kaynak kod yazısına bakabilirsiniz.
Demo ve beta aşaması ne anlama geliyor?
Bu yazıda XPEL CRM’i bir ürün olarak satmıyoruz; bir referans işinin parçası olarak anlatıyoruz. Yazılım şu an demo ve beta aşamasında. Mimari ve modüller tasarlandı, geliştirme sürüyor; bayi ağının gerçek günlük işinde yaygın olarak kullanıldığını söylemek doğru olmaz.
Bunu açıkça yazmak önemli, çünkü bayi ağı yazılımı seçerken en büyük risk, vaat edilen özelliklerin canlı kullanımda çıkmamasıdır. Bir firmadan referans isterken iki şeyi ayırt edin: bu sistem bugün kaç bayide gerçek iş yapıyor ve hangi modüller sadece planlandı. Dürüst bir firma bu iki soruya da net cevap verir.
Kendi bayi ağınız için bir çözüm arıyorsanız, önce bayi ağı için web sitesi yazısındaki merkez ve bayi ayrımını okuyun. Web sitesi ile yönetim yazılımı aynı veriye dokunuyorsa, ikisinin de aynı kurallara bağlanması gerekir.
Kontrol listesi: yazılım seçmeden önce
- Merkezin hangi kayıtları görüp hangilerini göremediği yazılı mı?
- Bayi verisi veritabanı ya da yetki katmanında mı ayrılıyor, yoksa sadece ekranda mı gizleniyor?
- İlk ay için en az beş temel modül belirlendi mi ve bayilerin günlük iş akışıyla eşleşiyor mu?
- Yazılım demo mu, beta mı, canlı mı? Hangi bayi ağında gerçekten kullanılıyor?
- Veri dışa aktarılabiliyor mu ve sözleşmeden çıkılırsa veriniz nasıl geri alınacak?
- Kaynak kod ve yönetim hesapları firma adına mı tutuluyor?
Bu soruların üçüne net cevap alamıyorsanız, teklif aşamasında durmak iyi bir karardır. Bayi ağı büyüdükten sonra veri ayrımını düzeltmek, baştan doğru kurmaktan çok daha pahalıya gelir.
Bu yazıdaki bilgiler XPEL Türkiye referans sayfamızdan ve XPEL CRM’in tasarım notlarından alındı. Referans sayfası için XPEL Türkiye sayfamıza bakabilirsiniz; firmaya özel yazılım işlerimiz için İş Yazılımları sayfası geçerli.
