WMS Şartnamesi Nasıl Hazırlanır?

WMS teklifi isteyen işletmelerin çoğu, tedarikçilere bir özellik listesi gönderir: barkod okuma, parti takibi, mobil terminal desteği, raporlama. Gelen tekliflerin hepsinde bu maddelerin karşısında “var” yazar — ve karşılaştırma orada biter.

Şartnamenin işi özellik saymak değil, sizin süreçlerinizi tarif etmektir. Tedarikçi ancak o zaman “bunu standart yaparım, şunu geliştirme ile yaparım, bunu hiç yapamam” diyebilir. Karşılaştırılabilir teklif buradan çıkar.

Bu rehber, bir WMS şartnamesinin dokuz bölümünü ve her bölümde nasıl yazıldığında işe yaradığını anlatıyor.

Özellik listesi ile şartname arasındaki fark

Şartname, tedarikçinin “hayır” diyebileceği kadar somut olmalıdır. “Hayır” diyemiyorsa, soru yeterince net sorulmamıştır.

Bölüm 1: İhtiyaç ve kapsam

Ne yazılır: Projenin çözmeye çalıştığı somut problem ve başarı ölçütü. “Stok doğruluğunu göz bazında ölçülebilir hale getirmek”, “toplama hatasını kayıt altına alıp kök nedene bağlamak” gibi. Ayrıca kapsam dışı olanlar: hangi depo, hangi süreç, hangi ürün grubu dahil değil.

Nasıl yanlış yazılır: “Depo süreçlerinin dijitalleştirilmesi” gibi ölçülemeyen bir amaç cümlesiyle. Bu cümle her teklifi kabul edilebilir kılar ve hiçbirini karşılaştırılabilir yapmaz.

Bölüm 2: Süreç tanımları

Ne yazılır: Mal kabulden sevkiyata kadar her sürecin adım adım akışı — kim, nerede, hangi cihazla, hangi doğrulamayla. İstisnalar da yazılır: hasarlı ürün geldiğinde ne olur, sayımda fark çıkarsa kim onaylar, kısmi sevkiyat nasıl kapatılır.

Nasıl yanlış yazılır: Yalnızca mutlu senaryo yazılarak. Projelerin devreye alma aşamasında tıkandığı yer neredeyse her zaman istisna akışlarıdır; şartnamede yoksa, sözleşmede de yoktur.

Bu bölüm şartnamenin en uzun ve en değerli kısmıdır. Süreçleriniz yazılı değilse, şartname yazmadan önce süreç tanımı yapılmalıdır — sistem seçimi buradan sonra gelir.

Bölüm 3: Kullanıcı rolleri ve yetkiler

Ne yazılır: Kaç farklı rol var, her rol hangi ekranı görüyor, hangi işlemi yapabiliyor, hangi işlem için onay gerekiyor. Özellikle stok düzeltme yetkisi kimde olacak — bu tek satır, stok doğruluğunun geleceğini belirler.

Nasıl yanlış yazılır: “Yetkilendirme yapılabilmelidir” denerek. Her sistem yetkilendirme yapabilir; mesele sizin rol yapınıza uyup uymadığıdır.

Bölüm 4: Entegrasyon gereksinimleri

Ne yazılır: Hangi sistemle, hangi veri, hangi yönde, hangi sıklıkta. Stok gerçeğinin hangi sistemde tutulacağı açıkça belirtilir. Hata durumunda ne olacağı yazılır: mesaj yeniden denenir mi, kuyruklanır mı, kim uyarılır?

Nasıl yanlış yazılır: “ERP ile tam entegre çalışmalıdır” denerek. Bu cümle, devreye alma sırasında iki tedarikçinin birbirini işaret etmesiyle sonuçlanır. Entegrasyonun sorumlusu şartnamede isimlendirilmelidir.

Bölüm 5: Veri ve ana veri gereksinimleri

Ne yazılır: Ürün ana verisinde hangi alanlar zorunlu (barkod, birim dönüşümleri, boyut, ağırlık, raf ömrü), adres yapısı nasıl kurgulanacak, mevcut stok sisteme nasıl aktarılacak, aktarım öncesi hangi temizlik yapılacak.

Nasıl yanlış yazılır: Veri kalitesi hiç konuşulmadan. WMS projelerinde gecikmenin en sık nedeni yazılım değil, eksik ürün ana verisidir. Bu bölüm, projeden önce kimin ne temizleyeceğini yazılı hale getirir.

Bölüm 6: Performans ve ölçek

Ne yazılır: Zirve gündeki eşzamanlı kullanıcı sayısı, günlük satır hacmi, beklenen büyüme, terminal yanıt süresi beklentisi, sistemin çalışması gereken saat aralığı.

Nasıl yanlış yazılır: Bugünün ortalamasıyla. Sistem ortalamaya göre boyutlandırılırsa yılın en yoğun gününde yavaşlar — ve o gün, sistemin gerçekten gerektiği gündür.

