Audyt nie powinien przypominać akcji ratunkowej. A jednak wiele zespołów projektujących elektronikę nadal przygotowuje się do audytów, przeszukując stare wiadomości e-mail, otwierając zarchiwizowane foldery, sprawdzając lokalne kopie plików i prosząc inżynierów, by przypomnieli sobie, dlaczego kilka miesięcy temu wprowadzono zmianę.
Takie podejście wywiera presję na wszystkich. Zespoły inżynieryjne tracą czas. Zespoły jakości mają trudność ze zbudowaniem przejrzystej ścieżki dowodowej. Zespoły ds. zgodności próbują po fakcie połączyć decyzje, zatwierdzenia, rejestry wydań i dane produktowe.
Automatyczne ścieżki audytu projektów elektronicznych rozwiązują ten problem, rejestrując dowody w trakcie pracy. Rejestr audytowy staje się częścią procesu projektowego. Zespoły nie muszą przerywać prac inżynieryjnych, aby później odtwarzać całą historię. Zamiast tego historia powstaje wraz z przechodzeniem projektu przez przeglądy, commity, zatwierdzenia, wydania i zmiany cyklu życia.
Gotowość do audytu działa najlepiej wtedy, gdy dowody powstają podczas codziennej pracy. Nerwowe przygotowania do audytu na ostatnią chwilę są ryzykowne, ponieważ pamięć zawodzi, a kontekst projektu się zmienia. Inżynier, który zatwierdził zmianę footprintu, może już pracować przy innym programie. Problem z dostawcą, który wymusił zmianę komponentu, może być ukryty w wątku czatu. Pakiet wydania może istnieć, ale uzasadnienie samego wydania może być trudniejsze do wykazania.
W tym miejscu wiele zespołów dostrzega różnicę między posiadaniem plików a posiadaniem dowodów. Plik pokazuje, co zostało wydane. Solidna ścieżka audytu pomaga wyjaśnić, jak projekt osiągnął ten stan, kto go przeglądał, co się zmieniło i dlaczego zatwierdzonemu stanowi można zaufać.
Zespoły prowadzone przez jakość dobrze znają ten schemat. Udokumentowane informacje, kontrola zmian projektowych, dowody przeglądów i rejestry autoryzacji mają znaczenie w kontrolowanym procesie rozwoju produktu. Zewnętrzne wytyczne dotyczące zmian w projektowaniu i rozwoju według ISO 9001 również wskazują na potrzebę prowadzenia zapisów dotyczących zmian projektowych, przeglądów i autoryzacji.
Wniosek jest prosty. Gotowość do audytu nie jest wydarzeniem. Jest zdolnością. Powinna być zaprojektowana w taki sposób, w jaki zespoły pracują każdego dnia.
Użyteczna ścieżka audytu pokazuje, kto co zrobił, kiedy to nastąpiło, co się zmieniło i których danych produktowych to dotyczyło.
Element ścieżki audytu | Co potwierdza | Dlaczego pomaga |
Dzienniki zdarzeń | Działanie użytkownika, czas i obiekt, którego dotyczyło. | Zespoły mogą potwierdzić aktywność bez proszenia ludzi o jej odtwarzanie. |
Historia wersji | Jak projekt zmieniał się między commitami i wydaniami. | Zespoły mogą porównywać stany i śledzić decyzje projektowe. |
Zapisy przeglądów projektu | Kto przeprowadzał przegląd, jakie kwestie zgłoszono i jak je zamknięto. | Zespoły ds. zgodności i jakości mogą zobaczyć dowody przeglądu i zamknięcia działań. |
Rejestry wydań | Które pliki, dane wyjściowe i dane BOM zostały wydane. | Produkcja może pracować na podstawie zatwierdzonego stanu produktu. |
Historia kontroli dostępu | Kto miał uprawnienia do przeglądania lub zmiany danych. | Zespoły IT i ds. zgodności mogą sprawdzić nadzór nad danymi i kontrolę użytkowników. |
Zapisy workflow | Jak projekt przechodził przez etapy przeglądu, zatwierdzania i wydania. | Kadra zarządzająca może sprawdzić, czy proces był konsekwentnie przestrzegany. |
Kontekst zmiany | Komentarze, zadania, powiązane zgłoszenia lub powody zmiany. | Zespoły mogą wyjaśnić nie tylko, co się zmieniło, ale też dlaczego się zmieniło. |
Rejestr powinien być kompletny, ale jego tworzenie nie powinno być uciążliwe. Jeśli inżynierowie muszą ręcznie uzupełniać dodatkowe logi, ścieżka audytu będzie spóźniona, uboga lub niespójna. Ręczne gromadzenie dowodów powoduje też różnice między zespołami. Jeden inżynier może dobrze udokumentować zmianę. Inny może polegać na pamięci, e-mailu lub nieformalnych notatkach.
Mocniejszym podejściem jest umożliwienie platformie przechwytywania zapisów w ramach zwykłej aktywności inżynieryjnej. System staje się miejscem, w którym odbywa się praca i w którym powstają dowody.
Automatyczne dzienniki zdarzeń zmniejszają stres, ponieważ zespoły nie muszą odtwarzać dowodów po fakcie. Nowoczesne platformy, takie jak Altium Agile Teams, na przykład wspierają monitorowanie zdarzeń w następujący sposób: dzienniki zdarzeń rejestrują działania użytkowników i zawierają szczegóły takie jak moment wystąpienia zdarzenia, kto je wywołał oraz jakiego obiektu lub użytkownika ono dotyczyło. Takie logi mogą wspierać zgodność regulacyjną, ułatwiając eksport i przegląd ścieżek audytu.
To właściwy model dla nowoczesnej pracy nad elektroniką. Inżynierowie nie powinni wybierać między robieniem postępów a prowadzeniem zapisów. Platforma powinna rejestrować te informacje w tle, podczas gdy ludzie wykonują swoją pracę.
Jest to ważne, ponieważ presja audytowa często pojawia się wtedy, gdy dowody są rozproszone. Jedna część historii może znajdować się w pliku projektu. Inna może być w e-mailu. Kolejna może znajdować się w notatce ze spotkania, wątku zatwierdzenia lub folderze wydania. Im więcej miejsc, w których znajdują się dowody, tym więcej wysiłku potrzeba, aby wykazać kontrolę.
Automatyczne dzienniki zdarzeń pomagają ograniczyć ten wysiłek. Zapewniają zespołom uporządkowany zapis aktywności, który można przeglądać, próbkować, eksportować i wykorzystywać do przygotowania odpowiedzi na audyt.
Historia wersji to nie tylko sposób na przywracanie starych plików. To sposób na wyjaśnienie ewolucji projektu. W Altium Agile Teams historia projektu może pokazywać główne zdarzenia dla projektu PCB, multi-board lub harness, w tym utworzenie, commity, wydania, kopie i wymiany MCAD. Tego rodzaju historia pomaga zespołom powiązać zdarzenia zmian z kontekstem projektu.
Dla audytora ma to znaczenie. Pytanie rzadko brzmi tylko: „Czy macie najnowszy plik?”. Lepsze pytanie brzmi: „Czy możecie pokazać, jak projekt osiągnął ten stan i kto kontrolował ten proces?”.
Historia wersji pomaga odpowiedzieć na to pytanie. Daje zespołom oś czasu aktywności inżynieryjnej. Pomaga pokazać, jak postępowały prace projektowe, kiedy wprowadzano główne zmiany i jak tworzono punkty wydań. Pomaga też zespołom porównywać wcześniejsze i bieżące stany projektu podczas badania problemów lub wyjaśniania decyzji.
Może to być szczególnie cenne, gdy zmiany są powiązane z aktualizacjami od dostawców, dostępnością komponentów, opiniami dotyczącymi wytwarzalności lub ustaleniami jakościowymi. W takich przypadkach sam plik projektu nie wystarcza. Zespoły potrzebują powiązanego zapisu, który wyjaśnia drogę od problemu do decyzji i do zatwierdzonego wydania.
Identyfikowalność zamienia pracę audytową z polowania w uporządkowaną ścieżkę. Program NIST digital thread program podkreśla potrzebę lepszej komunikacji projektów produktów do produkcji i jakości oraz zapewnienia, aby informacje zwrotne od tych zespołów docierały do inżynierów projektowych. W elektronice ten sam przepływ wspiera gotowość do audytu. Rejestr projektu, rejestr przeglądu, rejestr wydania i rejestr cyklu życia powinny być ze sobą połączone.
Gdy identyfikowalność jest słaba, zespoły ds. zgodności proszą inżynierię o pomoc. Inżynieria przerywa pracę, aby szukać informacji. Jakość czeka. Czas audytu nadal biegnie. Praca staje się reaktywna, a zespół spędza więcej czasu na znajdowaniu dowodów niż na wyjaśnianiu procesu.
Gdy identyfikowalność jest silna, zespół może przejść od komponentu, rewizji płytki, wydania, przeglądu lub działania użytkownika do powiązanej historii przy znacznie mniejszych trudnościach. Dowody są łatwiejsze do znalezienia, ponieważ są powiązane z samą pracą.
Poprawia to również współpracę. Inżynieria może pozostać skupiona na pracy technicznej. Jakość może przeglądać dowody bez spowalniania każdej decyzji projektowej. Zespoły ds. zgodności mogą wyraźniej widzieć zależność między wymaganiami, działaniami, zatwierdzeniami i wydanymi wynikami. Liderzy mogą mieć większą pewność, że proces jest kontrolowany i powtarzalny.
Najlepsza ścieżka audytu jest niemal niewidoczna dla osób wykonujących pracę. Nie oznacza to, że proces jest swobodny. Oznacza to, że zapis jest przechwytywany przez system, a nie tworzony przez dodatkową administrację. Inżynierowie nadal realizują przeglądy, zatwierdzenia i workflow wydań. Różnica polega na tym, że dowody są generowane jako część workflow
Ręczne przygotowanie do audytu | Automatyczna ścieżka audytu |
Przeszukiwanie e-maili w poszukiwaniu zatwierdzeń. | Przegląd zatwierdzeń w rejestrze projektu. |
Pytanie inżynierów, dlaczego wprowadzono zmianę. | Śledzenie zmiany poprzez komentarze, zadania, przeglądy i historię wydań. |
Sprawdzanie folderów w poszukiwaniu najnowszego pliku. | Korzystanie z zarządzanego projektu i historii wydań. |
Tworzenie logów audytowych w arkuszach kalkulacyjnych. | Eksport dzienników zdarzeń z platformy. |
Poleganie na wiedzy nieformalnej. | Poleganie na uporządkowanych dowodach projektowych. |
Odtwarzanie osi czasu po zdarzeniu. | Przegląd osi czasu zarejestrowanej podczas pracy. |
Traktowanie gotowości do audytu jako specjalnego ćwiczenia. | Traktowanie gotowości do audytu jako części normalnej kontroli projektu. |
To ważna zmiana sposobu myślenia. Gotowość do audytu nie musi spowalniać zespołów. Jeśli zostanie dobrze wdrożona, zmniejsza tarcia, ponieważ ludzie wiedzą, gdzie znajdują się dowody, jak rejestrowane są przeglądy i jak kontrolowane są wydania.
Zmniejsza też osobiste obciążenie inżynierów. Zamiast polegać na pamięci, zespoły mogą polegać na zapisach. To lepsze dla inżyniera, lepsze dla systemu jakości i lepsze dla organizacji.
Altium Agile Teams wspiera gotowość do audytu, dodając strukturę wokół ludzi, procesów i danych.
Efekt to mniej stresu podczas audytów. Zespoły inżynieryjne mogą dalej pracować. Zespoły ds. zgodności mogą szybciej znajdować dowody. Zespoły jakości mogą z większą pewnością przeglądać decyzje. Liderzy zyskują lepszą widoczność tego, czy proces projektowy jest kontrolowany, bez sprawiania, by każde zadanie wydawało się uciążliwe.
To jest rzeczywista wartość automatycznych śladów audytowych. Nie pomagają one tylko podczas audytu. Poprawiają rytm pracy przy projektowaniu elektroniki, ponieważ ułatwiają gromadzenie dowodów, ich odnajdywanie i wyjaśnianie.
Skorzystaj z tej listy kontrolnej przed kolejnym wydaniem projektu, a nie dopiero tydzień przed następnym audytem.
Lista kontrolna powinna być na tyle prosta, by można było z niej regularnie korzystać. Celem nie jest tworzenie dodatkowej administracji. Celem jest upewnienie się, że dowody są już na miejscu, gdy ktoś o nie poprosi.
Ślad audytowy w projektowaniu elektroniki to zapis działań projektowych, zmian, przeglądów, zatwierdzeń, wydań i zdarzeń dostępowych. Pomaga zespołom wykazać, jak projekt zmieniał się w czasie i w jaki sposób osiągnięto zatwierdzony stan projektu.
Automatyczne ślady audytowe ograniczają potrzebę ręcznego rejestrowania i zmniejszają ryzyko brakujących dowodów. Rejestrują przebieg prac w trakcie pracy inżynierów, dzięki czemu zapis jest pełniejszy, bardziej spójny i bardziej wiarygodny.
Nie. Zespoły działające w branżach regulowanych potrzebują śladów audytowych ze względu na zgodność, ale każdy zespół może ich używać do usprawnienia kontroli zmian, analizy przyczyn źródłowych, reagowania na problemy dostawców, zwiększenia pewności przy wydaniach produktu oraz nadzoru inżynieryjnego.
Zacznij od przeniesienia prac projektowych do zarządzanej przestrzeni roboczej, w której przeglądy, wydania, historia wersji i działania użytkowników mogą być rejestrowane w jednym spójnym zapisie.
Zespoły mogą jej uniknąć, traktując dowody audytowe jako część codziennej pracy projektowej. Korzystaj z uporządkowanych przeglądów, kontrolowanych wydań, zarządzanego dostępu i automatycznych dzienników zdarzeń, aby dowody powstawały wraz z postępem prac.