ERP Programı Nasıl Seçilir? Kriter Listesi ve Maliyet Kalemleri

Demo toplantısında her şey akıcı görünür. Ekran paylaşılır, örnek bir ürün açılır, sipariş oluşturulur, faturası kesilir; masadaki herkes başını sallar. Sıkıntı altı ay sonra, kendi verinizle canlıya geçtiğinizde çıkar: renk–beden kırılımı tek satıra düşer, kısmi sevkiyatta sipariş bakiyesi kapanmaz, iade belgesi elle düzeltilir. ERP programı seçimi aslında bir yazılım karşılaştırması değil, kendi operasyonunuzu ne kadar net tarif edebildiğinizin sınavıdır. Karşılaştırma tablosunu açmadan önce doldurmanız gereken şey, kendi profiliniz.

Eleme, demo izleyerek değil profil çıkararak başlar

Aynı ERP, iki işletmede taban tabana zıt sonuç verir. Farkı yaratan dört ölçü var: kaç satış kanalı yönetiyorsunuz, katalogunuz kaç SKU'ya ve varyanta yayılıyor, günde kaç sipariş işliyorsunuz, kaç fiziksel lokasyonda stok tutuyorsunuz. Bu dördü yazılı değilse, önünüze gelen her sistem "yapıyor" cevabını verir. Yazılıysa konuşma somutlaşır; artık sayılar üzerinden ilerlersiniz.

Somutlaştıralım. 400 model taşıyan bir konfeksiyon markası, renk ve beden kırılımıyla rahatlıkla 6.000 SKU'ya çıkar. Aynı markanın kendi sitesi, iki pazaryeri ve üç mağazası varsa aslında altı ayrı stok görünümü, üç ayrı fiyat listesi ve birbirinden farklı iade kuralları yönetiliyor demektir. Bu profildeki bir işletmenin sorusu "ERP stok tutuyor mu" değil, "kanal bazında stok havuzunu ayırabiliyor mu"dur.

Bize ERP önerisi sormak için gelen işletmelere ilk söylediğimiz şey genelde şu: bu dört başlığı tek sayfaya yazın, altına da bugün Excel'de yürüyen işleri ekleyin. Şartnamenin iskeleti orada duruyor zaten.

Şartnamede pazarlık konusu olmayan dört madde

"ERP şartnamesi nasıl hazırlanır" sorusunun cevabı çoğunlukla bir modül listesine dönüşüyor. Oysa modüller zaten benzer. Sözleşmeyi asıl belirleyen, sistemin kapağını açıp açamayacağınızla ilgili maddeler.

• Veri sahipliği: Veritabanındaki kaydın sahibi kim? Sözleşme bittiğinde veri sizde mi kalıyor, sağlayıcının sunucusunda mı?
• API ve entegrasyon erişimi: Okuma yetkisi mi var, yazma da var mı? Belge açık mı, ek lisansa mı bağlı? Sipariş, stok, cari ve fatura uçları ayrı ayrı sorulmalı.
• Test ortamı: Canlıdan kopyalanabilen, ayrı bir test veritabanı verilecek mi? Bu madde yoksa her güncellemeyi canlı sistemde denersiniz.
• Veriyi dışa aktarma hakkı: Ürün, stok hareketi, cari ve fatura verisini istediğiniz an standart formatta alabiliyor musunuz? Ücretli mi, kaç günde teslim ediliyor?

Bir de yerel mevzuat maddesi var. e-Fatura, e-Arşiv, e-İrsaliye ve beyanname tarafındaki değişikliklerin sürüme ne kadar sürede yansıdığını, bunun bakım kapsamında mı yoksa ayrı geliştirme olarak mı fiyatlandığını sorun. Mevzuat değişikliğini her seferinde ek teklifle karşılayan bir sağlayıcı, bütçede hesaba katmadığınız bir kalem yaratır.

