Kritické faktory úspěchu a rizika informačních systémů

Prof. Ing. Jiří Voříšek, CSc.

katedra informačních technologií

VŠE Praha

E-mail: vorisek@vse.cz

publikováno: listopad 1996

 

Abstrakt: Článek analyzuje kritické faktory úspěchu a rizika současných informačních systémů a informačních technologií (IS/IT). Analýza zahrnuje informatické projekty realizované v posledních letech jak v České republice, tak v zahraničí. Cílem analýzy je napomoci podnikovému managementu v plánování přínosů IS/IT a v odhadování rizik informatických projektů.

Klíčová slova: informační systém, informační technologie, kritické faktory úspěchu, podniková strategie, informační strategie, přínosy a rizika IS/IT

 

Informační systémy a informační technologie jsou sice velmi významným faktorem hospodářského prostředí, ale pozitivní efekt nepřinášejí zcela automaticky. Naopak řada informatických projektů skončila neúspěšně a přinesla jejich investorům nemalé ztráty. Strassman v [STS85] dokonce tvrdí: “Historie IS/IT může být charakterizována jako přeceňování toho, co může být dosaženo rychle, a nedoceňování dlouhodobých vlivů IS/IT.” Podobnou notou mu přizvukuje jeden americký bankéř, který tvrdí, že informatizace bankovního sektoru v 70. a 80. letech byla nejpromyšlenější bankovní loupeží století.

