Hledejte v chronologicky řazené databázi studijních materiálů (starší / novější příspěvky).

Stanovení kritérií pro výběr CASE nástroje

. Stanovení kritérií pro výběr CASE nástroje
• Výrobce, distributor
 Servis (podpora produktu, hotline, aktualizace)
 Vazby na výrobce HW a SW, podporované standardy
• Reference
 Kdo jsou hlavní uživatelé tohoto produktu, k čemu jej používají a jak jsou s ním spokojeni.
• Podporovaná metodika
 Volba metodiky záleží hlavně na zkušenostech vývojářského týmu, je rovněž možné částečně kombinovat objektové a strukturované metodiky (typickým příkladem je provedení objektové analýzy aplikace a návrhu databáze ve strukturované metodice)
 Základní pravidlo: vybírat CASE nástroj podle metodiky, ne přizpůsobovat metodiku podle zakoupeného nástroje
• Možnost automatického přechodu mezi jednotlivými fázemi vývoje IS
 Automatický přechod mezi fázemi projektu v rámci zvoleného nástroje
 Možnost integrace s dalšími nástroji, které budou v rámci projektu využity.
• Správa požadavků a sledování jejich plnění
 Mezi požadavky na systém a jejich plněním musí být zcela zřetelný vztah. Jestliže nástroj nedisponuje modulem pro evidenci a analýzu požadavků, měl by být s takovým nástrojem alespoň integrován.
• Možnosti automatické dokumentace
• Parametry repository
 Výkon, přijatelná doba odezvy (měřeno samozřejmě pro velikost projektu, na který je nástroj nasazen)
 Je repository vedená v proprietárním formátu daného výrobce nebo ukládá data do databáze?
 Pokud vývoj probíhá na více platformách, je repository přenositelná mezi těmito platformami?
• Možnost customizace CASE nástroje
 Je výhodné, pokud nástroj používá nějaký rozšířený standard (např. OLE) a dodávají se k němu zdrojové kódy rozhraní pro repository, které je možno upravit podle vlastních potřeb.
 Další možností je, pokud nástroj disponuje jazykem pro svoji customizaci
• Podpora týmové práce
 Podpora verzování
 Podpora sdílení komponent mezi vývojáři
• Správa projektu
 Disponuje CASE nástroj možností vygenerovat report o stavu projektu?
• Kontrola konzistence
 Kontrola konzistence pro jednotlivé modely
 Kontrola konzistence mezi modely
 Možnost nastavení parametrů pro kontrolu konzistence
• Generování kódu aplikační logiky
 Podporuje nástroj používané implementační prostředí?
 V případě použití různých programovacích jazyků pro jednotlivé vrstvy systému by CASE měl zajistit jejich konzistenci (např. správné namapování datových typů)
• Round Trip Engineering
 Možnost provádět změny ve vygenerovaném kódu, aniž by se narušila vazba mezi vygenerovaným kódem a návrhem systému. Jestliže programátor provede změnu v kódu (např. přidá ve třídě další metodu), zanese se tato změna automaticky do diagramu, kde je tato třída modelována.
• Reverse Engineering
 Reverse engineering je možnost, jak zahrnout do analýzy či návrhu systému již hotový zdrojový kód. Ten se procesem reverse engineeringu transformuje do diagramů. Celé diagramy nebo jejich části lze potom považovat za součást návrhu systému.
• Možnost znovupoužití částí analýzy či návrhu pro další podobné projekty
• Požadavky na HW a operační systém
• Uživatelské rozhraní
• Modularita nástroje
 Spíše finanční kritérium, možnost zakoupit pouze ty moduly, které při vývoji systému využiji.
• Cena
4. Seznámení se s nabízenými produkty
Při výběru CASE nástroje by zájemce měl mít možnost jednotlivé produkty prakticky vyzkoušet – nejlepší jsou pro tento účel trial verze v podobě ostrých verzí SW s časovým omezením (typicky 30 dnů).
5. Multikriteriální výběr CASE nástroje
Výběr produktu na základě výše stanovených kritérií a dojmů z testování.

CASE nástroj – obecné schéma

CASE nástroj – obecné schéma

obr. 3 – Obecné schéma CASE nástroje
Možnosti počítačové podpory jednotlivých činností v rámci projektu vývoje SW
Správa požadavků
• Evidence požadavků na funkcionalitu a výkon systému
• Zajištění konzistence a úplnosti požadavků
• Řízení změn
Příklad SW pro automatizovanou správu požadavků: Rational RequisitePro
Modelování business procesů
• Modelování entit a datových toků mezi nimi na podnikové úrovni (umožňuje např. ARIS, Select Enterprise)
Analýza a návrh
• Modelování funkcionality systému (zajišťují všechny nástroje pokrývající kategorii Middle CASE – tj. Rational Rose, Select Enterprise, Power Designer)
• Modelování datových struktur (např. XTG Data Modeller)
• Zajištění konzistence v rámci modelů i mezi modely
Konstrukce
• Automatické generování částí kódu – např. vygenerování databázového skriptu na základě modelu (např. XTG Data Modeller)
• Generování „rámcového kódu“: CASE nástroj vygeneruje pouze strukturu programu - hlavičky, parametry funkcí, atd. (příklad: Rational Rose)
• Automatizovaný návrh uživatelského rozhraní
• Automatizovaný vývoj expertních systémů (prázdné expertní systémy jako např. E-Mycin nebo SAK)
• Reverse Engineering (generování modelu z kódu) a Round Trip Engineering - model je stále udržován konzistentní s kódem. Příklad: Rational XDE.
• Integrovaná vývojová prostředí: různé pomůcky při psaní zdrojového kódu, možnost kompilace a spouštění programu přímo ve vývojovém prostředí (příklad: C++ Builder, Delphi, JBuilder).
Testování
• Testování výkonu systému: např. Rational Test Realtime
• Testování při změnách systému: používá se jedna série testů, která se aplikuje na daný SW produkt při každé jeho změně.
• Debugging (např. debuggery ve vývojových prostředích typu C++ Builder)
• Řízení a organizace testů
Příklad SW pro podporu testování: Rational PurifyPlus, Test RealTime, Rational Suite TestStudio
Řízení a monitorování projektu
• Plánovací systémy (např. MS Project)
• Systémy pro generování reportů o stavu projektu, návrh a sledování metrik projektu (např. Rational ProjectConsole)
Dokumentace
• Workflow systémy (např. Oracle Workflow)
• Systémy pro podporu práce ve skupinách a sdílení dokumentů – workgroups (např. Lotus Notes)
• Automatizovaná tvorba dokumentace (např. Rational SoDA)
• Reverse engineering (převod zdrojového kódu na grafický model, např. modul C++ Analyzer v Rational Rose)
Konfigurace systému
• Nástroje pro automatizovanou správu konfigurace a verzování
Příklad: Rational ClearCase
Řízení kvality
• Odstraňování chyb SW
• Monitorování a protokolování chodu systému, sledování základních parametrů (dostupnost, střední doba mezi závadami, střední doba opravy závady…)
• Řízení servisních úkonů
Příklad SW pro řízení změn a detekce+odstraňování chyb: Rational ClearQuest
Rozdělení CASE nástrojů podle úrovně abstrakce
• Upper CASE: nástroje pracující na nejvyšší úrovni abstrakce (business modely, analýza)
• Middle CASE: nástroje podporující modelování v rámci designu, vazba na Lower CASE
• Lower CASE: vývojová prostředí nad 3GL nebo 4GL.
Specifické nástroje podporující pouze určitou činnost – např. návrh databáze.
Obecná metodika výběru CASE nástroje
1. Vymezení organizace, pro kterou je CASE nástroj pořizován
Příkladem může být vývoj SW pro podporu automatické montážní linky, kde bude CASE nástroj muset podporovat znázornění realtimových operací.
2. Definování využití CASE
CASE nástroje lze během životního cyklu SW používat k různým účelům:
• Vývoj SW
 Podpora správy požadavků
 Podpora analýzy a návrhu
 Podpora implementace
 Možnost automatického generování kódu
 Automatická dokumentace
 Podpora testování
 Možnost tvorby prototypů
 Možnost předávání práce mezi jednotlivými vývojáři
• Zpětná analýza IS: Využiji hlavně v situaci, kdy mám již fungující systém, ale je špatně zdokumentovaný a tím de facto neudržovatelný.
 Reverse engineering
 Možnost částečné automatizace při dokumentování stávajícího systému
• Oblast rozvoje IS
 Modelování systému na nejvyšší úrovni abstrakce
 Řízení projektů vývoje IS

Objektová metodika versus CASE nástroj podporující strukturovaný přístup

Objektová metodika versus CASE nástroj podporující strukturovaný přístup
CASE nástroj je součástí metodiky, životní cyklus SW vyvíjeného objektovou metodikou proto nelze komplexně podpořit CASE nástrojem podporujícím pouze strukturovaný přístup. Nástroj podporující strukturovanou metodiku lze použít pouze jako doplněk – typicky pro návrh databáze. Pokud by se zákazník dokázal smířit s takto nízkým stupněm využití svého nástroje, mohl bych mu vyhovět. V opačném případě nikoliv.
Přínosy objektového přístupu
Problémy strukturovaných metodik:
• Oddělení datového a funkčního modelu, problém zajištění jejich konzistence
• Oddělení funkčního modelu od modelu řízení – model řízení využívá abstrakci založenou na generalizaci (tj. vyšší úroveň řízení není nadmnožinou nižších úrovní), zatímco funkční model je tvořen s použitím přístupu agregace. Důsledkem je, že řídící proces je vždy elementární, řízené funkce se ale mohou rozpadat do nižších úrovní. Zde je však rozpor, neboť řízení dekomponovaných funkcí určitého subsystému nelze považovat za podmnožinu řízení tohoto subsystému.
• Transformace konceptuálního modelu do modelu technologického – nedostatky v konceptuálním modelu se zákonitě přenášejí do modelu technologického
Objektový přístup je nepochybně krokem vpřed, neboť:
• Eliminuje výše uvedené problémy s oddělením jednotlivých modelů, dívá se od počátku na systém jako na celek.
• Eliminuje nedostatky strukturovaného přístupu vyplývající z potřeby dekompozice systému ještě předtím, než je k dispozici dostatečné množství informací (tj. top-down přístup)
• Objektový přístup umožňuje přírůstkový vývoj SW a tak výrazně eliminuje rizika spojená s vývoje IS. Zapracování změn (např. přidávání komponent, změny funkcionality) je v objektovém přístupu snazší.
• Objektová notace je z hlediska zadavatelů považována srozumitelnější než strukturovaná

Modelování

Modelování
Definice modelu:
• Znázornění zkoumaného jevu sloužící jako vyjádření skutečnosti.
• Zjednodušené zobrazení určitého jevu (systému) znázorňující pouze ty rysy, které jsou podstatné z hlediska cíle, který při tvorbě modelu sledujeme.
• Reprodukce charakteristik určitého objektu na jiném objektu, zvláště vytvořeném pro jejich studium.
Principy modelování:
• Model je formulován jako systém: souhrn prvků a jejich vazeb. Povaha prvků a vazeb je dána hlediskem modelu (data/operace).
• Hraniční prvky systému: představují kontext systému, jejich pomocí jsou definovány vstupy a výstupy systému (podněty a reakce systému na ně).
• Objektivní obsah modelu: každý prvek modelu odpovídá nějakému objektu reálného světa (existují zde však i „pomocné prvky“ zajišťující transformaci reálného světa do technologické podoby).
• Vnitřní struktura systému (uspořádání prvků) vždy odpovídá struktuře reálního světa.
Smysl modelování
• Abstrakce – při modelování zohledňuji pouze podstatné rysy reality, od nepodstatných abstrahuji
• Formalizace – formalizovaný model je prostředkem komunikace mezi zadavatelem a řešitelem
• Možnost provádět změny – v modelu je provádění změn jednodušší a lacinější než v realitě (kde je to zpravidla i nemožné)
• Jednoznačnost – každý datový prvek nebo operace musí být obrazem podobného prvku v realitě
• Redundance – model by měl umožnit lepší odstraňování redundancí a z nich plynoucích možností nekonzistence systému.
Způsob modelování pomocí abstrakcí
• Třídy a entity: Entity sdílející společné charakteristiky jsou sdružovány do tříd, entita nemůže existovat bez přítomnosti k třídě.
• Agregace: Spojování více entit do entity vyšší úrovně.
• Asociace: Spojování entit, nevytváří novou entitu.
• Atributy: Dvousměrný vztah mezi dvěma třídami entit, používá se pro vyjádření charakteristik tříd entit.
• Seskupení: Vytvoření množiny určitých entit, na rozdíl od třídy není entitou na metaúrovni.
• Specializace a generalizace – viz výše

Metodika

Vysvětlení pojmů
Metodika
Doporučovaný souhrn přístupů, zásad, etap, postupů, pravidel, dokumentů, řízení, technik a nástrojů pro tvůrce IS, který pokrývá celý životní cyklus IS. Metodika tedy určuje „kdo“, „co“ a „kdy“ má dělat. Každá metodika by měla ošetřovat následující problémy:
• Orientace na cíle a problémy: hledání cílů organizace a IS, hlavně v počátečních fázích vývoje.
• Účast zadavatele a klíčových uživatelů po celou dobu vývoje
• Klíčové dokumenty a vymezení způsobu jejich schvalování
• Modelování a abstrakce, princip 3 architektur (viz níže)
• Ověřování a testování návrhu během celého vývoje
• V každé etapě probíhá analýza i návrh (tj. návrh se postupem času zpodrobňuje). V případě změny kteréhokoli požadavku je třeba návrh vrátit do fáze, v níž byl tento požadavek definován (princip iterativního vývoje)
• Vývoj probíhá z hlediska všech úhlů pohledu na systém
 Data
 Funkce
 Organizace
 Lidé (kvalifikace)
 Technologie
 Ekonomická hlediska
