Product Data Backbone

Product Data Backbone stanowi podstawę konsolidacji danych i dokumentów ze wszystkich działów i systemów. Dlatego nadrzędnym podejściem PLM jest zintegrowanie wszystkich systemów informatycznych (ERP, CAD i PDM/PLM) istotnych dla cyklu życia produktu i stworzenie jednej centralnej bazy informacji. Dzięki niej firmy mają podstawy, które umożliwiają im następnie płynne i cyfrowe wykorzystanie informacji w procesach. System PLM agreguje i łączy w formę cyfrową wszystkie dane produktu i dokumenty. Wszystkie obszary rozpatrywane są jako całość w całym cyklu życia produktu. Gdy zachodzą zmiany i każdy zdaje sobie sprawę z istniejących bezpośrednich lub funkcjonalnych relacji to zależności można kontrolować, co zmienia Product Data Backbone w centralne repozytorium wszystkich informacji cyfrowych związanych z produktem. Product Data Backbone umożliwia firmom technicznym pełne wykorzystanie możliwości digitalizacji i ustanowienie spójnych procesów cyfrowych w inżynierii produktu i zarządzaniu produktem.

5.1 Platforma cyfrowaŹródło informacji dla całego cyklu życia produktu

Podobnie jak szkielet ludzki stanowi podparcie dla narządów, tak Product Data Backbone stanowi podparcie dla różnych działów i lokalizacji firmy dostarczając, w sposób ciągły, za pośrednictwem platformy cyfrowej informacji generowanych w całym cyklu życia produktu. Ważną sprawą jest cyfrowe ustanowienie relacji, które łączą informacje istotne dla inżynierii produktu i zarządzania produktem oraz modelowanie ich zależności, ponieważ jest to jedyny sposób na cyfrowe zainicjowanie przepływu pracy. Na przykład projektanci mogą zostać poinformowani o nieudanym teście zespołu, który stworzyli, lub redaktorzy techniczni mogą zostać poinformowani o konieczności zmiany dokumentacji w celu odzwierciedlenia podmiany części.

Osoby zaangażowane w przepływ pracy nie muszą gromadzić swoich dokumentów z różnych źródeł, ponieważ mają je automatycznie dostarczane z kompletnymi i prawidłowymi informacjami za pośrednictwem informacji o relacjach dostarczonych przez Product Data Backbone.



Dzięki rozwiązaniu PDM/PLM do zarządzania cyklem życia produktu można zbudować centralne repozytorium Product Data Backbone. W tym system CAD (np. AutoCAD, Autodesk Inventor, Creo, Solid Edge lub Solidworks) i system zarządzania danymi produktu (system PDM) w połączeniu z technicznym systemem zarządzania dokumentami (DMStec) utworzą jednolitą platformę cyfrową zaprojektowaną w celu zapewnienia współpracy między przedsiębiorstwami i wykorzystaną jako system PDM/PLM w całym przedsiębiorstwie.

5.2 Inżynieria produktu i zarządzanie produktemKrok w kierunku „inżynierii produktów cyfrowych”

Cykl życia produktu rozpoczyna się wraz z jego powstaniem – niezależnie od tego, czy chodzi o pompy, silniki, komponenty maszyny specjalnego przeznaczenia, czy o kompletny system techniczny na dużą skalę. Adaptacja i ulepszanie istniejących czy sprawdzonych komponentów podstawowych w celu spełnienia specyficznych wymagań klientów to chleb powszedni wielu firm technicznych. Kluczowe jest wykorzystywanie szablonów, które zostały już kiedyś utworzone przy innej okazji. Usprawnienie procesów inżynierii produktu wymaga między innymi usprawnionej koordynacji pomiędzy różnymi zaangażowanymi dziedzinami, tj. mechaniki, elektrotechniki, elektroniki i rozwoju oprogramowania. To z kolei oznacza, że ​​firmy techniczne potrzebują pełnego wglądu w zależności i powiązania dostępnych informacji, które są reprezentowane przez bogactwo danych o otaczających ich produktach i sąsiadujących obszarach administracyjnych. To pierwszy krok w kierunku „inżynierii produktów cyfrowych”


