Endüstri Mühendisi Saha Kullanım Kılavuzu: Teori Bittiğinde Gerçek Başlıyor

Bu makaleyi dinle

Üniversite vs. Gerçek İş Hayatı

Dört yıl boyunca lineer programlama çözdün, şimdi üretim planlama yapmanı bekliyorlar. Ancak modeldeki “kaynak kısıtı” artık bir değişken değil; bozulan CNC tezgahı, izne çıkan operatörün yerine geçen çırak ve o ay hiç gelmeyen hammadde. Üniversite sana “tam bilgi, sınırsız zaman, rasyonel karar verici” varsayımlarıyla çalışmayı öğretti. Sahada ise veri eksik, bütçe dar, zaman yok ve karar vericiler her zaman rasyonel değil.

Lineer programlamanın optimal çözümü, “30 yıldır böyle yapıyoruz” duvarını gördüğünde eriyip gidiyor. Teorik optimum sahada nadiren uygulanabilir; onun yerine “yeterince iyi” (satisficing) çözümler üretmeyi öğrenmen gerekiyor. Bu tembellik değil, mühendislik olgunluğu.

Sahada ilk hafta şunu anlıyorsun: üniversite sana düşünmeyi öğretti, ama düşündüğünü sahaya taşıma becerisini öğretmedi. Bu boşluğun farkındalığı bile seni bir adım öne çıkarır.

Teorik Mühendislik vs. Pratik Saha — Karşılaştırma Tablosu

Boyut	Üniversite	Saha
Veri	Temiz, eksiksiz, hazır veri seti	Eksik, tutarsız, birden fazla kaynaktan gelen kirli veri
Kaynak	Sınırsız varsayım, model sınırı yok	Kısıtlı bütçe, sınırlı insan kaynağı, bozulan ekipman
Model	Matematiksel, deterministik veya stokastik	Sezgisel, deneyime dayalı, sıklıkla “en az zarar veren” seçim
Karar Süreci	Bireysel, sınav kağıdında	Komite, hiyerarşi, siyasi dengeler, patronun o günkü ruh hali
Başarı Kriterleri	Not, akademik yeterlilik	İş sürekliliği, maliyet, zamanında teslimat, kullanıcı memnuniyeti

---

Acı Gerçekler ve Gri Alanlar

Diploma tek başına yetmiyor. Bunu sert bir şekilde söylüyorum çünkü sahada bunu sert bir şekilde öğreniyorsun. 78+ projede gördüğüm en yetenekli mühendislerin ortak özelliği teknik bilgileri değil, iletişim becerisiydi. Teknik yetkinlik giriş bileti; ama sürecin içinde seni ayakta tutan şey bir imalat müdürüne değişiklik gerekliliğini anlatabilme kapasiten.

Kirli veri = çöp analiz. Sahada ilk yapacağın iş veri kalitesini sorgulamak. Excel tablosundaki rakamlara gözünü kapatıp güzel grafikler çıkarırsan, kararlar yanlış yönde gider ve o grafikleri hazırlayan kişi olarak sorumlu sen olursun.

Masa başında yazılan rapor, sahaya inmeden sıfır değer taşır. Bir üretim sürecini iyileştirmek istiyorsan, o süreci bizzat görmen gerekiyor. Vardiya başında orada olman, operatörle konuşman, hammaddenin nasıl geldiğini izlemen gerekiyor. Toplantı odasında değil, üretim alanında belli olur.

İnsan faktörü: Kilit kullanıcı (key user) sabotajı gerçek bir şey. Yeni sistemi öğrenmek istemeyen, eski düzenin bozulmasından korkan, hatta sistemi kasten yanlış kullanan insanlarla karşılaşacaksın. Yönetici katında ise gizli ajandalar var: bazı müdürler dijital dönüşümü kendi departmanlarının gücünü artırmak için kullanmak ister, bazıları ise kontrol kaybından korktuğu için projeyi baltalar.

Yetki-sorumluluk paradoksu: Senden sonuç beklenir ama karar yetkisi verilmez. Bu paradoks özellikle yeni mezunlarda ağır bir hayal kırıklığı yaratır. Çözüm: verinle konuş. Veriye dayalı konuşmazsan odadaki en düşük kıdemli kişi sen olursun.