• Otevřenost metodiky: měla by používat standardní a ověřené metody a techniky návrhu
Příklady metodik
• Státem podporované a vlastněné
 SSADM (Structured System Analysis and Design Method)
 SDM (System Development Methodology)
 MERISE
 V-MODEL
• Firemní metodiky
 Rational Unified Process (Rational)
 SE (LBMS)
 Oracle CASE*Method
• Vyvíjené v ČR
 MDIS (KIT)
 PDIT (KIT+PragoData)
Metoda
Určuje, co je v dané fázi projektu třeba udělat. Vždy je závislá na zvoleném přístupu (např. datové modelování, objektový přístup). Metoda tedy řeší postup činností v určité uzavřené části (fázi) vývoje IS.
Příklady metod
• ISAC – informační analýza
• YSM – Yourdon structured method
• Jackson System Planning
• BSP – Business system planning
Technika
Určuje postup, jak se dobrat požadovaného výsledku. Zpravidla stanovuje způsob použití jednotlivých nástrojů, rozhodování v určitých situacích.
Příklady technik
• Transakční analýza
• Normalizace datového modelu
• Yourdonova funkční analýza
• Chennovo datové modelování
• Transformace konceptuálního schématu do logické úrovně návrhu
Nástroj
Prostředek vyjádření určité činnosti podporující určitou techniku. Nástroje formalizují znázornění reality, zpravidla uvažujeme automatizované nástroje s grafickým rozhraním.
Zdroj: [1], s.47
Příklady nástrojů
• DFD
• ERD
• STD (State transition diagram)
• Class diagram

Principy metod analýzy a návrhu systému

Principy metod analýzy a návrhu systému
Princip abstrakce
Definice: Myšlenkový proces odlučující odlišnosti a zvláštnosti a zjišťující obecné a podstatné vlastnosti předmětů a jevů, záměrná nekonkrétnost.

obr. 1 - klasifikace abstrakcí
• Jednoúrovňové abstrakce: Celý systém je rozdělen do na oblasti - substruktury. Každá oblast zohledňuje pouze určité aspekty, od ostatních abstrahuje. Příkladem je systém pohledů (modelů) – datový model, funkční model…
• Víceúrovňové abstrakce:
 Hierarchické (stromové): Dělení celku na části, sdružování částí do celku.
 Kolektivizace: Abstraktní pojem vyjadřuje pouze účelové sdružení prvků a nikoliv jejich společné vlastnosti. V metodách strukturované analýzy se jedná o tzv. Top-Down přístup (viz níže).
 Generalizace: Abstraktní pojem vyjadřuje sdružení prvků na základě jejich společných vlastností, tj. dědičnost.
• Vrstvené: Každý prvek nižší vrstvy představuje detailní rozpracování prvku vyšší vrstvy. Prvek nižší vrstvy vždy přejímá veškeré detaily od nadřízeného prvku vyšší vrstvy, tj. lineární struktura. Příkladem je princip 3 architektur (viz dále).
Top-Down hierachie funkcí (princip kolektivizace)
Princip Top-Down využívá rozdělení pohledů na systém podle úrovně podrobnosti. Na nejvyšší úrovni je hrubý pohled na celý systém, ten se dále rozpadá na jednotlivé subsystémy, které jsou popsány detailněji. Na nejnižší úrovni jsou pak dále nedělitelné elementární části systému, tzv. listy stromu.
Vazby jsou vždy následujících typů:
• Vertikální: prvek vyšší úrovně se skládá z prvků nižší úrovně
• Horizontální: Interakce prvků na stejné úrovni abstrakce. Interakce prvků z různých větví stromu vyplývá vždy z interakce nadřízených prvků, jsou tak vyloučeny redundance.
Původně byl princip top-down zamýšlen pro návrh komplexních IS pomocí dekompozice, v praxi však nebyl příliš úspěšný. Hlavní význam je proto dokumentační – přehledný popis logického uspořádání systému.
Vztah generalizace a specializace
• V modelu tříd: dědičnost
• V datovém modelu: nadtypy a podtypy, podtypy mají všechny vlastnosti nadtypu, navíc doplňují nějaké vlastní. Všechny podtypy jednoho nadtypu jsou navíc navzájem disjunktní, dávají úplný popis všech možností (klasifikace úplná a minimální).
Princip tří architektur
Definuje způsob použití abstrakce pro vývoj IS po jednotlivých vrstvách (tj. vrstvená abstrakce). Návrh IS probíhá v následujících krocích (architekturách). Každá architektura má vlastní jazyk a techniky návrhu, je definována technika přechodu k následující úrovni.
• Konceptuální: Řeší, co je obsahem systému. Abstrahuje od technologických a implementačních řešení.
• Technologická: Model systému zohledňující technologickou koncepci řešení (např. organizace dat v relační DB, architektura C/S apod.). Technologický návrh určuje, jak je obsah systému v dané technologii realizován. Tato úroveň abstrakce ještě nezohledňuje konkrétní vývojové prostředí.
• Implementační: Určuje čím je zvolené technologické řešení realizováno – tj. konkrétní databázový systém, programovací jazyk
Důvodem je rozdělit návrh systému na etapy a docílit vyšší pružnosti změn systému. Vlastnímu zapracování změn vždy předchází určení, jaké architektury se změna týká:
• Implementační: např. opravy programů, upgrade databázového systému
• Technologické: např. přechod z indexsekvenční organizace dat na relační DB
• Konceptuální: např. potřeba přidání další funkcionality systému, zapracování změn v řešené oblasti.
S tím souvisí i náklady na odstranění chyby – čím později je chyba odhalena, tím vyšší jsou náklady.
Princip plošné abstrakce – různé pohledy na systém
Celostní pohled na vyvíjený systém, uplatňuje se ve strukturovaném přístupu a s určitými modifikacemi i v přístupu objektovém. Rozlišuje základní dimenze:
• Funkční: popis chování systému. Zahrnuje konceptuální funkční model a částečně i model programové struktury
• Datovou: popis dat uložených v systému. Zahrnuje konceptuální datový model a model logických datových struktur.
• Řídící: popis časových souvislostí jednotlivých činností systému. Zahrnuje konceptuální model řízení, částečně funkční model a odpovídající model programové struktury.
• Technologickou: popis technologické realizace funkcí – totéž jako technologická architektura v předchozím oddílu. Zahrnuje model programové struktury a model logických datových struktur.

Průběh výběrového řízení dle metodiky ČSSI

Průběh výběrového řízení dle metodiky ČSSI
1. Formulace informační strategie podniku
2. Příprava soutěže
– jmenování výběrové komise (top management, IT, externí konzultant)
– tvorba poptávkového dokumentu (detailní vymezení funkcionality systému, kritéria pro hodnocení nabídek)
3. Vyhlášení soutěže
4. Přihlášení dodavatelů do soutěže, poskytnutí poptávkových dokumentů
5. Vyhodnocení nabídek
– vyřazení nabídek nesplňujících základní kritéria
– detailní hodnocení zbývajících nabídek (do dalšího kola postoupí 4-6 nabídek)
6. Analýza referenčních instalací (patrně nejdůležitější část výb. řízení)
7. Prezentace nabídek, diskuse
– výběr 3 nejlepších uchazečů
8. Vypracování úvodní studie dvěma nejlepšími uchazeči (na úvodní studii se uzavírá zvláštní smlouva, UST hradí zadavatel)
9. Vyhodnocení UST, uzavření smlouvy s vítězem výběrového řízení (pokud se nedohodnou, uzavře zadavatel smlouvu se 2. nebo 3. uchazečem)
10. Činnosti po uzavření smlouvy (spolupráce zadavatele a dodavatele na tvorbě IS)
Náležitosti smlouvy o dodávce komplexního IS
Právní vztahy v rámci systémové integrace jsou ošetřovány zejména následujícími typy smluv:
• Smlouva o dílo – doporučuje se pojmout jako rámcovou smlouvu, která upravuje náležitosti dalších obchodněprávních vztahů v rámci SI. Smlouva o dílo se rovněž použije pro následující části projektu:
 Zhotovení zakládací listiny projektu, úvodní studie, projektové dokumentace…
 Implementaci IS
• Kupní smlouva
 Je-li předmětem systémové integrace i dodání HW či jiného materiálu (Obchodní zákoník vylučuje ošetření takového právního vztahu smlouvo o dílo).
• Inominátní (nepojmenované) smlouvy. Pro následující vztahy se používají speciální smlouvy, které nejsou upraveny ObchZ:
 Smlouvy o poskytnutí práv k užití IS (časová omezenost práv, výlučnost užití, převoditelnost práv, stanovení poplatků za údržbu)
 Smlouvy o školení uživatelů
 Smlouvy o poskytování služeb podpory a údržby – činnosti nad rámec smluvní záruky nezbytné pro správný chod systému.
Typická struktura smlouvy o SI
• Smluvní strany – zhotovitel+objednatel
• Vysvětlení použitých termínů. Tyto jsou pak zpravidla v textu uváděny velkým písmenem.
• Předmět smlouvy
 Analýza a návrh komplexního IS včetně integrace stávajících komponent IS, které nebudou předmětem řešení.
 Vývoj a dodávka IS, řešení problémů vzniklých v průběhu projektu
 Migrace dat ze stávajícího IS
 Dokumentace projektu, školení uživatelů
 Záruční a pozáruční servis a úpravy IS
• Cena
 Možné přístupy stanovení ceny
 Time & material: cena závisí na době trvání projektu a využitých zdrojích. V takovém případě vede zhotovitel tzv. Activity Reports.
 Fix time & price: pevná cena a doba trvání projektu stanovená ve smlouvě
 Inflační či kursové doložky: možnost úpravy ceny v závislosti na vývoji inflace nebo výkyvech kursu domácí měny objednatele k měně zahraničního dodavatele.
• Platební podmínky
 Platby budou probíhat podle smluveného platebního kalendáře
 Neexistuje-li platební kalendář, stanoví se ve smlouvě náležitosti faktur, forma platby, splatnost a úroky z prodlení s placením.
• Termín plnění
 Termín plnění, jednotlivé kontrolní dny a další náležitosti jsou zaznamenány v Plánu projektu, který je přílohou této smlouvy.
• Předání a převzetí plnění
 Akceptační procedura: vymezení akceptačních kritérií a plánu akceptačních testů. Identifikace vad produktu v rámci akceptačních testů:
 Vada první úrovně: brání základnímu užívání systému, akceptační testy je třeba pozastavit do odstranění této vady.
 Vada druhé úrovně: brání užívání části systému, systém není schopen zpracovat požadovanou provozní zátěž.
 Vada třetí úrovně: Způsobí částečný neúspěch akceptačních testů, neohrožuje provoz systému a uložená data.
 Vada čtvrté úrovně: pouze kosmetická vada, neohrožuje provoz.
Dle smluvních podmínek doporučovaných ČSSI se akceptační testy považují za úspěšné, pokud systém nevykazuje ani jednu vadu 1. a 2. úrovně a maximálně 5 vad 3. úrovně.
 Ověřovací provoz: ostrý provoz se skutečnými daty, stanovena délka ověřovacího provozu a sledovaná kvalitativní kritéria provozu. Opět se sledují výše uvedené 4 úrovně vad.
• Předání a převzetí dokumentace: Dokumenty vymezené ve smlouvě předá zhotovitel objednateli jako návrh, objednatel vypracuje případné připomínky, které zhotovitel následně do těchto dokumentů zapracuje.
• Práva a povinnosti smluvních stran
 Zhotovitel
 Předat stanovené plnění dle časového harmonogramu
 Zajistit odpovídající počet pracovníků s potřebnou kvalifikací (dle předimplementační studie)
 Informovat objednatele o průběhu prací a případných problémech
 Objednatel
 Poskytnout požadovanou součinnost
 Jmenovat pracovníka pověřeného stykem se zhotovitelem
 Zajistit zhotoviteli spolupráci s klíčovými osobami z hlediska realizace projektu
• Smlouva by měla též upravovat součinnost a komunikaci objednatele a zhotovitele
 Určení způsobu předávání informací (pravidelné schůzky, pravidla pro používání e-mailu, záznamy o tom, kdo komu co předává, atd.)
 Povinnost objednatele a zhotovitele vzájemně se informovat o důležitých skutečnostech
 Vymezení organizační struktury projektu
• Vlastnická práva k předmětu plnění nebo jeho části: přecházejí na objednatele dnem úplného zaplacení předmětu plnění nebo jeho části
• Práva k užití
 Objednatel smí dílo používat v souladu s licenčními podmínkami uvedenými ve smlouvě nebo obecnými licenčními podmínkami (ustanovení o prodeji/pronájmu díla, vytváření kopií apod.).
 Možnost ustanovení o výlučném používání díla objednatelem
• Odpovědnost za škody
 Odpovědnost za škody vzniklé zhotoviteli
 Odpovědnost za škody vzniklé objednateli