Je-li nasazování IS/IT často spojeno s řadou rizik, je jistě užitečné analyzovat problémy a neúspěchy tuzemských i zahraničních projektů. Cílem této analýzy není pouze snaha o poučení z chyb našich předchůdců, ale také snaha ukázat příčiny, které si vynutily vznik a rozvoj strategického řízení IS/IT a systémové integrace. Vycházíme přitom z projektů řešených v poslední době v České republice, ale i ze zahraničních zdrojů (zejména z [ANG91], [MCN89], [DON94] [BAL95]). Zahraniční zkušenosti a příklady pokládáme za významné vzhledem k jejich příbuznosti s obdobně zakládanými projekty v ČR a současně vzhledem k postupnému propojování našich IS/IT se zahraničními (v rámci společných podniků, nadnárodních společností, mezinárodních organizací apod.).

  1. Chybně postavená globální podniková strategie
  2. Je-li globální podniková strategie chybně postavena, nelze ani od IS/IT očekávat přínosy. Je-li informační systém v této situaci orientován na maximální podporu podnikové strategie, může dokonce urychlit ekonomický pád firmy.

    Pro současné hospodářské prostředí je typické, že dříve úspěšné podnikové strategie, opírající se výlučně o jeden z následujících principů, již přestávají být úspěšné:

    Podle Donovana [DON94] je společnou slabinou těchto strategií (jsou-li používány dlouhodobě jako hlavní podniková strategie) jejich průhlednost, statičnost a relativně snadná dosažitelnost i konkurencí. Tyto strategie mohou být úspěšně využívány pouze krátkodobě. Jejich dlouhodobé opakované použití vede k tomu, že konkurence snadno odhadne budoucí chování svého konkurenta a může připravit své protitahy.

    Tak např. společnost Pan Am tak dlouho prodávala své profitující linky, aby udržela ty ostatní, až definitivně zkrachovala. Společnost Marlboro se tak dlouho spoléhala na to, že síla jejich značky udrží vysoké ceny jejich cigaret, až v r. 1993 díky tlaku konkurence musela ceny snížit. Toho dne celková cena akcií "značkové firmy" na New Yorské burze klesla o 50 mld. dolarů.

    Příklady výše uvedených chyb můžeme najít i mezi firmami orientovanými na informační technologie v ČR. Řada z nich založila svou existenci výhradně na obchodním rozpětí, které získávají při nákupu a prodeji hardwarových a softwarových komponent. Celosvětovým trendem zde je neustálý pokles cen těchto komponent, a tím i pokles výnosu z obchodního rozpětí. Aby se tyto firmy udržely na trhu, jsou nuceny snižovat mzdové náklady a náklady na personální rozvoj, což má za důsledek pokles úrovně služeb a odliv nejlepších pracovníků. Dlouhodobě pak značné existenční problémy firmy. Podstatně lepší strategií je neustálý rozvoj nových služeb.

    Společnou vlastností dlouhodobě úspěšných strategií je permanentní zvyšování užitné hodnoty produktu nebo služby pro zákazníka. Jinými slovy podniková strategie se musí neustále rozvíjet. Její fixace na 3 až 5 let (jak bylo zahraničními autory i námi v minulosti doporučováno) je v současné době předplatné do klubu neúspěšných.

     

    chybstra.jpg (111084 bytes)

    Obr. A: Příklad možných důsledků nevhodně zvolené podnikatelské strategie

     

  3. IS nerespektuje vlastnické a organizační změny v podniku
  4. Vlastnické a organizační změny jsou typické pro celou řadu podniků, které procházejí transformačním procesem. Zásadně inovovat informační systém v podniku s nevyjasněnými vlastnickými vztahy, v podniku s destabilizovanou vnitřní organizací, v podniku s probíhajícími výraznými změnami v centralizaci nebo decentralizaci řízení divizí, úseků apod. je značně problematické a rizikové. Změny tohoto charakteru obvykle vedou i k zásadním změnám požadavků na IS/IT (změna cílů IS/IT, změna funkcí IS, změna pravomocí a zodpovědností, změna distribuce hardware, funkcí a dat, apod.). Stane-li se např. novým vlastníkem podniku nadnárodní organizace, je velmi pravděpodobné, že bude vyžadovat, aby IS/IT byl kompatibilní po funkční i technologické stránce s IS/IT celé organizace.

    Očekávají-li se v podniku změny výše uvedeného charakteru, je vhodnější odložit zásadní inovaci IS/IT až na dobu po vyjasnění změn. Je-li nezbytné inovovat IS/IT i před těmito změnami, pak musí řešení obsahovat takové stupně volnosti (např. pomocí zabudované parametrizace, stavebnicovosti), které umožní akceptovat i budoucí změny. Je však nutné počítat s tím, že uvedené charakteristiky inovaci IS/IT zkomplikují a prodraží.

  5. Podcenění významu IS/IT pro zajištění konkurenceschopnosti podniku
  6. Vrcholové vedení některých podniků a dokonce i pracovníci některých poradenských firem nedoceňují význam IS/IT pro řízení podniku a pro pozici podniku na trhu a investice do IS/IT považují za druhořadé, resp. za přepych. Názornou ilustrací je následující příklad z české praxe.

    Vedoucí pracovníci nově konstituovaného průmyslového podniku si na pomoc při formulování rozvojové strategie najali poradenskou firmu. Její pracovníci pomohli vypracovat marketingový, výrobní a finanční plány na cca čtyři roky. Součástí těchto plánů bylo i doporučení investovat do IS/IT až po tom, co se firma stabilizuje na trhu a splatí úvěr poskytnutý bankou na zakoupení podniku, tj. cca za čtyři roky.

    Je samozřejmé, že nelze význam IS/IT přeceňovat a vidět v něm jediný a nejdůležitější faktor prosperity podniku. Na druhé straně je chybou i podceňování významu IS/IT tak, jak se tomu stalo v uvedeném příkladě. Vhodnou cestou je vyvážené řešení, kdy IS/IT jsou navrhovány konzistentně spolu s dalšími dimenzemi podnikové strategie. Kvalitní informační systém není přepych, který si může dovolit pouze špičkový podnik, ale je to jeden z účinných nástrojů řízení podniku na strategické, taktické i operativní úrovni. S podporou IS/IT lze lépe stanovit a vyhodnotit varianty rozvoje podniku, lze rychleji a kvalitněji vyhodnocovat stupeň naplňování podnikových cílů a lze snadněji realizovat operativní podnikové procesy.

    Jak např. může management podniku dobře rozhodnout o tom, které výrobky jsou pro podnik výhodné a které ne, když v podniku neexistuje kvalitní, informačním systémem podporované, sledování rentability jednotlivých výrobků a většina vnitropodnikových nákladů je zahrnována do celopodnikové režie? Jak mohou efektivně pracovat obchodní cestující firmy, kteří nemohou pomocí informačního systému přímo u zákazníka zjistit, kdy může být požadované zboží v požadovaném množství dodáno?

  7. Malá angažovanost vrcholového vedení při inovaci IS/IT
  8. Nedoceňování role IS/IT se v řadě podniků projevuje i malou angažovaností vrcholového vedení při inovaci IS/IT. Poměrně často se stává, že vrcholové vedení považuje implementaci nového IS/IT za výhradní záležitost odborníků na informatiku. Klasickým projevem této chyby je prohlášení ředitele podniku: “Tak nám hoši ten IS zaveďte, máte naši plnou důvěru, my nejsme odborníci, tak se Vám do Vaší práce plést nebudeme”.

    Zásadní inovace IS/IT je vždy v podniku provázena změnou pracovních postupů, změnou zodpovědností a pravomocí, často vede i ke změnám hodnotového systému a podnikové kultury. Realizovat tyto změny bez aktivního zapojení vrcholového vedení je nereálné. Členové vrcholového managementu přitom nemusejí mít hluboké znalosti o IS/IT. Měli by však vědět, jak mohou současné informační technologie přispět k dosažení celopodnikových cílů, neboť rolí vrcholového vedení je definovat požadované změny, vytvořit podmínky pro jejich dosažení a změny v podniku prosadit. Pracovníkům podniku na všech stupních musí být jasné, že nepochopí-li a neakceptují-li zaváděné změny, nebude v podniku pro ně nadále místo.

    Roli vrcholového vedení při zavádění nového IS/IT dobře dokumentuje následující příklad. Před několika lety jsme zaváděli nový IS/IT ve velké obchodní organizaci. Cílem automatizace bylo mj. vytvářet všechny obchodní dokumenty (objednávky, kontrakty, faktury apod.) automatizovaně tak, aby bylo možné okamžitě posuzovat vliv obchodního případu na ekonomiku podniku. Před zahájením zkušebního provozu jsme zahájili školení téměř všech pracovníků podniku. Když jsme v jedné obchodní skupině popsali jaká bude náplň práce obchodního referenta, povstal jeden mladý obchodník a prohlásil: “Pánové, já jsem obchodník a ne obsluha počítače. Jestli chcete, abyste měli ve vašem počítači i moje kontrakty, dodejte mi pracovní sílu, která moje kontrakty bude opisovat do počítače.” Toto prohlášení rozdělilo obchodní skupinu na dva tábory. Bylo jasné, že když se obchodníci přikloní na stranu řečníka, nebude možné inovovaný informační systém v podniku zavést. Také bylo jasné, že informatici neměli pravomoc nařídit obchodníkům, jak postupovat. Po chvilce mlčení povstal ředitel obchodní skupiny a směrem ke svému obchodnímu referentu řekl: “Jestli tu práci dělat nechceš, tak nemusíš. Já ji budu dělat za tebe. Ale v tom případě tě tady nepotřebuji.” Toto jediné prohlášení znamenalo zlom v přístupu celé obchodní skupiny k automatizaci. Mohl ji však pronést právě jen ředitel, nikoliv informatici, kteří systém vyvinuli a zaváděli. Za zmínku stojí i fakt, že řediteli v té době bylo 62 let a onomu obchodníkovi 30. Řediteli však bylo jasné, že když nebude mít i nadále operativně k dispozici informace o všech uzavíraných obchodních případech, nebude mít možnost kvalitně řídit činnost obchodní skupiny. Přístup ředitele nejen zprůchodnil zavedení projektu, ale také napomohl ke změně podnikové kultury. Obchodníci postupně přestávali chápat počítače jako záležitost informatiků, ale jako svůj nástroj obchodní činnosti.

  9. Řízení IS/IT delegováno na příliš nízkou úroveň podnikové hierarchie
  10. Podcenění role IS/IT managementem některých podniků se projevuje také tím, že veškeré řízení IS/IT je delegováno až na druhou nebo dokonce třetí úroveň podnikové hierarchie. Tímto opatřením se téměř znemožní, aby IS/IT prioritně podporoval stěžejní celopodnikové cíle, aby strategické projekty byly řešeny s jim odpovídajícími prioritami a aby na projekty byly vyčleněny odpovídající finanční a pracovní kapacity.

    Patří-li informace a informační systém k rozhodujícím podnikovým zdrojům nemůže o tomto zdroji rozhodovat pracovník na úrovni vedoucího odboru nebo dokonce vedoucího oddělení. Pracovník na této úrovni jednak nebývá dostatečně seznámen s podnikovými cíli a jejich prioritami a jednak nemá dostatečné pravomoce k prosazení významných rozhodnutí. Na základě zkušeností z prosperujících firem lze doporučit dvě varianty řízení informatiky. První variantou je, že řízení informatiky je v kompetenci finančního ředitele podniku. V druhé variantě je pro řízení informatiky zřízeno specializované funkční místo - ředitel informatiky. Praxe zejména velkých firem se postupně přiklání k druhé variantě.

  11. Řízení IS/IT je odděleno od řízení organizačních záležitostí
  12. Provoz informačního systému úzce souvisí s organizační strukturou podniku a zodpovědnostmi a pravomocemi jednotlivých funkčních míst. Je proto chybou, když řízení IS/IT je odděleno od řízení organizačních záležitostí v podniku. Jak informatický útvar, tak organizační útvar by proto měly být podřízeny stejnému řídícímu pracovníkovi - existuje-li v podniku ředitel informatiky, pak jemu.

  13. BPR a/nebo zavádění ISO 9000 není koordinováno s rozvojem IS/IT
  14. V poslední době stále více podniků aplikuje BPR (Business Process Re-engineering) a normy kvality ISO 9000. Bohužel ne všechny podniky si uvědomují, že BPR, ISO 9000 a IS/IT spolu velmi úzce souvisejí. Svůj díl viny mají i informatici, kteří tvrdí, že BPR a ISO 9000 není jejich záležitostí, stejně tak jako někteří pracovníci poradenských firem specializovaných na zavádění ISO 9000, kteří nemají dostatečné znalosti o IS/IT.

    Obr. B Varianty vzájemného vztahu zavádění ASW a BPR

    Zavádí-li některý podnik ISO 9000 bez ohledu na vývoj IS/IT a vzápětí poté výrazně IS/IT inovuje, musí se připravit na to, že bude muset výrazně modifikovat dokumenty, které jsou s aplikací ISO 9000 spojeny, a že bude muset opakovat celou řadu školení, aby pracovníci pochopili nové pracovní postupy a jiné rozdělení pravomocí a zodpovědností.

    Podobně je tomu se vztahem IS/IT s BPR. Jestliže podnik optimalizuje svoje pracovní postupy bez ohledu na IS/IT, může se stát, že náklady na vynucené modifikace IS/IT převýší efekty, které BPR mělo přinést. S tímto problémem souvisí i otázka, kdy provádět BPR (viz obr. b) - před, v průběhu nebo po zavedení typového aplikačního software (TASW) ? Jestliže navrhneme BPR před a zcela nezávisle na TASW, je téměř jisté, že nenajdeme na trhu žádný TASW, který by plně respektoval nově uspořádané podnikové procesy. Chceme-li procesy zachovat, musíme výrazně modifikovat TASW nebo dokonce vyvinout ASW “šité na míru” navrženým procesům. To výrazně prodlouží a prodraží zavádění ASW. Vybereme-li naopak nejdříve TASW, pak naše úvahy o následném BPR budou omezovány možnostmi nakoupeného TASW. Nejvhodnější je proto varianta, ve které v prvním kroku zahájíme BPR a určíme v hrubých rysech podnikové procesy. V druhém kroku vybereme ten TASW, který nejlépe pokrývá navržené procesy. Ve třetím kroku pak dokončíme návrh procesů tak, abychom co nejlépe využili možnosti daného TASW.

  15. Zaměření IS primárně na partikulární zájmy útvarů a jejich operativní úkoly
  16. Jestliže budujeme IS/IT primárně podle požadavků jednotlivých útvarů podniku, pak je obvyklé, že funkce IS/IT neodpovídají primárním cílům organizace nebo jsou dokonce s nimi v protikladu. Tato chyba vzniká obvykle v podnicích, kde vrcholové vedení nevěnuje vývoji IS/IT dostatečnou pozornost nebo kde jediná úroveň řízení informatiky je operativní úroveň (neexistuje strategické řízení IS/IT). V těchto podnicích se prioritně řeší ty funkce IS/IT, které si vynutí silné podnikové útvary a jejich management. Způsob řešení těchto funkcí je navíc zcela podřízen zájmům pracovníků příslušného útvaru.

    To např. v obchodní organizaci může vést k situaci, že automatizace maximálně zjednodušuje a usnadňuje zpracování dokladů obchodního případu, ale na druhé straně neumožňuje posoudit výhodnost obchodního případu z hlediska obchodní strategie firmy (cenové, teritoriální apod.).

    Nejhorším důsledkem této chyby je, když IS funguje sice v souladu s požadavky útvarů podniku, ale proti celopodnikovým zájmům a cílům. Např. když automatizované vystavování platebních příkazů a vystavování penalizačních faktur není v souladu s novou finanční a zákaznickou politikou podniku.

  17. Informatický projekt je zaměřen na dodávku IT, nikoliv na "dodávku strategické výhody", resp. na podporu dosažení lepších služeb pro zákazníka
  18. Rostoucí investice do IS/IT jsou patrné u většiny podniků a organizací. Přínosy těchto investic však často nejsou adekvátní a vyvolávají spíše zklamání než nové naděje.

    Velké obchodní a průmyslové organizace investují i v ČR do IS/IT desítky milionů korun ročně přičemž vedení těchto podniků nedostává potřebné informace buď vůbec nebo s neúměrným zpožděním. Podobné platí i o institucích státní správy.

    Problémy však existují i v zahraničí. Např. britský Passport Office realizoval projekt za 7 milionů liber a dosáhl prodloužení vyřízení průměrného požadavku z 15 dnů na 2 měsíce. Britské ministerstvo zemědělství realizovalo projekt pro vyřizování exportních zakázek za 4 mil liber a dosáhlo prodloužení jedné zakázky z 28 dnů na 6 měsíců.

    Protože rozsáhlý informatický projekt je velmi komplexní záležitostí vyžadující mnoho finančních, materiálových i personálních zdrojů, stane se někdy tento projekt účelem sám o sobě. Přitom se zapomene, že IS/IT je pouze prostředek na dosažení podnikových cílů. Nejhorší situace nastává, když investice do IS/IT vycházejí primárně z úvah “jaký hardware do podniku pořídit?”.

    Každý projekt proto musí mít definovány přínosy, které sleduje, kdo za dosažení daného přínosu zodpovídá, a jaké podmínky musí být pro dosažení přínosu vytvořeny. Projekt pak nemůže být považován za dokončený a úspěšný poté, co byly instalovány potřebné hardwarové a softwarové komponenty a vyškoleni uživatelé, ale až poté, co se dostaví požadovaný přínos.

    Příkladem požadovaných přínosů dokončeného projektu mohou být:

    Aby projekt přinesl ekonomické přínosy, musí řídící komise projektu i vedoucí projektu uvažovat zejména v ekonomických a ne výhradně v technických kategoriích. Že tento problém není aktuální pouze pro situaci v ČR dokazuje i fakt, že v roce 1994 byla v Manchasteru výhradně na tento problém orientována celá mezinárodní konference. Potřebné směry úvah dobře dokumentují schémata na obr. d a obr. d, která vycházejí z vystoupení Warda na této konferenci [WAR94].

    obr. c znázorňuje, že změny IS/IT nesmějí být samoúčelné, ale musejí úzce vázat na požadované změny podnikových procesů. Na druhé straně změny v IS/IT zpětně ovlivňují podnikové procesy. Nejsou-li dopady změn IS/IT na změny podnikových procesů analyzovány a předem plánovány, projekt obvykle končí nezdarem spojeným s ekonomickými ztrátami. Má-li projekt neplánované efekty (ať pozitivní nebo negativní), je třeba tyto efekty zanalyzovat a závěrů využít pro obohacení know-how řešitelského týmu - viz obr. d.

    Obr. C:Vztah změn podnikových procesů a stavu IS/IT

     

    Ward-2.jpg (99977 bytes)

    Obr. D:Vztah předpovídatelnosti výsledku projektu a výsledného efektu

     

  19. Povrchní specifikace požadavků na IS
  20. Jedním z velmi častých rizik je chybná nebo neúplná specifikace výchozích požadavků na projekty. Podhodnocení tohoto problému vedením podniku a rozhodujícími uživateli vede často k vytvoření nebo nákupu funkčně neadekvátního IS.

    Toto riziko je typické i pro velké projekty státních institucí. Klasickým příkladem je informační systém NHS (National Health Service) ve Velké Británii, jehož neúspěch se stává téměř legendárním. Proti neúspěchu nebyl imunní ani IS ministerstva obrany USA. Průzkum projektů zadaných tímto ministerstvem přinesl zajímavá zjištění [BEW90]:

    1,5% projektů bylo použito tak, jak byly dodány,

    3% projektů bylo použito po modifikacích,

    29% projektů bylo použito a opuštěno,

    47,5% projektů rezultovalo v tzv. shelfware (software objednaný, dodaný, ale nikdy nepoužitý),

    29% projektů skončilo tzv. vapourware (software objednaný, často i zaplacený, ale nikdy nedodaný nebo dokonce nenapsaný).

    Vyhnout se uvedeným problémům předpokládá vyhotovit přesnou specifikaci funkcí každé požadované aplikace a současně požadavky na uživatelský interface a provozní charakteristiky (počet uživatelů, doba odezvy atd.).

  21. Budování IS/IT bez jednotné koncepce
  22. I když jsou jasně definovány cíle IS/IT i požadavky na jednotlivé aplikace, ale chybí jednotná koncepce tvorby a rozvoje IS/IT, důsledky mohou být také velmi nepříjemné:

    Souvisejícím problémem je řešení dílčích úloh samotnými uživateli pomocí jednoduchých databázových procesorů, tabulkových kalkulátorů apod. označované souhrnně jako EUC (End User Computing). To v sobě nese řadu rizik, a to nejen v často proklamované desintegraci systému, ale i v nebezpečí stále se zvyšujícího objemu neprofesionálně připravených a naprosto nezdokumentovaných aplikací, za něž nemá nikdo de facto odpovědnost, ale o nichž se pouze předpokládá, že se "nějak" provozují. Navíc nevhodně využívané EUC vede k tomu, že vysoce placení specialisté (manažeři, finančníci, technici) tráví svůj čas nedokonalým a pomalým programováním aplikací.

  23. Málo pružná informační strategie a nepružný IS/IT s nevhodnou architekturou
  24. Totéž, co platí o podnikové strategii platí pochopitelně i o informační strategii. Musí-li se podniková strategie neustále rozvíjet, musí její vývoj kopírovat i vývoj informační strategie (důsledky nesouladu podnikové a informační strategie byly již dříve hojně diskutovány, např. [CAS88], [ANG91], [VOR94]). Musí-li se informační strategie neustále vyvíjet, znamená to, že architektura IS/IT musí permanentní změny umožňovat. A zde je další příčina neúspěchů. Strnulá architektura IS/IT založená na klasických dříve osvědčených přístupech se stává brzdou rozvoje podnikových aktivit.

    Opomenutí na první pohled banální záležitosti má pak důsledky v nadbytečné složitosti systému, obtížné orientaci v jeho základních interních i externích vazbách, v zamlžování odhadů potřebných kapacit atd.

    Důsledky nedostatečné architektury jsou rovněž varující. Barclays Bank musela zastavit dva multimilionové projekty jen proto, že v důsledku špatné architektury byly tyto systémy natolik složité, že se staly dále neřešitelnými. V jiném případě americká letecká společnost TWA zjistila, že požadovaná integrace dalších aplikací ke stávajícímu IS je nerealizovatelná vlivem špatné architektury a systém se musí kompletně předělat.

    Chybnými přístupy při tvorbě architektury IS/IT jsou např.:

  25. Atomizovaná datová základna podniku
  26. Chybou architektury IS/IT je i atomizovaná datová základna podnikového informačního systému. Tato chyba se vyznačuje tím, že jednotlivé aplikace nesdílejí společnou datovou základnu, ale že každá aplikace pracuje nad svojí datovou základnou - viz obr. e. Jestliže aplikace nesdílejí společně ty údaje, které jsou potřebné v obou aplikacích, vede to nejen k duplicitnímu sběru dat (např. nový zákazník je vkládán jak v subsystému “odbyt”, tak v subsystému “účetnictví”), ale také k obtížnému zajištění konzistence datové základny (změní-li zákazník adresu, může se stát, že změna je promítnuta jen do jednoho subsystému, a pak není jasné, který ze dvou údajů je správný). Nejhorší důsledek atomizované datové základny je nejednoznačná identifikace objektů (např. tentýž zákazník je identifikován jinak v odbytu a jinak v účetnictví).

    Obr.E: Oddělené datová základny jednotlivých aplikací

     

    Stane-li se taková situace např. v bankovním informačním systému, kde jednotlivé aplikace IS/IT jsou vytvořeny pro jednotlivé bankovní produkty (běžné účty, úvěry, stavební spoření apod.), pak je pro banku téměř nemožné zjistit souhrnné informace o klientovi, který využívá více produktů. Nejde tedy pouze o chybu technologickou, ale o chybu, která může vážně ohrozit ekonomické výsledky banky - např. klientovi, který nesplácí úvěr banka umožní vysoký kontokorent na běžném účtu.

    Stane-li se taková situace v obchodní organizaci rozdělené na několik prodejních závodů, které prodávají stejné komodity, ale v jiných teritoriích, může snadno nastat situace, kdy tatáž komodita je jinak identifikována v každém závodě. Potom vrcholové vedení nemá možnost zjistit celkový odbyt jednotlivých komodit za celý podnik. Výsledkem jsou obchodní rozhodnutí činěná z nesprávných podkladových materiálů.

  27. Neuvažuje se stav znalostí lidí a rozsah změn před zavedením nového IS/IT
  28. Při navrhování a zavádění IS/IT je třeba brát v úvahu dosavadní znalosti a zkušenosti pracovníků podniku. Metody velkých skoků a velkých třesků jsou velmi riskantní. Zavádět např. současně několik aplikací, které v zásadě mění způsob práce uživatelů a vyžadují od nich nové vědomosti a návyky, může znamenat neúspěch, i když aplikace jsou navrženy dobře.

    Vyžaduje-li situace zavádění rozsáhlých změn, které se dotknou většiny zaměstnanců podniku, je třeba věnovat přípravě zavedení projektu a zejména školení uživatelů mimořádnou pozornost. Vlastní zavedení projektu pak musí být velmi rychlé, aby se minimalizovala doba, kdy v podniku vedle sebe existují staré i nové postupy a doklady.

  29. Nedůsledné řízení projektu
  30. Kvalitní řízení projektu je dalším kritickým faktorem úspěchu IS/IT. Aby manažer projektu dovedl projekt do vítězného konce musí mít řadu specifických znalostí a zkušeností a musí být vybaven značnými pravomocemi. Manažer projektu musí dovedně koordinovat pracovníky rozdílných úrovní i specializací: vrcholové vedení podniku, koncové uživatele, pracovníky dodavatelských organizací atd. Z naznačeného je zřejmé, že úspěšným manažerem projektu nemůže být ani člen vrcholového vedení, který nemá žádné znalosti o informačních technologiích, ani analytik-programátor, který nezná věcnou problematiku dané aplikační oblasti nebo nemá dostatečnou formální i přirozenou autoritu.

    Nezkušení manažeři projektu dělají chyby zejména tam, kde IS/IT váže na ostatní činnosti podniku, resp. na externí partnery podniku, např.:

  31. Snaha o realizaci příliš rozsáhlých projektů
  32. S rostoucím rozsahem řešených projektů se exponenciálně zvyšují nároky na jejich řízení. Podcenění rozsahu projektu a podcenění problémů spojených s řízením těchto projektů vede často k trpkým závěrům. Z těchto důvodů např. U.S. Patent and Trademark Office zastavil projekt za cca 900 mil. USD - pouze pro jeho neuříditelnost.

    Již téměř klasickou knihou o problémech spojených s řízením velkých projektů je esej Brookse [BRO75], která vyšla v r. 1975. I když se informační technologie a metody řízení projektů od té doby značně zdokonalily, problémů neubylo, spíše naopak. Je to způsobeno nejen nezkušeností a neschopností řady manažerů projektů, ale zejména téměř megalomanskými ambicemi některých projektů.

    Specifickým problémem je v tomto smyslu i prudká dynamika velkých softwarových domů v ČR a její nezvládnutí ve vztahu k rozvoji vlastních organizačních, funkčních a personálních struktur. Přebujelá organizace, podcenění kvalifikačních programů pod tlakem splnění zadaných termínů, podcenění analýz projekčních rizik se pak promítá i do řízení projektů, které tyto firmy právě řeší.

    Základní pravidla, která by měl mít manažer projektu neustále na mysli, jsou:

  33. Chybné odhady časové a finanční náročnosti velkých projektů
  34. Zdá se, jako by nedodržení plánovaného termínu realizace informatického projektu bylo téměř zákonitým principem. Jen málokterý projekt je v celém plánovaném rozsahu a v plánované kvalitě dokončen v plánovaném čase. Přitom objektivní nutností je realizace zejména strategických projektů v minimálním čase. Strategický projekt dokončený za 2 až 3 roky od jeho zahájení obvykle ztrácí svoji strategickou výhodu díky rychlým změnám na trhu a díky rychlejším tahům konkurence. Nejobvyklejší chyby v této oblasti jsou:

    Chyby v odhadech, resp. při sestavování časových a finančních plánů projektů provázejí většinu současných velkých projektů. To vyplývá buď z nedostatku zkušeností řešitelského týmu z předchozích obdobných projektů, snahou dodavatelů IS/IT prosadit se v konkurenci (např. ve výběrových řízeních) za každou cenu, podhodnocením projekčních rizik (zejména personálních, technických a organizačních), apod. Snaha o snížení časového skluzu projektu pak obvykle vede ke snížení kvality řešení.

    V zahraničí lze nalézt příklady, které by se pro nás měly stát mementem. Tak např. Department of Social Security zahájil v roce 1982 projekt s předpokládanými náklady 700 mil. liber. V roce 1989 byl projekt dokončen s náklady 2.000 mil. liber a za rok provozu vykazoval 20.000 chyb a stovky terminálů musely být vráceny. Integrovaný systém "Inland Revenue" ve Velké Británii byl opuštěn po 200 člověkorocích práce (původní odhad byl 36.5 člověkoroku). British Telecom zaplatil na dodatečných nákladech za chyby v provozu účtovacího systému 150 mil. liber. Jedna z anglických bank odepsala dva projekty za 21 mil. liber, neboť každý z nich produkoval 2.500 chyb za měsíc.

  35. Podcenění oponentur a testování
  36. Je-li projekt nekvalitně řízen nebo dostává-li se projekt do časového skluzu, často to rezultuje v podcenění oponentur návrhu a podcenění testování jednotlivých komponent, zejména testování jejich chování v mezních nebo mimořádných situacích. Přitom čím je chyba odhalena později, tím vyšší jsou finanční i časové ztráty.

    Příkladem může být urychlené zavádění nové organizace studia na VŠE před několika lety. Se zaváděním tzv. kreditního systému bylo současně zrušeno i dálkové studium posluchačů, kteří studovali při zaměstnání. Zrušení znamenalo neotevření 1. ročníků dálkového studia s tím, že stávající ročníky dostudují dle starých předpisů. Organizace studia i jednotlivé jeho procesy byly promyšleny pouze v hrubých rysech s tím, že se předpokládalo, že případné “mouchy” v návrhu budou odstraněny za chodu nového systému. Projektanti nového systému přitom neošetřili řadu mimořádných situací. Jednou z nich byla i situace, kdy student posledního běhu dálkového studia propadne. Kam ale měl propadnout, když za jeho ročníkem žádný další ročník dálkového studia nenásledoval?!

  37. Chyby v odhadech provozních nároků IS na IT
  38. Chybné odhady provozních nároků IS/IT jsou i při rychle rostoucích parametrech hardware naprosto běžnou záležitostí. Jejich hlavní příčiny jsou:

    Chyby v odhadech uvedených charakteristik obvykle vedou k dlouhé době odezvy funkcí IS a k neočekávaným dodatečným nákladům na provoz IS/IT.

  39. Nevhodný postup při výběru systémového integrátora a při tvorbě kontraktu
  40. Které části IS/IT realizovat vlastními silami podniku a které dodavatelsky, jak vybrat vhodného dodavatele - systémového integrátora - to jsou další klíčové otázky, jejichž nevhodné řešení může nepříznivě ovlivnit úspěšnost projektu a tím i konkurenceschopnost podniku na dlouhé období. Zde upozorníme pouze na některé nejzávažnější chyby:

    Žádná z uvedených alternativ není výhodná ani pro jednu ze smluvních stran. První varianta je na první pohled výhodná pro odběratele. Jenže vztah dodavatele a odběratele při systémové integraci je dlouhodobý a partnerský. Prohra jedné ze stran se obvykle projeví za určité období jako komplikace i pro druhou stranu. Naivní dodavatel nezajišťující svoji prosperitu se v budoucnu může stát slabou stránkou minulého "vítěze" (nebude mít např. dostatek zdrojů na další rozvoj systému v souladu s celosvětovými trendy). Druhá varianta také není vítězstvím pro dodavatele, protože se negativně odrazí na jeho pověsti. A není snad větší hodnoty pro systémového integrátora než je jeho dobrá pověst založená na řadě úspěšných referenčních aplikací.

  41. Nedokonalá kooperace systémového integrátora se zákazníkem
  42. Tím, že dodávka systémové integrace je především dodávkou znalostí a teprve potom dodávkou hardwarových a softwarových komponent, nelze jí realizovat klasickým dodavatelským způsobem, tj. předat na určeném místě a v určeném čase dohodnuté zboží, zaplatit a obchodní případ je u konce. Systémová integrace je vztah partnerský a kooperační, ve kterém obě strany musí vytvořit na určitou dobu společný tým mající společný cíl.

    Nutnost kooperace a společné práce vyplývá zejména z toho faktu, že předávat znalosti a budovat vzájemnou důvěru nejde pouze pomocí předávaných komponent IS/IT a písemných dokumentů. Kromě toho znalosti, aby přinesly očekávaný přínos, musí být aktivně využity. Aktivní a efektivní užití znalostí se obvykle nedostaví ani po přečtení sebelepší uživatelské dokumentace. Optimální je postupné předávání znalostí při společném řešení konkrétních problémů zákazníka.

  43. Nedostatečná příprava uživatelů, ev. veřejnosti
  44. I přesto, že v současné době počítačové vzdělání se prudce zdokonalilo a pokrývá díky dostupnosti prostředků všechny vrstvy obyvatelstva (od žáků základních škol po důchodce), problémy zůstávají a posunují se dále. Hodně uživatelů spojuje informatickou kvalifikaci se schopností ovládat klávesnici ev. myš pro základní softwarové produkty, jakými jsou textové a tabulkové procesory. Stále ještě často uniká obsahová stránka informačních systémů, schopnost dobře zhodnotit a aplikovat datové a programové zdroje, schopnost domýšlet a řešit organizační, legislativní, ekonomické problémy spojené s informačními systémy.

    Dobře řízený projekt proto počítá s komplexem školení pro všechny typy budoucích uživatelů. Uživatelé se musí dovědět nejen o tom jak jednotlivé aplikace ovládat, ale také o tom, jaké cíle zavedení aplikace sleduje, jak se změní související pracovní postupy a zodpovědnosti a jak se budou řešit mimořádné stavy, které mohou nastat při provozu aplikace. Jinými slovy, školení se musejí stát nástrojem pro prosazování nové podnikové kultury a nástrojem pro získávání nové genetické informace.

  45. Rychlý vývoj IT
  46. Významným rizikovým faktorem projektů IS/IT je velmi rychlý rozvoj informačních technologií. Téměř denně se objevují na trhu s IT novinky jak v oblasti hardware a software, tak v oblasti služeb. Tento rychlý rozvoj s sebou přináší řadu otázek, na které neexistují triviální odpovědi:

    Obecně lze pro řešení této otázky dát pouze tato doporučení:

  47. Vysoké nároky na tvůrce IS
  48. Rychlý rozvoj IS/IT a komplexnost problémů při nasazování IS/IT s sebou přináší značné nároky na kvalifikaci a na zkušenosti tvůrců IS/IT. Tým, který nedisponuje členy s potřebnou kvalifikací a s potřebnými zkušenostmi nemůže realizovat úspěšně projekt, který je na úrovni doby. Do obtížné situace se dostávají zejména menší podniky, které provozují informační systém vyvinutý na míru vlastními pracovníky. Tito pracovníci jsou velmi často zavaleni řešením problémů operativního charakteru (řešením mimořádných stavů, údržbou systému podle stále se měnících požadavků uživatelů), takže jim nezbývá čas na sledování a osvojování nových trendů v informačních technologiích. Důsledkem pak může být i snížená konkurenceschopnost podniku.

  49. Přecenění významu metodik a nástrojů tvorby IS/IT
  50. Metodiky budování IS/IT, CASE prostředky a specializovaný software na řízení projektů sice představují nezbytnou podporu manažerům projektu, analytikům i programátorům, ale nejsou samospasitelné. Přeceňování jejich významu vede ke zdůrazňování formální stránky řešení oproti obsahové. Často se navíc vytrácí vlastní invence a tvořivost projektanta.

    Chyb v tomto směru lze najít praxi mnoho:

Shrnutí analýzy chyb a rizik při zavádění a provozování IS/IT

Na závěr analýzy chyb a rizik při vytváření a provozování IS/IT uvádíme tabulku, která shrnuje výše uvedené chyby a jejich nejčastější důsledky.

Legenda: Možné ekonomické a mimoekonomické důsledky chyb při vytváření a užití IS/IT.

  1. funkce IS jsou v rozporu se zájmy vlastníků (IS podporuje jiné chování podniku, než požadují vlastníci, IS nerespektuje vlastnické a organizační změny podniku)
  2. IS nepodporuje strategické řízení podniku a dosažení podnikových cílů
  3. desintegrace útvarů podniku
  4. investice do IS/IT nepřinášejí očekávané efekty
  5. projekt IS/IT nevystačí s původním rozpočtem a časem
  6. funkce IS jsou chybné (jsou v rozporu s podnikovými procesy a/nebo s požadovanými pravomocemi a zodpovědnostmi pracovníků)
  7. funkce IS jsou nedostatečné nebo nadbytečné (shelfware, wapourware)
  8. dlouhá doba odezvy funkcí IS
  9. obtížná orientace uživatelů ve funkcích IS a uživatelsky nepřívětivá komunikace systému
  10. neefektivní využití uživatelových schopností a kvalifikace
  11. nekvalifikované využití funkcí IS
  12. komplikovaná a nákladná údržba IS, obtížná přizpůsobitelnost IS měnícím se požadavkům
  13. rozpad integrace funkcí, dat, software a hardware