Saha Notu
Bir gıda fabrikasında üretim verimliliği projesi yapıyorduk. Üç hafta boyunca masa başında veri analiz eden mühendis, “hat verimliliği %72” diye rapor hazırladı. Sahaya indiğimizde gerçek verimlilik %58 çıktı. Fark neredeydi? Plansız duruşlar sisteme girilmiyordu çünkü operatörler “kısa duruşları yazmaya değmez” diye düşünüyordu. Veri kaynağına gitmeden analiz yapmak, pusulasız yol almak gibidir.

---

Sahadan 7 Gerçek Vaka

Bu vakalar gerçek projelerden alınan dersler. Firma isimleri ve sektörel detaylar bilinçli olarak gizlenmiştir, ama yaşananlar birebir gerçektir.

Vaka 1: Master Data Hatası — Adet/KG Birim Dönüşüm Felaketi

Problem: Bir üretim işletmesinde ERP sistemine ürün birimleri “adet” yerine “kilogram” olarak tanımlanmıştı. Satın alma “KG” bazında sipariş veriyor, üretim “adet” bazında tüketiyor, depo ise iki birim arasında kayboluyordu.

Kök Neden: Master data (ana veri) giriş aşamasında birim dönüşüm faktörleri tanımlanmamıştı. Sistemin ilk kurulumunda bu alan “sonra hallederiz” diye geçilmişti.

Saha Etkisi: Üç ay boyunca stok verileri gerçeği yansıtmadı. Satın alma gereksiz siparişler verdi, depo fiziksel sayımla sistem arasındaki farkı kapatamadı. Mali tablolar saptı.

Yeni Mezun Ne Yapmalı: Master data disiplini her şeyin temelidir. Bir projeye dahil olduğunda ilk kontrol etmen gereken şey ana verilerin tutarlılığıdır. Birim, ölçü, dönüşüm faktörü, tedarikçi kodu — bunlar “sıkıcı detay” değil, sistemin temeli.

Vaka 2: MRP’nin Teknik Değil Siyasi Çökmesi

Problem: MRP (Malzeme İhtiyaç Planlaması) sistemi doğru çalışıyordu ama çıktılarına kimse uymuyordu. Satın alma departmanı MRP önerilerini yok sayıp kendi listelerini kullanıyordu.

Kök Neden: Satın alma müdürü, MRP’nin “kendi otoritesini azalttığını” düşünüyordu. Yıllardır kurduğu tedarikçi ilişkileri ve pazarlık gücü, otomatik sipariş önerilerinde görülmüyordu.

Saha Etkisi: MRP çalışıyor ama kimse dinlemiyor. Üretim malzeme bekliyor, satın alma “ben zaten sipariş verdim” diyor, depoda ise fazla stok birikiyor. Sistem var, disiplin yok.

Yeni Mezun Ne Yapmalı: Teknik doğruluk tek başına yetmez. Paydaş yönetimi (stakeholder management) öğrenmen gerekiyor. MRP’yi kurduktan sonra asıl iş, insanları sisteme ikna etmek. Satın alma müdürüyle birlikte çalış, onun endişelerini anla ve sistemi onun da sahipleneceği şekilde konfigüre et.

Vaka 3: Satış Tahmini vs. Gerçek Talep Uçurumu

Problem: Satış ekibi “bu ay 500 birim satacağız” dedi, gerçekleşen 180 birim oldu. Üretim 500 birime göre planlama yaptı, hammadde alındı, vardiya düzenlendi.

Kök Neden: Satış tahminleri subjektif “hissiyat”a dayanıyordu. Geçmiş veri analizi yapılmıyordu. Satış ekibi iyimser tahmin veriyordu çünkü düşük tahmin = “hedefsiz ekip” algısı yaratıyordu.

Saha Etkisi: Fazla üretim, stok maliyeti, bozulma riski (gıda sektöründe kritik), gereksiz fazla mesai maliyeti. Bir üretim döneminin bütçesi tamamen saptı.

Yeni Mezun Ne Yapmalı: Satış tahmini (demand forecasting) konusunda geçmiş veriyi temel al. Hareketli ortalama, mevsimsellik analizi gibi basit yöntemler bile “hissiyat”tan kat kat daha güvenilir. Tahmin doğruluğu (forecast accuracy) metriğini takip et ve yönetimle paylaş.

Vaka 4: Fiziksel Sayım vs. Sistem Stoğu Uyumsuzluğu

Problem: Yıllık fiziksel envanter sayımında sistem stoğu ile fiziksel stok arasında %23 sapma çıktı. Bazı ürünlerde sistem “var” diyor, raf boş; bazı ürünlerde raf dolu, sistem “sıfır” gösteriyor.

