Üretim Takip Programı (MRP): Kurulum Rehberi

Üretim takip programı, atölyedeki her işi numaralanmış bir iş emrine bağlayan ve o emrin hangi istasyonda, kimde, ne kadar süredir beklediğini gösteren yazılımdır. MRP (malzeme ihtiyaç planlama) ise aynı iş emirlerinden geriye doğru çalışıp “hangi malzemeden, kaç adet, en geç ne zaman almam gerekiyor” sorusunu cevaplar. İkisi aynı şey değildir: takip olanı kaydeder, MRP olacak olanı hesaplar. Bir üretim yazılımı ikisini birden yapmadığında sonuç her zaman aynıdır — ya depo şişer ya teslim tarihi kayar. Kurmanın üç yolu var: hazır bir üretim programı almak, hâlihazırda kullandığınız ERP’nin üretim modülünü açmak ya da kendi sürecinize göre özel bir sistem geliştirmek. Aşağıda hangi verilerin toplanması gerektiğini, iş emri–rota iskeletini, ürün ağacından net ihtiyaç hesabını, üç satın alma yolunu ve projeyi bozan beş hatayı bulacaksınız.

Üretim takip programı ne işe yarar?

Bu yazılımın ürettiği asıl şey rapor değil, cevap verilebilir sorulardır. “Bu sipariş ne zaman çıkar”, “dün kaç saat durduk ve neden”, “bu parçanın gerçek maliyeti ne” sorularının üçü de aynı veriye dayanır: işin hangi istasyonda ne kadar zaman geçirdiği. Excel’le yürütülen atölyelerde bu sorular cevapsız değildir; tahminle cevaplanır. Fark budur. Sistem oturduğunda üç somut çıktı gelir: söz verilen teslim tarihi kapasiteye dayanır, fire ve duruş sayılabilir hâle gelir, bir operatör işten ayrıldığında “bu işi nasıl yapıyorduk” bilgisi şirkette kalır.

Hangi verileri toplar?

Yazılım seçmeden önce hangi altı veriyi toplayacağınıza karar vermeniz gerekir; hazır program da özel geliştirme de bu altısının üzerine kurulur:

• İş emri — hangi ürün, kaç adet, hangi sipariş için, hangi tarihe. Numarası olmayan iş takip edilemez; sözlü verilen işler sistemin dışında kaldığı sürece hiçbir rapor doğru olmaz.
• Operasyon ve istasyon — işin rotadaki hangi adımda olduğu. “Üretimde” diye tek bir durum yetmez; darboğaz ancak adım adım görünür.
• Süre — operasyonun başlangıç ve bitiş damgası. Gerçek maliyetin, kapasitenin ve teslim tahmininin tek kaynağı budur.
• Miktar ve fire — üretilen sağlam adet ile hurdaya çıkan adet ayrı ayrı. Fireyi tek kalemde toplamak yerine nedenini de isteyin: makine ayarı, malzeme, operasyon hatası.
• Duruş — makinenin durduğu süre ve kodlanmış nedeni (arıza, malzeme bekleme, kalıp değişimi, mola). Kodsuz duruş verisi hiçbir iyileştirmeye dönüşmez.
• İzlenebilirlik — hangi hammadde partisi hangi iş emrinde kullanıldı. Gıda, medikal, otomotiv ve savunmada bu bir tercih değil, zorunluluktur.

Bu altı verinin beşi zaten atölyede bir yerde tutuluyordur — bir deftere, bir panoya ya da vardiya şefinin telefonuna. Yazılımın işi yeni veri yaratmak değil, bunları tek yere ve tek biçimde toplamaktır.

MRP nedir, ERP’den farkı ne?

MRP, elinizdeki üretim planından yola çıkıp malzeme ihtiyacını zamana yayarak hesaplayan yöntemdir. Girdisi üçtür: ürün ağacı (hangi ürün hangi bileşenden kaç adet ister), stok durumu ve tedarik süresi. Çıktısı da tek bir şeydir: hangi malzemeden kaç adet, en geç hangi gün sipariş edilmeli. ERP ise bunun üstündeki çatıdır; satış, satın alma, muhasebe ve depoyu aynı veritabanında birleştirir ve MRP çoğu ERP’nin içinde bir modül olarak gelir. Şirketiniz ERP kararını henüz vermediyse önce ERP nedir, şirketler için ne yapar yazımızı okumanız daha doğru bir sıra olur.

Pratik ayrım şudur: üretim takibi geçmişi ölçer, MRP geleceği planlar, ERP ikisini şirketin geri kalanına bağlar. Yalnızca takip kurarsanız neyi geç aldığınızı çok net görürsünüz — ama geç almaya devam edersiniz.

İş emri ve rota: sistemin çekirdeği

Yazılımı seçmeden önce kendi üretiminizi bu iskelette yazmanız gerekir. Rota, bir ürünün hangi operasyonlardan hangi sırayla geçtiğini tanımlar; iş emri ise o rotanın belirli bir miktar için çalıştırılmış hâlidir. Dört alan olmadan hiçbir üretim yazılımı işe yaramaz:

• Operasyon sırası ve istasyon — her adımın hangi makinede ya da hangi tezgâhta yapıldığı. Aynı işi iki farklı makine yapabiliyorsa bunu alternatif olarak tanımlayın; tek makineye bağlanan rota, o makine arızalandığında planı komple çöpe atar.
• Standart süre — hazırlık (setup) süresi ile birim başına işleme süresi ayrı ayrı. İkisini toplayıp tek sayı yapmak, küçük partilerde kapasite hesabını tamamen yanlışlar.
• Malzeme tüketim noktası — hammaddenin rotanın hangi adımında düşüleceği. Hepsini ilk adımda düşmek stok raporunu, hepsini son adımda düşmek maliyet raporunu bozar.
• Kalite kontrol adımı — kontrolün rotada bir operasyon olarak yer alması. Kontrolü rotanın dışında bırakan sistemlerde ret edilen parça “üretilmiş” sayılır ve fire hiçbir zaman doğru çıkmaz.

Kritik eşik şudur: aynı anda takip ettiğiniz iş sayısı 15-20’yi geçtiyse ya da üretim iki vardiyaya yayıldıysa, sorun ekibin dikkati değil, kuyruk yapısının olmamasıdır. Aynı eşik depo tarafında da kendini gösterir; stok takibinin nerede yetmeye başladığını stok takip programı mı özel yazılım mı yazımızda anlattık.

Ürün ağacından net ihtiyaca: MRP’nin çekirdek hesabı

MRP’nin tamamı tek bir cümleye iner: brüt ihtiyaçtan eldeki ve yoldaki miktarı çıkar, rezerve edilmiş olanı ekle geri, kalanı sipariş et. Yarı mamul varsa aynı hesap bir alt seviyede tekrarlanır. Aşağıdaki fonksiyon bu patlatma işlemini yapar — bir üretim yazılımının en çok tartışılan 30 satırı budur:

type BomLine = { childId: string; qtyPer: number };
type Bom = Record<string, BomLine[]>;

interface StockRow {
  onHand: number; // depodaki fiziksel miktar
  onOrder: number; // açık satın alma / yolda
  allocated: number; // başka iş emirlerine rezerve
}

/**
 * Bir iş emri için satın alınacak veya üretilecek NET miktarları hesaplar.
 * stock bir çalışma kopyası olmalıdır: fonksiyon tükettiği miktarı rezerve eder,
 * böylece aynı bileşen ağaçta iki yerde geçtiğinde iki kez sayılmaz.
 */
function explodeRequirements(
  productId: string,
  quantity: number,
  bom: Bom,
  stock: Record<string, StockRow>,
  out: Record<string, number> = {},
): Record<string, number> {
  for (const line of bom[productId] ?? []) {
    const gross = line.qtyPer * quantity;
    const row = stock[line.childId] ?? { onHand: 0, onOrder: 0, allocated: 0 };
    const available = Math.max(0, row.onHand + row.onOrder - row.allocated);
    const net = Math.max(0, gross - available);

    // Eldeki stoktan tüketilen kısmı rezerve et; kalan ihtiyaç net.
    row.allocated += gross - net;
    stock[line.childId] = row;
    if (net === 0) continue;

    out[line.childId] = (out[line.childId] ?? 0) + net;
    // Yarı mamulse alt ağacı da patlat: eksik olan adedi üretmek gerekecek.
    explodeRequirements(line.childId, net, bom, stock, out);
  }
  return out;
}

Fonksiyonun döndürdüğü miktarlar tek başına yeterli değildir: her satırın bir de “en geç sipariş tarihi” olması gerekir ve o tarih, teslim tarihinden tedarik süresi kadar geriye sayılarak bulunur. Bu iki sayı — kaç adet ve hangi gün — bir üretim yazılımının satın almaya verdiği tek gerçek katkıdır. Gerisi rapordur.

Veriyi kim girer? Sahadaki asıl risk

Üretim yazılımı projelerinin çoğu teknik bir sebeple değil, veri girişi operatöre yük olduğu için çöker. Sahada üç yol vardır ve genellikle üçü bir arada kullanılır:

• Barkod veya QR ile terminal girişi — operatör iş emrini okutur, başlar, bitirir. En yaygın ve en dayanıklı yöntem. Kritik detay: tek işlem iki okutmayı geçmemeli. Üç ekran gezdiren bir arayüz vardiya sonunda toptan ve uydurma doldurulur.
• Makineden otomatik veri — sayaç, PLC ya da IoT modülünden adet ve duruş bilgisinin doğrudan alınması. En doğru veri budur ama her makine buna hazır değildir; eski tezgâhlarda maliyet donanım tarafına kayar.
• Vardiya şefi girişi — bir kişi tüm vardiyanın verisini toplu girer. Kurulum en kolayı, veri kalitesi en düşüğüdür. Geçiş dönemi için kabul edilebilir, kalıcı çözüm olarak değil.

