E-Ticaret Sipariş Yönetim Sistemi (OMS) Nedir?

E-ticaret sipariş yönetim sistemi, farklı satış kanallarından gelen siparişleri yalnızca listeleyen bir ekran değildir. Sağlıklı bir OMS; sipariş kimliğini ve birbirinden bağımsız durumları tutarlı yönetir, satılabilir stoğa göre söz verir, sipariş satırlarını uygun karşılama kaynağına yönlendirir, istisnaları görünür kılar ve müşteri teslimat vaadini uçtan uca izler. Bu rehber, küçük işletmenin anlayacağı yalınlıkla operasyon, entegrasyon ve satın alma kararlarını aynı çerçevede toplar.

OMS açılımı Order Management System, Türkçesi sipariş yönetim sistemidir. Bir bağlayıcı siparişi kanaldan taşır; OMS ise o sipariş için hangi durumun geçerli olduğuna, hangi stoktan karşılanacağına, bölünüp bölünmeyeceğine ve hangi istisnanın kime atanacağına ilişkin kararları koordine eder. Pazaryeri mesajlarının alınması için pazaryeri sipariş entegrasyonu, stok yayınlama ayrıntıları için stok ve fiyat senkronizasyonu rehberleri tamamlayıcıdır.

OMS, ERP, WMS, PIM, POS, CRM ve kargo sistemiyle iş birliği yapar; hepsinin yerine geçmez. ERP finansal ve ticari kayıtları, WMS depo içi yürütmeyi, PIM ürün bilgisini, POS mağaza satışını, CRM müşteri ilişkisini, taşıyıcı bağlantısı ise etiket ve teslimat olaylarını yönetir. Kaynak sahipliği ve veri sözleşmesi için e-ticaret ERP entegrasyonu, taşıyıcı akışı için e-ticaret kargo entegrasyonu ayrıca okunabilir.

OMS hangi problemi çözer ve ne zaman gerekir?

Tek kanallı ve düşük hacimli bir işletme, iyi tasarlanmış e-ticaret altyapısının yerleşik sipariş işlevleriyle başlayabilir. İhtiyaç; aynı SKU birden çok kanalda satıldığında, birden fazla stok noktası kullanıldığında, teslimat sözü verildiğinde, kısmi iptal ve iade arttığında veya manuel kararlar müşteri deneyimini bozduğunda belirginleşir. Günlük sipariş adedi tek başına eşik değildir; istisna oranı, kanal sayısı, stok kaynağı, hizmet seviyesi ve ekibin işlem maliyeti birlikte değerlendirilmelidir.

Sistem	Temel görev	OMS ile sınır	Başarı ölçüsü
Kanal bağlayıcısı	Sipariş ve durum mesajını taşır	Karar motoru olmak zorunda değildir	Eksiksiz ve zamanında veri
OMS	Sipariş yaşam döngüsü, stok sözü ve yönlendirme	Depo içi toplama rotasını yürütmez	Doğru söz, düşük istisna
ERP	Finans, cari, maliyet ve muhasebe kaydı	Her zaman gerçek zamanlı orkestrasyon yapmaz	Kayıt ve mutabakat doğruluğu
WMS	Depo içi kabul, yerleştirme, toplama, paketleme	Kanal vaadinin tek sahibi değildir	Toplama doğruluğu ve çevrim süresi
TMS/kargo	Taşıyıcı seçimi, etiket ve hareket olayı	Satılabilir stok hesaplamaz	Sevk ve teslimat performansı

Belirti	Manuel düzey	OMS adayı düzeyi	Ölçülecek kanıt
Sipariş tekrarı	Nadiren elle düzeltiliyor	Müşteriyi veya stoğu etkiliyor	Mükerrer sipariş oranı
Stok sözü	Tek kaynaktan okunuyor	Kanal ve konum arasında ayrışıyor	Fazla satış oranı
Yönlendirme	Tek depo sabit	Kapasite, maliyet ve SLA birlikte	Yeniden yönlendirme oranı
İstisna	E-posta ve sohbetle izleniyor	Sahip ve süre görünmüyor	İstisna yaşlanması
Teslimat vaadi	Genel metin	Sipariş ve konuma göre hesap	Promise accuracy

Sipariş yaşam döngüsü ve canonical veri modeli

Kanal sipariş numarası müşteriye ve kanala özgüdür; OMS içinde değişmez bir dahili kimlikle eşleştirilmelidir. Sipariş başlığı müşteri, kanal, para birimi ve genel adres gibi ortak alanları; satır ise SKU, miktar, fiyat, vergi, promosyon ve karşılama durumunu taşır. Bir fulfillment grubu, aynı kaynaktan ve yöntemle karşılanacak satırları bir araya getirir. Sipariş, ödeme, fulfillment, sevkiyat, belge ve iade durumları ayrı tutulursa kısmi olaylar kaybolmaz.

