Magento B2B Kurulumlarında En Pahalı 3 Mimari Hata

Kompleks Magento B2B projelerinde en pahalı hatalar neden sistem çalışırken ortaya çıkar

Kurumsal B2B şirketleri Adobe Commerce veya Magento üzerine ciddi bütçeler ayırır. Bu projelerde en pahalı hatalar genellikle sitenin çalışmamasından kaynaklanmaz. Site açılır, ürünler listelenir, sipariş alınır. Sorun, yanlış kurgulanan mimari nedeniyle her yeni müşteri hesabının, her fiyat güncellemesinin ve her sipariş sürecinin operasyonel ve teknik maliyeti biraz daha artırmasıdır. İlk altı ayda fark edilmeyen bu maliyet, ikinci yılda yeniden indeksleme için gece vardiyaları, ERP ile uyuşmayan stoklar ve satış ekibine e posta ile gelen siparişler olarak geri döner.

Bu yazıda, 20 binin üzerinde SKU ve yüzlerce kurumsal müşteri hesabı olan Magento B2B kurulumlarında en sık gördüğümüz üç mimari hatayı, bunların gerçek maliyetini ve doğru yaklaşımı anlatıyoruz.

Üç hata birbirinden bağımsız görünse de hepsi aynı kökten gelir: Magento'yu ERP'nin bir kopyası gibi kurgulamak yerine, ERP ile konuşan ince ve güncellenebilir bir ticaret katmanı olarak tasarlamamak.

Hata 1: Müşteriye özel fiyatlandırmayı Magento fiyat indeksine yüklemek

B2B'de iki müşteri aynı fiyat listesine bakmaz. Projenin başında en kolay görünen yol, her kurumsal müşteri için ayrı bir customer group ve ayrı bir shared catalog açıp sözleşme fiyatlarını doğrudan Magento'ya girmektir. İlk 20 müşteride bu yaklaşım sorunsuz çalışır. Sorun, müşteri sayısı 200'ü geçtiğinde başlar.

Magento fiyat indeksi, yani catalog_product_index_price tablosu, her ürün için her customer group ve her website kombinasyonunda ayrı bir satır üretir. 20 bin ürünü, 300 müşteri grubu ve 3 website'ı olan bir kurulumda bu tablo tek başına 18 milyon satıra ulaşır. Buna shared catalog izin indeksleri de eklendiğinde yeniden indeksleme süresi dakikalardan saatlere çıkar. ERP'den gelen fiyat güncellemesi indeks bitene kadar vitrine yansımaz, yani kilit müşteri sabah güncellenen fiyatı öğleden sonra görür. Deployment ve katalog importu riskli operasyonlara dönüşür, çünkü uzun süren indeksleme sırasında cron kilitleri ve veritabanı kilitlenmeleri yaşanır.

Doğru yaklaşım, fiyat segmentlerinin sayısını küçük tutmaktır. Bayi seviyesi, bölge, sözleşme tipi ve müşteri segmenti gibi az sayıda customer group ile fiyatların büyük bölümü karşılanabilir. Gerçekten hesaba özel olan istisnalar ise Magento'nun fiyat motorunu şişirmeden, SKU ve şirket kimliği ile sorgulanan ve önbelleğe alınan ayrı bir fiyat servisinde yönetilmelidir. Böylece indeks tablosu yönetilebilir boyutta kalır, ERP fiyat güncellemeleri dakikalar içinde vitrine yansır ve arama ile checkout hızı korunur.

Hata 2: ERP entegrasyonunu senkron ve noktadan noktaya kurmak

İkinci hata entegrasyon mimarisinde yapılır. Birçok ekip, stok kontrolü, fiyat sorgusu ve sipariş aktarımı için Magento ile kurumsal ERP arasında doğrudan ve eş zamanlı bir bağlantı kurar. Müşteri sepete ürün eklediğinde ERP'ye stok sorulur, checkout'ta fiyat teyit edilir ve sipariş tamamlanır tamamlanmaz ERP'ye yazılır.

Bu kurgu, ERP sağlıklı çalıştığı sürece iyi görünür. ERP bakıma girdiğinde, gece toplu işlem çalıştırdığında veya ağ gecikmesi yaşandığında ise tüm checkout hattı durur. Zaman aşımına uğrayan senkron çağrılar mükerrer siparişlere, ERP'de açılıp Magento'da görünmeyen hayalet stok rezervasyonlarına ve tamamen kaybolan işlemlere yol açar. Buna ek olarak gece çalışan tam katalog senkronizasyonu, yüz binlerce ürünü her seferinde baştan yazdığı için indeksleme ile çakışır ve admin paneli sabah saatlerine kadar yavaşlar.