Tab. A: Chyby při zavádění a provozování IS/IT a jejich obvyklé důsledky

Chyby / důsledky

1

2

3

4

5

6

7

8

9

10

11

12

13

Chybně postavená globální podniková strategie

x

x

 

x

                 
Podcenění významu IS/IT pro zajištění konkurenceschopnosti podniku

x

x

 

x

                 
Malá angažovanost vrcholového vedení při inovaci IS/IT  

x

 

x

 

x

x

           
Řízení IS/IT delegováno na příliš nízkou úroveň podnikové

x

x

 

x

 

x

x

           
Řízení IS/IT je odděleno od řízení organizačních záležitostí    

x

   

x

             
BPR a/nebo zavádění ISO 9000 není koordinováno s rozvojem IS/IT    

x

x

 

x

x

           
IS budován na základě lokálních zájmů útvarů, prioritně jsou podporovány operativní úkoly koncových uživatelů

x

x

x

x

   

x

           
Přístupová práva k IS jsou v rozporu s rozdělením pravomocí a zodpovědností v podniku    

x

x

       

x

       
Informatický projekt je zaměřen na dodávku IT, nikoliv na "dodávku strategické výhody", resp. na podporu dosažení lepších služeb pro zákazníka

x

x

 

x

 

x

x

           
Povrchní specifikace požadavků na IS  

