Sistemdeki rakamlara kimse güvenmiyorsa sorun yazılımda değildir.

Bunlar tanıdık geliyor mu?

• Stok bakiyeleri eksiye düşüyor, sayım hiçbir zaman tutmuyor
• Aynı malzeme için birden fazla stok kodu dolaşıyor
• Yıllardır hareket görmemiş yüzlerce ölü kod listeyi şişiriyor
• Reçeteler eksik ya da güncel değil, ürün maliyeti alınamıyor
• Maliyet hesabı ERP'de değil, birinin Excel dosyasında duruyor
• Fiyat teklifleri tahminle veriliyor
• Satın alma ne zaman ne alacağını sistemden göremiyor

Bunların hepsi tek bir sonuca çıkıyor: firma, maliyetini bilmeden üretiyor.

Bu neden oluyor?

ERP kurulurken mevcut stok listesi olduğu gibi sisteme aktarılır. O liste zaten Excel'de yıllar içinde birikmiştir; içinde mükerrer kayıtlar, tutarsız tanımlar ve artık kullanılmayan kalemler vardır. Yazılım bu veriyi sorgulamaz, aynen kabul eder. Kurulumun ilk gününden itibaren sistem bozuk veriyle çalışmaya başlar.

İkinci sorun kayıt akışıdır. Çıkış kaydı kolaydır, çünkü malzeme alınmadan üretim yürümez. Giriş kaydı ise sonraya bırakılır. Zamanla bakiye gerçekten uzaklaşır, insanlar sisteme güvenmeyi bırakır ve kendi Excel dosyalarını tutmaya başlar. Bu noktadan sonra ERP resmî kayıt, Excel ise gerçek kayıt olur.

Üçüncü sorun reçetedir. Reçete elle yazıldığında bir malzeme atlanır, bir revizyon işlenmez, bir fire oranı girilmez. Maliyet reçeteden hesaplandığı için çıkan rakam gerçeği yansıtmaz. Kimse güvenmediği için de kimse kullanmaz.

Ne yapıyorum?

Önce tablo, sonra müdahale

İlk aşamada hiçbir şeye dokunulmaz. Kaç kod ölü, kaç bakiye eksi, hangi kalemler mükerrer, hangi reçeteler eksik; bunlar sayıyla ortaya konur. Çoğu firma bu tabloyu ilk kez görür.

Bu aşamanın zor tarafı raporu üretmek değil, neyin gerçekten sorun olduğunu ayırmaktır. Bazı eksi bakiyeler kayıt gecikmesidir, ertesi gün kapanır. Bazıları ise yılların birikmiş açığıdır. İkisi aynı ekranda aynı görünür, aynı şekilde ele alınırsa iş büyür ve boşa gider.

Neyin birleştirileceğine karar vermek

Mükerrer kaydı görmek zor değildir; hangisinin birleştirilebileceğine karar vermek zordur. İki kod aynı malzemeyi gösteriyor olabilir, ama farklı reçetelerde geçiyordur, farklı tedarikçiye bağlıdır, geçmiş hareketleri ve maliyet kayıtları ayrıdır. Yanlış birleştirme dağınık listeden pahalıya mal olur, üstelik geri dönüşü zordur.

Bu yüzden temizlik topluca değil, sınıflandırarak yapılır: hangisi güvenle birleşir, hangisi sadece pasife alınır, hangisine hiç dokunulmaz. Kararın gerekçesi kayda geçer, böylece altı ay sonra "bu neden böyle yapılmış" sorusunun cevabı vardır.

Ardından kod açma kuralı tanımlanır: kim, hangi durumda, hangi yapıda kod açar. Kural konmazsa temizlik birkaç ay içinde tekrar bozulur. İşin kalıcı olan tarafı burasıdır.

Reçetenin çizimden beslenmesi

