1 Změny v působení firmy na trhu v podmínkách informační společnosti

3.1 Principy řízení firmy v informační společnosti Zadání teorie: Změny v působení firmy na trhu v podmínkách informační společnosti (podnik, zákazník, manažer). Nároky na pracovní sílu typické pro konkurenční prostředí IS/ICT. Přístupy a metody, ovlivňující konkurenceschopnost podniku IS/ICT, TQM (úloha standardů a nástrojů kvality v rozvoji firmy) atd. Změny v postavení řízení informatiky v řízení firmy.

1 1.1

Změny v působení firmy na trhu v podmínkách informační společnosti Informační společnost

Podoba dnešní globální společnosti, která se vyznačuje několika charakteristikami: snadno dosažitelné informace (pro práci, vzdělání i zábavu) silný vliv internetu (informace, business, zábava) informace je klíčovým rozlišovacím faktorem všech výrobků a služeb inf. spol. je pohodlná pro spotřebitele, tvrdá pro výrobce (konkurence) vyvinutá informační infrastruktura (levnější a modernější technologie, vyšší potřeba přenosové kapacity, stále vyšší objem přenášených dat (multimédia) člověk je zahlcen mnoha daty, které nepotřebuje zvyšující se důraz na péči o zdraví – hledají se cesty, jak informace o zdrav. péči najít mezi mnoha jinými informacemi hledání způsobu, jak pečovat o kulturu tvorba národního bohatství se přesouvá do oblasti zpracovávání informací a služeb s nimi spojených a další aspekty zmíněny dále

1.2

Globální informační infrastruktura (GII)

Všechny vyspělé státy (EU, USA, G7, OECD) si uvědomují probíhající informační revoluci a její potenciál. Podporují proto budování rozsáhlých mezinárodních informačních infrastruktur. GII jsou (dle definice OECD) komunikace provozované na celosvětové síti rychlých komunikačních kanálů, HW, SW a lidí. Cílem je umožnit nové služby a strategické aktivity založené na využívání všech typů informací. GII má dostatečnou kapacitu pro přenos multimediálních aplikací, hlasu, obrazu a dat. Klíčovou podmínkou jsou liberalizované telekomunikační trhy. Nové informační situaci se postupně přizpůsobují všechny dimenze života – politické, ekonomické, sociální a kulturní a vytváří se tak základy pro globální informační společnost (GIS) Internet

nejznámější představitel GII, celosvětová globální síť propojující navzájem mnoho sítí nové technologie, nové platformy vývoje a provozování aplikací (TCP/IP, http) levný zdroj informací původně pro vojenské a výzkumné účely – cílem bylo zajistit chod sítě i při výpadku některých uzlů

Intranet

podniková síť postavená na internetových technologiích je zabezpečena od vnějšího internetu a slouží k provozování interních podnikových aplikací

Extranet

propojení intranetů mezi více podniky; prakticky jde o to, že jeden podnik vidí některé informace druhého podniku zefektivnění dodavatelsko – odběratelských vztahů využitím intranetových (=internetových) technologií

WWW

systém pro snadné uložení, prezentaci a vyhledávání informací každý dokument má svojí URL, která slouží k identifikaci HTML – jazyk pro tvorbu www stránek přenos pomocí http nebo FTP

E-business

zahrnuje produkci, reklamu, prodej a distribuci produktů prostřednictvím telekomunikačních sítí, součástí jsou jakékoliv finanční transakce realizované pomocí internetu, faxu, EDI nebo internetu; - 1/8 -

1.3

Jak informační společnost ovlivňuje podnik

1.4

2.1

rodina zůstává základem společnosti, kladeny vyšší nároky na výchovu a vzdělávání. podstatné je, aby všichni měli rovný přístup k informacím, aby se svět nedělil na informačně vzdělané a nevzdělané. S informacemi souvisí možnost získat lepší práci a bohatnout. vyšší nároky na pedagogy a vzdělávací systém (ne memorování, ale schopnost analýzy dat)

Řízení podniku, nároky na manažery

2

standardní produkty rozšířené o informační služby (konzultace, projekty); podíl informačních služeb se zvyšuje zvyšující se důraz na kvalitu výrobků i služeb aplikace v prostředí internetu (a intra- a extra-) silně ovlivňují chování podniku svými novými příležitostmi, ale i nároky na řízení podniku; nalezení nových informačních , propagačních, prodejních a distribučních kanálů – tj. rozvoj ebusinessu nové kanály snadnost, lacinost a rychlost oslovení nových zákazníků ale růst konkurence zvyšující se rychlost reagování podniku na situaci na trhu dynamická změna produktů a struktury firem pružnost dosahována také pomocí outsourcingu podpůrných činností zefektivnění dodav – odběr. vztahů (např. využitím extranetu) vede k vytěsnění zbytečných mezičlánků mezi výrobcem a odběratelem, vede ke sdílení znalostí v řetězu a k novému vztahu k zákazníkovi nové formy řízení podniku dramaticky rostou nároky na pracovní sílu o celoživotní vzdělávání, stěhování za prací o nový prvek v organizaci práce - teleworking (práce na dálku bez nutnosti cestovat do práce, snížení nákladů, zvýšení potřeby kontroly a způsobu zadávání práce, vznik virtuálních společností) o potřeba vysoké specializace, ale také ochota se rychle přizpůsobit podmínkám trhu práce a rychle se naučit nové věci. K velké specializaci tak přibyla i jistá míra univerzálnosti o se vším souvisí nový životní styl

Společnost, rodina

1.5

diskutované otázky o e-businessu (dle OECD): ochrana soukromých dat, etika marketingu a inzerce na internetu, kryptografie a důvěra v e-podnikání, právní platnost digitálního podpisu, celní tarify, daně, ochrana autorských práv, konkurence v oblasti telekomunikací státní administrativa se tomuto trendu přizpůsobuje jen velmi pomalu

nové nároky na řízení (měnící se struktury organizací, nové trhy, noví zákazníci, nové formy prodeje, nová teritoria, nové formy komunikace mezi partnery, větší nároky na zaměstnance)

Nároky na pracovní sílu typické pro konkurenční prostředí IS/ICT. Životní cyklus podniku (Greinerův model)

Jednotlivé etapy vývoje podniku vyžadují různé nároky na charakter řízení. Tento model je platný i pro GIS. Tímto vývojem prošla v 90. letech řada podniků dodávající IS/IT. Růst prostřednictvím kreativity podnik roste na základě kreativity malého týmu lidí nastává krize vedení – je potřeba rozdělit kompetence a odpovědnosti Růst přímým řízením došlo k dělbě práce, podnik je řízen centralizovaně a direktivně, zaměstnanci se cítí omezeni hierarchickou strukturou nastává krize autonomie – vedení je vzdáleno od požadavků jednotlivých oddělení Růst prostřednictvím delegování došlo k delegování pravomocí a odpovědností na nižší řídící stupně nastává krize kontroly, neboť jednotlivé části podniku se začnou rozhodovat a vyvíjet více či méně samostatně Růst prostřednictvím koordinace zaveden vyšší stupeň koordinace jednotlivých útvarů nastává krize byrokracie – jednotlivé útvary jsou tvrdě od sebe oddělena vnitřními předpisy - 2/8 -

Růst prostřednictvím spolupráce došlo k návratu k původnímu duchu spolupráce a kreativity, ke sdílení společných hodnot další vývoj vede ke krizi psychologického nasycení, kdy týmová práce sama již nedostačuje to může vést k podvojné organizaci kombinující odlišné přístupy pro rutinní procesy a pro situace reagující na nové příležitosti na trhu Účel podniku stojí na vizích, kterými manažeři vyjadřují cíle podniku. Z cílů se formulují strategické záměry a ty jsou promítnuty do cílů. Operativním vyjádřením cílů jsou plány. Efektivně formulované poslání musí vyjadřovat: tržní orientaci (vymezení segmentu trhu a cílové skupiny) realizovatelnost (podnik se nesmí dostat z hranice produkčních možností) motivaci (lidí, že kroky jsou vedeny v duchu zvyšování blahobytu podniku) specifikaci (hodnotového systému podniku a vztahu k zákazníkovi)

3

Přístupy a metody, ovlivňující konkurenceschopnost podniku IS/ICT, TQM

3.1

Podniková strategie a konkurenční výhoda

Konkurenční výhoda vyplývá: 1. z pozice podniku v konkurenčním prostředí 2. ze schopnosti se vyrovnat s konkurenčními silami Z toho vyplývají dvě strategie (dle Portera): 1. cesta nízkých nákladů 2. odlišení vlastní produkce od konkurenční V podmínkách GIS z toho plyne, že e-business je především změna tradičního obchodního procesu mezi výrobcem, distributorem, dealerem a zákazníkem. Tento „model 4 subjektů“ má nevýhody: 1. distributor má dobré znalosti produktu, ale minimální o zákazníkovi 2. dealer má dobré znalosti o zákazníkovi, ale menší o výrobku Z toho vyplývá, že je nedostatečná komunikace týkající se toho nejdůležitějšího – potřeb zákazníka. Porter navrhuje nový model, který využívá technologií internetu, redukuje počet mezičlánků. Jeho hlavní konkurenční výhoda je v tom, že výrobce je v přímém kontaktu se zákazníkem a reaguje okamžitě. Další konkurenční výhodou využití internetu je snížení nákladů a poskytnutí dalších služeb provázející produkci a prodej přímo zákazníkovi. Tradiční obchodní model: Výrobce

Zboží

Distributor

Informace

Reklam a PR Dealer 1

Výzkum trhu

Dealer n

Peníze Zákazníci

Obchodní model v informační společnosti: Zboží

Výrobce

Přepravní služby

Informační služby („portály“)

Informace

Peníze Zákazníci

- 3/8 -

Finanční služby

Další konkurenční výhodou je využití fundovaných analýz pro zkoumání prostředí. Jde o BCG matice a SWOT analýzu.

3.2

Konkurenceschopnost podniku a její podpora nástroji IS/IT

V podmínkách tvrdé konkurence jsou manažeři nuceni přehodnocovat svoje manažerské možnosti a hledat nové nástroje a metody řízení. Vše s ohledem na požadavky zákazníka. Nesprávně použité metody však mohou vést ke špatným závěrům. Často se stává, že použití více metod není nijak koordinováno, což vyúsťuje ke spuštění redundantních nebo dokonce konfliktních projektů. Následuje popis metod, resp. nástrojů pro zvýšení konkurenceschopnosti podniku a pro zvýšení spokojenosti zákazníka (základem změny je BPR): 1. Strategické plánování V dnešní době se strategické plány mění velice často jako reakce na situaci na trhu. Strategické plánování by se tomu mělo přizpůsobit. Celý proces by mělo podpořit strategické plánování IS/IT. Bez strategického plánování by se podnik potácel v chaosu. Řešené otázky: - co je potřeba učinit v současnosti, aby byl podnik za několik konkurenceschopný? - jaký je cílový trh podniku a kdo jsou přesně naši zákazníci? - je cílem větší obrat, větší podíl na trhu nebo jiné kritérium 2. BPR Nejde o izolovaný proces, ale o šířeji pojatou strategii podniku. V informační společnosti se BPR úzce váže na strategické plánování. Zvláštní důraz je kladen na roli IS/IT v reengineeringu. 3. Průběžné zlepšování procesů Cílem podnikových procesů je zajištění podnikové strategie vyplývající ze strategického plánu. Zvýšení konkurenceschopnosti podniku musí nejen rychlé a výrazné, ale také dlouhodobé. Může vyústit ař v BPR, ale i po něm jsou procesy v pohybu. Podpora IS/IT procesů je klíčová. 4. Procesní modelování Modelování odráží část reality, tj. podnikový proces. Úkolem modelu je detailní popis průběhu jednotlivých procesů a jednoznačná identifikace procesu tak, aby bylo možné určit další průběh na základě současného stavu a aby bylo jasné, jaké má proces vstupy, výstupy, role a způsob provádění. Podpora IS/IT spočívá v poskytování řady nástrojů na modelování. (grafické komponenty pro modelování procesní architektury, simulační komponenty pro zjištění charakteristik průběhů procesů, referenční modely různých odvětví a programových aplikačních balíků, analytické nástroje, nástroje ABC [Aktivity Based Costing]). 5. Metriky Slouží ke správnému měření činností a získání realistického obrazu o výkonu podniku. Měření výkonu je základní manažerský nástroj. Lze jej využít za prvé jako klasický nástroj řízení (nátlaková metoda s hrozbami postihu) nebo za druhé jako motivační nástroj (metoda koučování). Záleží na situaci v podniku, na manažerovi, stylu řízení i situaci na trhu. Měřit se dá téměř vše. Co nelze měřit, nelze ani řídit. Měření je zacílené na zvyšování konkurenceschopnosti a vztahuje se k současným procesům. V dlouhodobějším horizontu je použito měření k zjištění efektivitu změn procesů. Velký význam též v IS/IT. Cíle a kritéria přínosů IS/IT: - cíle o zainteresování dodavatele nebo interního IT oddělení na dosažení přínosů IS/IT o vytvoření účinné platformy pro sjednocení cílů týmu odběratele i dodavatele o objektivnější obrázek o efektivitě prostředků vložených do IS/IT - kriteria tzv. měkká o oblasti, jejichž zlepšení povede podle přesvědčení zákazníka k vyší výkonnosti o hodnotí míru vytvoření potenciálních efektů realizací IS/IT - kriteria tzv. tvrdá o ukazatelé objektivně měřitelné o podporující podnikové cíle o směřující k zákazníkovi Doporučuje se mix metrik jak z hlediska zkoumání výkonového měření podniku (tvrdé m.), tak i z pohledu zákazníka (měkké m).

6. Řízení kvality – TQM (Total Quality Management) - 4/8 -

TQM se objevilo nejdříve ve výrobě, v 90. letech se stalo filozofií podnikání. Nástroje TQM (Ceny kvality) se stávají také marketingovým argumentem (i v ČR). Cílem TQM je uspokojit zákaznické požadavky co nejefektivněji. Aktivity vycházející z TQM jsou co rozsahu i rizika neúspěchu menší než u BPR. I tak jsou osvědčeným nástrojem transformace podniku. Příkladem TQM je posun v myšlení celého podniku a všech zaměstnanců tak, aby - se provozovaly jen činnosti nezbytné s správné - činnosti prováděly kvalitně a správně hned napoprvé Řízení -

kvality TQM vyžaduje vždy:

znalost zákazníka znalost a porozumění podmínkám vlastního podnikání funkční a nákladovou analýzu systém řízení jakosti spojité vylepšování kvality nástroje a metody řízení kvality

Ceny jakosti, jakožto nástroje TQM, shrnují požadavky na první dva body a na práci s daty a informacemi.

Obrázek 1: Zdroj - Metriky v informatice (Pour) Nástroje řízení kvality jsou: - Ceny kvality - týmová práce - srovnávací standardy - plánovací nástroje kvality např. QFD (Duality Function Deployment), a další V současnosti je ve světě ohlášena ve světě řada cen a soutěží. Jejich podstatou není ani tak samotné získání, jako nastavení obecného povědomí o nutnosti zvyšování kvality. Samotné úsilí o získání ceny zvyšuje úsilí o správné nastavení procesů. Samotná kritéria příslušné ceny jsou inspirací pro podnikové vedení, co lze všechno vylepšit.

Cena Malcova Baldrige Cena MBNQA (M.B. National Quality Award) je založena na hodnocení kvality výrobků a služeb. Založena v Americe, kde ji místním firmám uděluje Národní institut technologických standardů - 5/8 -

(NIST). V ČR se kritérii MBNQA a Evropské ceny za jakost řídí Česká společnost pro jakost a Sdružení pro cenu ČR za jakost. Při hodnocení se vychází ze 7 kategorií: 1. vůdcovství 2. strategické plánování 3. zaměření na trh, zákazníky a jejich spokojenost 4. informace a analýza 5. rozvoj a řízení lidských zdrojů 6. řízení kvality procesů 7. výsledky podnikání Kategorie se dají přirovnat ke kategoriím ISO9001. Každá kategorie (v NBNQA) je provázena sérií dotazů a podle míry naplnění dotazu se ji přiřadí určitý počet bodů (celkově jich je 1000). Jde o dost subjektivní hodnocení. Jde o vysoce diagnostickou metodu, jejíž naplňování jasně ukáže bariéry v podniku a vtáhne do problémů řízení i zaměstnance. Tak se vytváří podpora zdola nahoru záměrům vedení. Standardy kvality Mezi požadavky na TQM patří zavedení systému řízení kvality. Tento systém obsahuje standardy kvality, např. ISO9000. To bylo vytvořeno organizací ISO. Standardy jsou určeny pro kontraktační řízení (dodavatelsko-odběratelské vztahy). ISO normy cílově směřují k zavedení a dokumentaci systému kvality, resp. standardů kvality. To je zásadní rozdíl oproti přístupu Baldrigově ceny, jejíž cílem je dosažení konkurenční výhody a to prostřednictvím nepřetržitého zlepšování péče o zákazníka. Ta obsahuje právě něco více než jen statické ISO normy.

4

Změny v postavení řízení informatiky v řízení firmy.

4.1.1

Charakteristika změn v řízení IS/IT

Řízení IS/IT je chápáno jako součást řízení podniku. V 70. a 80. letech byly IS založeny na stejnorodých aplikacích. Jediné, v čem se lišily, byly výkonnostní parametry. V 90. letech prošly IS mimořádným vývojem a současný stav lze charakterizovat: - zkracující se doba mezi inovacemi (z několika let na měsíce; zkracuje se jak samotná doba inovace aplikací, tak i perioda obměn požadavků na ně; zrychluje se tempo nároků na koncepční změny IS) - vysoká heterogenita produktů, aplikací a služeb (různé aplikace běží „vedle sebe“, pro jiné uživatele, nad jinými technologiemi apod. Např. aplikace pro takt. a oper. řízení, MIS, ebusiness aplikace, bank. systémy,…) - globalizace informačního prostředí (vznikající GIS, dynamizující rozvoj infrastruktury, rozvoj informatické vzdělanosti, apod.) Všechny tyto aspekty mají zásadní vliv na řízení informatiky – to se mění. Důsledky: stále více služeb je outsorcováno, externí vztah se musí koordinovat, aplikace musí být integrovány, zvyšující se význam externích informačních zdrojů. Oproti 70. a 80. letům se minimalizuje řízení vlastních vývojářských aktivit. Na druhou stranu roste problém INTEGRACE. Nové nároky na řízení IS/IT vyplývají z ekonomických, obchodních a provozních potřeb a cílů firmy a současně z nových možností IT. Nové cíle řízení IS/IT lze charakterizovat: 1. zajistit vysokou funkcionalitu IS (na úrovni základních, resp. transakčních funkcí především analytických funkcí, funkcí pro podporu rozhodovávání, BI, 2. dosáhnout požadované úrovně disponibility IS/IT (bezpečnost, spolehlivost, flexibilita) 3. maximalizovat poměr efektů IS/IT (hlavně ekonomických) a vynaložených nákladů (nutnost měřit) Integrace řízení IS/IT do podnikového řízení - informatika zasahuje téměř do všech klíčových i podpůrných procesů - zvýšení počtu uživatelů - růst komplexnosti a složitosti IS Podstatné momenty v integraci řízení IS/IT do podnikového řízení:

- 6/8 -

Rozvoj řízení podniku -

-

IS/IT umožnilo, že složité se hierarchické řídící struktury transformovaly do několika málo řídících procesů (procesní řízení), dochází ke zplošťování org. struktury a jasnému vymezování pravomocí a odpovědností. s procesním řízením souvisí potřeba BPR tlak konkurence vede k nejrůznějším projektům zvyšování kvality (ISO, MBNQA, TQM) trend desintegrace řízení do samostatných provozních jednotek, avšak řízení marketingu a informatiky se doporučuje zachovat centralizované (efektivnější alokace zdrojů, synergický efekt) hranice řízení IS/IT a samotného např. výrobního procesu se někdy stává nejasnou a nastávají kompetenční problémy

Pozice řízení IS/IT v řízení podniku -

-

celková úroveň řízení IS/IT je přímo úměrná úrovni řízení podniku kromě toho jsou zde i jiné aspekty: o rozsah a struktura uživatelské sféry, případně zákazníků IS služeb o rozsah a struktura IS služeb pro partnery (EDI, konzultační služby,…), struktura a počet zákazníků, jejich požadavky o míra outsorcingu činností vývoje a provozu o funkce systémového integrátora (vlastní či dodavatelsky) o personální síla útvaru informatiky i přes případnou vysokou míru outsorcingu se doporučuje vlastní řízení IS/IT, které by mělo mít zastoupení i v top managementu pro některé firmy se stává informatika podnikatelskou aktivitou (rezervační, projekční, konzultační služby)

Řídící komise IS/IT -

-

cílem je provázat řízení IS/IT a řízení všech dalších oblastí nutností je dostatečná kompetence a odpovědnost; jde o manažerské funkce, ne technické měla by podporovat integraci IS/IT jednak do jednotlivých oblastí řízení (tj. horizontální integrace), tak i organizačních úrovní řízení (tj. vertikální integrace) je poradním orgánem vedení společnosti (posuzuje strategii podniku z pohledu informatiky , naplňuje ji a kontroluje čerpání zdrojů, posuzuje a přijímá řídící metodické dokumenty, řeší koordinaci, … v čele je zástupce top managementu a dále informační manažer a zástupci dalších klíčových útvarů

Cesty rozvoje IS/IT co je předmětem rozvoje řízení informatiky? o návrh a implementace komplexního systému řízení IS/IT, obsahovou náplň tvoří: vymezení úrovní IS/IT, funkce řízení IS/IT, procesy řízení, dokumentace řízení, pracovní role v řízení a organizace IS/IT - z čeho vycházet? o z celkové koncepce řízení podniku, podnikové strategie o z výsledků projektů BPR, TQM,… - jak postupovat? o etapy: 1. vymezení cíle a účelu řešení systému řízení IS/IT 2. určení týmu 3. analýza dostupných zdrojů řešení (tj. z čeho vyjít) a stanovení jejich využití 4. stanovení úrovní a hlavních oblastí řízení IS/IT v podniku 5. SWOT analýza 6. zpracování koncepce řízení IS/IT (klíčové procesy, struktura dokumentace,…) 7. řešení jednotlivých oblastí řízení IS/IT 8. návrh organizace IS/IT (účast rolí na řízení, organizační struktura informatiky) 9. detailní návrh dokumentace kompletace systému řízení IS/IT v podniku, jeho oponentura a prezentace a zpracování potřebných podnikových směrnic -

- 7/8 -

Praktická úloha

Jak budete dál postupovat? Odpověď není pouze jedna a každý si při státnicích musí zvolit sobě vlastní styl jednání v této situaci. Např. fa se rozhodla jednat na strategické úrovni, zde je otázkou, zda je nutné při pouze mírném poklesu tržeb ihned jednat na úrovni strategické. Strategie totiž může být v pořádku a je nutné pouze řešit otázky na úrovni taktické anebo operativní. Prvním krokem tedy bude identifikovat příčinu poklesu tržeb (pravděpodobně na úrovni taktické) a příčinu vyššího počtu reklamací (možno na úrovni operativní). Zjištění lze provést pomocí dotazníků anebo si objednat analýzu od externí konzultační firmy. Je vhodné začít dotazovat se samotných zákazníků na jejích názory ohledně produktů firmy.

Jaké možnosti se nabízejí na trhu konzultačních a auditorských služeb? Veliké nejen co do počtu firem, ale zároveň co do počtu a možných kombinací služeb. Preferoval bych v této situaci konzultační službu (spojenou s analýzou ve firmě) před auditem. Jaké si stanovíte priority a v jakém časovém horizontu? Do 1 měsíce provést svoji analýzu stavu v podniku. Pokud příčiny nenaleznu, musím najmout externí konzultační firmu. S touto firmou lze již během prvního měsíce konzultovat některé detaily. Tato firma by měla provést během dalšího měsíce analýzu a najít příčiny (obě !!!). Ihned poté by mělo proběhnout opět sezení s vrcholovým vedením a pokud se nejedná o problémy na úrovni strategické , doporučit a delegovat úkoly do těch podnikových ob oblastí, kde lze problémy vyřešit (např. marketing). Problém by mohl být během 5 měsíců vyřešen. V následujícím půlroku bude nutno sledovat, zda se problémy vyřešily – opět s konzultační společností. Jaká rizika vaše řešení v sobě nese a jak s nimi naložíte? Vedení firmy nebude považovat mnou řešený problém za vážný. Dále mohou být problémy s finančním ředitelem, který nebude chtít povolit spolupráci s konzultační firmou (pravděpodobně bude dost drahá). Při řešení se může jednat o komplexní problém, který zasáhne všechny organ. orgány podniku a zde hrozí nepřijetí nutnosti problémy řešit od vedoucích a i od ostatních zaměstnanců v daných odborech.

Jaké profesní vlastnosti budete u svých podřízených hledat? Schopnost jednat s vedením ostatních odborů v podniku. Schopnost domluvit se s konzultační firmou. Schopnost analýzy, znalost podnikových procesů a prodávaných produktů firmy.

- 8/8 -

3.1 Principy řízení firmy v informační společnosti

3.1 Principy řízení firmy v informační společnosti Změny v působení firmy na trhu v podmínkách informační společnosti (podnik, zákazník, manažer). Nároky na pracovní sílu typické pro konkurenční prostředí IS/ICT. Přístupy a metody, ovlivňující konkurenceschopnost podniku IS/ICT, TQM (úloha standardů a nástrojů kvality v rozvoji firmy) atd. Změny v postavení řízení informatiky v řízení firmy.

1.1.

Informační společnost a její dopady Informační společnost vznikla konvergencí informačních a komunikačních technologií (ICT) a jejich využitím v nejrůznějších sférách lidských aktivit1. Nejdůležitějším zdrojem se na úkor materiálních zdrojů stávají informace a znalosti. Nyní je celý svět propojen do jedné globální komunikační a technologické sítě, především prostřednictvím internetu. Výchozí charakteristika informační společnosti v bodech: • základem informační společnosti jsou informační a komunikační technologie, díky kterým lze nepřetržitě, celosvětově, rychle přijímat, zasílat, sdílet informace • hlavními rysy informační společnosti jsou převaha práce s informacemi, interaktivita, integrace a globalizační tendence2 • globalizace označuje proces, jímž se informace, předměty, vztahy a procesy globalizují a postupně se tak stávají globálními; o řadě z nich lze hovořit jako o globálních teprve až s masovým rozšířením moderních informačních a komunikačních technologií, tedy s příchodem a rozvojem informační společnosti • budoucnost se stává obtížněji predikovatelnou, jelikož tempo a rozsah změn, trendů, nových oblastí, vědy, ekonomik a dalších společenských sfér je tak velké, že nenasvědčuje možnosti usuzovat na určité v minulosti třeba cyklické jevy a etapy (hospodářské či technologické cykly)3 Dopady3,4 na:

Podniky • zesilování konkurence, zvětšování trhů, globalizace konkurence (e-business) • fůzí a akvizic je čím dál více – globální racionalizace, virt. podniky, přesuny výroby • potřeba přizpůsobovat se neustálým změnám nabídkou, int. procesy a řízením • převis nabídky nad poptávkou, komoditizace produkce4, interdisciplinarita4 • rozšiřující se automatizace rutinní a fyzicky náročné práce4 • důraz na ekologickou produkci, redukci dopadů na živ. prostředí, ekologii obecně • elektronické obchodování je v mnoha oborech podmínkou nutnou, jinde k. výhodou • je třeba plnit individuálně požadavky každého jednotlivého zákazníka • reagovat pakticky v nulovém čase (act in zero time)

1

Gála,Pour,Toman: Podniková informatika, Grada 2006

2

http://interval.cz/clanky/nova-ekonomika-a-globalni-informacni-spolecnost/

3

Basl, Blažíček: Podnikové IS, Podnik v informační společnosti, Grada 2008

4

Šmída: Zavádění a rozvoj procesního řízení ve firmě, Grada 2007 - 1/4 -


• dochází postupně k celkové změně paradigmatu: mizí chráněné trhy, životní cyklus výrobků se zkracuje a měří se na měsíce místo let, další nové produkty jsou plánovány již v době uvedení novinek na trh, trhy se chovají globálně nejen z hlediska potřeb, ale i z hlediska možných míst, kde firmy umísťují své podniky

Zákazníky • vyvolává poptávku po nových produktech a službách • individualizace lidí, jejich potřeb, poptávky • lepší a rychlejší dostupnost produktů a služeb a péče o zákazníka • decentralizace komunikace a informací • mohou nakupovat elektronicky – z počítače, mobilního telefonu, dalších zařízení • zákazník si snadno a levně nalezne, či získá informace o nabídce a cenách produktů a služeb mnoha tržních subjektů, může ji porovnat a racionálněji se rozhodovat (viz například srovnávače cen www.zbozi.cz) • chování zákazníků a jejich potřeby se rychleji mění v čase

Manažery • znamená potřebu měnit způsob řízení tak aby se podniky dokázaly dostatečně rychle měnit a přizpůsobovat potřebám zákazníků a zvyšovat svou efektivitu • vyžaduje nové znalosti, kreativní přístup a kontinuální rozvoj vzdělání • klíčová je orientace na zákazníky, kteří se ovšem rychle dále vyvíjejí, jsou dynamickou skupinou, mění se jejich požadavky, potřeby se prohlubují • reakce na nové informace, situace a události jsou požadovány v čím dál tím kratším čase, podniky musí reagovat pružně

1.2.

Nároky na pracovní sílu Za výše uvedených okolností se mění nároky na pracovní sílu: • podmínkou je stále častěji kvalifikace pracovat s IS/ICT (webové aplikace, e-business, ERP, kancelářské aplikace, • požadovány jsou aktuální znalosti a kreativní přístup k práci • porozumění a využití potenciálu pracovních nástrojů (IS/ICT)

1.3.

Přístupy a metody ovlivňující konkurenceschopnost podniků Několik základních faktorů, které „zploštili“ svět a vycházejí z role ICT ve světové ekonomice (P. Friedman: World is Flat, k nalezení v knize Basl: PIS3, str. 22-23): • internet – umožnil široce čerpat, šířit volně dostupné informace po celém světě • outsourcing – umožnil vyčlenění procesů či jejich částí mimo podnik do míst s vhodnou infrastrukturou, obvykle k jinému podniku, specializujícímu se na daný outsourcovaný proces • offshoring – vyčlenění procesů či až částí podniků do zahraničí do míst s nižšími náklady, například do Indie (dnes běžně například call-centra, helpdesky) • supply chaining – propojení podniků, technologií a lidí za účelem vytvoření uceleného efektivního toku produktu či služby k zákazníkovi; dnes vznikají celé sítě podniků (např. clustery) - 2/4 -


• workflow software – podporuje automatizaci procesů, kooperaci pracovníků, skupin, podniků Dnešní management je vystaven „vlnám“ moderních metod a přístupů, mezi které patří3: • podnikový controlling • štíhlá výroba (lean production) • řízení podle six sigma • řízení podle cílů (management by objectives) • procesní řízení (process management; BPM - Business Process Management, BPR - Business Process Reengineering, CPI – Continous Process Improvement) • Balanced Scorecard • teorie omezení (TOC – Theory of Constraint; constraint management)

IS/ICT a vliv na konkurenceschopnost Informační a komunikační technologie, coby základ informační společnosti, mají spolu se strategickými záměry, inovacemi a iniciativami podniků velký význam a vliv na jejich konkurenceschopnost. Mezi konkrétní témata z oblasti IS/ICT patří: • e-business – označuje takové využívání ICT, které přímo podporuje podnikatelské aktivity, nebo dokonce znamená nový obchodní model, prodejní kanál, produkt, službu či generuje dodatečnou konkurenční výhodu k stávajícím produktům a službám (podskupinou e-businessu je také e-commerce, m-commerce) • Business Intelligence (BI) - je sada aplikací /a procesů, technologií/, jejichž cílem je účinně a účelně podporovat rozhodovací procesy ve firmě; podporují analytické a plánovací činnosti podniků a organizací a jsou postaveny na principech multidimenzionálních pohledů na podniková data, CS Wiki, EN Wiki, kniha Novotný, Pour, Slánský: Business Intelligence, Grada 2005 • Customer Relationship management (CRM) – řízení vztahů se zákazníky • Suply Chain Management (SCM) – řízení dodavatelských řetězců • Knowledge Management – řízení znalostí • Enterprise Content Management – systémy správy podnikových informací • Competitive Intelligence, apod.

TQM a vliv na konkurenceschopnost

Total Quality Management je přístup uplatňovaný od 50. let v Japonsku, dále na základě úspěchů rozšířen do USA a Evropy. První mezinárodní konference TQM v roce 1969. Ve Velké Britínii vzniká v roce 1987 International Organization for Standardization (ISO) – snaha formalizovat požadavky na systémy řízení a kvalitu. Do TQM patří postupně: • ISO 9000 – soubor standardů, které mají v organizacích zajistit uspokojování požadavků zákazníků na kvalitu výrobků a služeb, plnění právních norem a regulací, kontinuální zvyšování výkonnosti podniku a spokojenosti zákazníků v souladu s cíli • Business Process Reengineering (BPR) – změny ve fungování podniků prostřednictvím radikálních přepracování a implementování podnikových procesů (Hammer, Champy, 90. léta)

- 3/4 -


• Procesní řízení (BPM) – dnešní procesní řízení a procesní přístupy uplatňované v drtivé většině TOP 500 organizací; trvalé zlepšování fungování firmy prostřednictvím podnikových a mezipodnikových procesů, které vycházejí z jasně stanovené strategie a jsou obvykle podpořeny IS/ICT (info např. viz Architektura podnikání – viz článek Basl na BPM Portálu)

1.4.

Změny v postavení informatiky v řízení podniků Lze říci, že informatika se stala s rozvojem informační společnosti nedílnou a velmi významnou součástí řízení podniků. Důkazem je přímá podpora businessu IS/ICT prostřednictvím mnohých z výše uvedených nástrojů a přístupů. V současnosti kladen větší důraz na provázanost s podnikovými cíli, větší flexibilitu, výkonovou i nákladovou transparentnost informatiky (reprezentanti např. SOA, SaaS), kvalitnější řízení informatiky (ITIL, COBIT, viz okruhy řízení informatiky).

Úloha - předpoklady: Stal/a jste se asistentem obchodního náměstka generálního ředitele firmy, která na českém trhu distribuuje SW renomovaného světového výrobce. Firma má 110 zaměstnanců a čtyři pobočky po republice. Protože v posledním roce mírně klesal obrat a rostl počet zákaznických stížností, dostal jste za úkol identifikovat hlavní problémové oblasti. Svolal/a jste strategickou poradu vedení, ale přes vaše velké osobní úsilí jste se nedokázal/a orientovat ve vzájemných vztazích členů vedení a jejich postoji k zaměstnancům. Zadání:

Jak budete dál postupovat? Začneme nalezením příčiny poklesu obratu – z různých úhlů pohledu (dimenzí) zanalyzujeme výnosy firmy. Na příčinu se zaměříme a dáme ji do kontextu s potřebami zákazníků a konkurenční nabídkou, zhodnotíme silné, slabé stránky, příležitosti a hrozby (SWOT).

Jaké možnosti se nabízejí na trhu konzultačních a auditorských služeb? Nabízí se neomezeně možností.

Jaké si stanovíte priority a v jakém časovém horizontu? Nalézt příčinu problému a naplánovat dvě fáze jeho řešení – prvotní rychlý balíček rozhodnutí, který lze realizovat ihned a za druhé střednědobý plán změn, který povede k úplnému odstranění problému.

Jaká rizika vaše řešení v sobě nese a jak s nimi naložíte? Příčina problémů neumožní rychlé řešení, plán na změny se nepodaří realizovat, nebude přijat a další.

Jaké profesní vlastnosti budete u svých podřízených hledat? Kreativitu, flexibilitu, kompetentnost, znalost trhu, zkušenost.

- 4/4 -

3.2 Řízení firmy působící v oblasti IS/IT

3.2

Řízení firmy působící v oblasti IS/IT Základní charakteristiky firmy působící na trhu IS/IT. Specifické nároky na řízení informatické firmy. Postoje manažerů v USA a západní Evropě k e-podnikání, rozdíly a důsledky. Hlavní zásady pro řízení informatických firem.

1.1.

Charakteristika firem na trhu IT 1. Analýza poskytovatelů služeb IS/IT a systémové integrace v ČR (dle [2]) z průzkumu vyplývá struktura a vlastnosti našich informatický firem

tučné nadpisy jsou kritérii hodnocení IT firmy (tj. charakteristiky)

závěry lze považovat také za doporučení, jaká kritéria hodnotit nebo nehodnotit při výběru vhodné IT firmy

zkoumáno bylo 37 firem, závěry jsem zestručnil, informace jsou z roku 2000

Právní forma

většina akciovky, hodně také SRO, ostatní jsou organizačními složkami cizích firem

právní forma není statisticky významná, nekoreluje s žádnou jinou zkoumanou veličinou

pobočky zahraničních firem jsou většinou SRO

Základní kapitál špatně se zjišťuje

byl by významným kritériem, ale u řady firem se nedá zjistit – jeho váha jako kritéria při výběru firmy je tedy omezena

druhým aspektem je, že „kapitál“ firmy je dán více znalostmi pracovníků než finančním ohodnocením aktiv (ty lze ovšem měřit, znalosti ne)

Vlastnická struktura asi polovina domácí, zbytek zahraniční

podstatné kritérium, svědčí o velikosti firmy (věrohodněji, než základní kapitál), síla značky

Obrat za poslední rok dobrý ukazatel

zahraniční firmy dosahují na českém trhu trojnásobný obrat než české

produktivita na jednoho pracovníka je podstatně vyšší u zahraničních firem

Struktura pracovníků zahraniční firmy jsou připraveny u nás nabízet stejné služby v potřebné kvalitě, jako jinde na světě (tj. tvrdá konkurence nejen mezi českými a zahr. firmami, ale i mezi nimi navzájem)

bohaté zázemí pro prodej HW (ten ale poslední dobou stagnuje)

dynamika růstu pracovníků v oblasti SI relativně k ostatním profesím IT - 1/5 -


hodně dodávek služeb je vedena jako subdodávka (třetím partnerem), proto při podpisu smlouvy by mělo být jasno, kdo přesně bude činnost provádět (někdy jsou dodavatelé implementační firmy důležitější, než samotná implementační firma). Firma stojí na lidech!

Cílové sektory zákazníků sektor obchodu několik let dominoval, nyní se zájem více přesouvá do průmyslu

malý podíl školství, energetiky a bankovnictví. Daleko od průmyslu (myšleno jako cíl trhu) je také státní správa

Produkty zatím jasná dominance určitých produktů na jednotlivých segmentech trhu (ERP, BI, DB systémy,…)

nárůst nabídky v oblasti datových skladů

obtížně se s klasickým prodejem srovnávají webovské služby, e-business či ASP

Služby poskytování „standardních“ služeb většinou firem: informační strategie, analýza a návrh IS, konzultace, vývoj SW na zakázku, řízení IS/IT

nejslabší nabídka školících služeb a konzultačních služeb v oblasti ISO či BPR

pouze třetina firem nabízí síťové služby

malá nabídka CRM či SCM a e-businessu. Tohle evidentně dnes již NEPLATI.

Outsourcing dost firem se tváří, že poskytuje úplný outsourcing, ale ve skutečnosti poskytuje jen částečný

není možno úplně zjistit, zda je firma připravena na poskytování outsourcingu, zda má dostatečnou infrastrukturu, apod.

je to velký potenciál, ale u nás teprve ve zrodu; málo referenčních zákazníků, navíc z těch je dost negativních

Sdělování informací o cenách velká nechuť přesně něco sdělovat, nelze si cenu ani vykalkulovat,na druhou stranu každý projekt je unikátní Další charakteristiky počet poboček na území státu (u HW potřeba hodně)

budování firemní značky, obecného povědomí

množství a charakteristika referenčních zákazníků

firemní prezentace na webu, poskytování informací o firmě

úroveň uživatelské podpory (HelpDesk, Call centrum)

šíře zaměření produktu

cenová politika, ... - 2/5 -


2. Struktura produktů informatických firem HW (servery, pracovní stanice, periférie, síťové karty, kabeláž)

1.2.

1.3.

SW (aplikační SW, systémový SW)

služby (konzultace, projekční práce, implementace, SI, správa a provoz systémů) – stále více dominují

outsourcing, ASP

internetové firmy (ISP, webdesign)

ISV (krabicový SW, SW na zakázku)

prodejci, obchodní zástupci

Specifické nároky na řízení informatické firmy

Schopnost formulovat informační strategii

Schopnost rychle se a svoji nabídku přizpůsobovat turbulentnímu prostředí

Vedení firmy by mělo mít alespoň přehled a znalosti z vývoje a výroby IT produktů

Postoje manažerů v USA a západní Evropě k e-podnikání, rozdíly a důsledky. (Uvedené informace jsou z roku 2000 - Dohnal, takže brát s rezervou) Uvádí se, že v severní Americe je hlavním důvodem k implementaci elektronického podnikání

konkurenční tlak (minimálně nutnost držet krok s konkurencí; snaha zlepšit interní procesy prostřednictvím elektronického podnikání se jeví pouze jako druhotný důvod)

chápání elektronického podnikání jako součásti firemní strategie (konkurent využívající elektronické podnikání se chápe jako zvýhodněný)

Zdá se, že v Evropě konkurenční tlak není ještě tak výrazný a elektronické podnikání je vnímáno nikoliv jako strategická výhoda, ale jako

1.4.

nástroj na snížení nákladů,

zlepšení péče o zákazníka nebo

zlepšení podnikových procesů.

Sev. Amerika

Evropa

Iniciativu má vrcholový management

iniciativu má vedení informatiky

často zacíleno na podnikatelské přínosy

často zacíleno (bezpečnost)

Připravenost akceptovat rizika, pokud povede elektronické podnikání ke konkurenční výhodě

snaha minimalizovat rizika, krátkodobé taktické cíle

na

technologické

problémy

Hlavní zásady pro řízení informatických firem Klíčové faktory úspěchu

principy řízení: důsledné dodržování principů kvality, řízení projektů podle dané metodiky, sledování a řízení finanční výkonnosti firmy (finanční řízení projektů, kontrola nákladů, řízení pohledávek)

- 3/5 -


důsledně uplatňované principy příjímání a rozvoje lidí ve firmě, přístup k informacím, školení.

dokonalý interní informační systém (propracovaný zejména v oblastech plánování a vyhodnocování obchodních případů/projektů a jejich návaznosti na účetnictví

dokonalý systém vedení dokumentace

systém řízení kvality, který podporuje výše zmíněné principy řízení

kvalita práce u zákazníka založená na kvalitě lidi ve firmě

kvalitní a stabilní produkty s dobrou podporou od dodavatele IS, který má dobrou strategii rozvoje a dobrou reputaci na trhu

dokonalá personální politika

dokonalý systému vedení projektů

dobrá strategie

důraz na formování a vedení týmů

vytvoření takové firemní kultury, která podporuje přátelskou a tvořivou pracovní atmosféru, nové myšlenky a tvrdou práci.

komplexní portfolio produktu

orientace na služby (ty jsou dnes nejvíce výnosné)

Důvody pro projektové řízení firma se pohybuje v turbulentní době s vysokou mírou konkurence

firma musí pracovat na několika projektech najednou

každý projekt je jiný svou povahou, spotřebováním pracovních fondů, materiálním zjištěním, dobou

firma má zpravidla více dodavatelů

firma se zabývá specifickou oblastí podnikání, kde hrají roli rychle se vyvíjející technologie, kterým se musí neustále přizpůsobovat

pracovní síla v tomto oboru je drahá, nutné přesně plánovat využití a návratnost

- 4/5 -


2.

Úloha - předpoklady: Pracujete v týmu ředitele firmy dodávající širokou škálu produktů IS/IT. Vaši kolegové firmu úspěšně uvedli na trh a dosáhl zejména ve službách obratu řadícího firmu do první dvacítky firem na českém trhu. Firma však již třetí rok stagnuje v obratu a mírně klesá v ziskovosti (3% ročně). Zadání:

Čemu se budete po nástupu do funkce věnovat?

Jak bude vypadat váš seznam prioritních úkolů (produkty, vedení lidí, apod)?

V čem vidíte pro svoji firmu příležitost a proč a jak ji hodláte zvládnout?

Které produkty budete rozvíjet?

2.1.

Čemu se věnovat Jako první je třeba provést analýzu, která pomůže odhalit v čem je problém stagnace firmy. K tomuto účelu může pomoci

2.2.

Analýza trhu

Analýza poptávky cílové skupiny

Analýza produktového portfolia firmy

Analýza konkurence – je na tom podobně, roste nebo klesá? Hledat rozdíly

Jaká byla inovativnost produktů za poslední roky?

Došlo k výrazným personálním změnám – architekti, vývojáři, prodejci?

Ztrácíme nějaké zákazníky? V jakých oblastech? U jakých produktů?

Jak bychom mohli firmu prosadit na zahraničním trhu

SWOTka a z ní plynoucí strategie opatření a rozvoje

Prioritní seznam Ten bude vycházet především z předchozích průzkumů a na prvních místech by mělo být opatření vůči stagnaci a činnosti pro rozvoj firmy.

2.3.

V čem je příležitost Příležitosti by měly vyplynout z kvalitně provedené SWOTky. Proč a jak ji zvládnout se dá na obecné rovině těžko diskutovat. Důvod proč je jasný, chceme prachy. Jak? – efektivně a spolehlivě ala nějaká metodika a projektové řízení.

2.4.

Které produkty rozvíjet Ukládání a zálohování (50-75% investic do IT) Monitoring výkonnosti systému. Řešení BI, SaaS, a cloud computing.

- 5/5 -

3.3 Informační bezpečnost

Informační bezpečnost a bezpečnostní politika IS/ICT. Vztah bezpečnostní politiky IS/ICT k jednotlivým úrovním řízení organizace a významným dokumentům. Základní mezinárodní a české standardy, české zákony, nařízení a vyhlášky, které se vztahují k informační bezpečnosti.

Bezpečnost v informatice se skládá z objektové bezpečnosti, bezpečnosti a ochrany zdraví při práci a informační bezpečnosti. V informační bezpečnosti lze mluvit o antivirech, řízeních přístupu, šifrování. Obsahem následujícího je řízení informační bezpečnosti. Důvody • Hodnota informací: know-how, strategie,... • Legislativní požadavky ve státní sféře • Největší překážky: nízké povědomí, finanční náročnost • Problém hlavně v uživatelích • Nejčastěji viry pro získávání hesel Information Security Management System (ISMS) je manažerský systém – poskytuje rámec pro řízení bezpečnosti. Cílem je udržet dlouhodobě bezpečnost informací, která odpovídá potřebám organizace – opatření x náklady – a zlepšování. Zavedením tedy není dosaženo bezpečnosti, ale toho, že procesy řízení informační bezpečnosti jsou konzistentní. Vychází z: • ISO 17799:2005 – Code of practice for information security management > v roce 2007 byla přejmenováva na ISO 27002:2005. Obsahuje best practice. • ISO 27001:2005 – Information security management system – Requirements. (z britského standardu BS 7799-2). Obsahuje požadavky a umožňuje certifikaci. Principy těchto standardů: 1. Integrace manažerských systémů -ISO 27000 se prolíná s ISO 9000 (kvalita) a ISO 14000 (živ. prostředí), takže se lépe zavádí, když už třeba 9000 je. 2. PDCA model Plan (ISMS design) – definice rozsahu (procesy, org. jednotky), politiky, cíle, procesy, procedury. Do (ISMS implementation and operation) – preventivní opatření proti rizikům, vývoj krizových plánů, zavedení opatření, výběr metrik, školení, řízení zdrojů, nastavení reportování. Check (ISMS monitoring and evaluation) – hodnocení rizik, metrik, interních auditů. Act (ISMS maintenance and improvement) – nápravná opatření. 3. Definice politiky ISMS 4. Řízení informačních rizik – skládá se z: • identifikace rizik (aktiva > hrozby > zranitelnost aktiv > dopady) • analýzy a hodnocení rizik (podnikatelské dopady, pravděpodobnost) Pro řízení rizik existují metodologie (CRAMM) a standardy (BS 7799-3). Výsledkem jsou opatření, přijetí rizika, vyhnutí se riziku nebo přenos rizika – zvážit náklady. Doporučení pro informační bezpečnost jsou: 1. Zavést řízení rizik jako součást řízení informační bezpečnosti 2. Mít bezpečnostní politiku:

3. Řídit informační bezpečnost 4. Realizovat řízení aktiv 5. Věnovat dostatečnou pozornost personální bezpečnosti 6. Řešit fyzickou bezpečnost 7. Řídit komunikace a provoz 8. Řídit přístup k systémům 9. Věnovat dostatečnou pozornost pořízení, vývoji a údržbě 10. Řešit bezpečnostní incidenty a nedostatky 11. Řídit správu kontinuity 12. Zajistit soulad se standardy a právními normami Politika ISMS Základní strategický dokument: cíle, směr a principy bezpečnosti. Často to samé jako politika informační bezpečnosti. Je založena na: • podnikové strategii • požadavcích na informační bezpečnost • bezpečnostní požadavky obchodních partnerů a třetích stran • zákonech, standardech a dalších obecně závazných předpisech Obsahuje: • definici informační bezpečnosti, její cíle a rozsah, její důležitost • deklaraci o podpoře managementem • krátké shrnutí požadavků a principů vyplývající z legislativy a standardů • definici zodpovědností • kritéria pro hodnocení rizik • systém pro reportování bezpečnostních incidentů • odkaz na další dokumenty Vztah k úrovním řízení Pro řízení bezpečnosti je sestaven projektový tým, který ji má na starosti. Bezpečnost musí procházet celou organizací, takže vlastnící klíčových procesů. Organizace: 1. sponzor projektu (někdo z top-managementu) 2. manažer projektu, koordinátor projektu 3. Ostatní členové týmu Možnost zapojení externí poradenské firmy. Zkušenosti x únik inofrmací. Vrcholový management musí: 1. podporovat zavedení 2. spolupracovat na bezpečnostní politice 3. zajistit vytvoření bezpečnostních cílů a plánů 4. komunikovat inf. bezpečnost v celé organizaci 5. zajistit dostatečné zdroje

6. rozhodnout o přijatelné úrovni rizika 7. kontrolovat management bezpečnosti Ostatní musí dodržovat bezpečnostní politiku. Vztahy s dalšími dokumenty • Globální podniková strategie • Corporate Governanace politika • Podniková bezpčnostní politika • Informační strategie • Katalog poskytovaných IT služeb a SLA • Analýzy rizik procesů • Historie porušení bezpečnosti • Popis probíhajících změn • Detaily o partnerech a třetích stranách Legislativa v ČR • 101/2000Sb., o ochraně osobních údajů • 106/1999Sb., o svobodném přístupu k informacím • 499/2004Sb., o archivnictví a spisové službě • 365/2000Sb., o informačních systémech veřejné správy • 127/2005Sb., o elektronických komunikacích • 227/2000Sb., o elektronickém podpisu • 480/2004Sb., o některých službách informační společnosti • usnesení vlády č. 624 z 20.6.2001, o pravidlech, zásadách a způsobu zabezpečování kontroly užívání počítačových programů • ústavní zákon 110/1998Sb., o bezpečnosti ČR • 148/1998Sb., o ochraně utajovaných skutečností • vyhláška NBÚ 56/1999Sb., o zajištění bezpečnosti informačních systémů nakládajících s utajovanými skutečnostmi, provádění jejich certifikace a náležitostech certifikátu Legislativa EU • Směrnice 1997/66/ES, o ochraně dat v telekomunikacích. • Směrnice 1995/46/ES, o ochraně osobních dat. • Směrnice 2002/58/ES, o soukromí v elektronické komunikaci. • Směrnice 1999/93/ES, o zásadách Společenství pro elektronické podpisy. • Směrnice 2002/58/ES, o zpracování osobních údajů a ochraně soukromí. • Nařízení 2001/45/ES, o ochraně fyzických osob při zpracování osobních údajů orgány a institucemi. • Směrnice rady 1991/250/EHS, o právní ochraně počítačových programů. • Směrnice rady 2001/264/EC, o ochraně utajovaných informacích Standardy • ISACA ◦ certifikát CISA (Certified Information Systems Auditor) ◦ směrnice a pracovní postupy ◦ CoBIT Security Baseline – sada základních bezpečnostních praktik odvozených od CoBIT • ISO / IEC (International Electrotechnical Commission) ◦ ISO 2700x (0-6) ◦ ISO/IEC 17799:2005 ◦ ISO 2000x: IT service management

•

◦ BIP 007x: návody na zavedení 27000 - British Standard Institution ◦ ČSN ISO/IEC 13888 Informační technologie - Bezpečnostní techniky – Nepopiratelnos ◦ a moře dalších ITIL ◦ Service Design: Information Security Management.

Další zdroje informací • Stručný přehled o MV ČR na http://web.mvcr.cz/archiv2008/micr/files/2705/06_nsib_cr_priloha_2_v0_8__2_.pdf • Riadenie a audit v informačnej bezpečnosti. Příručka pro manažera. Nakladatelství TATE. • pár dalších standardů na http://www.fi.muni.cz/usr/staudek/vystavelova/index.html :) Úloha - předpoklady: Jste v pozici řídícího pracovníka, který má za úkol sestavit bezpečnostní politiku IS/ICT. Zadání: Jaký tým budete potřebovat, specifikujte jeho složení, funkční náplň jednotlivých členů. Diskutujte začlenění tohoto týmu do organizační struktury organizace V různých fázích různí lidé. Najednou by se asi moc nedomluvili. Řešitelský tým: • interní / externí odborník na IT bezpečnost (jak na to) • vedoucí helpdesku (způsob reportování) • zástupce IT (možnosti a stav IT, náklady řešení) • analytik (interview s vlastníky dalších procesů, pro zjištění jejich pohledu a požadavků externích partnerů, se kterými jsou v kontaktu; administrativní činnost) Další lidé, kteří by měli být zapojeni: • další lidé z IT oddělení (architekt IT (začlenění bezp. prvků, slabá místa), technici, ...) • vlastnící klíčových podnikatelských procesů (hodnota aktiv, možné hrozby, přípustná řešení) • správce podnikových metodik a standardů (koncepce; vztah k ostatním dokumentům) • osoba zodpovědná za plán kontinuity (identifikovaná rizika, zajištění bezpečnosti v krizi) • zástupce personálního oddělení (právní otázka, povinnosti zaměstnanců, motivace, školení) • zástupce bezpečnostní agentury zajišťující ostrahu prostor firmy • generální ředitel (podpora) Zařazení jako štábní jednotka hned pod nejvyšším vedením.

3.4 Podstatné parametry aplikačních programových balíků

Podstatné parametry aplikačních programových balíků

Parametry ASW, možnosti hodnocení a výběru ASW pro konkrétní podmínky, příklady ASW. Implementační metody a nástroje pro nasazení ASW v konkrétních podmínkách. Příklady metod a nástrojů, základní fáze implementačního postupu, customizace, prototypování, organizace a řízení implementace ASW v praxi.

1.1.

Parametry ASW Parametry ASW

Základní údaje

Architektura

Provozní a vývojové prostředí

Dokumentace, služby

Vlastnosti produktu

Tvůrce

Modulární skladba

Databázové systémy

Dokumentaceformy

Standardy, certifikace

Distribuce

Vývojové prostředky

Operační systémy

Údržba rozsah,cena

Vazby na produkty

Orientace

Vazba na ZSW

Vývojové prostředí

Projekční služby

Flexibilita

Cenové charakteristiky

Implementační nástroje

CASE

Školicí služby

Paralelní organizace

Přehled instalací

Referenční modely

Uživatelské rozhraní

Konzultační služby

Specifické funkce

Jazyky

1.2.

Možnosti hodnocení a výběru ASW pro konkrétní podmínky Výběr (řešení) aplikací, resp. aplikačního software informačního systému lze realizovat několika možnými způsoby:

vývojem specializovaného, „jednoúčelového“ software podle potřeb konkrétního zákazníka. V těchto případech jde o rozsáhlé projekty pro státní správu, specializované bankovní aplikace, projekty vyžadující maximální bezpečnostní zajištění nebo projekty, kde vhodný aplikační software zatím není k dispozici,

nákupem a instalací typového aplikačního software s minimálními nároky na jeho úpravy (customizaci). To odpovídá především situaci relativně malých projektů, např. účetnictví pro samostatné podnikatele, projekty pro malé provozovny apod.,

komplexními projekty založenými na výběru velkých aplikačních software, jejich customizaci, jejich vzájemné integraci, s ev. dořešením a implementací těch částí nebo modulů, které typový aplikační software nepokrývá nebo neodpovídá potřebám zákazníka. Tato situace je dnes naprosto převažující u středních a velkých obchodních podniků nebo u větších organizací cestovního ruchu. Takové úlohy vyžadují poněkud - 1/4 -


jiný přístup k jejich řešení, než tomu bylo v případě varianty a), i když celá řada činností je založena na obdobných principech. Kritické faktory ERP – lze použít k hodnocení ASW

1.3.

1.4.

1.5.

existence, resp. úroveň informační strategie, vazba na podnikovou strategii,

úroveň celkové architektury IS/IT,

správná definice požadavků na ASW, úroveň detailu,

optimalizace procesů,

účast vedení na koncepci IS/IT a výběru ERP,

informovanost personálu podniku o koncepci IS/IT a výběru ERP,

stanovení reálného rozpočtu•existence, resp. úroveň informační strategie, vazba na podnikovou strategii,

úroveň celkové architektury IS/IT,

správná definice požadavků na ASW, úroveň detailu,

optimalizace procesů,

účast vedení na koncepci IS/IT a výběru ERP,

informovanost personálu podniku o koncepci IS/IT a výběru ERP,

stanovení reálného rozpočtu

Příklady ASW

Enterprise Resource Planning,

Supply Chain Management,

Customer Relationship Management,

Business Inteligence,

Účetnictví,

Kancelářské aplikace,

Workflow systémy

Implementační metody a nástroje pro nasazení ASW v konkr. podmínkách

obecné metodiky - SIV, SE,

firemní ve vazbě k ASW - ASAP, BASIS, Target

proprietární - APP, ORM

definování hranic - obsahu,

podpůrné nástroje - různá podpora činností metodiky

Příklady metod a nástrojů

implementační metodiky (ASAP,…),

analytické a modelovací nástroje – samostatné nebo integrované (ARIS, BAAN - DEM – Dynamic Enterprise Modeling,..), BAAN - skládá se ze čtyř dílčích modelů vytvořených podnikovým modelérem, z modelu řízení podniku, modelu podnikových funkcí, modelu podnikových procesů a z modelu organizace podniku.

referenční modely - předlohy pro tvorbu specifických projektových modelů podniku - 2/4 -


1.6.

mapy řešení (solution maps – SAP),

Základní fáze implementačního postupu, customizace, prototypování

Implementační fáze dle MMDIS o

vytvoření uživatelské dokumentace a pravidel provozu aplikace,

o

vytvoření provozního prostředí,

o

nastavení parametrů,

o

úpravy obrazovek,

o

realizace výstupních sestav,

o

nastavení přístupových práv,

o

transformace dat do nového systému,

o

analýza zatížení systému a jeho optimalizace,

o

integrační testy.

úrovně personalizace: 1. standardní řešení (R/3), 2. odvětvová řešení, 3. přizpůsobení pro zákazníka - podnik, 4. přizpůsobení pro skupinu uživatelů, 5. uživatel

1.7.

Organizace a řízení implementace ASW v praxi Požadavky na implementaci ASW

dosažení požadovaných efektů (ekonomické efekty, racionalizace procedur,...),

rychlost implementačního procesu,

přijatelné náklady,

flexibilita vzhledem ke změnám

- 3/4 -


2.

Úloha - předpoklady: Jste představitelem ICT firmy dodávajícího aplikace pro ERP systémy. Dodáváte plně lokalizovaný zahraniční produkt s velmi dobrou podporou zahraničního dodavatele. Připravujete presentaci Vaší firmy v rámci výběrového řízení vypsaného zákazníkem. Zadání:

Jaké informace si zjistíte předtím, než budete presentaci připravovat ?

Co bude předmětem presentace ASW, jaká bude její struktura ?

Na co budete klást při presentaci ASW hlavní důraz ?

2.1.

zjišťování informací • Čím se firma zabývá? • Jaká jsou ve firmě oddělení a jaké jsou mezi nimi vazby? • Jaký používá stávající systém? Ideální je zjistit stávající náklady na ERP. • Jaké objemy vyrábí?

2.2.

struktura prezentace • Stručné představení firmy a renomé dodavatele, vybrané reference. • Představení produktu a jeho možností • Jaká je parametrizovatelnost a kastomizovatelnost s ohledem na známé fakty o podniku. • Případová studie nasazení produktu v podobné oblasti či dle dostupnosti informací přímo na podniku.

2.3.

důraz v prezentaci na • na best practises zahrnuté v produktu • úspory a zrychlení procesů • rychlost nasazení • flexibilita

- 4/4 -

3.5 Řízení úloh Business Intelligence Místo BI v architektuře podnikového IS/ICT, charakteristika věcné a datové orientace BI, technologické principy BI – OLAP, zvláštnosti projekce BI, nástroje pro tvorbu BI. Úloha - předpoklady: Jste analytikem útvaru informatiky firmy působící na našem trhu v oblasti distribuce energie (utility). V rámci harmonogramu rozvoje Vašeho IS/ICT máte zahájit řešení aplikací BI ve Vaší firmě. Jste pověřen vedoucím tohoto projektu . (že bychom se šli rovnou oběsit?:)) Zadání: -

Jaké výchozí předpoklady celého řešení budete formulovat ? - viz obsah ve studii proveditelnosti Jaký způsob řešení zvolíte ? - záleží na požadavcích byznysu - takový, aby byl nejlepší poměr cena/výkon Jaké základní kroky v postupu řešení budete definovat a kdo se na nich bude podílet ?

Co to je BI, charakteristika věcné a datové oblasti BI je souhrn principů, procesů, technologií a nástrojů, pomocí kterých je možné získávat důležité strategické informace o společnosti. Tyto informace jsou pro podnik stěžejní, aby se mohl rozhodovat na základě toho, co udělal. Z BI tedy vystupují informace, které slouží k řízení a rozhodování. BI řešení spadá do OLAP (on-line analytical processing) nástrojů, které umožňují analytické rozbory dat přímo nad databází (rychlost jedné operace zde nehraje tolik roli, může být i v řádech hodin – u transakčních systémů je to v řádech milisekund, jde také o jiný typ informací – operativní...). Databází se má v tomto případě na mysli určitý datový sklad (data warehouse, cds). Narozdíl od běžných databází uchovávají DWH data s těmito charakteristikami: -

Konsolidovaná o

v datawarehousu se informace dostají do jedné tabulky. Pokud 2 záznamy reprezentují 1 realitu tak se to sloučí do jednoho produktu (např. švestky a slivovice). Je tedy zřejmé, že se do DWH dostávají data z mnoha zdrojových systémů (ERP,CRM,SCM..)

-

Konzistentní

-

Subjektivně orientovaná

o o

-

v centrálním datovém skladu nejsou všechna data ze zdrojových systémů, vždy se jedná o nějakou oblast.Jaká data do CDS – souvisí s otázkou kvality dat,MDM a určení klíčových dat

Historická o

-

nejsou tam informace, které by si vzájemně protiřečily – např jméno Nováková, pohlaví – muž

Data se tam zadávají a nemažou se, aby je bylo možné historicky porovnávat. Souvisí s tím SCD (slowing change dimensions), které určuje, zdali se u jedné konkrétní položky sleduje pouze aktuální stav, který se nikdy nemění (např. pohlaví bude vždy muž nebo žena) – historie se tedy nesleduje, případně se sleduje pouze jedna položka (která přepíše stávající) či se sleduje celá historie

Agregovaná o

většinou se nedávají úplné detaily, ale agregace (dnes je ale snaha tam mít všechno)

Proč to zavádět – příklady využití BI Dá se rozdělit do tří oblastí – IRACIS model (increase revenue, avoid cost, improve service): -

Snížení nákladů o o

-

Zvýšení příjmů o

o o o

-

Redukce času při přípravě reportů a analýz (ty provádět nad transakčními systémy a sjednocovat to to je hell) Zefektivnění řízení rizik – např. kterému klientovi poskytnout úvěr a kterému nikoliv Lepší zacílení marketingových kampaní (víme kteří typoví zákazníci jsou nejvýnosnější, v kterých segmentech, přes kteý distribuční kanál..), víme jaké produkty kupují společně..(úzká souvislost s data miningem a analýzou nákupního košíku) Včasné varování při propadu obchodu Varování před odchodem zákazníků a snížení jejich odchodovosti(churn management – pravděpodobnost odchodu zákazníka) Vyšší efektivita prodeje (víme přes který kanál, kdy, kde je to nejvýnosnější...), xselling, upselling

Zkvalitnění služeb o o

Lepší pochopení zákaznických preferencí – souvisí s analytickým CRM, víme který typ zákazníků co většinou kupuje a co si s tím většinou přiobjednává Rychlejší vyřešení stížností klientů (souvislost s KPI)

Page 1

BI a místo v architektuře IS/ICT Pokud si představíme extrémně zjednodušený proces BI, ve kterém se dostanou ze zdrojových systémů do datového skladu data, odkud jsou dále využívány pro reporting, datamining či multidimenzionální OLAP kostky, tak zjistíme, že je třeba řada komponent proto, aby toto řešení fungovalo: -

Zdrojové systémy o

-

nástroje pro zajištění kvality dat o

-

o

umožní konečné zobrazení a vizualizaci dat pro konečné uživatele

data-minigové nástroje o

-

umožňující analýzy a tvorby multidimenzionálních kostek, které mohou sledovat jednu veličinu podle více dimenzí

reportovací a manažerské nástroje o

-

defacto se jedná o předmětově orientované dwh (ty bývají obecnějšího charakteru, datamarty se věnují např. jen rizikům).

OLAP nástroje o

-

Zdaleka ne ve všech BI řešeních, Jedná se o jednotné místo, kde už jsou konsolidovaná, agregovaná a hlavně aktuální data.

DWH - datový sklad, jehož specifika byla již probrána Datamarty o

-

Předtím než se data dostanou do CDS je třeba je nějakým způsobem někde upravit. Tento "odpaďák" je vhodné místo

Operativní úložiště o

-

ETL - extraction transformation load - transformační nástroje , které extrahují data ze zdrojových systémů a poté s nimi provedou určitou transformaci, následně je pak nahrají do CDS EAI - enterprise application integration - tyto nástroje propojují zdrojové systémy, odstraňují redundantní spojení (spaghetti systém, kdy jsou zdrojové systémy propojené navzájem každý s každým). Defacto se jedná o platformu. Informace, které získávají ze zdrojových systémů jsou na rozdíl od ETL v reálném čase.

Dočasná úložiště dat (DSA - data storaging area - "Stage") o

-

bez kvalitních dat nebudou kvalitní výstupy a ani kvalitní rozhodování. Více viz Řízení kvality dat.

Transformační a integrační nástroje o

-

Jedná se o systémy, ze kterých jsou extrahována data pro BI

umožňují hledání skrytých souvislostí - jak souvisí příjem a věk klienta s neschopností splácet půjčky, co zákazník kupuje pospolu a další

nástroje pro správu metadat o

řada čísel je hezká věc, ale když nevíme, co znamenají, tak je to k ničemu. Extrémně důležité nejen pro koncové uživatele, ale i pro analytiky tvořící reporty či při čištění dat pro objevení sémantických chyb

Z tohoto počtu a druhů nástrojů vyplývá několik podstatných věcí -

BI není řešení, které si lze koupit jako jeden nástroj (u CRM, ECM a jiných PIS to jde.). Je také vysoce pravděpodobné, že jednotlivé části řešení budou i od jiných firem. Součástí BI řešení jsou produkční systémy, jejichž kvalita dat výrazně určuje kvalitu výstupů z BI. S tímto souvisí otázka Řízení kvality dat. BI nejenomže odebírá data ze mnoha zdrojových systémů, které jsou zaměřeny na různé oblasti (dodavatelé – scm, zákazníci – crm, účetnictví a další (erp)), ale finální výstupy ovlivňují pak i vztahy k těmto subjektům.

Aplikační architektura obohacená o BI pak neobsahuje pouze jedinou oblast, kde se BI nachází (nade všemi systémy pro výrobu, řízení zdrojů, ekonomiky, obchodu, vztahů s dodavateli či se zákazníky), části BI jsou propojeny do většiny oblastí ostatních PIS, které ovlivňují. Například výstupy ohledně zákazníků ovlivňují CRM, ohledně dodavatelů SCM atp. Následující obrázek toto dobře znázorňuje:

Page 2

Základní kroky postupu vytváření řešení BI Souvisí s předpoklady. Aby bylo možné nějaké BI řešení vytvořit, bude třeba vědět, zdali byznys ví, co se dá od BI očekávat a jaké jsou jeho přínosy. Také by si měl být vědom toho, že levné to rozhodně nebude a rychlost zavedení kompletního BI (pokud odmyslíme takové věcí jako urychlení přes nezávislé datamarty, které sice budou dříve, ale konsolidované informace z nich člověk nedostane) bude pomalá, odhaduje se, že implementace může trvat i rok (samozřejmě záleží na velikosti celého řešení, jiné to bude v SME a jiné v bance).

Obecné kroky zavedení BI Je třeba zodpovědět několik základních otázek, které jsou obsahem studie proveditelnosti: -

Které oblasti bude BI pokrývat a jak? o

-

Kdo z byznysu bude sponzorem projektu? Kdo vlastníkem jednotlivých částí, kdo gestorem a kdo propagátorem? o

-

Aby mělo zavedení BI smysl, tak se musí upravit i byznys procesy a musí se komunikovat s šéfy jednotlivých oblastí s tím, že se i projekt musí umět vysvětlit (od toho propagátor). Jednotlivé části nemohou být bez dozoru (gestoři.). A samozřejmě někdo musí ten projekt zaplatit - sponzor.

Jaká bude koncepce architektury řešení, jaké technologické komponenty budou potřeba? o

-

Z technického pohledu bude u tohoto nejdůležitější multidimenzionální analýza - tabulka s fakty (např. tržby) a dimenzemi (např. čas,distribuční kanál, pobočka, segment..). Naprosto nutná komunikace s byznysem.

Je třeba je vybírat s ohledem na potřeby firmy, aby poměr cena/výkon byl nejlepší

Jak bude rozložen věcný obsah do jednotlivých etap projektu? Jaký bude časový plán? Hrubý rozpočet? Jaký režim realizace bude zvolen? Vývoj, dodavatelsky, outsourcing? Kombinace? Jaká jsou rizika a s tím související kritické faktory?

Pokud je tento dokument a celý projekt schválen, následují následující fáze:

Page 3

-

Byznys zdůvodnění o

-

Plánování o

-

o o

Tým vývojářů spolu s analytiky integrují prvky dle zadání z detailní analýzy (tj. databáze, komponenty etl procesu, aplikace..). Součástí implementační fáze jsou i interní testy.

Testování a nasazení do provozu o o o o

-

Podrobné rozpracování koncepčního návrhu a všech jeho složek. Výsledky musí být schváleny za účasti byznys gestorů jednotlivých oblastí BI. Prověřuje se, zdali analýza splňuje výchozí byznys požadavky.

Implementace o

-

Zaměřuje se na identifikaci a analýzu požadavků, které mají pomoci realizovat BI řešení - změny v organizaci, kultuře, procesech a systémech. Součástí je zmapování stávajících procesů a systémů a nalezení odchylek - co bude potřeba vylepšit. Součástí je i konceptuální model obsahu (tj. datový model) a funkcí (procesní model) včetně hrubého návrhu reportů, zařazení BI do celkové IS/ICT architektury daného podniku Tato fáze probíhá s úzkou spoluprácí se zástupci byznysu. Po skončení tohoto kroku se upřesní plán.

Detailní analýza o

-

Specifikace rozsahu projektu a určení metod, stanovení úkolů a jejich trvání, milníky, WBS (work-breakdownstructure - dobře vidět v microsoft project, kde jsou definovány návaznosti mezi jednotlivými úkoly, což umožňuje zobrazit kritickou cestu, což je nejkratší cesta ukončení projektu), k úkolům přiřazení zdrojů a jejich ocenění pak umožní alespoň předběžný rozpočet

Konceptuální (byznys) analýza o

-

Jde o to vytvořit business case, jehož předmětem je návrh na požadovanou změnu

Všechny vyvinuté komponenty se testují, provádí se uživatelské akceptační testy Školení uživatelů, odstraňování nedostatků Nasazení do produkčního prostředí (odtud se reportuje), první naplnění. Realizace změn vyvolaných nasazením BI (ty samé věci jako v konceptuální analýze, tj. změna procesů, kultury..). Ještě jednou upozornění na to, že obzvláště proces řízení kvality dat je extrémně podstatný.

Údržba

Kritické faktory projektu -

Organizační zajištění o

-

Řízení rozsahu o

-

BI nebude lékem na všechno. Nenahradí nedostatečnou funkcionalitu provozních systémů či nesprávně fungující procesy. Nemělo by se očekávat, že když je něco ve zdrojovém systému špatně, tak ve výstupu BI to bude správně (toto se děje velmi často).

Integrace BI řešení o

-

Příliš velký věcný rozsah řešený najednou, nereflektování dohodnutých priorit při tvorbě řešení, rozšiřování rozsahu v průběhu realizace

Řízení očekávání o

-

Účast klíčových byznys lidí, byznys gestorů za jednotlivé oblasti, zajištění dalších projektových rolí je stěžení. BI tu je od toho, aby byznys podporovalo, pokud nebudou byznys zástupci přítomni v rámci plánování, analýz a testování, tak hotové řešení a podpora procesů pravděpodobně nebudou mít požadovaný efekt

Neochota modifikovat stávající byznys procesy a pracovní postupy za předpokladu, že to implementace BI vyžaduje.

Zdroje o

Technologické, lidské i finanční

Page 4

3.6 Elektronické podnikání – jeho formy, standardy a možnosti

3.06 Elektronické podnikání – jeho formy, standardy a možnosti Vývoj v EDI, standardy EDI, projekční postupy, vliv možností elektronického obchodu na řízení firmy, kritické faktory úspěšnosti projektů EDI a elektronického obchodu.

1.1.

Definice a vývoj EDI EDI je způsob výměny strukturovaných dat na základě dohodnutých standardů mezi jednotlivými subjekty a to elektronickou cestou. • • • • • •

1.2.

původ EDI v 60. letech v USA největší rozšíření v USA a Velké Británii V USA se standardizací zabývá ANSI – standard ANSI X.12. Dalším subjektem byla UN/TDI. Společně se podílely na vzniku UN EDIFACT (ISO 9735). je definováno více než 180 standardizovaných typů dokumentů každý dokument má ID tvořené 3 číslicemi standard pro použití EDI přes Internet - EDINTVývoj EDI

Standardy v EDI 1. „obálkou“ celé komunikace je výměna (Interchange) 2. výměna obsahuje funkční skupiny (Functional Group), FS obsahuje zprávy stejného typu 3. funkční skupina je tvořena zprávami (Message, Transaction), zpráva je druh EDI komunikace pro zajištění určité obchodní funkce 4. zpráva je rozdělena na segmenty, které představují logické seskupení datových prvků 5. datové prvky (Element) jsou jednotlivé údaje obsažené v dokumentu dále jsou definována syntaktická pravidla a pravidla pro návrh zpráv (pro tvoření nových nebo modifikaci stávajících zpráv).

1.2.1.

Členění standardů v EDI 1. Podle syntaxe zpráv •

struktura zprávy a možnost seskupování zpráv

•

možnost reprezentace vybraných komponent zprávy

•

přípustná sada znaků ve zprávě

2. reprezentace prvních dvou úrovní •

fixní nebo variabilní délka

•

umístění a identifikace komponenty založené na pozici nebo na identifikátoru

•

opakovatelnost komponenty ve zprávě

3. z hlediska regionů •

národní, např. TRADACOMS ve Velké Británii - 1/4 -


•

regionální, např. ICOM pro Belgii a Lucembursko

•

kontinentální, např. ODETTE pro Evropu

•

světové, např. EDIFACT

4. podle odvětví

1.3.

•

firemní, např. COPS pro Philips

•

firemní s rozšířením na další partnery, např. SADBEL v Belgii a Lucembursku

•

odvětvové, např. ODETTE, HL7 ve zdravotnictví

•

meziodvětvové, např. TRADACOMS, EDIFACT

Projekční postup 1. Zhodnocení současného stavu • Jak může EDI ovlivnit chod podniku? • Jaké možnosti může přinést? • Jaký bude mít dopad na obchodní vztahy? • kdo a jak již EDI využívá? • Jaký je stav IT pro EDI? • Jaká je úroveň standardizace? 2. Specifikace hlavních požadavků na EDI • Zhodnocení možností EDI ve všech obchodních aktivitách podniku • analýza trhu a možností EDI • specifikace cílů EDI • zhodnocení nákladů a přínosů EDI • specifikace základní strategie v řešení EDI 3. Výběr pilotního projektu - Pro výběr pilotní aplikace jsou rozhodující • předpokládané přínosy • priority nebo tlak obchodních partnerů • jednoduchost implementace 4. Výběr obchodních partnerů • význam partnera, charakter obchodních vztahů • předpokládané přínosy z EDI s daným partnerem • dostupné zdroje partnera pro realizaci EDI 5. Analýza disponibilních IT pro EDI - zahrnuje možnosti dostupných SW produktů pro EDI, technických prostředků, vlastního ASW. 6. Výběr standardů pro EDI 7. Řešení pilotní aplikace EDI • vytvoření projekčního týmu • vytvoření a schválení dohod s vybranými obchodními partnery - 2/4 -


• analýza a návrh řešení • implementace • řešení legislativních a bezpečnostních otázek • vytvoření provozních pravidel 8. Implementace a zavedení EDI

1.4.

Vliv na řízení firmy • Automatizace procesů • Rychlá dostupnost reportů • Možnost snazšího nasazení BI

1.5.

Faktory úspěšnosti 1. na úrovni státu • představa vlády o významu EDI (legislativa!!!) • technická a technologická infrastruktura • proniknutí IT do ekonomiky • rozvoj EDI vzhledem k ostatním státům 2. na úrovni sektoru • stupeň rozvoje IT • plánování rozvoje EDI v sektoru, koordinace aktivit různých subjektů • stupeň kvalifikace pracovníků v sektoru v IT i v oblasti řízení • úroveň standardizace v sektoru • úroveň koordinace a kooperace v mezinárodním měřítku 3. na úrovni podniku • strategie podniku, úloha IT • pochopení přínosů a možností EDI • úroveň IS/IT v podniku • podpora nejvyššího vedení • ochota k organizačním změnám • personální úroveň

- 3/4 -


úloha - předpoklady: Jste specialistou útvaru informatiky firmy působící v oblasti automobilového průmyslu. Vaším úkolem je analyzovat možnosti rozvoje EDI ve Vaší firmě. Zadání:

Co budete na počátku zjišťovat a analyzovat ?

Jaké efekty budete v souvislosti s EDI sledovat a jak je budete presentovat vedení firmy ?

Jaké nároky a omezení budete v souvislosti s řešením sledovat a vyhodnocovat ?

Analýza Viz prvních 6 bodů 1.3 Projekční postup 1. Zhodnocení současného stavu 2. Specifikace požadavků 3. Výběr projektu 4. Výběr partnerů 5. Analýza IT zdrojů a jejich výběr 6. Výběr standardů

Metriky hodnocení •

Rychlost vyřízení procesu

•

Náklady na vyřízení procesu

•

Počet vyřízených procesů za časový úsek

•

Úspory na papírové korespondenci (hlavně pro PR jako ekologičnost)

•

Míra automatizace

Nároky a omezení •

Množina (potencionálních) obchodních partnerů, kteří se mohou do EDI zapojit

•

Nákladovost pořízení, provozu a údržby EDI SW (i personální náklady na zaškolení atd.)

- 4/4 -

3.07 Možnosti řešení outsourcingu

3.07 Možnosti řešení outsourcingu Formy a oblasti realizace outsourcingu. Principy smluv na outsourcing. Proces outsourcingu IS/IT.

1.1.

Formy a oblasti outsourcingu

1.1.1.

Základní varianty outsourcingu

Outsourcing podnikového procesu (BPO – Business Process Outsourcing)

na externího partnera je převáděn celý podpůrný podnikový proces včetně podnikových zdrojů, které jsou pro provoz procesu zapotřebí (např. outsourcing účetnictví, stravování, dopravy, vymáhání pohledávek),

v zodpovědnosti podniku podnikovými procesy,

SLA popisuje výstupy vytěsněného podpůrného procesu a součinnost, kterou musí podnik zajistit.

zůstává

integrace

vytěsněného

procesu

s hlavními

Outsourcing komplexního IS/ICT (Complex IS/ICT Outsourcing)

na externího poskytovatele se přesouvá zodpovědnost za dodání veškerých ICT služeb a současně zodpovědnost za ICT procesy a zdroje, které s ICT službami souvisejí (viz SPSPR),

na podniku zůstává zodpovědnost za podnikové procesy, ale např. ICT služby podporující účetnictví jsou vytěsněny,

výhody: podnik se nezabývá problémy spojenými s vývojem a provozem IS/ICT

SLA orientováno na popis dodávaných informačních a aplikačních služeb,

- 1/5 -


Částečný IS/ICT outsourcing (Partial IS/ICT Outsourcing)

tři varianty: outsourcing ICT služby (aplikační služby na podporu účetnictví, CRM, mailu), ICT procesu (např. vývoj aplikací, integrace) a ICT zdroje (datové centrum, koncové stanice, servery, specialisté),

SLA: i. ICT služba: popis informačních a aplikačních služeb, ii. ICT proces: popis vytěsněného procesu, vstupy, výstupy, iii. ICT zdroj: popisuje zdroj, jeho kapacitní a další charakteristiky.

1.1.2.

umožňuje detailní plánování sourcingu IS/ICT

Varianty outsourcingu dle vlastnictví zdrojů

interní vlastnictví a interní provoz,

interní vlastnictví a externí provoz,

interní provoz a externí vlastnictví (leasing),

joint venture (společně vlastněný subjekt, kterému jsou předány procesy a zdroje), - 2/5 -


1.1.3.

1.2.

1.2.1.

jeden strategický poskytovatel,

více poskytovatelů (multisourcing).

Varianty outsourcingu dle umístění zdrojů

centralizovaná varianta – nákladově výhodnější, ale např. delší doba odezvy, nižší flexibilita,

distribuovaná varianta.

Principy smluv na outsourcing

outsourcingová smlouva musí ošetřit 4 období: období přípravy, transformace stávajícího stavu na poskytovatele, období poskytování služeb poskytovatelem, ukončení poskytování služeb a převod zpět na podnik nebo jinému poskytovateli

outsourcingová smlouva zahrnuje 3 složky: práci, prostředky (technologie), lidé

Smluvní úpravy pro období přípravy outsourcingu

1.2.2.

Ošetření podílu příjemce na nákladech přípravy outsourcingu poskytovatele o

každá strana nese své náklady

o

pokud nedojde k outsourcingu IT, příjemce uhradí určitou část nákladů

o

pokud dojde k outsourcingu, náklady poskytovatele na přípravné období budou umořeny v outsourcingových poplatcích

zajištění návaznosti nabídky a ÚS dodavatelů, přenesení parametrů z nabídky do smlouvy o

u jednoduchých případů může být nabídka požadována přímo v podobě návrhu smlouvy (návaznost je pak zřejmá).

o

u složitých a komplexních případů společně připravovat outsourcingový projekt.

o

v ostatních případech ošetřit

zajištění mlčenlivosti

regulace pohybu poskytovatele v prostorách příjemce a naopak (v mimořádných případech)

Smluvní úpravy pro období poskytování služeb outsourcingu

Smlouvy pro oblast outsourcingu IS/IT: Smlouva o dílo: spíše pro fázi přípravy outsourcingu (dílo je činnost časově přesně ukončená, zatímco outsourcingové služby jsou neustále probíhající a opakující se) Smlouva nájemní: problém - podle platného právního řádu není možný nájem ničeho jiného než věci, a SW věcí není. Smlouva mandátní: v případě, kdy má objednatel zájem pouze o zařízení některých úkonů dodavatelem vůči třetím stranám - dodavatel funguje jako prostředník. Smlouva nepojmenovaná: zpravidla nejvhodnější, může v sobě nést řadu prvků výše uvedených typů smluv (smlouva smíšená), záleží jen na smluvních stranách, jaká ustanovení bude obsahovat

1.2.3.

Obsah smlouvy

1.3.

formální obsah smlouvy obecně, smluvní strany, definice pojmů, předmět smlouvy, termín plnění, cena, oprávněné osoby a forma komunikace, ochrana informací, náhrada škody, řešení sporů, garantovaná úroveň služeb – SLA, změnové řízení, řešení problémů, pronájem prostor atd.

Proces outsourcingu Outsourcing jako proces se realizuje proces do 11 kroků.

prostřednictvím projektu. Podle metodiky MMDIS dělíme

1. Strategická analýza funkčních oblastí

součástí globální podnikové strategie, - 3/5 -


jejím úkolem je jasná definice hlavního předmětu činnosti podniku (core business) a k němu potřebných podpůrných činností,

výstupem je definování hlavních a podpůrných podnikových procesů,

nadřazeno dílčím podnikovým strategiím.

2. Určení funkčních oblastí, které budou vytěsněny

činnosti strategicky kompetitivně nedůležité lze vytěsnit, i když jde o oblasti pro podnik kritické (např. zpracování účetnictví),

nemělo by být odsouváno nic, co není přesně definováno,

hodnocení funkční oblasti z hlediska vytěsnění je rozhodováním za rizika/nejistoty,

je nutné zkoumat zda vytěsnit celou oblast, nebo pouze její část, a zda vše požadovat po jednom poskytovateli (analýza potenciálních poskytovatelů)

3. Detailní analýza předmětné oblasti

kontrola definice ICT služeb, procesů a zdrojů vytěsňované oblasti,

překontrolování zdrojů k outsourcingu – využití, škálovatelnost,

zjištění, zda nejsou vytěsňované zdroje používány i v nevytěsňovaných procesech,

upřesnění očekávaných přínosů,

detailní analýzou se určí oblasti, u kterých bude preferována externí varianta.

4. Definice požadovaných služeb

definice požadovaných služeb + návaznost těchto služeb na podnikové procesy

vztahy musí být v přesných termínech, úplně popsané,

definice zahrnuje také objemové a kvalitativní charakteristiky služeb, cenové limity atd., prostě vše co má SLA obsahovat.

5. Definice požadavků na poskytovatele

velikost (obrat, počet pracovníků), finanční síla (pojištění), kvalifikační požadavky, vlastnictví zdrojů, převzetí za úplatu nepotřebných zdrojů podniku apod.

6. Výběr sourcingové varianty a poskytovatele

sladění požadavků podniku s nabídkou trhu poskytovatelů. Výběr patrně proběhne výběrovým řízením (viz. otázka 3.11).

7. Due Dilligence

z amerického práva – jedná se o analýzu předmětné oblasti podniku s cílem zobrazit silná a slabá místa a rizika spojená s outsourcingem,

budoucí outsourcer provádí audit oblasti, která je předmětem outsourcingu, prověřuje správnost podkladů na jejichž základě podal nabídku.

8. Podepsání outsourcingové smlouvy

poslední přípravná fáze,

řeší se otázka jak naložit s nepotřebnými aktivy – nejčastěji jsou prodány outsourcerovy,

vlastní smlouva se pak může skládat z řady dílčích smluv (rámcová smouva, kupní smlouva, smlouva o pronájmu či odkoupení nebytových prostor, smlouva o poskytování služeb – SLA, atd.),

další informace o SLA viz otázka 1.19

9. Transformace funkční oblasti

přesun vytěsňovaných oblastí z podniku na poskytovatele,

přechodový proces je kritický především z hlediska lidských zdrojů, - 4/5 -


tato fáze musí proběhnout velmi rychle (téměř okamžitě).

10. Provozování outsourcingu – řízení vztahu

je nutné neustále sledovat a hodnotit stav vztahu a na základě toho vytvářet měřitelná kritéria

nová specializace outsourcing contract manager, kterou by v podniku zastával tzv. CRO, Chief Resource Officer (The Outsourcing Institut),

řízení vzájmeného vztahu a řešení sporů – relationship management.

11. Ukončení/převod outsourcingu

podmínky, za kterých je možné outsourcing ukončit, jsou uvedeny ve smlouvě.

Úloha - předpoklady: Z velkého českého podniku se vydělil celý informatický útvar do samostatného právního subjektu. Tento nový subjekt poskytuje komplexní služby svému mateřskému podniku. Jste v roli asistenta vedení mateřského podniku. Zadání:

Co bude obsahem smlouvy o outsourcingu? Jaké příležitosti a jaká rizika pro vás vyplývají z tohoto vztahu? Jak budete postupovat, abyste minimalizoval(a) rizika?

Viz část Outsourcing komplexního IS/ICT – součástí smlouvy tedy bude precizní popis dodávaných (požadovaných) informačních a aplikačních služeb. Příležitosti jsou dány obecnými přínosy outsourcingu (hlavně soustředění se na hlavní činnost podniku, zvýšení pružnosti zdrojů, organizační důvody, zeštíhlení atd.), rizika jsou také poměrně obecná – nezvládnutí nového způsobu řízení vytěsněné oblasti, nízká flexibilita vztahu. Zde je specifikum to, že mateřská společnost bude od dcery odebírat služby IS/ICT, takže otázka nákladů nebude na prvním místě, ale spíše se bude smluvní vztah zaměřovat na kvalitu, dostupnost, škálovatelnost služeb. Řada rizik byla minimalizována již vydělením interního útvaru do nové dcery – riziko úniku citlivých informací se značně snížilo, nenastane konflikt různých prostředí, poskytovatel má větší představu o tom co podnik potřebuje. Problémy ale mohou nově nastat v případě nesledování nákladů (minimalizujeme kontrolou nákladové stránky poskytování a jasným definováním SLA). Dalším problémem může být právě samotné SLA – nemusí být vytvářeno s takovou opatrností a obezřetností jako v případě externího poskytovatele, který nemá na podnik žádné vazby. Vedení musí zajistit, aby SLA bylo vytvořeno důkladně a aby bylo vše podchyceno tak, jak je výše popsáno.

- 5/5 -

3. 8 ŘÍZENÍ EKONOMIKY IS/ICT - NÁKLADŮ, EFEKTŮ Podstata ekonomických analýz tvorby a užití IS/ICT. Ekonomická analýza z hlediska dodavatele, provozovatele a uživatele IS/ICT. Analýzy efektů IS/ICT. Plánování IS/ICT z pohledu jejich ekonomiky. Materiály: prof. Molnár, http://gis.vsb.cz/GIS_Ostrava/GIS_Ova_2000/Sbornik/Molnar/Referat.htm

1.1.1 Podstata ekonomických analýz tvorby a užití IS/ICT •

Efektivnost IS/IT je dána jeho přínosy a výdaji na něj vynaloženými.

•

Na efektivnost lze pohlížet jako na maximalizaci užitku při daném objemu finančních prostředků nebo je známa potřeba určité aplikace IS/IT a hledá se co nejlevnější řešení.

•

do konce 70.let se od IS/IT očekávala především přímá úspora pracovních sil (tzv. nahrazovací aplikace)

•

v 80.letech se vedle toho očekával růst produktivity, flexibility a kvality výrobků a služeb (tzv. doplňkové aplikace)

•

v 90.letech se od IS/IT čeká zásadní vliv na klíčové procesy podnikání a jejich změnu a vytvoření nových podnikatelských příležitostí (tzv. inovační aplikace)

1.1.2 Ekonomická analýza z hlediska dodavatele, provozovatele a uživatele IS/ICT o majitelé, kterým by měla IS/IT přinášet trvalé zhodnocování jejich majetku vloženého do podniku, o manažeři, kterým by měla IS/IT dávat možnost úspěšně řídit podnik tak, aby bylo dosahováno žádoucích výsledků s minimem potřeby zdrojů jim svěřených do správy, o zaměstnanci, kterým by IS/IT měla nabídnout lepší pracovní prostředí, vyšší společenský status a větší pocit sounáležitosti s podnikem, o v konečném důsledku pak zákazník, který by toto všechno měl pocítit tím, že bude dostávat produkt či službu s vyšší přidanou hodnotou za přijatelnou cenu.

1.1.2.1 Klasifikace ukazatelů přínosů IS/IT •

finanční (měřené v peněžních jednotkách) a nefinanční (v jiných fyzikálních jednotkách)

•

kvantitativní (měřitelné kardinální stupnicí) a kvalitativní (ordinální stupnicí)

•

přímé (lze prokázat jednoznačný příčinný vztah) a nepřímé (musí se stanovit nějaké zástupné ukazatele)

•

krátkodobé (projevující se obvykle do ½ roku po implementaci IS/IT) a dlouhodobé (projevují se později, někdy až za více let)

•

absolutní (vyjádřené měřitelnou hodnotou) a relativní (bezrozměrné číslo)

Finanční ukazatele •

návratnost kapitálu (ROA – Return of Assets) Roční zisk po zdanění + úroky ROA = −−−−−−−−−−−−−−−−−−−−−−−−− x 100 Celkový kapitál

•

návratnost investic (ROI – Return of Investments) ROI [%] = výnosy / investice * 100

•

doba obratu

PSOM TOB = −−−−−−−−−−−−−− x 360 Q Kde PSOM značí průměrný stav oběžného majetku za rok z rozvahy Q značí roční výkony z výsledovky 360 dní tj. 30 dnů za měsíc resp. 90 dní za čtvrtletí

Měřitelné nefinanční ukazatele Z dalších měřitelných ukazatelů přínosů IS/IT, jejichž hodnotu jsme schopni měřit nějako fyzikální veličinou, a které jsou většinou po zevrubnější analýze vyjádřitelné finančně, se nabízí celá řada podle charakteru organizace a typu aplikace IS/IT. Mohou to být např. tyto ukazatele: •

zkrácení průběžné doby vývoje a výroby,

•

snížení počtu reklamací,

•

zvýšení počtu zákazníků,

•

zvýšení podílu na trhu,

•

snížení doby prostoje výrobního zařízení,

•

zkrácení doby obsluhy zákazníka,

•

rozšíření výrobního sortimentu, atd.

“Měkké” ukazatele přínosů IS/IT K měkkým ukazatelům patří zejména různé “kvalitativní” ukazatele jako např. •

zlepšení dobrého jména podniku (dá se hodnotit různými průzkumy),

•

spokojenost zákazníků (dá se hodnotit projevuje růstem počtu zákazníků),

•

zvýšení zákaznické věrnosti (dá se hodnotit počtem opakovaných objednávek od stávajících zákazníků),

•

flexibilita podniku, kreativita v přijímání nových produktů, služeb, procesů nebo struktur (dá se hodnotit např. počtem zákaznických modifikací),

•

reakce na nové potřeby trhu (dá se hodnotit dobou potřebnou k uvedení nového výrobku na trh)

•

zlepšení pracovního prostředí (dá se hodnotit různými anketami a dlouhodobě vede ke stabilizaci pracovníků resp. k růstu zájmu o práci)

•

zvýšení kvalifikace pracovníků podniku (dá se hodnotit různými anketami resp. celou řadou systémů hodnocení kvalifikace užívaných v personalistice)

•

přidání hodnoty produktu či službě (dá se hodnotit ochotou zákazníků zaplatit za výrobek více, zvýšením počtu zákazníků případně obojím současně)

různými průzkumy a dlouhodobě se

1.1.2.2 Základní kritéria hodnocení investic do IS/IT •

manažerská kritéria

•

technicko-organizační kritéria

•

finanční kritéria

Manažerská kritéria •

podporuje IS/IT strategické záměry?

•

je IS/IT v souladu s informační strategií?

•

je IS/IT významný pro zajištění konkurenční výhody?

•

splňuje IS/IT požadavky norem kvality?

•

splňuje IS/IT legislativní požadavky?

Finanční kritéria Metody pro hodnocení lze rozdělit např. podle toho, co berou v úvahu jako kritérium efektu investice: •

metody, v nichž jako kritérium hodnocení vystupuje úspora nákladů

•

metody, v nichž jako kritérium hodnocení vystupuje vykazovaný zisk

•

metody zaměřující se na peněžní tok z investice

ad 1) metoda průměrných ročních nákladů, metoda diskontovaných nákladů ad 2) průměrná výnosnost, doba návratnosti ad 3) ČSH, VVP

