Model danych śledzenia defektów

Przegląd

Właściwa architektura danych ma kluczowe znaczenie dla podejmowania właściwych działań w celu usprawnienia procesu. Dane nigdy nie są uniwersalne, ponieważ rozwiązywane problemy rzadko są identyczne. Niniejszy Functional Example przedstawia podstawowe dane zalecane do śledzenia defektów. Możesz dodać więcej Field, aby rozszerzyć ten przykład funkcjonalny.

W dokumencie Rozszerzenie koncepcji omówiono sposoby, w jakie ten model danych może zostać zbudowany, aby zapewnić jeszcze większą wartość.

Tabele

Ta aplikacja opiera się na tabelach do przechowywania danych. Jest to zalecane (zamiast używania Completions), ponieważ oznacza to, że ta sama tabela może być używana w wielu aplikacjach, co jest krytyczną cechą Composability, zwłaszcza jeśli śledzenie defektów istnieje w wielu aplikacjach.

Ta aplikacja opiera się na pojedynczej tabeli [Defect Events].

Rozszerzenie koncepcji obejmuje pewne możliwości rozszerzenia tego modelu danych, w tym szersze powiązania ze śledzeniem zamówień lub innymi przypadkami użycia.

Tabela [Defect Events]

Tabela zdarzeń defektów to podstawowe dane potrzebne do zapewnienia widoczności procesu. Niektóre pola rekordu tabeli są opcjonalne, a inne są naprawdę wymagane do utrzymania widoczności operacji.

Należy pamiętać, że pola te niekoniecznie muszą być wypełniane przez osobę. Informacje o zamówieniu mogą pochodzić z zewnętrznego źródła danych lub zostać wywnioskowane na podstawie logiki warunkowej.

Przykład. Opis usterki jest obliczany automatycznie poprzez połączenie zmiennej Material i zmiennej Reason z wyrażeniem Expression:

'Defected ' + @Variable.Material + ' due to ' + @Variable.Reason

Tabela Fields

ID (Tekst) - Wszystkie tabele potrzebują kolumny ID, aby jednoznacznie reprezentować każdy rekord tabeli. W tym przypadku używamy losowego ciągu znaków jako identyfikatora rekordu.

Opis (Tekst) - czytelny dla człowieka opis usterki. W Functional Example będzie to format "Defected Material due to Reason".

Reported Date (Datetime) - czas, w którym wada została pierwotnie zgłoszona.

ReportedBy (User) - Użytkownik, który zgłosił wadę. W przykładzie funkcjonalnym jest to wypełniane przez zalogowanego użytkownika, ale może być ustawione na statycznego użytkownika lub pozwolić użytkownikom wybrać osobę zgłaszającą.

Identyfikator materiału (tekst) - identyfikator materiału, w którym wykryto wadę. Zastąpienie tego pola rekordem powiązanym z tabelą [Materiały] byłoby świetnym sposobem na rozszerzenie koncepcji.

Ilość (Liczba)- Jak sama nazwa wskazuje, jest to ilość wadliwych części.

Powód (tekst) - Podobnie jak pole Status, pole Powód może być wykorzystane do automatycznego kierowania usterek do właściwego zespołu.

Na przykład. Wszystkie usterki związane z nadmiarem zapasów powinny być obsługiwane przez kierowników produkcji.

Assignee (User) - Użytkownik, który jest odpowiedzialny za usunięcie usterki. Może być ustawiany dynamicznie na podstawie przyczyny lub statycznie dla pojedynczego użytkownika/zespołu.

Status (Tekst) - aktualny stan tego defektu. Gdy defekt zostanie zgłoszony w Functional Example, będzie to domyślnie stan NOWY. W naszym przypadku użycia defekty przechodzą przez 3 statusy: 1. NOWY 2. W PRZEGLĄDZIE 3. ZAMKNIĘTY

Komentarze (tekst) - dowolne pole tekstowe, w którym można gromadzić wszelkie uwagi dotyczące defektu. Wykorzystaj to pole jako część analizy przyczyn źródłowych. W połączeniu z widżetem Digital Record History można wyświetlić dane historyczne dotyczące każdego defektu.

Zdjęcie (obraz) - Zbierz zdjęcie usterki. Obrazy można wykorzystać do lepszego zrozumienia przyczyny źródłowej.

Closed Date (Datetime) - gdy usterka zostanie rozwiązana, pole to może śledzić datę zamknięcia raportu usterki. Wykorzystaj to pole w Analytics, aby zrozumieć zaległości w istniejących otwartych raportach o usterkach.

Location Detected (Text) - sortowanie usterek według lokalizacji, w której zostały zidentyfikowane po raz pierwszy. Użyj tego pola, aby uzyskać wgląd w najczęstsze punkty awarii w procesie. Dodatkowo, pole to może być wykorzystane do przypisania defektu do właściwego Assignee.

Next Stes (Text) - śledzenie rozwiązania defektu, w połączeniu z Digital Record History. Widget użytkownicy mogą zobaczyć, w jaki sposób usterka została rozwiązana.