WMS Danışmanlığı ve Dijital Lojistik

WMS, RFID ve otomasyon güçlü araçlardır; ancak yanlış tasarlanmış bir süreci hızlandırmaktan başka bir şey yapmazlar. Teknoloji yatırımından önce sürecin doğru kurgulanıp kurgulanmadığına bakıyor, yatırımın operasyonunuza sağlayacağı gerçek katkıyı hesaplıyoruz.

Hiçbir WMS, ERP, otomasyon veya donanım markasının bayisi, bayi adayı ya da iş ortağı değiliz; herhangi bir tedarikçiden satış komisyonu almıyoruz. WMS danışmanlığı bizim için yazılım satmak değil alıcı tarafında durmak demek: WMS gereksinim analizi yapmak, WMS şartnamesi hazırlamak, teklifleri aynı kriter setiyle karşılaştırmak ve devreye alma sürecinde işvereni temsil etmek. WMS seçim danışmanlığının yanında barkod ve RFID altyapısı, el terminali seçimi ve raporlama tarafını da aynı dijital lojistik bakışıyla ele alıyoruz.

Bu hizmet kimin için?

• WMS almayı planlıyorsunuz ama hangi özelliklerin gerektiğini bilmiyorsunuz
• Mevcut WMS’ten beklenen fayda alınamıyor
• Otomasyon teklifleri geldi, yatırımın geri dönüşünden emin değilsiniz
• Raporlama Excel’de yapılıyor ve güncel değil

Çalışma kapsamı

WMS almadan önce cevaplanması gereken sorular

Yazılım seçimi, aslında seçimden çok önce başlar. Bir WMS projesinin başarısız sayılmasının en yaygın nedeni yanlış ürün seçilmesi değil, neye ihtiyaç duyulduğunun projeye başlamadan önce tanımlanmamış olması. Aşağıdaki üç soru, teklif toplamadan önce netleşmesi gereken başlıklar.

Süreçler yazılımı taşıyacak olgunlukta mı?

WMS, lokasyon disiplini üzerine kurulur. Ürünlerin adreslenmediği, barkodun okunmadığı, mal kabulde sayımın yapılmadığı bir operasyonda yazılım ancak mevcut belirsizliği kayıt altına alır. Olgunluk değerlendirmesinde adresleme yapısına, barkod kapsamına, işlem kayıt disiplinine ve veri kalitesine bakıyoruz. Eksikler varsa bunları yazılımdan önce mi sonra mı kapatmanın daha az maliyetli olduğunu birlikte karara bağlıyoruz.

ERP’nin depo modülü yeterli olabilir mi?

Her operasyon ayrı bir WMS gerektirmiyor. Sipariş satır sayısı sınırlı, ürün çeşidi az ve akış görece basitse mevcut ERP’nin depo modülü barkod desteğiyle birlikte yeterli olabiliyor. Ayrı bir WMS’i gerektiren şey genellikle hacim değil, karmaşıklık: parti ve miad takibi, çoklu toplama yöntemleri, dalga planlama, seri numarası, iade akışı ve çok sayıda eşzamanlı kullanıcı. Bu değerlendirmeyi yapmadan teklif toplamak, gereğinden büyük bir çözüme ödeme yapmaya yol açıyor.

Hangi işlev zorunlu, hangisi iyi olurdu?

İhtiyaç listesi hazırlanırken her istek aynı ağırlıkta yazıldığında, teklifler de karşılaştırılamaz hale geliyor. İşlevleri üçe ayırıyoruz: onsuz operasyonun yürümediği zorunlu işlevler, kazanç sağlayan ama vazgeçilebilir işlevler ve bugünkü operasyonun ihtiyaç duymadığı işlevler. Bu ayrım hem şartnameyi hem de bütçeyi belirleyen asıl adım.

Gereksinim dokümanı ve şartname nasıl kurulur?

Şartname, tedarikçilere ne istediğinizi anlatan ve tekliflerin aynı zeminde karşılaştırılmasını sağlayan belgedir. İyi bir şartname ürün özelliği listesi değil, operasyonun senaryolarını tarif eder: bir iade nasıl işlenecek, parti takibi hangi noktada devreye girecek, sayım sırasında operasyon duracak mı. Aşağıdaki başlıklar, hazırladığımız gereksinim dokümanının ana bölümleri.