Sözleşmede API erişimi yazmıyorsa o erişim yok demektir. Toplantıda "tabii ki açarız" cümlesi, projenin altıncı ayında ek teklif olarak geri döner. Yazılı olmayan her esneklik, sonradan fiyatlanır.

Demoyu kendi verinizle ve zor senaryolarla yaptırın

Hazır demo verisi her sistemde çalışır; o veri o sistem için hazırlanmıştır. Satıcıdan 20–30 satırlık kendi ürün ve müşteri dosyanızı yüklemesini isteyin, sonra şu dört senaryoyu sırayla çalıştırın. Ekranı siz kullanın, onlar anlatsın.

1. Varyantlı ürün: Üç renk, beş beden bir modeli açın. Barkod üretimi, fiyat farkı ve toplu stok girişi kaç ekranda bitiyor?
2. Kısmi sevkiyat: Beş kalemlik siparişin üç kalemini sevk edin. Kalan bakiye siparişte açık kalıyor mu, e-ticaret tarafına ne yansıyor?
3. İade ve fatura düzeltmesi: Sevk edilmiş bir ürünü iade alın. Stok geri giriyor mu, alıcının tipine uygun iade veya düzeltme belgesi otomatik mi üretiliyor, cari bakiye kendi kendine düzeliyor mu?
4. Çok depolu stok: Ana depoda 10, mağazada 3 adet olsun. Siteye hangi rakam gidiyor ve bunu kim belirliyor?

Bu dört senaryo, kriter listesinin en sert filtresi. Pratikte en çok üçüncüsünde tıkanılır; iade akışı çoğu sistemde satışın aynası gibi kurgulanmamıştır, satış üç tıkla biterken iade beş ekran gezdirir. Ağırlığı e-ticaret tarafında olan bir işletmeyseniz iade ve fatura düzeltmesini kendi gözünüzle görmeden ilerlemeyin.

Lisans, toplam maliyetin yalnızca bir kalemi

ERP maliyetinin neye göre değiştiğinin kısa cevabı şu: lisansa değil, kendi veri ve süreç dağınıklığınıza göre. Bütçeyi hazırlarken lisansın yanına en az altı kalem daha yazın. Aşağıdaki tablo bir tahmin listesi değil, teklif alırken tek tek sormanız gereken kalemlerin dökümü.

Veri taşıma kalemi neredeyse her projede olduğundan büyük çıkar. Kirli veri taşınırsa sorun da taşınır; bu yüzden temizliği kimin yapacağı sözleşmede net olmalı. "Müşteri temizler" yazan bir maddeyi kabul ediyorsanız, bunu yapacak kişiyi ve süreyi de bugünden ayırın. Ölçüyü kabaca almak zor değil: mevcut ürün listesini çekip aynı barkodun kaç farklı stok kodunda geçtiğine, kaç kayıtta barkod alanının boş olduğuna bakın. Çıkan sayı, ilerleyen aylarda kaç gün eşleştirme yapacağınızın habercisi.

Çekirdek nerede biter, özel katman nerede başlar?

İkinci büyük karar, ERP'yi ne kadar zorlayacağınız. Bir modülü olmadığı işe zorlamak kısa vadede ucuz görünür, uzun vadede versiyon yükseltmelerini kilitler. Genel yaklaşımımız standardı hazır ERP çekirdeğinde bırakmak, işletmeye özgü olanı yanına ayrı bir katman olarak yazmak; böylece paket güncellemesi geldiğinde özelleştirmeler tek tek elden geçmez.

Sınırı nereye çizeceğinize dair pratik bir test var: bu süreç sizi rakibinizden ayırıyorsa özel katmana, herkes aynısını yapıyorsa çekirdeğe. Konuyu daha ayrıntılı tartıştığımız özel yazılım mı hazır paket mi yazısı bu ayrımı örneklerle ele alıyor. Kanal tarafındaki bağlantıların nasıl kurulduğunu ise e-ticaret entegrasyonları sayfasında bulabilirsiniz. Marka özelinde bir başlangıç noktası arıyorsanız Nebim V3 rehberi modül yapısını anlatıyor.