• Záruka
 Záruční lhůta (délka, od kdy začíná běžet)
 Za jaké škody či vady vzniklé během záruční lhůty odpovídá zadavatel
 Záruka za komponenty dodané třetími stranami
 Postup při reklamaci, možnost servisu systému třetími osobami
• Změnové řízení
 Podmínky pro zahájení změnového řízení
 Postup změnového řízení
• Přílohy
 Popis funkcionality systému
 Popis architektury systému
 Plán (harmonogram) projektu
 …
Řešení v případě integrace zadavatelem
Oproti systémové integraci prováděné jinou firmou jsou zde tyto rozdíly:
• Absence smlouvy na úvodní studii
• Rozdíl v pojetí projektu (tedy jiný předmět smlouvy) – zatímco u SI prováděné externí firmou je výběr subdodavatelů z hlediska zadavatele transparentní, budou v tomto případě uzavírány dílčí smlouvy s jednotlivými dodavateli HW/SW komponent, jejich výběr bude muset zajistit sám zadavatel.

Zdroj:
Materiály k přednáškám IT_583.
Příručka pro tvorbu a hodnocení smluv na návrh a dodávku IS, ČSSI 2000
Úloha - předpoklady:
Předpokládejte komplexní dodávku ERP systému do strojírenského podniku.
Zadání:
Jaké ustanovení smlouvy byste navrhoval, aby byl dodavatel závislý na přínosech, které ERP podniku přinese?
Základem je rozdělení ceny produktu na dvě části – fixní, kterou zadavatel zaplatí při dodání, a zásluhovou, kterou zaplatí v závislosti na přínosech vyplývajících z nasazení SW. Pro tento případ je třeba stanovit metriky, na jejichž základě se bude nárok na tuto odměnu stanovovat. V případě ERP systému by se mohlo jednat např. o:
• Zkrácení průměrné doby vyřizování objednávky o x dní
• Zvýšení obratu o x%
• Snížení množství skladovaného materiálu o x%, zkrácení obratu zásob o x dní

Nejpoužívanější ASP služby

Nejpoužívanější ASP služby (tj. již skutečně využívané):
• 50% web hosting (které ale většinou nejsou považovány za ASP služby, ale spíše za služby internetových providerů)
• 44,7 messagingu (správa poštovních serverů a systémů, např. správa MS Exchange)
• 39,5 office productivity (kancelářské aplikace)
• 10,5 ERM (Enterprise Relashionship Management0

ASP služby, které by respondenti chtěli využívat (jejich využití teprve chystají/plánují):
• 45,9 messaging
• 45.9 specializované vertikální aplikace
• 45,1 aplikace z oblasti e-commerce
• 43,6 office productivity
• 43,6 online training (vzdělávání a školení on-line)
• 31,6 resource hosting (např. web hosting, server housing atd.)

Hodnocení přínosů ASP modelu pro uživatelské subjekty:
• 75,6% respondentů považuje za přínos to že ASP nahrazuje nedostatek vlastního IT personálu
• 67,6 poskytování specializovaného know-how vztahujícího se k provozované aplikaci
• 23,5 větší možnost volby

Hodnocení nedostatků a problémů ASP modelu z pohledu uživatelských subjektů:
• 59,7 rychlost sítě (komunikačního spojení)
• 59,0 absence "vlády nad aplikacemi"
• 54 bezpečnost
• 14,4 nekompatibilita platforem

Preference způsobu (techniky) poskytování ASP služeb
• 50,3 respondentů dává přednost využívání ASP služeb skrze WWW (a WWW browsery)
• 23,8 uživatelů dává přednost Windows aplikacím (formou vzdáleného grafického terminálového přístupu)
• pro 21 tato otázka nerozhoduje

Požadavky uživatelů na poskytovatele ASP služeb
• 95,5 respondentů hodnotí jako významnou nabídku školení koncových uživatelů
• 78,9 respondentů hodnotí jako významný aspekt spolehlivost
• 68,8 bezpečnost (zabezpečení)
• 61 dostupnost přenosových kapacit
• 24,6 ochota ASP subjektu přizpůsobit aplikace specifickým požadavkům uživatelů

Preference v oblasti placení za ASP služby
• 47,6 respondentů dává přednost měsíčnímu paušálu za neomezené využívání služeb

Průběh výběrového řízení dle metodiky ČSSI

Průběh výběrového řízení dle metodiky ČSSI
1. Formulace informační strategie podniku
2. Příprava soutěže
– jmenování výběrové komise (top management, IT, externí konzultant)
– tvorba poptávkového dokumentu (detailní vymezení funkcionality systému, kritéria pro hodnocení nabídek)
3. Vyhlášení soutěže
4. Přihlášení dodavatelů do soutěže, poskytnutí poptávkových dokumentů
5. Vyhodnocení nabídek
– vyřazení nabídek nesplňujících základní kritéria
– detailní hodnocení zbývajících nabídek (do dalšího kola postoupí 4-6 nabídek)
6. Analýza referenčních instalací (patrně nejdůležitější část výb. řízení)
7. Prezentace nabídek, diskuse
– výběr 3 nejlepších uchazečů
8. Vypracování úvodní studie dvěma nejlepšími uchazeči (na úvodní studii se uzavírá zvláštní smlouva, UST hradí zadavatel)
9. Vyhodnocení UST, uzavření smlouvy s vítězem výběrového řízení (pokud se nedohodnou, uzavře zadavatel smlouvu se 2. nebo 3. uchazečem)
10. Činnosti po uzavření smlouvy (spolupráce zadavatele a dodavatele na tvorbě IS)
Náležitosti smlouvy o dodávce komplexního IS
Právní vztahy v rámci systémové integrace jsou ošetřovány zejména následujícími typy smluv:
• Smlouva o dílo – doporučuje se pojmout jako rámcovou smlouvu, která upravuje náležitosti dalších obchodněprávních vztahů v rámci SI. Smlouva o dílo se rovněž použije pro následující části projektu:
 Zhotovení zakládací listiny projektu, úvodní studie, projektové dokumentace…
 Implementaci IS
• Kupní smlouva
 Je-li předmětem systémové integrace i dodání HW či jiného materiálu (Obchodní zákoník vylučuje ošetření takového právního vztahu smlouvo o dílo).
• Inominátní (nepojmenované) smlouvy. Pro následující vztahy se používají speciální smlouvy, které nejsou upraveny ObchZ:
 Smlouvy o poskytnutí práv k užití IS (časová omezenost práv, výlučnost užití, převoditelnost práv, stanovení poplatků za údržbu)
 Smlouvy o školení uživatelů
 Smlouvy o poskytování služeb podpory a údržby – činnosti nad rámec smluvní záruky nezbytné pro správný chod systému.

Výhody modelu ASP pro uživatele

1.2. Výhody modelu ASP pro uživatele
• Pokud firma najde a využije služeb vhodného subjektu ASP, získá tím následující výhody:
• může ihned využívat hotový systém,
• rizika realizace projektu nese subjekt ASP,
• získá časové úspory,
• může otestovat konkrétní službu v rámci zkušebního období
• a případně nespokojenosti hledat jiné řešení.

Výhody existují i v případě existujícího řešení, které je dostupné na trhu. S pořízením produktu, instalací, uvedením do rutinního provozu jsou spojená určitá rizika a vznikne jistá časová prodleva. V ASP modelu můžeme využít nabízenou službu prakticky ihned.
Významnou výhodou ASP modelu je také to, že uživatelský subjekt na sebe nemusí vázat potřebné know-how (především nemusí zaměstnávat IT specialisty), potřebné zajištění získává spolu se službou od subjektu ASP. Firmy se tedy mohou plně zaměřit na vlastní podnikání ("core business").

1.3. Výhody modelu ASP pro uživatele
Pro poskytovatele ASP je výhodné nákladové hledisko. Poskytovatelé rozkládají své náklady mezi více zákazníků. Díky tomu mohou dosáhnout významného snížení celkové nákladové hladiny na využívání dané aplikace oproti situaci, kdy si aplikaci pořizují přímo její koncoví uživatelé. To má velmi významný důsledek zejména pro malé a střední firmy, které by jinak neměly šanci využít kvalitní a specializované aplikace.
Výhodou modelu ASP může být též rovnoměrné rozložení nákladů při využívání služby a predikovatelnost těchto nákladů. Velká část nákladů je totiž většinou lineárně závislá na době po kterou byla ASP služba využívána a na míře jejího využití. Způsob, jakým si subjekty ASP účtují poplatky za své služby může být různý (např.: měsíční, čtvrtletní či roční paušální poplatky za uživatele, časově závislý tarif vycházející z doby, po kterou je aplikace skutečně používána, účtování podle počtu uzavřených transakcí apod.)

Způsob účtování poplatků umožňuje zákazníkovi přesně plánovat své výdaje na využívání daných služeb.
Zajímavým efektem je též schopnost poskytovatelů ASP zajistit svým uživatelům přístup k požadovaným službám v podstatě odkudkoli.
Zákazník může spolupracovat pouze s jedním partnerem (s poskytovatelem ASP), nemusí být v jednání se subjekty ISV nebo NSP.

Nevýhody ASP modelu

1.4. Nevýhody ASP modelu
• Podmínkou fungování ASP modelu je existence trvale dostupného, ekonomicky přijatelného propojení mezi zákazníkem a poskytovatelem ASP (resp. místem, kde je aplikace provozována). Bez dostatečně spolehlivého spojení, cenové dostupnosti propojení nebude ASP model života schopný. V praxi je možné využít propojení pomocí vyhrazených datových spojů či celých datových sítí, které dokáží garantovat požadované vlastnosti (např. trvale dostupnou a garantovanou přenosovou kapacitu či minimální zpoždění apod.). Též je možné využít Internetu, v tomto případě však existují omezení, jak garantovat požadované parametry (Internet lze využít především u méně kritických aplikací).
• Jednou z hlavních nevýhod ASP je nutnost svěřit chod IS a tedy i svá data do rukou externího subjektu. Aplikace nabízená ve formě služby může mít (podle svého charakteru) významný dopad na chod a existenci celé organizace. Mezi subjekty musí existovat platný smluvní vztah, který podrobně upravuje práva a povinnosti jednotlivých stran. Ve smlouvě (tzv. SLA – Service Level Agreement) musí být zakotveny všechny aspekty důležité pro uživatele – trvalá dostupnost služby (resp. maximální počet výpadků služby), způsob zabezpečení dat, řešení situací při porušení závazků apod. Zde je tedy důležité na jaké podmínky jsou obě strany ochotny vzájemně přistoupit. ASP subjekt by měl být také dostatečně finančně silný, pravděpodobnost možného bankrotu by měla být výrazně minimalizována.
• Další problémy mohou souviset s integrací aplikací. Integrace aplikací musí být vyřešena, pokud firma například využívá více poskytovatelů ASP.

1.5. Statistiky ASP
Podle studie konzultační společnosti IDC (The ASPs' impact on the IT industry) provedené v USA, lze aplikace, nejčastěji využívané na bázi ASP modelu, seřadit takto (od nejsložitějších a nejnáročnějších až po nejméně náročné):
• analytické aplikace: všechny aplikace, určené k provádění analýz vztahujících se k podnikání. (např. finanční analýzy, analýza chování a preferencí zákazníků, analýza rizik, analýzy WWW serverů atd.)
• vertikální aplikace: aplikace týkající se specifik konkrétního oboru podnikání (např. zpracování pojistných událostí v pojišťovnictví atd.)
• ERM (Enterprise Resource Management): aplikace z oblasti správy firemních zdrojů, zahrnující například personalistiku (HR, správu lidských zdrojů), účetnictví, evidenci materiálů, zboží, surovin atd.,
• CRM (Customer Relationship Management): aplikace z oblasti správy zákazníků, zahrnující např. vedení jejich evidence, dále podpora prodeje a marketingové aplikace atd.
• kolaborativní aplikace: různé druhy groupwaru, email a konferenční aplikace
• personální aplikace: například kancelářské balíky, spotřebitelské aplikace (hry, zábava, kultura), aplikace sloužící potřebám vzdělávání

Společnost IDC také rozeznává tři různé úrovně poskytování aplikačních služeb subjekty ASP, které definuje následovně:
1) Core services (základní služby): zahrnují to co je potřebné pro běh aplikace, včetně aktualizací (updaty a upgrady), nepřetržité monitorování aplikací, serverů i sítě, základní uživatelský support
2) Managed services: všechny základní služby, a k nim navíc další služby a garance ohledně podpory, zabezpečení, výkonnosti aplikací a redundance dat. Obvykle sem patří i dohody SLA týkající se chodu aplikací a bezpečnosti dat, každodenní zálohování aplikace i jejích dat atd.
3) Extended services: všechny "managed services", plus další služby jako například přizpůsobování a rozšiřování aplikací podle specifických požadavků zákazníka, školící služby atd.


Následující procentuelní údaje pochází ze studie společnosti Sosinski group, realizované v červnu a červenci 2000 na vzorku 139 respondentů v USA

Produktem ASP operátora je soubor služeb, který se skládá ze