Aşama	Giriş	OMS kararı	Çıkış
Alma	Kanal siparişi	Kimlik, şema ve tekrar kontrolü	Canonical sipariş
Doğrulama	Adres, ödeme, ürün	Hold veya devam	Doğrulanmış satırlar
Söz verme	Stok ve kapasite	ATP, tarih ve hizmet	Müşteri vaadi
Kaynak seçimi	Konum adayları	Tahsis ve yönlendirme	Fulfillment grubu
Yürütme	WMS/tedarikçi sonucu	İstisna veya sevk	Sevkiyat olayı
Kapanış	Teslim, iptal, iade	Mutabakat ve kayıt	İzlenebilir sonuç

Durum ekseni	Örnek değerler	Neden ayrı tutulur	Hatalı birleştirme riski
Sipariş	yeni, hold, onaylı, kapalı	Genel iş kararını gösterir	Kısmi satır kaybı
Ödeme	bekliyor, yetkili, tahsil, iade	Parasal olay bağımsızdır	Sevk ile tahsil karışır
Fulfillment	ayrılmadı, tahsisli, hazırlanıyor	Kaynak ve hazırlık görünür	Stok sözü yanlış okunur
Sevkiyat	etiketli, yolda, teslim	Bir siparişte çoklu paket olabilir	Son paket tüm siparişi kapatır
İade	talep, kabul, incelendi, sonuçlandı	Fiziksel dönüş ve para ayrılır	Erken geri ödeme veya gecikme

Canonical alan	Sahip	Değişmezlik	Kontrol
internal_order_id	OMS	Değişmez	Benzersiz anahtar
channel_order_id	Satış kanalı	Kaynakta değişmez	Kanal ve mağaza ile bileşik
sku ve line_id	PIM/kanal eşleme	Satır geçmişi korunur	Sürüm ve eşleme
payment_reference	Ödeme sağlayıcı	Olay bazlı	Token, maskeleme, mutabakat
promise_date	OMS kuralı	Yeni kararda sürümlenir	Hesap girdileriyle denetim

Veri alanı	Birincil kaynak	OMS kopyası	Çatışma kuralı
Ürün kimliği	PIM veya ERP	Sipariş anı snapshot	Sipariş tarihi korunur
Fiyat ve indirim	Kanal/checkout	Sipariş anı snapshot	Sonradan katalogla ezilmez
Fiziksel stok	WMS/ERP	Görünürlük projeksiyonu	Mutabakat farkı kuyruğa
Sipariş kararı	OMS	Ana kayıt	Sürüm ve audit log
Mali belge	ERP/e-Belge	Numara ve durum referansı	Mali kaynak esas

Tekilleştirme, idempotency ve güvenilir olay işleme

Aynı kanal mesajı ağ zaman aşımı nedeniyle yeniden gelebilir. OMS, kanal, mağaza, dış sipariş kimliği ve olay türünden oluşturulan doğal anahtarı; istek gövdesi özeti ve idempotency anahtarıyla birlikte değerlendirmelidir. Bir anahtar farklı içerikle yeniden kullanılırsa sessizce kabul edilmemelidir. Idempotency tekrarın etkisini sınırlar; ağın veya tüm sistemlerin exactly-once çalıştığını kanıtlamaz.

HTTP anlamı için RFC 9110, yapılandırılmış hata yanıtları için RFC 9457 kullanılabilir. IETF Idempotency-Key taslağı ${accessDate} itibarıyla Internet-Draft’tır; RFC değildir. API sözleşmesini sürümlemek için OpenAPI Specification pratik bir seçenektir.

Stok görünürlüğü, ATP, ATS, rezervasyon ve tahsis

On-hand fiziksel kaydı, reserved geçici olarak söz verilmiş miktarı, allocated belirli bir sipariş ve kaynağa bağlanmış miktarı, safety stock ise belirsizliğe karşı korunacak tamponu ifade eder. ATS çoğunlukla satılabilir mevcut miktarı, ATP ise gelecekteki girişler ve zaman ufkuyla birlikte söz verilebilir miktarı anlatır; sağlayıcılar terimleri farklı kullanabildiği için formül sözleşmede açık olmalıdır. Basit temsili yaklaşım: ATS = on-hand − ayrılmış − güvenlik stoğu − bloke miktar. Negatif ve gecikmeli veri kuralları ayrıca tanımlanır.

Stok havuzu kanala ayrılan üst sınırı belirleyebilir; güvenlik tamponu, gecikme ve iptal belirsizliğini yönetir. Bu mekanizma fiziksel stoğu çoğaltmaz. Stok yönetiminin daha geniş çerçevesi için e-ticarette stok yönetimi, kanal eşlemeleri için pazaryeri entegrasyonu nedir rehberi kullanılabilir.

Sourcing, order routing ve teslimat sözü

Sourcing, uygun stok kaynaklarını üretir; routing bu adaylar arasında kural ve skorla seçim yapar. En yakın depo her zaman en iyi değildir: ürün bütünlüğü, hazırlama kapasitesi, kesim saati, taşıyıcı hizmeti, maliyet, karbon hedefi, mağaza operasyonu ve split riski birlikte değerlendirilir. Karar girdileri ve kural sürümü kaydedilmezse sonuç açıklanamaz ve müşteri hizmetleri aynı siparişi yeniden değerlendiremez.

Ödeme, B2B, iptal, iade ve değişim kararları

