PLM Yazılımları

ÖZET

PLM yazılımları günümüzde gittikçe artan bir ilgi ile karşı karşıyadır. Bunun sebebi ise PLM kullanan bazı şirketlerin PLM ile sağladıkları kazanımları açık bir şekilde ifade etmelerinden kaynaklanmaktadır. Şirketler özellikle pazara çıkma süresi, ürün kalitesinin arttırılması ve ürün maliyetlerinin düşürülmesi gibi önemli faydaları belirtmektedir. Bu durum PLM yazılımı kullanmayan diğer şirketlerinde iştahını kabartmaktadır. Ancak PLM yazılımı alan şirketlerin büyük bir kısmı (özellikle Türkiye’de) PLM’i tüm fonksiyonları ile etkin bir şekilde kullanamamaktadır. Bu sebeple PLM ile sağlanan kazançları sağlayamamakta veya çok düşük miktarlarda sağlamaktadır. Bu durumun, bir süre sonra PLM yazılımlarının şirket içerisinde âtıl bir duruma gelmesine sebep olduğu görülmektedir. Böylece yapılan büyük yatırım maliyetleri geri dönüş sağlayamamakta şirketler bu durumdan zarar görmektedir. Bu sebeple bu makale kapsamında PLM Yazılımlarının şirketlere nasıl daha iyi kurulacağından, kurulum aşamasında yaşanabilecek zorluklardan ve dikkat edilecek hususlardan bahsedilmiştir. Son olarak Savunma Sanayinde yer alan bir şirkete ait PLM uygulama yol haritası paylaşılmış ve bu yol haritasında yer alan modüller ve alt süreçler için kritik gereksinimler tanımlanmıştır. Bu makale, şirketlerin etkili ve verimli bir PLM sistemi kurmalarına yardımcı olmak amacıyla yazılmıştır.

Anahtar Kelimeler: PLM Uygulama Yol Haritası, PLM Uygulama Metodolojisi, PLM Sistemlerinin Uyarlanması ve Uygulanması, PLM Dönüşümü,

Abstract

PLM software is facing increasing interest today. The reason for this is that some companies using PLM openly express the gains they have achieved with PLM. Companies specifically cite important benefits such as time to market, improved product quality and reduced product costs. This situation whets the appetite of other companies that do not use PLM software. However, most of the companies that buy PLM software (especially in Turkey) cannot use PLM effectively with all its functions. For this reason, it cannot provide the gains provided by PLM or it provides very low amounts. It is seen that this situation causes PLM software to become idle within the company after a while. Thus, large investment costs cannot provide a return, and companies suffer from this situation. For this reason, within the scope of this article, how to better install PLM Software in companies, the difficulties that may be experienced during the installation phase and the points to be considered are mentioned. Finally, the PLM implementation roadmap of a company in the Defense Industry was shared and critical requirements were defined for the modules and sub-processes in this roadmap. This article was written to help companies set up an effective and efficient PLM system.

Keywords: PLM Implementation Roadmap, PLM Implementation Methodology, PLM Systems Adaptation and Implementation, PLM Transformation,

1 Giriş

Ürün Yaşam Döngüsü Yönetimi yazılımları, bir şirketin ürünlerini fikir aşamasından başlayarak tedavülden kaldırılıncaya veya geri dönüştürülünceye kadar olan tüm yaşam döngüsü içerisindeki süreçlerin yönetilmesi amacıyla kullanılmaktadır. Ürün yaşam döngüsü (PLM) yazılımlarının temelini Bilgisayar destekli tasarım (CAD) yazılımları oluşturmaktadır. 1970’li yıllarda ürün geliştirme süreçlerinin hızlandırılması amacıyla kullanılan Bilgisayar Destekli Tasarım (CAD) yazılımları 1980’li yılların başında kişisel bilgisayarların uygun fiyatlı bir şekilde piyasaya sunulmasıyla birlikte çok daha aktif bir şekilde kullanılmaya başlanmıştır. Tasarımların bilgisayar ortamına taşınmasıyla birlikte yapılan tüm çizimlerin ve dokümanların yönetilmesi gittikçe daha zor bir hale gelmiştir.  Bu durum günümüzde PLM sisteminin temelini oluşturacak olan Ürün veri yönetimi (PDM) sisteminin geliştirilmesine sebep olmuştur. CAD verileri, modeller, üretim detayları ve diğer dokümanlar olmak üzere, ürün ile ilgili olan tüm bilgilerin yönetilmesi için PDM sistemi kullanılmaya başlanmıştır. Ürün veri yönetimi (PDM) sayesinde tasarımlar üzerindeki fikir çatışmaları ve mühendislik değişiklikleri azalmıştır. Bu sayede mühendisler müşterilerin talep ettikleri yeni ürünleri tasarlamak için daha fazla zaman bulabilmişlerdir. 1990’lı yılların sonuna doğru yönetilen verilerin kapsamı genişletilerek ürün ile ilgili tüm süreçleri kapsayacak şekilde olan PLM sistemleri geliştirilmiştir. PLM sisteminde, Gereksinim Yönetimi, Üretim Yönetimi, Proje Yönetimi, Kalite Yönetimi ve Servis Yönetimi süreçleri yönetilmektedir.

PLM sistemlerini uygulayan şirketler farklı sektörlerde bulunabilir. Otomotiv ve ulaşım sektörü, havacılık ve savunma sektörü, makine imalat sektörü vb. sektörler buna örnek olarak gösterilebilir. Bu sektörler benzersiz özelliklere sahip oldukları için farklı PLM uygulamalarına sahiptir. Ayrıca şirketin tedarik zinciri içerisinde bulundukları konumu (Orijinal Ekipman Üreticisi (OEM), Modül Sistem Alt yüklenici PLM firması (Tier 1) veya Bileşen Alt yüklenici PLM firması (Tier 2)), PLM algısını güçlü bir şekilde değiştirmektedir. Bu farklılıklara rağmen, şirketler ortak iş hedefleri için PLM'e yatırım yapmaktadır. PLM'e yatırım yapmanın en önemli itici güçleri şunlardır;

• Daha kısa ürün yaşam döngülerine duyulan ihtiyaç,
• Bileşenler ve işlevsellik açısından daha karmaşık ürünler için teşvik,
• Küreselleşme ve dış kaynak kullanımı eğilimleri ve sonuç olarak karmaşık tedarik zincirleri,
• Daha talep kâr müşteriler nedeniyle ürünlerin özelleştirilmesi ihtiyacı
• Güvenlik, çevre ve ürün güvenilirliği düzenlemeleri gibi artan düzenlemeler.

PLM ile ilgili konularda başarılı olan şirketler, artan yenilikçilik yeteneği, daha kısa pazara sunma süresi, artan karlar, yaşam döngüsünün sonlarında daha az mühendislik değişikliği, sahada daha az ürün hatası ve daha yüksek verimlilik gibi faydalar bildirmektedir.

Ürün Yaşam Döngüsü Yönetimi yazılımları (PLM), dinamik ve rekabetçi pazarlarda faaliyet gösteren şirketler için giderek daha önemli hale gelmektedir. Ancak şirketler PLM sistemlerini tüm modülleri ile uygulamaya almakta ciddi zorluklar yaşadığı görülmektedir. Bu makale kapsamında PLM sistemlerinin faydaları, uygulama aşamasında yaşan zorluklar, dikkat edilecek hususlar, PLM uygulama metodolojisi ve örnek bir yol haritası paylaşılacaktır. Bu çalışmanın şirketlerin PLM devreye alma sürecinde yaşadığı zorlukları önemli ölçüde azaltacağı düşünülmektedir.

2 PLM ile Elde Edilecek Kazanımlar

Şirketler elde edeceği maliyet tasarrufunu veya iş potansiyelindeki artış ile ilgili faydaları diğer kullanıcı şirketler tarafından doğrulandığını görmeden

