Yuog Dev
Yuog Dev Yuog Dev Yuog Dev Yuog Dev Yuog Dev Yuog Dev Yuog Dev
0 %
Yükleniyor

Üretim Programı (MRP) Nedir? Reçeteden Maliyete Tam Kontrol

Ürün ağacı, iş emri, kapasite ve fire takibi bir arada kurgulandığında üretim maliyeti tahmin olmaktan çıkar. Üretim programının temel yapı taşlarını anlatıyoruz.

Üretim programı ve MRP rehberi kapak görseli

Üretim yapan işletmelerde en sık duyduğumuz cümle şudur: "Ürünün maliyetini aslında tam olarak bilmiyoruz." Sebep genellikle hesap hatası değil, üretimin adım adım kayıt altına alınmamasıdır. Hammadde depodan çıkar, üç istasyondan geçer, mamul rafına iner. Arada ne kadar fire verildiği, hangi operasyonun ne kadar sürdüğü hiçbir yere yazılmaz. Ay sonunda elde kalan tek veri satın alma faturaları ile satış rakamlarıdır; ikisinin farkına da kâr denir ve hangi üründen geldiği bilinmez. Üretim programı (MRP), tam olarak bu boşluğu kapatır.

Üretim programı neyi kapsar?

Talepten maliyet raporlamasına kadar üretim akışının beş adımı
Talep, reçeteye; reçete iş emrine; iş emri gerçekleşen maliyete dönüşür.

Terimi baştan yerine oturtalım: MRP dar anlamda malzeme ihtiyaç planlamasıdır. Kapasiteyi, işçiliği ve maliyeti de kapsayan geniş yapı literatürde MRP II adıyla geçer; piyasada ikisine birden "üretim programı" deniyor. Ayrım işe yarıyor, çünkü yalnızca malzeme tarafını kuran bir işletme kapasiteyi hâlâ elle yönetiyordur. Program dört bloktan oluşuyor ve dördü birden ayakta değilse zincir bir yerinden kopuyor. Reçete yoksa ihtiyaç hesaplanamaz. İş emri yoksa tüketim bir yere yazılamaz. Saha bildirimi yoksa maliyet plandan ibaret kalır; ölçtüğünüz şey gerçekleşen değil, olması gerekendir.

Ürün ağacı (reçete)

Bir mamulün hangi hammadde ve yarı mamullerden, hangi miktarlarda oluştuğunu tanımlar. Çok kademeli üretimde reçete iç içe geçer: yarı mamulün kendi reçetesi vardır. Fire oranı da burada tanımlanır; aksi hâlde teorik ile gerçek tüketim arasındaki fark hiçbir zaman kapanmaz. Fireyi tek bir ortalama yüzdeyle geçmeyin. Kesim firesi ile boya kaybı aynı davranmaz: biri parti büyüklüğüyle azalır, diğeri yüzey alanına bağlıdır. Reçetenin ikinci sessiz alanı geçerlilik tarihi. Ürün revize edildiğinde eski reçeteyi silmeyin, kapanış tarihi verin. Silinirse geçmiş iş emirlerinin maliyeti bugünkü reçeteyle yeniden hesaplanır; altı ay önce kapanmış bir rakam kimse dokunmadan değişir.

İş emri

Üretilecek miktarı, operasyon sırasını, iş istasyonlarını ve terminleri belirler. İş emri açıldığı anda hammadde ihtiyacı hesaplanır; eksik varsa satın alma talebi doğar. Pratikte en çok tıkanan yer, iş emrini kimin, hangi kontrolden sonra serbest bırakacağının yazılı olmaması. Bir de kapanış tarafı var: sahada bitmiş ama sistemde kapatılmamış iş emri hem tüketimi hem mamul girişini askıda tutar. Ay sonu maliyetinin bir türlü çıkmamasının en sık sebebi de bu.

Kapasite planlama

Makine ve vardiya kapasitesi hesaba girmeden yapılan plan kâğıt üzerinde tutar, sahada tutmaz. Ortalama kapasite yanıltıcıdır; planın üst sınırını en yavaş istasyon çizer. Hesabın girdisi rota süreleridir ve çoğu kurulumda en zayıf veri budur: rotaya yazılan birim süre bir kez ölçülmüş, sonra yıllarca güncellenmemiştir. Darboğazın nasıl bulunduğunu ve terminin arkasındaki hesabı üretim planlama yazısında ele aldık.