Kök Neden: Depo giriş-çıkış işlemleri anlık yapılmıyordu. “Akşam toplu girelim” alışkanlığı vardı. Fire ve hurda kayıtları sisteme işlenmiyordu. Palet yer değişiklikleri güncelenmiyordu.

Saha Etkisi: Gerçekte olmayan malzemeye üretim planı yapıldı. Müşteriye teslimat sözleri verildi ama malzeme yoktu. Acil satın alma siparişleri maliyetleri yüzde 15-20 artırdı.

Yeni Mezun Ne Yapmalı: Stok sayımı sadece yıllık ritüel değil, sürekli bir disiplindir. Döngüsel sayım (cycle counting) yöntemini öğren ve öner. Depo işlemlerinin “anlık” girilmesini sağlayacak süreci kur. Barkod veya el terminali kullanımı olmazsa olmazdır.

Vaka 5: ERP Go-Live Sonrası Kullanıcı Sabotajı

Problem: Altı aylık ERP projesi tamamlandı, go-live yapıldı. İlk hafta içinde kullanıcılar sisteme ya yanlış veri girdi ya da hiç girmedi. “Sistem çalışmıyor” şikayetleri yağdı.

Kök Neden: Kullanıcılar değişim sürecine dahil edilmemişti. Eğitimler yetersizdi — iki günlük toplantı odasında PowerPoint gösterimi “eğitim” sayılmıştı. Kullanıcılar eski alışkanlıklarına dönmek istiyordu.

Saha Etkisi: Yönetim “ERP yanlış seçim miydi” sorgulamasına girdi. Proje ekibi günlük yangın söndürme moduna geçti. Moral dip yaptı. Bazı departmanlarda eski Excel tablolarına geri dönüldü.

Yeni Mezun Ne Yapmalı: Değişim yönetimi (change management) teknik projeden ayrı değildir, projenin kendisidir. Kullanıcıları sürecin başında dahil et. Eğitimleri sahada, gerçek senaryolarla yap. Go-live sonrası ilk iki hafta “hypercare” dönemi olarak planla ve sahada kal.

Saha Notu
78+ projede sürekli gördüğüm bir kalıp var: Teknik olarak kusursuz kurulan sistemler, kullanıcı benimsemesi olmadığı için rafa kalkıyor. Yazılım kurmak kolay, doğru yaşatmak zor. Bu cümleyi kariyerinin her aşamasında hatırla.

Vaka 6: Süreç Standardizasyonu vs. “Usta Bildiğini Okur”

Problem: Bir metal işleme fabrikasında aynı parçanın üç farklı operatörü üç farklı yöntemle üretiyordu. Kalite dalgalanmaları müşteri şikayetlerine dönüştü.

Kök Neden: Standart iş talimatları (SOP – Standart Operasyon Prosedürü) yoktu. Her usta kendi yöntemini uyguluyordu ve bu “tecrübe” olarak kutsanıyordu. “Usta bildiğini okur” kültürü süreç standardizasyonunun önündeki en büyük engeldi.

Saha Etkisi: Kalite tutarsızlığı, müşteri iade oranları yükseldi, yeni işe başlayan operatörler neyi öğreneceğini bilemedi. Ustaların izinli veya hasta olduğu günlerde üretim kalitesi dip yaptı.

Yeni Mezun Ne Yapmalı: Süreç dokümantasyonu “bürokrasi” değil, bilgi yönetimidir. Ustaların bilgisini yazılı hale getir, ama bunu “senin yöntemin yanlış” diyerek değil, “senin tecrübeni kalıcı kılalım” diyerek yap. Gösterecek verin olsun: fire oranları, müşteri iadeleri, operatörler arası verimlilik farkı.

Vaka 7: KPI Takıntısı, Kök Neden Analizi Yokluğu

Problem: Bir lojistik firmasında 47 adet KPI (Anahtar Performans Göstergesi) takılıyordu. Her ay raporlanıyordu. Ama hiçbirinde “neden böyle” sorusu sorulmuyordu.

Kök Neden: KPI’lar “ölçmek için ölçme” alışkanlığı haline gelmişti. Yönetim güzel grafikler görmek istiyordu ama kök neden analizi için zaman ve kaynak ayırmıyordu. Ölçemediğini yönetemezsin doğru, ama ölçüp de aksiyon almadığın şeyi ölçmenin de anlamı yok.

Saha Etkisi: Raporlama için haftalık 12 adam-saat harcanıyordu. Hiçbir KPI için aksiyon planı yoktu. Sorunlar tekrar ediyordu.