Produktentstehung_Produktmanagement-1-450x253

Wiele dokumentów tworzonych obok przepływów pracy firm technicznych jest zazwyczaj zarządzanych oddzielnie. Dane CAD generowane podczas opracowywania produktu są przechowywane w systemach PDM. Rozwiązania ERP/SCM wspierające procesy produkcyjne i logistyczne firmy mają własne zarządzanie dokumentami, podobnie jak aplikacje CRM ułatwiające komunikację z klientem. Ponadto konwencjonalne rozwiązania DMS, które są często używane do kontrolowania części przepływu dokumentów. Brak jednego, zintegrowanego systemu to pewna recepta na konflikty i zakłócenia. Najrozsądniejszym sposobem rozwiązania tego problemu jest stworzenie wspólnego kontekstu dla wszystkich informacji/dokumentów związanych z produktem. Najlepszym podejściem jest ustanowienie jednego repozytorium Product Data Backbone.

Ciągłe świadczenie usług staje się coraz częściej częścią samego produktu. Im bardziej dostosowany do potrzeb klienta jest produkt, tym ważniejszy jest dla producenta natychmiastowy dostęp do informacji i dokumentów, które go dotyczą. Aby to opisać, wymyślono pojęcia zarządzania produktami cyfrowymi i bliźniaczymi informacjami cyfrowymi. Rozwiązania PDM/PLM i DMStec konsolidują te informacje, strukturyzują je i reprezentują w oparciu o struktury techniczne, takie jak struktura urządzenia oraz zespoły i części zainstalowane w nim. Jeśli w jednym lub wielu urządzeniach zainstalowano wiele instancji tego samego silnika to specyfikacje usługi powiązane z tym silnikiem będą również powiązane z silnikami zainstalowanymi w całym zakładzie.

5.3 Relacje Informacji CyfrowejKluczowa jest komunikacja między mechaniką, elektroniką i tworzeniem oprogramowania

Pracownicy pracujący po stronie biznesowej przemysłu wytwórczego są zwykle o krok do przodu – przynajmniej jeśli chodzi o doświadczenie dostarczane przez rozwiązania programowe, którymi dysponują. System ERP, z którego korzystają, zapewnia pojedynczy panel pozwalający im poruszać się po informacjach na temat wszystkich komponentów, czy to mechanicznych, elektronicznych, czy programowych. W dowolnym momencie mogą umieszczać elementy we właściwym kontekście..

Jest to jednak dokładnie takie odniesienie, którego brakuje projektantom i programistom, przynajmniej w przypadkach, w których nie ma systemu PDM/PLM. Powód: informacje są zamulone i rozproszone w wielu systemach. Projektanci i twórcy oprogramowania M-CAD i E-CAD sami w większości zarządzają swoimi informacjami. Jednak bariery komunikacyjne między działami mechanicznym, elektronicznym i tworzącym oprogramowanie uniemożliwiają tworzenie produktów cyfrowych. Rozwiązaniem są relacje pomiędzy informacjami cyfrowymi.

Jeśli na przykład projektant elektroniki postanowi zrobić płytkę drukowaną o pięć centymetrów szerszą to projektant mechaniczny powinien zostać automatycznie powiadomiony o konieczności odpowiedniego dostosowania obudowy. Działy projektowe projektują złożone produkty, ale prawie nigdy nie mają wiedzy, co klient faktycznie myśli o produkcie i czy produkt działa zgodnie z przeznaczeniem. Nie ma prawie żadnych opinii zwrotnych, a kiedy są, nigdy nie trafiają do działów projektowania lub zarządzania produktem. Incydenty są zazwyczaj rozwiązywane przez zespoły serwisowe w zależności od przypadku i według potrzeb.


5-3-Digital-Information-Relationships-450x270

Brak kontekstu zapobiega powrotnemu przepływowi informacji

