Jak si poradit se správou releasů

Ve větších firmách je implementace ERP systému kontinuální proces. Systém zkrátka roste a rozvíjí se spolu s firmou a jejími potřebami. Aby to bylo možné, musí k tomu existovat i nezbytně nutné podpůrné procesy, které IT oddělení posunou do role proaktivního katalyzátoru strategických změn ve firmě. A k tomu je samozřejmě nezbytné umět pracovat s tzv. releasy podnikového informačního systému. Jak na to?

Co to je release

Pokud ve firmě využíváte Office 365 nebo třeba i obyčejné Windows, releasy velmi dobře znáte. Co měsíc přibudou nějaké aktualizace, které obvykle z pohledu uživatele jakoby nic nemění, ale čas od času přibude i taková aktualizace, která přidá novou funkci, změní vzhled či propojení aplikací mezi sebou a podobně. Děje se tak ve formě releasů, což se do češtiny nejčastěji v IT překládá jako „sestavení“.

S podnikovým informačním systémem je to vlastně stejné. I po jeho ostrém startu se obvykle objeví řada věcí, které by se daly zlepšit. Část z nich se týká backendu, tedy zjednodušeně řečeno částí systému, s nimiž uživatel sice nepřijde do styku, ale které mají významný dopad třeba na výpočetní výkon či pravidelné exporty a importy dat z jiných systémů. Tyto úpravy ani nutnost jejich provedení běžný uživatel nevnímá, ale pro IT oddělení jsou obvykle naprosto zřejmé a zásadní, protože ovlivňují funkčnost systému jako celku. Část úprav se týká frontendu neboli toho, s čím uživatel přichází pravidelně do styku, ať už ve formě uživatelského rozhraní, nebo ve formě například jednotlivých workflow, posloupností úkonů. V případě podnikových informačních systémů pak existuje ještě třetí část úprav, jež se týká přidávání zcela nových funkcionalit – například pokrytí nových agend, oddělení, dceřiných firem apod., kdy je nutné provést úpravy jak v backendu, tak ve frontendu, ale často i ve způsobu samotného fungování firmy.

Jednotlivé releasy slouží k tomu, aby stejně jako u Windows či Office 365 definovaly, které konkrétní změny se v kterém konkrétním releasu provedou. A protože se obvykle i v menších firmách stanovuje přesné datum, kdy daný release vychází (např. začátkem každého kvartálu), je zároveň dopředu známo, ke kterému datu bude podnikový informační systém jak fungovat.

Proč jsou releasy důležité

Možná se teď ptáte, k čemu je to vlastně dobré a proč se systém neupravuje prostě průběžně, ad hoc, podle toho, co je zkrátka zrovna potřeba. Problém je v tom, že úpravy podnikového informačního systému, pokud se nejedná čistě o backend, se bytostně dotýkají uživatelů a způsobu, jakým se systémem pracují (u úprav frontendu), nebo kompletně fungování celých oddělení či firmy, a to třeba i ve vztahu k zákazníkům a obchodním partnerům. Právě proto je důležité jednotlivé změny postupně plánovat, a hlavně koordinovat s dalšími částmi firmy.

Také u releasů, podobně jako u implementace samotné, platí, že se běžně stává, že kromě plánovaných aktivit se mohou objevit ad hoc úkoly, nejčastěji v podobě nutnosti provedených úprav. Proto je vhodné mít i v rámci jednotlivých releasů nastaveny priority úkolů na ty, které nutně musí být provedeny v daném releasu (typicky aktivity s dopadem na zákazníky, obchodní partnery, implementaci změn v legislativě či ovlivňující velkou část firmy), a ty, které mohou být odloženy. Také se vyplatí plánovat si zhruba jen 80 % kapacit, aby vždy byl prostor právě na tyto úpravy.

Proč se vyplatí udržovat si implementační tým

