Tasarım merkezi kuruldu. Peki işin nerede olduğu görünüyor mu?

Bunlar tanıdık geliyor mu?

• Bir projenin hangi aşamada olduğunu öğrenmek için mühendise sormak gerekiyor
• Tasarımcı ayrıldığında dosyalarının nerede olduğunu kimse bilmiyor
• Aynı parçanın birden fazla çizimi dolaşıyor, hangisinin güncel olduğu belirsiz
• Üretim yanlış revizyonla başladı, parça hurdaya gitti
• Hangi projeye ne kadar mühendislik saati harcandığı bilinmiyor
• Çizimden reçeteye geçiş elle yapılıyor, eksik ve geç giriliyor
• Parça listesi, revizyon takibi ve proje raporu Excel'de elle tutuluyor
• Mühendisin günü tasarıma değil, liste ve tablo doldurmaya gidiyor
• Denetim yaklaşınca geriye dönük kayıt üretiliyor

Bunların hepsi aynı yere çıkıyor: bilgi kişilerde duruyor, kurumda durmuyor. Mühendis biliyor, sistem bilmiyor. Bu yüzden bir soruyu cevaplamak için birini bulmak gerekiyor; o kişi gidince cevap da gidiyor.

Bu neden oluyor?

Tasarım merkezi ve mühendislik birimleri genellikle iyi mühendislerle kurulur; sorun yetkinlikte değildir. Sorun, kayıt tutmanın işin kendisi değil, işin üstüne eklenmiş ayrı bir görev olarak kurgulanmasıdır.

Mühendis için asıl iş, projeyi çıkarmaktır. Dosyayı doğru klasöre koymak, revizyon numarasını yükseltmek, harcanan saati yazmak; bunlar teslim baskısı altında hep sonraya kalır. Sonraya kalan da çoğu zaman hiç yapılmaz. Zamanla dosyalar kişisel bilgisayarlara dağılır, revizyon takibi dosya adına yazılan eklerle yürütülmeye çalışılır, saat dağılımı ise ay sonunda tahminle doldurulur.

Bu noktada alınan yazılım da işe yaramaz. PDM veya PLM lisansı satın alınır, kurulum yapılır, eğitim verilir; ama altı ay sonra kimse kullanmıyordur. Çünkü eksik olan araç değil, aracın içine koyulacak tanımlı düzendir.

Ürün yaşam döngüsü nerede kopuyor?

Bir ürün fikir olarak doğar; çizime döner, reçeteye dönüşür, üretime iner, sahada revizyon görür, sonunda yedek parça olarak yaşamaya devam eder. Bu halkaların hepsi birbirine bağlıdır ve her biri bir öncekinin verisiyle çalışır.

Sorun genellikle halkaların kendisinde değil, aralarındaki geçişlerde çıkar. Tasarım kendi içinde düzgün çalışır, üretim kendi içinde düzgün çalışır; ama tasarımdan üretime geçerken veri elle taşınır ve orada eksilir. Revizyon çıktığında da geriye doğru aynı kopukluk yaşanır: değişiklik çizimde yapılır, reçeteye yansımaz, sahadaki ürünle sistemdeki ürün birbirinden ayrılır.

Her firmada kopan halka farklıdır. Birinde çizimden reçeteye geçiş, diğerinde revizyonun üretime ulaşması, bir başkasında yedek parça talebinin hangi versiyona ait olduğunun bilinmemesi. Yapılacak ilk iş, sizin zincirinizin tam olarak nerede koptuğunu bulmaktır.

Ne yapıyorum?

Proje dosyalama standardı

Her projenin nerede başlayacağı, hangi yapıda ilerleyeceği ve hangi belgeleri içereceği tanımlanır. Proje açılırken yapı hazır gelir; mühendisin karar vermesi gereken bir şey kalmaz.

Buradaki zorluk klasör şeması çizmek değil. Mühendislerin halihazırda kullandığı, kimsenin yazmadığı ama herkesin bildiği bir düzen zaten vardır. Standardı sıfırdan dayatırsanız kimse uymaz, birkaç hafta sonra eski alışkanlığa dönülür. O yüzden önce mevcut davranış anlaşılır, standart onun üzerine kurulur. Kabul edilmeyen standart, olmayan standarttan kötüdür.

Revizyon ve versiyon disiplini

Model ve çizim dosyaları tek ve kontrollü bir kaynakta tutulur. Revizyon numarası dosya adına değil sistemin kendisine yazılır, geçmiş sürümler korunur. Üretime giden çıktı da bu kaynaktan üretilir.

Asıl karar, neyin revizyon sayılacağıdır. Her küçük değişiklik yeni revizyon açarsa numara enflasyonu olur ve kimse takip edemez; hiçbiri açmazsa da tarihçe kaybolur. Sınırın nereye çizileceği ürüne ve üretim şekline göre değişir; kalıplı bir parçayla kaynaklı bir konstrüksiyonda aynı kural işlemez. Bu sınır doğru çizilmezse sistem kurulur ama kullanılmaz.

Adam-saat dağılımı

Hangi projeye ne kadar mühendislik saati gittiği, iş biterken değil yürürken kayda geçer. Bu hem proje maliyetini gerçek kılar hem de birimin kapasitesini görünür yapar.

