Audyt nie powinien przypominać akcji ratunkowej. A jednak wiele zespołów elektroniki 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 zmiana została wprowadzona kilka miesięcy temu.
Takie podejście wywołuje presję po stronie wszystkich. Zespoły inżynieryjne tracą czas. Zespoły jakości mają trudności ze zbudowaniem przejrzystej ścieżki dowodowej. Zespoły ds. zgodności próbują po fakcie powiązać decyzje, zatwierdzenia, zapisy wydań i dane produktowe.
Automatyczne ścieżki audytowe projektów elektronicznych rozwiązują ten problem, rejestrując dowody w trakcie wykonywania pracy. Rejestr audytowy staje się częścią procesu projektowego. Zespoły nie muszą przerywać prac inżynieryjnych, aby później odtworzyć całą historię. Zamiast tego historia powstaje w miarę, jak projekt przechodzi 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 na ostatnią chwilę są ryzykowne, ponieważ pamięć zawodzi, a kontekst projektu się zaciera. Inżynier, który zatwierdził zmianę footprintu, może już pracować przy innym programie. Problem z dostawcą, który spowodował zmianę komponentu, może być ukryty w wątku na czacie. Pakiet wydania może istnieć, ale uzasadnienie wydania może być trudniejsze do udowodnienia.
W tym miejscu wiele zespołów dostrzega różnicę między posiadaniem plików a posiadaniem dowodów. Plik pokazuje, co zostało wydane. Dobra ścieżka audytowa 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 zorientowane na jakość dobrze znają ten schemat. Udokumentowane informacje, kontrola zmian projektowych, dowody przeglądów i zapisy autoryzacji mają znaczenie w procesie wytwarzania wyrobu kontrolowanego. Zewnętrzne wytyczne dotyczące zmian w projektowaniu i rozwoju zgodnie z ISO 9001 również wskazują na potrzebę prowadzenia zapisów zmian projektowych, przeglądów i autoryzacji.
Wniosek jest prosty. Gotowość do audytu nie jest wydarzeniem. Jest zdolnością. Powinna być zaprojektowana w sposób pracy zespołów każdego dnia.
Użyteczna ścieżka audytowa pokazuje, kto co zrobił, kiedy to nastąpiło, co się zmieniło i których danych produktowych to dotyczyło.
Element ścieżki audytowej | 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 dokonał przeglądu, jakie kwestie zgłoszono i jak zostały zamknięte. | Zespoły zgodności i jakości mogą zobaczyć dowody przeglądu i zamknięcia spraw. |
Zapisy 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 zgodności mogą sprawdzić nadzór nad danymi i kontrolę użytkowników. |
Zapisy przepływu pracy | Jak projekt przechodził przez etapy przeglądu, zatwierdzenia i wydania. | Kadra zarządzająca może sprawdzić, czy proces był realizowany konsekwentnie. |
Kontekst zmiany | Komentarze, zadania, powiązane zgłoszenia lub powody zmiany. | Zespoły mogą wyjaśnić nie tylko to, co się zmieniło, ale także dlaczego się zmieniło. |
Rejestr powinien być kompletny, ale jego tworzenie nie powinno być uciążliwe. Jeśli inżynierowie muszą ręcznie wypełniać dodatkowe dzienniki, ścieżka audytowa będzie spóźniona, uboga albo niespójna. Ręczne gromadzenie dowodów powoduje także różnice między zespołami. Jeden inżynier może dobrze udokumentować zmianę. Inny może polegać na pamięci, e-mailach lub nieformalnych notatkach.
Lepszym podejściem jest umożliwienie platformie rejestrowania zapisów jako części zwykłej aktywności inżynieryjnej. System staje się miejscem, w którym wykonywana jest praca i w którym powstają dowody.
Automatyczne dzienniki zdarzeń zmniejszają stres, ponieważ zespoły nie muszą tworzyć dowodów po fakcie. Nowoczesne platformy, takie jak Altium Agile Teams, na przykład obsługują 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 dotyczyło. Takie dzienniki mogą wspierać zgodność regulacyjną, ułatwiając eksport i przegląd ścieżek audytowych.
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ć zapisy w tle, podczas gdy ludzie wykonują swoją pracę.
Ma to znaczenie, ponieważ presja audytowa często pojawia się wtedy, gdy dowody są rozproszone. Jedna część historii może znajdować się w pliku projektowym. Inna może być w e-mailu. Jeszcze inna może znajdować się w notatce ze spotkania, wątku zatwierdzeń lub folderze wydań. Im więcej miejsc, w których znajdują się dowody, tym większy wysiłek potrzebny do wykazania kontroli.
Automatyczne dzienniki zdarzeń pomagają ograniczyć ten wysiłek. Dają zespołom uporządkowany zapis aktywności, który można przeglądać, próbkować, eksportować i wykorzystywać do wsparcia odpowiedzi na audyt.
Historia wersji nie jest jedynie sposobem na przywracanie starych plików. To sposób na wyjaśnienie ewolucji projektu. W Altium Agile Teams historia projektu może pokazywać najważniejsze zdarzenia dotyczące 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ł tę drogę?”.
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 wydania. Pomaga także 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 dostawców, dostępnością komponentów, informacją zwrotną dotyczącą 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 przez decyzję do zatwierdzonego wydania.
Identyfikowalność zamienia pracę audytową z poszukiwań 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 potrzebę przekazywania informacji zwrotnej od tych zespołów do inżynierów projektowych. W elektronice ten sam przepływ wspiera gotowość do audytu. Zapis projektu, zapis przeglądu, zapis wydania i zapis cyklu życia powinny być ze sobą powiązane.
Gdy identyfikowalność jest słaba, zespoły ds. zgodności proszą inżynierię o pomoc. Inżynieria przerywa pracę, by szukać informacji. Jakość czeka. Czas audytu biegnie dalej. Praca staje się reaktywna, a zespół poświęca więcej czasu na znajdowanie dowodów niż na wyjaśnianie 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ą połączone z samą pracą.
To poprawia także 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ć powiązania między wymaganiami, działaniami, zatwierdzeniami i wydanymi rezultatami. Kadra zarządzająca może mieć większą pewność, że proces jest kontrolowany i powtarzalny.
Najlepsza ścieżka audytowa jest niemal niewidoczna dla osób wykonujących pracę. Nie oznacza to, że proces jest swobodny. Oznacza to, że zapis jest rejestrowany przez system, a nie przez dodatkową administrację. Inżynierowie nadal przechodzą przez przeglądy, zatwierdzenia i przepływy wydań. Różnica polega na tym, że dowody są generowane jako część przepływu pracy
Ręczne przygotowanie do audytu | Automatyczna ścieżka audytowa |
Przeszukiwanie e-maili w poszukiwaniu zatwierdzeń. | Przegląd zatwierdzeń w zapisie projektu. |
Pytanie inżynierów, dlaczego wprowadzono zmianę. | Śledzenie zmiany do komentarzy, zadań, przeglądów i historii wydań. |
Sprawdzanie folderów w poszukiwaniu najnowszego pliku. | Korzystanie z zarządzanej historii projektu i wydań. |
Tworzenie dziennikó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 szczególnego ćwiczenia. | Traktowanie gotowości do audytu jako części zwykłej kontroli projektu. |
To ważna zmiana sposobu myślenia. Gotowość do audytu nie musi spowalniać zespołów. Jeśli jest 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.
Rezultatem jest mniej stresu podczas audytów. Zespoły inżynierskie 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. Kadra zarządzająca zyskuje lepszy wgląd w to, czy proces projektowy jest kontrolowany, bez sprawiania, że każde zadanie staje się nadmiernie uciążliwe.
To właśnie jest prawdziwa wartość automatycznych ścieżek audytu. Nie pomagają one tylko podczas audytu. Poprawiają rytm pracy przy projektowaniu elektroniki, ułatwiając gromadzenie dowodów, ich odnajdywanie i wyjaśnianie.
Skorzystaj z tej listy przed kolejnym wydaniem projektu, a nie tydzień przed następnym audytem.
Lista kontrolna powinna być na tyle prosta, aby można było używać jej regularnie. Celem nie jest tworzenie dodatkowej administracji. Celem jest upewnienie się, że dowody są już na miejscu, gdy ktoś o nie poprosi.
Ścieżka audytu w projektowaniu elektroniki to zapis działań projektowych, zmian, przeglądów, zatwierdzeń, wydań i zdarzeń dostępu. Pomaga zespołom wykazać, jak projekt zmieniał się w czasie i w jaki sposób osiągnięto zatwierdzony stan projektu.
Automatyczne ścieżki audytu ograniczają ręczne rejestrowanie i braki w materiale dowodowym. Rejestrują zapis podczas pracy inżynierów, dzięki czemu jest on pełniejszy, bardziej spójny i łatwiejszy do uznania za wiarygodny.
Nie. Zespoły działające w regulowanym środowisku potrzebują ścieżek audytu dla zgodności, ale każdy zespół może wykorzystywać je do usprawnienia kontroli zmian, analizy przyczyn źródłowych, reagowania na problemy dostawców, zwiększenia pewności przy wydaniach produktów oraz nadzoru inżynierskiego.
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, połączonym zapisie.
Zespoły mogą tego uniknąć, traktując materiał dowodowy audytu jako część codziennej pracy projektowej. Korzystaj z uporządkowanych przeglądów, kontrolowanych wydań, zarządzanego dostępu i automatycznych dzienników zdarzeń, tak aby dowody powstawały wraz z postępem prac.