Yeni Mezun Ne Yapmalı: Az ama anlamlı KPI seç. Her KPI için “bu düşerse/yükselirse ne yapacağız” sorusunu cevapla. 5 Neden (5 Why) analizi ve Ishikawa (balık kılçığı) diyagramını öğrenip uygula. Pareto analizi ile önceliklendirme yap: sorunların %80’i genellikle nedenlerin %20’sinden kaynaklanır.

---

Proje Yönetimi Gerçekleri

Proje yönetimi metodolojilerini okulda öğrendin: Waterfall (şelale), Agile (çevik), Scrum, Kanban. Sahada bunların hiçbiri saf haliyle çalışmaz. Neden çalışmadığını sadece isim sayarak değil, her birinin hangi eksende güçlü veya zayıf olduğunu görerek anlaman gerekiyor.

Metodoloji Karşılaştırması: Kapsam, Zaman, Bütçe, Değişiklik, Dokümantasyon

Eksen	Waterfall	Agile / Scrum	Hibrit (Sahada Çalışan)
Kapsam Yönetimi	Başta kilitlenir, değişiklik pahalıdır	Sürekli değişir, scope creep riski yüksek	Çekirdek kapsam kilitli, detay uygulamada iterasyon serbest
Zaman Planı	Gantt bazlı, öngörülebilir ama esnekliği düşük	Sprint bazlı, kısa döngüler ama ERP gibi büyük projelerde koordinasyon zorlaşır	Ana milestones Gantt, uygulama iterasyonları sprint
Bütçe Kontrolü	Net bütçe çerçevesi, sapma tespiti kolay	Bütçe “iterasyonla büyür”, patron “ne zaman bitecek” sorusuna net cevap alamaz	Sabit çerçeve bütçesi + iterasyon için ayrılmış esneklik payı
Değişiklik Yönetimi	Formal CR (Change Request) süreci, ağır ama izlenebilir	“Backlog’a ekle” kültürü, izlenebilirlik zayıf	CR süreci zorunlu, ama etki analizi hızlı tutulur (48 saat kuralı)
Kullanıcı Beklentisi	“Söyleyin, yapalım” → kullanıcı süreçten kopabilir	Kullanıcı sprint review’e katılır ama yorulur	Kritik milestones’da kullanıcı katılımı, arada çevik demo
Dokümantasyon	Ağır dokümantasyon, bazen gereksiz detay	“Çalışan yazılım > dokümantasyon” felsefesi, sahada tehlikeli	İş kuralı ve konfigürasyon dokümanı zorunlu, gerisi isteğe bağlı
UAT (Kullanıcı Kabul Testi)	Proje sonunda toplu test, geç geri bildirim	Her sprintte test, ama ERP entegrasyonu sprint’e sığmaz	Modül bazında UAT döngüleri + go-live öncesi bütünleşik UAT

Neden hibrit kaçınılmaz: Saf Waterfall, ERP projesinin ortasında değişen iş gereksinimlerine cevap veremez — patron yeni bir rapor istediğinde “kapsamda yok” demek proje güvenini öldürür. Saf Agile ise ERP’nin doğası gereği imkânsız: MRP konfigürasyonu, muhasebe hesap planı, rol-yetki matrisi gibi konular “sprint’te deneyelim, olmazsa geri alırız” yaklaşımına uygun değil. Hibrit model bu gerilimi çözer: tasarım aşaması Waterfall (kapsam, bütçe, zaman kilitleri), geliştirme aşaması çevik (iterasyon, demo, hızlı geri bildirim), UAT aşaması disiplinli (senaryo bazlı test, kullanıcı imzası).

Scope Creep (Kapsam Kayması) ve “Hayır” Demenin Değeri

Sahada öğreneceksin: “Hayır” demenin değeri altın değerindedir. Her gelen talep projeye eklenmez. Kapsam belgesinde yoksa, değişiklik talebi (change request) formu doldurulur, etki analizi yapılır, onay alınır. Bu “yavaşlık” değil, disiplin. Proje mezarlığına bir taş daha eklenmesin diye bu süreç işletilir.

Kapsam kaymasının sinsi tarafı şu: tek tek küçük görünen istekler biriktiğinde projeyi altı ay öteye sürükler. “Şu küçük raporu da ekleyelim” diye başlayan cümleler, proje takviminin %40 sapmasıyla sonlanır. Her talep için “bunu eklersek neyi erteleriz” sorusunu sor.

Toplantı Disiplini