Produktem ASP operátora je soubor služeb, který se skládá ze:
1) Zajištění přístupu k aplikacím. Za definovaný poplatek (měsíční, roční apod.) získává zákazník oprávnění využívat aplikaci, aniž by musel koupit licenci a zajišťovat si její údržbu.
2) Pronájem IT infrastruktury. Opět za definovaný poplatek získává zákazník do pronájmu část zdrojů technické infrastruktury operátora (výpočetní výkon, datový prostor apod.). Komunikační přístup k IT infrastruktuře operátora. Tato služba je poskytována ASP operátorem zejména prostřednictvím ISP operátorů (Internet Service Provider).
3) Implementační služby a servisní podpora. Do této kategorie patří parametrizace (personalizace) aplikací dle individuálních požadavků zákazníka, školení uživatelů, migrace dat, služby HelpDesku, vývoj/implementace nových verzí software apod.
4) Služby řízení a podpora provozu. Do této kategorie spadá např. správa dat, monitoring přístupů, administrace systému apod.

Předpoklady úspěšného ASP operátora
Firma, která uvažuje o vstup na pole ASP služeb by měla splňovat tyto základní kritéria:
1) Dlouhodobá stabilita a historie, pozitivní reference (ASP operátor musí být pro zákazníka „důvěryhodný“).
2) Alespoň střední velikost firmy ASP operátora (50 a více zaměstnanců - ASP operátor musí být pro zákazníka „spolehlivý“, zastupitelnost lidských zdrojů).
3) Dostatek finančních rezerv - vývoj, rozvoj či nákup aplikací. Financování negativního toku hotovosti v počátečním období, nezanedbatelné náklady na marketing a propagaci.
4) Kvalitní analýza struktury poptávky po ASP službách s vědomím komunikačních možností zákazníka a s tím spojený výběr vhodných aplikací pro ASP program.
5) Implementační know-how, pokrytí všech služeb nezbytných pro úspěšnou implementaci vybraného řešení (včetně vstupní analýzy, rozdílové analýzy, školení, ASP integrace apod.).

Výhody SCM/APS, metriky pro jejich hodnocení

1.7. Výhody SCM/APS, metriky pro jejich hodnocení
 Kratší doba na vyřízení objednávky
 Uspokojení zákazníků – dodržování termínů, režim „pull“ (činnost řetězce tažena zákazníkem)
 Omezení stárnutí produktu
 Provozní náklady na řízení dodavatelských řetězců
 Zvýšení výnosnosti aktiv (ROA)
 Vyšší využití výrobních kapacit
 Vyšší marže na jednotlivé produkty
 Rychlejší reakce na neplánované požadavky
 Snížení zásob
 Zvýšení rychlosti obratu zásob
 Zkrácení dob plánování

1.7.1. Přínosy konkrétních produktů dle Gartner Group
 zlepšení zákaznického servisu 5 - 25%
 redukce chyb v předpovědích 50 - 60%
 snížení zásob 10 - 50%
 zvýšení produktivity 25 - 30%
 snížení celkových nákladů až o 60%

1.7.2. Příklady implementací i2
 zlepšení spolehlivosti dodacích lhůt z 80 na 97%, snížení zásob o 25% (Copperweld)
 snížení zásob o 50%, zlepšení úrovně služeb zákazníkům o 10%, zvýšení dostupnosti výrobků z 60% na více než 70% (Whirlpool)
 zvýšení obrátky zásob z 5,5 na 12, zkrácení doby prognózování ze 2 týdnů na 2 dny, zkrácení plánovacího cyklu o 50% (Thomson)

1.8. Trh SCM/APS produktů
Na trhu existují dva typy SCM produktů:
Specializované:
 i2 Rhythm – nejsilnější pozice na světovém trhu SCM
 NetWorks – Manugistics USA
 Fygir – SCT Systems and Computer Technology
 Syncra CT – Syncra systems

SCM/APS jako součást ERP systémů
 APO – součástí SAP
 BAAN SCS – Baan
 JD Edwards

ASP (Application Services Provider)

ASP (Application Services Provider)
Definice, koncept, výhody a nevýhody pro uživatele i provozovatele, využívané druhy aplikací, vztah k řízení informatiky podniku (řízení IS/IT), stav v ČR a ve světě.



1.1. Definice
• První placené služby pronájmu software a výpočetní kapacity existují již od druhé poloviny 60tých let.
• Model ASP je založen na oddělení vlastnictví určitého IS (aplikace) od jeho používání. ASP narozdíl od outsourcingu odděluje od využívání systému, jak provozování, tak i vlastnictví daného řešení. Poskytovatel ASP (Application Service Provider) se tedy stará o provoz IS, vykonává veškeré činnosti .související s počátečním pořízením i s průběžným vlastnictvím systému a nese veškeré náklady s tím spojené. Zákazníkům tedy nabízí možnost využívat IT řešení, které sám vlastní a provozuje.
• Služby ASP jsou provozovány zákazníkům na dálku, z místa kde má poskytovatel vhodné vybavení, do místa, kde se nachází zákazník. Využívá se tedy vhodné komunikační infrastruktury jako je například privátní síť nebo Internet. ASP služby jsou poskytovány většinou za úplatu. Další důležitou charakteristikou modelu ASP je skutečnost, že poskytoval nabízí své služby několika zákazníkům, mezi které rozkládá své náklady. Tím může být určité řešení cenově dostupnější pro větší okruh zákazníků.
• Poskytovatelé ASP kupují programové vybavení místo koncových uživatelů. To samé platí i pro aplikace vyvíjené na míru různými vývojáři, kteří dříve pracovali pro koncového zákazníka.
• Nejrůznější producenti softwaru se označují termínem ISV (Independent Software Vendor). Tento termín zahrnuje jak subjekty které produkují "krabicový software", tak i subjekty které vyvíjejí jednoúčelový software na zakázku. Subjekty ISV tedy software jednorázově vytváří, ale neprovozují. Zatímco poskytovatelé ASP software provozují, ale nevyvíjí. Samozřejmě je možné, že subjekt ASP je současně i subjektem ISV (obecně jsou jejich role odlišné).
• ASP potřebuje tedy vhodné technické prostředky (servery apod.), které nejsou ve vlastnictví koncového zákazníka. V ASP modelu jsou aplikace provozovány na technickém vybavení které vlastní buď přímo sám ASP nebo si je pronajímá od jiného subjektu, který je vlastní a je specializován na jejich provoz. V praxi jde nejčastěji o adekvátně vybavená střediska označovaná jako datacentra (datová centra). Poskytovatelé ASP mohou být vlastníky datacenter nebo mohou využívat služeb provozovatelů datacenter.
• Ze skutečnosti, že aplikace vlastněné subjekty ASP jsou fyzicky provozované ve vhodných datacentrech, vyplývá nutnost využití určité komunikační infrastruktury. Musí být tedy zajištěno vhodné propojení mezi datacentrem a koncovým zákazníkem. Musí existovat další subjekt, který příslušnou konektivitu zajistí. Takovýto subjekt je v souvislosti s ASP a jejich fungováním označován jako NSP (Network Service Provider), a může jím být například i tradiční subjekt ISP (poskytovatel připojení k Internetu). Subjekt NSP je obecně samostatným subdodavatelem poskytovatele ASP, samozřejmě jsou možné i situace, kdy oba subjekty splývají (např. poskytovatelé internetu se díky rozšiřování svých služeb dostávají do rolí subjektů ASP).

Funkce (moduly) APS

1.4.2. Funkce (moduly) APS
• Strategické plánování sítě (strategic network planning): plánování zásobování, distribuce, prodeje na strategické úrovni. Slouží k návrhu dodavatelského řetězce (přiřazení produktů zákazníkům, určení dodavatelů jednotlivých materiálů).
• Plánování požadavků (demand planning): střednědobé prognózy odbytu sloužící jako vstup pro plánování kapacit.
• Plnění požadavků a ATP: krátkodobé plánování prodeje – stanovení termínu splnění příslušného požadavku zákazníka.
– ATP: „available to promise“: stanovení termínu předání výrobku zákazníkovi na základě stavu hotových výrobků na skladě.
– CTP: „capable to promise“: stanovení termínu předání výrobku v případě montáže na zakázku (tj. pokud nelze požadavek uspokojit ze skladu)
• Hlavní plánování (master planning): Střednědobé optimalizace zásobování, výroby a distribuce pro celý dodavatelský řetězec. Na základě tohoto plánu si podniky vytvářejí detailní plány výroby (viz Plánování a rozvrhování výroby)
• Plánování a rozvrhování výroby (production planning and scheduling): určení výrobních dávek, využití výrobních kapacit. Stanovuje se decentralizovaně pro jednotlivé zúčastněné podniky.
• Plánování distribuce a dopravy (distribution & transport planning): krátkodobé plánování dopravy materiálu od dodavatelů a distribuce výrobků zákazníkům. Někdy též plánování „toků“ materiálu.

SW pro SCM/APS

1.5. SW pro SCM/APS
Následující tabulka ukazuje, které funkce SCM jsou zajišťovány jakým SW:

• MRP I (Material Requirements Planning) - jediným plánovacím zaměřením je zajištění dostupnosti materiálu. Nebere se v úvahu dostupnost zdrojů/kapacit (např výrobní nebo dopravní kapacity), takže nelze v tomto smyslu zajistit proveditelnost vytvořených plánů
• MRP II (Manufacturing Resource Planning) - Plánování výroby se provádí s uvažováním dostupnosti materiálu i kapacit.
 Omezení: MRP II optimalizuje ( shodně jako MRP I) lokálně jednotlivý prvek (účastníka) SC. Nelze dosáhnout optimalizace celého SC. MRP II je sekvenčně orientovaný, takže např. plánování kapacit (CRP) se provádí v následném běhu po materiálu (MRP).
 Pokud se překročí omezení některého z výše uvedených plánů je nutné provést na něj navazující plánování znovu.
 Systémy MRP I či MRP II jsou často součástí ERP systému.
• APS – výhody oproti MRP I/II
 APS zajišťuje plánování pro celý složitý mezi-podnikový SC. Lze analyzovat a plánovat aktivity na základě informací z celého SC ( tj. od všech jeho účastníků) lze modelovat realistická omezení v SC ( viz teorie omezení)
 APS využívá postup simultánního plánování, při němž jsou jednotlivé plánovací procesy prováděny souběžně ( na rozdíl do MRP II, kde jsou sekvenční)
 APS zajišťuje v případě změny plánu okamžité předání všem účastníkům SC
 APS lze využívat jako DSS ("what if" analýza)
 APS umožňuje v okamžiku přijetí objednávky zákazníka určit ( na základě informací z celého SC) zda jsou k dispozici prostředky ( zdroje, kapacity) pro splnění objednávky v zákazníkem požadovaném termínu (viz ATP)

1.5.1. Vztah APS k ERP
 APS je nadstavbou ERP, která je orientována na plánovací aktivity (ne na transakční aktivity)
 Transakční aktivity jsou zajištěny ERP systémem ( např. operativní zajištění materiálu - MRP).
 Pro zajištění efektivní spolupráce v rámci SC je nutno zajistit integraci ASP s ERP. Ta je podporována všemi významnými dodavateli APS.

1.6. Hlavní odvětví využívající SCM/APS
Především velké příp. střední firmy a to zejména v oblastech – elektrotechnický průmysl, potravinářský průmysl, textilní průmysl, automobilový průmysl, chemický průmysl, strojírenství.

Procesy v SCM

1.3. Procesy v SCM
Vymezení procesů dle referenčního modelu SCOR (Supply Chain Operations Reference). Jedná se o hierarchické rozdělení procesů, zde je uvedena pouze nejvyšší úroveň:
 Plánování: Na strategické úrovni řeší rozhodování v oblasti dlouhodobého plánování kapacit, struktury výroby, rozhodnutí „make or buy“. Na operativní úrovni řeší plánování požadavků na distribuci, výrobu, materiál.
 Zásobování: Zásobování a nákup služeb. Zahrnuje též kontakty s dodavateli, řízení kvality zásobování, certifikaci dodavatelů apod.
 Výroba: Na strategické úrovni řeší např. umístění a vybavení výrobních závodů, na operativní úrovni řeší vlastní řízením výroby, zpracování požadavků na materiál, balení, testování.
 Dodání: Zpracování objednávek, řízení skladů hotové produkce, doprava, fakturace zákazníkovi.

1.4. APS – Advanced Planning & Scheduling
1.4.1. Definice
APS představuje základní komponentu SCM zajišťující plánování a optimalizaci procesů. Je třeba rozlišit APS pro plánování procesů v jednom podniku a v celé dodavatelské síti. U SCM budeme uvažovat pouze druhý typ. Základní funkce APS jsou:
• Integrované plánování pro celý dodavatelský řetězec.
• Optimalizace procesu na základě stanovených cílů a omezení.
• Hierarchický systém plánování: Rozložení celkového plánu do „plánovacích modulů“ přiřazených různým úrovním řízení. Zpravidla se využívají 3 úrovně.

Opatření, která vedou ke zkvalitnění dokumentace