Karar matrisi: ağırlıklı puanlama nasıl kurulur?

İki üç aday kaldığında his devreye girer. Bunu engellemenin yolu, kriterleri ağırlıklandırıp puanlamak. Ağırlıkları demolardan önce belirleyin. Sonraya bırakırsanız ağırlıklar, farkında olmadan beğendiğiniz ürünün güçlü olduğu başlıklara kayar. Aşağıda iki aday için örnek bir hesap var; puanlar 1–5 arası, ağırlıkların toplamı 100.

Tablodaki fark beş puan. Bu kadar yakın bir sonuç, tablonun karar veremediği anlamına gelir; kararı referans görüşmeleri ve sözleşme maddeleri belirler. Tablonun asıl faydası kazananı ilan etmek değil, hangi başlıkta neyi feda ettiğinizi görünür kılmak. B sistemi entegrasyonda güçlü ama süreç uyumunda zayıfsa, aradaki farkı kapatacak geliştirme bütçesini bugünden hesaba katın. Puanları tek başınıza değil, o modülü kullanacak kişiyle birlikte verin; depo sorumlusunun 2 dediği bir ekrana yöneticinin 4 vermesi başlı başına bir bulgudur.

Referansı satıcı seçmesin, siz seçin

Size verilen referans listesi doğal olarak en memnun müşterilerden oluşur. Bunu bilerek gidin ve mümkünse kendi sektörünüzden, kendi büyüklüğünüze yakın bir işletmeyle konuşmayı isteyin. Görüşme 20 dakika sürer, projenin kaderini değiştirir.

Referans görüşmesinde sorulacaklar

• Canlıya geçiş ne kadar sürdü, ilk plandan ne kadar saptı ve sapmanın sebebi neydi?
• Destek talebine pratikte kaç saatte dönülüyor? Sözleşmedeki süre ile yaşadığınız süre aynı mı?
• Versiyon yükseltmesinde özelleştirmeleriniz bozuldu mu, bozulduysa masrafı kim karşıladı?
• Bugün baştan başlasanız aynı sistemi seçer miydiniz, neyi farklı yapardınız?

Sık yapılan satın alma hataları

• Kullanıcı lisansını düşük tutmak: Depo ve muhasebe ekibi ortak hesap paylaşmaya başlar, hareketlerin kim tarafından yapıldığı kaybolur. Sonradan lisans eklemek çoğu sözleşmede ilk alımdaki koşuldan pahalıya geliyor.
• Yazılımı seçip uygulayan ekibi seçmemek: Aynı ürün, iki farklı iş ortağının elinde bambaşka sonuç veriyor. Projede kimin çalışacağı, danışmanın benzer kaç kurulum yaptığı ve ekip değişirse ne olacağı sözleşmede yazılı olsun.
• Entegrasyonu sözleşme dışında bırakmak: ERP alınır, kanallara bağlanma işi "sonra bakarız" denir. Aradaki boşluk aylarca elle veri girişiyle kapatılır.
• Canlıya geçişi kampanya dönemine denk getirmek: Kasım ve yılbaşı haftalarında sistem değiştirmek, en deneyimli ekipte bile riski katlar.
• Süreç sahiplerini analiz masasına oturtmamak: Demoya yalnızca yönetim katılırsa, ekranı gün boyu kullanacak kişinin itirazı ancak canlıya geçtikten sonra duyulur.

Canlıya geçiş tarihini seçerken sipariş grafiğinizin en düşük olduğu dört haftayı işaretleyin ve paralel çalışma için de bir hafta ayırın. Tarih baskısı altında alınan ERP kararlarının çoğu, ikinci yılda yeniden masaya geliyor.

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.