PLM yazılımı seçerken yalnızca ürün özelliklerini veya lisans fiyatlarını karşılaştırmak yeterli değildir. Doğru çözüm; şirketin ürün geliştirme süreçlerine, kullandığı CAD ve ERP sistemlerine, ürün ağacı yapısına, değişiklik yönetimi ihtiyaçlarına, veri güvenliği kurallarına ve büyüme planlarına uyum sağlamalıdır.

Seçim sürecinde önce çözülmek istenen iş problemleri belirlenmeli, ardından aday yazılımlar şirketin kendi verileri ve gerçek kullanım senaryoları üzerinden test edilmelidir. Lisans maliyetinin yanında veri geçişi, entegrasyon, eğitim, danışmanlık, destek ve sistem yönetimi maliyetleri de değerlendirilmelidir.

Her işletme için geçerli tek bir “en iyi PLM yazılımı” yoktur. En uygun çözüm; sektör, ürün karmaşıklığı, kullanıcı profili, mevcut sistemler ve hedeflenen süreç kapsamına göre değişir.

PLM Yazılımı Seçimine Neden Özellik Listesiyle Başlanmamalı?

PLM yazılımları; CAD ve doküman yönetimi, ürün ağacı, mühendislik değişiklikleri, gereksinimler, projeler, kalite süreçleri, konfigürasyon ve tedarikçi iş birliği gibi çok sayıda yetenek sunabilir. Ancak bir yazılımın uzun bir özellik listesine sahip olması, şirketin ihtiyaçlarına uygun olduğu anlamına gelmez.

PLM yazılımı seçimine şu soruyla başlanmalıdır:

“Şirketimizde ürün bilgisinin yönetilmesiyle ilgili hangi problemi çözmek istiyoruz?”

Temel problem aşağıdaki alanlardan biri veya birkaçı olabilir:

• Çalışanların güncel teknik resim ve dokümanlara ulaşamaması
• CAD dosyalarının kişisel bilgisayarlarda veya ortak klasörlerde tutulması
• Aynı parçanın farklı kodlarla tekrar oluşturulması
• Mühendislik değişikliklerinin e-posta ve Excel üzerinden takip edilmesi
• ERP’deki ürün ağacı ile mühendislik ürün ağacının uyuşmaması
• Tasarım, üretim, kalite ve satın alma ekiplerinin farklı verilerle çalışması
• Ürün revizyonlarının ve onay geçmişinin izlenememesi
• Proje dokümanları ile ürün verileri arasında bağlantı kurulamaması
• Tedarikçilerle paylaşılan teknik verilerin kontrol edilememesi

PLM projesinin ilk kapsamı, tespit edilen öncelikli problemlere göre belirlenmelidir. Bütün süreçleri aynı anda dönüştürmeye çalışmak yerine, ölçülebilir ve yönetilebilir kullanım senaryolarıyla başlamak daha kontrollü bir yol haritası oluşturabilir.

1. PLM Kapsamını Netleştirin

PLM bütün şirketlerde aynı süreçleri kapsamaz. Bir makine üreticisi için CAD verisi, ürün ağacı ve mühendislik değişiklikleri öncelikli olabilirken otomotiv tedarikçisi için konfigürasyon, kalite ve müşteri gereksinimlerinin izlenebilirliği daha kritik olabilir.

Seçim öncesinde aşağıdaki kapsam soruları cevaplanmalıdır:

• Yalnızca mühendislik verileri mi yönetilecek?
• CAD dosyaları ve teknik dokümanlar kapsama dahil edilecek mi?
• EBOM ve MBOM gibi farklı ürün ağacı yapıları yönetilecek mi?
• Mühendislik değişiklik talepleri ve onayları sisteme taşınacak mı?
• Gereksinim, proje ve kalite süreçleri kapsama alınacak mı?
• Tedarikçiler veya müşteriler sisteme erişecek mi?
• Satış sonrası servis bilgileri ürün kaydıyla ilişkilendirilecek mi?
• Birden fazla fabrika veya şirket aynı platformu kullanacak mı?
• Mevcut PDM sistemi korunacak mı, değiştirilecek mi?
• Ürün verileriyle ilişkili raporlama ihtiyaçları neler olacak?

Bu soruların cevapları, ihtiyaç duyulan yazılım rollerini, uygulamaları, entegrasyonları ve kullanıcı sayılarını doğrudan etkiler.