1.1.3 Plánování IS/ICT z pohledu jejich ekonomiky •

Především vždy musíme mít jasno v účelu proč si IS/IT pořizujeme. Tento účel jasně a zřetelně vyslovit formou definice cílů, které mají být pomocí IS/IT dosaženy.

•

Ke každému cíli určit hodnotící hlediska (metriky), pomocí kterých bude možno určit, zda jsme cíle dosáhli, nebo aspoň se k němu přiblížili a počítat s tím, že k některým cílům se budeme přibližovat dlouho.

•

Již v etapě plánování IS/IT definovat systém hodnocení dosahování cílů a to jak v rovině časové (Kdy?, Jak často?), tak i v rovině personální (Kdo je zodpovědný za plnění těchto cílů?)

•

Uvažovat celé portfolio přínosů (přímé i nepřímé, měřitelné i neměřitelné, krátkodobé i dlouhodobé)

•

Mít jasno v nákladech na IS/IT. Zavést controllingový systém hodnocení těchto nákladů z hlediska druhového (tj. uvažovat všechny druhy zdrojů IS/IT) i aplikačního (tj. sledovat náklady jednotlivé projekty IS/IT).

•

Pořizovat si jenom kvalitní IS/IT, protože nekvalitní IS/IT nemůže být nikdy efektivní.

