Systém pro podporu řízení podnikových požadavků

Jak jsem zmiňoval v předchozím článku Správa požadavků, podle prezentovaných "imperativů" mi připadalo, že odpovídající systém je přinejmenším stejně dostupný, jako nástroje pro servicedesk nebo DevOps.

Vyskytuje se spousta nástrojů pro specifikaci požadavků na software. 

Nevíme o systému pro správu podnikových požadavků.

A to jsme ho hledali dost důkladně... potom dost zoufale... nakonec jsme pro potřeby našich zákazníků něco takového museli vytvořit sami. Tak jsme pochopili, že naše představa o standardní podobě byla poněkud naivní ("...podmíněna obsahem TOGAF, kde to vypadá tak, že kdekdo má Architecture Repository a jde to pořídit v nejbližší sámošce za rohem...").

Lze správu požadavků standardizovat?

Naše nejhlubší přesvědčení je, že to není "volba", ale nutnost. Nemůžeme nechat ani analýzu potřeb, ani formulaci požadavků a už vůbec ne sjednávání akceptačních kritérií na lidové tvořivosti. 

• Proto očekáváme relativně standardní řešení. Ale to nikde...
• Musí být integrované s procesním modelem a podporou systému projektového řízení (nebo integrovatelné s čímkoli, především s ekonomickým a majetkovým systémem, CRM aj.).
• Použitelné pro úplnou správu požadavků - nemusí to na první pohled vypadat jako dobrý nápad - ale není tím myšleno, že se všechny typy požadavků mají řešit stejným způsobem. Jenom když už jednou něco takového máme a zjistíme, že pro monitoring informačních zdrojů potřebujeme evidovat požadavky (na doplnění zdroje či úpravu způsobu zpracování, popř. něco jiného) - má smysl rozšiřovat daný systém?
  Navíc o co všechno by se musel rozšířít. To je obdoba toho, jak monolitické systémy mají vlastní workflow (není účelné rozvádět).
• Situace každé organizace je výrazně odlišná, způsob identifikace požadavků nemusí být shodný. Byť by tam neměly být zásadní rozdíly. Není potřeba vymýšlet kolo. Je pravda, že při bližším pohledu je nutné hodně flexibilní prostředí. 
• Něco, co umožní současně procesy zdokonalovat a jejich instance řídit. V tomto případě také vytvářet & udržovat katalog požadavků.

To by mělo být jednoduché. Tohle "umí" (teoreticky) každý BPMS.

Neumí.

Resp. u těch, které používáme, by pokrytí potřeb (viz předchozí článek & samostatná analýza / metodika - později/jinde) správy požadavků bylo tak pekelně náročné, že by se to jen stěží mohlo vyplatit, pokud by to vůbec šlo zprovoznit v konečném čase. Možná s nimi neumíme pracovat tak dobře, jak jsme si mysleli. Ale neměli jsme prostor to ověřovat.

Znáte to - bylo potřeba jednat rychle.

Výhody iterativního vývoje

To možná také znáte. Máme extrémně dobrou zkušenost s MVP, kdy se při naší historicky nejzajímavější akci - vybudování systému řízení materiálového toku v DF Partner - krásně ukázalo, že "Kdo rychle dává, dvakrát dává...".

Uvedený projekt proběhl pekelně rychle. Ani jsme se do toho nestihli zamotat. Nikdo to nedokázal torpédovat, protože dřív, než mohl začít vymýšlet, "...proč to nejde...", už se bez toho nedalo fungovat. Ale nemá nic moc společného s požadavky, resp. nutno přiznat, že tehdy jsme je skutečně "nepotřebovali" (dáno tím, že samotný proces byl zcela jasný, data konzistentní a času málo).

Vytvářet řešení v jeho minimálním rozsahu - zejména v dosud víceméně neřešených oblastech - přináší obrovské výhody. Neznamená to, že není potřeba udělat analýzu. Jenže ji neděláte proto, že potřebujete alibi pro fakturaci a dva roky záruky. Průběžně zpřesňujete celkový záběr, aby se dalo najít to, co dává smysl udělat jako nejmenší možný krok. Je lhostejné, jak moc přesně bude popsáno to, jak má systém fungovat a vypadat. Formuluje se zadání, co má umět zjednodušit & ulehčit.

Obě strany vědí, že obsah, vzhled i funkčnost se bude měnit. Neustále.

Plus naprosto zásadní výhoda - pokud se některé scénáře nepodařilo domyslet (aby byly realizovatelné s podporou systému)... pokud jsou data v uživatelsky přístupném prostředí, dá se s nimi udělat cokoli je potřeba. Obvykle se dá i vytvořit funkčnost pro podporu zcela zjevných a jasných postupů a klidně počkat, až se objeví ty, na které jsme původně nepřišli.