x

 

x

 

x

x

       

x

 
Budování IS/IT bez jednotné koncepce  

x

x

x

       

x

   

x

x

Špatná nebo neexistující architektura IS      

x

       

x

   

x

x

Atomizovaná datová základna podniku  

x

x

x

               

x

Neuvažuje se stav znalostí lidí a rozsah změn před zavedením nového IS/IT      

x

       

x

x

x

   
Nedůsledné řízení projektu      

x

x

x

x

   

x

 

x

x

Snaha o realizaci příliš rozsáhlých projektů      

x

x

           

x

 
Chybný odhad časové a finanční náročnosti (vlivem malé zkušenosti, resp. snahou získat lukrativní zakázku)      

x

x

               
Podcenění oponentur a testování      

x

 

x

x

x

x

       
Chybný odhad provozních nároků IS na IT        

x

   

x

x

x

     
Nevhodný postup při výběru systémového integrátora a při tvorbě kontraktu      

x

x

x

x

   

x

 

x

x

Nedokonalá kooperace systémového integrátora se zákazníkem      

x

 

x

x

   

x

x

x

 
Nedostatečná příprava uživatelů, ev. veřejnosti      

x

       

x

x

x

   
Nevhodné užití "end-user computing"                  

x

x

x

x

Přecenění významu metodologií a nástrojů tvorby IS      