1.4. Opatření, která vedou ke zkvalitnění dokumentace
Opatření (metodická, organizační, programová, technická), která vedou ke zkvalitnění (tj. přehlednosti, dostupnosti apod.) dokumentace.
 Metodická opatření - Musí být předem určeny konvence, jakým způsobem se bude dokumentace vytvářet. Vychází se z dostupných standardů (ISO normy řady 9000), metodik, podnikových směrnic založených na zkušenostech, požadavků zákazníků apod. Musí být určen způsob doplňování nových dokumentů. Musí být definovány konvence pro vytváření modelů v CASE nástrojích apod.
 Organizační opatření - Každý dokument musí obsahovat: účel, dobu vzniku, jména autorů a spoluautorů, obsah, zdroje (postup, techniky, nástroje), technická doporučení (korektury, nástroje), určení dokumentace (komu bude výstup sloužit). Za správu jednotlivých typů dokumentací musí být zodpovědná konkrétní osoba. Musí být přesně určeno místo, kde bude dokumentace uložena.
 Programová opatření - Určí se konvence pro psaní zdrojového kódu, vytváření komentářů, způsob vytváření programových knihoven, návrh adresářové struktury pro ukládání informací, způsob vytváření programového rozhraní (jakým způsobem budou aplikace/procedury/funkce atd. komunikovat a jak si budou předávat data), atd.
 Technická opatření - Určí se, jaké informace se budou dokumentovat (modely, grafy apod.). Jaké metodiky a nástroje budou používány pro tvorbu dokumentace (textové editory, tabulkové kalkulátory, CASE nástroje, apod.), atd.

1.5. Základní dokumenty vedoucího projektu
 Plán projektu
Deník projektu - eviduje historii projektu, důležité události (schůzky, milníky, dohody, předané dokumenty, deník potvrzuje rada projektu), statistika projektu (pro vedoucího je velmi významná, obsahuje záznam důležitých kvalitativních a kvantitativních charakteristik projektu tj. činnosti, role, skutečně strávený čas, celkové výnosy, spec. podmínky, metriky)

Úloha - předpoklady:
Jste vedoucím svého prvního velkého a důležitého projektu vývoje IS. Uvědomujete si, že jde o Vaší jedinečnou šanci, která podstatně ovlivní průběh Vaší další kariéry. Proto se snažíte maximálně využít dostupné metodiky a projekt řádně připravit. Potřebujete stanovit pravidla pro tvorbu dokumentace. Máte k dispozici metodiky SDM a Prince. Jelikož je třeba, aby dokumentace tvořila jeden konzistentní celek, usuzujete, že je třeba si vybrat jednu z nich. Při bližším zkoumání však zjišťujete, že jde o dva velice rozdílné pohledy na obsah dokumentace, které se prakticky nepřekrývají, přičemž ani jeden z nich zjevně není úplný.
Zadání:
 Rozhodněte se, zda je dokumentace systému záležitostí řízení jeho projektu, nebo vývojové metodiky? Proč?
 Jak se ve svém projektu rozhodnete?

Řízení dodavatelského řetězce

Řízení dodavatelského řetězce (sítě) – SCM
Dodavatelský řetězec a jeho řízení - definice, konceptuální model SCM, procesy, přínosy - metriky, software pro SCM, APS (Advanced Planning System) - systém pokročilého plánování, jeho model a vztah k SW pro SCM, dodavatelé SW pro SCM.



1.1. Definice
SCM je činnost spočívající v integraci organizačních jednotek, které tvoří dodavatelský řetězec, a v koordinaci materiálových informačních a finančních toků za účelem uspokojení zákazníka při dosažení vyšší konkurenceschopnosti řetězce jako celku.

1.2. Konceptuální model SCM


SCM se týká:
 integrace
 kooperace

Detailní návrh

 Detailní návrh
Dokumenty: návrh databázových souborů / tabulek, propočet velikosti databáze, návrh obrazovek, návrh reportů, návrh na získání testovacích dat, návrh datových zdrojů pro naplnění datové základny a návrh transformačních procedur, detailní specifikace vazeb manuálních a automatizovaných činností, detailní specifikace transakci, návrh distribuce funkcí, návrh algoritmů, návrh struktury menu a komunikač. sítě, plán testování systému, návrh změny pracovních předpisů, definitivní návrh přístupových práv ve vazbě na organizační strukturu, vazby dat na funkční místa v org. struktuře, vazby funkcí na funkční místa v org. struktuře, návrh školících materiálů, návrh školitelů, detailní návrh SW architektury a specifikace programových modulů, přehled prostředků a metod implementace, detailní návrh programových standardů a programových vzorů, detailní návrh programových standardů a vzorů, detailní návrh HW architektury, návrh umístění jednotlivých zařízení v místnosti, detailní návrh přenosových cest, harmonogram instalace HW, vazby počítače na lokality, data, SW
Metody a nástroje: ERD, DFD, UML (objektový model, stavové diagramy, use case, interakční diagramy)
 Implementace
Dokumenty: výsledků testování, návrh testu akceptace, plán zavedení systému, plán prosazení změn v pracovním kolektivu, přehled knihoven a adresářů, dokumentace programů a procedur, definitivní verze uživatelské a provozní příručky, plán distribuce SW na určené počítače, upřesněný odhad nákladů zavedení a provoz, návrh systému účtování informačních služeb uživatelům
Metody a nástroje: Programovací prostředky (jejich výstupy), tabulkové kalkulátory, síťové grafy pro plánování zavádění systému, atd.

 Zavádění
Dokumenty: uživatelská a projekční a managerská dokumentace, zápis výsledků zkušebního provozu, upřesněný postup řešení reklamací, organizační a pracovní předpisy, shrnutí nákladů tvorby IS, smlouvy o užití IS se zákazníkem.
Metody a nástroje: tabulkové kalkulátory, textové editory
 Provoz a údržba
Dokumenty: změny v dokumentacích, výsledky vyhodnocování provozních charakteristik, návrhy změn IS, evidence oprav IS, přehledy nákladů a účtování, přehledy přínosů
Metody a nástroje: tabulkové kalkulátory, textové editory

Typy dokumentací

1.2. Typy dokumentací:
 Uživatelská
 Pro koncové uživatele - Obecně popisuje fungování systému, interpretace jednotlivých funkcí, obrazovek a menu, obsahuje návod jak řešit různé problémy, popis chyb a chybových hlášení, přehled členů obslužného personálu, atd.
 Administrátorská - Slouží pro správu systému. Obsahuje přehled programů a jejich spouštění, přehled vstupů a výstupů programů, chyby a chybová hlášení, popis struktury HW, popis základního nastavení systému, pravomoci a odpovědnost správců, popis přístupových práv, popis nastavení přístupových práv, atd.
 Projekční
Obsahuje:
 Výstupy analýzy a návrhu - modely, výsledky interview včetně otázek, testy, apod.
 Metodické konvence, uživatelská zadání
 Architekturu systému, programové vybavení, popis sítě, atd.
 Manažerská
Obsahuje:
 Smlouvy
 Plány projektu
 Evidenci průběhu (popř. vzájemný vztah)

1.3. Vztah dokumentace, životního cyklu systému, metody a nástroje
V každé etapě životního cyklu projektu vzniká určitý typ dokumentace (např. viz. MDIS).
Vstupní/výstupní dokumenty, metody a nástroje v jednotlivých fázích MDIS:
 Úvodní studie
Dokumenty: hrubý datový model, kontextový diagram systému a okolí, hrubý funkční model, hrubý procesní model, vazby funkce-data, zákony a normy vztahující se k řešené problematice, podnikové předpisy, přehled osob garantů IS za jednotlivé útvary, organizační struktura, návrh dodavatelů HW a SW, přehled výběrových kritérií, odhad nákladů a přínosů.
Metody a nástroje: ISAC, DFD, ERD
 Globální návrh
Dokumenty: výstupy analýzy informací, podrobný datový model, podrobný funkční model, podrobný procesní model, role uživatelů a jejich charakteristiky, organizační požadavky, návrh kontrolních činností, plán školení budoucích uživatelů i řešitelů, návrh SW architektury, přehled vybraného TASW a ZSW, přehled používaných standardů, vazby funkce - SW, nároky na HW, rozhodnutí o centraliz./decentraliz./distribuované architektuře
Metody a nástroje: ERD, DFD, HIPO, LRT, VD, SD, vztahové matice, vybrané modelovací techniky v UML (objektový model, procesní model, use case)

Techniky pro plánování a jejich automat. podpora

1.5. Techniky pro plánování a jejich automat. podpora
 GRANT Chart
 PERT Chart - Metoda podobná jako CPM. Narozdíl od CPM se jedná o stochastickou metodu tzn. nejsou přesně určeny jednotlivé časové intervaly. Musí být znám nejhorší možný výsledek a nejlepší možný výsledek u každé činnosti.
 CPM - Critical Path Metod (Metoda kritické cesty). Je zakreslena pomocí síťového grafu. U každé činnosti musí být známa její doba trvání. Start první činnosti začíná v čase nula. V síťovém grafu se zakreslují hrany (činnosti) a uzly (místa, kde se setkávají činnosti).
 Funcion points analysis (FPA) - Metoda objektivního měření velikosti vyvíjeného informačního systému na základě složitosti, rozsahu a specifických vlastností. Analýza založená na postupu shora dolů. Hodnoty jsou určeny podle funkčních a technických charakteristik a podle vývojového prostředí. Existuje více variant výpočtu např. Albrech nebo Mark II. Metoda nehodnotí provedení implementace, schopnosti lidí, omezení projektu, atd. Může být použita pro projekty, určení pracnosti, atd.
Postup:
1. Výpočet hrubých funkčních bodů - ohodnotí se složitost vstupní funkce, výstupní funkce, dotazovací funkce, datové sady, vazební datové sady.
2. Úprava hrubých funkčních bodů - určí se váhy jednotlivých funkcí a datových sad
3. Zjištění stupňů vlivu - ohodnotí se faktory ovlivňující vývoj systému
4. Výpočet faktoru úpravy hodnoty - vypočte se faktor úpravy
5. Výpočet celkového (netto) počtu fcí - vypočte se celkový počet bodů, který ohodnocuje složitost projektu
 Weight Average (WAVE) - Metoda váženého průměru. Slouží k odhadu pracnosti popř. trvání projektu. Je vhodná pro počáteční fázi projektu. Existuje více vzorců pro výpočet. Musí být předem znám optimistický a pesimistický odhad. Potom se určí podle vzorců střední hodnota, standardní odchylka, spodní a horní hodnota intervalu rozptylu. Pokud je standardní odchylka větší než střední hodnota dělená 20, potom je odhad potřeba zpřesnit. Spodní a horní hodnota intervalu rozptylu ukazují, že s 95 % pravděpodobností bude výsledek v tomto intervalu.
 Analýza objektů - Částečně podobná metodě FPA. Je vhodná pro měření nízkoúrovňových činností a poskytuje kontrolu vůči postupům shora-dolů. Vyžaduje detailní znalosti o náplni konkrétního kroku postupu. Pro každý krok postupu se určí typ sledovaných objektů (členové týmu, transakce, entity). Poté se určí náročnost zpracování daného typu objektu a vypočítá se náročnost kroku (počet objektů * ohodnocení objektu). V jedné činnosti lze sledovat více objektů a jejich pracnosti sčítat.

Mezi nástroje pro plánování a řízení projektu patří např.
 MS Project
 Rational Unified Process, Rational SoDA a Rational Project Console od společnosti Rational
 Project KickStart od společnosti Experience in Software
 Open plan od společnosti Welcom
 Produkty od společnosti Primavera
 Produkty od společnosti Plan View
 TurboProjekt od společnosti IMSI
 Nexxiom od společnosti Proscom Management Services
 …

Dokumentace projektu

Dokumentace projektu
Typy dokumentace. Vztah dokumentace, životního cyklu systému, metody a nástroje. Opatření (metodická, organizační, programová, technická), která vedou ke zkvalitnění (tj. přehlednosti, dostupnosti apod.) dokumentace. Úloha dokumentace při řízení projektu.



1.1. Úloha dokumentace při řízení projektu
Dokumentace má několik úloh:
 pomáhá řídit projekt,
 sjednocuje pohled na projekt,
 pomáhá při aktualizaci SW,
 je důležitá z důvodu zastupitelnosti,
 obsahuje informace pro uživatele,
 slouží k eliminaci chyb, atd.

Role v projektu

1.3. Role v projektu
Role v projektu je možné obecně rozdělit např. na : projekční a uživatelské. Role projekční pak mohou být dále členěny na: řídící a výkonné.

Řídící projekční:
 Zástupce vedení na straně dodavatele
 Správce dokumentace
 Plánovač
 Vedoucí analytik
 Vedoucí technolog
 Správce rozpočtu
 Vedoucí etapy
 Dohled nad kvalitou

Výkonné projekční
 Specialista na informační strategii
 Specialista na BPR dané oblasti
 Vedoucí analytik
 Facilitátor
 Analytik
 Analytik/Programátor
 Vedoucí programátor
 Programátor
 Konzultant pro věcné oblasti
 Správce datového modelu (administrátor databáze)
 Správce sítě
 Technik
 Architekt technického prostředí
 Správce výstupů projektu (správce verzí a změnového řízení)
 Tester
 Tvůrce uživatelské dokumentace
 Školitel
 Metodik (řízení, analýzy, programování)
 Specialisté na jednotlivé komponenty technické architektury
 Provozní podpora

Uživatelské
 Sponzor (Výkonný sponzor)
 Koordinátor prací za uživatele (objednatele)
 Klíčoví uživatelé (často jeden nejklíčovější)
 Koncový uživatel
 Informatik
 Specialisté na jednotlivé věcné oblasti
 Správce systému
 Administrátor

Projekční a programové standardy

1.4. Projekční a programové standardy
Standardy se zaměřují na tyto oblasti:
 Řízení projektu
 Projekční metody
 Bezpečnost

