Jak správně vést IT projekty (nejen) v bankovnictví

Lukáš Zrzavý | 28.04.2014 | Analýzy, Ostatní | Žádné komentáře

Dobré zadání je prvním předpokladem každého úspěšného IT projektu. Čím je projekt komplexnější, tím propracovanější zadání musí být. To platí nejen pro finanční sektor, ale prakticky pro každé odvětví, které nové IT projekty zavádí. Kvalitní zadání by mělo obsahovat schémata či obrázky, z nichž bude jasný byznysový proces a jeho cíle, které má informační systém pokrývat. Velmi důležitý je i rámcový výpis očekávaných funkčností a pohled na objekty nebo entity, se kterými systém bude pracovat.

Pokud tedy budeme pracovat s úvěrem, kartou, podpisovým vzorem, se zákazníkem, informacemi o pobočce, musí být ze zadání jednoznačně možné vyvodit, která data / objekty bude informační systém obsahovat. Nezanedbatelný bod dobrého zadání je stanovení rozpočtu. Klient sice obvykle nemá dostatek znalostí na stanovení ceny, ale musí přesně znát své investiční možnosti. Častou chybou klientů bývá, že nepřicházejí s žádnou konkrétnější finanční představou a stanovení ceny nechávají zcela na dodavateli.

Informační systém řešící určitou oblast se dá vytvořit za 3 nebo 5, ale i za 100 milionů korun. A vždy bude funkční. Rozdíl však bude v komfortu pro uživatele, v rychlosti zaškolení obsluhy, v ceně provozu a údržby, v tom, co si mohu dovolit řešit automaticky, co budu muset řešit ručními servisními zásahy a pod. Finanční rozsah je tedy důležitá součást zadání projektu, stejně i rámcové termíny a představa, jakým způsobem se má systém nasazovat. Nejhorší je přijmout chybné zadání nebo se dostat do situace, v níž sám zadání nedůvěřuji. Jde o to, aby projekt dopadl dobře, ne abychom vybírali peníze a za rok zápasili s nespokojeností klienta kvůli špatně provedené práci.

Řízení KKTR – co a jak dělat pro to, abychom udrželi parametry

Základní parametry projektu dodávky informačního systému jsou kvalita, kvantita, termín a rozpočet (KKTR). Stejně jako při stavbě domu se při návrhu a dodávce informačního systému postupuje v několika krocích: úvodní studie, technický projekt s prototypem a až poté následuje implementace a zavedení systému do pilotní a následně do rutinního provozu.

Základní parametry KKTR je potřeba vnímat jako jeden celek. Ve fázi úvodní studie a následného technického projektu se detailně rozpracovává rozsah projektu (kvalita a kvantita) – probíhá analýza požadavků a design celého řešení. Je zcela běžné, že se diskutuje o funkčnostech, které v systému budou a které ne. Zadavatelé z byznysu a byznys architekti navrhují co nejlepší řešení, co nejvíce propracované a maximálně vyhovující potřebám koncových uživatelů.

Tento přístup má logicky podstatný vliv na cenu a je důležité, aby již v průběhu analýzy byl návrh nového systému neustále konfrontován s plánovaným rozpočtem. Častá chyba je, že rozpočet se nepovažuje za vstupní požadavek. Na konci analytické fáze tak dojde k „přepočítání“ ceny projektu a k překvapení všech zúčastněných se zjistí, že rozpočet je překročen například dvojnásobně. Pak nastává složitá fáze ořezávání rozsahu. Projekt se tak začne zpožďovat, zákazník, který si již nastavil určité očekávání od nového informačního systému, musí toto očekávání změnit. Tyto činnosti navíc stojí projektový čas a peníze.

Dobrý byznys architekt bere neustále při analýze a syntéze požadavků rozpočet jako klíčový vstupní požadavek pro všechny své analytické úvahy, které s tímto rozpočtem konfrontuje. Je tedy správné, když na analytickém workshopu zazní : „Obávám se, že tuto funkčnost asi nebude možné vyřešit takto komfortně, protože tím porušíme rozpočet. Váš pan ředitel považuje rozpočet za podstatnou součást zadání. Navrhuji, že funkčnost bude zjednodušená takto… Uživatelům to bude plně dostačovat a nenarušíme tím celkový rozpočet projektu.“ Tuto všudypřítomnou validaci navrhovaného řešení a rozpočtu nazýváme řízení budoucích rozpočtů.

Mnoho „strážců“ rozpočtu sleduje rozpočet probíhající fáze (např. technického projektu), ale uniká jim, že důležité je v technickém projektu stanovit právě budoucí rozpočet implementace. Není složité ukončit technický projekt v rozpočtu, který byl stanoven na samotnou projekci – to patří k základním schopnostem projektových manažerů. Důležité je předložit i výstupy analytických prací – takový technický projekt, který našel řešení splňující všechny čtyři parametry KKTR.

Zákazník musí rozuměl výstupům a potvrdit je

Zástupci zákazníka by měli nejen rozumět věcně řešené problematice, ale měli by také umět číst technický projekt. Jedině tak se dají odhalit a odstranit možné nedostatky a rozdílné pohledy ještě v projekční fázi. Je naivní myslet si, že lepší zákazník je ten, který vše odsouhlasí bez hlubších znalostí. Proto je důležité školit zákazníky tak, aby rozuměli jednotlivým modelům a diagramům.

Chybou je vzbuzovat v zákazníkovi pocit závislosti na dodavateli. Některé firmy si nezastupitelnou roli dokonce budují. Je potřeba dbát na to, aby na straně klienta byla skupina lidí, která je dodavateli partnerem, která práci rozumí, která ji zadává i přebírá, chápe přidanou hodnotu a rozhoduje například i o tom, zda si nebudou některé části projektu dělat sami.

Přístup klienta ke všem informacím v projektu – věcným i řídícím

V průběhu realizace projektu je třeba podělit o informace se všemi zúčastněnými stranami. Je nezbytné starat se o to, aby každý měl takové informace, které při své práci potřebuje. Pro řízení je neefektivní, když jsou informace pouze v hlavách jednotlivců nebo v jejich e-mailových schránkách. Důležité informace je nezbytné sdílet na jednom společném místě. Jejich shromažďování musí probíhat cíleně a zároveň bychom měli být schopni odkudkoliv a kdykoliv najít to, co potřebujeme.

Autor je provozní ředitel ve společnosti Unicorn Systems a. s.

Zdroj: www.infoware.sk

Zanechte komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *


tři + = pět

Můžete používat následující HTML značky a atributy: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Copyright © ICT manažer | ISSN 1805-5486 | SEO optimalizace a přizpůsobení SEO-care.cz