MRP Sisteminde Üretim Planlama Parametrelerini Nasıl Optimize Edersiniz?

Bursa’da orta ölçekli bir metal işleme atölyesi düşünün. Firma iki yıl önce MRP (Malzeme İhtiyaç Planlaması) yazılımı kurdu. Kurulum sırasında teknik ekip bazı rakamlar girdi: her parça için kaç adet sipariş açılacağı, hammaddenin tedarikçiden kaç günde geleceği, üretimde ne kadar fire çıkacağı. Sistem o günden bu yana çalışıyor. Ama son aylarda depo dolup taşıyor, bazı parçalar ise hiç yetişmiyor. Üretim müdürü bunu anlayamıyor. Sorun yazılımda değil — yazılıma girilen rakamlarda.

MRP sistemi, üretim emirlerini ve satın alma siparişlerini otomatik olarak hesaplar. Bunu yaparken üç temel rakama dayanır. Birincisi parti büyüklüğü: her seferinde kaç adet üretileceği ya da satın alınacağı. İkincisi temin süresi: bir malzemenin tedarikçiden gelmesi ya da üretimde işlenmesi için gereken gün sayısı. Üçüncüsü fire oranı: üretimde beklenen kayıp miktarı. Bu üç rakam kurulum sırasında elle girilir. Yazılım bu rakamları doğru kabul eder ve tüm planlamayı bunların üzerine kurar.

Sorun şu: fabrikada her şey değişir ama bu rakamlar değişmez. Tedarikçi teslimat süresini kısaltmış olabilir. Ya da tam tersi, son krizden sonra süreler uzamış olabilir. Fire oranı makine bakımı sayesinde düşmüş olabilir. Parti büyüklüğü ise belki iki yıl önce mantıklıydı ama şimdi sipariş miktarları farklı. Yazılım eski rakamlarla çalışmaya devam eder. Sonuç: sistem gereğinden fazla malzeme sipariş eder ya da gereğinden az üretim emri açar. Depo gereksiz stokla dolar ya da üretim durur.

Bu durumu bir tarife benzetmek mümkün. Annenizin tarifi diyor ki ‘dört yumurta koy.’ Ama siz iki kişilik pişiriyorsunuz, iki yumurta yeterli. Tarifi değiştirmezseniz her seferinde fazla malzeme harcarsınız. MRP parametreleri de böyle. Gerçekle uyuşmayan her rakam, her üretim döngüsünde küçük bir hata üretir. Tek seferlik bu hatalar önemsiz görünür. Ama yüzlerce parça kalemi, onlarca tedarikçi ve aylarca birikince sonuç büyük olur.

Peki ne yapılmalı? En basit yöntem altı ayda bir parametre gözden geçirmesidir. Bunun için karmaşık bir şeye gerek yok — bir Excel tablosu ve iki saatlik bir toplantı yeterli. Üretim sorumlusu, satın alma sorumlusu ve depo sorumlusu bir araya gelir. Her ana malzeme kalemi için şu sorular sorulur: Son altı ayda tedarikçi gerçekte kaç günde teslim etti? Üretimde fiilen ne kadar fire çıktı? Ortalama sipariş miktarımız değişti mi? Bu soruların cevapları yazılımdaki rakamlarla karşılaştırılır. Fark varsa parametre güncellenir.

Parametre güncellemesinin etkisini ölçmek de zor değil. Yazılım üretim emirlerini açmadan önce ‘öneri’ listesi sunar. Bu listeye bakın: sistem kaç adet sipariş önerdi, siz gerçekte kaç adet açtınız? Aradaki fark büyükse parametreler gerçekle uyuşmuyor demektir. Bazı MRP yazılımları bu karşılaştırmayı raporla da verir. Ama raporun olması şart değil — elle takip de işe yarar. Önemli olan düzenli bakmak ve farkı kayıt altına almaktır.

Bir de şu var: temin süresini güncellerken tek bir tedarikçi deneyimine bakmamalısınız. Geçen ay bir tedarikçi iki haftada getirdiyse bu her zaman böyle olacağı anlamına gelmez. Son altı aya bakın, ortalamayı alın, üstüne küçük bir güvenlik payı ekleyin. Fire oranında da aynı mantık geçerli. Tek bir üretim koşusundan değil, birkaç aylık gerçek veriden hesaplayın. Yazılıma girdiğiniz rakam ne kadar gerçeği yansıtırsa sistem o kadar doğru çalışır.

MRP yazılımı alan bir firma için en kritik karar, yazılımı kurduktan sonra parametreleri unutmamaktır. Kurulum tamamlandı, sistem açıldı, herkes rahat bir nefes aldı — ve parametreler bir daha açılmadı. Bu yaygın bir hata. Yazılım ne kadar iyi olursa olsun, içine girilen rakamlar eskimiş ve yanlışsa üretim planlaması tutarsız çıkar. Altı ayda bir yarım günlük bir gözden geçirme, bu hatayı önler. Bunu bir rutin haline getiren firmalar, depo maliyetlerini düşürür ve üretim aksaklıklarını azaltır. Yazılımın değeri, kurulumda değil — doğru parametrelerle sürekli çalıştırılmasında ortaya çıkar.


canlı geçiş süreci şirketin geçmişini kaydetmek için değil, gelecekteki kararlarını güçlendirmek için tasarlanmalıdır. Doğru mimari; görünürlük, hız, kontrol ve öğrenme kapasitesi üretir. Aksi halde veri toplanır, raporlar çoğalır ama karar kalitesi aynı yerde kalır.


Gökhan Mercanoğlu
ERP ve Kurumsal Yazılım