Není architekt jako architekt - jak členit systém na menší části?

Která metoda členění budoucího systému je nejlepší?

To je špatně položená otázka. Možná logická a v zásadě správná. Neexistuje na ni však odpověď. Proč? Protože podmínky nejsou nikdy ideální a tudíž je množina odpovědí na tuto otázku logicky prázdná. Musíme se ptát odlišně.

Jaká metoda je nejideálnější pro náš projekt?

Abych byl ještě přesnější, tak „pro náš projekt v aktuálních podmínkách“. Za každým projektem stojí jiný aparát – lidé, finance, zázemí, politika atd. Každý projekt má tedy jiné podmínky zabezpečující naplnění svého účelu. Což je zároveň klíčové zaklínadlo pro výběr správné metody – která z nich nejlépe pomůže splnit účel projektu.

Proč vůbec systém členit?

Jedna věc je členění projektu. To však přenechme korporacím a projektovým manažerům. Členění systému je však problém, se kterým se s největší pravděpodobností budete muset vypořádat i v menších či středních projektech. Nebudete-li tedy potřebovat systém o dvou tabulkách s jednoduchými vazbami. Komplexnější systémy, zvláště má-li být jejich úkolem pokrýt celofiremní procesy, bude třeba rozpadnout při jejich stavbě na dílčí celky zpracovávané zvlášť a následně propojit v rámci enterprise architektury do high-level celku.

Otázkou pak zůstává – jak?

Obrázek 1: Příklad členění systému komplexního systému

Způsobů je celá řada. Můžeme členit systém na funkční celky a zpracovávat je postupně ve všech ohledech. Můžeme jít ještě dále a rozdělit systém do modulů, což je z mnoha důvodů rozšířený způsob mnoha systémů na českém trhu. Můžeme zohlednit časové hledisko a řešit systém „náhodně“ podle výše časové náročnosti jeho oblastí. Můžeme systém rozpadnout do jednotlivých funkčních a nefunkčních požadavků a řadit je podle priorit – tato metoda se však nejčastěji používá v kombinaci s některou další. Odnoží prioritizace může být například metodika MoSCoW – Must / Should / Could / Won't (Musí / Mělaby / Mohla by/ A nakonec něco jako „Kdyby zbyl čas / asi nebude“). Některé z novějších metod pak dělí systém podle oblastí změn / volatilit. Jistě existují i další způsoby, které jsem zde vynechal, pro ilustraci je však výčet dostačující.

Kterou metodu tak zvolit? Plošně to říci určitě nelze a troufnu si doporučit, abyste nespolupracovali s lidmi a společnostmi, které tvrdí opak. Záleží nutně na procesech, které chcete pokrýt informačním systémem (hledáte komplexní ERP? Systém na správu dokumentů? CRM pro komunikaci se zákazníky?). Záleží také na složitosti těchto procesů a komplexitě databázové struktury. Záleží na složení projektového týmu. Záleží na projektové metodice – chcete pracovat v klasickém „vodopádu“, využít některých zaběhnutých metodik jako je PRINCE2 nebo ITIL nebo pracovat agilně v trendy duchu metodik Kanban nebo Scrum? Výsledné zpracování architektury budoucího systému je koktejlem všech těchto přísad a důležitým předpokladem projektu úspěšného.