Toplantı kültürü konusunda şunu asla unutma: Karar alınmayan toplantı, maaşla finanse edilen zaman hırsızlığıdır. Her toplantıya gündemle gir, kararla çık, aksiyon listesiyle dağıl. Toplantı çıktısı şu formatta olmalı: karar + aksiyon + sahip + tarih. Bu dört bilgi yoksa o toplantı yapılmamış sayılır.

Saha Notu
Bir projede haftalık “durum toplantısı” iki saate uzuyordu. Herkes sorunlarını anlatıyordu ama kimse çözüm önermiyordu. Toplantı yapısını değiştirdik: her katılımcı için 3 dakika, sadece “tıkanıklık + önerilen çözüm + gereken destek” formatı. Toplantı 25 dakikaya düştü, verimlilik tavan yaptı.

---

ERP Kültürü ve Disiplini

ERP (Kurumsal Kaynak Planlaması) bir yazılım değil, şirketin anayasasıdır. Bütün departmanların aynı dilde konuşması, aynı verileri kullanması ve aynı kurallara uymasıdır. Bunu anlamadan ERP projesine girersen, yazılım kurucu olursun ama değer üretemezsin.

Temel Yapı Taşları

Süreç sahipliği (Process Ownership): Her iş sürecinin bir sahibi olmalı. “Bu kimin sorumluluğu” sorusunun net cevabı yoksa, o süreç er ya da geç çöker. Süreç sahibi sadece isim değil; o sürecin performansından, kurallarından ve değişiklik taleplerinin onayından sorumlu kişidir.

Rol-yetkilendirme matrisi ve SoD (Segregation of Duties — Görevler Ayrılığı): Satın alma siparişini oluşturan kişi aynı zamanda onaylayan kişi olmamalı. Bu sadece muhasebe ilkesi değil, operasyonel güvenlik gerekliliği. ERP’deki yetki matrisi şirketin iç kontrol mekanizmasıdır — gevşek bırakırsan suistimale açık kapı bırakırsın.

Master data disiplini: Ürün kodu, müşteri kodu, tedarikçi kodu — bunlar kaotik oluşturulursa sistem altı ayda çöp yığınına döner. Master data yönetimi bir kerelik iş değil, sürekli bakım gerektiren disiplindir.

Değişim yönetimi: ERP projesinin %30’u teknik kurulum, %70’i insanları değişime hazırlama işidir. Kullanıcı eğitimi bu disiplinin merkezinde yer alır.

Eğitim Planı: PowerPoint Değil, Saha Eğitimi

ERP eğitimi toplantı odasında yapılan iki günlük sunum değildir. Etkili eğitim şu unsurları içerir:

• Rol bazlı eğitim: Satın almacıya sadece satın alma modülü, depo görevlisine sadece depo süreçleri. Herkese her şeyi öğretmeye kalkmak hiçbir şey öğretmemekle aynı kapıya çıkar.
• Gerçek veriyle senaryo eğitimi: Kullanıcı kendi ürün kodlarıyla, kendi tedarikçileriyle, kendi iş akışlarıyla çalışmalı. Demo verisinden öğrenilen bilgi sahaya transfer olmaz.
• Sahada yan yana eğitim: Eğitmen kullanıcının yanında, gerçek iş ortamında, gerçek işlem yaparken eşlik eder. Sınıf eğitimi temel bilgi verir; asıl öğrenme sahada yan yana çalışarak olur.
• Eğitim sonrası destek: İlk iki hafta “hypercare” dönemi. Eğitim verdin ve bıraktıysan, o eğitim tamamlanmamış demektir.

Test ve UAT Akışı

UAT (Kullanıcı Kabul Testi) ERP projelerinin en fazla ihmal edilen aşamasıdır. Test iş kurallarını doğrular, sistem doğruluğunu değil. UAT akışı şöyle kurulmalı:

1. Senaryo hazırlığı: Gerçek iş vakalarından senaryo yazılır — “100 adet X ürünü sipariş et, al, depoya koy, üretime çek, üret, sevk et, faturala.” Uçtan uca bir süreç.
2. Kullanıcı yürütmesi: Senaryoyu IT değil, sürecin gerçek sahibi olan kullanıcı yürütür.
3. Hata / sapma kaydı: Her sapma belgelenir, önceliklendirilir (kritik / yüksek / düşük), atanır.
4. Düzeltme + tekrar test: Düzeltilen her hata için aynı senaryo tekrar çalıştırılır.
5. Kullanıcı onayı: UAT tamamlandığında kullanıcı yazılı onay verir. Bu imza “sistemi kabul ediyorum” demektir ve sorumluluk paylaşır.