2. PDM İhtiyacı ile PLM Hedefini Birbirinden Ayırın

PDM genel olarak CAD dosyaları, teknik dokümanlar, versiyonlar, revizyonlar ve mühendislik verilerinin yönetimine odaklanır. PLM ise ürün bilgisini daha geniş bir yaşam döngüsü içinde; değişiklik, ürün ağacı, gereksinim, proje, kalite ve iş birliği süreçleriyle ilişkilendirebilir.

Ancak PDM ve PLM arasındaki sınır her üründe ve her yapılandırmada aynı değildir. Bazı çözümler güçlü PDM yetenekleriyle birlikte geniş PLM fonksiyonları sunabilir. Bu nedenle seçim yalnızca ürünün “PDM” veya “PLM” olarak adlandırılmasına göre yapılmamalıdır.

Şirket yalnızca CAD dosyalarının kontrollü biçimde saklanmasını, revizyonların izlenmesini ve teknik dokümanların yönetilmesini istiyorsa ilk aşamada PDM kapsamı yeterli olabilir. Ürün bilgisinin mühendislik dışındaki departmanlara yayılması, değişikliklerin uçtan uca yönetilmesi, ürün ağaçlarının farklı işlevlerle ilişkilendirilmesi ve ürün yaşam döngüsünün izlenmesi hedefleniyorsa daha geniş bir PLM kapsamı değerlendirilmelidir.

3. Seçim Ekibine İlgili Departmanları Dahil Edin

PLM yalnızca tasarım veya mühendislik departmanını etkileyen bir sistem değildir. Ürün bilgisini oluşturan, değiştiren, onaylayan veya kullanan bölümler de seçim sürecine dahil edilmelidir.

Değerlendirme ekibinde ihtiyaca göre şu roller bulunabilir:

• Ürün geliştirme ve Ar-Ge
• Tasarım mühendisliği
• Üretim mühendisliği
• Kalite
• Proje yönetimi
• Satın alma ve tedarik zinciri
• Satış sonrası servis
• Bilgi teknolojileri
• Bilgi güvenliği
• Süreç sahipleri
• Üst yönetim temsilcisi

Her departmanın ayrı bir özellik listesi oluşturması yerine, departmanlar arasında ilerleyen ortak iş senaryoları belirlenmelidir. Örneğin bir tasarım değişikliğinin mühendislikten üretime, kaliteye, satın almaya ve ERP sistemine nasıl aktarılacağı uçtan uca değerlendirilmelidir.

4. CAD, CAE ve CAM Entegrasyonlarını Kontrol Edin

Mühendislik yoğun şirketlerde PLM yazılımının kullanılan tasarım, analiz ve üretim sistemleriyle uyumu önemli bir seçim kriteridir.

Aşağıdaki sorular gerçek dosyalar üzerinden test edilmelidir:

• CAD dosyaları doğrudan sistem içinden açılıp kaydedilebiliyor mu?
• Parça, montaj ve teknik resim ilişkileri korunuyor mu?
• Referans dosyaları ve dış bağlantılar güvenli biçimde yönetiliyor mu?
• Revizyon ve versiyon arasındaki fark kullanıcılar tarafından anlaşılabiliyor mu?
• CAD ürün ağacı PLM sistemine doğru aktarılıyor mu?
• Birden fazla CAD yazılımıyla çalışmak mümkün mü?
• CAD kullanmayan çalışanlar modelleri görüntüleyebiliyor mu?
• Simülasyon ve CAM verileri ürün kaydıyla ilişkilendirilebiliyor mu?
• Büyük montajların sisteme yüklenmesi ve açılması sırasında performans yeterli mi?

Şirket CATIA, SOLIDWORKS veya farklı CAD sistemlerini birlikte kullanıyorsa çoklu CAD ortamı yalnızca sunum üzerinden değerlendirilmemelidir. Gerçek montajlar, teknik resimler ve referans ilişkileri kullanılarak test yapılmalıdır.

5. Ürün Ağacı ve Konfigürasyon Yönetimini İnceleyin

Ürün ağacı yönetimi, birçok PLM projesinin merkezinde yer alır. Yazılımın yalnızca bir BOM tablosu göstermesi yeterli değildir. Ürün yapısının farklı departmanlar ve yaşam döngüsü aşamaları arasında nasıl yönetildiği değerlendirilmelidir.