Saha bildirimi

Miktar, duruş ve fire sahadan gelmiyorsa yukarıdaki üç blok da havada kalır. Asıl karar, bildirimin hangi seviyede toplanacağı. İş emri bazında tek bildirim en kolayı, ama hangi operasyonun ne kadar sürdüğünü göstermez; kapasite hesabının ihtiyacı olan veriyi hiç üretmez. Operasyon bazında bildirim daha kıymetli, karşılığında sahadan daha fazla giriş ister. Çok istasyonlu hatlarda ikincisi, tek ustanın baştan sona götürdüğü işlerde birincisi oturuyor.

MRP hesabı arka planda ne yapıyor?

MRP özünde tek bir soruyu tekrar tekrar cevaplar: bu malzemeden, hangi tarihte, kaç birim eksiğim var? Girdisi doğrudan müşteri siparişi değil, siparişten ve tahminden çıkarılan ana üretim planıdır; MRP o planı reçeteler üzerinden patlatır. Hesap brüt ihtiyaçtan başlar, eldeki ve yoldaki miktarlar düşülür, kalan net ihtiyaç satın alma ya da üretim önerisine dönüşür. Mahsup tek bir toplam üzerinden değil dönem dönem yapılır; ay toplamında fazlanız varken ayın ikinci haftasında malzemesiz kalabilirsiniz. Aşağıda mamul başına 2 kg sac giden bir ürünün 500 adetlik kırılımı var.

AdımNereden gelir500 adetlik iş emrinde
Brüt ihtiyaçReçete miktarı × üretim miktarı2 kg × 500 = 1.000 kg
Fire payıReçetedeki fire oranı%4 ile 1.040 kg
Eldeki stokDepo bakiyesi300 kg
Rezerve miktarAçık diğer iş emirlerine ayrılmış120 kg, kullanılabilir 180 kg
Yoldaki miktarAçık satın alma siparişi250 kg, 12 gün sonra
Net ihtiyaçFireli ihtiyaç − kullanılabilir − yoldaki610 kg
Sipariş miktarıMinimum sipariş ve paket katı250 kg'lık paketle 750 kg
Sipariş tarihiİhtiyaç tarihi − tedarik − mal kabul12 + 2 gün geriye

Tablonun en çok atlanan iki satırı rezerve miktar ile mal kabul süresi. Rezerve tutulmazsa aynı 300 kiloyu üç ayrı iş emri kendi stoğu sanır; hat ortasında malzeme biter. Mal kabul de anlık değildir: kamyon geldiği gün malzeme üretime hazır olmaz, kalite kontrol ve raf yerleşimi araya girer. Bu süre karta yazılmadığında MRP siparişi hep birkaç gün geç açar, gecikmenin sebebi de tedarikçide aranır.

Fire satırında ayrıca bir yöntem farkı var. Yukarıdaki 1.040 kg, ihtiyacın üzerine %4 eklenerek bulundu; bazı sistemler aynı oranı verim olarak okur ve 1.000 / 0,96 = 1.042 kg der. Tek partide önemsiz bir fark, tonajlı malzemede yıl boyunca birikiyor. Reçetede hangisinin çalıştığını kurulum sırasında öğrenin.

Üretim maliyeti nasıl hesaplanır?

Maliyet kalemiKaynağı
Direkt hammaddeReçete + gerçekleşen tüketim
Direkt işçilikOperasyon süresi × saatlik maliyet
Genel üretim gideriDağıtım anahtarı (makine saati, işçilik saati)
Fire ve yeniden işlemSaha bildirimi

Standart ile gerçekleşen maliyet arasındaki farkı (sapma analizi) düzenli izlemek, fiyatlamayı tahmin olmaktan çıkarır. Ama sapmaya tek rakam olarak bakmak işe yaramıyor. Miktar sapması üretimin işidir: reçetedekinden fazla malzeme gitmiştir, fire yükselmiştir. Fiyat sapması satın almanın işidir; aynı malzeme daha pahalıya girmiştir. İkisi tek satırda toplandığında toplantı "hammadde zamlandı" cümlesinde biter ve kimse fireye bakmaz.