Personel ve vardiya tarafını zaten bir sistemle yönetiyorsanız iki yazılımın çakışmaması gerekir; mesai ve vardiya verisinin nerede tutulması gerektiğini personel takip programı (PDKS) yazımızda ayrıntılandırdık. Üretim raporlarının yönetim tarafına nasıl taşındığı ise ayrı bir iştir; ölçüm ile karar arasındaki bağı iş zekâsı ve raporlama paneli yazımızda anlattık.

Hazır program, ERP modülü, özel yazılım

Üç yolun hiçbiri diğerinden iyi değildir; üretiminizin ne kadar standart olduğuna göre değişir:

• Hazır üretim programı — hızlı başlar, aylık abonelikle ilerler, sektöre özel şablonlarla gelir. Üretiminiz klasik parti üretimiyse doğru seçim. Sınırı şudur: rotanız programın veri modeline uymuyorsa süreci yazılıma göre değiştirmek zorunda kalırsınız.
• ERP’nin üretim modülü — stok, satın alma ve muhasebe zaten aynı yerde olduğu için entegrasyon derdi en az olan seçenek. ERP’niz varsa ilk bakılacak yer burasıdır; devreye alma maliyeti çoğunlukla lisanstan değil, ürün ağaçlarını ve rotaları doğru yazmaktan gelir.
• Özel yazılım — üretiminiz sektöre özgüyse (proje tipi imalat, ölçüye göre üretim, karmaşık kalite kaydı, müşteriye özel izlenebilirlik) tek gerçekçi yol. Daha pahalı değil, farklı pahalı: lisans yok, geliştirme ve bakım var. Karar kriterlerini özel yazılım mı hazır çözüm mü yazımızda karşılaştırdık.

Maliyet kalemleri

Teklifleri karşılaştırırken tek bir rakama bakmak yanıltır; bu projelerde bütçe her zaman dört kaleme dağılır:

• Yazılım — hazır programda aylık/yıllık kullanıcı başı abonelik, özel yazılımda adam-gün üzerinden geliştirme. Özel geliştirmede fiyatın nasıl kurulduğunu özel yazılım maliyeti yazımızda kalem kalem açtık.
• Saha donanımı — terminal veya tablet, barkod okuyucu, etiket yazıcısı, gerekiyorsa makine veri toplama modülü. Küçük bir atölyede bile bu kalem yazılımdan büyük çıkabilir.
• Veri hazırlığı — ürün ağaçlarının ve rotaların yazılması. Projenin en çok küçümsenen kalemi ve gecikmelerin birinci sebebi budur; kimse sizin yerinize yapamaz.
• Eğitim ve paralel yürütme — ilk bir iki ay eski yöntemle yeni sistem bir arada yürür. Bunu bütçeye koymayan projeler, ilk hatalı raporda eski deftere geri döner.

Projeyi bozan beş hata

• Ürün ağacı gerçekle uyuşmuyor. Kâğıt üzerindeki reçete ile tezgâhta gerçekten kullanılan malzeme farklıysa MRP her çalıştırmada yanlış sipariş üretir. Sistem kurulmadan önce en çok satan on ürünün ağacı sahada doğrulanmalıdır.
• Fire ve duruş nedeni kodlanmıyor. Nedeni olmayan duruş verisi yalnızca kötü haber taşır, iyileştirme üretmez. Beş-altı kodla başlayın, zamanla ayrıntılandırın.
• Kapasite yokmuş gibi planlanıyor. Sonsuz kapasite varsayan bir plan her siparişe “olur” der ve söz verilen tarihlerin hiçbiri tutmaz. En azından darboğaz istasyonun kapasitesi hesaba girmelidir.
• Aynı anda her şey devreye alınıyor. Takip, MRP, kalite, maliyetlendirme ve bakım aynı ay açıldığında ekip hiçbirine güvenmez. Sıra nettir: önce iş emri takibi, veri oturduktan sonra MRP, en son maliyetlendirme.
• Operatör arayüzü masabaşı için tasarlanıyor. Eldiven, toz, kötü ışık ve ayakta çalışma; sahadaki arayüzün üç büyük butondan ibaret olması gerekir. Bu tek karar, veri kalitesini diğer hepsinden çok belirler.

Sonuç

Üretim takip programı üretimi iyileştirmez; yaptığınız işi görünür ve ölçülebilir hâle getirir, iyileştirmeyi siz yaparsınız. Bu yüzden başarı, seçilen ürünün markasıyla değil üç şeyle ilgilidir: doğru yazılmış ürün ağaçları ve rotalar, operatöre yük olmayan bir veri girişi ve kademeli devreye alma. Üretiminiz standart parti üretimiyse hazır bir programla ya da mevcut ERP’nizin modülüyle başlayın; ölçüye göre üretim yapıyor, proje bazlı çalışıyor ya da müşterinize parti bazında izlenebilirlik taahhüt ediyorsanız kurumsal çözümler hizmetimize bakın veya ürün çeşidinizi ve günlük iş emri sayınızı yazıp teklif alın.