WMS Projesi Neden Başarısız Olur?

WMS projeleri nadiren “battı” denerek biter. Çoğu, canlıya alınır, kısmen kullanılır, bir bölümü Excel’e geri döner ve birkaç ay sonra kimse projenin hedefine ulaşıp ulaşmadığını konuşmaz. Başarısızlık genellikle bu sessiz biçimde olur.

Bu yazı yazılım firmasını suçlamak için değil. Sahada tıkanan projelerin nedenleri neredeyse her zaman iki taraflıdır: işletmenin hazırlamadığı bir girdi ile tedarikçinin sormadığı bir soru aynı noktada buluşur. Aşağıdaki sekiz nedenin her birini bu ikili çerçevede ele alıyoruz.

Başarısızlık neye benziyor?

• Sistem canlıda ama stok doğruluğu projeden önceki seviyede
• Kullanıcılar terminali kullanıyor, kararları hâlâ kâğıda bakarak veriyor
• Bazı süreçler sistemde, bazıları paralel Excel’de yürüyor
• Raporlar üretiliyor ama hiçbir toplantıda açılmıyor
• Devreye alma tarihi üçüncü kez ertelendi ve neden ertelendiği tartışmalı
• Sistemi “düzeltmek” için sürekli ek geliştirme talebi çıkıyor

Bir WMS projesi, yazılım çalıştığı için başarılı sayılmaz; karar biçimi değiştiği için başarılı sayılır.

Neden 1: İhtiyaç analizi yapılmadan başlamak

İşletme tarafında: Projeye “dijitalleşmek” ya da “rakipler aldı” gerekçesiyle başlanır. Çözülecek somut problem ve başarı ölçütü tanımlanmaz.

Tedarikçi tarafında: Satış süreci, problemi sorgulamak yerine ürünün yapabildiklerini anlatmak üzerine kurulur.

Erken uyarı: Projenin başarısının nasıl ölçüleceği sorulduğunda net bir cevap çıkmıyorsa.

Neden 2: Süreçlerin tanımsız olması

İşletme tarafında: Süreçler kişiye bağlı yürür. “Biz böyle yapıyoruz” cümlesinin arkasında yazılı bir akış yoktur; farklı vardiyalar farklı çalışır.

Tedarikçi tarafında: Süreç tanımı olmadan kurulum başlatılır; eksikler analiz toplantılarında doldurulmaya çalışılır ve her toplantı yeni bir geliştirme talebi üretir.

Erken uyarı: Kurulum başladıktan sonra hâlâ “bu durumda ne yapıyoruz?” sorusu soruluyorsa.

İlgili: süreçlerin şartnamede nasıl tarif edildiği →

Neden 3: Veri kalitesi

İşletme tarafında: Ürün ana verisi eksik veya yanlıştır — barkodsuz kalemler, hatalı birim dönüşümleri, boyut ve ağırlık bilgisi olmayan ürünler. Mevcut stok da gerçeği yansıtmaz.

Tedarikçi tarafında: Veri hazırlığının kimin işi olduğu sözleşmede net değildir; “müşteri verecek” varsayılır ve hangi formatta, hangi kalite eşiğinde verileceği yazılmaz.

Erken uyarı: Test ortamına yüklenen veriyle gerçek operasyon arasında fark çıkmaya başladıysa.

Bu, projelerde en sık gecikme üreten kalemdir ve tamamen yazılımın dışındadır. Veri temizliği projeden önce başlatılmalıdır.

Neden 4: Entegrasyon sınırlarının belirsizliği

İşletme tarafında: Stok gerçeğinin hangi sistemde tutulacağı kararı verilmemiştir. ERP ve WMS aynı veriyi farklı anlarda farklı gösterir.

Tedarikçi tarafında: İki ayrı tedarikçi varsa, arayüzün sorumlusu isimlendirilmemiştir. Hata durumunda her iki taraf da diğerini işaret eder.

Erken uyarı: “Bu bizim tarafımızda görünmüyor” cümlesi toplantılarda tekrarlanmaya başladıysa.

Neden 5: Kullanıcı kabulü ve eğitim

İşletme tarafında: Saha ekibi projeye tasarım aşamasında dahil edilmez; sistem hazır olunca “kullanın” denir. Yeni sistem, işini bilen bir çalışanın hızını başlangıçta düşürür — bu normaldir ama beklenmiyorsa direnç üretir.

Tedarikçi tarafında: Eğitim tek seferlik ve teorik yapılır; devreye alma sonrası saha desteği planlanmaz.

