Hybris B2B ve B2C Accelerator: Doğru Başlangıç Noktası

Accelerator nedir ve neden kritik bir karardır?

Accelerator, SAP Commerce'in hazır mağaza iskeletidir: veri modeli örnekleri, sipariş akışları, ödeme/sevkiyat entegrasyon noktaları ve ön yüz şablonlarıyla 'boş platformdan mağazaya' mesafesini aylar kısaltır. Kritikliği şuradadır: B2B mi B2C accelerator ile mi başladığınız ve onu nasıl özelleştirdiğiniz, projenin yalnızca ilk ayını değil, beş yıl sonraki yükseltme faturasını belirler. Bu yazı iki accelerator'ın gerçek farklarını ve pişman etmeyen başlangıç kurgusunu anlatır.

B2B ve B2C: fark kozmetik değil, modeldir

Karar kuralı basit görünür ama sahada sık ihlal edilir: iş modeliniz hesap hiyerarşisi, özel fiyat ve onay akışı içeriyorsa B2C accelerator üzerine B2B yamamaya çalışmayın — bu üç yetenek B2B accelerator'da model seviyesinde hazırdır ve elle inşası projenin en pahalı sürprizi olur. Tersi de geçerlidir: saf B2C operasyona B2B accelerator almak, kullanmayacağınız karmaşıklığı bakım yüküne çevirir. Her ikisi birdense (bayi + son kullanıcı), çok mağazalı kurulumda her kanal kendi accelerator temelinde yaşar.

Özelleştirme stratejisi: yükseltilebilir kalmak

Sağlık taraması yazımızdaki kırmızı bayrakların doğum yeri, accelerator özelleştirme tarzıdır. Doğru kurgu üç kuralla özetlenir: accelerator kodu referanstır, gövde değil — özelleştirme kendi extension/addon'larınızda yaşar, accelerator sınıfları kopyalanıp içi değiştirilmez; genişletme noktaları tercih edilir — davranış değişiklikleri override edilebilir bean tanımları, event/interceptor mekanizmaları ve yapılandırmayla yapılır; veri modeli disiplinli genişletilir — mevcut tiplere kontrolsüz nitelik yağmuru yerine, iş alanına ait tipler kendi extension'ında tanımlanır. Bu üç kuralın ödülü somuttur: platform yükseltmelerinde çakışma yüzeyi küçülür, 'accelerator'dan ne kadar saptık' sorusunun cevabı ölçülebilir kalır.

Ön yüz gerçeği: accelerator storefront ve composable

Accelerator'ın klasik JSP tabanlı storefront'u yıllarca işi gördü; bugünkü kurulumlarda ise ön yüz kararı ayrı verilmelidir: SAP'nin composable storefront'u (Spartacus kökenli, Angular tabanlı) veya headless yazımızda kurduğumuz gibi OCC API'leri üzerinde kendi React/Next.js katmanınız. Pratik yönlendirmemiz: yeni projelerde sunucu tarafı accelerator (iş mantığı, akışlar, entegrasyon) + headless ön yüz ayrımı; klasik storefront ise mevcut kurulumlarda kademeli geçişin başlangıç noktası olarak meşrudur. Kritik olan, iş mantığının ön yüz katmanına sızmamasıdır — ön yüz değişse bile ticaret çekirdeği yerinde kalmalıdır (BFF yazımızdaki sınır ilkesinin platform karşılığı).

İlk 90 gün: iskeletten iş değerine

Accelerator ile sağlıklı başlangıcın faz düzeni şudur: temel kurulum (accelerator + kendi extension iskeletiniz + CI/CD hattı + ortam stratejisi — ilk hafta biten işler); model uyarlama (katalog yapısı, fiyat modeli, B2B'de hesap/rol hiyerarşisi — iş birimiyle atölyeler eşliğinde); entegrasyon omurgası (ERP fiyat/stok/cari akışları — S/4HANA entegrasyonunu bir sonraki yazıda ayrıca ele alacağız); ve akış özelleştirme (checkout, onay zincirleri, hızlı sipariş uyarlamaları). Bu sıranın mantığı risk yönetimidir: en belirsiz ve en pahalı alan entegrasyondur; onu sona bırakan projeler, canlıya geçiş haftasında ERP gerçekleriyle tanışır.

İş etkisi: hız ile borç arasındaki denge

Accelerator'ın vaadi hızdır ve gerçektir — ama hızın iki türü vardır: ilk demo hızı ve sürdürülebilir teslim hızı. Kopyala-değiştir tarzı ilk demoyu hızlandırır, ikinci yılda her değişikliği yavaşlatır; disiplinli genişletme ilk haftalarda biraz daha yavaş görünür, yıllarca sabit hızda teslim ettirir. Ticari karşılığı yükseltme maliyetinde okunur: temiz kurulmuş projelerde sürüm yükseltme rutin bir bakım kalemidir; kirli kurulumda ise her yükseltme, mini bir yeniden yazım projesidir. Başlangıç kararları, bu iki gelecekten hangisini satın aldığınızdır.

Sık sorulan sorular

Accelerator olmadan, sıfırdan başlamak mantıklı mı?

Nadiren: platformun değeri hazır ticaret modelinde ve akışlarındadır; sıfırdan başlamak bu değeri çöpe atar. İstisna, accelerator varsayımlarıyla temelden çelişen çok özgün iş modelleridir — o durumda da platform seçimi yazımızdaki 'özel geliştirme' satırı yeniden değerlendirilmelidir.

B2C başladık, B2B ihtiyacı doğdu; ne yapmalıyız?

Yamalamadan önce durun: B2B accelerator'ın hesap/fiyat/onay modelini ayrı mağaza veya ayrı site olarak devreye alıp ortak çekirdeği paylaşmak, B2C üzerine el yapımı B2B inşasından neredeyse her zaman ucuzdur. Geçiş tasarımı, mevcut özelleştirme temizliğinizle birlikte planlanmalıdır.

Accelerator sürümüyle platform sürümü ilişkisi ne?

Accelerator platformla birlikte sürümlenir; bu yüzden 'accelerator'a ne kadar dokunduğunuz' yükseltme maliyetinizin ana çarpanıdır. Sapma envanteri (hangi accelerator parçası, neden, nasıl değiştirildi) yükseltme provasının girdisidir.

Mobil uygulama bu kurgunun neresinde?

OCC API'leri üzerinde: mobil, headless ön yüzlerden biridir ve aynı ticaret çekirdeğini kullanır. Mobil için ayrı iş mantığı yazılmaya başlandıysa, sınır ihlali alarmıdır.

Accelerator başlangıç kontrol listesi

1. B2B/B2C kararı iş modeli envanteriyle verildi (hesap, fiyat, onay)

2. Özelleştirme kendi extension/addon'larında; accelerator kopyalanmadı

3. Genişletme noktaları tercih edildi; sapma envanteri tutuluyor

4. Ön yüz kararı ayrıca verildi; iş mantığı çekirdekte kaldı

5. İlk 90 gün fazları: kurulum → model → entegrasyon → akış

6. ERP entegrasyonu erken faza alındı; canlı öncesi sürpriz yok

7. Yükseltme provası ve sapma raporu süreçte tanımlı

SSH Yazılım, SAP Commerce projelerinde accelerator seçimi, kurulum mimarisi ve yükseltilebilir özelleştirme stratejisini uçtan uca kurar. Doğru başlangıcı birlikte yapalım.