Śledzenie defektów - rozszerzenie koncepcji

Przegląd

Celem Functional Example nie jest idealne dopasowanie do jednego procesu lub obiektu, ale raczej działanie jako punkt wyjścia do tworzenia własnych aplikacji do śledzenia zamówień.

Niniejszy przewodnik ma na celu przedstawienie kilku pomysłów na to, jak ten przykład funkcjonalny można zmienić i dostosować do własnego procesu, a także sposobów, w jakie można go połączyć z innymi fantastycznymi przypadkami użycia Tulip.

Rozszerzanie aplikacji

Podziel aplikacje według funkcji pracy

Jak mówiliśmy w przewodniku po architekturze aplikacji, jednym z najprostszych sposobów na uzyskanie wartości z Tulip jest tworzenie aplikacji specyficznych dla użytkowników, którzy będą z nimi współpracować.

W większości procesów operatorzy będą zgłaszać defekty, ale oddzielny zespół będzie przeprowadzał analizę przyczyn źródłowych, podejmował działania naprawcze i kończył rozwiązywanie audytu. Rozdzielenie tego na osobną aplikację usprawni interfejs operatora i pozwoli na zwiększenie kontroli nad dostępem użytkowników.

Modyfikacja interfejsu użytkownika

Przyjęcie nowego procesu jest zawsze wyzwaniem w produkcji, ale intuicyjne aplikacje zawsze będą łatwiejsze do zaakceptowania. Dostosuj przykład funkcjonalny, aby lepiej odpowiadał potrzebom użytkowników.

• Określ, które pola rekordu tabeli [Defect Events] mają być wprowadzane przez użytkowników, a które można zautomatyzować.
  • W Functional Example pole opisu jest generowane automatycznie, ale może być bardziej sensowne, aby użytkownicy mogli napisać niestandardową notatkę.
• Zmodyfikuj routing defektów, aby użytkownicy widzieli tylko te defekty, które ich dotyczą. Filtrowanie może odbywać się w polu Next Steps, polu Reason, polu Assignee lub innym kluczowym wyróżniku procesu.
• Dodaj przyciski "szybkiego działania", aby zautomatyzować typowe przepływy pracy. Być może twój dział jakości ma standardowe rozwiązania dla określonych usterek. Rozwiązania te można dodać do przycisków, które automatycznie wypełniają odpowiednie pola tabeli.

Rozszerzanie modelu danych

Każdy proces jest wyjątkowy, a różnice w procesach prawie zawsze wymagają dodania dodatkowych danych do domyślnego modelu danych.

Jako twórca aplikacji najlepiej wiesz, gdzie Wspólny Model Danych nie pasuje do Twojego procesu, ale oto kilka przykładów sposobów rozszerzenia modelu.

Powiązane tabele

Powiązane rekordy umożliwiają powiązanie jednego rekordu z innym. Oznacza to, że tabela [ Defect Events ] nie potrzebuje szczegółowych informacji o materiale, który został uznany za wadliwy, zamiast tego może po prostu odwoływać się do powiązanego rekordu w tabeli [ Materials].

Tabela [Materiały]

Tabela Materiały jest przeznaczona do śledzenia materiałów, powiązanych z nimi zamówień, wad i innych. Jeden materiał może mieć wiele defektów.

Pozwala to na śledzenie defektów według materiału i wykorzystanie informacji o każdym materiale w tabeli Materiały podczas pracy z jego defektami.

| ID | Tekst | Unikalny identyfikator dla rekordu. Musi być unikalny | | Numer materiału | | Tekst | Identyfikator materiału | | Opis materiału | | Tekst | Czytelny dla człowieka opis komponentu | | Status | | Tekst | Bieżący status materiału. Służy do śledzenia materiału podczas produkcji. | Typ | Tekst | Typ materiału np. partia, jednostka, produkt, podzespół, komponent, partia itp. | Jednostka miary | Tekst | Jednostka miary używana dla ilości | | Lokalizacja | Tekst | Bieżąca lokalizacja materiału | | Ilość | Liczba | Bieżąca ilość materiału | | Zdjęcie | Zdjęcie elementu materiału do wyprodukowania | | Partia / Numer seryjny | Tekst | Unikalne odniesienie materiału łączące go z dostawcą. Służy to do rozszerzenia śledzenia materiału na dostawcę (wewnętrznego / wiecznego), który znajduje się poza Tulip. | Zamówienie | Powiązany rekord | Zamówienie, które używa tego materiału. Jest to używane tylko dla materiału najwyższego poziomu, pozostała hierarchia jest rozwijana poprzez linki podrzędne/nadrzędne materiałów. | Materiały podrzędne | Połączony rekord | Materiały, które są używane (łączone/składane) do produkcji tego materiału | | Materiały nadrzędne | Połączony rekord | Materiał, który używa tego materiału |

Dodawanie pól tabeli

Tabela [Defect Events] jest dobrym punktem wyjścia do śledzenia ważnych danych dotyczących defektów, ale prawdopodobnie nie zawiera wszystkich pól ważnych dla procesu. Być może chcesz również śledzić: - Koszt utopiony w wadliwych towarach (Cost-Of-Goods może pochodzić z powiązanej tabeli [ Materials] ), - Rekord powiązany z powiązanym rekordem [Orders].

Dodawanie tabel

Istnieją dziesiątki różnych wspaniałych zastosowań Tulip, dodanie większej liczby procesów może wymagać dodania większej liczby tabel Tulip.

• And-On Tracking
• Zdarzenia jakości
• Inspekcje
• Sprzęt
• Wysyłka/Odbiór zamówień

Dowolne/wszystkie te tabele mogą być tworzone i włączane do podstawowego przypadku użycia Defect Tracking. Ze względu na elastyczny charakter tabel, te nowe tabele mogą być również zarządzane przez dedykowane aplikacje.