İhtiyaca göre şu yetenekler incelenebilir:

• Mühendislik ürün ağacı, yani EBOM yönetimi
• Üretim ürün ağacı, yani MBOM yönetimi
• EBOM ve MBOM arasında ilişki kurulması
• Alternatif ve muadil parçalar
• Ürün seçenekleri ve varyantlar
• Seri numarası veya tarih bazlı geçerlilik
• Parça ve montaj revizyonları
• Standart parçaların yeniden kullanılması
• Ürün ağacı karşılaştırması
• Değişikliklerin alt montajlara etkisi
• CAD yapısı ile BOM arasındaki ilişkinin korunması
• Ürün ağacının ERP’ye kontrollü aktarılması

Ürün ağacı yapısı, şirketin ürün geliştirme ve üretim modeline göre değişir. Bu nedenle çözümün yalnızca standart bir BOM ekranı değil, şirketin gerçek ürün yapısını destekleyip desteklemediği kontrol edilmelidir.

6. Değişiklik Yönetimini Gerçek Bir Senaryoyla Test Edin

Mühendislik değişiklik yönetimi yalnızca bir onay formundan oluşmaz. Değişikliğin gerekçesi, etkilenen parçalar, sorumlular, teknik etkiler, onaylar, uygulama tarihi ve üretime yansıması birlikte izlenebilmelidir.

Demo sırasında örnek bir mühendislik değişikliği oluşturularak şu adımlar test edilmelidir:

1. Değişiklik talebinin açılması
2. Değişikliğin gerekçesinin kaydedilmesi
3. Etkilenen parça, doküman ve ürün ağaçlarının belirlenmesi
4. Teknik, üretimsel ve ticari etkinin değerlendirilmesi
5. İlgili kullanıcılara inceleme ve onay görevi atanması
6. Yeni revizyonun hazırlanması
7. Değişikliğin uygulanması ve doğrulanması
8. Güncel verinin ERP veya üretim sistemine aktarılması
9. Değişiklik geçmişinin raporlanması

Sistemin değişiklik sırasında yalnızca dokümanları değil, ilişkili ürün verilerini ve süreçleri de gösterebilmesi önemlidir.

7. ERP Entegrasyonunu Projenin Başında Değerlendirin

PLM, ERP’nin yerine geçen bir sistem değildir. İki sistem farklı ancak bağlantılı görevleri yerine getirir.

Genel olarak PLM; ürün tanımı, mühendislik verisi, ürün ağacı, revizyon ve değişiklik süreçlerine odaklanır. ERP ise malzeme planlama, stok, satın alma, maliyet, sipariş ve üretim işlemlerini yönetir.

Ancak hangi verinin hangi sistemde oluşturulacağı ve yönetileceği şirketin sistem mimarisine göre belirlenmelidir.

Seçim sırasında şu sorular cevaplanmalıdır:

• Parça kodunu hangi sistem oluşturacak?
• Onaylanan ürün ağacı ERP’ye nasıl aktarılacak?
• Malzeme, tedarikçi ve maliyet bilgileri hangi sistemden gelecek?
• Revizyon değişiklikleri iki sistem arasında nasıl eşleştirilecek?
• Veri aktarımı tek yönlü mü, çift yönlü mü olacak?
• Hatalı veya eksik veri aktarımında nasıl uyarı verilecek?
• Entegrasyon hazır bir bağlantıyla mı, özel geliştirmeyle mi kurulacak?
• Entegrasyonun bakım sorumluluğu kimde olacak?
• Sistemlerden biri güncellendiğinde entegrasyon nasıl etkilenecek?

PLM ve ERP’nin aynı verinin kontrolsüz kopyalarını tutması yerine, her veri alanı için ana sistem ve veri sahibi belirlenmelidir.

8. Veri Geçişini Lisans Seçiminden Önce Planlayın

Mevcut dosyaların ve ürün bilgilerinin yeni PLM sistemine taşınması, projenin en fazla hazırlık gerektiren aşamalarından biri olabilir.

Geçiş öncesinde şu konular incelenmelidir:

• Kaç dosya ve kayıt taşınacak?
• Ortak klasörlerde mükerrer veriler var mı?
• Dosya adlandırma ve parça kodlama kuralları tutarlı mı?
• Eski revizyonların tamamı taşınacak mı?
• Hangi veriler aktif, hangileri arşiv niteliğinde?
• CAD referansları ve montaj ilişkileri korunabilecek mi?
• Eksik meta veriler nasıl tamamlanacak?
• Mevcut onay ve revizyon geçmişi taşınacak mı?
• Hatalı veya eksik kayıtlar nasıl ele alınacak?
• Geçiş sonrasında veriler nasıl doğrulanacak?

Eski klasör yapısını temizlemeden aynen yeni sisteme aktarmak, mevcut düzensizliği PLM ortamına taşıyabilir. Veri temizliği, sınıflandırma, eşleştirme ve doğrulama işlemleri ayrı bir çalışma paketi olarak planlanmalıdır.

9. Bulut, Şirket İçi veya Hibrit Kullanım Modelini Değerlendirin

PLM çözümleri bulut, şirket içi veya ürüne bağlı olarak hibrit modellerle sunulabilir. Her şirket için geçerli tek bir doğru model yoktur.

Karar verirken şu kriterler değerlendirilmelidir:

• Verilerin nerede tutulacağı
• Şirketin bilgi güvenliği politikaları
• Sunucu ve sistem yönetimi kapasitesi
• Güncellemelerin kim tarafından yapılacağı
• Farklı lokasyonlardan erişim ihtiyacı
• Tedarikçi ve müşteri erişimleri
• CAD dosyalarının boyutu
• İnternet bağlantısı ve performans koşulları
• Yedekleme ve felaket kurtarma gereksinimleri
• Sektörel mevzuat ve veri yerleşimi şartları
• Yeni kullanıcı ve lokasyon ekleme planları
• Lisans, altyapı ve yönetim maliyetleri

Bulut çözümü otomatik olarak daha uygun veya şirket içi kurulum otomatik olarak daha güvenli kabul edilmemelidir. Karar, şirketin teknik gereksinimleri ve risk politikaları üzerinden verilmelidir.

10. Güvenlik ve İzlenebilirlik Gereksinimlerini Kontrol Edin

PLM sistemi, şirketin fikrî mülkiyet niteliğindeki ürün verilerini barındırabilir. Bu nedenle güvenlik yalnızca kullanıcı adı ve paroladan ibaret görülmemelidir.

Kontrol edilmesi gereken başlıca noktalar şunlardır:

• Rol ve proje bazlı erişim yetkileri
• Revizyon ve işlem geçmişi
• Denetim izi
• Çok faktörlü kimlik doğrulama
• Kurumsal kimlik sistemi ve SSO desteği
• Veri yedekleme ve kurtarma prosedürleri
• Dış kullanıcı ve tedarikçi erişimi
• Dosya indirme ve paylaşma kısıtlamaları
• Görev ayrılığı ve onay yetkileri
• Veri saklama politikaları
• Kullanıcıların sistemden ayrılması durumunda erişimlerin kapatılması
• Güvenlik olaylarının kaydedilmesi ve raporlanması

Özellikle savunma, havacılık, otomotiv ve düzenlemeye tabi sektörlerde şirketin kendi güvenlik ve uygunluk şartları ayrıca değerlendirilmelidir.

11. Kullanıcı Deneyimini ve Benimsenmeyi Ölçün

Teknik olarak güçlü bir sistem, çalışanlar günlük işlerinde sistemi kullanmıyorsa beklenen değeri üretmeyebilir.

Demo ve pilot çalışmalarına yalnızca yöneticiler değil, sistemi günlük kullanacak çalışanlar da katılmalıdır. Aşağıdaki işlemlerin ne kadar anlaşılır olduğu gözlemlenmelidir:

• Doküman ve parça arama
• Yeni parça kaydı oluşturma
• CAD verisi kaydetme
• Revizyon açma
• Onay görevini tamamlama
• Ürün ağacını görüntüleme
• Değişiklik talebi oluşturma
• İlgili dokümanlara erişme
• Rapor veya gösterge paneli kullanma

Amaç bütün kullanıcıları aynı ekranlarla çalıştırmak değildir. Mühendislik, kalite, üretim, satın alma ve yönetim gibi farklı kullanıcı grupları için gerekli bilgiyi sade biçimde sunan rol bazlı deneyimler değerlendirilmelidir.

Kullanıcıların eğitim ihtiyacı, günlük işlem sayısı ve sisteme erişim biçimi de seçim kararına dahil edilmelidir.

