Analýza

Přestože zadání bývá často detailní, často s sebou nese chyby, které se nepodařilo zákazníkovi správně vyspecifikovat. Proto většinou probíhá analýza, která v lepším případě jen potvrzuje věcné zadání. Problémem je snaha o rychlé schválení analýzy, která není podrobena dostačující oponentuře. Dalším momentem je oboustranná akceptace obsahu analýzy, která pak musí být závazná pro dané plnění implementace Informačního systému. Dále jsou sepsány typické problémy spojené s plněním analýzy:

1. Nedůslednost při realizaci analýzy – hrozí předělávání a nejednoznačnost při vymáhání dodání díla (termíny, sankce apod.),
2. Neseznámení všech zainteresovaných s finální podobou analýzy,
3. Snaha dodavatele obcházet věcné zadání náhradním řešením, která již má hotové,
4. Snaha zmenšit plnění původně sjednané v zadání výběrového řízení,

Nepřesnost a nepochopení problematiky dodavatelem - hrozí předělávání a nejednoznačnost při vymáhání dodání díla (termíny, sankce apod.),apod.

Implementace

V rámci implementace často dochází k pomalému náběhu realizace, podhodnocení termínů plnění pak vede k dodělávání řešení v období testů a školení, kdy již by mělo vše správně a úplně fungovat. Mezi typické problémy patří:

1. Podcenění termínů,
2. Nedostatečná projektová dokumentace (podepsané zápisy, předávací protokoly, pozdní eskalace chyb/nesoučinnosti apod.)
3. Chybná implementace zadání v analýze,
4. Nedostatečné ověření funkčnosti před implementací u zákazníka,
5. Vznik nových chyb opravou jiných chyb – nekvalitní vývoj,

Chybějící testovací scénáře, automaty ověřující funkcionalitu apod.

Testy

Testy bývají typickou podceňovanou skupinou činností, které se z důvodu nestíhání termínů implementace často obcházejí či vynechávají. Je nutné pamatovat zejména na:

1. Funkční testy,
2. Bezpečnostní testy,
3. Zátěžové testy,
4. Integrační testy,
5. Křížové testy pro případ funkční integrace do jiné aplikace apod.

Školení

Školení uživatelů na nové aplikace, zejména proprietární aplikace je často podceňovaná oblast. Dále platí, že školení je třeba několikrát opakovat a zejména je třeba u rozsáhlé aplikace opakovat školení několikrát do roka. Vlastní reakce uživatelů a nepochopení funkcionality aplikace na první okamžik je výbornou zpětnou vazbou na ergonomickou optimalizaci aplikace (pokud je možná). Postupem času se ověřil mechanismus školení tzv. klíčových uživatelů, kteří jsou zástupci jednotlivých oddělení zákazníka a jsou vlastně nejvíc proškolení a znalí uživatelé aplikace. Tito klíčoví uživatelé pak pomáhají na každodenní bázi jednotlivým koncovým uživatelům při práci s novou aplikací či při zpracování činností, které koncový uživatel dělá jen jednou za čas.
Vedle vlastních školení je vhodné realizovat informační semináře, vytvářet tipy a triky, vytvářet obrázkovou dokumentaci a případně nasadit e-learningové kurzy.

Pro vlastní školení je vhodné aplikovat tyto pravidla:

1. Nedělat školení delší než 5 hodin,
2. Nedělat školení pokud uživatel nemůže do týdne zkoušet proškolenou problematiku,
3. Neopakovat školení častěji než 1 x za měsíc,
4. Nabízet testovací verzi aplikace s minimálně týdenním předstihem včetně zaslání obrázkové dokumentace.

Předávání

Pro vlastní předávání je důležité specifikovat jednotlivé etapy ve smyslu stavu aplikace a tyto stavy mít vázaný na definici smlouvy a souvisejícího placení za jednotlivé etapy. Jednotlivé etapy lze eventuelně determinovat na úroveň modulů aplikace, to jen ale komplikuje situaci při orientaci v problematice rozpracovaného stavu aplikace. V praxi se osvědčily tyto stavy aplikace pojmenované etapami:

• Etapa Analýza - stav definice analýzy a akceptace analýzy,
• Etapa Implementace - stav vývoje aplikace a akceptace správnosti implementované funkcionality,
• Etapa Testování - stav testování aplikace na zkušebních datech a akceptace správné manipulace se zkušebními daty včetně správné hodnoty zkušebních dat,
• Etapa Pilotní provoz - stav provozu aplikace s ostrými daty a akceptace správné funkčnosti aplikace s ostrými daty včetně jejich dosahovaných hodnot s možností vrácení se do Testovací etapy,
• Etapa Rutiní provoz - stav ostrého provozu s ostrými dat po ověřovacím pilotním provozu, nyní se jen udržuje aplikace v korektním ostrém provozu.

Výše uvedený postup se dá samozřejmě aplikovat i jen na dílčí změny/dodávky/úpravy již nasazené aplikace.

Záruka

Záruční podmínky Informačních systémů bývají často realizovány prostřednictvím servisních smluv a případných smluvně definovaných podmínek odstranění chyb, definice termínu odstranění a případné definice sankcí pro případ nedodržení termínů odstranění chyb. Tyto smluvní podmínky jsou vlastně podobné SLA parametrům servisních smluv.

Chyby se často člení dle charakteru chyby na:

• Chybu kritickou - nelze pracovat
• Chybu vážnou - chyba významně omezuje funkci aplikace, ale základní činnosti fungují
• Chybu nízkou - jedná se o drobnou chybu, která nepřekáží ve výkonu činností prostřednictvím aplikace

K těmto charakterům chyb se pak definují různé časy na reakci a odstranění chyby a procentuální úspěšnost řešení chyb v rámci sledovaného období. Vyhodnocením sledovaného období lze vypočíst případné sankce, které vyplývají z porušení termínů či nedodržení procentuální úspěšnosti odstraňování chyb. Konkrétní model aplikování záručních podmínek závisí na potřebách zákazníka či možností garancí dodavatele.

Servis

Servisní podmínky údržby a provozu informačních systémů jsou obdobné popisu záručních podmínek uvedených v předchozí kapitole. Jako příklad takových podmínek je možné uvést následující soustavu parametrů:

Máte-li zájem o bližší informace, rádi Vám je poskytneme elektronickou formou nebo v rámci osobního setkání viz. záložka s kontaktními údaji.