Jdeme „úplně na začátek“ a vezmeme to jako metodu, ne jako implementaci

1) Co je „architektura souvislostí“ v implementaci účetního SW

Je to mapa reality firmy ve čtyřech vrstvách, které se musí potkat:

1. Tok hodnoty (objednávka → expedice → fakturace → platba → účetnictví → výkaznictví)
2. Tok dokladů (co vzniká, kdy, z čeho, s jakými pravidly)
3. Tok rozhodnutí (kdo smí změnit stav, schválit výjimku, opravit chybu)
4. Tok odpovědnosti (kdo nese důsledky, kdo je „owner“ chyby)

Výsledkem architektury souvislostí je závazná mapa návazností, kde platí:

• každá změna má dopad,
• každý dopad má vlastníka,
• každé pravidlo má důvod.

2) Role tří dokumentů: každý hlídá jiný typ bordelu

Nejjednodušší uchopení:

• Projektový záměr hlídá bordel ve směru: aby se nedělalo něco „protože to jde“, ale protože to má efekt.
• Projektový rámec hlídá bordel ve hře o moc: kdo rozhoduje, kdo je vlastník, jak se řeší konflikt, kdo může změnit pravidla.
• Logický rámec hlídá bordel v logice a kauzalitě: aby se nezaměňovaly výstupy za výsledky a prostředky za cíle.

Tyto tři dokumenty dohromady vytvářejí „trojúhelník“: Směr – Governance – Logika.

3) Převod do architektury souvislostí: postup po krocích

Krok A — Projektový záměr → „Mapa hodnoty a hranic“
Z projektového záměru se vytahují čtyři věci (a nic víc):

1. Cíl v metrice
   Ne „zautomatizovat“, ale například:

• zkrátit průchod objednávky barákem o X %,
• snížit ruční zásahy do dokladů o X %,
• snížit počet chyb v DPH dokladech o X,
• zkrátit měsíční uzávěrku o X hodin.

2. Rozsah jako hranice reality
   Co do toho patří a co ne. V praxi největší zabiják bordelu:

• co je součást řetězce,
• kde řetězec začíná a končí,
• jaké „sousední systémy“ jsou jen rozhraní, ne součást.

3. Kritické požadavky (must-have invariants)
   Naše „dopravní pravidla“:

• legislativa (DPH, zálohy, banky, účetní zápisy),
• auditovatelnost,
• dohledatelnost změn,
• pravidla pro opravy.

4. Akceptace – jak poznáme, že to funguje
   Tady se rodí testy reality:

• měřitelné ukazatele,
• „co je nepřijatelné chování“ (typicky: tichý bypass).

Výstup pro architekturu souvislostí:
Záměr dá směr toku hodnoty a hranice: co do mapy patří.

Krok B — Projektový rámec → „Řízení změny reality“
Dokument, který dělá implementaci buď stabilní, nebo politicky rozbitou.

Z projektového rámce se vytahuje:

1. Vlastníci procesů (owners)
   Ne role v org chartu, ale vlastníci reality:

• owner objednávky,
• owner skladu/expedice,
• owner fakturace,
• owner bank a párování,
• owner účetnictví a uzávěrek.

2. Rozhodovací pravomoci

• kdo může měnit pravidla,
• kdo může schválit výjimku,
• kdo může „vrátit stav zpět“,
• kdo může opravovat chyby a jakým způsobem.

3. Mechanismus konfliktu
   Když se:

• sklad hádá s účtárnou,
• obchod chce „rychle“,
• účetní chce „správně“,
  kdo rozhodne a jak rychle.

4. Změnové řízení
   Klíčová vrstva:

• jak se mění proces po nasazení,
• kdo to schvaluje,
• jak se to testuje,
• jak se to komunikuje uživatelům.

Výstup pro architekturu souvislostí:
Rámec vytvoří „síť autorit“: kdo má pravomoc zasáhnout do kterého uzlu řetězce.

Krok C — Logický rámec → „Kauzální síť: co s čím souvisí“
Logframe je nástroj proti iluzi, že „něco děláme“ = „něco se zlepší“.

Z logického rámce se vytahuje:

1. Vstupy → aktivity → výstupy → outcomes → dopad
   U každého:

• indikátor,
• způsob ověření,
• předpoklady / rizika.

2. Předpoklady jako závislosti
   Přímá architektura souvislostí:

• „pokud odejde klíčová osoba, co to udělá?“,
• „pokud marketplace změní formát, co to udělá?“,
• „pokud dojde k výpadku banky / párování, co to udělá?“.

3. Rizika jako místa k rozpadu řetězce
   Ukáže se:

• kde je single point of failure,
• kde vzniknou obcházení,
• kde se bordel vrátí oknem.

Výstup pro architekturu souvislostí:
Logframe dá „graf kauzality“: co musí platit, aby systém dával výsledky, ne jen výstupy.

4) Jak z toho udělat jeden sjednocený model (bez klikání)

Výsledkem je jeden „artefakt“, který nese pracovní název „Mapa souvislostí řetězce“.

Každý uzel řetězce (objednávka / sklad / doklad / banka / účetnictví / reporting…) má u sebe šest štítků:

1. Smysl (proč uzel existuje)
2. Vstup / výstup (data i doklady)
3. Pravidla / invarianty (legislativa, účetní logika)
4. Owner odpovědnosti
5. Pravomoci / výjimky
6. Indikátory a ověření (jak poznám, že to jde dobře)

Tím vznikne architektura souvislostí, která není o SW, ale je připravená k implementaci do jakéhokoli SW.

5) „Bez bordelu“ znamená dvě tvrdé zásady

Zásada 1: pravidla jsou nad lidmi
Systém není demokratický: je auditovatelný.

Zásada 2: změna pravidel je drahá a řízená
Jakmile může kdokoli kdykoli „trochu upravit“, bordel je nevyhnutelný.

6) Malá, ale podstatná poznámka: proč je technologie poslední

• Technologie je jen materializace pravidel.
• Když pravidla nejsou, účetní SW bude nahrazovat myšlení, a to končí workaroundy a výjimkami.
• Když pravidla jsou, účetní SW je vykoná a uživatelé se přizpůsobí realitě, ne rozmaru.