x

x

               

 

Pro srovnání jsou zajímavé výsledky šetření firem Deloitte & Touche a IDOM [POL95] ve státech střední a východní Evropy - viz

a tab. c. Z údajů vyplývá, že v České republice je úspěšnost projektů IS/IT v průměru vyšší než v ostatních státech regionu. Na druhé straně jsou v ČR podstatně významnějšími příčinami neúspěchu projektů neochota uživatelů akceptovat změny, nedostatek kvalifikovaného personálu, nedostatečné školení a častá změna uživatelských požadavků.

 

tab. b

V čem byla chyba, jestliže se vám ne-podařilo dosáhnout cílů zavedení IS/IT ?

Region

ČR

Bylo dosaženo původních cílů

23

30

Neochota uživatelů akceptovat změny

26

52

Nedostatek kvalifikovaného personálu

22

42

Rozpočet

35

36

Podniková byrokracie

14

27

Nedostatečné školení

15

22

Špatná komunikace

17

16

tab. c

Jaké problémy jste měli při zavádění IS/IT ve vaší organizaci ?

Region

ČR

Změna uživatelských požadavků

43

70

Ztráta koordinace z důvodu značně dlouhé implementace

14

27

Neefektivní využití možností počítače

35

27

Neodpovídající školení

28

25