Puanlama şartnameden önce belirlenir

Kriter ağırlıkları teklifler geldikten sonra belirlenirse, seçim farkında olmadan gelen tekliflere göre şekilleniyor. Ağırlıkları şartnameyle birlikte, teklif toplanmadan önce belirliyoruz. Böylece karar hem savunulabilir oluyor hem de şirket içinde farklı beklentisi olan bölümler arasındaki tartışma teklif aşamasına taşınmıyor.

Tedarikçi karşılaştırması ve demo

Demo, tedarikçinin ürününü en iyi gösterdiği senaryodur; bu haliyle karşılaştırma değeri sınırlıdır. Karşılaştırmayı anlamlı kılan şey, aynı senaryoyu tüm adaylara uygulamak ve senaryoyu kendi operasyonunuzdan seçmek.

Entegrasyon, SLA ve devreye alma

Projelerin zorlandığı yer genellikle yazılımın kendisi değil, çevresiyle kurduğu bağlantılar ve canlıya geçiş haftası oluyor. Bu iki başlık sözleşme imzalanmadan netleşmezse, sonradan yapılan her tanım ek maliyet olarak geri dönüyor.

Entegrasyon noktaları baştan sayılmalı

ERP ile stok ve sipariş senkronizasyonu, e-ticaret siparişlerinin akışı, kargo firmalarıyla barkod ve takip bağlantısı, üretim veya muhasebe tarafındaki kayıtlar. Her bağlantı için yön, sıklık ve hata durumunda ne olacağı tanımlanmalı. Özellikle hata senaryosu çoğu şartnamede atlanıyor: aktarım başarısız olduğunda kim haberdar oluyor, işlem tekrar mı ediliyor, operasyon bu sırada nasıl devam ediyor?

SLA’da hangi maddelere bakılır?

Destek anlaşmasında bakılacak başlıklar: destek saatleri ve vardiya kapsamı, olay önceliklendirmesi, ilk yanıt ve çözüm süreleri, kritik arıza tanımı, sistem erişilebilirlik taahhüdü, yedekleme ve geri dönüş süresi, sürüm yükseltmelerinin kapsamı ve verilerinizin size ait olduğunu belirten madde. Gece vardiyasıyla çalışan bir depo için destek saatlerinin operasyon saatlerini kapsaması, çoğu teknik özellikten daha kritik.

Veri hazırlığı ve test

Devreye alma öncesinde ürün ana verisi, birim dönüşümleri, lokasyon yapısı ve açılış stoğu hazırlanmalı. Bu iş çoğunlukla işveren tarafındadır ve küçümsendiğinde projenin en büyük gecikme kaynağı olur. Test aşamasında ise gerçek senaryoların, gerçek kullanıcılarla ve mümkünse gerçek hacimle denenmesi gerekir; kabul kriterleri test başlamadan yazılı olmalı.

Canlıya geçiş haftası

Geçiş tarihi operasyonun en yoğun dönemine denk getirilmemeli. Geçiş planında sayım ve açılış stoğunun ne zaman dondurulacağı, ilk günlerde hangi işlemlerin çift kayıt yürüyeceği ve sorun çıkarsa geri dönüş senaryosunun ne olduğu yazılı olmalı. Bu hafta boyunca sahada karar verebilecek bir sorumlunun bulunması, planın kendisi kadar önemli. Satın alma sürecinin operasyon tarafındaki karşılığını WMS alacağım başlığında özetledik.

Nasıl çalışıyoruz, ne teslim ediyoruz?

1. Süreç olgunluk değerlendirmesiTeknolojiye hazır olup olmadığınızın objektif ölçümü
2. İhtiyaç listesiZorunlu, faydalı ve gereksiz özelliklerin ayrıştırılması
3. Tedarikçi karşılaştırmaAynı kriter setiyle tekliflerin puanlanması
4. FizibiliteYatırımın geri ödeme süresi ve ROI hesabı
5. Devreye alma desteğiVeri hazırlığı, test senaryoları ve kullanıcı eğitimi

Teslim ettiklerimiz

Takip ettiğimiz göstergeler

Yazılım projesinin başarısı canlıya geçiş tarihiyle değil, operasyonun göstergelerindeki değişimle ölçülür. Geçiş öncesi ve sonrası aynı göstergeleri izliyoruz.

Sık sorulan sorular