Reçete elle yazıldığı sürece eksik kalır; bu bir dikkat meselesi değil, hacim meselesidir. Çözüm, reçetenin tasarım tarafındaki ürün ağacından beslenmesidir. Tasarım tarafının kendi düzeni de bu işin bir parçasıdır; o konuyu tasarım merkezi ve mühendislik süreçleri sayfasında ayrıca anlattım.

Buradaki asıl mesele aktarımın kendisi değil, iki tarafın aynı şeyi kastetmesidir. Tasarım ağacındaki bir kalem üretimde her zaman bir stok kalemine karşılık gelmez; bazı parçalar birleşiktir, bazıları satın alınır, bazıları hiç stoklanmaz. Bu eşleşme kurulmadan yapılan otomatik aktarım, elle yazmaktan daha fazla hata üretir. Önce eşleşme kuralları tanımlanır, aktarım ondan sonra kurulur.

Maliyetin veriye oturması

Reçete doğru olduğunda ürün maliyeti hesap değil, sonuç haline gelir. Fiyat teklifi artık sistemdeki rakamla verilir.

Bu aşamada genellikle rahatsız edici bir şey ortaya çıkar: bazı ürünlerde kâr sanıldığı kadar değildir, bazılarında hiç yoktur. Rakamın güvenilir olması, verdiği cevabın hoşa gideceği anlamına gelmiyor. Ama körlemesine yönetmenin alternatifi de bu.

Yeni ERP kuruyorsanız

En doğru zaman budur. Stok listesi ve kod yapısı sisteme aktarılmadan önce düzeltilirse, kurulumdan sonra yıllarca uğraşacağınız sorunların çoğu hiç oluşmaz. Bozuk veriyle başlayan bir kurulum, en pahalı yazılımla bile rafta kalır.

Sisteminiz yıllardır çalışıyorsa

Geç değildir. Veri düzeltme işi üretim akışının dışında yürür, ekibin günlük işi durmaz. Çalışma parça parça devreye alınır; her aşamada elinizde çalışan bir sonuç olur, sonunda topluca teslim edilen bir proje değil.

Neden bağımsız bir danışman?

Yazılım satmıyorum, hiçbir firmadan lisans komisyonu almıyorum. Bu, mevcut ERP'nizi savunmak ya da yenisini satmak gibi bir çıkarım olmadığı anlamına geliyor. Elinizdeki sistem yeterliyse onu işler hale getiririm; yetmiyorsa bunu açıkça söylerim.

ERP'nin tablosunu da okurum, tezgah başındaki ustanın o veriyi neden girmediğini de bilirim. Sorun çoğu zaman yazılımda değil, saha ile sistem arasındaki kopukluktadır.

Sık sorulan sorular

Murat Özdemir — İzmir merkezli bağımsız süreç danışmanı. Kurulu kalıp çalışmayan sistemleri sahada, firmanın kendi ekibiyle birlikte işler hale getiriyorum. Genellikle 20-500 kişilik üretim firmalarıyla çalışıyorum. Hakkımda · Nasıl çalışırız · Tasarım merkezi süreçleri

Birlikte çalıştığım firmalardan bazıları

★★★★★

Beraber çalışma fırsatımız oldu. Reçeteler manuel hazırlanıyordu ve sürekli farklılıklar çıkıyordu. CAD ortamından otomatik reçete çıkaran yapıyı kurdu, operasyonel iş akışlarını düzenledi. En değerlisi de şu. Kurduğu sistem o gittikten sonra da çalışmaya devam etti.

Önder Şenli

★★★★★

Ürünlerin hammadde, yarı mamul ve mamul bazında doğru kodlanması, bu yapının ERP sistemi içerisinde etkin şekilde kurgulanması ve süreçlere uygulanması konusunda beklentilerimizi karşıladı. Ekstralardan kaçmayarak, isteklerimize cevap veren Murat Özdemir'e teşekkür ederim.

Akın Budakoğlu

Google işletme profilinde bırakılan değerlendirmelerdir.

Proje içerikleri firmalara özeldir. Referans görüşmesi talep edebilirsiniz.