Trvalá nedůvěra k nové technologii

26

23

Neodpovídající definice potřeb před instalací

25

16

 

Literatura:

[ANG91] Angel,I.O., Smithson,S.: Information Systems Management - Opportunities and Risks, Macmillan, 1991

[BAL95] Balint, S., Nottingham, A.: Analysing Risk During the Appraisal of IS/IT Investments, Systems Integration ‘95, sborník konference, VŠE, Praha, 1995

[BEW90] Bewley, B.: National Center for IT, 1990, Members conference

[BRO75] Brooks,F.P.: The Mythical Man-Month, Essays on Software Engineering, Addison-Wesley, Reading, 1975

[CAS88] Cash,J.,I., McFarlan,F.,W., McKeney,J.,L.: Corporate Information Systems Management, Harvard University, 1988

[DON94] Donovan,J.J.: Business Re-engineering with Information Technology, Prentice Hall, 1994

[MCN89] McNurlin,B.C., Sprague,R.H.: Information Systems Management in Practice, Prentice-Hall, 1989

[POL95] Polák,J., Kafka,J.: Trends in Information Technology in Central and Eastern Europe, Systémová integrace'95, sborník mezinárodní konference, ČSSI, Praha, 1995, 17-30

[STS85] Strassman, P.A.: Information Pay Off, The Transormation of Work in the Electronic Age, New York Free Press, Collier MacMillan, London, 1985

[WAR94] Ward,J.: Information Systems - Delivering Business Value?, Proceedings of 4th Annual BIT Conference "Information Systems - Delivering Business Value?", Manchester Metropolitan University, 1994

[VOR90] Voříšek, J., Štěrba,M.: Interaktivní systémy, Praha, SNTL, 1990,

[VOR94] Voříšek, J.: Systémová integrace - komplexní služba v oblasti IS/IT, Systémová integrace, č. 1, 1994, ČSSI, Praha 1994