Talep Üzerine Pazaryeri Yazılımı Geliştirme
Hazır çözüm yetmediğinde kuruma özel pazaryeri ve entegrasyon yazılımı: keşiften canlıya kadar aşamalı ilerleyen, ERP/muhasebe köprüsü ve özel iş kurallarını içeren mikroservis/API mimarisi.
Hazır pazaryeri yazılımları katalog, satıcı yönetimi ve sipariş gibi standart akışları hızlıca çözer. Ancak kurumun özgün komisyon modeli, sektöre özel onay hiyerarşisi, mevcut ERP ile derin bütünleşme veya olağandışı ölçek ihtiyaçları devreye girdiğinde hazır ürünün sınırlarına gelinir. Bu sayfa, talep üzerine (kuruma özel) pazaryeri geliştirmeyi değerlendiren operasyon, e-ticaret, lojistik ve tedarik ekipleri için kapsamı, karar çerçevesini ve mimari kriterleri anlatır.
Ne zaman talep üzerine geliştirme? (build vs buy)
Karar bir his değil, ölçülebilir bir eğilimdir. Basit bir eğilim ölçütü: Build eğilimi = Σ(özgün gereksinim ağırlığı) ÷ (hazır ürün kapsama oranı). Oran bire yaklaştıkça veya aştıkça özel geliştirme öne çıkar; belirgin biçimde birin altındaysa hazır ürün + yapılandırma yeterlidir. Bu oranı stratejik önem ve veri sahipliği ihtiyacı ile birlikte okuyun.
| Kriter | Hazır ürün (buy) | Talep üzerine (build) |
|---|---|---|
| Başlangıç hızı | Yüksek | Düşük–orta (aşamalı hızlanır) |
| Özel iş kuralları | Yapılandırma ile sınırlı | Tam esneklik |
| Veri sahipliği | Tedarikçiye bağlı | Kurumda |
| Vendor lock-in | Yüksek olabilir | Mimariyle azaltılır |
| Bakım sorumluluğu | Tedarikçide | Kurumda / geliştirme ekibinde |
Aşamalı yol haritası: keşif → PoC → MVP → canlı
Talep üzerine geliştirme, riski öne çekerek ilerler. Önce belirsizliği en yüksek varsayımlar doğrulanır, sonra çekirdek akış üretime taşınır. Aşağıdaki süreler temsilidir; kapsam, entegrasyon sayısı ve karar hızıyla değişir.
| Aşama | Çıktı | Süre (temsili) |
|---|---|---|
| Keşif | Gereksinim ve kapsam dokümanı, risk haritası, entegrasyon envanteri | 1–2 hafta |
| PoC | En riskli varsayımın (kanal API, komisyon, senkron) doğrulandığı ispat | 2–4 hafta |
| MVP | Canlıya yakın çekirdek akış: satıcı, katalog, sipariş, ödeme ayrıştırma | 6–12 hafta |
| Canlı | Üretim, izleme/uyarı, SLA, kademeli açılım ve iterasyon | Sürekli |
Entegrasyon eforu nasıl tahmin edilir?
Pazaryerinin gerçek yükü çoğunlukla entegrasyonlardadır. Kaba bir tahmin için: Toplam entegrasyon eforu ≈ uç nokta sayısı × uç nokta başına ortalama efor (adam-gün). Bu formül yanıltıcı olabilir; çünkü her uç nokta yalnızca "veri çekmek" değildir. Her bağlantı için ek eforu unutmayın:
- Kimlik doğrulama, yetkilendirme ve anahtar/token yenileme.
- Hız sınırları (rate limit), tekrar deneme (retry) ve idempotensi.
- Hata yönetimi, mutabakat (reconciliation) ve tutarlılık kontrolleri.
- Kargo, ödeme ve e-belge tarafında kenar durumların (iade, kısmi sevkiyat, iptal) ele alınması.
Bu nedenle uç nokta başına eforu, geçmiş verinizle kalibre edilmiş bir karmaşıklık katsayısı ile çarpmak daha gerçekçi bir tahmin verir.
PoC başarı kriteri
PoC, "güzel görünen bir demo" değil, bir karar aracıdır. Net bir başarı tanımı olmadan başlatılmamalıdır: PoC başarılı = (kritik varsayım doğrulandı) ∧ (ölçülen metrik ≥ önceden tanımlı eşik) ∧ (süre/bütçe sınırı aşılmadı). Eşik ve metrik baştan yazılır (ör. "1.000 ürünlük katalog 5 dakikada senkronize olmalı"). Üç koşuldan biri sağlanmıyorsa PoC "başarısız" değil, "karar verdiren" sonuçtur: kapsamı daraltır veya build kararını gözden geçirtir.
Mimari ve kapsam
- Mikroservis/API mimarisi: Katalog, satıcı, sipariş, ödeme ayrıştırma ve bildirim gibi alanların gevşek bağlaşımlı, bağımsız ölçeklenebilir servisler olarak kurgulanması.
- Özel kanal entegrasyonu: Standart olmayan tedarikçi/pazaryeri/kanal API'lerine adapter (soyutlama) katmanıyla bağlanma; kanal ekleme maliyetini sabitleme.
- ERP/muhasebe köprüsü: Stok, cari, sipariş ve fatura verisinin çift yönlü senkronu; GİB e-Fatura/e-Arşiv/e-İrsaliye belge akışının otomasyonu.
- Özel iş kuralları: Komisyon/tahsis modelleri, kademeli fiyatlandırma, onay hiyerarşisi ve kural motoru.
- Ölçek: Olay/iş kuyruğu, önbellek, yatay ölçekleme ve gözlemlenebilirlik (log/metrik/izleme).
Seçim ve şartname kriterleri
- Veri sahipliği: Tüm verinin (şema dahil) kurumda kalması ve tam dışa aktarımın sözleşmede garanti edilmesi.
- Vendor lock-in önlemi: Açık standartlar, adapter katmanları ve standart formatlarla tedarikçi değişiminin tüm sistemi yeniden yazmadan mümkün olması.
- API-first: Her yeteneğin dokümante, sürümlenmiş API ardında sunulması; entegrasyonun sonradan eklenen değil, tasarımın çekirdeği olması.
- KVKK-by-design: 6698 uyumunun tasarım aşamasında kurgulanması — veri minimizasyonu, rol/yetki, denetim izi, saklama süreleri; ticari ileti için İYS onay yönetimi.
- Mevzuat uyumu: 6563 sayılı Kanun kapsamında ATHS/ETHS sorumluluk ayrımı, ETBİS kayıt/bildirim yükümlülükleri ve ödeme tarafında PCI DSS kapsamının (mümkünse ödeme kuruluşuna devrederek) daraltılması.
Süreçlerinizi birlikte inceleyip hazır çözümün mü yeterli olduğunu yoksa talep üzerine geliştirmenin mi doğru olduğunu netleştirelim; gerekiyorsa keşif ve PoC ile riski önce doğrularız. Aşağıdaki formdan ihtiyacınızı iletmeniz yeterli.
Merak edilenler
Hazır pazaryeri yazılımı mı, talep üzerine geliştirme mi?
Standart satıcı, katalog ve sipariş akışları için hazır bir pazaryeri yazılımı hızla değer üretir. Ancak süreçleriniz özgünse, mevcut ERP/muhasebeye derin entegrasyon gerekiyorsa veya sektöre özel iş kuralları (fiyatlandırma, komisyon, tahsis, onay hiyerarşisi) varsa talep üzerine geliştirme ya da hazır çekirdek + özel modül daha doğrudur. Basit bir eğilim ölçütü: özgün gereksinimlerin ağırlığı ile hazır ürün kapsama oranını karşılaştırmaktır; oran bire yaklaştıkça özel geliştirme öne çıkar.
PoC ile MVP arasındaki fark nedir?
PoC (kavram kanıtı) tek bir amaç taşır: en riskli varsayımı (ör. bir kanalın API sınırları, stok senkron gecikmesi, komisyon hesabının doğruluğu) sabit süre ve bütçe içinde doğrulamak; sıklıkla atılabilir koddur. MVP ise üretim hattına giren, canlıya en yakın çekirdek akıştır: gerçek satıcı onboarding, sipariş, ödeme ayrıştırma ve temel raporlama ile sınırlı ama gerçek kullanıcıya açılabilir. PoC "yapılabilir mi?", MVP "en küçük değerli sürüm nedir?" sorusunu yanıtlar.
Pazaryerimizi hangi mevzuata göre kurgulamalıyız?
Pazaryeri işletmecisi 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun kapsamında aracı hizmet sağlayıcı (ATHS) konumundadır; platformda satan taraf ise elektronik ticaret hizmet sağlayıcı (ETHS) sayılır ve sorumluluk paylaşımı bu ayrıma göre kurgulanır. ETBİS (Elektronik Ticaret Bilgi Sistemi) kayıt/bildirim yükümlülükleri, KVKK 6698 kapsamında veri işleme esasları, ticari ileti için İYS (İleti Yönetim Sistemi) onayları, faturalama için GİB e-Fatura/e-Arşiv/e-İrsaliye entegrasyonu ve ödeme tarafında PCI DSS mimari kararlarınızı doğrudan etkiler.
Vendor lock-in riskini nasıl azaltırız?
Sözleşmede veri sahipliğini ve tam dışa aktarımı (şema dahil) garanti altına alın; API-first mimari, açık ve dokümante standartlar, olay/iş kuyruğu tabanlı gevşek bağlaşım ve standart veri formatları (JSON, CSV, e-belge XML) kullanın. Kimlik doğrulama, ödeme ve kargo gibi dış bağımlılıkları soyutlama katmanı (adapter) ardında tutarsanız tedarikçi değişimi tüm sistemi yeniden yazmadan mümkün olur.
Kendi pazaryerinizi size özel geliştirelim.
Pazaryeri fikrinizi ya da mevcut ihtiyacınızı yazın; iş modelinden geliştirmeye tek elden değerlendirip 1 iş günü içinde dönelim. Hazır paket değil — kaynak kodu sizin, size özel.
Talep Oluştur