Business analýza: Připravte své podnikání na nové výzvy!

Nosíte v hlavě už delší dobu nápad, jak posunout váš byznys, ale nevíte, jak ho proměnit v „hmatatelné“ softwarové řešení? Potřebuje vaše firma podnikový nebo informační systém, který jí pomůže dosahovat vytyčených obchodních cílů? Chcete svým zákazníkům nabídnout lepší uživatelský dojem prostřednictvím perfektní aplikace, ale nemáte spolehlivého partnera, který by vývoj zastřešil od analýzy až po nasazení?

Pokud o svém byznysu přemýšlíte vždy s důrazem na budoucí výzvy a příležitosti, gratulujeme: Jste na dobré cestě k úspěchu! Abyste však mohli dosáhnout trvale vyšší konkurenceschopnosti, budete k tomu potřebovat formalizovaný postup, jakým je business analýza. Podívejte se na své strategické a obchodní cíle pěkně z nadhledu a nechte si vyvinout softwarové řešení přímo na míru! Přečtěte si náš článek, ve kterém se dozvíte, co to business analýza vlastně je, jaké kroky obnáší a co vaší organizaci přinese.

Co je business analýza?

Business analýza slouží k pochopení a zlepšení celkové obchodní činnosti a strategie organizací. Zajišťuje soulad mezi obchodními potřebami klienta a koncepcí byznysových změn. V praxi to znamená, že klient má určitou představu o obchodním cíli (vyšší prodeje, expanze na zahraniční trhy, oslovení nových zákazníků, …), a business analýza mu má pomoct najít prostředek, jak tohoto cíle dosáhnout (v našem případě se jedná o softwarové řešení).

Na rozdíl od procesní analýzy, která se zaměřuje zejména na provozní stránku věci (tzn. na funkčnost a optimální sladěnost procesů), se při business analýze díváme na celý problém z pohledu byznysových požadavků klienta. Business analýza má širší záběr zahrnující posouzení podnikatelského a tržního prostředí, finančních faktorů a sestavení strategických doporučení. 

Při business analýze nejprve klientovy požadavky identifikujeme, snažíme se je pochopit, domýšlíme jejich dopady, stanovujeme jejich priority a spojujeme si vztahy mezi nimi do jasně definované struktury. Výstupem je pak dokumentace, strategický plán a v našem případě samozřejmě softwarové řešení ušité na míru konkrétní organizaci.

User stories: K čemu chce uživatel aplikaci používat?

Požadavky a specifikace klienta je nejprve potřeba převést do jednoduchých popisů funkcí z pohledu koncového uživatele. Těmto popisům se říká user stories a jejich smyslem je v hrubých obrysech načrtnout cíle, kterých chce uživatel při používání softwaru dosahovat. Pokud tedy vyvíjíte například aplikaci pro e-shop, může mít user story tuto strukturu: „Jako zákazník chci mít možnost sledovat stav objednávky, abych věděl, kdy mi bude doručena.“

Ve fázi user stories se ještě nezabýváme otázkou, jak budou uživatelé požadované akce provádět. Zajímá nás pouze to, co budou chtít. User stories musejí být proto formulovány stručně a výstižně. Často se používají při agilním vývoji, který je založený na častých iteracích a průběžném dialogu a zpětné vazbě mezi vývojářskými týmy a klientem.

Specifikace user stories je úkolem pro business analytika, který by měl být schopen vše vysvětlit ze strany klienta, a zároveň mít určité povědomí o technické rovině. Jinými slovy: Klient sdělí své požadavky na to, jaké akce by měl být koncový uživatel aplikace schopen provádět, a business analytik to vývojářům „přeloží“ do technického jazyka tak, aby mohla vzniknout konkrétní funkcionalita pokrývající tyto požadavky.

Use cases: Jak bude systém těchto cílů dosahovat?

Když již máme definované user stories, můžeme přistoupit k další fázi, kterou jsou use cases. To jsou již detailnější, technické popisy postupů, které uživatelům umožňují provádět požadované akce. V podstatě se jedná o „recepty“, které vývojářům říkají, jak navrhnout jednotlivé funkce tak, aby uživatel mohl aplikaci efektivně používat.

