Nebim V3 ERP Nedir? Perakende ve E-Ticaret İçin Kapsamlı Rehber

Ay sonu kapanışında masaya üç ayrı rakam gelir: mağazanın kasa raporu, e-ticaret panelinin sipariş dökümü, muhasebenin defter kaydı. Üçü de kendi içinde tutarlıdır. Hiçbiri diğerini tutmaz. Aradaki farkı kapatmak için birileri iki gün boyunca Excel'de eşleştirme yapar, bulunan sapma "sonra bakarız" klasörüne girer ve bir sonraki ay aynı iş yeniden başlar. ERP tam olarak bu dağınıklığı toplayan sistemdir; Nebim V3 ise Türkiye'de özellikle perakende ve moda–tekstil tarafında yaygın kullanılan ERP çözümüdür.

ERP tam olarak neyi çözer?

ERP'yi "muhasebe programının büyüğü" saymak yaygın ama eksik. ERP'nin asıl işi, bir ürünün satın alınmasından müşteriye ulaşmasına kadar geçen her adımı tek bir veri modeli üzerinde birleştirmektir. Doğru kurgulandığında şu soruların cevabı tek ekrandan alınır:

• Şu anda hangi üründen, hangi depoda, kaç adet var?
• Bu ayki brüt kârım kanal bazında ne durumda?
• Hangi tedarikçiye ne kadar borcum var, vadesi ne zaman?
• İade edilen ürün stoğa geri girdi mi, faturası düzeltildi mi?

Pratikteki karşılığı şu: aynı hareket sisteme bir kez girer; stok ve cari bakiyesi anında değişir, muhasebe fişi de aynı kayıttan üretilir. Muhasebeleştirme çoğu kurulumda günlük ya da dönemsel çalışan toplu bir adımdır; önemli olan fişin ikinci kez elle yazılmamasıdır. Ayrı programlarla çalışırken tek bir sevkiyat üç ayrı yere işlenir, dolayısıyla üç ayrı yerde yanlış işlenebilir. Sistem sayısı arttıkça zorlaşan şey hatayı bulmak değil, hatanın hangi sistemde başladığını bulmaktır.

Nebim V3 kimin için uygun?

Nebim V3, özellikle çok kanallı satış yapan işletmelerde güçlüdür: mağaza, e-ticaret, bayi ve toptan aynı anda yönetiliyorsa yapı buna göre kurgulanmıştır. Varyantlı ürün yönetimi ve mağazacılık süreçleri bu segmentte öne çıkar.

Somut bir sahne üzerinden bakalım. Üç mağazası ve kendi sitesi olan bir ev tekstili markasında cuma akşamı, o modelden kalan son nevresim takımı mağaza kasasından geçiyor. Aynı dakikalarda site o ürünü hâlâ satışta gösteriyor ve sipariş düşüyor. İki kayıt da kendi içinde doğru; tutmayan şey, iki sistemin aynı adede aynı anda bakmaması. Nebim V3'ün bu segmentte işe yaradığı yer tam burası: kasa fişi de e-ticaret siparişi de aynı deponun stok bakiyesini düşürür, siteye hangi deponun açılacağı tanımla belirlenir, renk–beden matrisi ürün kartında, bayi fiyatı ise ona bağlanan ayrı bir fiyat listesinde durur.

Buna karşılık tek kanaldan, sınırlı ürün çeşidiyle satış yapan ve ekibinde süreç sahibi bulunmayan küçük işletmelerde ERP çoğu zaman erken bir yatırım. Kimsenin sahiplenmediği sistem, pahalı bir veri giriş ekranına dönüşür. Önce süreçleri oturtmak, ERP'yi sonra konuşmak daha ucuza geliyor. Ara adım olarak stok ve sipariş takibini toparlayan bir panel çoğu ölçekte yetiyor; bu geçişi Excel'den özel panele geçiş yazısında ayrıntılı anlattık.

ERP'ye geçme zamanı geldi mi? Hızlı kontrol

Sık kullanılan modüller ve pratikte karşılığı

Stok ve ürün yönetimi