12. Yapılandırma ile Özelleştirme Arasındaki Farkı Sorun

PLM çözümünün şirket süreçlerine uyarlanması gerekebilir. Ancak her ihtiyacın özel kod geliştirilerek karşılanması, bakım ve sürüm güncelleme süreçlerini zorlaştırabilir.

Tedarikçiye şu sorular yöneltilmelidir:

• İhtiyaç standart fonksiyonlarla karşılanabiliyor mu?
• Rol, form, alan ve iş akışları yapılandırılabiliyor mu?
• Hangi gereksinimler özel geliştirme gerektiriyor?
• Özelleştirmeler sürüm güncellemelerinden nasıl etkileniyor?
• Geliştirilen bağlantıların dokümantasyonu kime ait olacak?
• Sistem yöneticileri hangi değişiklikleri kendileri yapabilecek?
• Yapılandırmalar farklı şirket veya tesislerde tekrar kullanılabilecek mi?
• Özel geliştirmelerin bakım maliyeti nasıl hesaplanacak?

Şirket süreçlerini değerlendirmeden sistemi aşırı özelleştirmek risk oluşturabilir. Bununla birlikte bütün iş süreçlerini yazılımın varsayılan yapısına zorlamak da kullanıcıların gerçek ihtiyaçlarının karşılanmamasına neden olabilir.

13. Toplam Sahip Olma Maliyetini Hesaplayın

PLM maliyeti yalnızca lisans veya abonelik ücretinden oluşmaz. Çözümler karşılaştırılırken toplam sahip olma maliyetine aşağıdaki kalemler dahil edilmelidir:

• Lisans veya abonelik ücretleri
• İhtiyaç analizi ve danışmanlık
• Kurulum ve yapılandırma
• Entegrasyon geliştirmeleri
• Veri temizleme ve geçiş
• Sunucu veya bulut altyapısı
• Kullanıcı eğitimleri
• Sistem yöneticisi eğitimleri
• Test ve canlıya geçiş desteği
• Bakım ve teknik destek
• Sürüm güncellemeleri
• Sistem yönetimi
• Özel geliştirmelerin bakımı
• Yeni kullanıcı ve modül maliyetleri

Doğrulanmış şirket verisi bulunmadan PLM’nin belirli bir yüzdeyle maliyet azaltacağı veya yatırımın belirli bir sürede geri döneceği söylenmemelidir.

Yatırım değerlendirmesi, şirketin mevcut koşulları üzerinden yapılmalıdır. Teknik veri aramak için harcanan süre, yanlış revizyon kullanımı, yeniden işleme, mükerrer parça oluşturma, değişiklik gecikmeleri ve mevcut sistemlerin yönetim maliyetleri ölçülebiliyorsa PLM yatırımının etkisi daha gerçekçi biçimde değerlendirilebilir.

14. Standart Demo Yerine Senaryo Tabanlı Değerlendirme Yapın

Tedarikçinin hazırladığı genel ürün demosu, yazılımın şirketin gerçek süreçlerine uygunluğunu göstermeyebilir.

Değerlendirme için anonimleştirilmiş gerçek verilerden oluşan bir senaryo hazırlanabilir:

• Bir parça ve bağlı teknik resim
• Küçük bir ürün ağacı
• Örnek bir değişiklik talebi
• Birden fazla kullanıcıdan oluşan onay süreci
• ERP’ye aktarılacak veri alanları
• Farklı departmanlardan kullanıcı rolleri
• Revizyon geçmişi
• Tedarikçiyle paylaşılacak bir doküman

Bütün adayların aynı senaryoyu uygulaması, çözümleri daha tutarlı biçimde karşılaştırmayı sağlar. Kritik veya teknik açıdan belirsiz gereksinimler için sınırlı kapsamlı bir pilot ya da kavram kanıtlama çalışması yapılabilir.

PLM Yazılımı Değerlendirme Kriterleri

PLM adayları aşağıdaki başlıklar üzerinden puanlanabilir:

• Süreç ve fonksiyon uyumu
• CAD ve mühendislik uygulamalarıyla entegrasyon
• ERP ve diğer kurumsal sistemlerle entegrasyon
• Ürün ağacı ve konfigürasyon yönetimi
• Değişiklik yönetimi
• Veri geçişi
• Kullanılabilirlik
• Güvenlik ve izlenebilirlik
• Bulut veya şirket içi kullanım seçenekleri
• Ölçeklenebilirlik
• Yapılandırma ve özelleştirme olanakları
• Raporlama
• Çözüm ortağının deneyimi
• Eğitim ve teknik destek
• Toplam sahip olma maliyeti

