Systémová integrace je termín používaný ve více významech. V širším smyslu shrnuje potřeby, úkoly a technologie vyskytující se při spolupráci více aplikací různého řádu pro podporu průřezových obchodních procesů. Většinou jsou míněny klíčové postupy podniku, jako je například obsluha zákazníka, od nabídky produktů až po všechny dopady uzavření smlouvy se zákazníkem.
Je zřejmé že na nákladově efektivní podporu těchto procesů má vliv historie informačního vývoje podniku, plánování, přesnost a dodržování strategie i použité technologie. Jejich výběr pro zprostředkování přenosu dat a zpráv na technické úrovni pokrývá termín systémová integrace v užším smyslu. Z hlediska řízení změny se tyto úrovně v některých aspektech zásadně liší, neboť například vývoj a podporu integrace v čistě technickém smyslu lze předat jednomu či více externím dodavatelům (outsourcing), avšak dohled nad podporou obchodních procesů musí nutně zůstat v interní péči. Zatímco na technické úrovni je několik málo standardních dodavatelů softwaru, je jen málo univerzálních schémat platných pro širší systémovou integraci.
V poměrně nedávné minulosti existují příklady projektů, jejichž cílem bylo mimo jiné pozvednutí průřezové systémové integrace (SI) podniku na vyšší úroveň. Z jejich průběhu, ukončení a mnohdy i systematického pokračování lze vyvodit několik poučení. Tyto mají řadu společných atributů, i když nemusí jít nutně o projekty velkého rozsahu ani rozpočtu.
Řada projektů, které lze k SI přiřadit, se potýkala se změnami v zadání, s navyšováním rozpočtu i s posunem termínů. Na druhé straně úvodní smluvní jednání jsou vždy dlouhá a komplikovaná (většinou dochází k prvnímu posunu původních interních projektových termínů), takže by bylo možno očekávat maximální přípravu a důkladnost na straně dodavatele i zákazníka.
V realitě se však už v tvorbě smluvního vztahu odráží potenciální budoucí problémy projektu. Na jedné straně zákazník není schopen na základě interní analýzy specifikovat všechny parametry cílového řešení ani přesný popis aktuálního stavu a na druhé straně dodavatel či dodavatelé nejsou schopni nabídnout přiměřenou pevnou cenu. Z hlediska zákazníka není ani možné stanovit detailní popis, neboť obchodní vývoj je takový, že v době ukončení projektu může být zákazník ve zcela jiné situaci a na její vývoj musí průběžně reagovat. Není tedy ani možné pojmout projekt výhradně klasickou metodologií od analýzy po dodání.
Na stranu dodavatele je charakteristicky kladen velký nárok na projektové vedení. To musí reflektovat záměry mnoha stran na straně zákazníka, z nichž mnohé často nejsou ani explicitními účastníky projektu. Projekty SI jsou navíc komplikované partnerstvím s více dodavateli. Může docházet k změnám v projektovém plánu, které nejsou vyvolány pouze potřebou zákazníka. Řízení rizika a změny na různých úrovních se stává naprosto nepostradatelným. Jeho podcenění nebo spolehnutí se výhradně na dodavatele vede zákonitě k problémům.
Zkušenost ukazuje, že pokud není řízení změny přesně podchyceno již při přípravě smluvního vztahu a pevně dodržováno od začátku projektu, jsou projekty SI náchylné ke generování vedlejších projektů nebo navyšování pracnosti na obou stranách. To vede přímou cestou k nespokojenosti s projektem a dále jsou tak do původního projektu zaváděna nová rizika a závislosti. Dodavatel si je často tohoto rizika vědom, zdráhá se nést globální zodpovědnost za projekt a přijímá ji ovšem s cenou riziku odpovídající.
Stejně jako se vyvíjejí potřeby reagovat na změny na trhu a okolní prostředí projektu, může dojít k rozdílu mezi aktuálními potřebami zákazníka a striktním zněním smlouvy. Tento vývoj nesmí být potlačován na žádné straně a je třeba na něj reagovat. Z tohoto pohledu je nejvýhodnější, pokud smlouva velmi přesně stanovuje nejen cíl a cenu, ale i detaily sdílení projektových rolí a zodpovědností. Tím je stanoven nejen cíl projektu, ale i prostředí řídící jeho potenciální úpravy.
Zmíněné problematické aspekty se ovšem vyskytují i u jiných projektů a nejsou typické pouze pro SI. Na rozdíl od jiných projektů jsou ale ještě umocněny tím, že u zákazníka není z logických důvodů dost volných a přitom potřebně kvalifikovaných lidských zdrojů na straně obchodní ani technologické. V tomto směru je tedy kladen extrémní nárok na dodavatele. Ten musí disponovat nejenom technicky orientovanými konzultanty, ale musí vlastnit a uvolňovat podle plánu i zdroje se znalostmi na úrovni detailů všech dotčených procesů.
Kvalitní systémový integrátor, pokud vystupuje jako primární dodavatel, proto v případě projektu SI, kde je zúčastněno mnoho stran, automaticky nabízí kompletní garanci za celý projekt. Řízení změny projektu je věnována stejně velká pozornost jako naplňování projektového plánu a jsou jím pověřováni nejzkušenější pracovníci. Hlavní dodavatel navrhuje priority změn, poskytuje kompletní podklady pro jejich posuzování a provádí vlastní doporučení s tím, že konečné rozhodnutí je samozřejmě na straně zákazníka.
Vždy je ovšem dobré, jsou-li do projektu zapojeni zaměstnanci zákazníka, a to od samého začátku a na všech úrovních. Tímto způsobem se sice poněkud zvyšuje riziko závislosti na interních potřebách klienta, kdy zaměstnanec může být pověřen jinými úkoly, je to však věc řešitelná a umožňuje nenásilné předávání znalostí. Ty jsou jinak velmi obtížně sdělitelné formou obvyklých písemných materiálů – manuálů a doporučení. Současně s tím je pak snížen nárok na zaškolení. I testování probíhá daleko kvalifikovaněji než v případě dodávky na klíč výhradně dle předdefinovaných parametrů. Důsledkem takovéhoto přístupu je také snížení závislosti zákazníka na externích zdrojích a racionální volba případného outsourcingu technické podpory neovlivněná vědomím rizika vlastních zdrojů.
Rozsah případné postprojektové podpory, v případě přání zákazníka, by měl mít systémový integrátor na zřeteli současně s výše zmíněným změnovým řízením. Obsah případného SLA (Service Level Agreement) a všechny implikace dalšího vývoje je nutno specifikovat průběžně a nikoliv až ke konci projektu, neboť jen tak je možné vidět i sekundární náklady vyvolané změnami rozsahu projektu. Průběžně vznikající podpůrná dokumentace umožňuje i správné vnitřní plánování zdrojů v případě, kdy se zákazník nerozhodne pro outsourcing technické podpory a vývoje. V každém případě je neocenitelná pro vývoj navazující na ukončení projektu.
Systémový integrátor přebírá zodpovědnost za celý projekt, ale nedoporučuje se striktní oddělení zákazníka od ostatních dodavatelů. Naopak, zapojení zaměstnanců klienta je klíčové pro úspěch projektu i vývoj po něm. Při smluvních jednání vždy klademe důraz nejen na konečné cíle projektu a posouzení jejich dosažení, ale i na explicitní vymezení zodpovědností změnového řízení s ohledem na pružnost reakce na vývoj okolního prostředí a jeho požadavků. Technické aspekty integrace zcela garantuje hlavní dodavatel s tím, že zákazník má v každém okamžiku dostupné podklady pro rozhodnutí nejenom o outsourcingu podpory, ale především pro potřeby dalšího rozvoje. Dobrý systémový integrátor tímto naplňuje roli nejen odborníka znalého technologií a procesu jejich zavádění, ale logicky zastává i pozici průvodce plynulým architektonickým vývojem reagujícím na potřeby okolního prostředí, kdy je systémová integrace efektivní odpovědí na měnící se potřeby klienta.
Autoři jsou manažery divize Finance společnosti Ness Czech.
Foto: Wikipedie, licence obrázku public domain