Şirketler, iş potansiyeli veya maliyet tasarrufu olarak sayılan faydalar hakkında diğer kullanıcı şirketlerden gelen geri bildirimler olmadığı sürece yatırım yapmaya istekli değildir. PLM faydaları genellikle doğası gereği “yumuşaktır” ve kolayca parasal faydalara aktarılamaz. PLM'nin uygulanması, ürün geliştirme süresinin haftalardan günlere düşmesine neden olabilir ve ayrıca imalat, servis, bakım ve destekte de önemli değişikliklere neden olabilir.

En büyük faydalar, daha hızlı ürün geliştirme süresi ve daha hızlı pazara sunma süresi ile olarak belirtilebilir. PLM sistemleri ayrıca örgütsel öğrenmeyi iyileştirme ve bilgi birikimine yardımcı olma olanağına sahiptir. PLM'in genel faydaları ise şu şekilde tanımlanabilir:

• Müşteri ihtiyaç bilgilerine daha iyi erişim,
• Daha yenilikçi fikirler,
• Geliştirilmiş satış süreci,
• Dağıtılmış geliştirmeyi kullanmak,
• Yap-satın al kararları için daha iyi olanaklar,
• Geliştirilmiş kullanıcı desteği,
• Daha az ürün kusuru,
• Servis ve bakım için birikmiş bilgi birikimini kullanmak.
• Ürün parçalarının daha etkili yeniden kullanımı ve ürünlerin elden çıkarılması.

PLM sistemleri genellikle şirketler için özelleştirilmiş olduğundan, faydalar şirketler arasında değişir ve sistem konfigürasyonunun nihai sonucuna bağlıdır. PLM sistemlerinin genel faydaları, bilginin, belgelerin ve uzmanlığın kolay ve hızlı bir şekilde yayılmasıdır. Ayrıca ürün geliştirme faaliyetlerinin dağıtılması ile ilgili riskleri azaltır. Bilginin daha iyi organize edilmesi ve bulunmasını kolaylaştırır, bu da üretkenliği iyileştirmeyi mümkün kılar. Standardizasyon ve şeffaflık, süreç ve ürün kalitesini artırır. Müşteri talepleri ve geri bildirimleri geliştirme ve üretimde etkin bir şekilde kullanılabilir. Ürün ve süreç sorunları daha hızlı önceliklendirilerek çözülebilir. Karmaşık ürün tasarım ve üretim süreçlerinin kontrolü daha kolay hale gelir ve piyasa, standart ve mevzuattaki değişikliklere daha hızlı tepki vermek mümkün olur. Ayrıca ürün planlamadaki hatalar azalır, bu da ürün geliştirme maliyetlerini düşürür, çünkü gerekli değişiklikler süreç içinde daha erken yapılabilir ve test maliyetleri daha düşük olur. Bilginin eşzamanlı olarak yayılması, daha hızlı karar vermeyi sağlar ve sıralı bilgi paylaşımına gerek yoktur. Ayrıca örtük mühendislik bilgisi daha iyi kodlanabilir ve kullanılabilir. PLM'i etkin kullanan şirketlerde mühendisler, değer katan görevler için diğer şirketlere göre daha fazla zaman bulur. Bunun nedeni, gelişmiş iletişim ve bilginin erişilebilirliğidir. İş süreçleri daha standart ve otomatik hale gelir ve mevcut bilgi ve tasarım modellerinden yararlanmak, daha kaliteli ve daha hızlı pazara sunma süresi sağlar. Bunun pazar payı, kârlar ve müşteri sadakati üzerinde olumlu bir etkisi vardır.

3 PLM Yazılımlarının Uygulanmasının Zorlukları

Şirketlerde PLM'in uygulama zorlukları, bir yanda teknoloji, diğer yanda bilgi birikimi veya bilgi yönetimi ile ilgili olabilir. Büyük şirketlerde PLM uygulama projesi, genellikle büyük bir proje olarak organize edilen uzun vadeli bir süreçtir. Sistemlerin özelleştirilmesi gerektiğinden, toplam maliyetlere satın alma, bakım ve hizmet dahil edilmelidir. Ayrıca iş süreçlerinin felsefesi de değişeceğinden bu durum kültürel ve zihinsel bir değişimi de beraberinde getirmektedir. Küçük şirketlerde önemli süreç değişiklikleri korkusu, PLM benimseme ve uygulama sürecini yavaşlatmaktadır. Şirkette kullanılan CAD gibi diğer sistemlere entegrasyon önemli bir zorluk teşkil etmektedir. Kullanıcı eğitimleri ek maliyet olarak gelmektedir. Ayrıca teknik danışmanlık ihtiyacı da bulunmaktadır. Şirketler maliyetler, altyapı gereksinimleri ve muhtemelen süreçler ve stratejilerdeki değişiklikler nedeniyle PLM sistemlerini edinmekten ve uygulamaktan korkmaktadır. Süreç ve konfigürasyon değişiklikleri dikkate alındığında, toplam uygulama maliyeti sistemin orijinal satın alma fiyatının üç katı olabilir. Bu nedenle şirketler, PLM’in sağladığı tüm faydalara rağmen planlama ve uygulama faaliyetlerini çok dikkatli bir şekilde ele almalıdır.

PLM teknolojisinin farklı endüstrilerdeki etkisi, ürün yaşam döngüsü, ürün geliştirme süreci ve pazara sunma sürecinin yanı sıra endüstrinin gelişim faktörlerine (pazarlama, projeler, teknoloji, üretim) bağlıdır. PLM, pazara sunma süresi, üretim hacmi ve kârlar gibi merkezi iş gereksinimlerini etkiler. Sektöre özel faktörlerin yanı sıra, şirkete özel faktörler, ürün geliştirme, genişleme ve ağ oluşturma planları da PLM ihtiyacını, sistemin gerekliliklerini ve işlevselliğini etkiler. PLM'in faydaları en iyi, sistemin orijinal satın alma fiyatının tek önemli faktör olmadığı, ancak satın almanın stratejik bir niyetle yapıldığı ve sürecin, uygulamanın kalitesi ve maliyetlerine odaklandığı durumlarda elde edilir. Gereken işlevsellik seviyesinin tanımlanması ve bulunması ayrıca diğer sistemlerle (kendi ve paydaşlar) entegrasyonun da dikkate alınması gerekir.

4 PLM Dönüşüm Yol Haritasının Uygulanmasında Dikkat Edilecek Hususlar

Sorunsuz, başarılı bir PLM uygulaması için aşağıda belirtilen 6 madde dikkate alınarak planlamaların ve çalışmaların yapılması gereklidir.

        i.            PLM stratejisi için amaç ve hedefler belirlenmeli,

      ii.            Süreçler gözden geçirilerek yeni süreçlerin tasarlanmalı,

    iii.            Veriler gözden geçirilerek ve tasnif edilmeli,

    iv.            Üst yönetim ve organizasyonel desteğin alınması sağlanmalı,

      v.            PLM bir proje planında ve proje lideri ile çalışılmalı,

    vi.            İnsanlar yeni süreçler hakkında önceden eğitilmeli.

        i.            PLM stratejisi için amaç ve hedefler belirlenmeli,

Bir Ürün Yaşam Döngüsü Yönetimi yazılımı satın alıp, şirkete uygulamaya başlamadan önce, böyle bir adımı atma nedenleri tanımlanarak başlanmalıdır.

Bazı ortak operasyonel amaçlar ve hedefler şunları içerir:

• Daha iyi erişilebilirlik için ürün verilerini merkezileştirme,
• Malzeme listelerinin standartlaştırılması ve yinelenen içeriğin kaldırılması,
• Kâğıt tabanlı bir süreçten elektronik bir ECO sürecine geçiş
• Ürün verilerini başka bir sisteme bağlama (ERP yazılımı gibi)
• Mevzuat gerekliliklerini yönetme

Bu amaçlar ve hedefler hangi süreçlerin öncelikli olarak ele alınacağı, hangilerinin iler bir tarihe ertelenebileceği hakkında net bir resim sunar. Bu anlayış, PLM ihtiyaçlarınızı tanımlamanıza ve çalışma ortamını bozma olasılığı daha düşük olan kademeli yükseltmeleri ve iyileştirmeleri planlamanıza yardımcı olur. Net amaçlar ve hedefler belirlemek, PLM uygulama sürecinin başarısını ve yeni PLM süreçlerinizin ve/veya sistemlerinizin başarısını ölçmenize de olanak sağlar.

      ii.            Süreçler gözden geçirilerek yeni süreçlerin tasarlanmalı,