Nie ma jednak takiego dialogu, jeśli wszyscy ograniczają się do pracy i dokonywania zmian w „ich” odpowiednim systemie. Nikt nie zgłasza uwag i nie istnieje plan określający, w jaki sposób można dopasować właściwą reklamację do odpowiedniej części czy odpowiednio przypisać (w celu zapewnienia dokładnej analizy reklamacji). Posiadanie tego rodzaju informacji zwrotnych jest jednak dokładnie tym, co jest potrzebne, aby zapewnić, że potencjalne wady projektu można wyeliminować tak szybko, jak to możliwe. Na przykład, gdy jest zbyt mało miejsca między zainstalowanymi komponentami, które regularnie powodują przegrzanie kondensatora. Albo część, która ciągle się psuje i powinna zostać przeprojektowana od podstaw.

Powielanie zmian jest kolejną niepożądaną konsekwencją niepowodzenia komunikacji. Często wynika ze źle zdefiniowanej odpowiedzialności, zazwyczaj w przypadku części, których funkcja nie ogranicza się do jednej dyscypliny. Powoduje to problemy w planowaniu produkcji, podczas którego ostatecznie decyduje się, która część ma zostać użyta. Kolejne zapytania i koordynacja opóźniają proces produkcji. A jeśli błąd pozostanie niezauważony to w najgorszym przypadku część jest wytwarzana dwukrotnie lub według złych specyfikacji.

Oprócz wersjonowania części składających się na maszynę coraz ważniejsze staje się podłączanie ich do różnych wersji oprogramowania maszyny. Obecnie jeszcze rzadko – co wynika z faktu, że do niedawna oprogramowanie stanowiło stosunkowo niewielką część prac projektowych. W następstwie cyfryzacji w firmach technicznych udział ten jednak szybko rośnie; propozycja wartości produktu w coraz większym stopniu przesuwa się w kierunku oprogramowania, które go zasila. Dostarczana dzisiaj maszyna działa na zupełnie innym oprogramowaniu niż model, który został zbudowany dziesięć lat temu i trudno będzie znaleźć jakiekolwiek podobieństwa. W związku z tym ważne jest, aby producent wiedział, która maszyna została dostarczona, kiedy i z jakim oprogramowaniem – w przeciwnym razie utrzymanie jej będzie trudne. Co więcej, nie można zaktualizować przestarzałego oprogramowania do najnowszej wersji.

Przedsiębiorstwa produkcyjne powinny mieć świadomość, które składniki ich produktów są bardziej podatne na defekty niż inne. Powinni być w stanie ocenić, w jaki sposób można łatwo naprawić i wymienić komponenty oraz co ich zespoły ds. rozwoju i zarządzania produktem mogą zrobić, aby zapobiegać wadom. Firmy, które przekazują te informacje odpowiednim działom, są w stanie przygotować dokładne plany obsługi serwisowej, co samo w sobie daje im przewagę konkurencyjną. Celem powinno być przyjęcie strategicznego procesu zarządzania utrzymaniem, który pozwala zastąpić daną część z wyprzedzeniem dla każdej używanej maszyny – zanim będzie za późno. Umożliwia to producentom spełnianie umów dotyczących poziomu usług i minimalizuje roszczenia gwarancyjne.

5.4 Wątek cyfrowyWątek cyfrowy łączy bieżące operacje z rozwojem

Dzięki ustanowieniu relacji między projektowanymi częściami, a otrzymywanymi reklamacjami firmy mogą ograniczyć ilość reklamacji i podnieść jakość swoich produktów. Wątek Cyfrowy łączy informacje z bieżących operacji z rozwojem, umożliwiając firmom łatwe analizowanie elementów/części. Product Data Backbone jest obowiązkowy, aby składać reklamacje w odniesieniu do odpowiednich części. Jak widać wykracza to poza zwykłe ustalenie powiązanego klienta (co odbywa się w systemie CRM), ponieważ przynosi to korzyści tylko zespołom wsparcia. Projektanci również muszą być natychmiast informowani o wszelkich częściach, na które wpływają uwagi od klientów, aby mogli od razu włączać tę wiedzę do swoich dokumentów projektowych i produkcyjnych. Jeśli nie dociera do nich odpowiednia wiedza, będą korzystać wciąż z tej samej części z powodu braku lepszych informacji. Po stronie serwisowej oznacza to, że będzie się powtarzać potrzeba przeprowadzania tych samych napraw.

