facebook
Exkluzivní partner sekce
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
Navisys
IT SYSTEMS 11/2010 , ERP systémy

Rizika při vývoji podnikového softwaru



Během implementace velkých podnikových softwarových systémů se často vyskytují nejrůznější problémy. Informační systém vyvíjený na míru podle konkrétních požadavků zadavatele pravděpodobně bude trpět dětskými nemocemi. S tímto faktem je nutné počítat a připravit se na různá rizika. Podcenění rizik může zapříčinit, že výsledný produkt nepřinese kýženou hodnotu vzhledem k vynaloženým prostředkům. Proto je nutné vnímat rizika se zvýšenou pozorností především v dnešní době, která klade důraz na snížení nákladů.


Je důležité si uvědomit, že existuje velký rozdíl při nasazení hotového krabicového softwaru oproti podnikovému řešení, které je tvořeno na míru podle požadavků zadavatele. Krabicový software je testován velkým počtem uživatelů, kteří vytváří dlouhodobou zpětnou vazbu. Díky této zpětné vazbě výrobce postupně produkt vylepšuje. Takový produkt je otestován časem. Oproti tomu podnikový software bývá krokem do neznáma. I když se obvykle řeší podobné problémy, nakonec nikdy neexistují stejná řešení.
Různorodé požadavky zadavatele přinášejí různorodé problémy. Je to podobné, jako když se podle přání investora navrhuje a staví dům. První důležitý krok je stanovení účelu stavby. Přijde na řadu architekt, který musí správně pochopit potřeby zadavatele a přetransformovat je na konkrétní požadavky na stavitele. Dále je nutné vhodně zvolit stavební materiál, dobře položit základy, postavit správně obvodové zdi, zajistit kvalitní střechu. Každá jednotlivá činnost je důležitá, každé opomenutí v kvalitě provedení jednotlivých částí komplikuje celkovou stavbu. Nejenže jednotlivá klopýtnutí ohrožují obvykle napjatý rozpočet, ale v případě kumulace problémů může dojít k tomu, že výsledek vůbec neodpovídá tomu, co jsme původně chtěli.
Při vývoji softwaru dochází k podobným rizikům. Nejdůležitější částí projektu je stanovení požadavků na software, a to především schopnost odlišit důležité požadavky od těch méně významných, nebo dokonce zcela nepodstatných. Zdá se, že stejně jako v ekonomii zde platí Paretovo pravidlo 80/20 – v tomto případě dvacet procent požadavků, které definuje zadavatel, je tak důležitých, že pokryjí osmdesát procent skutečných potřeb. Jde především o nalezení těchto kritických požadavků a přiřazení odpovídajících priorit. V případě existence problémů, ať už časových nebo rozpočtových, se zaměřit především na prioritní požadavky a nerozptylovat energii na něco, co ve skutečnosti není důležité. Jinak hrozí zvýšení nákladů kvůli realizaci nepotřebných funkcionalit, nebo snížení kvality v důležitých částech systému. V nejhorším případě oboje zároveň.
Obtížnou částí vývoje softwaru je převedení problému z reálného světa do domény informačních technologií. Častou chybou je snaha o otrockou migraci stávajících postupů a procesů do nového informačního systému. Tento postup obvykle vede k zbytečnému zesložitění a byrokratizaci procesu. Co dobře funguje v reálném světě, nemusí dobře fungovat (a obvykle také nefunguje) ve světě IT. V reálném světě neexistují zásadní omezení, a pokud proces definovaný směrnicí nefunguje, je možné ho modifikovat ad hoc rozhodnutím konkrétního pracovníka. Ve světě IT ale tato ad hoc řešení nemusí být vůbec k dispozici. Například poznámku, která se obvykle píše na formuláři pod čarou, teď v novém systému nelze do žádné kolonky zapsat, dokument omylem poslaný kolegovi, který je nyní na dovolené, již nelze získat zpět pro důležitou korekturu a podobně. Je tedy nutné projít veškeré procesy a rozhodnout se, které ponechat, které od základu změnit a které do informačního systému vůbec nepřevádět. V případě nesprávné migrace procesů může dojít k tomu, že míra byrokratizace systému překročí únosnou mez a vysněný systém nakonec přinese více nových problémů, než kolik původně řešil.
Další kapitolou je nalezení vhodné platformy a technologie. Tady dodavatel samozřejmě protlačuje svoje řešení, které může, ale nemusí být v souladu se skutečnými potřebami zákazníka. Výběr technologie je důležitý pro budoucí rozšíření a kompatibilitu s aplikacemi třetích stran. S tímto také souvisí požadavek na určitou nezávislost na dodavateli softwaru. Neexistence alespoň hypotetické možnosti odejít v budoucnu ke konkurenci zvyšuje samozřejmě provozní náklady a zdražuje případné budoucí požadavky na rozšíření.
Důležitou částí je testování výsledné aplikace. Nejde jen o běžné vyzkoušení základní požadované funkcionality, ale o širší zodpovězení otázek typu „co se stane, když“. Například co se stane při větší zátěži (se systémem pracuje větší množství uživatelů než obvykle), při neoprávněném přístupu, při nestandardním úkonu uživatele a podobně. Při nedostatečném otestování aplikace hrozí akceptace nekvalitního řešení. Následně skryté kritické chyby mohou později dokonce poškodit provozní data, a problém nakonec může eskalovat mimo firemní prostředí.
Výše zmíněná rizika mohou neplánovitě navýšit celkové náklady na softwarový systém. Kromě nákladů, které jsou vidět – základní vývoj a implementace softwaru –, existují také náklady, které běžně vidět v tomto kontextu nejsou. Jsou to náklady související s:

  • neefektivitou pracovních postupů uživatelů systému,
  • administrací systému,
  • řešením havarijních situací systému,
  • budoucím rozšířením – novými požadavky na software,
  • integrací s jinými systémy.