•

Celou oblast informatiky v organizaci odpovídajícím způsobem organizačně zabezpečit, zejména optimálním vyvážením vnitřních i vnějších zdrojů.

•

Vytvořit účinný motivační systém pro všechny pracovníky, který by je motivoval nejen k tomu aby užívali při své práci IS/IT, ale aby jí užívali efektivně, tj. aby sami vnímali náklady s tím spojené a aby sami hledali a hodnotili přínosy tím vznikající.

•

Všechny tyto zásady a rozhodnutí neustále komunikovat nejen uvnitř podniku, ale i ke svým zákazníkům, aby nás viděli jako moderně řízenou organizaci, která má jasnou perspektivu trvalého rozvoje.

•

Neustále sledovat trendy IS/IT a to jak v obecném pohledu, tak zejména z pohledu vývoje IS/IT u konkurence. Úloha - předpoklady: Vyberte si podnik z libovolného sektoru ekonomiky a jeho libovolný informatický projekt. Zdroj: http://www.systemonline.cz/clanky/data-mining-v-praxi.htm Projekt data mining - predikce odchodu zákazníků ke konkurenci (churn) v telekomunikační společnosti. Zadání:

Určete plánované ekonomické přínosy tohoto projektu

V konkrétním případě analýzy a predikce odchodu zákazníků u telekomunikační společnosti se potvrzují odhady uváděné v zahraničních pramenech, které hovoří o reálné možnosti snížit objem ztráty tržeb od odcházejících zákazníků o více než 10%.

