B2B Ürün Konfigüratörü: Kural, BOM, Fiyat ve Teklif Mimarisi

B2B Ürün Konfigüratörü: Kural, BOM, Fiyat ve Teklif Mimarisi

Yazar: Üzeyir Hakan CeylanOluşturulma: Güncellenme: 6 dk okuma
Henüz puanlanmadı Puanınız:

Blog yazısı içeriği

B2B ürün konfigüratörü, seçenekleri yan yana dizen bir form değil; yalnızca teknik olarak üretilebilir, ticari olarak satılabilir ve fiyatlandırılabilir bileşimlerin teklif edilmesini sağlayan kural tabanlı bir üründür.

Bu rehber makine, endüstriyel ekipman, sunucu, elektrik panosu, yapı sistemi, ambalaj ve benzeri karmaşık ürünler için kapsam çıkarmaya yardım eder. Amaç görsel bir seçici yapmak değil; ürün kuralları, BOM/rota, maliyet, fiyat, teklif ve revizyonu aynı izlenebilir yapıda buluşturmaktır.

Konfigüratör neyi çözer?

Karmaşık bir üründe güç, kapasite, malzeme, ölçü, aksesuar, sertifika ve teslimat koşulu birbirinden bağımsız değildir. Bir seçim diğerini zorunlu kılabilir, engelleyebilir veya maliyeti değiştirebilir. Bu ilişkiler yalnızca deneyimli satışçının hafızasında kaldığında teklif kalitesi kişiye bağlı olur.

Microsoft’un ürün konfigürasyon modeli; nitelikleri, kısıtları, hesaplamaları, alt bileşenleri ve kullanıcı gereksiniminden türeyen ürün varyantlarını birlikte ele alır. Microsoft product configuration models belgesi modelin BOM ve rota gibi üretim bilgileriyle ilişkisini açıklar.

Seçimden teklife konfigürasyon omurgası

Müşteri ihtiyacını nitelik, kısıt, geçerli bileşim, BOM, fiyat ve sürümlü teklife bağlayan B2B konfigüratör akışı
Teklifteki her satır, seçim ve kural sürümüne geri izlenebilmelidir.
  1. İhtiyaç: Kullanım amacı ve başarı koşulları toplanır.
  2. Nitelikler: Teknik ve ticari seçenekler kontrollü değerlere dönüşür.
  3. Kısıtlar: Zorunlu, yasak ve koşullu ilişkiler çalışır.
  4. Geçerli bileşim: Üretilebilir yapı ve uyarılar oluşur.
  5. BOM ve rota: Parçalar, işlemler ve hizmetler türetilir.
  6. Maliyet ve fiyat: Kaynak veriler ile ticari kurallar uygulanır.
  7. Teklif sürümü: Sonuç dondurulur, onaylanır ve siparişe aktarılır.

Seçenek listesinden önce ürün modelini kurun

Ürün ailesi, bileşen, nitelik, izin verilen değer, ölçü birimi ve varsayılan değer ayrı kavramlardır. Müşterinin gördüğü “yüksek kapasite” ifadesi, mühendislikte belirli motor, kablo, soğutma ve kasa bileşenlerine dönüşebilir. Pazarlama dili ile teknik model arasında kontrollü bir eşleme gerekir.

Her niteliğin sahibi, veri türü, birimi, geçerli aralığı, görünürlüğü ve değişiklik etkisi kaydedilmelidir. Serbest metni yalnızca gerçekten serbest tasarım gereken yerde kullanın; aksi halde aynı seçenek farklı yazımlarla çoğalır.

Kısıtları açıklanabilir kurallara dönüştürün

Kural; “A seçilirse B zorunlu”, “C ile D birlikte olamaz”, “değer E’yi geçerse F boyutu gerekir” veya “bu sertifika yalnızca belirli pazarda sunulur” biçiminde olabilir. Her kuralın kimliği, açıklaması, sahibi, yürürlük tarihi ve sürümü tutulmalıdır.