İkinci soru, sapmanın hangi kalemde doğduğu: hammaddede mi, işçilikte mi, yoksa genel üretim giderinin dağıtım anahtarında mı? Anahtar yanlış seçildiğinde hiçbir kalemde hata olmadan maliyet yine tutmaz. Neredeyse tamamı makineyle üretilen bir ürüne işçilik saatinden gider dağıtırsanız o ürün olduğundan ucuz görünür. Birkaç benzer ürünle çalışan atölyede tek anahtar yeter; ürün karması genişledikçe dağıtımı istasyon bazına indirmek gerekiyor.

Fire kaydedilmiyorsa maliyet hesabı her zaman iyimser çıkar. Üretimde en pahalı veri, hiç toplanmayan veridir.

ERP ile ilişkisi: hangi veri nerede yaşar?

Üretim programı, ERP'den bağımsız bir ada olmamalı. Stok ve satın alma ERP'de, üretim planı ve saha bildirimi üretim tarafında yaşar; arada hammadde tüketimi, mamul girişi ve maliyet verisi akar. Kural WMS–ERP entegrasyonundakiyle aynı: her verinin tek bir sahibi vardır.

VeriSahibiKarşı tarafa nasıl geçer
Ürün ve hammadde kartıERPÜretim programı okur, kendi kartını açmaz
Ürün ağacı ve rotaÜretim tarafıERP standart maliyeti buradan hesaplar
Stok bakiyesiERP veya depo sistemiTüketim ve mamul girişi hareket olarak yazılır
Açık satın alma siparişiERPMRP yoldaki miktar olarak okur, ikinci kez sipariş açmaz
İş emri ve saha bildirimiÜretim programıERP'ye sarf fişi ve mamul giriş fişi olarak düşer
Müşteri siparişi ve terminERP veya e-ticaret tarafıMRP talep girdisi olarak alır

Aynı veriyi iki sistemde birden düzenlenebilir tutmak, entegrasyonun en pahalı hatası. Kart hem ERP'de hem üretimde açılabiliyorsa altı ay içinde mükerrer SKU çıkar ve ihtiyaç hesabı tutmaz. Bağlantı da bir gecelik iş değil: hangi fişin hangi tetikle oluşacağı, tekrar gönderimlerin mükerrer kayıt üretmemesi ve hata durumunda kaydın kuyruğa alınması ayrı ayrı kurgulanır. Bu tarafı özel yazılım ve ERP çözümleri başlığı altında yürütüyoruz; gece çalışan ihtiyaç hesabı gibi tekrarlı işler ise zamanlanmış görevlere devrediliyor.

MRP'nin varsayımları sahada nerede kırılır?

Program yanlış sonuç ürettiğinde suç genelde yazılımda aranır. Çoğu durumda kırılan şey, hesabın arkasındaki varsayımlardır.

  • Kapasite sonsuz sayılır: Klasik MRP, ihtiyaç tarihine göre iş emri önerir; o tarihte makinenin dolu olup olmadığına bakmaz. Öneri listesi ancak kapasite kontrolünden geçtikten sonra plan olur.
  • Temin süresi sabit sayılır: Sistemde 12 gün yazan tedarikçi sezonda 20 günde teslim ediyorsa hesap her seferinde geç kalır. Süreyi sözleşmeden değil, son altı ayın gerçek teslimlerinden alın.
  • Stok doğru sayılır: Sayım farkı olan bir depoda MRP yanlış miktarı sipariş eder. Depo tarafı düzelmeden üretim tarafı düzelmiyor; ikisi aynı projenin parçası.
  • Malzemenin tek bir alternatifi varsayılır: 3 mm sac bittiğinde usta eldeki 3,5 mm'yi kesip kullanır. Muadil tanımı sistemde yoksa bu ikame hiçbir yere yazılmaz; o günden sonra hem stok hem maliyet kayar.

Fason çalışan işletmelerde bir varsayım daha devreye giriyor: malzemenin tamamı sizin deponuzda değil. Mülkiyeti sizde, konumu dışarıda olan stok ayrı bir emanet depoda izlenmezse hesap iki yönden bozulur: hiç görünmüyorsa aynı malzeme ikinci kez satın alınır, serbest stok sayılıyorsa elde olmayan miktarla yeni iş emrine söz verilir. Bu akışın nasıl kurulduğunu fason üretim takibi yazısında ayrıca anlattık.