UAT’ı atlayan veya sıkıştıran projeler, go-live sonrası kullanıcı sabotajıyla (Vaka 5) karşılaşma riskini katlar.

Entegrasyon Mantığı

Hiçbir ERP tek başına yaşamaz. Muhasebe, e-Fatura, banka entegrasyonu, üretim makinesi veri toplama (MES), CRM, e-ticaret — bunlardan en az ikisiyle konuşması gerekir. Entegrasyon planı ERP projesinin en erken aşamalarında ele alınmalı; sonradan “bunu da bağlayalım” demek maliyet ve risk katlıyor.

Raporlama Etiği

ERP’de raporlama “güzel grafik üretme” işi değildir. Raporlar karar almayı destekler; bu yüzden her raporun bir alıcısı, bir kullanım amacı ve bir aksiyon eşiği olmalı. “Sadece bilgi olsun diye” üretilen raporlar kaynak israfıdır. Raporlama etiği şunu gerektirir: veriyi çarpıtmamak, olumsuz sonuçları gizlememek ve “yeşil” gösteren dashboardların arkasındaki sarı/kırmızı sinyalleri de sunmak.

Kurmak vs. Doğru Yaşatmak

Bu ayrım sahada en çok göz ardı edilen konudur. ERP’yi kurmak bir proje; ama doğru yaşatmak sürekli bir operasyondur. Kurulumda danışman + proje ekibi çalışır, sonra çekilir. Geride kalan ekip sistemi doğru işletmezse — master data bozulur, süreç kısayolları devreye girer, raporlar güvenilmezleşir — sistem kağıt üzerinde “canlı” ama pratikte ölüdür. Yazılım kurmak kolay, doğru yaşatmak zor. Bu cümle kariyer boyunca geçerliliğini korur.

Türkiye’de ERP Gerçeği

Türkiye’de ERP pazarında yerel ve global çözümler bir arada yaşıyor. Türkiye’ye özgü yasal gereksinimler — e-Fatura, e-Defter, e-İrsaliye, KVKK (Kişisel Verilerin Korunması Kanunu), UBL-TR standartları — her ERP seçiminde belirleyici faktör. Hangi yazılımı seçersen seç, bu yasal uyumluluk konuları pazarlık konusu değil, zorunluluk.

---

Yeni Mezunun Geliştirmesi Gereken Yetkinlikler

Teknik bilgi giriş bileti, ama sahada seni ayakta tutan yetkinlikler bunlar:

• [ ] İleri Excel: VLOOKUP/XLOOKUP, Pivot Table, Power Query, makro temelleri. Sahada ilk silahın bu.
• [ ] Temel SQL: SELECT, JOIN, WHERE, GROUP BY. Veritabanından veri çekebilmek seni “rapor bekleyen” değil “rapor üreten” kişi yapar.
• [ ] BPMN/Swimlane diyagramları: İş süreçlerini görselleştirebilmek. Sözel anlatım yetersiz kalır, çiz ve göster.
• [ ] 5 Neden / Ishikawa / Pareto: Kök neden analizi araçları. Semptom değil, neden tedavi edersin.
• [ ] Toplantı yönetimi: Gündem hazırlama, zaman yönetimi, karar/aksiyon takibi. Küçümseme, kariyerini hızlandırır.
• [ ] ERP mantığı: Sipariş-sevkiyat-fatura döngüsünü, MRP çalışma prensibini, stok yönetimi temellerini bil.
• [ ] Dokümantasyon: Yaptığı işi yazmayan mühendis, iz bırakmayan gezgin gibidir.
• [ ] KVKK farkındalığı: Kişisel veri işleme, saklama, imha süreçleri. Yasal zorunluluk, ihmal edilemez.
• [ ] Teknik İngilizce: ERP dokümanlarının %80’i İngilizce. Okuyup anlayabilmek minimum seviye.
• [ ] AI araçları: Prompt mühendisliği, çıktı doğrulama ve saha teyidi. Yeni nesil Excel bu.

---

AI ve Otomasyon Çağında Endüstri Mühendisi

Sadece analiz yapan mühendis yerini yapay zekaya bırakacak. Bu korkutmak için değil, hazırlaman için söylüyorum.

AI sana saniyeler içinde veri analizi, tahmin modeli ve optimizasyon önerisi sunabilir. Ama AI bir şeyi yapamaz: sahaya inip o verinin doğru olup olmadığını kontrol etmek. Depo rafında fiziksel sayım yapmak. Operatörle görüşüp “neden bu şekilde yapıyorsun” diye sormak. Satın alma müdürünün gizli direncini fark etmek.

