Projektování informačních systémů 4 Příprava smlouvy, plánování a řízení projektu IS Doc. Mgr. Petr Suchánek, Ph.D. RNDr. Ing. Roman Šperka, Ph.D. Převzato od: Ing. Dominik Vymětal, DrSc 1 Předpoklady zahájení projektu oSchválení konkrétních cílů projektu oRozhodnutí o zajištění cílů (interně, dodavatelsky, smíšeně) oStanovení podmínek a omezení projektu oStanovení zodpovědností za zavedení, provozování a údržbu oSchválen časový a nákladový rámec oSouhrnně: je schválena Studie proveditelnosti nebo odpovídající dokument o 2 > Etapy realizace projektu IS oVýběr dodavatele oDetailní analýza požadavků na nový systém oZpracování konceptu řešení oPříprava nového řešení oPříprava převodu dat oŠkolení klíčových uživatelů oAkceptační /Integrační testy oŠkolení uživatelů oPřevody dat oNáběh nového systému 3 > Základní otázky v souvislosti s projektem IS Firemní nebo koncernová politika oCentralizace zdrojů, údržby, změn, rozvoje oRoll Out oOutsourcing qPřizpůsobí se Organizace firmy dodanému SW nebo se SW bude přizpůsobovat Organizaci firmy? qMěníme procesy a organizaci současně se zavedením IS? qMíra zapojení interních zdrojů qZpůsoby zaškolení (Train the trainer, dodavatelské školení) qPriority (Termín, Náklady, Kvalita) n 4 Příprava kontraktu V oblasti IS se často rozhoduje o dodavateli po schválení Úvodní studie proveditelnosti nebo po interním rozhodnutí o zahájení. Druhy kontraktů nVnitřní: definice požadované práce, zodpovědností, zdrojů, řídí se pracovní smlouvou a pracovním právem nVnější: popis produktu, služby, smluvních podmínek, řídí se obchodním právem Většina projektů IS představuje kombinaci obou 5 Fáze života kontraktu Plánování nUrčení potřeb, návrh předmětu kontraktu, časových a finančních aspektů, plánování dalších podmínek nUpřesnění obecných cílů Studie proveditelnosti Formování nIdentifikaci potenciálních dodavatelů, jednání o podmínkách dodávek (výběrové řízení), definitivní výběr dodavatele Administrace nVlastní výkon kontraktu, kontrola provedení dodávek a služeb ( zpravidla na obou stranách) Monitorování nManagement procesů souvisejících s výkonem kontraktu 6 Fáze přípravy kontraktu 7 Vyhlášení soutěže Vyžádáním kalkulace nU menších finančních objemů Žádost o nabídku nU větších finančních objemů nNabídka bývá zpravidla předmětem upřesnění se všemi nabízejícími nU nabídek Generálního dodavatele souběžně běží nabídkové řízení u subdodavatelů(zodpovědnost Generálního dodavatele) Výzva k nabídce nJasný popis požadované dodávky a služeb nČasto u projektů IS n 8 Výběr a vyjednávání •Hodnocení nabídek na základě předem připravených kriterií • •Výběr jednoho nebo více dodavatelů • •Konečné vyjednávání : rozsah služeb, typ ceny, garance, termíny Typ ceny: nPevná – u IS je dodavateli odmítána nProměnná – riziko nákladové exploze nNáklady + cílová částka se stanoveným stropem n 9 Typy cen 10 Pevná Náklady dodavatele HW+SW Zisk dodavatele Proměnná HW+SW Náklady + zisk dodavatele podle skutečné spotřeby času S cenovým stropem HW+SW Limitované náklady + zisk dodavatele > BQA (Balanced Quotation Analysis) - kroky 11 V etapě přípravy výběrového řízení: •Definice požadovaných funkcí a jejich důležitost (Nezbytné, Důležité, Opční) jejich ocenění na základě bodových hodnot (známek). •Definice dalších kriterií a jejich ocenění. •Definice vah požadovaných funkcí v hodnocení. •Definice vah dalších kritérií v hodnocení. •Zavedení kriterií a jejich hodnot do tabulky nastavení. > Nastavení BQA vah 12 Kategorie Požadavek Detaily Plnění Fj Priorita Pj Ocenění FVi Parametr: NUTNÉ 1,00 DŮLEŽITÉ 0,75 VOLITELNÉ 0,25 Vysvětlivky: Rozsah 100%= optimálně splněno 0% = nesplněno Jsou možné všechny hodnoty mezi! Nastaveno dle priorit projektu Součin plnění a priority > Nastavení BQA vah II 13 Kategorie Detaily Váha Kategorie Detaily Váha 1 = nízká 1 = nízká 10 = idůležitá 10 = důležitá Plnění funkčních požadavků. Úroveň plnění 10 Navrhované náklady HW 7 Reakce na RFP Čas reakce, úroveň komunikace 5 Integrace s web-shopem Možnost integrace s navrženým SW 5 Časový plán Míra přijetí požadovaného časového plánu 8 Akceptace koncernových pravidel 7 Penále Akceptují penále při zdržení projektu 8 Cena 10 Podmínky podpory Podmínky podpory jsou OK 6 Náklady na údržbu 9 SW moduly k dispozici Poměr standardních modulů k nutnému programování 6 Kvalita navrhovaného školení 2 Počet konzultantů 6 Koncept migrace dat 3 Reference Známé společnosti, rozsah dodávky 5 Součet vah W 97 > BQA – konkrétní výsledek 14 Kritéria Nabídka 1 Nabídka 2 Nabídka 3 Nabídka 4 Plnění funkčních požadavků. AF 10,07 9,95 10,00 9,97 Reakce na RFP AO1 5,15 3,09 4,12 2,58 Časový plán AO2 1,65 4,95 6,60 4,12 Penále AO3 8,25 8,25 8,25 - Podmínky podpory AO4 0,62 3,71 4,95 0,62 SW moduly k dispozici AO5 0,31 3,71 4,95 0,62 Počet konzultantů v projektu AO6 4,95 3,71 4,95 0,62 Přijetí koncernových zadání AO7 0,14 4,33 5,77 3,61 Cena AO8 5,15 6,19 8,25 5,15 Údržba – náklady AO9 5,57 5,57 7,42 4,64 Kvalita školení AO10 1,65 1,24 1,65 1,03 Převod dat AO11 2,78 1,86 2,47 1,55 Reference AO12 3,09 2,06 2,58 2,06 Vyhodnocení celkem ABA 49,38 58,62 71,96 19,9 > Smlouva Smlouva by měla obsahovat: nSpecifikaci zadavatele a dodavatele nPředmět smlouvy nRozsah prací nPodmínky platnosti smlouvy nTyp ceny a celkovou cenu zakázky nPodmínky a možnosti uplatnění změn nZpůsob a termíny plateb nZáruční podmínky a termín podpory a update programového vybavení nVýši a podmínky penalizace v případě nedodržení obsahu nebo termínů nUjednání pro případ předčasného ukončení prací nUjednání o utajování informací Některé z těchto bodů mohou být specifikovány v přílohách 15 Plánování v projektech IS qPlán převádí výsledky z předinvestiční fáze (studie proveditelnosti) do formy vhodné pro realizaci q qV oblasti IS je již zpravidla znám hlavní dodavatel, který se podílí na konkrétním plánování q qPodrobně se definuje Předmět projektu, který se dále konkretizuje do dílčích plánů HW, SW, časových návazností a lidských zdrojů q qVýstupem je závazný Projektový prováděcí plán 16 Projektový plán obecně obsahuje Definiční část: nČeho má být dosaženo a jakou formou (co, kdo) oCílový stav projektu oSoupis hlavních funkcí cílového stavu a činností týmu oStanovení organizačního systému projektu Část popisná a přiřazovací nJak dosáhneme cíle (jak, kdy, za kolik) oČasové plány oMatice zodpovědností oČasové plány nákladů a zdrojů oPlány rizik oPlány kontrolních procedur a mechanizmů V relevantních částech se neustále zpřesňuje 17 Podrobná definice cíle projektu CO bude v projektu vytvořeno V procesu plánování projektů IS se jedná o iterativní činnost paralelní s podrobným rozpisem funkcí. Jak vzniká: n výstup z workshopů – požadavky uživatelů n upřesnění cílů projektů n stanovení dalších cílů a omezení K čemu slouží: nZáklad pro návrh kriterií akceptace nVodítko pro vytváření detailních rozpisů nZdroj řízení kvality a provádění změnových řízení nOpěrný bod pro rozhodování a komunikaci v projektu 18 Časový plán projektu Obsahuje: nLogické hierarchické struktury úloh a úkolů a jejich časových sledů nÚdaje o předpokládané délce jednotlivých úloh nMilníky a důležité termíny projektu nVazby a souslednosti mezi úlohami a úkoly, formulované tak aby zůstaly zachovány i při změnách v harmonogramu n(plán zdrojů nutných k řešení úkolů a úloh) Forma nGantovy diagramy a diagramy milníků nSíťové diagramy oDiagramy PERT oMetoda kritické cesty odalší n 19 Časový plán projektu II Ganttův diagram 20 T1 T2 T3 T4 T5 Úkol A ● Úkol B ● Úkol C ● Úkol D ● Diagram milníků Princip propočtu síťových grafů Pojmy nDoba trvání činnosti nNejdříve možný začátek činnosti nNejdříve možný konec činnosti nNejpozději přípustný začátek činnost nNejpozději přípustný konec činnosti Kritická cesta : vede přes uzly jejichž nejdřívější a nejpozdější uzly jsou stejné (nulová časová rezerva). Metody síťových analýz: nCPM – jsou-li doby trvání činností známy ( určeny) nPERT – (Programm Evaluation and Review Technique) – jsou-li doby činností považovány za náhodné veličiny Znázornění síťového grafu: Ganttův diagram Znázornění čerpání zdrojů - Histogram n 21 Plánování a alokace zdrojů Plánování a alokace zdrojů vychází z: nPodrobného rozpisu prací nHarmonogramu projektu nNávrhu projektové organizace nDiskuze s liniovými manažéry a kandidáty na účast v projektu (dostupnost, kompetence..) nZávazku všech stran na způsob a rozsah účasti na projektu nMožných alternativních obsazení 22 Plánování a alokace zdrojů II Histogramy nGrafické vyjádření kumulovaných spotřeb času v průběhu projektu (za osobu) nUmožňují: oKompenzaci nadměrných kumulací u klíčových osob oSnížení zbytečných rozptylů činností mezi různé profese oBalancování členů týmu při použití nedostatkových technologií oOptimalizaci časových harmonogramů oOptimalizaci nákladů nBývají součástí všech dostupných SW pro plánování projektů 23 Plánování a alokace zdrojů III Zkušenosti z praxe: nPosledních 10% projektu často spotřebuji 30% zdrojů nPři obsazování se má začínat od nedostatkových zdrojů na činnosti na kritické cestě nPosunovat činnosti v harmonogramu tak, aby bylo dosaženo optimální využití kapacity specialistů nPokud je využití zdrojů na určitý úsek menší než 50%, lze potřebnou dobu zkrátit na polovinu nExterní dodavatelé často plánují specialisty na více projektů ve stejném čase s cílem maximalizovat fakturaci – problém pro manažéra projektu nHlavní dodavatelů často nemají kontrolu nad zdroji subdodavatelů nLinioví vedoucí s úspěchem prosazují realokaci jejich pracovníků pod záminkou ohrožení plnění úkolů. 24 Řízení a koordinace projektu Týmový management projektu je součástí celkového řízení a koordinace projektu. Do řízení a koordinace projektu patří: nVšechny aktivity zaměřené na provedení, časování a sladění prací definovaných v projektu nMotivace členů týmu nKomunikace v projektu nŘízení kvality nMarketing projektu n 25 Řízení projektu z pohledu dodavatele nNastartování projektu (dodavatelský kick off) nPlán projektu očlenění do základních funkcí očasový plán oplán odpovědností (dodavatel – odběratel) ofinanční plán a plán zdrojů (řešitelský tým) nDokumentace průběhu projektu oprotokoly, smluvní vztahy, změnová řízení oarchivace nŘízení práce s klientem nPrůběžné hodnocení termínů, kvality a nákladů 26 > Řízení projektu z pohledu odběratele oNastartování projektu (odběratelský kick off) oPlánování nčasový plán nplán zdrojů a kapacit (projektový tým) nplán sledování kvality oOrganizace projektu nřízení činnosti interních týmů nřízení požadavků na změny nřízení zaškolení uživatelů oŘízení práce s dodavatelem oSledování kvality oŘešení konfliktů a nenadálých situací 27 > Specifika řízení projektu IS z hlediska odběratele ofiremní strategie ovrcholové vedení a IS opřipravenost na změny ozdroje oúroveň IT oddělení obezpečnostní pravidla okompetence v období projektu o 28 > Specifika řízení projektu IS z pohledu dodavatele ovyplatí se to (vazba na přednášku 2) ozdroje ofinance osubdodavatelé ospecifika generální dodávky ometodologie 29 > Vstupy a výstupy procesu Řízení a koordinace dle Svozilové (upraveno) 30 Podproces Vstupy Výstupy Řízení a koordinace •Plán projektu, •Definice předmětu projektu, •Schválené změny, nápravné akce, preventivní akce, zprávy o opravách, výstupy dodávek/subdodávek •Výstupy projektu, •Požadované změny, •Provedené změny, nápravné akce, preventivní akce, opravy •Hlášení o postupu prací Výkon řízení kvality •Plán řízení kvality, •Ukazatele kvality, •Hlášení o postupu prací, •Schválené změny, •Provedené změny, nápravné akce, preventivní akce, opravy •Hlášení o kvalitě, •Požadované změny, •Aktualizace Plánu projektu, •Požadavky na změny v podnikových procesech/funkcích IS Obsazení projektového týmu •Plán projektu, disponibilní zdroje, •Podniková pravidla a metodiky (podniková kultura), •Organizační struktura projektu, •Plán obsazeni, role a odpovědnosti •Pověření zdrojů, •Aktualizace požadavků na zdroje, •Aktualizace Planu projektu Vstupy a výstupy procesu Řízení a koordinace II 31 Podproces Vstupy • Výstupy • Koordinace projektového týmu •Plán projektu, •Definice předmětu projektu, •Organizace projektového týmu, •Změny (všechny formy a stavy), •Souhrnné zprávy o stavu projektu, •Schválené výstupy projektu •Souhrnné zprávy o projektu – aktualizace, •Pokyny k provedení prací Distribuce informací •Plán řízení komunikace, firemní zvyklosti, •Organizační struktura projektu, •Schválené výstupy projektu •Souhrnné zprávy o projektu •Pokyny managementu •Informační zpětné vazby z firmy •Informační zpětné vazby z týmu •Informace o stavu projektu •Požadavky na změny informačních toků •Reakce na informační zpětné vazby Řízení rizik projektu Hlavní věcná rizika projektů v oblasti IT nŠpatná nebo neúplná definice cílů a požadovaných funkcí nPříliš optimistické časové plány nPodceněná etapa převodu dat nPodceněná výkonnost hardware (cena) nPodceněný vliv výkonnosti LAN / WAN nZdroje a kompetence dodavatele nMalá podpora projektu ze strany vrcholového vedení 32 Řízení rizik projektu II oPříčiny: npředvídatelné (velikost projektu, firemní kultura, kompetence týmu, motivace, kvalita smlouva s dodavatelem) nneovlivnitelné (legislativa, omezení zdrojů, ..) oCíle řízení rizika: nodstranění příčin vzniku možných rizik nomezení negativních důsledků rizik npříprava na možné důsledky rizikových událostí oMetody omezení rizik a jejich důsledků: nrizikový (katastrofický) scénář (pro IS naprostá nutnost) npravidelná kontrola kvality projektu nkomunikace s vedením podniku a pravdivá informace o stavu projektu 33 > Zodpovědnost v procesu kontroly projektu IS 34 > Vysvětlivky oV – vykonává oS - spolupracuje oI – informován oP - plánuje 35 > Zajištění kvality projektu okvalita je jedním z rizikových faktorů (viz trojúhelník náklady – termíny – kvalita) ozákladním prvkem je smlouva s dodavatelem npožadované funkce a jejich specifikace ntermíny nzáruky nproces řízení změn v projektu nkriteria kontroly kvality 36 > Metody řízení kvality projektu opravidelný sběr informací o stavu projektu o„ruční“ vyhodnocování je možné jen pro malé projekty oautomatizované sledování (např. MS Project) ntermíny a funkce nsledování kritické cesty nsledování vytíženosti zdrojů otaktiky jednání při zjištění problémů nkonsensuální : je vždy výhodné pro udržení týmu nkonfliktní : v případě opakovaných problémů n 37 > Metody vývoje software oVodopádový model je sekvenční vývojový proces, ve kterém je vývoj nahlížen jako neustále se svažující tok (jako když teče vodopád) fázemi analýzy požadavků, návrhu, implementace, testování (validace), integrace a údržby. 38 > Metody vývoje software 39 > Metody vývoje software oHlavními principy vodopádového přístupu: nProjekt je rozdělen na fáze jdoucí postupně za sebou, přičemž některé se mohou překrývat. nDůraz je kladen na plánování, časové rozvrhy, termíny, rozpočty a realizace celého systému najednou. nPřísná kontrola je udržována po celou dobu životnosti projektu prostřednictvím využití rozsáhlých písemných dokumentů, jakož i prostřednictvím formálních revizí a schvalování uživatelem (signoff) a na konci většiny fází a vstupy od managementu informačních technologií před začátkem další fáze. 40 > Metody vývoje software oPrototypový přístup: ndochází k vývoji neúplných verzí software, tzv. prototypů. 41 > Metody vývoje software oZákladní principy prototypového přístupu nNení samostatným a kompletním přístupem metodiky vývoje, ale spíše přístup k jednotlivým částem větších tradičních metodik vývoje software (tj. přírůstková metoda, spirála, nebo RAD - Rapid Application Development). nSnaha snížit nebezpečí projektových rizik rozdělením projektu na menší části a zjednodušit tak možnost změn v průběhu procesu vývoje. nUživatel je zapojen v celém procesu vývoje, což zvyšuje pravděpodobnost přijetí konečné implementace uživatelem. nMalé ukázky systému jsou vyvíjeny iterativním procesem, dokud se prototyp nevyvine tak, že splňuje požadavky uživatele. nVětšina prototypů je sice vyvíjena s tím, že budou vyřazeny, ale v některých případech je možné pokročit od prototypu k funkčnímu systému. nAby se předešlo vývoji, který řeší jiný problém, než bylo zadáno, je třeba pochopit základní business problematiku. o o 42 > Metody vývoje software oPřírůstkový (inkrementální) přístup oInkrementální přístup je vhodný pro kombinaci sekvenčních a iteračních metodik softwarového vývoje. oCílem je omezit projektová rizika rozdělením projektu na menší segmenty a zjednodušuje možnost zavedení změn během procesu vývoje. o 43 > Metody vývoje software oZákladní principy inkrementálního přístupu: nJsou prováděny série malých vodopádů, kde každý vodopád je prováděn pro malou část systému a je dokončen před pokračováním na další přírůstek, nebo nobecné požadavky jsou definovány dříve než se přikročí k evolučnímu vývoji pomocí malých vodopádů pro jednotlivé přírůstky systému, nebo nPrvotní koncept, analýza požadavků, design architektury a systémové jádro jsou definovány vodopádovým přístupem, následuje iterativní prototypový přístup, který vrcholí instalací konečného prototypu jako funkčního systému. o 44 > Metody vývoje software oSpirálový přístup je proces vývoje software, který kombinuje prvky designového přístupu a prototypového přístupu tak, aby zkombinoval výhody obou konceptů shora-dolů (prototypování) a zdola-nahoru (designování). oZákladní principy spirálového přístupu: nZaměřuje se na analýzu rizik a minimalizaci projektových rizik rozdělením projektu na menší segmenty a umožněním změn během procesu vývoje. V průběhu vývoje je také možné vyhodnocovat rizika a zvažovat další pokračování projektu v průběhu životního cyklu. o 45 > Metody vývoje software nKaždý cyklus spirály spouští stejný sled kroků pro každou část produktu a pro každou úroveň elaborace (od konceptuálních dokumentů až po programování jednotlivých programů). o 46 > Otázky? Děkuji za pozornost 47