Aynı tezgahları, aynı hammaddeyi ve aynı işçiyi birden fazla ürün için paylaşıyorsan bu hafta hangi üründen ne kadar yapacağına vereceğin karar marjını belirler — literatürdeki adıyla Ürün Karması problemi, doğrusal programlamanın (LP) klasik uygulaması.
Kısaca
Tanıdık geliyor mu?
- 3-15 ürün yapıyoruz, hepsi aynı hammaddeyi ve aynı tezgahları paylaşıyor — birinin üretimi diğerinden tezgah çalıyor.
- Satış her hafta yeni sipariş kabul ediyor, üretim 'bu sefer sığar' diye söz veriyor, sonra dar boğaz tezgahta tıkanıyoruz.
- Hangi üründen ne kadar yapacağımıza karar verirken 'satış fiyatı en yüksek olanı öncelendir' kuralını uyguluyoruz — ama belki o ürün tezgahı en uzun yiyen ürün.
- Ürün başına birim marj muhasebede var. Ama **'tezgah saati başına marj'** veya **'kilogram hammadde başına marj'** yok — bu hesabı kimse yapmıyor.
- Ay sonunda dönüp baktığımızda 'şu üründen daha az yapsaydık şuna sığardık' diyoruz; o anki bilgiyle alsaydık farklı karar verirdik.
- Hammadde kıt olunca (ithal kalem, kur fırlayınca, tedarikçi geç kalınca) hangi ürünü tutup hangisini kıssak diye her seferinde sıfırdan tartışıyoruz.
- Müşterinin haftalık alacağı miktar tavanı var — bunu plana sokmamız lazım ama hesap tablosu hep elden gidiyor.
Niye önemli?
Nasıl çözülür?
Teknik derinlik
Nasıl çözülür?
Teknik derinlikTek satırla: Aynı tezgahı yiyen ürünler arasında bir saat tezgahta ne kadar para kazandıranı öncelendir — satış fiyatı yüksek olanı değil. Karar üç aşamada verilir.
1. Hesap kurulur. Her ürün için elde edilmesi gereken sayılar şunlar: birim marj (satış fiyatı eksi değişken birim maliyet — TRY/adet, muhasebeden çıkar), tezgah saati/adet, kilogram hammadde/adet, işçi saati/adet, müşterinin haftada/ayda alacağı en fazla miktar (talep tavanı). Sonra her kaynak için kapasiteyi yaz: haftada/ayda kaç tezgah saati var (planlı bakım ve duruşları çıkarınca net), kaç kilogram hammadde stoğa giriyor, kaç işçi saati var. Bu tablo doğrusal programlamanın girdisidir: amaç tüm ürünlerin (üretim miktarı × birim marjı) toplamını maksimum yapmak; kısıt ise her kaynak tüketiminin kapasiteyi aşmaması ve her ürünün talep tavanını aşmamasıdır.
2. Bilgisayar çözer. Hesap tablosundaki “çözücü” eklentisi (Solver) ya da açık-kaynak bir çözücü saniyeler içinde optimum karmayı verir. Çıktıda üç değerli bilgi var:
- Optimum karma: Her üründen kaç adet yapılacağı.
- Gölge fiyat (her dar boğaz kaynak için): “Bu kaynaktan bir saat/kilogram fazla olsa, aylık marjım ne kadar artar?” Örneğin dolum hattının gölge fiyatı 47 TRY/saat çıktıysa, 1 saat fazla dolum hattı kapasitesi 47 TRY ek marj demektir.
- Boşta kalan kapasite (slack): Hiç dolmayan kaynak. Bu kaynağa ek yatırım anlamsız.
Gölge fiyat tek başına müthiş bir karar aracı: dolum hattının gölge fiyatı 47 TRY/saat ise ve mesai zammı 25 TRY/saat ise, mesai açmak değer — saatte 22 TRY fazla marj. Tersi olsaydı (gölge fiyat 18 TRY/saat, mesai zammı 25 TRY/saat) mesai zarar olurdu.
Eğer ürün miktarları tam sayı olmak zorundaysa (yarım adet üretilemiyor) tamsayılı programlama (MIP) ile çözülür, orta ölçekte yine dakikalar içinde optimum. Talep belirsizse — örneğin bu hafta müşteri 100 ile 300 arası ne ısmarlayacağı belli değil — senaryo-bazlı ya da risk-payı (robust) uzantılarla çözülür.
3. Saha akışı kurulur. Çıktı haftalık ya da aylık üretim emrine çevrilir: ürün başına üretim miktarı, tezgah dolum yüzdesi, gölge fiyat raporu. Veri akışı: birim marj muhasebeden, talep tavanı satıştan, kaynak kapasiteleri üretimden. Aylık planlama toplantısında satış-üretim-finans aynı tabloya bakar. Hammadde fiyatı sıçrayınca, kur değişince, yeni sipariş gelince — model yeniden çözülür, karma günceller. Bu “kayan-pencereli (rolling-horizon)” yaklaşım: her hafta veya her ay yeniden çöz, çünkü talep ve kapasite değişiyor.
Alternatifler
Kafadan + hesap tablosu sıralaması
ÜcretsizSıfır lisans
Kim için: 2-4 ürün, tek dar boğaz, hammadde fiyatı oturmuş
- + Sıfır yazılım maliyeti
- + Anlık karar, esnek
- + Az ürün ve tek dar boğazda makul sonuç verir
- − 5 ürün üstünde insan zihni dar boğaz başına marjı doğru sıralayamaz
- − İki dar boğaz aynı anda darda ise kafadan çözülemez
- − Gölge fiyat görünmez — yeni tezgah/vardiya yatırımı verisiz alınır
- − Hammadde fiyatı sıçrayınca karma elle yeniden hesaplanmaz
Hesap tablosu çözücü eklentisi (Solver)
lowSıfır ek lisans (ofis paketinin içinde) ya da düşük yıllık abonelik
Kim için: 5-25 ürün, 5-15 kaynak kısıdı, aylık döngü
- + Kullandığın ofis paketinin içinde, ek yazılım yok
- + Doğrusal programlama çözücüsü dakikalar içinde optimum verir
- + Gölge fiyat ve duyarlılık raporu hazır
- + Operasyon ekibi 1-2 haftada öğrenir
- − Hesap tablosu hata yatağıdır — formül kayması fark edilmez
- − Versiyon yönetimi zor (kim hangi sürümü güncelledi belli olmaz)
- − 200+ değişken üstünde çözücü yavaşlar
- − Otomatik veri akışı için makro veya betik gerekir
Kurumsal kaynak planlama üretim modülü + LP eklenti
KurumsalAna lisans dahil; özel LP eklenti 60K-250K TRY tek seferlik veya yıllık 40K-120K TRY (TR pazar gözlemi)
Kim için: Orta-ölçekli imalatçı, 10-50 ürün, çoklu-vardiya
- + Kurumsal kaynak planlama içinde stok, satış, maliyet zaten entegre
- + Türkçe arayüz, yerel destek
- + Veri otomatik akar — elle taşıma yok
- + Çoklu kullanıcı, rol-bazlı yetki
- − Standart kurumsal kaynak planlama modülünde genelde LP yok — özel geliştirme gerek
- − Gölge fiyat ve duyarlılık raporu çoğu pakette eksik
- − Belirsizlik altında senaryo desteği zayıf
Açık-kaynak çözücü + özel ürün karması modülü
Açık KaynakLisans ücretsiz; iç geliştirme 6-14 hafta ya da 200K-700K TRY danışmanlık
Kim için: Yazılım ekibi olan imalatçı, mevcut sistemle entegrasyon istenen yerlerde
- + Lisans bedeli yok
- + Doğrusal ve karışık-tamsayılı çözücüler olgun, milyon-değişken problemi saniyelerde çözer
- + Belirsizlik ve kayan-pencereli uzantılar literatürde mevcut
- + Stokastik ve robust LP uzantıları eklemek kolay
- − İçeride doğrusal programlama bilen biri + entegrasyon ekibi şart
- − Prototipten saha sistemine taşıma 3-6 ay
- − Bakım sorumluluğu işletmede kalır
Tavsiye
Çözüm görüşmesinde sor
- Ürün karması modelinde hangi yöntem kullanılıyor — sürekli doğrusal programlama (LP), tamsayılı programlama (MIP), yoksa basit sıralama mı?
- Kaç ürün × kaç kaynak ölçeğine kadar pratik çözüm süresi makul kalıyor (saniyeler, dakikalar, yoksa saatler)?
- Gölge fiyat ve duyarlılık raporu çıktıda doğrudan görünüyor mu, yoksa ayrı modülden mi alıyoruz?
- Talep belirsiz olduğunda senaryo-bazlı veya robust planlama destekleniyor mu, yoksa yalnızca tek-tahminli plan mı?
- Hammadde fiyatı veya kur sıçradığında karmayı yeniden hesaplamak için veri akışı nasıl kuruluyor — saatlik, günlük, yoksa elle tetiklenen mi?
- Mevcut kurumsal kaynak planlamamızdan birim maliyet, stok seviyesi, tezgah-takvim ve sipariş havuzu otomatik okunuyor mu, yoksa hesap tablosu aktarımı mı?
- Pilot dönemde (12-16 hafta) gerçek talep ve kapasite verisiyle, manuel kararla kıyasla ne kadar marj iyileşmesi raporu sunulabilir?
- Sözleşme biterse model parametreleri, çözüm raporları ve gölge fiyat geçmişini hangi standart formatta dışa aktarabiliriz?
Teknik detay
Editör notu
Bu problem halk dilinde “ne yapsam karlı?”, “hangi sipariş öncelikli?” veya “ürün karması” diye anılır. Akademik adıyla Ürün Karması Problemi (Product Mix Problem) ya da Resource Allocation Linear Programming‘dir; doğrusal programlamanın (LP — kısıtlar altında en iyi karmayı bulan matematiksel yöntem) ilk yaygın endüstri uygulamasıdır. 1947’de geliştirilen simpleks algoritması 1950’lerde önce petrol rafinerilerinde uygulandı (rafineriden çıkan benzin/dizel/asfalt karmasını en karlı şekilde ayarlamak için), oradan tüm imalat ve gıda sanayisine yayıldı.
Problem 44 (Toplu Üretim Planlaması — APP) ile karıştırılmamalı. APP üst katmandadır: 3-18 ay ufukta üretim hızı + stok + işgücü + işçi alma-çıkarma + mesai + fason kararlarını birlikte verir. Ürün karması LP daha küçük ve tek dönem: bu hafta veya bu ay, kapasite ve hammadde sabit kabul edilerek hangi üründen ne kadar üretileceği. APP aylık ürün-ailesi hızını verir; ürün karması LP bu hızı haftalık ürün-bazlı miktara parçalar.
Problem 16 (Wagner-Whitin lot sizing) ile de karıştırılmamalı. Wagner-Whitin tek ürün için çoklu dönemde “bu ay üreteyim mi, ne kadar?” — kurulum maliyeti (setup) ile stok elde tutma maliyeti arasındaki dengedir. Ürün karması LP çoklu ürün için tek dönemde kıt kaynak paylaşımıdır. Birlikte çalışırlar: önce ürün karması bu dönem hangi ürünlerden ne kadar, sonra Wagner-Whitin her ürünün lot büyüklüğü.
Sektörde en sık atlanan nokta: Karar birim kâra göre değil, dar boğaz tezgah saati başına marja göre verilir. Eliyahu Goldratt’ın kısıtlar teorisi bunu vurgular: aynı tezgah saatini en çok marj getiren ürün için kullan, en yüksek satış fiyatlı için değil. Bir ürün birim 1000 TRY marj verip 4 saat dar boğaz tezgahı yiyorsa, dar boğaz saati başına 250 TRY/saat marj. Başka bir ürün birim 600 TRY marj verip 1.5 saat yiyorsa 400 TRY/saat. İkincisi önceliklidir. Kafadan karar genelde birinciyi seçer çünkü “birim kârı daha yüksek” görür — ama saat başına bakınca tablo tersine döner.
İkinci atlanan nokta — gölge fiyat okuma. LP çözümü her dar boğaz kaynak için marjinal değeri verir: “bu kaynaktan bir saat fazla olsa aylık marjım ne kadar artar.” Örneğin 380 TRY/saat. Bu rakam mesai zammı ile karşılaştırılır: mesai zammı 250 TRY/saat ise mesai açmak değer (saatte 130 TRY net kazanç). Gölge fiyat 180 TRY/saat olsaydı mesai açmak zarar olurdu. Aynı rakam yeni tezgah yatırımının veya yeni fason firma kararının geri dönüş hesabını veriye dayar.
Adım adım yol — KOBİ için
Aşama 1 — Önce ölç, sonra plan. Önümüzdeki 4-12 hafta için her ürün başına şu sayıları topla: birim marj (satış fiyatı eksi değişken birim maliyet — muhasebeden kuruşuna kadar oku), dar boğaz tezgah saati/adet, kilogram hammadde/adet, işçi saati/adet, müşterinin haftalık alacağı maksimum miktar. Kapasite envanteri: haftalık net tezgah saati (planlı bakım, vardiya değişimi ve duruşlar düşülmüş), haftalık hammadde stok girişi, haftalık net işçi saati.
Aşama 2 — Modeli kur. Hesap tablosunda her ürünü bir satır, her kaynağı bir sütun yap. Çözücü (Solver) eklentisi ile karar değişkenleri (her üründen kaç adet), kısıtlar (her kaynak toplam tüketimi kapasiteyi aşmasın, her ürün talep tavanını aşmasın, sıfırın altına inmesin) ve hedef (toplam marj maksimum) tanımla. Pilot olarak geçen haftanın gerçek verisiyle çöz (gerçek sipariş havuzu, kapasite, fiyatlar); çıktıyı senin kafadan verdiğin kararla kıyasla. İlk pilot tipik olarak %5-15 marj iyileşmesi gösterir.
Aşama 3 — Otomatize et. Veri akışı: birim marj muhasebeden, talep tavanı satıştan, kaynak kapasiteleri üretimden. Haftalık model otomatik koşar, çıktı üretim takvimine ve satış sipariş kabul kararına bağlanır. Gölge fiyat raporu aylık yönetim panosuna girer.
Aşama 4 — Yaygınlaştır. 6-12 ay sürede tüm ürün hattı, çoklu dar boğaz, hammadde fiyatı değiştiğinde otomatik yeniden hesaplama, gölge fiyat bazlı yeni tezgah/vardiya yatırım önerileri. Talep belirsizliği belirginse stokastik veya robust uzantı ek modül olarak gelir.
Riskler — ne yanlış gidebilir
- Birim maliyet hatası. Birim marj muhasebe verisinden çıkar; eğer genel giderler ürünlere yanlış pay edilmişse (örn. ortak makine maliyeti ürünler arası eşit bölünmüşse — kullanıma göre değil), karar yanlış ürünü öncelendirir. Önce maliyet sistemi denetlemesi şart.
- Talep tavanı hatası. Müşteri talep tavanını yüksek tutarsan optimum satılamayan stoğa döner; düşük tutarsan kazanabileceğin marj kaçar. Tavanı satışın son 6-12 ay gerçekleşmesinden veriye dayandır, tahminden değil.
- Dar boğaz kayması. Karma değiştikçe dar boğaz tezgah da değişebilir. Sabit dar boğaz varsayımı eskir. Aylık yeniden çözüm + gölge fiyat raporu izlemesi şart.
- Hammadde belirsizliği. Tek-tahminli LP fiyat veya tedarik şokuna kırılgan. Kritik hammadde için iki-üç senaryo (taban/düşük/yüksek) ile çoklu-senaryo veya robust LP. Tek tedarikçi bağımlılığı varsa ürün karması o tedarikçinin durumuna kilitlenir.
Çözüm yöntemine teknik bakış
| Yaklaşım | Tipik ölçek | Çözüm süresi | Garantili optimum? |
|---|---|---|---|
| Kafadan + sıralama | 2-4 ürün, tek dar boğaz | anında | Hayır, optimumdan %30-50 sapma |
| Dar boğaz saati başına marj sıralaması (Goldratt 1984) | 3-8 ürün, tek dar boğaz | dakikalar | Tek dar boğazda evet |
| Hesap tablosu LP çözücü eklentisi | 5-50 ürün, 5-20 kaynak | saniyeler | Evet |
| Tamsayılı programlama (MIP) | 5-50 ürün, 5-30 kaynak | saniye-dakika | Evet |
| Senaryo-bazlı (stokastik) LP | 10-100 ürün, çok-senaryo | dakikalar | Evet, senaryo sayısı kısıtlı |
| Risk-payı (robust) LP | 10-100 ürün, belirsizlik bütçesi | dakikalar | Evet |
Hedef seçimi:
- Toplam marj maksimum: Standart hedef. Her ürünün miktar × birim marjı toplamı maksimum.
- Müşteri tamamlama oranı maksimum: Stratejik müşterilerin sipariş tamamlanma yüzdesi önceliklidir; talep tavanı altında bu ürünlere ağırlık ver.
- Dar boğaz boş kalmasın: Kapasite kullanımı maksimum. Genelde toplam marj ile aynı sonucu verir; farklılaşırsa kapasite stratejik nedenle dolu tutulmak isteniyor demektir.
- Risk-ayarlı marj (kötü senaryo da iyi): Talep belirsiz iken kötü senaryoda da marj korunsun — stokastik veya robust uzantı gerekir.
Çok-hedefli ise: ya ağırlıklı toplam (toplam marj + müşteri-önceliği ağırlığı) ya da hiyerarşik (önce stratejik müşteri tamamlama, sonra toplam marj).
Akademik kaynaklar
Sayfanın frontmatter’ında sources alanında listelidir.
Kaynaklar
- Dantzig, G. B. (1963). Linear Programming and Extensions. Princeton University Press. Doğrusal programlamanın kanonik kaynağı; simpleks algoritmasının ilk geniş yayını.
- Hillier, F. S. ve Lieberman, G. J. (2014). Introduction to Operations Research (10. baskı). McGraw-Hill. Ürün karması LP’nin standart ders kitabı sunumu; sayısal örnekler.
- Winston, W. L. (2003). Operations Research: Applications and Algorithms (4. baskı). Duxbury. Endüstri örnekleriyle ürün karması ve duyarlılık analizi.
- Taha, H. A. (2017). Operations Research: An Introduction (10. baskı). Pearson. LP ve simpleks, ürün karması uygulamaları.
- Goldratt, E. M. (1984). The Goal. North River Press. Kısıtlar teorisi; dar boğaz kaynak başına marj kavramı.
- Bertsimas, D. ve Sim, M. (2004). The price of robustness. Operations Research, 52(1), 35-53. Belirsizlik altında robust LP çerçevesi.
- YÖK Tez Merkezi — anahtar kelime: ‘ürün karması’ veya ‘doğrusal programlama’ veya ‘kapasite tahsisi’ — 50+ tez. tez.yok.gov.tr
Sözlük
- Doğrusal Programlama (LP)
- Doğrusal bir amaç fonksiyonunu doğrusal eşitlik ve eşitsizlik kısıtları altında optimize eden ve operasyonel araştırmanın temelini oluşturan matematiksel programlama dalı.
- Ürün Karması Problemi
- Birden fazla ürünü aynı kapasite ve hammadde havuzundan üreten KOBİ'nin kısa-dönem için hangi üründen ne kadar yapacağını kâr veya katkı payı maksimum olacak şekilde belirleyen klasik doğrusal programlama uygulaması.
- Gölge Fiyat (Shadow Price)
- Bir doğrusal programlama probleminde herhangi bir kıt kaynak kısıdının sağ-taraf sabitinde birim artışın hedef fonksiyonu değerinde yarattığı marjinal değişim; eşdeğer olarak dual problemin optimal değişken değeri.
Benzer problemler
Aynı Malzemeyi Beş Tedarikçi Veriyor — Hangisinden Ne Kadar Alayım?
20-200 kişilik bir üretici firmada aynı hammaddeyi veya bileşeni 4-8 farklı tedarikçiden alıyorsunuz. Her tedarikçi fiyat, kalite, teslim süresi, kapasite, ödeme koşulları ve finansal sağlamlık açısından farklı; hangisini onaylı listeye alacağınız ve her sipariş için kime ne miktarda yükleyeceğiniz iki ayrı karardır. Yanlış seçim aylar süren bir kalite krizine veya tek tedarikçi kesintisinde hattın durmasına yol açabilir; 'en ucuz teklif' yaklaşımı kalite, geç teslim ve uyum maliyetlerini görmediği için %15-40 daha pahalıya çıkabilir. 5-15 teklifi 8-12 kriter üzerinden manuel skorlamak hesap tablosunda tutarsızlaşır.
Bir Seferde Ne Kadar Üreteyim, Ne Zaman Tekrar Başlayayım?
Bir üreticinin önündeki temel sorulardan biri: belli bir dönem için talep verisi var, her yeni üretim partisi başlatmak setup (kurulum) maliyeti gerektiriyor (kalıp değişimi, hat ayarı, kalibrasyon), üretilip de hemen satılmayan ürün stok maliyeti yaratıyor (depo, sermaye bağlama, eskime). Hangi haftada ne kadar üreteceğini önceden planlamak gerekir; bu sorunun matematiksel adı Lot Sizing Problem'dir. Tek ürünlü, deterministik talepli, kapasitesiz versiyonu 1958'de Wagner ve Whitin tarafından dinamik programlama ile çözüldü. Çok ürünlü, kapasiteli, çok aşamalı varyantları MRP, Capacitated Lot Sizing (CLSP) ve Economic Lot Scheduling (ELSP) olarak gelişti.
Bir Üründen Yılda Kaç Kez, Her Seferde Ne Kadar Sipariş Versem — Sipariş + Depo Maliyeti Toplam Minimum Olsun?
Yıllık 5-50M TRY ciroda toptan tedarikçi, ambalaj-hammadde alan orta-ölçekli üretici veya 50-500 SKU tüketen KOBİ depo/satınalma sorumlusu için her SKU'da iki karar tekrar eder: ne kadar büyük partilerle sipariş verelim, ne sıklıkta. Çok büyük parti → para depoda yatar, depo dolar, bozulma + eskime + finansman maliyeti şişer; çok küçük parti → sipariş başına nakliye + gümrük + sipariş işleme bedeli ezilir ve sipariş sıklığı patlar. Pratisyen sezgisel 'bir aylık stok al' veya 'kamyon dolacak kadar al' kuralıyla çalışır, optimumdan tipik %20-50 sapar — toplam yıllık maliyette %10-25 fazla. SKU başına doğru denge yıllık talep, sipariş başına sabit maliyet, sermaye bağlama oranı (TR son 5 yıl %25-45 bandı) ve birim depo maliyetinden hesaplanır; tedarikçi miktar iskontosu varsa kademe-kademe karşılaştırma gerekir. 200M TRY satın alma hacminde doğru hesap yıllık 300K-2M TRY operasyonel marj demek.