Yeni rol şu: AI’ya doğru soruyu yöneltmek + çıktıyı kritik gözle değerlendirmek + sahayla teyit etmek. “Prompt kurma, yeni nesil Excel” diyorum çünkü ikisi de araç; önemli olan aracı doğru kullanma becerisi.

AI halüsinasyonları (uydurma bilgi üretmesi) gerçek bir tehlike. AI sana çok ikna edici ama tamamen yanlış bir maliyet analizi sunabilir. Doğrulama (validation) adımı atlanırsa, o rapora dayanarak alınan kararlar şirketi zarara uğratır ve sorumlu sen olursun.

AI saha çalışmasının yerini almaz. Sahaya inmeni hızlandırır, ama sahaya inme zorunluluğunu ortadan kaldırmaz.

---

Türkiye KOBİ Gerçeği

Türkiye’de KOBİ’lerde çalışıyorsan, ders kitabında okumayacağın bazı gerçeklerle tanışacaksın.

Patronun oğlu/damadı faktörü: Organizasyon şemasında yazmaz ama karar mekanizmasında vardır. Bunu görmezden gelmek değil, anlamak ve buna göre iletişim stratejisi kurmak gerekir.

Aile şirketi dinamikleri: Profesyonel yönetim ile aile bağlılıklarının çakıştığı noktalar. İK müdürü aynı zamanda patronun yengesi olabilir. Bu durumlarda “doğru olan”ı değil, “kabul edilebilir olan”ı bulmak sanatını öğrenirsin.

SGK/vergi yükü: KOBİ sahibinin zihninin yarısı vergi planlamasıyla meşgul. Dijital dönüşüm projelerinde bütçe ayırmasını istiyorsan, yatırım getirisini (ROI) onun dilinde anlatman gerekir: “Bu sistem sana ayda şu kadar tasarruf sağlayacak.”

Bütçe onayı: Formal süreç vs. koridor sohbeti. KOBİ’lerde bütçe onayı çoğu zaman yazılı bir süreçten değil, patronla öğle yemeğindeki sohbetten çıkar. Bunu bilmen gerekiyor.

KOBİ’de her şey senden beklenir. Üretim planlamacısı olarak girdin, bir de bakıyorsun depo düzenleme, tedarikçi görüşmesi, Excel rapor hazırlama, hatta bazen IT destek bile senden isteniyor. Bu kaosu yönetebilmek başlı başına bir yetkinlik.

---

Kariyer Yolları

Endüstri mühendisliği geniş bir alan. Sahada gözlemlediğim ana kariyer patikaları:

• Üretim Planlama: Kapasite, çizelgeleme, MRP yönetimi
• Tedarik Zinciri (Supply Chain): Lojistik, depo, dağıtım optimizasyonu
• Satın Alma (Procurement): Tedarikçi yönetimi, maliyet analizi, sözleşme yönetimi
• Kalite: Kalite yönetim sistemleri, ISO, süreç kontrolü
• Süreç İyileştirme: Yalın üretim (Lean), Altı Sigma (Six Sigma), Kaizen
• İş Analisti (Business Analyst): Yazılım gereksinimleri, süreç modelleme, UAT (Kullanıcı Kabul Testi)
• ERP Danışmanlığı: Kurulum, eğitim, destek — teknik ve fonksiyonel roller
• PMO (Proje Yönetim Ofisi): Proje portföy yönetimi, metodoloji, raporlama
• Operasyonel Mükemmellik (OpEx): Departmanlar arası süreç optimizasyonu
• Dijital Dönüşüm Danışmanlığı: Strateji, teknoloji seçimi, değişim yönetimi
• Bağımsız Danışmanlık: Kendi işini kurma, çoklu sektörde çalışma

Her birinin kendine özgü öğrenme eğrisi var. İlk iki yılında farklı alanlarda deneyim kazanmaya çalış; uzmanlaşmak için acele etme.

---

İlk 90 Gün Aksiyon Planı

0-30 Gün: Gözlem ve Dinleme

• Süreçleri izle, not al ama hemen değiştirmeye kalkma
• Kilit kullanıcılarla tanış, onların dilini öğren
• Mevcut dokümanları (varsa) oku
• Fiziksel olarak sahada bulun: depo, üretim alanı, sevkiyat noktası
• Organizasyon şemasındaki resmi yapıyla fiili karar mekanizmasını karşılaştır
• Hangi veriler nerede tutuluyor, kim giriyor, kim kullanıyor — bunu haritala

