Proces zamówienia może obejmować e-mail, arkusze, portal kupującego, system magazynowy i kilka ról pracowników. Łączenie wszystkiego naraz utrudnia określenie, co właściwie ma robić pierwsza wersja. Konkretniejszy punkt wyjścia to jedna powtarzalna ścieżka od przychodzącego zamówienia do następnego działania zespołu.
Prześledź jedno zamówienie
Wybierz zwykły przykład i opisz, skąd przychodzi zamówienie, jakie dane są wpisywane i kto działa dalej. Zapisz przepisywane pola: identyfikator klienta, kody produktów, ilości, dostawę lub ustalone warunki płatności. Zaznacz miejsca, w których człowiek podejmuje decyzję, a nie tylko przenosi dane.
Mapa powinna pokazywać obecną pracę. Lista nazw programów nie wystarczy. Ważne jest to, jakie informacje posiada każdy system i co powinno się wydarzyć podczas przekazania zamówienia do następnego etapu.
Zacznij od przewidywalnego źródła
Uzgodniony szablon arkusza lub formularz portalu zapewnia jasne dane wejściowe. Można określić wymagane kolumny, identyfikatory produktów i zasady ilości. Dzięki temu łatwiej sprawdzić proces oraz wyjaśnić, dlaczego rekord został odrzucony.
Wiadomości i dokumenty o wielu różnych układach wymagają osobnego omówienia. Rozpoznawanie, interpretacja i kontrola pewności to dodatkowa praca. Prosty import arkusza oraz ogólny system odczytywania dokumentów nie są tym samym projektem.
Ustal reguły chroniące zamówienie
Przydatne kontrole zależą od firmy. Mogą obejmować znane kody produktów, ilości w opakowaniach, dopasowanie kupującego, duplikaty lub wybór magazynu. Część wyjątków można odrzucić od razu, a część pokazać osobie uprawnionej do podjęcia decyzji.
Uzgodnij odpowiedzialność za dane. Jeśli za dostępność odpowiada system magazynowy, automatyzacja nie powinna tworzyć obok niego niezależnego stanu. Jeśli ceny indywidualne pochodzą z innego źródła, trzeba opisać drogę ich pobierania i zasady aktualizacji.
Zachowaj zatwierdzanie tam, gdzie jest potrzebne
Automatyzacja nie musi oznaczać natychmiastowego ostatecznego zapisu. Pierwszy etap może przygotowywać robocze zamówienie i pokazywać wyjątki do sprawdzenia. To użyteczne, gdy dane są powtarzalne, ale określone warunki nadal powinien zatwierdzić pracownik.
Interfejs powinien wskazywać, co przyjęto, co wymaga uwagi i czy system docelowy potwierdził działanie. Samo poprawne przesłanie pliku nie dowodzi jeszcze, że w systemie firmy istnieje właściwe zamówienie.
Uwzględnij wyjątki w testach
- Poprawne zamówienie trafia do uzgodnionego systemu.
- Nieznany produkt jest wyraźnie wskazany, a nie po cichu zastępowany.
- Ponowione żądanie jest obsługiwane zgodnie z regułą duplikatów.
- Odrzucony rekord pozostaje dostępny do sprawdzenia.
- Błąd połączenia nie tworzy niewyjaśnionego częściowego wyniku.
To przykładowe scenariusze, a nie gotowa specyfikacja dla każdej firmy. Rzeczywista lista zależy od systemów oraz pierwszego etapu. Dostępy, interfejsy i ponawianie działań trzeba sprawdzić przed potwierdzeniem konkretnego wdrożenia.
Wybierz etap z widocznym rezultatem
Praktyczny zakres może obejmować jeden format, ustalone kontrole, jeden system docelowy i widok weryfikacji. Kolejne kanały, dokumenty lub programy można dodać po przetestowaniu oraz odbiorze tej ścieżki. Pierwszy etap powinien pozostawić użyteczne rozwiązanie, a nie odłączony eksperyment techniczny.
Realizacja SD-MED pokazuje zamawianie przez kupujących połączone z istniejącym 1C. To przykład rodzaju procesu, a nie gotowy konektor do każdego ERP. Aby omówić własną ścieżkę, poznaj automatyzację obsługi zamówień i opisz obecne dane wejściowe oraz system docelowy.