Kriterlerin ağırlığı şirketin önceliklerine göre belirlenmelidir. Örneğin çoklu CAD ortamında çalışan bir işletme için CAD entegrasyonu yüksek ağırlığa sahip olabilirken, düzenlemeye tabi bir sektörde güvenlik ve izlenebilirlik daha öncelikli olabilir.

Ağırlıklı puanlama tek başına karar vermek için yeterli değildir. Kritik bir güvenlik, entegrasyon veya mevzuat gereksiniminin karşılanmaması, toplam puan yüksek olsa bile çözümü uygunsuz hale getirebilir.

PLM Çözüm Ortağı Seçerken Hangi Sorular Sorulmalı?

Yazılım kadar uygulama ve danışmanlık ekibinin yetkinliği de değerlendirilmelidir.

Çözüm ortağına şu sorular yöneltilebilir:

• Benzer sektörlerde hangi PLM süreçlerini hayata geçirdiniz?
• İhtiyaç analizi nasıl yürütülüyor?
• Projenin kapsamı ve başarı ölçütleri nasıl belirlenecek?
• Proje ekibinde hangi uzmanlar görev alacak?
• Veri geçişinden hangi taraf sorumlu olacak?
• CAD ve ERP entegrasyonunu hangi ekip gerçekleştirecek?
• Canlıya geçiş öncesinde hangi testler yapılacak?
• Kullanıcı ve sistem yöneticisi eğitimleri nasıl planlanacak?
• Canlıya geçiş sonrasında destek modeli nedir?
• Yapılandırmalar ve geliştirmeler nasıl dokümante edilecek?
• Projenin kapsamı değişirse süreç nasıl yönetilecek?
• Güncellemeler sırasında özelleştirmeler nasıl korunacak?
• Şirket içinde bilgi birikimi oluşturmak için nasıl bir eğitim planı uygulanacak?

Belirsiz proje kapsamı, yalnızca ürün özelliklerine dayanan satış sunumu, doğrulanmamış fayda oranları ve veri geçişinin proje sonuna bırakılması önemli risk işaretleridir.

3DEXPERIENCE ve ENOVIA Değerlendirmeye Nasıl Alınmalı?

ENOVIA ve 3DEXPERIENCE platformu; ürün verisi, değişiklik, konfigürasyon, ürün ağacı, gereksinim, proje ve iş birliği süreçlerine yönelik farklı uygulama ve roller sunar.

Ancak bu, tek bir lisansın veya standart bir kurulumun her şirketin bütün PLM ihtiyaçlarını otomatik olarak karşılayacağı anlamına gelmez.

Değerlendirme sırasında aşağıdaki konular ayrı ayrı belirlenmelidir:

• Hangi kullanıcı rollerinin gerektiği
• Hangi süreçlerin ilk proje kapsamına alınacağı
• CATIA ve diğer mühendislik uygulamalarıyla kurulacak bağlantılar
• ERP ve mevcut kurumsal sistem entegrasyonları
• Bulut veya şirket içi kullanım tercihi
• Veri geçişinin kapsamı
• Yapılandırma ihtiyacı
• Özel geliştirme gereksinimleri
• Eğitim ve destek modeli
• Projenin ilerleyen aşamalarında eklenecek süreçler

Yenaplus ile gerçekleştirilecek ön değerlendirmede şirketin mevcut ürün geliştirme süreçleri, veri kaynakları, CAD ve ERP altyapısı ile entegrasyon ihtiyaçları incelenerek uygun PLM kapsamı ve uygulama yol haritası oluşturulabilir.

Sıkça Sorulan Sorular

En iyi PLM yazılımı hangisidir?

Bütün şirketler için geçerli tek bir en iyi PLM yazılımı yoktur. Uygun çözüm; sektör, ürün karmaşıklığı, kullanılan CAD ve ERP sistemleri, güvenlik ihtiyaçları, kullanıcı sayısı ve hedeflenen süreç kapsamına göre belirlenir.

PLM yazılımı ERP’nin yerine geçer mi?

