ÚvodBlogAgilní Business Intelligence, díl 1: proč to zkusit jinak ?
Agilní Business Intelligence, díl 1: proč to zkusit jinak ?
V rámci jednoho z mých předchozích pracovních angažmá (ještě před založením Delfínů) jsem prošel dvěma tragickými projekty, které mě přesvědčily, že stávající klasický způsob projektového řízení implementace Business Intelligence řešení metodou „waterfall“ má ohromná úskalí a rizika a že musí existovat lepší, alternativní přístup. Tyto projekty mi trvale utkvěly v paměti jako názorné odstrašující příklady.
Projekt 1: implementace datového skladu a reportingu pro softwarovou společnost. Před začátkem projektu proběhla standardní dvouměsíční analýza – pohovory se zástupci všech oddělení na téma informačních potřeb, podle kterých byl následně nastaven rozsah projektu. Podle našeho chápání měl být vybudován datový sklad a sada reportů, které podpoří a zjednoduší tvorbu pravidelných zpráv pro akcionáře a dodají informace pro rozhodování interním zaměstnancům. Implementační tým byl tvořen námi jako zástupci dodavatele a zaměstnanci oddělení, které do té doby reporty vytvářelo. Interní tým byl přesvědčen, že ví, co je potřeba uživatelům dodat, proto je nebudeme průběžně zatěžovat a přijdeme až s výstupy k testování. My jako dodavatel jsme tento fakt akceptovali a to se (z dnešního pohledu samozřejmě) ukázalo jako tragická, neodpustitelná chyba. Přibližně do půlky projektu vše probíhalo skvěle, datový sklad utěšeně rostl, reporty přibývaly a bylo rozhodnuto, že budou konečně zapojeni i uživatelé, aby reporty a čísla mohli testovat a připomínkovat. První reakce byla jako studená sprcha. Ukázalo se, že uživatelé celou dobu očekávali systém, který bude zprávy pro akcionáře automaticky na stisk tlačítka generovat a že vygenerovaná data půjde manuálně upravovat a libovolně k nim dopisovat komentáře. To je úloha, kterou standardně řeší jiné než klasické Business Intelligence nástroje, vyžaduje implementaci korekční vrstvy, řadu manuálních vstupů a další funkce, se kterými jsme původně vůbec nepočítali. Začala série vyjednávání o tom, kdo co říkal, věděl, předpokládal a podepsal, projekt byl rozšířen, protáhl se o několik měsíců, BI nástroje byly patřičně „ohnuty“ a nakonec se opravdu podařilo systém nastavit tak, aby zprávy automaticky generoval. S jednou nevýhodou: aby k automatickému vygenerování došlo, museli uživatelé provést tolik kroků, že pracnost byla ve finále stejná nebo dokonce o něco větší, než původní manuální způsob jejich zpracovávání. Řešení bylo používáno 3 měsíce a pak postupně zaniklo. Dodnes tento projekt považuji za největší osobní neúspěch v mé třináctileté kariéře BI konzultanta a projektového manažera a nepřestává mě udivovat, jak kritické chyby jsem při jeho řízení udělal.
Projekt 2: implementace datového skladu a reportingu pro retailovou společnost. Projekt měl za úkol vybudovat komplexní datový sklad a nad ním cca 100 reportů. Po tříměsíční analýze byl nastaven rozsah a plán projektu - implementace měla trvat přibližně 9 měsíců. Po celou dobu vývoje tehdejší projektový manažer (po kterém jsem řízení v krizovém režimu převzal) na pravidelných schůzkách reportoval, že se projekt vyvíjí úspěšně. Před termínem plánovaného dokončení požádal o třítýdenní posun, protože zbývalo „dodělat několik reportů“. Na následující schůzce požádal o další tři týdny. A po tomto termínu vyplulo na povrch, že dokončeno není prakticky nic, že se datový sklad potýká s ohromnými výkonnostními problémy, vyvinutá je cca třetina reportů, kvůli navrženému datovému modelu jejich spuštění trvá desítky minut a navíc vrací špatná čísla. Po náročných jednáních se zákazníkem bylo rozhodnuto, že projekt bude na náklady dodavatele dokončen v omezeném rozsahu. Následná implementace trvala dalších 12 měsíců, způsobila dodavateli vážné finanční problémy a i zákazník výsledek podle mého názoru akceptoval spíše z celkové únavy, než že by jím byl uspokojen.
Po těchto dvou zkušenostech jsem se rozhodl, že podobnou zkušenost už nikdy nechci zažít a že založím společnost, která k implementaci BI řešení bude přistupovat jinak. Rozhodli jsme se prosazovat implementaci Business Intelligence pomocí agilních metodik vývoje, které podle nás výrazně snižují riziko projektu a zvyšují jeho obchodní přínos pro uživatele.
Agilní metodiky spočívají v implementaci projektů v krátkých iteracích (pro BI projekty standardně 2-3 týdny), z nichž každá musí uživatelům dodat reálně využitelné výstupy v produkční kvalitě. Metodika vychází z poznatku, že uživatelé mají ve skutečnosti velmi mlhavou představu o tom, co potřebují, a často to zjistí až v okamžiku, kdy výstupy dostanou na stůl. Tento fakt často irituje klasické „ajťáky“, kteří nedokáží pochopit, jak může uživatel najednou chtít něco jiného, než jim na začátku projektu řekl. Je to ale naprosto logické a funguje to i v běžném životě – dokud si nevyzkoušíme několik aut, nevíme, co od nich požadovat a očekávat, které nám bude vyhovovat a jaké požadavky máme mít při nákupu. Dokud si neprojdeme první rekonstrukcí bytu nebo stavbou domu, nevíme, na co si dávat pozor, co chtít po architektovi a co po stavební firmě. I soužití s partnerem se před svatbou vyplatí vyzkoušet, abychom věděli, jestli nás něco později nepříjemně nepřekvapí (i když ani poté se tomu nedá vyhnout úplně J). Přitom o všech těchto věcech běžného života standardně víme daleko více, než o nějakém „Business Intelligence“. Dát dohromady všechny teoretické požadavky na informace, které budeme chtít za půl roku znát, je pro budoucí uživatele podobné věštění z křišťálové koule. Agilní metodiky využívají řadu technik jako je uživatelská konference, zásobník uživatelských příběhů, denní patnáctiminutové schůzky projektového týmu (SCRUM), řízení technologického dluhu a další, o kterých se zmíníme v další kapitole. Nejdůležitější ale je, že uživatelé dostávají reálné výsledky průběžně, mohou dynamicky měnit své požadavky a včas zatáhnout za záchrannou brzdu v případě, že se výstupy začínají hodně lišit od jejich původních představ. Agilní projekty jsou na změnu požadavků připravené a oproti projektům klasickým je vítají, protože požadavek na změnu znamená, že výstup někoho zajímá. Už guru datových skladů Ralph Kimball tvrdil, že pokud k datovému skladu a reportingu neexistují žádné změnové požadavky, znamená to naprostý neúspěch projektu, protože řešení nikdo nepoužívá.
Tímto článkem zahajujeme seriál na téma Agilní Business Intelligence, v rámci kterého bychom se s vámi rádi podělili o techniky a zkušenosti, které při budování BI řešení používáme, a byli bychom moc rádi, kdybyste se do diskuze zapojili i Vy, ať již na síti LinkedIn, Facebook, emailem nebo osobně. Neváhejte nám tedy napsat, nebo si domluvit schůzku – těšíme se na Vás.
Pokud Vás článek zaujal, můžete pokračovat čtením druhého dílu.
Autor: Jakub Holubec
Chcete se dozvědět více o agilním řízením? Přijďte na náš Workshop agilního řízení. Workshop pořádáme pro firmy i pro jednotlivé zájemce.