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

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é:

• neustálé snižování výrobních nákladů,
• vybudování jména značky výrobku nebo služby a opírání dalšího úspěchu především o tuto značku,
• stálá orientace na jeden neměnný předmět činnosti,
• orientace na velké trhy,
• využívání protekcionistických bariér,
• finanční restrukturalizace založená na odprodeji částí podniku.

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.

 



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

 

2. IS nerespektuje vlastnické a organizační změny v podniku

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ží.

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

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?

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

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.

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

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ě.

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

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.

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

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.

8. Zaměření IS primárně na partikulární zájmy útvarů a jejich operativní úkoly

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.

9. 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

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:

• snížení průměrné doby vyřízení objednávky z 10 dnů na 6,
• snížení stavu zásob o 10 mil. Kč,
• zavedením on-line sledování a plánování finančních toků snížit objem úvěrů a z nich placených úroků o 30%,
• standardizovat formu všech interních a externích dokumentů standardními šablonami a tím zvýšit image podniku a snížit administrativní náročnost tvorby dokumentů atd.

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

 



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

 

10. Povrchní specifikace požadavků na IS

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.).

11. Budování IS/IT bez jednotné koncepce

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é:

• nekompatibilita postupně nakupované výpočetní techniky a na ní zpracovávaných aplikací. Neexistuje-li celková koncepce IS/IT, pak neexistují jasná kritéria vhodnosti a výběru jak hardwarových, tak softwarových komponent. Informační technologie podniku pak spíše než promyšlenou stavbu připomínají sbírku nesystematického sběratele,
• postupný rozpad integrace funkcí, dat, programového i technického vybavení IS s dalšími negativními důsledky, jako je neprůhlednost a komplikovanost architektury systému jak pro uživatele, tak pro jeho tvůrce, ztráta pružnosti na změny v požadavcích zákazníků, dlouhá doba reakce na události přicházející z okolí, desintegrace podnikových útvarů apod.

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í.

12. Málo pružná informační strategie a nepružný IS/IT s nevhodnou architekturou

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ř.:

• budování IS/IT na centralizovaném principu, i když většina aktivit firmy probíhá decentralizovaně,
• budování IS/IT na hardware a/nebo software, který nesplňuje charakteristiky otevřených systémů,
• nedůsledné využívání standardů (hardwarových, softwarových, komunikačních),
• aplikační software (ASW) má monolitní architekturu, která neumožňuje, aby se změny zapříčiněné vlivy různých typů promítly pouze do přesně vymezené části ASW. Tak např. změny legislativy se musí promítat do zcela jiné části ASW než změny uživatelského rozhraní, resp. změny databázového systému, se kterým ASW pracuje. Moderní ASW je budován na principech mnohovrstevné architektury (viz [VOR90], [DON94]), která důsledně odděluje minimálně tři vrstvy funkcí ASW:
• presentační funkce,
• aplikační a technologické funkce,
• datové funkce.
13. Atomizovaná datová základna podniku

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ů.

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

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.

15. Nedůsledné řízení projektu

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ř.:

• úspěšné nasazení IS/IT vyžadovalo realizaci určitých organizačních změn, ale ty nebyly uskutečněny,
• aplikace vyžadovala změny chování partnerů podniku (např. zasílání objednávek v elektronické místo papírové podobě), ale s partnery nikdo nejednal a neuzavřel s nimi potřebné dohody,
• aplikace využívá hardware a software od různých dodavatelů, ale nikdo neprovedl prověření kapacitních nároků aplikace na počítačové zdroje.
16. Snaha o realizaci příliš rozsáhlých projektů

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:

• čím větší systém, tím tvrdší pád - snaž se proto rozdělit velký projekt na řadu menších projektů s jasně vymezenými cíli,
• snaž se vše dělat co nejjednodušší. Geniální manažer projektu není ten, který v projektu využije všechny poslední novinky informačních technologií, nebo ten, který jako jediný rozumí příliš sofistikované architektuře IS/IT, ale ten, který z omezenými finančními a lidskými zdroji dokáže ve stanoveném čase dosáhnout stanovený cíl.
17. Chybné odhady časové a finanční náročnosti velkých projektů

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:

• malá zainteresovanost vrcholového vedení podniku na realizaci projektu. Často se stává, že vrcholové vedení podniku sice slovně vyjadřuje veškerou podporu realizaci projektu, ale přitom se vedoucí pracovníci v projektu neangažují a ani nevytvoří pracovníkům řešitelského týmu podmínky pro dodržení harmonogramu prací. Například klíčoví pracovníci projektu jsou odvoláváni z prací na projektu, aby řešili běžné operativní úkoly, na které se nenašly v podniku jiné pracovní zdroje. Pracovní týmy projektu se pak scházejí v neúplném nebo v neustále se měnícím složení,
• nedostatečně kvalifikovaný tým řešitelů. Tento problém má obvykle kořeny v uspěchané přípravě projektu, v podcenění školení a v nízké kvalitě školení. Přitom na první pohled "ztracený" čas školením se bohatě vrátí v kvalitě a v rychlosti řešení,
• používání málo mocných nástrojů a stavebních kamenů při implementaci projektu. Velký projekt se nedá realizovat rychle bez mocného vývojového prostředí, kterými jsou především CASE pokrývající všechny fáze řešení projektu (včetně generování programů), a bez předpřipravených standardních stavebních kamenů aplikací.

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.

18. Podcenění oponentur a testování

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?!

19. Chyby v odhadech provozních nároků IS na IT

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:

• v chybných odhadech náročnosti základního a aplikačního SW na technickou základnu,
• v chybných odhadech rozvoje systému z hlediska růstu datových bází, zvyšujícího se počtu uživatelů a jejich pracovních nároků, časové náročnosti zpracovávaných procedur, nárocích na sdílené IT zdroje, apod.,
• v chybných odhadech a testech zatížení systému ve špičkách nebo při sezónních výkyvech (dopravní špičky, administrativní špičky, např. termíny odevzdání některých výkazů, daňových přiznání, různých druhů registrací apod.),
• v chybných principech pro přidělování přístupových práv, nevycházejících z adekvátní organizační a funkční struktury,
• v prudkém rozvoji software, často nesourodých softwarových konfiguracích na serverech nebo pracovních stanicích, a s tím spojeném zahlcení těchto prostředků,
• v rostoucích požadavcích na aplikace s grafickým uživatelským rozhraním a s tím související růst náročnosti na kapacity a výkon technických zařízení,
• v nejasné koncepci distribuce výpočetních a datových zdrojů.

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.

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

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:

• základní chybou je dívat se na dodávku IS/IT jako na každou jinou investici. Dodávka IS/IT není totéž, co dodávka výrobní linky nebo stavba výrobní haly. Dodávka IS/IT je především dodávkou znalostí a nových metod práce! Proto systémový integrátor (tj. generální dodavatel IS/IT) musí být více konzultant a učitel než stavebník a mechanik,
• výběrové řízení je účinný nástroj pro snížení ceny a zkrácení termínu dodávky IS/IT. Tlak na cenu a termín má však své meze. Zejména u prestižních zakázek může vzniknout situace, kdy uchazeči v tendru jsou dotlačeni do situace, kdy jejich nabídky se postupně posouvají za hranice jejich reálných možností. Vítěz v tendru je pak postaven do velmi obtížného dilematu:
• buď dodrží všechny slíbené parametry dodávky včetně její ceny, termínu a kvality a zakázka se pro něj stane nerentabilní,
• nebo využije vhodně formulovaných ustanovení kontraktu pro zvýšení ceny, prodloužení doby řešení nebo snížení rozsahu dodávek.

Žá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í.

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

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.

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

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.

23. Rychlý vývoj IT

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:

• má se řešení opírat o nejnovější software a technologie, a nebo je vhodnější využít sice starší, ale odzkoušené a lacinější komponenty? Rozhodne-li se podnik pro první variantu, může získat náskok před konkurencí, ale může se dostat také do situace, kdy se zvolené řešení ukáže být slepou cestou vývoje, nebo kdy daná komponenta je sice perspektivní, ale ve své první verzi je tak poruchová, že nelze o ní opřít klíčové podnikové procesy. Rozhodne-li se podnik pro druhou variantu, může nejen zaostat za konkurencí, ale také se může dostat do situace, že zvolená komponenta přestane být v krátké době podporovaná dodavatelem nebo přestane být kompatibilní s ostatními komponentami provozovaného IS/IT.

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

• novou komponentu je vhodné upřednostnit tehdy, když nebude znamenat pouze změnu technologie, ale její nasazení přinese s vysokou pravděpodobností i ekonomické nebo mimoekonomické přínosy (např. zlepšení image podniku),
• není obvykle vhodné opírat klíčové podnikové procesy o “nulové” verze softwarových produktů (např. o komponentu s označením 3.0). Tyto produkty jsou často uváděny na trh pod tlakem konkurence nedostatečně otestované a mohly by zapříčinit vysokou nespolehlivost podnikového procesu a následné snížení kvality výroby nebo služeb,
• která z nových komponent nabízených na trhu je ta nejvhodnější? Protože na nové komponenty ještě nejsou ani pozitivní ani negativní reference, je i výběr z nových komponent stejného typu značným problémem. Vysoce riziková je zejména volba komponenty, kterou dodává nově založená nebo velmi malá firma. Po jisté době nastává na trhu období standardizace komponent daného typu s tím, že za základ standardu obvykle slouží vedoucí produkt na trhu. I kvalitní produkty menších firem nemusí v konkurenci obstát, protože jejich řešení je obvykle postavené na jiné koncepci než na té, která se stala základem vzniklého standardu,
• jak udržet integritu (celistvost) a konzistenci (soudržnost) celého IS/IT, když se jeho jednotlivé části vyvíjejí nerovnoměrně? Klasickým problémem je rozdílná rychlost morálního zastarávání hardware, základního software a aplikačního software. Nutností zde je vybírat takové ASW, pod kterým bude možné vyměnit za doby jeho provozu jednou až dvakrát ZSW (např. přejít na jiný typ databázového systému nebo jiný typ operačního systému), a takové ZSW, pod kterým bude možné obměňovat HW každé dva až tři roky.
24. Vysoké nároky na tvůrce IS

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.

25. Přecenění významu metodik a nástrojů tvorby IS/IT

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:

• v projektu se používá věhlasná metodika, ale bez jejího přizpůsobení rozsahu projektu, počtu a zkušenostem řešitelů a uživatelů, požadované době řešení a disponibilním finančním prostředkům. Striktní aplikace metodiky pak v nejlepším případě vede k prodloužení doby řešení a k překročení rozpočtu,
• nezkušení řešitelé projektu podlehnou argumentaci dodavatele CASE: "Jestliže si zakoupíte náš CASE, zvýší se produktivita vaší práce několikanásobně." Již se však včas nedozví, že CASE bez dokonalé znalosti metod a technik, na kterých je postaven, a bez zapojení CASE do celkové metodiky řízení projektu přinese spíše finanční a časové ztráty než očekávané efekty,
• vybere se CASE, který není kompatibilní s ostatními částmi vývojového prostředí (s programovacím jazykem, se SŘBD apod.,
• možnost a někdy i nutnost detailního popisu řady aspektů souvisejících s datovým a funkčním návrhem IS odvede nezkušené projektanty od klíčových problémů projektu. Např. detailně se analyzuje a navrhuje ta část projektu, jejíž význam je z hlediska celopodnikových cílů zanedbatelný.