30-60 Gün: Hızlı Kazanımlar

• Gözlemlerinden en kolay düzeltilecek bir-iki sorunu belirle
• Küçük ama görünür bir iyileştirme yap (örnek: bir raporun otomasyonu, bir veri giriş formunun sadeleştirilmesi)
• Hızlı kazanımı belgele ve ilgili yöneticiye sun
• Güveni inşa et: “Bu kişi değer üretiyor” algısını yarat
• Proje mezarlığına bir taş daha eklenmesin diye küçük başla

60-90 Gün: Veriye Dayalı İlk Öneri

• İlk iki aydaki gözlem ve verileri birleştir
• Somut bir iyileştirme önerisi hazırla: mevcut durum, hedef durum, maliyet-fayda tahmini
• Öneriyi ilgili paydaşlara sun
• Geri bildirimi al, revize et, uygulamaya geçmek için destek iste
• Sahada öğrenirsin — ilk 90 gün bunun en yoğun dönemidir

---

Sıkça Sorulan Sorular (FAQ)

S: Endüstri mühendisliği mezunları için en iyi başlangıç pozisyonu nedir?
Tek bir “en iyi” yok. Üretim planlama veya iş analisti pozisyonları geniş perspektif kazandırır. Önemli olan pozisyon değil, sahaya yakınlık. Masa başında rapor yazmaktan ibaret bir işe başlarsan öğrenme hızın düşer. Sahada olan, veriyi kaynağında gören, operatörle konuşan pozisyonları tercih et.

S: ERP bilmeden iş bulabilir miyim?
Evet, çoğu iş ilanı “ERP deneyimi tercih sebebidir” der, şart koşmaz. Ama ERP mantığını — sipariş döngüsü, stok hareketi, MRP çalışma prensibi — anlamak seni aday havuzunda öne çıkarır. Üniversite yıllarında bir açık kaynak ERP sistemi kurup denemen bile fark yaratır.

S: Yüksek lisans yapmalı mıyım yoksa sahaya mı çıkmalıyım?
Akademik kariyer hedeflemiyorsan, iki yıl saha deneyimi bir yüksek lisanstan daha fazla kapı açar. Saha deneyiminden sonra yapılan yüksek lisans çok daha verimli olur çünkü teoriyi somut problemlere bağlayabilirsin. Önce saha, sonra akademi — bu sıralamayı tercih ederim.

S: Hangi sertifikalar kariyerime katkı sağlar?
PMP (Project Management Professional) proje yönetimi için, Six Sigma Green/Black Belt süreç iyileştirme için, APICS/CPIM tedarik zinciri için değerlidir. Ama sertifika koleksiyoncusu olma; bir alan seç, derinleş. Sertifika bilgi verir, sahada uygulama beceri kazandırır.

S: AI tüm işimizi elimizden alacak mı?
Rutin analiz ve raporlama işlerini evet, büyük ölçüde devralacak. Ama saha teyidi, paydaş yönetimi, değişim yönetimi ve “insani faktör”ü anlamayı yapay zeka yapamaz. Kendini AI’yı kullanan mühendis olarak konumlandırırsan, değil iş kaybetmek, aranan profil olursun.

---

Bu makalenin doğmasına vesile olan, sorduğu sorularla sahadaki gerçekleri yeniden düşünmemi sağlayan endüstri mühendisliği öğrencisi Senanur Bağlıoğlu‘na teşekkür ederim. Sizin jenerasyonunuzun, bizim bedelini ödeyerek öğrendiğimiz dersleri daha ucuza alabilmesi için bu yazıyı kaleme aldım. Sahada görüşürüz.

---

Koray Çetintaş — Dijital Dönüşüm Mimarı, ERP ve Yapay Zeka Danışmanı. 20+ yıl saha deneyimi, 78+ tamamlanmış proje, 12+ sektörde danışmanlık. Bağımsız yönetim kurulu üyesi.

---

Eğer kariyerinin başındaysan ve sahada neyle karşılaşacağını merak ediyorsan, ya da bir projenin ortasında tıkanıp kaldıysan — 30 dakikalık bir keşif görüşmesi yapalım. Satış yok, baskı yok; sadece senin durumunu dinler, sahadaki deneyimlerimle yönlendirebileceğim noktaları paylaşırım. koraycetintas.com üzerinden ulaşabilirsin.