Az adetli, proje bazlı üretim yapan bir firmanın satınalma ekranındaki en sinir bozucu satır şudur: projenin ihtiyacı 12 adet, tedarikçinin minimum sipariş miktarı (MOQ) 100 adet. Karar bir dakikada verilir, faturası aylarca ödenir. Alınan 88 fazla parça o gün 'ileride lazım olur' diye kabul edilir; iki yıl sonra rafta duran, kimsenin sahiplenmediği, sayımda çıkan ama hiçbir projeye bağlanamayan bir kalemdir.
MOQ bir tedarikçi kaprisi değildir; kalıp, tezgâh ayarı ve parti başına sabit maliyetlerin karşılığıdır. Yani ortadan kalkmaz. Ortadan kalkmayan bir kısıtla baş etmenin yolu ise onu görünür kılmak ve fazlayı bilinçli yönetmektir. Bu yazı, sipariş üzerine mühendislik (ETO) yapan üretim KOBİ'lerinde MOQ fazlasının nasıl sessizce ölü stoğa dönüştüğünü ve bunu engelleyen birkaç somut disiplini ele alıyor.
MOQ neden ETO'da orantısız acıtır?
Seri üretimde MOQ görece zararsızdır: aynı ürünü her ay üretiyorsanız, fazla alınan parça bir sonraki partide erir. Talep tekrar eder, stok döner. ETO'da ise her proje kendine özgüdür. Bu projede kullandığınız özel konnektörün, bu müşteriye özel profilin veya bu tasarıma göre seçilmiş güç kaynağının bir daha aynı şekilde ihtiyaç olacağının garantisi yoktur.
Üstüne birkaç etken daha binince tablo ağırlaşır. İthal kalemlerde nakliye ve gümrük maliyeti küçük siparişte parça başına orantısız yükselir, bu da ekibi 'madem gönderiyoruz, biraz fazla alalım' refleksine iter. Savunma ve havacılık tarafında ise izlenebilirlik şartı devreye girer: aynı lottan alma isteği, siparişi tek seferde ve büyük vermeye zorlar. Sonuçta MOQ kararı, teknik bir gereklilik kılığına girmiş bir stok kararına dönüşür.
Ölü stoğun faturası sadece bağlanan nakit değildir
MOQ fazlasının maliyeti genellikle yalnızca 'bağlanan para' olarak konuşulur. Oysa nakit, listenin sadece ilk maddesidir. Raf alanı, sayım yükü ve elleçleme her yıl tekrar eder. Elektronik bileşenlerde teknolojik eskime, yapıştırıcı, conta ve boya gibi kalemlerde ise raf ömrü devreye girer — iki yıl sonra o malzeme fiziksel olarak yerinde durur ama kullanılamaz durumdadır.
En pahalı kalem ise ölçülmesi en zor olanıdır: yanlış güven. Sistemde stokta görünen bir malzemeye güvenip sipariş açmayan bir planlamacı, üretim haftasında o malzemenin aslında başka bir projeye ayrılmış olduğunu ya da raf ömrünün geçtiğini öğrenir. Bu noktada kaybedilen şey para değil, termindir. Ölü stok bütçeye zarar verir; yanlış görünen stok takvime zarar verir.
En pahalı hata: MOQ fazlasını projeye rezerve etmek
Burada, birçok kurulumda fark edilmeden yapılan kritik bir hata var. 12 adet ihtiyaç için 100 adet alındığında, malzeme depoya girer ve sistem gelen 100 adedin tamamını talebi açan projeye rezerve eder. Fiziksel olarak 88 adet elinizdedir; planlama açısından ise o 88 adet yoktur. İki ay sonra başka bir proje aynı malzemeye ihtiyaç duyduğunda sistem 'stok yok' der ve ikinci bir sipariş açılır. Firma aynı parçayı iki kez, üstelik iki kez MOQ'ya çarparak satın alır.
Doğru kural basittir ve tek cümleyle yazılabilir: rezerve edilen miktar, projenin gerçek ihtiyacı kadardır; MOQ nedeniyle gelen fazla, serbest stoğa yazılır. Bu ayrım kozmetik değildir. Rezerve stok bir projeye söz verilmiş miktardır; serbest stok ise firmanın herkese açık kaynağıdır. İkisi aynı sayının içinde eridiğinde, hem planlamacı hem depocu aynı ekrana bakıp farklı sonuçlara varır.
İhtiyacı proje bazında değil, malzeme bazında toplayın
MOQ israfının ikinci kaynağı, ihtiyaca yanlış açıdan bakmaktır. Üç aktif projeniz aynı bağlantı elemanından sırasıyla 12, 20 ve 30 adet istiyorsa ve satınalma bu talepleri ayrı ayrı işliyorsa, her biri MOQ'ya takılır: üç ayrı 100'lük sipariş, toplam 300 adet ve 238 adet fazla. Aynı ihtiyaç malzeme bazında toplandığında ise tablo değişir: toplam 62 adet, tek bir 100'lük sipariş, 38 adet fazla.
Kritik nokta şudur: toplama işlemi projenin kimliğini kaybetmeden yapılmalıdır. Yani sipariş tek satırda birleşir, ama hangi projeye kaç adet gideceği kayıtta durmaya devam eder. Mal kabulde her proje kendi payını alır, MOQ fazlası ise kimseye söz verilmeden serbest stokta bekler. Talepleri yalnızca proje ekranından yönetiyorsanız bu birleştirmeyi hiçbir zaman göremezsiniz — çünkü açığı doğuran şey bilgi eksikliği değil, bakış açısıdır.
MOQ'yu tedarikçi tarafında da yönetmek mümkün
MOQ çoğu firmada pazarlık dışı bir veri olarak kabul edilir; oysa pazarlığa en açık kalemlerden biridir. Birkaç pratik yol var:
- Fiyat yerine miktar esnekliği isteyin. Yüzde birkaçlık indirim yerine MOQ'nun yarıya inmesi, az adetli üretimde çoğu zaman daha kârlıdır.
- Miktarı bağlayın, teslimi bölün. Yıllık çerçeve miktar taahhüt edip parçalı teslim almak, hem birim fiyatı korur hem depoyu boğmaz.
- Muadil kodları hazır tutun. Aynı işi gören alternatif üretici kodu tanımlıysa, MOQ'su uygun olan tedarikçiye yönelmek dakikalar sürer; tanımlı değilse mühendislik onayı beklerken termin kayar.
- MOQ'yu e-postada değil stok kartında tutun. Gerçek temin süresi ve MOQ malzemenin kalıcı parametresi olmalı; teklif yazışmalarında saklandığında her sipariş yeniden keşif turuna dönüşür.
Fazla stoğun kaderine karar verin — ertelemek de bir karardır
MOQ fazlası doğru şekilde serbest stoğa yazıldığında iş bitmez; o stok yönetilmelidir. Uygulaması kolay birkaç kural yeterlidir. Her yeni proje planlamasında ilk bakılacak yer serbest stok olmalıdır: satınalma talebi açmadan önce elde olanı görmek, MOQ döngüsünü kırmanın en ucuz yoludur. Raf ömrü olan kalemlerde son kullanma takibi stok kaydının parçası olmalı, ayrı bir hatırlatma listesi olmamalıdır.
En önemlisi de şudur: on iki aydır hiç hareket görmemiş serbest stok için bilinçli bir karar verilmelidir — başka bir projede değerlendirmek, tedarikçiyle mahsuplaşmak veya hurdaya ayırmak. Karar vermemek de bir karardır ve genellikle en pahalısıdır; çünkü malzeme değerini kaybetmeye devam ederken, envanterde durduğu için hâlâ bir varlık gibi görünür.
Yazılım bu disiplini nasıl taşır?
MOQ bir yazılım sorunu değil, bir planlama disiplinidir; yazılım o disiplini ayakta tutan araçtır. Doğru kurgulanmış bir ERP+MRP şunları yapar:
- MOQ ve gerçek temin süresini stok kartının kalıcı parametresi olarak tutar, sipariş önerisini bu veriyle üretir.
- Aynı malzemenin farklı projelerdeki ihtiyacını proje kırılımını kaybetmeden toplar, MOQ'yu bir kez uygular.
- Mal kabulde yalnızca gerçek ihtiyaç kadarını projeye rezerve eder; MOQ fazlasını serbest stoğa yazar.
- Toplam stoğu rezerve, serbest ve üretim deposu olarak ayrıştırıp aynı sayıyı herkese aynı anlamda gösterir.
- Net ihtiyacı hesaplarken serbest stoğu düşer, böylece elde duran malzeme için ikinci kez sipariş açılmasını engeller.
- Son alım fiyatı üzerinden maliyet çıkararak fazla stoğun gerçek büyüklüğünü para olarak görünür kılar.
Tedeg ERP'de bu mantık bilinçli bir tasarım tercihidir: MOQ nedeniyle gelen fazla miktar projeye rezerve edilmez, serbest stoğa gider — çünkü bir projeye söz verilmemiş malzemeyi o projeye kilitlemek, ikinci projenin gereksiz siparişini garantiler. Amaç satınalmacının kararını devralmak değil; kararı doğru rakamla önüne koymaktır.
Bu hafta atabileceğiniz üç adım
Yeni bir sistem kurmadan da ölçülebilir kazanç elde edebilirsiniz. Birincisi, son on iki ayda MOQ yüzünden ihtiyacın üzerinde alınan kalemleri çıkarın ve bugünkü fiyatla toplam tutarı hesaplayın; bu rakam genellikle tahmin edilenden büyüktür ve tartışmayı tek başına başlatır. İkincisi, stok kartlarınızdaki MOQ ve temin süresi alanlarına bakın — çoğu firmada bu alanlar ya boştur ya da yıllar önce girilmiştir; güncellemek bir günlük iştir. Üçüncüsü, açık taleplerinizi malzeme bazında sıralayın ve aynı kalemin farklı projelerde tekrar edip etmediğini kontrol edin; birleştirilebilecek ilk siparişi bu hafta birleştirin.
Bu üç adım yeni bir modül satın almaktan çok daha hızlı sonuç verir. Satınalma ve stok tarafını proje bazlı bir akış üzerinde görmek isterseniz, gerçek bir üretim senaryosuyla inceleyebilirsiniz; ama önce yukarıdaki listeyi çıkarın — çoğu firmada asıl kazanç zaten oradadır.