Teknik resim, CAD dosyası, reçete ve numune bilgisinin hangi sürümünün geçerli olduğunu tek bir yerden belirleriz. PDM dosyayı ve revizyonu yönetir; PLM bunu ürünün fikirden seri üretime uzanan tüm ömrüne, değişiklik onaylarıyla birlikte yayar. Sahaya inen resmin doğru resim olduğu tartışma konusu olmaktan çıkar.
Bir imalat firmasında en pahalı hatalardan biri sessizce olur: tezgâha inen teknik resim, geçerli olan resim değildir. Parça üretilir, ölçü tutmaz, hurdaya çıkar ya da daha kötüsü müşteriye gider. Sonradan bakıldığında herkes doğru davranmıştır; ustabaşı elindeki çıktıyı kullanmıştır, teknik ofis revizyonu yapmıştır, satın alma eski reçeteyle malzeme istemiştir. Sorun kişilerde değil, geçerli sürümün nerede olduğunun tanımsız olmasındadır. Dosyalar ortak klasörde durur; adları son, son_v2, son_revize_yeni gibi birikir ve bir süre sonra hangisinin üretime gittiğini kimse kesin olarak söyleyemez hale gelir. Maliyet de hurdayla sınırlı kalmaz; müşteriye giden yanlış parça, sonraki siparişin de sorgulanmasına yol açar.
Aynı sorun her sektörde farklı bir kılıkta çıkar. Makine ve metal işinde konu CAD dosyası ve montaj ağacıdır: bir parçanın değişmesi, o parçayı kullanan diğer montajları da etkiler ama bu ilişki genellikle yalnızca tasarımcının kafasındadır. Tekstil ve halı tarafında konu koleksiyon ve numunedir; desen, iplik reçetesi, renk varyantı ve numune onay geçmişi e-posta eklerine dağılır, aynı numune ikinci kez dokunur. Gıdada reçete ile etiket bilgisi aynı yerden yönetilmediğinde ambalaj ve içerik uyuşmaz. Ortak nokta şudur: ürünün teknik gerçeği bir sistemde değil, insanların hafızasında ve dosya adlarında tutulmaktadır. Sektör değişse de çözüm aynı yerden başlar, teknik veriyi dosyadan çıkarıp kayda almaktan.
İki terim burada sıklıkla karışır, ayırmakta fayda var. PDM (Product Data Management, ürün veri yönetimi) dar ve somuttur; teknik dosyaların kasası gibi çalışır. Dosyayı kim aldı, hangi revizyon geçerli, hangi dosya hangi parçaya ait, eski sürümler nerede duruyor sorularını yanıtlar. PLM (Product Lifecycle Management, ürün yaşam döngüsü yönetimi) daha geniştir; ürünün fikir aşamasından tasarıma, numuneden seri üretime, oradan revizyonlara ve üretimden kaldırılmasına kadar tüm ömrünü yönetir. PDM olmadan PLM kurulmaz; PLM olmadan PDM ise düzenli bir dosya arşivi olarak kalır. Uygulamada çoğu firmanın ihtiyacı PDM ile başlar, değişiklik yönetimi eklendikçe PLM'e doğru genişler.
Dürüst olmak gerekirse bu iş, yazılımdan çok disiplin işidir. Sistemin tek başına yapabileceği şey, geçerli sürümü tek bir yerde tutmak ve değişikliği onaysız geçirmemektir; teknik ofisin dosyayı sisteme koymayı alışkanlık haline getirmesi ise zaman alır. Ayrıca biz CAD yazılımı yazmıyoruz: kullandığınız tasarım programı yerinde kalır, biz onun ürettiği dosyaların sürümünü, ilişkisini ve onay akışını yönetiriz. Üç boyutlu model içinde geometri düzenleme, otomatik ölçülendirme veya mukavemet simülasyonu bizim kapsamımız değildir. Sistemin kurulmuş olması, ustabaşının elindeki eski çıktıyı da kendiliğinden ortadan kaldırmaz; sahaya inen çıktının nasıl kontrol edileceği ayrıca kurgulanır. Kapsamı baştan böyle çizmek, sonradan karşılanamayacak bir beklenti üretmekten iyidir.
Sipariş bazında makine, hat veya kalıp tasarlayan firmalar. Her işte önceki projeden kopyalanıp elle değiştirilen dosyalar birikir; hangi müşteriye hangi konfigürasyonun gittiği ancak proje klasörü tek tek açılarak anlaşılır. Teknik veri yönetimi bu birikimi aranabilir hale getirir ve benzer iş geldiğinde teklif hazırlama süresini de kısaltır.
Sezonluk desen, renk varyantı ve numune süreci yürüten üreticiler. Numunenin hangi reçeteyle dokunduğu, müşterinin hangi varyantı onayladığı ve seri üretime hangi sürümün gittiği tek kayıtta tutulmadığında aynı numune ikinci kez üretilir. Hangi numunenin hangi tarihte kime gönderildiği ve sezon sonunda hangisinin satışa dönüştüğü de aynı kayıttan okunur.
Müşteriye göre uyarlanan çok sayıda varyantı olan üreticiler. Ürün ağacındaki tek bir parçanın değişmesi onlarca ürünü etkiler; bu etkinin elle takip edildiği yerde yanlış malzemeyle üretim er geç kaçınılmaz hale gelir. Etki analizi bu firmalarda ilk günden hissedilir; revizyonun hangi siparişten itibaren geçerli olacağı da kayda bağlanır.
Otomotiv, savunma veya kurumsal ihracat müşterisiyle çalışan, teknik dokümanın geçmişini kanıtlaması istenen firmalar. Hangi revizyonun ne zaman ve kimin onayıyla yürürlüğe girdiğinin kaydı, denetimde ilk sorulan şeylerden biridir. Aynı kayıt, sonradan bir müşteri şikayeti geldiğinde ürünün hangi revizyonla üretildiğini de gösterir.
| Yetenek | Ne sağlar |
|---|---|
| Teknik dosya arşivi ve sürümleme (PDM) | CAD dosyaları, teknik resimler, reçeteler ve şartnameler tek kasada tutulur. Her kayıt için sürüm geçmişi saklanır; eski sürümler silinmez, arşivde erişilebilir kalır. Dosya adına son yazma alışkanlığı yerine, hangi sürümün geçerli olduğunu sistemin söylemesi esastır. Dosyanın yanında hangi ürüne, hangi müşteriye ve hangi projeye ait olduğu öznitelik olarak tutulur; arama da bu alanlar üzerinden yapılır. |
| Revizyon, çek-al ve düzenleme kilidi | Bir dosya üzerinde aynı anda iki kişinin çalışıp birbirinin işini ezmesi engellenir. Dosyayı alan kişi kilitler, işini bitirdiğinde yeni revizyon olarak geri koyar. Kimin ne zaman neyi değiştirdiği kayıtta durur; sonradan çıkan tartışmayı bitiren şey genellikle bu kayıttır. Her revizyona kısa bir değişiklik notu zorunlu tutulur, unutulan kilitler ise süre aşımıyla otomatik açılır. |
| Onay akışı ve yürürlük durumu | Her teknik doküman bir durum taşır: taslak, incelemede, onaylı, revize edildi, kullanımdan kaldırıldı. Onay akışı role göre kurulur ve onaysız hiçbir doküman üretime çıkmış sayılmaz. Sahaya inen çıktının üzerinde revizyon numarası ile durum bilgisi görünür biçimde yer alır. Onaylı bir doküman revize edildiğinde önceki sürüm otomatik olarak geçersiz duruma düşer ve durum değiştirme yetkisi rolle sınırlanır. |
| Ürün ağacı (BOM) ilişkisi ve etki analizi | Teknik dosyalar ürün ağacındaki parçalarla ilişkilendirilir. Bir parça revize edildiğinde, o parçayı kullanan tüm ürün ve montajlar listelenir; değişikliğin nereye dokunacağı onaydan önce görülür. Bu liste, uygulamada en sık atlanan ve atlandığında en pahalıya mal olan adımdır. Aynı ilişki tersten de okunur: bir üründe hangi parçaların, hangi revizyonlarla kullanıldığı tek listede çıkar. |
| Değişiklik yönetimi (ECR / ECO) | Değişiklik talebi (ECR) açılır, gerekçesi ve etkilenen kalemler yazılır; onaylanırsa değişiklik emrine (ECO) dönüşür. Emirde yürürlük tarihi, mevcut stoğun ve devam eden siparişlerin ne olacağı belirtilir. Böylece revizyon, kimsenin haberi olmadan gerçekleşen bir olay olmaktan çıkar. Değişikliğin üretim, satın alma ve kaliteye duyurulması da aynı akış içinde yapılır ve kapanan her emir arşivde kalır. |
| Numune ve koleksiyon yönetimi | Numune talebi, üretilen numunenin reçetesi, müşteri geri bildirimi ve onay durumu tek kayıtta izlenir. Koleksiyon bazında hangi varyantın hangi müşteriye gittiği ve hangisinin seri üretime alındığı görülür. Onaylanmış numunenin reçetesi doğrudan üretim tarafına devredilir. Numune maliyeti ile harcanan süre kaydedilir, reddedilen numunelerin gerekçesi ayrıca tutulur; koleksiyonun toplam numune yükü böylece ölçülebilir. |
| Arama, yeniden kullanım ve erişim yetkisi | Parça numarası, malzeme, müşteri veya öznitelik üzerinden arama yapılır; benzer bir parça daha önce tasarlandıysa sıfırdan çizilmez. Dosyalara erişim role göre sınırlanır; tedarikçiyle paylaşılacak dokümanlar ayrı bir yetkiyle ve kim ne zaman indirdi kaydıyla verilir. Kullanımdan kaldırılmış dosyalar aramada varsayılan olarak görünmez, istendiğinde arşivden çağrılır; bu tek başına yanlış dosya kullanımını azaltır. |
Teknik ofiste dosyaların bugün nerede durduğunu, hangi adlandırmanın kullanıldığını ve revizyonun bugün nasıl duyurulduğunu birlikte çıkarırız. Çoğu firmada burada yazılı bir kural yoktur; ilk iş, fiilen işleyen kuralı görünür kılmak ve boşluklarını göstermektir. Bu aşama genellikle bir ila iki hafta sürer ve teknik ofisle birlikte yürütülür.
Parça numarası, doküman kodu ve revizyon gösteriminin nasıl olacağı yazılı olarak kararlaştırılır. Bu adım teknik görünür ama aslında bir yönetim kararıdır; sonradan değiştirilmesi maliyetlidir, o yüzden tek satır yazılım yazılmadan önce netleşir. Mevcut numaralandırma işliyorsa değiştirmeyiz; değiştirmenin bedeli çoğu zaman faydasından büyüktür.
Sistem kurulur ve mevcut dosyalar taşınır. Tamamını taşımak yerine hâlâ üretimde olan ürünlerle başlarız; eski arşiv ikinci aşamaya bırakılır. Taşıma sırasında mükerrer ve ölü dosyaların ayıklanması işin en zahmetli ama en değerli kısmıdır. Dosyalar öznitelikleriyle etiketlenir, aksi halde arama işe yaramaz; bu aşama dört ila sekiz hafta sürebilir.
Onay rolleri, doküman durumları ve değişiklik emri akışı açılır. Önce sınırlı sayıda ürün grubunda denenir; akış sahada tıkanıyorsa adım sayısı azaltılır. Fazla onay basamağı, sistemin etrafından dolaşılmasının en yaygın nedenidir. Hangi değişikliğin onay gerektirmediği de tanımlanır; her küçük düzeltmeyi onaya sokmak akışı kilitler.
Onaylı revizyonun üretim, satın alma ve kalite tarafına nasıl ulaşacağı bağlanır; ERP veya üretim takip sistemiyle entegrasyon kurulur. Ekibe devir yapılır, kurallar yazılı bırakılır. İlk aylarda revizyon sayısı ve onay süreleri birlikte izlenir; akış tıkanıyorsa sadeleştirilir. Kaynak kod ve tüm teknik veri size teslim edilir.
PDM teknik dosyaların ve revizyonların yönetimidir: hangi dosya geçerli, kim değiştirdi, hangi parçaya ait. PLM ise ürünün fikirden seri üretime, revizyonlardan üretimden kaldırılmasına kadar tüm ömrünü kapsar; değişiklik yönetimi, numune süreci ve ürün ağacı ilişkileri buraya girer. Uygulamada çoğu firma PDM ihtiyacıyla gelir, çünkü acıyan yer yanlış resimdir. Kurulum PDM ile başlar, değişiklik ve numune akışları eklendikçe PLM'e genişler. Baştan tam PLM kurmaya çalışmak, kullanılmayan bir sistem üretme riski taşır.
Hayır ve o alana girmiyoruz. Kullandığınız tasarım programı yerinde kalır, tasarım orada yapılmaya devam eder. Bizim kurduğumuz katman o dosyaların sürümünü, ilişkisini, onayını ve arşivini yönetir. Model içinde geometri düzenleme, otomatik teknik resim üretimi veya mukavemet simülasyonu kapsamımız dışındadır. Yaptığımız iş, tasarım programının bıraktığı yerden devam edip dosyayı kurumsal bir kayda dönüştürmek ve o kaydı üretim, satın alma ve kalite tarafına doğru biçimde ulaştırmaktır.
Çakışmaz; ikisi farklı ürün ağacına bakar. ERP'deki ağaç üretim ve maliyet içindir: malzeme, miktar, birim. Teknik taraftaki ağaç ise tasarım ilişkisini taşır: hangi parça hangi montajda, hangi resimle, hangi revizyonla. Doğru kurulum, teknik tarafta onaylanan revizyonun ERP'ye kurallı biçimde aktarılmasıdır. Logo, Mikro, Netsis veya Canias kullanıyorsanız bu sistem onların yerine geçmez; yanlarında çalışır ve onlara onaylı veriyi besler.
Hayır ve genellikle tavsiye de etmiyoruz. Hâlâ üretimde olan ürünlerle başlanır; kullanılmayan eski arşiv olduğu yerde bırakılır veya salt okunur biçimde aktarılır. Toplu taşımanın asıl zorluğu kopyalama değil, mükerrer ve hangisinin geçerli olduğu bilinmeyen dosyaların ayıklanmasıdır; bu iş de teknik ofisin zamanını ister. Kapsamı dar tutmak, projeyi aylarca dosya temizliğine kilitlemekten iyidir.
Bu gerçek bir risktir ve başarısız kurulumların çoğunun nedenidir. Direncin kaynağı genellikle ek yüktür: her dosya için doldurulacak on alan varsa kimse doldurmaz. Bu yüzden zorunlu alan sayısını en aza indirir, kaydetme adımını tasarımcının normal akışına yerleştiririz. Bir diğer şart, ortak klasörün bir tarih verilerek yazılabilirlikten çıkarılmasıdır; iki kaynak paralel açık kaldığı sürece eski alışkanlık kazanır.
Sürümlenmiş bir teknik dosya arşivi ve geçerli revizyonun tek kaynaktan belli olması; kilitli düzenleme ile tam bir değişiklik geçmişi; role göre onay akışı ve doküman durumları; ürün ağacı ilişkisi ve etki analizi; değişiklik talebi ile emri süreci; numune ve koleksiyon takibi; aranabilir, yetkilendirilmiş erişim. Kaynak kod, veritabanı ve tüm teknik veri size aittir.
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
Bina, kat, oda ve masa envanterini tek kayda alır; kira ile abonelik sözleşmelerinin tarihlerini, periyodik bina bakımlarını, yangın ve güvenlik ekipmanının kontrol takvimini aynı sistemde yürütürüz. Tesisin gideri de böylece bina ve alan bazında görünür hale gelir.
Detay →Personel özlüğünü, belgeleri, izin ve devamsızlığı, organizasyon şemasını ve çalışan self-servisini tek kayıtta toplayan bir insan kaynakları katmanı kurarız. Bordronun yerine geçmez; ona giden veriyi doğru ve izlenebilir biçimde hazırlar, puantaj ve PDKS tarafıyla aynı personel kaydı üzerinden bağlanır.
Detay →İlanın hazırlanmasından teklife ve işe başlama devrine kadar tüm aday sürecini tek akışta yürüten bir sistem kurarız. Başvurular hangi kanaldan gelirse gelsin aranabilir bir havuzda birikir, değerlendirme ortak forma yazılır, saklama süresi ve imha kayda geçer.
Detay →Deponuzdaki her rafı ve gözü adresler, her hareketi barkodla kayda alırız. Mal kabulden yerleştirmeye, toplama rotasından sevkiyat kontrolüne kadar akış el terminalinden yürür; ERP'nizdeki miktar bilgisinin altına malın fiziksel yerini ve kim tarafından ne zaman taşındığını ekleriz.
Detay →Giriş, proses ve son kontrol kayıtlarını sahada tabletten alır; uygunsuzluk çıktığında malı karantinaya alır, DÖF/CAPA akışını başlatır ve kapanışını takip ederiz. Ölçüm, sertifika ve onaylar parti bazında birikir; ISO 9001 denetimine geriye dönük klasör derleyerek değil, hazır dosyayla girersiniz.
Detay →Ürün ağacınızı (BOM) esas alarak hangi malzemeden ne kadar ve ne zaman gerektiğini hesaplar; mevcut stok, açık siparişler ve tedarik sürelerini düşerek satın almaya tarihli sipariş önerisi çıkarırız. MRP II katmanıyla aynı planı makine kapasitesi ve iş gücü açısından da sınarız.
Detay →