Je vidět, že vývoj, implementace a provoz podnikových systémů je komplexní proces, který přináší určitá rizika, ať už projektová, technická nebo obchodní. Zkušený dodavatel může těmto rizikům předcházet, nicméně ne vždy se zájmy dodavatele kryjí se zájmy zadavatele. Navíc může být obtížné kvalitního a zkušeného dodavatele vůbec najít.
Východiskem v této situaci může být existence nezávislého pohledu třetí strany. Podobně jako může být ohrožena stavba bez kvalitního stavebního dozoru, implementace složitých softwarových řešení může být velmi riziková bez nezávislého softwarového dozoru. Softwarový dozor stojí na straně zadavatele a jeho úkolem je především:

  • analýza a detekce důležitých prioritních požadavků,
  • korekce nerealistických přání a vizí,
  • rozeznání, analýza, plánování a monitorování rizik,
  • kontrola technické realizace,
  • kontrola testování,
  • kontrola produkčního prostředí.

Softwarový dozor by měl provádět odborník s kvalitním vzděláním a dlouholetou praktickou zkušeností v oboru implementace podnikových řešení. Ať už zadavatel využije služby softwarového dozoru, či nikoliv, je nutné věnovat dostatečný čas především přípravné analytické fázi, kdy se dávají dohromady klíčové požadavky a technologie. I na drobné chyby v této fázi se mohou postupně nabalovat jiné problémy a v konečném důsledku degradovat výsledný produkt, kdy vynaložené náklady neodpovídají očekávaným výsledkům.

Roman Bouchner

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Význam automatizace a digitalizace v post-pandemickém světě

IT Systems 6/2020V aktuálním vydání IT Systems se věnujeme především roli digitálních technologií v post-pandemickém světě. Zatímco se život postupně vrací do normálu, podniky se musí pustit do sanace škod a začít revitalizovat své provozy a procesy. Pandemie připravila pro mnohé firmy intenzivní zatěžkávací zkoušku. Současně ale jasně ukázala, čemu by podniky měly věnovat pozornost, aby svou provozuschopnost zabezpečily i do budoucnosti.