Jakými metrikami budete měřit dosažení těchto přínosů ?

Na základě tohoto bylo a je možné relativně přesně zjišťovat ROI data mining projektu analýzy a predikce odchodu zákazníků.

3.9

ŘÍZENÍ LIDSKÝCH ZDROJŮ V IS/ICT

Profesní zajištění IS/ICT, – plánování, formování týmů, kvalifikační programy (profese a požadované kvalifikace ve fázích tvorby a provozu IS). Vývojové trendy.

1.1.1 Profesní zajištění IS/ICT, – plánování, formování týmů Viz ot. 15 (AI)

1.1.2 Kvalifikační programy (profese a požadované kvalifikace ve fázích tvorby a provozu IS) Zdroj: Konkurenceschopnost absolventů IT oborů VŠ a VOŠ na trhu práce v ČR (Voříšek, Novotný, Doucek)

Znalosti a dovednosti, kterými musejí disponovat všechny informatické role: •

vysoký stupeň kreativity při řešení úloh,

•

dobrá znalost angličtiny (písmem i slovem),

•

schopnost práce v týmu,

•

komunikační schopnosti.

Byznys analytik- architekt

Manažer rozvoje a provozu IS/IT

Obchodník s ICT produkty a službami

Vývojář IS architekt

Správce aplikací a ICT infrastruktury

Obchodník s ICT produkty a službami

1.1.3 Vývojové trendy Zdroj: prof. Voříšek - Trendy IS/ICT a jejich dopady na strukturu ICT trhu, dodavatelské a uživatelské organizace - http://www.cssi.cz/cssi/system/files/all/SI_05_1_vorisek.pdf •

konsolidace trhu – menší firmy pohlcovány velkými, na trh práce se dostává řada zkušených informatiků,

•

propojování dříve samostatných odvětví – IT + business (telco, retail, banking, insurance, public),

•

off-shore outsourcing – přesouvání výroby ICT produktů a služeb do Indie, Číny, atd.

•

současná ekonomická situace – propouštění.

Úloha - předpoklady: Vyberte si podnik z libovolného sektoru ekonomiky. Stručně popište stav IS/ICT podniku. Nábytkářská společnost – výroba nábytku, 100 zaměstnanců, 1 výrobní hala + kanceláře. IT – 10x notebook, 30 x desktop (MS Windows, MS Office), 1x aplikační server s OS Windows 2008 Server, IS MS Navision + DB MS SQL Server 2008. Zadání:

Navrhněte vhodnou organizační strukturu informatického útvaru

Org. struktura: IT manager

IT specialista – SW

IT specialista – HW

Pracovník helpdesk

Popište klíčová funkční místa tohoto útvaru, jejich potřebnou kvalifikaci, zodpovědnosti a pravomoci

IT specialista - SW Požadavky: • nejméně SŠ vzdělání technického zaměření • znalost MS SQL, MS NAVISION • schopnost psát reporty a dataporty v prostředí MS NAVISION • znalost programování • vysoká znalost MS Office, především Excel, Word, Power Point • znalost angličtiny (základní) • analytické myšlení, pečlivost, samostatnost, komunikační a organizační schopnosti • chuť zvládat nové činnosti a postupy Pracovní náplň: • aktivní účast na implementaci MS Navision • vytváření reportů a dataportů v prostředí Object Designeru Microsoft Navision • podpora uživatelů včetně školení • správa aplikací • testování nových aplikací • správa webových stránek

3.10 Legislativa a IS Zákony a ostatní právní předpisy vztahující se k problematice tvorby a užití IS (obchodní zákoník, autorský zákon, zákon na ochranu osobních údajů, daňové zákony apod.) Vlivy právní úpravy na návrh, lokalizaci a provoz IS.

1. Zákony a ostatní právní předpisy vztahující se k problematice tvorby a užití IS (obchodní zákoník, autorský zákon, zákon na ochranu osobních údajů, daňové zákony apod.) 1.1. Klasické právní normy (upravují závazkové právní vztahy, lze je aplikovat v případě protiprávního jednání. ) • občanský zákoník • obchodní zákoník (smlouvy mandátní, o dílo, nájemní, kupní, nepojmenovaná – inominátní) 1.2. Dojde-li ke spáchání deliktu, lze postihnout protiprávní jednání podle zákonů: • trestní zákon • přestupkový zákon 1.3. další, zvláštní zákony upravující některé speciální otázky, týkající se IT. • • • • •

autorský zákon zákon o ochraně osobních údajů, telekomunikační zákon zákon o elektronickém podpisu zákon o některých službách informační společnosti (tzv. antispamový zákon). 1.4. oborové zákony potřebné vzít v úvahu:

• • • •

zákon o účetnictví (archivace úč. výkazů až 10let, vedeny v češtině, dohledání zodpovědné osoby) zákon o informačních systémech veřejné správy SOX (transparentnost fin. výkazů pro firmy, jejichž akcie jsou obchodované na burze) BASEL II (řízení rizik, kapitálová přiměřenost, pro finanční instituce) 1.4.1. Zákon o elektronickém podpisu

Vychází z principu existence tzv. certifikační autority, která ověřuje vztah mezi podepsanou zprávou a oprávněnou osobou. Vše je založeno na existenci veřejného a soukromého klíče, které jsou vygenerovány majitelem podpisu. Majitel podpisu podepisuje zprávu svým soukromým klíčem. Kdokoli, kdo má k dispozici majitelův veřejný klíč si pak může ověřit, zda zpráva skutečně přišla od majitele podpisu a zda během přenosu nedošlo k narušení integrity. Zavedl časovéh razítko a elektronickou značku

1.4.2. Zákon o ochraně osobních údajů Definovány práva a povinnosti při zpracování údajů o fyzických osobách a stanoveny podmínky zpracování. Kontrolu dodržování tohoto zákona provozuje Úřad pro ochranu osobních údajů. zpracování osobních údajů, které provádí fyzická osoba výlučně pro osobní potřebu a na nahodilé shromažďování osobních údajů, pokud tyto údaje nejsou dále zpracovávány. Správce a zpracovatel je povinen stanovit účel, k němuž mají být osobní údaje využity, stanovit prostředky a způsob zpracování osobních údajů, shromažďovat osobní údaje odpovídající pouze stanovenému účelu a v rozsahu nezbytném pro naplnění stanového účelu, uchovávat osobní údaje pouze po dobu, která je nezbytná k účelu jejich zpracování a nesdružovat osobní údaje, které byly získány k rozdílným účelům. Při porušení tohoto zákona se mohou uložené sankce vyšplhat do výše 10 – 20mil. Kč.

1.4.3. Zákon o svobodném přístupu k informacím Podmínky práva svobodného přístupu k informacím a stanoví základní podmínky, za nichž jsou informace poskytovány. Povinnými subjekty jsou státní orgány a orgány územní samosprávy.

Při účasti ve výběrovém řízení, které jsou vypsány státními orgány a orgány územní samosprávy, je možné na základě tohoto zákona získat informace o vítězi soutěže a jeho podané nabídce. Při zjištění nesrovnalostí lze na základě těchto informací docílit až zrušení výběrového řízení a vypsání nového.

1.4.4. Zákon o IS veřejné správy

Stanoví práva a povinnosti, které souvisejí s vytvářením, užíváním, provozem a rozvojem informačních systémů veřejné správy. 1.4.5. Smlouvy

Nejčastěji smlouvy o outsourcingu, nákupu nebo SI Systémová integrace • smlouva o dílo – rámcová, vymezuje ostatní, • kupní smlouva pokud je součástí nákup SW aHW • smlouva o poskytování služeb– údržba a podpora IS po zavedení • zbytek nepojmenované (inominátní smlouvy) - např. smlouva o školící činnosti Outsourcing • • •

nájemní smlouva použitelná pouze pro HW, nic nehmotného si totiž nelze najímat smlouva o dílo maximálně na fázi příprav smlouva mandátní – objednatel má zájem o zařízení některých úkonů dodavatelem vůči třetím stranám (dodavatel funguje pouze jako prostředník) • vše ostatní – smlouvy nepojmenované Časté vady smluv • • • •

vytváří je mnoho osob na obou stranách (zhotovitel i objednatel) – nekonzistentní terminologie tvorba často na základě templatů z minula -- každý projekt unikátní, možnost opomenout mnoho věcí špatná spolupráce mezi IT a právníky (právníci nemají o obsahu dodávky ani šajn) u inominátních smluv - větší náročnost na obsah (není stanoven zákonem) – co není ošetřeno ve smlouvě, není ošetřeno nijak jinak

• dobrou pomůckou při tvorbě je checklist

2. Vlivy právní úpravy na návrh, lokalizaci a provoz IS • • • • • •

IS by měl mít podporu pro více národních legislativ (např. účetnictví) měl by umožňovat snadnou aktualizaci customizace a parametrizace podporu více národních měn možnost el. podpisu dostatečné zabezpečení dat

Úloha - předpoklady: Byl(a) jste najat(a) jako externista na místo vedoucího projektu vývoje IS velké zahraniční firmy. kde bude výhradním dodavatelem prací jistý zahraniční SWhouse, protože je generálním celosvětovým dodavatelem zákaznické firmy. Důvodem k Vašemu angažmá je Vaše znalost místního prostředí, s nímž nemá dodavatelská firma zkušenosti. Právě tvoříte plán tohoto projektu. Metodik dodavatele se ptá, nakolik bude nutné upravit firemní metodiku, aby vyhověla místním legislativním podmínkám. Jaké problémy a jakým způsobem budete řešit? Rozhodněte se, zda ovlivňuje legislativa i proces a vlastnosti vývoje informačního systému. Pokud ano, čím a jak? Jak to ovlivní přípravu Vašeho projektu?

3.10 LEGISLATIVA A IS Zákony a ostatní právní předpisy vztahující se k problematice tvorby a užití IS (obchodní zákoník, autorský zákon, zákon na ochranu osobních údajů, daňové zákony apod.) Vlivy právní úpravy na návrh, lokalizaci a provoz IS.

1.1.1 Zákony a ostatní právní předpisy vztahující se k problematice tvorby a užití IS (obchodní zákoník, autorský zákon, zákon na ochranu osobních údajů, daňové zákony apod.) Zdroj: Smejkal, V. a kol.: Právo informačních a telekomunikačních systémů. 2. rozšířené vydání. Praha : C. H. Beck, 2004 Aktuální právní úpravy Obdobně, jako tomu je ve všech ostatních zemích EU, i v ČR existují tradiční právní normy, které se dotýkají významným způsobem práva IT. Jsou to především: 1. autorský zákon - zákon č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, 2. zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, 3. telekomunikační zákon - zákon č. 151/2000 Sb., o telekomunikacích a o změně dalších zákonů. Dále se samozřejmě jedná o klasické právní normy, které upravují především závazkové právní vztahy, resp. je lze aplikovat v případě protiprávního jednání, jež se může vyskytnout i v prostředí IT. Těmito právními normami jsou především: 4. občanský zákoník - zákon č. 40/1964 Sb., 5. obchodní zákoník - zákon č. 513/1991 Sb. Dojde-li ke spáchání deliktu, lze postihnout protiprávní jednání podle zákonů: 6. trestní zákon - zákon č. 140/1961 Sb., 7. přestupkový zákon - zákon č. 200/1990 Sb. Kromě toho existují i další, zvláštní zákony, které upravují některé speciální otázky, týkající se IT. Jsou to především: 8. zákon č. 227/2000 Sb., o elektronickém podpisu a o změně některých dalších zákonů, 9. zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, 10. zákon č. 480/2004 Sb., o některých službách informační společnosti a o změně některých zákonů (zákon o některých službách informační společnosti, tzv. antispamový zákon). Zákon o elektronickém podpisu je jedním z nejpropracovanějších zákonů v Evropě, možná i na světě, a obsahuje kromě povinných ustanovení vyplývajících ze směrnice 1999/93/ES další možnosti. Kromě časového razítka, které je již ve světě používáno, zavedl do českého právního řádu dvě důležité novinky, které mají vztah především k činnosti orgánů veřejné moci. Jsou to tzv. elektronická značka a elektronická veřejná listina. V současné době se připravuje nový zákon o elektronických komunikacích, který vychází z tzv. nového regulačního rámce elektronických komunikací EU, jež by měl učinit další krok k plné liberalizaci telekomunikačního trhu. + Varianty právní formy řešení outsourcingové smlouvy (ot. 8)

1.1.2 Vlivy právní úpravy na návrh, lokalizaci a provoz IS •

IS by měl mít podporu pro více národních legislativ (např. účetnictví)

•

měl by umožňovat snadnou aktualizaci

•

customizace a parametrizace

•

podporu více národních měn

•

možnost el. podpisu

•

dostatečné zabezpečení dat

Úloha - předpoklady: Byl(a) jste najat(a) jako externista na místo vedoucího projektu vývoje IS velké zahraniční firmy. kde bude výhradním dodavatelem prací jistý zahraniční SWhouse, protože je generálním celosvětovým dodavatelem zákaznické firmy. Důvodem k Vašemu angažmá je Vaše znalost místního prostředí, s nímž nemá dodavatelská firma zkušenosti. Právě tvoříte plán tohoto projektu. Metodik dodavatele se ptá, nakolik bude nutné upravit firemní metodiku, aby vyhověla místním legislativním podmínkám. Zadání:

Jaké problémy a jakým způsobem budete řešit?

Rozhodněte se, zda ovlivňuje legislativa i proces a vlastnosti vývoje informačního systému. Pokud ano, čím a jak? Jak to ovlivní přípravu Vašeho projektu?

3.11 Výběrové řízení Výběrové řízení na dodávku IS/ICT Cíle a fáze výběrového řízení, poptávka – struktura, vazba na informační strategii, nabídka – struktura, vazba na nabídku, kritéria a postup hodnocení nabídek. Úloha - předpoklady: Vaše cestovní kancelář prodávající zájezdy do zahraničí ve své síti několika desítek poboček po ČR se rozhodla pro outsourcing provozu informačního systému. Zadání: Určete hlavní služby, které budou předmětem poptávky - vycházíme z IT strategie, kterou stanovil CIO a jakým způsobem on chce podporovat byznys cíle. Pravděpodobně bude třeba využití služeb umožňujících komunikaci mezi jednotlivými pobočkami, lokalizaci do příslušného jazyka v dané pobočce, standardizovanost, dále možnost zjišťování počtu klientů (konsolidovaně i jednotlivě), počet volných míst a dalších věcí pojící se k byznysu zájezdových kanceláří .. Určete klíčová kritéria výběru poskytovatele služeb tak, abyste minimalizoval rizika - viz stanovení kritérií + kritické faktory u outsourcingu v otázce Outsourcing

Co je výběrové řízení Výběrové řízení je proces, jehož cílem je získání nejlepšího dodavatele určité služby či určitého řešení. S tímto souvisí způsoby pořízení určitého IS či služby - vlastní vytvoření, dodavatelský způsob, outsourcing či asp/saas. Vedle vlastního vytvoření vždy potřebujeme vybrat nějakou protistranu, která nám bude něco dodávat. Z tohoto pohledu se pak dají cíle výběrového řízení shrnout takto: -

dosáhnout optimální poměr cen/výkon získat z našeho pohledu nejvýhodnějšího dodavatele

Postup výběrového řízení Proto, aby bylo možné tohoto dosáhnout, existuje metodika výběrového řízení, která definuje jednotlivé fáze tohoto procesu tak, aby byl co nejúspěšnější, tj.: -

snižuje náklady snižuje rizika (každý krok sníží určitý druh rizik)

Jednotlivé fáze výběrového řízení: -

Formulace celkového záměru vývoje IS/ICT: o

-

Stanovení kritérií pro výběrové řízení na dodavatelskou společnost (přes 100, do několika kategorií s podkategoriemi a vahami, které jsou pro každý podnik jiné, bodově ohodnotit a také slovně co to znamená). Kritéria jsou o o o

-

Jmenování výběrové komise (finančák,výroba,CIO,externí konzultant,právník,druhá úroveň vedoucích, která ví, jakou funkcionalitu potřebují)

Vytvoření poptávkového dokumentu o o

-

obligatorní – povinná,firma to musí splnit (sw v souladu s legislativou, peníze,termíny atd,referenční instalace.) fakultativní - nepovinná zveřejnění hodnocení daných kritérií: u veřejných zakázek se musí povinně uvést, proč jsme vybrali určitou společnost u neveřejných zakázek alespoň zhruba

Příprava soutěže o

-

Jsme firma ta a ta, vyrábíme to a to, máme tolik a tolik zaměstnanců, provozujeme ten a ten systém, chceme ho změnit, pošlete nám svoje nabídky. Tak bychom dostali to co dodavatel má a ne to co potřebujeme. Nebude to mít vazbu na naše business cíle ani na nic jiného. Firma musí vědět, CO CHCE a tudíž musí být tento záměr podpořen informatickou strategií. Užší výběr dodavatelů pak musí vědět, i proč to chceme a jaké jsou souvislosti.

