Zincir marketler için karar yazılımı

Stok yönetim programı seçerken demo neyi göstermez

Yazılım seçimi süreçlerinin çoğunda aynı şey oluyor: dört firma demo yapıyor, dördü de etkileyici görünüyor, karar fiyata ya da kimin daha güven verdiğine kalıyor. İki yıl sonra sistemin neden beklentiyi karşılamadığı konuşulurken ortaya çıkan sorunların neredeyse hiçbiri demoda görülebilecek şeyler değildi. Bu yazıda demoda görünmeyen ama kurulumdan sonra her gün karşınıza çıkacak beş konuyu ve bunları demoda nasıl sınayacağınızı anlatıyorum.

Demo kendi verisiyle çalışır

Demo ortamındaki veri temizdir: ürün kodları tekil, barkodlar eşleşmiş, birim tanımları tutarlı, geçmiş hareketler eksiksiz. Sizin verinizde bunların hiçbiri garanti değildir.

Gerçekte olan şudur: aynı ürün iki farklı kodla açılmıştır, bir kısım barkod tedarikçiden gelmiştir ve çakışır, koli ile adet birimi bazı kayıtlarda karışmıştır, üç yıl önceki hareketlerin bir bölümü eksiktir. Bu koşullarda demo ekranındaki hiçbir rapor aynı görünmez.

Sınama yolu basit: demoyu kendi ürün listenizden bir örnekle isteyin. Beş yüz kalemlik gerçek bir kesit, hangi alanların boş kalacağını ve hangi eşleştirmenin elle yapılması gerektiğini demo aşamasında gösterir. Bunu vermeyen ya da 'kurulumda hallederiz' diyen bir sağlayıcı, işin en pahalı kısmını sözleşme sonrasına bırakıyor demektir.

Sorulacak asıl soru: bu rakam nerede hesaplanıyor

Ekranda bir devir hızı görüyorsunuz. Sorun şu: bu sayı nerede üretildi. Üç ihtimal var ve üçünün sonucu farklı.

Birincisi, sayı veritabanında tanımlı bir yordamla hesaplanmıştır. Bu durumda aynı soru iki kez sorulduğunda aynı cevap gelir ve hesap denetlenebilir. İkincisi, rapor aracının içinde bir formülle hesaplanmıştır; o zaman formül rapordan rapora değişebilir ve iki ekran farklı sayı gösterebilir. Üçüncüsü, sayı uygulama katmanında kod içinde üretilmiştir; bu en kırılgan olanıdır, çünkü hesabı görebilmek için kaynak koda bakmak gerekir.

Demoda bunu sınamanın yolu şu soruyu sormaktır: 'Bu sayının formülünü ve hangi tablodan geldiğini yazılı olarak alabilir miyim.' Cevap gecikirse ya da 'sistem hesaplıyor' olursa, kurulumdan sonra aynı belirsizlikle yaşayacaksınız.

Geçmiş değişince ne oluyor

Perakendede maliyet düzeltmesi kuraldır, istisna değil. Navlun faturası mal girdikten üç hafta sonra gelir, tedarikçi fiyat farkı keser, iade geçmiş bir partiye işlenir.

Kritik soru şu: bu düzeltme geçmiş raporu değiştiriyor mu, değiştiriyorsa haber veriliyor mu. Bazı sistemler düzeltmeyi sessizce geriye işler; geçen ayın marjı bir gecede değişir ve kimse fark etmez. Bazıları hiç işlemez; bu sefer de geçmiş yanlış kalır.

Doğru davranış ikisi de değildir: düzeltme ayrı bir hareket tipi olarak yazılır, ait olduğu dönem ile işlendiği tarih iki ayrı alanda tutulur ve rapor yeniden basıldığında farkın nedeni satır bazında görülebilir. Demoda bunu sınamak için geçmiş bir alıma masraf ekletin ve raporun ne yaptığına bakın.

Tanımı kim sahipleniyor

Sistem kurulduktan sonra mutlaka şu olur: iki departman aynı metrik için farklı sayı görür ve tartışma başlar. Bu kaçınılmazdır; önemli olan tartışmanın nasıl bittiğidir.

Tanım sözlüğü olan bir kurulumda tartışma beş dakikada biter: sözlüğe bakılır, hangi ekranın hangi tanımı kullandığı görülür, gerekirse tanım değiştirilir ve değişiklik her yere yansır. Sözlük yoksa tartışma her ay tekrar eder.

Demoda sorulacak soru: 'Metrik tanımları nerede duruyor, kim değiştirebiliyor ve değiştiğinde geçmiş raporlar ne oluyor.' Bu sorunun cevabı, sistemin iki yıl sonra hala güvenilir olup olmayacağını demodaki hiçbir ekrandan daha iyi anlatır.

Sayım ve saha tarafı

Stok yazılımının en çok kullanılan parçası, ofiste değil depoda ve mağazada çalışan parçasıdır. Buna rağmen demoların çoğu masaüstü ekranlar üzerinden yapılır.

Depoda ağ her yerde yoktur. Raf aralarında, soğuk hava deposunda ve bodrum katlarda sinyal düşer. Bağlantı koptuğunda sayımın durup durmadığı, kayıtların cihazda tutulup tutulmadığı ve bağlantı gelince ne olduğu demoda sorulmalıdır. 'Wi-Fi güçlendirin' cevabı bir mimari cevabı değildir.

İkinci soru senkron davranışıdır: aynı okuma iki kez gönderilirse sistem ne yapar. Çevrimdışı çalışan bir uygulamada bu durum kural olarak oluşur; tekrarı eleyemeyen bir senkron, sayım sonuçlarını sessizce şişirir.

Ne zaman program almayın

Mevcut sorun veri değil süreçse yazılım onu çözmez. Sayım altı ayda bir yapılıyorsa ve kimse fark raporunu incelemiyorsa, yeni bir sistem aynı raporu daha güzel bir ekranda gösterir.

Aynı şekilde, ürün kodları henüz tekilleştirilmemişse kuruluma başlamak erkendir. Bu iş sağlayıcıya devredilebilir ama sizin tarafınızda karar verecek birinin olması gerekir: hangi kodun kalacağına ancak ürünü bilen kişi karar verebilir.

Üçüncü durum kapasitedir. Kurulum, sizin tarafınızdan süreçleri bilen ve ekibimizle birlikte çalışacak bir sorumlu ister. O kişi yoksa proje teknik olarak tamamlanır, kullanımda kalmaz.

Ne yapmalı

Demoyu kendi verinizden bir kesitle isteyin. Hangi alanların boş kaldığını görmeden alınan karar, işin en pahalı kısmını sözleşmeden sonraya bırakır.

Üç soruyu yazılı sorun: bu rakam nerede hesaplanıyor, geçmiş düzeltme nasıl işleniyor, tanım nerede duruyor. Üçünün de yazılı cevabı olan bir sağlayıcı, ekran sayısı daha az olsa bile daha güvenli bir seçimdir.

Saha tarafını masaüstünden değerlendirmeyin. Sayımın çevrimdışı davranışını ve tekrar eden okumanın ne olduğunu sorun; bu iki soru depoda geçirilecek yılları belirler.

Kendi verinizle görün.