Veri Var. Sorun, Nerede Durduğu.
Markalar DPP hazırlıklarını haritalamaya başladıklarında tipik olarak hem rahatlatıcı hem sinir bozucu bir şey keşfediyorlar: Dijital Ürün Pasaportunun gerektirdiği verinin büyük bölümü kuruluşlarında zaten bir yerde mevcut. Lif bileşimi PLM sisteminde. Kimyasal uyum kayıtları bir uyum yönetim aracında veya paylaşılan sürücüde. Tedarikçi adları ERP'de. Sertifikalar sürdürülebilirlik ekibi tarafından yönetilen klasörde. Bakım talimatları bakım etiketinin kendisinde.
Sorun verinin var olmaması değil. Sorun, birbirinden kopuk sistemlere dağılmış parçalarda bulunması — birbirleriyle konuşamayan formatlarda tutuluyor ve bunları birbirine bağlayan ortak veri standardı olmaksızın farklı ekipler tarafından yönetiliyor.
DPP uyumu için eski BT zorluğu bu. Ve pek çok marka için, mevcut durumları ile uyumlu, işlevsel bir Dijital Ürün Pasaportu arasındaki tek en büyük engel.
Markalar Bugün Ürün Verilerini Nasıl Tutuyor?
Tipik orta ölçekli tekstil markası, her biri belirli bir sorunu çözmek için oluşturulmuş — birbirleriyle veri paylaşmak için değil — sistemlerin mozaiğinde ürün verilerini yönetiyor:
Ürün Yaşam Döngüsü Yönetimi (PLM)
PLM sistemleri tasarım ve geliştirme verilerini tutar — malzeme spesifikasyonları, Malzeme Listesi (BOM), teknik paketler, tedarikçi atamaları. Bu, genellikle bir markanın BT ortamındaki DPP ile ilgili en zengin ürün verisi kaynağı. Ancak PLM sistemleri tipik olarak tasarım ve geliştirme aşaması için optimize edilmiş. Ürün üretime ve ticari satışa geçtiğinde PLM verisi çoğunlukla yerinde kilitleniyor — PLM'deki kaydın örnekleme veya üretim sırasında yapılan değişiklikleri yansıtmıyor olabileceği anlamına geliyor.
Kurumsal Kaynak Planlama (ERP)
ERP sistemleri ticari ve lojistik verileri yönetir — satın alma siparişleri, envanter, tedarikçi faturaları, sevkiyat kayıtları. DPP tedarik zinciri veri gereksinimleriyle doğrudan ilgili tedarikçi adlarını, sipariş miktarlarını ve üretim tesisi bilgilerini içeriyorlar. Ancak ERP verisi sürdürülebilirlik açıklaması için değil, finansal ve operasyonel amaçlar için yapılandırılmış — DPP'nin gerektirdiği tedarik zinciri ayrıntısı (tesis adları, üretim aşaması, işleme ülkesi) nadiren buluyor.
Uyum ve Kimyasal Yönetim Araçları
REACH uyum belgeleri, ÇYED beyanları ve test raporları özel uyum araçlarında, belge yönetim sistemlerinde veya basitçe paylaşılan klasörlerde PDF olarak yönetiliyor. Bu veriler çoğunlukla daha geniş ürün verisi ekosistemine sınırlı entegrasyonu olan ayrı bir uyum veya kalite ekibi tarafından tutuluyor.
Tedarikçi Portalları ve E-posta
Tedarik zinciri verilerinin büyük bölümü — fabrika denetim sonuçları, sertifikalar, malzeme beyanları — tedarikçi portalları, e-posta yoluyla gönderilen elektronik tablo şablonları veya manuel anketler aracılığıyla toplanıyor. Veri tutarsız formatlarda geliyor, dahili sistemlere manuel olarak giriliyor (girildiyse) ve bireysel ürün düzeyine nadiren bağlanıyor.
Elektronik Tablolar
Çoğu markada sürdürülebilirlik ve tedarik zinciri verilerinin önemli bir bölümü elektronik tablolarda yaşıyor — bireyler tarafından tutuluyor, tutarsız biçimde yapılandırılmış ve tabloyu oluşturan kişi kuruluştan ayrılırsa tek arıza noktasını temsil ediyor. Elektronik tablo tabanlı veri API aracılığıyla sorgulanamaz, makine okunabilir standarda göre yapılandırılmamış ve DPP'nin gerektirdiği ölçekte bireysel ürün birimi tanımlayıcılarına bağlanamaz.
Zorluk veri eksikliği değil. Veri mimarisi sorunu. Aynı bilgi, aralarında tek bir gerçek kaynağı olmayan, kayıtları sistemler arasında bağlayan tutarlı ürün tanımlayıcısı bulunmayan ve veriyi dış paydaşlara erişilebilir kılan API katmanı olmayan birden fazla kopuk sistemde mevcut.
DPP'nin Eski Sistemlerin Sağlayamadığı Gereksinimleri
Uyumlu bir DPP yalnızca verinin var olmasını değil — verinin eski sistemlerin desteklemek için tasarlanmadığı spesifik biçimlerde yapılandırılmış, bağlantılı ve erişilebilir olmasını gerektiriyor:
Tüm Verileri Bağlayan Tek Benzersiz Ürün Tanımlayıcısı
DPP, her veri kaydının, tüm sistemlerde tutarlı olan ve fiziksel ürünü dijital kayda bağlayan anahtar işlevi gören benzersiz seri numaralı ürün tanımlayıcısına bağlanmasını gerektiriyor. Çoğu eski sistem kendi dahili tanımlayıcılarını kullanıyor (PLM model kodları, ERP madde numaraları, uyum sistemi referansları) — bunlar birbirleriyle veya DPP'nin gerektirdiği GS1 tabanlı seri numaralı GTIN ile örtüşmüyor. Tipik olarak bir ürünün kaydını PLM, ERP, uyum ve sürdürülebilirlik sistemleri arasında bağlayan ana tanımlayıcı yok.
Makine Okunabilir, Yapılandırılmış Veri Formatları
DPP verisi, geri dönüştürücü platformları, gümrük araçları ve tüketiciye yönelik DPP arayüzleri dahil üçüncü taraf sistemler tarafından otomatik olarak işlenebilecek makine okunabilir formatlarda — yapılandırılmış JSON veya eşdeğeri — servis edilmelidir. PDF'lerde, taranmış belgelerde veya eski sistemlerdeki yapılandırılmamış metin alanlarında tutulan veriler, önemli dönüşüm çalışması olmadan bu formatta servis edilemez.
Gerçek Zamanlı API Erişilebilirliği
Ürünün QR kodu tarandığında çözümleyici isteği markanın veri uç noktasına yönlendiriyor ve bu uç nokta gerçek zamanlı olarak doğru veriyi döndürmeli. Eski sistemler — özellikle PLM ve ERP — tipik olarak ürün verilerini dışa yönelik API'ler aracılığıyla sunmak için tasarlanmamış. Veri dışa aktarmayı veya toplu raporlamayı destekleyebilirler; ancak DPP altyapısının gerektirdiği türde gerçek zamanlı, ürün birimi başına sorguyu değil.
Dinamik Veri Güncellemeleri
DPP verisi statik değil — tamir olayları, döngüsellik güncellemeleri ve sertifika değişikliklerinin canlı kayıtta yansıtılması gerekiyor. Üretim tamamlandıktan sonra ürün verilerini sabit olarak ele alan eski sistemlerin bu yaşam döngüsü güncellemeleri için mekanizması yok. Sistem güncellemeleri kabul edebilse bile, üçüncü tarafların (tamir operatörleri, geri dönüştürücüler) güncellemelerinin nasıl alınacağı, doğrulanacağı ve uygulanacağı konusunda tipik olarak tanımlanmış süreç bulunmuyor.
Entegrasyon Zorluğu
Parçalı eski sistemlerden uyumlu DPP veri altyapısına giden yol, temelde bir entegrasyon zorluğu. Amaç mevcut sistemleri değiştirmek değil — bunları bağlayan, verilerini normalleştiren ve sonucu standartlara uyumlu API aracılığıyla sunan bir katman oluşturmak.
Bu entegrasyon katmanı şunları yapmalı:
- PLM, ERP, uyum araçları ve tedarikçi veri kaynaklarından ürün verisi çekme
- Bu veriyi tutarlı ürün tanımlayıcısına ve standartlaştırılmış veri şemasına göre normalleştirme
- Yayımlanan DPP kayıtlarına yayılmadan önce boşlukları, tutarsızlıkları ve hataları yakalamak için veri kalitesi doğrulaması uygulama
- Normalleştirilmiş, doğrulanmış veriyi API aracılığıyla çözümleyiciye ve aşağı akış paydaşlarına servis etme
- Döngüsel ekonomi operatörlerinden dinamik güncellemeleri kabul etme ve işleme
- Tüm veri değişiklikleri için sürüm geçmişi ve denetim izleri tutma
Bu katmanı şirket içinde oluşturmak önemli bir yazılım mühendisliği projesi. Çoğu tekstil markası için normalleştirme, doğrulama ve API servisini yönetirken mevcut sistemlere standart entegrasyon protokolleri aracılığıyla bağlanan uzmanlaşmış DPP platformuyla entegrasyon, sıfırdan kurmaktan daha pratik.
Eski Sistemlerin İçinde Saklı Veri Kalitesi Sorunu
Yapısal uyumsuzluğun ötesinde, eski sistemler çoğunlukla yalnızca markalar DPP amaçları doğrultusunda veriyi birleştirmeye çalıştığında görünür hale gelen bir veri kalitesi sorununa ev sahipliği yapıyor. Yaygın sorunlar:
- Tutarsız tedarikçi adlandırması. Aynı fabrika PLM, ERP ve uyum kayıtlarında farklı isimler, kısaltmalar veya yazımlarla görünebilir — manuel uzlaştırma olmaksızın kayıtları otomatik olarak bağlamayı imkânsız kılıyor.
- Eksik bileşen düzeyinde bileşim verisi. PLM sistemleri çoğunlukla genel garman bileşimini (bakım etiketinde görünen rakam) kaydeder, ancak DPP'nin gerektirdiği bileşen düzeyinde dağılımı (gövde kumaşı, astar, aksesuar, iplik) kaydetmez.
- Güncel olmayan veya eksik menşe ülkesi verisi. ERP'de kayıtlı menşe ülkesi, gümrük amaçları doğrultusunda son montaj ülkesini yansıtıyor olabilir; bu, bir DPP'deki iki farklı alan olan hammaddelerin menşe ülkesinden farklı.
- Ürünlere bağlı olmayan sertifikasyon verisi. Sertifikasyon kayıtları çoğunlukla tedarikçi veya tesis düzeyinde mevcut; spesifik ürünlere veya ürün partilerine bağlı değil — hangi sertifikaların hangi DPP kaydına uygulandığını otomatik olarak belirlemeyi imkânsız kılıyor.
- Makine okunabilir olmayan formatlardaki uyum belgeleri. Taranmış PDF olarak tutulan test raporları, ÇYED beyanları ve REACH uyum belgeleri otomatik olarak ayrıştırılamaz ve yapılandırılmış formatta yeniden girilmesi gerekir.
Pratik Bir İlerleme Yolu
Eski BT zorluğuyla karşı karşıya kalan markalar, kapsamlı bir sistem revizyonu girişimi yerine aşamalı yaklaşmalı:
Adım 1: Mevcut Veri Ortamını Haritalayın
Herhangi bir teknoloji kararı vermeden önce DPP için gereken her veri kategorisinin şu anda nerede yaşadığını belgeleyin — hangi sistemin tuttuğunu, hangi formatta, hangi ayrıntı düzeyinde ve kimin sahip olduğunu. Bu harita hem çekilecek mevcut kaynakları hem de tedarikçi başvurusu veya yeni veri toplama süreçleriyle doldurulması gereken boşlukları ortaya koyacak.
Adım 2: Ortak Ürün Tanımlayıcısı Oluşturun
Tüm dahili sistemlerde tutarlı biçimde kullanılabilecek ana ürün tanımlayıcısını belirleyin veya oluşturun. Bu hemen nihai seri numaralı GTIN olmak zorunda değil — daha sonra GS1 uyumlu seri numaralı tanımlayıcıyla eşleştirilen dahili kod olabilir. Amaç, PLM, ERP, uyum ve sürdürülebilirlik kaynaklarından gelen verilerin aynı ürün kaydına bağlanmasına olanak tanıyan tutarlı anahtar.
Adım 3: Önce Statik, Nesnel Veriye Odaklanın
İlk veri birleştirme çabalarını hemen toplanmaya hazır nesnel veri noktalarına yoğunlaştırın — üretim yerleri, malzeme bileşimi, tedarikçi tanımlayıcıları, sertifikalar, bakım talimatları. Bunlar hâlâ sürmekte olan metodoloji kararlarına bağlı değil ve metodolojiye bağlı veri için düzenleyici tablo gelişmeye devam ederken yapılandırılıp doğrulanabilir.
Adım 4: Mevcut Sistemlerinizle Entegre Olan Bir DPP Platformu Seçin
DPP hizmet sağlayıcılarını değerlendirirken özellik setleri yerine entegrasyon kapasitesini önceliklendirin. Mevcut PLM ve ERP'nize standart API'ler aracılığıyla bağlanabilen — veriyi manuel yeniden giriş yerine otomatik çeken — platform, süregelen operasyonel yükü önemli ölçüde azaltacak. Tüm verinin yeni sisteme manuel girilmesini gerektiren platformlar ortama yalnızca başka bir silo ekler.
Adım 5: Veri Taşıma Öncesinde Veri Yönetişimini Planlayın
Veriyi DPP platformuna taşımadan önce sahipliği tanımlayın: her veri kategorisinden kim sorumlu? Güncellemeleri kim doğruluyor? Tedarikçi markanın dahili sistemlerin gösterdikleriyle çelişen veri sağlarsa ne olacak? Taşıma öncesinde alınan veri yönetişim kararları, birden fazla ekip veri doğruluğunu başkasının yönettiğini varsaydığında ortaya çıkan kalite sorunlarını önler.
epassportify mevcut PLM ve ERP sistemlerinizle entegre olarak DPP veri altyapınızı hızla kurmanıza yardımcı olur. Demo talep edin →
Sık Sorulan Sorular
DPP'ye uymak için PLM veya ERP sistemimizi değiştirmemiz gerekiyor mu?
Zorunlu değil. Amaç mevcut sistemleri değiştirmek değil, bunları bağlayan ve standartlara uyumlu DPP veri uç noktasını açığa çıkaran bir veri entegrasyon ve API katmanı oluşturmak. Mevcut sistemler DPP altyapısına veri katkısında bulunurken birincil işlevlerini sürdürebilir. Bununla birlikte, mevcut sistemler temel API entegrasyonunu destekleyemeyecek kadar eskiyse daha kapsamlı modernizasyon gerekebilir — ancak bu DPP uyumundan ayrı bir iş kararı.
Birden fazla eski sistemden ürün verisi birleştirmek ne kadar sürer?
Dahil olan sistem sayısına, kapsam dahilindeki ürün hacmine ve mevcut veri kalitesine büyük ölçüde bağlı. Bu süreci başlatan markalar, ilk veri denetimi ve boşluk tanımlamasının birkaç ay sürdüğünü ve veri kalitesi sorunlarının çözümünün — özellikle tedarikçi veri boşluklarının — önemli ölçüde daha uzun sürdüğünü bildiriyor. Parçalı eski veriden yapılandırılmış, doğrulanmış DPP'ye hazır veri setine geçen orta ölçekli marka için gerçekçi tahmin 12 ila 24 aylık odaklanmış çalışma.
DPP veri altyapısı için minimum uygulanabilir başlangıç noktası nedir?
Minimum uygulanabilir başlangıç noktası, tutarlı ürün tanımlayıcısına bağlı ve temel bir API sunan yapılandırılmış, sorgulanabilir ürün kayıtları veritabanı — başlangıçta ürün türü başına bir kayıt ve birim düzeyinde serializasyonu destekleyecek mimari. Birinci günden tam özellikli DPP platformu olmak zorunda değil. Gereksinimler onaylandıkça üzerinde uyumlu DPP sistemi kurulabilecek temiz, yapılandırılmış veri temeli olmak zorunda.