Bir PLM sistemine hangi süreçlerin aktarılacağının ve PLM sisteminde nasıl yönetileceğinin belirlenmesi için mevcut süreçler gözden geçirilmelidir. Örneğin, mühendislik değişiklik yönetim süreci ERP sistemlerinde yönetiliyorsa bu sürecin PLM sistemine aktarıldıktan sonra CAD verileri ile ilişkilendirilmesi, ERP sisteminde yaşanan zorlukların PLM sistemi ile iyileştirilmesi bu sürecin daha etkin ve verimli bir şekilde kullanılmasını sağlayacaktır. Bu nedenle mevcut süreçleri gözden geçirmeye zaman ayırmak ve yeni PLM sistemi ile birlikte nasıl daha iyi yönetilebileceği hakkında beyin fırtınası yapılmalıdır. Süreçlerde ki değişikliklerden etkilenen şirket içi ve dışı paydaşlar belirlenmeli ve bu kişilerin sürecin yeniden tasarlanmasında katkı sağlamaları gereklidir.

Neyin yapıldığını, kimin yaptığını ve kimin etkilendiğini bilmek hem planlama hem de satın alma aşamasında PLM uygulama sürecinin önemli bir parçasıdır. Süreçleri önceden gözden geçirmek daha hızlı ve sorunsuz bir PLM uygulaması için ortam hazırlar.

    iii.            Veriler gözden geçirilerek ve tasnif edilmeli,

Yeni bir eve taşınırken genel olarak ev eşyalarını gözden geçirmek ve nelerin paketlenip nelerin paketlenmeyeceğine karar vermek için zaman harcanmaktadır. Benzer şekilde, verilerin "yaşadığı" yerde bir değişiklik yapılacağından, verilerin gözden geçirilmesine de zaman harcanmalıdır. Mevcut veriler gözden geçirilerek hangi verilerin taşınması gerektiğine ve hangi verilerin olduğu yerde kalabileceğine karar verilmelidir. Taşınan tüm bilgilerin doğru ve eksiksiz olduğunu tespit etmek için test senaryoları ver kriterleri belirlenmelidir. Aktarılacak verilerin büyüklüğü arttıkça bu işlemin otomatik olarak yapılması hata oranını azaltacağı gibi aktarım süresini de azaltacaktır.

    iv.            Üst yönetim ve organizasyonel desteğin alınması sağlanmalı,

Süreç değişikliği zor olabilir ancak bir PLM sisteminin başarılı bir şekilde uygulanması organizasyona finansal faydalar sağlarken aynı zamanda ekiplerin günlük iş süreçlerini de iyileştirebilir. Ürün yaşam döngüsü yönetimi stratejisinin işe yaraması için, yönetim ekibini ve yeni sistemi kullanacak olan ekiplerin desteğinin alınması çok önemlidir.

Yönetici ekip, uygulamanın çarpık gitmesini önlemek için teşvikler ve motivasyon sağlayabilir. PLM sistemini kullanacak olanların işlerini nasıl kolaylaştıracağı konusunda eğitilmeleri gereklidir. Kullanıcılar PLM projesine katkıda bulunabilir ve katıldıkları süreçleri yeniden şekillendirmeye yardımcı olabilirse, duygusal olarak da projeye dahil olacaklarından yeni sistemi sahiplenmeleri artacağından kullanıcı direnci minimum seviyeye düşürecektir

      v.            PLM bir proje planında ve proje lideri ile çalışılmalı,

PLM'yi uygularken, bir proje planından çalışmak ve kuruluşunuzdan bir proje lideri aüreci idare etmek için en doğru yöntemdir. Son teslim tarihlerinin açıkça belirtildiği bir kilometre taşları listesine sahip olmak, uygulama sürecinin daha verimli bir şekilde ilerlemesine yardımcı olacaktır. Ayrıca yardıma ihtiyacı olan alanlar daha kolay tespit edilecek.

PLM uygulaması sırasında ortaya çıkan soruları yanıtlamak için PLM satıcısından atanmış yetkili bir kişi daima proje içerisinde yer almalıdır. İyi yapılandırılmış bir plan ve yönetim ekibinin desteğine sahip bir proje lideriyle, başarılı bir PLM uygulaması gerçekleştirilebilir.

    vi.            İnsanlar yeni süreçler hakkında önceden eğitilmeli.

Günümüzde birçok PLM sisteminin kullanımı kolaydır ve çoğu, anında soruları yanıtlamak için online destek platformlarına sahiptir. Kullanıcıların PLM yazılım sistemiyle bireysel başarıya ulaşmalarına yardımcı olmak için web eğitimi ve sınıf eğitimi imkanları da sağlanmalıdır.

Kullanıcılar daha önce hiç görmedikleri bir sistemi kullanmaya zorlanırlarsa, geçiş yapmak zorunda kalana kadar eski yönteme bağlı kalmaları muhtemeldir ve o zaman büyük bir isteksizlikle geçiş sürecini sürdürürler. Kullanıcıların eğitim materyallerine PLM uygulama sürecinin başlarında erişmesini sağlamak, motivasyonun korunmasına yardımcı olur. Süreçlerin ve verilerin kullanıcılar tarafından daha iyi kontrol edilmesiyle daha verimli bir PLM sistemi elde edilir.

5 PLM Uygulama Metodolojisi

Yeni PLM sistemi devreye alınırken öncelikli olarak devreye alınacak modüller belirlenir ve bir yol haritası oluşturulur. Bu yol haritasına göre tüm modüller Şekil 1’ de belirtilen metodoloji uygulanarak PLM sistemine aktarılır. PLM sisteminin belirli bir metodoloji uygulanarak kurulması sistemin başarı oranını ciddi anlamda yükseltmektedir. Bu metodoloji kapsamında PLM sisteminin kurulması ve süreçlerin devreye alınması işleminin alt yüklenici bir PLM firması ile yapılacağı düşünülmüştür. Ayrıca metodolojide belirtilen adımlar PLM Uygulama Proje ekibi ile yapılacaktır. Proje ekibinde şirket içinden çalışanlar ve alt yüklenici PLM firması bulunmaktadır.

5.1 Olgunluk Taraması

Bu adımda Proje ekibi ilk olarak şirket içerisinde bir olgunluk taraması yaparak mevcut durumda sistemin güçlü yanlarını ve zayıf yanlarını analiz eder. İlgili sürecin PLM sistemine aktarıldıktan sonra sağlanmasını amaçladığı kazanımlar, amaç ve performans kriterleri belirlenir. Daha sonra proje risk analizi yapılarak projedeki riskler tanımlanır. Tüm bu çalışmalar olgunluk tarama dokümanında bir araya getirilerek kayıt altına alınır.

5.2 Çözüm Oluşturma

PLM Proje ekibi yol haritasında yer alan tüm modüller için iş birimlerini ve süreçlerini analiz ederek gereksinimleri çıkartır. Bu analiz tüm modüller için ayrı ayrı yapılmalıdır. PLM firması çözümü tanımlamak için bu gereksinimleri kullanır. PLM proje ekibi tarafından tüm gereksinimleri kapsayan ve izlenebilirliği gösteren bir analiz dokümanı hazırlanır. Bu analiz dokümanı, mevcut süreçleri, en iyi uygulamaları, olması gereken çözüm ve süreçleri, PLM performansını değerlendirmek için KPI'ları, kullanım ve test senaryolarını, yapılandırma/özelleştirme noktalarını kapsar. Daha sonra bu dokümanda yer alan bilgiler ışığında PLM’e aktarılması planlanan süreç PLM sistemi yetkinliklerine uygun ve gereksinimleri karşılayacak şekilde yeniden yapılandırılır. Burada yapılandırılan sürecin PLM standart fonksiyonları ile sağlanabiliyor olması, ek geliştirme istememesi, çok önemli bir husustur. Mümkün olduğunca süreçler PLM sistemi içerisinde standart olarak gelen fonksiyonlar ile kurgulanmalıdır.

