ACONIS – MASTER

Účel projektu

ACONIS je projektový rámec pre procesné myslenie, biznis analýzu, modelovanie organizácií, návrh riešení, systémovú architektúru a praktické riadenie zmien.

Cieľom projektu je vytvárať zrozumiteľné modely toho, ako organizácia, projekt, služba alebo systém funguje dnes, ako by mal fungovať v budúcnosti a čo sa môže stať, ak sa niektoré predpoklady ukážu ako chybné.

ACONIS má pomáhať najmä pri:

• pochopení aktuálneho stavu,
• odhalení skrytých problémov,
• návrhu budúceho riešenia,
• simulovaní rizík,
• príprave klientskych projektov,
• štruktúrovaní požiadaviek,
• procesnom modelovaní,
• a tvorbe rozhodnutí, ktoré sa dajú vysvetliť technickým aj netechnickým ľuďom.

Hlavná myšlienka

ACONIS vychádza z jednoduchej pravdy:

Ak nerozumieme tomu, ako veci fungujú dnes, nemôžeme bezpečne navrhnúť, ako majú fungovať zajtra.

Veľa projektov zlyháva nie preto, že by chýbala technológia, ale preto, že nikto presne nepomenoval:

• kto čo robí,
• prečo to robí,
• čo na to potrebuje,
• kde vzniká chyba,
• kde sa stráca čas,
• kde vzniká riziko,
• kto nesie zodpovednosť,
• a čo sa stane, ak sa zmení jeden článok systému.

ACONIS má byť nástrojom, ktorý tieto veci robí viditeľnými.

Charakter projektu

ACONIS je metodický, analytický a architektonický projekt.

Nie je to iba softvér.
Nie je to iba procesná dokumentácia.
Nie je to iba kreslenie diagramov.

Je to spôsob práce, ktorý prepája:

• pozorovanie reality,
• rozhovor s klientom,
• modelovanie procesov,
• systémové myslenie,
• hodnotenie rizík,
• návrh cieľového stavu,
• simuláciu možných scenárov,
• a praktickú realizáciu riešení.

ACONIS má byť použiteľný v malých aj väčších projektoch, najmä tam, kde treba upratať chaos, pripraviť zmeny alebo navrhnúť nový systém.

Základné projektové vrstvy

ACONIS môže pracovať v týchto vrstvách:

1. Organizačný model

Popisuje ľudí, roly, funkcie, kompetencie, zodpovednosti, dostupnosť a vzťahy.

Otázky:

• kto je v systéme,
• akú má rolu,
• za čo zodpovedá,
• čo potrebuje,
• komu odovzdáva výstup,
• kto ho kontroluje,
• kto rozhoduje,
• kto vykonáva,
• kto nesie riziko.

2. Procesný model

Popisuje činnosti, kroky, vstupy, výstupy, rozhodnutia a výnimky.

Otázky:

• čo sa deje,
• v akom poradí,
• čo je vstup,
• čo je výstup,
• kde vzniká rozhodnutie,
• kde môže nastať chyba,
• kde vzniká čakanie,
• čo sa deje pri výnimke.

3. Dátový model

Popisuje informácie, ktoré systém potrebuje.

Otázky:

• aké údaje sa zbierajú,
• kde vznikajú,
• kto ich zadáva,
• kto ich mení,
• kto ich potrebuje,
• kde sa ukladajú,
• ako sa overujú,
• ako sa chránia.

4. Technologický model

Popisuje nástroje, systémy, aplikácie, integrácie a technickú architektúru.

Otázky:

• aký softvér sa používa,
• čo je ručné,
• čo je automatizované,
• kde sú slabé miesta,
• čo je možné integrovať,
• čo treba nahradiť,
• čo stačí zjednodušiť.

5. Rizikový model

Popisuje, čo sa môže pokaziť.

Otázky:

• kde môže vzniknúť chyba,
• čo sa stane pri výpadku človeka,
• čo sa stane pri výpadku systému,
• čo sa stane pri nejasnej zodpovednosti,
• čo je najväčšie úzke miesto,
• čo ohrozuje klienta,
• čo ohrozuje obchod,
• čo ohrozuje reputáciu.

AS IS model

AS IS model popisuje aktuálny stav.

Nie ideálny stav.
Nie to, čo si firma myslí, že robí.
Ale to, čo sa reálne deje.

AS IS má zachytiť:

• aktuálne procesy,
• skutočné pracovné postupy,
• používané nástroje,
• neformálne obchádzky,
• slabé miesta,
• chýbajúce vedomosti,
• zodpovednosti,
• problémy,
• duplicity,
• zbytočné kroky,
• riziká.

Dôležitá zásada:

AS IS nesmie byť prikrášlený. Ak klame vstup, bude klamať aj riešenie.

TO BE model

TO BE model popisuje cieľový stav.

Nie ako fantáziu, ale ako prakticky dosiahnuteľný návrh.

TO BE má odpovedať na otázky:

• ako má systém fungovať,
• čo sa má zmeniť,
• čo zostáva,
• čo sa ruší,
• čo sa automatizuje,
• kto bude mať akú rolu,
• aké údaje budú potrebné,
• aké nástroje sa použijú,
• čo bude merateľným výsledkom.

Dôležitá zásada:

TO BE má byť vízia, ktorá sa dá premeniť na kroky.

WHAT IF model

WHAT IF model skúma možné zlyhania, alternatívy a scenáre.

Jeho cieľom je zistiť, čo sa stane, ak:

• človek neurobí svoju úlohu,
• dodávateľ mešká,
• klient nedodá podklady,
• softvér zlyhá,
• rozpočet sa zníži,
• legislatíva sa zmení,
• dátový vstup je nesprávny,
• vznikne bezpečnostný incident,
• zákazník zmení požiadavku,
• kľúčový pracovník vypadne.

WHAT IF pomáha odhaliť slabé miesta skôr, než z nich vznikne drahý problém.

Dôležitá zásada:

Dobré riešenie nie je to, ktoré vyzerá pekne v ideálnom stave, ale to, ktoré sa nerozpadne pri prvom reálnom otrase.

Procesné modelovanie

ACONIS pracuje s procesným modelovaním ako spôsobom porozumenia a komunikácie.

Modelovanie má pomôcť:

• vysvetliť systém,
• nájsť chyby,
• zladiť ľudí,
• pripraviť vývoj,
• rozdeliť zodpovednosti,
• zjednodušiť prácu,
• a vytvoriť spoločný jazyk medzi klientom a technikom.

Použiteľné nástroje môžu byť:

• diagrams.net / draw.io,
• Bizagi,
• BPMN,
• jednoduché blokové schémy,
• tabuľkové procesné mapy,
• textové procesné scenáre,
• prípadne ďalšie dostupné nástroje.

Dôležité nie je nástrojové náboženstvo.
Dôležité je, aby model pomohol pochopiť realitu.

Diagramy a vizualizácia

Diagram nie je ozdoba dokumentácie.

Dobrý diagram má:

• ukázať tok práce,
• zviditeľniť závislosti,
• pomenovať roly,
• ukázať rozhodovacie body,
• zachytiť výnimky,
• pomôcť klientovi pochopiť problém,
• pomôcť vývojárovi navrhnúť riešenie.

Zlý diagram je ten, ktorý vyzerá odborne, ale nikomu nepomôže rozhodnúť sa.

Základná zásada:

Diagram má slúžiť pochopeniu, nie dokazovaniu múdrosti autora.

Roly a zodpovednosti

ACONIS má klásť veľký dôraz na roly.

V mnohých projektoch nevznikajú problémy preto, že ľudia nechcú pracovať, ale preto, že nie je jasné:

• kto začína proces,
• kto rozhoduje,
• kto kontroluje,
• kto dodáva údaje,
• kto komunikuje s klientom,
• kto schvaľuje výstup,
• kto nesie zodpovednosť za chybu,
• kto má právo proces zastaviť.

Roly musia byť pomenované skôr, než sa začne riešiť technológia.

Kompetencie a dostupnosť

Pri modelovaní organizácie nestačí vedieť, kto má aký titul alebo pracovnú pozíciu.

Treba vedieť:

• čo človek skutočne vie,
• čo môže robiť,
• koľko má času,
• kedy je dostupný,
• čo zvládne samostatne,
• kde potrebuje podporu,
• čo sa stane, keď vypadne.

Dôležitá zásada:

Proces, ktorý stojí na človeku bez náhrady, je riziko prezlečené za riešenie.

Klientská analýza

ACONIS má byť použiteľný najmä pri práci s klientmi.

Klient často nevie presne popísať, čo potrebuje.
Vie však popísať, čo ho trápi.

Úlohou analýzy je preložiť klientovu bolesť do zrozumiteľného modelu problému.

Príklady klientskych viet:

• máme v tom chaos,
• nikto nevie, kde sú súbory,
• zákazníci nám posielajú veľké prílohy,
• nevieme sledovať stav požiadaviek,
• niekto to vždy zabudne,
• účtovníčka to nechce robiť ručne,
• klienti nečítajú dokumentáciu,
• nevieme, čo je v cene a čo nad rámec.

ACONIS má z týchto viet vytvoriť procesný a systémový obraz.

Solution Architect prepojenie

ACONIS prirodzene súvisí s projektom Solution Architect.

Rozdiel:

• ACONIS = metodický a procesný rámec,
• Solution Architect = profesijná rola a spôsob návrhu riešení.

ACONIS poskytuje nástroje, modely a metodiku.
Solution Architect ich používa pri práci s klientom, systémom a vývojom.

Dôležitá zásada:

Solution Architect bez modelu riskuje domnienky. ACONIS mu dáva mapu.

Prepojenie s WordPress projektmi

ACONIS je dôležitý aj pri WordPress a pluginových projektoch.

Pomáha pred vývojom určiť:

• aké sú používateľské roly,
• aký je pracovný tok,
• aké údaje treba ukladať,
• čo má byť CPT,
• čo má byť vlastná tabuľka,
• čo má byť nastavenie,
• čo má byť workflow,
• čo je administrácia,
• čo je front-end,
• čo je MVP,
• čo je nadstavba.

Bez procesného modelu sa plugin ľahko zmení na sklad funkcií bez poriadku.

Prepojené klientské projekty

ACONIS môže byť použitý najmä pri projektoch:

• DREMONT,
• Správca súborov,
• SinTrade.Company,
• TOPTOUR-Core,
• TOPTOUR Cestovateľský denník,
• ChatForest,
• Jarmok,
• Osobný kalendár vitality,
• Dr.Fyto,
• cascadya.pro.

ACONIS je pomocný rámec, ktorý pomáha tieto projekty analyzovať, navrhovať a bezpečne rozvíjať.

Procesné vrstvy klientského projektu

Pri každom klientskom projekte možno vytvoriť aspoň tieto vrstvy:

1. Kontext

• kto je klient,
• čo potrebuje,
• čo ho bolí,
• čo je cieľ,
• čo je obchodný dôvod.

2. Aktuálny stav

• ako to robí dnes,
• aké má nástroje,
• kde vzniká chaos,
• kde sa stráca čas.

3. Cieľový stav

• ako to má fungovať,
• čo sa má zjednodušiť,
• čo sa má automatizovať,
• kto bude čo robiť.

4. Riziká

• čo sa môže pokaziť,
• čo klient nemusí pochopiť,
• čo nebude čítať,
• čo bude drahé,
• kde sú technické limity.

5. Etapy

• čo treba spraviť najprv,
• čo môže počkať,
• čo je MVP,
• čo je nadstavba.

Analýza požiadaviek

ACONIS má pomáhať prekladať požiadavky do jasných funkčných blokov.

Požiadavka klienta môže znieť jednoducho:

Chcem, aby si klienti mohli nahrávať súbory.

ACONIS sa pýta:

• kto je klient,
• aké súbory,
• aká veľkosť,
• kto ich vidí,
• kto ich maže,
• kto dostane notifikáciu,
• kde sa ukladajú,
• ako dlho zostanú,
• čo ak súbor obsahuje citlivé údaje,
• čo ak ho nahrá nesprávna osoba,
• čo ak ho treba stiahnuť na mobile.

Tak sa z jednoduchej vety stáva použiteľná špecifikácia.

MVP myslenie

ACONIS podporuje MVP prístup.

MVP nie je lacná oklieštená verzia.
MVP je najmenší praktický test hodnoty.

Otázka MVP:

Čo je najmenší funkčný krok, ktorý overí, či riešenie skutočne pomáha?

Pri MVP treba odlíšiť:

• nutné,
• vhodné,
• neskôr,
• zatiaľ nie,
• vôbec nie.

MVP má chrániť projekt pred preťažením.

Rozhodnutia

ACONIS má viesť k lepším rozhodnutiam.

Každé dôležité rozhodnutie by malo mať:

• dátum,
• názov,
• problém,
• možnosti,
• vybrané riešenie,
• dôvod,
• riziká,
• dopad,
• kto rozhodol,
• čo sa má sledovať.

Dôležitá zásada:

Rozhodnutie bez dôvodu je budúci zmätok.

Changelog