Podle původu jsou standardy děleny na:
 Průmyslové (Corba, OpenDoc, AD-Cycle)
 De-facto (Active-X)
 Mezinárodní (ISO,...)
 Státní (ČSN,...)
 Oborové (armáda, zdravotnictví, státní správa,...)
 V rámci organizace - standardy (směrnice), které jsou vytvořeny uvnitř organizace, které vycházejí ze zkušeností, tradic, rozsahu projektů, které společnost realizuje atd. (týkají se dokumentace, psaní programového kódu, atd.)
 Jiné

Normy ISO řady 9000
Jsou zaměřeny na:
 Formalismus (v dobrém slova smyslu)
 Transparentnost
 Obecné principy řízení kvality

Nejsou zaměřeny na:
 Způsob kontroly kvality
 Nemají modifikace pro různá průmyslová odvětví (výjimkou je SW inženýrství)
 Nejedná se o technické normy

Přehled norem ISO 9000
ISO 8402 Slovník pro management a zabezpečování jakosti

Podle délky období, na které je plán vytvářen, rozlišujeme plány

Podle délky období, na které je plán vytvářen, rozlišujeme plány:
 Dlouhodobé - Jsou vytvářeny pro období delší než 1 rok. Vytvářejí se v podnicích, kde existuje velká podniková kultura plánování a řízení. Jsou vytvářeny pro velké a finančně náročné projekty (např. projekt je rozplánován do více dní). Měl by být proveden variantně. Realizace plánu závisí na autoritativní podpoře vedení. Jako zdroje jsou přiřazovány role. Rozlišovací úrovní jsou roky a měsíce.
 Střednědobé - Pro období do 6 měsíců, max. 1 rok. Mohou být základem smlouvy. Časovými jednotkami jsou měsíce a týdny. Plánování je doporučeno ve dnech. Zdroje jsou konkrétní osoby.
 Akční (krátkodobé) - Pro období do 14 dnů. Obsahuje zadání práce na nejbližší období. Časovými jednotkami jsou týdny a dny. Zdroji jsou konkrétní osoby.
Při vytváření plánu projektu jsou v protikladu tři faktory: dobře, rychle, levně. Zvýšením jednoho faktoru musím snížit ostatní dva faktory. Např. rychlejší provedení projektu způsobí nižší kvalitu (popř. nižší rozsah řešených problémů) a vyšší náklady.

1.2. Organizace projektu
Organizaci projektu je možné chápat různě (organizací se může rozumět vlastní řízení projektu). V tomto textu se organizací projektu rozumí přehled projektových rolí, jejich předpoklady, jejich pracovní náplň, kompetence, zodpovědnost, vztah k týmům a přiřazení lidí rolím. Typy rolí jsou vytvářeny podle projekčních zvyklostí a v závislosti na životním cyklu projektu. Přehled dodavatelských a odběratelských rolí a jejich vzájemné přiřazení by měl být obsažen ve smlouvě mezi dodavatelem a odběratelem. Konkrétní osoby jsou jednotlivým rolím přiřazeny před zahájením projektu. Role jednotlivých lidí se mohou v průběhu projektu měnit.

Projekt musí mít určeny:
1. Řídící radu (komisi) - Řídící rada je nejvyšší orgán jmenovaný statutárními zástupci. Rozhoduje o plánech, kapacitách, rozpočtu, smluvním plnění, schvaluje změny, jmenuje jednotlivé týmy. Rozhoduje konsensem. Jednání je formalizované (pozvání, zápisy). Má max. 9 členů.
Časté uživatelské role v řídící komisi:
 Výkonný sponzor
 Vedoucí informatik
 Koordinátor
 Klíčový uživatel
Časté projekční-řídící role v řídící komisi:
 Zástupce vedení
 Vedoucí projektu
 Vedoucí analytik
 Vedoucí technolog
Vysvětlení pojmů:
 Sponzor - Platí a spotřebovává konečný výsledek, předsedá rozhodčí komisi.
 Uživatel - Iniciuje celý projekt, přebírá konečný výrobek a odpovídá za jeho použití (i kvalitu).
 Dodavatel - Produkuje a vydělává.
2. Projektový výbor - Je podřízen řídícímu výboru. Je tvořen vedoucím projektu a vedoucími týmů.
3. Realizační (projekční) tým - Je tvořen výkonnými projekčními rolemi. Je podřízen projektovému výboru. Existuje jeden nebo několik realizačních týmů.
4. Další týmy - U rozsáhlých projektů je optimální vytvořit další týmy (tým akceptace, tým kvality, atd.).

Plánování a organizace projektu

Plánování a organizace projektu
Plánování a organizace projektu – řídící komise, vedoucí projektu, projekční týmy atd., projekční a programové standardy, techniky pro plánování a jejich automat. podpora.



Cílem plánování je určení projektových činností, přiřazení lidí k činnostem, určení nákladů a odhad potřebného času na projekt. Plánování musí být provedeno ještě zahájením projektu. Během projektu se plán pro jednotlivé etapy (životního cyklu projektu) postupně upřesňuje.

1.1. Plán projektu
Výstupy plánování jsou obsaženy v plánu projektu. Ten je tvořen těmito komponentami (např. dokumenty):
 Zadání projektu - Obsahuje cíle a rozsah projektu (tj. co se bude dělat). Tyto informace se určí ještě před plánováním.
 Struktura projektu - Obsahuje přehled projektových činností, které bude nutné provést.
 Harmonogram a rozpočet - Obsahuje činnosti rozplánované do jednotlivých dní, týdnů, měsíců. Obsahuje odhad nákladů na projekt.
 Zhodnocení proveditelnosti projektu - Obsahuje zhodnocení realizovatelnosti harmonogramu, projektu, posouzení důvěryhodnosti plánu apod.
 Organizace projektu - Obsahuje přehled lidí, kteří se budou na projektu podílet a jejich role. Obsahuje, jaké osoby tvoří řídící výbor (radu), projekční týmy, atd. Musí být přiřazeny lidé k jednotlivým činnostem.
 Řídící a kontrolní procedury (postupy) - Obsahuje přehled postupů určených pro zajištění požadované kvality výsledného produktu, pro provádění změn apod.

Techniky (nástroje) pro plánování a řízení projektu

1.10. Techniky (nástroje) pro plánování a řízení projektu
Mezi jednoduché metody bychom mohli zařadit:
 slovní popis , ale ten pro práci analytiků a i uživatelů není vhodný, má malou míru formalizace a standardizace, jsou velmi zdlouhavé, nepřehledné a neurčité
 anketa - pro zajištění úplnosti poznatků o potřebě informací a informačních vztazích. Sam patří příprava dotazníku
 interview (rozhovory s pracovníky) - vhodná pro hlubší průzkum. Zajistit si schválení plánovaného postupu, určení spolupracovníků, schválení navrženého řešení a podmínky pro realizaci připravovaných záměrů
 vývojové diagramy
 rozhodovací tabulky
 metody síťové analýzy

Jedná se především o časovou , nákladovou a pravděpodobnostní analýzu provádění určitých projektů za účelem zefektivnění realizace dané akce. Modelem celého projektu je pro síť (síťový graf). Obrazem jednotlivých činností jsou orientované hrany tohto grafu, které jsou ohodnoceny, tzn., že každá činnost je časově, nákladově či pravděpodobnostně oceněna. Je třeba respektovat vzájemnou závislost jednotl. činností. Žádná činnost nemůže být zahájena dříve, než jsou dokončeny činnosti, které je předcházejí. Cílem čas. analýzy v síť. grafu je především odhalení optimalizace doby provádění celého projektu (hledání čas. rezerv a nalezení kritických činností s min rezervou). Kritická cesta udává nejkratší možnou dobu provedení celého projektu. Proto je důležité, aby se vedoucí projektu věnoval zejména činnostem ležících na kritické cestě.
 Metoda CPM - deterministického charakteru, čas. ocenění jsou pevně dána. Vhodná pro rozvržení projektu a pro řízení úprav.
 Metoda PERT - čas trvání činností je náhodné, řídí se určitým pravděpodobn. rozdělením, je stochastickou metodou. Vhodná pro komunikaci vedoucího projektu s nadřízenými, protože je přehledná a lehce srozumitelná. Pomáhá vedoucímu proj. při odhadu času, který je potřeba k vytvoření projektu, k rozdělení práce jednotlivých projektantům. To je také hlavní přínos pro plánování. Nevýhoda metody PERT - Jednotlivé uzly - fáze mohou začít po ukončení všech fází předcházejích. Ale ve skutečnosti se mohou během jedná fáze začít provádět fáze následující. Dá se spíše říci, že ukončení jedné fáze je podmíněno ukončením fází předcházejících.

Automatizační podpora

1.11. Automatizační podpora
- CASE
 Upper Case - zaměřené na plánování a modelování podnikových strategií, tvorbu koncepce systému, rozklad podnikových cílů a modelování stuktury projekčního řešení. K dispozici je i řada nástrojů pro různé typy analýz s podporou zpětných vazeb do předchozích etap práce.
 Middle Case - zaměřený na střední část životního cyklu projektu zahrnující několikaúrovňovou dekompozici systému až po popis procesů, modelování informačních toků a vytváření konceptuálních dat. modelů.
 Lower Case - realizační fáze životního cyklu projektu, tj. podrobné datové struktujry a modely, návrhy vstupních a výstupních formátů (obrazovek), vytváření progr. specifikací, až po vygenerování někdy i podstatné většiny aplikačních programů. Do této kategorie se většinou zahrnují i funkce podporující řízení prací na projektu.

Nástroje automatizovaného prostředí pro řízení proj. a prog. prací lze rozdělit dle míry abstrakce do tří úrovní:
1. Úrověň - nástroje pro zdokonalování technologie projektování a programování (překladače, ladící programy, generátory sestav, nástroje pro testování systému atd.)
2. Úrověň - nástroje produkující metadata o novém systému (vývojové diagramy dat, programu, modely pro odhady nákladů na software jako je SLIM, COCOMO, odhady spolehlivosti, tabulky pro měření kvality apod.)
3. Úrověň - nástroje, které umožňují řízení celého procesu tvorby softwaru. Tato úroveň je nejabstraktnější a nelze uvést příklady obecně přijatelných nástrojů. Zatím existují pouze takové nástroje, které řeší jen dílčí problémy (např. TAGS - využívá metod stukturní analýzy, které doplňuje plánovacími a kapacitními charakteristikami), APCE (Automated Product Control Environment) - umožňuje maximální předhlednost projektu a zajišťuje mnoho kontrol důležitých pro zvýšení kvality výsledného systému.


Úloha - předpoklady:
Jste vedoucím svého prvního velkého a důležitého projektu vývoje IS. Uvědomujete si, že jde o Vaší jedinečnou šanci, která podstatně ovlivní průběh Vaší další kariéry. Proto se snažíte maximálně využít dostupné metodiky a projekt řádně připravit. Máte však problém s tím, že každá metodika vidí trochu jinak životní cyklus vývoje IS. Přitom o tom, co je třeba udělat při přípravě projektu, jste se dočetl(a) pouze v metodice Prince, která však zase neříká nic o činnostech analýzy a návrhu IS.
Zadání:
 Rozhodněte se, zda vůbec existuje fáze "Příprava projektu" v životním cyklu vývoje IS? Pokud ano, mezi kterými fázemi leží a proč? Pokud ne, proč?

Hlavní projektant

Hlavní projektant
odpovídá za věcnou náplň, odbornou úroveň a efektivnost řešení IS. Hlavní projektant musí mít úzkou vazbu na nejvyšší vedení organizace, aby mohl být z těchto míst ovlivňován a kontrolován, musí mít pravomoce úměrné jeho zodpovědnostem a musí vytvářet předpoklad, aby vybudovaný IS mohl být postupně zaváděn do stávajícího systému řízení.

Řešitelské týmy
jsou sestaveny k realizaci určitého cíle. Vedoucí řešitelského týmu odpovídá za dodržení harmonogramu, věcnou a odbornou úrověň řešení.
Plánování a řízení projekčních a programátorských prací
Pro dosažení požadované kvality IS a zvládnutí složitosti projekčního procesu je třeba
 vytvořit bázi dat požadavků na IS
 navrhnout dekompozici projekčních prací
 vypracovat plán dokumentace systému
 stanovit pravidla pro sdílení dat mezi členy projekčního týmu
Aby návrh splňoval požadavky zadavatele, zapíší se požadavky do předdefinovaných tabulek na základě interview či písemné dokumentace. V průběhu či na konci řešení tak lze zjistit zda jsou všechny požadavky splněny.
Po té se navrhne dekompozice proj. prací. Přidělí se odpovědnost za části řešení a definují se výsledné produkty.
Na základě dekompozice proj. prací a def. výsl. produktu je možné připravit plán dokumentace, což uvožní zabezpečit plnou a včasnou specifikaci.
Když se na tvorbě projektu účastní tým pracovníků s využitím více osobních počítačů, je třeba vypracovat pravidla upravující přístup k datům a pro manipulaci s daty, vytvořit plán sdílení dat, ochrany dat, řešení nesouladů, integraci dat do centrálního projektu.
To lze řešit pomocí hlavního projektu, který obsahuje všechny data projektu. Vedoucí projektu je jediným uživatelem tohoto projetu a nikdo jiný ho nemůže modifikovat. Může závazné údaje uzamknout. Vedoucí projektu přenáší kopie projektováných dat z hlavního projektu do podprojektů jednotlivých projektantů. Data vytvořená či modifik. v prodprojektech vedoucí projektu integruje zpět.
Podprojekty obsahují data, s kt. jednotlivý projektanti pracují při řešení své úlohy. Každý projektant přebírá data, kt. potřebuje z hl. projektu. Data týkající se svého projektu může měnit, přidávat či rušit. Výsledky předá do hl. projektu.
Projekt pro řešení nesouladů obsahuje seznamy dat z každého podprojektu a z hl. projetu pro zjištění duplicit z jednotl. podprojektů, mezi podprojekty a hl. projektem a rozhodují kt. entity zahrne do hl. projektu. V průběhu se některé data ustálý a vedoucí proj. je můžou udělat závaznými.