Odvozen z IST, ale neobsahuje důvěrné informace Obsahuje prohloubenou funkční specifikaci těch částí IS, které jsou předmětem soutěže. Jak to dobře vyhodnotit? Uděláme si tabulku a v ní jednotlivé funkce v řádcích, ve sloupcích jednotlivé dodavatele. Dodavatel může odpovědět: Máme ve standardu Nemáme Obsahuje navíc požadovanou strukturu nabídky

Vyhlášení soutěže o

Forma veřejná nebo neveřejná - pokud víme, že množina dodavatelů je omezená a víme víceméně, od kterých,tak oslovíme pouze firmy, o které máme zájem

Page 1

o o o o

o

-

Přihlášení do soutěže a vypracování nabídek uchazeči o zakázku o

-

Pokud dodavatel nesplňuje jakékoliv obligatorní kritérium, tak ho vyřadíme a vrátíme mu jistotu Detailní hodnocení nabídek, nejlépe maticově Výběr 4-6 nejúspěšnějších Dodavatelé mohou své nabídky prezentovat, tyto prezentace by měly být ve stylu "vy máte problém, tak jak my vám ho pomůžeme vyřešit"

Analýza referenčních instalací o o o

-

Rozumná doba pro sepsání nabídky je 4-6 týdnů, v tomto období by poptávající strana měla poskytnout uchazečům nejen poptávkový dokument, ale i konzultace

Vyhodnocení nabídek o o o o

-

Název, sídlo, telefon Obsahové vymezení zakázky Adresu a lhůtu, do kdy je možno si vyžádat zadávací dokumentaci, případně též výši úhrady za její poskytnutí Postup výběrového řízen pro kandidáty: Způsob hodnocení nabídek, viz zveřejnění hodnocení daných kritérií Požadovaná struktura nabídky včetně nabídkové a ceny a platebních podmínek • Základní charakteristika uchazeče o Název, sídlo, právní, forma, datum založení, doba podnikání,ZK o Ekonomická síla (obrat za poslední 3 roky, HV) o Průměrný počet pracovníků za 3 roky • Struktura definovaná poptávajícím - viz vytvoření poptávkového dokumentu Místo pro podávání nabídek, soutěžní lhůta a čas otevírání obálek s nabídkami Zadávací lhůta (čas po který jsou uchazeči nabídkami vázání) a jistota - částka, která propadá ve prospěch zadavatele výběrového řízení tehdy, pokud je dodavatel vybrán, ale není schopen podepsat kontrakt podle toho, co si specifikoval ve výběrovém řízení Důležitým kritickým faktorem této fáze je, aby dodavatelé předali korektní informace v nabídkách (proto jistota)

Slouží k ověření toho, zdali je firma opravdu taková, jaká se zdá Pozor na lokalizaci - referenci na druhém konci světa je nám z tohoto pohledu k ničemu Je třeba se připravit - zvolit si cíl, obsah a účastníky, tj. kdo by měl jet a na co by se měl ptát - nejlépe metodici a střední management (lidi co rozumějí funkcionalitě) - hledají svůj protějšek a ptají se ho, zdali byly problémy s komunikací, termíny, zdroji…)

Finální výběr o o o

Ze dvou uchazečů, kterým jsou předány důvěrnější informace, aby mohl každý z nich zpracovat úvodní studii (na základě prohloubení nabídky). Neúspěšnému uchazeči za úvodní studii však zaplatíme a vrátíme jistotu. V tomto bodu komunikujeme již s lidmi, kteří budou na projektu pracovat. Po vybrání vítěze uzavřeme kontrakt.

Poptávkový dokument Měl by být odvozen od informační strategie, ale neměl by obsahovat žádné důvěrné informace. Pro dodavatele slouží nejenom k tomu, jakou funkcionalitu by měl zajišťovat, ale i dimenzování systémů, tj. počet licencí či uživatelů, diskové kapacity… , obsah: -

Organizačně ekonomické charakteristiky o o o

-

Specifikace požadovaných funkcí poptávaného IS o o o

-

Popis současného stavu věcí Požadovaná funkcionalita, priority a doba odezvy u určitých funkcí (tj. kvalitativní charakteristiky služby) Přiřazení požadovaných funkcí do organizační struktury

Datová specifikace o o o

-

Organizační schéma Kapacitní charakteristiky Personální charakteristiky

Současný stav (datové zdroje, objemy dat..) Vymezení nových datových objektů, jejich objemu a periodicity změn Požadované principy ochrany a zabezpečení dat

Technologická specifikace o o

Co máme za technologie - zajímá nás, jakým způsobem dokáže dodavatel využít naše stávající technologie Předpokládaný počet koncových stanic

Page 2

3.11 Výběrové řízení na dodávku IS/IT Cíle a fáze výběrového řízení, poptávka – struktura, vazba na informační strategii, nabídka – struktura, vazba na nabídku, kritéria a postup hodnocení nabídek.

1. Cíle a fáze výběrového řízení 1.1. Co je výběrové řízení Jde o proces, jehož cílem je: • je získání nejlepšího dodavatele určité služby či určitého řešení. • dosáhnout optimálního poměru cen/výkon • získat optimální skladbu SW a technických prostředků a služeb, které budou nejlépe odpovídat situaci a potřebám podniku 1.2. Postup výběrového řízení Postup výběrového řízení definuje jednotlivé fáze procesu tak, aby byl co nejúspěšnější - snižuje náklady ( využívá převisu nabídky nad poptávkou) - snižuje rizika (každý krok sníží určitý druh rizik)

Jednotlivé fáze výběrového řízení: - Formulace celkového záměru vývoje IS/ICT: o o o o o

Většinou formou IST Jsme firma ta a ta, vyrábíme to a to, máme tolik a tolik zaměstnanců, provozujeme ten a ten systém musíme vědět CO CHCEME Užší výběr dodavatelů pak musí vědět, i PROČ TO CHCEME a jaké jsou souvislosti CSF: musí být známo, co se požaduje

- Příprava soutěže o

Jmenování výběrové komise

o

Stanovení kritérií výběru

o

finančák,výroba,CIO,externí konzultant,právník,druhá úroveň vedoucích (ví, jakou funkcionalitu potřebují) nejlépe rozřadit do kategorií a podkategorií, určit jim váhy, bodové hodnocení Kritéria • obligatorní – povinná,firma to musí splnit o např. SW v souladu s legislativou, peníze, termíny,referenční instalace • fakultativní - nepovinná zveřejnění hodnocení daných kritérií: o u veřejných zakázek se musí povinně uvést o u neveřejných zakázek alespoň zhruba

Vytvoření poptávkového dokumentu

Odvozen z IST, ale neobsahuje důvěrné informace Prohloubenou funkční specifikaci těch částí IS1, které jsou předmětem soutěže. Požadovanou strukturu nabídky

- Vyhlášení soutěže, zveřejnění podmínek •

veřejná nebo neveřejná

•

Podmínky (u veřejných zakázek povinně)

o o o o o o o o

neveřejná - víme, že množina dodavatelů je omezená - oslovíme pouze firmy, o které máme zájem

Název, sídlo, telefon a fax zadavatele Obsahové vymezení zakázky Adresa a lhůta, do kdy je možno si vyžádat zadávací dokumentaci, případně výši úhrady za její poskytnutí2 dobu a místo plnení zakázky, Způsob hodnocení nabídek Požadovaná struktura nabídky Místo pro podávání nabídek, soutěžní lhůta a čas otevírání obálek s nabídkami Zadávací lhůta - čas po který jsou uchazeči nabídkami vázání

1

Jak to dobře vyhodnotit? Uděláme si tabulku a v ní jednotlivé funkce v řádcích, ve sloupcích jednotlivé dodavatele. Dodavatel může odpovědět: Máme / Nemáme

2

poptávkový dokument si vyzvednou jen vážní zájemci

Page 1

o o

jistota - částka, která propadá ve prospěch zadavatele výběrového řízení tehdy, pokud je dodavatel vybrán, ale není schopen podepsat kontrakt CSF - dodavatelé předají korektní informace v nabídkách (proto jistota)

- Přihlášení do soutěže a vypracování nabídek uchazeči o zakázku o o o

poskytunutí poptávkového dokumentu konzultace – veřejné / soukromé Rozumná doba pro sepsání nabídky 4-6 týdnů

- Vyhodnocení nabídek o o o

dle obligatorních kriterií Detailní hodnocení ( nejlépe maticově ) Výběr 4-6 nejúspěšnějších

- Analýza referenčních instalací (začíná 2.kolo) o o o

o

Slouží k ověření firmy - je opravdu taková, jaká se zdá? Pozor na lokalizaci - referenci na druhém konci světa je nám z tohoto pohledu k ničemu Důležitá je příprava cíl, obsah a účastníci - kdo by měl jet a na co by se měl ptát nejlépe metodici a střední management (lidi co rozumějí funkcionalitě) - hledají svůj protějšek a ptají se ho, zdali byly problémy s komunikací, termíny, zdroji… CSF: umejí udelat to, co my potrebujeme mají kvalitní tým rešitelu chovají se korektne k zákazníkovi

- Prezentace nabídek o

končí výběrem 2 nabídek do 3.kola

- Zpracování US o o

2 vybraným uchazečům poskytneme bližší informace k vypracovnání US nevybranému uchazeči studii zaplatíme

- Vyhodnocení studií, podpis smlouvy s vítězem o

Po vybrání vítěze uzavřeme kontrakt.

2. Poptávkový dokument – vazba na IST Měl by být odvozen od IST, ale neměl by obsahovat žádné důvěrné informace. Pro dodavatele • popis požadované funkcionality • dimenzování systémů, (počet licencí či uživatelů, diskové kapacity) Obsah: - Základní charakteristiky zadavatele a zakázky o o o

název, sídlo, předmět činnosti, statutár místo plnění zakázky, předpokládaná doba plnění zakázky soutěžní lhůta, zadávací lhůta

- Cíle, kterých má být pomocí dodávky dosaženo o

ekonomické, z hlediska org. struktury, pracovníků podniku, IS/IT základem pro určení kriterii kvality řešení

- Organizačně ekonomické charakteristiky o

Organizační schéma, kapacitní a personální charakteristiky

- Předpokládaná architektura komplexního IS/IT - Funkční specifikace o o o

Popis současného stavu Požadovaná funkcionalita, časové priority a doba odezvy u určitých funkcí (tj. kvalitativní charakteristiky služby) Přiřazení požadovaných funkcí do organizační struktury

- Datová specifikace o o o

Současný stav (datové zdroje, objemy dat..) Vymezení nových datových objektů, jejich objemu a periodicity změn Požadované principy ochrany a zabezpečení dat

- Technologická specifikace o o

Co máme za technologie (zajímá nás, jakým způsobem dokáže dodavatel využít naše stávající technologie) Předpokládaný počet koncových stanic

- Požadovaná struktura nabídky (umožňuje rychlejší vyhodnocování nabídek) - Shrnutí obligatorních podmínek soutěže

3. Struktura nabídky - Základní charakteristika uchazeče a jeho kvalifikační predpoklady

Page 2

o o o o

o

Název, sídlo, právní, forma, datum založení, doba podnikání,ZK Ekonomická síla (obrat za poslední 3 roky, HV) Průměrný počet pracovníků za 3 roky Prokázání uchazeče, že3 má podnikatelské oprávnení (doložit), nebyl na jeho majetek prohlášen konkurz, nebylo proti němu zahájeno konkurzní nebo vyrovnávací rízení, není právnickou osobou v likvidaci, nemá danové nedoplatky, nemá po splatnosti závazky vuci nositelum sociálního a zdravotního pojištení Další charakteristiky uchazeče: aplikační orientace (na který sektor ekonomiky a na jaké aplikace v tomto sektoru je firma zamerena), technologická orientace (hardware, síte, základní software), vlastnictví platných certifikací na používané technologie, hlavní již realizované projekty (rok realizace, zákazník, předmět dodávky, rámcový financní objem), vlastnictví certifikace dle ISO 9000

- Sumarizace nabídky o o o o o o

strucný prehled navrhovaného rešení, ocekávané efekty, které nastanou po realizaci rešení, zpusob garance funkcnosti jednotlivých komponent a celého systému, termínu dodávky a ceny, konecný termín dodávky a termíny hlavních etap, celková cena systému a cena jednotlivých etap, stupen splnení jednotlivých obligatorních kritérií

- Celková koncepce rešení o o o o o o

aplikační architektura systému a způsob realizace technologická architektura řešení integrací flexibilita systému, otevřenost a standardy argumentace vhodného dimenzování systému (prohlášení, že systém je dimenzován tak, aby splňoval požadavky v poptávkovém dokumentu) návrh řešení kritických/krizových situací, globální návrh bezpečnosti systému

- Specifikace nabízeného ASW o o o o

specifikace jednotl. funkčních celků stupeň pokrytí požadovaných funkcí a dat (tabulka – název funkce, stupeň pokrytí pomocí ASW) flexibilita, vývojové prostředí, vzájemné vazby mezi subsystémy úroveň řešení národního prostředí, specifikace dokumentace

- Návrh ZSW a OIS o

OS, SW pro řízení LAN a WAN, DB, workflow, pošta, principy a podmínky integrace

- Návrh vazeb HW, ZSW, ASW a organizacní struktury podniku - Služby související s dodávkou o o o o o o

-

ekonomicko-organizacní poradenství (zejména BPR související s optimálním nasazením ASW), údržba systému, zpusob rešení modifikací a verzí ZSW a ASW, vývoj specifických aplikací na zakázku, pozárucní servis HW školení (typ, délka, jazyk, komu urceno, odhadovaný počet úcastníku z rad pracovníku odberatele), horká linka,

Garance a záruční servis Metodika implementace systému Předávací procedury Postup přechodu ze stávajícího IS na nový Řešitelský tým dodavatele Specifikace eventuálních subdodavatelu a jejich subdodávek Harmonogram rešení IS a jeho smluvní zajištení Cenová specifikace dodávky Dodací podmínky a soucinnost odberatele Referencní instalace systému

4. kritéria a postup hodnocení nabídek - Postup hodnocení nabídek dle kriterii: 1. 2.

3

návrh každého uchazece boduje každý clen komise (stupnicí 0-5) podle stanovených kritérií. Hodnotitel nemusí hodnotit nabídky z hlediska všech kritérií, ale pouze z hlediska tech kritérií, ve kterých je odborníkem, porovná se hodnocení jednotlivých hodnotitelu,

u veřejných zakázek povinnost

Page 3

3. 4. 5.

jsou-li mezi hodnotiteli významné rozdíly, probehne diskuse s argumentací, po které hodnotitelé mohou zmenit svá bodová hodnocení, u každého návrhu se vypocítá aritmetický prumer bodového hodnocení dle každého kritéria, soucet soucinu bodu a vah urcí poradí návrhu.

- Kriteria - Největší váhy: o o o o o

funkčnost SW kompatibilita cena dostupnost v místním jazyce (diskutabilní) dostupnost kvalitní podpory, rozšiřitelnost, atd….

Úloha Vaše cestovní kancelář prodávající zájezdy do zahraničí ve své síti několika desítek poboček po ČR se rozhodla pro outsourcing provozu informačního systému.

• Určete hlavní služby, které budou předmětem poptávky • vycházíme z IT strategie, kterou stanovil CIO (jakým způsobem chce podporovat byznys cíle) o služby komunikace mezi jednotl. pobočkami o rezervační služby zájezdů, letenek, napojení na hotely o služby provozu online rezervačního systému na webových stránkách • Určete klíčová kritéria výběru poskytovatele služeb tak, abyste minimalizoval rizika o míra pokrytí požadovaných služeb poskytovatelem o míra záruk funkčnosti o kompatibilita se stávajícím systémem o podpůrné služby – školení, helpdesk o velký dodavatel se stabilním zázemím a zkušenostmi v oboru, počet a druh zákazníků o cena

Page 4

3.12 UZAVÍRÁNÍ SMLUV Konfrontujte pohledy zadavatele a řešitele na obsah smlouvy pro dodávku komplexního IS. Objasněte obsah smlouvy a vysvětlete zájmy obou skupin. Rozeberte obsah smlouvy, kdy jako řešitel vystupuje externí systémový integrátor anebo kdy jako řešitel vystupují dodavatelé jednotlivých komponent a systémovým integrátorem je zadavatel.

1.1.1 Konfrontujte pohledy zadavatele a řešitele na obsah smlouvy pro dodávku komplexního IS Indikace pro volbu externího systémového integrátora

IS/ICT má pro podnik prioritní význam a jeho nefunkčnost může ohrozit dosažení podnikatelského záměru,

požadavky na realizátory přesahují možnosti vlastního týmu informatiku,

čas realizace IS/ICT je kritickým faktorem.

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.

1.1.2 Objasněte obsah smlouvy a vysvětlete zájmy obou skupin !!!

1.1.3 Rozeberte obsah smlouvy, kdy jako řešitel vystupuje externí systémový integrátor anebo kdy jako řešitel vystupují dodavatelé jednotlivých komponent a systémovým integrátorem je zadavatel 1.1.3.1 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.

Ú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í

Počítačová podpora životního cyklu vývoje IS (3.13) Okruh: RIS Č. ot.: 3.13 Zadání teorie:

Úloha předpoklady:

Zadání úlohy:

9.4.2005, v1.0

Počítačová podpora životního cyklu vývoje IS Co je životní cyklus informačního systému, resp. model vývoje systému. Uveďte přístupy k životnímu cyklu z hlediska různých metod. Základní fáze tvorby projektu IS, rozhodující problémy spojené s jednotlivými fázemi, možnosti řešení. Jaké jsou možnosti počítačové podpory prací v jednotlivých etapách vývoje a provozu IS (automatizace v oblasti řízení projektu, analýzy a návrhu a implementace IS, v době provozu IS). Prostředky typu CASE. Jste zástupcem softwarové firmy, zaměřené na vývoj IS. Právě se rozhodujete o příslušném nástroji CASE. Máte, pochopitelně, velmi omezené finanční zdroje, nechcete se však, též pochopitelně, nechat omezovat vybraným nástrojem, jelikož nechcete omezovat okruh svých potenciálních zákazníků (resp. jejich možných přání). Rozhodněte se, jaké vlastnosti by podle Vašeho názoru měl splňovat „ideální“ CASE (nutná míra závislosti na typu organizace, ve které se CASE využívá, nebo na typu IS, řešených s pomocí CASE apod.). Budete případně ochoten i riskovat zadlužení a v jakém případě (jaké vlastnosti by musel takový nástroj mít a jsou vůbec reálné)?

Předmět: Zdroje:

IT_572

Garant:

Doc. Řepa, Václav

Zpracoval:

Jiří Khun

Teorie Životní cyklus znamená proces tvorby informačního systému a jeho následné existence.

etapa tvorby návrh, realizace a stabilizace projektu

garantuje vývoj

etapa rutinního využívání projektu etapa morálního dožití garance stabilního prostředí pro uživatele

garantuje provoz

příprava na nové řešení projektu

garantují oba

V minulosti byl obvyklý tento poměr mezi jednotlivými etapami: 1-1.5 roku

4-7 let

0.5-1 rok

V současnosti se prosazuje mnohem rychlejší inovace a rychlý vývoj a mění se dříve ustálené poměry: 3-6 měsíců

2-4 roky

do 5 měsíců

Metodika tvorby IS zahrnuje jednak celkový pohled na životní cyklus IS, dále rozpracování jednotlivých atributů všech fází životního cyklu a příslušné metody, techniky a nástroje, používaných v jednotlivých činnostech vývoje a provozu IS. Metodika tvorby IS je souhrn etap, přístupů, zásad, postupů, pravidel, dokumentů, řízení, metod, technik a nástrojů, který pokrývá celý životní cyklus IS. Metodika by se měla vztahovat na všechny prvky IS – pracovníky, org.procedury a postupy, data, SW, HW, organizační vlivy IS, ekonomické otázky spojené s vývojem a provozem IS, použité metody, techniky a nástroje jednotlivých fází ŽC IS, produkty a potřebné dokumenty v jednotlivých fázích ŽC IS, způsob řízení v jednotlivých fázích ŽC IS. Základem všech úvah v metodikách je představa o struktuře a obsahu tzv.životního cyklu informačního systému - od této představy se odvíjí a k ní se váže veškerý další obsah metodiky.

Obecné principy metodik tvorby IS 1. Orientace na cíl a problémy - 1/7 -

Počítačová podpora životního cyklu vývoje IS (3.13)

9.4.2005, v1.0

2. Účast zadavatele projektu 3. Klíčové dokumentace a jejich schvalování 4. Zapojení uživatele do návrhu 5. Modelování a abstrakce, princip 3 architektur systému 6. Ověřování a testování návrhu během celého vývoje 7. V každé etapě probíhá analýza a návrh 8. Vývoj probíhá z hlediska všech úhlů pohledu na systém (data, funkce, organizace, technologie, sociálně psychologického, ekonomického.) 9. Otevřenost metodiky

Druhy metodik Metodiky vývoje lze nakoupit v podobě vytištěných publikací, hypertextových souborů, školení, kurzů – což je řadí do skupiny specifického zboží. Lze je členit do následujících skupin: a) státem podporované metodiky – stát vyžaduje při státních zakázkách daný postup, nebo je jejím vlastníkem a zodpovídá za vytváření nových podverzí. - SSADM (GB), SDM (Hol.), MERISE (Fr.), V-MODEL (N). b) mezinárodní metodiky – zaměřeny na pracovníky státní i nadstátní správy – Euromethod, Software Life-Cycle process (ISO) c) firemní metodiky - jsou ve vlastnictví významných firem, škol, institutů, autorů, možnost placení za použití. SE (LBMS), ORACLE CASE∗method (Oracle Corp.), Acceleration Systém Development for Client/Server (Erst&Young), RAP (Texas Instrumnets). Zde jsou uvedeny jen 2 metodiky, další jsou uvedeny v přiloženém dokumentu na konci otázky.

1) MDIS - viz otázka 1.9

2) SDM (System development Methodology) - Klasický vodopádový přístup k tvorbě IS. Tato metoda se dívá na vývoj nového IS jako na propast, která vznikla mezi současným stavem v informační podpoře organizace a žádoucím. Mostem přes propast je vývoj IS, který bude následně popsán fázemi, a ten je podřen pilířemi (řízení, změna, ověření – přítomné v každé fázi vývoje IS). SDM není striktně lineární např. v zavádění. Fáze SDM se dělí dále na činnosti, těmi jsou realizovány 4 základní procesy SDM 1. Informační plánování (IP) –zaměření na celou organizaci, hledají se primární problémy, na základě toho vybrání oblasti zájmu, IP se rozpadá na dvě etapy: situační analýzu (zmapování všech činností v organizaci a posouzení jejich informační podpory) a koncepci informačních systémů (spočívá v návrhu 4 architektur – informační, technické,m organizační, projektové) 2. Úvodní studie – posouzení realizovatelnosti systému, ne pro celou organizaci, ale jen pro jeden systém, posouzení realizovatelnosti se provádí v alternativách, skončí, pokud je vedení schopno stanovit tu nejlepší alternativu. Shromáždění údajů o současném stavu, následné upřesnění požadavků na IS, vypracován předběžný návrh (koncept) obsahující pouze vstupy,výstupy, funkce, návrh alternativ jak tento systém řešit, výběr alternativy a na závěr je vytvořen plán vývoje systému, obsahující odhad nákladů a přínosů 3. Globální návrh –poslední fáze kdy ještě systém vidíme jako celek, zpodrobnění funkčního návrhu, začíná se technický návrh, rozdělení na subsystémy. Při dekompozici se dělí funkce a data na menší celky. Jako první se provádí funkční návrh a to ze 3 hledisek: určení organizační struktury, určení dat.struktury, určení funkcí systému a jejich struktury. Při funkčním návrhu se vychází z požadavků uživatelů. Hlavní chybou je přílišná podrobnost která spadá až do další fáze.

- 2/7 -


9.4.2005, v1.0

4. Detailní návrh každého subsystému – provádí se pro každý subsystém zvlášť, návrh je v této fázi dotažen do takové fáze, je buď možno začít hned programovat, nebo začít upravovat hotové sady ASW. Na závěr by měl být vytvořen podrobný plán testování. 5. Implementace – jde o fázi programování, psaní dokumentace, seznámení s uživateli, testování programů tvůrci a i uživateli. Nelze měnit(přidávat) uživatelské požadavky 6. Zavádění – instalace programů, vytvoření popisů pracovní náplně, proškolení, provedení navržených změn. Definice požadavků na rutinní provoz, uzavírání smluv oddělením provozu, konverze stávajících dat do podoby použitelné systémem. 7. Provoz a údržba – cílem je udržet IS v takovém stavu, že splňuje všechny požadavky po zbytek ŽC.

Životní cyklus SW produktu Fáze životního cyklu SW jde rozdělit na zahájení, růst, dospělost, ústup, - viz.obr.88 str.276 (1) Zahájení – u výrobce je tato fáze spojena se značnými investicemi(vývoj a marketing produktu), první instalace produktu. Riziko pro výběr za účelem strategického sw ve firmě. Nedostatky, chyby, není zaručená životnost. Při tendru zařadit mezi možné kandidáty, pouze v tom případě, pokud je životně důležitý, cena (ost.parametry) jsou mnohem výhodnější než u jiných kandidátů.

Růst – další vývoj produktu(funkce, platformy, provozní charakteristiky, roste počet instalací. Riziko – nezvládnutý růst výrobcem – následně šatná kvalita služeb ( i pád produktu). Pokud jsou při v.ř. tyto rizika brána v potaz a vyhodnocena jako minimální, je nákup produktu v této fázi velmi dobrou investicí do budoucna.

Dospělost – nyní se výrobce soustřeďuje především na provoz a údržbu systému. U nových verzí dochází k drobným vylepšením systému, žádné zásadní inovace. Počet instalací stabilní – až stagnuje. Minimální rizika při nákupu, ale také žádná velká konkurenční výhoda.

Ústup – fáze produktu, která nastane tehdy, pokud výrobce neinvestuje do inovací, nevylepšuje produkt - nové verze. Konkurenční produkty jsou mnohem dál, nabízejí větší rozsah funkcí, založených na modernějších a aktuálnějších technologiích. Úbytek počtu instalací. Investice do daného produktu je nevýhodná, nevýnosná. Pokud nedochází k inovacím, zákazníkovi nastanou dvě možnost: ponechá si starý produkt, ztrácí konkurence schopnost nebo koupí nový, čímž mu vznikají náklady na nákup a implementaci.

Možnosti počítačové podpory jednotlivých činností v rámci projektu vývoje SW CASE je podporou

• řízení vývoje IS (poskytuje dokumentaci a okamžitou aktuální informaci o stavu a obsahu vyvíjeného IS) • zajištění konzistence a integrace návrhu IS (na základě definovaných integritních pravidel) CASE zahrnují prostředky pro automatizovanou podporu metod SW inženýrství. Nejzákladnější etapou životního cyklu programového systému je jeho úsržba - na výši těchto nákladů má vliv kvalita přípravné fáze -> CASE kladou důraz na přípravné fáze životního cyklu IS. Základní vlastnosti (přínosy) CASE • konzistentní grafické komunikační prostředí • centrální DB (encyklopedie) - jednotný slovník dat - použitelnost dat, dokumentace se snadno tvoří • obsahuje prostředky pro ověření konzistence a kompletnosti dat (prostředky pro normalizaci dat) • formalizuje popis všecxh fází životního cyklu projektu, užívá formalizovaných prostředků - DFD, ERD - díky formalizaci vnutí společnou řeč všem, kteří se na projektu podílí • obsahuje generátor zdrojových programů • umožňuje vytváření prototypu (uživatel se stává spolutvůrcem, možnost přesně formulovat požadavky) • možnost používat import/export textových či DB souborů do/z jiných programových systémů • prostředky pro podporu řízení projektů (např. CPM, PERT) • prostředky pro tvorbu dokumentace • podporuje některou metodiku, nebo výběr z několika metodik - 3/7 -


9.4.2005, v1.0

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 Typy CASE v životním cyklu vývoje IS GST -> Pre-CASE

IST -> ÚS -> GAN -> DAN Upper-CASE Middle-CASE

->

IMP -> ZAV -> Lower-CASE

PÚR Post-CASE

CASE prostředky zaměřující se pouze na některé fáze životního cyklu projektu jsou běžně členěny na: • Pre-CASE: nástroje (např. tabulkové kalkulátory) podporující činnosti předcházející vývoji IS - 4/7 -


9.4.2005, v1.0

• tyto činnosti se váží k tvorbě globální strategie • Upper-CASE: prostředky zaměřené na podporu činností při tvorbě informační strategie a úvodní studie IS • podporují činnosti podobné činnostem globální strategie + metody používané při informační analýze a návrhu specifikace IS • Middle-CASE: prostředky zaměřené na analytickou a logickou část návrhu systému • v této části existuje nejvíce exaktních metod a technik - na jejich podporu jsou zaměřeny a jejich vzájemnou integraci • Lower-CASE: prostředky podporující implementaci výsledků analýzy a logického návrhu systému • tvoří most mezi middle-CASE a implementačním prostředím • jsou často implementačně závislé na konkrétním prostředí • Post-CASE: podporují zbývající fáze - zavedení a údržbu a provoz

CASE nástroj – obecné schéma

Řízení

Programový kód Definice databáze

Cíle systému Uživatelské požadavky

CASE Modely reality Technologická omezení

Prototypová řešení

Systémová encyklopedie Repository Implementační omezení

Prototypová řešení

Integrace a konzistence 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 - 5/7 -


9.4.2005, v1.0

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

3. 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 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 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í. - 6/7 -


9.4.2005, v1.0

Praktická úloha 1) Vlastnosti, které by CASE nástroj měl splňovat, byly vysvětleny v kapitole Stanovení kritérií pro výběr CASE nástroje na předešlé stránce. Co se orientace CASE nástroje týče (podnik nebo typ IS), tak zde bych preferoval orientaci na IS. Dle zadání jsme totiž reprezentanti SW firmy a pokud bychom se soustředili jen na některé podniky (např. u mezinárodních podniků s předem známým implementačním prostředím nemusíme používat drahé nástroje, ale vystačíme si pohodlně s omezenými verzemi), tím bychom snižovali i rozsah nabízených služeb. Takže jednoznačně orientace na typ IS. 2) K vlastnostem CASE nástroje – viz minulá odpověď. Co se zadlužení týče – v počáteční fázi podnikání bych se odmítl zadlužit kvůli CASE nástroji. Daleko radši bych se snažil využívat levnější alternativy (např. nástroje CASEStudio nebo Enterprise Architect stojí okolo 4.000 Kc/rocne a jejich funkcionalita je na většinu akcí zcela dostačující). Pokud bych na konkrétní projekt potřeboval kvalitnější nástroj, rozhodoval bych se mezi 2 možnostmi: a) pokud by příjem z tohoto projektu byl natolik vysoký, že by se z větší části drahý CASE nástroj zaplatil, pak bych byl ochoten zadlužení připustit. b) pokud nikoliv, využil bych nájmu této služby pomocí ASP či bych svěřil tuto konkrétní činnost našemu strategickému partnerovi. Toto je co se týče počátku podnikání. Nyní ze strany, kdy již na trhu nějakou dobu existuji – v tuto chvíli bych už pravděpodobně znal, jak na tom trh je, na co jsou které nástroje postačující a byl bych schopen daleko kvalifikovaněji rozhodnout, zda-li je zadlužení se kvůli kvalitnímu CASE nástroji vhodné. Další poznámky k otázce

