Sipariş Yönetimi Nedir? CRM ile ERP Arasındaki Sınır Nerede Çizilir?
- Kategori
- CRM
- Yayın tarihi
- 27 Ağustos 2026
Sipariş yönetimi, müşteri “evet” dedikten sonra başlayan zinciri kayıt altında tutma işidir: teklif siparişe, sipariş sevkiyata, sevkiyat faturaya dönüşür ve her halkada kimin neyi ne zaman taahhüt ettiği bellidir.
Türkçe kaynakların çoğu bu zinciri tek bir yazılımın özellik listesi gibi anlatır. Bu yazı başka bir soruya cevap veriyor: zincirin hangi halkası CRM'de, hangisi ERP'de durur — ve o sınırı kim çizer?
Kısa cevap şu: sipariş yönetimi tek bir sistemin işi değildir, bir sınır kararıdır. Zincirin tamamını tek ekrana sığdırmaya çalışan her kurulum er ya da geç aynı duvara çarpar, ve o duvarın adı stoktur.
Aşağıda zincirin dört halkası, sınırın pratikte nereden geçtiği, stok gerçeğinin neden ERP tarafında kaldığı ve Rapitek CRM'in bu zincirin neresinde durduğu var. Sonda açık sınırlarımız yazılı.
Yazıdaki Rapitek CRM olguları, Ağustos 2026'da ürünün kendi şeması ve kurulum verisi üzerinden ölçülmüştür. Dış sağlayıcılar hakkında bu yazıda olgu iddiası yoktur.
Stok gerçeği ERP'de olur; CRM'in gördüğü kopyadır. Kopyayı gerçek sanan bir satış ekranı, müşteriye olmayan malı söz verir.
İçindekiler
Zincir dört halkadan oluşur: teklif, sipariş, sevkiyat, fatura
Dört halka aynı kelimelerle konuşur — hepsinde “müşteri”, “ürün”, “miktar” ve “tutar” vardır — ama aynı şeyi kastetmezler. Halkadan halkaya geçerken değişen şey alanlar değil, kaydın doğasıdır.
- Teklif bir öneridir. Değişmesi normaldir; üçüncü revizyonu ilk ikisi kadar meşrudur. Bir teklifin geçmişi, satış tarafı için kaydın kendisi kadar değerlidir.
- Sipariş bir taahhüttür. İki taraflıdır: müşteri almayı, siz vermeyi taahhüt edersiniz. Bu andan sonra kaydı tek taraflı değiştirmek bir düzeltme değil, sözden dönmedir.
- Sevkiyat fiziksel bir olaydır. Yazılımdaki satır, depoda olmuş bir şeyin izidir. Kayıt ile depo çelişirse depo haklıdır; yazılımın işi bu çelişkiyi görünür kılmaktır, örtmek değil.
- Fatura mali ve hukuki bir belgedir. Değiştirilemez; düzeltilmesi bile ayrı bir belge gerektirir.
Sınır tartışmasının tamamı tek bir olayın etrafında döner: bir kaydın “değişmesi normal” olmaktan çıkıp “değişmemesi gereken” hâle geldiği an. O an zincirin neresine düşüyorsa, sistemler arasındaki çizgi de oraya yakın durur.
Bir siparişin beş adımı ve her adımda değişen soru
-
1
Teklif yazılır
Fiyat, miktar, vade ve geçerlilik süresi belirlenir. Bu adımda sorulan soru şudur: bu fiyatı vermeye yetkim var mı? Cevap fiyat listesinde ve iskonto kuralındadır; henüz depoyu ilgilendiren bir şey yoktur.
-
2
Teklif siparişe dönüşür
Müşteri onayladığı anda kayıt öneri olmaktan çıkıp taahhüde döner. Soru da değişir: bu malı gerçekten verebilir miyim? Cevap CRM'de değil, stoğun tutulduğu yerdedir.
-
3
Stok ayrılır
Sipariş, sayılabilir bir miktarı belirli bir müşteriye bağlar. Bu ayırma iki sistemde birbirinden bağımsız yapılırsa aynı mal iki kez satılır; hata sipariş anında değil, sevkiyat günü görünür.
-
4
Sevkiyat çıkar
Mal depodan çıkar. Miktar kısmi olabilir, tarih kayabilir, irsaliye ayrı bir belge olarak doğar. Soru şu: müşteriye söylenen tarih hâlâ geçerli mi — ve bunu satış ekibi ne zaman öğreniyor?
-
5
Fatura kesilir, tahsilat izlenir
Belge resmî sağlayıcıda üretilir; satış tarafında kalan şey numara, tarih ve tutardır. Soru şu: bu satış tahsil edildi mi? Cevabı satış ekibinin de görmesi gerekir, çünkü bir sonraki teklifi o bilgi değiştirir.
Sınır nerede çizilir: CRM nerede biter, ERP nerede başlar?
Sınır teknik bir olgu değil, bir karardır. Ve kararı verirken işe yarayan tek ölçüt şu: bir alanın otoritesi, o alan yanlış olduğunda bedelini kim ödüyorsa oradadır.
Teklifteki fiyat yanlışsa satış revize eder, bedeli bir görüşmedir. Fatura tutarı yanlışsa bedeli mali işler öder ve bedel bir görüşme değildir. Bu yüzden fatura ERP tarafında kalır, teklif CRM tarafında.
İkinci kural birincisinden çıkar: her alanın otoritesi tek bir tarafa yazılır. İki sahipli alan bırakmak, iki değer ayrıştığında hangisinin geçerli olduğunu söyleyen bir kural bırakmamak demektir. Karar sistem sistem değil, alan alan verilir — “sipariş CRM'de olsun” cümlesi bir karar değil, bir temennidir.
Sınırın yeri kurumdan kuruma da kayar. ERP'si olmayan bir şirkette CRM zinciri daha uzun taşır ve sevkiyata kadar gider; yerleşik bir ERP'si olan şirkette CRM çoğu zaman siparişte durur, gerisini görünürlük olarak taşır. İkisi de doğru yerleşimdir; yanlış olan, hangisinde olduğunuzu yazılı hâle getirmemektir.
Bu sınırın iki yakasının nasıl bağlandığı — hangi alan, hangi yöne, hangi sıklıkta, hangi anahtarla — ayrı bir işin konusu: ERP–CRM entegrasyonunun kapsamı ve yöntemi ayrı bir sayfada duruyor.
Zincirin halkaları genelde nerede durur?
| Halka | Otorite genelde nerede | Neden orada |
|---|---|---|
| Teklif | CRM | Değişmesi normal olan tek halka; revizyon geçmişi satış tarafında anlam taşır |
| Sipariş | Sınırın tam üstünde | Satış taahhüdü kaydeder, sevk ve maliyet tarafı icra eder; iki taraf da aynı kaydı görmek zorundadır |
| Stok ve rezervasyon | ERP veya depo sistemi | Sayılabilir, fiziksel ve tek gerçekli; ikinci bir kopya ikinci bir gerçek üretir |
| Sevkiyat | ERP veya lojistik sistemi | İrsaliye, araç ve depo hareketine bağlı; CRM'in gördüğü şey durum bilgisidir |
| Fatura ve tahsilat | ERP veya mali sağlayıcı | Mali ve hukuki sonuç doğurur; düzeltilmesi bile ayrı belge gerektirir |
Stok gerçeği ERP'de olur; CRM'in gördüğü kopyadır
Zincirin en kırılgan halkası stoktur, çünkü stok dakikalar içinde değişebilen bir alandır. Bakiye gün içinde birkaç kez değişir; stok, bir sevkiyat aracı yüklenirken değişir.
Bir alanın iki sistem arasında kopyalanması tek başına senkron sayılmaz. Senkron, çelişki anında hangi tarafın kazanacağını tanımlamayı da gerektirir. O kural yazılmadıysa ortada senkron değil, iki bağımsız sayı vardır — ve iki sayı ayrıştığında ikisi de kendi ekranında doğru görünür.
Sonucu şurada görünür: satış ekranında yanlış stok görmek, hiç stok görmemekten farklı bir sonuç doğurur. Görülen sayıya güvenilerek müşteriye söz verilir. Boş bir alan insanı depoyu aramaya iter; yanlış dolu bir alan itmez.
Bu yüzden doğru kurulumda CRM'e taşınan şey otorite değil görünürlüktür: kapsamı ve tazeliği tanımlı bir kopya. Pratik ölçüt basit — bir stok sayısının yanında “en son ne zaman güncellendi” bilgisi yoksa, o sayı bir veri değil bir tahmindir ve ekranda tahmin gibi durmalıdır.
Sınırı çizerken cevaplanacak dört soru
Hangi alanın otoritesi kimde?
Her alanın sahibi tek bir sistem olmalı. İki sahipli alan, iki değer ayrıştığında hangisinin geçerli olduğunu söyleyen bir kural bırakmaz. Karar sistem sistem değil, alan alan verilir ve yazılı durur.
İki sistem aynı firmayı hangi alanla eşleştiriyor?
Kurulumlarımızda bu alan vergi kimlik numarasıdır, unvan değildir: aynı firma bir sistemde “A.Ş.”, diğerinde “AŞ” yazıldığında unvan üzerinden kurulan eşleşme kimse fark etmeden kaybolur.
Hangi bilgi hangi sıklıkta akıyor?
Bakiye görünürlüğü için günlük bir aktarım yetebilir; stok dakikalar içinde değişir. Sıklık bir teknoloji tercihi değil iş kararıdır — arttıkça kapsam da bedel de değişir.
Çelişki anında hangi taraf kazanır?
Çift yönlü akan her alan için bu kural yazılmadıysa senkron kurulmuş sayılmaz. Kural yoksa çelişki, onu ilk fark eden kişinin elle düzeltmesiyle çözülür; yani çoğu zaman hiç çözülmez.
Rapitek CRM bu zincirin neresinde duruyor?
Ağustos 2026'da ürünün kendi şemasını okuduk. Zincirin halkaları ayrı iş nesneleri olarak duruyor: teklif ve teklif kalemi, sipariş ve sipariş kalemi, sevkiyat ve sevkiyat kalemi, fatura ve fatura kalemi, ödeme. Stok tarafında depo, stok hareketi ve stok rezervasyonu ayrı nesneler.
Zincir üründe kuruludur ve kurulum bazında açılıp kapatılabilir; teklifin siparişe dönüşmesi hazır bir aksiyonla çalışır. Ama şunu da yazalım: bu bir şema ölçümüdür, saha ölçümü değil. Bu nesnelerin müşteri kurulumlarında ne kadar kullanıldığına dair yayımlanmış bir ölçümümüz yok, ve olmadığı için de kullanım iddiası kurmuyoruz.
Sınırın öteki yakasına bağlanmak için elimizdeki araçlar ölçülü: REST API OAuth2 ile korunur, composite ucu tek istekte 25 alt-istek taşır, toplu uçlar çağrı başına 200 kayıt alır; içe aktarma sihirbazının tavanı dosya başına 25 MB ve iş başına 100.000 satırdır; kayıt olaylarında dış sisteme imzalı webhook gider.
Entegrasyon tarafındaki tek somut kanıt şu: canlı bir müşteri kurulumunda, bize ait olmayan üçüncü taraf bir ERP entegratörü bu API üzerinden kayıt okuyup yazıyor. Tek kurulum olarak aktarıyoruz — yaygın bir uygulama olduğunu söylemiyoruz. Hangi bağlantıların bugün çalıştığı ve hangilerinin talep üzerine kurulduğu entegrasyonlar sayfasında duruyor.
Bizim sınırlarımız
Rapitek CRM bir ERP değildir ve ERP'nizin yerine geçmeyi teklif etmiyoruz. Bir CRM verinin otoritesini ERP'den almaya başladığı anda yaptığı iş entegrasyon projesi olmaktan çıkar, ERP değişim projesi olur; bizim işimiz o değil.
Anlık stok senkronizasyonu vaat etmiyoruz. Stok kaydının otoritesi ERP'nizde ya da depo sisteminizde kalır; çift yönlü canlı bir stok aynasını ölçülmüş bir yetenek olarak sunmuyoruz. Sunsaydık, birbirini tutmayan iki stok sayısı üretirdi. Yerine kapsamı ve sıklığı tanımlı bir görünürlük katmanı kuruyoruz.
Resmî belge üretimi bizim işimiz değil. Rapitek CRM e-Fatura veya e-Arşiv belgesi düzenlemez ve GİB özel entegratörü değildir; üründe ETTN ya da GİB durumu gibi alanlar bulunmuyor. Faturalarınız bugünkü sağlayıcınızda kesilmeye devam eder; numara, tarih ve tutar alan olarak taşınabilir. Ayrıntısı e-Fatura ve CRM sayfasında.
Hiçbir ERP için kutudan çıkan bir modülümüz yok ve olduğunu söylemeyeceğiz. Bağlantı, kapsamı keşifte belirlenen ayrı bir iş kalemidir.
Belge imzalama ekranı üründe kurulu ama sahada ölçülmedi: ölçüm günü bakılan 8 kiracının 8'inde de 0 imza ve 0 imza talebi vardı. Sipariş onayını imzaya bağlamayı planlıyorsanız bunu bilerek planlayın.
Süre konusunda da peşin söz vermiyoruz. Keşiften önce süre taahhüt etmiyoruz; keşif görüşmesinden sonra size aralık değil tarih veririz.
Sipariş yönetimi hakkında sık sorulan sorular
Sipariş yönetimi CRM'in işi mi, ERP'nin işi mi?
Teklif ile sipariş arasındaki fark nedir?
CRM'de stok görünür mü?
Rapitek CRM'de sipariş nesnesi var mı?
CRM'den e-fatura kesebilir miyiz?
ERP'miz yok. Sipariş zincirini CRM'de yürütebilir miyiz?
İlgili içerikler
- Satış yönetimi nedir? — Sipariş, satış yönetiminin bittiği yerde başlar; zincirin üst çerçevesi orada.
- Fırsat yönetimi nedir? — Fırsat kazanıldığı anda sipariş doğar; o kapanışın nasıl yönetildiği burada.
- Satış fırsatı nedir? — Zincirin teklif öncesi halkası: hangi kayıt fırsat sayılır?
- Görev yönetimi nedir? — Zincirde takılan her halka birinin görevidir; takibin nerede tutulduğu burada.
- Stok yönetiminde Excel'den sisteme geçiş — Stoğun otoritesi CRM'de olmadığına göre nereye taşınır: dört aday ve sayım günü.
- ERP CRM entegrasyonu — Sınırın iki yakasını bağlayan projenin kapsamı, yöntemi ve vaat etmediklerimiz.
- Entegrasyonlar — Bugün çalışan bağlantılar ve talep üzerine kurduklarımız.
Zincirin sınırını kendi sisteminiz üzerinden çizelim
Hangi halka sizde CRM'de duruyor, hangisi ERP'de — ve hangi alanın otoritesi kimde? Demo görüşmesinde bu tabloyu kendi kurulumunuz üzerinden doldurmaya başlıyoruz; kapsam yazılı belirlenir.
Entegrasyon, CRM kurulumundan ayrı bir iş kalemidir ve keşiften sonra ayrı fiyatlanır.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