Takip edilecek göstergeler

  • Termin uyumu: Planlanan bitiş tarihinde kapanan iş emirlerinin oranı. Gecikme gün sayısıyla birlikte tutulduğunda anlam kazanır; "geç" ile "üç hafta geç" aynı şey değil.
  • Fire oranı: Ürün ve operasyon bazında kayıp. Tek rakama düşürüldüğünde firenin hangi istasyondan çıktığı görünmez.
  • Kapasite kullanımı: İstasyon bazında boşta kalma ve darboğaz. Kuyrukta bekleyen iş saatiyle birlikte okunmalı.
  • Maliyet sapması: Standart ile gerçekleşen arasındaki fark, miktar ve fiyat ayrımıyla.
  • Yeniden işlem oranı: Bir kez daha operasyona giren mamulün payı. Fireden farklı bir şey söyler; yeniden işlem hem malzemeyi hem darboğaz saatini ikinci kez yer, üstelik çoğu kurulumda hiç kaydedilmez.

Nereden başlamalı?

  1. Ürün ağacını sahayla birlikte çıkarın; ofiste yazılan reçete ilk turda hemen hiç tutmuyor.
  2. Tek bir ürün ailesiyle pilot yapın, ama o ailenin bütün kademelerini kapsayın; yarı mamulü dışarıda bırakan pilot yalnızca kolay kısmı test eder.
  3. Bildirim ekranını tasarlamadan önce iki hafta kâğıtla deneyin; operatörün gerçekten doldurduğu alanlar orada belli oluyor.

Hâlâ tabloyla çalışıyorsanız sıra değişiyor: önce veri temizliği, sonra açılış sayımı. O tarafı Excel'den üretim programına geçiş yazısında yazdık.

MRP'yi çalıştırmadan önce beş parametreyi karara bağlayın

  • Planlama ufku: Hesap kaç hafta ileriyi kapsayacak? En uzun temin süresinin en az iki katı olsun. Kısa tutulan ufukta uzun temin süreli malzeme hep dışarıda kalır; ihtiyaç göründüğünde sipariş çoktan gecikmiştir.
  • Koşu sıklığı: MRP her sipariş girişinde mi, gecede bir mi çalışacak? Gece koşusu daha sakin bir liste üretiyor; gün içinde sürekli değişen öneri ekranını kimse açmıyor.
  • Lot kuralı: Net ihtiyaç kadar mı, sabit partiyle mi, yoksa haftalık ihtiyaçlar birleştirilerek mi sipariş verilecek? Aynı depoda üç kural birden yaşayabilir; ucuz ve hacimli malzemede sabit parti, pahalı olanda ihtiyaç kadar sipariş oturuyor.
  • Emniyet stoğu: Hangi kalemde tutulacak? Hepsinde tutmak sermayeyi rafa bağlar. Temin süresi uzun, tek tedarikçiden gelen ve durduğunda hattı durduran malzemeyle sınırlayın.
  • Önerinin onayı: Çıktı doğrudan satın alma siparişine mi dönüşecek, arada bir kişi onaylayacak mı? İlk altı ay onaysız açmayın; yanlış girilmiş tek bir reçete satırı kamyon kapıya gelene kadar fark edilmez.

Bu beş satır yazılı değilse MRP'nin listesi her hafta yeniden tartışılır. Bir de kimsenin sevmediği bir çıktı var: tarihi geçmiş öneriler. Hesap size "bu malzemeyi üç gün önce sipariş etmeliydiniz" der. Sistem bu satırları gizlemesin, ayrı bir başlıkta toplasın; geçmişe düşen öneri sayısı planlamanın ne kadar geriden geldiğini gösteren en dürüst gösterge.

Bu konuda nasıl yardımcı oluyoruz?

Yuog Dev olarak e-ticaret işletmelerinin ERP, entegrasyon ve otomasyon altyapısını kuruyoruz. İhtiyaç analiziyle başlıyor, ölçülebilir hedefler koyuyor ve teslim sonrasında da destek veriyoruz. Süreçlerinizi konuşmak isterseniz iletişim sayfasından bize ulaşabilirsiniz.