Oprogramowanie PDM/PLM powinno również odzwierciedlać relacje między częściami, które firma samodzielnie projektuje, a zakupionymi częściami utrzymywanymi w systemie ERP – na wypadek gdyby zakupione części były podatne na awarie i wymagały częstej wymiany. Oczywiście nie pojawiają się one w procesie projektowania; ale projektanci powinni być świadomi wszelkich problemów z jakością. Umożliwi im to samodzielne zaprojektowanie części zamiennej lub zasugerowanie nabycia innej części. W związku z tym system PDM/PLM wymaga dwukierunkowej komunikacji z systemem ERP, aby zapewnić przepływ informacji w obie strony i ich odpowiednie połączenie.



Firmy, które chcą mieć możliwość analizowania usług świadczonych dla każdego produktu, powinny również rozważyć ustanowienie kontrolowanego procesu zmiany i ulepszenia. W ten sposób – i poprzez stworzenie relacji między częściami projektowanymi, zakupowymi i reklamacjami – mogą zbudować wątek cyfrowy w całym przedsiębiorstwie. Wątek cyfrowy łączy informacje z bieżących operacji z rozwojem. Ścisłe przestrzeganie tej cyfrowej ścieżki szybko doprowadzi do znacznego zmniejszenia częstotliwości zgłoszeń serwisowych. Usługi ad hoc zastępowane są środkami zapobiegawczymi, które można zaplanować z wyprzedzeniem (konserwacja). Firmy mogą podnosić poziom usług, łatwiej nimi zarządzać i poprawiać jakość swoich produktów, zmniejszając liczbę wadliwych części.

Użycie Product Data Backbone daje mechanikom, elektronikom i programistom wspólny język. Firmy, które łączą dane i dokumenty związane z produktem, tworzą cyfrowe relacje między informacjami, umieszczając każdy pojedynczy komponent – mechaniczny, elektroniczny lub oparty na oprogramowaniu – w kontekście. Dzięki temu wyeliminowane jest zgadywanie, kiedy i która wersja części została zainstalowana, a następnie ponownie użyta i w jakim projekcie. Firmy, które dysponują tak przejrzystą informacją i mają jasno określone obowiązki między różnymi działami, minimalizują ryzyko powielania wysiłków w projektowaniu i produkcji swoich części.

Poprzez włączenie do Product Data Backbone danych handlowych z systemu ERP informacje na temat preferowanych części (w magazynie, tańsze, szybsze czasy realizacji) są już dostępne na etapie projektowania. Informacje są wymieniane dwukierunkowo między systemami PDM/PLM i ERP, tworząc połączenie zarówno pomiędzy poszczególnymi komponentami, jak i projektami, w których były używane.

Jednoznaczna informacja w całym procesie rozwoju jest kluczem do udanej współpracy we wszystkich działach. Podobnie, jednoznaczne oznaczenie zapewnia, że wszyscy wiedzą, co muszą zrobić. Widać, które części są już obecne w strukturze mechatronicznej, kto je stworzył i jakie będą skutki zmiany. Zespoły spędzają mniej czasu na koordynowaniu pracy, współpracują łatwiej i wygodniej oraz mogą szybciej projektować, produkować i dostarczać, eliminując jednocześnie wszelkie błędy w procesie.



Biorąc pod uwagę niesłabnące tempo digitalizacji w przedsiębiorstwach średniej wielkości, w szczególności w przedsiębiorstwach technicznych, potrzeba ustanowienia wątku cyfrowego staje się coraz bardziej paląca. Tym bardziej istotne jest wykorzystanie systemu PDM/PLM jako Product Data Backbone, który pokonuje bariery komunikacyjne między mechanikami, elektronikami oraz programistami i toruje drogę do tworzenia produktów cyfrowych.