Prehled_CASE_nastr oju.doc

Dalsi_metodiky_vyvo je_IS.doc

- 7/7 -

3.13

Počítačová podpora životního cyklu vývoje IS

Co je životní cyklus informačního systému, resp. model vývoje systému. Uveďte přístupy k životnímu cyklu z hlediska různých metod. Základní fáze tvorby projektu IS, rozhodující problémy spojené s jednotlivými fázemi, možnosti řešení. Jaké jsou možnosti počítačové podpory prací v jednotlivých etapách vývoje a provozu IS (automatizace v oblasti řízení projektu, analýzy a návrhu a implementace IS, v době provozu IS). Prostředky typu CASE. Úloha - předpoklady: Jste zástupcem softwarové firmy, zaměřené na vývoj IS. Právě se rozhodujete o příslušném nástroji CASE. Máte, pochopitelně, velmi omezené finanční zdroje, nechcete se však, též pochopitelně, nechat omezovat vybraným nástrojem, jelikož nechcete omezovat okruh svých potenciálních zákazníků (resp. jejich možných přání). Zadání: Rozhodněte se, jaké vlastnosti by podle Vašeho názoru měl splňovat „ideální“ CASE (nutná míra závislosti na typu organizace, ve které se CASE využívá, nebo na typu IS, řešených s pomocí CASE apod.). Budete případně ochoten i riskovat zadlužení a v jakém případě (jaké vlastnosti by musel takový nástroj mít a jsou vůbec reálné)?

Co je životní cyklus informačního systému? Základní fáze tvorby projektu IS (problémy a možnosti řešení). Životní cyklus IS je několik za sebou jdoucích fází, pro které je stanoven specifický cíl a činnosti vedoucí ke splnění tohoto cíle (ve své podstatě vychází z marketingového pojetí životního cyklu produktu). Každá metodika definuje svůj specifický životní cyklus, nicméně základní prvky jsou všude stejné a ten nejjednodušší životní cyklus se skládá z těchto fází: • • • •

Plánování Návrh Implementace Provoz a údržba

Jemnější rozdělení jednotlivých fází vypadá následovně: • • • • • • •

Identifikace problémů, možností a cílů Definice informačních potřeb Analýza systémových potřeb Návrh doporučeného systému Vývoj a dokumentace software Testování a zavádění systému Údržba a zavádění systému

Například Voříšek uvádí zejména čtyřfázový životní cyklus – zahájení, růst, dospělost a ústup. Pro každou etapu je definována řada činností, které je třeba udělat – tyto činnosti jsou popsány metodikou. Popis jednotlivých činností je: • • • • • •

Cíl – co je úkolem této fáze Postup – jak dosáhneme cíle Vstupy – z jakých dokumentů a materiálů se čerpá Výstupy – jaké produkty a dokumenty se v dané fázi vytvářejí Zúčastněné role a odpovědnosti – jaké profese se účastní a co mají na starosti Doporučené nástroje a techniky – techniky a technické prostředky, které využijeme v dané fázi

Přístupy k životnímu cyklu z hlediska různých metod.

Vodopádový životní cyklus Je charakterizovaný následujícími atributy: -

Ruční programování (bez použití CASE) Strukturované programování Řízení projektu pomocí CPM a PERT Aplikace vyvíjené pro jeden centrální počítač Za nedostatek byla považována dlouhá doba vývoje (často se v průběhu realizace změnilo zadání)

Prototypový životní cyklus Prototyp je částečnou implementací produktu (nebo jeho části) v logické, nebo fyzické formě, která prezentuje všechna vnější rozhraní.

Spirálový model životního cyklu - Jde o kombinaci prototypování a analýzy rizik - 4 základní kroky se při vývoji systému stále opakují a při zopakování jsou již na vyšší (kvalitnější ) úrovni: o Určení předmětu řešení, alternativ a omezení o Vyhodnocení alternativ, identifikace a řešení rizik o Vývoj produktu pro danou úroveň o Plánování další fáze Chyby a nevyhovující postupy jsou odhaleny co nejdříve a při vývoji SW jsou použity neustále vylepšované postupy. Naopak nevyhovuje vývoji na zakázku (obtížně se mění požadavky v průběhu vývoje). Je závislý na rizikové analýze a vyžaduje zkušenější pracovníky a projekty menšího rozsahu. Velké projekty by bylo nutné členit na podrobnější kroky a určovat kontrolované výstupy.

Metoda iterace a inkrementace To je vlastně několik vodopádů za sebou. Po každé iteraci je k dispozici funkční a testovatelný produkt, který nabaluje nové funkčnosti. Díky tomu zákazník vidí jak se jeho požadavky promítají do reálného software a může je ještě přizpůsobit.

Iterace 1 Analýza Návrh

přírůstek Iterace 2

Tvorba aplikace

Analýza Návrh Tvorba aplikace

Navíc díky iterativnímu vývoji vidí výstupy i projektový tým a to dodává další motivaci. Kdyby se pořád programovalo a nebyl by žádný reálný výsledek, tak by to mělo negativní dopady na morálku týmu.

Možnosti počítačové podpory prací v jednotlivých etapách vývoje a provozu IS. • Plánování o Software pro kreslení „hadů“- MS Project, OpenProj • Návrh o Nástroje pro UML – Enterprise Architect, Power Designer, Jude, Rational Rose, Visio, Oracle Designer • Implementace o IDE – Visual Studio, NetBeans, Eclipse, Delphi atd. o Testování - Rational Robot, MS WebStress, Rational Performance Tester, (n)JUnit • Provoz a údržba o Zejména nástroje pro monitorování – JConsole, ITCAM for WebSphere, Nagios

Prostředky typu CASE. CASE je malovátko. Sice dokonalé (a patřičně drahé), ale vztah mezi metodikou a CASE je podobný vztahu mezi psaním a tužkou. K tomu, abych uměl, papír a tužka nestačí. CASE (Computer Aided Systems Engineering) v překladu znamená počítačem podporované softwarové inženýrství nebo-li vývoj software s využitím počítačové podpory. CASE nástroje primárně umožňují: -

Modelování IT systému pomocí diagramů Generování zdrojového kódu z modelu Zpětné vytvoření modelu podle již existujícího zdrojového kódu (reverse engineering) Synchronizaci modelu a zdrojového kódu Vytvoření dokumentace z modelu

CASE nástroje jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému, zajišťují sdílení zpracovaných fragmentů, správu vývoje, sledují konzistenci modelu systému, automatizují některé procesy, hlídají dodržování zvolené metodiky, některé umožňují řízení celého životního cyklu aplikací. Úspěch využití CASE nástrojů záleží mimo jiné na vybrané metodice. Přínosy CASE nástrojů: - Vyšší produktivita práce - Nižší chybovost - Snazší údržba a další vývoj výsledného produktu

- Kvalitnější dokumentace - Umožnění větší participace uživatelů na vývoji produktu

Co by měl splňovat ideální CASE nástroj (v závislosti na typu organizace, kde se využívá). Důležité vlastnosti a funkce CASE nástroje: - Konzistentní grafické ovládací prostředí (podle zásad tvorby GUI) – jednotný vzhled obrazovek, popisků, tlačítek, jednotné ovládání, použití symbolických ikon apod.¨ - Centrální databáze (repository) pro uchování informací o všech objektech IS (tímto způsobem se zaručí, že informace je použitelná v libovolném dalším kroku projektování) - Prostředky verifikace konzistentnosti dat a podpora normalizace dat · Textový editor pro popis jednotlivých objektů – pro účely technické a uživatelské dokumentace systému, možnost jejího přímého generování ze systému Možnost rychlého návrhu uživatelských obrazovek včetně simulace vstupů a výstupů (je vyžadováno pro prototyping) - Generátor zdrojových programů (pro případy častého znovupoužití daného kódu) - Export / import dat – pro práci s modely a dokumentací, které byly vytvořeny v jiných programech nebo jsou v jiných programech dále využívány a zpracovávány.

Riskovat nebo neriskovat zadlužení (a proč). Podle mě jsou CASE nástroje na tak vysoké úrovni (mnohdy i ty open-source), že nevidím příliš velký smysl pro zadlužení kvůli takovému nástroji. Jediná možnost by byla, kdyby se z analytické dokumentace dala generovat velká část systému (ať už programového kódu nebo návrhu obrazovek), to by velmi urychlilo vývoj.

Zavádění systému do užívaní (3.14) Okruh: RIS Č. ot.: 3.14 Zadání teorie: Úloha předpoklady:

Zadání úlohy: Předmět: Zdroje:

15.4.2005, v1.0

Zavádění systému do užívání Zavádění systému do užívání, způsoby realizace, jejich hodnocení, zkušební provoz, provozní a uživatelská dokumentace, školení odpovědných pracovníků. Jste asistentem vedoucího informatiky v podniku. Býváte kritizován(a) za to, že svým vlivem zdržujete zavádění částí IS poté, co jsou již hotové. Bývá Vám též vyčítáno zbytečné navyšování nákladů na vývoj IS, zejména s poukazem na to, že moderní systémy (zvláště ty od firmy Microsoft) jsou tak uživatelsky přítulné, že prakticky žádné zavádění do provozu nepožadují, přičemž náklady na jejich zavádění mnohdy převyšují jejich základní cenu, což bývá označováno za absurdní. Rozhodněte se, zda je vůbec možné ve specifických případech tuto etapu přeskočit? Jak svým kritikům odpovíte? IT210,583 Garant: Doc. Ing. Voříšek, Pour Zpracoval: Jaromír Mataj Voříšek : Strategie řízení IS a systémová integrace, Management press 1999 JE SOUČAST MDIS- 5. ZAVÁDĚNÍ (stránky 313-4) Materiály k IT 583 Teorie

1

Vymezení

Zavádění systému do provozu je různě komplikované a vyžaduje provedení řady činností. Jejich náplň je závislá na konkrétním projektu. Stručně lze shrnout do následujících kroků (fází): 1) plán etapy 2) tvorba školení a školení 3) tvorba dokumentace 4) příprava instalace a instalace 5) přejímací testy a testování 6) příprava na migraci systému 7) testovací provoz (sledování, vyhonocení a optimalizace) Kvalita jejich provedení ovlivní úspěch projektu. Zavedení může ovlivnit organizační strukturu, pracovní náplň zaměstnanců (organizačních jednotek, útvarů) a kompetence. Na zavedení systému je nutné se dobře připravit tj. vytvořit harmonogram, vytvořit školící materiály, seznámit zaměstnance s kroky, které budou následovat apod. Úzká místa, problémy apod., které budou spojeny se zavedením systému se objeví již v předchozích etapách životního cyklu projektu (analýza, návrh, implementace). Musí být proto dokumentovány již od začátku projektování (tj. vytvářet přehled CSF apod.), aby se zabránilo jejich opomenutí. Postup zavedení IS/IT by měl být řešen a upřesňován během jednotlivých etap projektu. V etapě implementace by měl být vytvořen plán zavedení. Činnosti, které jsou spojeny se zavedením IS/IT, je možné rozdělit do dvou skupina na: Činnosti, které je nutné provést před vlastním zavedením IS/IT Činnosti, které je nutné provést při zavedení IS/IT Zavedení je zahájeno, jakmile je systém uznán jako vhodný pro zavedení (byla dokončena implementace apod.). Zavedení je ukončeno, jakmile byl ověřen provoz v reálných podmínkách, byl proveden přechod na nový systém a byl zahájen provoz. Zaváděním projektu do užívání končí životní cyklus projektu a začíná životní cyklus systému. Zavádění projektu je cílovou etapou, která je často řešitelským týmem nedoceněna, přitom pro celkový úspěch projektu je důležité, jak bude přijat uživatelem a jak jej bude využívat. Zavádění projektu představuje "hodinu pravdy", která prověří výsledky projektování, ladění,... .Cílem etapy zavádění projektu do užívání je zkušební provoz, prověření funkcí, odstranění chyb a předání systému do rutinního provozu na základě protokolu o předání do užívání. Je dobré zavádět projekt do užívání ke kulatým datům (začátek čtvrtletí apod.).

1.1

Zavádění projektu do užívání představuje následují činnosti: Instalace a testování HW a komunikační sítě instalace ZSW a ASW, TASW distribuce knihoven systému na příslušné počítače akceptační test a zavádění - zkušební provoz systému - 1/6 -

Zavádění systému do užívaní (3.14)

15.4.2005, v1.0

vyhodnocení akceptačních dat - případné korektury systému zkompletování projekční, programové, provozní, uživatelské dokumentace školení uživatelů a provozního personálu v používání jim příslušných částí systému školení nových organizačních a pracovních předpisů vydání a uplatnění organizačních a pracovních předpisů, nových funkčních náplní přidělení uživatelských kmen a hesel jednotlivým uživatelům, přidělení přístupových práv k DZ a funkcím (transakcím) systému konverze DB a vytvoření počátečního stavu DZ ukončení starého způsobu zpracování podporování systému v průběhu kritické doby upřesnění postupu řešení reklamací během rutinního zpracování shrnutí nákladů tvorby IS podepsání smluv o užití informačních služeb s uživateli

Cílem etapy zavádění projektu je: zkušební provoz, prověření funkcí, odstranění chyb,předání systému do rutinního provozu na základě protokolu o předání do užívání

1.2

Předpoklady úspěšného přechodu na nový IS:

systém je plně dokončen po stránce projekční, programové a organizační (ověření programů na zkušebních i konkrétních datech, odsouhlasení postupů uživatelem: dokončení všech částí dokumentace, nedělat při zavádění programátorské zásahy) je vypracován plán přechodu na nový IS (organizační zajištění, řízení celé akce, finanční krytí, …) došlo k seznámení všech účastníků se systémem, jejich vyškolení, byl vypracován plán a realizovaly se všechny druhy školení (příprava dat, využívání výsledků) byla zajištěna organizační příprava ve vlastním výpočetním středisku (média, kapacity, strojový čas, ...) je zvolena vhodná metoda a taktika přechodu na nový IS

1.3

Okolnosti ovlivňující volbu způsobu přechodu

doba trvání, která je pro přechod vymezena rozsah prováděného systému použití typového SW nebo převážně uživatelských programů závislost na starém systému zpracování dat míra rizika, kterou chce nebo může uživatel i řešitel podstoupit zkušenosti na straně řešitelů i uživatelů spolehlivost technického systému u úloh s vysokou periodicitou nutno volit opatrný postup, aby doba mezi jednotlivými zpracováními byla dostatečná pro odstranění nepředvídaných potíží psychologická hlediska o uživatel je příliš konzervativní o jedná se o zavedení 1. úlohy - uživatel se musí přesvědčit o výhodnosti o jde o choulostivé úlohy (výpočet mezd), kde kritikem jsou všichni pracovníci

2

Činnosti, které je nutné provést před vlastním zavedením IS/IT

Plán zavedení, vytvoření potřebných materiálů, testování aplikací, určení materiálů, navržení testu akceptace, nastavení přístupových práv, plán zajištění podpory uživatelům (help desk) jsou provedeny v etapě implementace. Seznámení zaměstnanců zákaznického podniku se změnami by mělo probíhat průběžně během projektu. Cílem je zabránit odporu uživatelů, který může být způsoben nedostatečným informováním o změnách. Vytvoření plánu zavedení - Vytvoří se detailní přehled činností, které bude vyžadovat zavedení IS/IT, činnosti se rozplánují do jednotlivých dní (týdnů) a určí se zodpovědné osoby za tyto činnosti. Určí se zaměstnanci zákaznického podniku, kteří se budou na zavedení podílet. Plán zavedení musí zohlednit způsob realizace: spálené mosty současné používání starého a nového systému pilotní projekt (zavedení nejprve v jedné lokalitě a následné využití zkušeností v ostatních lokalitách) - 2/6 -


15.4.2005, v1.0

zavedení celého systému najednou postupné zavádění modulů, funkcí apod. Plán zavedení musí obsahovat způsob konverze z původního systému na nový a způsob konverze dat např. ve formě příručky pro konverze a zavádění. Vytvoření potřebných materiálů - Musí být vytvořena dokumentace programů a procedur, uživatelská dokumentace + provozní příručky. Musí být vytvořeny školící materiály (slide, příklady řešení úkolů, atd.) Testování aplikací - Před vlastním zavedením musí být jednotlivé části aplikace (procedury, funkce, moduly, úlohy, atd.) otestovány. Rozsah testování je volen podle optimálního poměru „cena/výkon“ tj. čím větší je rozsah testování, tím je nákladnější a časově náročnější. Nikdy nelze opravit všechny chyby v systému popř. opravení určitého malého procenta chyb je velmi nákladné. Určení nákladů na zavedení Navržení testu akceptace - Měl by být vytvořen speciální test, který má kontrolní funkci pro zákazníka a jehož výsledky jsou důležité pro zahájení provozu systému. Na jeho základě je systém certifikován a označen jako provozu schopný. Příprava na seznámení zaměstnanců zákaznického podniku s připravovanými změnami - U větších projektů je pravděpodobně optimální uspořádat setkání řešitelů s uživateli, při kterém jsou uživatelé seznámeni s plánem zavedení. Cílem je zákazníka uvolnit, odstranit pocit negativních důsledků, vyvolat pocit změny, podat jednotné informace o zavedení. Nastavení přístupových práv - Tato činnost může proběhnout před nebo při vlastním zavedení. Plán zajištění podpory uživatelům v prvních fázích provozu systému a vytvoření provozních pokynů plán, jak bude zajišťována podpora uživatelů při zavedení a počátečním období běhu IS. Určí se, kdo bude zajišťovat podporu. Vytvoří se provozní pokyny pro uživatele, jak postupovat v případě problémů se systémem apod.

3

Činnosti, které je nutné provést při zavedení IS/IT

4

Instalace technického a programového vybavení (instalaci HW a SW) Přenos a transformace dat stávajícího systému do nového systému Školení uživatelů a administrátorů Zajištění podpory uživatelů a administrátorům v prvních fázích Zkušební provoz, testování a odstranění zjištěných nedostatků Úplné zprovoznění nového systému a odstavení původního systému Provedení a vyhodnocení akceptačního testu Přidělení uživatelských oprávnění

Způsoby realizace zavedení a jejich hodnocení

Viz. text výše rozlišujeme realizaci podle toho, zda existuje návrat do původního stavu: Spálené mosty - Podle plánu může proběhnout ze dne na den odstavení původního systému a zprovoznění nového systému. U velkých projektů je tento přístup z počátku málo nákladný, ale velmi riskantní. Výhody: - okamžité zavedení nového systému - snížení nákladů (především oproti duplicitnímu zpracování) - uživatelé nemají možnost se vrátit ke starému způsobu práce - není třeba zajistit na přechodnou dobu dodatečné kapacity u uživatele - opuštění staré filosofie práce Nevýhody: - rizikový postup, využitelný tam, kde jsou značné zkušenosti řešitelů - nutná dokonalá příprava, která vede k prodloužení etapy ověřování programů Současné používání starého a nového systému - Po určité období, jakmile je nový systém akceptován, certifikován apod., je odstaven původní systém. Oba systémy nejprve běží současně. To klade vyšší nároky na uživatele. Tento přístup umožňuje zavést nový systém, jakmile jsou nalezeny a odstraněny jeho chyby. Tento přístup je zpočátku nákladnější, ale méně rizikový. Je vhodný tam, kde nový automatizovaný systém dostává po obsahově zcela jiné výstupy než původní systém. S ohledem na značné náklady je vhodný tam, kde je možné porovnávat výsledky nového systému se starým, kde jde o oblast mimořádné důležitosti pro život organizace Výhody: - je bezpečný - dává uživateli čas na zvládnutí metod práce a umožňuje realizovat netradiční návaznosti nového zpracování na staré - je vhodný u prvních aplikací a tam, kde jsou malé zkušenosti řešitelů a uživatelů Nevýhody: - vysoké náklady (vše 2x dražší) - 3/6 -


15.4.2005, v1.0

- prodlužuje se doba zavedení - u uživatele se musí dodatečně zvýšit stav pracovníků - je nutné hlídat, aby se uživatel skutečně snažil přejít na nový systém Přechod po etapách - využívá se tam, kde jde o rozsáhlý problém nebo se má jednoduchá aplikace zavést v rozsáhlém terénu a jiným způsobem by to bylo těžko zvládnutelné Výhody: - umožňuje řešit rozsáhlé problémy - zmenšuje rizika - umožňuje postupně získávat zkušenosti na straně uživatele - umožňuje realizovat i netradiční postup a formy práce Nevýhody: - velice náročný po stránce dlouhodobého dohledu nad pracemi - obtížně se při zavádění po etapách zajišťují vazby na neautomatizované okolí (např. promítání změn do organizačního řádu) Zpracování historie - je velmi blízká duplicitnímu zpracování. Nutné je však vytvořit některé další předpoklady, které předchozí metody nevyžadují. Tento způsob se využívá, když se přechod uskutečňuje v průběhu určitého období a pro správnou a úplnou funkcí algoritmů je nutné mít data a vypočtené hodnoty za celé období. Metoda umožňuje prověřit správnou funkcí všech programů a navíc umožní vytvořit úplný soubor, ve kterém bude možné zajistit i roční zpracování. Velmi náročná je však organizační příprava. Musí totiž být k dispozici za celé předchozí období všechna vstupní data. Všechny předpisy a pracovní postupy musí být připraveny ještě před začátkem období, které se má rekonstruovat. Výhody: - vysoká míra ověření správné fce programů, - efekt kontroly větší než při duplicitním zpracování, - nižší náklady a později podstatné zkrácení doby zavádění (možný okamžitý přechod na nový systém), - uživatel nemá možnost užívat starých metod. Nevýhody: - náročná organizační příprava, - nutné zkušenosti řešitelů. Podle toho, zda je systém zaveden najednou nebo po částech, rozlišujeme: pilotní projekt - Systém se zavede nejprve pouze v jedné lokalitě a celý postup se vyhodnotí. Zkušenosti se využijí při zavedení v ostatních lokalitách. Optimální je vybrat lokalitu, ve které jsou uživatelé ke změnám nejlépe naladěni (optimističtí, podporují změny, apod.) Zavedení celého systému najednou - Celý systém je zaveden najednou tj. nainstalují se a zprovozní všechny aplikace, moduly, funkce, atd. Postupné zavádění modulů, funkcí - Postupně se zavádějí jednotlivé aplikace, moduly, funkce, atd. Pohled na zavádění projektů z hlediska dat necháme doběhnout postaru, co dobíhá a DB naplňujeme novými údaji postupně (rozpracovanou zakázku zpracujeme postaru, nové zakázky vkládám do DB) jednorázově zaplním DB všemi daty -je velmi náročné kompromis - s uživatelem se dohodneme, co se musí do DB bezpodmínečně uložit a co lze ještě nechat doběhnout postaru

5

Hodnocení kvality zavedení IS

Pro hodnocení zavedení IS je důležitý výstup z akceptačního řízení tzn. akceptační protokol. Placení za projekt by mělo být vázáno na výsledky v akceptačního řízení. Hodnocení může být provedeno podle definovaných metrik. Metriky musí být definovány před zavedením a jejich navržení není snadné. Mohou být hodnoceny např. dodržení harmonogramu, nákladů, kvalita produktu, kvalita školení, podpora při zavedení systému, přechod na nový systém, provedení akceptačního testu, atd.

6

Zkušební provoz

Cílem zkušebního provozu je ověřit funkčnost systému v reálném prostředí a oprava chyb. Uživatelé při prvním používání systému určí chyby a systém připomínkují. Zkušební provoz je prováděn na ostrých datech. Je proveden až po testování celého systému. měl by být proveden na zkušebních datech, pak teprve na skutečných důležitou roli hraje oponentský posudek (jako v celém životním cyklu projektu) -> musí posoudit, zda navržený systém splnil uživatelské požadavky měl by být vypracován systém přejímacích kritérií Některé se ukážou až při zpracování na ostrých datech! - 4/6 -


7 7.1

15.4.2005, v1.0

Provozní a uživatelská dokumentace Provozní dokumentace

Pokyny pro provozní pracovníky (operátory, správce aplikace, pracovníky informačního střediska) - pro vedení provozu - časový harmonogram rutinního zpracování projektu - bilance potřeb strojového času a ostatních zdrojů systému - pro operátory - schéma návaznosti jednotlivých programů - řešení chybových a havarijních situací - dokumentace zpráv pro operátora - připravujeme návod na přípravu vstupních dat včetně obsluhy terminálů - pro vstupně výstupní kontrolu a přípravu dat - časový harmonogram rutinního zpracování projektu - pokyny pro přejímání úloh -jejich příprava pro zpracování na počítači - pokyny pro kontrolu výsledků -jejich předání uživateli - pokyny v případě reklamací

7.2

Uživatelská dokumentace - helpy k datovým obrazovkám - helpy k funkcím = uživatelská příručka - požadované vlastnosti – přehlednost, aktuálnost, kvantita, dostupnost, vhodná forma - obsah uživatelské příručky - organizační předpis - kdo zodpovídá za provádění jednotlivých funkcí systému - závazné sekvence jednotlivých činností - způsob řešení mimořádných stavů a reklamací

7.3

Projekční a programová dokumentace

Dokumentace jednotlivých programů, souborů atd. Slouží tvůrcům systému pro vzájemnou komunikaci, pro údržbu a rozvoj systému.

8

Školení odpovědných pracovníků

Na začátku etapy zavedení popř. před jejím začátkem musí proběhnou školení uživatelů a administrátorů. Důležité je vhodně motivovat a naladit uživatele pro změny, připravit kvalitní dokumentaci (uživatelská, příručky). Je vhodné zvolit příjemné prostředí, připravit podrobnou osnovu, opakovat procvičovanou látku. zásady: závislost na charakteru projektu posouzení úrovně dosavadních znalostí uživatelů o výpočetní technice spolupracovat s nadřízeným uživatele a vytvořit podmínky zainteresovanosti uživatelů na získání potřebných poznatků a zkušeností seznamovat uživatele s problematikou postupně od nejobecnějšího pohledu, prohlubovat jeho znalosti, získat je pro spolupráci vypracovat hodnotící kritéria pro posouzení do jaké míry uživatel školení pochopil a akceptoval školení by mělo vždy předcházet důležité je psychologické klima Příprava uživatelů by neměla mít podobu jednorázových kurzů, ale měla by mít permanentní charakter Vedoucí pracovník by měl znát minimálně způsob komunikace se systémem Širší znalosti by měli mít lidé pracující se systémem většinu doby Dvoustupňové řešení školení 1) vyškolení vybraných pracovníků (splňují určité předpoklady) 2) tito pracovníci školí další pracovníky Cílem školení administrátorů je naučit: Odstraňování drobnějších chyb a nedodělků Správu přístupových práv Údržbu HW Správu databází a údržbu dat Školení nově příchozích pracovníků Zálohování a obnovu dat Řešení obvyklých požadavků koncových uživatelů - 5/6 -