Ürün hiyerarşisi, varyantlar, barkod yapısı ve depo tanımları burada kurgulanır. E-ticaret entegrasyonunun kalitesi büyük ölçüde bu tanımların doğruluğuna bağlıdır: stok kodu ve barkod disiplini bozuksa, entegrasyon ne kadar iyi yazılırsa yazılsın sonuç hatalı olur. Depo sayısı arttıkça mal kabul, transfer ve sayım da aynı modelin içinde tanımlanır.

Satış ve sipariş

Mağaza satışı, e-ticaret siparişi ve toptan sipariş aynı akışta toplanır; onay, hazırlık, sevk ve iptal durumları tek ekrandan izlenir. Kısmi sevkiyatta kalan bakiyenin sipariş üzerinde açık kalması, günde 250 sipariş çıkaran bir operasyonda tek başına ciddi bir kolaylık. Bu olmadığında depoda "kalanlar" başlıklı bir liste doğar, kimse sahiplenmez ve unutulan kalem müşteri arayınca ortaya çıkar.

Finans ve muhasebe

Cari hesaplar, tahsilat, ödeme planı ve e-Fatura / e-Arşiv süreçleri buraya bağlanır. Doğru kurulduğunda muhasebe ekibi ay sonunu veri toplayarak değil, kontrol ederek kapatır. Hangi belgenin hangi adımda üretileceğini e-Fatura ve e-İrsaliye entegrasyonu yazısında ele aldık.

Raporlama

ERP'nin gerçek değeri raporlamada ortaya çıkar. Satış, stok devir hızı, iade oranı ve kanal kârlılığı aynı modelden okunduğunda sistem yalnızca kayıt tutmaz; hangi ürünü ne zaman ısmarlayacağınıza da karışır. Hangi raporu isteyeceğinizi kurulumdan önce yazmanın sebebi de bu. Rapor ihtiyacı veri modelini geriye doğru şekillendirir: kanal kırılımı istiyorsanız her hareketin üzerinde kanal alanı olmalı. Sonradan eklenen kırılım eski hareketlerde boş kalır.

Veri modelinde en çok atlanan beş karar

Kurulum toplantılarında modüller konuşulur, tanımlar konuşulmaz. Oysa projenin ilk yılında yaşanan sıkıntıların çoğu modül eksikliğinden değil, aşağıdaki beş kararın toplantıda hızlı geçilmesinden çıkar.

Bu beşin yanına bir altıncısı eklenebilir: stok maliyet yöntemi. Hangi yöntemin (ağırlıklı ortalama, FIFO) çalışacağı ve açılış stoklarının hangi maliyetle taşınacağı baştan kararlaştırılmazsa, kanal kârlılığı raporu ilk aydan itibaren yanlış bir maliyetin üstüne kurulur. Yöntemi sonradan değiştirmek, geçmiş hareketlerin yeniden değerlenmesi demek.

Kurulumda verilmeyen her karar, canlıya geçtikten sonra veri düzeltme işi olarak geri gelir. Tanımı değiştirmek bir günlük iştir; yanlış tanımla birikmiş altı aylık hareketi düzeltmek değildir.

Geçiş süreci nasıl planlanmalı?

1. Analiz: Mevcut süreçler, veri kaynakları ve kanallar çıkarılır. Projenin kaderi büyük ölçüde burada belirlenir.
2. Tasarım: Ürün, depo, cari ve fiyat yapısı ERP mantığına göre modellenir.
3. Veri taşıma: Ürün, stok ve cari verisi temizlenerek aktarılır. Mükerrer stok kodları birleştirilir, cari bakiyeleri mutabakattan geçmeden taşınmaz; taşınan hatalı kayıt yeni sistemde de hatalı kalır.
4. Entegrasyonlar: E-ticaret, pazaryeri, kargo ve e-Fatura bağlantıları kurulur.
5. Test ve eğitim: Gerçek senaryolarla paralel çalışma yapılır, kullanıcı eğitimleri verilir.
6. Devreye alma ve destek: Canlıya geçiş sonrası ilk haftalar yakın takip ister.

Sürenin ne kadar olacağı duruma göre değişir; kanal sayısı, veri kalitesi ve karar verecek kişinin ne kadar erişilebilir olduğu üç ana etken. Üçüncüsü sanıldığından ağır basıyor: cevabı bir hafta bekleyen tek bir soru, arkasındaki üç işi birden durdurur. Bu yüzden kimin neye tek başına karar verebileceğini baştan yazın, gerisi için haftalık sabit bir toplantı koyun.