ACONIS odporúča viesť changelog aj pri metodických a projektových dokumentoch.

Changelog môže zachytiť:

• zmeny modelu,
• zmeny procesu,
• zmeny rolí,
• zmeny požiadaviek,
• doplnené riziká,
• zmenené rozhodnutia,
• nové výnimky,
• nové etapy.

Changelog je pamäť projektu.

Riziková analýza

Riziková analýza nemusí byť korporátna tabuľka na strašenie.

Má byť praktická.

Každé riziko možno popísať:

• čo sa môže stať,
• prečo by sa to mohlo stať,
• aký bude dopad,
• ako tomu predísť,
• čo urobiť, ak sa to stane,
• kto za to zodpovedá.

Príklady rizík:

• klient nečíta dokumentáciu,
• nejasná hranica paušál/nadpráca,
• závislosť od jednej osoby,
• expirovaná licencia,
• nejasné vlastníctvo dát,
• zlá mobilná použiteľnosť,
• chýbajúce zálohy,
• technický dlh,
• nesprávne pochopená požiadavka.

WHAT IF simulácie

WHAT IF simulácie sú praktickým nástrojom rizikového myslenia.

Príklady:

• čo ak klient nezaplatí načas,
• čo ak dodávateľ nedodá podklady,
• čo ak plugin prestane fungovať,
• čo ak sa zmení legislatíva,
• čo ak používateľ nahrá škodlivý súbor,
• čo ak účtovníčka odmietne nový proces,
• čo ak klient bude chcieť mobilné rozhranie dodatočne,
• čo ak sa projekt zväčší desaťnásobne.

Tento typ otázok pomáha navrhnúť riešenie odolnejšie voči realite.

Dokumentačná štruktúra

ACONIS môže mať pre každý projekt odporúčanú dokumentačnú štruktúru:

• MASTER článok,
• AS IS,
• TO BE,
• WHAT IF,
• Roly a zodpovednosti,
• Procesy,
• Dáta,
• Riziká,
• Rozhodnutia,
• Changelog,
• MVP,
• Otvorené otázky,
• Zdrojové materiály.

Nie každý projekt potrebuje všetko.
Ale veľký projekt by bez týchto vrstiev nemal ísť do vývoja naslepo.

Jednoduchý jazyk

ACONIS má používať jednoduchý jazyk.

Nie preto, že by témy boli jednoduché.
Ale preto, že model má slúžiť porozumeniu.

Nevhodné je zahltiť klienta slovami:

• enterprise architecture,
• capability mapping,
• orchestration layer,
• governance framework,
• process maturity,
• solution blueprint,

ak nevedú k praktickému rozhodnutiu.

Vhodné je povedať:

• kto čo robí,
• čo sa pokazí,
• čo potrebujeme zmeniť,
• čo treba zaplatiť,
• čo sa stane, ak to neurobíme.

Komunikácia s klientom

ACONIS má pomáhať hovoriť s klientom vecne a zrozumiteľne.

Klient potrebuje vedieť:

• čo riešime,
• prečo to riešime,
• koľko to stojí,
• čo dostane,
• čo sa zlepší,
• čo je riziko,
• čo je mimo rozsahu,
• aké má možnosti.

Dôležitá zásada:

Klient nemusí rozumieť technickej architektúre, ale musí rozumieť rozhodnutiu, ktoré má urobiť.

Etapizácia vývoja

ACONIS podporuje etapizáciu.

Etapy môžu byť:

1. pochopenie problému,
2. AS IS,
3. návrh TO BE,
4. rizikové WHAT IF,
5. MVP,
6. testovanie,
7. úpravy,
8. rozšírenie,
9. dokumentácia,
10. prevádzka.

Etapizácia chráni projekt pred tým, aby sa všetko riešilo naraz.

Vzťah k nástrojom

ACONIS nie je viazaný na jeden nástroj.

Použiteľné nástroje:

• diagrams.net / draw.io,
• Bizagi,
• Notion alebo podobné nástroje,
• BetterDocs,
• WordPress,
• tabuľky,
• markdown,
• GitHub,
• jednoduché textové dokumenty.

Nástroj je dobrý vtedy, keď pomáha lepšie rozhodovať.

Vzťah k AI

AI môže v ACONIS pomáhať.

Možnosti:

• triedenie požiadaviek,
• tvorba modelov,
• návrh otázok,
• identifikácia rizík,
• tvorba AS IS / TO BE osnov,
• návrh dokumentácie,
• príprava klientskych textov,
• kontrola konzistencie,
• tvorba preflight checklistov.