Bölüm 7: Raporlama ve izlenebilirlik

Ne yazılır: Hangi raporlar standart gelmeli, hangi veriye kimin erişmesi gerekiyor, verinin dışa aktarılabilir olup olmadığı. İzlenebilirlik tarafında: bir ürünün hangi partiden, hangi göze, kim tarafından yerleştirildiğinin geriye dönük sorgulanabilmesi.

Nasıl yanlış yazılır: Rapor listesi verilerek ama hangi kararı besleyeceği yazılmadan. Kullanılmayan rapor, geliştirme maliyetidir.

İlgili: hangi göstergelerin ölçülmesi gerektiği →

Bölüm 8: Hizmet seviyesi ve destek

Ne yazılır: Arıza sınıfları ve her sınıf için müdahale süresi, destek saatleri, güncelleme politikası, yedekleme sorumluluğu, sistem erişilemezse devreye girecek manuel süreç.

Nasıl yanlış yazılır: Yalnızca “7/24 destek” yazılarak. Destek saatinden çok, arızanın hangi sürede çözüleceği önemlidir; ikisi farklı taahhütlerdir.

Bölüm 9: Test ve kabul kriterleri

Ne yazılır: Sistemin hangi koşulda kabul edilmiş sayılacağı. Ölçülebilir olmalı: belirlenen senaryoların tamamının hatasız çalışması, belirli bir hacimde performans testinin geçilmesi, kullanıcı eğitiminin tamamlanması.

Nasıl yanlış yazılır: Kabul kriteri hiç yazılmadan. Kriter yoksa proje “bitmiş” sayılamaz; ödeme ve sorumluluk tartışması burada başlar.

Şartnamede sık yapılan yedi hata

Son madde özellikle önemlidir. Şartname, mevcut sürecin fotoğrafı değil, olması gereken sürecin tarifi olmalıdır. Sistem kurulumu, süreçleri düzeltmek için elinizdeki en iyi fırsattır; mevcut hâli kopyalamak bu fırsatı harcar.

Şartname hazır — sonra ne oluyor?

1. Tedarikçi listesi kısaltılır. Şartname, sizin operasyonunuza uygun olmayan sağlayıcıları kendiliğinden eler.
2. Teklifler aynı yapıda istenir. Her madde için “standart / geliştirme ile / kapsam dışı” cevabı ve geliştirme kalemlerinin ayrı fiyatlandırması.
3. Demolar aynı senaryo üzerinden izlenir. Şartnamedeki üç-dört kritik akış, her tedarikçiye aynı şekilde yaptırılır. Hazır demolar karşılaştırma değil, tanıtımdır.
4. Geliştirme kalemleri ayrıca değerlendirilir. Düşük lisans bedeli, yüksek geliştirme kalemiyle birleştiğinde ucuz olmaktan çıkabilir.
5. Şartname sözleşme ekine girer. Yazılı olmayan hiçbir beklenti sonradan talep edilemez.

Sık sorulan sorular

Şartnameyi tedarikçi hazırlayabilir mi?

Hazırlayabilir ama o belge şartname değil, teklif kapsamı olur. Tedarikçinin hazırladığı belge doğal olarak kendi ürününün yapabildiklerini tarif eder; yapamadıklarını kapsam dışı bırakır. Karşılaştırma amacı taşıyan bir belgenin, karşılaştırılacak tarafların dışında hazırlanması gerekir.

WMS şartnamesi ne kadar uzun olmalı?

Uzunluk hedef değildir; süreç tanımlarının eksiksiz olması hedeftir. Tek depolu, sınırlı SKU’lu bir operasyonda kısa bir belge yeterli olabilir; çok kanallı ve parti takibi gerektiren bir operasyonda süreç bölümü tek başına uzar. Ölçüt şudur: bir tedarikçi belgeyi okuduğunda size soru sormadan teklif verebiliyor mu?

Süreçlerimiz yazılı değil, ne yapmalıyız?

Şartname yazmadan önce süreç tanımı yapılmalıdır. Bu, projenin ertelenmesi değil, en riskli kısmının öne alınmasıdır. Süreçler yazılmadan seçilen sistem, kurulum sırasında tanımlanmaya çalışılır — en pahalı ve en yavaş yöntem budur.

Küçük bir depo için de şartname gerekir mi?

Belgenin adı önemli değil; sorunun cevabı gerekir. Küçük bir operasyonda birkaç sayfalık bir süreç tanımı ve kabul kriteri listesi yeterlidir. Şartnamesiz alınan sistemlerde beklentiyle teslim edilen arasındaki fark, depo büyüklüğünden bağımsız olarak aynı sorunu üretir.

Yazılım seçimi ve süreç tasarımının yalın çerçevedeki yeri için Yalın Enstitü’nün yalın depo yönetimi derlemesine bakılabilir.