Kart ödemesinde yetkilendirme ve tahsil, havalede bekleme ve son tarih, kapıda ödemede risk ve taşıyıcı kabiliyeti ayrı akışlardır. B2B siparişte müşteri onayı, cari limit, fiyat yetkisi, teslimat bölme izni ve kısmi karşılama politikası sipariş satırına kadar inebilir. Fraud hold, siparişi silmez; neden, sahibi, son karar zamanı ve serbest bırakma yetkisiyle denetlenebilir bir bekleme durumu oluşturur.

İade ile geri ödeme aynı olay değildir. Güncel tüketici yükümlülükleri için Ticaret Bakanlığı mesafeli sözleşmeler bilgilendirmesi incelenmeli; işleme özgü hukuki değerlendirme alınmalıdır. Otomatik belge akışının işletme boyutu için otomatik faturalandırma rehberi tamamlayıcıdır.

OMS entegrasyon mimarisi ve sistemler arası sözleşme

Olay zarfı için CloudEvents, tedarik zinciri olay görünürlüğü için GS1 EPCIS 2.0 ve kavram sözlüğü için GS1 CBV 2.0 değerlendirilebilir. Ticari ortak mesajlaşmasında GS1 EDI seçenekleri vardır. Bunlar zorunlu OMS teknolojileri değil; gereksinime göre kanıtlanması gereken uyumluluk seçenekleridir.

İstisna yönetimi, mutabakat ve gözlemlenebilirlik

İstisna kuyruğu yalnız hata listesi değildir. Her kayıt iş etkisi, öncelik, yaş, sahip, önerilen işlem, müşteri vaadi ve yeniden deneme durumunu taşımalıdır. Manuel müdahale eski değeri, yeni değeri, nedeni, kullanıcıyı ve zamanı denetim izine ekler. Read-back, hedef sistemin komutu gerçekten uyguladığını okur; reconciliation ise iki tarafın toplamını ve tekil kayıtlarını dönemsel olarak karşılaştırır.

Üreticiden bağımsız telemetri yaklaşımı için OpenTelemetry incelenebilir. Teknik başarı iş sonucuyla bağlanmalıdır: hızlı API cevabı, yanlış stoğa söz veriliyorsa yeterli değildir. Kanal ve finans farklarının daha geniş denetimi için pazaryeri mutabakatı rehberi yararlıdır.

Güvenlik, KVKK ve yetki tasarımı

API risklerini sınıflandırmak için OWASP API Security Top 10 2023, uygulama riskleri için OWASP Top 10 2025, OAuth güvenlik uygulamaları için RFC 9700 dikkate alınabilir. Kart verisi kapsamı için PCI SSC belge kütüphanesindeki PCI DSS 4.0.1 ve ödeme mimarisi birlikte değerlendirilmelidir. Türkiye’de KVKK veri güvenliği yükümlülükleri ile yurt dışına aktarım rehberi güncel hukuki incelemenin başlangıç noktalarıdır.

KPI, kapasite ve hizmet hedefleri

Hedefler tek ortalamayla izlenmemelidir. p95 ve p99 gecikme, hata bütçesi, kuyruk yaşı ve iş sonucu birlikte raporlanır. Bir kampanya provası temsili sipariş karışımı, aynı SKU yarışı, kaynak kesintisi ve gecikmiş olaylarla yapılır. Operasyonun günlük yönetimi için e-ticaret operasyonu, yönetim görünürlüğü için e-ticaret raporlama rehberleri tamamlayıcıdır.

OMS seçenekleri, TCO ve satın alma yaklaşımı

İşletme, ürün kataloğu ve ticaret operasyonunu aynı çerçevede planlamak istiyorsa SoloCommerce e-ticaret paketlerini gereksinim listesiyle karşılaştırabilir. Canlı sayfada paketler sipariş, ödeme, kargo, fatura, pazaryeri, stok ve operasyon görünürlüğünü farklı kapsamlarla sunuyor. Bu ifade gelişmiş DOM veya belirli SLA garantisi değildir; standart paket, özel entegrasyon ve Enterprise teklif ayrımı demo, teknik keşif, teklif ve sözleşmede doğrulanmalıdır.

Yapay zekâ OMS’de nerede kullanılabilir?

Model önerisi iş kuralını, yetkiyi veya hukuki kararı gizlice değiştirmemelidir. Eğitim verisi, veri aktarımı, model sürümü, açıklanabilirlik, sapma, geri alma ve insan onayı izlenir. Dinamik yönlendirme önce gölge modda çalıştırılır; öneri ile gerçek karar arasındaki fark ve KPI etkisi ölçülmeden otomatikleştirilmez.

Temsili işletme senaryoları

Senaryo 1: Kampanyada aynı SKU yarışı

Senaryo 2: İki depoda kaynak seçimi

Senaryo 3: Ödeme başarısızlığında bırakma

Senaryo 4: Kapasite nedeniyle yeniden yönlendirme

Senaryo 5: Split shipment kararı

Senaryo 6: Dropship tedarikçi gecikmesi

Senaryo 7: B2B limit ve kısmi karşılama

Senaryo 8: Kısmi iptal ve geri ödeme

Senaryo 9: Mağazadan teslim

Senaryo 10: Kanal kesintisi ve mutabakat

Uygulama ve operasyon kontrol listesi

