Agilní přístup existuje na standardy IT už dlouho, a ukázalo se, že je pro mnoho společností úspěšný. S tím, jak se společnosti vyvíjely a postupovaly průkopnickou fází agility, objevila se tu tendence podnikat v tomto směru větší a větší akce.
Objevily se dokonce pokusy o aplikaci agility při podpoře nasazení ERP (projektů, které jsou nechvalně proslulé svojí složitostí s významnou mírou integrace). Ale výhody agilního přístupu, které byly odvozeny ze snah menšího rozsahu, se přirozeně nepřenesly na agilní projekty ve větším měřítku.
Díky zkušenostem a průzkumu jsem identifikoval šest výzev, které je třeba překonat, aby bylo možné efektivně využít agilní přístup k při implementaci ERP, a akce, které je k tomu třeba podniknout.
1. Klíčové rozhodovací řízení
Významným faktorem úspěšného agilního projektu je malý angažovaný tým vzájemně propojených, vysoce kvalifikovaných členů zmocněných činit klíčová rozhodnutí v průběhu celého projektu. Jak se měřítko projektu zvětšuje, zvyšuje se objem rozhodování mezi týmy a zvyšuje se také počet „šíleně chaotických“ rozhodnutí, která je třeba učinit. Tato rozhodnutí obvykle zahrnují vítěze a poražené v rámci organizace. Je obtížnější a časově náročnější zajistit, aby všechny týmy byly sladěny, hlavně když je ve hře více týmů a souvisejících důsledků.
Zvyšuje se také rozsah zúčastněných stran, což může dále prodloužit čas potřebný k dosažení konsensu. Agilní myšlení neprospívá přijímání velkých rozhodnutí napříč funkcemi, takže s tím, jak se projekt zvětšuje, stává se tato záležitost komplikovanější.
K vyřešení tohoto bodu je třeba, aby technici na pozici Release Train Engineer (RTE) převzali plnou odpovědnost za identifikaci klíčových rozhodnutí, včasnou a častou socializaci a vytvořili strategii rozhodování, která umožní, aby tato klíčová rozhodnutí byla přijímána včas.
2. Správa nevyřízených položek
V agilním projektu velkého měřítka je správa nevyřízených položek obtížnější než v malém vývojovém projektu, protože nevyřízené položky se skládají z mnoha aktivit, které přímo nesouvisejí s vývojem softwaru (jde například o podporu datových týmů, podporu školení, aktivity související s nasazením atd.).
Správa integrovaného testování může být také náročná, protože většina testování ERP vyžaduje zapojení více týmů. Druhou dimenzí složitosti správy nevyřízených položek je, že mnoho položek v nevyřízených položkách je nediskrečních (zejména v ERP) a je přímým požadavkem jiných týmů. Tyto dvě dimenze kladou mnohem větší požadavek na vlastníka produktu, aby pochopil rozsah celého programu, a aby tak účinně upravil nevyřízené položky za účelem jejich správného seřazení a synchronizace s ostatními týmy.
Abyste tento problém vyřešili, je třeba v počáteční části programu vyřešit strategii end-to-end testování. Vytvořením této strategie mohou vlastníci produktů lépe porozumět závislostem a precedentům, které jsou nutné k upřednostnění nevyřízených položek.
3. Synchronizace a sladění scrum týmů
Agilní projekty silně závisejí na kalibraci rychlosti napříč scrum týmy. Jestliže se objeví nesoulad v komunikaci a výkonu napříč všemi týmy, skončíte s nevyužitým zdrojovým týmem. Všechny týmy musejí překročit cílovou čáru ve stejnou chvíli na stejné úrovni dokončenosti.
Aby toho bylo dosaženo, musí agilní nastavení mysli kompletně přijmout všichni členové všech týmů, kteří zároveň musejí mít jasnou definici slova „hotovo“. Týmy fungující v různých definicích slova „hotovo“ by mohly vést k prodloužení času stráveného end-to-end testováním.
Aby tento soulad umožnili, musejí Release Train inženýři provést dvě kritické funkce:
- Potvrdit, že závislosti mezi týmy jsou rozpoznány a zaznamenány jako součást nevyřízených položek jednotlivých týmů a plánů sprintu.
- Monitorovat rychlost a přizpůsobit týmovou kapacitu sprintů dle požadavků pro sjednocení dodávky daného týmu v očekávaném datu dodávky.
4. Integrace sdílených zdrojů a zdrojů na částečný úvazek
I když zde budou členové na plný úvazek, kteří se projektu věnují naplno, budou pravděpodobně muset sdílet svůj čas napříč více týmy. Efektivní alokace jejich času bude záviset na jejich udržení v souladu s tím, kde jsou ostatní týmy v projektu.
Rovněž bude nutné spravovat zdroje na částečný úvazek mimo účast scrum týmu. Například osoba odpovědná za audit může celkově agilnímu projektu věnovat pouze 10% svého času. Manažer programu bude muset pomoci koordinovat jejich čas, aby zajistil jejich dostupnost a angažovanost v agilním projektu, když je potřeba provést audit.
Dobrým nástrojem k řešení tohoto bodu jsou prognózy zdrojů. Release Train inženýři musejí udržovat úplnou předpověď poptávky po zdrojích napříč programy a pravidelně aktualizovat všechny oblasti poskytující služby. Vlastníci produktů si u těchto externích poskytovatelů zdrojů získají přízeň tím, že budou spravovat nevyřízené položky tak, aby odpovídaly prognóze poptávky.
5. Nezbytná byrokracie pro velké projekty
Aby byl projekt udržován na správné cestě, je typické, že jsou do formálních hodnocení (Stage Gate Review) zapojováni i seniorní pracovníci, a že k tomu, aby takové hodnocení mohli podpořit, mají vše, co potřebují. U projektů velkého měřítka je typické, že je potřeba více výstupů a dokumentace k tomu, aby mohlo být dosaženo plné podpory ze strany členů hodnotícího výboru. Paradoxem při implementaci agilního přístupu je fakt, že je zde kladen větší důraz na postupný vývoj v průběhu projektu a menší na dokumentaci obecně. To komplikuje schopnost týmu poskytovat na úrovni výboru transparentnost v oblasti správy nákladů a rizik.
Aby vlastníci produktů mohli reagovat na tento bod, je jim doporučováno, aby si vytvořili úvodní prezentaci pro nejvyšší management a poté tento materiál aktualizovali vždy při uzavírání každého sprintu se zpětnou účinností. Prezentace pro výbory a nejvyšší management by neměly být událostí, ale spíše dodávkou současného stavu a projekcemi stavu budoucího.
6. Zodpovědnost a výkon dodavatelů
V agilních projektech je složitější definovat sdílení rizik mezi společností a dodavatelem. Kontrakty na programy velkého měřítka má zpravidla model vodopádu či založený na doručitelnosti (deliverable-based), kde výkon nákladů a harmonogramu řídí pokuty či pobídkové odměny, díky čemuž jsou dodavatelé zodpovědní za dodávku v plném rozsahu. Naopak agilita vyžaduje fixní náklady a čas, zatímco rozsah je proměnný. Tato situace jde přímo proti standardnímu předpokladu, že velká část rozsahu ERP není flexibilní. Jednou z oblastí, kterou tohle komplikuje, je definice a řešení konceptu podpory záruky. Tohle je další důvod, proč musí mít každý v rámci projektu, jak na straně klienta, tak dodavatele, stejnou definici pojmu „hotovo“ pro každý sprint.
V posledních letech se objevily nové smluvní struktury, které jsou zaměřeny na tuto definici pojmu „hotovo“ s využitím pobídek a pokut v rámci dodávky této specifické definice. Týmy, které zvažují využití agilního přístupu ve velkém měřítku pro řešení ERP projektů, by v této oblasti měly vyhledávat experty, od kterých se těmto novým strukturám naučí.
PŘEDPLATNÉ
ČLÁNKY DO MAILU