15.4.2005, v1.0

Cílem školení koncových uživatelů je naučit (popř. seznámit s): Jakým způsobem je možné řešit jednotlivé úkoly Jaký je význam jednotlivých funkcí, aplikací, atd. Jak postupovat v případě problémů, kdo je zodpovědný za systém Jaká je základní struktura systému. Při konkrétní přípravě na určitý systém je nutné provádět přípravu komplexně. Není přijatelné, aby se zaškolení zúčastnilo pouze několik málo vybraných jedinců. Zavedení výpočetní techniky zasáhne většinu pracovníků organizace. Na druhé straně je však nezbytná určitá účelovost a specializace. Není možné, aby úplně stejné znalosti a příprava se předpokládali u ředitele, náměstka a referenta. Vedoucí pracovník by měl znát minimálně způsob komunikace se systémem, aby byl schopen ho sám využívat a měl přehled o práci svých podřízených. Širší znalosti týkající se práce s výpočetní technikou (reakce na havarijní situace, schopnost malých technických úprav) by měli mít především lidé, kteří pracují se systémem většinu pracovní doby. Úroveň školení je též rozdílná podle fáze životního cyklu, v kterém se uživatel nachází. Např. referent, který pracuje s počítačem již 5 let, při zavádění nového programového produktu nemusí procházet základním kurzem, protože dané znalosti již získal dříve. Příprava uživatelů by také neměla mít podobu jednorázových kurzů, ale měla by mít permanentní charakter. V souvislosti se školením uživatelů je vhodné rozlišit dva základní případy: 1) Projekt dávkového charakteru - uživatel komunikuje přes papírová média, není přímo přítomen technologickému procesu ZD. Školení má v tomto případě 3 fáze: a) seznámení s VT vůbec (pokud má uživatel minimální nebo žádné zkušenosti s VT), charakteristika možností a omezení způsobů ZD, b) seznámení s uživatelskou příručkou - nejdříve obecně, - později podrobně a prakticky odzkoušet znalosti, c) po určité době provozu - zhodnocení provozu,připomínky, náměty na rozvoj,... . 2) Kombinace dávkového a interaktivního zpracování, interaktivní aplikace a) seznámení s interaktivním způsobem práce - výhody, omezení, jak je aplikace začleněna do systému, základní logika zpracování, b) výuka práce s terminálem, možnosti použití fcí HELP, c) seznámení s uživatelskou příručkou (nejprve obecně, pak podrobně), d) zhodnocení provozu, úzká místa, náměty uživatele na další rozvoj systému.

Praktická úloha

Rozhodněte se, zda je vůbec možné ve specifických případech tuto etapu přeskočit? Pokud vytvářím nový IS, který má někde v reálu fungovat, tak vždy musím systém uvést do provozu a do užívání (i sebe menší změnu). Takže si neumím představit tuto etapu vynechat jako celek. Snad jen u neúspěšných projektů…, kde už ani není žádné užívání a provoz. Průběhu zavádění IS do užívání se vykonává celá řada dílčích činností z nichž lze podle specifik projektu některé vynechat (např. v nové firmě nebudu mít problém s konverzí předchozích dat a systémů).

Jak svým kritikům odpovíte? I sebe menší změna systému (např. verze office) se minimálně musí naplánovat tak aby uživatel zaznamenal co nejmenší újmu a byl připraven na nový produkt. Dále by mělo proběhnout testování s ostatními aplikacemi podniku které integrují některé funkčnosti stávajícího SW. A samozřejmě musí proběhnout samotná instalace, která si v případě stovky uživatelů vyžádá své. Samozřejmě, že vše má své limity a záleží na konkrétním produktu, počtu uživatelů, míře integrace aplikací,… Osobně jsem zastánce extrémního programování pod heslo „Tested on Human“ ;-) a zavádění systému příliš neprotahovat. Myslím, že v určité míře (především u měkkých systémů) je efektivnější uvést do provozu produkt, který je otestován např. z 90% než čekat než vše bude 100%, protože se pak může stát, že nebude stále něco OK a po čase může dojít ke změnám, a tak produkt bude stále ve fázi testování. Další poznámky k otázce Otázka úzce souvisí s MDIS a životním cyklem IS, takže případně lze využít i dalších znalostí z těchto oblastí.

- 6/6 -

3.14

Zavádění systému do užívání

Zavádění systému do užívání, způsoby realizace, jejich hodnocení, zkušební provoz, provozní a uživatelská dokumentace, školení odpovědných pracovníků. Úloha - předpoklady: Jste asistentem vedoucího informatiky v podniku. Býváte kritizován(a) za to, že svým vlivem zdržujete zavádění částí IS poté, co jsou již hotové. Bývá Vám též vyčítáno zbytečné navyšování nákladů na vývoj IS, zejména s poukazem na to, že moderní systémy (zvláště ty od firmy Microsoft) jsou tak uživatelsky přítulné, že prakticky žádné zavádění do provozu nepožadují, přičemž náklady na jejich zavádění mnohdy převyšují jejich základní cenu, což bývá označováno za absurdní. Zadání:

Rozhodněte se, zda je vůbec možné ve specifických případech tuto etapu přeskočit? Jak svým kritikům odpovíte?

Zavádění systému do užívání, způsoby realizace. Zavedení nového IS je ve firmě vždy problémem. Proto pro úspěšnou realizaci tohoto zásadního kroku je nutná volba vhodného způsobu zavedení IS do rutinního provozu. Tato volba závisí od mnoha faktorů jako např.: -

Typ a funkce předchozího IS, objem změn a způsobu ovládání IS, připravenost jednotlivých pracovišť a pracovníků na zavedení IS, a mnohé další.

Postupů pro zavádění IS do rutinního provozu je veliké množství. Liší se od sebe rychlostí, zaváděcí metodou apod. Souběžné zavádění Informační systém je zaveden souběžně na všech pracovištích najednou. Tento postup je vhodné použít při zavádění jednodušších IS, které nevyžadují náběhovou fázi zavádění (složitá školení, konverzi dat z předchozích IS).

Pilotní zavádění Informační systém se zavede na jednom pracovišti, které je na tuto činnost připraveno. Po zavedení probíhá ověřovací provoz a posléze zde probíhá zacvičování pracovníků ostatních pracovišť. Tento způsob je vhodný pro zavádění kvalitativně odlišných IS, které vyžadují rozsáhlé testování nového IS v provozních podmínkách. Toto pilotní zavádění umožňuje postupnou transformaci dat z předchozích IS. V závěru pilotní fáze dochází k zavádění IS na ostatní pracoviště, které jsou již připravena.

Postupné zavádění Zavádění IS na jednotlivá pracoviště probíhá postupně, bez pilotní fáze. Rychlost zavádění je závislá na připravenosti jednotlivých pracovišť a na složitosti IS. Tento způsob je vhodnsý pro takový systém,

u kterého není nutné provozní ověřování (komerčně dodávaný IS, IS převzatý z podobně fungujících pracovišť).

Nárazová strategie zavádění Strategie zavádění, kde najednou ukončíme činnost jednoho IS a po nezbytně nutné pauze spustíme nový informační systém. Tento postup je riskantní, používá se tak, kde souběh IS není možný.

V praxi však nastává nutnost kombinovat jednotlivé postupy. Nejčastější je kombinace postupu nárazového a postupného. Plán zavedení by měl obsahovat: -

vytvoření potřebných materiálů – dokumentace, příručky a školící materiály testování aplikací – otestování s ohledem na poměr cena/výkon výpočet nákladů na zavedení navržení testu akceptace – na základě výsledku testu systém zákazník akceptuje a zacvaká příprava cílových uživatelů na zaváděné změny nastavení přístupových práv sestavení plánu podpory uživatelů jak v počáteční fázi, tak v obyčejném provozu

Hodnocení kvality zavedení IS Pro hodnocení zavedení IS je důležitý výstup z akceptačního řízení tzn. akceptační protokol. Placení za projekt by mělo být vázáno na výsledky v akceptačního řízení. Hodnocení může být provedeno podle definovaných metrik. Metriky musí být definovány před zavedením a jejich navržení není snadné. Mohou být hodnoceny např. dodržení harmonogramu, nákladů, kvalita produktu, kvalita školení, podpora při zavedení systému, přechod na nový systém, provedení akceptačního testu, atd. Zkušební provoz Cílem zkušebního provozu je ověřit funkčnost systému v reálném prostředí a oprava chyb. Uživatelé při prvním používání systému určí chyby a systém připomínkují. Zkušební provoz je prováděn na ostrých datech. Je proveden až po testování celého systému. měl by být proveden na zkušebních datech, pak teprve na skutečných důležitou roli hraje oponentský posudek (jako v celém životním cyklu projektu) -> musí posoudit, zda navržený systém splnil uživatelské požadavky měl by být vypracován systém přejímacích kritérií Provozní dokumentace Pokyny pro provozní pracovníky (operátory, správce aplikace, pracovníky informačního střediska) - pro vedení provozu - časový harmonogram rutinního zpracování projektu - bilance potřeb strojového času a ostatních zdrojů systému - pro operátory - schéma návaznosti jednotlivých programů - řešení chybových a havarijních situací - dokumentace zpráv pro operátora

- připravujeme návod na přípravu vstupních dat včetně obsluhy terminálů - pro vstupně výstupní kontrolu a přípravu dat - časový harmonogram rutinního zpracování projektu - pokyny pro přejímání úloh -jejich příprava pro zpracování na počítači - pokyny pro kontrolu výsledků -jejich předání uživateli - pokyny v případě reklamací Uživatelská dokumentace - helpy k datovým obrazovkám - helpy k funkcím = uživatelská příručka - požadované vlastnosti – přehlednost, aktuálnost, kvantita, dostupnost, vhodná forma - obsah uživatelské příručky - organizační předpis - kdo zodpovídá za provádění jednotlivých funkcí systému - závazné sekvence jednotlivých činností - způsob řešení mimořádných stavů a reklamací Projekční a programová dokumentace Dokumentace jednotlivých programů, souborů atd. Slouží komunikaci, pro údržbu a rozvoj systému.

tvůrcům systému pro vzájemnou

Školení odpovědných pracovníků Dvoustupňové řešení školení 1) vyškolení vybraných pracovníků (splňují určité předpoklady) 2) tito pracovníci školí další pracovníky Cílem školení koncových uživatelů je naučit (popř. seznámit s):

Jakým způsobem je možné řešit jednotlivé úkoly Jaký je význam jednotlivých funkcí, aplikací, atd. Jak postupovat v případě problémů, kdo je zodpovědný za systém Jaká je základní struktura systému.

„Jste asistentem vedoucího informatiky v podniku. Býváte kritizován(a) za to, že svým vlivem zdržujete zavádění částí IS poté, co jsou již hotové. Bývá Vám též vyčítáno zbytečné navyšování nákladů na vývoj IS, zejména s poukazem na to, že moderní systémy (zvláště ty od firmy Microsoft) jsou tak uživatelsky přítulné, že prakticky žádné zavádění do provozu nepožadují, přičemž náklady na jejich zavádění mnohdy převyšují jejich základní cenu, což bývá označováno za absurdní.“

Rozhodněte se, zda je vůbec možné ve specifických případech tuto etapu přeskočit? Pokud vytvářím nový IS, který má někde v reálu fungovat, tak vždy musím systém uvést do provozu a do užívání (i sebe menší změnu). Takže si neumím představit tuto etapu vynechat jako celek. Snad jen u neúspěšných projektů…, kde už ani není žádné užívání a provoz. Průběhu zavádění IS do užívání se vykonává celá řada dílčích činností z nichž lze podle specifik projektu některé vynechat (např. v nové firmě nebudu mít problém s konverzí předchozích dat a systémů). Jak svým kritikům odpovíte? I sebe menší změna systému (např. verze office) se minimálně musí naplánovat tak aby uživatel zaznamenal co nejmenší újmu a byl připraven na nový produkt. Dále by mělo proběhnout testování s ostatními aplikacemi podniku které integrují některé funkčnosti stávajícího SW. A samozřejmě musí

proběhnout samotná instalace, která si v případě stovky uživatelů vyžádá své. Samozřejmě, že vše má své limity a záleží na konkrétním produktu, počtu uživatelů, míře integrace aplikací,… Osobně jsem zastánce extrémního programování pod heslo „Tested on Human“ ;-) a zavádění systému příliš neprotahovat. Myslím, že v určité míře (především u měkkých systémů) je efektivnější uvést do provozu produkt, který je otestován např. z 90% než čekat než vše bude 100%, protože se pak může stát, že nebude stále něco OK a po čase může dojít ke změnám, a tak produkt bude stále ve fázi testování.

Údržba a rozvoj informačního systému (3.15) Okruh: Č. ot.:

RIS 3.15

30.3.2005, v1.0

Údržba a rozvoj informačního systému

Zadání teorie:

Co je změna, důvody a dopady změn. Promítání změn do systému, dlouhodobá údržba systému, odpovědnost za údržbu, předpoklady údržby systémů, životnost systému, příprava inovace systému, autorský dozor.

Ú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í úlohy:

Rozhodněte se, kde se stala chyba, stala-li se vůbec. Co s tím uděláte? IT_583 Garant: Doc. Ing. Voříšek Zpracoval: Jan Novák http://nb.vse.cz/~vorisek Voříšek: Strategické řízení IS a systémové integrace, Management Press 1999.

Předmět: Zdroje:

Teorie

Údržba a rozvoj informačního systému 1

Změna IS, důvody a dopady změn

1.1

1.2

Změna IS

1.3.1

proces, kdy dochází ke změně funkčnosti IS

změnou není, pokud IS nefunguje, jak má – jde pouze o problém

vždy je potřeba vycházet ze stávajícího stavu

zohlednit, zda podnik provozuje IS zcela sám, outsourcuje určité části (např. jen SW) nebo outsourcuje celý provoz

Důvody změny

Jsou to

1.3

vnější a vnitřní požadavky nebo podněty Legislativa Partneři Dodavatele Konkurence Trh Zákazníci Rozvoj IT Bezpečnost Problémy(Helpdesk) …

Typy změn 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)

- 1/4 -

Údržba a rozvoj informačního systému (3.15)

1.3.2

1.3.3

1.4

30.3.2005, v1.0

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)

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)

teleworking až vytváření virtuální organizace

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: rutinní uživatelské změny změny v aplikační funkcionalitě/ve službách změny v infrastruktuře

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

Změny v aplikační funkcionalitě (body se prolínají)

1.5

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ě)

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 - 2/4 -


2

3

30.3.2005, v1.0

úč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

Rostoucí komplexita a náročnost údržby IS

zastaralé technologie se nevyhazují, zůstávají v podniku a běží vedle nových

fúze podniků/reorganizace/aliance – také propojování IS

neodhadnutelné chování, neodhadnutelné chyby (nemám šanci zjistit, moc nákladné)

snaha omezit komplexitu – obrovské výdaje na integraci

rozsáhlé provozy nutno sofistikovaně řídit, jinak akceleruje růst nákladů na udržení provozu (integrační náklady); jde o problém řízení, nikoliv technologií

Údržba (provoz) IS

3.1

údržba úzce souvisí s provozem IS/IT a také s jeho řízením (proto nelze přesně oddělit tyto složky a jsou společně zobrazovány na ilustračních obrázcích)

Řízení aktiv (Asset Management)

nepatří celé přímo do informatiky, v kompetenci IT jsou pouze technické evidence

jde o evidenci zařízení, inventarizaci, sledování životního cyklu zařízení, sledování nákladů

vazby na ICT monitoring, řízení konfigurací, nákupy, řízení uživatelských oprávnění, HelpDesk

- 3/4 -


4

30.3.2005, v1.0

Odpovědnost za provoz IS

A

Strategi e Rozvoj organizace IS/IT

Ekonomika

Personální Systémové zdroje vlastnosti

Datové zdroje

B

C Zadávání a koordinace projektů

Provozování projektů řízení sítí a provozu a dalších informačních služeb

Vývoj projektů

5

Řízení informačních technologií

A. Strategické plánování a řízení IS/IT B. Taktické plánování a řízení IS/IT C. Provozní a operativní řízení IS/IT

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. Praktická úloha Chyba se stala a může mít dva důvody. Za prvé, zastaralost IS, a to nejen fyzickou, ale i morální. Pak záleží na konkrétním systému, je-li jeho stav opravdu tak kritický, že je nutné řešit tyto nedostatky velmi výraznými změnami např. v infrastruktuře. Tento druh změn ale bývá poměrně nákladný, proto je rozumné zvážit, zda se nevyplatí pořídit rovnou celý nový systém. Pokud situace ještě není tak kritická, stačí postupně inovovat a provádět řadu „menších změn“ nebo korekcí a tím přizpůsobovat systém aktuálním požadavkům. Při běžné údržbě systému se realizací změn může předcházet řadě problémům - změna jako prevence. Ale důvod rostoucích nákladů nemusí být jen technologický, může jít také o problém řízení. Rozsáhlé provozy je nutno sofistikovaně řídit, jinak akceleruje růst nákladů na udržení provozu... Další poznámky k otázce - 4/4 -

3.16 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. Organizace projektu Role • • •

Investor (sponzor, zadavatel) Uživatel Dodavatel (řešitel)

Projektový tým • Řídící komise – zodpovědnost za dosažení cílů ◦ Zástupce sponzora ▪ řídí schůze kontrolním komise ▪ schvaluje vedoucího projektu (na návrh koordinátora projektů) a vedoucího etapy (na návrh vedoucího projektu) ▪ rozhoduje o základních změnách ▪ schvaluje rozpočet ▪ schvaluje dokončení, hodnocení, uzavření etapy a projektu

•

◦ Zástupce uživatele ▪ vypracovává podklady o průběhu a dokončení projektu ▪ změny z pohledu uživatele ▪ podílí se na akceptačním řízení ▪ navrhuje vzájemné přizpůsobení procesů, organizačního zajištění a IS ◦ Zástupce dodavatele ▪ zajišťuje dodržování povinností dodavatele ▪ zastupuje zájmy dodavatele ▪ změny z pohledu dodavatele ▪ informování koordinátora projektů o problémech Vedoucí projektu – zodpovědný za realizaci plánu ◦ vytváří plán projektu

◦ navrhuje a řídí práci vedoucích etap ◦ určuje odpovědnosti, přiděluje a kontroluje úkoly ◦ řídí a analyzuje postup projektu, věcně i finančně ◦ sleduje kvalitu a vnější vlivy ◦ zajišťuje změny plánu ve styku se zástupcem sponzora a vedoucími týmů • Vedoucí etapy ◦ vytváří plán etapy ◦ určuje odpovědnosti, přiděluje a kontroluje úkoly ◦ řídí a analyzuje postup etapy ◦ sleduje kvalitu a vnější vlivy ◦ připravuje požadavky na změny ◦ zajišťuje potřebnou kvalifikací týmu ◦ informuje vedoucího projektu • Vedoucí týmu ◦ informuje členy týmu o jejich úkolech ◦ organizuje a řídí práci týmu ◦ komunikuje s vedoucími etap a projektu • Správce metodiky • Koordinátor projektů • Sekretář projektu ◦ administrativa při vedení projektu ◦ udržuje dokumentaci ◦ podle vedoucího připravuje podklady pro řídící komisi • Tým kvality ◦ členy schvaluje řídící komise ◦ tvoří plán kontroly kvality ◦ zodpovědnost za průběžnou kontrolu výstupů ◦ před milníky kontroluje odevzdané výstupy ◦ zpráva vedoucímu projektu a řídící komisi • Tým akceptace ◦ členy schvaluje řídící komise ◦ zástupci všech tří rolí ◦ plán akceptace ◦ zodpovědnost za akceptační řízení výstupů ◦ zpráva vedoucímu projektu a řídící komisi • Tým řízení změn ◦ členy schvaluje řídící komise ◦ zástupci všech tří rolí ◦ jednání při změně ◦ výsledkem je standardizovaný dokument „projektová změna“, který vedoucí projektu zapracuje do plánu Znalosti a zkušenosti členů Koordinace projektů Hlavní koordinátor projektů • zodpovídá za soulad schvalovaných a řešených projektů s inf. strategií • řídí tým pro koordinaci projektů • posuzuje projektové záměry a rozhoduje o předání zástupci sponzora • zodpovědnost za správu portfolia projektů

Technický koordinátor • definuje technické standardy • dohlíží, aby byly správně aplikovány • dohlíží, aby technické řešení odpovídalo stanovenému • schvaluje hodnocení etap • schvaluje uzavření projektu Správce metodiky řízení a koordinace projektů • zapracovává poznatky do standardů • podílí se na přípravě projektového týmu, logiky postupu projektu • spravuje znalosti a vzdělávání Plánování Plán projektu musí obsahovat plán • struktura prací (WBS) • Výstupy • Organizace projektu ◦ role a jejich obsazení ◦ komunikační procedury a pravidla ◦ součinnost jednotlivých subjektů • Harmonogram • Plán potřeby zdrojů • Milníky (místo, kdy se rozhoduje o dalším postupu) • Rizika • Rezervy (přijatelné odchylky) • Metriky a způsob jejich měření • rozpočet • procedury zajištění kvality Odhad pracnosti • kvalifikovaný odhad, analogické projekty, znalostní databáze organizace, speciální techniky • přesnost: řádová (na začátku), předběžná (po úvodní studii), realistická (-5%/+10%) • techniky ◦ Work Breakdown Structure (WBS) – dekompozice na detailní činnosti, hierarchické ◦ Delfská věštírna – expertní odhad, řádová přesnost, na úrovni celého projektu, skupina expertů – řeknou kolik a když jsou odchylky v rozmezí, tak průměr, jinak diskutují a odhadují znovu. ◦ Analogie – předběžná přesnost, podobný projekt (počet úloh, agend, rolí,...) ◦ Funkční body – realistická přesnost, po detailním návrhu; rozdělení funkcí na: vstupní

transakce, výstupní, dotazy, externí vazby a logické datové soubory → rozdělí se ještě podle složitosti →ohodnoceno počtem bodů → upraveno o prostředí → přepočet na člověkodny ◦ Objektové – druhá až třetí přesnost, podle pracnosti výstupů (analogií z minulosti) Zobrazení - Ganttův diagram, sítový graf (pro CPM a PERT – uzlově nebo hranově orientován) PERT (Program Evaluation and Review Techniques) • očekávaná doba = (optimistický+4xrealistický+pesimistický)/6 • směrodatná odchylka = (pesimistický-optimistický)/6 CPM (Critical Path Method) – pro určení které činnosti jsou kritické, postupné načítání doby trvání pro jednotlivé větve, při spojování větví vyšší číslo. Vztahy mezi činnostmi – finish-to-start (B nezačne než A skončí), finish-to-finish, start-to-start, start-to-finish Omezení činností- ASAP, as late as possible, finish no earlier than, must finish on, start no later than, a další kombinace CC (Critical Chain) – aplikace TOC v projektech. Založeno na myšlence, že úzkým místem projektu je kritický řetěz (nejdelší cesta) a té se musí všechno přizpůsobit. • odhady pracnosti již obsahují rezervu, kterou lze oddělit a sloučit na konci celého projektu nebo při napojování větví na kritický řetěz • eliminuje multitasking • z tlačeného systému na tažný • drum buffer rope – tempo a rychlost celku udává nejpomalejší a je proto před ním vytvořena rezerva, aby v případě zastavení celku se nejpomalejší nemusel zastavovat • Postup 1. klasické plánování, identifikace kritické cesty 2. odstranění časových rezerv (všechny časy 50%) 3. přeplánování na as-late-as-possible 4. odstranění konfliktů zdrojů 5. určení kritického řetězce 6. ochrana CC přípojnými nárazníky (z rezerv) 7. nárazník projektu (z rezerv) Programy jsou definované v informační strategii a obsahují projekty pro jejich naplnění. Nástroje pro podporu:Oracle EPM, MS Project, Primavera, MS Sharepoint, Artemis (AISC),... Standardy a metodiky • PRINCE (PRojects IN Controlled Environemnts) od CCTA, public domain • ISO hlavně 10006 a 15188 (project management guidelines) a pro živ. cyklus SW 16326 • Project Management Institute - PMBOK • COBIT (spíš ICT obecně, ale ve skriptech u projektů je) • KIT VŠE a ITG – MMDIS ŘIP Úloha - předpoklady: Pracujete na projektu vývoje IS a připravujete jeho plán. Uvažujete právě o termínu ukončení projektu, přičemž znáte termín předání vyvinutého systému. Zadání: Rozhodněte se, zda projekt skončí předáním vyvinutého systému, nebo ne. Proč? (To pravděpodobně závisí na smlouvě a zákazníkovi, ale budiž.) NE. Záleží mi na spokojenosti zákazníka, a proto budu spolupracovat i na implementaci, případně ještě dělat úpravy, školit uživatele, aby mohl zákazník plně využít potenciálu IS. Navíc z toho budou dodatečné peníze, vytvořím si kontakty ve společnosti a zjistím, co bych zákazníkovi mohl prodat dalšího.

3.17 Řízení a dokumentace projektu

Principy a zásady řízení projektu, životní cyklus IS/ICT versus životní cyklus projektu vývoje IS/ICT, organizace projektu a odpovědnost, projektová dokumentace a její smysl. Specifika informatických projektů a jejich řízení. 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. Ú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? Pozor na rozlišení dokumentace systému a projektu. V zadání jsou obě. Projekt je řízená skupina činností vyvolaná za účelem dosažení předem určených cílů v daných termínech, ceně a s přidělenými zdroji. Charakteristické znaky • unikátnost • přesné určení cílů a výstupů • dané termíny • daná cena a omezené zdroje • interdisciplinární charakter Řídit je potřeba • integraci • rozsah • čas • náklady • kvalitu • lidské zdroje • komunikaci • rizika • obstarávání od dalších organizací Stádia • • • •

příprava plánování provedení ukončení

Řídící vs věcný přístup (řízení projektu – jednotlivá stádia – je ve všech projektech stejné, ale

věcná náplň se liší; např. zavádění IASW a TASW) Procesy: hlavní, řídící a podpůrné. Projekt je na podnět informační strategie, výsledků hodnocení podnikových procesů nebo uživatele. Projektová dokumentace Důvody • pomáhá řídit projekt, • formalizace, nepopiratelnost, • sjednocuje pohled na projekt, • je důležitá z důvodu zastupitelnosti, • slouží k eliminaci chyb, atd. Dokumenty v jednotlivých fázích • příprava → zadání → projektový záměr (ne vedoucí projektu, důvody, cíle, metriky a jejich cílové hodnoty, přínos, finanční ukazatele, předpoklady a omezení, kritické faktory ze SWOT, co nen9 předmětem, vazba na ostatní projekty, hlavní výstupy a metriky, etapy, odhad nákladů a zdrojů, vyjádření sponzora, uživatele, koordinátora) → pověřovací dekret → v ICT to může být úvodní studie (zadání a současná situace, požadavky na systém, koncepce, akceptační procedura a testování, plán vývoje) • plánování → plán projektu (viz 3.16) → plán etapy • provedení → zápis z jednání → předávací protokol → akceptační protokol (výstup, kritéria, připomínky, vyjádření, termín pro odstranění nedostatků) → deník projektu (činnost, problémy, komentáře) → projektová změna (popis, důvod, návrh na úpravu parametrů projektu) → zpráva z průběžného hodnocení etapy (stav činností, události, výhled plnění) → zpráva o čerpání zdrojů projektu (rozpočet, plánované, skutečné, zhodnocení etapy, členů, problémů, a výhled) → protokol o ukončení etapy (rekapitulace, zhodnocení, problémy, souhrn změn) → protokol o ukončení prací na projektu (zhodnocení výsledků, výhrady, odchylky, související dokumenty) • ukončení (analýza postupu, dosažených výsledků, čerpání zdrojů, vyhodnocení práce členů, zobecění zkušeností, hodnocení úspěšnosti) → závěrečná zpráva z projektu • dále smlouvy, metodické pokyny, návrhy řešení,zápisy z jednání apod. Nástroje pro podporu řízení • nižší třída - Ganttovy diagramy, publikování, šablony (Milestones Simplicity) • střední třída – i pro více projektů, Gantt, síťové diagramy, hledání kritické cesty, sledování průběhu, alokace zdrojů, vytváření zpráv,… (MS Project, Artemis, PlanView, Primavera) • vyšší třída – rozptýlené pracovní skupiny, souhrnné pohledy na projekt z různých hledisek organizace, často přes web (MS Enterprise Project Management Solution, VPMi)

