Yan sanayide yazılım kararı çoğu zaman içeriden değil, dışarıdan geliyor. Ana sanayi bir şey istiyor ve o istek bir yazılım arayışına dönüşüyor.
Bu, kararın başlangıcı olarak makul. Sorun, kararın sonuna kadar aynı yerden gelmesi.
Kısa cevap
Yan sanayide iki ayrı ihtiyaç var ve bunlar aynı şey değil.
Birincisi ana sanayiye karşı yükümlülükler. Sipariş çağrılarının karşılanması, termine uyum, istenen kayıtların sunulabilmesi, denetimde belge çıkarabilmek.
İkincisi işletmenin kendi içindeki kayıp. Hangi işin nerede beklediği, malzemenin ne zaman biteceği, hangi siparişin kârlı olduğu.
Yalnızca birincisine göre seçilen sistem, denetimi geçiriyor ama işletmeye bir şey kazandırmıyor. Yalnızca ikincisine göre seçilen sistem ise ilk büyük denetimde eksik kalıyor.
Doğru soru şu: bu iki ihtiyacın kesiştiği yer neresi ve orada ne var.
Yan sanayiyi diğer üretimden ayıran dört şey
Genel bir üretim yazılımı değerlendirmesi, bu sektörde birkaç noktada yetersiz kalıyor.
Birincisi termin baskısının niteliği. Gecikmenin bedeli, geciken siparişin kendisiyle sınırlı değil. Hattın durması demek olduğunda tablo tamamen değişiyor. Bu yüzden termin görünürlüğü, burada bir rapor konusu değil bir risk yönetimi konusu.
İkincisi talebin dalgalı gelmesi. Sipariş çağrıları değişebiliyor ve bu değişim malzeme tarafına doğrudan yansıyor. Malzeme planı bu dalgalanmayı taşıyamıyorsa, işletme ya fazla stok tutuyor ya da yetişemiyor.
Üçüncüsü izlenebilirlik. Bir parçanın hangi partiden, hangi hammaddeden ve hangi süreçten geçtiğinin sorulabilmesi. Bu soru gelmeyebilir; geldiğinde ise cevabın hazır olması gerekiyor.
Dördüncüsü maliyet tarafındaki hassasiyet. Fiyatlar uzun süreli anlaşmalara bağlı olduğunda, girdi maliyetindeki değişim doğrudan marja yansıyor. Kur tarafındaki etki ayrı bir başlık: dövizli satın alma ve kur farkı.
En pahalı yanlış seçim
Sahada en sık görülen hata, sistemin yalnızca ana sanayinin görmek istediği çıktıya göre seçilmesi.
Bu seçim mantıklı görünüyor çünkü acil olan o. Denetim yaklaşıyor, bir belge isteniyor, sistem o belgeyi üretecek şekilde kuruluyor.
Sonuç şu oluyor: sistem işletmenin günlük işine girmiyor. Kayıtlar, denetim öncesinde toplu girilen kayıtlara dönüşüyor. Bir süre sonra sistemin ürettiği veri, gerçeği değil beyanı anlatıyor.
İkinci pahalı hata, sistemin kapsamının işletmenin kendi büyüklüğüne göre değil, ana sanayinin büyüklüğüne göre seçilmesi. Ana sanayinin kullandığı düzenin küçültülmüş hali, çoğu zaman yan sanayide oturmuyor; kurulum uzuyor ve ekip kullanmıyor.
Hazır paket ile uyarlanmış çözüm arasındaki genel ayrım ayrı bir yazıda duruyor: hazır paket mi uyarlanmış mı.
Seçimde belirleyici dört soru
Değerlendirme listelerinin çoğu özellik sayıyor. Yan sanayide belirleyici olan şey özellik sayısı değil, dört sorunun cevabı.
Sipariş çağrısı değiştiğinde ne oluyor? Sistemin bu değişimi malzeme ve plan tarafına taşıyıp taşımadığı, günlük işi doğrudan etkiliyor.
Termin riski ne zaman görünüyor? Gecikme gerçekleştikten sonra görünen bir sistem, rapor üretiyor ama önlem üretmiyor. Açık siparişlerin ve terminlerin nasıl takip edildiği ayrı bir yazıda anlatılıyor.
Bir parçanın geçmişi kaç dakikada çıkıyor? Bu soru sorulmadan izlenebilirlik iddiası değerlendirilemiyor.
Ve veri kimin? Sistem değiştirmek gerektiğinde geçmiş kayıtların dışa aktarılabilmesi, sözleşme aşamasında sorulacak bir şey.
Tek sistem mi, bağlanan sistemler mi
Yan sanayide sık karşılaşılan bir durum, muhasebe tarafının zaten yerleşik olması ve değiştirilmek istenmemesi.
Bu makul bir tutum. Muhasebe tarafı çalışıyorsa onu değiştirmek, projenin en riskli kısmını gereksiz yere büyütüyor.
Bu durumda karar, her şeyi tek sisteme toplamak ile mevcut sisteme bağlanan bir katman kurmak arasında veriliyor. İkisinin de doğru olduğu durumlar var ve ayrım ERP modülü mü ayrı yazılım mı yazısında ayrıntılı.
Burada sorulacak asıl soru şu: aynı veri iki yere iki kez giriliyor mu? Cevap evetse, hangi mimari seçilirse seçilsin sorun devam ediyor.
Bir yan sanayi firmasında nasıl ilerledi
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
Ana sanayiye parça üreten orta ölçekli bir firma. Arayış, müşterisinin istediği bir izlenebilirlik kaydıyla başladı.
İlk yaklaşım doğrudan o kaydı üretmekti. Bir çözüm bulundu, kuruldu ve istenen belge çıkarılabilir hale geldi. Denetim sorunsuz geçti.
Altı ay sonra durum şuydu: kayıtlar denetim öncesinde toplu giriliyordu ve sistemi gün içinde kimse açmıyordu.
Aynı dönemde firma iki kez termin sıkıntısı yaşadı. İkisinde de sorun, malzemenin zamanında sipariş edilmemesiydi ve ikisinde de eksiklik ancak üretim planlanırken fark edildi.
Bu iki olay kararı değiştirdi. Soru “ana sanayi ne istiyor” olmaktan çıkıp “biz nerede kaybediyoruz” oldu.
Kapsam yeniden kuruldu ve sıralama değişti. Önce malzeme talebi ve sipariş tarafı sisteme alındı; talep açıldığı anda kaydediliyor, sipariş ondan türüyordu. İkinci aşamada açık siparişlerin termin takibi eklendi.
İzlenebilirlik kaydı üçüncü aşamada, ama bu sefer farklı bir yerden geldi: mal kabulde girilen parti bilgisi üretim kaydına bağlandı. Yani belge, ayrı bir iş olarak değil, zaten yapılan işin çıktısı olarak üretilmeye başlandı.
Denetim tarafında değişen bir şey olmadı; aynı belge yine çıkıyordu. Değişen şey, o belgeyi üretmek için kimsenin ayrıca çalışmıyor olmasıydı.
Sırayı belirleyen kural
Bu sektörde işe yarayan tek kural şu: sistemin ürettiği belge, günlük işin yan ürünü olmalı.
Belge üretmek için ayrıca bir iş yapılıyorsa, o iş er ya da geç toplu ve geriye dönük yapılmaya başlanıyor. O andan itibaren kayıt gerçeği anlatmıyor.
Bu yüzden kapsam seçilirken önce günlük işin içinde duran adımlar dijitalleşiyor. Denetim çıktısı, o adımların üzerine kuruluyor.
Akışın nerede tıkandığını görmek için ölçüm de bir seçenek: üretimde iş akışı analizi yazısında konum verisiyle yapılan analiz anlatılıyor.
Codigno tarafında
ERP çözümleri ve satın alma ve lojistik yazılımı tarafında talep, teklif, sipariş, mal kabul ve stok tek zincir olarak kuruluyor. Bu, kademeli geçişi mümkün kılıyor: önce bir adım açılıp oturması bekleniyor, sonrakiler aynı kayıt üzerine ekleniyor.
Muhasebe tarafının yerinde kalması gereken kurulumlarda kapsam buna göre tanımlanıyor; kullandığınız sistemi paylaşırsanız aktarımın kapsamını keşifte netleştirebiliriz.
Üretim tarafındaki genel resim için endüstri ve üretim sayfasına bakabilirsiniz.
Sık sorulan sorular
Ana sanayinin istediği sistemi almak zorunda mıyız?
Genelde istenen şey belirli bir yazılım değil, belirli bir çıktı. Hangisinin istendiği yazılı olarak netleştirilmeli; ikisi karıştırıldığında gereğinden büyük bir karar veriliyor.
Muhasebe programımızı değiştirmek zorunda kalır mıyız?
Zorunlu değil. Asıl sorulacak soru aynı verinin iki yere iki kez girilip girilmediği.
İzlenebilirlik kaydı ayrı bir sistem mi gerektiriyor?
Gerektirmiyor. İşe yarayan kurgu, kaydın günlük işin yan ürünü olarak üretilmesi; ayrı bir iş olarak yapıldığında toplu ve geriye dönük giriliyor.
Nereden başlamak gerekiyor?
Günlük işin içinde duran adımdan. Talep ve sipariş tarafı genelde ilk sırada oluyor; denetim çıktısı onun üzerine kuruluyor.
Termin riskini erken görmek için ne gerekiyor?
Açık siparişlerin ve teslim tarihlerinin tek yerde ve güncel olması. Gecikme gerçekleştikten sonra görünen bir yapı önlem üretmiyor.
Sistem değiştirmek gerekirse verilerimiz ne olacak?
Bu soru sözleşme aşamasında sorulmalı. Geçmiş kayıtların dışa aktarılabilmesi, ileride verilecek kararların tek güvencesi.
Ana sanayinin istediği belge mi, sizin kaybınız mı öncelikli? Sipariş çağrılarının nasıl geldiğini, bugün nerede gecikme yaşadığınızı ve kullandığınız muhasebe sistemini paylaşın; kapsamın nereden başlaması gerektiğini birlikte çıkaralım.
