Ideálně obojí. A tušíte dobře – řeč bude o rozdílu …a taky podobnosti … mezi business analýzou a IT analýzou. (Nejen) ve světě byznysu totiž nestačí udělat věci správně. Je potřeba dělat i správné věci.
A to nejde bez pochopení rozdílu mezi tím, co vlastně organizace potřebuje (business analýza), a jak to technicky postavit (IT/systémová analýza).
Laura Brandenburg , business analytička a inspirativní BA stratéžka, to na svém blogu shrnuje přesně: “Role byznys analytika je prostě více byznysově zaměřená – definuje potřeby byznysu – a systémový [čti IT] analytik se zaměřuje na technická řešení – definuje, jak systém tyto potřeby naplní.“
Řešení nebo problém?
V praxi často od byznysu slýcháme…
„Potřebujeme novou aplikaci, která nám automatizuje proces schvalování.“
„Chceme chatbot.“
„Postavte nám nový portál.“
Jenže – víme vůbec, proč to potřebujeme?
Jsou to situace, kdy za business analytikem přichází klient či šéf rovnou s požadavkem na řešení. Definice problému bývá přinejlepším mlhavá, ale často chybí úplně. Proč? Protože řešení je hmatatelné – dá se vizualizovat, nacenit, naplánovat. Oproti tomu problém bývá abstraktní, někdy nepříjemný – a tak ho máme tendenci přeskakovat.
Adrian Reed, konzultant BA konzultantů, to vystihuje trefně: „Jako business analytici musíme být obhájci problému – držet diskusi u podstaty a nebát se ptát: ‘Připomeňme si, jaký problém vlastně řešíme?’“
Krásné, ale zbytečné
Tady je příklad z reálného světa. Firma investovala do vývoje interního helpdesku – robustního, přehledného, s AI routingem požadavků. Jenže… když se analytik po spuštění zeptal, co se zlepšilo, zaznělo: „No… zaměstnanci nám pořád radši volají.“
Důvod? Nikdo předem neověřil, co je pro uživatele pohodlnější. Možná by stačilo doplnit stávající systém o přehled kontaktů nebo proškolit první linii podpory. Výsledek: krásný systém, který nikdo nechtěl.
Jak říká Karl Wiegers , SW developer a autor mnoha knih: „Každý požadavek by měl být odpovědí na obchodní potřebu. Pokud tu potřebu nedokážeme pojmenovat, nemá požadavek smysl.“
Past prvního řešení
Reed tomuto nešvaru říká „first solution trap“. Máme tendenci naskakovat na první rozumný nápad – a celý projekt se točí kolem něj. Bez hlubší analýzy. Bez zjišťování, jestli se řeší opravdu ten hlavní problém. A tak se může stát, že celé řešení je perfektní… jen pro úplně jiný problém.
„Když je řešení vybráno dřív, než zapojíme analytika, začíná být problém přizpůsobován řešení. Místo aby řešení vzniklo na základě pochopeného problému,“ dodává k tomu Reed
Dobrá analýza začíná otázkami
Co s tím? Špičkoví BA vědí, že někdy musí dojít i na zpochybnění původního zadání. Musíme se ptát:
Proč to chceme?
Jaký problém tím řešíme?
Jak vypadá úspěch?
Co se stane, když to neuděláme?
Jak k tomu dodává Brandenburg: „Někteří stakeholdeři nechtějí slyšet žádnou analýzu – chtějí jen, aby se jejich nápad zrealizoval. Dobří analytici ale dokážou ukázat, že pochopení problému vede k lepšímu výsledku – pro všechny.“
Business analýza není o tom, že zapisujeme, co stakeholder řekl. Je o tom, že hledáme, co vlastně potřebuje. Ne proto, že mu nevěříme. Ale proto, že mu chceme opravdu pomoct. Takže příště, než začnete psát požadavky… zastavte se. A položte si otázku:
„Řešíme opravdu ten správný problém?“
Protože (a to je poslední dnešní citát 😉), jak řekl marketingový klasik Peter Drucker: „Není nic tak zbytečného jako dělat dokonale to, co vůbec dělat nemáme.“
