1.2 Internet, elektr. podnikání a konkurenceschopnost
1.01 Internet, elektronické podnikání a konkurenceschopnost
E-podnikání a architektury IS/IT. Jednotlivé fáze zavádění e-podnikání. Elektronické podnikání a konkurenceschopnost. Hlavní procesy v podnicích, které e-podnikání ovlivňuje.
1.1.
E-podnikání a architektury IS/IT
1.2.
Jednotlivé fáze zavádění e-podnikání
1.3.
podniky většinou začínají s e-podnikáním tak, že publikují na webu informace o sobě a svých produktech (jen neinteraktivní katalogy a prezentace) v další fázi následuje tvorba jednotlivých aplikací, ty jsou zatím izolované, nepropojené s jednotlivými procesy v podniku (např. umožnění zákazníkovi zaslat dotaz ) rozšíření aplikací tak, aby byla jejich prostřednictvím možná komunikace mezi zákazníky dodavateli a partnery: on-line objednávky, on-line prodej i placení, on-line podpora zákazníka zavedení EDI
Vliv Internetu na hosp. prostředí (e-business a konkurenceschopnost): pronikání firem do vzdálených teritorií- firma nabídně produkty na velkém globálním trhu, a jejich trhů. Konkurence se ale zrovna tak v internetu může rychle. Nové aplikace IS/IT vytvořené a provozované na platformě internetu, jako např. elektronický marketing, elektronické podnikání a další, ve svém důsledku ovlivňují chování podniků. Jde zejména o: •
odstranění mezičlánku v řetězu výrobce-distributor-zákazník – aplikace zprostředkují v prostředí internetu přímý vztah mezi prodávajícím a kupujícím
- 1/4 -
IS/IT
1.2 Internet, elektr. podnikání a konkurenceschopnost
•
•
•
•
• • •
sdílení znalostí v řetězu subdodavatel-výrobce-distributor - elektronické podnikání umožňuje efektivně spolupracovat a sdílet informace mezi subdodavateli – výrobci a distibutory. To přináší výrazné zkrácení doby reakce firmy a tedy zlepšení služby zákazníkům. nový vztah výrobce – zákazník - výrobce může využít informace získané z „internetového“ styku se zákazníkem(demografické údaje, oblasti zájmu zákazníka, ..) a nabídnout mu katalogy vystavené na webu, interaktivní nabídkové aplikace, udržující se zákazníkem dialog a dále upevňující jeho loajalitu,.. Změny forem komunikace mezi obchodními partnery. Klasické papírové dokumenty jsou stále častěji nahrazovány elektronickou výměnou dat(EDI). Ti partneři, kteří nebudou schopni příjmat a zasílat obchodní dokumenty (objednávky, faktury, platební příkazy,..) elektronickou cestou, budou v obchodě znevýhodněni, protože komunikace s nimi bude neefektivní. Změny ve formách prodeje výrobků a služeb. Stále více se prosazují nákupy z domova, zákaznické on-line bankovní služba další podobné formy styku se zákazníkem Posílení bezhotovostních plateb a vznik elektronických peněz Nové typy obchodních dohod mezi partnery založené na společném využívání datových zdrojů Změny stylu práce – virtuální týmy a virtuální podniky. Dochází ke zvyšování podílu duševní práce. Vznikají virtuální podniky, které jsou značně flexibilní, jejich náklady jsou oproti ostatním podnikům podstatně nižší(nízké náklady na podikové budovy, energii, cestovné, ..) a produktivita práce vyšší.
Elektronické podnikání přináší: B2C: snížení nákladů (př. vynechání „kamenných obchodů“ a objednáním přímo přes Internet) zlepšení časové a místní dostupnosti zlepšení komunikace se zákazníkem (on-line služby, podpora ...)........ B2B: zlepšení komunikačních možností s obchodním partnerem snížení nákladů (JIT, ..)....... EDI: podstatné zrychlení obchodního cyklu (nabídka – objednávka – potvrzení objednávky – smlouva ...) vytvoření pevných vazeb k obchodním partnerům a obrana proti nové konkurenci snížení dodacích lhůt (rychlé odbavení pojištění, celnice,..) snížení nákladů na administrativu (poštovné, mzdové náklady,..) urychlení platebního styku.......
- 2/4 -
1.2 Internet, elektr. podnikání a konkurenceschopnost
1.4.
Hlavní procesy v podnicích, které e-podnikání ovlivňuje E-podnikání nejvíce ovlivní procesy z oblastí: 1. péče o vztahy se zákazníky (CRM) - Ke dříve používaným kontaktům se zákazníky(pošta, telefon,..) nabízí elektronické podnikání elektronickou poštu a zejména interaktivní aplikace na webu, to vše řízeno a koordinováno z kontaktních center. Kontaktní centra umožňují integraci telefonů a informačního systému, automatické interaktivní hlasové odpovědi, zpracování elektronické pošty, hlasovou komunikaci přes web, vedení marketingových kampaní. (56%/62%) 2. řízení dodavatelských řetězců (SCM) - S využitím e-podnikání dochází k interaktivní komunikaci mezi jednotlivými podniky. Dochází k těsnější spolupráci firmy s jejími partnery založené na větší důvěře a lze dosáhnout časově přesnějších dodávek a úspor nákladů. (21%/11%) 3. platby a faktury (10%/12%) 4. operace specifické pro jednotlivé druhy podnikání (10%/13%) Čísla v závorkách jsou výsledkem průzkumu McKenna Group (1999,2000) a údaje OECD(1999) uvádějí,že podniky v USA a v západní Evropě očekávají, že e-obchod nejvíce ovlivní v jejich firmách tyto procesy (USA/Evropa)
- 3/4 -
1.2 Internet, elektr. podnikání a konkurenceschopnost
Úloha - předpoklady: Jste reprezentant obchodního partnera velké počítačové firmy, která dodává relativně bohatou škálu produktů podporujících e-podnikání. Vaše provize závisí na množství nových obchodních kontraktů. Proto jste zorganizoval/a seminář pro potenciální zákazníky. Zadání:
V jakém pořadí budete prezentovat produkty podporující e-podnikání a které byste v každém případě chtěl/a mít ve své prezentaci a proč (i když ještě třeba firma tyto produkty neimplementovala)? Navrhněte agendu semináře . Jak se chcete odlišit od konkurence, resp. co doporučíte vedení firmy, aby zavedlo jako produkt podporující e-podnikání?
Příklady produktů podporujících e-podnikání – vybrané aplikace mySap.com(SAP) a Siebel(Siebel): •
Prodej po Internetu (Internet Sales): aplikace umožňuje vybrat zboží z katalogu, jeho konfiguraci zároveň s dynamicky se měnící cenou, kontrolu dostupnosti a objednávku. Bývá integrováno s ERP. Registrovaný zákazník je provázen personalizovanými nabídkami zboží. Zároveň se změnou konfigurace (automobil, počítač) se průběžně mění také cena a je kontrolována disponibilita (Internet Pricing a Configurator). Shromážděné údaje o chování zákazníků jsou využity při vytváření strategie podniku.
•
Propagace na Internetu (Internet Marketing): informační kanál pro provozování marketingových kampaní. Umožňuje registraci zákazníka a jeho přiřazení k určitému profilu podle údajů získaných z přihlašovacího formuláře. Když zákazník opět zavítá do internetového obchodu, nabídka zboží je dynamicky generována na míru typu zákazníka. Používá se pro sledování odezvy prodejních kampaní a sledování zájmu zákazníků.
•
Spolupráce s obchodními partnery (Business Partner Collaboration) : otvírá obchodním partnerům přístup k vybraným funkcím systému. Například prodejci mohou využívat centrální databázi informací o zákaznících a doplňovat ji. Mohou touto cestou zjišťovat cenu a stav zásob a zakládat zakázky a kontrolovat jejich plnění. Dodavatelé mohou spolupracovat na doplňování zásob.
•
Informační samoobsluha přes Internet (Internet Customer Self Service): otvírá zákazníkům internetový přístup k vybraným informacím z databáze zákazníků. Takže si touto cestou mohou např. sami změnit zasílací adresu.
•
Servisní interakční centrum (Service Interaction Center): aplikace call centra zaměřená na poskytování technické pomoci a informací. Smíšené kontaktní a interakční centrum podporuje komunikaci prostřednictvím telefonu, el. pošty, faxu a poštovních zásilek.
- 4/4 -
1.5 Standardy a normy v IS/IT
1.2 Standardy a normy v IS/IT Druhy a oblasti standardů v IT. De jure standardy, de facto standardy, orgány pro tvorbu a dohled nad standardy, přínosy standardizace.
1.
Úvod do tématiky V době sálových počítačů, které vyrábělo několik málo velkých firem, byl trend linie produktů – podnik se rozhodl pro určité řešení a od jednoho dodavatele nakoupil veškerou výpočetní techniku. Protože řady jednotlivých výrobců (a mnohdy i různé řady jednoho výrobce) nebyly kompatibilní viz. Dále, byl podnik nucen nakupovat SI/IT od stejného výrobce a změna byla velmi nákladná. (Vázanost na jednoho výrobce – proprietary). S příchodem dalších firem na trh a se specializací a rozvojem bylo nutné, aby se hlavně menší firmy, které neměly prostředky na marketing atd., přizpůsobily velkým výrobcům a tím mohly konkurovat. Proto mnoho firem převzalo řešení IBM aj. (např. IBM PC kompatibilní – standard (de facto) z roku 1981: První model IBM PC - otevřený standard, procesor od Intelu, operační systém od Microsoftu, oproti modelu od firmy Macintosh, který v té době byl daleko výkonnější, ale měl uzavřenou architekturu). Řešení, kterému se přizpůsobují různí výrobci a které tak představuje určitou společnou konvenci, zajištující vzájemnou kompatibilitu1 produktů od různých výrobců, si již zaslouží přívlastek standardní, jako protipól anglického proprietary. Samotný obsah resp. podstata tohoto řešení se pak v širším slova smyslu označuje jako standard. Standardní řešení resp. standard může vniknout tak, že se z podnětu či pod záštitou určité instituce, která je k tomu příslušná, sejde skupina odborníků a vypracuje návrh příslušného řešení. Ten je posléze kodifikován (tj. dostane formu oficiálního dokumentu příslušné instituce), a pak je prosazován do praxe. Podstatné přitom je, že zmíněné standardizační instituce obvykle nereprezentují přímo jednotlivé výrobce (i když tito se na jejich práci mohou významně podílet). Technické normy jsou dokumentované dohody, které obsahují technické specifikace nebo jiná určující kriteria používaná jako pravidla, směrnice/pokyny nebo definice charakteristik k zajištění, že materiály, výrobky, postupy a služby vyhovují danému účelu. Ve společnosti s rozvinutým tržním hospodářstvím jsou to kvalifikovaná doporučení, žádné příkazy. Jejich používání je dobrovolné, avšak všestranně výhodné.
2.
Druhy a oblasti standardů
2.1.
Druhy De jure standardy – standardy, které přijme některá ze standardizačních organizací, jeho závaznost pro výrobce i uživatele je ovšem různá podle toho, jaký má právní statut resp. jaký je statut toho, kdo jej formálně vydává. (Například standardy, vypracované a vydávané mezinárodními standardizačními institucemi, mají často pouze formu doporučení a po formální stránce nejsou právně závazné. Právní závaznost pak mívají až návrhy ve formě norem, které v rámci jednotlivých zemí vypracovávají k tomu oprávněné instituce, často na základě doporučení, přijatých mezinárodními organizacemi.)
1
Pojem bude rozveden dále - 1/6 -
1.5 Standardy a normy v IS/IT
De facto standard – taková konvence, která je všeobecně užívána jako standard, ale nebyla přijata standardizační organizací – například jej vyvinul velký producent určitého produktu, či první producent, který produkt začal vyrábět (např. ActiveX – technologie f. Microsoft)
2.2.
Oblasti
HW – kompatibilita technických zařízení (dříve např.IBM PC kompatibilní)
Protokolů – např. síťové protokoly (TCP/IP, IPX/SPX, NetBEUI, AppleTalk, Data Link Control – DLC, Systems Network Architecture – SNA),
Standardy komunikačních sítí - IEEE (Institute of Electrical and Electronics Engineers) např. IEEE 802, - normy pro lokální a metropolitní sítě
Jazyků – programovací a jiné jazyky (HTML, XML, SQL, ),
Metodik (např. pro modelování UML, DFD, procesní modelování – viď. obrázek pro ilustraci v příloze)
Bezpečnosti – postupy a metody vytváření systémů informační bezpečnosti (např. ČSN ISO/IEC TR 13335-(1-4) - Information technology - Guidelines for the management of IT Security), šifrování
Řízení projektů – PMI (Project Management Institute), ISO,
standardy pro EDI – Edifact,
Standardy v obecných metodikách vývoje IS/ICT – SDM, SSADM , ale i např. standard ISVS – Standardy inf. systémů veřejné správy,
Standardizace obsahu a jakosti IS/ICT – v metodice ITIL, v metodice COBIT, ve standardech ISO
Standardizace v oblasti auditu IS/ICT – podle INTOSAI, podle ISACA, ...
atd.
3.
Orgány pro tvorbu a dohled nad standardy
3.1.
Mezinárodní standardizační organizace •
ISO (International Organization for Standardization) = mezinárodní federací národních standardizačních orgánů.
•
IEC - International Electrotechnical Commission = je organizace, která se věnuje standardizaci v oblasti elektrotechniky a elektroniky a úzce spolupracuje s organizací ISO.
•
ITU - International Telecommunication Union = je mezinárodní organizace, založená v roce 1865. Zabývá se standardizací v oblasti telekomunikací a reprezentuje více než 170 zemí. Mezi aktivity ITU patří též tvorba standardů (nazývaných doporučení). WSSN - World Standards Services Network CEN - European Committee for Standardization = vyvíjí evropské standardy v mnoha oborech, včetně oborů elektrotechnických. Standardy pro elektrotechnické obory jsou zajišťovány sesterskou organizací CENELEC, která od roku 1984 zajišťuje spolu s CEN standardy pro země Evropského společenství. CENELEC - European Committee for Electrotechnical Standardization ETSI - European Telecommunications Standards Organisation
• •
• •
- 2/6 -
1.5 Standardy a normy v IS/IT
•
3.2.
Národní standardizační organizace • • •
•
3.3.
ECMA - (European Computer Manufacturers Association) = je nezisková organizace, jejímiž členy jsou evropské firmy, které vyvíjejí, vyrábějí a prodávají hardware a software. ECMA vydala přes dvě stovky standardů IT a technických zpráv, které byly často použity jako podklady pro tvorbu ISO/IEC a ITU standardů. ECMA je aktivní především v oblasti otevřených systémů (OSI) a její technický výbor TC36 se zabývá standardy v oblasti bezpečnosti informačních systémů.
COPANT - Pan American Standards Commission NIST (National Institute of Standards and Technology, dříve NBS resp. National Bureau of Standards), ANSI (American National Standards Institute) = standardizační organizace, která koordinuje vývoj standardů v USA. Mnohé z těchto standardů jsou využívány i mimo USA a mnohé rovněž sloužily jako předloha při vytváření standardů mezinárodních. EIA (Electronic Industries Assocation)
V České republice 1. ÚNMZ- Úřad pro technickou normalizaci, metrologii a státní zkušebnictví připravuje určení harmonizovaných českých technických norem a zajišťuje oznámení o jejich určení ve Věstníku Úřadu připravuje smluvní zabezpečení tvorby českých technických norem Českým normalizačním institutem z prostředků ze státního rozpočtu podílí se na přípravě návrhů nařízení vlády, kterými se stanoví technické požadavky na výrobky analyzuje vývoj legislativy ES s cílem iniciovat aktualizaci českých právních předpisů, zejména nařízení vlády, kterými se stanoví technické požadavky na výrobky, transponujících předpisy ES 2. ČSNI pracuje na základě pověření Ministerstva průmyslu a obchodu ČR. Plní funkci národní normalizační organizace uvnitř ČR i v zahraničí - ČSN jsou univerzální, tzn. pro všechny obory činnosti!! Základním předmětem činnosti ČSNI je: tvorba českých technických norem, vydávání a distribuce českých technických norem, poskytování informací o technických normách, spolupráce s nevládními mezinárodními a evropskými organizacemi, které se zabývají technickou normalizací. Rozhodující podíl v normotvorné činnosti má zavádění evropských norem a navazujících mezinárodních norem do soustavy ČSN, zatímco tvorba norem čistě domácího původu tvoří zbytkovou část každoročního programu normalizačních prací (okolo 10%). Normy ISO 9000 – normy pro management jakosti ČSN EN ISO 9000 Systémy managementu jakosti - Základy, zásady a slovník ČSN EN ISO 9001 Systémy managementu jakosti – Požadavky ČSN EN ISO 9004 Systémy managementu jakosti - Směrnice pro zlepšování výkonnosti - 3/6 -
1.5 Standardy a normy v IS/IT
Norma ISO 14000 má společné s normou ISO 9000 to, že požadavky obou norem se týkají systému řízení a lze je aplikovat ve Vaší společnosti současně. ISO 9000 určuje požadavky na kvalitu Vaší produkce, ISO 14000 určuje požadavky na Vaše chování k životnímu prostředí. Pokud získáte certifikát ISO 14000 garantujete Vaším partnerům a státní správě, že výrobu máte pod kontrolou z hlediska ohrožení životního prostředí a Vaše výrobky nejsou zhotoveny na úkor okolní přírody. Zákony stanovují: - výrobky musí být bezpečné - dále odpovědnost za škodu - zákon o ochraně osobních údajů
4.
Přínosy standardizace Důvody pro standardizaci Celosvětový pokrok v liberalizaci trhů Vzájemné ovlivnění různých sektorů trhů a jejich vývoj a integrita Usnadnění celosvětové potřeby komunikace Standardy pro infrastrukturu kompatibilita systémů Rozvoj tržního prostředí Podpora růstu jakosti Přínosy standardizace
kompatibilita systémů – např. standardy v oblasti komunikací a počítačových sítí jsou přímo životně důležité utváření tržního prostředí podpore růstu jakosti možnost kontroly systémů možnost vzájemného porovnávání systémů ....
Normy se využívají
4.1.
ve všech oblastech lidské činnosti v marketingu (myšleno – „náš výrobek splňuje normu...“ jako součást konkurenčního boje ve smluvních vztazích (podle normy xxx) ...
Kompatibilita systémů (hlavní přínos standardizace) slučitelnost určité složky výpočetního systému X se shodnou složkou systému Y tj. možnost použít tuto složku ze systému X bez úprav v systému Y. 1. Technická kompatibilita kompatibilita procesoru - 4/6 -
1.5 Standardy a normy v IS/IT
shodný soubor instrukcí nebo soubor instrukcí jednoho procesoru je exaktní podmnožinou instrukčního souboru druhého procesoru. kompatibilita přídavných zařízení možnost připojení daného zařízení ke kanálu nebo sběrnici uvažovaného počítače, aniž by bylo nutné provádět změny na zařízení nebo na kanálu Případné problémy s kompatibilitou (zvláště přídavných zařízení) lze řešit emulací. Ta je zajištěna buď programově, pokud je zařízení programovatelné vestavěnými prostředky zařízení
2. Programová kompatibilita (přenositelnost (ve strojovém kódu = binární) možnost přenosu programů napsaných a odladěných na jednom počítači na jiný počítač a to bez úprav. Zajišťována je většinou kompatibilita programů ve zdrojové formě (nutný nový překlad) v menší míře je zajištěna kompatibilita v cílové formě (strojovém kódu). 3. Kompatibilita dat zajišťuje možnost přenosu datových souborů připravených pro jeden počítač na počítač jiný. Kompatibilita médií – například standard diskety (3,5’, 5,25’,8’) Kompatibilita kódu – stejný kód na daném médiu (disketě) Kompatibilita struktury dat na daném médiu 4. Kompatibilita obsluhy shodná komunikace uživatele či operátora s počítačem (na úrovni OS či ASW) 5. Další validita (W3C), přenos dat (TCP/IP),
Praktická úloha
Proveďte přehled oblastí standardizace ICT s uvedením zásadních standardů pro jednotlivé oblasti. viz jednotlivé oblasti standardizace
Pro jednotlivé oblasti ICT uveďte specifické požadavky Vaší firmy a na tomto základě definujte standardy, které ve Vašem případě použijete. Oblasti standardizace: standardizace technologická – stejné sítě (de facto standard Ethernet), stejné operační systémy (de facto standard Windows API nebo Java), stejné programové vybavení (použití imagů), datová standardizace – komunikace mezi jednotlivými systémy např. pomocí webových služeb, XML, podle příslušných standardů W3C. Standardizace procesů řízení IT – např. s využitím ITILu, manuál kvality podle ISO, atd. - 5/6 -
1.5 Standardy a normy v IS/IT
- 6/6 -
1.5 Standardy a normy v IS/IT
1.2 Standardy a normy v IS/IT Druhy a oblasti standardů v IT. De jure standardy, de facto standardy, orgány pro tvorbu a dohled nad standardy, přínosy standardizace.
1.
Druhy a oblasti standardů
1.1.
Druhy- je níže zmíněné věcné? Kompatibilita slučitelnost určité složky výpočetního systému X se shodnou složkou systému Y tj. možnost použít tuto složku ze systému X bez úprav v systému Y. 1. Technická kompatibilita kompatibilita procesoru shodný soubor instrukcí nebo soubor instrukcí jednoho procesoru je exaktní podmnožinou instrukčního souboru druhého procesoru. kompatibilita přídavných zařízení možnost připojení daného zařízení ke kanálu nebo sběrnici uvažovaného počítače, aniž by bylo nutné provádět změny na zařízení nebo na kanálu Případné problémy s kompatibilitou (zvláště přídavných zařízení) lze řešit emulací. Ta je zajištěna buď programově, pokud je zařízení programovatelné vestavěnými prostředky zařízení 2. Programová kompatibilita (přenositelnost (ve strojovém kódu = binární) možnost přenosu programů napsaných a odladěných na jednom počítači na jiný počítač a to bez úprav. Zajišťována je většinou kompatibilita programů ve zdrojové formě (nutný nový překlad) v menší míře je zajištěna kompatibilita v cílové formě (strojovém kódu). 3. Kompatibilita dat zajišťuje možnost přenosu datových souborů připravených pro jeden počítač na počítač jiný. Kompatibilita médií – například standard diskety (3,5’, 5,25’,8’) Kompatibilita kódu – stejný kód na daném médiu (disketě) Kompatibilita struktury dat na daném médiu 4. Kompatibilita obsluhy shodná komunikace uživatele či operátora s počítačem (na úrovni OS či ASW) 5. Další validita (W3C), přenos dat (TCP/IP),
1.2.
Oblasti
HW – kompatibilita technických zařízení (dříve např.IBM PC kompatibilní) Protokolů – např. síťové protokoly (TCP/IP), - 1/4 -
1.5 Standardy a normy v IS/IT
2.
Progamovacích jazyků – programovací a jiné jazyky (HTML, XML, SQL, ) Metodik (např. pro modelování UML, DFD) Řízení informatiky? Cobit, ITIL.. Aj.
De jure a defacto standardy • •
De jure standardy – standardy, které přijme některá ze standardizačních organizací, např. ISO, IEC De facto standard – taková konvence, která je všeobecně užívána jako standard, ale nebyla přijata standardizační organizací – například jej vyvinul velký producent určitého produktu, či první producent, který produkt začal vyrábět (např. Word Doc – formát f. Microsoft)
3.
Orgány pro tvorbu a dohled nad standardy
3.1.
Mezinárodní standardizační organizace •
ISO (International Organization for Standardization) = mezinárodní federací národních standardizačních orgánů.
•
IEC - International Electrotechnical Commission = je organizace, která se věnuje standardizaci v oblasti elektrotechniky a elektroniky a úzce spolupracuje s organizací ISO.
•
ITU - International Telecommunication Union = je mezinárodní organizace, založená v roce 1865. Zabývá se standardizací v oblasti telekomunikací a reprezentuje více než 170 zemí. Mezi aktivity ITU patří též tvorba standardů (nazývaných doporučení). WSSN - World Standards Services Network CEN - European Committee for Standardization = vyvíjí evropské standardy v mnoha oborech, včetně oborů elektrotechnických. Standardy pro elektrotechnické obory jsou zajišťovány sesterskou organizací CENELEC, která od roku 1984 zajišťuje spolu s CEN standardy pro země Evropského společenství. CENELEC - European Committee for Electrotechnical Standardization ETSI - European Telecommunications Standards Organisation ECMA - (European Computer Manufacturers Association) = je nezisková organizace, jejímiž členy jsou evropské firmy, které vyvíjejí, vyrábějí a prodávají hardware a software. ECMA vydala přes dvě stovky standardů IT a technických zpráv, které byly často použity jako podklady pro tvorbu ISO/IEC a ITU standardů. ECMA je aktivní především v oblasti otevřených systémů (OSI) a její technický výbor TC36 se zabývá standardy v oblasti bezpečnosti informačních systémů.
• •
• • •
3.2.
Národní standardizační organizace • •
COPANT - Pan American Standards Commission NIST (National Institute of Standards and Technology, dříve NBS resp. National Bureau of Standards),
- 2/4 -
1.5 Standardy a normy v IS/IT
•
•
3.3.
ANSI (American National Standards Institute) = standardizační organizace, která koordinuje vývoj standardů v USA. Mnohé z těchto standardů jsou využívány i mimo USA a mnohé rovněž sloužily jako předloha při vytváření standardů mezinárodních. EIA (Electronic Industries Assocation)
V České republice 1. ÚNMZ- Úřad pro technickou normalizaci, metrologii a státní zkušebnictví připravuje určení harmonizovaných českých technických norem a zajišťuje oznámení o jejich určení ve Věstníku Úřadu připravuje smluvní zabezpečení tvorby českých technických norem Českým normalizačním institutem z prostředků ze státního rozpočtu podílí se na přípravě návrhů nařízení vlády, kterými se stanoví technické požadavky na výrobky analyzuje vývoj legislativy ES s cílem iniciovat aktualizaci českých právních předpisů, zejména nařízení vlády, kterými se stanoví technické požadavky na výrobky, transponujících předpisy ES 2. ČSNI pracuje na základě pověření Ministerstva průmyslu a obchodu ČR. Plní funkci národní normalizační organizace uvnitř ČR i v zahraničí - ČSN jsou univerzální, tzn. pro všechny obory činnosti!! Základním předmětem činnosti ČSNI je: tvorba českých technických norem, vydávání a distribuce českých technických norem, poskytování informací o technických normách, spolupráce s nevládními mezinárodními a evropskými organizacemi, které se zabývají technickou normalizací. Rozhodující podíl v normotvorné činnosti má zavádění evropských norem a navazujících mezinárodních norem do soustavy ČSN, zatímco tvorba norem čistě domácího původu tvoří zbytkovou část každoročního programu normalizačních prací (okolo 10%). Normy ISO 9000 – normy pro management jakosti ČSN EN ISO 9000 Systémy managementu jakosti - Základy, zásady a slovník ČSN EN ISO 9001 Systémy managementu jakosti – Požadavky ČSN EN ISO 9004 Systémy managementu jakosti - Směrnice pro zlepšování výkonnosti Norma ISO 14000 má společné s normou ISO 9000 to, že požadavky obou norem se týkají systému řízení a lze je aplikovat ve Vaší společnosti současně. ISO 9000 určuje požadavky na kvalitu Vaší produkce, ISO 14000 určuje požadavky na Vaše chování k životnímu prostředí. Pokud získáte certifikát ISO 14000 garantujete Vaším partnerům a státní správě, že výrobu máte pod kontrolou z hlediska ohrožení životního prostředí a Vaše výrobky nejsou zhotoveny na úkor okolní přírody. Zákony stanovují: - výrobky musí být bezpečné - 3/4 -
1.5 Standardy a normy v IS/IT
-
dále odpovědnost za škodu zákon o ochraně osobních údajů
3.4.
Dokumenty a standardy Internetu- odstraněno, souhlasíte?
4.
Přínosy standardizace Důvody pro standardizaci Celosvětový pokrok v liberalizaci trhů Vzájemné ovlivnění různých sektorů trhů a jejich vývoj a integrita Usnadnění celosvětové potřeby komunikace Standardy pro infrastrukturu kompatibilita systémů Rozvoj tržního prostředí Podpora růstu jakosti
- 4/4 -
1.5 Standardy a normy v IS/IT
1.2 Standardy a normy v IS/IT Druhy a oblasti standardů v IT. De jure standardy, de facto standardy, orgány pro tvorbu a dohled nad standardy, přínosy standardizace.
1.
Druhy a oblasti standardů
1.1.
Druhy- je níže zmíněné věcné? Kompatibilita slučitelnost určité složky výpočetního systému X se shodnou složkou systému Y tj. možnost použít tuto složku ze systému X bez úprav v systému Y. 1. Technická kompatibilita kompatibilita procesoru shodný soubor instrukcí nebo soubor instrukcí jednoho procesoru je exaktní podmnožinou instrukčního souboru druhého procesoru. kompatibilita přídavných zařízení možnost připojení daného zařízení ke kanálu nebo sběrnici uvažovaného počítače, aniž by bylo nutné provádět změny na zařízení nebo na kanálu Případné problémy s kompatibilitou (zvláště přídavných zařízení) lze řešit emulací. Ta je zajištěna buď programově, pokud je zařízení programovatelné vestavěnými prostředky zařízení 2. Programová kompatibilita (přenositelnost (ve strojovém kódu = binární) možnost přenosu programů napsaných a odladěných na jednom počítači na jiný počítač a to bez úprav. Zajišťována je většinou kompatibilita programů ve zdrojové formě (nutný nový překlad) v menší míře je zajištěna kompatibilita v cílové formě (strojovém kódu). 3. Kompatibilita dat zajišťuje možnost přenosu datových souborů připravených pro jeden počítač na počítač jiný. Kompatibilita médií – například standard diskety (3,5’, 5,25’,8’) Kompatibilita kódu – stejný kód na daném médiu (disketě) Kompatibilita struktury dat na daném médiu 4. Kompatibilita obsluhy shodná komunikace uživatele či operátora s počítačem (na úrovni OS či ASW) 5. Další validita (W3C), přenos dat (TCP/IP),
1.2.
Oblasti
HW – kompatibilita technických zařízení (dříve např.IBM PC kompatibilní) Protokolů – např. síťové protokoly (TCP/IP), - 1/3 -
1.5 Standardy a normy v IS/IT
2.
Progamovacích jazyků – programovací a jiné jazyky (HTML, XML, SQL, ) Metodik (např. pro modelování UML, DFD) Řízení informatiky? Cobit, ITIL.. Aj.
De jure a defacto standardy • •
De jure standardy – standardy, které přijme některá ze standardizačních organizací, např. ISO, IEC De facto standard – taková konvence, která je všeobecně užívána jako standard, ale nebyla přijata standardizační organizací – například jej vyvinul velký producent určitého produktu, či první producent, který produkt začal vyrábět (např. Word Doc – formát f. Microsoft)
3.
Orgány pro tvorbu a dohled nad standardy
3.1.
Mezinárodní standardizační organizace • • • • • • •
3.2.
Národní standardizační organizace • • • •
3.3.
ISO (International Organization for Standardization) IEC - International Electrotechnical Commission ITU - International Telecommunication Union WSSN - World Standards Services Network CEN - European Committee for Standardization CENELEC - European Committee for Electrotechnical Standardization ETSI - European Telecommunications Standards Organisation
COPANT - Pan American Standards Commission NIST (National Institute of Standards and Technology, dříve NBS resp. National Bureau of Standards), ANSI (American National Standards Institute) EIA (Electronic Industries Assocation)
V České republice 1. ÚNMZ- Úřad pro technickou normalizaci, metrologii a státní zkušebnictví připravuje určení harmonizovaných českých technických norem a zajišťuje oznámení o jejich určení ve Věstníku Úřadu připravuje smluvní zabezpečení tvorby českých technických norem Českým normalizačním institutem z prostředků ze státního rozpočtu podílí se na přípravě návrhů nařízení vlády, kterými se stanoví technické požadavky na výrobky analyzuje vývoj legislativy ES s cílem iniciovat aktualizaci českých právních předpisů, zejména nařízení vlády, kterými se stanoví technické požadavky na výrobky, transponujících předpisy ES 2. ČSNI - 2/3 -
1.5 Standardy a normy v IS/IT
pracuje na základě pověření Ministerstva průmyslu a obchodu ČR. Plní funkci národní normalizační organizace uvnitř ČR i v zahraničí - ČSN jsou univerzální, tzn. pro všechny obory činnosti!! Základním předmětem činnosti ČSNI je: tvorba českých technických norem, vydávání a distribuce českých technických norem, poskytování informací o technických normách, spolupráce s nevládními mezinárodními a evropskými organizacemi, které se zabývají technickou normalizací. Rozhodující podíl v normotvorné činnosti má zavádění evropských norem a navazujících mezinárodních norem do soustavy ČSN, zatímco tvorba norem čistě domácího původu tvoří zbytkovou část každoročního programu normalizačních prací (okolo 10%). Normy ISO 9000 – normy pro management jakosti ČSN EN ISO 9000 Systémy managementu jakosti - Základy, zásady a slovník ČSN EN ISO 9001 Systémy managementu jakosti – Požadavky ČSN EN ISO 9004 Systémy managementu jakosti - Směrnice pro zlepšování výkonnosti Zákony stanovují: - výrobky musí být bezpečné - dále odpovědnost za škodu - zákon o ochraně osobních údajů
3.4.
Dokumenty a standardy Internetu- odstraněno, souhlasíte?
4.
Přínosy standardizace Důvody pro standardizaci Celosvětový pokrok v liberalizaci trhů Vzájemné ovlivnění různých sektorů trhů a jejich vývoj a integrita Usnadnění celosvětové potřeby komunikace Standardy pro infrastrukturu kompatibilita systémů Rozvoj tržního prostředí Podpora růstu jakosti
- 3/3 -
1 IT trh – strukturalizace, možnosti a problémy jeho analýzy • • • •
• • •
Objem domácího IT trhu: €3,2 mld. (2007), tedy asi 90 mld. Kč, meziroční růst 8 až 9 % (pro srovnání: obrat Škoda Auto a.s. je asi 200 mld. Kč) Prodej PC za rok: kolem 1 mil. ks (2007), meziroční růst 25 %. Instalovaná báze PC: 4,6 mil. ks (konec roku 2007) Počet uživatelů Internetu: cca polovina populace ve věku nad 15 let (4,4 mil. lidí) neboli 40 % domácností (1,68 mil. domácností), to představuje cca 20. místo v Evropě (za ČR je Slovensko, Řecko, Bulharsko, Makedonie, Rumunsko; první tři: Island, Nizozemsko, Dánsko) Pro srovnání: objem celosvětového trhu IT je asi €980 mld., aktuální meziroční růst: 5,5 % Z toho Evropa (bez bývalého SSSR) představuje asi €340 mld., aktuální meziroční růst: 4,4 % HDP je asi 3400 mld. Kč, IT trh tedy představuje asi 2,5 % HDP
1.1 Dodavatelské členění IT trhu: • • • • • •
Distributoři (velkoobjemoví a specializovaní) Systémoví integrátoři, dodavatelé IT služeb Dodavatelé PC („garáže“, lokální assembleři, zahraniční A-značky) Internetové firmy (ISP, web design, dodavatelé obsahu, e-byznys, infrastrukturní služby) – přesahují do ICT segmentu ISV (krabicový software, software na zakázku) Další typy firem (zastoupení zahraničních výrobců, koncoví prodejci, retailové řetězce...)
1.2 Největší distributoři (ČR+SK): • • • • •
eD‘ system Czech BGS Levi Group Tech Data Distribution AT Computers SWS
9,8 mld. 9,1 mld. 6,0 mld. 5,5 mld. 3,3 mld.
1.3 Příležitosti IT trhu: • • • • • • •
Silný růst celého IT a ITC segmentu v porovnání s ostatními vertikálami Zavádění ERP a podobných systémů v podnicích Rostoucí počet uživatelů Internetu, vznik a nárůst poptávky domácností Celková změna životního stylu obyvatel ČR Rostoucí počet platebních a kreditních karet (meziroční nárůst 40 %) Zákon o elektronickém podpisu a další legislativní úpravy Mimořádně silná instalovaná báze mobilních telefonů (meziroční nárůst 64 %)
1.4 Hrozby IT trhu: • • •
Neschopnost IT dodavatelů plnit vlastní sliby Neschopnost zákazníků využít IT efektivním způsobem Nižší kupní síla obyvatelstva než v západní Evropě, příliš pomalý trend k vyrovnávání
• • • •
Nízká úroveň penetrace PC a Internetu Chybí tradice nakupování podle katalogu Softwarové pirátství Generační propast, rostoucí sociální rozdíly (podle příjmu, národnosti, lokality apod.)
1.5 Předpokládaný další vývoj: • • •
Dnešní stav trhu je důsledkem akvizic (Logica/FCC, debis/Oasa, Synergon/Infinity, S&T/Neos, ICL/PC-DIR, Ness/APP, Prokom/PVT…) – těžko se výrazně změní, už není koho koupit Prodejci hardwaru se musí transformovat na vyšší přidanou hodnotu, jinak neobstojí (do 2 až 3 let) Budování outsourcingových center (IBM, Accenture, DHL…), poskytování služeb na dálku
1.6 Trendy v IT: V roce 2006 byly hlavní dva trendy využívání softwaru jako služby a virtualizace. Pokud se ptáte na to, jak moc se tyto trendy skutečně nakonec realizovali, tak v případě softwaru jako služby je vidět, že adopce tohoto modelu mezi velkými firmami je značná. V roce 2007 jsou trendy jiné. Prvním je přechod k servisně orientované architektuře (SOA). 64% respondentů odpovědělo, že plánují implementovat SOA během přístího roku. Obhájci SOA očekávají, že pomůže udělat IT více flexibilní, otevřené a efektivní a to tím, že zajistí komunikaci a spolupráci mezi systémy. Docela zajímavý je fakt, že 48% CIOs řeklo, že plánují implementovat SOA aby zajistili integraci s externími obchodními partnery v roce 2007. Druhým trendem je pak aplikace principů štíhle výroby (lean-manufacturing) do datových center. Datová centra v posledních letech ohromně narostla, je problematické je řídit, provádět v nich změny a dochází v nich k plýtvání. Tyto centra potřebují velké prostory jsou velmi náročné na spotřebu energie a musí se o ně starat hodně lidí. Cílem aplikování principů štíhlé výroby je zabránit plýtvání a zvýšit produktivitu práce (občas se tímto principem podařilo zlepšit produktivitu práce až o 40%).
1.7 Další: • • • •
Otevřené systémy (je možné přidávat a odebírat funkční moduly). Třívrstvá architektura ASW. Distribuované zpracování založené na klient - server architektuře. Grafické a multimediální uživatelské rozhraní.
1.8 Top firmy v ČR pro rok 2008: Ocenění TOP 10 SI (podle abecedy, tučně top3)
Ocenění TOP 10 ICT (abecedně):
LogicaCMG s.r.o. SAP ČR, spol. s r.o Telefónica O2 Czech Republic, a.s.
ADASTRA, s.r.o. AutoCont CZ a.s. HEWLETT-PACKARD s.r.o. IBM Česká republika, spol. s r. o. Logica Czech Republic s.r.o. MICROSOFT s.r.o. Oracle Czech, s.r.o.
Systemový integrator desetiletí HEWLETT-PACKARD s.r.o.
SAP ČR, spol. s r.o. Sun Microsystems Czech s.r.o. Unicorn, a.s. Tabulka 1 - http://demo.hottop.cz/top-systemovych-integratoru/vysledky-2008/
1.4 Řízení informačních systémů
1.4 Řízení informačních systémů Úrovně a oblasti řízení informačních systémů. Charakterizujte možné varianty řešení IS/ICT podniku z hlediska zodpovědnosti za tvorbu, integraci a provoz IS/ICT. Analyzujte přínosy a rizika těchto variant. Současné problémy a omezení rozvoje řízení IS/ICT.
1. Úrovně a oblasti řízení IS/IT1 Řízení informatiky probíhá ve třech úrovních. Každá z úrovní se člení na domény2 (oblasti) řízení a ty pak obsahují jednotlivé procesy a funkce řízení. 1.1. Úrovně řízení IS/IT • strategická
Formulace IST
• taktická
Řízení rozvoje IS/IT a systémová integrace služeb a zdrojů
Specifikace informatických služeb
Řízení poskytování informatických služeb
Řízení ekonomiky a efektů podnikové inf. Řízení lidských zdrojů
Řízení datových zdorjů
Řízení ICT zdrojů a konfigurací
• operativní Řízení jednotlivých projektů
Řízení provozu IS/ICT
1.1.1. Strategické řízení Tvorba informační strategie (koncepce dalšího rozvoje informatiky na 2-3 roky, aktualizace ročně) využití standartních metod strategického řízení – SWOT, BSC, RPZ
formulace základních strategických cílů
analýza současného stavu
analýza dosahování očekávnaých efektů návrh inovované architektury služeb a aplikací
1.1.2. Řízení rozvoje IS/IT a systémová integrace služeb a zdrojů • plánování, zadávání a koordinace projektů
periodické zpracování souhrnných plánů projektů a údržby celého IS
prvotní specifikace nových projektů – formulace projektových záměrů řízení úloh systémové integrace (aplikační, datová, technologická, metodologická)
výběrová řízení (na outsourcovaná řešení)
1
zpracováno dle Principy a modely řízení podnik.informatiky, Voříšek – referenční model ITGPM
2
domén je tak celkově 10 - 1/4 -
1.4 Řízení informačních systémů
1.1.3. Specifikace informatických služeb • optimalizace striktury a kvality služeb informatiky, zajištění souladu s nároky podniku (organizačními,
ekonomickými, obchodními) a s legislativou, řízení vztahů k externím dodavatelů, řešení dlouhodobých kooperačních vztahů
identifikace potřeb a sestavení poptávky služeb a požadavků na služby
analýza ICT služeb dostupných na trhu a výěr dodavatelů
specifikace struktury a obsahu služeb – definice katalogu služeb, ceník služeb pro interní útvary příprava a uzavírání SLA
prodej ICT služeb externím partnerům n. zákazníkům 1.1.4. Řízení poskytování informatických služeb
• plánování a vyhodnocování kvalitativních charakteristik poskytovaných služeb – bezpečnost,
spolehlivost, flexibilita, výkon
řízení dostupnosti (analýzy mezi smluvenou a reálnou dostupností…)
řízení bezpečnosti (vytvoření a aktualizace bezpečnostní politiky)
řízení flexibility informatických služeb
řízení výkonu a škálování průběžný reporting a analýzy
1.1.5. Řízení ekonomiky a efektů podnikové inf. • finanční plánování informatiky a tvorba rozpočtů, analýza nákladů a dosahovaných efektů, sledování i
mimoekonomických efektů • cíl – dosažení optimálního poměru cena/výkon
účtování poskytovaných služeb a plateb za externí služby analýzy nákladů (např. ABC)
analýzy efektů informatiky (plánovaných a realizovaných)
hodnocení návratnosti investic do informatiky (např. ROI, NPV) příprava investičních plánů
tvorba a kontrola plnění rozpočtu 1.1.6. Řízení lidských zdrojů
analýzy a plánování personálních kapacit
přijímání nových pracovníků
plánování školení a rekvalifikace
realizace školení 1.1.7. Řízení datových zdrojů
analýzy stavu a řízení kvality datových zdrojů
plánování rozvoje dat. zdorjů
řízení datové integrace 1.1.8. Řízení ICT zdrojů a konfigurací
• analýzy, výběr a pořízení všech komponent ICT technologií (ASW, SŘBD, OS, tech a kom.
prostředků a jejich konfigurací)
analýza stavu a kvality technologických zdrojů a požadavků na ně
- 2/4 -
1.4 Řízení informačních systémů
konfigurační řízení (evidence konfigurací, analýza změn, analýza provozních problémů, analýza nových možností na trhu)
obnova a rozvoj technologických zdorjů (výběr a pořizování nových technických a sw prostředků, řízení upgrade stávajících, vyřazování nepotřebných) 1.1.9. Řízení jednotlivých projektů
• vlastními silami X dodavatelsky • typ projektu (ERP,CRM,…) • IASW X TASW
analýza průběhu a operativní řízení projektu
administrace projektu
akceptační a předávacíí řízení 1.1.10. Řízení provozu IS/ICT
správa technologických zdrojů – sledování a kontrola jednotl. komponent, administrace serverů a DB, správa LAN/WAN řízení uživatelských požadavků – registrace požadavků na service desk, kategorizace úrovně požadavku, vyhodnocení a ocenění, operativní řešení požadavku, kumulace požadavků a jejich ocenění, vyhodnocování a statistiky požadavků a jejich řešení
řízení a provoz aplikací – plánování zařazení aplikace do provozu, distribuce a automatická instalace SW, příprava scriptů pro nasazení nového SW, kompletace provozní dokumentace
řízení incidentů – evidence, vyhodnocování a řešení incidentů
řízení problémů - evidence, vyhodnocování a řešení problémů, sledování vztahů mezi incidenty a problémy
2. Charakterizujte možné varianty řešení IS/ICT podniku z hlediska zodpovědnosti za tvorbu, integraci a provoz IS/ICT. Analyzujte přínosy a rizika těchto variant. Varianta
Pozitiva
Negativa
I. Vlastní vývoj IASW, nákup ostaních komponent, integrace vlastními silami
• • •
• •
• •
II. Vývoj IASW externí firmou, nákup ostaních komponent, integrace vlastními silami
• • • •
III. Nákup všech komponent (vč. TASW) od různých výrobců a zajištění integrace vlastními silami
• • • • •
IS šitý na míru potřebám podniku inkremnetální vývoj dle funkcí know-how o provozovaném systému je v podniku konkurence nezná silné a slabé stránky provozovaného systému snadná reakce na okmažité potřeby uživatelů
IS šitý na míru potřebám podniku inkrementální vývoj dle funkcí konkurence nezná silné a slabé stránky provozovaného systému optimální využití zanlosti interních a externích specialistů rychlá realizace nejnižší náklady lze vybrat osvědčenou část pro každou část IS TASW obsahuje nejlepší zkušenosti širokého okruhu uživatelů TASW je parametrický
- 3/4 -
• • • • • • • • • • • •
vysoké náklady nejsou do IASW zabudovány osvědčené metody a postupy dlouhá doba řešení nižší kvalita IASW, obtížná integrace celého IS/IT nízká parametričnost řešení (řešení mnohdy reaguje na okamžité požadavky - malá snaha o generalizaci řešení) nekonzistence řešení při fluktuaci řešitelů vysoké náklady (vyšší než u v.I.) dlouhá doba řešení (kratší než u v.I.) obtížná integrace celého IS/IT nízká parametričnost rizika úniku důvěrných informací mimo podnik procesy v podniku se musejí přizpůsobovat TASW vysoké nároky na řešitelský tým (obtížná integrace, pokud různé části od různých dodavatelů) nízká stabilita (obtížná údržba vazeb mezi aplikacemi)
1.4 Řízení informačních systémů IV. Nákup celého IS/IT od generálního dodavatele systémového integrátora
V. Tvorba IS generálním dodavatelem - systémovým integrátorem a outsourcing provozu části nebo celého IS/IT
• • •
nejrychlejší realizace nízké náklady profesionální řešení každé komponenty i celého IS/IT • lze vybrat osvědčená řešení pro každou část IS • TASW obsahuje nejlepší zkušenosti širokého okruhu uživatelů • TASW je parametrický • dodavatel garantuje vývoj TASW • rozložení rizik mezi S. integrátora a podnik viz varianta 4 a navíc. • • • •
snížení nároků na provozní personál snadnější přizpůsobování kapacit IT dle potřeb podniku výnoisy z rozsahu u S. integrátora mohou snížit náklady u zákazníka ještě více než u v.IV. využívání nejprogresivnějších technologií z důvodu specializace S. Integrátora
• • •
procesy v podniku se musí přizpůsobit TASW velká závislost na generálním dodavateli a jeho (serióznosti, schopnostech, stabilitě) růziko úniku důvěrných ionformací mimo podnik
viz varianta 4 a navíc. • •
další růst závislosti na S. integrátoru další zvýšení rizika úniku informací
3. Problémy a omezení rozvoje řízení IS/IT nepochopení informatiky a jejích možností – informatika pouze podpůrná činnost, žrout peněz vazba informatiky a vlastního businessu náročnost na zdroje (personální, finanční, časové, znalostní) dynamika oboru – těžký výběr partnerů vykazování přínosů finanční krize – mylný krok utínání investic do inovací
4. Praktická úloha Úloha - předpoklady: Jste asistentem vedoucího informatiky obchodní firmy se silnými pobočkami dislokovanými po celé republice. Informační systém je založen na několika produktech. Vaším úkolem je navrhnout novou koncepci řízení IS/ICT pro celou firmu. Zadání: Z čeho budete vycházet, jaké podklady si zajistíte ? - Globální strategii, vstupní info do IST= analýza IS konkurence, klíčových partnerů, dostupný TASW na trhu, nákladové ukazatele našeho současného SW atd.
Co bude hlavním obsahem navržené koncepce ?
- Body zmíněné v IST, čili cílový stav- Globální a detailní architektura S kým budete daný problém řešit ? Nejen s IT oddělením, ale i s vedoucími jednotlivých úseků (nákup, výroba, prodej, marketing, ekonomické atd.), se zástupcem skupiny uživatelů systému, se šéfem☺
Jaké varianty přicházejí v úvahu ?
- TASW, IASW, různé možnosti vývoje, integrace a správy- buď vlastními silami, nebo externí společností, Saas, outsourcing Jaký předpokládáte další postup ? - navrhnuté změny předat ke schválení vrcholnému vedení, výběr dodavatele, uzavření smlouvy, zavedení, provoz.....
- 4/4 -
1.4 Řízení informačních systémů
1.4 Řízení informačních systémů Úrovně a oblasti řízení informačních systémů. Charakterizujte možné varianty řešení IS/ICT podniku z hlediska zodpovědnosti za tvorbu, integraci a provoz IS/ICT. Analyzujte přínosy a rizika těchto variant. Současné problémy a omezení rozvoje řízení IS/ICT.
1.
Úrovně a oblasti řízení IS/IT
1.1.
Úrovně řízení IS/IT • • •
strategická – formulace IST, řešení zásadních koncepčních otázek, výběr externích partnerů, stanovení projektů atd. taktická – převážně řízení jednotlivých projektů, analytické a projekční činnosti, řízení vazeb na ostatní projekty (?), implementace projektů ad. operativní – zejména řízení provozu IS, instalace produktů, údržba HW i SW, monitorování systému atd.
1.2.
Úrovně a jejich oblasti
1.2.1.
Strategická úroveň
Cíl – dlouhodobý rozvoj ve vazbě na strategické a podnikatelské záměry společnosti Náplň – formulace a periodická aktualizace celkové koncepce IS/IT = informační strategie Vstupy – podnikatelská strategie + strategie dílčí (obchodní, marketingová, atd.) Výstupy – nová nebo aktualizovaná informační strategie Zodpovědnost - Za strategické řízení IS/IT podniku je zodpovědný informační manažer, formulovat strategické záměry v informatice musí celé vedení podniku.
Hlavní náplň: Tvorba IST- z toho vše odvodit- co se musí při tvorbě IST dělat
1.2.2.
Analýzy strategických záměrů celého podniku
Analýza stavu IS/IT a jeho okolí
Přehodnocení cílového stavu IS/IT
Specifikace nových informačních služeb pro zákazníky
Strategie outsourcingu
Řízení vztahů s externími partnery v oblasti IS/IT
Aktualizace systému řízení IS/IT
Plánování investic do IS/IT
Plánování stěžejních projektů IS/IT
Časový plán realizace strategických záměrů
Zajišťování trvalé informovanosti pracovníků o rozvoji IS/IT
Taktická úroveň Rozvoj organizace ve vazbě na informatiku
- 1/7 -
1.4 Řízení informačních systémů
Cíl – optimalizace organizačního uspořádání firmy v souladu s možnostmi informačních technologií v rámci permanentního zkvalitňování péče o zákazníka. Vstupy – informační strategie podniku – rozvoj podniku a jeho dopady do organizace podniku, platný organizační řád podniku, zákony, směrnice, nařízení, které se promítají do ASW, dokumentace systému řízení podnikové informatiky Výstupy – úpravy či návrhy úprav organizační dokumentace podniku Zodpovědnost – různá řešení, doporučuje se provázanost s útvary odpovědnými za organizaci podniku
Hlavní náplň: Sledování zákonů a předpisů
Změny podnikových procesů a podnikové organizační struktury
Řízení a organizace informatiky v podniku
Definování vztahů útvarů informatiky na ostatní organizační jednotky podniku
Poznámka: může spadat i do strategické úrovně. Řízení ekonomiky IS/IT Finanční plánování v oblasti IS/IT, analýzy nákladů a dosahovaných efektů. Cíl – dosažení optimálního poměru cena/výkon Vstupy – informační strategie, podklady z účetnictví (náklady, efekty) Výstupy – nákladové analýzy na IS/IT, finanční plány a rozpočty Zodpovědnost – většinou informační manažer + pracovníci úseku IT a ekonomičtí specialisté
Hlavní náplň: Koncepce sledování a vyhodnocování nákladů a přínosů IS/IT
Dlouhodobé plánování nákladů na IS/IT
Zpracování rozpočtů na provoz a rozvoj IS
Kalkulace nákladů na IS/IT
Evidence nákladů na IS/IT v rámci analytického účetnictví
Analýza nákladů na IS/IT podle zvolených hledisek
Analýzy a návrh cenové strategie za služby
Analýzy dosahovaných efektů
Personální řízení IS/IT Plánování personálních kapacit, kvalifikační rozvoj pracovníků. Cíl – takový rozvoj kvalifikace a znalostí pracovníků firmy, které zaručí efektivní využití vložených investic do informatiky (řízení znalostí podniku) Vstupy – informační strategie, podklady z podnikové personalistiky, potřeby personálních kapacit projektů Výstupy – plány rozvoje personálních kapacit, školení, rekvalifikace Zodpovědnost – informační manažer
- 2/7 -
1.4 Řízení informačních systémů
Hlavní náplň: Analýzy vlastních pracovních kapacit
Hodnocení personálního zajištění IS/IT
Plánování stavu personálu pro IS/IT
Operativní evidence pracovníků
Kvalifikační programy v oblasti IS/IT
Operativní plánování a zajištění jednotlivých odborných školení
Řízení disponibility – systémových vlastností
Plánování a vyhodnocování průřezových charakteristik celého inf. systému podniku Cíl – dosažení požadovaných provozních charakteristik IS za přijatelných nákladů Vstupy – informační strategie, organizační řád, provozní řád IS/IT, podnikové bezpečnostní směrnice, dokumenty ISO 9000 Výstupy – definování specifických projektů rozvoje bezpečnosti, spolehlivosti, výkonu, nové či upravené podnikové směrnice Zodpovědnost – informační manažer, vedoucí provozu IT, týká-li se to specifické oblasti – pracovník dané oblasti
Hlavní náplň: Řízení bezpečnosti IS/IT
Řízení systémové doby odezvy
Řízení pružnosti (flexibility) systému
Řízení datových zdrojů
Projektování interních i externích datových zdrojů, nikoli správa databází Cíl – dosažení optimálního rozsahu a kvality dat pro provozované aplikace, žádoucí poměr mezi vlastními a externími zdroji Vstupy – informační strategie, operativní evidence využívaných dat. zdrojů a projekční a provozní dokumentace Výstupy – plány rozvoje a integrace datových zdrojů včetně externích.
Hlavní náplň: Analýza stavu interních datových zdrojů, databází
Plánování rozvoje interních datových zdrojů
Analýzy potřeb a možností externích datových zdrojů
Analýzy možností a plánování mobilních databází
Prezentace ve veřejných datových zdrojích a službách
Řešení integrace databází a datových zdrojů
Řízení informačních technologií
Analýza, výběr, pořízení všech komponent informačních technologií – DB systémů, operačních systémů, technických prostředků. Cíl – rozvíjet a naplňovat kvalitní technologickou architekturu systému a vytvořit tak předpoklad pro efektivní provoz IT, min.nákladů na správu, prostor pro rozšiřování. - 3/7 -
1.4 Řízení informačních systémů
Vstupy – informační strategie – definice základní koncepce rozvoje, studie specializovaných firem na analýzy trendů IT, analýzy trhů atd. Výstupy – konkretizace a detailizace technologické architektury IS/IT, stanovení standardů a požadavků na výběr komponent, plány a požadavky na upgrade, atd. Zodpovědnost – pověřený specialista (vedoucí rozvoje IT, systémový architekt, atd.)
Hlavní náplň: Řízení technologické architektury
Pořízení nových komponent technologického prostředí
Řízení upgrade všech komponent HW, ZSW
Řízení technologické integrace
Systémová podpora provozu
Definování standardů a pravidel pro použití IT
Řízení rozvoje aplikací – zadávání a koordinace projektů Projekty IS/IT – formulace zadání, posuzování, způsob řešení – řízení rozvoje celkové funkcionality IS/IT podniku. Cíl – směřovat IS/IT k optimální funkcionalitě – pokrytí všech potřebných funkcí aplikační produkty, redukovat duplicity. Řídící procesy směřují k obsahové optimalizaci zadání nových projektů a současně k časové synchronizaci řešených projektů. Vstupy – informační strategie, celková, funkční a procesní architektura, evidence uživatelských požadavků na nové funkce a služby. Výstupy – zadávací dokumentace projektů a dokumentace výběrových řízení (až smlouva s dodavatelem) Zodpovědnost – za nové projekty – vedoucí oddělení vývoje IS/IT, u větších projektů celé vedení firmy. Hlavní náplň: Analýzy uživatelských požadavků na rozšíření a rozvoj IS/IT
1.2.3.
Vstupní analýzy před zahájením projektu
Specifikace projektů, projektový záměr
Posuzování projektových záměrů
Rozhodnutí o přijetí či nepřijetí projektu a způsobu řešení
Zadání projektu řešitelskému týmu
Realizace výběrového řízení (v případě dodavatelského řešení) - postup
Kontraktační řízení na úvodní studie
Operativní úroveň Implementace a zavádění- nepatří spíše do taktické úrovně? Implementace/customizace
Testovací procedury
Příprava provozu a migrace
Předávací procedury
- 4/7 -
1.4 Řízení informačních systémů
Řízení provozu Veškeré řídící aktivity spojené s provozem celého informačního systému a jeho jednotlivých komponent. Cíl – zajisti provoz jednotlivých aplikací a požadovanou úroveň konzultační a technické podpory. Vstupy – provozní dokumentace projektů. Výstupy – provozní dokumentace – deníky sítě, serverů, databází, hot-line, help-desk. Zodpovědnost – vedoucí provozu IT Hlavní náplň: Plánování zařazování projektů do provozu
2.
Přebírání projektu do provozu
Provoz Hot-line a Help-desk
Řízení správy serverů, sítě a databází
Správa koncových stanic sítě
Výběr a nákup počítačového materiálu
Zajištění spojení s okolím a připojení do externích sítí
Charakterizujte možné varianty řešení IS/ICT podniku z hlediska zodpovědnosti za tvorbu, integraci a provoz IS/ICT. Analyzujte přínosy a rizika těchto variant. Varianta I. Vlastní vývoj IASW, nákup ostaních komponent, integrace vlastními silami
Pozitiva • • • • •
IS šitý na míru potřebám podniku inkremnetální vývoj dle funkcí know-how o provozovaném systému je v podniku konkurence nezná silné a slabé stránky provozovaného systému snadná reakce na okmažité potřeby uživatelů
Negativa • • • • •
• II. Vývoj IASW externí firmou, nákup ostaních komponent, integrace vlastními silami
• • •
III. Nákup všech komponent (vč. TASW) od různých výrobů a zajištění integrace vlastními silami
• • •
•
• •
vysoké náklady nejsou do IASW zabudovány osvědčené metody a postupy dlouhá doba řešení nižší kvalita IASW, obtížná integrace celého IS/IT nízká parametričnost řešení (řešení mnohdy reaguje na okamžité požadavky - malá snaha o generalizaci řešení) nekonzistence řešení při fluktuaci řešitelů
IS šitý na míru potřebám podniku inkrementální vývoj dle funkcí konkurence nezná silné a slabé stránky provozovaného systému optimální využití zanlosti interních a externích specialistů
• • • • •
vysoké náklady (vyšší než u v.I.) dlouhá doba řešení (kratší než u v.I.) obtížná integrace celého IS/IT nízká parametričnost rizika úniku důvěrných informací mimo podnik
rychlá realizace nejnižší náklady lze vybrat osvědčenou část pro každou část IS TASW obsahuje nejlepší zkušenosti širokého okruhu uživatelů TASW je parametrický
•
procesy v podniku se musejí přizpůsobovat TASW vysoké nároky na řešitelský tým (obtížná integrace, pokud různé části od různých dodavatelů) nízká stabilita (obtížná údržba vazeb mezi aplikacemi)
- 5/7 -
•
•
1.4 Řízení informačních systémů IV. Nákup celého IS/IT od generálního dodavatele systémového integrátora
• • • • • • • •
V. Tvorba IS generálním • dodavatelem • systémovým integrátorem a • outsourcing provozu části nebo celého IS/IT •
3.
nejrychlejší realizace • nízké náklady profesionální řešení každé komponenty i • celého IS/IT lze vybrat osvědčená řešení pro každou • část IS TASW obsahuje nejlepší zkušenosti širokého okruhu uživatelů TASW je parametrický dodavatel garantuje vývoj TASW rozložení rizik mezi S. integrátora a podnik viz varianta 4 a navíc. snížení nároků na provozní personál snadnější přizpůsobování kapacit IT dle potřeb podniku výnoisy z rozsahu u S. integrátora mohou snížit náklady u zákazníka ještě více než u v.IV. využívání nejprogresivnějších technologií z důvodu specializace S. Integrátora
• •
procesy v podniku se musí přizpůsobit TASW velká závislost na generálním dodavateli a jeho (serióznosti, schopnostech, stabilitě) růziko úniku důvěrných ionformací mimo podnik
viz varianta 4 a navíc. další růst závislosti na S. integrátoru další zvíšení rizika úniku informací
Problémy a omezení nepochopení informatiky a její možností vazba informatiky a vlastního businessu náročnost na zdroje (personální, finanční, časové, znalostní) dynamika oboru – těžký výběr partnerů
- 6/7 -
1.4 Řízení informačních systémů
4.
Praktická úloha
Úloha - předpoklady: Jste asistentem vedoucího informatiky obchodní firmy se silnými pobočkami dislokovanými po celé republice. Informační systém je založen na několika produktech. Vaším úkolem je navrhnout novou koncepci řízení IS/ICT pro celou firmu. Zadání:
Z čeho budete vycházet, jaké podklady si zajistíte ? - Globální strategii, vstupní info do IST= analýza IS konkurence, klíčových partnerů, dostupný TASW na trhu, nákladové ukazatele našeho současného SW atd.
Co bude hlavním obsahem navržené koncepce ? - Body zmíněné v IST, čili cílový stav- Globální a detailní architektura
S kým budete daný problém řešit ? Nejen s IT oddělením, ale i s vedoucími jednotlivých úseků (nákup, výroba, prodej, marketing, ekonomické atd.), se zástupcem skupiny uživatelů systému
Jaké varianty přicházejí v úvahu ? - TASW, IASW, různé možnosti vývoje, integrace a správy- buď vlastními silami, nebo externí společností
Jaký předpokládáte další postup ? - navrhnuté změny předat ke schválení vrcholnému vedení, výběr dodavatele, uzavření smlouvy, zavedení, provoz.....
- 7/7 -
1.5 Vztah globální a informační strategie podniku
1.9
Vztah globální a informační strategie podniku Charakterizujte obsah globální a informační strategie podniku a jejich vzájemné časové a obsahové vazby. Význam, cíle a obsah informační strategie. Vazba IST a jednotlivých projektů. Kritické faktory úspěchu IST.
1.
Charakterizujte obsah globální a informační strategie podniku a jejich vzájemné časové a obsahové vazby.
1.1.
Obsah globální strategie -
-
dává smysl všem podnikovým aktivitám a směřuje podnik kupředu je tvořena cca na 2-3 roky v případě že GST chybí, pak se podnik vyvíjí živelně, trvá-li toto delší dobu, dohází k separátním zájmům např. v jednotlivých oddělení => silná bariera v prosazování změn v podniku GST nestačí pouze formulovat, ale musí být také prosazována GST je živý dokument, prochází cyklem = formulace – realizace – vyhodnocení (interval cca 1 rok, čili po roce minimálně vyhodnotit, popř. změnit) Určuje: • hlavní zaměření podniku • podnikové cíle, kterých má být dosaženo • zdroje pro realizaci cílů • odpovědné osoby za realizaci cílů Konceptuální model GST:
-
1) SWOT - 1/6 -
1.5 Vztah globální a informační strategie podniku
Prvním krokem při formulaci GST dle MDIS je tzv. SWOT analýza (strengths, weaknesses, opportunities, threats), která analyzuje externí možnosti a hrozby a interní silné a slabé stránky podniku. Dle MMDIS se SWOT dělí na externí a interní faktory. Externí= Strenghts, Weakness, Interní = Opportunity, Threats. Externí Interní -
Vlastníci podniku Zákazníci Dodavatelé Aliance a jejich členové Konkurenti Rozvoj technologie Podmínky v zemi- ekonomické, legislativní, politické, sociální, geografické atd. Vrcholové řízení Marketing Nákup Výroba Prodej Ekonomika Organizace a řízení Pracovníci HR atd.
Kritické faktory Po analýze jednotlivých externích a interních faktorù ( ze SWOT) následuje vymezení kritických faktorù rozvoje podniku. Při vymezení kritických faktorù se bere v úvahu závažnost (význam) každého faktoru a doba jeho působení. Současně se analyzují vzájemné vztahy faktorů a vymezují se oblasti "výzev" a "nebezpečí" pro podnikání podniku. Globální strategie by měla být pochopitelně formulována tak, aby podnik maximálně využil svých silných stránek a externích příležitostí a eliminoval své slabé stránky a vyhnul se externím hrozbám. krit. faktory viz tabulka ve Voříškově černé knize str. 242! 2) Na základě provedené a vyhodnocené SWOT analýzy se ve druhém kroku tvorby globální strategie formuluje poslání (mission) podniku. Poslání definuje smysl existence firmy, tj. mìlo by odpovídat na následující otázky: a) jaké potřeby chce firma uspokojit ? b) jakých skupin zákazníkù ? c) v jakém teritoriu ? d) jakou technologií ? 3) V třetím kroku tvorby GST se definují globální podnikové cíle, jejichž dosažením se naplní poslání podniku a uspokojí zájmy vlastníků podniku. Globální cíle se formulují na období tří až pěti let, a to ve čtyřech rovinách: cíle z hlediska vlastníků podniku , cíle z hlediska vrcholového vedení podniku , cíle z hlediska pracovníků podniku, - 2/6 -
1.5 Vztah globální a informační strategie podniku
cíle z hlediska společnosti . 4) Aby podnik dosáhl svých cílù, vykonává řadu tzv. globálních podnikových funkcí. Vymezení těchto funkcí a celopodnikových programů (projektů) rozvoje je náplní čtvrtého kroku tvorby GST. Typickými globálními funkcemi výrobního podniku jsou: vrcholové řízení a organizace, nákup, výroba,skladování/služby, prodej (marketing, odbyt), výzkum & vývoj, personální řízení, finanční řízení, informatika. Celopodnikové programy rozvoje jsou návrhem alternativních cest dosažení podnikových cílů. Např teda pro cíl proniknutí na nový trh je program specifikace postupu vytvoření sítě distributorů v daném teritoriu.
5) Posledním krokem tvorby GST, který je současně přechodem k implementaci globální strategie je tvorba strategií jednotlivých globálních podnikových funkcí (prodeje, výroby, informatiky atd.). GST je jednak zdrojem, na který všechny dílčí strategie navazují, a jednak nástrojem pro udržení konzistence a vzájemných vazeb mezi globálními podnikovými funkcemi. Konzistence je zajišťována celopodnikovými programy, které koordinují hlavní procesy probíhající na základě dílčích strategií. Například proniknutí do nového teritoria bude vyžadovat koordinaci marketingu (zmapování trhu v daném teritoriu), výroby (výroba produktů pro nový trh), odbytu (vytvoření nových distribučních kanálů), informatiky (informační podpora nové výroby a odbytu), personálního řízení (zajištění pracovníků pro práci v novém teritoriu) atd.
2.
Význam, cíle a obsah IST Cílem IST je navrhnout celkovou koncepci IS/IT podniku tak, aby byly optimálně podpořeny celopodnikové cíle definované v globální podnikové strategii a navrhnout jednotlivé kroky realizace IS/IT (= jednotlivé verze IS/IT) Význam IST: informační strategie je modelem budoucího stavu IS/IT spolu s globální podnikovou strategií zajišťuje: integraci vizí a idejí integraci podniku s okolím integraci interních podnikových procesů Dále: IST
navrhuje technologickou integraci IS/IT navrhuje celkovou architekturu IS/IT určuje legislativní rámec a standardy závazné pro celý IS/IT definuje všechny informační projekty podniku (stávající i budoucí) časový horizont: 2 – 3 roky (vzhledem k rychlosti změn ekonomického prostředí i IT) periodické aktualizace informační strategie (1/2 – 1 rok) dostupnost informační strategie všem zainteresovaným pracovníkům - 3/6 -
1.5 Vztah globální a informační strategie podniku
Obsah Struktura informační strategie Shrnutí (5 – 8 stran) nejhrubší pohled na IS/IT shrnuje základní závěry a doporučené strategie Hlavní část (80 – 120 stran) zdroje, cíle a východiska zpracování informační strategie analýza a hodnocení současného stavu IS/IT v podniku a ve světě návrh cílového stavu IS/IT způsob transformace ze současného do cílového stavu Přílohy podrobné informace týkající se jednotlivých analýz a návrhů Zde může být skryta podotázka obsah IST- viz. obr. Voříšek str. 254
Konceptuální model tvorby IST
Na cílový stav IS/ICT působí tyto vstupní materiály: 1. stav IS/ICT konkurence 2. hodnocení stavu IS/ICT klíčových partnerů 3. hodnocení ASW, který je na trhu – co můžeme při stavbě IS využít 4. hodnocení trendů IS/IT -jakým směrem se má Is ubírat 5. výsledky SWOT analýzy 6. podnikové cíle a jejich priority 7. výsledky BPR ( business process reengeneering) 8. požadavky uživatelů Cílový se stav se skládá z: - globální architektury - dílčích architektur: - 4/6 -
1.5 Vztah globální a informační strategie podniku
Dílčí architektury a jejich hlavní výstupy: o
o
o
o
o
o
o
3.
Funkční a procesní - kontextový diagram znázorňující externí partnery a důležité externí vazby - hierarchie funkcí - seznam a periodicita klíčových událostí - určení maximální doby reakce na klíčové události - schémata popisující procesy - vztah funkcí k ostatním dimenzím Datová - Rozlišení a návrh interních a externích zdrojů - Hlavní datové objekty - Vztah k ostatním dimenzím Technologická - Povinné a volitelné standardy - Návrh celé koncepce ochrany a zabezpečení Softwarová - Požadavky na softwarové komponenty - Návrh celkové softwarové architektury - Specifikace ISW, ASW, vývojového prostředí - Vztah k ostatním dimenzím Hardwarová - Požadavky na technické zdroje - Návrh celkové architektury - Specifikace jednotlivých komponent - Vztah k ostatním dimenzím Organizační a legislativní aspekty - Zákony, normy a směrnice, které se vztahuji k IS - Návrh změn v organizaci vzhledem k novému IS - Oblasti vývoje, které budou outsourcouvány - Změny pracovní náplně funkčních míst - Vztah k ostatním dimenzím Personální, sociální a etické aspekty - Vliv IS/IT na profesní a kvalifikační strukturu pracovníků podniku - Návrh kvalifikačních programů - Struktura školení
Vazba IST a jednotlivých projektů.
Projekty jsou způsobem přechodu ze současného do budoucího stavu. Musí být integrované navzájem a musí být aktualizovány na základě měnících se interních i externích podmínek podniku
4.
Kritické faktory úspěchu IST -
kvalita GST
-
míra přijetí pracovníky vývoje
-
atd...:)
- 5/6 -
1.5 Vztah globální a informační strategie podniku
5.
Praktická úloha
Vyberte si podnik z libovolného sektoru ekonomiky. V rámci toho se rozhodujete o příslušných nástrojích. Zákazník požaduje v rámci vývoje specifikovat i informační strategii a žádá, aby specifikace návrhu systému byla (pokud možno přímo v CASE) maximálně formálně (říká dokonce "automatizovaně") navázána na informační strategii. Zadání:
Které hlavní cíle určí IST a proč ? -
Jaké zdroje bude podnik potřebovat k dosažení těchto cílů ? -
určí čeho chceme pomocí projektů směřujících podnikovou informatiku ze současného do stavu budoucího dosáhnout. Prostor pro fantazii:) lidské, finanční, materiální, know-how atd
Rozhodněte, zda se vůbec dá informační strategie (semi)formálně modelovat. Znáte na to nějaké nástroje? Jaké vidíte základní prvky takového (semi)formálního modelu? -
podle mne se dají modelovat dílčí architektury- např. funkční a procesní pomocí CASE- procesní diagramy, kontextové diagramy apod.
- 6/6 -
1.06 Podnikové procesy a vývoj IS/ICT
1.06 Podnikové procesy a vývoj IS/ICT
Důvody a podstatné rysy reengineeringu podnikových procesů (BPR). Statický versus procesní pohled na podnik. Úloha IS/ICT v BPR a v řízení podnikových procesů. Úloha procesního řízení podniku ve vývoji IS/ICT podniku. Analyzujte vliv různé míry podrobnosti definice podnikového procesu na kreativitu pracovníků realizujících proces, na standardizaci procesu, na náklady návrhu a náklady realizace procesu, na možnosti predikce nákladů a doby trvání procesu, na využitelné ASW pro podporu procesu, na flexibilitu procesu, na podnikovou kulturu.
1.1.
Podnikový proces Proces – je účelně naplánovaná a realizovaná posloupnost činností, ve které za pomoci odpovídajících zdrojů probíhá transformace vstupů na požadované výstupy. Podnikový proces – je proces, kterým podnik zajišťuje naplnění podnikových cílů, reaguje na významné události a zajišťuje produkci plánovaných výstupů (produktů, služeb apod.) Podnikové procesy: • Hlavní • Řídící • Podpůrné Hlavní proces
Řídící proces
Podpůrný proces
Přidává proces hodnotu?
ano
Ne
Ano/ne
Probíhá proces napříč společností?
Ano
Ano/ne
Ne
Má proces externí zákazníky?
Ano
Ne
Ne
Generuje proces tržby?
ano
Ne
ne
Proces může být popsán/nadefinován pomocí celé řady charakteristik: • Cíle procesu • Událost aktivující celý proces • Vlastník procesu = role, resp. funkční místo zodpovědné za návrh procesu • Kvalitativní a kvantitativní metriky • Omezující podmínky procesu • Výstupy procesu • Seznam činností procesu • Návaznost činností • Vstupy a výstupy každé činnosti
- 1/4 -
1.06 Podnikové procesy a vývoj IS/ICT
1.2.
BPR (Business process reengineering) BPR – Radikální rekonstrukce (redesign) podnikových procesů tak, aby mohlo být dosaženo dramatického zdokonalení v kritických parametrech výkonnosti, jako jsou kvalita, služby a rychlost. Důvodem pro tyto změny je neustále rostoucí konkurence na světových trzích. Dnes již nestačí na trh prostě přijít, dnes se jedná o boj o přežití. Podnikům přestávaly stačit jen přírůstková zlepšení, začaly vyžadovat dramatické a průkopnické změny, a to hned. Tyto posuny v konkurenčním prostředí mají globální dosah a jen málo oblastí podnikání si mohlo dovolit se jim vyhnout, resp. necítit je tak dramaticky. Jedním z přístupů k dramatickým změnám a dramatickému zlepšení, který se v 90. letech objevil, byl BPR.
1.3.
Statický vs. procesní pohled na podnik Statický pohled – klasický pohled na podnik podle jeho funkčních organizačních celků (finance, marketing, prodej, výroba, nákup atd.). Firmu již ale nelze řídit na základě pevně definované organizační struktury, kde každý zaměstnanec má své předem určené místo, definovanou odpovědnost a k tomu příslušné pravomoci. Takové řízení totiž předpokládá především pevně definovanou strukturu činností a jejich návazností, představu přesně definované a především neměnné posloupnosti činností. Od takto řízené firmy pak nelze očekávat patřičnou pružnost, variantnost postupů, ani přílišnou nahraditelnost pracovníků, jak vyžadují dnešní podmínky. Procesní pohled – namísto pevné struktury je základem organizace nového typu představa podnikových procesů jako souboru činností, které vyžaduje jeden nebo více vstupů a tvoří výstup, jenž představuje hodnotu pro zákazníka. Procesy jsou tedy chápány účelově a vždy ve vazbě na zákazníka. Tímto pojetím procesů je dána i jejich případná hierarchie – hlavní či klíčové procesy jsou ty řetězce činností, jimiž přímo vzniká hodnota pro zákazníka, u ostatních musíme hledat jejich smysl v podpoře oněch klíčových. Procesy a jejich vztahy tedy tvoří základ organizace, vše ostatní má již povahu infrastrukturní a jej od základní struktury procesů odvozeno: organizační a komunikační struktura, IS a další případná technologie.
1.4.
Úloha IS/ICT v BPR a v řízení podnikových procesů Role informační technologie je v BPR nezastupitelná, nicméně by to nemělo vést k názoru, že změny, které BPR provádí, jsou ryze technologickou záležitostí. Je zřejmé, že vývoj informační technologie dodal tu poslední kapku, kterou přetekl pohár starého (statického) způsobu řízení, což ale neznamená, že by právě ta poslední kapka měla být tou nejdůležitější. Při řízení podnikových procesů se však dnes bez podpory IS/ICT nelze prakticky obejít. Z hlediska podpory byznysu je nedůležitější komponentou aplikační software (ASW). Je určen pro podporu podnikových procesů, individuální a skupinovou práci uživatelů a pro poskytování informací vyžadovaných a zpracovávaných v rámci jednotlivých byznys funkcí. Podle účelu, pro který je ASW použit lze rozlišit několik základních druhů ASW: ERP, CRM, SCM, ECM, BI atd. IS/ICT zdroje jsou poskytovány uživatelům prostřednictvím služeb. ICT služby podporují jednotlivé podnikové procesy.
- 2/4 -
1.06 Podnikové procesy a vývoj IS/ICT
1.5.
Úloha procesního řízení podniku ve vývoji IS/ICT podniku Při vývoji IS/ICT je znalost podnikových procesů nezbytnou nutností. Realizaci IS/ICT podniku lze provést několika způsoby. Je možné jít cestou IASW, TASW nebo nákupem informatických služeb. V každé variantě je ale nutné mít k dispozici popis podnikových procesů, aby bylo možné vyvinout nový IS na míru (v případě IASW) nebo prozkoumat produkty TASW, zda jejich funkce pokrývají potřebné spektrum podnikových procesů. Bez znalosti podnikových procesů může při vývoji IS/ICT dojít k výrazným pochybením a následných ztrátám, způsobených dodáním nebo vyvinutím nevyhovujícího IS/ICT.
1.6.
Podrobnost definice podnikového procesu KBPR - Knowledge Based Process Reengineering Detailní definice procesu může mít řadu předností: •
každý průběh procesu a výstup procesu jsou identické s ideálním stavem, který byl při návrhu procesu požadován,
•
průběh procesu má dobře predikovatelnou dobu trvání i dobře predikovatelné náklady,
•
většinu činností procesu mohou vykonávat relativně nekvalifikované (nicméně dobře zaškolené) pracovní síly,
•
veškerá kreativita byla vynaložena specialisty při návrhu procesu, kreativita při průběhu procesu naopak může mít negativní dopady
KBPR rozlišuje čtyři úrovně návrhu a optimalizace procesu, úrovně se liší zejména v tom, jaké znalosti a zkušeností se předpokládají na straně: •
firmy (akumulované firemní znalosti)
•
pracovníků podílejících se na průběhu procesu
(1) První nejméně podrobná úroveň definice procesu popisuje proces pomocí těchto charakteristik: •
cíle procesu,
•
událost aktivující daný proces,
•
vlastník procesu = role, resp. funkční místo zodpovědné za celý proces,
•
zákazník procesu,
•
kvalitativní a kvantitativní metriky procesu a
•
omezující podmínky/pravidla procesu (např. finanční nebo časový limit pro průběh procesu).
Každá další úroveň definice procesu přejímá popisné charakteristiky předcházející úrovně a přidává další charakteristiky: (2) v druhé úrovni je navíc definován •
výstup procesu
(3) ve třetí úrovni jsou navíc definovány •
seznam činností
•
seznam rolí, resp. funkčních míst
•
seznam všech externích vstupů do procesu, ale bez přiřazení k činnostem - 3/4 -
1.06 Podnikové procesy a vývoj IS/ICT
(4) ve čtvrté úrovni jsou navíc definovány •
návaznost činností
•
vstupy a výstupy každé činnosti
•
přiřazení zodpovědných rolí k jednotlivým činnostem
•
doba trvání činnosti
•
náklady činnosti
Úloha - předpoklady: Jste vedoucím projektu vývoje IS/ICT v jistém podniku a právě tvoříte plán tohoto projektu. V podniku právě probíhá reengineering podnikových procesů konzultační firmou. Nikdo v podniku (včetně zástupců vrcholového vedení) Vám není schopen odpovědět na otázky dopadu a směru budoucího vývoje reengineeringu, všichni Vás odkazují na experty od dodavatelské firmy, kteří Vám však, jako konkurentovi, odmítají podat jakékoliv informace. Zadání:
Jaký vliv bude mít skutečnost probíhajícího reengineeringu na postup Vašeho projektu?
Skutečně Vám náleží informace o dopadech a směru budoucího vývoje reengineeringu a pokud ano, jak je hodláte získat?
Čím přitom budete argumentovat?
• Vliv BPR je zcela zásadní, je nutná spolupráce na obou projektech a kooperace obou firem • Informace jsou nezbytně nutné pro výběr správného ASW (TASW nebo vývoj IASW). Pokud by každý projekt probíhal nezávisle, výsledek by mohl být katastrofální – IS/ICT, který zcela nevyhovuje novým podnikovým procesům. Hodlám apelovat na vedení podniku, aby přiměl konzultační firmu ke spolupráci, jinak odstupuji z vedení projektu. • Vývoj IS/ICT bez znalosti podnikových procesů není možný, výsledek by mohl přivést firmu do nemalých potíží. IS/ICT může být naprosto nepoužitelný.
- 4/4 -
1.11 Systémová integrace
1.11 Systémová integrace Charakterizujte cíle a základní principy systémové integrace. Další možné materiály, z kterých lze vycházet: https://akela.mendelu.cz/~loucka/studium/7sem/IIS/p%F8edn%E1%9Aky/kapit2.doc otázka vychází e stejnojmenné kapitoly ve Voříšek, černá knížka, str.100
1.
Cíle systémové integrace Jeden ze systematických a praxí ověřených postupů k vývoji a provozu IS/IT, zaměřený na minimalizaci rizik a maximalizaci efektů IS/IT. Cílem SI je vytvoření a permanentní údržba integrovaného informačního systému, který optimálně využívá potenciálu dostupných IT k maximální podpoře podnikových cílů. Informační systém je přitom vytvářen integrací různých zdrojů, tj. různých produktů a služeb.
2.
Principy vývoje IS/IT
požadované funkce IS jsou odvozeny od podnikových cílů a potřeb podnikových procesů
IS je řešen a realizován jako komplexní informační systém vytvořen z řady různých komponent různých výrobců. hlavní komponenty jsou: o o o o
o
o
počítače a přídavná zařízení sítě LAN a WAN ZSW: řídí využití zdrojů počítačů a počítačové sítě (OS, SW pro řízení sítě, RDBMS) TESW (technologicky orientovaný typový software): podporuje základní administrativní činnosti a komunikaci mezi pracovníky (workflow, text. editor, tab. kalkulátor, email) ASW: pro podporu výrobních, ekonomických, distribučních a dalších procesů podniku. 1. TASW - standardizované řešení informačního systému podniku (výrobní, distribuční apod. podnik) 2. IASW - individuální ASW šité na míru potřebám podniku interní a externí datové zdroje
Komplexní je informační systém v tom smyslu, že podporuje všechny významné podnikové procesy a všechny potřebné lokality podniku IS je realizován jako integrovaný komplex služeb (projekční, implementační, instalační, školící, apod.)
IS je realizován jako otevřený systém na bázi mezinárodních i podnikových standardů, zajišťující podniku nezávislost na určitém výrobci techniky a SW IS je rozvíjen pomocí jednotné metodiky
- 1/4 -
1.11 Systémová integrace
2.1.
IS je provozován na základě jednotné vrstvy pravidel, které musí dodoržovat všichni uživatelé
Složky SI
Integrace dat Integrace aplikací (funkce, software, data) Integrace podnikových procesů a funkcí IS/IT Integrace uživatelských rozhraní aplikací Integrace metodická Integrace hardwarová a technologická
vývoj integrace – viz. Voříšek
2.2.
Úrovně SI
integrace vizí
integrace podniku s okolím
integrace interních podnikových procesů
technologická integrace (data, HW, SW, uživatelské rozhraní)
- 2/4 -
1.11 Systémová integrace
Úloha - předpoklady: Jste reprezentantem dodavatelské firmy, působící jako systémový integrátor pro vámi zvoleného zákazníka. Zadání:
Jaké budou hlavní principy systémové integrace, o něž budete řízení rozvoje IS/IT opírat ? Jaké požadované služby od vás, jako systémového integrátora, bude zákazník zřejmě očekávat a jak je zajistíte ? Demonstrujte možné chyby v integraci IS/IT zákazníka a popište způsob jejich řešení.
Jaké budou hlavní principy systémové integrace, o něž budete řízení rozvoje IS/IT opírat? viz obecné principy. Jaké požadované služby od vás, jako systémového integrátora, bude zákazník zřejmě očekávat a jak je zajistíte ?
spolupráce na tvorbě a aktualizaci informační strategie tvorba úvodní studie (specifikace produktů, služeb, času, financí, atd. pro projekt) návrh architektury celého IS/IT aby bylo MOŽNO o budovat IS/IT jako stavebnici z komponent o přizpůsobovat IS/IT podnikovým změnám (cílům, vizím) o přizpůsobovat IS/IT novým možnostem v IT
dodání metodiky vývoje IS/IT; nutno definovat:
odpovědnost integrátora a zákazníka v procesu vývoje IS/IT, licenční a leasingové podmínky na služby integrátora typové etapy vývoje IS/IT, vč. vstupů, výstupů, metod a řešení způsob a dokumentace předání, testování a vyhodnocení kvality komponent a služeb o způsob podávání, řešení a dokumentace reklamací plánování projektu a tvorba harmonogramu
řízení projektu
konzultace optimalizace podnikových procesů zajištění dodávek a instalací HW a SW komponent, vč. dokumentace. Jedná se o tyto komponenty: o HW (servery, koncové stanice, tiskárny a další přídavná zařízení) o kabeláž o síťový SW o OS o RDBMS o DWH o CASE, 4GL , apod. o technologicky orientovaný SW(OIS, EDI, workflow, apod.) o ASW koordinace subdodávek
o o o o
zajištění všech služeb (servis, údržba, konzultace, školení, apod.) související s integrací všech komponent udržování dokumentace - 3/4 -
1.11 Systémová integrace
garance funkčnosti a kvality
dle POUR:
projekční služby (analýza, návrh, implementace a instalace jednotlivých komponent IS/IT) výběr vhodných produktů pro realizaci projektů - od aplikačního sw až po dílčí technické prostředky instalační služby - technických prostředků, kabeláže, ZSW školící služby - pro všechny typy komponent IS/IT a skupiny uživatelů, kde je školení účelné nebo je vyžadováno podíl na řízení projektů a provozu IS/IT zajišťování permanentního rozvoje IS/IT v souvislosti s novými funkčními požadavky, datovými zdroji, rozvojem IT a rozvojem znalostí uživatelské sféry
Demonstrujte možné chyby v integraci IS/IT zákazníka a popište způsob jejich řešení? viz předchozí. (Rizika)
- 4/4 -
1.8 Metodiky vývoje IS
1.8 Metodiky vývoje IS Charakterizujte a zhodnoťte různé přístupy k analýze a návrhu informačního systému (datový, funkční, objektový, inkrementální, prototypový, implementací ASW atd.). Vysvětlete smysl, obhajte účel a vyjmenujte základní vlastnosti metodiky vývoje IS. Popište specifika a problémy zavedení metodiky do používání v organizaci. Vyjmenujte Vám známé metodiky a klasifikujte je. Jejich výhody, možná nebezpečí, možnosti kombinace těchto přístupů.
1.
Přístupy k analýze a návrhu informačního systému
1.1.
Strukturovaná analýza a návrh (1989)
Podstatnou vlastností je oddělení pohledu na funkce a data. Většina strukturovaných metod se snaží tento problém řešit definicí různě složitých pravidel pro zajištění konzistence. Základem strukturovaného návrhu jsou moduly, které si mezi sebou předávají data a řídící informace (signály) Tento přístup je dneska už totálně out. Ve skriptech je to zařazeno jen kvůli porozumění architektuře starších systémů. Dnes frčí objektový přístup.
- 1/4 -
1.8 Metodiky vývoje IS
1.2.
Objektový přístup
S nástupem objektového orientace byl bordel v notacích a výrobci CASE nástrojů s tim měli problém. Proto vzniklo UML, které umožňuje modelovat tyto diagramy: • užití - use case • tříd – class • objektů – object • sekvenční – semence • spolupráce – collaboration • aktivit – activity • stavový – state • komponent – component • balíčků – package • nasazení – deployment Jednotlivé typy diagramů reprezentují různé dimenze pohledu na navrhovaný systém. Můžeme je dělit z pohledu na statické a dynamické a také na lidské (spojení s realitou) a technické.
1.3.
Komponentový vývoj
Je nejmodernější přístup na poli návrhu a implementace IS. Komponenta je část sw, která byla navržena tak, aby ji bylo možné znovu použít. Požadavky na komponentu: zapouzdření, znovupoužitelnost, dokumentace, parametrizovatelnost, standardní rozhraní, nezávislá testovatelnost, nezávislá na programovacím jazyce. Často je diskutován rozdíl mezi třídou a komponentou. Třída je však spjata s implementačním prostředím, kdežto komponenta je zcela zapouzdřená a nezávislá na prog. jazyce. Komponentový vývoj lze realizovat např. v COM, CORBA, J2EE, .NET. - 2/4 -
1.8 Metodiky vývoje IS
2.
Vysvětlete smysl, obhajte účel a vyjmenujte základní vlastnosti metodiky vývoje IS •
systematický přístup k tvorbě IS, který jasně vymezuje postup a obsah jednotlivých fází vývoje IS/IT. • Metodika je explicitní způsob strukturování myšlení a konání. Metodika obsahuje model, který reflektuje zvolené pohledy na realitu a který vychází z množiny filosofických paradigmat. Metodika musí říkat „jaké“ kroky a „jak“ je vykonat, ale nejdůležitější je, aby řekla proč se mají vykonat. Metodika je souhrnem • etap, • přístupů, • zásad, • postupů, • pravidel, • dokumentů, • řízení, • metod a nástrojů, který pokrývá celý životní cyklus informačního systému. Metodika by se měla vztahovat na všechny prvky IS (pracovníky, organizační procedury, data, SW, HW a další), organizační vlivy IS, ekonomické otázky spojené s vývojem a provozem IS a doporučené dokumenty způsobu řízení IS
Každá metodika MUSÍ (požadavky na metodiku): • • • •
3.
deklarovat soubor hodnot, na kterých je založena, resp. kterých chce u budovaného IS/IT dosáhnout (min. náklady tvorby, krátká doba řešení, apod.) určovat postup řešení, aby bylo možné celý proces vývoje IS plánovat určit priority řešení (co kdy a kde je důležité) doporučit metody, techniky a nástroje pro jednotlivé etapy řešení
Specifika a problémy zavedení metodiky do používání v organizaci • • • • • • • •
4.
metodik je velké množství a nejsou jednotně popsány obtížně je lze srovnávat a vyhledat vhodnou metodiku mnohé metodiky se zaměřují jen na určité aspekty vývoje, jen na určité fáze živ.cyklu většinou jsou zaměřeny jen na vývoj nového SW tradiční rigorózní metodiky pro současné projekty nevyhovují většina metodik je v angličtině
Klasifikace metodik
( Jejich výhody, možná nebezpečí, možnosti kombinace těchto přístupů) Rozsah: •
metodiky pokrývající celý životní cyklus vývoje . např. MMDIS viz dále - 3/4 -
1.8 Metodiky vývoje IS
• dílčí metodiky – zabývají se jen částí životního cyklu IS – např. jen návrh a implementace Podrobnost: •
těžké metodiky o podrobný popis o rigorózní • lehké metodiky o minimálně dostatečná metodika o agilní metodiky Přístup k vývoji: • strukturované metodiky • RAD metodiky - RAD nástroje, prototypování • objektově orientované metodiky Způsob vývoje: • •
tradiční metodiky s vodopádovým životním cyklem metodiky pro iterativní a přírůstkový vývoj
Nejlepší je prostě MMDIS!!! Proč dělat kompromisy? ☺
- 4/4 -
1.13 Metodiky vývoje IS
1.13 Metodiky vývoje IS
Vysvětlete smysl, obhajte účel a vyjmenujte základní vlastnosti metodiky vývoje IS. Popište specifika a problémy zavedení metodiky do používání v organizaci. Vyjmenujte Vám známé metodiky a klasifikujte je.
1.1.
Metodika •
systematický přístup k tvorbě IS, který jasně vymezuje postup a obsah jednotlivých fází vývoje IS/IT.
•
Metodika je explicitní způsob strukturování myšlení a konání. Metodika obsahuje model, který reflektuje zvolené pohledy na realitu a který vychází z množiny filosofických paradigmat. Metodika musí říkat „jaké“ kroky a „jak“ je vykonat, ale nejdůležitější je, aby řekla proč se mají vykonat.
Metodika je souhrnem •
etap,
•
přístupů,
•
zásad,
•
postupů,
•
pravidel,
•
dokumentů,
•
řízení,
•
metod a nástrojů,
který pokrývá celý životní cyklus informačního systému. Metodika by se měla vztahovat na všechny prvky IS (pracovníky, organizační procedury, data, SW, HW a další), organizační vlivy IS, ekonomické otázky spojené s vývojem a provozem IS a doporučené dokumenty způsobu řízení IS Každá metodika MUSÍ (požadavky na metodiku): deklarovat soubor hodnot, na kterých je založena, resp. kterých chce u budovaného IS/IT dosáhnout (min. náklady tvorby, krátká doba řešení, apod.) určovat postup řešení, aby bylo možné celý proces vývoje IS plánovat určit priority řešení (co kdy a kde je důležité) doporučit metody, techniky a nástroje pro jednotlivé etapy řešení vyjmenujte základní vlastnosti metodiky vývoje IS.
- 1/5 -
1.13 Metodiky vývoje IS
1.2.
Obecné principy:
orientace na cíle a problémy: východisko tvorby IS=cíle a problémy účast zadavatele na projektu: protože vedení organizace má odpovědnost na obsahu realizovaného IS, musí se aktivně podílet na vývoji . klíčové dokumenty a jejich schvalování: dokumenty, které podléhají schválení ze strany vedení =klíčové; bez schválení nelze pokračovat ve vývoji IS, toto zajišťuje účast vedení na projektu zapojení uživatele do návrhu: klíčoví uživatelé (s pravomocí rozhodovat) se musí účastnit projektu modelování a abstrakce, princip tří architektur: vytvoření modelu úrovní modelů systému vede k oddělení podstaty systému od omezení vyplývající ze zvolené technologie a implementačního prostředí. ověřování a testování návrhu během celého vývoje: nutnost ověřování zda, každá činnost splňuje přepokládaný stav. realizuje se prostřednictvím řídících komisí a schvalovacích procedur. v každé etapě probíhá analýza a návrh: v jednotlivých etapách se analyzují požadavky na systém a zpodrobňují se pouze na takovou úroveň, aby bylo možné na základě takto provedené analýzy, navrhnout systém tak, aby mohla být zahájena další etapa. požadavky se pouze zpodrobňují. při změně nadřízeného požadavku, je nutné změnu provést až v etapě, kde byl daný požadavek zaveden. takto se změna požadavku promítne do všech etap, ve kterých se požadavek vyskytuje. vývoj probíhá z hlediska všech pohledů na systém: v každé etapě je třeba analyzovat a navrhovat na odpovídající úrovni podrobnosti: o data o funkce o organizace o sociální a psychologická hlediska o technologie o ekonomická hlediska otevřenost metodiky: musí být postavena na běžně používaných metodách a technikách vývoje IS a měla by být schopna vstřebat veškeré nové poznatky na tomto poli. umožňuje top použití CASE nástrojů. Každá metodika tak kompatibilní s s většinou standardních metodik vývoje IS.
Vysvětlete smysl obhajte účel
1.3.
Smysl metodiky: základním přínosem zavedení metodiky tvorby informačního systému je zvýšení kvality vyvíjených informačních systémů vč. zvýšení konkurenceschopnosti firmy na trhu. toho je dosahováno především toho, že metodika umožní:
dosáhnout větší produktivity a kooperace projektových týmů vytvořit přesně definovaný komunikační standard pro jednotlivé typy funkčních míst, a to jak tvůrců, tak i uživatelů systému. vetší specializaci projektových týmů a jejich členů na jednotlivé etapy životního cyklu vývoje IS získat větší nezávislost vyvíjených, či již vytvořených informačních systémů na konkrétních řešitelích - 2/5 -
1.13 Metodiky vývoje IS
dosáhnout větší pružnosti vytvářených IS vzhledem k vývoji potřeb uživatelů získat kvalitní a aktuální dokumentaci k IS dosáhnout efektivnější údržby IS definovat kritéria kvality vytvářených IS pro každou etapu životního cyklu vývoje IS pro každou etapu vývoje IS kvalitněji řídit a kontrolovat práci na projektech snížit rizika vyčerpání zdrojů na nerealizované IS, tj. soustředit se na vyvíjený systém především v počátku vývoje IS a odhalit nerealizovatelnost vývoje získat větší možnost přenositelnosti do jiných implementačních prostředí získat jasně určená východiska a kritéria pro výběr a použití prostředků CASE
Metodika má sloužit jako základní standard tvorby IS
1.4.
Specifika zavádění metodiky do používání: zavádění metodiky do organizace má vliv na celou organizaci jako celek. základem zavedení metodiky je výchozí verze metodiky tvorby IS pro organizaci. Výchozí verzi je nutné před použitím v reálné situaci upravit pro specifické podmínky v organizaci. dále je nutné provést změny v sociálně psychologické oblasti - protože musí být věcí lidí v organizaci. lidé budou s metodikou pracovat. nutno vytvořit vstupní podmínky pro metodiku:
příznivé sociálně psychologické klima dostatečná kvalifikace pracovníků v oblasti metod technik a nástrojů vývoje IS jednotně koordinovaná a řízená organizační struktura vývoje IS, výsledkem je vytvořené metodické centrum, jehož náplní je údržba a rozvoj metodiky
Zavádění metodiky má své činnosti (řádky) a své fáze (sloupce)
výběr pilotního projektu vyškolení pracovníků získávání školitelů sociálně psychologická centra budování metodického centra pilotní projekt vyhodnocení pilotního projektu úprava metodiky na základě pilotního projektu rozšíření metodiky v organizaci
1.5.
příprava zavádění X X
pilotní projekt
úprava metodiky
rozšiřování metodiky
X
X
X
X X
X
X X
X
X X X X
Klasifikace metodik: metodiky lze koupit v podobě: vytištěných publikací hypertextových souborů školení, kurzů klasifikace: - 3/5 -
1.13 Metodiky vývoje IS
státem podporované (stát vyžaduje při státních zakázkách použití definované metodiky, případně je jím vlatníkem a zodpovídá za vytváření nových verzí metodik) o SSADM (Structured Systems Analysis and Design Method) - Velká Británie o SDM (System Development Methodology) - Holandsko o MERISE - Francie o V-MODEL - Neměcko Mezinárodní(zaměřené na pracovníky statní správy) o Euromethod - EU o Software Life-Cycle Process - ISO Firemní metodiky (ve vlastnictví významných firem, škol, institucí ... apod.) o IE (Information Engineering Methodology - James Martin and Co.) o SE (LBMS System Engineering) o ORACLE CASE Metohd (Oracle Corp.) o Accelerated System Development for Client/Server (Ernest and Young) o RAP (Rapid Application Prototyping - Texas Instruments) o RSDM (Rapid System DevelopmentMethodology - Bechman Information Systems)
zájem firemních metodik: specifický postup vývoje IS a tomu příslušné nástroje a pravidla, CASE zájem státních a eurometod: integrovat jednotlivé vyvíjené systémy tak, aby vzájemně tvořily systém
Úloha - předpoklady: Jste projektantem IS v podniku. Řešíte problémy výběru a uplatnění standardní metodiky vývoje Vašeho informačního systému. Zadání:
Jaké otázky si položíte a jak je budete řešit. Jak budete při výběru vhodné metodiky postupovat ?
Jaké otázky si položíte a jak je budete řešit? Otázky budou vycházet z obecných charakteristik metodik, tj. budeme vztahovat metodiku na konkrétní organizaci a následně vyhodnocovat její úspěšnost v aplikaci na definovanou organizaci. zkoumáme jak efektivně metodika naplňuje svůj smysl, tj. co nejkvalitnější výsledný IS jaká je orientace metodiky na cíle a problémy? jak se účastní zadavatel na projektu? jaké jsou klíčové dokumenty a jak probíhá jejich schavalování? jak probíhá zapojení uživatele do návrhu? jak probíhá ověřování a testování návrhu během celého vývoje? jak se zpracovávají změny požadavků? jak probíhá vývoj IS z hlediska všech pohledů na systém: (data, funkce, organizace, sociální a psychologická hlediska, technologie, ekonomická hlediska) jak velká je otevřenost metodiky - 4/5 -
1.13 Metodiky vývoje IS
Rovněž je nutné stanovit jak daná metodika reflektuje současné trendy (str. 45 Řepa) Trendy: nahrazování vodopádového postupu tvorby IS postupy iterativními pronikání objektových charakteristik globalizace pojetí analýzy posun od hard k soft metodikám zohlednění postupu implementace TASW Jak budete při výběru vhodné metodiky postupovat ? opatrně a obezřetně zaeviduju zhodnotím vyberu implementuju
- 5/5 -
1.9 Multidimenzionální přístup k řešení IS
1.9 Multidimenzionální přístup k řešení IS
Cíle multidimenzionálního přístupu k vývoji IS/IT. Dimenze řešení informačního systému (datová, funkční, organizační, pracovní, ekonomická, softwarová, hardwarová, časová, metodická apod.). Vztah dimenzí a fází životního cyklu projektu, modifikace vah dimenzí s ohledem na podmínky řešení projektu. Metainformační systém jako nástroj řízení vývoje integrovaného IS/IT.
1.1.
Cíle multidimenzionálního přístupu
Multidimenzionalita = řešení IS/IT souběžně ze všech pohledů, které ovlivňují efektivitu IS/IT a vzájemné ovlivňování těchto faktorů. Multidimenzionalita je jeden ze základních principů metodiky MMDIS, viz kapitola 1.2 Cíl multidimenzionality • •
1.2.
neopomenout žádný faktor, který ovlivňuje úspěšnost tvorby, zavedení, provozování a dalšího vývoje IS/IT neopomenout vzájemné ovlivňování (vazby) faktorů
MMDIS (Multidimensional Management and Development of Information System)
Cílem MMDIS je vývoj a provoz integrovaného informačního systému, který optimálně využívá potenciálu dostupných informačních a komunikačních technologií (ICT) k maximální podpoře podnikových cílů Zajištění efektivní podpory podnikových cílů a podnikových procesů pomocí integrovaných informatických služeb, procesů a zdrojů Mnohost pohledů na IS/IT jak při řešení, tak při provozu IS/IT, tzv. multidimenzionalita, základní předpoklad efektivnosti IS/IT.
1.3.
Dimenze řešení IS (podle MMDIS) 2 základní skupiny dimenzí IS: 1. úrovně integrace, použitá úroveň abstrakce a časová dimenze 2. dimenze obsahové a organizačně - metodické, které se aplikují v každé fázi vývoje IS/IT – 7+3 dimenze: Obsahové dimenze Organizační dimenze
informační/ procesní/ datová funkční
ekonomická/ finanční
softwarová hardwarová
pracovní/sociální/etická
metodická
dokumentační
manažerská
- 1/5 -
organizační/ legislativní
1.9 Multidimenzionální přístup k řešení IS
Obsahové dimenze Mezi obsahové dimenze řešení IS patří: • •
•
• • • •
data / informace (inf) - Zabýváme se typy informací, které jsou v organizaci potřeba, obsahem a strukturou datové základny podniku a jejím fyzickým uložením. Řešením této dimenze je datová architektura IS. funkce / procesy (pro) - Zaměřeno na procesy probíhající v podniku a možnost jejich podpory pomocí funkcí IS. Výsledkem je funkční a procesní architektura IS. Funkční pohled na IS je statický, protože popisuje hierarchický rozpad funkcí IS (zahrnuje vstupní, výstupní a řídící data). Při procesním pohledu nás zajímá dynamika chování podniku, jako reakce na různé události. Události mohou být informační (příchod nebo vznik nové informace), časové (nastane časový signál) nebo mimořádné (narušuje ostatní - dojde proud, onemocní). organizační a legislativní aspekty (org) - Kromě jiného jde o stanovení zákonů, norem a směrnic, které musí být při tvorbě IS respektovány. Popisujeme organizační strukturu podniku - útvary, typy a počty funkčních míst, pracovní náplně a pod. Primární organizační struktura je hlavní org. struktura v podniku (strom), sekundárních struktur může být více, jsou ad-hoc tvořeny pro speciální problémy. Také definuje pravidla pro vývoj, údržbu a provoz IS, zodpovědnosti a pravomoci, postupy prevence proti mimořádným stavům. pracovní, sociální a etické aspekty (pra) - Cílem je určit potřebnou strukturu pracovníků podniku (počet, kvalifikace,..), jaké sociální a etické dopady může mít přechod na nový IS a jaká opatření (nábor, propuštění, školení) si to vyžádá. software (sw) - Určíme architekturu programového systému - vzájemné vztahy mezi základním a aplikačním softwarem, spadá sem i problematika nákupu či vývoje komponent. hardware (hw) - Určíme hardwarovou architekturu IS - parametry a typy počítačů, periférií, komunikačních sítí a podobně. ekonomické / finanční aspekty (eko) - Zahrnuje finanční náklady tvorby a provozu IS a přínosy z užívání. Určujeme jak, z čeho a kdy budou náklady kryty. Metodicko-organizační dimenze
Mezi metodicko-organizační dimenze patří: • • •
metody (met) - nástroje používané v jednotlivých fázích dokumenty (dok) - jaké dokumenty vznikají, jaký mají obsah a jak na sebe navazují řízení práce (mng) - určuje postup při řešení, dále pravidla a organizaci tvorby IS
Obsahové dimenze se i mezi sebou vzájemně ovlivňují, např. navržené softwarové řešení může vyžadovat konkrétní HW, z legislativy vyplývají požadavky na data, ale i procesy a funkce, aj. Vztahy mezi obsahovými dimenzemi: funkce ↔ data, řídící data – zákony, rozsah dat – diskové kapacity, programové moduly – počítače, sítě, řídící odpovědnost funkčního místa, funkční místa – počet pracovníků, řídící a výkonné odpovědnosti – kvalifikace, propojení HW, SW a datové dimenze, vnitřní stavba aplikací (KIS,…) a uživatelské rozhraní
1.4.
Vztah dimenzí a fází životního cyklu projektu, modifikace vah dimenzí s ohledem na podmínky řešení projektu
Životní cyklus projektu Projekty definované v informační strategii se realizují v 6 fázích: • Úvodní studie (US) - taktéž je známa pod názvem studie proveditelnosti, protože posuzuje realizovatelnost požadavků, které byly na projekt kladeny. Může dojít k závěru, že je projekt příliš rozsáhlý, a tak dojde k rozdělení na subprojekty, nebo jsou požadavky nerealizovatelné a potom životní cyklus končí. - 2/5 -
1.9 Multidimenzionální přístup k řešení IS
•
•
•
• •
Globální analýza a návrh (GAN) - Hlavním cílen GAN je vymezení hlavních funkcí a dat projektované aplikace na konceptuální úrovni. Jedná se o úroveň, která není závislá na technicko-programovém řešení. Hlavní úlohou je zmapovat, popsat, analyzovat a navrhnout podstatu aplikace. Výstupem je návrh funkcí a návrh logické struktury dat. Poznámka - GAN se takto vyčleňuje pouze u větších projektů, u menších splývá a US nebo DAN. Detailní analýza a návrh (DAN) - V detailní úrovni se transformuje konceptuální úroveň návrhu do technologické, která je již závislá na technicko-programovém řešení. Výstupem je návrh programových modulů budoucí aplikace, návrh fyzické struktury dat a návrh uživatelského rozhraní. Implementace (IM) - Náplní implementace je transformace technologické úrovně návrhu do implementační úrovně, neboli realizace fyzického návrhu databáze, programování programů, testování jednotlivých modulů, testování celého programového systému a kompletace dokumentace. Zavádění (ZA) - V této fázi se instaluje technicko-programový systém, školí se uživatelé aplikace a provádí se zkušební provoz aplikace. Provoz a údržba (PU) - V závěrečné fázi je aplikace provozována a jsou dosahovány přínosy. Čím déle vydrží tento projekt v této fázi, bez významnějších inovací, tím jsou větší efekty celého systému (i finanční)
Obrázek 1 Princip multidimenzionality a dimenze IS
Význam dílčích dimenzí pro jednotlivé fáze ŽC projektu závisí mnoha více parametrech: •
charakter řešení (TASW, IASW)
•
rozsah problému a jeho složitost
•
požadovaná kvalita řešení a spolehlivost provozu
•
čas, který je objektivně dán na řešení
•
počet, schopnosti a zkušenosti řešitelů
•
počet a dosavadní zkušenosti uživatelů
•
finanční zdroje na řešení - 3/5 -
1.9 Multidimenzionální přístup k řešení IS
1.5.
Metainformační systém jako nástroj řízení vývoje integrovaného IS
metasystém = systém popisující/modelující jiný systém. Je jednotou metadatabáze (metadat) a operací umožňujících uchování a zpracování metadat. Metadata popisují všechny entity IS v podniku (minulé, současné i plánované). metadata popisují IS/IT podniku a jejich vzájemné vazby na další součásti podniku a na podnikové aktivity Komerčně nejúspěšnějším je ARIS (použitelný pro zavádění ISO 9000 i BPR). MtS na VŠE – má zajistit integrovaný pohled rozdílných skupin uživatelů na IS. Základní operace MtS •
operace realizující pasivní roli MtS (nevyžaduje přímé propojení MtS a IS)
•
o vytváření a údržba metadatabáze o dotazy na obsah a strukturu IS/IT o analýzy konsistence IS/IT (chybějící části IS, nadbytečná data,…) o analýzy nad metadaty – co se stane, když… operace realizující aktivní roli MtS
o řízení IS/IT (spouštění dávek, kontrola přístupových práv,…) o sledování provozu IS/IT (monitorování přístupu uživatelů k IS,…) Hlavní požadované vlastnosti MtS 1. Funkčnost MtS • musí zajišťovat požadované spektrum funkcí pro různorodé skupiny uživatelů v prostředí dynamického vývoje IS 2. Pružnost • umožnit přidávání dalších objektů, vazeb a operací s nimi dle požadavků uživatelů 3. Jednoduchost použití
- 4/5 -
1.9 Multidimenzionální přístup k řešení IS
1.6.
Úloha - předpoklady: Uvažujte projekt většího rozsahu, resp. projekt, který vám zadá zkoušející přímo u zkoušky. Zadání: • Řešení kterých dimenzí je pro úspěch projektu rozhodující a proč? • Vazby kterých dimenzí jsou v tomto projektu nejvýznamnější?
Pro úspěch řešení projektu je třeba brát v úvahu veškeré dimenze. V rámci globální spolupráce jednotlivých částí je totiž třeba přejít od systematického pohledu na systémový, tzn. hledět na to jako na celek, nikoli na funkčnost jeho jednotlivých částí. Jednotlivé části spolu vzájemně spolupracují, a tudíž je třeba věnovat pozornost všech aplikovaným vrstvám. Při přiřazení menší důležitosti některé z nich by mohlo dojít k následnému vzniku nedostatku v jiných vrstvách, což by pak vedlo ke zhoršení celého systému. Jestliže má být budoucí IS konzistentní a integrovaný je nutné zohlednit všechny dimenze. To lze schematicky naznačit tabulkou, která má v jednotlivých řádcích dimenze časové a ve sloupcích dimenze obsahové (úplná kombinace obou řešitelských pohledů). To znamená, že se ve všech životních fázích projektu musíme zabývat všemi obsahovými dimenzemi. Musíme však upozornit, že významnost téže dimenze se v jednotlivých fázích může měnit - organizační a ekonomická dimenze mají vyšší váhu na počátku (GST, IST, US) a naopak softwarová a hardwarová dimenze mají vyšší váhu ke konci projektu (GAN, DAN, IM).
CO(obsah řešení fáze) inf GST
GST(inf)
IST
IST(inf)
US
US(inf)
pro
org
pra
GST(pro) GST(org) GST(pra)
bzp …
GAN DAN IM ZA PU
- 5/5 -
ui
sw
hw
eko
JAK s ČÍM
JAKÝ VÝSTU P
JAK ŘÍDIT
met
dok
mng
1.15 Fáze projektu IS/IT
1.15 Fáze projektu IS/IT
Zdůvodnění nutnosti fázového postupu, odlišnosti fází různých typů projektů - při vývoji aplikace, řešené na míru potřebám podniku, versus při řešení aplikace typovým aplikačním softwarem. Zdůvodnění nutnosti fázového postupu, Z důvodů nesnadného plánování projektu "od začátku do konce", se často využívají tzv. fáze projektu. Ty člení projekt na části, které jsou naplánovány jen do určité míry podrobnosti. Jak projekt postupuje, je plánování fází zpřesňováno. Platí zde pravidlo, že před zahájením fáze musí být plán této fáze úplný. Fáze, které následují mohou být dočasně naplánovány jen rámcově.
1.1.
Fáze projektu
Příprava projektu Plánování projektu Řízení postupu projektu Ukončení projektu
odlišnosti fází různých typů projektů.
1.2.
Fáze přípravy projektu IASW
1.3.
rozhodnutím mezi vlastním vývojem, nákupem nebo nákupem a následným přizpůsobování aplikačního balíku.
Úvodní studie vlastní vývoj - obr str. 82 TASW – obr. str. 94 Cílem je určení základních systémových konceptů pokrytí systémových požadavků a to tak, aby specifikace byla zcela nezávislá na jakémkoli aplikačním balíku. TASW V této fázi se může stát, že dojde při zkoumání trhu s TASW ke zjištění, že náklady tohoto řešení by se nevyplatili a organizace se rozhodne pro cestu IASW. V této fázi se u aplikačního balíku také rozhoduje, zda-li bude sloužit k pokrytí všech vlastností systému nebo jen jeho části. - 1/5 -
1.15 Fáze projektu IS/IT
Provádí se hodnocení systémů, které byly vybrány jako možné alternativy dle stanovených kritérií. V úvahu se bere stabilita, otevřenost, možnost dopracovat novou funkcionalitu, „jméno“, nezávislé hodnocení, cena/výkon, licenční politika atd. IASW U IASW se oproti TASW stanovuje předběžný návrh ASW obsahující pouze důležité funkce, vstupy a výstupy. Definují se zde i alternativy, jak tento systém řešit. U obou se provádí analýza nákladů/přínosů.
1.4.
Globální návrh TASW zúžení spektra možných „balíku.“ definování kritérií, podle kterých proběhne výběr detailní prozkoumání balíku. provedení takových úprav, které jsou nutné k dosažení shody se specifickými požadavky (parametrizace, definování projektu na vývoj aplikace, která doplní požadovanou funkcionalitu) IASW dochází ke zpodrobnění funkčního návrhu – vychází se z požadavků uživatelů. hlavní častou chybou je přílišná podrobnost. detaily by se měly definovat jen u rozhraní mezi systémy a s okolím. začíná technický návrh aplikace
1.5.
Detailní návrh TASW detailní specifikace možných rozšíření popsat rozhraní člověk/počítač případně definovat způsob konverze dat. To může vyvolat specifický subprojekt IASW provádí se pro každý subsystém zvlášť taková úroveň podrobnosti systému, že je možno začít programovat funkční návrh se provádí až na úroveň datových položek, elementární funkce, požadavky na obrazovky a sestavy,… definice plánu testování návrh formulářů u neautomatizovaných činností (dokumenty) – často se opomíjí! návrh fyzické databáze v konkrétním db systému
1.6.
Implementace TASW provést test organizační přijatelnosti. Pokud by se při tomto testu zjistilo, že aplikační balík je nepřijatelný, bude nutné se vrátit do předchozí etapy a buď provést - 2/5 -
1.15 Fáze projektu IS/IT
celý postup vyhodnocení znovu, nebo dokonce úplně odmítnout alternativu nasazení aplikačního balíku namísto vývoje na míru. pokud OK tak OK
IASW – obr. str 88! jde o programování a psaní dokumentace testování napsaných programů první seznámení s uživateli pro oba přístupy
1.7.
- školení uživatelů - schvalování jednotlivých kroků
Zavádění TASW, IASW - oba přístupy stejné. Nezapomínat na ! popisy pracovní náplně systému proškolení uživatelů definice požadavků na rutinní provoz s odděleními konverze dat do nového systému
1.8.
Provoz a údržba Tady nevím. Please help!
- 3/5 -
1.15 Fáze projektu IS/IT
- 4/5 -
1.15 Fáze projektu IS/IT
Úloha - předpoklady: Vyberte určitou funkční oblast vámi zvoleného podniku, která je na počátku řešení. Zadání:
Jaký je obsah jednotlivých fází řešení jejího IS ? Kde očekáváte možné hlavní problémy v jednotlivých fázích ? Jaká bude technologická podpora řešení IS/IT v jednotlivých fázích ?
Kde očekáváte možné hlavní problémy v jednotlivých fázích ? Pour 87 - 95 Jaká bude technologická podpora řešení IS/IT v jednotlivých fázích ? Specifické projekt od projektu. Obecně lze ale říci, že při implementaci a zavádění je nutné testovat v reálném prostředí podniku. Je tedy potřeba tyto činnosti dobře naplánovat a zkoordinovat. A jak mnozí z nás víme, pracovat ve večerních a nočních hodinách.
- 5/5 -
1.11 Architektury IS/IT
1.11 Architektury IS/IT Charakterizujte podstatu a účel architektur IS/ICT. Vysvětlete pojmy aplikační architektura a softwarová architektura. Účel softwarové architektury a možnosti jejího využití v jednotlivých fázích životního cyklu vývoje IS.
1.1.
Vymezení Architektura je základím konceptem výstavby systémů IS/IT. Určuje základní komponenty IS, vazby mezi nimy a okolím. Určuje principy návrhu a vývoje IS. Definuje standardy a základní pravidla Informace v ní obsažené jsou závazné pro metodiku vývoje IS/IT. = schéma zohledňující všechny podstatné dimenze návrhu IS.
1.2.
Podstata a účel architektur vychází z jejich vlastností:
Orientace na strategické cíle podniku Pokrytí požadovaných služeb Integrace dimenzí datová, funkční, procesní, SW, HW Otevřenost systému (parametrický, nastavitelný, schopný reagovat na nové požadavky uživatelů) Architektura vytváří stabilní rámec řešení IS/IT pro další rozvoj systému Významný komunikační prostředek: mezi vedením podniku a oddělením IS/IT při formulaci základních o IS/IT Stálost architektury v dlouhém čase= její neměnnost
Vyjadřuje celkovou vizi IS, oproštění od detailů, musí však vycházet z úplného pochopení ekonomické, obchodní a výrobní podstaty činnosti organizace a cílů, které organizace sleduje.
Srozumitelné a jednoduché vyjádření
1.3.
Aplikační a Softwarová architektura
1.3.1.
Aplikační architektura
1.3.2.
Specifikuje jakými aplikacemi (ASW) je pokryta celková funkcionalita IS
Definuje vazby mezi aplikacemi (ASW)
Specifikuje nutnou infrastrukturu nutnou pro provoz ASW (aplikace a její účtování)
Využití apl.architektury zejména při nutnosti vypnout aplikaci, nebo rozhodnout o jejím outsourcingu
Zastresujici pojem SW architektury
Softwarová architektura
Určuje z jakých SW komponent bude systém postaven a jaké vazby budou mezi moduly
Vazby mezi moduly jsou dány voláním modulů a předávanými daty - 1/4 -
1.11 Architektury IS/IT
Zobrazení systému softwarových modulů ASW
Vlastnosti modulu (Funkce, I/O a řídící Data, Algoritmus převodu I na O, vývojové prostředí modulu (CASE, jazyk), provozní prostředí (OS, DB, Presentační systém)
Architektury dle volání modulu o
Lineární
o
Hierarchická
o
Vrstevná
o
Síťová
1.4.
Typy architektur dle volání modulů
1.4.1.
Lineární
1.4.2.
Hierarchická
1.4.3.
Vrstevná
Minimalizace nákladů
Funkce vyšších vrstev mohou využívat jen fce přímo podřízených nižších vrstev
- 2/4 -
1.11 Architektury IS/IT
1.4.4.
Síťová
1.5.
Vrstvy v architekturách IS/IT Tyto vrstvy je třeba chápat jednak z pohledu IS/IT jako celku, jednak v rámci jednotlivých bloků.
Vrstva prostředí ekonomické prostředí, legislativa, organizační struktury, personální kapacity (včetně úrovně znalostí a kvalifikace), zkušenosti v IT atd.
Vrstva aplikační provozované i řešené projekty, jejich dokumentace, funkční a datová specifikace, ASW atd.
Vrstva technologická návrh a provoz počítačových sítí, vymezení jednotlivých komponent IT a jejich vazeb
1.6.
Životní cyklus a možnosti využití SW architektury
identifikace problémů, možností a cílů (stanovení strategie vedoucí k realizaci tvorby IS) -> IST
definování informačních potřeb (proč má produkt vzniknout a jaké informační potřeby uspokojí) -> UST
analýza systémových potřeb (zkoumáme systémové potřeby nezbytné pro tvorbu vlastního IS) -> GAN (definice SW architektury)
návrh doporučeného systému (navrhujeme, jak bude systém řešen v dané technologii a jaké postupy budou uplatněny) -> DAN (definice SW architektury)
vývoj a dokumentace softwaru -> IMP
testování a zavádění softwaru -> ZAV
údržba a hodnocení systému -> PUR
- 3/4 -
1.11 Architektury IS/IT
Úloha - předpoklady: Jste v situaci, kdy zákazník má k dispozici softwarovou architekturu určitého programového systému a potřebuje posoudit kvalitu této architektury. Zadání:
Jaké podklady byste od zákazníka očekával a jak byste postupoval ?
Informace, jaké měl požadavky na systém (GAN, DAN) a porovnal bych se současným stavem Jaké jsou k dispozici prostředky k zachycení softwarové architektury ? Zachyceni pomocí CASE nástroje v Strukturálních diagramech jako je Component diagram.
Jak budete určovat kvalitu programového systému ?
Atributy kvality jsou myšleny požadavky na systém nesouvisející přímo s jeho funkcionalitou jako jsou požadavky na výkon, bezpečnost, škálovatelnost, dostupnost, čistotu dat apod. Jedním z úskalí práce s atributy kvality je, že jsou mnohdy protichůdné.
Jaké využijete metody k hodnocení kvality softwarové architektury ?
Metody měření architektury a naměřené hodnoty porovnávat s hodnotami požadovanými v SLA.
- 4/4 -
1.12 Outsourcing - Možné důvody pro outsourcing určité funkční oblasti, proces outsourcingu, specifika outsourcingu Úloha - předpoklady: Jste vedoucím pracovníkem útvaru informatiky vámi zvoleného podniku a řešíte problém rozsahu a způsobu realizace outsourcingu IS/ICT. Zadání: Které oblasti pro outsourcing zvolíte a proč ? - viz co outsourcovat a co neoutsourcovat Analyzujte příležitosti a rizika navrženého řešení outsourcingu IS/ICT. - viz proč to zavádět a viz rizika
Co to je - Specifika ICT Outsourcingu Jedná se o poskytování určité služby1 externím dodavatelem za určitých podmínek.
Služby ICT Mohou být vícero druhů: -
Informační o
-
Aplikační o
-
Jde o schopnost struktury zpracovávat informace - Např. koncové stanice nebo servery. I zde bývá součástí školení, testování, service desk, dále také opravy
Vývojové o
-
Dodávají funkciontalitu, např. CRM nebo účetnictví. Podporují jeden nebo více business procesů. Součástí bývá i školení, testování uživateli , service desk a drobné údržby systému.
Infrastrukturní o
-
Nedodávají infrastrukturu, pouze informaci. Např. stav obchodování na burze. Přestože informace může být produktem sw aplikace, tak ta je pro koncového uživatele informace nepodstatná
Dodávka požadovaného sw nějakou formou, v podstatě se jedná o klasický projekt. U tohoto typu služby obzvlášť pozor na licence.
Podpůrné o
Komunikace se zákazníky, evidence chyb…
Podmínky Představují SLA (service level agreement - úroveň vykonání služby) a jsou obsažené ve smlouvě s dodavatelem. Z právnického pohledu jde o následující typy smluv: -
Mandátní o
-
Nájemní o
-
Pokud je předmětem smlouvy hlavně služba
Pokud jde hlavně o pronájem určitého vybavení
Smlouva o dílo o
Pokud má být vykonáno něco v kratším časovém úseku (měsíc)
Vždy je třeba ve smlouvě ošetřit i případná rizika a co se stane s licencemi po skončení outsourcingu. Pro smlouvu jsou zásadní metriky
Základní struktura outsourcingu Obsahem SLA bývá mimo dalších věcí jako je ošetření rizik, vymezení smluvních stran atp. následující: -
Kdo to bude dodávat - typ i konkrétního dodavatele (viz proces outsourcingu) Co se bude dodávat - o jakou službu se přesně jedná o
o
-
1
V jaké kvalitě - např. dostupnost (kolik času z celkového času je služba skutečně dostupná), aktuálnost informací, doba poskytování služby, bezpečnost (ochrana proti přístupům, fyzické zabezpečení), spolehlivost (dělá to vše, co bylo dohodnuto), doba reakce na požadavek, integrita. Škodu v případě nedostupnosti odhadne vlastník procesu. V jakém množství - objem služby - např. počet koncových stanic, počet uživatelů, objem transakcí, objem dat, počet konzultačních hodin, škálovatelnost objemu dat (lze v jednom měsíci přenést 100GB a v druhém 500GB?), počet licencí Adobe -pro uživatele, stanici nebo stačí správce tisku?
Za kolik - kolik to bude stát - cena Komu a kde
Obsah smlouvy
V tomto případě se má službou na mysli nejen služba jako taková, ale i proces či zdroj. Rozdíl mezi outsourcingem a nákupem je v tom, že u outsourcingu jsme danou službu (tj. proces, službu či zdroj) předtím vlastnili.
K čemu to je - proč to zavádět - možné důvody zavedení Existuje řada důvodů, proč outsourcing zavádět: -
Snížení nákladů - Gartner udává, že lze docílit 5-10% snížení personálu. V případě Off-Shore outsourcingu, kdy jde o přesun výroby něčeho k poskytovateli, je možné ušetřit 20-40% nákladů. Zdaleka ne vždy použitelné! Soustředění se na hlavní předmět činnosti podniku - byznys si určí, co je jeho core business a to co není, převede na externí partnery Sdílení rizik - při outsourcingu nepadají rizika pouze na naši hlavu - sníží se náklady na určitá rizika Schopnosti a možnosti služby na vysoké úrovni - najímáme si na to specialistu, který tomu rozumí lépe, neboť na rozdíl od nás je to jeho core business Standardizace - pokud chceme mezinárodně sjednotit dělání určité věci Rozšíření přínosů BPR - u byznys process reengineeringu, ve kterém jde o zvýšení efektivnosti procesů, je zásadní vytvoření určitých SLA. Je tedy zřejmé, že podnik si vytvoří na své procesy své vlastní SLA (interním SLA se říká OLA - operation level agreement), aby definoval úroveň služby u jednotlivých procesů a následně na to je může či nemusí outsourcovat.
Přestože je snížení nákladů většinou tím nejpodstatnějším důvodem outsourcingu, je třeba dát pozor na transakční náklady - řešitelský tým zabývající se celým kontraktem a jeho uzavřením, expertní a konzultační činnosti a další věci, které je zvýší.
Rizika outsourcingu - CSF - Critical success factors Z hlediska konkrétních rizik společnosti uvažující o outsourcování: -
Nenajdeme dodavatele služby, který : o
o
-
-
zvládá danou činnost lépe - pakliže jsme chtěli outsourcovat,aby možnosti služby a její provedení bylo na vysoké úrovni, tak to předpokládá dodavatele schopného službu na vysoké úrovni dodat. Pokud ho nenajdeme, máme problém. je minimálně stejně velký jako naše firma - souvisí to s rizikem dodávání služby, čím kritičtější je služba, tím je toto důležitější - nemůžeme si dovolit, aby naše velká společnost měla problémy jenom proto, že si vybrala firmu, jejíž kapitál ani velikost se naší nemůže rovnat. Je zřejmé že u outsourcingu méně důležitých činností může být malá velikost naopak výhodná - flexibilita a cena
únik citlivých informací - nejen ve státní správě, ale např. banky a klienti nízká flexibilita vztahu k měnícím se požadavkům zákazníka - dodavatel musí umět rychle reagovat při požadavcích na změnu ztráta specializovaných znalostí - pracovník helpdesku či administrátor nás neohrozí, tvůrce core procesů či bezpečnostní ředitel ano (zabezpečení všeobecně je lepší nechat "doma") konflikt kultur - outsourcování z Indie vyjde společnost nejlevněji, ale mentalita je jiná (dle jednoho z vysoce postavených IBM manažerů Indové nezpochybňují zadání a neuvažují o něm, co řekl sáhib je svaté a tak se to udělá, což nemusí být vždy ideální…Češi jsou na tom z analytického pohledu lépe, ale také dražší) obtížnost - neúspěšnost outsourcingu je mezi 40-70% (podle Radecký, Business World 2007), důvodem jsou často požadavky koncového zákazníka, který chce kvalitnější službu za nižší náklady versus zisk u dodavatele služby (základem je kvalitní smlouva. Pokud je vyvážená smlouva, tak si žádná strana ublížením té druhé Obsah smlouvy nepomůže), jiným častým důvodem je špatně provedená analýza procesů či dodavatele
Co outsourcovat Z obecné roviny je vhodné outsourcovat vše, co chceme mít nějakým způsobem standardizováno a automatizováno. Doma by měly zůstat jedinečné věci, to čím se chceme od konkurence lišit. To co určitě neoutsourcovat jsou vyšší patra byznys aktivit - strategie, byznys model, klíčové byznys procesy včetně jejich definice (u klíčových procesů jde většinou o řízení a nějaký vztah k zákazníkovi). Outsourcovat se jinak dá vše ostatní. Z hlediska IT je vhodné použití katalogu služeb, ve kterém jsou popsané služby, které IT byznysu dodává včetně toho, jak je daná služba v byznysu využitelná. Konkrétní oblasti -viz služby ICT. Z hlediska rozsahu (outsourcing procesu/komplexní IS..) - viz Varianty outsourcingu.
Postup zavedení - proces outsourcingu -
-
Vybrat typ outsourcingu - co budeme tedy outsourcovat? Viz Co outsourcovat Sourcing strategie - určení oblastí, které budou outsourcovány a cíle, proč jsou outsourcovány. Viz Proč to zavádět. Detailní analýza předmětné oblasti - kontrola definice služeb, procesů a zdrojů z dané oblasti - audit, finanční analýzy a očekávané přínosy Definice rozhraní zadavatel-poskytovatel (podklad pro SLA) - obsahuje dodávané produkty a služby včetně jejich kvantity a kvality - určí se pásma - co je standard, nadstandard, kritická (dodavatel dostane méně) a motivační úroveň (bonus - dodavatel dostane více) Vyhodnocení plánovaných přínosů a rizik - rozhoduje o tom, zdali společnost bude outsourcovat či nikoliv. Výběr poskytovatele o
o
-
typ, např.: Multisourcing / sourcing - od jednohovíce poskytovatelů, podnik si je koordinuje sám Brand service company - najmeme jednoho providera a ten si případně kontaktuje další (a nás do toho nezatahuje) Best of Breed - další poskytovatele si vybírá nejen náš hlavní provider, ale mluvíme do toho i my Výběrové řízení - pro outsourcing jsme se již rozhodli, chceme však vybrat nejlepšího kandidáta (u veřejných zakázek povinnost ze zákona - toto se dá obejít, pokud je termín na nabídku týden a předtím jsme se s nějakou společností domluvili, stihne to jen tato); chyby výběrového řízení - pozor na: Povrchní posouzení potřeb a nabídky poskytovatele Finance nebo právo dominují v kontraktačním procesu - nejdříve by měli mluvit odborníci o obsahu a pak teprve právníci Neberou se v úvahu reference na poskytovatele a jeho dosavadní vztahy k zákazníkům Krátkodobé výhody dominují mezi rozhodovacími faktory - potřeba pečlivého zvážení
Sepsání smlouvy - určitě s právníkem. Stanovit metriky [např. výkon serveru (počet transakcí,chyb), výkon helpdesku, doba trvání vyřízení určitého incidentu, škálovatelnost serverů (jak může být kolik vytížen..)] a vymezit i naprosto triviální věci - co je to pracovní doba atd. V případě problémů lze využívat rozhodců, neboť Obsah smlouvy jsou rychlejší (rozhodčí doložka do smlouvy).
Co rozhoduje o tom, zdali se má komponenta outsourcovat či nikoliv? Existují určitá kritéria, která mohou sloužit jako návod: -
Náklady na provoz a údržbu komponenty generované doma o
-
Nabídka komponenty na trhu o
-
Čím vyšší, tím menší vhodnost pro outsourcing, neboť se zvyšují náklady při integraci této komponenty
Sezónnost využití o
-
Čím vyšší, tím lepší pro outsourcing, defacto jde o opak předcházejícího
Integrační vazby o
-
Čím vyšší, tím menší vhodnost pro outsourcing. Nebudeme outsourcovat to co nás činí jedinečnými
Standardizace o
-
Čím vyšší, tím lepší - máme větší možnosti při výběru dodavatele
Unikátnost komponenty - nejde o unikátnost komponenty samotné, ale i jejího využití o
-
Čím vyšší jsou náklady generované doma nad cenou, za kterou je možné danou komponentu outsourcovat, tím je vhodnost pro outsourcing větší
Čím vyšší, tím vhodnější pro outsourcing - na co kupovat drahou komponentu s ještě dražší údržbou, když ji potřebujeme využívat 3x do roka?
Frekvence využití o
Čím vyšší, tím menší vhodnost pro outsourcing, často používanou komponentu mít (nejenom z hlediska bezpečnosti) raději doma
3.7 Možnosti řešení outsourcingu Formy a oblasti realizace outsourcingu. Principy smluv na outsourcing. Proces outsourcingu IS/ICT. Ú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 ? - viz Sepsání smlouvy u postupu zavedení, viz základní struktura outsourcingu, viz rizika outsourcingu. Jaké příležitosti a jaká rizika pro vás vyplývají z tohoto vztahu? - viz proč to zavádět a viz rizika Jak budete postupovat, abyste minimalizoval rizika? - postup podle procesu outsourcingu+jednotlivá rizika - viz rizika. V potaz se také vezme, co rozhoduje o tom, zdali se má komponenta outsourcovat či nikoliv
Pro tuto otázku stačí většina z předchozí, podíváme se ale blíže na možnosti řešení jako takové, tj. na varianty outsourcingu.
Varianty outsourcingu a jejich kritické faktury Zavedení určitého systému či jeho části může podnik řešit více způsoby: -
Vlastní vývoj o
-
Nákup o
-
Jde o aplikaci hostovanou u providera, klient ji pouze používá. V ČR se příliš nevyužívá, není dostatečná důvěra a ani opěra v zákonech
ASP (application service provider),COD (capacity on demand) o
-
Tradiční cesta, podnik si nechá implementovat ERP externí firmou, provoz IS/ICT řeší vlastními zdroji
SAAS (software jako služba) o
-
Připadá v úvahu jen v určitých případech (sw společnost), jinak je to příliš nákladné
Podobné jako SAAS, akorát aplikaci je možné upravit na míru, saas bývají typové řáešení. Faktem zůstává, že mnoho poskytovatelů bere ASP/SAAS jako synonyma
Outsourcing o o
Komplexní - outsourcujeme celé IT - často nepřinese očekávané snížení nákladů - např. CocaCola Částečný - nějaký proces
2
Komplexní outsourcing - celé IS/ICT -
Outsourcují se všechny služby, procesy a zdroje v IT Např. informatická podpora účetnictví, vývoj a provoz informatických služeb Za provoz odpovídá poskytovatel Kritické faktory o o o o o
Klíčové procesy - nechceme outsourcovat něco, co nás činí jedinečné Jeden poskytovatel a závislost na něm - není to příliš riskantní? Zvlášť u poskytování celého IS Schopnosti CIO - od kterého poskytovatele co nakoupit a uřídit to Katalog služeb a jeho kvalitní definice (co všechno se bude pro byznys dodávat). Objem, kvalitu a cenu službu by měl definovat byznys Transformace doma vyvinutých aplikací - pokud je pro poskytovatele levnější vytvořit aplikaci celou znova, aby uspokojil naší potřebu, tak je to extrémně nákladné - něco takového by se nevyplatilo
Částečný outsourcing Z hlediska částečného outsourcingu můžeme outsourcovat: -
Informatickou službu - např. CRM či elektronickou poštu, tiskové služby Informatický proces - implementaci ERP, integraci IS/ICT, řešení incidentů koncových stanic Informatické zdroje - datové centrum Kritické faktory o o
o
Řízení- větišnou ještě složitější než u komplexního outsourcingu od jednoho poskytovatele, tady jich je více. Ještě větší nároky na CIO. Optimální granularita architektury - jedna služba pokrývající široký záběr funkcionality (a část pravděpodobně ani nevyužijeme) nebo mnoho malých "službiček", které jsou popsány do nejmenších detailů (a tím přicházíme o výhodu standardizace a do určité míry i znovupoužitelnosti)?. Úzká souvislost se SOA. Controlling - vyhodnocování kvality poskytovaných služeb - měření a metriky. Souvisí se řízením
Částečný outsourcing dle lokality zdrojů: -
2
Centralizované zdroje umístěné v prostorách podniku nebo v prostorách poskytovatele Decentralizované zdroje - datový server umístěn v podniku, aplikační u poskytovatele, část zdrojů může být i u třetí strany. Trend - je to levnější. U tohoto typu outsourcingu pozor na bezpečnost a spolehlivost.
Viz článek,ve kterém CIO CocaColy McNamee popisuje zkušenosti - ZDNEt
1.13 Kritéria kvality programového systému
1.13 Kritéria kvality programového systému
Způsob stanovení kritérií kvality, měření kvality a dosahování požadované kvality programového systému.
1.1.
Pojem kvalita IS/IT Kvalita IS/IT je dána mírou, kterou IS/IT přispívá k výkonnosti a efektivnosti podnikových procesů, činností a uživatelů. IS/IT je kvalitní, jestliže splňuje požadavky nebo takový, který je způsobilý k zamýšlenému použití. Pro potřeby srovnání je ale třeba stanovit určité parametry kvality: 1. 2. 3. 4. 5.
funkčnost (plní funkci, pro kterou je určen) vzhled resp. komfort (způsob užívání, estetické působení) spolehlivost a udržovatelnost (stálý výkon po dobu životnosti, jednoduchost údržby) trvanlivost (dlouhá životnost, schopnost vývoje) bezpečnost (ergonomie, ekologičnost)
do jisté míry platí:
1.2.
kvalita = efektivnost
Uživatelská hlediska kvality IS/IT Z hlediska obsahu posuzuje uživatel informace podle toho: • jak jsou významné pro daný účel • zda jsou dostatečně přesné • za jsou dostatečně kompletní • zda jsou přiměřeně detailní • zda jsou získána ze spolehlivých zdrojů Z hlediska formy prezentace posuzuje, zda jsou informace: • předávány správným osobám • předávány včas z hlediska okamžiků jejich potřeb • předávány vhodným způsobem • srozumitelné příjemci
- 1/4 -
1.13 Kritéria kvality programového systému
1.3.
Technologická / technická kvalita IS/IT Technické hledisko IS postihuje aspekty podmiňující úspěšné provozování a údržbu IS/IT a tím i dosažení kvality z hlediska uživatelů. Nejvýznamnějšími kategoriemi jsou: • Provozní aspekty – zahrnují snadnost užívání v trvalém provozu, tj. zejména úroveň podpory pro průběžné sledování provozních charakteristik a řešení problémových stavů. • Aspekty údržby – jsou zaměřeny na vhodnost pro dlouhodobé užívání aplikace IS/IT, při kterém je třeba opravovat a rozšiřovat její funkčnost. Je hodnocena např. komplexnost, kvalita dokumentace, vícenásobná použitelnost komponent a možnosti testování. • Architektura řešení – ta úzce souvisí s dosažením dlouhodobé stability a spolehlivosti IS/IT. Vhodnými kritérii jsou zejména přenositelnost na různá systémová prostředí, rozšiřitelnost pro větší rozsah dat i uživatelů, vzájemná kompatibilita a propojitelnost a bezpečnostní hlediska.
1.4.
Praktické stanovení kritérií (technologické i uživatelské aspekty kvality) • • • • • • • • • • • • •
přesnost – systém se chová tak, jak je určeno ve specifikaci jeho funkcí spolehlivost – systém vykazuje minimum výpadků robustnost – systém se chová „rozumně“ i za krajních podmínek, které nebyly uvažovány při jeho specifikaci efektivnost – systém užívá počítačové zdroje ekonomicky a má vyvážené náklady s průchodností a dobou odezvy škálovatelnost – schopnost systému běžet na HW s různým výkonem přenositelnost – systém může běžet na různých platformách (HW,SW) bez ztráty funkcí propojitelnost – schopnost systému spolupracovat s jinými systémy udržovatelnost – systém může být snadno měněn podle dodatečných požadavků verifikovatelnost – vlastnosti systému mohou být snadno ověřeny dostupnost aplikací IS – je charakterizována rozsahem zpracování v reálném čase, dobou odezvy a možností přístupu k historickým datům. integrita a komplexnost IS – je dána stupněm korektnosti a integrity dat, jejich aktuálností a synchronizací. bezpečnost IS – jak a jakým způsobem aplikace zamezují neautorizovaným přístupům k informacím. snadnost užívání IS – zahrnuje hlediska jako jednoduchost, flexibilita, odolnost proti náhodným chybám, možnost individuální konfigurace ad.
Hodnocení uživatelské kvality se zpravidla provádí dotazníkovým průzkumem (přímým měřením a výpočty pouze tam, kde je to možné). Dalšími možnostmi měření je audit (externí nebo interní) nebo hloubkové pohovory. Úroveň kvantity: standardní, podstandardní, kritická, motivační Metriky měření – tvrdé (výsledkové, výkonnostní) nebo měkké (zralostní - CMM, spokojenost, …) - 2/4 -
1.13 Kritéria kvality programového systému
1.5.
Normy kvality IS/IT Mezinárodními normami definujícími systém kvality jsou normy ISO900X 2000. Hlavní normou je ISO9001 Systémy jakosti (Model zabezpečení jakosti při navrhování, výrobě, uvádění do provozu a servisu). Tato norma definuje základní součásti systému jakosti, které je třeba splnit pro získání certifikátu jakosti. Vedle snahy normalizovat procesní stránku jakosti (ISO9001) existuje i snaha normalizovat kontrolu jakosti produktu. Hlediska hodnocení SW produktu jsou definována v normách ISO/IEC 9126-1 Vyhodnocení jakosti SW produktu (nedefinuje metriky). Jak jakost měřit řeší norma ISO9126-2 Charakteristiky a metriky jakosti SW – Část 2: Externí metriky. Jedná se o metriky, které měří chování produktu v předem definovaném prostředí, aniž by se zabývaly jeho vnitřní strukturou. Jejich nevýhodou je to, že většinu z nich lze aplikovat až na hotový produkt a proto jsou skoro nepoužitelné jako nástroj pro řízení vývoje produktu. ISO9126-3 Charakteristiky a metriky jakosti SW – Část 3: Interní metriky. Jedná se o metriky měřící charakteristiky, které nelze odvodit z jeho chování v předem definovaném prostředí. Pro jejich použití je nutné znát vnitřní strukturu produktu. Slouží proto hlavně jako nástroje při vývoji. Nevýhodou je nemožnost využití na měření všech charakteristik jakosti. ISO9126 dělí jakost SW produktu do 6 kategorií (tzv. charakteristiky). Cílem je minimální překrývání těchto charakteristik a jejich vzájemná nezávislost. Nepodařilo se.
obrázek 1 - model jakosti ISO 9126-1: charakteristiky a subcharakteristiky interní a externí jakosti
ISO9126-4 Charakteristiky a metriky SW – Část 4: Metriky jakosti v užití. Měří jakost, které dosahuje produkt při použití různými druhy uživatelů. Jakost užití SW
efektivnost
produktivita
bezpečnost
- 3/4 -
uspokojení
1.13 Kritéria kvality programového systému
1.6.
Úloha - předpoklady: Máte na starosti prodej aplikačního software zaměřeného na podporu ekonomickologistických agend. Zadání: • Budete ve fázi (před-)kontraktačního jednání zjišťovat kvalitativní požadavky potenciálního zákazníka, event. jakými metodami? • Jaké prostředky lze použít pro to, aby dodávka nebyla neúspěšná z důvodů „nekvality“?
V první řadě zjišťujeme, zda námi nabízený SW produkt plně pokryje zákazníkovy požadavky na funkčnost – to musí být samozřejmost. Tj. zda SW obsahuje všechny moduly podporující všechny „ekonomicko-logistické“ aktivity + další charakteristiky jako licence, počty současně pracujících uživatelů, způsoby přístupu k datům, architektura SW (klient/server) apod. V rámci požadavků na kvalitu pak můžeme vycházet z uvedených ISO standardů, např. ze systému kritérií ISO/IEC 9126, 14 598 (SW balíky) nebo jiných uznávaných standardů. Pokud zároveň zákazník některý ze standardů zná, pak zjistíme jeho požadavky na náš SW produkt v jednotlivých (sub)charakteristikách. Pokud ne, sami budeme vycházet s řady 9126 a zjišťovat požadavky zákazníka. Systém ISO by měl poskytovat co nevyčerpávající sestavu kritérií pro různé oblasti, které pro SW produkt přicházejí v úvahu, proto je vhodné řídit se právě jím. Případně lze ale jednoduše získat jen základní požadavky zákazníka: vždy je určující, že kvalita našeho SW je dána mírou uspokojení potřeb jeho uživatelů (tj. zákazníka). Prostředkem pro prevenci neúspěšnosti z důvodu nekvality bude oboustranná dohoda dokument obsahující požadovaná kritéria na produkt a míru jejich splnění. Může mít i formu SLA, kde budou podrobně specifikovány jednotlivé kvalitativní nároky na produkt.
- 4/4 -
1.13 Kritéria kvality programového systému
1.13 Kritéria kvality programového systému
Způsob stanovení kritérií kvality, měření kvality a dosahování požadované kvality programového systému.
1.1.
Pojem kvalita IS/IT Kvalita IS/IT je dána mírou, kterou IS/IT přispívá k výkonnosti a efektivnosti podnikových procesů, činností a uživatelů. IS/IT je kvalitní, jestliže splňuje požadavky nebo takový, který je způsobilý k zamýšlenému použití. Pro potřeby srovnání je ale třeba stanovit určité parametry kvality: 1. 2. 3. 4. 5.
funkčnost (plní funkci, pro kterou je určen) vzhled resp. komfort (způsob užívání, estetické působení) spolehlivost a udržovatelnost (stálý výkon po dobu životnosti, jednoduchost údržby) trvanlivost (dlouhá životnost, schopnost vývoje) bezpečnost (ergonomie, ekologičnost)
do jisté míry platí:
1.2.
kvalita = efektivnost
Uživatelská hlediska kvality IS/IT Z hlediska obsahu posuzuje uživatel informace podle toho: • jak jsou významné pro daný účel • zda jsou dostatečně přesné • za jsou dostatečně kompletní • zda jsou přiměřeně detailní • zda jsou získána ze spolehlivých zdrojů Z hlediska formy prezentace posuzuje, zda jsou informace: • předávány správným osobám • předávány včas z hlediska okamžiků jejich potřeb • předávány vhodným způsobem • srozumitelné příjemci
- 1/5 -
1.13 Kritéria kvality programového systému
1.3.
Technologická / technická kvalita IS/IT Technické hledisko IS postihuje aspekty podmiňující úspěšné provozování a údržbu IS/IT a tím i dosažení kvality z hlediska uživatelů. Nejvýznamnějšími kategoriemi jsou: • Provozní aspekty – zahrnují snadnost užívání v trvalém provozu, tj. zejména úroveň podpory pro průběžné sledování provozních charakteristik a řešení problémových stavů. • Aspekty údržby – jsou zaměřeny na vhodnost pro dlouhodobé užívání aplikace IS/IT, při kterém je třeba opravovat a rozšiřovat její funkčnost. Je hodnocena např. komplexnost, kvalita dokumentace, vícenásobná použitelnost komponent a možnosti testování. • Architektura řešení – ta úzce souvisí s dosažením dlouhodobé stability a spolehlivosti IS/IT. Vhodnými kritérii jsou zejména přenositelnost na různá systémová prostředí, rozšiřitelnost pro větší rozsah dat i uživatelů, vzájemná kompatibilita a propojitelnost a bezpečnostní hlediska.
1.4.
Praktické stanovení kritérií (technologické i uživatelské aspekty kvality) • • • • • • • • • • • • •
přesnost – systém se chová tak, jak je určeno ve specifikaci jeho funkcí spolehlivost – systém vykazuje minimum výpadků robustnost – systém se chová „rozumně“ i za krajních podmínek, které nebyly uvažovány při jeho specifikaci efektivnost – systém užívá počítačové zdroje ekonomicky a má vyvážené náklady s průchodností a dobou odezvy škálovatelnost – schopnost systému běžet na HW s různým výkonem přenositelnost – systém může běžet na různých platformách (HW,SW) bez ztráty funkcí propojitelnost – schopnost systému spolupracovat s jinými systémy udržovatelnost – systém může být snadno měněn podle dodatečných požadavků verifikovatelnost – vlastnosti systému mohou být snadno ověřeny dostupnost aplikací IS – je charakterizována rozsahem zpracování v reálném čase, dobou odezvy a možností přístupu k historickým datům. integrita a komplexnost IS – je dána stupněm korektnosti a integrity dat, jejich aktuálností a synchronizací. bezpečnost IS – jak a jakým způsobem aplikace zamezují neautorizovaným přístupům k informacím. snadnost užívání IS – zahrnuje hlediska jako jednoduchost, flexibilita, odolnost proti náhodným chybám, možnost individuální konfigurace ad.
Hodnocení uživatelské kvality se zpravidla provádí dotazníkovým průzkumem (přímým měřením a výpočty pouze tam, kde je to možné). Dalšími možnostmi měření je audit (externí nebo interní) nebo hloubkové pohovory. Úroveň kvantity: standardní, podstandardní, kritická, motivační Metriky měření – tvrdé (výsledkové, výkonnostní) nebo měkké (zralostní - CMM, spokojenost, …) - 2/5 -
1.13 Kritéria kvality programového systému
Metrika je měřitelný ukazatel použitý pro stanovení kvality, kvantity IS. měřitelný ukazatel použitý pro stanovení kvality IS. Tvrdé (objektivně, snadno měřitelné, převoditelné na finanční vyjádření; např. dostupnost, odezva, doba řešení požadavku); Měkké (špatně měřitelné, hodnotí se míra či úroveň informatické podpory jednotlivých procesů, hodnotí se auditním způsobem –alokace bodů) Tvrdé metriky jedná se o objektivně měřitelné ukazatele jsou snadno měřitelné dají se převést na finanční vyjádření Tvrdé metriky jsou výsledkové - jsou zaměřeny na dosažení cílů výkonnostní - jsou zaměřeny na měření výkonnosti a podporu příklad dostupnost (v procentech) běžná a maximální doba odezvy běžná a maximální doba řešení požadavků průměrná a mezní odezva aplikace v rámci služby Měkké metriky slouží k měření a hodnocení úrovně informatické podpory jednotlivých procesů, jsou koncipovány v souladu s účelem použití příklad ostatní metriky pro danou službu (kvalitativní ukazatele typu akceptace, zápis, potvrzení realizovaného školení a prezenční listina, hodnocení lektora školení, hodnocení účastníka školení apod. měkké metriky se hodnotí tzv. auditním způsobem. Vlastníci procesů či funkčních oblastí a jim náležejících metrik hodnotí prostřednictvím bodového ohodnocení (0-100 bodů) úroveň informatické podpory pro konkrétní klíčové aktivity, které byly vybrány pro hodnocení. Metriky v členění podle opakovatelnosti použití kontinuální (měření probíhá opakovaně) diskrétní - jsou aplikovány v časovém rozsahu
1.5.
Normy kvality IS/IT Mezinárodními normami definujícími systém kvality jsou normy ISO900X 2000. Hlavní normou je ISO9001 Systémy jakosti (Model zabezpečení jakosti při navrhování, výrobě, uvádění do provozu a servisu). Tato norma definuje základní součásti systému jakosti, které je třeba splnit pro získání certifikátu jakosti. Vedle snahy normalizovat procesní stránku jakosti (ISO9001) existuje i snaha normalizovat kontrolu jakosti produktu. Hlediska hodnocení SW produktu jsou definována v normách ISO/IEC 9126-1 Vyhodnocení jakosti SW produktu (nedefinuje metriky). Jak jakost měřit řeší norma ISO9126-2 Charakteristiky a metriky jakosti SW – Část 2: Externí metriky. Jedná se o metriky, které měří chování produktu v předem definovaném prostředí, aniž by se zabývaly jeho vnitřní strukturou. Jejich nevýhodou je to, že většinu z nich lze aplikovat až na hotový produkt a proto jsou skoro nepoužitelné jako nástroj pro řízení vývoje produktu. ISO9126-3 Charakteristiky a metriky jakosti SW – Část 3: Interní metriky. Jedná se o metriky měřící charakteristiky, které nelze odvodit z jeho chování v předem definovaném prostředí. Pro jejich použití je nutné znát vnitřní strukturu produktu. Slouží proto hlavně - 3/5 -
1.13 Kritéria kvality programového systému
jako nástroje při vývoji. Nevýhodou je nemožnost využití na měření všech charakteristik jakosti. ISO9126 dělí jakost SW produktu do 6 kategorií (tzv. charakteristiky). Cílem je minimální překrývání těchto charakteristik a jejich vzájemná nezávislost. Nepodařilo se.
obrázek 1 - model jakosti ISO 9126-1: charakteristiky a subcharakteristiky interní a externí jakosti
ISO9126-4 Charakteristiky a metriky SW – Část 4: Metriky jakosti v užití. Měří jakost, které dosahuje produkt při použití různými druhy uživatelů. Jakost užití SW
efektivnost
produktivita
bezpečnost
- 4/5 -
uspokojení
1.13 Kritéria kvality programového systému
1.6.
Úloha - předpoklady: Máte na starosti prodej aplikačního software zaměřeného na podporu ekonomickologistických agend. Zadání: • Budete ve fázi (před-)kontraktačního jednání zjišťovat kvalitativní požadavky potenciálního zákazníka, event. jakými metodami? • Jaké prostředky lze použít pro to, aby dodávka nebyla neúspěšná z důvodů „nekvality“?
V první řadě zjišťujeme, zda námi nabízený SW produkt plně pokryje zákazníkovy požadavky na funkčnost – to musí být samozřejmost. Tj. zda SW obsahuje všechny moduly podporující všechny „ekonomicko-logistické“ aktivity + další charakteristiky jako licence, počty současně pracujících uživatelů, způsoby přístupu k datům, architektura SW (klient/server) apod. V rámci požadavků na kvalitu pak můžeme vycházet z uvedených ISO standardů, např. ze systému kritérií ISO/IEC 9126, 14 598 (SW balíky) nebo jiných uznávaných standardů. Pokud zároveň zákazník některý ze standardů zná, pak zjistíme jeho požadavky na náš SW produkt v jednotlivých (sub)charakteristikách. Pokud ne, sami budeme vycházet s řady 9126 a zjišťovat požadavky zákazníka. Systém ISO by měl poskytovat co nevyčerpávající sestavu kritérií pro různé oblasti, které pro SW produkt přicházejí v úvahu, proto je vhodné řídit se právě jím. Případně lze ale jednoduše získat jen základní požadavky zákazníka: vždy je určující, že kvalita našeho SW je dána mírou uspokojení potřeb jeho uživatelů (tj. zákazníka). Prostředkem pro prevenci neúspěšnosti z důvodu nekvality bude oboustranná dohoda dokument obsahující požadovaná kritéria na produkt a míru jejich splnění. Může mít i formu SLA, kde budou podrobně specifikovány jednotlivé kvalitativní nároky na produkt.
- 5/5 -
1.14 Software - komplexní přehled a možnosti hodnocení
1.14 Software - komplexní přehled a možnosti hodnocení Celkový přehled, resp. klasifikace softwarových produktů. Možnosti hodnocení software a možnosti a problémy řešení jejich vzájemné integrace.
1.1.
Software je:
komplex programů, programových prostředků, zahrnuje především základní a aplikační software1
je prostředek využití hardware uživatelem (Obrázek 2)
programové vybavení - v informatice sada všech počítačových programů v počítači (na rozdíl od hardware, který zahrnuje všechny fyzické součásti počítače); zahrnuje aplikační software (pracuje s ním uživatel), operační systém (zajišťuje běh programů) a další (knihovny, middleware, BIOS, firmware apod.)2
is a general term used to describe a collection of computer programs, procedures and documentation that perform some tasks on a computer system3
all or part of the programs, procedures, rules, and associated documentation of an information processing system4
nezbytnou součástí aplikované informatiky, tvoří převážnou část informačních a komunikačních technologií, které spolu s lidmi a předmětem užití tvoří informační systémy (Obrázek 1)
Obrázek 2 – SW je prostředek využití 3 HW uživatelem
Obrázek 1 - Software a jeho místo v aplikované informatice
1
Každý program (aplikace) představuje formulaci určitého algoritmu vyjádřeného pomocí programovacího jazyka. Algoritmus v tomto smyslu označuje přesný a jednoznačný postup, kterým lze vyřešit daný typ úlohy. Důležitou vlastností algoritmu je opakovatelnost. Základními oblastmi aplikace jsou prezentační, aplikační a datová část. 1
Gála,Pour,Toman: Podniková informatika, Grada 2006
2
Wikipedia CZ: Software, http://cs.wikipedia.org/wiki/Software
3
Wikipedia EN: Software, http://en.wikipedia.org/wiki/Software
4
ISO/IEC 2382-1:1993 Information technology--Vocabulary--Part 1: Fundamental terms, SEVOCAB - 1/4 -
1.14 Software - komplexní přehled a možnosti hodnocení
1.2.
Klasifikace softwarových produktů Základní klasifikace vycházející z výše uvedených definic a je odvozena od úrovně blízkosti SW vzhledem k HW a uživateli, z čehož vyplývají 3 základní kategorie:
Základní software1 (System software3, ZSW) Je základním programovým vybavením umožňujícím využít počítač či jiné zařízení. Mezi vlastnosti ZSW patří: • vytváří prostředí pro spouštění aplikačního software (platforma provozu) • odstiňuje technická specifika hardware (počítačových zařízení a periferií) • měl by zabezpečit stabilní funkčnost a přístup k technickým prostředkům (HW) • patří do základní technologické infrastruktury informatiky Typy základního software: • Operační systémy (komplexně řídí HW, viz kniha Podniková informatika, str. 229) • Ovladače (zprostředkovatelé kom. mezi HW komponentami a OS; Device drivers) • Servery („Služební programy“ viz Podniková informatika, str. 233) • Middleware (integrační ZSW, „lepidlo“; Jiko blog, Podniková informatika, str. 234) • Firmware (specifický ZSW oživující HW např. viz Wikipedia: Firmware) • Virtualizační software (viz Wikipedia: Virtualizace) • Utility („Podpůrné programy“, různé pomocné rutinní operace viz například Wiki)
Aplikační software1 (Application software3, ASW) Je takové programové vybavení (aplikace), které slouží uživatelům při jejich činnostech, jako podpora vykonávaných procesů. Mezi vlastnosti ASW patří: • vyvolává potřebu ZSW, který zajišťuje prostředí pro spouštění (platforma provozu) • poskytuje uživatelům určitou funkcionalitu, v „moderním pojetí“ poskytuje službu či její část (služba = vyjadřuje komplex specifikovaných činností zajišťovaných poskytovatelem služby např. i za podpory ASW) • účelem aplikačního software je zpracování a řešení konkrétního problému uživatele, pro interakci s uživatelem má v počítači typicky grafické nebo textové rozhraní • při běhu dochází k transformaci dat (např. čtení, prezentaci, modifikaci, vytvoření, řazení, výpočtu, zápisu, uložení, odeslání dat) Typy aplikačního software (základní členění dle uživatele, dále dle účelu, užití): • Aplikace osobní informatiky (užívány jednotlivci, viz Podniková informatika, str. 53) → Kancelářské aplikace (zpracování tabulek /Excel/, textů /Word/, prezentací, atd) → Komunikační prostředky (internetový prohlížeč /IE, Chrome/, email /Outlook/, text-hlas, instant messaging, internetová telefonie VoIP /ICQ,Skype/) → Grafické programy (DTP; CAD, editor vektorové/rastrové grafiky /Adobe,Corel/) → Organizační a další softwarové prostředky - 2/4 -
1.14 Software - komplexní přehled a možnosti hodnocení
• Podnikové aplikace (celopodnikový aplikační SW, Podniková informatika, str. 47) → ERP (Enterprise Resource Planning; obvykle jádro aplikační architektury IS, pokrývá největší rozsah procesů a funkcí podniku, obecně jde o komplexní plánování podnikových zdrojů, tyto aplikace jsou označovány za celopodnikové, typickým představitelem s největším tržním podílem je ASW balík SAP, více v samostatné kapitole o ERP v Podniková informatika, str. 63, či Wiki) → BI (Business Intelligence; 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) → e-business aplikace (nejčastěji e-commerce typu B2B, B2C, Wiki) → aplikace rozšiřující ERP, tzv. (CRM, SCM, SRM, APS, PLM) → správa obsahu a workflow (ECM a workflow groupware) → další podnikové aplikace viz např. přehled na Wiki
Prostředky vývoje1 (Programming software3) Jsou specifické programové prostředky, které jsou určené pro vývoj software. Typy vývojových prostředků: • CASE (Computer Aided Software/Systém Engineering; komplex nástrojů pro podporu analýzy, návrhu a implementace IS/ICT a dalších činností /modelování/) • Integrovaná vývojová prostředí (IDEs, dnes ve vývoji největší význam, jde o balíky obsahující editor zdrojového kódu, překladač, interpret, ladění, verzování, návrhové prostředí grafického rozhraní, nástroje pro práci s objekty, komponentami, datová napojení, integrační podporu, podporu přípravy webových služeb /MS Visual Studio, Borland Delphi, atd./) • SDK (Software Development Kit; balíčky pro podporu snazšího vývoje aplikací /Java SDK/ )
Další možné kategorizace software následují. Dle typu vývoje (viz kniha Voříšek: Strategické řízení IS, 1997; metodika MMDIS, článek): •
IASW (Individuálně vyvíjený aplikační software) Vyvíjený pro konkrétní subjekt na zakázku poskytovatelem, či interně vlastními silami; ustupuje, velmi nákladné, dlouhá doba vývoje, výjimečné případy (jedinečný, specifický business proces; snaha maximalizovat bezpečnost – banky; či dosažení mimořádné konkurenční výhody; využíváno také pro rozvoj či doplnění TASW). Výhodou je obvykle adresné krytí požadavků uživatele, integrace se stávajícím ASW.
•
TASW (Typový aplikační software) Typový software, někdy označován za „krabicový“, obecně však jde především o software poskytovaný prostřednictvím nevýhradní licence, který je touto formou užíván více subjekty. Využívá se opakovaného užití, tzn. náklady na vývoj, legislativní aktualizace a další rozvoj jsou hrazeny všemi uživateli. Do tohoto režimu spadá dnes většina ASW. Problémem je někdy nedostatečné krytí potřeb uživatele (podniku), neintegrovatelnost, podmínky a vazby na dodavatele TASW. - 3/4 -
1.14 Software - komplexní přehled a možnosti hodnocení
1.3.
Hodnocení software – možné přístupy Hodnocení a parametry aplikačního software (ASW) viz otázka 3.4 (Podstatné parametry aplikačních programových balíků) a 1.13 (Kritéria kvality programového systému). Přístupy k hodnocení software obecně nejspíš budou doplněny.
1.4.
Integrace software – možnosti a problémy Integrace je obsahem samostatné otázky 1.7 (Systémová integrace). Celkový přehled ASW v podniku a jeho integrace by měl tzv. Aplikační architektury (zmíněno v otázce 1.11 Architektury IS/IT).
být
obsahem
Podrobnější informace k integraci SW nejspíš budou doplněny. Úloha - předpoklady: Jste analytikem útvaru informatiky průmyslového podniku a připravujete komplexní inovaci informačního systému firmy. Řešíte koncepci softwarového vybavení informačního systému. Zadání:
Jaké typy softwarových prostředků budete brát v úvahu, jak je rozčleníte pro další posuzování? V úvahu je třeba brát všechny typy prostředků, které budou třeba k pokrytí potřeb (procesů, projektů, příp. dalších aktivit) konkrétního průmyslového podniku. Na počátku plánu inovace samozřejmě jako analytik provedu analýzu současného stavu a z té bude nejlepší vyjít. Analýza by měla prověřit pokrytí především hlavních a dále vedlejších procesů (vyplynuvších z procesní analýzy, pokud ji dosud podnik nemá, provést) současným ASW. Nebude-li krytí dostatečné, vyplyne problémová situace, jelikož je žádoucí procesy za účelem jejich kontinuálního zlepšování, podporovat ASW, sbírat data, měřit, upravit = zlepšit atd. Snahou tedy bude nalézt takový ASW, který bude možné integrovat do stávající aplikační architektury a zaplnit mezery v podpoře businessu. Samozřejmě aplikujeme i MMDIS, zohledníme GST, odvodíme IST a je to doma.
Jaké hlavní společné a na druhé straně specifické parametry pro hodnocení a výběr software budete uvažovat? Společná kritéria: •
náklady na zavedení a provoz, vs. očekávaný přínos (např. typicky personální úspora)
•
integrovatelnost se současnou aplikační architekturou (+ standardy a otevřenost)
•
uživatelská přívětivost (kritérium přívětivosti SW obecně pro uživatele je zásadní)
•
reference SW u existujících uživatelů (+ služby, velikost a stabilita dodavatele)
•
doba implementace (zajímá nás celková předpokládaná doba zavedení SW)
Specifické parametry pro některé typy SW:
•
ZSW hodnocen a volen na základě potřeb ASW (od toho dále odvozen HW)
•
způsob poskytování SW (outsourcing - např. poskytováno jako webová služba / vlastní)
•
úroveň podpory procesu, ve kterém bude SW uplatněn (týká se specificky některých)
•
TASW či IASW (u některých typů SW bude otázka na místě)
Jaké hlavní problémy při řešení softwarové koncepce firmy očekáváte ? •
zesložitění stávající aplikační architektury a infrastruktury IS/ICT obecně
•
negativních dopadů dobře zamýšlených změn v reálu podniku (např. změna ASW typu ERP může ochromit na měsíce firmu a způsobit škody) - 4/4 -
1.15 Řízení týmů při vývoji IS
1.15 Řízení týmů při vývoji IS
Co je třeba zajistit pro úspěšný vývoj IS/ICT v týmu? Sestavení týmu, kvalifikační požadavky. Týmové role a jejich odpovědnosti v projektu. Řídicí komise projektu. Technologická podpora – uveďte příklady podpůrných produktů.
1.1.
Co je třeba zajistit pro úspěšný vývoj IS v týmu? Účelem řízení projektu je optimalizovat spotřebu lidských, finančních, materiálových a dalších zdrojů tak aby se s minimálními nároky na kapacitu těchto zdrojů dosáhlo v plánovaném čase požadovaných cílů IS/IT. Řízení projektů zahrnuje: tvorba plánu projektu - zahrnuje: •
Zadání projektu - Obsahuje cíle a rozsah projektu (tj. co se bude dělat). Tyto informace se určí ještě před plánováním. Struktura projektu - Obsahuje přehled projektových činností, které bude nutné provést. Harmonogram a rozpočet - Obsahuje činnosti rozplánované do jednotlivých dní, týdnů, měsíců. Obsahuje odhad nákladů na projekt. Zhodnocení proveditelnosti projektu - Obsahuje zhodnocení realizovatelnosti harmonogramu, projektu, posouzení důvěryhodnosti plánu apod. Organizace projektu - Obsahuje přehled lidí, kteří se budou na projektu podílet a jejich role. Obsahuje, jaké osoby tvoří řídící výbor (radu), projekční týmy, atd. Musí být přiřazeny lidé k jednotlivým činnostem. Řídící a kontrolní procedury (postupy) - Obsahuje přehled postupů určených pro zajištění požadované kvality výsledného produktu, pro provádění změn apod.
• • • • •
mapování a vytvoření potřebných projekčních zdrojů, tzn. vytvoření projektových a programátorských týmů, zajištění technicko-programových podmínek pro přípravu projektů (příprava a ladění programů, příprava a instalace technických prostředků apod.), výběr standardních programových prostředků plánování projekčních postupů, stanovení harmonogramu řešení projektu, jednotlivých subsystémů úloh, specifikace objemu proj. prací vzhledem k rozsahu a stanovení nároků jednotlivých úloh na pracovníky vyjadřované v tzv. člověkodnech organizace a přiřazování projekčních zdrojů (lidí, techniky, atd.) k plánovaným projekčním procesům, úlohám stanovení závazných pravidel a konvencí pro tvorbu projektů • • • •
•
v oblasti dokumentace - pro dodržování jednotné struktury dokumentace, stejné terminologie atd. v oblasti komunikace, resp. uživ. interface - dodržování jednotné formy obrazovkových formátů, jazyka funkcí v oblasti projekčních metod - jejich výběr a standardizace v oblasti programových prostředků a aplikačních programů - jejich výběr (progr. jazyků, databázových procesorů, tab. kalkulátorů, text. procesorů atd.) a jejich standard. použití, stanovení struktury aplikačních programů v oblasti identifikace uživatelů, technických prostředků, programů, dat - stanovením konvencí pro tvorbu těchto označení apod.
kontrola dodržování stanovených harmonogramů projektu a stavu kapacit projektu, definovaných pravidel a konvencí a operativní opatření při zjištěných nedostatcích.
- 1/4 -
1.15 Řízení týmů při vývoji IS
1.2.
Sestavení týmu, kvalifikační požadavky.
Role v projektu je možné obecně rozdělit na projekční a uživatelské. Role projekční (realizační) pak mohou být dále členěny na: řídící a výkonné. Obsazení týmu rolemi závisí na rozsahu projektu, jeho charakteru, rozpočtu, aj. Řídící projekční role
Výkonné projekční role
Uživatelské role
Zástupce vedení na straně dodavatele Správce dokumentace
Specialista na informační strategii
Sponzor (výkonný sponzor)
Specialista na BPR dané oblasti
Koordinátor prací za uživatele
Plánovač Vedoucí technolog
Implementátor Vedoucí analytik / analytik
Klíčoví uživatelé Koncový uživatel
Správce rozpočtu
Vedoucí programátor / programátor
Informatik
Vedoucí etapy
Vedoucí programátor
Dohled nad kvalitou
Administrátor databáze
Specialisté na jednotlivé věcné oblasti Administrátor systému
Správce sítě Vedoucí tester / Tester Školitel Metodik (řízení, analýzy, programování) Provozní podpora
1.3.
Týmové role a jejich odpovědnosti v projektu.
Obrázek 1 Role v řízení projektu
Následující tabulka obsahuje shrnutí nejvýznamnějších rolí projektu včetně definice jejich zodpovědností. - 2/4 -
1.15 Řízení týmů při vývoji IS
Role dodavatele
Odpovědnosti Vytváří plán projektu Navrhuje a řídí práci vedoucích etap Určuje odpovědnosti, přiděluje a kontroluje úlohy podřízených zaměstnanců na projektu Řídí postup projektu a sleduje jej věcně i finančně
Vedoucí projektu
Sleduje postup prací, jejich kvalitu a vnější vlivy Informuje řídící komisi projektu Kompletuje požadavky na změny Zajišťování potřebné kvalifikace členů týmu Analyzuje postup projektu a práci vedoucích a členů týmů Zajišťuje úpravy plánu postupu projektu ve styku se zástupcem sponzora a vedoucími týmů U menších projektů splývá role vedoucího etapy s Vedoucím Vytváří plán a řídí postup etapy Určuje odpovědnost, přiděluje a kontroluje úkoly podřízeným zaměstnancům v rámci jím řízené etapy projektu
Vedoucí etapy
Sleduje postup prací, jejich kvalitu a vnější vlivy Informuje vedoucího projektu Připravuje požadavky na změny Zajišťování potřebné kvalifikace členů týmu Analyzuje postup projektu a práci vedoucích a členů týmů Informuje členy týmu o jejich úkolech v rámci realizace výstupů projektu
Vedoucí týmu Organizuje a řídí práci členů týmu projektu Komunikuje s vedoucím etapy, vedoucím projektu Má společný cíl Příslušnost k týmu je bez hierarchie
Řešitelský tým
Je hodnocen jako celek Je dočasný účelově sestavený Role v řešitelském týmu složené dle požadovaných charakteristických vlastností, viz Belbinovy role Tým kvality vypracovává plán kontroly kvality
Tým kvality
Zodpovídá za průběžnou kontrolu kvality jednotlivých výstupů projektu Tým kvality se schází v období přípravy milníků projektu (před odevzdáním jednotlivých výstupů) a provádí kontrolu jejich kvality Zpráva o výsledcích kontroly kvality je předávána vedoucímu projektu, řídící komisi projektu
Tým akceptace
Tým akceptace musí být tvořen zástupci všech tří skupin rolí (sponzor, dodavatel, uživatel) Vypracovává plán akceptace Zodpovídá za provedení akceptačního řízení jednotlivých výstupů projektu Předání zprávy o výsledcích akceptačního řízení vedoucímu projektu, řídící komisi projektu Pro některé projekty je sestavován zvláštní tým pro řízení změn v projektu
Tým řízení změn
1.4.
Tým řízení změn musí být tvořen zástupci všech tří skupin rolí (sponzor, dodavatel, uživatel) Jednání týmu je vyvoláno potřebou připravit a projednat projektovou změnu Výsledky práce jsou ve formě standardního dokumentu projektová změna předávány vedoucímu projektu, který je zapracovává do zpráv z průběhu projektu (etapy)
Řídící komise projektu. •
nejvyšší orgán projektu - je jmenována statutárními zástupci
- 3/4 -
1.15 Řízení týmů při vývoji IS
• • • • • •
1.5.
rozhoduje o projektu (o plánech, kapacitách, rozpočtu, smluvním řešení, změnách, jmenuje jednotlivé týmy) vedoucí projektu je jí přímo podřízen rozhoduje konsensem její jednání je formalizované - pozvání, zápisy… má maximálně 9 členů (zákazník by měl mít o jednoho více) složení: → zástupci zákazníka - výkonný sponzor, vedoucí informatik, koordinátor, klíčový uživatel → zástupci dodavatele - zástupci vedení, vedoucí projektu, vedoucí analytik, vedoucí programátor
Technologická podpora Technologická podpora týmové práce: Plánování (času, rozdělení prací,...): MS Excel,MS Word, MS Project Správa verzí: SourceSafe (Microsoft), ClearCase (Rational) Správa požadavků: ClearQuest (Rational)
1.6.
Úloha - předpoklady Jste vedoucím projektu vývoje IS/ICT a právě tvoříte plán tohoto projektu. Zadání:
• Podle jakých kriterií se budete rozhodovat o personálním obsazení a potřebném technickém vybavení projektu?
• Jakou sestavu řídicí komise projektu navrhnete (v závislosti na čem)?
Personální obsazení – musí se rozpočítat podle předpokládané doby trvání projektu a časové náročnosti vyjádřené v člověkohodinách nebo člověkodnech – expertní odhady. Je třeba vzít v úvahu jednak příslušnou kvalifikaci, ale také schopnost týmové spolupráce. Na tuto schopnost existuje řada testů a metodik, např. Belbinovy role (inovátor, vyhledávač zdrojů a příležitostí, koordinátor, formovač, vyhodnocovač, týmový pracovník, realizátor, dotahovač, specialista) Optimální je, pokud vedoucí své lidi zná, ale pozor na skupinové myšlení! V neposlední řadě je třeba vzít v úvahu i velikost rozpočtu - trojúhelník rychle, dobře, levně. Taky jde o to, jak rozsáhlý je to projekt – u drobného vylepšení nějaké dílčí části není třeba dělat rozsáhlou analýzu, ale zvládne to jeden vývojář sám (pokud ho donutíme to zadokumentovat), u rozsáhlých projektů je třeba velké úsilí na řízení, na zabezpečení technické i na vzájemnou komunikaci. Sestava řídící komise závisí na typu, rozsahu, rozpočtu a důležitosti projektu. Musí tam být vedoucí zástupci všech dodavatelů (externích i interních) + všichni zúčastnění zadavatelé. Maximálně 9 lidí, přičemž zástupci zadavatele mají mít většinu.
- 4/4 -
1.23 Internet, Intranet, Extranet
1.23 Internet, Intranet, Extranet
Charakterizujte Internet, Intranet, Extranet – definujte základní rozdíly. Specifikujte využití jejich služeb v jednotlivých sférách společnosti (firma, státní správa, jednotlivec apod.). Uveďte příklady užití. Specifikujte možné přínosy a rizika.
1.1.
Internet Internet je nejznámějším představitelem globální informační infrastruktury (= komunikace provozované na celosvětové síti rychlých komunikačních kanálů, HW, SW a lidí s cílem umožnit nové služby a strategické aktivity založené na využívání všech typů informací).
Prostředí, které podnikům: přináší novou platformu vývoje a provozování aplikací IS/IT, umožňuje získat konkurenční výhodu, umožňuje laciněji a rychleji získat velké množství informací, přináší prostředí, ve kterém se provozují nejrůznější obchodní, informatické a vědeckovýzkumné aktivity. Internet Globální síť vytvořená z jednotlivých telekomunikačních sítí propojujících počítače. Původně navržena pro výzkumnou komunitu s cílem vybudovat redundantní přístupové cesty pro případ poškození některé části telekomunikační sítě. Historie Internetu vznikl jako experiment amerického ministerstva obrany, který měl ověřit možnost vybudování počítačové sítě propojující místa velení a schopnou přežít i jaderný úder nepřítele. Studie dospěla k závěru, že jedinou možností je nevytvářet v síti žádný centrální prvek - který by jistě byl prvním cílem nepřítele - a pak také nutnost předem počítat s nespolehlivostí přenosových cest (které může nepřítel kdykoli „odstřelit", ale síť jako celek by to měla přežít). Důsledkem pak bylo i zjištění, že „klasické" přenosové technologie na bázi přepojování okruhů, v tehdejší době zcela dominující ve světě spojů, nejsou pro daný účel použitelné (když nepřítel „odstřelí" část sítě, přeruší tím již zřízený okruh). Přednost proto dostala myšlenka přepojování paketů, pocházející právě od zmíněné Rand Corporation. Světlo světa tak spatřila síť ARPANET, pojmenovaná po grantové agentuře ARPA (Advanced Research Projects Agency) - což byla účelová organizace ministerstva obrany USA (DoD, Department of Defense), skrz kterou „tekly peníze" od vojáků do akademické sféry, která výzkum skutečně zajišťovala. Původní ARPANET byl tedy vybudován na technologii přepojování paketů. Původní implementace se ukázala jako nepříliš vhodná pro praktické použití V průběhu 70. let zrodily protokoly TCP/IP. Časem (postupně cca od roku 1980, definitivně k 1.1.1983) na ně přešla i síť ARPANET, která postupně přerostla až v dnešní Internet.
1.1.1.
Fungování Internetu: Na počítači uživatele pracuje webový prohlížeč (Browser), který postupně čte a zobrazuje textové informace po jednotlivých stránkách. Příslušný dokument je umístěn na serveru. Komunikace mezi klientem a serverem probíhá v protokolu HTTP. Stránky jsou vytvořeny - 1/5 -
1.23 Internet, Intranet, Extranet
v jazyku HTML. Vedle textu obsahují stránky také propojení. Některé odkazy nevedou k jiným stránkám na Internetu, ale k souborům dostupným přes standardní protokol FTP.
1.2.
Intranet Podniková síť, která využívá internetovské technologie, je zabezpečena a slouží k provozování interních podnikových aplikací. Intranet je takové nasazení technologií pocházejících ze světa Internetu, které slouží například • •
sdílení informací provozování informačních systémů v relativně uzavřených komunitách uživatelů (typicky v jednotlivých firmách, podnicích, organizacích apod.)
Obrat na trhu intranetu dosáhnul v roce 1995 výše 142 milionů USD, a na rok 1996 předpovídají 488 milionů, zatímco na rok 1997 již obrat ve výši 1,2 miliardy dolarů.
1.3.
Extranet Rozšíření intranetu na dva a více podniků (např. dodavatelů, obchodních partnerů). Jde o vzájemně komunikující prostředí dvou a více podniků, které pro své obchodní, řídící a informační aktivity interně používají intranet.
www – systém, který umožňuje snadnou identifikaci a vyhledávání dokumentů uložených na počítačích připojených do internetu. Dokumenty uložené na www obsahují adresu URL, která slouží k identifikaci.
http (Hypertext Transport Protocol) – protokol komunikace mezi klientem a serverem. HTML(Hyper Text Markup Language) – jazyk tvořící jednotlivé stránky netu Ftp(File Transfer Protocol) – standardní protokol pro manipulaci se soubory po netu
1.4.
Základní rozdíly Internet je veřejný, přístupný všem Intranet pouze podniková síť, která je od Internetu oddělena, pouze pro členy organizace a pro autorizované osoby z řad dodavatelů Extranet propojení podnikových sítí – intranetů – omezený přístup z obou organizací - neveřejný. Specifikujte využití jejich služeb v jednotlivých sférách společnosti
1.5.
Využití jejich služeb v jednotlivých sférách společnosti (firma, státní správa, jednotlivec apod.). - 2/5 -
1.23 Internet, Intranet, Extranet
Firma Vnitrofiremní systémy – intranet Prezentace a aplikace pro veřejnost - Intranet Propojení s dodavateli a odběrateli – Extranet Státní správa vnitřní systém – intranet Propojení na ostatní složky správy – extranet Styk s veřejností – Internet Jednotlivec informace aj. – Internet
1.6. Rizika bezpečnost – neautorizované osoby, hackeři, viry.
1.7. Přínosy 1.7.1.
Aplikace IS/IT: Internet, Intranet a Extranet ovlivňují chování podniku nejen tím, že vytvářejí nové příležitosti, ale spolu s nimi se objevují i nové nároky na řízení podniku. Internet nabízí: přístup k informacím (např. marketing) přístup k datům (např. služby, subdodávky,..) transakční zpracování (např. el. obchod) Intranet nabízí: na úrovni přístupu k informacím (např. telefonní seznamy, ceníky,...) na úrovni přístupu k datům (např. ekonomické aplikace, personalistiku,..) na úrovni transakčního zpracování (různé druhy obchodních transakcí).
1.7.2.
Pro podnik díky globální komunikační síti nabízí produkty potenciálním zákazníkům na celém světě a v reálném čase a s nízkými náklady získává jejich reakci a poptávku ⇒ nabídka mnohem většímu trhu ⇒ ale na takto informovaném trhu roste daleko více a rychleji konkurence ⇒ co nejrychlejší reakce podniků ⇒ změna na dynamickou organizaci ⇒ změna obchodního modelu ⇒ co nejrychlejší a nejjednodušší kontakt se zákazníkem. Dále vytěsnění (outsourcing) málo efektivních aktivit podniku. Nové aplikace (el. marketing, el. podnikání,..) vedou k: • odstranění mezičlánku v řetězci výrobce – distributor – zákazník přímý vztah mezi prodávajícím a kupujícím (zkrácení času mezi nabídkou a poptávkou), podpora péče o zákazníka ⇒ větší zákaznická spokojenost • ke sdílení znalostí rozlišujícím faktorem v konkurenční soutěži se stane informační obsluha, která poskytne stručnou a přesnou informaci o výrobku nebo službě, bude předvídavá v odhadu zákaznického zájmu a bude reagovat na momentální poptávku a zájem • vzniku nového vztahu výrobce – zákazník - 3/5 -
1.23 Internet, Intranet, Extranet
informace z tohoto vztahu získané poskytují řadu demografických údajů a odpovědí, které objasňují zákaznická očekávání. Vhodné je využít katalogy vystavěné na webu, interaktivní nabídkové aplikace udržující se zákazníkem dialog ⇒ upevnění zákaznické loajality 1.7.3.
pracovní sílu rostou nároky na pružnost pracovní síly = ochota akceptovat celoživotní vzdělávání jako životní styl, ochota k opakovanému doškolování a vzdělávání, změna specializace, ale i stěhování za pracovní příležitostí. Objevuje se nový prvek teleworking (= práce na dálku) – pro firmy to znamená snížení režie, zvýšení flexibility a rychlosti reakce na změny na trhu. ⇒ vznik nových pracovních příležitostí, pozvolný zánik tradičních pracovních uplatnění.
1.7.4.
společnost, rodinu, občana a demokracii ve společnosti hraje rozhodující roli přístup občanů k informacím ⇒ pečovat o to aby nevznikla společnost rozdělená informačně (ti, co přístup k informacím mají x ti, co ne). Změna životního stylu (práce na dálku, přístup věří k informacím na internetu); růst nároků na pedagogickou osvícenost učitelů a rodičů; schopnost informaci zařadit, vybrat důležité, nalézt a soustředit se na podstatné souvislosti. Pozitivní rozvoj člověka v oblasti školství, vědy, kultury ale i zábavy. Prostor k zneužití (třídní a rasová nenávist, dětská pornografie,...).
1.7.5.
státní administrativu informace se stala klíčovým rozlišujícím faktorem prakticky všech výrobků a služeb. Aktivity provozované prostřednictvím Internetu přesahují národní hranice a tedy i působnost národní jurisdikatur to, spolu s problémy zneužívání Internetu, vyžaduje stálou mezinárodní spolupráci při úpravě a slaďování zákonů. V tomto prostředí budou úspěšné ty státy, jejichž státní administrativa vytvoří pro podnikání prostředí, ve kterém bude možné co nejefektivněji získat informace a ty pak použít.
Úloha – předpoklady: Jste v pozici pracovníka, který má obhájit v organizaci vývoj a nasazení Intranet aplikací. Zadání:
Navrhněte obsah a strukturu argumentace, která povede k prosazení projektu.
Vývoj intranetových aplikací je levný a rychlý, snadná úprava a integrace do celku s ostatními aplikacemi, moderní technologie, minimální požadavky na HW, umožňuje zpracování informací způsobem, na který jsou uživatelé zvyklí z internetu – hypertext,
- 4/5 -
1.23 Internet, Intranet, Extranet
obrázky, grafy, video, ale i tabulky (výstupy z databází), možnost tisku toho, co je na obrazovce. Ovládání – opět standardní – webovský prohlížeč.
- 5/5 -
1.17 Architektura řízení vztahů se zákazníky
1.17 Architektura řízení vztahů se zákazníky Fáze CRM souvisejí s jednotlivými částmi obchodního cyklu a s životním cyklem zákazníka. Jak technologie CRM tyto souvislosti podporuje. Architektura řízení vztahů se zákazníky. Její vývoj jako jednoho z rozhodujících procesů výrazně ovlivňujících konkurenceschopnost firmy
1.1.
1.2.
Životní cyklus zákazníka (CLC)
Sledování vývoje
Formulace požadavků
Výběr dodavatele
Vybudování znalostí
Specifikace řešení
Naplánování
Objednání
Placení
Převzetí
Nasazení a užití
Kontrola
Udržení
Zhodnocení
Kontrola
Obchodní cyklus
Marketingové aktivity - 1/4 -
1.17 Architektura řízení vztahů se zákazníky
1.3.
1.4.
Řízení příležitostí
Prodejní aktivity
Servisní aktivity + odhad budoucích potřeb
Fáze CRM
Identifikace zákazníka
Uzavření kontraktu
Plnění kontraktu
Péče o zákazníka, jeho udržení
Aplikační architektura CRM
Tři základní části: operační, analytickou a kooperativní.
1. Operační část CRM je zaměřena na automatizaci a řízení základních podnikových procesů týkajících se služeb, marketingu a obchodu. Jejím primárním úkolem je zajištění co největší efektivnosti existujících procesů. Můžeme je dále rozdělit na podpůrné aplikace (Back Office) nebo aplikace využívané v kontaktu se zákazníkem (Front Office). 2. Analytická část CRM Veškerá data, která podnik shromažďuje o zákaznících, vyžadují průběžnou analytickou práci, jejíž výsledky jsou podkladem pro řízení podniku založeného na faktech. Přirozeně, že tato část CRM úzce souvisí s využíváním datových skladů. Aplikace, které analýzu provádějí, využívají veškerá data získaná v operační části a při vlastní interakci se zákazníkem. 3. Kolaborativní část CRM
zajišťuje spolupráci s okolím organizace
řadíme sem: o
aplikace mobile office podporující práci obchodníků na místě u zákazníka (mobil),
o
podpora komunikace přes web a e-mail,
o
nástroje určené k řízení kontaktních center
- 2/4 -
1.17 Architektura řízení vztahů se zákazníky
1.5.
Vývojová stadia CRM
Tradiční CRM: většina podniků začíná s budováním CRM tak, že v první fázi se nejčastěji snaží o vytvoření jednotné databáze o zákaznících, která se bude používat v celém podniku. V dalším kroku se zpřístupní alespoň některé informace o zákaznících na webových stránkách (ceníky, stav objednávky, dodávky apod.). Začíná se využívat potenciálu elektronického obchodu pro poskytnutí většího pohodlí zákazníkům, ale vlastní podnikové procesy zůstávají zatím nedotčeny. Jde o první stadium budování CRM.
Pokročilé CRM: instaluje software CRM (Back Office) poskytující vedle řízení kontaktů, marketingu a obchodu také příslušné analytické nástroje na jejich vyhodnocování. Jde již o rozbor zákaznické loajality, individualizaci kontaktu se zákazníkem (s každým nejednáme stejně, může existovat skupina zákazníků. která svojí existencí rozhoduje o bytí a nebytí podniku) a o nastavení přesných pravidel vedoucích k tomu, že podnik se z hlediska zákazníka vždy chová transparentně, pokud možno předvídatelně a stejně ve všech svých odděleních. Jde již o druhé, pokročilé stadium budování CRM, ve kterém některé firmy budují kontaktní centra nebo je výrazně inovují.
Aktualizované CRM: v poslední fázi dochází tam, kde existují kontaktní centra, k jejich podpoře a k integraci jejich softwaru se softwarem Back Office. Pracuje se na integraci zděděných systémů ERP, SCM či jiných se softwarem CRM, dochází k propojování se systémy business partnerů a v některých případech dokonce k aliancím dosud konkurenčních firem disponujících komplementární nabídkou. To se děje s cílem vytvořit řešení, které zákazníka maximálně uspokojí. Z uvedených aktivit vyplývá, že v této fázi CRM dochází k přestavění těch podnikových procesů, které se nějakým způsobem týkají zákazníka.
- 3/4 -
1.17 Architektura řízení vztahů se zákazníky
Úloha - předpoklady: Jste asistentem obchodního náměstka firmy vyrábějící spotřební elektroniku a fungující současně jako distributor osobních počítačů. Váš obrat se poslední čtyři roky zvyšoval v meziročním nárůstu o 5%, a to proto, že jste přesvědčil/a vedení o nezbytnosti zvýšení počtu obchodníků. Můžete také doložit mírný růst zákaznické spokojenosti za poslední dva roky. Vaše náklady však rostly průměrně o 8%, a to zejména díky platům obchodních zástupců. Váš finanční ředitel trvá na zastavení trendu poklesu zisku a vyžaduje propuštění průměrně 10% zaměstnanců, tentokrát včetně obchodních zástupců. Zadání:
Jak budete postupovat? Jaké další údaje si případně od finančního útvaru vyžádáte?
Vyžádat si čísla, jak se rostoucí spokojenost zákazníků projevila na obratu společnosti a na zisku. Ideálně analyzovat strukturu nákladů napříč společností a snažit se identifikovat jiné místo úspor než obchodních zástupců. Případně apelovat na změnu smluv s větším podílem výkonové složky …..
Jaké možné alternativy řešení vidíte?
Vyhovět vedení, trvat na stávajícím řešení s myšlenkou ustálení se situace v X kvartálech, nalézt jiné řešení třeba změna způsobu odměňování
- 4/4 -
1.18 Úlohy řízení provozu Činnosti provozu IS/ICT ve velkých a středních organizacích. Úloha HelpDesku při provozu IS/ICT. Souvislosti vývoje IS/ICT a provozu IS/ICT. Služby IS/ICT a jejich zajištění provozovaným IS/ICT. Produkty a nástroje pro podporu řízení provozu. Formy zajištění provozu IS/ICT (interní provoz, outsourcing)
1.1. 1.2. 1.3.
Činnosti provozu ve velkých a středních organizacích Starost o HW, SW a LAN Správa LAN v rozsahu od kabeláže, přes nastavování až měření průchodnosti Správa SW od uživatelů, licencí, přístupová práva až po aplikace Správa HW Moderní trend standardizace od koncových stanic až po servery v aplikační rovině virtualizace HW u serverů až po jednotné programové vybavení už.stanic Druhým trendem je outsourcing a offshoring IT Třetí trend je důsledná implementace monitoringu od HW systémů, přes Aplikace až po transakce ( HP OpenView, IBM Tivoli Monitoring, Nagios –open source) Úloha HelpDesku při provozu IT/ICT Účelem je zajištění komunikace mezi uživatelem IT a provozními správcy Dělení na Interní a Externí helpdesk Interní hlp – prostředek komunikace se zaměstnanci organizace, pokud HW,SW nefunguje. Externí hlp- komunikace pro vnější uživatele, většinou zákazníky společnosti, že dodávaná služba nefunguje Formy helpdesku – email, telefon, www stránky s trakingem řešení (nejčastější a nejvýhodnější) Souvislosti vývoje IS/ICT a provozu IS/ICT. Služby IS/ICT a jejich zajištění provozovaným IS/ICT /tady improvizace/ Provoz IS/ICT je úzce spojen s problematikou formy pořízení (IASW, TASW, vlastní síly, outsourcing) Zajistění provozu IS/ICT je součástí Operativního řízení (viz. obr. níže)
1.4.
1.5.
Produkty a nástroje pro podporu řízení provozu Řízení provozu pomocí dohledových systémů, pomocí metrik (zvolených i osobně definovaných) Primárně se u systémů sleduje: dostupnost, průchodnost a znich počítaná spolehlivost Požadavek na metriky definován v SLA, obzvláště jedná li se o outsourcing služby Dělení dohledových systémů na Performance (spojitá měřitelná data) a Events (výskyt událostí) Dělení systémů z pohledu sledovaných objektů na: o Desktop management o Network management o Řízení bezpečnosti o Řízení paměti o Řízení aplikací o IT Service level management Formy zajištění provozu IS/ICT (interní provoz, outsourcing)
Interní provoz o Výhody: znalost prostředí a systémů, možná rychlá reakce, sledování dlouhodobého vývoje, rychlá úprava úrovně sledování o Nevýhody: cena (není ekonomické mít lidi alokované pouze na sledování dashboardu, v případě člověka alok. I na toto krom jiné práce je v případě události pomalá reakce)´ Outsourcing: řekl bych opak interního provozu
Úloha - předpoklady: Jste odpovědný za provoz IS/ICT v malé organizaci. Jak navrhnete jeho organizační zajištění. Rozdělit problémy na o Požadavky na HW, SW (nové věci) o Problémy Nejdříve řeším problémy a až pak požadavky Spad problémů by se měl mít nastavené priority Bud rozhodnout se, že outsourcovat, nebo vlastními silami ….
1.18. Úlohy řízení provozu IS/ICT Činnosti provozu IS/ICT ve velkých a středních organizacích. Úloha HelpDesku při provozu IS/ICT. Souvislosti vývoje IS/ICT a provozu IS/ICT. Služby IS/ICT a jejich zajištění provozovaným IS/ICT. Produkty a nástroje pro podporu řízení provozu. Formy zajištění provozu IS/ICT (interní provoz, outsourcing) Úloha předpoklady: Jste odpovědný za provoz IS/ICT v malé organizaci. Jak navrhnete jeho organizační zajištění?
1
Činnosti provozu IS/ICT ve velkých a středních organizacích.
Tento podnikový útvar má za úkol obhospodařovat technologickou infrastrukturu podniku. Stará se jak o hardware, tak o software. Ve velkých a středních organizacích jsou desítky, stovky i tisíce počítačů s různě distribuovanými a sdílenými aplikacemi a daty. Provoz IS/ICT zajišťuje správu sítě LAN (činnosti v rozsahu od pokládání kabelů, management uživatelů až k měření průchodnosti sítě), správu softwaru (licencí, uživatelů, přístupových práv), správu databází a jiných softwarových i hardwarových prvků. Vzhledem ke složitosti velkých LAN sítí, přistupují dnes firmy k principu standardizace a to jak v oblasti hardwaru, tak v oblasti softwaru. V praxi to znamená, že se provoz IS/ICT snaží všude nainstalovat stejné počítače na stejné platformě se stejnými programy, aby pak realizoval úspory s rozsahu při opravování prvků sítě. Druhým převládajícím trendem je outsourcing provozu IS/ICT. Ten umožňují především dohledové systémy jako HP OpenView nebo IBM Tivoli, nicméně dohledové systémy samozřejmě využívá i interní provoz. Jedním ze způsobů komunikace uživatelů s provozem IS/ICT je HelpDesk. Nesmí se totiž stát, že vás jak informatika někdo zastaví na chodbě a poprosí vás,
jestli byste mu tam něco neopravili. Všechno musí jít přes HelpDesk kvůli sledování a aby v tom nevznikl bordel.
2
Úloha HelpDesku při provozu IS/ICT.
HelpDesk běžně dělíme na dvě části – interní a externí. Externí HelpDesk je pro vnější uživatele našeho informačního systému, slouží zákazníkům při řešení jejich problémů s naším produktem. Zpravidla je prezentován možností dotazu po e-mailu, formulářem a telefonické podpory. Pozor, jako telefonní operátoři nepracují pracovníci provozu, ale méně vzdělaní lidé. Nesmí existovat přímý kontakt uživatele na technika, to vede k neefektivitě. Dotazy musí být filtrované. Jednoduché dotazy musí zodpovědět operátor HelpDesku sám. Interní HelpDesk je prostředek komunikace provozu IS/ICT se zaměstnanci (uživateli). Je preferován HelpDesk přes formuláře a e-mail. Technici se tím příliš nezatěžují a pracují na problémech, když na ně mají čas. V zásadě dělíme dotazy na dva druhy – a) něco nefunguje (HW,SW) a je potřeba to opravit, vyměnit, přeinstalovat, případně jen poradit s postupem; a za b) uživatel vytvořil požadavek na novou technologii. Zde je potřeba vyhodnotit oprávněnost požadavku, finanční možnosti firmy vzhledem k zakoupení nové technologie a najít někoho, kdo je oprávněn takovou operaci podepsat (zpravidla je to vedoucí odboru informatiky po pohádání se s finančním ředitelem).
3
Souvislosti vývoje IS/ICT a provozu IS/ICT. Služby IS/ICT a jejich zajištění provozovaným IS/ICT.
IS/ICT je ve firmě vyvíjen, a to buď interními silami (zpravidla se na tom podílí provoz IS/ICT) nebo externě (zakoupením nějaké části podnikové infrastruktury). Na to přirozeně musí provoz IS/ICT reagovat a vývoj absorbovat. Služby IS/ICT zajišťuje právě provoz IS/ICT. Toto je model řízení informatiky společnosti ITG
1 - Strategické řízení IS/ICT (cíle, architektury, standardy, projekty, harmonogram, rozpočet, organizace a pravidla řízení, ...) Taktické řízení IS/ICT
Řízení služeb IS/ICT
Řízení zdrojů IS/ICT
2 - Řízení (vývoj, nákup prodej) služeb ve vztahu k zákazníkům a dodavatelům
3 - Řízení ekonomiky - finančních zdrojů
8 - Řízení vlastností služeb (užitečnost, hospodárnost, bezpečnost, shoda s legislativou, řízení rizik)
Plánování, organizace, integrace, koordinace rozvoje IS/ICT
4 - Řízení personálních zdrojů v IS/ICT 5 - Řízení datových zdrojů 6 - Řízení technologických zdrojů a konfigurací (ASW, ZSW, HW, síť LAN a WAN)
Operativní řízení IS/ICT 7 - Řízení jednotlivých projektů rozvoje IS/ICT (vývoj, údržba, implementace)
9 - Řízení provozu IS/ICT (služeb a zdrojů)
Nás zajímá vlastně jen 9 (řízení provozu): 9 - Řízení provozu zahrnuje veškeré řídící aktivity spojené s provozem celého informačního systému a jeho jednotlivých komponent. Cílem řízení provozu je zajistit provoz jednotlivých aplikací a požadovanou úroveň konzultační a technické podpory uživatelů. Řízení provozu sleduje i dosažení optimální disponibility informačního systému, tzn. zajištění bezpečnosti a spolehlivosti provozu,
požadované doby odezvy jednotlivých aplikací, zajištění požadovaného výkonu, včetně jeho špičkového zatížení. Cílem řízení je tu rovněž optimalizace nákladů na provoz IS/ICT podniku.
4
Produkty a nástroje pro podporu řízení provozu. Formy zajištění provozu IS/ICT (interní provoz, outsourcing)
Zatímco v malých podnicích je provoz řízen tak, že když se vyskytne nějaký problém, uživatelé si zajdou do servrovny, kde se sedí nějaký technik, u velkých společností to takhle jednoduše nejde. K řízení provozu IS/ICT se využívají především dohledové systémy, jež mají celou škálu metrik, podle kterých měří výkonnost systému. Primárně se zkoumá, dostupnost, průchodnost, výpadkovost, spolehlivost apod. Tyto metriky bývají zakomponovány do SLA (Service Level Agreement), zvláště je-li informatika outsourcována. Tím se dostáváme k všudypřítomných metodikám ITIL, COBIT a CBS, které mimo spoustu jiných věcí upravují i standardizaci měření v oblasti výkonnosti IS/ICT a auditu IS/ICT.
4.1
Charakteristika dohledových systémů
Dohledové systémy, nebo také EMS – Enterprise Management Systems jsou softwarová řešení, která vytvářejí jednotný rámec pro administraci a kontrolu nad síťovou infrastrukturou a koncovými zařízeními. EMS systémy představují automatizovanou podporu ITIL metodologie, protože naplňují aktivity spojené s částí ITIL, tzv. • Správa služeb • Podpora služeb • Řízení aplikací.
4.1.1
Funkčnost dohledových/EMS systémů
Desktop management Network management Řízení bezpečnosti Řízení paměti IT Service level management Řízení aplikací Řízení kapacit Řízení kapacit představuje jednotlivé oblasti, kterými se zabývá provoz IS/ICT: • • • • •
4.1.2
Řízení výkonnosti (Performance Management) Řízení provozního zatížení (Workload Management) Řízení zdrojů (Ressource Management) Řízení požadavků ( Demand Management) Odhad velikosti aplikací (Application Sizing)
Vstupy a výstupy ze systémů
Základním předpokladem pro takový systém je systematický sběr relevantních informací a událostí souvisejících s provozem IS. Pro účely dohledu se sbírají data dvou typů: • Performace Management - průběžná (spojitá data –– jsou zaměřena na sledování a vyhodnocování zátěže systému. Výstup Performace Managementu se používají pro: o Upozornění při neobvyklých situacích, např. vysoká chybovost
o o o
Rekonfiguraci systémů s cílem lepšího využití stávajících zařízení (investice) Plánování off-line úloh mimo dobu zátěže systému Plánování kapacit v závislosti na vyhodnocení historických trendů vývoj zatížení
• Event Management – řízení událostí – plní funkci pomyslného supervizora, který podle přesně definovaných pravidel označuje výskyt určité události, která je z provozního hlediska stavem, o kterém je nutné informovat kompetentní a zodpovědné složky nebo je stavem, který iniciuje aktivaci některých činností.
4.1.3
Architektura EMS /dohledových systémů
zahrnuje několik vrstev: 1. Infrastruktura 2. Systémy (operační) 3. Aplikace a služby 4. Pracovní stanice
4.1.4
Reprezentanti
Produkty EMS je možné rozdělit do tří kategorií podle funkcionality, kterou nabízejí: 1. Tzv. end-to-end produkty, u kterých je možné propojovat různé produkty od různých dodavatelů. Příklady: Tivoli od IBM, Unicenter od Computer Associates, Open View od HP, Patrol od BMC, Spektrum, MQ Series, E3MS od Bull 2. Méně pružné v možnostech provázání s ostatními produkty Příklady: Compuware, Ganymede, Microsoft, Sterling Software, Systar 3. specializace na jednu oblast řízení, kterou lze integrovat s dalšími produkty (většími typu ad 1) Příklady: Omniguard pro řízení bezpečnosti, Backup Exec pro řízení záloh
4.2
Formy zajištění provozu IS/ICT (interní provoz, outsourcing)
Interní provoz o Výhody: znalost prostředí a systémů, možná rychlá reakce, sledování dlouhodobého vývoje, rychlá úprava úrovně sledování o Nevýhody: cena (není ekonomické mít lidi alokované pouze na sledování dashboardu, v případě člověka alok. I na toto krom jiné práce je v případě události pomalá reakce)´ Outsourcing: řekl bych opak interního provozu
Praktická úloha Vzhledem k tomu, že skutečně jsem odpovědný za provoz IS/ICT v malé organizaci, mohu popsat, jak to dělám já. 1. Dělám klasické úkony správce sítě (nainstaloval jsem firewall a AVG), přeinstalovávám počítače, když už to dál nejde. Dělám podporu uživatelům. HelpDesk funguje tak, že v akutních případech mi mohou uživatelé zavolat a přijedu. Jinak chodím do práce kdy se mi zlíbí a cestou po chodbě sbírám nahromaděné dotazy, připomínky, požadavky a ty pak operativně řeším. 2. V práci začal fungovat nový člověk, jež je schopen většinu primitivních problémů vyřešit sám. Tím filtruje mou komunikaci se zaměstnanci. Všechny požadavky chodí přes něj (on je takový HelpDesk), teprve když si neví rady, zavolá mi. Toto zajištění je napůl interní a napůl externí. Není to outsourcing. Malé firmě se nikdy nemůže vyplatit pořizovat drahé dohledové systémy či outsourcovat provoz IS/ICT vůbec. Jestli ano, tak sním svůj klobouk. Toto je nejlepší forma organizačního zajištění a docela funguje.
1.23 Řízení informatických služeb
1.23 Řízení informatických služeb
Význam informatických služeb, model SPSPR, typy služeb, význam a struktura SLA.
1.1.
ICT služba ICT služba jsou koherentní aktivity a/nebo informace dodávané poskytovatelem ICT služby příjemci služby. ICT služba je vytvářena ICT procesy, které při svém průběhu konzumují ICT zdroje (hw, sw, data, lidé). Služba se realizuje na základě dohodnutých obchodních a technických podmínek. Podnikové procesy ICT služby ICT procesy ICT zdroje ICT služby jsou v modelu chápány jako rozhraní mezi byznysem a informatikou, přes které poskytovatel ICT služeb podporuje jednotlivé byznys procesy podniku či jiné dílčí aktivity. Poskytovatel služby musí zajistit ICT procesy, které službu dodají, a ICT zdroje, které jsou pro průběh ICT procesů nezbytné.
1.2.
Význam ICT služeb Význam ICT služeb je dán zejména tím, že jsou nástrojem komunikace mezi byznysem a podnikovou informatikou, nástrojem pro řízení vztahů s externími partnery podnikové informatiky a produktem, který – na rozdíl od samotných technologií – umožňuje podniku získat konkurenční výhodu. Vhodné propojení ICT služeb s modelem podnikání, s podnikovými procesy a s podnikovou kulturou. Má-li toto propojení unikátní charakter, které vede k tomu, že podnikový proces produkuje produkt/službu s vyšší užitnou hodnotou a/nebo s nižší cenou, pak přináší podniku konkurenční výhodu.
1.3.
Model SPSPR Model řeší vztah mezi řízením podnikových procesů a řízením podnikové informatiky. Definuje základní zodpovědnosti byznys a ICT manažerů při řízení vztahu byznys – podniková informatika. Základem modelu je řízení firmy na pěti vzájemně provázaných vrstvách (S – Strategy, P – Business Processes, S – ICT Services, P – ICT Processes, R – ICT Resources). Cílem rozdělení řídících aktivit do pěti vrstev je: • Taková strukturace podnikových činností a zodpovědností, která optimálně odpovídá současným požadavkům na flexibilní a efektivní podnikové řízení • Jasné určení zodpovědností různých typů manažerů/specialistů v podniku - 1/4 -
1.23 Řízení informatických služeb
• Zprůhlednění způsobu dekompozice podnikových cílů až na úroveň řízení provozu ICT • Vytvoření schématu, ze kterého je možné odvodit vhodné metriky úspěšnosti jednotlivých typů procesů a za ně odpovědných manažerů – viz. místa označená budíkem.
Obrázek 1 - Model SPSPR (nový Voříšek str. 154)
1.4.
Typy služeb a) Podle předmětu ICT služby byznysu (koncovým uživatelům) – bezprostředně podporují podnikové procesy a koncové uživatele. • Informační – Poskytovatel dodává příjemci požadovanou informaci (kurzy na burze, počasí atd.). Informace je v požadované struktuře, formátu, čase. Poskytovatel odpovídá za správnost a aktuálnost dodaných informací. • Aplikační – Předmětem je funkcionalita byznys aplikace (účto, CRM atd.). Poskytovatel poskytuje aplikace na vhodné ICT infrastruktuře a příjemce užívá funkcionalitu. Poskytovatel odpovídá za správnost transformace dat, majitel odpovídá za správnost vstupních dat. • Infrastrukturní – Předmětem je vybudování a provoz ICT infrastruktury (servery, pc, lan, wan, os, db atd.) potřebné pro bezchybný chod aplikací. • Podpůrné služby – Jsou služby vhodné/potřebné pro zajištění služeb informačních, aplikačních a infrastrukturních. Jedná se zejména o školení; implementaci, customizaci a integraci aplikací, služby help desku, služby poradců atd.
- 2/4 -
1.23 Řízení informatických služeb
ICT služby rozvoje IS/ICT – slouží k rozvoji IS/ICT, nejsou bezprostředně konzumovány byznysem. • Vývoj sw (aplikace) • Implementace aplikace • Integrace IS • Rozvoj tech. infrastruktury • Poradenství atd. b) Podle způsobu spotřeby • Služby s jednorázovou konzultace..)
spotřebou
–
spotřebovány
jako
celek
(vyškolení,
• Služby s kontinuální spotřebou (internetové připojení..) • Služby s diskrétní spotřebou (údržba infrastruktury) c) Podle typu příjemce • Služba 2C • Služba 2B • Služba 2A • Služba 2ABC d) Podle poskytovatele • Interní ICT útvar • Externí poskytovatel e) Podle potřebných zdrojů a znalosti poskytovatele • Instalace a dimenzovaní ICT infrastruktury • Vývoj a instalace, customizace a integrace sw • Provoz a s správa hw a sw • Zpracování, publikování a poskytování dat • Poradenství v oblasti ICT
1.5.
SLA Obchodní a technické podmínky dodávky služby jsou součástí smlouvy o poskytované službě (SLA – Service level agreement) a obvykle upřesňují tyto charakteristiky: • Komu je služba poskytována • Kde je služba poskytována • Kdy je služba poskytována • Kým je služba poskytována • Co je předmětem služby (funkcionalita CRM..) • Jak je služba poskytována (online, web..) • Jaký je objem poskytované služby (počet uživatelů, objem dat..) • Jaké jsou kvalitativní charakteristiky (dostupnost, doba odezvy, spolehlivost..) • Jaká je cena (bonusy, sankce..)
- 3/4 -
1.23 Řízení informatických služeb
• Jakými znalostmi a technologiemi musí disponovat příjemce služby, aby mohl službu konzumovat • Mechanismy kontinuity v případě havárie • Bezpečnostní pravidla a mechanismy • Forma, obsah, cyklus reportovaní o průběhu dodávky služby • Pravidla pro realizace změn služby Úloha - předpoklady: Vyberte si podnik a jeho podnikový proces. Zadání:
Definujte SLA aplikační služby určené na podporu podnikového procesu.
E-shop (50 zaměstnanců) – proces správa účetních operací Aplikační služba určená pro podporu – Účetnictví SLA: • Komu je služba poskytována: E-shop • Kde je služba poskytována: E-shop • Kdy je služba poskytována: 24x7 • Kým je služba poskytována: • Co je předmětem služby: funkcionalita aplikace účetnictví • Jak je služba poskytována: webové rozhraní • Jaký je objem poskytované služby: 3 uživatelé • Jaké jsou kvalitativní charakteristiky: dostupnost 24x7, doba odezvy < 1s, spolehlivost 95 % • Jaká je cena • Jakými znalostmi a technologiemi musí disponovat příjemce služby, aby mohl službu konzumovat: vysokorychlostní připojení do Internetu, koncová stanice • Mechanismy kontinuity v případě havárie: převedení služby na záložní server • Bezpečnostní pravidla a mechanismy: pravidelné zálohování, logování…
- 4/4 -
1.20 Metodiky a modely řízení informatiky
1.20 Metodiky a modely řízení informatiky
Charakterizujte podrobněji ITIL, COBIT a MMDIS (základní zaměření, principy, struktura, skupiny procesů).
1.1.
ITIL ITIL je zkratka vážící se k pojmu Information Technology Infrastructure Library. Definic, které by vymezovaly pojem ITIL je mnoho, jmenujme alespoň některé: • ITIL je sada konceptů a postupů řízení IT infrastruktury, vývoje a provozu. • ITIL je souhrn nejlepších praktik pro provozování IT, poskytování IT služeb a podporu obchodních činností pomocí IT. • Zdokumentovaná sada procesů, které jsou navrženy tak, aby definovaly, jak mohou být IT funkce spravovány. Obsahuje řadu tvrzení, která definují procedury, kontroly a zdroje, které by měly být použity na různé procesy, které jsou spjaté s IT. • ITIL je veřejně dostupný rámec, který popisuje nejlepší praktiky ve správě služeb IT. Poskytuje rámec pro zvládnutí IT v organizaci, pojednává komplexně o službách a zaměřuje se na neustálé měření a zlepšování kvality dodávaných služeb IT, a to jak z pohledu businessu, tak z pohledu zákazníka.
1.2.
Charakteristické rysy ITILu ITIL má 5 charakteristických rysů, které by bylo vhodné na tomto místě uvést. Jde o: • Procesní řízení ITIL přináší procesně orientovaný přístup k řízení IT služeb (na rozdíl od tradičního funkčně-liniového řízení). Proces je logický sled činností transformujících nějaký vstup na nějaký výstup, přičemž plnění jednotlivých činností v procesu je zajišťováno rolemi s jasně definovanými odpovědnostmi. Celý proces je řízen, monitorován, měřen, vyhodnocován a neustále vylepšován, což je odpovědností vlastníka procesu. • Zákaznicky orientovaný přístup Všechny procesy se navrhují s ohledem na potřeby zákazníka, tzn. každá aktivita v každém procesu musí přinášet nějakou přidanou hodnotu pro zákazníka - pokud ne, pak je taková činnost nadbytečná. • Jednoznačná terminologie Jednoznačná terminologie je někdy málo doceňovanou charakteristikou ITIL. Používáním jednotné terminologie definované v ITILu se nám nemůže stát, že by někdo používal stejný termín v jiném významu, než od něj ostatní očekávají. • Nezávislost na platformě Rámec procesů podle ITIL je nezávislý na jakékoliv platformě. Dokonce je možné ITIL použít i pro navržení procesů (úplně mimo oblast ICT) v jakékoliv firmě, která podniká ve službách. • Public Domain
- 1/10 -
1.20 Metodiky a modely řízení informatiky
Knihovna je volně dostupná, což znamená, že každý si může knihy ITIL koupit a procesy ITSM podle ITIL ve svém podniku implementovat, aniž by musel platit jakékoliv další licenční poplatky. Tato skutečnost mj. přispěla k rychlému celosvětovému rozšíření ITIL.
1.3.
Trocha historie Začátkem 80. let trápily britskou předsedkyni vlády Margaret Thatcher problémy s kvalitou služeb a velikostí rozpočtu (kolem 8 bilionů liber a stále rostl), který byl utrácen v zemi na informační technologie. Vykonávala politický nátlak na CCTA (Central Computer & Telephone Agency - britská vládní agentura, která měla na starosti rozpočet na IT), aby snížila rozpočet. Ta zahájila studii, jejímž cílem bylo nashromáždění nejlepších praktik v IT a jejich kombinace tak, aby tvořily návod pro snížení rozpočtu a zvýšení kvality poskytovaných IT služeb. Protože tato studie pokrývala velmi rozsáhlou, rostoucí a extrémně dynamickou oblast, trvala její kompletace poměrně dlouhou dobu. Přirozené je, že studie procházela mnoha iteracemi, první z nich, nazvaná GITIM (Government Information Technology Infrastructure Management) se od současného ITILu sice velmi lišila, konceptuálně byla však velice podobná, zaměřovala se zejména na service support a service delivery.
1.3.1.
ITIL-1 Studie byla nakonec dokončena r. 1991 a nazvána ITIL. CCTA publikovala zprávu r. 1993. Šlo o kompletní přehled toho, JAK vše funguje, soustředil se pouze na strukturu IT. Brzy byla přijata velkými organizacemi a vládami v Evropě. ITIL byl rozdělen do dvou částí service support a service delivery a celkem obsahoval 42 knih.
1.3.2.
ITIL-2 Kvůli své délce a obsahu byla první verze ITIL shledávána příliš byrokratickou, vyžadovala příliš papírování a záznamů. Druhá verze nazvaná ITIL -2 (první hlavní revize publikace dokumentu ITIL) se místo popisu struktury IT zaměřila na to, JAK dělat věci ohledně IT správně, zaměřila se na funkci IT. V roce 2000 se stala CCTA součástí OGC (Office of Government Commerce). Zároveň vzniklo také ITSMF (IT Service Management Forum) sdružující subjekty se zájmem o obsah ITILu. Zatímco OGC bylo nadále vlastníkem a vydavatelem ITILu, ITSMF bylo zodpovědné za obsah knih. Zároveň v roce 2000 oznámila firma Microsoft, že používá ITIL jako základ pro vývoj svého proprietárního MOF (Microsoft Operating Framework), což bylo dalším impulsem k tomu, aby byl ITIL brán i ostatními organizacemi jako standard, kterému by bylo vhodné věnovat pozornost a řídit se jím. ITIL se stal oficiálním standardem v Británii vznikem a publikováním standardu BS-15000 (British Standard number 15,000). V roce 2001 byl publikován ITIL v. 2, v němž došlo k redukci ze 42 svazků na pouhých 8. Následně na to byl v r. 2002 revidován standard BS-15000 tak, aby odrážel změny v ITIL v. 2, v r. 2005 byl pak nahrazen standardem ISO-20000 (více podrobností viz kapitola věnovaná standardu).
1.3.3.
ITIL-3 V roce 2005 začala ITSMF revizi stávající druhé verze ITILu, která vyvrcholila 31. 5. 2007 vydáním nové verze s názvem ITIL-3 (druhá revize ITILu). Počet svazků ještě zredukovala (z osmi na pět) a změnila pohled na problematiku, popisujíc životní cyklus služby.
- 2/10 -
1.20 Metodiky a modely řízení informatiky
ITIL knihovna verze 3 obsahuje následující komponenty: 1. The ITIL Core - soubor „best practices“ použitelný na všechny typy organizací poskytujících služby businessu 2. The ITIL Complementary Guidance – soubor doplňkových publikací s návody pro specifická průmyslová odvětví, různé typy organizací, modely řízení a technologických architektur. The ITIL Core obsahuje 5základních knih: •
Service Strategy (Strategie služeb)
•
Service Design (Návrh služeb)
•
Service Transition (Přechod služeb)
•
Service Operation (Provoz služeb)
•
Continual Service Improvement (Neustálé zlepšování služeb) Každá z těchto knih reprezentuje jednu z etap v životním cyklu IT služby.
1.4.
COBIT
CobiT (Control Objectives for Information and related Technology) je mezinárodně uznávanou metodikou, která podporuje systematický přístup k řízení informatiky. Metodika se opírá soubor všeobecně akceptovaných nejlepších praktik tak, aby využití informací a nasazení informačních a komunikačních technologií přispívalo k dlouhodobému rozvoji organizace, prohlubovalo její strategické cíle a snižovalo rizika související s použití ICT. Pro správné pochopení metodiky CobiT je potřeba nejprve objasnit dva důležité pojmy z oblasti řízení informačních a komunikačních technologií (ICT), které jsou v poslední době stále více rozlišovány. ICT governance je odpovědností nejvyššího vedení, které svým příkladem, organizačním uspořádáním a vnitřními procesy zajišťuje, že ICT přispívá a prohlubuje strategii a dlouhodobé cíle organizace. ICT management se soustředí na efektivní poskytování služeb a produktů ICT a na účinné řízení rozvoje a provozu ICT. V kontextu těchto definic je zřejmé, že ICT governance má širší pojetí a jeho snahou je definovat strategické cíle ICT v souladu s potřebami a zájmy celé organizace. Naproti tomu snahou ICT managementu je efektivně a účinně realizovat stanovené cíle, a proto se orientuje na taktické a operativní řízení. ICT management je realizován zejména v rámci útvarů ICT. Pro pochopení metodiky CobiT je rozlišení těchto pojmů velmi důležité. Metodika CobiT totiž není určena jako nástroj pro realizaci ICT managementu, za což je často ale mylně považována. Určení metodiky CobiT Metodika CobiT je charakterizována jako procesně orientovaný nástroj pro budování a rozvoj ICT governance. Metodika vychází z nejlepší vžité praxe a její první verze pochází z roku 1996. V roce 1998 byla vydána druhá verze a byl v ní zapracován širší okruh zdrojů a východisek (celkem 41 standardů a metodik). Platná třetí verze byla zveřejněna v roce 2000 IT Governance Institutem, který ke konci roku 2005 plánuje další aktualizaci.
- 3/10 -
1.20 Metodiky a modely řízení informatiky
ICT Governance je záležitost plošného vnímání možností využívání ICT a jejich integrace do celkového fungování organizace. Z tohoto pohledu je metodika CobiT určena především pro následující skupiny pracovníků: Management - potřebuje rozhodovat o výdajích do rozvoje a provozu ICT a posoudit, zda jsou tyto výdaje správně a efektivně využívány. V tomto směru je CobiT nástrojem pro definování jednoznačného rámce řízení ICT a usnadňuje orientaci managementu v nečitelném prostředí ICT. Uživatelé - mají stále vyšší potřebu seznámit se s fungování ICT a nalézt přiměřené záruky za správné a bezpečné fungování služeb ICT, které využívají či garantují. Auditoři - při své práci neustále naráží na využívání ICT. V tomto směru CobiT poskytuje základní rámec pro to, jakým způsobem hodnotit správnost a hodnost nasazení ICT vzhledem k posuzované části organizace. Již výčet uživatelů metodiky CobiT naznačuje, že metodika není přímo určena pro ICT management (vnitřní řízení ICT). CobiT je nástrojem, který dovoluje prezentovat činnosti ICT vůči okolnímu světu, jenž nedisponuje detailními znalostmi o ICT. Cílem je vytvořit rámec pro řídící a kontrolní systém fungující nad prostředím ICT, který je nastaven ve schodě s ostatními řídícími a kontrolními systémy organizace (např. pro finanční oblast, vnitřní řízení apod.). Obecný model řízení Obecný model řízení se opírá o prosazování cílů pomocí přímého řízení činností, kterých se účastní dostupné zdroje. U těchto činnostech musí být vytvořena intenzivní zpětná vazba, pomocí které je možné objektivně posoudit, zda provedení činností skutečně přispělo k naplnění daných cílů.
V některých systémech řízení je podobný princip označován jako model PDCA ze zkratek anglických slov Plan - Plánuj, Do - dělej, Check - kontroluj a Act - jednej. Na tomto modelu je založena nejen metodika CobiT ale i řada dnes velmi známých systémů řízení např. systém managementu jakosti podle ISO 9001, systém managementu služeb ICT podle ISO/IEC 20000 či systém managementu bezpečnosti informací podle ISO/IEC 27001:2005 (BS 7799-2). Vnitřní uspořádání CobiT Výše uvedené skutečnosti se odráží v základu metodiky CobiT, který se soustředí na vyjádření vzájemných vztahů tří klíčových prvků řízení. Za základní stavební prvky CobiT jsou tudíž považovány: • Informační kritéria - vyjadřují požadavky, které jsou na ICT kladeny a podle kterých by měla být posuzována úspěšnost naplnění stanovených cílů. Informační kritéria by měla odrážet všeobecné zájmy organizace. • Zdroje ICT - jsou dostupné prostředky, které je možné při řízení ICT využít. • Procesy ICT - jsou skupiny činnosti, které jsou při řízení ICT vykovávány. Vzájemné vztahy tvoří trojrozměrný prostor nazývaný krychle CobiT, který je znázorněn na následujícím obrázku.
- 4/10 -
1.20 Metodiky a modely řízení informatiky
Procesy ICT rozděluje metodika CobiT do 4 domén, které odráží hlavní oblasti řízení ICT: • Plánování & Organizace (PO) - doména se soustředí na definování informační strategie a hledání vhodných taktik pro dosažení nejvyšší míry přispění ICT k naplňování obecných cílů organizace. • Akvizice & Implementace (AI) - aby bylo možné realizovat strategie ICT je důležité identifikovat, vyvinout nebo nakoupit a implementovat zdroje ICT, které jsou důsledně provázány s příslušnými procesy organizace. • Dodání & Podpora (DS) - doména se soustředí na zajištění kvalitního dodání požadovaných služeb ICT, což zahrnuje činnosti od provozu přes bezpečnost až po přípravu uživatelů. • Monitorování (M) - všechny procesy ICT musí být pravidelně sledovány a hodnoceny, zda kvalita jejich provádění odpovídá stanoveným požadavkům a potřebám. Tato doména je zaměřena na získávání objektivního přehledu o prováděných činnostech ICT. Tři základní stavební kameny CobiT: informační kritéria, zdroje ICT a procesy ICT a jejich vzájemné vztahy jsou zachyceny v následující tabulce, která je jádrem celé metodiky CobiT. Pro každý proces ICT je v tabulce znázorněna míra vlivu na naplnění informačních kritérií (s rozlišením primárního a sekundární účinku) a zdroje ICT, se kterými proces souvisí.
- 5/10 -
1.20 Metodiky a modely řízení informatiky
1.5.
MMDIS cíl: vývoj a údržba komplexního a integrovaného IS/IT, který optimálně podporuje dosažení podnikových cílů nepředepisuje detailně jednotlivé kroky vývoje IS/IT- vychází z toho, že každý projekt je natolik specifický, že by to mohlo vést k hledání analogií i tam, kde nejsou metodika klade důraz na to o jak strukturovat práci o co by se mělo řešit v jednotlivých fázích vývoje IS/IT o čem v jednotlivých fázích vývoje IS/IT přemýšlet Mnohost pohledů na IS/IT jak při řešení, tak při provozu IS/IT = základní předpoklad efektivnosti IS/IT. Multidimenzionalita = řešení IS/IT souběžně ze všech pohledů, které ovlivňují efektivitu IS/IT.
2 základní skupiny dimenzí vývoje IS/IT 1. úrovně integrace, použitá úroveň abstrakce a časová dimenze 2. ty úrovně, které se aplikují v každé fázi vývoje IS/IT = obsahové dimenze (informační / datová) (procesní / funkční) (ekonomická / finanční) (organizační / legislativní) (pracovní / sociální / etická) (softwarová) (hardwarová) - 6/10 -
1.20 Metodiky a modely řízení informatiky
(metodická) (manažerská)
Cíl multidimenzionality
neopomenout žádná faktor, který ovlivňuje úspěšnost tvorby, zavedení, provozování a dalšího vývoje IS/IT neopomenout vzájemné ovlivňování (vazby) faktorů
Dimenze řešení IS = druhy pohledů na IS Při řešení je nutno vycházet z uživatelských pohledů na IS/IT a ty postupně transformovat v řešitelské Uživatelské pohledy
pohled vrcholového vedení podniku – dlouhodobý a strategický charakter o na podporu kterých podnikových procesů se zaměřit o požadovaný čas nasazení dalších verzí IS/IT o jaké finanční (i pracovní) zdroje může podnik na řešení uvolnit procesní pohled koncových uživatelů o jaké procesy probíhají na sledované úrovni řízení podniku o která data sbírat a uchovávat o kdy data sbírat o jaké transformace dat provádět pohled koncového uživatele na funkce IS při komunikaci s počítačem o odvození návrhu průběhu komunikace uživatele s IS
Řešitelské pohledy na IS/IT a. dimenze čas, úroveň abstrakce, úroveň integrace Úlohou řešitelských pohledů je transformovat uživatelské pohledy (požadavky) nejdříve do logického návrhu a ten pak do fyzického. Z této skupiny dimenzí (čas, úroveň abstrakce, úroveň integrace) jsou v MDIS odvozeny jednotlivé fáze vývoje IS/IT. Každá fáze má cíle, vstupy, výstupy a postup řešení. Cíle rozdělení prací do fází rozdělit řešení do projektů – usnadní plánování a řízení prací vývoj po částech, které jsou samostatně co nejrychleji předatelné do provozu (zavedením projektu do provozu vzniká nová verze provozovaného IS/IT) jasně oddělit jednotlivé úrovně abstrakce při řešení IS/IT – sjednocování náročnosti zajistit adekvátní podporu globálních cílů podniku Fáze:
globální strategie = model budoucího stavu celého podniku informační strategie = model budoucího stavu IS/IT (technologická integrace)
Obě fáze zajišťují integraci: - 7/10 -
1.20 Metodiky a modely řízení informatiky
vizí a idejí podniku s okolím interních podnikových procesů
Životní cyklus projektu Projekty definované v informační strategii se realizují v 6 fázích: • úvodní studie = studie proveditelnosti, variantní návrh koncepce • globální analýza a návrh = vymezení hlavních funkcí a dat na konceptuální úrovni • detailní analýza a návrh – transformuje konceptuální do technologické (např. relační model) • implementace – technologická do implementační (programování programů) • zavádění – instalace, školení • provoz a údržba
b. Obsahové a metodicko-organizační dimenze obsahové •
data / informace
•
funkce / procesy
•
organizační a legislativní aspekty
•
SW
•
HW
•
ekonomické a finanční aspekty
metodicko-organizační •
metody – určuje metody a nástroje pro jednotlivé fáze
•
dokumenty – jaké dokumenty vznikají v průběhu, jejich obsah
•
řízení prací dané fáze – postup při řešení fází vývoje IS
data / informace potřebné typy informací, obsah a struktura DZ a její fyzické uložení •
signální (došlá faktura)
•
strukturální (popisuje strukturu systému)
•
genetické (uložená ve vlastní paměti systému – např. paměti lidí)
funkce / procesy funkční pohled na IS/IT je statický – popisuje hierarchický rozpad funkcí IS •
výstupní data (hrubá mzda, daň ze mzdy,…)
•
vstupní data (odpracovaný počet hodin,…)
•
řídící data (zákon o dani z příjmu,…)
- 8/10 -
1.20 Metodiky a modely řízení informatiky
procesní – zajímá nás dynamika chování podniku při výskytu různých událostí •
informační (příchod faktury)
•
časová (spojena s určitým časem)
•
mimořádná (výpadek proudu)
organizační a legislativní •
musí respektovat platnou legislativu dané země a podnikové směrnice a normy
•
popis organizační struktury platné v době provozu jednotlivých verzí IS/IT o
primární – obvykle stromová
o
sekundární – při řešení specifických problémů (může jich být více) – definuje pravidla pro vývoj, údržbu a provoz IS, zodpovědnosti a pravomoci, postupy prevence proti mimořádným stavům
pracovní, sociální a etické aspekty •
určit potřebnou strukturu pracovníků podniku (počet, kvalifikace, věk, pohlaví)
•
analyzovat sociální a etické dopady přechodu na novou verzi IS
•
jak do nového pracovníka přenést genetickou info
•
jak využít znalosti nového pracovníka
•
jak motivovat spolupráci
SW •
určení architektury programového systému – typy, parametry, vazby komponent ZSW a ASW
•
nákup či vývoj SW komponent?
HW •
určení HW architektury IS – typy, parametry, počty počítačů, periferních zařízení, sítí
ekonomické/finanční •
finanční náklady tvorby a provozu IS + přínosy z použití IS
•
kdy a z jakých zdrojů budou náklady na IS kryty
Vztahy mezi obsahovými dimenzemi • • • • • • • •
funkce ↔ data řídící data – zákony rozsah dat – diskové kapacity programové moduly – počítače, sítě řídící odpovědnost funkčního místa funkční místa – počet pracovníků řídící a výkonné odpovědnosti – kvalifikace propojení HW, SW a datové dimenze ⇒
- 9/10 -
1.20 Metodiky a modely řízení informatiky
o o
technologická architektura – definuje způsob zpracování aplikací IS (dávkově,…) vnitřní stavba aplikací (KIS,…) a uživatelské rozhraní
- 10/10 -