Právě kontinuální změny a někdy i opakované odkládání méně zásadních úprav systému jsou velmi dobrý důvod, proč se vyplatí po ostrém startu i nadále udržovat fungující a pravidelně se scházející implementační tým. Výběr implementačního týmu – ať už té části ve firmě, nebo té u implementačního partnera – je klíčový faktor úspěchu libovolné implementace ERP systému. Právě proto, že ve větších firmách proces implementace vlastně nikdy nekončí, je důležité, aby mezilidské vztahy v rámci týmu byly na dobré a upřímné úrovni a aby tým fungoval jako celek. Navíc jednotliví klíčoví uživatelé by měli být „evangelizátory“ plánovaných změn na svých pracovištích, tedy by je měli nejen umět vysvětlit a obhájit, ale také pomoci s jejich faktickou implementací. To, že nějaká funkce přibude v systému, totiž bohužel neznamená, že se uskuteční změna, kterou má do firmy ve skutečnosti přinést. To je právě úkol těchto klíčových uživatelů.

Tím spíš by však firmy měly myslet na to, že účast v implementačním týmu zabere část pracovní doby, pokud má klíčový uživatel odvádět dobrou práci. Samozřejmě, u kontinuálních implementací, kdy se podnikový informační systém rozvíjí de facto neustále od jedné implementace až k té následující, je také běžné, že se členové implementačního týmu mění. Odchod zaměstnance z tohoto týmu z firmy by tak měl být řádně ošetřen. V takovém případě bývá často vhodnější do implementačního týmu jmenovat za vypadlého klíčového uživatele některého ze stávajících zaměstnanců, protože zaměstnanec, který přichází do firmy nově, se musí se všemi procesy teprve seznámit.

Releasy a agilní vývoj

V současné době existují v IT dva hlavní směry projektového řízení vývoje softwaru, včetně přípravy releasů podnikového IS: tradiční tzv. waterfall a modernější agilní přístup. Z pohledu plánování releasů však mezi nimi není až tak zásadní odlišnost. Tradiční waterfall je svým přístupem vhodný spíše pro implementaci větších množství změn v méně pravidelných intervalech (typicky jednou za tři až šest měsíců), zatímco agilní projektové řízení umožňuje rychlou implementaci malých změn s releasy třeba jednou za měsíc, někdy i méně (kromě vývoje je potřeba dbát také na otestování). To je vhodné zejména pro rychlé implementace změn v backendu a v dílčích případech i malých změn ve frontendu. Při implementaci systémových změn je však oním „úzkým hrdlem“ obvykle zcela jiná část firmy než IT, takže způsob řízení softwarového vývoje až takovou roli z pohledu firmy nehraje.

Systém by měl umět růst s firmou

Možná si teď říkáte, že celý tento systém je vlastně příliš složitý a určitě jsou s ním spojeny i někdy nemalé časové a finanční náklady. Jenže pokud k němu přistoupíte, změníte svůj podnikový informační systém v opravdový flexibilní pracovní nástroj, v něco, co proaktivně podporuje firmu v jejím rozvoji a růstu a umožňuje jí maximálně využívat svého inovačního potenciálu.

Není to tedy ani tak o procesním pohledu na IT, jako o tom strategickém – změnit IT ve firmě v součást byznysu, v něco, co už není jen nákladovým střediskem v účetním slova smyslu, ale něčím, co ve firmě generuje reálnou přidanou hodnotu pro všechna oddělení a také pro zákazníky i obchodní partnery. A pokud chcete mít firmu, která je flexibilní a roste, musíte mít takový podnikový informační systém. A samotný cloud, například ve formě naší služby Erport, jež umožňuje jen flexibilní škálování výkonu, vám k tomu stačit nebude. K tomu už je potřeba změna myšlení a někdy také vnímání podnikového informačního systému, třeba jako nového parťáka. A mimochodem, třeba nový HELIOS Orange přesně takový umí být a nejlépe toho dosáhne právě ve firmách, které svůj systém průběžně rozvíjejí.