Erken uyarı: Terminal kullanılıyor ama yanında kâğıt liste de taşınıyorsa.

Neden 6: Kapsam kayması

İşletme tarafında: Proje sırasında “madem sistem kuruyoruz” diye yeni talepler eklenir. Her ek talep takvimi uzatır, uzayan takvim motivasyonu düşürür.

Tedarikçi tarafında: Ek talepler kapsam değişikliği olarak yazılı hale getirilmez; takvim etkisi konuşulmadan kabul edilir.

Erken uyarı: İlk kapsam listesiyle güncel liste arasındaki fark kimse tarafından takip edilmiyorsa.

Neden 7: Proje yönetimi ve karar mekanizması

İşletme tarafında: Projenin tam yetkili bir sahibi yoktur; kararlar birkaç departman arasında dolaşır. Depo, satın alma, bilgi işlem ve satış farklı şeyler ister.

Tedarikçi tarafında: Karar bekleyen konular listelenmez; bekleyen karar sessizce takvimi tüketir.

Erken uyarı: Aynı konu üç toplantıdır kapanmadan devrediliyorsa.

Neden 8: Devreye alma planının eksikliği

İşletme tarafında: Geçişin hangi gün, hangi sırayla, hangi stok durumuyla yapılacağı planlanmaz. İlk haftanın ek iş gücü ihtiyacı hesaba katılmaz.

Tedarikçi tarafında: Geri dönüş senaryosu hazırlanmaz. Sistem beklenmedik bir davranış gösterdiğinde operasyonun nasıl devam edeceği belirsizdir.

Erken uyarı: Devreye alma tarihi belli ama geçiş planı yazılı değilse.

Erken uyarı işaretleri

Duran bir proje kurtarılabilir mi?

Çoğu durumda evet — ama kurtarma, kaldığı yerden devam etmekle olmaz. İşleyen yol şudur:

1. Durun. Yeni geliştirme talebi almayı geçici olarak kesin. Hareket halindeyken teşhis yapılamaz.
2. Hedefi yeniden yazın. Bu proje hangi somut sonucu üretecekti? Ölçülebilir tek cümleyle.
3. Kapsamı daraltın. Tek bir süreci — genelde mal kabul veya toplama — eksiksiz çalışır hale getirin. Kısmi çalışan beş süreç yerine tam çalışan bir süreç.
4. Veriyi düzeltin. Ana veri ve adres yapısı temizlenmeden hiçbir süreç güvenilir çalışmaz.
5. Kabul kriteri koyun. Ne olursa “bu süreç bitti” diyeceğinizi yazın.
6. Sonra genişletin. Bir süreç sağlam çalıştığında ikincisi belirgin şekilde kolaylaşır.

Sık sorulan sorular

Yanlış yazılım mı seçtik?

Bazen evet, ama istatistiksel olarak daha nadir. Duran projelerin büyük kısmında yazılım, tanımlanmamış bir sürecin üzerine kurulduğu için çalışmaz. Yazılımı değiştirmek, aynı tanımsızlığı yeni bir sistemle tekrar yaşamakla sonuçlanabilir. Teşhis yapılmadan sistem değiştirmek en pahalı seçenektir.

Tedarikçiyle ilişki bozuldu, ne yapmalı?

Tartışmayı kişilerden çıkarıp belgeye taşımak işe yarar: kapsamda ne vardı, ne eklendi, hangi karar ne zaman verildi, hangi girdi kimden bekleniyor. Çoğu anlaşmazlık, iki tarafın farklı şeyi hatırlamasından kaynaklanır. Yazılı bir kapsam ve karar listesi, ilişkiyi yeniden çalışır hale getirir.

Devreye alma sırasında verim düşmesi normal mi?

Evet, ve planlanması gerekir. Yeni sistemle çalışan bir ekip ilk günlerde daha yavaştır; bu öğrenme eğrisidir. Sorun, düşüşün olması değil, beklenmemesidir. İlk hafta için ek iş gücü planlanmadığında bu normal düşüş kriz gibi yaşanır ve sisteme güven ilk günden zedelenir.

Projeye başlamadan riski nasıl azaltırız?

Üç şeyi projeden önce bitirin: süreçlerin yazılı tanımı, ürün ana verisinin temizliği ve başarı ölçütünün tek cümlelik tanımı. Bu üçü hazırsa, tedarikçi kim olursa olsun proje belirgin şekilde daha az riskli ilerler.

Süreç disiplininin sistemle ilişkisi için Yalın Enstitü’nün yalın depo yönetimi derlemesine bakılabilir.