BI Delivery Process

Ukázkový BI Delivery process vychází z mých zkušeností na projektech. Jeho cílem je oddělení specifických BI rolí a dát komplexní přehled do vývoje BI, ukázat důležitost business analýzy a solution architektury.

Velká část firem tento proces nemá popsaný a každý projekt  si jede po svém. Proto jsem ke každému výstupu doplnil typické příznaky jeho přeskočení. Naplnění tohoto procesu má dlouhodobě vliv na snížení nákladů na vývoj a provoz BI řešení.  Implementace tohoto procesu není jednoduchá a je třeba navázat na současné zvyky. Nápady ve stylu udělat šablony a začít každý dokument tvrdě vyžadovat zpravidla nevedou k cíli.

Kdy přichází nutnost zavedení procesu? V situaci, kdy je analýza AS-IS stavu tak dlouhá, že se nedokončí a vývoj i provoz řešení stojí 2x tolik (plus náklady na pošramocené vztahy s dodavatelem a interním týmem), trvá 3x déle (za předpokladu, že nebude třeba hledat nového dodavatele) a přinese 20% očekávaných benefitů (pokud se projekt vůbec dokončí).

Výstupy procesu

Všechny výstupy budou jeden po druhém popsány zde na blogu. Na této stránce je pouze základní přehled.

Business Requirement Summary

Zpracuje: Business Analyst
Schvaluje: Business Architect
Účel: V jakém procesu a jak se promítne vyřešení požadavku? Kdo jsou stakeholdeři? Kdo je sponzor? Zjednodušeně jde o to zasadit požadavek do kontextu celé firmy a jejího fungování.
Platí, že zkušený business analytik (architekt) požadavek z 50% doplní právě o souvislosti napříč firmou a zachrání tak projekt od prvního restartu (u středního BI projektu úspora cca 3-6 měsíců času + adekvátní MD).
Když chybí: Do projektu budou nahodile přibývat stakeholdeři a každý přinese sadu change requestů, zároveň tito lidé a oddělení na projektu oficiálně nebudou (nebudou mít čas a projekt většinu jejich požadavků stejně odignoruje). Nepodaří se nahradit původní řešení. Vedení má pocit, že to zaměstnanci zbytečně blokují a zaměstnanci pochybují o kompetencích managementu. Měl-li projekt přinést úspory, zpravidla je převýší náklady na implementaci.

Delivery Packages Statements

Zpracuje: BI Solution architect
Schvaluje: Data Architect
Účel: Rozpad BI požadavku do jednotlivých BI dodávek (balíčků). Velikost balíčku je definována samostatností nasazení a odhadovaným časem implementace (do 5 měsíců). Delivery packages statements typicky obsahuje business kontext a popis high level architektury (Které DWH vrstvy budou upraveny (backend a fronted), datové zdroje, schématické etl) a komentář. Rozsah je maximálně 2 stránky.
Když chybí: Projekt s plánovaným trváním 1 rok probíhá následovně. Prvních 6 měsíců se tvoří analýza a panuje atmosféra optimismu a radosti, na konci tohoto období jsou všichni překvapeni, že výstupy z analýzy se míjí očekáváním, projekt se o půl roku prodlužuje. Začíná se vyvíjet první fáze, projekt začíná být pod tlakem. Přichází první spory mezi dodavatelem, zákazníkem a sponzorem. Steeringy jsou o tom, jak si „oplechovat pozadí“. Vzhledem k prodloužení přichází change requesty (okolí projektu se zpravidla nepodaří zmrazit), to projekt protáhne o dalších 6 měsíců. Přichází první rescopes a descopes. Po cca 2 letech je projekt dodán nebo restartován.

AS – IS BI Solution Architecture

Zpracuje: BI Analyst
Schvaluje: BI Solution Architect
Účel: Popis AS-IS stavu, v ideálně světě lze vyčíst z dokumentací, či dřívějších projektů. Typicky jde o fyzický datový model, ETL model (DFD), Manual inputs definition, případně další informace, které umožní formální implentaci (standardizaci) prototypu.
Když chybí: Nové BI řešení nebude reflektovat současný stav – špatný odhad pracností, nepodaří se odstranit původní řešení, nové řešení bude odmítnuto a skončí v propadlišti dějin. AS-IS analýza je výstup, který zajistí, že zadání projektu (které často padá shora), bude dávat smysl i na té nejnižší úrovni. Pokud je řešení nové, o to více je tato fáze nutná (někdo musí posbírat všechny excely apod.).

Functional or Non-Functional Prototype

Zpracuje: BI Analyst
Schvaluje: Business stakeholders
Účel: Co nejrychleji (a nejlevněji) vytvořit prototyp, který dokáže zpracovat vstupní data na požadované výstupy, které by mohly stakeholdeři akceptovat. Ideálně je možné tento prototyp dělat na nějakém pískovišti v produkčním prostředí.
Když chybí: Rozejde se pohled stakeholderů, architektury a vývojářů (rozebráno zde – požadavky na analytickou fázi). Nízká angažovanost stakeholderů během analýzy, píše se mnoho psaného textu, předávka vývojářům bude složitá a někdy i emotivní, vývoj a UATy se značně protáhnou.

Target BI Solution Architecture (Solution Design)

Zpracuje: BI Analyst
Schvaluje: BI Solution Architect
Účel: Popsat cílovou architekturu BI řešení. Typicky jde o fyzický datový model, ETL model (DFD), Manual inputs definition, případně další informace, které umožní formální implentaci (standardizaci) prototypu.
Když chybí: Dodané řešení bude black box a vznikne silná závislost na dodavateli. Sepsání dokumentace bude tak drahé, že se neuskuteční (nebo spíše odflákne). Příští as-is analýza se prodraží (analytik bude muset dělat reverse engineering od nuly).

Standardized BI Solution

Zpracuje: BI Developer
Schvaluje:  BI Analyst + QA + Stakeholders
Účel: Zajistit provozovatelnost prototypu -> tzn. splnit formální (technické) požadavky BI řešení (Historizace dat, datový slovník, logování, začlenění do ETL scheduleru, kvalita kódu, kompletace metadat). BI oddělení má zpravidla nějakou metodiku nebo standard, který potřeba splnit. Tento artefakt je finální BI dodávka, která bude sloužit stakeholderům.
Když chybí: Projekt nedodá klíčový výstup a skončí failem. Jedinou vyjímkou je stav, kdy se skončí prototypem (sponzor a stakeholdeři dojdou k závěru, že řešení nechtějí standardizovat, typicky v situacích, kdy se neustále mění zadání)

Documentation

Zpracuje: BI Analyst
Schvaluje: QA + Stakeholders
Účel: Potvrdit aktuálnost Target BI Solution Architecture (Solution Design) a případně rozkopírovat jeho části na místa dle zvyklostí zákazníka.
Když chybí: Target architektura (pokud byla nadefinována) zůstane zapomenuta v nějaké projektové složce a bude aktualizována až s dalším projektem (za předpokladu, že PMs fungují dobře a s novým projektem tu složku dohledají).