Strateji ve kapsam

• Kontrol 001: kanal ve stok kaynağı envanterini onayla.
• Kontrol 002: OMS ile bağlayıcı sınırını yazılılaştır.
• Kontrol 003: müşteri vaadi hedefini ölçülebilir tanımla.
• Kontrol 004: kapsam dışı WMS yürütme işlerini ayır.
• Kontrol 005: iş sahibi ve teknik sahibi ata.
• Kontrol 006: başlangıç KPI tabanını çıkar.
• Kontrol 007: kritik sipariş türlerini sırala.
• Kontrol 008: B2B ve B2C farklarını belgeye geçir.
• Kontrol 009: ülke ve para birimi kapsamını belirle.
• Kontrol 010: pik kampanya varsayımını kaydet.
• Kontrol 011: mevcut manuel dokunuş maliyetini ölç.
• Kontrol 012: başarı ve durdurma ölçütünü belirle.
• Kontrol 013: veri sahipliği RACI matrisini onayla.
• Kontrol 014: paket ve özel geliştirme sınırını çiz.
• Kontrol 015: çıkış planını daha başta tasarla.

Sipariş veri modeli

• Kontrol 016: dahili sipariş kimliğini değişmez yap.
• Kontrol 017: kanal kimliğini mağaza ile bileşik tut.
• Kontrol 018: başlık ve satır durumlarını ayır.
• Kontrol 019: ödeme durumunu sevkiyattan ayır.
• Kontrol 020: fulfillment grubu kimliği üret.
• Kontrol 021: fiyat ve indirim snapshotını koru.
• Kontrol 022: adres sürümünü sipariş anında sakla.
• Kontrol 023: birim ve para hassasiyetini tanımla.
• Kontrol 024: promosyon dağıtım kuralını belgeye geçir.
• Kontrol 025: kısmi miktarı satır düzeyinde izle.
• Kontrol 026: durum geçiş matrisini onayla.
• Kontrol 027: iptal ve iade neden sözlüğü oluştur.
• Kontrol 028: kaynak sistem referanslarını sakla.
• Kontrol 029: şema sürümünü olayla taşı.
• Kontrol 030: kişisel veri alanlarını etiketle.

Stok ve söz verme

• Kontrol 031: ATS formülünü sistem bazında doğrula.
• Kontrol 032: ATP zaman ufkunu tanımla.
• Kontrol 033: rezervasyon TTL politikasını yaz.
• Kontrol 034: tahsis ile rezervasyonu ayır.
• Kontrol 035: güvenlik stoğunu SKU bazında yönet.
• Kontrol 036: kanal havuzu tavanını test et.
• Kontrol 037: bloke stoğu satılabilirden düş.
• Kontrol 038: negatif stok davranışını belirle.
• Kontrol 039: stok olay yaşı alarmı kur.
• Kontrol 040: sahipsiz rezervasyonu raporla.
• Kontrol 041: ödeme hatasında bırakmayı test et.
• Kontrol 042: sayım farkı mutabakatı kur.
• Kontrol 043: preorder tarih kaynağını belirle.
• Kontrol 044: backorder müşteri onayını kaydet.
• Kontrol 045: stok read-back kontrolünü çalıştır.

Yönlendirme ve vaat

• Kontrol 046: aday kaynak filtresini tanımla.
• Kontrol 047: kapasite üst limitini uygula.
• Kontrol 048: kesim saati takvimini sürümle.
• Kontrol 049: tatil ve bölge istisnasını işle.
• Kontrol 050: hazırlama süresini gerçek veriden besle.
• Kontrol 051: taşıma servis uygunluğunu kontrol et.
• Kontrol 052: maliyet bileşenlerini ayrı izle.
• Kontrol 053: split tavanını siparişe uygula.
• Kontrol 054: müşteri teslimat tercihini koru.
• Kontrol 055: kural sürümünü kararla kaydet.
• Kontrol 056: skor açıklamasını operasyona göster.
• Kontrol 057: fallback kaynak sırasını belirle.
• Kontrol 058: yeniden tahsis yetkisini sınırla.
• Kontrol 059: promise date değişimini bildir.
• Kontrol 060: mağaza kabul süresini izle.

Entegrasyon güvenilirliği

• Kontrol 061: API sözleşmesini sürümle.
• Kontrol 062: webhook imzasını doğrula.
• Kontrol 063: replay penceresini sınırla.
• Kontrol 064: idempotency kapsamını tanımla.
• Kontrol 065: aynı anahtarda farklı gövdeyi reddet.
• Kontrol 066: retry bütçesi ve jitter uygula.
• Kontrol 067: kalıcı hatayı DLQya taşı.
• Kontrol 068: outbox kayıp mesaj kontrolü kur.
• Kontrol 069: polling watermarkını kalıcı tut.
• Kontrol 070: sayfalama boşluğunu test et.
• Kontrol 071: olay sıra numarasını doğrula.
• Kontrol 072: bilinmeyen durumu istisnaya al.
• Kontrol 073: read-back zamanlamasını belirle.
• Kontrol 074: dönemsel mutabakat raporu üret.
• Kontrol 075: kontrollü replay runbooku yaz.