Bu aşamada ayrıca süreç PLM sistemine aktarıldıktan sonra yapılacak olan test senaryoları belirlenmelidir. Test senaryolarının başarı kriterleri ve detaylı bir şekilde testin nasıl yapılacağını içeren test tanım dokümanı hazırlanmalıdır. Geliştirme ve doğrulama işlemi sırasında yapılacak olan test senaryoları ayrı ayrı belirlenir. Geliştirme aşamasında yapılan test senaryoları Alt yüklenici PLM firması tarafından yapılır. Doğrulama işlemi sırasında yapılan test senaryoları ise son kullanıcılar tarafından yapılmalıdır. Test senaryoları belirlenirken her bir gereksinime karşılık bir test kriterinin olduğundan emin olunmalıdır. Gereksinimler ve ilgili test kriterleri çift yönlü olarak izlenebilir olmalıdır. Test işlemlerinin sonunda Alt yüklenici firma tarafından test sonuç raporu dokümanı hazırlanmalıdır.

Sistem canlı kullanıma alındıktan sonra son kullanıcıların sistemi daha etkin ve verimli bir şekilde kullanabilmesi için bir eğitim planı hazırlanmalıdır. Bu eğitim planı sistemi kullanacak tüm kullanıcıları ve ilgili tüm konuları kapsamalıdır. Verilecek olan ilk eğitimler PLM firması tarafından yüz yüze verilmesi eğitimin başarı oranını önemli ölçüde etkilemektedir. Sistem canlı kullanıma alındıktan sonra yapılacak eğitimler online, eğitim materyali (forum, video, pdf vb.) veya eğitim platformu ile aracılığıyla sağlanabilir.

5.3 Çözüm Onayı

Çözüm oluşturma aşamasında hazırlanan tüm dokümanlar Alt yüklenici PLM firması ile bir araya gelerek değerlendirilir. Bu değerlendirme sonucunda PLM proje ekibi ve Alt yüklenici PLM firması hem fikir olarak çözüm oluşturma aşamasında hazırlanan tüm dokümanları onaylar. PLM proje ekibi tasarlanan yapıda bu aşamada bir değişiklik talep edebilir. Alt yüklenici PLM firması istenen değişiklikleri yaparak tekrar onaya sunar. PLM proje ekibi tarafından çözüm onaylandıktan sonra ilgili dokümanlar üzerinden bir değişiklik yapılamaz. Eğer değişiklik zorunlu ise proje değişiklik yönetimi süreci yürütülmesi gereklidir. Bu adım sonucunda PLM firması PLM sistemi üzerindeki çalışmalarına başlar.

5.4 Teslimat ve Doğrulama

Bu aşamada teslimat onaylanan çözüm dokümanlarına göre PLM firması tarafından yürütülür. PLM firması öncelikli olarak geliştirme ortamında uyarlama çalışmalarına başlar. Çözüm dokümanlarında yer alan tüm tanımlamalar PLM sistemine uyarlanır. PLM firması test ortamında onaylanan test tanım dokümanına göre kendi testlerini yaptıktan sonra test sonuç raporunu hazırlayarak PLM proje ekibine sunar. Bu doküman PLM proje ekibi tarafından onaylandıktan sonra çalışmalarını canlı öncesi ortama taşır.  Bu aşamadan sonra son kullanıcılar test tanım dokümanlarına göre testlerini uygulayarak yapılan çalışmayı doğrular ve test sonuç raporunu hazırlar. Hazırlanan sonuç raporu PLM proje ekibi tarafından onaylanırsa yapılan çalışma canlı ortama aktarılır. Eğer test raporunda ilave bir test ihtiyacı veya olumsuz bir durum tespit edilirse bu durum PLM firmasına bildirilerek çözümü sağlanır. Uygulanan çözümler de doğrulandıktan sonra sistem canlı ortama aktarılır.  Daha sonra PLM sisteminde doğrulanan çözüm eğitim ortamına da aktarılır. Eğitim ortamında onaylanan eğitim planına uygun olarak son kullanıcı eğitimleri verilir. Son kullanıcı eğitimleri bittikten sonra eski sistemler kapatılara yeni PLM sisteminde canlı kullanıma başlanır.

4.6. Sürdürülebilirlik

İlgili süreçler yeni PLM sisteminde devreye alındıktan sonraki ilk 6 ay PLM firması sistemde yaşanacak problemleri yakından takip eder. Kullanıcıların sistemi kullanamamasına neden olan (herhangi bir arıza veya düşük performans sorunu dahil) son kullanıcılar veya proje ekibi tarafından belirlenen tüm hatalar alt yüklenici PLM firması tarafından düzeltilmelidir. Sistem performansını belirli aralıklarla takip ederek rapor ederek raporlanır. Performans düşüklüğü yaşanması durumunda ilgili ekibi uyararak geliştirmelerin yapılmasını sağlar. Aynı zamanda eğitim ihtiyaçlarını tespit ederek kullanıcılara eğitim verilmesini sağlar. Herhangi bir güvenlik problemi yaşanmaması için şirketin siber güvenlik ekibi ile koordineli bir şekilde çalışır.

PLM sisteminin sürdürülebilirliğinin sağlanması için en önemli hususlardan biri de şirket içerisinde bir PLM teknik ekibin olmasıdır. PLM firması tarafından kurulan sistem şirketin teknik PLM ekibi tarafından teslim alınarak idame edilmesi sağlanmalıdır. Ancak bu şekilde sağlık bir PLM sisteminin yönetilmesi sağlanabilir.

5 Örnek Bir PLM Uygulama Yol Haritası ve Uygulama adımları

PLM Uygulama Yol haritası PLM sistemlerinin başarısını önemli ölçüde etkileyen bir kriterdir. Şekil 2’de Savunma Sanayinde yer alan bir şirkete ait PLM uygulama yol haritası görülmektedir. Bu yol hartiası kapsamında yer alan tüm modüller ve alt kırılımlarında yer alan süreçler için kısa tanımlamalar yapılmıştır. Bu bölümde bu tanımlamalar anlatılarak PLM projesinin kapsamının gerçekte ne kadar geniş bir yapıda olduğu vurgulanmıştır.

Şekil 2: PLM Uygulama Yol Haritası

5.1 PLM Dönüşüm Yol Haritası Detayları

Bu bölümde Şekil 2’de belirtilen yol haritasında yer alan modüller ve alt süreçleri ile ilgili bazı kritik gereksinimler tanımlanmıştır. Ayrıntılı gereksinimler ve içerikler, her sürecin başında uygulanacak olan PLM Uygulama metodolojisi ile belirlenecektir. PLM uygulama yol haritasındaki modüllere başlamadan önce bir hazırlık adımı bulunmaktadır. Bu hazırlık adımında PLM proje yönetim stratejisinin belirlenmesi, sistem alt yapısının belirlenmesi ve kurulması, projede yer alacak proje ekiplerinin belirlenmesi gibi genel hususlar yer almaktadır. Bu adım tamamlandıktan sonra PLM uygulama Yol Haritasında yer alan ilk adım ile projeye başlanır.

5.2 CAD Entegrasyonu

5.2.2 MCAD ve ECAD Entegrasyonu

• Siemens NX, PTC Creo, Dassault Catia V5 vb. MCAD uygulamaları PLM sistemine entegre edilmelidir. İlgili veri taşıma işlemleri otomatik mekanizmalar ile gerçekleştirilmelidir. Tüm MCAD entegrasyonları aynı işlevselliği sağlamalıdır.
• Siemens Mentor Xpedition, Siemens Mentor Pads, Altium Designer, Zuken E3, Eplan vb. ECAD uygulamaları PLM sistemine entegre edilmelidir. İlgili veri taşıma işlemleri otomatik mekanizmalar ile gerçekleştirilmelidir. Tüm ECAD entegrasyonları aynı işlevselliği sağlayacaktır.
• Gerekli tüm CAD öznitelikleri (sayı, revizyon, isim, ağırlık, malzeme, hacim, alan vb.) ve EBOM, PLM sisteminde tanımlanmalı ve eski sistemlerden PLM sistemine taşınmalıdır.
• Veri taşımada CAD parçaları ile çizimler arasındaki bağlantılar kopmamalıdır.
• CAD modeller veri geçişinde bozulmamalıdır.
• CAD verileriyle ilişkili tüm dosyalar (pdf, Word, zip vb.) yeni sisteme ilişkileri koparılmadan taşınmalıdır.