Bu konunun teknik tarafı kolaydır; zor tarafı insandır. Saat kaydı, mühendise denetlendiği hissini verdiği anda içi boş doldurulmaya başlar ve elinizde gerçeği yansıtmayan bir veri kalır. Kayıt kırılımının ne kadar ince olacağı da buna bağlıdır: fazla ince olursa kimse tutmaz, fazla kaba olursa hiçbir şey anlatmaz. Doğru seviye birimin büyüklüğüne ve proje tipine göre belirlenir.

Elle yapılan işlerin azaltılması

Mühendislik biriminde tekrar eden elle işler zamanla normalleşir: parça listesinin tabloya geçirilmesi, revizyonun ayrı bir dosyada takibi, ay sonu raporunun elle derlenmesi. Tek tek bakınca küçük görünür, toplamda mühendisin gününün önemli bir kısmını alır ve her seferinde hata riski taşır.

Bu işlerin bir kısmı mevcut yazılımın doğru kullanılmasıyla çözülür. Kalanı için gerektiğinde kendi çözümümü geliştiririm; aradaki boşluğu üçüncü bir yazılım almadan kapatabiliyorum. Amaç yeni bir sistem kurmak değil, elinizdekiler arasındaki kopukluğu gidermek.

Tasarımdan üretime veri akışı

Çizimden reçeteye, reçeteden ERP'ye giden yol kurulur. Bu geçiş elle yapıldığı sürece eksik ve geç kalır. ERP tarafındaki stok ve maliyet düzeni ayrı bir konu; onu ERP, reçete ve maliyet sayfasında anlattım.

Zorluk, iki tarafın ürünü farklı gözle görmesinden çıkar. Mühendis ürünü montaj mantığıyla kurgular; üretim ve satın alma ise onu tedarik ve iş emri mantığıyla görür. Aynı ürün ağacı, iki tarafta iki farklı yapıya karşılık gelir. Bu ayrımı çözmeden kurulan aktarım, hatayı hızlandırmaktan başka işe yaramaz. Bu yüzden önce iki tarafın ortak dili tanımlanır; hangi tasarım kaleminin karşılığında ne olduğu tek tek kararlaştırılır. Aktarım en son kurulur ve o noktada zaten mekanik bir iş haline gelmiştir.

Yeni kuruyorsanız

En doğru zaman budur. Yapı henüz oluşmadan tanımlanırsa, sonradan düzeltmenin maliyetiyle hiç karşılaşmazsınız. Dosyalama standardı, revizyon kuralları ve saat takibi birim çalışmaya başladığı gün yerinde olur.

Merkeziniz yıllardır çalışıyorsa

Geç değildir ve işleyişi durdurmak gerekmez. Yürüyen projeler mevcut düzeninde devam ederken yeni yapı paralel kurulur. Önce dosyaların ve kayıtların envanteri çıkarılır, sonra standart tanımlanır, ardından yeni açılan projeler yeni yapıda başlar. Eski projeler ihtiyaç oldukça taşınır.

Neden bağımsız bir danışman?

Hiçbir yazılım firmasından komisyon almıyorum, lisans satmıyorum. Bu, mevcut sisteminizi savunmak ya da yenisini satmak gibi bir çıkarım olmadığı anlamına geliyor. Elinizdeki araç yeterliyse onu işler hale getiririm; yetmiyorsa bunu açıkça söyler, hangi yönde gitmeniz gerektiğini anlatırım.

Ürün yaşam döngüsünün her iki ucunu da gördüm: fikrin çizime döndüğü yeri de, o çizimin tezgahta karşılık bulduğu yeri de. Tasarım merkezi süreçlerini hem içeriden yürüttüm, hem de dışarıdan danışmanlık verdim.

Sık sorulan sorular

Murat Özdemir — İzmir merkezli bağımsız süreç danışmanı. Kurulu kalıp çalışmayan sistemleri sahada, firmanın kendi ekibiyle birlikte işler hale getiriyorum. Genellikle 20-500 kişilik üretim firmalarıyla çalışıyorum. Hakkımda · Nasıl çalışırız · ERP, reçete ve maliyet

Birlikte çalıştığım firmalardan bazıları

★★★★★

Beraber çalışma fırsatımız oldu. Reçeteler manuel hazırlanıyordu ve sürekli farklılıklar çıkıyordu. CAD ortamından otomatik reçete çıkaran yapıyı kurdu, operasyonel iş akışlarını düzenledi. En değerlisi de şu. Kurduğu sistem o gittikten sonra da çalışmaya devam etti.

Önder Şenli

★★★★★

Ürünlerin hammadde, yarı mamul ve mamul bazında doğru kodlanması, bu yapının ERP sistemi içerisinde etkin şekilde kurgulanması ve süreçlere uygulanması konusunda beklentilerimizi karşıladı. Ekstralardan kaçmayarak, isteklerimize cevap veren Murat Özdemir'e teşekkür ederim.

Akın Budakoğlu

Google işletme profilinde bırakılan değerlendirmelerdir.

Proje içerikleri firmalara özeldir. Referans görüşmesi talep edebilirsiniz.