Operasyon ve istisna

• Kontrol 076: istisna sınıfı sözlüğü oluştur.
• Kontrol 077: iş etkisine göre önceliklendir.
• Kontrol 078: her kayda sahip ve son tarih ata.
• Kontrol 079: kuyruk yaşını görünür yap.
• Kontrol 080: müşteri vaadini kartta göster.
• Kontrol 081: önerilen çözüm adımını ekle.
• Kontrol 082: manuel değişiklik nedenini zorunlu kıl.
• Kontrol 083: eski ve yeni değeri kaydet.
• Kontrol 084: toplu işlemi yetkiyle sınırla.
• Kontrol 085: vardiya devir notu üret.
• Kontrol 086: kritik alarm nöbetini tanımla.
• Kontrol 087: tekrarlayan nedeni problem kaydına bağla.
• Kontrol 088: SLO ihlalinde eskalasyon çalıştır.
• Kontrol 089: kapanan istisnayı örnekle denetle.
• Kontrol 090: operasyon eğitimini senaryoyla ölç.

Güvenlik ve KVKK

• Kontrol 091: SSO ve MFA kapsamını doğrula.
• Kontrol 092: servis hesaplarını kişiden ayır.
• Kontrol 093: en az ayrıcalık rollerini test et.
• Kontrol 094: görev ayrılığı ihlalini engelle.
• Kontrol 095: API sırlarını kasada sakla.
• Kontrol 096: anahtar rotasyonunu prova et.
• Kontrol 097: hassas log alanlarını maskele.
• Kontrol 098: kart verisini OMS dışında tut.
• Kontrol 099: TLS ayarlarını tarat.
• Kontrol 100: veri saklama süresini uygula.
• Kontrol 101: silme ve anonimleştirmeyi kanıtla.
• Kontrol 102: alt işleyen listesini güncelle.
• Kontrol 103: veri lokasyonunu sözleşmede belirt.
• Kontrol 104: olay müdahale tatbikatı yap.
• Kontrol 105: erişimleri dönemsel gözden geçir.

Test ve geçiş

• Kontrol 106: contract test paketini çalıştır.
• Kontrol 107: kritik yolu uçtan uca test et.
• Kontrol 108: aynı SKU yarış testi yap.
• Kontrol 109: gecikmiş olay testi yap.
• Kontrol 110: mükerrer mesaj testi yap.
• Kontrol 111: kısmi iptal testi yap.
• Kontrol 112: çoklu paket testi yap.
• Kontrol 113: ödeme belirsizliği testi yap.
• Kontrol 114: pik yük ve soak testi yap.
• Kontrol 115: güvenlik negatif testi çalıştır.
• Kontrol 116: veri taşıma örneğini mutabık kıl.
• Kontrol 117: açık sipariş cutoverını prova et.
• Kontrol 118: geri dönüş karar noktasını belirle.
• Kontrol 119: pilot kanal sınırını koru.
• Kontrol 120: hiper bakım komuta planı kur.

KPI ve iyileştirme

• Kontrol 121: perfect order tanımını ortaklaştır.
• Kontrol 122: fill rate paydasını sabitle.
• Kontrol 123: promise accuracy penceresini yaz.
• Kontrol 124: p95 ve p99 gecikmeyi izle.
• Kontrol 125: oversell nedenini sınıflandır.
• Kontrol 126: split maliyetini raporla.
• Kontrol 127: yeniden tahsis oranını izle.
• Kontrol 128: istisna yaşını sınıfa böl.
• Kontrol 129: manuel dokunuş süresini ölç.
• Kontrol 130: müşteri temas nedenini siparişe bağla.
• Kontrol 131: kural değişimini deney gruplarıyla ölç.
• Kontrol 132: hata bütçesini yayınla.
• Kontrol 133: kapasite tahminini haftalık yenile.
• Kontrol 134: KPI bozulmasında geri alma uygula.
• Kontrol 135: aylık kök neden toplantısı yap.

Tedarikçi ve sözleşme

• Kontrol 136: paket işlevini canlı demoda doğrula.
• Kontrol 137: API ve webhook kotalarını yazılı al.
• Kontrol 138: test ortamı eşdeğerliğini ölç.
• Kontrol 139: veri dışa aktarma biçimini dene.
• Kontrol 140: SLA kapsam ve hariçlerini incele.
• Kontrol 141: RTO ve RPO kanıtını iste.
• Kontrol 142: alt sağlayıcı değişiklik bildirimini yaz.
• Kontrol 143: fiyat artış ve fazla kullanımını hesapla.
• Kontrol 144: güvenlik raporu tarihini kontrol et.
• Kontrol 145: destek eskalasyon yolunu prova et.
• Kontrol 146: sürüm sonlandırma süresini netleştir.
• Kontrol 147: veri silme belgesini sözleşmeye koy.
• Kontrol 148: fikri mülkiyet sınırını belirle.
• Kontrol 149: çıkış yardımını fiyatlandır.
• Kontrol 150: referans müşteride benzer akışı doğrula.

PoC ve UAT test matrisi

OMS sağlayıcısına sorulacak sorular

Kapsam