Kullanıcıya yalnızca “geçersiz seçim” demeyin. Hangi iki kararın çatıştığını, hangi seçeneğin değiştirilebileceğini ve sistemin otomatik düzeltme yapıp yapmadığını gösterin. Otomatik düzeltme sessiz olmamalı; kullanıcı sonucu onaylamalıdır.

BOM ve rotayı aynı modelden türetin

Geçerli seçimler hangi parçaların, miktarların, operasyonların ve dış hizmetlerin gerektiğini belirlemelidir. Bu çıktı bir şablonu kopyalamak yerine kural sürümüyle yeniden üretilebilir olmalıdır. Değiştirilen bir seçimin BOM ve rota etkisi teklif onayından önce gösterilmelidir.

Alt bileşenleri yeniden kullanmak model bakımını kolaylaştırır. Ancak ortak bileşendeki değişikliğin hangi ürün ailelerini etkilediği bir bağımlılık raporuyla görülmelidir.

Maliyet ve fiyatı birbirinden ayırın

Maliyet; malzeme, operasyon, dış hizmet, kurulum ve lojistik kaynaklarından gelebilir. Satış fiyatı ise müşteri grubu, para birimi, miktar, bölge, kampanya ve onay sınırlarıyla hesaplanabilir. Maliyet değişti diye yayınlanmış teklif sessizce değişmemelidir.

Microsoft, BOM hesaplama gruplarını maliyet uyarıları ve geçerlilik gibi politikalarla; maliyet sürümlerini ise planlı ve standart maliyet kayıtlarıyla ilişkilendirir. BOM calculation groups ve costing versions dokümanları sürüm ve politika ayrımı için yararlı referanslardır.

Teklifi değişmez bir anın kaydı olarak saklayın

Teklif; seçenekler, kural sürümü, BOM özeti, fiyat girdileri, para birimi, vergi, geçerlilik, teslimat varsayımı ve onaylarla birlikte sürümlenmelidir. Yeni bir seçim eski teklifi değiştirmek yerine yeni revizyon oluşturmalıdır.

Müşteriyle paylaşılan PDF veya portal sayfası aynı revizyona işaret etmelidir. Siparişe dönüşümde konfigürasyon yeniden hesaplanırsa farklar bloke edilmeli veya yetkili onayına sunulmalıdır.

Kullanıcı deneyimini soru ağacı olarak tasarlayın

Yüzlerce teknik seçeneği aynı ekrana koymak yerine kullanım senaryosundan başlayın. Erken cevaplar ilgisiz adımları gizlesin; ancak kullanıcı önceki kararına döndüğünde hangi alt seçimlerin sıfırlanacağı önceden açıklansın. Teknik ve ticari özet her adımda erişilebilir olmalıdır.

Görsel önizleme yararlıdır fakat teknik doğruluğun yerine geçmez. Önizleme temsilî ise bunu belirtin; ölçü, renk veya aksesuarın kesin görsel taahhüt olduğu izlenimini vermeyin.

Yönetişim, test ve ölçüm

  • Sınır değerde kapasite, ölçü ve birim dönüşümü;
  • Birbirini dolaylı olarak zorunlu kılan üç kural;
  • Kaldırılan bileşenle kaydedilmiş eski teklif;
  • Farklı para birimi ve miktarda fiyat/onay sınırı;
  • Kural değişirken açık oturum ve kayıtlı taslak;
  • ERP aktarımının tekrarlanması ve aynı siparişin iki kez oluşmasının engellenmesi.

Geçersiz bileşim oranı, açıklanamayan kural hatası, manuel mühendislik müdahalesi, teklif revizyonu, fiyat farkı, sipariş aktarım hatası ve kural yayınlama süresi izlenebilir. Bunlar garanti değil; pilot dönemde başlangıç ölçümü olarak kullanılmalıdır.

Sonuç

Model yönetişimini ürünün parçası yapın