Na rozdíl od user stories mají use cases i více formalizovanou strukturu. Jsou tvořeny několika částmi, jako jsou název, aktor (uživatel nebo systém interagující s aplikací), podmínky pro spuštění, hlavní tok (primární kroky), alternativní tok (variace a výjimky) a podmínky pro dokončení. Vrátíme-li se opět k příkladu s e-shopovou aplikací a sledováním objednávky, může příslušný use case zahrnovat kroky jako „Uživatel se přihlásí“, „Uživatel vybere objednávku, kterou chce sledovat“, „Systém zobrazí stav objednávky“ atd.

Mezi formální požadavky na use cases patří dále kritéria přijetí a dokončení (podmínky, které musí být splněny, aby byl use case považován za dokončený a přijatelný), číslování use casů, propojení s grafickými návrhy (prostřednictvím dokumentace) a udržování všech prvků v synchronizovaném stavu v rámci jedné verze (k tomu opět slouží dokumentace, která je zdrojem aktuálních a jednotných informací pro všechny zainteresované strany).

Use cases jsou tedy celkově podrobnější než user stories, zaměřují se na technické detaily a umožňují dokumentaci komplexních interakcí s více možnými průběhy. Pomáhají do hloubky pochopit požadavky na systém a strukturu jednotlivých funkcí.

Struktura komponent: Jak spolu budou části vaší aplikace spolupracovat?

Díky user stories víme, k jakým účelům a konkrétním akcím budou lidé aplikaci používat. Use cases vývojářům říkají, jak jednotlivé funkcionality strukturovat. Konečně si tedy můžeme vyhrnout rukávy a pustit se do definicí a návrhu komponent aplikace.

V tomto prvním kroku je potřeba komponenty rozdělit podle typů a popsat je z hlediska funkce a účelu. Řekněme, že máme komponentu „tabulka“: Její popis bude obsahovat informace o tom, co přesně tato komponenta dělá, jaké jsou její specifické vlastnosti (možnosti řazení, počet sloupců atd.). Takto popsané komponenty dále dělíme podle typů do jasně specifikovaných kategorií, např. „uživatelské rozhraní“, „datové komponenty“, „kontrolní prvky“ atd. Hlavním smyslem tohoto kroku je to, aby bylo možné komponenty jednou navrhnout a naprogramovat a poté používat na různých místech aplikace konzistentně se stejnou definicí.

Kromě popisu a kategorizace komponent je nutné věnovat pozornost také jejich použití odlišnými částmi aplikace. Vezmeme-li si opět příklad s tabulkou, je potřeba specifikovat třeba to, která část aplikace bude využívat tabulku s pěti a která se třemi sloupci.

Jak jsme již naznačili výše, díky konzistentním definicím a popisům je následně možný i standardizovaný design a implementace. Pokud se tedy kdekoli v aplikaci objeví tabulka, bude mít vždy stejný vzhled (barva, tloušťka ohraničení, font písma atd.), i když se bude lišit velikostí (počet sloupců a řádků). Jednotné definice umožní vytváření knihoven komponent, což vývojářům usnadní práci a zajistí maximální konzistentnost.

Tvorba wireframů a klikatelný prototyp

Pokud kladete důraz na co nejlepší uživatelský dojem, lze v rámci analýzy přikročit i k návrhu obrazovek (wireframy). Wireframy jsou statické či interaktivní skicy obrazovek systému nebo aplikace, které vystihují jejich strukturu a rozvržení ovládacích prvků. Velkou výhodou těchto náhledů je možnost vizualizace výsledného softwaru dlouho před jeho dokončením – klient tak může rychle poskytnout zpětnou vazbu, na základě které vývojáři návrh iterativně doladí k dokonalosti.

Za zmínku stojí také možnost vytvoření klikatelného prototypu, což je zjednodušená verze aplikace (demo) pro ověření její funkčnosti předtím, než se začne reálně programovat. Na rozdíl od wireframů, které jsou více statické, lze pomocí klikatelného prototypu vyzkoušet i základní interakce uživatele se systémem. To je dalším cenným zdrojem zpětné vazby, která pomůže „vychytat“ nedostatky dlouho před nasazením.