Opatření pro zkvalitnění projektové dokumentace • metodická – použití šablon, UML • organizační – je jmenován sekretář projektu • programová • technická – sdílení, projektové weby Specifika informatických projektů • ICT je čím dál tím komplexnější a zasahuje do více oblastí • doba využití SW se zkrátila • potřeba rychlejšího uvedení na trh Zásady • projekt v souladu se strategií, architekturou, podnikovou kulturou, … Modely životního cyklu projektu ICT – nutnost opakovat projekty • vodopádový – nejstarší; jedna etapa po ukončení předchozí, optimální pořadí etap; dodavatel hradí až po nasazení do provozu • spirálový – dodavatel vytvoří na vlastní náklady prototyp IS v určité oblasti, který nabízí; cyklus specifikace požadavků, analýzy rizik, vývoje a ověření, plánování postupu, avšak s rostoucími náklady (proto spirálový) • síťový – metamodel, který je aplikován a následně zpětně upraven (učení se) Kombinace vodopádového (první zákazník) a spirálového (další). Další modely: fontánový (komponentový vývoj), inkrementální (postupný vývoj a nabalování dalších funkcí) Životní cyklus ICT vs projektu ICT Součástí informační strategie je „Jak transformovat stávající do cílového stavu“. V rámci toho jsou definovány ICT projekty.

Dokumentace IS • požadavků • architektury a návrhu – vztahy mezi entitami, komponentami • technická - algoritmy • uživatelská • administrátorská • marketingová - whitepapers Úloha PRINCE je metodika od Office of Government Commerce, UK, která razí strukturovaný přístup k řízení projektu. Je procesně orientovaná: 45 podprocesů organizovaných v 8 základních procesech.

System Developement Methodology (SDM) - strukturovaná metodika, vodopádový přístup k vývoji IS - pro vývoj IS obecně, robustní rámec především pro vývoj IASW Jednotlivé fáze: Informační plánování (jaký je stav a jaká je potřeba informační podpora – pro celou organizaci), Úvodní studie (pro jeden systém, posouzení realizovatelnosti, alternativ), Globální návrh (detailní funkční návrh = org. struktura, datový model a model funkcí; globální technický návrh), Detailní návrh (pro každý subsystém, převod funkčního na technický – dB, obrazovky), Implementace, Zavádění, Provoz a údržba. Odpověď: Je potřeba odlišovat věcnou podstatu projektu od jeho řízení. V tomto případě je předmětem projektu vývoj IS. K jeho dokumentování je třeba využít metodiku vývoje IS. Například tedy SDM. Zároveň je však potřeba dokumentovat i průběh procesu a to jak kvůli řešení sporů, zastupitelnosti, poučení se v budoucnosti apod. Proto je potřeba udržovat i dokumentaci projektu např. podle PRINCE.

3.18 Řízení dodavatelského řetězce (sítě) – SCM

3.18 Ří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.

Dodavatelský řetězec a jeho řízení

1.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. SCM má 2 hlavní cíle: • koordinace aktivit jednotlivých členů a optimalizace dodavatelského řetězce jako celku • vyrovnání nabídky s poptávkou a tím lepší řízení produkce každého článku a řetězce 1.1.2. Konceptuální model SCM Zásobování (info)

Dodavatelé

Poptávka (info)

Podnik Vstupní logistika (materiál)

Zákazníci Výstupní logistika (produkce)

- výroba - distribuce - plánování

Nákup

Přidání hodnoty

Prodej

Fyzický kanál Informace

1.1.3. Procesy v SCM Na nejvyšší úrovni:

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í.

Expedice: Zpracování objednávek, řízení skladů hotové produkce, doprava, fakturace zákazníkovi.

Plánování: Koordinace předešlých tří procesů. 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.

- 1/4 -


Plánování a řízení těchto procesů probíhá z časového hlediska na třech úrovních tj. dlouhodobé, střednědobé a krátkodobé. V tomto směru jsou též výše uvedené procesy děleny do dalších dílčích procesů. Detailní "rozpad" procesů na dílčí procesy je proveden např. v SCOR1. 1.1.4. Přínosy – metriky V rámci zvýšení zákaznické spokojenosti nabízí aplikace SCMnapříklad: • podíl zákazníka na výsledné konfiguraci produktu • trvalé informování zákazníka o stavu jeho objednávky • snížení pravděpodobnosti výskytu opoždění nebo nekompletní dodávky Pro partnery v rámci řetězce nabízí: • snížení nákladů • zkrácení času vyřízení zákaznického požadavku • zlepšení řízení v rámci celého procesu (včetně reakcí na změny n.vzniklé problémy) • eliminaci hluchých míst v rámci tohoto procesu • možnost automatizace nákupních činností • možnost sdílení informace o aktuálním stavu objednávky všemi partnery • zvýšení kooperací a důvěry mezi partnery V rámci podpory plánovacích činností nabízí: • plánování požadavků v řetězci na základě historických dat (s ohledem na celkové možnosti nákupu, výroby, distribuce a transportu) • podporu určení optimální lokality a formy dodavatelského řetězce • materiálové požadavkymohou být napojeny na možnosti e-procurementu či na možnosti nákupu v rámci el. tržiště (e-marketplace) Metrikami mohou být například: • • • • • • • •

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% Zkrácení obchodního cyklu 30-70% zvýšení včasných dodávek ( o 40%) zvýšení obratu ( o 17%)

1.1.5. SW pro SCM + dodavatelé SW pro SCM Plánování a řízení dodavatelského řetězce je zajišťováno aplikačními programy, jejichž jádrem je APS (Advanced Planning System)- systém pokročilého plánování. Ty využívají pro komunikaci partnerů v SC typicky Internet a zajišťují: • •

integrované SCM v tom smyslu, že souběžně provádějí předpověď požadavků, řízení zásob, plánování výroby, plánování dopravy optimalizaci nejen nákladů ( na SCM a jeho řízení) ale též kvality výrobku, časových faktorů, kvality služeb (zákazníkovi) což silně ovlivňuje spokojenost zákazníka

Na trhu existují dva typy SCM produktů: Specializované: • 1

Infor ( specializovaná řešení pro odvětví např. výroba, přeprava/logistika, retail)

Supply Chain Council Reference model - 2/4 -


•

i2 SCM

SCM/APS rozšiřující stávající ERP systémy

mySap SCM (SAP)

BAAN SCS – Baan

Oracle

K2

1.1.6. Metody řízení uplatňované v rámci SCM • •

CRP (Continuous Replenishment Planning) – systém plynlého zásobování zákazníka dodavatelem VMI (Vendor Managed Inventory) – řízení zásob dodavatelem (odběratel přebírá plnou zodpovědnost za dohodnutou úrověň zásob ve skladu odběratele) • ECR (Efficient Customer Response) – spojení a spolupráce obchodníka s výrobcem s cílem efektivnějšího reagování na požadavky zákazníka a snížení nákladů v dodavatelském řetězci • CPFR (Continuous Planning, Forecasting and Replenishment) – společné plánování a predikce v dodavatelském řetězci podporující existující praktiky, zvýšení kooperativního řízení a vizualizace a umisťování produktů v celém řetězci na základě sdílené informací V rámci plánování v řetězci jsou využívány 2 principy: • CTP (capable to promise)– možný termín dokončení zakázky kalkuluje na základě výrobních plánů disponibilní kapacity pracovišť • ATP (available to promise) – kalkuluje pouze na základě disponibilní zásoby hotových výrobků a fixních průběžných dob výroby

1.2.

APS – Advanced Planning & Scheduling

APS • •

• •

Je proces řízení výroby, ve kterém dochází k optimalizované alokaci zdrojů a materiálu nutných k zajištění poptávky. Výsledkem tohoto procesu bývá plán Je oblast speciálních aplikací v rámci podnikového IS která se týká výrobního plánování až na úroveň detailního dílenského rozvrhování.

Závisí na synchronizovaném plánování všech zdrojů s respektováním všech známých omezení. Kladou si za důraz dodržení termínů a kvality spolu s nízkými náklady.

1.2.1. Model APS

- 3/4 -


1.2.2. Vztah APS k SW pro SCM

•

APS má podobnou roli uvnitř podniku, jako řeší SCM systémy směrem vně podniku

APS představuje základní komponentu SCM zajišťující plánování a optimalizaci procesů. V současnosti jsou všechny produkty nazývány APS/SCM. − − − − −

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)

- 4/4 -

3.19 ASP (Application Services Providing) – poskytování aplikačních služeb

3.19 ASP (Application Services Providing) – poskytování aplikačních služeb Definice ASP, koncept, srovnání „software-as-a-license“ modelu se „software-as-a-service“ modelem, výhody a nevýhody pro uživatele i provozovatele, vhodné druhy aplikací, vztah k řízení informatiky podniku (řízení IS/ICT), stav v ČR a ve světě

1.1.

1.2.

1.3.

Definice ASP •

ASP (Application Service Provider) – Služba založená na oddělení vlastnictví určité aplikace od jejího používání, na rozdíl od outsourcingu odděluje od využívání systému, jak provozování, tak i vlastnictví daného řešení. Poskytovatel ASP se 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 poskytovatel 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 vhodné komunikační infrastruktury jako je například privátní síť nebo Internet. ASP služby jsou poskytovány většinou za úplatu. Poskytoval nabízí své služby několika zákazníkům, mezi které rozkládá své náklady - řešení cenově dostupnější pro větší okruh zákazníků.

•

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 - datacentra (datová centra). Musí být tedy zajištěno vhodné propojení mezi datacentrem a koncovým zákazníkem – musí existovat NSP (Network Service Provider).

Koncept ASP •

Specializovaný poskytovatel udržuje, provozuje a dává k dispozici aplikaci, ICT infrastrukturu pro provoz aplikace a podpůrné služby s aplikací související a dodává je velkému počtu zákazníků prostřednictvím internetu jako službu.

•

Mnoho uživatelů z různých organizací využívá tutéž aplikaci společně.

•

Aplikace má jako svoji součást service management, která umožňuje měřit a řídit dodávanou službu.

•

Zákazník platí pouze za služby, které v daném období objednal, resp. využil.

•

Kontrakt má podobu informatické služby – SLA, obsahuje tedy hlavně obsah, objem, kvalitu a cenu služby.

Srovnání modelem •

„software-as-a-license“

modelu

se

„software-as-a-service“

Rozdílů mezi „SaaL“ a SaaS je celá řada (viz výhody a nevýhody ASP – výhody ASP jsou nevýhody SW jako licence a naopak), níže uvedené body jsou v kontrastu k výše uvedené definici SaaS (ASP): 1) v SaaL výrobce vytvoří a dále rozvíjí SW aplikaci,ta je specializovanou firmou instalována na počítače zákazníka – za provoz je zodpovědný interní ICT útvar podniku, 2) architektura SaaS je navržena pro současné využívání tisíci uživateli z různých organizací (Multi-Tenant Architecture), kdežto SaaL využívají pouze lidé z jedné organizace (Single-Tenant Architecture), 3) SaaL nabízí široké monžosti prezentace dat uživatelům, SaaS pouze webový prohlížeč, 4) o nasazení nové verze SaaS rozhoduje poskytovatel, v případě SaaL pak zákazník, 5) u SaaL jsou nutné licence, u SaaS nikoli, 6) SaaL vyžaduje ICT lidské zdroje na straně zákazníka, 7) kontrakt SaaL je obvykle rozdělen na několik dílčích smluv (na HW, SW, licence, doprovodné služby), u SaaS je to pouze SLA. - 1/3 -


1.4.

Výhody a nevýhody pro uživatele i provozovatele

1.4.1.

Výhody ASP modelu

1.4.2.

1.5.

•

pro uživatele: 1) krátký implementační cyklus – služba je rychle využitelná, 2) vysoká dostupnost (obvykle 365/7/24), 3) služba je často škálovatelná, 4) typicky velmi vysoká spolehlivost, 5) možnost otestovat před pořízením, 6) nutnost malého množství technologických a lidských zdrojů, 7) není nutný nákup licencí, 8) nižší celkové náklady na aplikaci, náklady jsou operativní povahy, nikoli investiční, 9) rychlá návratnost investice, 10) vysoká bezpečnost dat.

•

pro provozovatele: 1) značné úspory z rozsahu – snížení cenové hladiny poskytovaných služeb, 2) možnost oslovit značné množství zákazníků standardizovanou nabídkou služby, 3) pravidelné měsíční poplatky představují trvalý zdroj příjmů, 4) náklady na dalšího zákazníka (tj. na prodání služby další organizaci) jsou velmi nízké, 5) jednotná technologická infrastruktura - ASP služby jsou poskytované přes tenkého klienta a poskytovatel se nemusí starat o dostupnost.

Nevýhody ASP modelu •

pro uživatele: 1) existence trvale dostupného, ekonomicky přijatelného propojení mezi zákazníkem a poskytovatelem ASP, 2) nutnost svěřit chod IS a tedy i citlivá data do rukou externího subjektu, 3) problematická integrace aplikací, jednotlivých ASP služeb, 4) uživatelské rozhraní prohlížeče stále nenabízí takové možnosti jako tlustý klient, 5) uživatel nemá pod kontrolou nasazování nových verzí aplikace, 6) závislost na externím subjektu, 7) není možná rozsáhlá customizace a přizpůsobení ASP aplikace na míru.

•

pro provozovatele: 1) existence trvale dostupného, ekonomicky přijatelného propojení mezi zákazníkem a poskytovatelem ASP, 2) musí poskytovat zákazníkům neustále služby na špičce světové úrovně, 3) je nutná vysoká dostupnost, spolehlivost, bezpečnost aplikace, 4) musí překonat nedůvěru organizací v tento typ aplikací, 5) musí mít špičkové odborníky téměř všech IS/ICT specializací.

Vhodné druhy aplikací •

Pro model dodávky ICT formou ASP nejsou vhodné následující typy aplikací: 1) životně důležité aplikace (mission critical) – zákazník nemá pod kontrolou změny aplikace a čas zavádění nových verzí, 2) specializované aplikace – nejsou zajímavé pro poskytovatele, malý počet potenciálních zákazníků, 3) vysoce customizované aplikace – ztráta úspor z rozsahu, 4) aplikace s vysokými nároky na integraci.

•

Mezi nejpoužívanější ASP služby patří: 1) webhosting, 2) messaging (pošta), 3) kancelářské aplikace, - 2/3 -


4) e-commerce, 5) CRM.

1.6.

1.7.

Vztah k řízení informatiky podniku (řízení IS/ICT) •

Předmět kontraktu je vymezen prostřednictvím SLA na dodávku informatické služby (vymezuje obsah, objem, kvalitu a cenu služby).

•

Existence SLA je standardem – uživatelé mají smluvně podloženo, jakou službu a za jakých podmínek dostávají.

•

Za ICT infrastrukturu aplikace a její dostupnost a výkonnost je zodpovědný poskytovatel.

•

Zodpovědnost za ochranu dat před zneužitím či krádeží se přenáší na dodavatele v případě dat již uložených v aplikaci (za data přenášená je zodpovědný poskytovatel připojení).

•

V podniku musejí být tyto znalosti: jak využít ICT služby na podporu podnikání, jaké jsou ICT služby dostupné na trhu, jaký má být obsah a struktura SLA, jak správně řídit dodávky těchto aplikačních služeb.

•

Snižuje se potřebné množství ICT personálu.

•

Reakce na incidenty jsou ze strany poskytovatele velmi krátké, oprava chyby hlášené jedním ze zákazníků je opravou chyby všem zákazníkům.

•

Podnik ale ztrácí znalost, která může být potřebná v budoucnu.

•

Je nutné vybrat kvalitního, spolehlivého dodavatele služby.

Stav v ČR a ve světě •

Situace v oblasti ASP (SaaS) se postupně zlepšuje, ale zatím není rozhodně možné mluvit o masovém rozšíření tohoto modelu dodávky ICT služeb. Důvody jsou následující: 1) jedná se o poměrně novou cestu a většina firem je po Y2K, EURO a osudech .COM firem mnohem konzervativnější v přijímání nových technologií a služeb, 2) nabídka ICT služeb formou SaaS modelu je na evropském trhu oproti situaci v USA velmi omezená – v ČR je např. pouze několik desítek firem nabízejících SaaS, řada z nich navíc tento způsob považuje za nevýznamný doplněk své obchodní činnosti a nemá dobře připravenou technologii ani obchodní model (jasné SLA, škálovatelnost), 3) existují obavy z úniku dat mimo podnik, 4) ještě nedávno se sami dodavatelé stavěli k SaaS poměrně chladně – byl v přímém rozporu s jejich cílem prodávat stále větší objem softwarových licencí,

•

V budoucnu je věštěno ASP modelu masové rozšíření, ICT se má stále více přesunovat od uživatelských firem ke specializovaným poskytovatelům ICT služeb.

•

Podle Gartnera má tvořit v roce 2011 SaaS 25% softwarového trhu, v roce 2005 byl objem SaaS cca 6mld. dolarů s předpokládaným nárůstem 20% ročně.

- 3/3 -

3.24 Modely elektronického obchodování Modely elektronického obchodování B2B, elektronická tržiště, klasifikace, zhodnocení, alternativy, vývoj v dané oblasti.

1. Modely elektronického obchodování B2B Zařazení B2B obchodování:

Charakteristiky modelu B2B v porovnání s B2C: •

•

•

Transakce o Mnoho B2B transakcí se provádí mezi známými partnery (i když se provádí i "spot transakce" - tj. jednorázové obchodní transakce mezi předem ne-spolupracujícími partnery), často formou dílčích dodávek na základě dlouhodobých obchodních vztahů Marketing o Product Rozlišují se na přímé a nepřímé prostředky (více viz kapitola věnovaná ET) Některé produkty nejsou vhodné pro prodej B2B (např. lokomotivy) o Place Podobné distribuční kanály jako u B2C o Price Větší počet mechanizmů určování ceny než v B2C (např. reverzní aukce, RFP – regest for proposal) Využívání diferenčních cen o Promotion Liší se od B2C v závislosti na odvětví, zejména s ohledem na počet potenciálních kupujících (“velikosti trhu“) v daném odvětví Cíle

•

•

•

•

•

•

o Cílem B2C prodávajícího je dosáhnout toho, aby návštěvník e-obchodu (webu) nakoupil okamžitě; je tomu tak proto, že nákupní rozhodování spotřebitele v B2C je do značné míry impulsivní, emotivní, vycházející z přání, typicky s ohledem zejména na cenu o Nákupní rozhodování kupujícího v B2B je odlišné, tj. trvá déle (viz též víceúrovňové rozhodování), je racionální - vycházející z vyhodnocení podnikatelských přínosů (např. snížení nákladů, zvýšení produktivity; cílem B2B prodávajícího je typicky dosáhnout toho, aby potenciální kupující projevil prodávajícímu o nabízený produkt zájem (např. dotazem, či žádostí o informace apod.), v návaznosti pak prodávající vzdělává potenciálního kupujícího dalšími promočními aktivitami (často i mimo IO) Personalizace o Orientována na jednotlivé podniky o V některých B2B aplikacích mají významní zákazníci vlastní webové stránky (přesnější sledování průběhu zakázek, celoročního objemu obchodů, dokonalejší poprodejní podpora, specielní ceny) Vytvoření kontraktu o U B2C nejčastěji stejné podmínky pro všechny kupující o U B2B jsou kontrakty složitější (různé podmínky a ceny pro různé zákazníky) a jejich vyjednání trvá déle, přičemž často je jejich část vyjednávána mimo internet Dodání o Jiný charakter než B2C, většinou rozsáhlé dodávky, často do větších lokalit, dodržení termínu dodání má typicky u B2B meritorní význam (zejména v rámci SCM) a je obslouženo kontraktem Platba o Finanční objemy dílčích dodávek v B2B jsou výrazně vyšší než u dodávek B2C (v tomto směru lze B2B považovat za "velkoobchod") o Placení se u B2B provádí především bankovními převody (přes EDI či přes Internet), typické je placení po dodání (a rozdíl od B2C, kde se platí předem) o Často se využívá úvěr mezi známými partnery Aplikace o u B2B se (na rozdíl od B2C) kromě aplikací prodávajícího využívají často i aplikace kupujícího (viz e-zásobování) o Pro B2B jsou specifická elektronická tržiště - vertikální portály (zaměřené na určitou oblast např. chemie) v míře, která není pro B2C typická o Některé aplikace B2B (platforma spolupráce) zajišťují též integraci ve směru k epodnikání (zejména integraci SCM) o Pokud se v B2B aplikacích využívají katalogy (pro nákupní aplikace), jsou přesnější než u B2C s vazbou na další dokumenty pro využití/údržbu prodávaných produktů. o Pouze u některých aplikací B2B komunikuje např. kupující s aplikací prodávajícího s využitím internetového prohlížeče (jako v B2C), zejména u silných/dlouhodobých partnerů je zajištěna přímá komunikace/integrace jejich IS (představující např. aplikaci prodávajícího u prodávajícího a ERP u kupujícího) prostřednictvím Internetu a to bez nutnosti manuálního zásahu -tzv. vnější integrace. o Kromě vnější integrace se využívá i vnitřní integrace (v daném podniku např. prodávajícího) např. v aplikaci prodávajícího integrace internetové komponenty IS (front-end) s vnitropodnikovým IS (ERP) umožňující okamžitou vazbu obchodní transakce se skladovým hospodářstvím, financemi podniku apod. (tato míra integrace je ještě vyšší u aplikací e-podnikání) Technologie ICT

•

• •

o Pro podporu řady B2B aktivit (např. dílčí objednávky na základě dlouhodobého kontraktu) se využívá přímé propojení aplikací v IS partnerů s využitím zpráv (EDI či XML) – na rozdíl od C/S modelu s prohlížečem u B2C o V některých odvětvích (např. automobilový průmysl) se místo internetového obchodování B2B využívá EDI (Electronic Data Interchange) o Silný partner (např. kupující – Škoda) může předepsat, jaké technologie mají partneři (např. dodavatelé) používat Důvěra o Dlouhodobé kontrakty mezi partnery (což je častý případ v B2B) výrazně přispívají k posílení důvěry o U B2B aplikací v zásadě vyšší požadavky na bezpečnost (než u B2C) Daně a cla o U B2B významnější (než u B2C) i otázky daní a cel Právo o I specifické právní otázky EO jsou v B2B typicky přesně dohodnuty v kontraktu

2. Definice elektronického tržiště, elektronického trhu (ET) Podnikatelský pohled • ET je podnikatelský subjekt podporující provádění obchodní transakce B2B (tj. prodej/nákup produktu nebo služby) případně i další služby • Subjekty ET o Prodávající, kupující, provozovatel tržiště z podnikatelského hlediska, prostředníci – provozovatelé dalších služeb nabízených na ET, příp. provozovatel tržiště z technologického hlediska • Zdroje příjmů podnikatele - provozovatele ET o Členské poplatky účastníků, příjmy z reklamy, poplatky z transakcí (cca několik%), příjmy od prostředníků nabízejících služby na ET, příjmy z dalších poskytovaných služeb, příp. příjmy z prodeje (etického) informací třetím stranám Technologický pohled • ET je technologicky typicky internetovou aplikací, na níž mohou být jednotliví uživatelé (podniky – účastníci ET) připojeni o Internetovým prohlížečem o Integrovaným připojením IS jednotlivých účastníků (např. ERP)

3. Klasifikace ET Dle vlastnictví: •

•

Soukromé o Soukromý trh (private exchange), vlastněn a typicky i provozován jedinou firmou (prodávající, kupující) o Typy soukromých ET (ET prodávajícího, ET kupujícího, ET zajištující obě varianty) o Zajišťuje různé funkce podporující obchodní transakci Veřejné o Veřejné tržiště vlastněné konsorciem firem (consortia exchange), které na něm obchodují, ale které mimo něj často navzájem soupeří o Veřejné neutrální tržiště (independent, third party) vlastněné nejčastěji jednou firmou (často Internet start-up) nebo skupinou nesoupeřících firem, které na tržišti neobchodují

•

o Zajišťuje různé funkce podporující obchodní transakci Platforma spolupráce o Soukromá či veřejná platforma spolupráce, zajišťuje různé funkce podporující spolupráci účastníků tj. jiné funkce než přímá podpora obchodní transakce

Dle účastníků: •

•

• •

•

Trh prodávajícího (sell side) - 1 (prodávající):N (kupujících) o Často provozován silným výrobcem nebo prostředníkem o Často formou podnikového portálu o Systematický nákup na základě dlouhodobého kontraktu Trh kupujícího (buy side) - N (prodávajících):1 (kupující) o Typicky provozován silným kupujícím o Nákup na základě RFP a RFQ na webu kupujícího Systematický nákup dle katalogu prodávajících Reverzní aukce v reálném čase Tržiště (exchange) - M (prodávajících):N (kupujících) o Nejčastěji vertikální Platforma spolupráce - N účastníků o Zaměřeny na podporu tj. zefektivnění obchodních/podnikatelských procesů mezi podniky tj. podporují dlouhodobější spolupráci/vztahy partnerů, protože zefektivnění podnikatelských procesů mezi nimi vyžaduje mj. důvěru a investice, což je relevantní pouze u dlouhodobějších vztahů Některé druhy lze kombinovat např. trh prodávajícího s trhem kupujícího a soukromou platformou spolupráce

Dle orientace na průmyslovou oblast: • •

Horizontální ET (pro různá průmyslová odvětví) Vertikální ET (pro jedno průmyslové odvětví)

Dle otevřenosti členství v ET: • •

Veřejné (otevřené) ET (účast na ET není a priori omezena) Uzavřené ET (účast na ET je (vlastníkem ET) a priori omezena)

Dle určení ceny: •

• •

•

Katalogy produktů o Jednoduchá nástěnka produktů s fixní cenou o Veřejný katalog s fixní cenou o Privátní katalog s dynamickými cenami Normální a reverzní aukce Agregace o Spojení několika menších dílčích objednávek různých (menších) kupujících do společné objednávky, kterou tržiště (prostředník) prezentuje potenciálním dodavatelům RFP (regest for proposal) a RFQ (regest for qualifications)

Dle obchodovaných produktů a služeb: • Nepřímé (provozní) prostředky o Nejsou součástí koncových produktů kupujícího (kancelářské potřeby, letenky) o Nejsou oborově závislé, a proto se nakupují na horizontálních ET • Přímé (výrobní) prostředky o Jsou součástí koncových produktů kupujícího (suroviny, komponenty) o Jsou oborově závislé, a proto se nakupují na vertikálních ET Dle geografické orientace: • Omezená geografická oblast • Globální trh Dle podpory obchodních vztahů: • Podpora stávajícího dlouhodobého vztahu nebo vytváření dlouhodobých vztahů • Podpora krátkodobých – jednorázových vztahů mezi partnery Dle poskytovaných funkcí a služeb: • Základní diferenciace je v sortimentu a kvalitě nabízených funkcí a služeb • Funkce podpory obchodní transakce o Informace o průmyslové oblasti o Vyhledávání partnerů a produktů o Seznamy poptávek o Různé způsoby určování ceny • Funkce podpory spolupráce o Integrace IS účastníků o Funkce ET jako datového uzlu (konverze EDI, XML) o Podpora workflow mezi účastníky • Další funkce o Hodnocení dodavatelů o Konzultační služby

4. Zhodnocení přínosů a překážek využívání ET Přínosy: • Pro kupující o Rychlé provedení obchodní transakce, včetně snadného a rychlého nalezení vhodného obchodního partnera či produktu o Snížení transakčních nákladů kupujícího o Široký výběr (produktů, partnerů) o Nižší ceny o Dostupnost služeb, které mohou sami jen obtížně či nákladně zajistit (např. plánování dodavatelského řetězce) • Pro prodávající o Snížení transakčních nákladů prodávajícího o Zvýšení tržního podílu, výnosů a zisku o Oslovení mnoha zákazníků s nízkými náklady • Pro oba o Z technologického hlediska dosažení mnoha partnerů (a mnoha různých služeb) připojením pouze k jednomu IS (tj. k webu ET)

Překážky využívání u veřejných ET: • • • • • • •

Chybí jasná, přesná a kvantifikovaná (např. objem transakcí za měsíc) deklarace provozovatele ET o přínosech ET pro jeho účastníky Důvěra Bezpečnost Ztráta pozitivního vlivu značky prodávajícího (prodávající i kupující jsou často po část času provádění transakce anonymní) Cena produktu nemusí být vždy hlavním kriteriem uzavření transakce (=> zavádění multikriteriálních hodnocení a aukcí) Nejasné přínosy vzhledem k ne jasně garantované kvalitě služeb/produktu ET (SLA) Nepřipravenost potenciálních účastníků (podnikatelská i technologická) pro účast na ET

5. Vývoj ET •

Po enormním nárůstu počtu ET (celosvětově několik tisíc) v letech 1999/2000 dochází cca od druhé poloviny roku 2000 k výrazné redukci jejich počtu (na řádově stovky v r. 2003 dle Forrester Research); redukce = zánik nebo změna oblasti podnikání ET (např. na dodávku SW či služeb)

•

Redukce zejména v počtu neutrálních (3. strana) tržišť, méně v konzorciálních, velmi málo v soukromých

•

Přes "krach" řady ET střízlivě optimistický výhled jejich využívání do budoucna

•

Další vývoj o Rozvoj privátních ET o Rozvoj služeb u všech druhů ET

Úloha – předpoklady: Jste zaměstnanec firmy, která uvažuje o vstupu na e-tržiště jako prodávající. Zadání: Jaké informace v této souvislosti budete potřebovat pro rozhodnutí, zda na dané tržiště vstoupit, kde je získáte, jak je vyhodnotíte a jak se na jejich základě rozhodnete, jaké alternativy k e-tržišti budete uvažovat.

1 Změny v působení firmy na trhu v podmínkách informační společnosti

Recommend Documents