Konfigurace procesu v OOD

Jak převést skutečný postup organizace do stavů, rolí, pravidel, formulářů a integrací.

Pro koho: Procesní analytik, vyškolený správce, implementační partner, vlastník procesu
Výsledek: Publikovaná definice má vlastníka, otestované běžné i chybové větve a dohledatelnou verzi.

1. Nezačínejte obrazovkou

Vyberte jeden konkrétní případ a pojmenujte jeho začátek a konec.
Sepište účastníky, odpovědnosti, vstupní podklady a autoritativní systémy.
Oddělte zákonné nebo interní pravidlo od dnešního zvyku a technického omezení.
Doplňte výjimky: chybějící podklad, nesoulad částky, odmítnutí, nečinnost, zástup a chyba integrace.

2. Návrh definice

Pracovní vzorHodnoty <…> doplňte z release

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. Formulář a data

Každé pole má název, typ, zdroj, povinnost, viditelnost a právo změny.
U převzatých údajů uchovejte zdroj a podle potřeby původní i opravenou hodnotu.
Číselníky přebírejte z autoritativního systému; lokální kopie musí mít vlastníka a způsob synchronizace.
Validace musí uživateli říct, co nesedí a jak chybu napravit.
Přílohy mají povolený typ, velikost, účel a pravidlo předání do CUL/eSSL.

4. Role, zástupy a princip čtyř očí

Role definujte podle odpovědnosti, ne podle jmen konkrétních lidí.
ZST deleguje jen určenou roli, modul a období; nepředává účet uživatele.
Zakázané kombinace rolí a limity se kontrolují před přechodem.
Vynucené schválení dvěma osobami musí být nezávislé a zapsané v auditu.
Eskalace nečinnosti neurčuje automatické schválení, pokud to pravidlo výslovně nepovoluje.

5. Integrace a dokumenty

Pro každý směr určete systém evidence, kontrakt, autentizaci, timeout, retry, idempotency key a korelační ID.
DOG šablonu verzujte společně s definicí procesu a testovacími daty.
EPK/WSCS odděluje obchodní rozhodnutí od technického podpisu.
Předání do eSSL mapuje dokument, metadata a identifikátory podle potvrzeného integračního profilu.
Chyba cílového systému vytváří řešitelný stav; nesmí zmizet v logu bez úkolu.

6. Test, publikace a změna

Otestujte běžný průchod, každou návratovou větev, zástup, zákaz role, časový limit a nedostupnou integraci.
Použijte anonymní nebo syntetická data a očekávané výsledky.
Nechte vlastníka procesu potvrdit význam pravidel a IT potvrdit integrační chování.
Publikujte neměnnou verzi definice; rozpracovaná změna nesmí ovlivnit běžící případy bez migračního pravidla.
Zapište změny, dopad, schválení a možnost návratu na předchozí definici.

Další postup

Dokumentace tvoří jeden celek.

Co musí obsahovat instalační balíček→Instalace z Docker images a Docker Compose→Sestavení SIFYBOXU z více služeb→