1. Sağlayıcı sorusu 01: Standart pakette hangi sipariş durumları vardır?
2. Sağlayıcı sorusu 02: DOM, ATP ve yönlendirme hangi pakette ve hangi sınırla sunulur?
3. Sağlayıcı sorusu 03: Kısmi iptal, split ve backorder yerleşik midir?
4. Sağlayıcı sorusu 04: B2B onay ve cari limit akışı nasıl modellenir?
5. Sağlayıcı sorusu 05: Mağazadan sevk ve teslim için kanıtlanmış akış var mı?
6. Sağlayıcı sorusu 06: Yol haritası özelliği sözleşme kapsamına girer mi?

Stok

1. Sağlayıcı sorusu 07: ATS ve ATP formülleri nasıl tanımlanır?
2. Sağlayıcı sorusu 08: Rezervasyon TTL ve bırakma kuralı yapılandırılabilir mi?
3. Sağlayıcı sorusu 09: Atomik rezervasyon hangi depolama mekanizmasıyla korunur?
4. Sağlayıcı sorusu 10: Kanal havuzu ve tampon SKU bazında çalışır mı?
5. Sağlayıcı sorusu 11: Stok gecikmesi ve negatif değer nasıl ele alınır?
6. Sağlayıcı sorusu 12: Sayım farkı mutabakat raporu var mı?

Yönlendirme

1. Sağlayıcı sorusu 13: Kural motoru hangi kriterleri destekler?
2. Sağlayıcı sorusu 14: Karar skoru ve kural sürümü görülebilir mi?
3. Sağlayıcı sorusu 15: Kapasite ve cut-off takvimi nasıl beslenir?
4. Sağlayıcı sorusu 16: Split maliyet tavanı tanımlanabilir mi?
5. Sağlayıcı sorusu 17: Fallback ve yeniden tahsis kim tarafından yönetilir?
6. Sağlayıcı sorusu 18: Promise date girdileri denetlenebilir mi?

Entegrasyon

1. Sağlayıcı sorusu 19: API ve webhook kapsamı ile kota nedir?
2. Sağlayıcı sorusu 20: Idempotency ve tekrar teslim davranışı nasıldır?
3. Sağlayıcı sorusu 21: Şema değişiklikleri ne kadar önce bildirilir?
4. Sağlayıcı sorusu 22: Polling ve toplu aktarım seçenekleri var mı?
5. Sağlayıcı sorusu 23: Read-back ve reconciliation araçları nelerdir?
6. Sağlayıcı sorusu 24: DLQ replay işlemi nasıl yetkilendirilir?

Performans

1. Sağlayıcı sorusu 25: Sipariş ve satır bazında kapasite kanıtı var mı?
2. Sağlayıcı sorusu 26: p95 ve p99 gecikme nasıl ölçülür?
3. Sağlayıcı sorusu 27: Pik kampanya için ölçek planı nedir?
4. Sağlayıcı sorusu 28: Backpressure ve oran sınırlama nasıl çalışır?
5. Sağlayıcı sorusu 29: Test ortamı üretim kapasitesini ne kadar temsil eder?
6. Sağlayıcı sorusu 30: Bağımlılık kesintisinde bozulma modu nedir?

Güvenlik

1. Sağlayıcı sorusu 31: SSO, MFA ve servis kimliği seçenekleri nelerdir?
2. Sağlayıcı sorusu 32: Rol ve görev ayrılığı satır işlemine iner mi?
3. Sağlayıcı sorusu 33: Sırlar nerede tutulur ve nasıl döndürülür?
4. Sağlayıcı sorusu 34: Loglarda müşteri verisi nasıl maskelenir?
5. Sağlayıcı sorusu 35: Sızma testi ve güvenlik raporu ne sıklıkta yenilenir?
6. Sağlayıcı sorusu 36: Olay bildirimi ve müdahale taahhüdü nedir?

KVKK

1. Sağlayıcı sorusu 37: Veri hangi ülkelerde ve alt işleyenlerde tutulur?
2. Sağlayıcı sorusu 38: Saklama ve silme kuralları yapılandırılabilir mi?
3. Sağlayıcı sorusu 39: Yurt dışı aktarım mekanizması nasıl belgelenir?
4. Sağlayıcı sorusu 40: İlgili kişi talebi hangi kayıtlara bağlanır?
5. Sağlayıcı sorusu 41: Veri dışa aktarımı ve silme kanıtı sağlanır mı?
6. Sağlayıcı sorusu 42: Alt işleyen değişikliği nasıl bildirilir?

Operasyon

1. Sağlayıcı sorusu 43: İstisna kuyruğu hangi alanları ve SLOyu destekler?
2. Sağlayıcı sorusu 44: Manuel değişikliklerde eski ve yeni değer tutulur mu?
3. Sağlayıcı sorusu 45: Toplu işlemler nasıl onaylanır?
4. Sağlayıcı sorusu 46: Runbook ve nöbet entegrasyonu var mı?
5. Sağlayıcı sorusu 47: Müşteri hizmetleri için karar açıklaması sunulur mu?
6. Sağlayıcı sorusu 48: Kök neden ve tekrar analizi nasıl raporlanır?

Ticari