1.8. Vlastnosti projekční činnosti:
 výrazně tvůrčí charakter
 řešení proj. úloh je svými vstupy a výstupy na sobě úzce závislé, některé mohou i probíhat paralelně.
 požadavek na vysokou iniciativu projektantů při řešení proj. úkolů, potřebná kázeň při dodržování projekčních pravidel, konvencí.
 projekční činnost lze obtížně normovat z hl. spotřeby času a oceňovat je resp. stanovit pro toto oceňování obj. kritéria
 úrověň výsledku - hotového projektu, progr. systému lze obtížně zhodnotit kvalitu (nedostatky se často projeví až s delším časovým odstupem)

Plánování a řízení musí probíhat tak, aby uvedené zdroje byly neustále v rovnováze a aby kapacitně odpovídaly poskytovaným službám.

Projekční a programové standardy

1.9. Projekční a programové standardy
Projekční standardy - závazné v rámci jedné organizace. Jsou to standardy, na kterých se domluví jednotliví členové projekčního týmu v rámci jedné organizacse v závislosti na jejím typu, tradicích i zkušenostech s automatizací a rozsahu zpracovávaných projektů. Mají za úkol usnadnit komunikacsi při vytváření projektů a zvýšit produktivitu práce. Jedná se o standardy v rámci životního cyklu projektu (např. určení velikosti modulů, typu dokumentace, dodržování jednotné formy komunikace, určení metod, určení doby zhotovení projektu - pracnost atd.).
Programové standardy - platí obecně, bez ohledu na charakter organizace. S rostoucím počtem různých firem zabývajících se tvorbou PV vzniká určitá potřeba standardizace. Tvorba kvalitního programového vybavení, ať už typového nebo individuálního je poměrně nákladná záležitost. Proto je nutné navrhovat a vytvářet programové vybavení task, aby bylo možné ho použít bez jakýchkoliv závažných změn po co nejdelší časové období. Vzhledem k tomu, že tempo vývoje HW se neustále zvyšuje, dochází k rychlejšímu morálnímu opotřebení a v souvislosti s tím i častější obnově výpočení techniky. Podle světového trendu se HW obnovuje zhruba jednou za tři roky. Programové vybavení by mělo mít vzhledem k poměrně vysokým pořizovacím nákladům, podstatně delší životnost. Proto je třeba ho koncipovat tak, aby bylo schopno se přizpůsobit těmto změnám. Jednou z možností řešení tohoto problému je dodržování obecně platných standardů. Dodržování zákl. strand. by mělo zajistit přenositelnost programového vybavení z jednoho typu výpočení techniky na druhý (vyšší vývojový stupeň). Standardizací v této oblasti se v současné době zabývá řada organizací. Jednou z nich je např. ANSI (American National Standard Institute). Tato organizace se zabývá standardizací v oblasti programových jazyků. Vypracovala např. standard pro programovací jazyk Cobol : ANSI Cobol, dále pak standard pro SQL. Další organizací zabývající se touto problematikou je X-Open, která vytváří standardy v oblasti otevřených systémů. Jedním z nich je např. standard XPG3, což je standard pro slučitelsnot systémů. Jednou z dalších organizacsí je Státní správa USA, která vypracovala řadu standardů FIPS (Federal Information Processing Standard). Tyto standardy se týkají oblasti zpracování dat. Další organizací je IEEE. Ta se zabývá oblastí systémového prostředí. V poslední době však klesá význam těchto organizací. Stávalo se totiž, že různé instituce vypracovaly podobné standardy, samotřejmě s různými odchylkami, a to pak způsobovalo často různé zmatky. Proto se nyní prosazují zejména tzv. "průmyslové standardy". Ty vznikají oproti předcházejícím "zdola": SW firma vyvine nový typ progr. vybavení. Pokud se tento typ ujme na trhu, stává se jakýmsi neoficiálním standardem, kterému se pak přizpůsobí i ostatní firmy, pokud chtějí být na trhu také úspěšné. Takto se tento SW stává postupně oficiálním standardem. Jedním z taskto vzniklých standardů je např. NFS (Network File System) firmy Microsystems nebo sítě typu Ethernet od firmy XEROX. Uvedené příklady nejsou zdaleka úplným výčtem. Standardů v této oblasti existuje nepřeberné množství.

Provedení projektu

Provedení projektu
1. přidělení prací členům týmu
2. sledování postupu prací
3. sledování kvality prací
4. sledování vnějších vlivů
5. vyhodnocení postupu projektu
6. kompletace požadavků na změny
7. úprava rozvrhl projektu
8. úprava předpokladů projektu
9. úprava ocenění projektu
10. schválení nového rozvrhu

1.6. Organizace projektu
(převzato z otázky 25A, dodatek)

1.6.1. Organizace projektu
Na začátku, každého projektu je zvolen project manager (PM), který řídí projekt po celou dobu. Organizace činností a lidí se v různých etapách liší.
1. Úvodní studie - poměrně malý tým : PM + hlavní projektant (někdy nazýván architekt), + další projektanti, celkově tak 5 lidí
2. Návrh globální architektury (HW i SW) - cílem vytvořit určitý rámec, který bude držet celý projekt pohromadě - kromě lidí z úvodní studie se účastní specialisté z podni¬ ku, 1-2 HW specialisté, SW specialista, odborníci z jednotlivých oblastí.
3. Globální a detailní návrh - vytvoří se projekční subtýmy zabý¬ vající se jednotlivými oblastmi. Ve spolupráci s vedením pro¬ jektu zakomponovávají svůj návrh do připravené architektury.
4. Implementace - obdobný systém jako GN A DN - malé týmy a jedna řídící skupina.

Při zavádění mohou být profesionální školitelé nebo sami tvůrci, záleží na počtu školených uživatelů a jejich předpokládané in¬ teligenci, obtížnosti systému, pedagogických schopnostech tvůrců.
Dále by měla existovat testovací skupina, někdy musí být nezᬠvislá od tvůrců.
U větších projektů dále existuje řídící komise složená z vyššího vedení odběratele a dodavatele, která odsouhlasuje výsledky jednotlivých etap. U ještě větších projektů existuje změnová komise, která se obvykle schází častěji než řídící komise a vyřizuje menší změny.
Z odběratelské firmy je třeba spolupracovat s nejvyšším vedením, se zástupci uživatelských skupin, u podniků, které mají vlastní oddělení zabývající se IS, tak budeme úzce spolupracovat i s tímto oddělením, není špatné vzít některé tyto pracovníky do do našich týmů.

Při sestavování týmů "namíchat" různě zkušené pracovníky, různé typy lidí. Obecně 4 typy lidí podle jejich chování:
viz. otázka A25

V týmu jsme měli mít pracovníky všech skupin, poměr podle činnosti týmu, zároveň bychom měli při sestavování myslet na dob¬ré sociální klima.

Při řízení může být použita např. metoda hlavního programátora. Hlavní programátor v týmu koordinuje práci a sestavuje systém na vyšší úrovni, ostatní píší obslužné rutiny, zajišťují nižší úroveň programování. Tento přístup by měl vést k větší konzistentnosti výsledného IS, umožňuje hl. programátorovi soustředit se na koncepční otázky.
Při řízení lidí je třeba dodržovat obecné postupy - např. motivování, zvolit vhodnou míru kontroly, dát jednotlivým vývojovým pracovníkům dostatečnou míru autonomie.

Motivační faktory

Motivační faktory by měly být používány v co nejpestřejší škále, nelze se zaměřit jen na jeden - např. dobrá mzda, to má většinou jen dočasný účinek.
Příklady motivačních faktorů: odměna (mzda, příplatky na stravu, dopravné apod.), přitažlivá a různorodá práce, dobré pracovní prostředí, formální uznání dobrých výsledků, možnost služebního postupu a rozvoje kvalifikace apod. Je samozřejmě třeba odhadnout co na koho působí.

Budování IS představuje nejen velký objem prací a překonávání řady problémů, který samy o sobě kladou veliké nároky na řízení celého projektu, ale tato činnost je mimořádně náročná i proto, že jde o organizování práce kolektivů uživatelů a řešitelů, kdy jednotlivé skupiny specialistů jsou zcela odlišně orientovány a kde členové jednoho týmu často spadají do různých organizačních útvarů.
Řízení různorodých pracovních týmů a nároky na koordinaci, přesnost jejich práce, která má vyústit v dokonale sladění IS definovaný s přesností a důsledností, jakou vyžaduje počítač, je možné jen při dodržení určitých pravidel.

1.7. Plánování a řízení projektu
se dělí na dvě části –
v předprojektovém stadiu
- v projektových stadiích a při jeho realizaci

V průběhu předprojektového stadia se zpracovává projektový úkol, na jehož schválení závisí, zda podnik nebo organizace bude vytvářet IS. Pro zpracování projektového úkolu se vytvoří dočasný pracovní tým, jehož členy i vedoucího jmenuje ředitel organizace jmenovací listinou, ve které jsou současně vymezena práva a povinnosti i pravidla práce týmu.

Při řízení projektu v projektových stadiích a při realizaci se ustanoví tyto orgány řízení projektu:
 řídící komise
 hlavní projektant
 řešitelské týmy

Prototypování

Prototypování
Sekvenční postup projektu se změní v kruhové provádění jednotlivých fází (asi jako když píšu diplomku, čtu diplomku, upravuju diplomku, reviduju, upravuju) – dochází k minimalizaci rizika včasného odhalení chyby, která vzniká z těchto důvodů:
 tvůrce podlehl sebeklamu , že řešenému problému rozumí
 zadavatel neumí přesně definovat požadavky
 nedostatečná analýza

Cyklus prototypu – návrh prototypu – implementace prototypu – testování prototypu –analýza výsledků – (pokud ano projekt pokračuje) – modifikace plánu – detailnější/upravený prototyp –a celé kolečko znovu 

Přírůstkový životní cyklus projektu
Klade si za díl co nejrychleji dosáhnout přínosu projektu. Životní cyklus není prováděn sekvenčně ale paralelně. Řešení se rozdělí na menší celky a ty jsou zpracovány dle klas. Životního cyklu. Podmínkou je aby jednotlivé části řešení (např. aplikace) byly samostatně funkční. Při úvodní studii projektu je třeba rozdělit řešení (např. aplikaci) na jádro a jednotlivé „inkrementy“ – třeba modul základní, účetní, skladový….

1.5. Činnosti při řízení projektů - plánování
Plán –Plán projektu obsahuje závazná pravidla, podmínky a postupy pro zpracování projektu. Plán projektu popisuje projekt z hlediska: cílových produktů, pracovních postupů, zdrojů, času, financí, organizace, kvality.
V plánu projektu jsou uloženy informace o tom, co, jak, kdy, s kým a za co bude v rámci projektu realizováno.
Výchozí plán projektu je definován ještě před vlastním zahájením projektu. Plán projektu dále žije a je aktivní po celou dobu trvání projektu. Po ukončení každé etapy je plán revidován, doplněn o nové skutečnosti a změny vzniklé na základě dosavadního průběhu a podrobně rozpracován pro následující etapu. Úpravy Plánu projektu jsou prováděny v případě potřeby průběžně i během zpracování etapy.

základními komponentami Plánu projektu jsou:
 zadání projektu,
 struktura projektu,
 harmonogram a rozpočet projektu,
 zhodnocení proveditelnosti projektu,
 organizace projektu,
 stanovení řídících a kontrolních procedur

Bývá vyjádřen dokumentem a schválen vedoucím orgánem projektu.

Plány

Plány
 dlouhodobý plán – více než 1 rok – spíše utřídění úvah, orientace na autoritu, která nám plán pomůže splnit, různé varianty, úkoly přiřazujeme ne lidem ale rolím
 střednědobý 6měs-rok – dobrý základ smlouvy, rozpočtu, jednotkami jsou týdny, měsíce, kapacity jsou konkrétní lidé
 akční plán 14 dní – přesné konkrétní úkoly, jednotkami jsou dny, kapacity jsou lidé.

Kde vzít údaje pro plán? - z hlavy, z knihovny procesů, z metodik, ze znalostní báze projektu, z osobního archivu projektů. Nástrojem může být MS Project, Project Manager

Metody pro odhadování pracnosti
WAWE – metoda váženého průměru. Nejdříve činnosti rozdělím na fáze/činnosti/kroky/úkoly. Poté pro jednotlivé fáze a činnosti a kroky pesimistický (P), optimistický (O), realistický odhad (R), kde doba fáze se rovná = (P+ 4R + O)/6. JE to jednoduchá metoda, založená na odhadech, vhodná třeba na workshopy.
Evidence pracnosti – pro odhad jsou použita historická data, POZOR! Nesmí být použita pro hodnocení.
Object Based – projekt se rozloží na nejmenší objekty, u kterých je známá doba trvání. Objekty je třeba tabulka v db, procedura, vyškolený uživatel …. Velmi pracná metoda, ale poměrně přesná
FPA – Top down model odhadu, nutná historická data. Z hist. projektů určíme produktivitu firmy, poté provedeme bodování nového projektu (FPA body) a dobu spočteme jako FPA/produktivita práce.

