Konfiguracja procesu w OOD

Jak przełożyć rzeczywisty postęp organizacji na stany, role, reguły, formy i integracje.

Publiczność: Analityk procesów, przeszkolony administrator, partner wdrożeniowy, właściciel procesu
Wynik: Opublikowana definicja ma właściciela, przetestowane gałęzie normalne i błędne oraz wersję, którą można śledzić.

1. Nie zaczynaj od ekranu

Wybierz jeden konkretny przypadek i nazwij jego początek i koniec.
Wymień uczestników, obowiązki, dokumenty wejściowe i systemy autorytatywne.
Oddziel przepisy prawne i wewnętrzne od dzisiejszych zwyczajów i ograniczeń technicznych.
Uzupełnij wyjątki: brakujący dokument, niezgodność kwoty, odrzucenie, brak aktywności, tłum i błąd integracji.

2. Projekt definicji

Przykład roboczyZastąp wartości <…> danymi z wydania

Proces: Přijatá faktura
Verze definice: 1.0-draft

Společné stavy:
  PRIJATA -> KONTROLA_DAT -> VECNE_SCHVALENI
  -> KONTROLA_ROZPOCTU -> SCHVALENA_K_UCETNIMU_ZPRACOVANI

Volitelná interní účetní kontrola:
  SCHVALENA_K_UCETNIMU_ZPRACOVANI -> UCETNI_KONTROLA
  -> PRIPRAVENA_PRO_EIS

Předání ekonomickému systému:
  PRIPRAVENA_PRO_EIS -> ODESLANA_DO_EIS -> EIS_TECHNICKY_PRIJAL

Další stav smí odpovídat jen tomu, co EIS skutečně vrací:
  CEKA_NA_UCETNI | DOKLAD_ZALOZEN_V_EIS | ZAUCTOVAN_V_EIS

Výjimky:
  KONTROLA_DAT -> VRACENA_DODAVATELI
  VECNE_SCHVALENI -> VRACENA_REFERENTOVI
  KONTROLA_ROZPOCTU -> NEDOSTATECNE_KRYTI
  ODESLANA_DO_EIS -> EIS_ODMITL_DATA | CHYBA_PRENOSU_EIS
  NEJASNY_VYSLEDEK -> NUTNA_REKONCILIACE

Před publikací ověřit:
  role, zástupy, limity, termíny, notifikace,
  idempotenci integrací, audit, návratové větve a podmínku uzavření.
  Technické přijetí ani ID dávky samo o sobě neznamená zaúčtování.

3. Formularz i dane

Każde pole ma nazwę, typ, źródło, obowiązek, widoczność i prawa do zmiany.
W przypadku skopiowanych danych należy zachować źródło, a w razie potrzeby także oryginalną i poprawioną wartość.
Pobierz książki liczbowe z autorytatywnego systemu; kopia lokalna musi mieć właściciela i metodę synchronizacji.
Walidacja musi wskazać użytkownikowi, co jest nie tak i jak naprawić błąd.
Załączniki mają dozwolony typ, rozmiar, cel i regułę przesyłania dla CUL/eSSL.

4. Role, tłumy i zasada czterech oczu

Definiuj role na podstawie obowiązków, a nie nazwisk konkretnych osób.
ZST deleguje tylko określoną rolę, moduł i okres; nie przenosi konta użytkownika.
Przed przejściem sprawdzane są niedozwolone kombinacje ról i ograniczenia.
Wymuszona zgoda dwóch osób musi być niezależna i odnotowana w audycie.
Eskalacja bezczynności nie powoduje automatycznego zatwierdzenia, chyba że reguła wyraźnie na to zezwala.

5. Integracja i dokumenty

Dla każdego kierunku określ system dowodowy, kontrakt, uwierzytelnianie, limit czasu, ponawianie próby, klucz idempotencji i identyfikator korelacji.
Utwórz wersję szablonu DOG wraz z definicją procesu i danymi testowymi.
EPK/WSCS oddziela decyzje biznesowe od podpisów technicznych.
Przesłanie do eSSL powoduje mapowanie dokumentu, metadanych i identyfikatorów zgodnie z potwierdzonym profilem integracji.
Błąd systemu docelowego tworzy stan rozwiązywalny; nie może zniknąć w dzienniku bez wykonania zadania.

6. Testowanie, publikacja i zmiana

Przetestuj normalne przejście, każdą gałąź powrotną, tłum, zakaz roli, limit czasu i niedostępną integrację.
Użyj anonimowych lub syntetycznych danych i spodziewaj się wyników.
Poproś właściciela procesu o potwierdzenie znaczenia reguł, a dział IT o potwierdzenie zachowania integracji.
Opublikuj niezmodyfikowaną wersję definicji; zmiany w toku nie mogą mieć wpływu na bieżące sprawy bez reguły migracji.
Zapisz zmiany, ich wpływ, zatwierdzenie i możliwość powrotu do poprzedniej definicji.

Następna instrukcja

Podręczniki współdziałają ze sobą.

Co musi zawierać pakiet instalacyjny?→Instalacja z obrazów Docker i Docker Compose→Budowanie SIFYBOX z wielu usług→