Doğru yaklaşım, asenkron öncelikli bir entegrasyon kurgusudur. Magento'nun kendi mesaj kuyruğu altyapısı ve RabbitMQ üzerinde çalışan consumer'lar ile sipariş aktarımı arka planda yapılır; müşteri checkout'u tamamlar, ERP'ye yazma işlemi kuyrukta bekler. Stok ve fiyat verisi ise tam senkronizasyon yerine yalnızca değişen kayıtların aktarıldığı delta senkronizasyonu ile güncellenir. Her sipariş aktarımına bir idempotency anahtarı eklenerek aynı siparişin ERP'ye iki kez yazılması engellenir. ERP ile Magento arasına ince bir ara katman konulduğunda ERP tarafındaki her değişiklik Magento kodunu etkilemez ve yıllık bakım maliyeti ciddi şekilde düşer.

Hata 3: Kurumsal satın alma sürecini standart B2C checkout'una sıkıştırmak

Üçüncü hata, sistem ilk gün canlıya alındığında görünmez. Şirket, Magento'yu klasik bir tüketici mağazası akışıyla kurar: ürün, sepet, checkout, ödeme. Oysa gerçek bir kurumsal satın alma süreci çok daha katmanlıdır. Satın almayı başlatan kişi ile onaylayan kişi farklıdır, bütçe ve kredi limiti kontrolü vardır, sipariş çoğu zaman bir satın alma emri numarasına bağlanır, fiyat pazarlığa açıktır ve ödeme kredi kartıyla değil açık hesap ile yapılır.

Platform bu gerçekleri dijital olarak karşılamadığında kurumsal alıcılar sistemi devre dışı bırakır. Siparişler yine telefonla ve e posta ile satış temsilcisine gelir, temsilci siparişi admin panelinden elle girer ve ciddi bütçe harcanan platform bir broşür siteye dönüşür. Daha pahalı olan ise veri modelidir. Şirket hesapları, roller ve onay kuralları baştan kurgulanmadığında bu yapılar sonradan eklenir ve mevcut müşteri verisinin taşınması gerekir. ERP tarafında müşterinin şirket mi yoksa satın alma sorumlusu mu olduğu, kredi limitinin hangi sistemde yaşadığı gibi sorular canlıya çıktıktan sonra cevaplanmaya çalışılır.

Doğru yaklaşım, mimari dokümanı yazmadan önce kilit müşterilerin gerçek satın alma akışını çıkarmaktır. Hangi roller sipariş oluşturuyor, hangi tutarın üzerinde onay gerekiyor, hangi müşteriler açık hesapla çalışıyor ve kredi limiti kimin tarafından yönetiliyor sorularına net cevap alındıktan sonra Adobe Commerce B2B özellikleri bu akışa göre yapılandırılır. Company Accounts, roller ve izinler, Approval Rules, Purchase Orders, Negotiable Quotes, açık hesap ödemesi ve kredi limitleri bu amaçla vardır. Checkout'u varsayılan haliyle bırakıp bu özellikleri sonradan eklemek yerine, baştan satın alma sürecinin etrafında kurgulamak hem geliştirme maliyetini hem de müşteri benimsemesini doğrudan etkiler.

Üç hatanın ortak kökü ve doğru mimari yaklaşım

Üç hata da aynı yerden gelir: Magento'nun, kurumun tüm karmaşıklığını içinde taşıması gerektiği varsayımından. Fiyat istisnaları, ERP mantığı ve satın alma kuralları Magento'nun içine gömüldükçe platform ağırlaşır, güncellenmesi zorlaşır ve her yeni müşteri bir risk haline gelir. Doğru mimaride Magento, fiyat servisi ile konuşan, ERP ile kuyruk üzerinden haberleşen ve kurumsal satın alma sürecini kendi B2B modülleriyle yansıtan ince bir ticaret katmanıdır.

Kendi kurulumunuzu hızlıca test etmek için üç soru yeterlidir. Fiyat indeksinizin satır sayısı kaç milyon ve tam yeniden indeksleme kaç dakika sürüyor? ERP beş dakika yanıt vermediğinde müşteriniz sipariş verebiliyor mu? Kilit müşterilerinizin siparişlerinin yüzde kaçı hâlâ e posta ile geliyor? Bu üç sorudan birine rahat cevap veremiyorsanız, maliyet büyümeden mimariyi gözden geçirmenin zamanı gelmiş demektir.

Magento B2B mimarinizi birlikte değerlendirelim

Mevcut Magento veya Adobe Commerce B2B kurulumunuz için 30 dakikalık ücretsiz bir mimari değerlendirme sunuyoruz. Bu görüşmede fiyat indeksinizin boyutunu, ERP senkronizasyon modelinizi ve şirket hesabı yapınızı birlikte inceliyor, en büyük maliyet kalemini ve ilk adımı somut olarak ortaya koyuyoruz.