1. Sağlayıcı sorusu 49: Lisans sipariş, satır, kullanıcı veya GMV bazlı mı?
2. Sağlayıcı sorusu 50: Pik ve fazla kullanım ücretleri nelerdir?
3. Sağlayıcı sorusu 51: Özel entegrasyon bakım bedeli nasıl hesaplanır?
4. Sağlayıcı sorusu 52: SLA kredisi hangi olaylarda uygulanır?
5. Sağlayıcı sorusu 53: Fiyat artış tavanı ve para birimi nedir?
6. Sağlayıcı sorusu 54: Pilot, eğitim ve geçiş hizmetleri fiyata dahil mi?

Çıkış

1. Sağlayıcı sorusu 55: Tüm sipariş ve audit verisi hangi formatta çıkar?
2. Sağlayıcı sorusu 56: Veri çıkışında ücret ve hız sınırı var mı?
3. Sağlayıcı sorusu 57: Sözleşme sonunda erişim ne kadar sürer?
4. Sağlayıcı sorusu 58: Özel kural ve eşlemelerin mülkiyeti kimdedir?
5. Sağlayıcı sorusu 59: Geçiş yardımı ve paralel çalışma desteği nedir?
6. Sağlayıcı sorusu 60: Silme belgesi ile yedeklerin yok edilmesi nasıl kanıtlanır?

Sık hatalar ve kırmızı bayraklar

Kapsam

• Kırmızı bayrak 01: OMS’yi yalnız sipariş listesi sanmak.
• Kırmızı bayrak 02: entegrasyon ile karar motorunu aynı kabul etmek.
• Kırmızı bayrak 03: WMS görevlerini belirsizce OMS’ye yüklemek.
• Kırmızı bayrak 04: tek kanal başarısını çok kanala genellemek.
• Kırmızı bayrak 05: geliştirme yol haritasını mevcut özellik saymak.
• Kırmızı bayrak 06: iş sahibini atamamak.
• Kırmızı bayrak 07: kapsam dışını yazmamak.
• Kırmızı bayrak 08: başarı ölçütü belirlememek.
• Kırmızı bayrak 09: çıkış planını sona bırakmak.
• Kırmızı bayrak 10: paket sınırını sözleşmede göstermemek.

Veri

• Kırmızı bayrak 11: kanal numarasını tek anahtar yapmak.
• Kırmızı bayrak 12: başlık ve satır durumunu birleştirmek.
• Kırmızı bayrak 13: fiyat snapshotını katalogla ezmek.
• Kırmızı bayrak 14: kaynak sahipliğini tanımlamamak.
• Kırmızı bayrak 15: bilinmeyen durumu sessizce eşlemek.
• Kırmızı bayrak 16: zaman dilimini belirsiz bırakmak.
• Kırmızı bayrak 17: para yuvarlamasını standartlaştırmamak.
• Kırmızı bayrak 18: kişisel veri alanlarını etiketlememek.
• Kırmızı bayrak 19: şema sürümünü taşımamak.
• Kırmızı bayrak 20: manuel değişikliği kayıtsız yapmak.

Stok

• Kırmızı bayrak 21: on-hand değerini ATS sanmak.
• Kırmızı bayrak 22: rezervasyon ile tahsisi eşitlemek.
• Kırmızı bayrak 23: TTL olmadan rezervasyon tutmak.
• Kırmızı bayrak 24: başarısız ödemede stoğu bırakmamak.
• Kırmızı bayrak 25: güvenlik stoğunu tüm SKUya aynı vermek.
• Kırmızı bayrak 26: gecikmiş stok yaşını izlememek.
• Kırmızı bayrak 27: negatif stoğu kanala yayınlamak.
• Kırmızı bayrak 28: kanal kotalarını fiziksel stok sanmak.
• Kırmızı bayrak 29: sayım farkını mutabık kılmamak.
• Kırmızı bayrak 30: sahipsiz rezervasyonu görmezden gelmek.

Yönlendirme

• Kırmızı bayrak 31: her zaman en yakın depoyu seçmek.
• Kırmızı bayrak 32: kapasiteyi anlık hesaba katmamak.
• Kırmızı bayrak 33: cut-off takvimini kod içine gömmek.
• Kırmızı bayrak 34: split maliyetini dışlamak.
• Kırmızı bayrak 35: müşteri tercihini yok saymak.
• Kırmızı bayrak 36: kural sürümünü kaydetmemek.
• Kırmızı bayrak 37: fallbacksiz tek kaynak kurmak.
• Kırmızı bayrak 38: yeniden tahsisi sınırsız yapmak.
• Kırmızı bayrak 39: taşıyıcı servis alanını doğrulamamak.
• Kırmızı bayrak 40: promise date değişimini bildirmemek.

Entegrasyon

• Kırmızı bayrak 41: timeout sonrası kör tekrar yapmak.
• Kırmızı bayrak 42: idempotency anahtarını sınırsız yeniden kullanmak.
• Kırmızı bayrak 43: farklı gövdeyi aynı anahtarla kabul etmek.
• Kırmızı bayrak 44: exactly-once garantisi vermek.
• Kırmızı bayrak 45: sonsuz retry uygulamak.
• Kırmızı bayrak 46: DLQyu sahipsiz bırakmak.
• Kırmızı bayrak 47: webhook imzasını kontrol etmemek.
• Kırmızı bayrak 48: polling watermarkını bellekte tutmak.
• Kırmızı bayrak 49: read-back yapmamak.
• Kırmızı bayrak 50: mutabakatı yalnız toplam adetle sınırlamak.