Hayır. PLM ve ERP farklı ancak bağlantılı görevleri yerine getirir. PLM ürün tanımı ve geliştirme süreçlerine; ERP ise kaynak, stok, satın alma, maliyet ve üretim işlemlerine odaklanır. İki sistem arasındaki veri sahipliği ve entegrasyon kuralları proje kapsamında belirlenmelidir.

PLM ile PDM arasındaki fark nedir?

PDM daha çok CAD dosyaları, teknik dokümanlar, versiyonlar ve revizyonların yönetimine odaklanır. PLM ürün bilgisini değişiklik, ürün ağacı, gereksinim, proje, kalite ve diğer yaşam döngüsü süreçleriyle ilişkilendirebilir. Bununla birlikte PDM ve PLM arasındaki sınırlar kullanılan ürüne ve yapılandırmaya göre örtüşebilir.

PLM seçiminde önce demo mu, ihtiyaç analizi mi yapılmalıdır?

Önce temel ihtiyaçlar ve kullanım senaryoları belirlenmelidir. Aksi halde demo şirketin gerçek problemleri yerine ürünün güçlü görünen özelliklerine odaklanabilir. İhtiyaç analizi sonrasında bütün adayların aynı senaryolar üzerinden değerlendirilmesi daha sağlıklı bir karşılaştırma sağlar.

Bulut PLM mi, şirket içi PLM mi tercih edilmeli?

Karar; güvenlik politikaları, BT kapasitesi, erişim ihtiyacı, veri yerleşimi, performans, güncelleme yönetimi ve maliyet kriterlerine bağlıdır. Her şirket için geçerli tek bir doğru kullanım modeli bulunmaz.

PLM bütün Excel dosyalarını ortadan kaldırır mı?

PLM, ürün verilerinin ve iş akışlarının daha kontrollü yönetilmesini sağlayabilir. Ancak bütün Excel kullanımının otomatik olarak ortadan kalkacağı söylenemez. Hangi tabloların PLM sistemine taşınacağı, hangilerinin başka araçlarda kalacağı süreç analizi sırasında belirlenmelidir.

PLM projesi ne kadar sürer?

Proje süresi; süreç kapsamı, kullanıcı sayısı, veri kalitesi, entegrasyonlar, özelleştirme ihtiyacı ve kullanım modeline göre değişir. İhtiyaç analizi yapılmadan kesin bir uygulama süresi vermek doğru değildir.

Küçük ve orta ölçekli işletmeler PLM kullanabilir mi?

Evet. PLM ihtiyacını yalnızca şirket büyüklüğü belirlemez. Ürün çeşidi, mühendislik değişikliği sayısı, doküman yoğunluğu, ürün ağacı karmaşıklığı ve farklı ekiplerin aynı veriyi kullanma ihtiyacı daha belirleyici olabilir. Kapsam, şirketin öncelikli ihtiyaçlarına göre aşamalı biçimde oluşturulabilir.

PLM yazılımı satın almadan önce pilot çalışma yapılmalı mı?

Kritik süreçler, entegrasyonlar veya veri geçişi konusunda belirsizlik bulunuyorsa pilot çalışma faydalı olabilir. Pilotun kapsamı, başarı kriterleri ve kullanılacak örnek veriler önceden belirlenmelidir.

Sonuç

PLM yazılımı seçimi, yalnızca ürün özelliklerini ve lisans ücretlerini karşılaştırmaktan daha kapsamlı bir karardır. Sağlıklı bir değerlendirme; iş problemlerinin tanımlanmasını, süreç kapsamının belirlenmesini, gerçek senaryolarla test yapılmasını, entegrasyon ve veri geçişi planının oluşturulmasını, kullanıcıların sürece katılmasını ve toplam sahip olma maliyetinin hesaplanmasını gerektirir.

3DEXPERIENCE ve ENOVIA gibi kapsamlı platformlar farklı ürün yaşam döngüsü süreçleri için geniş bir yetenek seti sunabilir. Bununla birlikte doğru rollerin, uygulamaların ve proje kapsamının şirketin ihtiyaçlarına göre belirlenmesi gerekir.

Şirketinizin mevcut ürün geliştirme süreçlerini, CAD ve ERP altyapısını ve veri yönetimi ihtiyaçlarını değerlendirmek için Yenasoft ekibiyle iletişime geçebilirsiniz.