E-ticaret sitesi, pazaryeri, B2B bayi portalı, showroom ve telefonla gelen siparişleri tek havuzda toplarız. Stok her kanala ayrı ayrı değil, tek kaynaktan söz verilir; ayrılan miktar düşer, iptal ve iade geri döner. Amaç aynı ürünü iki kez satmamak ve siparişin nerede olduğunu tek ekrandan görmektir.
Bir firma tek kanaldan satarken sipariş yönetimi diye ayrı bir işten söz edilmez; sipariş gelir, stoktan düşer, sevk edilir. Kanal sayısı arttığında tablo hızla değişir. Kendi siteniz, birkaç pazaryeri, bayilerin girdiği B2B portal, showroomdaki satış ve hâlâ telefonla ya da WhatsApp'tan gelen siparişler aynı depodan beslenir; ama her biri stoğu kendi tarafında ayrı bir sayı olarak tutar. Bir üründen elinizde otuz adet varken pazaryerine otuz, siteye otuz, bayi portalına otuz yazılır. Bu dağıtım işlerken sorun görünmez, satış yoğunlaştığında ise aynı gün içinde aynı ürün birden fazla kanala satılır. Ardından iptal, müşteri şikâyeti, pazaryeri tarafında performans cezası ve satış ekibiyle depo arasında sonu gelmeyen bir telefon trafiği başlar.
Sipariş yönetimi ve orkestrasyonu, yani OMS (Order Management System), bu dağınıklığı tek karar noktasına bağlayan katmandır. İşin özü stoğun kanallara paylaştırılması değil, tek bir havuzdan söz verilmesidir. Her kanaldan gelen sipariş aynı havuza düşer; sipariş alındığı anda ilgili miktar o siparişe ayrılır ve diğer kanallara açık görünen miktar düşer. Buna söz verilebilir stok, yani ATP (Available to Promise) denir: elinizdeki fiziksel stok değil, bugün gerçekten satabileceğiniz miktardır. Bekleyen tedarik siparişleri, rezerve edilmiş miktarlar, bayi tarafındaki bloke stok ve iade beklenen ürünler bu hesabın içine girer. Orkestrasyon ise siparişin kabulden teslime kadar hangi adımlardan, hangi kuralla geçeceğini yönetmektir.
OMS'in en çok karıştırıldığı üç şey vardır ve sınırı baştan çizmek gerekir. E-ticaret altyapısı satış vitrinidir; ürünü gösterir, sepeti ve ödemeyi yürütür, ama diğer kanalları bilmez. ERP muhasebe ve finansal kaydın merkezidir; faturayı, cariyi ve resmî stoğu tutar, fakat siparişin operasyonel yaşam döngüsünü ve kanal kurallarını yönetmek için tasarlanmamıştır. Depo yönetimi ise ürünün depoda hangi rafta olduğuyla ilgilenir. OMS bunların arasında durur: hangi kanala ne kadar söz verildiğini, siparişin hangi depodan veya şubeden karşılanacağını, hangi durumda beklemeye alınacağını ve iade geldiğinde stoğun ne zaman tekrar satılabilir sayılacağını belirler. Kurduğumuz katman bu üçünün yerine geçmez, aralarındaki boşluğu doldurur.
Bu işin dürüst kurulmasının şartı iki noktayı açıkça söylemektir. Birincisi, çift satış tamamen sıfırlanmaz. Pazaryeri tarafındaki stok güncellemeleri anlık değildir, API kotaları ve gecikmeler vardır; iki müşterinin son adedi saniyeler arayla sepete koyması her sistemde mümkündür. Yaptığımız iş bu riski kanal bazlı tampon miktarlar, hızlı senkron ve son adet kurallarıyla belirgin biçimde azaltmaktır; sıfır vaat etmiyoruz. İkincisi, OMS stok doğruluğu üretmez. Depodaki fiili miktar kayıtla uyuşmuyorsa sistem yanlış sayıyı hızlı ve düzenli biçimde tüm kanallara dağıtır. Bu yüzden projeye başlarken sayım disiplinini ve stok hareketlerinin kayda geçmesini, yazılımdan önce konuşuruz.
Kendi sitesi, pazaryerleri ve bayi portalı aynı depodan beslenen üretici ve toptancılar. Bu firmalarda kanal sayısı arttıkça stok tablosu elle yönetilemez hale gelir ve kararlar günün yoğunluğuna göre değişir. Kazanç, stoğun kanallara bölünmesi yerine tek havuzdan söz verilmesi kuralının kurulmasıyla başlar.
Bayiye toptan, son tüketiciye perakende satan işletmeler. İki tarafın fiyatı, ödeme koşulu, cari limiti ve teslim önceliği farklıdır. Aynı stoğu paylaşırken kıt üründe hangi siparişin önce karşılanacağı kural olarak tanımlanmadığında karar her seferinde kişiye kalır ve bayiyle son tüketici arasında sürekli bir gerilim üretir.
Birden fazla depo, şube veya showroomdan sevkiyat yapan firmalar. Siparişin hangi noktadan karşılanacağı mesafe, stok, teslim süresi ve kargo maliyetine göre kurala bağlanabilir. Aksi halde en yakın depoda ürün varken uzaktan gönderim yapılır, bir şubede biriken stok satılamaz ve iki nokta arasında gereksiz transfer trafiği oluşur.
Moda, ayakkabı ve yedek parça gibi iade oranı yapısal olarak yüksek olan kategorilerde çalışan firmalar. İadenin ne zaman tekrar satılabilir stok sayılacağı belirsizse hem stok fazlası hem eksiği aynı anda görülür, kanal mutabakatı aylara yayılır ve müşteriye verilen para iadesi gecikir. Kural netleştiğinde bu üç sorun birlikte azalır.
| Yetenek | Ne sağlar |
|---|---|
| Kanalların tek sipariş havuzunda toplanması | E-ticaret sitesi, pazaryerleri, B2B portal, showroom ve elle girilen siparişler aynı yapıya çevrilerek tek listede toplanır. Her siparişin hangi kanaldan geldiği, hangi fiyat listesiyle ve hangi koşullarla alındığı kayıtta durur. Ekip her kanalın kendi paneline ayrı ayrı bakmak zorunda kalmaz; kanal panelleri kapanmaz ama günlük iş tek ekrandan yürür. |
| Stok ayırma ve söz verilebilir stok (ATP) | Sipariş alındığı anda ilgili miktar o siparişe ayrılır ve satılabilir stoktan düşer. Bekleyen tedarik siparişleri, rezerve miktarlar ve bloke stok hesaba katılarak söz verilebilir miktar, yani ATP (Available to Promise) hesaplanır. Ayırma süresi dolan veya ödemesi gelmeyen siparişlerde ayrılan stok kural gereği serbest bırakılır ve tekrar satışa açılır. |
| Kanal stok senkronu ve çift satış riskinin azaltılması | Satılabilir miktar tüm kanallara belirlenen sıklıkta gönderilir. Hızlı tükenen ürünlerde kanal bazlı tampon miktar tanımlanır ve son adetlerde daha temkinli davranılır. Bu yaklaşım riski azaltır, tamamen ortadan kaldırmaz; çift satış oluştuğunda sistem bunu istisna olarak işaretler, kimin müdahale edeceğini belirler ve müşteriye ne söyleneceği önceden kararlaştırılmış olur. |
| Sipariş kaynağı seçimi ve bölünmüş sevkiyat | Siparişin hangi depodan, şubeden veya tedarikçiden karşılanacağı stok, mesafe, teslim süresi ve maliyet kurallarına göre belirlenir. Tek noktada tamamlanamayan siparişlerde bölünmüş sevkiyat yapılabilir; kaç parça halinde gideceği ve ek kargo maliyetinin kabul edilip edilmeyeceği kuralla yönetilir. Kural sizin kararınızdır, sistem yalnızca onu tutarlı biçimde uygular; aynı durumda iki çalışan farklı karar vermez. |
| Sipariş yaşam döngüsü ve durum yönetimi | Onay, ödeme kontrolü, cari limit ve vade kontrolü, hazırlık, paketleme, kargo teslimi ve teslim durumları tek akışta izlenir. B2B tarafında limiti aşan bayi siparişi otomatik olarak onaya düşer. Her durum değişikliği kim, ne zaman ve hangi nedenle sorularının cevabıyla birlikte loglanır; bekleyen siparişler neden beklediğiyle birlikte listelenir. |
| İade, değişim ve iptal yönetimi | İade talebi geldiği kanaldan bağımsız olarak aynı akışta karşılanır: neden kodu, ürün kontrolü, tekrar satılabilir veya hurda kararı, para iadesi ya da değişim. Ürün ancak kontrolden geçtikten sonra satılabilir stoğa döner, böylece olmayan mal satışa açılmaz. İade nedenlerinin ürün ve kanal bazlı raporu çoğu firmada ilk kez düzenli olarak görülür. |
| Entegrasyonlar ve istisna yönetimi | Pazaryeri ve e-ticaret API'leri, kargo firmaları, ERP ve muhasebe sistemi bağlanır; fatura ile e-arşiv akışı buradan tetiklenir. Bir entegrasyon hata verdiğinde işlem sessizce kaybolmaz: belirli aralıklarla yeniden denenir, çözülemezse istisna listesine düşer ve sorumluya bildirilir. Her istisnanın bir sahibi ve bir çözüm süresi vardır. Görünmeyen hata, sipariş yönetiminde en pahalı hata türüdür. |
Hangi kanaldan ne kadar sipariş geldiğini, stoğun bugün nasıl paylaştırıldığını ve çift satışın hangi ürünlerde yaşandığını çıkarırız. Kanal öncelikleri, iade politikası ve ödeme koşulları yazıya dökülür. Bu adımın çıktısı yazılım değil, üzerinde anlaşılmış bir kural setidir; kurallar netleşmeden yazılan yazılım kısa sürede yeniden yazılır.
Aynı ürünün her kanaldaki farklı kodları tek ürün kimliğine bağlanır; varyant, paket ve set ürünler ayrıştırılır. Depodaki fiili stokla kayıt karşılaştırılır ve fark nedenleri incelenir. Bu adım projenin en çok küçümsenen kısmıdır ve ürün sayısına göre genellikle iki ile beş hafta arasında sürer.
Stok ayırma süresi, kanal tampon miktarları, kaynak deposu seçimi, bölünmüş sevkiyat, onay eşikleri ve iade akışı tanımlanır. Kurallar canlıya alınmadan önce geçmiş sipariş verisi üzerinde denenir; sonuç sizin o dönemde verdiğiniz kararlarla karşılaştırılır ve farklar tek tek tartışılır. Kabul edilmeyen kural canlıya çıkmaz.
Bağlantılar kurulur ve sistem önce tek kanalda ya da tek ürün grubunda çalıştırılır. Eski yöntem bir süre paralel yürür; iki taraftaki stok ve sipariş farkları günlük olarak kontrol edilir. Pilot çoğu projede dört ile sekiz hafta arasında tamamlanır ve bu sürede kuralların gerçek trafikte nasıl davrandığı görülür.
Kalan kanallar sırayla eklenir, istisna listesi ve uyarılar devreye alınır, raporlar açılır. Ekibe devir yapılır; hangi istisnaya kimin bakacağı ve kuralların nasıl değiştirileceği yazılı bırakılır. Sonrasında bakım kapsamında izleme sürer ve yeni bir kanal açtığınızda aynı yapıya eklenir, sistem yeniden kurulmaz.
Hayır ve bunu vaat etmiyoruz. Pazaryeri tarafındaki stok güncellemeleri anlık değildir; API kotaları, kuyruk gecikmeleri ve platform tarafındaki önbellekler nedeniyle saniyeler mertebesinde bir açık her zaman kalır. Yaptığımız iş bu riski ölçülebilir biçimde küçültmektir: hızlı senkron, kanal bazlı tampon miktar, son adetlerde temkinli davranma ve çift satış oluştuğunda bunu istisna olarak yakalayıp kimin ne yapacağını netleştirmek. Sıfır çift satış sözü veren bir teklife temkinli yaklaşmanızı öneririz.
Düzeltmez. Bu, sayfada söylememiz gereken en önemli sınırlardan biri. OMS eldeki sayıyı doğru varsayar ve onu kanallara dağıtır; kayıt yanlışsa yanlış sayıyı daha hızlı ve daha geniş biçimde yayar. Bu yüzden projeye başlarken sayım disiplinini, depo giriş-çıkış hareketlerinin kayda geçmesini ve fireyle numunenin nasıl düşüleceğini konuşuruz. Stok doğruluğu yeterli değilse önce o tarafı düzeltmenizi, yazılımı sonra devreye almanızı öneririz.
Her firmada gerekmez. Tek depodan, tek fiyat listesiyle ve sınırlı sayıda kanalda satıyorsanız mevcut entegratör çözümünüz büyük ihtimalle yeterlidir; bunu açıkça söyleriz. OMS ihtiyacı genellikle şu durumlarda doğar: B2B ile B2C aynı stoğu paylaşıyorsa, birden çok depo veya şubeden sevkiyat yapılıyorsa, kanala göre farklı öncelik ve ayırma kuralları gerekiyorsa ya da iade hacmi stok görünürlüğünü bozuyorsa. Hangisinde olduğunuzu keşifte birlikte belirleriz.
Hayır. Kullandığınız ERP veya muhasebe programı yerinde kalır; fatura, cari ve resmî stok kaydı orada tutulmaya devam eder. OMS bunun üzerinde çalışan operasyonel katmandır: siparişi toplar, stoğu ayırır, kanallara söz verir, akışı yönetir ve sonucu ERP'ye yazar. Böyle kurmamızın nedeni hem muhasebe düzeninizi bozmamak hem de geçişi kademeli yapabilmektir. Kaynak kod ve veri her durumda sizindir.
Evet, ama kuralları farklı tanımlanır. Bayi tarafında fiyat listesi, cari limit, vade, minimum sipariş miktarı ve onay eşiği devreye girer; son tüketici tarafında ödeme onayı ve kargo süreci öndedir. İkisi aynı stok havuzunu paylaşır ve kıt üründe hangisinin öncelikli olduğu kural olarak yazılır. Bu ticari kararı sizin yerinize biz vermeyiz; keşifte açıkça konuşup yazıya döker, sistemi ona göre kurarız.
Tüm kanalların düştüğü tek sipariş havuzu; stok ayırma ve söz verilebilir stok hesabı; kanallara senkron gönderim ve tampon kuralları; siparişin hangi depodan karşılanacağını belirleyen kaynak seçimi; onaydan teslime kadar durum takibi ve denetim kaydı; iade, değişim ve iptal akışı; entegrasyon hatalarının düştüğü istisna listesi; kanal, ürün ve iade nedeni bazlı raporlar. Kaynak kod, dokümantasyon ve veri size aittir.
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
Ürünün tüm özniteliklerini, açıklamalarını ve çeviri metinlerini tek merkezde toplarız; her satış kanalının kendi şablonuna göre zenginleştirilmiş halini oradan üretiriz. Eksik veya kurala aykırı alan, ürün kanala çıkmadan önce yakalanır. Ürün verisi artık kimsenin masaüstündeki dosyasında yaşamaz.
Detay →Fotoğraf, video, katalog ve tasarım dosyalarını tek arşivde toplar; her dosyanın hangi ürüne ait olduğunu, hangi sürümün onaylı olduğunu ve nerede kullanılabileceğini kayıt altına alırız. Kanalların istediği ölçü ve formatlar orijinalden otomatik türetilir; kimse dosya boyutlandırmakla uğraşmaz.
Detay →Mağazanın kasasını, stoğunu, kampanyasını ve vardiya devrini tek sistemde toplarız. Buradaki POS, internet sitesindeki sanal POS değil; tezgâhın üzerindeki gerçek kasadır. Çok şubeli yapılarda fiyat ve kampanya merkezden yönetilir, gün sonu her şubede aynı disiplinle kapanır.
Detay →Üretim planını makine ve hat düzeyinde sıraya çeviririz: kalıp ve ayar süreleri, darboğaz kapasitesi, malzemenin hazır olacağı tarih ve öncelik kuralları birlikte hesaplanır. Sonuç, sahada gerçekten uygulanabilen bir çizelge ve müşteriye verilebilecek savunulabilir bir termin tarihidir.
Detay →Üretim, kalite, bakım ve envanter operasyonlarını ortak bir veri modelinde birleştiririz. Aynı duruş, aynı lot ve aynı vardiya dört ayrı yerde değil tek kayıtta buluşur; vardiya devri yazılı hale gelir ve yönetim tek bir gösterge setine bakar.
Detay →Makine, tesis, araç ve ekipmanı satın alındığı andan elden çıkarıldığı ana kadar tek kayıt üzerinde tutarız. Garanti, kritiklik, yedek parça, bakım maliyeti ve amortisman aynı varlık kartında birikir; yenileme kararı tahminle değil biriken kayıtla verilir hale gelir.
Detay →
