Większość zespołów elektronicznych nie traci czasu dlatego, że ich indywidualne narzędzia są niewystarczające. Tracą czas na granicach między narzędziami. Przekazanie pracy między tworzeniem schematu a layoutem, tłumaczenie między ECAD i MCAD, uzgadnianie danych BOM z systemami zakupowymi oraz ręczna synchronizacja plików projektowych w kolejnych cyklach przeglądu — wszystko to wprowadza tarcia, które narastają w każdym projekcie.
Tarcia te łatwo zlekceważyć, ponieważ rzadko objawiają się jako jedna duża awaria. Zwykle przyjmują formę powtarzających się drobnych opóźnień: footprint złącza, który nie pasuje do obudowy mechanicznej, zamiennik komponentu zatwierdzony przez zakupy, ale nigdy niezaktualizowany w bibliotece schematów, albo przegląd projektu przeprowadzony na podstawie nieaktualnego pliku wyjściowego. Każdy z tych problemów z osobna da się naprawić, ale łącznie wydłużają harmonogramy, zwiększają liczbę poprawek i podważają zaufanie do danych projektowych.
Najczęstsze luki integracyjne w rozwoju sprzętu pojawiają się między obszarami, które są ściśle powiązane w fizycznym produkcie, ale słabo powiązane w łańcuchu narzędzi. Najbardziej oczywistym przykładem jest projektowanie elektryczne i mechaniczne. Obrys płytki, rozmieszczenie złączy lub strefa keep-out zdefiniowane w jednym narzędziu i ręcznie przeniesione do drugiego stwarzają ryzyko niezgodności przy każdej zmianie po którejkolwiek ze stron. Gdy taka niezgodność zostanie wykryta dopiero przy montażu prototypu, koszt mierzy się w tygodniach i wydatkach na produkcję.
Dane komponentów tworzą podobny problem. Gdy symbole schematowe, footprinty, modele 3D i dane dostawców są zarządzane w oddzielnych systemach, projektant musi ręcznie weryfikować ich spójność. Taka weryfikacja jest żmudna, podatna na błędy i powtarzana przy każdym nowym projekcie. Ryzyko inżynierskie polega tutaj nie na tym, że dane nie istnieją, ale na tym, że nie są powiązane z miejscem podejmowania decyzji. Projektant wybierający regulator napięcia powinien widzieć w kontekście jego dostępność, geometrię obudowy i charakterystykę termiczną, a nie w osobnym arkuszu kalkulacyjnym, który może, ale nie musi odzwierciedlać bieżącej sytuacji.
W niespójnych przepływach pracy informacja zwrotna często zależy od eksportów plików, zrzutów ekranu, plików PDF i łańcuchów e-maili. To wszystko spowalnia pracę, zwłaszcza gdy zespoły są rozproszone po różnych strefach czasowych lub współpracują z zewnętrznymi producentami.
Bardziej zintegrowany przepływ pracy ułatwia współpracownikom przeglądanie najnowszej wersji projektu, komentowanie w odpowiednim kontekście i wcześniejsze zadawanie pytań. Zamiast przesyłać pliki tam i z powrotem, zespoły mogą reagować bliżej samego projektu.
To skraca pętlę informacji zwrotnej i zmniejsza ryzyko działania na podstawie nieaktualnych informacji.
Jakość BOM wpływa na harmonogram w takim samym stopniu jak jakość layoutu.
Gdy danymi części zarządza się ręcznie, łatwiej przeoczyć dostępność, status cyklu życia, ceny i zamienniki albo trudniej utrzymać te informacje w aktualności. Zwiększa to ryzyko wykrycia problemów sourcingowych zbyt późno, gdy projekt jest już bliski wydania.
Zintegrowane środowisko z bieżącą widocznością łańcucha dostaw pomaga wcześniej ujawniać takie problemy. Inżynierowie mogą sprawdzać status części podczas projektowania, zamiast traktować sourcing jako osobne zadanie wykonywane na końcu. Jest to szczególnie przydatne dla mniejszych zespołów, w których ta sama osoba może odpowiadać za projekt, przegląd i przygotowanie wydania.
Wiele ECO nie wynika z błędów projektowych. Są skutkiem informacji, które były dostępne gdzieś w organizacji, ale nie były widoczne dla projektanta w momencie podejmowania decyzji. Problem z prześwitem mechanicznym, konflikt orientacji złącza, ograniczenie związane z pakowaniem lub ograniczenie sourcingowe, które powinno zostać wykryte wcześniej — każde z nich może wywołać formalną zmianę po zakończeniu layoutu.
Gdy dane elektryczne, mechaniczne i dotyczące komponentów są rozproszone między narzędziami, takie problemy z większym prawdopodobieństwem ujawnią się dopiero po zatwierdzeniu decyzji. Integracja ogranicza to ryzyko, udostępniając istotne ograniczenia wcześniej, gdy projekt nadal łatwo zmienić. Różnica kosztów między skorygowaniem ograniczenia na etapie tworzenia schematu a wydaniem ECO po zwolnieniu do produkcji zwykle wynosi rząd wielkości lub więcej, zarówno pod względem czasu, jak i kosztów.
Rozproszony przepływ pracy generuje zaskakująco dużo pracy administracyjnej.
Czas pochłania eksport modeli, aktualizacja arkuszy kalkulacyjnych, potwierdzanie wersji, porządkowanie bibliotek, sprawdzanie aktualności danych części oraz powielanie informacji między narzędziami, które nie pozostają zsynchronizowane. Nic z tego nie stanowi istoty problemu inżynierskiego, ale mimo to pochłania czas inżynierów.
Lepsze środowisko projektowe nie eliminuje złożoności, ale może ograniczyć ilość ręcznej koordynacji potrzebnej do utrzymania postępu projektu.
To ważne, ponieważ każda godzina poświęcona na uzgadnianie narzędzi to godzina niepoświęcona projektowaniu.
Luka między narzędziami projektowymi a systemami danych produktowych tworzy własną kategorię tarć. Pliki projektowe trudno przeglądać bez pobrania ich do narzędzia źródłowego. Dane bibliotek i części tracą synchronizację. Procesy wydania zależą od ręcznej koordynacji między systemami, które nigdy nie zostały zbudowane z myślą o współpracy. Rezultatem jest więcej narzutu niż widoczności, szczególnie podczas przeglądu, wydania i przekazania do produkcji.
Zintegrowane środowisko projektowe poprawia tę sytuację, utrzymując powiązanie danych projektowych i dokumentacji wspierającej w całym cyklu życia produktu. Nie rozwiązuje to każdego wyzwania PLM, ale ogranicza tarcia między projektowaniem płytki a zarządzaniem informacjami wokół niej. Dla zespołów publikujących wiele rewizji lub zarządzających rodzinami produktów taka łączność z czasem zwielokrotnia swoją wartość.
To rzeczywiście istotna kwestia. Właściwe porównanie nie dotyczy jednak komfortu i dyskomfortu. Chodzi o to, czy obecny przepływ pracy generuje na tyle duże obciążenie, że koszt pozostania przy nim jest wyższy niż koszt jego ulepszenia.
Prawdziwe pytanie nie dotyczy chmury samej w sobie. Chodzi o to, czy Twój zespół ma terminowy dostęp do potrzebnych informacji bez czekania na eksporty, załączniki e-mail czy ręczne aktualizacje.
To zależy od tego, skąd biorą się obecne opóźnienia. Jeśli zespół poświęca dużo czasu na przekazania pracy, zarządzanie plikami, porządkowanie BOM lub poszukiwanie kontekstu projektowego, lepsza integracja może przynieść mierzalną różnicę.
Wartość zintegrowanego środowiska projektowego nie polega na tym, że wygląda nowocześniej. Polega na tym, że ogranicza możliwe do uniknięcia tarcia w procesie, który i tak jest już wystarczająco trudny.
Rozwój PCB zależy od powiązanych ze sobą decyzji. Informacje elektryczne, mechaniczne, sourcingowe i związane z wydaniem wpływają na to, czy płytka przejdzie dalej bezproblemowo, czy zamieni się w serię poprawek. Gdy te dane wejściowe są rozproszone między niespójnymi narzędziami i komunikatami, problemy wychodzą na jaw później, niż powinny.
Integracja pomaga, ponieważ ułatwia dostrzeżenie właściwych informacji, ich udostępnianie i działanie na ich podstawie, gdy projekt wciąż pozostaje elastyczny.
Altium Agile Teams zapewnia taki poziom integracji rozwijającym się i rozproszonym zespołom sprzętowym, oferując wspólne środowisko, w którym dane projektowe, BOM-y, przeglądy i rewizje pozostają ze sobą powiązane. Zamiast polegać na eksportach plików, arkuszach kalkulacyjnych i komunikacji bocznymi kanałami, zespoły pracują w oparciu o wspólne źródło prawdy, które utrzymuje spójność decyzji elektrycznych, mechanicznych i sourcingowych wraz z rozwojem projektów.
Dzięki temu, że najnowszy kontekst projektu jest widoczny dla wszystkich zaangażowanych — projektantów, recenzentów, działu zakupów i produkcji — Agile Teams pomaga wcześniej ujawniać problemy, ograniczać możliwe do uniknięcia ECO i skracać pętle informacji zwrotnej. Przeglądy projektu odbywają się we właściwym kontekście, zmiany w BOM są łatwiejsze do śledzenia, a przygotowanie wydania staje się bardziej przewidywalne, ponieważ wszyscy pracują na tych samych zweryfikowanych danych.
Zamiast dodawać ciężki proces lub narzut klasy enterprise, Altium Agile Teams koncentruje się na ograniczaniu tarć narastających między narzędziami, rolami i etapami projektu, aby zespoły mogły spędzać mniej czasu na uzgadnianiu informacji, a więcej na pewnym rozwijaniu projektów. Rozpocznij pracę z Altium Agile Teams już dziś →
Przepływy pracy oparte na eksporcie mogą działać, ale wprowadzają luki, w których pliki stają się nieaktualne, przekazania trwają dłużej, a kontekst łatwiej zgubić. Zintegrowane środowisko ogranicza tę zależność od ręcznego przenoszenia danych.
Przyjrzyj się cyklom rewizji, czasowi poświęcanemu na zarządzanie plikami, porządkowanie BOM, pętlom doprecyzowań i zmianom na późnym etapie. Jeśli są to powracające problemy, przepływ pracy prawdopodobnie dokłada się do kosztów.
To zwykle sprawia, że integracja jest jeszcze cenniejsza, ponieważ wspólna widoczność i informacja zwrotna w kontekście ograniczają potrzebę synchronicznej komunikacji.
Niekoniecznie. Wiele zespołów zaczyna od usprawnienia obszaru generującego największe tarcia, na przykład przeglądu projektu, zarządzania BOM lub koordynacji ECAD-MCAD.