5.2.3 Yayın ve Versiyon Yönetimi

• Revizyonlar, versiyon şemaları, yayın süreçleri, yaşam döngüsü durumları (inwork, under review, relased, canceled vb.) ve gerekli kurallar tanımlanmalıdır.
• Sistem devreye alındıktan sonra da, herhangi bir iş akışı, revizyon ve versiyon şeması, yaşam döngüsü durumları herhangi bir zamanda değiştirilebilir olmalıdır.

5.2.4 Uygunluk ve Tasarım Standartları

• CAD dokümanları için gerekli nitelikler PLM sisteminde belirlenmeli ve bu nitelikler hem PLM'den CAD'e, hem de CAD'den PLM'e senkron olarak güncellenmelidir. CAD ve parçalar üzerinde birimleriyle birlikte string, tamsayı, gerçek sayı gibi farklı formattaki herhangi bir öznitelik çift yönlü olarak güncellenebilir.
• CAD belgeleri PLM sistemine aktarılırken tüm CAD kontrol modülleri (Model Check, Quick checker vb.) PLM sistemi ile uyumlu olarak kullanılabilir olmalıdır. PLM sisteminden farklı bir satıcıya ait olan CAD kontrol modülleri Alt yüklenici PLM firması tarafından uygulanmalıdır.
• Tüm teknik resim şablon yapıları ortak olmalıdır. Teknik çizim şablonlarındaki boşluklar, CAD parametrelerinden ve PLM sisteminden gelen verilerle otomatik olarak doldurulmalıdır. BOM listeleri ve standart çizim notları teknik resimlere otomatik olarak eklenmelidir.
• CAD parametreleri ortaklaştırılmalı ve otomatik olarak PLM'den CAD modellerine ve teknik çizimlere aktarılmalıdır.
• Tüm CAD uygulamaları ortak konfigürasyon ayarları ile çalışmalıdır. Konfigürasyon ayarları sadece ilgili sistem yöneticisi tarafından değiştirilebilir. Bir kullanıcı CAD uygulamasında konfigürasyon ayarlarını değiştirirse, değişiklikler sonraki oturumlar için kaydedilmemelidir.

5.2.5 Temel E-BOM ve Veri Görselleştirme

• CAD verileri PLM sistemine aktarıldıktan sonra E-BOM otomatik olarak oluşturulmalıdır.
• CAD verileri PLM sistemine aktarıldığında PLM sisteminde 3 boyutlu görselleştirme otomatik olarak oluşturulmalıdır.
• PLM sisteminde otomatik olarak oluşturulan 3D ve 2D modeller, CAD uygulaması olmayan tüm ilgili PLM kullanıcıları tarafından görüntülenebilmelidir.
• Tüm MCAD ve ECAD uygulamalarından gelen teknik çizimler, PLM sistemine yüklendiğinde otomatik olarak PDF, DXF, DWG vb. belgelere dönüştürülebilmelidir.
• CAD dokümanları PLM sistemine yüklendiğinde STP, IGS vb dokümanlar otomatik olarak oluşturularak ve güncellenebilmelidir.
• 3D şekil arama fonksiyonu kullanılabilmelidir.

5.2.6 Parça Sınıflandırma ve Kütüphaneler

• Parçalar ve CAD verileri farklı kategorilerde (norm, mekanik, kaynaklı, talaşlı imalat, elektrik, yazılım vb.) yönetilmeli ve her kategori için farklı kurallar tanımlanmalıdır.
• Parça kitaplıkları çoklu mCAD (NX, Creo, Catia vb.) yapısını desteklemelidir. Bir MCAD dosyası (yani NX) oluşturulur/değiştirilirse, diğer mCAD dosyaları (yani Creo, Catia) otomatik olarak oluşturularak/güncellenebilmelidir.
• Kütüphaneler, kütüphane veri yapısı, kütüphane özellikleri, sınıflar, sınıflandırmalar, hiyerarşiler vb. şirkete özel olarak tanımlanmalıdır.
• Ortak kütüphaneler oluşturulmalı (malzeme kütüphanesi, standart parça kütüphanesi vb.) ve tüm kullanıcılar bu kütüphaneleri kullanabilmelidir.
• Şirket genelinde ortak sınıf yapıları kullanılmalıdır.
• Şirket’te yaygın olarak kullanılan parçalar tanımlanmalı ve sınıflandırılmalıdır.
• Ortak ve standart parçalar sınıflandırılmalı ve bu parçalar için kütüphaneler oluşturulmalıdır. Ayrıca bu kütüphaneler NX, Creo, Catia vb. veri setlerine sahip olacaktır.
• Montajlarda sınıflandırılmamış CAD parçaları kullanılması engellenmelidir.

5.2.7 Yeni Stok Numaralandırma Sistemi