Operasyon

• Kırmızı bayrak 51: istisnaları e-postayla yönetmek.
• Kırmızı bayrak 52: sahip ve son tarih atamamak.
• Kırmızı bayrak 53: kuyruk yaşını ölçmemek.
• Kırmızı bayrak 54: toplu iptali tek onaya bırakmak.
• Kırmızı bayrak 55: müşteri vaadini ekipten gizlemek.
• Kırmızı bayrak 56: manuel düzeltmeyi neden kodsuz yapmak.
• Kırmızı bayrak 57: vardiya devrini kayıtsız bırakmak.
• Kırmızı bayrak 58: kök nedeni kapatmadan bileti kapatmak.
• Kırmızı bayrak 59: SLO ihlalini eskale etmemek.
• Kırmızı bayrak 60: eğitimi yalnız ekran demosuyla yapmak.

Güvenlik/KVKK

• Kırmızı bayrak 61: ortak yönetici hesabı kullanmak.
• Kırmızı bayrak 62: servis sırrını kaynak koda koymak.
• Kırmızı bayrak 63: loglara açık adres ve kart verisi yazmak.
• Kırmızı bayrak 64: rol testini yalnız olumlu yapmak.
• Kırmızı bayrak 65: anahtar rotasyonunu hiç prova etmemek.
• Kırmızı bayrak 66: alt işleyenleri bilmemek.
• Kırmızı bayrak 67: saklama süresini sınırsız yapmak.
• Kırmızı bayrak 68: veri lokasyonunu doğrulamamak.
• Kırmızı bayrak 69: audit logu düzenlenebilir tutmak.
• Kırmızı bayrak 70: ihlal runbookunu test etmemek.

Satın alma

• Kırmızı bayrak 71: canlı demo yerine sunuma güvenmek.
• Kırmızı bayrak 72: referans hacmini doğrulamamak.
• Kırmızı bayrak 73: test ortamını üretim eşdeğeri sanmak.
• Kırmızı bayrak 74: fazla kullanım ücretini hesaplamamak.
• Kırmızı bayrak 75: SLA hariçlerini okumamak.
• Kırmızı bayrak 76: özel entegrasyon bakımını bütçelememek.
• Kırmızı bayrak 77: veri çıkışını denememek.
• Kırmızı bayrak 78: güvenlik raporunun tarihini kontrol etmemek.
• Kırmızı bayrak 79: pilot geri dönüş ölçütü koymamak.
• Kırmızı bayrak 80: marka vaadini teknik garantiye çevirmek.

SoloCommerce’i değerlendirme ve sonraki adım

Canlı paket sayfasında doğrulanan tek panel, web sitesi ve pazaryeri sipariş görünürlüğü, stok/depo görünürlüğü, kargo/iade süreç görünürlüğü, otomatik faturalandırma, ERP ve özel entegrasyon ifadeleri bir keşif başlangıcı sağlar. E-ticaret paketlerini karşılaştırırken bu rehberdeki UAT satırlarını demo verisiyle çalıştırın; hangi kabiliyetin standart, hangi bağlantının özel entegrasyon ve hangi hizmet seviyesinin Enterprise teklif kapsamında olduğunu yazılılaştırın.

Pazaryeri kapsamını ayrıca SoloMarketplace pazaryeri entegrasyonu, belge bağlantısını Solofor e-Fatura sayfasından canlı olarak kontrol edin. Çok kanallı B2B gereksinimi için B2B e-ticaret sitesi rehberinden yararlanın; taşıma ve eski sistem veri alışverişi gereksinimlerini ise proje kapsamına göre ayrıca test edin.

Başlangıç sırası basittir: önce mevcut sipariş akışını ve istisnaları ölçün; sonra canonical model, durumlar, ATS formülü, rezervasyon ve yönlendirme politikasını yazın; kritik 10–20 UAT senaryosuyla adayları eleyin; sınırlı pilotta müşteri vaadini ve mutabakatı kanıtlayın. İhtiyaçlar altyapı içi yönetimle karşılanıyorsa gereksiz karmaşıklık eklemeyin. Çok kaynaklı kararlar farklılaştırıcıysa bağımsız OMS veya hibrit seçeneği değerlendirin. Ticaret operasyonunu bütün olarak görmek için SoloCommerce paket kapsamını inceleyin; hiçbir pazarlama cümlesini teknik veya sözleşmesel garanti yerine koymayın.

Sonuç: İyi bir OMS, siparişin nereden geldiğini bilmenin ötesinde neye söz verildiğini, bu sözün hangi stok ve kapasiteyle karşılanacağını, kararın neden alındığını ve sapma olduğunda kimin ne yapacağını görünür kılar. Kazanç yalnız otomasyon değildir; daha ölçülebilir müşteri vaadi, daha düşük fazla satış riski, daha hızlı istisna çözümü ve denetlenebilir ticaret operasyonudur.