Zodpovednosť však nesie človek.

Dôležitá zásada:

AI môže pomôcť vidieť súvislosti, ale nesmie predstierať, že pozná realitu lepšie než ľudia, ktorí v nej žijú.

Preflight princíp

Pred technickou prácou treba robiť preflight.

Najmä pri vývoji a kóde.

Preflight môže obsahovať:

• over aktuálny stav,
• over názvy súborov,
• over vetvu alebo prostredie,
• over verziu,
• over závislosti,
• over, čo už existuje,
• nájdi zastarané pokyny,
• zastav sa pri rozpore,
• nepredpokladaj, ak môžeš overiť.

Preflight je prevencia zbytočných havárií.

Vzťah k projektovému manažmentu

ACONIS súvisí s projektovým manažmentom, ale nie je s ním totožný.

Projektový manažment rieši najmä:

• úlohy,
• termíny,
• kapacity,
• zodpovednosti,
• dodanie výstupu.

ACONIS rieši najmä:

• pochopenie systému,
• procesy,
• riziká,
• vzťahy,
• architektúru riešenia,
• správne otázky pred vývojom.

Spolu tvoria silný pár.

MVP ACONIS

Prvá praktická verzia ACONIS metodiky môže obsahovať:

• šablónu AS IS,
• šablónu TO BE,
• šablónu WHAT IF,
• šablónu rolí,
• šablónu procesného opisu,
• šablónu rizík,
• šablónu rozhodnutí,
• šablónu MVP,
• jednoduchý klientsky dotazník,
• základný diagramový vzor.

Cieľ MVP:

Vedieť rýchlo a zrozumiteľne popísať projekt tak, aby sa z neho dal bezpečne navrhnúť prvý funkčný krok.

Budúce moduly

Možné budúce moduly ACONIS:

• knižnica procesných šablón,
• AS IS / TO BE / WHAT IF generátor,
• klientsky dotazník,
• rizikový katalóg,
• rozhodovací register,
• diagramové vzory,
• role matrix,
• dátový model template,
• WordPress plugin pre projektové modely,
• napojenie na BetterDocs,
• prepojenie s ChatForest,
• projektový dashboard,
• AI asistent pre analýzu požiadaviek.

Prepojené projekty

ACONIS súvisí najmä s:

• Solution Architect,
• DREMONT,
• Správca súborov,
• SinTrade.Company,
• TOPTOUR-Core,
• ChatForest,
• Jarmok,
• Osobný kalendár vitality,
• Dr.Fyto,
• cascadya.pro,
• technické WordPress projekty,
• klientské projektové riadenie.

Verejná komunikácia projektu

Pri verejnej komunikácii možno ACONIS predstaviť ako:

• metodiku procesného myslenia,
• rámec pre návrh riešení,
• nástroj na pochopenie aktuálneho a cieľového stavu,
• podporu klientskych analýz,
• procesnú a systémovú architektúru,
• praktické modelovanie pred vývojom.

Nevhodné je sľubovať:

• automatické vyriešenie chaosu,
• dokonalé procesy bez práce ľudí,
• univerzálny model na všetko,
• softvér, ktorý nahradí myslenie,
• dokumentáciu, ktorú netreba udržiavať.

Odporúčané podčlánky

Postupne vytvoriť alebo doplniť:

• ACONIS – metodika
• AS IS model
• TO BE model
• WHAT IF model
• Organizačný model
• Roly a zodpovednosti
• Procesný model
• Dátový model
• Rizikový model
• Klientská analýza
• Analýza požiadaviek
• MVP myslenie
• Preflight checklist
• Rozhodovací register
• Changelog projektu
• Diagramové vzory
• ACONIS a Solution Architect
• ACONIS a WordPress projekty
• ACONIS – verejná komunikácia

Stav dokumentu

Tento článok je hlavný MASTER dokument projektu ACONIS.

Slúži ako rozcestník, pracovná mapa a základná definícia metodiky.

Nie je finálnou procesnou príručkou, softvérovou špecifikáciou ani obchodným produktom.
Je to živý pracovný dokument, ktorý sa bude dopĺňať podľa reálnych klientskych projektov, skúseností z modelovania, technických potrieb, nástrojov a rozhodnutí.

Cieľom ACONIS je pomôcť premieňať chaos na zrozumiteľný model, model na rozhodnutie a rozhodnutie na bezpečne realizovateľné riešenie.