• Yeni stok numaralandırma sistemi Proje ekibi ve PLM firması ile birlikte tasarlanmalı ve uygulanmalıdır.
• Stok numaralarının ve tanımlarının standardizasyonu için ortaklaştırma çalışmaları yapılmalıdır. Stok numaraları ve tanımları, önceden tanımlanmış konfigürasyonlara göre PLM sistemi tarafından otomatik olarak oluşturulmalıdır.
• PLM sisteminde oluşturulan stok numaraları SAP sistemine (SAP'a malzeme entegrasyonu) aktarılmalıdır. Transfer süreci, onay süreçlerine dayalı olarak gerçek zamanlı olmalıdır. Ayrıca bu iş akışı herhangi bir zamanda düzenlenebilir olmalıdır.
• SAP için gerekli olan stok numarası öznitelikleri, PLM sisteminde tanımlanmalı ve SAP tarafındaki alanlara başarılı bir şekilde eşlenmelidir.
• Stok numarası öznitelikleri, PLM sistemi tarafından SAP kurallarına göre (40 karakter sınırı) otomatik olarak kontrol edilmelidir. Yanıt işlemi (SAP'ta materyal oluşturma başarılı veya başarısız oldu) SAP'den alınmalıdır. Herhangi bir arıza durumunda, kullanıcı gerekli değişikliği güncelleyebilmeli ve materyali yeniden yayınlayabilmelidir.
• Stok numaralarının oluşturulması için onay mekanizmaları (iş akışı) tasarlanmalıdır.
• İlgili tüm PLM kullanıcıları, stok numaraları oluşturup SAP sistemine aktarabilir olmalıdır.

5.3 Doküman Yönetimi ve Süreç Entegrasyonu

5.3.1 Doküman yönetimi

• Şirkete özel olarak doküman tipleri tanımlanmalıdır.
• Nitelikler, numaralandırma formatı, şablonlar, yayın süreçleri vb. belge tipine özel tanımlamalar yapılabilir olmalıdır.
• Dokümanlar, doküman tipine göre önceden tanımlanmış belirli PLM klasörlerine kaydedilmelidir.
• Doküman oluşturma/görüntüleme/düzenleme yetkilendirmesi ilişkili dokümanın projesine, sınıfına vb. göre yapılmalıdır.
• Microsoft Office (Word Excel vb.) uygulamaları PLM sistemi ile entegre olarak çalışmalıdır. Aç/kaydet/düzenle/Check-in/Checkout vb. PLM işlevleri Office uygulamaları üzerinden kullanılabilir olmalıdır.
• Dokümanların içeriklerinde (iş belgeleri, PDF, CAD model ve çizim vb.) gelişmiş indeks araması yapılabilmelidir.
• Belgeler herhangi bir niteliğe göre (tür, nitelik, oluşturan, tarih, durum, sınıf, şirkete özgü nitelikler vb.) aranabilmeli ve sınıflandırılabilmelidir.
• Doküman tipleri ve şablonlar tüm şirket için ortak olmalıdır.
• Öz nitelikler dinamik olarak yönetilebilmelidir. Örneğin özniteliğe bir değer atandığı zaman onun altındaki öz nitelikler otomatik olarak güncellenmeli ve o değere uygun öznitelikler gelmelidir.
• Her doküman tipi için farklı ekranlar tanımlanabilmelidir.
• Dokümanlar ve özellikleri karşılaştırılabilir olmalıdır.
• Standart raporlama fonksiyonları ile her doküman tipine özel rapor şablonları hazırlanmalıdır.

 5.3.2 Değişiklik ve Konfigürasyon Yönetimi

• Şirkete uygun olarak ortak, standartlaştırılmış (CM2 veya farklı metodolojilere göre) ve otomatikleştirilmiş değişiklik yönetim süreci tasarlanmalı ve uygulanmalıdır.
• Şirket içerisindeki tüm birimler ortak değişiklik yönetim sürecini kullanmalıdır. Farklı bir gereksinimi olan birim olursa mevcut sürece eklemeler yapılabilmelidir.
• Problem raporu, sapma, ECR, ECN, CIB (değişim uygulama panosu) obje tipleri için ekranlar ve iş akışları şirket gereksinimlerine göre uygulanmalıdır.
• Değişiklik işleminden sonra ilgili veriler SAP sistemine aktarılmalıdır. Transfer süreci, ECN detayları ve etkinlik bilgileri dahil olmak üzere gerçek zamanlı olmalıdır. Yayının başarılı veya başarısız olması durumunda yanıt işlemi SAP'den otomatik olarak alınmalıdır. Herhangi bir arıza durumunda, kullanıcı gerekli değişikliği veya ECN'yi güncelleyip SAP'ye yeniden yayınlayabilmelidir.
• Etki analizi yapılmalıdır. Doğrudan etkilenen nesneler (üst montaj, gereksinim, analiz raporu, proje takvimi vb.) belirlenmeli ve ilgili aksiyonlar oluşturulmalıdır. Ayrıca dolaylı olarak etkilenen nesneler belirlenmeli ve ilgili eylemler oluşturulmalıdır.
• Değişiklik yönetimi, farklı içerik türlerini (BOM, CAD, gereksinimler, vb.) içerebilir.
• Bekleyen, geciken, kapatılan görevler gibi değişiklik yönetimine ilişkin ayrıntılı raporlar oluşturulabilmelidir.
• Herhangi bir değişiklik süreci alt türü tanımlanabilmelidir. (sorun raporu için: kalite sorunu, montaj sorunu, prototip sorunu; ECR için: belge değişikliği talebi veya PFMEA gibi herhangi bir özel süreç)
• Değişiklik yönetimi farklı süreçleri tetikleyebilir. Ayrıca farklı süreçler değişiklik yönetimini tetikleyebilir. (ECN çözüldüğünde, ilgili tüm ECR'ler, sorun raporları ve diğer ilgili süreçler otomatik olarak güncellenmeli ve çözülmelidir.)
• Herhangi bir otomatik bildirim, gerekli posta formatına göre ilgili kullanıcılara gönderilmelidir. Değişiklik yönetimi süreçlerinde bilgilendirme e-postaları otomatik olarak gönderilmelidir.

5.3.3 Proje Yönetimi

• Projeler, kaynaklar, roller, oranlar, görevler, bütçeler, program vb. Primavera ve PLM sistemi arasında gerçek zamanlı ve çift yönlü olarak veri aktarımı sağlanmalıdır.
• Primavera'da bir proje oluşturulduğunda; proje, kaynaklar, görevler vb. otomatik olarak PLM'ye aktarılmalıdır.
• MS Project ve PLM arasında çift yönlü entegrasyon sağlanmalıdır. Proje planları, MS Project formatı aracılığıyla kolayca içe aktarılabilmelidir.
• Primavera'da bir proje değiştirildiğinde (yeni görev oluşturma, kaynak, süre, proje takvimi değiştirme vb.), bu değişiklikler gerçek zamanlı olarak otomatik olarak PLM sistemine aktarılmalıdır. Aynı şekilde PLM sistemindeki değişiklikler de otomatik olarak gerçek zamanlı olarak Primavera'ya aktarılmalıdır.
• PLM kullanıcıları veri girişlerini (çalışma saati, süreleri vb.) PLM sisteminden yapmalıdır.
• PLM ile MS Outlook arasında gerçek zamanlı entegrasyon olmalıdır. (Toplantılar, görevler vb. için).
• Kullanıcılara herhangi bir proje veya veriden bağımsız olarak herhangi bir görev veya eylem öğesi atanabilir. Görevler ve eylem öğeleri, bir Excel dosyası aracılığıyla iki yönlü olarak dışa ve içe aktarılabilmelidir.
• Projeler için detaylı raporlar oluşturulabilecektir.

5.3.4 Alt yüklenici İş birliği

• ŞIRKET içindeki harici kullanıcılar için: Bu kullanıcılar, internete bağlanmayan başka bir iç ağda PLM kullanacaklardır. Veri aktarımı farklı iç ağ arasında çift yönlü olarak yapılmalıdır. Farklı ağ etki alanları (SSL, TLS, vb.) arasında güvenli bir protokol uygulanmalıdır.
• Şirket dışındaki harici kullanıcılar için: İlgili PLM verileri (CAD, pdf, ofis vb.) PLM kullanmayan tedarikçilerle (yani internete bağlı harici bir sunucu ile) paylaşılacaktır. Tedarikçiler bu sunucuya bağlanacaktır. PLM bağlantısı otomatik olarak olacaktır). PLM ile bu harici tedarikçi portalı arasındaki veri aktarımı, yaşam döngüsü durumunun serbest bırakılacak şekilde değiştirilmesi durumunda verileri PLM'den göndermek gibi önceden tanımlanmış ayarlara dayalı olarak yapılandırılacaktır. Ve her tedarikçi bu harici portalda yalnızca kendi verilerini görüntüleyebilmelidir. Bu harici portal, şirket gereksinimlerine göre Tedarikçi tarafından uygulanmalı ve yapılandırılmalıdır
• Tedarikçiler, sorularını harici tedarikçi portalı üzerinden iletebilmeli ve cevaplar da bu portal üzerinden gönderilmelidir.

5.4 Ürün Ağacı ve Üretim Entegrasyonu

5.4.1 Malzeme Listesi Yönetimi

• Mevcut ürün reçeteleri SAP'den PLM sistemine taşınmalıdır. BOM'un tüm bilgileri (nitelikler, koşullar, kurallar vb.) aktarılmalıdır. BOM yönetimi PLM sisteminde yapılmalıdır.
• PLM sisteminde oluşturulan veya düzenlenen ürün reçeteleri, iş akışı onayına bağlı olarak gerçek zamanlı olarak SAP'ye aktarılmalıdır.
• EBOM, MBOM, SBOM vb. herhangi bir BOM, şirket gereksinimlerine göre tanımlanmalı ve uygulanmalıdır. Mevcut BOM yapısı, EBOM ve MBOM yapılarına dönüştürülebilmelidir.
• EBOM ile MBOM, SBOM vb. arasında ilişkisel bağlantı tanımlanmalıdır.
• Tek bir kullanıcı ara yüzünde iki farklı Malzeme Listesi versiyonu karşılaştırılabilir ve versiyonlar arasında farklı Malzeme Listesi bileşenlerini, niteliklerini, ilişkili CAD ve belgeleri ve 3D görselleştirmeyi rapor edebilmelidir.
• İlgili MBOM'u SAP'de doğru tesis altında yayınlayabilmek için MBOM, SAP tesis bazında farklı görünümlerde tanımlanmalıdır.
• Tasarım mühendisleri tarafından oluşturulan EBOM, PLM sistemi içerisinde MBOM'a dönüştürülmelidir.
• EBOM ve MBOM birbiri ile ilişkili olmalıdır.
• MBOM, bir 3D model (EBOM gibi) olarak görüntülenebilmelidir.
• Alternatif veya ikame malzemeler, herhangi bir ürün reçetesinde tanımlanmalıdır.

5.4.2 Varyant ve Opsiyon Yönetimi

• Yeni varyant ve seçenekler konfigürasyon yönetim sistemi/yapısı tasarlanmalı ve uygulanmalıdır.
• Süper BOM yapısı tasarlanmalı ve uygulanmalıdır.
• Karmaşık kurallar (birden fazla kural) ve seçim kriterleri Super BOM'da tanılanabilmelidir.
• Daha önce yapılmış varyantlar erişilebilir olmalıdır. (Gelişmiş arama ve filtreleme mümkün olmalıdır.).
• Gereksinimler, varyant ve seçeneklerle ilişkilendirilebilmelidir.
• Süper BOM'lar %100 BOM'a dönüştürülebilmelidir.

5.4.3 Üretim Değişiklik Yönetimi

• Bu süreç, “Değişiklik ve Konfigürasyon Yönetimi” süreci ile aynı gereksinimleri içermektedir.

5.4.4 Proses Listesi

• Tesise özel proses planları tanımlanmalıdır. Süreç planları, sıraları, operasyonları, alt operasyonları, parçaları, kaynakları, belge tahsislerini, zaman/maliyet dökümünü vb. içermelidir.
• Aynı parçalar için alternatif süreç planları mevcut olmalıdır.
• SAP'de tanımlanan tüm kaynaklar toplu olarak Excel dosyaları ile PLM'de oluşturulabilmelidir.
• Standart süreç planları için ortak kütüphane oluşturulmalıdır. Süreç planları kütüphanelerden yeniden kullanılabilmelidir.
• İşlem Listesi ile ilişkili takımlar, işlem malzemeleri, beceriler, iş talimatları vb., iş akışı onayına dayalı olarak gerçek zamanlı olarak SAP'ye aktarılmalıdır.
• Proses planları, üretim değişikliği yönetimi süreci ile değiştirilmelidir.
• Proses Listesi için detaylı raporlar oluşturulabilmelidir.
• CAD araçlarında tasarlanan fikstürler gibi üretim araçları, üretim kaynakları ile ilişkilendirilmelidir. Bu aletler çalışma talimatlarında gösterilmelidir.

5.4.5 Çalışma talimatları

• Tüm üretim kaynakları bir değişiklik yönetimi sürecinde güncellenebilir.
• Parçaların/sistemlerin üretilmesi, incelenmesi, onarılması, bakımı vb. ile ilgili talimatlar adım adım tanımlanmalıdır.
• Proses planları, operasyonlar, sıralar vs. değiştiğinde iş talimatları otomatik olarak güncellenmelidir.
• Çalışma talimatları, üretim işçilerinin erişimine açık olmalıdır.
• İş talimatları, CAD modelleriyle ilişkili 2B ve 3B görüntüleri içermelidir. CAD modelleri değiştiğinde bu görüntüler otomatik olarak güncellenmelidir.
• PLM sistemindeki 3B ve 2B modeller, CAD uygulaması olmayan tüm ilgili PLM kullanıcıları tarafından görüntülenmeli, kesitleri alınabilmeli ve ölçülebilmelidir.
• PLM sisteminde oluşturulan veya düzenlenen tüm İş Talimatları, iş akışı onayına bağlı olarak gerçek zamanlı olarak SAP'ye aktarılmalıdır.
• Mevcut İş Talimatları SAP'den PLM sistemine taşınmalıdır. İş Talimatlarının tüm bilgileri aktarılmalıdır.

5.5 Gereksinim Yönetimi ve MBSE Entegrasyonu

5.5.1 Gereksinim Yönetimi

• Mevcut gereksinimler, IBM DOORS vb. sistemlerden PLM sistemine aktarılmalıdır.
• Tüm gereksinimler ve gereksinim nitelikleri, gerçek zamanlı olarak IBM DOORS vb. sistemler ile PLM sistemi arasında çift yönlü olarak eşitlenecektir.
• Gereksinimler, iş akışları yayınlanmalı ve değiştirilmelidir.
• Doğrulama durumu, ilerleme ve gereksinimlerin sonuçları izlenebilir ve raporlanabilir olmalıdır.
• Gereksinimleri doğrulamak için test spesifikasyonları tanımlanmalıdır.
• Hata yönetimi süreçleri ve gereksinim yönetimi entegre edilmelidir. Hata yönetiminden elde edilen sonuçlar, gereksinim yönetimine bir girdi olmalıdır.
• Bazı gereksinimler CAD verileri ile ilişkilendirilebilmeli ve bu ilişkiler izlenebilir olmalıdır.
• Gereksinimlerin izlenebilirlik matrisleri oluşturmalıdır. (Gereksinimler ve projeler, CAD verileri, değişiklik süreçleri vb. arasındaki izlenebilirlik).
• Gereksinimler ürün reçeteleri ile ilişkilendirilebilmelidir.
• Fonksiyonel blok diyagramlar, parametre diyagramları ve ara yüz matrisleri gibi sistem mühendisliği araçları, gereksinim yönetimine entegre edilmelidir.
• Gereksinim belgeleri, resimler, tablolar vb. kullanılarak oluşturulabilmelidir.
• Gereksinimler Word ve Excel dosyaları ile PLM sistemine aktarılmalıdır. Gerekli Word ve Excel şablonları Alt yüklenici PLM firması tarafından hazırlanmalıdır.
• Gereksinimlerin farklı versiyonları karşılaştırılabilmelidir.
• Gereksinimler kaydedildiğinde, gereksinimlerin yeni bir versiyonu oluşturulmalıdır.

5.5.2 Model Tabanlı Sistem Mühendisliği

• MBSE için ilgili altyapı ve standartlar oluşturulmalıdır.
• MBSE sistem mimarisi tasarlanmalı ve uygulanmalıdır.
• Modeller, SysML (minimum sürüm 2.0) veya eşdeğer bir dil kullanılarak oluşturulmalı ve birbirleriyle ilişkilendirilmelidir.
• Modeller analiz edilmeli ve görsel olarak simüle edilmelidir.
• Blok diyagramlar ürün reçeteleri ile ilişkilendirilebilmelidir.
• Farklı kullanıcılar tarafından oluşturulan modeller tek bir yapı altında yönetilmelidir.
• MBSE modülü, diğer süreçlerle veri alışverişi yapabilmelidir. (Kalite süreci, tasarım süreci vb.)

5.6 Kalite Yönetimi ve Entegrasyonu

5.6.1 Kalite Veri Yönetimi

• Şirket tarafından kullanılan APQP (8D, DFMEA, PFMEA, kontrol planları vb.) ile ilgili tüm standartlar ve süreçler PLM sistemi üzerinden yönetilecektir. Geçmiş veriler (PDF, Word, Excel vb.) PLM sistemine taşınmalıdır.
• Kalite süreçlerinde ekranlar, iş akışları, etiketler, açılır menüler vb. şirkete özel tasarlanmalı ve gerektiğinde değiştirilebilmelidir.
• Kalite süreçleri şirket genelinde yaygınlaştırılmalıdır.
• Tüm kalite süreçleri için detaylı raporlar oluşturulabilmelidir.
• Süreçler birbirleriyle etkileşimli olmalıdır (bir sürecin bitişi, başka bir sürecin başlamasını tetikleyebilir).
• Kalite süreçleri ürün reçetesi, dokümanlar, parçalar vb. ile ilişkilendirilebilmelidir.
• Denetim işlemleri PLM sistemi ile yönetilecektir.
• Mevcut kalite yönetim sistemi nesneleri, CAPA, NC vb. audit operasyonları ile ilişkilendirilebilmelidir.

5.6.2 NC/CAPA

• Mevcut hata yönetimi süreçleri PLM sisteminde yönetilmelidir. Mevcut veriler (sorun türleri, iş akışları, roller vb.) taşınmalıdır.
• CAPA süreçleri tasarlanmalı ve uygulanmalıdır.
• CAPA süreçleri ürün reçeteleri, belgeler, parçalar vb. ile entegre olabilmelidir.
• NC/CAPA süreçlerinde ekranlar, iş akışları, etiketler, açılır menüler vb. ŞIRKET'a özel tasarlanmalı ve gerektiğinde değiştirilebilmelidir.
• Değişiklik bildirimleri DÖF süreçleri içerisinde otomatik olarak oluşturulabilmelidir.
• CAPA ve NC süreçleri için detaylı raporlar oluşturulabilmelidir.
• CAPA'lar kalite girdileriyle (şikayetler, tasarım geçmişi, vb.) ilişkilendirilebilmelidir.
• NC/CAPA'lardan öğrenilen dersler Bilgi Yönetim Sisteminde (know-how olarak) yönetilmelidir.

5.6.3 Risk ve Güvenilirlik Yönetimi

• Risk ve güvenilirlik PLM sisteminde yönetilmelidir.
• FTA, Prediction, RBD, Sürdürülebilirlik, FMEA vb. süreçler tasarlanmalı ve uygulanmalıdır.
• MIL-HDBK-217, 217 Plus, FIDES, PRISM, Telcordia vb. tüm prediction kitaplıkları yapılandırılmalıdır.
• Risk ve Güvenilirlik Yönetimi süreçlerinde ekranlar, iş akışları, etiketler, açılır menüler vb. şirkete özel tasarlanmalı ve gerektiğinde değiştirilebilmelidir.
• Risk ve Güvenilirlik Yönetimi kullanıcıları, ürün reçetelerini PLM'den otomatik olarak kullanabilmelidir. Malzeme Listelerinde PLM’de bir değişiklik olduğunda anında güncellenecektir.
• Hata kodları tanımlanmalıdır.
• Risk ve Güvenilirlik Yönetimi'nde oluşturulan problem kayıtları (8D vb.), değişiklik taleplerine veya problem raporlarına otomatik olarak dönüştürülebilmelidir.

5.6.4 Bilgi Birikimi Yönetimi

• Bilgi birikimi yönetimi PLM sisteminde yapılmalıdır.
• Bilgi birikimi verileri belirli sınıflandırma ve kurallara göre saklanmalıdır.
• Bilgi birikimi verileri güncellenebilmeli ve izlenebilmelidir. Tüm revizyonlar ilgili kullanıcılar tarafından erişilebilir olmalıdır.
• Bilgi birikimi verileri filtrelenebilir ve farklı niteliklerle aranabilir olmalıdır.
• Bilgi birikimi verilerinin yayınlanması ve bildirim süreçleri tanımlanmalıdır.
• Bilgi birikimi verileri için detaylı raporlar oluşturulabilmelidir.
• Bilgi birikimi verileri için yetkiler tanımlanabilmelidir.
• Bilgi birikimi verileri, ilgili belgeler, CAD, nesneler, projeler, süreçler vb. ile ilişkilendirilebilmelidir.
• Bilgi birikimi verileri puanlanabilmeli ve puanlara göre filtrelenmelidir.

5.7 Servis Yönetimi ve Entegrasyonu

5.7.1 SBOM Dönüşümü

• SBOM, EBOM veya MBOM'a dayalı olarak oluşmalıdır. SBOM ve EBOM/MBOM birbiri ile ilişkilendirilmelidir.
• 2D/3D çizimler CAD modelleri ile ilişkilendirilebilmelidir. CAD modelleri değiştiğinde bu görüntüler otomatik olarak güncellenmelidir.
• SBOM, bir 3D model (EBOM gibi) olarak görülebilmelidir.
• Yedek parça listesi, servis kitleri, SBOM üzerinden kolayca tanımlanabilmelidir.

29.10.2. Yedek Parça Yönetimi

• Servis/yedek parça dökümanları vb. PLM sisteminde yönetilmelidir.
• Parça kataloglarında, bakım kılavuzlarında, eğitim materyallerinde, çalışma talimatlarında vb. görseller (patlatılmış görünümler, çeşitli animasyonlar vb.) oluşturulabilmeli, kullanılabilmeli ve bu görseller 3D verilere ve ürün reçetesine bağlanmalıdır.
• Kataloglarda alternatif veya yedek parçalar tanımlanmalıdır.

29.10.3. Bilgi Yönetimi

• Belirli ürün konfigürasyonları veya kullanım koşullarında hangi içeriğin kullanılacağını belirlemek için uygulanabilirlik kuralları oluşturulmalıdır.
• Tasarım ve hizmet bilgileri bağlantılı olmalıdır. Tasarım bilgilerinde yapılan değişiklikler hizmet bilgilerine aktarılmalıdır.

29.10.4. Teknik doküman

• Kullanım kılavuzları, parça katalogları, servis belgeleri, onarım kılavuzları, eğitim kılavuzları vb. PLM sisteminde yönetilmelidir.
• Teknik dokümanların içerikleri, ilgili tasarım verileri değiştiğinde dinamik olarak güncellenmelidir.
• XML tabanlı içerikler PLM sisteminde oluşturulmalı ve tasarım verileri değiştiğinde otomatik olarak güncellenmelidir.
• XML geliştirme aracı, Arbortext, Cortona 3D, Framemaker vb. PLM ile çift yönlü olarak çalışmalıdır.
• İçerik yönetimi (konu ve veri modülü yönetimi) PLM sistemi içerisinde yapılmalıdır.
• Servis teknik dokümanları, SBOM ve 3D/2D verileri değiştiğinde otomatik olarak güncellenmelidir.
• Çeşitli standartların (DITA, S1000D, vb.) yazılması ve yayınlanması için kodlar, konfigürasyonlar, stil sayfaları, teknik özellikler vb. içeren kütüphaneler PLM sisteminde yönetilmeldir.
• Servis dokümanları için çeviri yönetimi, birden çok dilde XML paketleri oluşturularak uygulanmalıdır.
• Sağdan sola yazı dilleri desteklenmelidir. (Arapça).
• PLM, XML tabanlı hizmet içeriklerini otomatik olarak farklı formatlarda (PDF, html vb.) ve önceden tanımlanmış yayınlama kurallarına göre birden çok dilde yayınlayabilir.

5.8 Yazılım Yönetimi ve Entegrasyonu

5.8.1 Yazılım Veri Yönetimi

• Yazılım veri yönetimi PLM sisteminde yapılmalıdır.
• Yazılım verileri, gömülü sistemler için elektronik donanım ve mekanik parça verileri ile ilişkilendirilebilmelidir.

5.8.2 Yayın ve Değişiklik Yönetimi

• Yazılım veri yayınlama ve değiştirme süreçleri PLM sisteminde tasarlanmalı ve uygulanmalıdır.

5.8.3 ALM Entegrasyonu

• ALM yazılım verileri ve süreçleri, PLM araçları ve süreçleri ile entegre edilmelidir.
• Github Git, IBM Clearcase, Microsoft Azure DevOps (TFS), Collabnet SVN/Subversion vb. ALM uygulamaları PLM sistemi ile entegre edilmeli ve veri entegrasyonu gerçek zamanlı ve çift yönlü olmalıdır.
• Github Git, IBM Clearcase, Microsoft Azure DevOps (TFS), Collabnet SVN/Subversion uygulamalarındaki geçmiş veriler PLM sistemine taşınmalıdır.

6.Sonuç

PLM sistemleri şirketler için büyük faydalar vaat etmektedir. Yapılan araştırma sonuçlarında bu faydalar net olarak görülmektedir. Ancak çoğu şirket başarılı bir PLM kurulumu gerçekleştiremediği için bu faydaları sağlayamamakta veya kısıtlı olarak sağlamaktadır. Bu makale kapsamında şirketlerde PLM sistemlerinin doğru bir şekilde kurulmasını sağlayacak bir PLM uygulama metodolojisi paylaşılmıştır. Bu metodoloji ile şirketlerin başarılı bir PLM kurulumu gerçekleştirerek PLM sistemlerinden sağlayacağı faydayı maksimum seviyeye çıkartılması amaçlanmıştır. Nitekim bu metodoloji ilgili tüm süreçler için ayrı ayrı uygulandığı taktirde PLM kurulumunun başarı ile sonuçlanması sağlamaktadır. Metodolojiye ek olarak kurulum ve uygulama aşamalarında dikkat edilecek hususlar PLM başarısını etkileyen diğer önemli kriterlerdir. Bu kriterlerden herhangi birinin sağlanmadığı durumda PLM kurulumunun başarısı da önemli ölçüde azalmaktadır.