Konfigürasyon modeli bir kez kurulup unutulmaz. Ürün yöneticisi nitelikleri, mühendislik kısıtları ve BOM’u, maliyet ekibi kaynak verileri, satış yönetimi ise fiyat ve onay kurallarını sahiplenmelidir. Hiçbir rol tek başına test edilmemiş modeli canlıya alamamalıdır.

Taslak, incelemede, onaylı, yayında ve kullanımdan kalkmış durumlarını tanımlayın. Yeni sürüm, örnek konfigürasyon kümesi ve beklenen BOM/fiyat sonuçlarıyla otomatik regresyon testinden geçsin. Yayın sonrası kritik hata için önceki sürüme dönüş ve etkilenen teklifleri bulma planı bulunmalıdır.

Dar pilot ile ilerleyin

İlk pilot için iş değeri yüksek fakat kural sayısı yönetilebilir bir ürün ailesi seçin. Geçmiş tekliflerden basit, sınırda, istisnai ve hatalı örnekleri toplayın. Satış, mühendislik, üretim ve finans aynı sonucun doğruluğunu onaylamadan müşteriye açmayın.

İlk sürümde 3D görsel veya her ERP alanını tamamlamak zorunlu değildir. Önce geçerli bileşim, açıklanabilir kural, yeniden üretilebilir BOM, kontrollü fiyat ve sürümlü teklif omurgasını doğrulayın. Görselleştirme ve self servis kapsamı bu omurga güvenilir olduktan sonra genişletilebilir.

Teklif kapsamında hangi teslimatlar olmalı?

  • Ürün ailesi, nitelik, değer, bileşen, kural ve sürüm veri modeli;
  • Soru ağacı, özet, hata açıklaması ve taslak deneyimi;
  • Kısıt motoru, hesaplamalar ve referans konfigürasyon testleri;
  • BOM/rota türetimi ve ERP alan/kimlik eşlemesi;
  • Maliyet kaynağı, fiyat formülü, onay eşiği ve kur dönüşümü;
  • Teklif revizyonu, PDF/portal sunumu ve siparişe dönüşüm;
  • Model yayınlama, geri alma, denetim ve teknik devir süreci.

Entegrasyon sınırını alan bazında belirleyin

Konfigüratörün PIM, ERP, CRM ve CAD ile ilişkisinde tek bir “tam entegrasyon” ifadesi yeterli değildir. Ürün adı, bileşen uygunluğu, stok, maliyet, müşteri indirimi, teklif durumu ve teknik çizim için kaynak sistemi, okuma-yazma yönü, güncelleme sıklığı ve hata davranışı ayrı tanımlanmalıdır.

Bir kaynağa ulaşılamadığında son bilinen değeri kullanmak her alan için güvenli değildir. Pazarlama açıklaması önbellekten gösterilebilirken güncel maliyet veya mevzuata bağlı uygunluk bilinmiyorsa teklif bloke edilebilir. Kullanıcıya verinin zamanı ve kesinlik durumu açıkça gösterilmelidir.

Sipariş aktarımında konfigürasyon, teklif ve hedef ERP işlemi için benzersiz kimlikler kullanın. Ağ hatasından sonra tekrar deneme aynı siparişi ikinci kez oluşturmamalı; kısmi başarı insan inceleme kuyruğunda görünmelidir.

Başarılı bir B2B konfigüratör, gösterişli bir seçenek ekranından önce yönetilebilir ürün modelidir. Nitelik, kısıt, BOM, rota, maliyet, fiyat ve teklif sürümünü aynı kanıt zincirine bağlar. Kendi ürün aileniz için kapsam çıkarmak isterseniz Kumsal Ajans e-ticaret çözümlerini inceleyebilir; ürün ağaçları, kural tabloları, BOM örnekleri ve fiyat onaylarını hazırlayabilirsiniz.

Anasayfa

Projelerimiz

Ürünlerimiz

Hizmetlerimiz