Obrázek 2: Názorné zpracování metodiky Scrum (zdroj: http://labs.openviewpartners.com)

A jak tedy začít?

Na začátku předchozí kapitoly jsem zmínil „stavbu systému“. Když si chcete představit svůj budoucí systém, zkuste na něj pohlížet právě jako na stavbu. Dům, který stavíte pro svou rodinu, nebo kancelářskou budovu po expanzi vaší firmy. Stejně jako dům i informační systém má své části, bez kterých prostě nebude stát (fungovat) a které jsou napříč různými stavbami přibližně stejné. Má mnoho a mnoho částí, které jsou důležité pro určitý účel – např. elektrickou síť a osvětlení ve většině domů potřebujete, ale např. v garáži s otevřenou přední stranou nikoliv (může tam být, ale nebude to asi úplně nutné). A samozřejmě existuje také spousta částí, které dělají stavbu lepší či hezčí, ale nejsou nutné. Např. Tančící dům je určitě hezčí, protože se „vlní“. Kanceláře, luxusní byty i restaurace na střeše by se však jistě obešly i bez toho a svůj základní účel by mohly plnit ve stejné kvalitě. Jde o estetickou záležitost, která má pro stavbu zcela jistě přidanou hodnotu (v tomto konkrétním případě velmi vysokou), která však nemá vliv na základní funkčnost svých částí.

Funkční členění – konzervativní pohled, který přetrvá staletí

Můžeme jej přirovnat například k vodopádové projektové metodice. Není nejefektivnější, ani nejrychlejší, ani nedosahuje nejlepších výsledků. Je zde však s námi od sedmdesátých let minulého století a bude tu s námi stále.

Proč?

Představte si nejoblíbenější investiční a spořící produkty mezi lidmi (v průměru) v České republice. Stavební spoření a soukromé penzijní spoření. Ty rozhodně nezhodnotí vaše peníze nejlépe. Navíc je fixují na (poměrně – v případě stavebka) dlouhou dobu, po kterou na ně nesmíte sáhnout a udrželi si tak jejich jisté výhody. Jaké? Oproti srovnatelným produktům stále ještě „slušný úrok“ podpořený státní podporou. A navíc státem zajištěné vklady. Nízké riziko. Nízký výnos.

 Nechci své peníze nechávat v polštáři, ale akcií se bojím.

Tak nějak by se dal shrnout člověk, který „investuje“ tímto způsobem. Nebo spíš spoří. A přesně takto by se dal shrnout člověk/firma, který dělí komplexní systém. Vlastně tím nic nezkazí a výsledku se vždy dobere. Neriskuje. A také nic nezíská.

Proč nás tedy funkční členění všechny přežije? Právě pro svou konzervativnost si najde vždy své zastánce. V kombinaci s jinými způsoby, které dokáží eliminovat jeho slabé stránky, se navíc stává velmi silnou zbraní v „boji“ proti překážkám projektu.

Představme si, jak by mohlo vypadat funkční členění při projektování stavby:

Modulové členění – vlastnost, která má lepší marketing než užitek

Nechápejte mne špatně – členění systému na moduly dává v mnoha ohledech smysl, ale…

V zásadě se tolik neliší od členění funkčního jen s tím rozdílem, že moduly mohou být (ne)nasazovány jednotlivě, což tvoří iluzi možné úspory v případě, že si v pozici klienta některé moduly neobjednáte. Stoprocentní výhodu modulových systémů však neobjevíte během implementace, ale spíše až za ostrého provozu.

A jak je to s tou zmiňovanou úsporou? Výrobci modulových systémů si umí dobře spočítat své potenciální zisky. Pořídit si komplexní ERP složené z modulů tak bude většinou nákladnější, než srovnatelný systém v jednolitém celku. Postupné nasazování po modulech vám příliš užitku také nepřinese. Stejně budete muset nasadit jednu aplikaci, otevírat jednu aplikaci a pracovat s jednou aplikací. To, že některé z modulů zatím nebudou v provozu a budou se implementovat postupně, vám každodenní práci spíše stíží. Řada funkcí systému bude neaktivních, přesto viditelných. Mnoho propadů do dalších agend bude „v budoucnu připraveno“, dosud však pouze pasivních. Osobně nevidím pro segment malých a středních podniků výraznou výhodu v tomto způsobu implementace. (nemluvím o velkých korporacích s různou geografickou či jazykovou příslušností – obří systémy prostě nejde nasazovat jinak než postupně a ve velkém procentu případů navíc nepůjde pouze o jednu aplikaci)

Všimněte si, že marketing mnohých výrobců či dodavatelů moderních IS už od formátu modulových systémů odchází, čím to asi bude?

Jak bychom mohli naznačit modulové členění na projektu stavby domu?

Čas a priority – skrytí vzadu. Nevšimnete-li si jich, dostanete se do problémů

Zatímco časové hledisko je každému selsky uvažujícímu jedinci vcelku uchopitelné, až překvapivě velké množství lidí mívá problém s rozpoznáním a určením priorit.

Je vcelku logické, že se většinou nepodaří za jeden časový úsek nasadit vše. Rozhodně zde platí, že mezi počtem implementátorů (konzultanti, vývojáři, architekti….) a zkrácením doby implementace není přímá úměra. Od určitého počtu si v závislosti na velikosti projektu prostě a jednoduše začnou překážet (a teď nemyslím fyzicky díky velikosti kanceláře) a mnohdy dochází i k problémům se simultánní potřebou zasahovat do stejných oblastí. Časové hledisko také může být, a většinou je, ovlivněno dostupností zdrojů. Nejen na straně dodavatele, ale také na straně klienta. Je naivní si myslet, že implementace si nevyžádá přítomnost řady kolegů a jejich kapacity je potřeba do projektu naplánovat. Finanční zdroje také nemusí být k dispozici nepřetržitě a projekt se kvůli cash-flow často posouvá v čase. Faktorů může být samozřejmě mnohem více.

Nastavení priorit berte jako nutnost a věnujte mu odpovídající úsilí

Prioritizace zadání považuji osobně za nutnost. Existuje mnoho způsobů, jak jej realizovat a neexistuje ten jediný a správný, já osobně však doporučuji kombinaci metodiky MoSCoW a jednoduchého číselného řazení požadavků na řešení.

Prvním krokem je důsledné slovní popsání požadovaných funkcionalit do tzv. funkčních a nefunkčních požadavků. Jde vlastně o samostatnou metodu členění systému, já osobně ji však považuji za natolik standardní, že by měla předcházet jakékoli implementaci. Požadavky na funkčnost budoucí aplikace je třeba dobře slovně popsat a vytvořit měřitelná akceptační kritéria, která budou sloužit k testování zadaných funkcionalit. Tyto požadavky je pak dobré označit s ohledem na to, jak moc důležitá pro klienta daná funkčnost je.

Před druhým krokem si pak dejte určitý časový odstup a skryjte členění podle MoSCoW. Rozdělte si požadavky do větších celků (jejich počet záleží na celkové velikosti projektu) a tyto celky očíslujte od 1 do X. Celky mohou být určeny jakoukoli ze zmiňovaných i vynechaných metodik. Následně proveďte stejné číslování i pro požadavky v rámci těchto celků, vždy od 1 do X. S tím, že požadavek/celek s číslem 1 má prioritu nejvyšší. A je úplně jedno, jestli následně celky spravujete v product backlogu po jednotlivých sprintech nebo postupně vodopádovou metodikou. Máte určený postup prací, ideálně máte každý celek ohodnocen odhadovanou časovou a finanční náročností a můžete vesele plánovat.

Dobře se pak například páruje odhadované řešení oproti možnostem klienta. Byl cílený rozpočet např. 150.000 Kč a projekt je nahodnocen na 200.000 Kč? Co třeba se podívat na požadavky „W“ a zvážit odebrání některých z nich? Je to velmi zjednodušené, ale v zásadě jednoduché.

Volatility, změny…moderní a nabubřelé, přesto na nich něco je

Ano ano…vždy jednou za čas je potřeba přijít s něčím novým. Oživit stagnující trh a vyburcovat zákazníky k nákupu nového, „revolučního“, „zcela zásadně měnícího zavedené pořádky“. Ubezpečuji vás, že stavba systému pomocí oblastí volatilit/změn není KOLO. Ani PARNÍ STROJ. Nemusíte kvůli tomu okamžitě odinstalovat své aktuální systémy a zbavit se všech analýz, které máte v dokumentaci. Uvažujete-li ovšem o novém systému či razantnější úpravě toho stávajícího, možná stojí za to se nad touto novou metodikou pozastavit a alespoň něco si z ní vzít.

Statický design - velkoobchod s květinami (Pavelkunert.cz)

Osobně jsem zkoušel na modelových příkladech z reality aplikovat pouze tuto metodiku a narazil jsem na mnoho „děr“, které obsahuje, stejně jako metodiky ostatní. Nicméně základní myšlenka stavby designu budoucího systému na základě oblastí a jejich předpokládané míře změn v budoucnosti má skutečně něco do sebe.

Je dobré, nebo možná spíše nutné, mít důkladnou představu o funkčnosti budoucího systému a následně správné vytčení oblastí, kterým se budeme věnovat, které jsou pro systém důležité. Ty pak musíme ohodnotit podle toho, s jakou pravděpodobností se jich budou týkat budoucí změny. Oblasti pak stavíme do architektury s ohledem na tyto skutečnosti a celky s vysokou pravděpodobností změn se snažíme skládat v jedny větší celky tak, aby byly samostatně měnitelné – možná tím o něco prodražíme implementaci systému v aktuálním stavu. Ušetříme však mnoho zdrojů, AŽ některé z očekávaných změn nastanou.

Příklad ze stavebnictví bych jeden měl…reálný…z poslední doby. Na mnoha místech českých dálnic se v 4Q roku 2016 stavěla nová svodidla. Stejná jako ta, která tam stála po mnoho let předtím – jen nová, nezrezlá, neotlučená atd. Nevím, kolik taková výměna může stát při přepočtu na 1 km dálnice, to možná poradí kolegové stavaři. Co ovšem vím, že je v jednání jistá evropská směrnice, která by měla upravit vzhled svodidel na dálnicích evropské unie, a které tato naše nová svodidla nevyhovují. Umíte si jistě spočítat, co se stane, když (až) tato směrnice nabyde účinnosti. Všechna tato nová svodidla budeme muset strhnout a postavit nová, o centimetr vyšší (to je s nadsázkou samozřejmě) a ta budeme muset znovu zaplatit.

Pokud by šéf architekt dálnic tuto oblast zahrnul do volatilit a našel by všechny ovlivňující faktory, musel by se přeci rozhodnout jinak. Bez přemýšlení se nabízí dvě varianty řešení:

Obě varianty mi připadají lepší, než nakupovat nová svodidla dvakrát. I kdyby nakonec k přijetí směrnice nedošlo, maximálně vyměníme svodidla později nebo jsme je vyměnili za odlišná. Ani nemusím zabíhat do podrobností abych věděl, že tomuto riziku se dá předcházet.

Rada závěrem?

Universální řešení neexistuje. Metodik projektů i členění systémů je celá řada a pouze jejich vhodnou kombinací dosáhnete nejen úspěšného procesu, ale i efektivního systému, který splní vaše očekávání a klíčové faktory. Shrnutí s konkrétními postupy tak tentokrát nečekejte.

Jak by se dalo pomoci i vaší společnosti a vašemu systému? Zajímá-li vás, jak by mohl vypadat váš projekt, neváhejte mne kontaktovat. Nezávazně se sejdeme a pohovoříme nad kávou či čajem o možnostech, které se nabízejí. Nebo se podívejte, jak by mohl váš projekt vypadat.