Üretim modelleri arasında ETO (Engineer-to-Order — sipariş üzerine mühendislik) en az standartlaştırılmış, en çok mühendislik yoğunluğu taşıyan yapıdır. Müşteri siparişi geldiğinde ürün henüz tam tanımlı değildir; tasarım, malzeme seçimi, test planı ve üretim rotası birlikte şekillenir. Seri üretimde (MTS) veya stoktan üretimde (MTO) BOM ve rota önceden bellidir; ETO'da her proje kendi BOM ağacını, kendi teslim takvimini ve kendi risk profilini taşır.
ETO ile MTO/MTS arasındaki fark
MTS firması stok seviyesine göre üretir; talep tahmini merkezdedir. MTO firması sipariş alır ama ürün ailesi bellidir — konfigürasyon sınırlıdır. ETO firmasında ise müşteri çizimi, özel toleranslar ve değişen teslim tarihleri sürecin merkezine oturur. Bu fark, yazılım seçimini de belirler: muhasebe ağırlıklı ERP'ler ETO derinliği vermez; proje, çok seviyeli BOM ve mühendislik çıktıları tek akışta birleşmelidir.
- Tasarım gecikmesi doğrudan üretim başlangıcını kaydırır.
- BOM revizyonu satınalma ve üretimi aynı anda etkiler.
- Test ve kalite ürün tanımının parçasıdır, sonradan eklenmez.
Mühendislik-yapım: tek operasyonun iki yüzü
Türk mühendislik-yapım ve savunma tedarikçilerinde "mühendislik" ile "üretim" çoğu zaman farklı ekipler, farklı Excel dosyaları ve farklı toplantılarda yürür. Oysa ETO'da bu ayrım yapaydır: tasarım onaylanmadan malzeme alınamaz; malzeme gelmeden montaj başlamaz; montaj bitmeden test planı anlamsızdır. Operasyonun kalbi, bu disiplinleri tek proje kaydı altında birleştirmektir.
Disiplin bazlı planlama (mekanik, elektronik, yazılım) Gantt üzerinde görünür olduğunda, üretim tarafı "ne zaman başlarız?" sorusuna spekülasyonla değil, tamamlanmış çıktılarla cevap verir. Ar-Ge teslimatı geciktiğinde MRP'nin çalıştırılması anlamsızdır — çünkü patlatılacak BOM henüz kesin değildir.
Gerçek ETO örneği: Tedeg Savunma ve büyük savunma sanayi entegratörü PO
Tedeg Savunma'nın büyük savunma sanayi entegratörü müşterisi için yürüttüğü ters polarite siparişi tipik bir ETO senaryosudur. Müşteri PO numarası — altında 24 kalemli BOM, toplam 83 adet ürün ve 8 farklı teslim tarihi tanımlandı. Süreç teklif aşamasından başlayıp proje açılışı, disiplin bazlı mühendislik, BOM onayı, MRP, satınalma, mal kabul, üretim, test ve sevkiyata kadar tek zincirde ilerledi.
Bu ölçekte Excel ile yönetim şu riskleri taşır: revizyonların farklı kopyalarda kalması, açık satınalma taleplerinin görünmemesi, sevkiyat öncesi seri numarası ve CoC verilerinin dağınık olması. Tedeg ERP üzerinde aynı proje altında tüm kalemler izlendiğinde, sevk hazırlık süresinin anlamlı biçimde kısaldığı gözlemlendi — çünkü veri toplama değil, karar verme zamanı kaldı.
ETO için yazılımda olmazsa olmazlar
- Proje merkezli yapı (sipariş = proje)
- Çok seviyeli BOM ve revizyon kontrolü
- Mühendislik çıktısı → BOM onay köprüsü
- MRP ile otomatik satınalma talebi
- Seri/lot izlenebilirlik ve kalite kayıtları
Generic ERP'ler çoğu zaman "stok + fatura" ekseninde güçlüdür; ETO ise "proje + mühendislik + tedarik + kalite" ekseninde yaşar. KOBİ ölçeğinde SAP/Enterprise ERP bütçesi olmayan firmalar için, sektöre özel (savunma, makine, ölçüm cihazı) ETO odaklı çözümler bu boşluğu doldurur.
Karar vericiler için pratik kontrol listesi
ETO geçişinde şu soruları yanıtlayın: Müşteri PO revizyonu kalem seviyesinde mi izleniyor? BOM onaysız satınalma açılabiliyor mu? Test sonuçları sevkiyat belgesine otomatik akıyor mu? Bu üç sorudan biri "hayır" ise, operasyon hâlâ Excel ve e-posta üzerinde taşınıyor demektir. Hedef, her siparişin tekrarlanabilir bir proje şablonuyla açılması ve sapmaların erken görünür olmasıdır.
Sonuç: ETO bir mod değil, kültürdür
ETO'ya geçmek sadece yazılım almak değildir; mühendislik ile üretimin aynı gerçeği paylaştığı bir operasyon kültürü kurmaktır. İlk adım: müşteri PO'sunu, parça revizyonunu ve teslim tarihini tek yerde görmek. İkinci adım: BOM'u patlatıp malzeme ihtiyacını saniyeler içinde hesaplamak. Üçüncü adım: sevkiyat anında izlenebilirlik ve uygunluk belgelerini otomatik üretmek. Bu üçlü oturduğunda, ETO artık "kaotik özel sipariş" değil, tekrarlanabilir bir mühendislik-yapım operasyonu haline gelir.
Planlama ve kapasite: ETO'da belirsizlik yönetimi
ETO projelerinde kapasite planlaması, standart rota sürelerine değil, mühendislik çıktılarına bağlıdır. Gantt'ta mekanik tasarım bitmeden CNC iş emri açmak, ya boşta makine ya da yanlış revizyonla işlenmiş parça demektir. İyi uygulamada kritik yol haftalık olarak güncellenir; gecikme erken görünür ve müşteri teslim tarihi yeniden müzakere edilir. Sistem bu görünürlüğü sağlamazsa planlama toplantıları "tahmin toplantısı"na dönüşür.
Kaynak planlamada çok disiplinli ekipler (mekanik, elektronik, yazılım, kalite) aynı proje zaman çizelgesinde olmalıdır. Bir disiplinin gecikmesi diğerinin başlangıcını kilitlemeli — bağımlılık tanımsızsa paralel çalışma sanılır ve son hafta çöküş yaşanır. Tedeg Savunma'nın ters polarite projesinde 8 teslim tarihi, parça bazlı üretim ve test sırasını zorunlu kıldı; tek bir teslim tarihi varsayımı bu projede işe yaramazdı.
Maliyet ve marj: görünür maliyet ETO'da şart
ETO'da standart maliyet kartı yetersiz kalır; proje bazlı gerçekleşen malzeme, işçilik, fire ve yeniden işleme maliyeti izlenmelidir. Hangi mühendislik değişikliğinin marjı erittiği görülmezse, aynı hatalar tekrarlanır. Proje kapanışında "tahmini vs gerçekleşen" analizi, bir sonraki teklifin doğruluğunu artırır. Excel'de bu analiz çoğu zaman hiç yapılmaz — çünkü veri dağınıktır.
Satınalma fiyat sapmaları, acil kargo, ekstra test turu gibi kalemler proje altında toplanmadığında genel giderlere kaybolur. Yönetim "bu iş kârlı mıydı?" sorusuna net cevap alamaz. ERP'de proje maliyet defteri, ETO firmasının stratejik karar aracıdır.
Müşteri iletişimi: tek doğruluk kaynağı
Müşteri "nerede?" diye sorduğunda üç farklı cevap üretmek güven kaybıdır. Proje durumu ekranı — tasarım yüzdesi, açık eksikler, üretim emirleri, testler, sevkiyat planı — müşteri toplantısının temelidir. Savunma müşterilerinde bu bilgi sıklıkla resmi toplantı notuna girer; tutarsızlık sözleşmesel risk doğurur.
ETO başarısı, iç operasyon kadar dış iletişim disiplinine bağlıdır. Müşteri PO revizyonu geldiğinde etki analizi yapılmadan "anladık" demek, en pahalı hatadır. Sistem, revizyonu proje, BOM ve açık siparişlere yansıtmayı zorunlu kıldığında, iletişim ile operasyon hizalanır.