Naplánovaní projektu
1. detailní stanovení činností
2. detailní stanovení potřeby zdrojů
3. přiřazení produktů činnostem
4. přiřazení zdrojů činnostem
5. plánování metrik a metod měření
6. analýza rizik projektu
7. stanovení rezerv
8. detailní stanovení milníků
9. vytváření plánu postupu
10. ocenění projektu
11. stanovení procedur zajištění kvality
12. kompletace, posouzení a odsouhlasení plánu projektu

Typy činností při řízení IT projektů

1.2. Typy činností při řízení IT projektů
a) tvrdé
 plánování (příprava činností a přiřazení zdrojů pro dosažení cíle při daných omezeních)
 řízení (správa průběhu činností a jejich přeplánování vzhledem k reálnému průběhu)
b) měkké
 vedení (zajišťování optimálního výkonu zdrojů a udržování zaměření činností na platné cíle)

1.3. Objekty řízení projektů
 Čas (milníky, návaznosti, zpoždění vnitřní, vnější)
 Cíle (věcné, finanční, vlastní)
 Zdroje (materiálním logistika, lidské, motivace, kvalita, produktivita)
 Náklady (rozpočet, zdroje, penále, režie)
 Činnosti (kvalita, funkčnost, spolehlivost, bezpečnost, technologie)
 Rozsah ?? (rozšíření, zúžení, lokality…)

Hlavním principem při projektovém řízení je kvalitní analýza a shoda s globální a informační strategií podniku: krátkodobá řešení přinášejí vysoké náklady v budoucnu a nejasnost dosažení cílů (křišťálová koule). Správně: strategická analýza (týdny), poté projekty dle informační strategie (roky), nakonec dosažení cíle.

Informační strategie - jasně a přesně definovaná strategie společnosti v oblasti využití informační technologie přímo odvozená od strategických věcných cílů společnosti.

Business reengineering je oborem, který se zabývá optimalizací fungování organizace ve vztahu k jejím business cílům. Business reengineering bývá úzce spojován s aplikací produktů procesního modelování a řízení prací tzv. WORKFLOW nástrojů a metod. Business reenginering je však širším oborem, jehož aplikace také mimo jiné určuje způsob rozvoje informačního systému. V rámci informační strategie lze odpovědně provádět, resp. navrhovat pouze dílčí reengineering v oblastech informatiky podniku. Při poznání zásadních nesouladů v chodu firmy je nutné začít reengineering z úrovně Business strategie.

O vztahu podnikové strategie a IT strategie více v otázkách A5…!!!!!!!!!! (MDIS),

Životní cyklus IS x životní cyklus projektu

1.4. Životní cyklus IS x životní cyklus projektu
Východiskem návrhu IS/IT je globální podniková strategie, která určuje hlavní směry a priority rozvoje podniku. Na globální podnikovou strategii navazuje informační strategie, jejímž cílem je optimálně podpořit cíle GST pomocí IS/IT. IST i GST mají v zásadě tři fáze 1. analýzu současného stavu, 2. model budoucího stavu (GST je model budoucího stavu podniku, IST je budoucí model IS/IT podniku) 3. plán transformace od dosavadního stavu do požadovaného stavu.
IST definuje projekty , které vedou ke splnění IST. Cyklus IST je určován cyklem GST, a celkově se jedná o 2-3 roky. Cyklus projektu je vždy v rámci IST, doba projektu, max. rok, jinak rozdělit na více projektů.

Životní cyklus projektu
1. úvodní studie (studie proveditelnosti) – detailní posouzení realizovatelnosti požadavků, variantní návrh koncepce projektu, event. rozdělení na subprojekty (pokud je projekt příliš velký)
2. globální analýza – hlavním cílem je stanovení hlavních funkcí a dat projektované aplikace na konceptuální úrovni (nezávislá na implementačním prostředí aplikace či technologické platformě)
3. detailní analýza – projekce globální analýzy do technologického prostředí (implementačně závislého prostředí)
4. implementace – převedení návrhu do praxe (programování, vytvoření databáze) + testování + kompletace dokumentace
5. zavádění – školení, konverze dat, instalace technicko-programového vybavení, zkušební provoz
6. provoz a údržba

Řízení informatických projektů

21 Řízení informatických projektů
Principy a zásady řízení projektu, životní cyklus IS versus životní cyklus projektu vývoje IS, organizace projektu a odpovědnost, projektová dokumentace a její smysl. Specifika informatických projektů a jejich řízení.



1.1. Projekt
1. má stanovené cíle,
2. má definované výstupy,
3. má začátek,
4. má konec,
5. je unikátní,
6. má omezené zdroje,
7. je živý,
8. ovlivňuje své okolí

-délka efektivně řiditelného projektu je 12 měsíců, pak není možné plánovat, jelikož se vše mění (ceny, technologie, lidé, cíle…)

Program – skupina souvisejících projektů

Projekt manager – základem jsou techniky a dovednost vést projekt, nadstavbou je znalost vývojových prostředků, aplikací a ideál ještě zná problémovou oblast.
Projekt manažer se může naučit:
• Znalosti (techniky, metody, trendy, znalost lidí v týmu, znalost trhu)
• Dovednosti (obchodní, vyjednávací, plánovací, komunikační, finanční)

Projekt manažer může rozvíjet:
• Talent (logické myšlení, komunikativnost, odolnost stresu, pozitiv. Myšlení, vůdcovství, rozhodnost)
Typy projekt manažerů v praxi = mix (administrator, organizator, obchodník, architekt, vůdce, majitel, šampión)

Provozní služby

3. Provozní služby
HelpDesk
 kontaktní místo
 podpora uživatelů
 řízení problémů
 řízení změn

Řízení IS
 řízení přínosů – při provozu je vhodné sledovat metriky přínosů, jestli jsou naplňovány stanovené cíle. Pokud ne, vyvolat změnu.
 řízení bezpečnosti – koordinace operativních opatření s bezpečnostní politikou podniku a s jednotlivými kompetencemi v informatice
 řízení Service Level – sledování úrovně služby
 administrace/vykazování – parametry služeb a IS/IT se periodicky vykazují pro vedení
 vztahy k dodavateli – někteří dodavatelé se snaží něco prodat na různých místech v podniku. V podniku by mělo být jen jedno centrální nákupní místo. Funkce CRO.
 provozní nákupy – papír, tonery, …

1.9. Náklady na provoz IT
Kolik nás stojí informatika? Kolik nás stojí informatika na podporu konkrétních aktivit/procesů?
Je obtížné sledovat náklady na informatiku. Struktura je následující:
 konzultační služby (externí)
 nákup služeb, servisní poplatky (externím partnerům)
 drobné nákupy majetku/materiálu (tonery, papír)
 mzdy, personální náklady (nepřímé náklady, př. židle)
 licenční poplatky
 odpisy majetku (tvoří až 50% nákladů)
 ostatní (budovy, energie)

Kontrolling a informatika
Cílem je stanovení průhledné ceny. Cestou je vykazovat co nejvíce nákladů co nejpravdivěji a přiřadit je podle vhodných parametrů a dimenzí jejich skutečným nositelům v podniku. To lze však těžko, neboť IS/IT je prorostlé skrz podnik a většinu nákladů tvoří režie.

SW systémy pro podporu údržby IS

1.10. SW systémy pro podporu údržby IS
 velké SW balíky pro podporu údržby IS
 funkcionalita: (lze ji využít k povídání o možnostech distribuovaných IS, problémech a nástinech řešení)
o řízení distribuovaného prostředí
o správa přístupových práv administrátorů
o definování systémových politik
o správa chybových a diagnostikovaných hlášení
o automatická distribuce, instalace a údržba SW vybavení v síťovém prostředí podniku
o monitoring stavu systémů, procesů a aplikací
o uložení, detekování a prezentace dat o HW
o monitoring celé sítě, aktivních síťových prvků a automatická detekce chyb
o grafické modelování topologie sítě, propojení aktivních částí, zpracování událostí, sledování výkonnosti sítě
o vzdálené ovládání stanic a serverů
o centrální zálohování, archivace a obnovy dat v SaN (storage area netvork)
o správa DB serverů
o nástroje pro podporu rozhodování a řešení problémů IT prostředí

1.11. Příprava inovace systému
 souvisí s mnoha body uvedenými výše, různé důvody (funkcionalita, infrastruktura, změna organizace,…)
 de facto příčiny inovace souvisí s příčinami změn
 zpravidla se jedná o větší změnu ve funkčnosti nebo nasazení úplně nového IS
 je dobré projektově řídit
 odpovědné by měly být všechny části vedení, vč. strategické úrovně
 analýza by měla být započata včas, je potřeba počítat, že nový (inovovaný) systém by měl běžet nějakou dobu společně s původním systémem

Samotný proces přípravy inovace je stejný jako při návrhu nového IS, jen je potřeba zohlednit míru změn a stav stávajícího IS!!!

životní cyklus IS viz B17
příprava zavádění nového IS viz B19

Úloha – předpoklady:
Pracujete jako projektant útvaru informatiky v podniku. Býváte kritizován(a) za to, že údržba systému vyžaduje stále vyšší náklady, přičemž však on sám je stále zastaralejší. Je dokonce důvodné podezření, že jeho provoz je čím dál riskantnější.
Zadání:
 Rozhodněte se, kde se stala chyba, stala-li se vůbec.
 Co s tím uděláte?

Proces řízení změn

Proces řízení změn

 má v informatice úkol zajistit, aby veškeré změny, které jsou v IS provedeny, byly předem dostatečně zváženy (jejich dopad, náklady, efekt apod.) a byly řádně zadokumentovány a nenarušily kontrolovatelnost informatiky podniku
 účel tohoto procesu je nutné odlišit od řízení změn během informatických projektů, které je součástí řízení projektu. Zde uvedený proces řízení změn řídí změny před tím, než je pro jejich realizaci zaveden projekt (je-li)
 z toho vyplývá, že změnové řízení se provádí jak při projektu, tak i při provozu IS (viz obr. výše)


1.3. Typy změn (co je iniciuje, tohle je klíčové)
1. vnější sociálně – ekonomické prostředí
 změny ve vztazích k odběratelům, k dodavatelům rozšiřování trhu, ztráty trhu, orientace na jiné segmenty, reakce na inovace konkurence, změny požadavků odběratelů v rámci CRM
 změny celkového ekonomického prostředí legislativy (změny úrok. sazeb, přizpůsobování se pravidlům a legislativě EU, změny podmínek pro úvěrování, změny daňových zákonů, změny sociálních zákonů, zákoníku práce)
2. změny ve vnitřním fungování organizace
 změna vlastníka organizace, změna zaměření, slučování či dělení, změny v řízení jakosti ISO, TQM
 změny v dílčích oblastech řízení (přehodnocení procesů postupů, přerozdělení pravomocí mezi útvary, změny požadavků uživatelských útvarů na IT podporu)
 BPR
 integrace nového systému do stávající IS/IT (CRM, SCM, e-business)
3. změny vyvolané rozvojem technologií a metod
 nové technologie si často vynucují změny v IS a někdy vyvolávají celkovou inovaci IS (dnes např. příklon k www aplikacím)
 konvergence IT a telekomunikací, mobilní computing
 teleworking až vytváření virtuální organizace

Typy požadavků na změnu (dle dopadu a nákladů)

1.4. Typy požadavků na změnu (dle dopadu a nákladů)
Podle toho, zda požadavek lze splnit snadno nebo obtížně, a dle nákladů, lze požadavky rozdělit na:
 požadavek lze splnit s již provozovaným systémem (ve stávajících parametrech) – náklady jsou nepatrné
 požadavek lze splnit modifikací již provozovaného systému – náklady se pohybují v určitém limitu
 požadavek lze splnit zavedením nového IS (celého nebo nové části/komponenty) – náklady jsou nad limitem, vysoké

Dále lze změny rozdělit na:
1. rutinní uživatelské změny
2. změny v aplikační funkcionalitě/ve službách
3. změny v infrastruktuře

1. Rutinní uživatelské změny
 přesun pracovišť (koncových stanic – KS)
 nový pracovník – převedení KS
 nová KS – vrácení/výměna KS
 souvisí s asset managementem

2. Změny v aplikační funkcionalitě (body se prolínají)
 uživatelské změny aplikací – změny jsou součástí funkcionality (tiskové sestavy, parametry aplikací, doplnění číselníků); uživatel je může provádět sám
 drobné změny (Small Jobs) – změny funkcionality, které mohou proběhnout neprojektovou změnou; musí být zaneseny do dokumentace a konfrontovány s integritou IS/IT; většinou bez zásahu do DB základny
 rozsáhlé změny = projekty – změny musí být řízeny projektově, často nákladné (v některých případech i jen pro malé změny funkcionality)
 nerealizovatelné projekty (např. z důvodu ekonomických, stávající infrastruktury, nebo přesahující jen změny v aplikační funkcionalitě)

3. Změny v infrastruktuře
 tj. změna síťových prvků, kabeláže, apod.
 uživatel by je neměl vnímat
 mohou být vyvolány např. požadavkem na změnu v aplikační infrastruktuře