V současné době nechce nikdo udělat při výběru informačního systému chybu. Časové podmínění této věty se může zdát nesmyslné, ale v rozmezí let 1990-1993 došlo k tolika omylům při nákupu a nasazování nevhodných informačních systémů, že se to zpětně zdá až neuvěřitelné. Svou roli tehdy sehrála místní nezkušenost v této oblasti, přecenění možností vlastní ekonomiky (výroky typu ekonomický tygr východní Evropy jsou nyní spíše úsměvnou vzpomínkou), optimistické prognózy i obratná reklamní a obchodní politika poskytovatelů. Dnes se již podniky a organizace z velké části poučily a nastává období napravování někdejších pochybení. Z tohoto pohledu mohou nyní nastat v podstatě tři situace.

Zcela nový informační systém (na zelené louce)
K této situaci dochází obvykle při nasazení komplexního informačního systému v nově vznikajících firmách a organizacích (v oblasti státní správy a samosprávy například vznik krajských hejtmanství).

Dalším příkladem je zakládání místních poboček zahraničních firem, kde se obvykle přebírá informační systém z ústředí. Variací může být i nutnost nahradit lokálně vyvinuté a nesystémové aplikace různých oddělení (FoxPro, Excel apod.) komplexním systémem. Je zřejmé, že zde je výchozí situace poměrně nekomplikovaná - dají se lépe zmapovat skutečné potřeby, předimplementační příprava není zatížena žádnou předchozí zkušeností, organizační, funkční i datové modely mohou vznikat nezávisle na historii.

V těchto případech by dnes a při dodržení zásad již mnohokrát popsaných nemělo dojít k závažnějším problémům při implementaci.

Upgrade informačního systému
Upgrade informačního systému znamená obvykle výraznější povýšení stávajícího systému jeho poskytovatelem. Může zahrnovat například

. změnu platformy operačního systému (např. z MS-DOS na Windows),
. změna databázové plaformy (např. z FoxPro, B-Trieve na Visual Foxpro, MS SQL Server, Oracle apod.),
. významné změny funkcionality,
. integrace s prostředím Internet, intranet, Extranet.

Tento postup obvykle také nepřináší větší problémy. Poskytovatel většinou zaručuje převedení dat a podporu při případných změnách hardware, operačního systému a databáze. Zároveň není potřeba provádět rozsáhlá školení uživatelů, protože základní funkcionalita je zachována, ovládání je podobné a řadu věcí lze intuitivně odvodit. K problémům může dojít, pokud ve starší verzi došlo k výraznějším lokálním úpravám (buď poskytovatelem nebo i uživatelem). Po upgrade systému tyto nestandardní úpravy samozřejmě zmizí, protože nová verze je standardní a nepromítají se do ní nesystémové změny jednotlivých instalací. Všechny uvedené důvody směřují k doporučení modelu spolupráce se silným poskytovatelem, který garantuje vývoj systému, řízenou distribuci nových verzí a vytváří se zákazníkem dlouhodobý vztah na základě oboustranné výhodnosti.

Náhrada staršího informačního systému zcela novým produktem Důvody vedoucí k tomuto zřetelně nejkomplikovanějšímu postupu mohou být různé

. současný produkt nemá novou verzi (nedostatečný vývoj, existenční problémy poskytovatele),

. výrazně změněné nároky na funkcionalitu (expanze firmy, změna obchodního modelu, změna managementu, vstup zahraničního partnera),

. náhrada proprietárního nebo speciálně vyvinutého řešení s náročnou údržbou standardním produktem nebo službou ASP.

Největším úskalím v této situaci je riziko podlehnutí plíživému stínu starého systému i se všemi jeho chybami. Pokud již nějaký systém ve firmě funguje, je vždy velmi lákavé využít jeho model a implementovat nový systém podle starého - de facto jej pouze nahradit. Že je tento postup chybný, není třeba zdůrazňovat. Řešením je samozřejmě stará a obehraná písnička - před implementací provést detailní analýzu požadavků na informační systém, zpracovat procesní model a podle něj pak nový systém nasadit. Proč k tomuto řešení dochází velmi zřídka, bylo již rovněž mnohokrát popsáno v řadě článků. Samotná náhrada pak přináší řadu komplikací jako:

. zvládnutí odlišné hardwarové a softwarové platformy,
. přizpůsobení datových a funkčních modelů, založených na různých filozofiích,
. migrace odlišných datových struktur,
. zvládnutí odlišné funkcionality nového systému,
. současná práce se starým systémem a učení se nového,
. ztráta zavedených výstupů (formuláře, tiskové sestavy, grafy).

Nejkritičtější je správné naplánování okamžiku a způsobu změny. Je možné postupovat podle dvou následujících scénářů:

A) Pozvolný přechod z jednoho systému na druhý s obdobím souběžného provozu starého a nového systému.

B) Jednorázová změna ukončení běhu jednoho systému a spuštění druhého.

Varianta A
umožňuje pozvolný náběh nového systému bez velkého třesku s možností většího prostoru na korekci chyb. Nevýhodou je nebezpečí lpění některých uživatelů na starém systému ("ještě tuhle zakázku, na kterou se tak spěchá, uděláme postaru") a nutnost vytváření řady přechodových můstků pro importy a reimporty dat mezi oběma systémy. Pro IT specialisty zákazníka je to samozřejmě mimořádně náročné období z hlediska koexistence obou systémů a jejich údržby.

Varianta B
vyžaduje velmi dobrou přípravu, nejlépe s několika odzkoušenými simulacemi přechodu. I v tom případě je však téměř jisté, že se nějaké problémy vyskytnou. Výhodou je, že je možné se cíleně zaměřit pouze na nový systém bez dalšího tříštění sil. Ke konsolidaci rutinního provozu pak může dojít mnohem rychleji než u varianty A. Přechod skokem bývá obvyklý zejména u účetních systémů, kde vzniká častý požadavek spuštění nového systému společně s novým účetním obdobím.

Jako historický příměr tohoto přístupu může sloužit čin dobyvatele říše Aztéků Hernana Corteze. Když doplul se svou nepočetnou a personálně ne zcela ideální armádou k pobřeží Mexika, nechal poté záměrně spálit všechny lodě. Pak přestoupil před své vojáky. Cíl je pouze vepředu, cesty zpět již není.

Výsledkem tohoto činu byla porážka mnohonásobně početnějšího protivníka a dobytí velké říše.