Přínosy a rizika vlastního řešení

Především musí být skutečně vlastní. Pokud opravdu máte ve firmě (byť nedokonalý) proces správy požadavků, tak je to životně důležitá součást systému řízení. Nervového systému firmy. Účetnictví můžete (a nejspíš byste měli) outsourcovat, ale rozvoj firmy se nedá partnerovi. Je dobré využívat expertízu, zkušenosti odjinud. Není potřeba se obávat, že by partner vědomě poškozoval vaše zájmy. Ale nemá bytostný zájem na vytváření optimální kondice vaší organizace pro budoucnost.

Téma je, jestli je možné "vlastní řešení" koupit. My si myslíme, že ano (rozumí se jeho základ). Zejména pokud je realizováno především v "low-code / no-code" prostředí. Vysvětlíme na vyžádání.

Power Platform

Když řešení potřebujete rychle, použijete platformu, o které víte, že nebude klást příliš velký odpor. Jasně, ne všechno bude dokonalé. Některé prvky jsou vysloveně "ošklivé". Ale (pokud víte, co chcete dělat) je to použítelné.

• Komplex tabulek (primárně SharePoint), pomocí kterých se podněty evidují.
• Workflow, která je (lidem) pomáhají zpracovávat.
• Desítky dalších součástí a funkcí.
• Integrace s katalogem procesů (elementární procesní model) a správou projektového porfolia.
• Knihovny dokumentů, které potřebujeme pro ukládání definic a výsledků akceptačních testů a dalších artefaktů.
• Nativní spolupráce s ostatními aplikacemi a prostředím M365.
• Plně otevřené možnosti pro integraci s jakýmikoli jinými systémy.

Nejdůležitější je naučit se s tím správně zacházet. Přizpůsobit pracovní postupy novým možnostem (něco úplně zavrhnout a nezavrhovat to, co si nevyzkoušíte). Současně neustále doplňovat funkčnost & data podle toho, jak se vyvíjí poznání potenciálních potřeb a příležitostí.

Zcela zásadní součástí námi poskytovaného řešení je adaptace a dle vašeho zájmu trvalý rozvoj metodiky. Pomůžeme vám vytvořit realistické pracovní postupy. Žádné obecné teorie, ale konkrétní pravidla a činnosti.

Samozřejmě platí, že systém "sám o sobě" nic nedělá / neumí. Umět to musí lidé.

Promluvme si o tom, jak užitečný může pro vaši firmu být systém správy požadavků. Nic nevnucujeme. Předpokládáme M365, přičemž máme ověřeno, že se nasazení takovéhoto řešení vyplatí i pokud fungujete na jiné platformě.

Co očekávat

Máme metodiku a prostředky. Umíme využit pro implementaci procesní metamodel. Vzhledem k použité platformě musíme dát do pořádku infrastrukturu.

Umíme vysvětlit, co a proč je rozumné a užitečné. Pomůžeme začít v minimálním rozsahu. Na některém jednoduchém typu požadavků. Naučíme vás analyzovat potřeby. 

Podmínky

• Ochota osvojit si elementární dovednosti, zejména z oblasti 
• Alespoň dílčí uplatnění procesního přístupu
• Komunikovat a spolupracovat - 

Cena

Platí stejné podmínky, jako u všech ostatních produktů - platíte, až víte, jakou hodnotu pro vás má má řešení / spolupráce. Správa podnikových požadavků se vyplatí organizaci se stovkami spolupracovníků a několika relativně nezávislými organizačními součástmi (výjimky jistě existují). Která nemá vlastní velmi ambiciózní a kompetentní IT. Hodnota je na úrovni 2-5% příspěvku na krytí (hrubého zisku; díky potenciálnímu zvýšení efektivnosti rozvojových aktivit v násobcích). Tedy v řádu milionů Kč ročně či vyššší.

Náklady by měly být v řádu desítek tisíc měsíčně.

Krom nákladů na infrastrukturu. Ty umíme optimalizovat. A taky bude potřeba - hlavně na začátku - poměrně dost angažované kapacity člověka, který se má procesu na systému řízení podnikových požadavků věnovat.

Mimochodem - co říkáte na hezké, ale poněkud nicneříkající schémátko? Bylo převzato z dříve zmíněného článku Requirements Management 101: Processes, Plans, and Best Practices. Ono když se napíše "Change management", tak to zní velkolepě, ale bůhví... 😉 ...co to vlastně znamená. Ani to pořadí dílčích kroků pro identifikaci/specifikaci (shromáždit, definovat, analyzovat) není úplně nesporné.

O procesu řízení podnikových požadavků příště.