Paralel çalışma dönemi

Eski sistemi kapatmadan ikisini bir süre birlikte yürütmek yaygın bir yaklaşım. Faydalı ama bedava değil: ekip aynı işi iki kez yapar. Bu yüzden paralel dönemi kısa tutun, kapsamını da baştan sınırlayın. Genelde satış ve stok hareketlerini iki tarafta da işlemek, muhasebe kapanışını tek tarafta yürütmek yeterli oluyor.

Canlıya geçiş öncesi kontrol listesi

• Ürün ve barkod verisinde mükerrer kayıt kaldı mı, açılış stokları sayımla doğrulandı mı?
• Açık siparişler ve açık cari bakiyeleri hangi tarihe kadar eski sistemde kalacak?
• Hangi kullanıcı hangi depoda hareket yapabilecek, depolar arası transferi kim onaylayacak?
• e-Fatura, e-Arşiv ve e-İrsaliye tarafında test ortamında uçtan uca belge kesildi mi?
• Yetkiler rol bazında tanımlandı mı; depo personeli fiyat değiştirebiliyor mu?
• Geri dönüş planı var mı? İlk hafta işler yürümezse ne yapılacağı belli mi?

Sık yapılan hatalar

• Her şeyi aynı anda devreye almak: Kanalları aşamalı açmak riski ciddi biçimde düşürür.
• Veri temizliğini atlamak: Mükerrer stok kodu ve eksik barkod, entegrasyonun ilk gününde patlar.
• Standart olanı zorlamak: Her istisnayı özelleştirmeye çevirmek, versiyon yükseltmelerini zamanla kilitler.
• Eğitimi tek seferlik saymak: Personel devri olan ekiplerde eğitim, canlıya geçişten sonra da tekrarlanmalı.

Bir de sessiz bir hata var: sistemi alan ile kullanacak olanın farklı kişiler olması. Depo şefinin ilk gün ekrana bakıp "bu böyle yürümüyor" demesi çoğu zaman haksızlık değildir; onun günlük ritmi analiz masasında hiç konuşulmamıştır. Toplantılara depodan, muhasebeden ve müşteri hizmetlerinden birer kişi çağırmak, sonradan yazılacak onlarca özelleştirmeyi baştan eler. Seçim aşamasındaki kriterleri ve şartname maddelerini ERP programı nasıl seçilir yazısında topladık.

ERP projelerinin çoğu yazılımdan değil, karar verilmemiş süreçlerden dolayı uzar. "Bu ürün iade edildiğinde ne olacak?" sorusunun cevabı projeden önce netleşmelidir.

Nebim V3 tek başına yeterli mi?

Çoğu işletmede ERP çekirdeği yeterlidir; ancak kanal sayısı arttıkça ERP ile e-ticaret arasında bir entegrasyon katmanı gerekir. Stok, sipariş ve fatura verisinin hangi yönde akacağını Nebim V3 – e-ticaret entegrasyonu yazısında akış şemasıyla anlattık. Depo hacmi büyüdüğünde ise devreye WMS girer; ERP'nin stok kaydı ile WMS'in raf hareketinin nasıl ayrıştığı ayrı bir konu.

Bunların dışında kalan, işletmeye özgü ihtiyaçlar için de özel yazılım devreye alınır. Sınırı çizerken sorulacak soru, ERP'nin o işi yapıp yapamadığı değil; o işi yaptırmak için standardı ne kadar eğmek gerektiğidir. Cevap "epeyce" ise ayrı bir katman hem ucuza gelir hem de versiyon yükseltmelerinin önünü açar. İade Yönetim Paneli bunun tipik bir örneği; iade süreci ERP'nin standart akışına sığmadığında yanına oturan bir katman olarak çalışıyor. Kurulum ve özelleştirme tarafındaki kapsamımız ERP çözümleri sayfasında.

Bu konuda nasıl yardımcı oluyoruz?

Yuog Dev olarak e-ticaret işletmelerinin ERP, entegrasyon ve otomasyon altyapısını kuruyoruz. İhtiyaç analiziyle başlıyor, ölçülebilir hedefler koyuyor ve teslim sonrasında da destek veriyoruz. Süreçlerinizi konuşmak isterseniz iletişim sayfasından bize ulaşabilirsiniz.