Dokumentace: Víc než jen zbytečné papírování

Důležitou součástí business analýzy, na kterou se občas zapomíná, je precizní dokumentace. Všechny kroky, od zjištění požadavků a byznysových potřeb až po nasazení aplikace, je potřeba přehledným a detailním způsobem zaznamenávat. Jednoduchým pravidlem pro vytváření dokumentace je to, aby se z ní někdo, kdo se na vývoji softwaru nepodílel, dozvěděl vše podstatné a mohl na již odvedenou práci navázat a systém dál rozvíjet.

Dokumentace ale pomáhá i samotnému klientovi lépe porozumět cílům a rozsahu projektu, včetně veškerých procesů a rozhodnutí v rámci analýzy. Dalším přínosem je efektivní komunikace mezi klientem (případně jeho zaměstnanci) a vývojáři. Dokumentace je společným referenčním bodem, na který je možné se odkazovat a který předchází nedorozuměním a nekonzistencím.

Pečlivě zpracovaná dokumentace, včetně systematického verzování, napomáhá zajištění kvality (QA) a dodržování standardů (případě i zákonných předpisů).

Jak zjistím, kolik mě to celé bude stát?

V případě business analýzy není možné cenu závazně a s jistotou stanovit předem, protože se vždy uplatňuje model průběžné fakturace („pay-as-you-go“). Samozřejmě lze klientovi sdělit přibližný odhad a dopředu se domluvit na tom, v jakých cyklech se bude zhruba fakturovat, ale konečnou částku není snadné určit takříkajíc „od stolu“. Vždy se může stát, že se objeví určitá překážka nebo úroveň detailu, o které nikdo nevěděl předem a kterou je nutné odstranit, aby mohl vývoj pokračovat.

Model „pay-as-you-go“ je však v mnoha ohledech pro klienta výhodný – nabízí větší flexibilitu v podobě škálovatelnosti rozsahu projektu (rozsah lze průběžně rozšiřovat nebo zužovat) a řízení rizika (např. u projektů s měnícími se požadavky se nestane, že by se klient dopředu upsal k příliš drahému kontraktu). Je také potřeba zmínit efektivnější správu nákladů, operativní stanovování priorit a celkově větší transparentnost. 

Co dál? Technická analýza!

Byla to fuška, ale konečně si můžete vydechnout: Business analýza je úspěšně za vámi, nová aplikace splňující vaše byznysové potřeby je navržená a připravená na realizaci. V podnikání je ale vždy potřeba se ptát: Co dál? Jaké další výzvy stojí před vaší firmou? Jak ještě více posílit konkurenceschopnost a odolnost vaší organizace dovnitř i navenek?

Na business analýzu lze navázat technickou analýzou, která doplní konkrétní návrh datového modelu, rozhraní pro komunikaci s dalšími systémy, jejich propojení atd. My v Think Easy provádíme technickou analýzu v rámci business analýzy – tyto dva přístupy se vzájemně doplňují a umožňují perfektní vyladění vašeho řešení i po provozní stránce. Ve fázi technické analýzy se totiž do procesu zapojí vývojáři, kteří dohlédnou na to, aby navržený systém splňoval nejen obchodní potřeby, ale také bezvadně fungoval. Je-li to nutné, můžeme ještě upravit i celkový rozpočet.

Business analýza v režii expertů

Pokud jste dočetli až sem, určitě máte hlavu plnou otázek: Z jakého konce business analýzu uchopit? Jak si jednotlivé aktivity rozplánovat, aby vše probíhalo hladce a efektivně? Kde najít spolehlivého a profesionálního partnera, který dokáže celý proces zastřešit od identifikace požadavků až po nasazení hotového systému? Business analýza může být komplexní proces, a proto není žádnou ostudou obrátit se na skutečné experty. Rádi si poslechneme vaše nápady a navrhneme technické řešení, se kterým dosáhnete svých obchodních cílů. Vyplňte náš kontaktní formulář, domluvte si nezávaznou schůzku a představte nám svůj projekt!