Externí systémy, které jsou využívány různými uživateli (v okolí systému) - ať již off-line nebo on-line -by měly mít tyto vlastnosti:
• Jednoduchost: sám systém nemusí být jednoduchý, ale musí se tak jevit uživateli. Proto má mít následující charakteristiky:
• Srozumitelnost - pro uživatele musí být srozumitelné: obsluha systému, dialogy, též vyhledání pomoci, nápovědy, rady (HELP, Hot-line,...):
pokud by nebyla obsluha systému srozumitelná, vyžadoval by uživatel často pomoc ze strany provozovatele systému; jelikož však uživatel (klient) je vzdálen od centra, kontakt s provozovatelem je obtížný, časově náročný a většinou i nákladný; rady a pomoc musí tedy poskytovat sám systém (a pokud není srozumitelný, jsme v bludném kruhu).
• obsluha má být:
o co nejjednodušší,
o „průhledná" - úkony přirozené, jasné, zřetelné, logické, zapamatovatelné,
• systém s vymezeným přístupem může počítat s určitým modelem uživatele a musí se přiblížit mentalitě tohoto modelu
• systém s obecným přístupem má vyjít vstříc průměrné (lépe však mírně podprůměrné) mentalitě nejrůznějších uživatelů, počítat s mírně podprůměrným IQ a s mírně podprůměrným způsobem uvažování.
• Odolnost systému i v něm uložených informací vůči:
o chybám,
o poškození, zničení, ztrátě z technických příčin,
o neznalosti (uživatele),
o zlomyslnosti,
o zločinnosti.
• Stálost systému znamená neměnit zavedené doklady, pracovní postupy, číselníky, formu a formát výstupních informací atd. Je velmi obtížné sladit stálost systému s jeho dynamickým vývojem, avšak změny vždy zvyšují pracnost a především chybovost
• Respektování zákonů a zvyklostí dává uživateli garance věcné i morální správnosti a přípustností funkcí a informací. Systém má respektovat:
o právní normy (zákony, předpisy, vyhlášky,...)
o etické normy
Jak jsou podporovány moderním IT – viz. SR13
Externí informační systém
• není určen pro některý podnik, ale slouží různým právnickým nebo i přímo fyzickým osobám jako jeden ze zdrojů externích informací.
Externí informační systémy jsou iniciovány, řešeny a řízeny podle některého z následujících principů:
a) obchod s informacemi,
b) povinnost předávaní informací (např. povinnost stáru seznamovat občany s právními dokumenty) nebo nutnost práce s externími informacemi (např. systémy koordinace kmitočtového spektra v radiokomunikacích),
c) potřebnost, účelnost a užitečnost externích zdrojů informací (např. Internet, BBS, bibliografické systémy) - zde se ovšem nevylučuje použít také principu obchodování.
Externí informační systémy mohou být (podle provedení):
• on-line systémy plošně rozlehlé, s velkým počtem uživatelů, pracující v režimu terminál - mainframe
• client - server (těmto systémům se také říká rozsáhlé), => lokální, regionální nebo jinak plošně omezené on-line systémy menšího rozsahu, pracující na bázi nejrůznějších technologií
• systémy na médiích (např. CD ROM), distribuované nebo prodávané, => systémy, poskytující ze svých bází tiskoviny (off-line).
Obecně jsou pro externí systémy možná jakákoliv řešení, umožňující šíření informací pro daný účel vhodným a efektivním způsobem. Většina externích systémů se také vyznačuje rozsáhlými bázemi dat
Externí systémy mohou poskytovat služby:
• buď široké veřejnosti (systémy s obecným přístupem),
• nebo vymezené množině uživatelů (systémy s vymezeným přístupem) - množinu uživatelů stanoví provozovatel systému (obecně - vymezením okruhu zákazníků, konkrétně - určením konkrétních uživatelů).
Externí informační systémy jsou iniciovány, řešeny a řízeny podle některého z následujících principů:
a) obchod s informacemi,
b) povinnost předávaní informací (např. povinnost stáru seznamovat občany s právními dokumenty) nebo nutnost práce s externími informacemi (např. systémy koordinace kmitočtového spektra v radiokomunikacích),
c) potřebnost, účelnost a užitečnost externích zdrojů informací (např. Internet, BBS, bibliografické systémy) - zde se ovšem nevylučuje použít také principu obchodování.
Externí informační systémy mohou být (podle provedení):
• on-line systémy plošně rozlehlé, s velkým počtem uživatelů, pracující v režimu terminál - mainframe
• client - server (těmto systémům se také říká rozsáhlé), => lokální, regionální nebo jinak plošně omezené on-line systémy menšího rozsahu, pracující na bázi nejrůznějších technologií
• systémy na médiích (např. CD ROM), distribuované nebo prodávané, => systémy, poskytující ze svých bází tiskoviny (off-line).
Obecně jsou pro externí systémy možná jakákoliv řešení, umožňující šíření informací pro daný účel vhodným a efektivním způsobem. Většina externích systémů se také vyznačuje rozsáhlými bázemi dat
Externí systémy mohou poskytovat služby:
• buď široké veřejnosti (systémy s obecným přístupem),
• nebo vymezené množině uživatelů (systémy s vymezeným přístupem) - množinu uživatelů stanoví provozovatel systému (obecně - vymezením okruhu zákazníků, konkrétně - určením konkrétních uživatelů).
Podle provozovatele rozlišujeme:
- systémy privátní, provozované soukromým subjektem,
- systémy veřejné, provozované státní správou nebo jinými veřejnými (společenskými) institucemi.
Externí systémy s obecným přístupem mohou být založeny na bezplatném nebo placeném poskytování služeb, uživatelem může být kdokoliv nebo jen taková osoba, firma či instituce, která má s provozovatelem uzavřenou smlouvu o využívání systému (smlouva je ovšem dostupná prakticky komukoliv). Může být použito i principu obchodování (např. prodej systémů na médiích - „přes pult", dodávka dle objednávky atd.).
Systémy s vymezeným přístupem jsou též založeny na bezplatném nebo placeném poskytování služeb, uživatelem je však pouze ten, koho provozovatel za uživatele přijme nebo určí (např. systémy pro plánování a koordinaci kmitočtového spektra jsou bezplatně přístupné pouze vybraným pracovištím státní správy a radiokomunikačních podniků). Může být použito i principu distribuce (např. mezinárodní kmitočtové byro IFRB poskytuje abonentům - národním administracím - základní informace o kmitočtech na CD).
Uživatel externích systémů je umístěn v okolí systému. Místo „uživatel" můžeme použít i označení klient nebo zákazník. Zatímco v podnikovém systému jsou uživatel i provozovatel součástí téže organizační jednotky (podniku, instituce), jsou podřízeni společnému vedení a jsou spolu tudíž ve spolupracovnickém vztahu, pak uživatel externího systému je vůči provozovateli v odběratelském vztahu (a není vůbec důležité, zda odebírá služby zdarma nebo za úplatu).
- systémy veřejné, provozované státní správou nebo jinými veřejnými (společenskými) institucemi.
Externí systémy s obecným přístupem mohou být založeny na bezplatném nebo placeném poskytování služeb, uživatelem může být kdokoliv nebo jen taková osoba, firma či instituce, která má s provozovatelem uzavřenou smlouvu o využívání systému (smlouva je ovšem dostupná prakticky komukoliv). Může být použito i principu obchodování (např. prodej systémů na médiích - „přes pult", dodávka dle objednávky atd.).
Systémy s vymezeným přístupem jsou též založeny na bezplatném nebo placeném poskytování služeb, uživatelem je však pouze ten, koho provozovatel za uživatele přijme nebo určí (např. systémy pro plánování a koordinaci kmitočtového spektra jsou bezplatně přístupné pouze vybraným pracovištím státní správy a radiokomunikačních podniků). Může být použito i principu distribuce (např. mezinárodní kmitočtové byro IFRB poskytuje abonentům - národním administracím - základní informace o kmitočtech na CD).
Uživatel externích systémů je umístěn v okolí systému. Místo „uživatel" můžeme použít i označení klient nebo zákazník. Zatímco v podnikovém systému jsou uživatel i provozovatel součástí téže organizační jednotky (podniku, instituce), jsou podřízeni společnému vedení a jsou spolu tudíž ve spolupracovnickém vztahu, pak uživatel externího systému je vůči provozovateli v odběratelském vztahu (a není vůbec důležité, zda odebírá služby zdarma nebo za úplatu).
Řízení při použití různých modelů
- pro různé úrovně řízení je nezbytné použít transformaci pro převod prvků modelů mezi sebou
- Účelné je, aby tato transformace byla dvoustupňová
- V prvním stupni se aktivity modelu řízení procesu sdruží do skupin, v druhé úrovni se pak vytvořené skupiny zobrazí do modelu řízení projektu.
Pro transformaci je nutné vzhledem ke zásadám řízení zachovat tato pravidla:
• transformace mezi aktivitami a úlohami musí být ve tvaru N:1 (případně 1:1). Žádná jiná možnost nepřichází v úvahu. Pro sdružování aktivit do úloh je podstatné o jakou aktivitu se jedná. Zda se jedná o aktivitu výkonnou - vývojovou nebo opravnou, nebo o aktivitu informační.
• zobrazení úloh do modelu řízení projektu musí být v poměru N:1 (případně 1:1). V tomto případě musí úroveň řízení projektu vzít v úvahu možnost paralelních úloh během tvorby projektu a jejich případnou vzájemnou provázanost.
Jenom takto aplikovaná transformace neporuší možnost efektivního nasazení metod a prostředků řízení na všech úrovních projektu.
- typová aktivita může být "přiřazena" i více fázím modelu řízení projektu. To je možné proto, že proces řízení (management) nepracuje s typovými aktivitami, ale s jejich konkrétní rozpracovanou podobou. A samotná existence typu není pro řízení tvorby projektu podstatná meritorní pro něj je "pouze" existence konkrétního rozpracování typové aktivity.
Kromě provedení vlastní transformace je důležité sledovat průběh celého procesu řízení na všech úrovních. To je možné prostřednictvím vazeb jak byly jednotlivé aktivity přiřazeny do skupin a která skupina byla přiřazena do které fáze modelu řízení projektu. Pro celý průběh řízení a kontroly postupu prací na projektu mají informace o příslušnosti ke skupinám a fázím prvořadý charakter a proto musí být dostupné vždy a na každé úrovni řízení
- Účelné je, aby tato transformace byla dvoustupňová
- V prvním stupni se aktivity modelu řízení procesu sdruží do skupin, v druhé úrovni se pak vytvořené skupiny zobrazí do modelu řízení projektu.
Pro transformaci je nutné vzhledem ke zásadám řízení zachovat tato pravidla:
• transformace mezi aktivitami a úlohami musí být ve tvaru N:1 (případně 1:1). Žádná jiná možnost nepřichází v úvahu. Pro sdružování aktivit do úloh je podstatné o jakou aktivitu se jedná. Zda se jedná o aktivitu výkonnou - vývojovou nebo opravnou, nebo o aktivitu informační.
• zobrazení úloh do modelu řízení projektu musí být v poměru N:1 (případně 1:1). V tomto případě musí úroveň řízení projektu vzít v úvahu možnost paralelních úloh během tvorby projektu a jejich případnou vzájemnou provázanost.
Jenom takto aplikovaná transformace neporuší možnost efektivního nasazení metod a prostředků řízení na všech úrovních projektu.
- typová aktivita může být "přiřazena" i více fázím modelu řízení projektu. To je možné proto, že proces řízení (management) nepracuje s typovými aktivitami, ale s jejich konkrétní rozpracovanou podobou. A samotná existence typu není pro řízení tvorby projektu podstatná meritorní pro něj je "pouze" existence konkrétního rozpracování typové aktivity.
Kromě provedení vlastní transformace je důležité sledovat průběh celého procesu řízení na všech úrovních. To je možné prostřednictvím vazeb jak byly jednotlivé aktivity přiřazeny do skupin a která skupina byla přiřazena do které fáze modelu řízení projektu. Pro celý průběh řízení a kontroly postupu prací na projektu mají informace o příslušnosti ke skupinám a fázím prvořadý charakter a proto musí být dostupné vždy a na každé úrovni řízení
Interní informační systém
= podnikový informační systém který produkuje informace, určené převážně subjektu, který tento systém zřídil
- externí informační systém produkuje informace pro jiné subjekty
- Manažerský informační systém (MIS) je informační systém, sloužící potřebám řízení a správy podniků
o Manažer využívá jednak služeb MIS, vybudovaných přímo pro jeho potřebu (nebo potřebu jeho podniku) tzn. interních a jednak služeb IS, vybudovaných pro uspokojení obecných informačních potřeb společností (takovéto IS jsou zdrojem externích informací, nazýváme je externí)
Podnik není uzavřeným systémem, ale má četné vazby k okolí.
Podnikový informační systém pomocí těchto vazeb nejen získává informace, ale řadu informací do okolí sám předává.
Okolí podnikového informačního systému tvoří
- jiné podnikové informační systémy,
- externí informační systémy,
- jiné systémy nebo prvky (např. systémy nadřízených orgánů a institucí, u některých podnikových systémů i občané).
Okolí externího informačního systému tvoří
- jiné externí informační systémy,
- uživatelé (systémy včetně podnikových, jednotlivci, občané).
- externí informační systém produkuje informace pro jiné subjekty
- Manažerský informační systém (MIS) je informační systém, sloužící potřebám řízení a správy podniků
o Manažer využívá jednak služeb MIS, vybudovaných přímo pro jeho potřebu (nebo potřebu jeho podniku) tzn. interních a jednak služeb IS, vybudovaných pro uspokojení obecných informačních potřeb společností (takovéto IS jsou zdrojem externích informací, nazýváme je externí)
Podnik není uzavřeným systémem, ale má četné vazby k okolí.
Podnikový informační systém pomocí těchto vazeb nejen získává informace, ale řadu informací do okolí sám předává.
Okolí podnikového informačního systému tvoří
- jiné podnikové informační systémy,
- externí informační systémy,
- jiné systémy nebo prvky (např. systémy nadřízených orgánů a institucí, u některých podnikových systémů i občané).
Okolí externího informačního systému tvoří
- jiné externí informační systémy,
- uživatelé (systémy včetně podnikových, jednotlivci, občané).
Síť úloh a jejich přiřazení k etapám
- druhý stupeň transformace
- ten zobrazí prvním stupněm vytvořené úlohy do modelu řízení projektu
model řízení projektu
- musí se skládat z různých na sebe navazujících etap
řízení
- aby bylo možné provádět řízení pak splnění každé z etap musí být možné jednoznačně kontrolovat
- Proto musí být zobrazení jedné úlohy do modelu řízení projektu takové, že jedna úloha se může zobrazit do nebo na jednu etapu.
- Zobrazení do odpovídá zobrazení N:1, zobrazení na zobrazení 1:1.
- To jsou jediné přípustné možnosti pro zobrazení úlohy směrem do modelu řízení projektu, přičemž možnost 1:1 je de facto jednostupňové zobrazení, které připadá v úvahu pouze pro velice jednoduché projekty nebo pro zobrazení workflow úloh a které je možné brát jako zvláštní případ transformace N:1.
Nechť pro druhý stupeň platí, že každá úloha se zobrazuje do modelu řízení projektu v poměru N:1.
- Jakmile je úspěšně dokončena transformace aktivit na úlohy, vzniká redukovaná síť úloh, ty je možné přiřadit jednotlivým etapám tvorby projektu ve smyslu chápání řízení projektu
- vzhledem k charakteru řízení projektu je ve finále nutná transformace síťových modelů do lineární časové osy, aby bylo možné stanovit přesné časové hranice jednotlivých etap, kontrolní body projektu, oponentní řízení apod. K tomuto účelu je nutné síť úloh promítnout do lineární časové osy.
Hlavním problémem, který je znázorněn na obr. q, je ta skutečnost, že úlohy C a D probíhají paralelně. Samotný paralelní průběh úloh není žádným nedostatkem modelu, ale problémy mohou vzniknout při vzájemné výměně výsledků mezi současně probíhajícími úlohami. Z pohledu řešení této vazby musíme rozlišit situaci, kdy:
• obě úlohy obsahují výkonné aktivity,
• alespoň jedna z úloh je úlohou informační.
Pokud obě úlohy obsahují výkonné aktivity, je nutné, aby první stupeň transformace aktivit na úlohy byl v síťovém modelu znovu přepracován, neboť z takto nadefinovaného modelu není zřejmé, v kterém okamžiku a jaké výsledky má úloha C předat úloze D.
Pokud je alespoň jedna z úloh C a D informační úlohou (v tomto případě se jedná o úlohu D), je výměna dat mezi úlohami naprosto korektní a není důvod, proč by se měla předchozí přiřazení měnit.
- ten zobrazí prvním stupněm vytvořené úlohy do modelu řízení projektu
model řízení projektu
- musí se skládat z různých na sebe navazujících etap
řízení
- aby bylo možné provádět řízení pak splnění každé z etap musí být možné jednoznačně kontrolovat
- Proto musí být zobrazení jedné úlohy do modelu řízení projektu takové, že jedna úloha se může zobrazit do nebo na jednu etapu.
- Zobrazení do odpovídá zobrazení N:1, zobrazení na zobrazení 1:1.
- To jsou jediné přípustné možnosti pro zobrazení úlohy směrem do modelu řízení projektu, přičemž možnost 1:1 je de facto jednostupňové zobrazení, které připadá v úvahu pouze pro velice jednoduché projekty nebo pro zobrazení workflow úloh a které je možné brát jako zvláštní případ transformace N:1.
Nechť pro druhý stupeň platí, že každá úloha se zobrazuje do modelu řízení projektu v poměru N:1.
- Jakmile je úspěšně dokončena transformace aktivit na úlohy, vzniká redukovaná síť úloh, ty je možné přiřadit jednotlivým etapám tvorby projektu ve smyslu chápání řízení projektu
- vzhledem k charakteru řízení projektu je ve finále nutná transformace síťových modelů do lineární časové osy, aby bylo možné stanovit přesné časové hranice jednotlivých etap, kontrolní body projektu, oponentní řízení apod. K tomuto účelu je nutné síť úloh promítnout do lineární časové osy.
Hlavním problémem, který je znázorněn na obr. q, je ta skutečnost, že úlohy C a D probíhají paralelně. Samotný paralelní průběh úloh není žádným nedostatkem modelu, ale problémy mohou vzniknout při vzájemné výměně výsledků mezi současně probíhajícími úlohami. Z pohledu řešení této vazby musíme rozlišit situaci, kdy:
• obě úlohy obsahují výkonné aktivity,
• alespoň jedna z úloh je úlohou informační.
Pokud obě úlohy obsahují výkonné aktivity, je nutné, aby první stupeň transformace aktivit na úlohy byl v síťovém modelu znovu přepracován, neboť z takto nadefinovaného modelu není zřejmé, v kterém okamžiku a jaké výsledky má úloha C předat úloze D.
Pokud je alespoň jedna z úloh C a D informační úlohou (v tomto případě se jedná o úlohu D), je výměna dat mezi úlohami naprosto korektní a není důvod, proč by se měla předchozí přiřazení měnit.
Sdružování informačních a kontrolních (Workflow) aktivit
- informační aktivity se obvykle používají pro jednotlivé úlohy tzn. vzniká další relativně samostatná síť zvláštních aktivit, které shromažďují informace o jednotlivých úlohách.
- Více informačních aktivit se obvykle sdružuje do jedné informační úlohy, která pak bývá přiřazena relací 1:1 k příslušné aktivitě
Informační úloha se plní průběžně během vykonávání prací na jednotlivých výkonných aktivitách úlohy.
Elementární vztah
- Každá aktivita je přiřazena právě jedné úloze
- počet prvků sítě se pro vyšší úroveň řízení nijak nezmění
- Obecně nelze tento postup doporučit, ale pro některé speciální aktivity je možné i jednu aktivitu považovat za jednu úlohu.
- U každá aktivity je možné kontrolovat výstupy z aktivity na nejobecnějším rozlišovacím stupni. Například jestli vůbec nějaký výstup z aktivity vznikl nebo jestli příslušný výstup obsahuje základní požadované veličiny (je-li to program, analýza, návrh apod.).
Tento elementární cyklus oprav ukazuje možnost zapojení mechanismu kontroly kvality do cyklu tvorby projektu. Kontrolu kvality dosažených výsledků je při tvorbě projektu možné popsat a zahrnout do modelu pomocí elementárního vztahu kontroly kvality každé aktivity nebo pomocí soustavy kontrolních a informačních toků.
- Více informačních aktivit se obvykle sdružuje do jedné informační úlohy, která pak bývá přiřazena relací 1:1 k příslušné aktivitě
Informační úloha se plní průběžně během vykonávání prací na jednotlivých výkonných aktivitách úlohy.
Elementární vztah
- Každá aktivita je přiřazena právě jedné úloze
- počet prvků sítě se pro vyšší úroveň řízení nijak nezmění
- Obecně nelze tento postup doporučit, ale pro některé speciální aktivity je možné i jednu aktivitu považovat za jednu úlohu.
- U každá aktivity je možné kontrolovat výstupy z aktivity na nejobecnějším rozlišovacím stupni. Například jestli vůbec nějaký výstup z aktivity vznikl nebo jestli příslušný výstup obsahuje základní požadované veličiny (je-li to program, analýza, návrh apod.).
Tento elementární cyklus oprav ukazuje možnost zapojení mechanismu kontroly kvality do cyklu tvorby projektu. Kontrolu kvality dosažených výsledků je při tvorbě projektu možné popsat a zahrnout do modelu pomocí elementárního vztahu kontroly kvality každé aktivity nebo pomocí soustavy kontrolních a informačních toků.
Opravné činnosti
• úloha buď obsahuje všechny přípustné cykly oprav (to znamená všechny aktivity vývojové a zároveň všechny aktivity opravné),
• nebo úloha nesmí obsahovat zároveň aktivity vývojové a aktivity opravné,
• úloha sestavená pouze z aktivit opravných musí splňovat podmínky spojitého grafu.
Cyklus opravy je definovaná následnost všech aktivit , které musí být vykonány, jestliže je v aktivitě AD zjištěna chyba a původ chyby je lokalizován v aktivitě AA. Potom musí být vykonána aktivita AE, která zajistí opravu všech dříve dokončených výsledků - obr. k.
Sdružování aktivit do úloh - příklad
Typová aktivita "Kompilace do PASCALU" je rozpracována do konkrétního vyjádření pro tři pracovníky Novák, Černík a Mudras. Aktivity (v tomto případě překlad konkrétních zdrojových programů kompilátorem PASCALU) A11 A14 a A21, A22 jsou součástí etapy "Kódování", zatímco práce na aktivitách A31 a A32 jsou práce na údržbě již fungující části systému. Při takovém zobrazení není možné, aby se některá z aktivit zobrazila do více úloh a tím i případně do více etap modelu řízení projektu.
Neelementární vztah - relace N:M
- Pokud není splněn předpoklad disjuktnosti přiřazení = zpochybnění předpokladu o zobrazení skupiny pouze do jedné fáze řízení projektu = jedna aktivita se zobrazí do více úloh, není možné nikde učinit předpoklad, aby se úlohy zobrazily do stejné fáze modelu řízení projektu
- porušen základní předpoklad druhého stupně transformace pro řízení.
- Jak se může projevit nesplnění tohoto předpokladu v praxi je znázorněno na obr. m.
.
Takovou transformaci není možné připustit, neboť jsou porušeny zásady řízení. Pokud už problém v této podobě vznikne, je možné jej řešit dvěma způsoby:
1. v modelu řízení projektu změnit definici přiřazení aktivit do skupin (tak, aby byla splněna podmínka disjunktnosti skupin).
2. v modelu řízení procesu tvorby projektu změnit:
• rozpracování síťového modelu,
• samotný typový síťový model (definici typových aktivit a jejich návazností).
• nebo úloha nesmí obsahovat zároveň aktivity vývojové a aktivity opravné,
• úloha sestavená pouze z aktivit opravných musí splňovat podmínky spojitého grafu.
Cyklus opravy je definovaná následnost všech aktivit , které musí být vykonány, jestliže je v aktivitě AD zjištěna chyba a původ chyby je lokalizován v aktivitě AA. Potom musí být vykonána aktivita AE, která zajistí opravu všech dříve dokončených výsledků - obr. k.
Sdružování aktivit do úloh - příklad
Typová aktivita "Kompilace do PASCALU" je rozpracována do konkrétního vyjádření pro tři pracovníky Novák, Černík a Mudras. Aktivity (v tomto případě překlad konkrétních zdrojových programů kompilátorem PASCALU) A11 A14 a A21, A22 jsou součástí etapy "Kódování", zatímco práce na aktivitách A31 a A32 jsou práce na údržbě již fungující části systému. Při takovém zobrazení není možné, aby se některá z aktivit zobrazila do více úloh a tím i případně do více etap modelu řízení projektu.
Neelementární vztah - relace N:M
- Pokud není splněn předpoklad disjuktnosti přiřazení = zpochybnění předpokladu o zobrazení skupiny pouze do jedné fáze řízení projektu = jedna aktivita se zobrazí do více úloh, není možné nikde učinit předpoklad, aby se úlohy zobrazily do stejné fáze modelu řízení projektu
- porušen základní předpoklad druhého stupně transformace pro řízení.
- Jak se může projevit nesplnění tohoto předpokladu v praxi je znázorněno na obr. m.
.
Takovou transformaci není možné připustit, neboť jsou porušeny zásady řízení. Pokud už problém v této podobě vznikne, je možné jej řešit dvěma způsoby:
1. v modelu řízení projektu změnit definici přiřazení aktivit do skupin (tak, aby byla splněna podmínka disjunktnosti skupin).
2. v modelu řízení procesu tvorby projektu změnit:
• rozpracování síťového modelu,
• samotný typový síťový model (definici typových aktivit a jejich návazností).
Pro lepší popis složité sítě aktivit modelu tvorby projektu rozdělujeme aktivity na kategorie:
• aktivity pro výměnu dat a zajištění kontroly v rámci řízení projektu - workflow aktivity,
• aktivity, které zajišťují vývoj projektu - vývojové aktivity,
• aktivity funkční v případě změny, oprav nebo modifikací již hotových výsledků - opravné aktivity.
Aktivity vývojové a aktivity opravné je možné shrnout pod souhrnný název aktivity výkonné
- při jejich plnění se vykonává nějaká konkrétně plánovatelná práce.
Naproti tomu workflow aktivity zachycují pohyb informací v rámci projektu
- tedy vlastně vyjadřují informační toky.
Navigace v modelu procesu tvorby projektu
- výstup každé aktivity směřuje směrem vpřed - výsledek představuje rozšíření souhrnu dílčích výsledků v projektu
- nebo výstup každé aktivity směřuje vzad - je výsledkem činnosti opravený výsledek, který byl již dříve vytvořen - opravné činnosti.
• Směr vpřed - zahrnuje ty aktivity, které nově v projektu vznikají, projekt se dále rozvíjí,
• Směr vzad - je vyhrazen pro aktivity kontrolní nebo opravné.
Pravidla sdružování aktivit do větších celků
Pravidla pro sdružování aktivit do větších celků musí splňovat kritéria nutná pro celkovou kontrolu určitého manažerského horizontu jako jsou:
• kontrolovatelnost
• jednoznačnost
• přehlednost
• srozumitelnost
• aktivity, které zajišťují vývoj projektu - vývojové aktivity,
• aktivity funkční v případě změny, oprav nebo modifikací již hotových výsledků - opravné aktivity.
Aktivity vývojové a aktivity opravné je možné shrnout pod souhrnný název aktivity výkonné
- při jejich plnění se vykonává nějaká konkrétně plánovatelná práce.
Naproti tomu workflow aktivity zachycují pohyb informací v rámci projektu
- tedy vlastně vyjadřují informační toky.
Navigace v modelu procesu tvorby projektu
- výstup každé aktivity směřuje směrem vpřed - výsledek představuje rozšíření souhrnu dílčích výsledků v projektu
- nebo výstup každé aktivity směřuje vzad - je výsledkem činnosti opravený výsledek, který byl již dříve vytvořen - opravné činnosti.
• Směr vpřed - zahrnuje ty aktivity, které nově v projektu vznikají, projekt se dále rozvíjí,
• Směr vzad - je vyhrazen pro aktivity kontrolní nebo opravné.
Pravidla sdružování aktivit do větších celků
Pravidla pro sdružování aktivit do větších celků musí splňovat kritéria nutná pro celkovou kontrolu určitého manažerského horizontu jako jsou:
• kontrolovatelnost
• jednoznačnost
• přehlednost
• srozumitelnost
Sdružování výkonných aktivit
Pro transformace výkonných aktivit do jednotlivých úloh je nutné zachovávat následující pravidla.
1. jednotlivé úlohy musí být disjunktní,
Nechť Ti a Tj jsou úlohy a P je celý projekt, který je složen z n úloh, potom musí platit:
Vzorec A Rozdělení na disjunktní úlohy
( Tj = P for j,j=1,n) ((ij) Ti Tj = ).
2. Pokud je zjištěna disjunktnost úloh, je možné definovat vztah mezi aktivitami a úlohami jako:
• elementární,
• neelementární.
Elementární vztah - 1:1
Neelementární vztahy
• N:1
• N:M více aktivit se sdruží do více skupin (skupiny nejsou disjunktní - spor sprvním pravidlem).
Elementární vztah - relace 1:1
= Každá aktivita je úlohou
- Taková transformace je sice korektní (není porušena žádná ze zásad řízení), ale nepřináší prakticky vůbec žádné usnadnění modelového přístupu.
- V kombinaci s možností transformace úloh do modelu řízení projektu 1:1 dává možnost, že jedna aktivita je etapou modelu řízení projektu.
- Tento tvar je možné použít pouze u velmi jednoduchých projektů nebo se u složitějších projektů zamyslet nad způsobem definice aktivity, úlohy a etapy v různých úrovních řízení.
Pro tuto transformaci není podstatné uvažovat typ aktivity.
Neelementární vztah - relace N:1
= Více aktivit se sdruží do jedné úlohy
- Je situací obvyklou a také nejjednodušší. Představuje případ, kdy jsou všechny aktivity sdruženy do disjunktní soustavy úloh ve smyslu vzorec a rozdělení na disjunktní úlohy.
- Všechny aktivity, které jsou sdruženy do jedné úlohy, musí tvořit spojitý graf.
1. jednotlivé úlohy musí být disjunktní,
Nechť Ti a Tj jsou úlohy a P je celý projekt, který je složen z n úloh, potom musí platit:
Vzorec A Rozdělení na disjunktní úlohy
( Tj = P for j,j=1,n) ((ij) Ti Tj = ).
2. Pokud je zjištěna disjunktnost úloh, je možné definovat vztah mezi aktivitami a úlohami jako:
• elementární,
• neelementární.
Elementární vztah - 1:1
Neelementární vztahy
• N:1
• N:M více aktivit se sdruží do více skupin (skupiny nejsou disjunktní - spor sprvním pravidlem).
Elementární vztah - relace 1:1
= Každá aktivita je úlohou
- Taková transformace je sice korektní (není porušena žádná ze zásad řízení), ale nepřináší prakticky vůbec žádné usnadnění modelového přístupu.
- V kombinaci s možností transformace úloh do modelu řízení projektu 1:1 dává možnost, že jedna aktivita je etapou modelu řízení projektu.
- Tento tvar je možné použít pouze u velmi jednoduchých projektů nebo se u složitějších projektů zamyslet nad způsobem definice aktivity, úlohy a etapy v různých úrovních řízení.
Pro tuto transformaci není podstatné uvažovat typ aktivity.
Neelementární vztah - relace N:1
= Více aktivit se sdruží do jedné úlohy
- Je situací obvyklou a také nejjednodušší. Představuje případ, kdy jsou všechny aktivity sdruženy do disjunktní soustavy úloh ve smyslu vzorec a rozdělení na disjunktní úlohy.
- Všechny aktivity, které jsou sdruženy do jedné úlohy, musí tvořit spojitý graf.
Transformace jednotlivých úrovní modelů
- Aby bylo vůbec možné provést transformaci jednotlivých úrovní modelů je nutné sdružovat aktivity do úloh (tasků) = nejmenší jednotky plánování řízení projektu
- Nutné stanovit pravidla pro sdružování aktivit do vyšších jednotek
- Pro převod mezi modelem řízení procesu tvorby projektu a modelem řízení projektu je účelné použít dvoustupňovou transformaci. Dvoustupňovou proto, že objekty, které vzniknou po prvním stupni transformace, mohou být použity pro postup plánovacích prací na projektu.
Dělení transformace:
1. stupeň : transformace aktivita - úloha
Jednotlivé aktivity se sdruží do skupin.
2. stupeň : transformace úloha - etapa
Skupiny se promítnou do modelu řízení projektu.
- Úlohou je tu myšlena základní nejmenší, dále nedělitelná část projektu, na níž se dá plánovat (např. podprogram nebo funkce).
- Definice úlohy je plně v kompetenci řízení projektu a na něm také záleží, jak je skupina definována. Postup definování úlohy není v mnoha případech možno provést za automatizované podpory nějakého nástroje. Stejně tak není možné bez zvážení strategie přiřazovat aktivity k úlohám.
Oba stupně transformace mají svá specifika, ale obecně lze říci, že první stupeň bude značně obtížnější než stupeň druhý.
Každá z aktivit v modelu je charakterizována čtyřmi atributy:
• vstupy (které výsledky do aktivity vystupují),
• vlastní popis aktivity,
• výstupy (které výsledky aktivita produkuje)
• a navigací (které aktivity jsou předchůdci - od kterých aktivit dostává výsledky - a kterým aktivitám mají být výsledky poskytnuty)
- Nutné stanovit pravidla pro sdružování aktivit do vyšších jednotek
- Pro převod mezi modelem řízení procesu tvorby projektu a modelem řízení projektu je účelné použít dvoustupňovou transformaci. Dvoustupňovou proto, že objekty, které vzniknou po prvním stupni transformace, mohou být použity pro postup plánovacích prací na projektu.
Dělení transformace:
1. stupeň : transformace aktivita - úloha
Jednotlivé aktivity se sdruží do skupin.
2. stupeň : transformace úloha - etapa
Skupiny se promítnou do modelu řízení projektu.
- Úlohou je tu myšlena základní nejmenší, dále nedělitelná část projektu, na níž se dá plánovat (např. podprogram nebo funkce).
- Definice úlohy je plně v kompetenci řízení projektu a na něm také záleží, jak je skupina definována. Postup definování úlohy není v mnoha případech možno provést za automatizované podpory nějakého nástroje. Stejně tak není možné bez zvážení strategie přiřazovat aktivity k úlohám.
Oba stupně transformace mají svá specifika, ale obecně lze říci, že první stupeň bude značně obtížnější než stupeň druhý.
Každá z aktivit v modelu je charakterizována čtyřmi atributy:
• vstupy (které výsledky do aktivity vystupují),
• vlastní popis aktivity,
• výstupy (které výsledky aktivita produkuje)
• a navigací (které aktivity jsou předchůdci - od kterých aktivit dostává výsledky - a kterým aktivitám mají být výsledky poskytnuty)
Aplikace modelového přístupu
- úrovně řízení projektu a řízení procesu tvorby projektu určí předpoklady pro reálné splnění požadavků, takže úrovni řízení úloh zbývá vlastně pouze dodržovat předepsané postupy a snažit se je splnit a případné odchylky od předpisů "hlásit výše"
- Modely řízení procesů tvorby projektů a řízení projektů po určitou dobu splývaly vodopádový model, spirálový nebo kruhový využívaly obě úrovně. S nástupem velkých a složitých projekčních celků vznikl specializovaný model pouze pro řízení procesů síťový model.
- pro úrovně řízení projektu a řízení procesu tvorby projektu se používá různý model vyjádření (taktéž i forma). Aby bylo možné udržet kontinuitu a komplexnost procesu řízení, je nezbytné sestavit projekci (transformaci) mezi oběma různými modely. Obecně lze říci, že se vlastně jedná o transformaci síťového modelu řízení procesu tvorby projektu na libovolný model klasického řízení projektu. Schéma transformace znázorněno na obr. j
Obr. J Obecné schéma transformace aktivita - úloha- etapa
Jaké požadavky musí taková transformace splnit?
• Zobrazuje všechny výsledky a aktivity modelu řízení procesu (pokud existují některé aktivity nebo výsledky, které nejsou postiženy modelem - de facto managementem projektu - nejsou tudíž řízeně vykonávány a ani kontrolovány. Musí být tedy prováděny "na černo". Takové aktivity a výsledky je nutno do modelu řízení projektu zahrnout formou rozšíření typového modelu projektu).
• Aktivity jsou zobrazovány do všech fází modelu řízení projektu (pokud ne, jsou některé fáze zbytečné a je možné je z modelu vypustit).
• Existuje příslušné vhodné zobrazení (Aktivity z modelu tvorby projektu není možné samozřejmě sdružovat do úloh náhodně a je nutné zachovávat určitá pravidla)
První dva body je nutné splnit a jejich splnění vyplývá přímo z toho, že projekt musí být smysluplně řízen
Model tvorby projektu a sdružování aktivit do skupin - vznik úloh
- Modely řízení procesů tvorby projektů a řízení projektů po určitou dobu splývaly vodopádový model, spirálový nebo kruhový využívaly obě úrovně. S nástupem velkých a složitých projekčních celků vznikl specializovaný model pouze pro řízení procesů síťový model.
- pro úrovně řízení projektu a řízení procesu tvorby projektu se používá různý model vyjádření (taktéž i forma). Aby bylo možné udržet kontinuitu a komplexnost procesu řízení, je nezbytné sestavit projekci (transformaci) mezi oběma různými modely. Obecně lze říci, že se vlastně jedná o transformaci síťového modelu řízení procesu tvorby projektu na libovolný model klasického řízení projektu. Schéma transformace znázorněno na obr. j
Obr. J Obecné schéma transformace aktivita - úloha- etapa
Jaké požadavky musí taková transformace splnit?
• Zobrazuje všechny výsledky a aktivity modelu řízení procesu (pokud existují některé aktivity nebo výsledky, které nejsou postiženy modelem - de facto managementem projektu - nejsou tudíž řízeně vykonávány a ani kontrolovány. Musí být tedy prováděny "na černo". Takové aktivity a výsledky je nutno do modelu řízení projektu zahrnout formou rozšíření typového modelu projektu).
• Aktivity jsou zobrazovány do všech fází modelu řízení projektu (pokud ne, jsou některé fáze zbytečné a je možné je z modelu vypustit).
• Existuje příslušné vhodné zobrazení (Aktivity z modelu tvorby projektu není možné samozřejmě sdružovat do úloh náhodně a je nutné zachovávat určitá pravidla)
První dva body je nutné splnit a jejich splnění vyplývá přímo z toho, že projekt musí být smysluplně řízen
Model tvorby projektu a sdružování aktivit do skupin - vznik úloh
Mezi velmi vážné problémy při opravách již hotových výsledků a návazných změn patří, jak:
• vytipovat a v celém síťovém modelu charakterizovat aktivitu, kde chyba vznikla,
• v návaznosti na síťový model definovat podmnožinu těch aktivit, které mohou být změnou předchozího výsledku postiženy,
• přijmout pravidla a opatření pro řízení navigace v tomto dílčím síťovém modelu oprav během prací na opravách,
• promítnout po skončení prací na aktivitách dílčího síťového modelu oprav modifikované výsledky do všech aktivit, které buď právě probíhají, nebo byly dokončeny během prací na opravách.
Reálného řízení projektu
- z pohledu reálného řízení je nezbytně nutné transformovat síťový model řízení postupu prací na tvorbě projektu IS do formy, která bude vhodná pro úroveň řízení projektů
- pro vývoj projektu je důležité přesné vymezení jednotlivých úrovní řízení projektu. Počet prvků v jednotlivých úrovních řízení projektu je značně proměnlivý a závisí na tom, jakou míru abstrakce nebo detailu je účelné sledovat pro příslušnou úroveň řízení. Ukázka zmenšování počtu komponent modelů - nárůst abstrakce je znázorněn na obr. i.
Pro úroveň řízení celého projektu nemá smysl sledovat detailně celý průběh projektu v členění na sledování jednotlivých dílčích aktivit nebo skupin aktivit. Na této úrovni je podstatné udržet si globální přehled o projektu jako celku. Naproti tomu model řízení postupu prací na projektu se primárně zabývá problematikou navigace při tvorbě projektu - tj. následností jednotlivých aktivit a úloh, sledováním a správou jejich výsledků, apod.
• v návaznosti na síťový model definovat podmnožinu těch aktivit, které mohou být změnou předchozího výsledku postiženy,
• přijmout pravidla a opatření pro řízení navigace v tomto dílčím síťovém modelu oprav během prací na opravách,
• promítnout po skončení prací na aktivitách dílčího síťového modelu oprav modifikované výsledky do všech aktivit, které buď právě probíhají, nebo byly dokončeny během prací na opravách.
Reálného řízení projektu
- z pohledu reálného řízení je nezbytně nutné transformovat síťový model řízení postupu prací na tvorbě projektu IS do formy, která bude vhodná pro úroveň řízení projektů
- pro vývoj projektu je důležité přesné vymezení jednotlivých úrovní řízení projektu. Počet prvků v jednotlivých úrovních řízení projektu je značně proměnlivý a závisí na tom, jakou míru abstrakce nebo detailu je účelné sledovat pro příslušnou úroveň řízení. Ukázka zmenšování počtu komponent modelů - nárůst abstrakce je znázorněn na obr. i.
Pro úroveň řízení celého projektu nemá smysl sledovat detailně celý průběh projektu v členění na sledování jednotlivých dílčích aktivit nebo skupin aktivit. Na této úrovni je podstatné udržet si globální přehled o projektu jako celku. Naproti tomu model řízení postupu prací na projektu se primárně zabývá problematikou navigace při tvorbě projektu - tj. následností jednotlivých aktivit a úloh, sledováním a správou jejich výsledků, apod.
Opravy a změny
- při vývoji a řízení tvorby projektů IS je výskyt chyb poměrně značný. Důvodů je hned několik:
• jsou relativně malé zkušenosti s tímto typem práce
• vytváří se vlastně nehmotný majetek, který se poměrně obtížně kontroluje - komplexnost řešení, kvalita apod.
• pracovní postupy a návyky jsou závislé na rychle se měnící technologii
• rozličná kvalita pracovníků v týmu
• práce probíhá v různých technologických prostředích
- snahou je minimalizovat výskyt chyb během tvorby projektu a tím průběh zlevnit, zrychlit a zkvalitnit
- při každé iteraci síťového modelu je manažer projektu postaven před dvě skupiny problémů, které jsou spojeny:
• s pokračováním ve vývoji IS
• s organizací skupiny nebo pracovního týmu pro opravy a změny v hotových částech projektu IS
- pracovníci podílející se na realizaci projektu jsou rozděleni na dvě skupiny = na skupinu vývojovou a na skupinu těch, kteří opravují chyby a promítají jejich důsledky do již hotových nebo právě probíhajících aktivit
- i opravy již dokončených částí projektu mají rozdělují pracovníky do dvou odlišných skupin - do skupiny dalšího vývoje projektu a do skupiny, která provádí opravy výsledků již „ukončených“
• jsou relativně malé zkušenosti s tímto typem práce
• vytváří se vlastně nehmotný majetek, který se poměrně obtížně kontroluje - komplexnost řešení, kvalita apod.
• pracovní postupy a návyky jsou závislé na rychle se měnící technologii
• rozličná kvalita pracovníků v týmu
• práce probíhá v různých technologických prostředích
- snahou je minimalizovat výskyt chyb během tvorby projektu a tím průběh zlevnit, zrychlit a zkvalitnit
- při každé iteraci síťového modelu je manažer projektu postaven před dvě skupiny problémů, které jsou spojeny:
• s pokračováním ve vývoji IS
• s organizací skupiny nebo pracovního týmu pro opravy a změny v hotových částech projektu IS
- pracovníci podílející se na realizaci projektu jsou rozděleni na dvě skupiny = na skupinu vývojovou a na skupinu těch, kteří opravují chyby a promítají jejich důsledky do již hotových nebo právě probíhajících aktivit
- i opravy již dokončených částí projektu mají rozdělují pracovníky do dvou odlišných skupin - do skupiny dalšího vývoje projektu a do skupiny, která provádí opravy výsledků již „ukončených“
Vlastnosti aktivit
Ukončené aktivity jsou ty aktivity při řešení projektu, které byly vyplněny a vedení projektu je nemá v úmyslu znovu provádět. K jejich změně může během tvorby projektu ovšem dojít, pokud vznikne při řešení projektu nějaký důvod modifikovat již hotové výsledky - např. zjištěná chyba ve vývoji, radikální změna požadavků na řešení projektu apod. Z pohledu vlastního řízení projektu jsou pro řídícího pracovníka již hotovou záležitostí, ke které se vrací jen nerad a jen tehdy, je-li k tomu okolnostmi donucen.
Aktivity pevně naplánované jsou v bezprostředním poli zájmu manažera. Jsou to aktivity, které jsou přesně rozplánovány jak z pohledu návazností jedné na druhou, tak i z pohledu rozdělení zdrojů na jejich plnění, přidělení pracovníků (až do úrovně úkolových listů - To Do List), objemů financí na aktivity, termínů plnění apod. Aktivity této kategorie jsou právě vykonávány nebo jejich začátek nastane ve velice blízkém termínu. Představují horizont řízení celého projektu.
Aktivity naplánované vágně je skupina aktivit, které musí pracovní tým projektu nevyhnutelně provést, aby projekt byl řádně dokončen. Nacházejí se ale za bezprostředním horizontem řízení manažera projektu. Je u nich naplánována následnost jednotlivých činností, navigace mezi aktivitami, informační toky během zpracování a přibližné termíny jejich plnění. Co není detailně rozpracováno, je přiřazení zdrojů k pokrytí požadavků aktivit, nejsou k nim s konečnou platností přiřazeni pracovníci, nástroje na jejich tvorbu apod.
Navigace v modelu procesu tvorby projektu
Řízení prací na projektu = konkrétní postup, jak vykonávat jednotlivé aktivity ze síťového modelu postupu prací na projektu, sledovat návaznosti výsledků příslušných aktivit a kontrolovat jejich atributy (kvalitu, čas, úplnost, komplexnost apod.).
Vývoj projektu
Aspekty navigace a řízení vývoje projektů IS jsou podporovány celou řadou nástrojů a pomůcek na různých úrovních řízení. Všechny tyto techniky a nástroje jsou postaveny na vztazích a zásadách analýzy síťových grafů. Mezi nástroje, které se dnes v této oblasti uplatňují, patří především MS PROJECT, TIME LINE apod.
Aktivity pevně naplánované jsou v bezprostředním poli zájmu manažera. Jsou to aktivity, které jsou přesně rozplánovány jak z pohledu návazností jedné na druhou, tak i z pohledu rozdělení zdrojů na jejich plnění, přidělení pracovníků (až do úrovně úkolových listů - To Do List), objemů financí na aktivity, termínů plnění apod. Aktivity této kategorie jsou právě vykonávány nebo jejich začátek nastane ve velice blízkém termínu. Představují horizont řízení celého projektu.
Aktivity naplánované vágně je skupina aktivit, které musí pracovní tým projektu nevyhnutelně provést, aby projekt byl řádně dokončen. Nacházejí se ale za bezprostředním horizontem řízení manažera projektu. Je u nich naplánována následnost jednotlivých činností, navigace mezi aktivitami, informační toky během zpracování a přibližné termíny jejich plnění. Co není detailně rozpracováno, je přiřazení zdrojů k pokrytí požadavků aktivit, nejsou k nim s konečnou platností přiřazeni pracovníci, nástroje na jejich tvorbu apod.
Navigace v modelu procesu tvorby projektu
Řízení prací na projektu = konkrétní postup, jak vykonávat jednotlivé aktivity ze síťového modelu postupu prací na projektu, sledovat návaznosti výsledků příslušných aktivit a kontrolovat jejich atributy (kvalitu, čas, úplnost, komplexnost apod.).
Vývoj projektu
Aspekty navigace a řízení vývoje projektů IS jsou podporovány celou řadou nástrojů a pomůcek na různých úrovních řízení. Všechny tyto techniky a nástroje jsou postaveny na vztazích a zásadách analýzy síťových grafů. Mezi nástroje, které se dnes v této oblasti uplatňují, patří především MS PROJECT, TIME LINE apod.
Síťový model
- klíčový význam má pro průběh tvorby celého projektu úroveň procesu tvorby projektu
- pro modelové vyjádření této vrstvy se v praxi používá vícevrstevný síťový model tak, jak je popsán na obr. e.
- metamodel uvedený na obr. E se mění v čase a mění se zároveň ve více dimenzích
• První dimenzí změny síťového modelu je vlastní vývoj typového síťového modelu (TM) a jeho modifikace pro určité projekty
• Vztah mezi výsledky a aktivitami typového modelu TM a jeho modifikací pro konkrétní projekt je: TMA TM.
= každá aktivita, vazba nebo výsledek v typovém modelu pro určitý konkrétní projekt TMA musí být zároveň popsána v obecném síťovém modelu (tm)
- pokud by nebyla je nutné obecný síťový model TM o takové úpravy neprodleně rozšířit
Příprava modelu řízení projektu
= konkrétní rozpracování typového modelu pro projekt A
- vztah mezi aktivitami, vazbami a výsledky je obdobný jako u obecného typového modelu a jeho modifikací pro projekt A: TMA i TMA TM
- zpřesňování modelu, jeho modifikace a změny v něm probíhají v závislosti na celé řadě externích a interních faktorů iterativním způsobem.
- Samotný iterační proces probíhá ve dvou částečně závislých úrovních.
• První úroveň jsou iterační kroky = postupná modifikace modelů od TMAi do TMAi+1 - tedy od i-té iterace do iterace i+1. Vznik nové iterace je iniciován vždy nějakou událostí, která má vliv na změnu projektu - například změna používaných nástrojů, vznik chyb v projektu nebo nutnost změny modelu z důvodu obměny pracovníků, upřesňování prováděného díla apod.. Jedná se převážně o změny v rozdělení zdrojů, výměně odpovědností pracovníků za některé aktivity na projektu apod.
• Druhou úrovní iterativního procesu jsou zásadní změny na projektu. Zásadními změnami na projektu se rozumí ty změny a úpravy v postupu řešení projektu, které zasahují do modifikace obecného typového modelu pro určitý projekt, případně až do vrstvy obecného typového modelu. Takové změny mají za následek modifikace a úpravy celého firemního modelu vývoje projektu, který je tímto způsobem udržován neustále v aktuálním stavu vzhledem ke znalostem o projektování a k používaným nástrojům.
- v iteračním procesu se tedy model řešení projektu pomocí popsaných aktivit přibližuje realitě
- manažer projektu však není schopen současně udržet kontrolu nad všemi aktivitami celého projektu
- je možné jednotlivé aktivity projektu rozdělit z pohledu představ manažera o jejich plnění a v závislosti na postupu prací na projektu na tři kategorie:
• ukončené aktivity,
• aktivity pevně naplánované,
• aktivity naplánované vágně.
- příslušnost určitých aktivit do jednotlivých kategorií je závislá na čase plnění projektu
- pro modelové vyjádření této vrstvy se v praxi používá vícevrstevný síťový model tak, jak je popsán na obr. e.
- metamodel uvedený na obr. E se mění v čase a mění se zároveň ve více dimenzích
• První dimenzí změny síťového modelu je vlastní vývoj typového síťového modelu (TM) a jeho modifikace pro určité projekty
• Vztah mezi výsledky a aktivitami typového modelu TM a jeho modifikací pro konkrétní projekt je: TMA TM.
= každá aktivita, vazba nebo výsledek v typovém modelu pro určitý konkrétní projekt TMA musí být zároveň popsána v obecném síťovém modelu (tm)
- pokud by nebyla je nutné obecný síťový model TM o takové úpravy neprodleně rozšířit
Příprava modelu řízení projektu
= konkrétní rozpracování typového modelu pro projekt A
- vztah mezi aktivitami, vazbami a výsledky je obdobný jako u obecného typového modelu a jeho modifikací pro projekt A: TMA i TMA TM
- zpřesňování modelu, jeho modifikace a změny v něm probíhají v závislosti na celé řadě externích a interních faktorů iterativním způsobem.
- Samotný iterační proces probíhá ve dvou částečně závislých úrovních.
• První úroveň jsou iterační kroky = postupná modifikace modelů od TMAi do TMAi+1 - tedy od i-té iterace do iterace i+1. Vznik nové iterace je iniciován vždy nějakou událostí, která má vliv na změnu projektu - například změna používaných nástrojů, vznik chyb v projektu nebo nutnost změny modelu z důvodu obměny pracovníků, upřesňování prováděného díla apod.. Jedná se převážně o změny v rozdělení zdrojů, výměně odpovědností pracovníků za některé aktivity na projektu apod.
• Druhou úrovní iterativního procesu jsou zásadní změny na projektu. Zásadními změnami na projektu se rozumí ty změny a úpravy v postupu řešení projektu, které zasahují do modifikace obecného typového modelu pro určitý projekt, případně až do vrstvy obecného typového modelu. Takové změny mají za následek modifikace a úpravy celého firemního modelu vývoje projektu, který je tímto způsobem udržován neustále v aktuálním stavu vzhledem ke znalostem o projektování a k používaným nástrojům.
- v iteračním procesu se tedy model řešení projektu pomocí popsaných aktivit přibližuje realitě
- manažer projektu však není schopen současně udržet kontrolu nad všemi aktivitami celého projektu
- je možné jednotlivé aktivity projektu rozdělit z pohledu představ manažera o jejich plnění a v závislosti na postupu prací na projektu na tři kategorie:
• ukončené aktivity,
• aktivity pevně naplánované,
• aktivity naplánované vágně.
- příslušnost určitých aktivit do jednotlivých kategorií je závislá na čase plnění projektu
Přílohy: Prostředí CASE
- od určitého stupně složitosti procesu tvorby projektu je možné sledovat posloupnost jednotlivých kroků, jejich správnou návaznost, správu mezivýsledků a konečných výsledků pouze za pomoci výpočetní techniky
- proto nutný vznik automatizovaného prostředku interpretace modelu procesu tvorby projektu
- nutné ponechat rozumně velký prostor systémovému integrátorovi
- vývojové prostředí CASE muselo převzít další úlohy, a tak tvůrce projektu pracuje s jednotným integrovaným rozhraním při použití všech nástrojů na tvorbu projektu
Obr. D Integrované prostředí tvorby projektů IS
Stručný popis složek integrovaného prostředí tvorby projektů IS je uveden v tab. c
Složka integrovaného prostředí Úloha
Interpret modelu Přebírá řízení a správu procesu tvorby projektu a tím, že interpretuje model procesu tvorby projektu prostřednictvím integrovaného uživatelského rozhraní komunikuje s uživatelem, nástroji a bankou mezivýsledků a konečných výsledků.
Model procesu tvorby projektu Obsahuje obecně platný formalizovaný předpis procesu tvorby projektu IS. Z něho musí být vzhledem ke konkrétním specifikům odvozen postup pro tvorbu určitého projektu.
Rozhraní nástrojů pro tvorbu projektu Prostřednictvím standardního uživatelského rozhraní jsou připojeny všechny požadované nástroje pro tvorbu projektu.
Správa výsledků Prostředí CASE přejímá správu mezivýsledků a konečných výsledků a sleduje i jejich vzájemné vztahy. Vlastní záznam výsledků provádí do banky mezivýsledků a konečných výsledků.
Pomoc a konzultace Poskytuje po zavolání funkce HEPL pomocné informace pro práci s příslušnými nástroji.
Navigace v modelu
Pomocí této komponenty volí řídící pracovník projektu tu aktivitu, která se má vykonat jako následující.
Banka nástrojů pro uživatele Tvůrce projektu dostává jejím prostřednictvím informace o ukončených aktivitách, jejich souvislostech, výhledu dalších prací, očekávaných výsledcích a nástrojích, které mu jsou k dispozici.
Definování procesů tvorby a údržby Pomocí této složky je pravidelně aktualizován samotný model procesu tvorby projektu a zde také vstupují do modelu projektu specifické rysy a zvláštnosti konkrétního projektu.
Dokumentace Ačkoli je většina informací jak o projektu, tak i o nástrojích přístupna on-line, přesto jsou občas potřeba i některé příručky v klasické formě
Tab. C Integrované prostředí tvorby projektů IS
- počítačová podpora procesu tvorby projektu decentralizaci řízení projektu prakticky na všech úrovních
- přesto díky integrovanému prostředí nástroje typu CASE a síťovému propojení mezi pracovišti možné udržet centrální kontrolu nad průběhem tvorby projektu IS a proces jeho tvorby účinně koordinovat
- proto nutný vznik automatizovaného prostředku interpretace modelu procesu tvorby projektu
- nutné ponechat rozumně velký prostor systémovému integrátorovi
- vývojové prostředí CASE muselo převzít další úlohy, a tak tvůrce projektu pracuje s jednotným integrovaným rozhraním při použití všech nástrojů na tvorbu projektu
Obr. D Integrované prostředí tvorby projektů IS
Stručný popis složek integrovaného prostředí tvorby projektů IS je uveden v tab. c
Složka integrovaného prostředí Úloha
Interpret modelu Přebírá řízení a správu procesu tvorby projektu a tím, že interpretuje model procesu tvorby projektu prostřednictvím integrovaného uživatelského rozhraní komunikuje s uživatelem, nástroji a bankou mezivýsledků a konečných výsledků.
Model procesu tvorby projektu Obsahuje obecně platný formalizovaný předpis procesu tvorby projektu IS. Z něho musí být vzhledem ke konkrétním specifikům odvozen postup pro tvorbu určitého projektu.
Rozhraní nástrojů pro tvorbu projektu Prostřednictvím standardního uživatelského rozhraní jsou připojeny všechny požadované nástroje pro tvorbu projektu.
Správa výsledků Prostředí CASE přejímá správu mezivýsledků a konečných výsledků a sleduje i jejich vzájemné vztahy. Vlastní záznam výsledků provádí do banky mezivýsledků a konečných výsledků.
Pomoc a konzultace Poskytuje po zavolání funkce HEPL pomocné informace pro práci s příslušnými nástroji.
Navigace v modelu
Pomocí této komponenty volí řídící pracovník projektu tu aktivitu, která se má vykonat jako následující.
Banka nástrojů pro uživatele Tvůrce projektu dostává jejím prostřednictvím informace o ukončených aktivitách, jejich souvislostech, výhledu dalších prací, očekávaných výsledcích a nástrojích, které mu jsou k dispozici.
Definování procesů tvorby a údržby Pomocí této složky je pravidelně aktualizován samotný model procesu tvorby projektu a zde také vstupují do modelu projektu specifické rysy a zvláštnosti konkrétního projektu.
Dokumentace Ačkoli je většina informací jak o projektu, tak i o nástrojích přístupna on-line, přesto jsou občas potřeba i některé příručky v klasické formě
Tab. C Integrované prostředí tvorby projektů IS
- počítačová podpora procesu tvorby projektu decentralizaci řízení projektu prakticky na všech úrovních
- přesto díky integrovanému prostředí nástroje typu CASE a síťovému propojení mezi pracovišti možné udržet centrální kontrolu nad průběhem tvorby projektu IS a proces jeho tvorby účinně koordinovat
Hlavní vztahy mezi úrovní řízení procesu tvorby projektu a řízením projektu:
1. Vztahy mezi úlohami a aktivitami
- je definována relace mezi úlohou a aktivitami buď N:1 nebo 1:1
- kromě výkonných úloh musí vedoucí projektu plánovat i další „úlohy“, které nejsou v modelu postupu prací (např. dovolená, školení práce s novými nástroji apod.).
2. Vztahy logické a časové
- časová následnost úloh je dána logickou následností plnění aktivit = je popsána pomocí modelu postupu prací
3. Předávání informací o stavu úloh a aktivit
- stav úlohy je možné odvodit od stavu jejích jednotlivých aktivit (správu stavů aktivit provádí úroveň řízení postupu prací).
4. Pořadí vykonávání aktivit a určování jejich priorit
- pro stanovení následností jednotlivých aktivit je nutné znát zdroje (materiální, lidské), které jsou pro dané etapy k dispozici
- zdroje dává k dispozici úroveň řízení projektu
Nástroje
Nástroje a techniky pro podporu projektového řízení z pohledu typu SW nástrojů
1) Project Management Software
• SW určený pro automatizovanou podporu řízení projektů (MS Project, Time Line…)
• zaměření na podporu plánovacích technik (Ganttův diagram, metoda PERT, metoda CPM)
• rozvrhování zdrojů
• sledování vývoje projektu
• řízení změn a porovnávání skutečného stavu s plánovaným
2) Součást nástrojů CASE nebo ERP balíků
CASE nástroje (Computer Aided Software Engineering)
• podpora řízení projektů
• podpora projekčních a programátorských prací
• vyuzivaji se u projektu kde se produkt vytvari vlastnimi silami
• mají několik tříd z nichž pouze nektere zahrnuji nastroje pro podporu rizeni projektu.
3) součást ERP
• napr. model procedury
• hotové návody dekompozice cíle projektu na dílčí úlohy
• řízení a konfigurace systému řízení dokumentace
- je definována relace mezi úlohou a aktivitami buď N:1 nebo 1:1
- kromě výkonných úloh musí vedoucí projektu plánovat i další „úlohy“, které nejsou v modelu postupu prací (např. dovolená, školení práce s novými nástroji apod.).
2. Vztahy logické a časové
- časová následnost úloh je dána logickou následností plnění aktivit = je popsána pomocí modelu postupu prací
3. Předávání informací o stavu úloh a aktivit
- stav úlohy je možné odvodit od stavu jejích jednotlivých aktivit (správu stavů aktivit provádí úroveň řízení postupu prací).
4. Pořadí vykonávání aktivit a určování jejich priorit
- pro stanovení následností jednotlivých aktivit je nutné znát zdroje (materiální, lidské), které jsou pro dané etapy k dispozici
- zdroje dává k dispozici úroveň řízení projektu
Nástroje
Nástroje a techniky pro podporu projektového řízení z pohledu typu SW nástrojů
1) Project Management Software
• SW určený pro automatizovanou podporu řízení projektů (MS Project, Time Line…)
• zaměření na podporu plánovacích technik (Ganttův diagram, metoda PERT, metoda CPM)
• rozvrhování zdrojů
• sledování vývoje projektu
• řízení změn a porovnávání skutečného stavu s plánovaným
2) Součást nástrojů CASE nebo ERP balíků
CASE nástroje (Computer Aided Software Engineering)
• podpora řízení projektů
• podpora projekčních a programátorských prací
• vyuzivaji se u projektu kde se produkt vytvari vlastnimi silami
• mají několik tříd z nichž pouze nektere zahrnuji nastroje pro podporu rizeni projektu.
3) součást ERP
• napr. model procedury
• hotové návody dekompozice cíle projektu na dílčí úlohy
• řízení a konfigurace systému řízení dokumentace
Nástroje a techniky pro podporu projektového řízení z pohledu funkci které plní
= jaké funkce plní automatizované nástroje pro podporu řízeni projektu
základní funkce a techniky projektového řízení
1) plánovací techniky
• technika PERT (vychází z odhadnutých údajů síťový graf)
• technika Ganttových diagramů (čas vs. úlohy)
2) rozvrhování zdrojů na tvorbu systému
• vytvoření profilu požadavků na zdroje (poptávka)
• představa o existujících zdrojích (nabídka)
sladění nabídky a poptávky (podklady – pracovní dekompozice
časový plán práce)
3) odhadování času a nákladů projektu
• výše požadavků na zdroje
• hodnota zdrojů
4) analýza rizik a jeho řízení
• vytipování důležitých úloh
• definování hrozeb a pravděpodobností výskytu
• určení rizika a jeho hodnoty
• navržení opatření zmírňující riziko
5) sledování postupu vývoje projektu
6) řízení změn
7) řízení kvality projektu
• sjednocení názoru na požadavky kvality
• určení metrik
• určení tříd kvality ve vazbě na metriky
základní funkce a techniky projektového řízení
1) plánovací techniky
• technika PERT (vychází z odhadnutých údajů síťový graf)
• technika Ganttových diagramů (čas vs. úlohy)
2) rozvrhování zdrojů na tvorbu systému
• vytvoření profilu požadavků na zdroje (poptávka)
• představa o existujících zdrojích (nabídka)
sladění nabídky a poptávky (podklady – pracovní dekompozice
časový plán práce)
3) odhadování času a nákladů projektu
• výše požadavků na zdroje
• hodnota zdrojů
4) analýza rizik a jeho řízení
• vytipování důležitých úloh
• definování hrozeb a pravděpodobností výskytu
• určení rizika a jeho hodnoty
• navržení opatření zmírňující riziko
5) sledování postupu vývoje projektu
6) řízení změn
7) řízení kvality projektu
• sjednocení názoru na požadavky kvality
• určení metrik
• určení tříd kvality ve vazbě na metriky
Řízení procesu tvorby projektu (Process Management)
- přebírá od úrovně řízení projektu, které má úlohu koncepční, úlohu operativního řízení
- zahrnuje:
řízení postupu prací na tvorbě projektu
dodržování stanoveného postupu prací
evidence dosažených výsledků jednotlivých částí pracovního postupu řešení projektu
- vychází z modelu řízení prací
- základem jsou logické vazby mezi jednotlivými aktivitami úlohy
- formálním vyjádřením modelu řízení procesů je komplexní síť jednotlivých aktivit, které produkují určité výsledky, které jsou používány následnými aktivitami a jsou jimi dále zpracovávány
- používá nástroje pro podporu tvorby projektu, nasazuje je do příslušných fází a etap tvorby projektu
- hlavní náplní je provádět pilotáž projektu (sledovat logickou a časovou návaznost činností).
Obr. A Schéma funkcionálních vztahů úrovní řízení projektu
na obr. a je vidět úzká provázanost mezi řízením projektů a řízením procesu tvorby projektu (oblasti působnosti řízení projektu a řízení procesů se společně prolínají v nejnižším článku v řízení úloh obr. a.)
- projekt musí být řízen hierarchicky - není možné práce na projektu řídit jednoúrovňově vedoucí "ví všechno a zná všechno" a vše je schopen rozhodnout
- hierarchická struktura jednotlivých úrovní řízení projektu
Řízení úloh
- hlavní úlohou je řízení tvorby konkrétních částí systému (jednotlivých úloh)
- práce s konkrétními pracovníky (stanovení rozumného počtu pracovníků, optimální struktury pracovního týmu)
- nasazování příslušných nástrojů tvorby projektu na řešení určitých úloh
- zahrnuje:
řízení postupu prací na tvorbě projektu
dodržování stanoveného postupu prací
evidence dosažených výsledků jednotlivých částí pracovního postupu řešení projektu
- vychází z modelu řízení prací
- základem jsou logické vazby mezi jednotlivými aktivitami úlohy
- formálním vyjádřením modelu řízení procesů je komplexní síť jednotlivých aktivit, které produkují určité výsledky, které jsou používány následnými aktivitami a jsou jimi dále zpracovávány
- používá nástroje pro podporu tvorby projektu, nasazuje je do příslušných fází a etap tvorby projektu
- hlavní náplní je provádět pilotáž projektu (sledovat logickou a časovou návaznost činností).
Obr. A Schéma funkcionálních vztahů úrovní řízení projektu
na obr. a je vidět úzká provázanost mezi řízením projektů a řízením procesu tvorby projektu (oblasti působnosti řízení projektu a řízení procesů se společně prolínají v nejnižším článku v řízení úloh obr. a.)
- projekt musí být řízen hierarchicky - není možné práce na projektu řídit jednoúrovňově vedoucí "ví všechno a zná všechno" a vše je schopen rozhodnout
- hierarchická struktura jednotlivých úrovní řízení projektu
Řízení úloh
- hlavní úlohou je řízení tvorby konkrétních částí systému (jednotlivých úloh)
- práce s konkrétními pracovníky (stanovení rozumného počtu pracovníků, optimální struktury pracovního týmu)
- nasazování příslušných nástrojů tvorby projektu na řešení určitých úloh
Komponenty řízení projektu
- proces tvorby projektu je nutné posuzovat z různých pohledů – 3 vrstev řízení:
• řízení projektu (Project Management),
• řízení procesu tvorby projektu (Process Management),
• řízení úloh (Task Management).
Řízení projektu (Project Management)
- zahrnuje činnosti, jejichž cílem je úspěšné završení projektu (tzn. s danými zdroji (náklady),ve stanoveném čase, s výsledky požadované kvality, v požadovaném rozsahu (kvantita)).
Jádrem řízení projektu je:
- plánování celého projektu
- odstranění nepředvídatelných komplikací během celého projektu
- vymezení plánovaných skupin pracovních aktivit (úloh)
- rozdělení zdrojů
- stanovení následností mezi jednotlivými aktivitami
- stanovení organizačních pravidel pro práci
• řízení projektu (Project Management),
• řízení procesu tvorby projektu (Process Management),
• řízení úloh (Task Management).
Řízení projektu (Project Management)
- zahrnuje činnosti, jejichž cílem je úspěšné završení projektu (tzn. s danými zdroji (náklady),ve stanoveném čase, s výsledky požadované kvality, v požadovaném rozsahu (kvantita)).
Jádrem řízení projektu je:
- plánování celého projektu
- odstranění nepředvídatelných komplikací během celého projektu
- vymezení plánovaných skupin pracovních aktivit (úloh)
- rozdělení zdrojů
- stanovení následností mezi jednotlivými aktivitami
- stanovení organizačních pravidel pro práci
Průběh delfské metody:
1. Dotazníky rozeslané poštou - formalizace, odstranění vlivu osobností a ostýchavosti
2. Následují další kola dotazů, které doplňují a zpřesňují výsledky kola prvního-
3. Inklinace ke shodě - používá se medián jako indikátor shody
Cíl: zjištění příčin a okolností, nikoliv kdy se co stane. Odhad budoucí události, dosáhnout souhlasu, zjistit příčiny rozporů, získat expertní odhady, komunikace mezi vědou a praxí.
Pravidla:
• Počet členů: 15-25 odborníků
• Odměny za vrácené dotazníky
• Vyhnout se dvouznačnostem
• Max. 25 otázek,
• Lze měnit složení skupiny, doba trvání 2 měsíce, max. 4 kola, při neshodě svolat panelovou diskuzi.
Brainstorming
- používán k vyvolávání množství námětů (proto se česky užívá termín "burza nápadů") a k řešení problémů v tvořivé, uvolněné atmosféře řešitelské skupiny, v níž platí zákaz kritiky a ironie. Má různé modifikace, např. známe brainstorming:
• didaktický, kdy problém postupně zpřesňujeme a konkretizujeme
• destruktivně konstrukční, v němž nejdříve vytipujeme slabiny výchozího objektu
• integrační, kdy každý člen skupiny připraví svůj námět na řešení, pak se skupina snaží integrovat první dva nápady v jeden s využitím předností obou námětů, poté se přiřadí třetí námět atd.
Braiwriting (písemná diskuse)
Náměty se píší na arch papíru. Každý člen týmu dostane čistý arch, na který napíše ve velmi omezené době (např. 5 minut) určitý počet námětů (třeba tři). Pak podá svůj arch sousedovi po levici a vezme arch od souseda po pravici. Na něj připíše další tři náměty, buď zcela nové, nebo inspirované již napsanými náměty. Tak obejde každý arch všechny členy skupiny. Ta pak všechny náměty vyhodnotí. Pro začátečnickou skupinu je metoda velmi vhodná.
Dobře a špatně strukturované problémy
- na nejvyšší úrovni se řeší především nestrukturované problémy (informace se získávají především pomocí metod rozhodování za rizika a nejistoty tzn. heuristických metod) . Naopak problémy na nejnižší řídící úrovni jsou většinou rutinní a dobře strukturované a vyžadují pouze malou rozhodovací volnost.
Fotr, Dědina: Manažerské rozhodování
2. Následují další kola dotazů, které doplňují a zpřesňují výsledky kola prvního-
3. Inklinace ke shodě - používá se medián jako indikátor shody
Cíl: zjištění příčin a okolností, nikoliv kdy se co stane. Odhad budoucí události, dosáhnout souhlasu, zjistit příčiny rozporů, získat expertní odhady, komunikace mezi vědou a praxí.
Pravidla:
• Počet členů: 15-25 odborníků
• Odměny za vrácené dotazníky
• Vyhnout se dvouznačnostem
• Max. 25 otázek,
• Lze měnit složení skupiny, doba trvání 2 měsíce, max. 4 kola, při neshodě svolat panelovou diskuzi.
Brainstorming
- používán k vyvolávání množství námětů (proto se česky užívá termín "burza nápadů") a k řešení problémů v tvořivé, uvolněné atmosféře řešitelské skupiny, v níž platí zákaz kritiky a ironie. Má různé modifikace, např. známe brainstorming:
• didaktický, kdy problém postupně zpřesňujeme a konkretizujeme
• destruktivně konstrukční, v němž nejdříve vytipujeme slabiny výchozího objektu
• integrační, kdy každý člen skupiny připraví svůj námět na řešení, pak se skupina snaží integrovat první dva nápady v jeden s využitím předností obou námětů, poté se přiřadí třetí námět atd.
Braiwriting (písemná diskuse)
Náměty se píší na arch papíru. Každý člen týmu dostane čistý arch, na který napíše ve velmi omezené době (např. 5 minut) určitý počet námětů (třeba tři). Pak podá svůj arch sousedovi po levici a vezme arch od souseda po pravici. Na něj připíše další tři náměty, buď zcela nové, nebo inspirované již napsanými náměty. Tak obejde každý arch všechny členy skupiny. Ta pak všechny náměty vyhodnotí. Pro začátečnickou skupinu je metoda velmi vhodná.
Dobře a špatně strukturované problémy
- na nejvyšší úrovni se řeší především nestrukturované problémy (informace se získávají především pomocí metod rozhodování za rizika a nejistoty tzn. heuristických metod) . Naopak problémy na nejnižší řídící úrovni jsou většinou rutinní a dobře strukturované a vyžadují pouze malou rozhodovací volnost.
Fotr, Dědina: Manažerské rozhodování
Heuristické metody
- jsou využity při hledání řešení - nejčastěji pro omezení všech možných variant, které připadají v úvahu
- obecně jakékoliv metody, které přináší slušné výsledky
- využívají logiku a zobecnělé zkušenosti
- jsou rozdělovány na metody invenční a metody logicko-strukturální
Invenční metody
- vhodné především pro etapu prvotního zkoumání problému, analýzu potřebných informací či hledání nových, netradičních přístupů a návrhů řešení
- mezi tyto metody se řadí orientační diskuse, tématická diskuse, brainstorming, brainwriting či delfská metoda
Strukturální metody
- mají charakter určitého obecného programu rozhodování
- vycházejí z obecné metodiky rozhodovacího procesu a podrobně analyzují základní prvky rozhodování (cíle, podmínky, kritéria)
- umožňují stanovení většího počtu variant řešení a formulují i zásady jejich hodnocení. Mezi tyto metody patří rozhodovací analýza, rozhodovací strom a rozhodovací matice
Metoda získání informací od expertů
Experti mluví jiným jazykem!
Delfská metoda:
- vhodná k dosažení kompromisu nebo upřesnění rozptylu odhadu nějakého neurčitého parametru nebo jeho pravděpodobné hodnoty
- K problému se sestaví dotazník, který se rozešle asi 10 až 20 odborníkům. Každý z nich, nezávisle na druhých, dotazník vyplní a vrátí organizátorovi, který odpovědi zhodnotí a takto zpracovaný materiál vrátí respondentům pro druhé kolo ankety. Podle této zpětné vazby mohou, ale nemusí, experti svá stanoviska přehodnotit. Výhodou metody je, že se vylučuje vzájemné ovlivňování, kterému se někdy nevyhnou skupinové diskuse.
- obecně jakékoliv metody, které přináší slušné výsledky
- využívají logiku a zobecnělé zkušenosti
- jsou rozdělovány na metody invenční a metody logicko-strukturální
Invenční metody
- vhodné především pro etapu prvotního zkoumání problému, analýzu potřebných informací či hledání nových, netradičních přístupů a návrhů řešení
- mezi tyto metody se řadí orientační diskuse, tématická diskuse, brainstorming, brainwriting či delfská metoda
Strukturální metody
- mají charakter určitého obecného programu rozhodování
- vycházejí z obecné metodiky rozhodovacího procesu a podrobně analyzují základní prvky rozhodování (cíle, podmínky, kritéria)
- umožňují stanovení většího počtu variant řešení a formulují i zásady jejich hodnocení. Mezi tyto metody patří rozhodovací analýza, rozhodovací strom a rozhodovací matice
Metoda získání informací od expertů
Experti mluví jiným jazykem!
Delfská metoda:
- vhodná k dosažení kompromisu nebo upřesnění rozptylu odhadu nějakého neurčitého parametru nebo jeho pravděpodobné hodnoty
- K problému se sestaví dotazník, který se rozešle asi 10 až 20 odborníkům. Každý z nich, nezávisle na druhých, dotazník vyplní a vrátí organizátorovi, který odpovědi zhodnotí a takto zpracovaný materiál vrátí respondentům pro druhé kolo ankety. Podle této zpětné vazby mohou, ale nemusí, experti svá stanoviska přehodnotit. Výhodou metody je, že se vylučuje vzájemné ovlivňování, kterému se někdy nevyhnou skupinové diskuse.
Dotazník
Díky užití dotazníků, může analytik následně určit co je nutno zjistit v interview. Opačně dotazníky mohou být využity k tomu, aby se zjistily další podrobnosti k informacím, získaným v interview. Dotazníky mohou vyhodnotit obrovské množství informací od uživatelů systému. Lze tak shromáždit důležité informace, řešení, pochopit jednotlivé problémy ještě před interview.
Je mnoho podobností mezi používáním dotazníků a interview. Především by bylo ideální spojení mezi nimi. Každý dotazník koresponduje s interview, nebo dotazník je postaven na základe interview. Ačkoli každá technika má specifickou funkci, není ale třeba už/vat obé dvě techniky najednou.
Dotazníky se zdají být rychlou cestou ke sběru velkého množství informací o tom, jak uživatelé využívají stávající systém, jaké problémy souvisí s jejich prací, a co lidé očekávají od nového nebo modifikovaného systému. Tvorba dotazníků, jejich vyhodnocování i distribuce však zabere mnoho Času a je nutno zvážit, kdy je opravdu vhodné shromáždit informací pomocí dotazníků bez použití interview.
Druhy informací, které získáváme použitím dotazníků
Dotazník je technika shromažďování informaci, která dovoluje shromažďovat stanoviska, mínění a názory, chování a charakteristiky od většího počtu osob ve firmě (které mohou být využity při shromažďováni informací o stávajícím nebo nově navrhovaném systémy):
• stanoviska, postoje, zaujímané dotazovaným k problému
• mínění, názory dotazovaného, týkající se problému
• (typické) jednání / chování dotazovaného
• charakteristiky entit a procesů, jak je vnímá dotazovaný
Je mnoho podobností mezi používáním dotazníků a interview. Především by bylo ideální spojení mezi nimi. Každý dotazník koresponduje s interview, nebo dotazník je postaven na základe interview. Ačkoli každá technika má specifickou funkci, není ale třeba už/vat obé dvě techniky najednou.
Dotazníky se zdají být rychlou cestou ke sběru velkého množství informací o tom, jak uživatelé využívají stávající systém, jaké problémy souvisí s jejich prací, a co lidé očekávají od nového nebo modifikovaného systému. Tvorba dotazníků, jejich vyhodnocování i distribuce však zabere mnoho Času a je nutno zvážit, kdy je opravdu vhodné shromáždit informací pomocí dotazníků bez použití interview.
Druhy informací, které získáváme použitím dotazníků
Dotazník je technika shromažďování informaci, která dovoluje shromažďovat stanoviska, mínění a názory, chování a charakteristiky od většího počtu osob ve firmě (které mohou být využity při shromažďováni informací o stávajícím nebo nově navrhovaném systémy):
• stanoviska, postoje, zaujímané dotazovaným k problému
• mínění, názory dotazovaného, týkající se problému
• (typické) jednání / chování dotazovaného
• charakteristiky entit a procesů, jak je vnímá dotazovaný
Rozhovor
- interview je především formální setkání, kde analytik může získat informace potřebné ke zkoumání stávajících nebo k návrhu nových systémů. Analytik totiž zpravidla nedisponuje důkladnou znalostí věcné problematiky v dané oblasti. Cílem této činnosti je přímou komunikací s jednotlivými pracovníky ve firmě zadavatele tvorby IS;
• identifikovat a shromáždit informace z reality
• zachytit je
• a uspořádat přehlednou formou pro potřeby následného vyhodnocení.
Druhy informací, které získáváme použitím interview
Informace získané pomocí interview mají díky přímé konverzaci (otázka - odpověď) poněkud specifický charakter. Pomocí interview lze zjistit názory dotazovaného, jeho mínění o (pocity a sympatie vzhledem ke) stávajícím stavu systému, firemní i osobní cíle i informace o neformální procesech a činnostech. Nejdůležitější je zaměřit se na názory a mínění dotazovaného. Především názory jsou velice důležité a v mnoha případech odhalí více než strohá fakta.
Kromě názorů je vhodné se pokusit zachytit i pocity a emoce dotazovaného. Stále je nutno si uvědomit, že dotazovaný zná firemní prostředí lépe než sebelepší analytik. Porozumět například firemní kultuře, náladě, neformálním pravidlům lze pouze „nasloucháním pocitů" dotazovaného. Lze také vycítit optimismus nebo skepsi vzhledem ke stávajícímu stavu systému nebo případná očekávání od systému nového.
Vztahy k cílům jsou velice důležité informace, které lze získat pouze z interview. Fakta získaná ze „strohých dat" mohou osvětlil minulost, nikdy však cíle a záměry budoucna. Je vhodné pokusit se zjistit co nejvíce cílů právě pomocí interview. V praxi není možné zjisti cíle a očekávání pomocí žádné jiné metody sběru faktů.
• identifikovat a shromáždit informace z reality
• zachytit je
• a uspořádat přehlednou formou pro potřeby následného vyhodnocení.
Druhy informací, které získáváme použitím interview
Informace získané pomocí interview mají díky přímé konverzaci (otázka - odpověď) poněkud specifický charakter. Pomocí interview lze zjistit názory dotazovaného, jeho mínění o (pocity a sympatie vzhledem ke) stávajícím stavu systému, firemní i osobní cíle i informace o neformální procesech a činnostech. Nejdůležitější je zaměřit se na názory a mínění dotazovaného. Především názory jsou velice důležité a v mnoha případech odhalí více než strohá fakta.
Kromě názorů je vhodné se pokusit zachytit i pocity a emoce dotazovaného. Stále je nutno si uvědomit, že dotazovaný zná firemní prostředí lépe než sebelepší analytik. Porozumět například firemní kultuře, náladě, neformálním pravidlům lze pouze „nasloucháním pocitů" dotazovaného. Lze také vycítit optimismus nebo skepsi vzhledem ke stávajícímu stavu systému nebo případná očekávání od systému nového.
Vztahy k cílům jsou velice důležité informace, které lze získat pouze z interview. Fakta získaná ze „strohých dat" mohou osvětlil minulost, nikdy však cíle a záměry budoucna. Je vhodné pokusit se zjistit co nejvíce cílů právě pomocí interview. V praxi není možné zjisti cíle a očekávání pomocí žádné jiné metody sběru faktů.
Klasické metody získávání dat a informací:
1. Analýza firemních dokumentů a firemní dokumentace – rozšířeno níže
Mezi ně patří především organizační diagramy,administrativní příručky, popisy práce a specifikace pracovních zařazení, výukové materiály, prodejní a reklamní publikace
2. Dotazníky
3. Interview a rozhovor
4. Pozorování
Pozorování systému při normální činnosti odhalí mnoho charakteristických rysů prostředí, které nemusí být zpočátku považovány za závažné.
5. Anketa
6. Kontrolní lístky (empirická data)
Analýza firemních dokumentů a firemní dokumentace
Informace o firmě mohou být v následujících podobách tzv. podkladových materiálů:
• organizační diagramy
• administrativní příručky
• popisy práce a specifikace pracovních zařazení
• výukové manuály
• prodejní a reklamní dokumentace.
Významným zdrojem informací jsou dokumenty charakteru strategického plánování a výroční zprávy. Čas strávený touto činností závisí na konkrétních okolnostech. Analýza může být časově velmi náročná. Je zde viditelná tendence k získávání příliš mnoha informací, protože tato činnost je pro analytika poměrně bez problémů. Většinou se při této fázi analýzy stráví příliš mnoho času, resp. více, než je úměrné výsledku této analýzy.
Podrobnosti získané o dokumentu jsou zdrojem pro tvorbu datových slovníků, charakteristika dokumentu může obsahovat:
• čas, kdy je datový prvek zapsán
• význam, velikost a formát každého datového prvku
• zdroj každého datového prvku
• použití každého datového prvku
• pořadí vkládání datových prvků.
Analýza dokumentů by měla také zahrnovat ohodnocení srozumitelnosti formuláře a vyjádření, jak dobře splňuje svůj cíl. Analytik by měl zvláště hledat dvojznačnost (například v záhlaví sloupců, která nesprávně označují data zapsaná v prvcích). Obsah a počet dokumentů je také velmi významný. Nový systém musí být schopen se vyrovnat s množstvím dat, která jím budou procházet, včetně špiček.
Mezi ně patří především organizační diagramy,administrativní příručky, popisy práce a specifikace pracovních zařazení, výukové materiály, prodejní a reklamní publikace
2. Dotazníky
3. Interview a rozhovor
4. Pozorování
Pozorování systému při normální činnosti odhalí mnoho charakteristických rysů prostředí, které nemusí být zpočátku považovány za závažné.
5. Anketa
6. Kontrolní lístky (empirická data)
Analýza firemních dokumentů a firemní dokumentace
Informace o firmě mohou být v následujících podobách tzv. podkladových materiálů:
• organizační diagramy
• administrativní příručky
• popisy práce a specifikace pracovních zařazení
• výukové manuály
• prodejní a reklamní dokumentace.
Významným zdrojem informací jsou dokumenty charakteru strategického plánování a výroční zprávy. Čas strávený touto činností závisí na konkrétních okolnostech. Analýza může být časově velmi náročná. Je zde viditelná tendence k získávání příliš mnoha informací, protože tato činnost je pro analytika poměrně bez problémů. Většinou se při této fázi analýzy stráví příliš mnoho času, resp. více, než je úměrné výsledku této analýzy.
Podrobnosti získané o dokumentu jsou zdrojem pro tvorbu datových slovníků, charakteristika dokumentu může obsahovat:
• čas, kdy je datový prvek zapsán
• význam, velikost a formát každého datového prvku
• zdroj každého datového prvku
• použití každého datového prvku
• pořadí vkládání datových prvků.
Analýza dokumentů by měla také zahrnovat ohodnocení srozumitelnosti formuláře a vyjádření, jak dobře splňuje svůj cíl. Analytik by měl zvláště hledat dvojznačnost (například v záhlaví sloupců, která nesprávně označují data zapsaná v prvcích). Obsah a počet dokumentů je také velmi významný. Nový systém musí být schopen se vyrovnat s množstvím dat, která jím budou procházet, včetně špiček.
Personální zajištění řešení
všechny tři strany
• cíle
- strategické – dlouhodobé, určeny kvalitativně
- taktické – kvantitativně
- operativní – nástroj pro kontrolu a koordinaci operativních činností
- dosažení určitého stavu, struktury nebo chování, nějaké vlastnosti (změny vlastnosti)
- u více cílů je nutné stanovit jejich heirarchii
• metody
logické sítě, metody síťové analýzy, grafy typu strom pro dekompozici globálních problémů
- definování systému, jeho identifikace a zobrazení
• obtížný krok
• vazba na formulaci problémů a cílů jejich řešení
• 4 hlavní kroky
- základní rozpoznání objektu a jeho problémové situace (shrnout a uspořádat fakta z analýzy problémové situace a formulace problému)
- simplifikace objektu
• stanovit metody přechodu od reálného objektu k systému
- definice systému
• určení prvků, vazeb a vlastností
- identifikování systému
- analýza systému
• zkoumání chování
• teorie grafů (o vybraných prvcích, zpětné vazby, předchůdci a následovníci)
- syntéza systému
• rekonstrukce nebo projekce
• úprava vymezení systému, úprava ve vazbách mezi prvky, nahrazení prvků nebo systému
• více variantních řešení
modely, testování na těchto modelech
problémy u sociálních systémů
- implementace a realizace
• včleňování řešení do konkrétních podmínek
• někdy může dočasně vést i ke zhoršení
• nutná účast všech tří stran
- interpretace a komunikace řešení problémů
• zpráva nebo projekt pro oponentní řízení
• shrnutí závěrů; časový harmonogram
Problémy systémové analýzy
- kvalita výsledků je více závislá na věcné znalosti řešené problematiky než na použité systémové metodologii
- úspěšnost řešení je závislá na schopnostech řešitelů kombinovat různé poznatky
- nedostatečné předpoklady pro použití nebo nevhodný způsob použití
• kvalita výchozích informací o problému
• sémantické a pravdivostní stránky ekonomické informace
- nedostatečně propracovaná teorie a metody
- problémy implementace
• cíle
- strategické – dlouhodobé, určeny kvalitativně
- taktické – kvantitativně
- operativní – nástroj pro kontrolu a koordinaci operativních činností
- dosažení určitého stavu, struktury nebo chování, nějaké vlastnosti (změny vlastnosti)
- u více cílů je nutné stanovit jejich heirarchii
• metody
logické sítě, metody síťové analýzy, grafy typu strom pro dekompozici globálních problémů
- definování systému, jeho identifikace a zobrazení
• obtížný krok
• vazba na formulaci problémů a cílů jejich řešení
• 4 hlavní kroky
- základní rozpoznání objektu a jeho problémové situace (shrnout a uspořádat fakta z analýzy problémové situace a formulace problému)
- simplifikace objektu
• stanovit metody přechodu od reálného objektu k systému
- definice systému
• určení prvků, vazeb a vlastností
- identifikování systému
- analýza systému
• zkoumání chování
• teorie grafů (o vybraných prvcích, zpětné vazby, předchůdci a následovníci)
- syntéza systému
• rekonstrukce nebo projekce
• úprava vymezení systému, úprava ve vazbách mezi prvky, nahrazení prvků nebo systému
• více variantních řešení
modely, testování na těchto modelech
problémy u sociálních systémů
- implementace a realizace
• včleňování řešení do konkrétních podmínek
• někdy může dočasně vést i ke zhoršení
• nutná účast všech tří stran
- interpretace a komunikace řešení problémů
• zpráva nebo projekt pro oponentní řízení
• shrnutí závěrů; časový harmonogram
Problémy systémové analýzy
- kvalita výsledků je více závislá na věcné znalosti řešené problematiky než na použité systémové metodologii
- úspěšnost řešení je závislá na schopnostech řešitelů kombinovat různé poznatky
- nedostatečné předpoklady pro použití nebo nevhodný způsob použití
• kvalita výchozích informací o problému
• sémantické a pravdivostní stránky ekonomické informace
- nedostatečně propracovaná teorie a metody
- problémy implementace
Systémová analýza
- metodologická aplikační disciplína systémové vědy
- jejím úkolem je přispět ke zvýšení kvality rozhodování o závažných otázkách
• zvýšením úrovně znalostí rozhodovacího subjektu
• vybráním nejúčelnějšího řešení
• testováním efektu/důsledku navrhovaného řešení (modely)
• simulováním efektů různých možných řešení (různé podmínky, různá kritéria)
- předmětem jsou technické, přírodovědné, ekonomické, společenské objekty, jejich vlastnosti, problémy, informační a řídící soustavy takových objektů a procesů a jejich vlastnosti a problémy
Předmět systémové analýzy
- bezprostředně obtížně pozorovatelné, zvládnutelné či řešitelné objekty, procesy, jejich vlastnosti, problémy a jejich informační a řídící systémy, jejich vlastnosti a problémy
- tyto objekty vykazují větší složitost a mají následující systémové vlastnosti
• celistvost objektu
• rozložitelnost na části
• existence vazeb mezi částmi
• interakce celku s okolím
• dynamičnost (cílovost, adaptibilitu, učení se, …)
- problémy těchto celků
• složité, komplikované
• více možných řešení s různými výhodami a nevýhodami
• více řešitelů s různými preferencemi
- postupy systémové analýzy a metodologický aparát jsou ovlivněny
• typem řešeného problému
• povahou objektu
- problémy
• reálný objekt, projekt reálného objektu, proces nebo komplex procesů, problém nebo komplex problémů
• ostré/neostré/mlhavé
- systémová analýza nemůže vycházet z jasně formulovaného problému, ale z existující či očekávané problémové situace – přístup se přizpůsobuje
• této situaci
• času, který je k dispozici
• možnostem řešitelů
• znalostem, schopnostem a zájmům rešitelů
- jejím úkolem je přispět ke zvýšení kvality rozhodování o závažných otázkách
• zvýšením úrovně znalostí rozhodovacího subjektu
• vybráním nejúčelnějšího řešení
• testováním efektu/důsledku navrhovaného řešení (modely)
• simulováním efektů různých možných řešení (různé podmínky, různá kritéria)
- předmětem jsou technické, přírodovědné, ekonomické, společenské objekty, jejich vlastnosti, problémy, informační a řídící soustavy takových objektů a procesů a jejich vlastnosti a problémy
Předmět systémové analýzy
- bezprostředně obtížně pozorovatelné, zvládnutelné či řešitelné objekty, procesy, jejich vlastnosti, problémy a jejich informační a řídící systémy, jejich vlastnosti a problémy
- tyto objekty vykazují větší složitost a mají následující systémové vlastnosti
• celistvost objektu
• rozložitelnost na části
• existence vazeb mezi částmi
• interakce celku s okolím
• dynamičnost (cílovost, adaptibilitu, učení se, …)
- problémy těchto celků
• složité, komplikované
• více možných řešení s různými výhodami a nevýhodami
• více řešitelů s různými preferencemi
- postupy systémové analýzy a metodologický aparát jsou ovlivněny
• typem řešeného problému
• povahou objektu
- problémy
• reálný objekt, projekt reálného objektu, proces nebo komplex procesů, problém nebo komplex problémů
• ostré/neostré/mlhavé
- systémová analýza nemůže vycházet z jasně formulovaného problému, ale z existující či očekávané problémové situace – přístup se přizpůsobuje
• této situaci
• času, který je k dispozici
• možnostem řešitelů
• znalostem, schopnostem a zájmům rešitelů
Základní postupy systémové analýzy
- primární je řešený problém, ostatní je tomu podřízeno (např. metody řešení)
- hlavní etapy
• analýza problémové situace
• formulace problému a cílů jeho řešení
• definování systému, jeho identifikace a zobrazení
• analýza systému
• syntéza systému
• interpretace a komunikace řešení
• implementace a realizace řešení
- navíc (další okolnosti)
• nedostatek znalostí o problému nebo problémové situaci
• nejasné cíle
• nestabilní výchozí podmínky
• různé cíle diferentních zájmových skupin
- analýza problémové situace
• žádný problém není izolovaný, souvisí s jinými
• často více problémů najednou
• kromě problémové situace je žádoucí se pokusit předvídat i její vývoj
• závislá na konkrétních podmínkách (časově krátká)
• používá se interview, brainstorming, práce s experty
- formulace problému a cílů jeho řešení
• formulaci ovlivňují
charakter objektu
důvody, které vyvolaly řešení problému
subjekty, kterých se problém týká (zadavatel, řešitel, uživatel)
cíl, kterého má být dosaženo
zdroje (materál, pracovníci, technická omezení, finance, …)
• formulace ostrých problémů
věcný obsah
cíl
dílčí problémy, dílčí cíle
zdroje
lhůta
uživatel a realizátor
• formulace neostrých a mlhavých problémů
některé chybí
musíme neustále zpřesňovat
hlavní je definovat cíle, motivaci
kvalita potřebné datové báze, naléhavost
• formulace omezení
omezení výsledného řešení a průběhu řešení
• hranice problému
problém s vymezením
okolí systému (politické, ekonomické, ekologické, …) ale jeho hranice se liší
- hlavní etapy
• analýza problémové situace
• formulace problému a cílů jeho řešení
• definování systému, jeho identifikace a zobrazení
• analýza systému
• syntéza systému
• interpretace a komunikace řešení
• implementace a realizace řešení
- navíc (další okolnosti)
• nedostatek znalostí o problému nebo problémové situaci
• nejasné cíle
• nestabilní výchozí podmínky
• různé cíle diferentních zájmových skupin
- analýza problémové situace
• žádný problém není izolovaný, souvisí s jinými
• často více problémů najednou
• kromě problémové situace je žádoucí se pokusit předvídat i její vývoj
• závislá na konkrétních podmínkách (časově krátká)
• používá se interview, brainstorming, práce s experty
- formulace problému a cílů jeho řešení
• formulaci ovlivňují
charakter objektu
důvody, které vyvolaly řešení problému
subjekty, kterých se problém týká (zadavatel, řešitel, uživatel)
cíl, kterého má být dosaženo
zdroje (materál, pracovníci, technická omezení, finance, …)
• formulace ostrých problémů
věcný obsah
cíl
dílčí problémy, dílčí cíle
zdroje
lhůta
uživatel a realizátor
• formulace neostrých a mlhavých problémů
některé chybí
musíme neustále zpřesňovat
hlavní je definovat cíle, motivaci
kvalita potřebné datové báze, naléhavost
• formulace omezení
omezení výsledného řešení a průběhu řešení
• hranice problému
problém s vymezením
okolí systému (politické, ekonomické, ekologické, …) ale jeho hranice se liší
Postup implementace ERP
• při zavadeni ERP produktu se kombinuje modelovani s customizaci a implementaci.
• Součásti ERP produktu jsou business objekty – datové objekty s interní strukturou, které komunikují prostřednictvím volání metod (napr. zákazník, dodavatel)
• Části procesnich řetězců pracuji s business objekty a mohou se konfigurovat do hodnotových řetězců podle pozadavku uzivatele
• Jde o postup zdola nahoru, dany systém se prizpusobi konkrétnímu prostředí
• Pomoci metamodelu (formalizovaný prostředek pro popis modelu podniku (zahrnuje zakladni objekty a vazby mezi nimi)) se vytvori model procedur – zahrnuje plán projektu, jeho fázování a postup implementace a konfigurace systému – konkrétní nastavení parametrů systému podle modelu podniku.
MODELOVÁNÍ CUSTOMIZACE IMPLEMENTACE
referenční model
• spolecne s modelem procedur je zakladnim nastrojem rizeni implementace ERP
• Dává přehled funkčnosti systému, nástroj komunikace mezi resitelem a uživatelem, k identifikaci nedostatků, identifikaci alternativních řešení
postup navigace při použití referenčního modelu = 3 etapy
1) analýza podnikatelské činnosti (sestavi se matice prvky vs. scénáře procesů)
2) konfigurace hodnotových řetězců (organizují se vybrané procesy do logických posloupností)
3) konfigurace komponent procesů (provede se detailnější popis procesů z hodnotových řetězců)
• Součásti ERP produktu jsou business objekty – datové objekty s interní strukturou, které komunikují prostřednictvím volání metod (napr. zákazník, dodavatel)
• Části procesnich řetězců pracuji s business objekty a mohou se konfigurovat do hodnotových řetězců podle pozadavku uzivatele
• Jde o postup zdola nahoru, dany systém se prizpusobi konkrétnímu prostředí
• Pomoci metamodelu (formalizovaný prostředek pro popis modelu podniku (zahrnuje zakladni objekty a vazby mezi nimi)) se vytvori model procedur – zahrnuje plán projektu, jeho fázování a postup implementace a konfigurace systému – konkrétní nastavení parametrů systému podle modelu podniku.
MODELOVÁNÍ CUSTOMIZACE IMPLEMENTACE
referenční model
• spolecne s modelem procedur je zakladnim nastrojem rizeni implementace ERP
• Dává přehled funkčnosti systému, nástroj komunikace mezi resitelem a uživatelem, k identifikaci nedostatků, identifikaci alternativních řešení
postup navigace při použití referenčního modelu = 3 etapy
1) analýza podnikatelské činnosti (sestavi se matice prvky vs. scénáře procesů)
2) konfigurace hodnotových řetězců (organizují se vybrané procesy do logických posloupností)
3) konfigurace komponent procesů (provede se detailnější popis procesů z hodnotových řetězců)
IMPLEMENTACE ERP - používané postupy v současnosti
organizace na úrovni podniků
- při implementaci je na této urovni nutne ucinit základní rozhodnutí – tzn.
1) jaka bude míra centralizace – od toho se odviji které funkce a datove struktury budou centralizovane,
2) určit strategie (scénář implementace) – tu ovlivni rozshlost podniku a zda ma oddelene pracoviště
Scénáře implementace - ovlivněny strukturou společnosti – 3 typy
1) funkční organizace – jelikoz kazda organizační jednotka realizuje jinou funkci je cilem IS integrace různých funkcí lokálních organizačních jednotek (implementace proběhne ve fázích)
2) regionální organizace – organizační jednotky se nachazeji v ruznych lokalitách a zajistuji stejne procesy, cilem implementace IS je finanční konsolidace a výměna agregovaných informačních entit mezi autonomními organizačními jednotkami
3) organizace založená na sektorech – autonomni organizační jednotky zajistuji stejne procesy bez ohledu na to kde jsou umístěny (napr. když se zavody specializuji na ruzne produkty) – cil implmenetace IS je finanční konsolidace a výměna standardizovaných zpráv mezi autonomními organizačními jednotkami realizujícími ucelené procesy bez ohledu na regiony
3 zpusoby řešení
1. centralizované řešení – jedna centrální databáze, závody fungují pouze jako pracoviště;
2. decentralizované řešení – vytvori se obecne standardy které musí splnovat implementace ve všech jednotkách, distribuce funkcí umožňuje integraci propojenych aplikaci a proto je to vhodne reseni pro funkcni organizaci, lokální pilotní řešení a jeho horizontální rozšíření je zase vhodne pro regionální organizaci;
3. heterogenní řešení – jedna se o decentralizované řešení s výměnou dat bez použití standardů, to je vhodne pro sektorovou organizaci;
možnosti implementace modulů
1) velký třesk – zavedení systému najednou k datu, to je velmi kapacitne narocne s velkym rizikem, výhodou je rychlost
2) postupné zavádění – krok za krokem, to je casove narocne a musí se simulovat dosud nezavedene moduly
3) roll-out postup – pilotní instalace ve vybrane spolecnosti následně opakovaný projekt v ostatních společnostech s použitím stejnych nastaveni, výhodou je mensi riziko
- při implementaci je na této urovni nutne ucinit základní rozhodnutí – tzn.
1) jaka bude míra centralizace – od toho se odviji které funkce a datove struktury budou centralizovane,
2) určit strategie (scénář implementace) – tu ovlivni rozshlost podniku a zda ma oddelene pracoviště
Scénáře implementace - ovlivněny strukturou společnosti – 3 typy
1) funkční organizace – jelikoz kazda organizační jednotka realizuje jinou funkci je cilem IS integrace různých funkcí lokálních organizačních jednotek (implementace proběhne ve fázích)
2) regionální organizace – organizační jednotky se nachazeji v ruznych lokalitách a zajistuji stejne procesy, cilem implementace IS je finanční konsolidace a výměna agregovaných informačních entit mezi autonomními organizačními jednotkami
3) organizace založená na sektorech – autonomni organizační jednotky zajistuji stejne procesy bez ohledu na to kde jsou umístěny (napr. když se zavody specializuji na ruzne produkty) – cil implmenetace IS je finanční konsolidace a výměna standardizovaných zpráv mezi autonomními organizačními jednotkami realizujícími ucelené procesy bez ohledu na regiony
3 zpusoby řešení
1. centralizované řešení – jedna centrální databáze, závody fungují pouze jako pracoviště;
2. decentralizované řešení – vytvori se obecne standardy které musí splnovat implementace ve všech jednotkách, distribuce funkcí umožňuje integraci propojenych aplikaci a proto je to vhodne reseni pro funkcni organizaci, lokální pilotní řešení a jeho horizontální rozšíření je zase vhodne pro regionální organizaci;
3. heterogenní řešení – jedna se o decentralizované řešení s výměnou dat bez použití standardů, to je vhodne pro sektorovou organizaci;
možnosti implementace modulů
1) velký třesk – zavedení systému najednou k datu, to je velmi kapacitne narocne s velkym rizikem, výhodou je rychlost
2) postupné zavádění – krok za krokem, to je casove narocne a musí se simulovat dosud nezavedene moduly
3) roll-out postup – pilotní instalace ve vybrane spolecnosti následně opakovaný projekt v ostatních společnostech s použitím stejnych nastaveni, výhodou je mensi riziko
Druhy modelů vytvářených dle klasických a moderních metodik
Modely komponent
• funkční model – zobrazuje hlavni funkce v podniku, vystupem je struktura hlavnich funkci které bude plnit aplikace, touto dekompozici ziskame casti které uz jde relativne nezavisle navrhovat, implementovat a testovat
• organizační model – pomoci nej se priradi zaměstnanci k jednotlivym rolim a stanovi se urovne autorizace
• model dat – zobrazuje entity datových struktur které se pouzivaji
Modely procesů – neexistoval v klasických metodologiích – viz. Svata str. 45
• model komunikace – zobrazuje vazby mezi aplikacemi a organizačními jednotkami
• model toku informací – zobrazuje vazby mezi funkčním a datovym modelem
• procesní model – zobrazuje hlavni a podpurne procesy
Model procedur
• životní cyklus
• pracovní dekompozice
(funkční, procesní a organizační model odpovídají na otázky Co? Jak? Kdo?)
• funkční model – zobrazuje hlavni funkce v podniku, vystupem je struktura hlavnich funkci které bude plnit aplikace, touto dekompozici ziskame casti které uz jde relativne nezavisle navrhovat, implementovat a testovat
• organizační model – pomoci nej se priradi zaměstnanci k jednotlivym rolim a stanovi se urovne autorizace
• model dat – zobrazuje entity datových struktur které se pouzivaji
Modely procesů – neexistoval v klasických metodologiích – viz. Svata str. 45
• model komunikace – zobrazuje vazby mezi aplikacemi a organizačními jednotkami
• model toku informací – zobrazuje vazby mezi funkčním a datovym modelem
• procesní model – zobrazuje hlavni a podpurne procesy
Model procedur
• životní cyklus
• pracovní dekompozice
(funkční, procesní a organizační model odpovídají na otázky Co? Jak? Kdo?)
Vývoj implementace informačních systémů
tradicni životní cyklus projektu – etapy
1) studie proveditelnosti systému
2) studie aplikační oblasti
3) systémová analýza
4) systémový návrh
5) implementace
6) provoz a údržba
Etapy transformace životního cyklu projektů (ERP)
1. etapa transformace
• představuje klasický zivotní cyklus
• nejdřív uzivatel definuje potřeby a cile ty se potom realizuji pomocí oddělených etap s vlastními nástroji, dokumentací apod. (nedostatky mely odstranit CASE nástroje které propojovali některé etapy;
2. etapa transformace
• je charakteristická implementaci standardních softwarových balíků
• BPR pořízení ASW customizace ASW implementace (+ reengineering by mel doprovázet implementaci)
• nevýhodou je ze reengineering a customizaci provadeji zpravidla ruzni resitele a cyklus je zdlouhavy;
3. etapa transformace
• cilem je propojit etapu reengineeringu s etapou konfigurace systému pomoci metainformacnich systemu
• tato etapa by mela nahradit etapu CASE nastrojů
• kombinuje postup zhora dolu (tzn. modelovani) a postup zdola nahoru (tzn. integrace produktu)
• prubeh - pořízení ASW BPR modelování (funkcni, procesni a organizacni model) implementace
1) studie proveditelnosti systému
2) studie aplikační oblasti
3) systémová analýza
4) systémový návrh
5) implementace
6) provoz a údržba
Etapy transformace životního cyklu projektů (ERP)
1. etapa transformace
• představuje klasický zivotní cyklus
• nejdřív uzivatel definuje potřeby a cile ty se potom realizuji pomocí oddělených etap s vlastními nástroji, dokumentací apod. (nedostatky mely odstranit CASE nástroje které propojovali některé etapy;
2. etapa transformace
• je charakteristická implementaci standardních softwarových balíků
• BPR pořízení ASW customizace ASW implementace (+ reengineering by mel doprovázet implementaci)
• nevýhodou je ze reengineering a customizaci provadeji zpravidla ruzni resitele a cyklus je zdlouhavy;
3. etapa transformace
• cilem je propojit etapu reengineeringu s etapou konfigurace systému pomoci metainformacnich systemu
• tato etapa by mela nahradit etapu CASE nastrojů
• kombinuje postup zhora dolu (tzn. modelovani) a postup zdola nahoru (tzn. integrace produktu)
• prubeh - pořízení ASW BPR modelování (funkcni, procesni a organizacni model) implementace
Účelnost
Účelnos (effectivenes) tzn. Umět dělat správné věci (doing the right thing).
Účinnost (efficiency) tzn. Umět tyto správné věci dělat hospodárně (doing the things right). Účinnost uplatnění postupů řešení apliíkace odpovídá na účelnost.
Prioritní je účelnost. Účel má být zajišťován ekonomicky účinně. Účel aplikace je zpravidla dán vymezením jejího cílového postavení tj. obvykle stanovením soustavy cílů.
Účelnost a účinnost fungování manažerských procesů předurčují strategie, struktura IS/IT a další faktory.
S ohledem na její intencionální charakter [Rosický, 2003a] lze také lépe porozumět dvěma stránkám racionality, vymezených Simonem [1979]. Primární aspekt – substantivní racionalita – se týká subjektivní podstaty sledovaných cílů, zatímco procedurální racionalita tvoří (nejen vybírá) aktivity, používané k jejich dosažení.
Substantivní raionalita souvisí s účelností zatímco procedurální s účinností.
Účinnost (efficiency) tzn. Umět tyto správné věci dělat hospodárně (doing the things right). Účinnost uplatnění postupů řešení apliíkace odpovídá na účelnost.
Prioritní je účelnost. Účel má být zajišťován ekonomicky účinně. Účel aplikace je zpravidla dán vymezením jejího cílového postavení tj. obvykle stanovením soustavy cílů.
Účelnost a účinnost fungování manažerských procesů předurčují strategie, struktura IS/IT a další faktory.
S ohledem na její intencionální charakter [Rosický, 2003a] lze také lépe porozumět dvěma stránkám racionality, vymezených Simonem [1979]. Primární aspekt – substantivní racionalita – se týká subjektivní podstaty sledovaných cílů, zatímco procedurální racionalita tvoří (nejen vybírá) aktivity, používané k jejich dosažení.
Substantivní raionalita souvisí s účelností zatímco procedurální s účinností.
Metodologie
Představuj souhrn procedur, technik, nástrojů a dokumentace, který pomáhá tvůrcům při implementaci nového informačního systému. Metodologie se skládá z fází a subfází, které usnadňují výběr technik vhodných pro určitou fázi a rovněž pomáhají při plánování, řízení, kontrole a hodnocení projektů informačních systémů.
Cíle metodologií
1) správné zaznamenání pozadavků na IS
2) poskytovat systematický prehled o postupu práce na projektu
3) udrzovat projekt v přijatelných časových a nákladových limitech
4) vytvořit systém dobře zdokumentovany
5) vytvořit systém který bude uzivatelsky prijemny
Vývoj metodologií
METODOLOGIE CHARAKTERISTIKA PŘÍKLADY
Klasická, tradiční vývojové diagramy, závislé na fyzické struktuře dat metodologie založena na SDLC konceptu
NCC - National Computing Centre ve VB
SDM - System development Methodology - Pandata
Strukturovaná oddělené procesní a datové modely, oddělení fyzické struktury od logické
DFD diagramy, strukturovaný jazyk STRADIS, SSADM, IE Merise
Objektová propojení RAD - Rapid Application Development (DSDM - Dynamic Systems Development Method)
Navigační • integrace dat, metod a procedur
• integrace objektových a procesních přístupů
• integrace všech funkčních oblastí
SAP, BAAN
Cíle metodologií
1) správné zaznamenání pozadavků na IS
2) poskytovat systematický prehled o postupu práce na projektu
3) udrzovat projekt v přijatelných časových a nákladových limitech
4) vytvořit systém dobře zdokumentovany
5) vytvořit systém který bude uzivatelsky prijemny
Vývoj metodologií
METODOLOGIE CHARAKTERISTIKA PŘÍKLADY
Klasická, tradiční vývojové diagramy, závislé na fyzické struktuře dat metodologie založena na SDLC konceptu
NCC - National Computing Centre ve VB
SDM - System development Methodology - Pandata
Strukturovaná oddělené procesní a datové modely, oddělení fyzické struktury od logické
DFD diagramy, strukturovaný jazyk STRADIS, SSADM, IE Merise
Objektová propojení RAD - Rapid Application Development (DSDM - Dynamic Systems Development Method)
Navigační • integrace dat, metod a procedur
• integrace objektových a procesních přístupů
• integrace všech funkčních oblastí
SAP, BAAN
Optimalizační bariéru
- představuje souhrn všech faktorů, které ovlivňují řízení projektu - nasazení jednotlivých nástrojů, návaznost etap apod. Vlastně se jedná o souhrn technických faktorů a faktorů společenských, psychologických a ekonomických.
Na obr. j (Model na obrázku je záměrně převzat v originále z práce [Raut_92]) je znázorněn model životního cyklu projektu, který se skládá ze čtyř kvadrantů, které z pohledu řízení projektu představují určité suboptimální cykly jeho tvorby. Každý z kvadrantů představuje určitou fázi tvorby projektu:
• první kvadrant - fázi určení požadavků na projekt,
• druhý kvadrant - fázi specifikace řešení projektu,
• třetí kvadrant - fázi implementace projektu,
• čtvrtý kvadrant - fázi rutinního provozu, údržby a dalšího rozvoje projektu.
Základním problémem současného vývoj projektů IS je fakt, že lidem, kteří jsou zainteresováni na tvorbě projektů, není dostatečně jasné, že tvorba projektů je primárním problémem dělení (dekompozice) na úlohy, etapy a řízení navigace v nich. Pokud by se tento trend prosadil, bude proces tvorby projektu od samého začátku plánován za účasti profesionálů v tomto oboru, včetně etap návrhu projektu, plánování personálních, časových i finančních zdrojů, používání nástrojů apod. Globální životní cyklus projektu je pro potřeby použití modelu rozdělen do čtyř kvadrantů, které představují lokální suboptimální cykly životního cyklu projektu. Zvýšené investice (pracovní, časové i finanční) v kvadrantu jedna a dvě umožní nejen redukovat rozhodným způsobem i celkové náklady na vývoj projektu, ale ve svém důsledku vedou i k optimálnímu návrhu technického a programového vybavení projektu a jeho dobrému souladu. To je dáno tím, že značné úsilí všech zúčastněných osob na tvorbě projektu je věnováno určení požadavků na projekt a jeho návrhu. O co více času, financí a myšlenek bylo věnováno v úvodních dvou kvadrantech projektu, tím jsou potom redukovány náklady ve všech formách převážně v kvadrantu čtvrtém - při provozu, údržbě a rozvoji fungujícího projektu. Ale především je nutné, abychom se naučili plánovat koordinované nasazení informační technologie, organizace pracovních týmů, nástrojů a lidských zdrojů pro tvorbu projektů.
Dva vstupní body do modelu životního cyklu projektu představují možnosti:
• tvorby nového projektu - bod A,
• úpravy projektu stávajícího při změně podmínek - bod B (slouží i jako výchozí bod pro prototypová řešení).
Oba vstupní body jsou uvedeny na obr. j pod názvem START A a START B.
Na obr. j (Model na obrázku je záměrně převzat v originále z práce [Raut_92]) je znázorněn model životního cyklu projektu, který se skládá ze čtyř kvadrantů, které z pohledu řízení projektu představují určité suboptimální cykly jeho tvorby. Každý z kvadrantů představuje určitou fázi tvorby projektu:
• první kvadrant - fázi určení požadavků na projekt,
• druhý kvadrant - fázi specifikace řešení projektu,
• třetí kvadrant - fázi implementace projektu,
• čtvrtý kvadrant - fázi rutinního provozu, údržby a dalšího rozvoje projektu.
Základním problémem současného vývoj projektů IS je fakt, že lidem, kteří jsou zainteresováni na tvorbě projektů, není dostatečně jasné, že tvorba projektů je primárním problémem dělení (dekompozice) na úlohy, etapy a řízení navigace v nich. Pokud by se tento trend prosadil, bude proces tvorby projektu od samého začátku plánován za účasti profesionálů v tomto oboru, včetně etap návrhu projektu, plánování personálních, časových i finančních zdrojů, používání nástrojů apod. Globální životní cyklus projektu je pro potřeby použití modelu rozdělen do čtyř kvadrantů, které představují lokální suboptimální cykly životního cyklu projektu. Zvýšené investice (pracovní, časové i finanční) v kvadrantu jedna a dvě umožní nejen redukovat rozhodným způsobem i celkové náklady na vývoj projektu, ale ve svém důsledku vedou i k optimálnímu návrhu technického a programového vybavení projektu a jeho dobrému souladu. To je dáno tím, že značné úsilí všech zúčastněných osob na tvorbě projektu je věnováno určení požadavků na projekt a jeho návrhu. O co více času, financí a myšlenek bylo věnováno v úvodních dvou kvadrantech projektu, tím jsou potom redukovány náklady ve všech formách převážně v kvadrantu čtvrtém - při provozu, údržbě a rozvoji fungujícího projektu. Ale především je nutné, abychom se naučili plánovat koordinované nasazení informační technologie, organizace pracovních týmů, nástrojů a lidských zdrojů pro tvorbu projektů.
Dva vstupní body do modelu životního cyklu projektu představují možnosti:
• tvorby nového projektu - bod A,
• úpravy projektu stávajícího při změně podmínek - bod B (slouží i jako výchozí bod pro prototypová řešení).
Oba vstupní body jsou uvedeny na obr. j pod názvem START A a START B.
Model „Optimálního životního cyklu“
Mezi nejnověji navržené modely životního cyklu projektu patří model vyvinutý ve švýcarském federálním institutu technologií. Jeho smyslem je překonat tři bariéry, které stojí v cestě tvůrcům projektů v rychlé a kvalitní tvorbě informačních systémů.
Jsou to bariéry:
• specifikační,
• komunikační,
• optimalizační.
Specifikační bariéra představuje předším nejistotu tvůrce IS nebo jeho části, že uživatel, který má s budoucím systémem pracovat je schopen pregnantně specifikovat svoje požadavky na vyvíjenou část IS tak, aby během samotné realizace projektu nemuselo docházet k její modifikaci. Pro tvůrce IS se stává fatální chybou předpoklad, že uživatel - převážně pracovníci středního a vyššího managementu - je schopen takovéto činnosti. Odstranění chyby je nejlépe možné pomocí formalizované nebo semiformalizované formy zápisu požadavků na tvořený IS.
Komunikační bariéra - je dána odlišným pojetím vzdělání u jednotlivých osob, které jsou zúčastněny na procesu tvorby projektu IS. Pojetím vzdělání zde myslím např. nesoulad mezi chápáním skutečností u osob s technickým vzděláním, odlišnou terminologií, které používají osoby pracující s projektem IS (uživatel, tvůrce projektu, správce apod.). Tuto bariéru prohlubuje i používání úzce specializované odborné terminologie až žargonu příslušných oborů nebo profesí.
Jsou to bariéry:
• specifikační,
• komunikační,
• optimalizační.
Specifikační bariéra představuje předším nejistotu tvůrce IS nebo jeho části, že uživatel, který má s budoucím systémem pracovat je schopen pregnantně specifikovat svoje požadavky na vyvíjenou část IS tak, aby během samotné realizace projektu nemuselo docházet k její modifikaci. Pro tvůrce IS se stává fatální chybou předpoklad, že uživatel - převážně pracovníci středního a vyššího managementu - je schopen takovéto činnosti. Odstranění chyby je nejlépe možné pomocí formalizované nebo semiformalizované formy zápisu požadavků na tvořený IS.
Komunikační bariéra - je dána odlišným pojetím vzdělání u jednotlivých osob, které jsou zúčastněny na procesu tvorby projektu IS. Pojetím vzdělání zde myslím např. nesoulad mezi chápáním skutečností u osob s technickým vzděláním, odlišnou terminologií, které používají osoby pracující s projektem IS (uživatel, tvůrce projektu, správce apod.). Tuto bariéru prohlubuje i používání úzce specializované odborné terminologie až žargonu příslušných oborů nebo profesí.
Jiné modely
Samozřejmě, že výše uvedenými modely není jejich výčet úplný. V různých podmínkách a firmách se vyvíjejí další a další modely životního cyklu projektu. Jejich cílem je především zdůraznit specifika použití toho kterého modelu vzhledem k použitým informačním technologiím jako např. modelu fontánového - obr. i, nebo se jedná o modely životního cyklu, které hledají optimální řešení (de facto minimalizaci nákladů na tvorbu při maximálním užitku) jak pro uživatele, tak i pro řešitele projektu (např. model „Optimálního životního cyklu projektu“- obr. j).
Fontánový model
Fontánový model vychází v zásadě z podobných přístupů jako model vodopádový. Základní podmínky jejich aplikovatelnosti jsou obdobné. Jsou to:
• žádné jiné pořadí vykonávání etap životního cyklu projektu nepřinese lepší výsledky,
• etapa životního cyklu projektu je nejprve ukončena a teprve potom je zahájena etapa další
Model uvedený na obr. i je převzat z publikace [Sch_93]. Aby nedošlo ke zkreslení nebo záměně pojmů, je záměrně obrázek modelu převzat z originálu.
Model je typický pro tvorbu projektu informačního systému při dekompozici celého projektu na menší celky, které jsou vyvíjeny paralelně a nakonec jsou zkompletovány do jednoho celku. Charakterem přístupu podporuje model i tendence využívání firemních knihoven hotových modulů určitých aplikací. Výsledkem práce na jednotlivých „fontánách“ jsou hotové moduly, které jsou uloženy do firemní knihovny a odtud jsou vybírány pro kompletaci celého projektu. Typickou informační technologií, která se dnes pro takové druhy projektů užívá, jsou přístupy objektového programování.
Fontánový model
Fontánový model vychází v zásadě z podobných přístupů jako model vodopádový. Základní podmínky jejich aplikovatelnosti jsou obdobné. Jsou to:
• žádné jiné pořadí vykonávání etap životního cyklu projektu nepřinese lepší výsledky,
• etapa životního cyklu projektu je nejprve ukončena a teprve potom je zahájena etapa další
Model uvedený na obr. i je převzat z publikace [Sch_93]. Aby nedošlo ke zkreslení nebo záměně pojmů, je záměrně obrázek modelu převzat z originálu.
Model je typický pro tvorbu projektu informačního systému při dekompozici celého projektu na menší celky, které jsou vyvíjeny paralelně a nakonec jsou zkompletovány do jednoho celku. Charakterem přístupu podporuje model i tendence využívání firemních knihoven hotových modulů určitých aplikací. Výsledkem práce na jednotlivých „fontánách“ jsou hotové moduly, které jsou uloženy do firemní knihovny a odtud jsou vybírány pro kompletaci celého projektu. Typickou informační technologií, která se dnes pro takové druhy projektů užívá, jsou přístupy objektového programování.
Síťový model
Síťový model [Chr_92a] reprezentuje ukázku industriálního přístupu k tvorbě projektů IS. Velké firmy, které se zabývají tvorbou informačních systémů, si na základě postupů při tvorbě minulých projektů postupně vytvářejí síť na sebe navazujících činností (aktivit) a jejich výsledků. Vazby mezi aktivitami a výsledky pak představují síťový model postupu prací na projektu. V praxi je síťový model používán ve více stupních [Dou_92a]. Prvním stupněm soustavy síťových modelů je typový model chování firmy při práci na projektu. Tato úroveň obsahuje pro všechny projekty vlastně obecně platný návod -typový síťový model (TM), jak se chovat při jejich realizaci.
Tento obecně platný typový model je podle potřeb konkrétního projektu A upraven na typový model projektu A, kde všechny aktivity výsledky TMA musí být součástí TM. Pokud není tato podmínka splněna, je nutno modifikovat obecně platný typový model pomocí zpětné vazby a jedná se vlastně o postupné zdokonalování obecně platného síťového modelu. Vlastní typový model pro projekt A (TMA) však sám o sobě také není definitivní, neboť v závislosti na proměnných externích podmínkách, změnách používaných technologií, metodik a postupně rozšiřujících se znalostech a vědomostech o vyvíjeném projektu A se do určité míry modifikují pohledy na první iteraci konkrétního rozpracování síťového modelu projektu A (TMA1). Pomocí tohoto přístupu je možné zajistit velice kvalitní řízení tvorby projektu v závislosti na externích i interních faktorech. Podrobněji se této problematice věnuji v kapitole 2. Ještě podrobněji je problematiky rozvedena v publikacích [Dou_93], [Dou_95c].
Ekonomicky je rozdělení nákladů a rizik opět dále posunuto ve prospěch zadavatele. Ten se v těchto podmínkách stává vlastně jen odběratelem již hotového výrobku - informačního systému - a dodavatel provádí nastavení parametrů hotových IS potřebám zákazníka.
Náklady na vývoj IS jsou rozpouštěny částečně do všech projektů, které firma realizuje bez ohledu na to, o jaké projekty se jedná. Jsou to především ty náklady, které se týkají sestavení, aktualizace a provozu obecně platného typového síťového modelu.
Pro potřeby řízení skutečných projektů tvorby IS a vzhledem k rozličnému využívání různých modelů pro různé úrovně řízení projektů (podrobněji je tato problematika rozpracována v kapitole 2.4.), je nezbytné mít k dispozici transformaci zvolených modelů mezi sebou. Jedná se speciálně o model síťový a jeho transformaci do modelu vodopádového.
Tento obecně platný typový model je podle potřeb konkrétního projektu A upraven na typový model projektu A, kde všechny aktivity výsledky TMA musí být součástí TM. Pokud není tato podmínka splněna, je nutno modifikovat obecně platný typový model pomocí zpětné vazby a jedná se vlastně o postupné zdokonalování obecně platného síťového modelu. Vlastní typový model pro projekt A (TMA) však sám o sobě také není definitivní, neboť v závislosti na proměnných externích podmínkách, změnách používaných technologií, metodik a postupně rozšiřujících se znalostech a vědomostech o vyvíjeném projektu A se do určité míry modifikují pohledy na první iteraci konkrétního rozpracování síťového modelu projektu A (TMA1). Pomocí tohoto přístupu je možné zajistit velice kvalitní řízení tvorby projektu v závislosti na externích i interních faktorech. Podrobněji se této problematice věnuji v kapitole 2. Ještě podrobněji je problematiky rozvedena v publikacích [Dou_93], [Dou_95c].
Ekonomicky je rozdělení nákladů a rizik opět dále posunuto ve prospěch zadavatele. Ten se v těchto podmínkách stává vlastně jen odběratelem již hotového výrobku - informačního systému - a dodavatel provádí nastavení parametrů hotových IS potřebám zákazníka.
Náklady na vývoj IS jsou rozpouštěny částečně do všech projektů, které firma realizuje bez ohledu na to, o jaké projekty se jedná. Jsou to především ty náklady, které se týkají sestavení, aktualizace a provozu obecně platného typového síťového modelu.
Pro potřeby řízení skutečných projektů tvorby IS a vzhledem k rozličnému využívání různých modelů pro různé úrovně řízení projektů (podrobněji je tato problematika rozpracována v kapitole 2.4.), je nezbytné mít k dispozici transformaci zvolených modelů mezi sebou. Jedná se speciálně o model síťový a jeho transformaci do modelu vodopádového.
Spirálový model
Spirálový model [Hum_89] patří k modelům, které jsou pevně svázány s metodou „Prototypingu“. Charakteristickým rysem na trhu vývojových prací je mírná převaha nabídky nad poptávkou a smyslem projektů tvořených pomocí spirálového modelu je schopnost řešitele vytipovat oblast vhodnou pro automatizaci, kde existuje latentní poptávka po informačním systému. V souladu s tímto záměrem pak řešitel provede na vlastní náklady analýzu příslušné problematiky a na jejím základě sestaví prototyp informačního systému. V praxi při prvním pokusu o prototyp se spíš jedná o jádro informačního systému. S tímto prototypem pak přijde na trh a na základě možných reakcí trhu prototyp:
• prodává a implementuje,
• dále pracuje na rozvoji prototypu ve formě nových verzí.
Případně kombinuje oba tyto přístupy.
Podíl na rozdělení nákladů mezi řešitelem a zadavatelem se podstatně mění, neboť sám řešitel vlastně vyvíjí první verzi informačního systému na vlastní náklady a zadavatel platí za tento odzkoušený prototyp pouze část skutečné vývojové ceny, protože řešitel předpokládá, že svůj prototyp prodá vícekrát. K úhradě zadavatele jsou vlastně pouze ty funkce a části IS, které nebyly součástí prototypu. Ovšem i tyto nehotové části jsou ještě z pohledu řešení dvojího typu:
• části, které jsou základním nedostatkem prototypu a které do něj musí řešitel stejně dokomponovat a bude je v dalších verzích prototypu standardně dodávat,
• části, které jsou speciální na přání zákazníka, které nemůže řešitel opakovaně použít.
Rozdělení nákladů mezi zadavatele a řešitele
Finanční strategie řešitele může být v takových situacích různá, ale obvykle za znovupoužitelné části - de facto nedodělky vlastní předešlé analýzy - účtuje řešitel podstatně nižší náklady než za části, které jsou evidentně použitelné pouze pro konkrétního zadavatele. Na základě zkušeností z mnohých implementací prototypu se prototyp neustále zlepšuje a zahrnuje více a více funkcí, které komplexněji pokrývají řešenou problematiku a výsledná cena IS je ve srovnání s poskytovanou užitnou hodnotou informačního systému vlastně relativně nižší.
Typickým příkladem modelového přístupu pro tvorbu aplikací je použití modelového přístupu pro tvorbu EIS aplikaci. V současné době se pro tvorbu EIS aplikací používá kombinace modelů vodopádového a spirálového. První zakázky se většinou provádějí na bázi vodopádového modelu a na základě z nich získaných zkušeností vyvíjí firma první pokusné prototypy, které zpočátku uvádí jako částečná řešení a které postupně transformuje do formy skutečného prototypu.
Pro samotný proces tvorby se používá modelu síťového a pro vyjádření vztahu mezi prvky síťového modelu formy modelu kaskádního.
• prodává a implementuje,
• dále pracuje na rozvoji prototypu ve formě nových verzí.
Případně kombinuje oba tyto přístupy.
Podíl na rozdělení nákladů mezi řešitelem a zadavatelem se podstatně mění, neboť sám řešitel vlastně vyvíjí první verzi informačního systému na vlastní náklady a zadavatel platí za tento odzkoušený prototyp pouze část skutečné vývojové ceny, protože řešitel předpokládá, že svůj prototyp prodá vícekrát. K úhradě zadavatele jsou vlastně pouze ty funkce a části IS, které nebyly součástí prototypu. Ovšem i tyto nehotové části jsou ještě z pohledu řešení dvojího typu:
• části, které jsou základním nedostatkem prototypu a které do něj musí řešitel stejně dokomponovat a bude je v dalších verzích prototypu standardně dodávat,
• části, které jsou speciální na přání zákazníka, které nemůže řešitel opakovaně použít.
Rozdělení nákladů mezi zadavatele a řešitele
Finanční strategie řešitele může být v takových situacích různá, ale obvykle za znovupoužitelné části - de facto nedodělky vlastní předešlé analýzy - účtuje řešitel podstatně nižší náklady než za části, které jsou evidentně použitelné pouze pro konkrétního zadavatele. Na základě zkušeností z mnohých implementací prototypu se prototyp neustále zlepšuje a zahrnuje více a více funkcí, které komplexněji pokrývají řešenou problematiku a výsledná cena IS je ve srovnání s poskytovanou užitnou hodnotou informačního systému vlastně relativně nižší.
Typickým příkladem modelového přístupu pro tvorbu aplikací je použití modelového přístupu pro tvorbu EIS aplikaci. V současné době se pro tvorbu EIS aplikací používá kombinace modelů vodopádového a spirálového. První zakázky se většinou provádějí na bázi vodopádového modelu a na základě z nich získaných zkušeností vyvíjí firma první pokusné prototypy, které zpočátku uvádí jako částečná řešení a které postupně transformuje do formy skutečného prototypu.
Pro samotný proces tvorby se používá modelu síťového a pro vyjádření vztahu mezi prvky síťového modelu formy modelu kaskádního.
Konceptuální x operativní modely
Modely vyvinuté v dobách klasického období, se vyznačují spíše obecným konceptuálním charakterem ,který obsahuje globání popis ideového přístupu k projektu, zatímco modely posledních let odrážejí spíš snahu o perfekcionismus v oblasti detailního zpracování a tím i řízení projektu IS/ICT, Proto se dřívější modely životního cyklu projektu používají dodnes, ale nikoliv pro operativní řízení projekčních prací, ale především pro taktické a strategické řízení projektů. Představují totiž větší abstrakci pohledu na konkrétní projekt IS/ICT. Pro operativní řízení jsou využívány modely, které jsou bezprostčředně podporovány účinnými nástroji IT (např. nástroje typu CASE a různé nástroje pro automatizovanou podporu řízení projekčních prací, jako např. MS Project).
Konceptuální – vodopádový, spirálový, síťový
Typy modelů
Vodopádový model
Vodopádový model životního cyklu projektu [Boeh_76] informačního systému patří mezi modely nejstarší, jeho pojetí vychází de facto z tržní situace, kdy poptávka na trhu projekčních prací převyšuje nabídku a kdy vlastně každý projekt informačního systému se stává jedinečným uměleckým dílem na zakázku. Tento přístup samozřejmě nevyhovuje průmyslovému chápání tvorby projektů informačních systémů.
Obr. A Vodopádový model životního cyklu projektu
Ekonomické vztahy mezi řešitelem (tvůrcem IS) a jeho zadavatelem (zde uvažuji o tom, že zadavatel se stává zároveň i investorem celého projektu), lze shrnout takto:
Zadavatel hradí veškeré finanční náklady na tvorbu projektu informačního systému - od etapy analýzy požadavků až po jeho rutinní provoz a údržbu. Podíl na krytí nákladů na projekt a tím i míra rizika úspěšnosti projektu leží plně na bedrech zadavatele.
Na řešitele zbývají vlastně náklady pouze na základní vyškolení vlastních zaměstnanců a získání základních informačních technologií - obr. d.
Obr. B Rozdělení nákladů mezi zadavatele a řešitele
V současné době je možné tento přístup vidět pouze u speciálních projektů na zakázku, kterými jsou dnes i do značné míry projekty informačních systémů typu EIS. Typický je také tento přístup u firem, které se snaží nově na trh EIS aplikací proniknout, neboť přestože mají vyškolené odborníky v oblasti vývojového prostředí, potřebují svou první zakázku, na níž by získané znalosti využily. I v tomto případě se ale vybrané části informačního systému (moduly) převádějí do firemní knihovny hotových procedur k případnému opětovnému použití
Konceptuální – vodopádový, spirálový, síťový
Typy modelů
Vodopádový model
Vodopádový model životního cyklu projektu [Boeh_76] informačního systému patří mezi modely nejstarší, jeho pojetí vychází de facto z tržní situace, kdy poptávka na trhu projekčních prací převyšuje nabídku a kdy vlastně každý projekt informačního systému se stává jedinečným uměleckým dílem na zakázku. Tento přístup samozřejmě nevyhovuje průmyslovému chápání tvorby projektů informačních systémů.
Obr. A Vodopádový model životního cyklu projektu
Ekonomické vztahy mezi řešitelem (tvůrcem IS) a jeho zadavatelem (zde uvažuji o tom, že zadavatel se stává zároveň i investorem celého projektu), lze shrnout takto:
Zadavatel hradí veškeré finanční náklady na tvorbu projektu informačního systému - od etapy analýzy požadavků až po jeho rutinní provoz a údržbu. Podíl na krytí nákladů na projekt a tím i míra rizika úspěšnosti projektu leží plně na bedrech zadavatele.
Na řešitele zbývají vlastně náklady pouze na základní vyškolení vlastních zaměstnanců a získání základních informačních technologií - obr. d.
Obr. B Rozdělení nákladů mezi zadavatele a řešitele
V současné době je možné tento přístup vidět pouze u speciálních projektů na zakázku, kterými jsou dnes i do značné míry projekty informačních systémů typu EIS. Typický je také tento přístup u firem, které se snaží nově na trh EIS aplikací proniknout, neboť přestože mají vyškolené odborníky v oblasti vývojového prostředí, potřebují svou první zakázku, na níž by získané znalosti využily. I v tomto případě se ale vybrané části informačního systému (moduly) převádějí do firemní knihovny hotových procedur k případnému opětovnému použití
Pojetí modelu
Existuje několik různých pojetí modelu, všechna se však shodují v tom, že model je účelově zjednodušené zobrazení nějakého reálného nebo abstraktního objektu.
Modely fungují na několika různých úrovních:
• Jsou prostředkem komunikace
• Jsou nástrojem zachycení podstaty problému a mohou být tak převedeny do jiné formy bez ztráty detailu
• Model je rychlý a univerzální prostředek umožňující porozumět danému problému
Modely mohou být:
• Verbální
• Analytické nebo matematické
• Schématické, obrázkové
• Simulační
Úloha modelování v managementu
V managementu a ekonomii nahrazují experimenty na modelech experimenty laboratorní. S ekonomickými objekty nemůžeme obvykle manipulovat a experimentovat v reálném prostředí. Proto místo na objektech provádíme toto experimentování na modelech, které zobrazují některé vlastnosti studovaných soustav. Modely nám tedy umožňují vyzkoušet si možné situace a jejich dopady na modelu, který popisuje naší situaci.
Úloha modelování v analýze a navrhování systému
Modelování pomáhá s popsáním reality hlavně v těchto dvou počátčních fázích, které jsou obecnější. Umožňuje simulaci budoucího chování systému
Modely fungují na několika různých úrovních:
• Jsou prostředkem komunikace
• Jsou nástrojem zachycení podstaty problému a mohou být tak převedeny do jiné formy bez ztráty detailu
• Model je rychlý a univerzální prostředek umožňující porozumět danému problému
Modely mohou být:
• Verbální
• Analytické nebo matematické
• Schématické, obrázkové
• Simulační
Úloha modelování v managementu
V managementu a ekonomii nahrazují experimenty na modelech experimenty laboratorní. S ekonomickými objekty nemůžeme obvykle manipulovat a experimentovat v reálném prostředí. Proto místo na objektech provádíme toto experimentování na modelech, které zobrazují některé vlastnosti studovaných soustav. Modely nám tedy umožňují vyzkoušet si možné situace a jejich dopady na modelu, který popisuje naší situaci.
Úloha modelování v analýze a navrhování systému
Modelování pomáhá s popsáním reality hlavně v těchto dvou počátčních fázích, které jsou obecnější. Umožňuje simulaci budoucího chování systému
Podstata
- řešení rozporu mezi dynamikou vědy a setrvačností praxe, profesionální náplň = znalost prostředků a metod k navrhování a projektování provozu a racionalizaci systému.
- i název vědní disciplíny, která se zabývá úpravou existujících či navrhovaných nových systémů schopných plnit úkol s minimálními náklady, převládá technický charakter SI
Reálné syssst., kterými se SI zabývá:
• • jsou umělé
• • mají integritu (komponenty - cíl)
• • složité a rozlehlé
• • značná interdependence
• • automatizovvané
• • postupy stochastické
• • v kompletním prostředí
Při projektování tato hlediska: výkonost, spolehlivost, náklady
prvky = počítače, jejich začlenění do systému - vážný úkol SA
Projektování složitých systémů dvě fáze:
1) makroprojektování - strujtury a jejich chování
2) mikroprojektování - prvků nebo subsystémů
- i název vědní disciplíny, která se zabývá úpravou existujících či navrhovaných nových systémů schopných plnit úkol s minimálními náklady, převládá technický charakter SI
Reálné syssst., kterými se SI zabývá:
• • jsou umělé
• • mají integritu (komponenty - cíl)
• • složité a rozlehlé
• • značná interdependence
• • automatizovvané
• • postupy stochastické
• • v kompletním prostředí
Při projektování tato hlediska: výkonost, spolehlivost, náklady
prvky = počítače, jejich začlenění do systému - vážný úkol SA
Projektování složitých systémů dvě fáze:
1) makroprojektování - strujtury a jejich chování
2) mikroprojektování - prvků nebo subsystémů
Metodologie měkkých systémů
Pojem metodologie měkkých systémů vznikl a stává se populární úměrně snahám analytiků a systémových inženýrů ovládnout nebo alespoň ovlivnit chování sociálních a sociálně technický systémů. V takových případech se formalizované metody ukazovali jako neadekvátní povaze problémů, jejich pestrobarevnosti. Formalizované metody jsou používány k řešení dílčích problémů, zatímco strategie celkového řešení pod vlivem metodologie měkkých systémů. Existují dva přístupy:
Akční přístup – (Jenkins)
Předchází Cheklendově metodologie a Chekland na ní později navázal. Tato metodologie zahrnuje čtyři základní fáze:
1. Analýzu systému
2. Systémový projekt
3. Implementaci
4. Provoz systému
Sys. je složité seskupení lidí a strojů , vhodné dekomponovat na subsystémy, výstupy jednoho subsys. jsou vtupy druhého subsys. - nelze studovat odděleně - ovlivňují se, existuje i vertikální členění, sys. má cíle chování - mohou být komfliktní - účelová fce
Jenkinsovu metodologii charakteriyují tato strategická pravidla:
• soubor cílú je zjišťován dotazováním a oceňováním, podle celé řady hledisek,
• konfliktnost cílů - uplatnění váhových faktorů nebo omezení na určité proměnné
• budování modelu iterační adaptibilní
• konečná správa - diskutovat s vedoucími pracovníky
Pojem metodologie měkkých systémů vznikl a stává se populární úměrně snahám analytiků a systémových inženýrů ovládnout nebo alespoň ovlivnit chování sociálních a sociálně technický systémů. V takových případech se formalizované metody ukazovali jako neadekvátní povaze problémů, jejich pestrobarevnosti. Formalizované metody jsou používány k řešení dílčích problémů, zatímco strategie celkového řešení pod vlivem metodologie měkkých systémů. Existují dva přístupy:
Akční přístup – (Jenkins)
Předchází Cheklendově metodologie a Chekland na ní později navázal. Tato metodologie zahrnuje čtyři základní fáze:
1. Analýzu systému
2. Systémový projekt
3. Implementaci
4. Provoz systému
Sys. je složité seskupení lidí a strojů , vhodné dekomponovat na subsystémy, výstupy jednoho subsys. jsou vtupy druhého subsys. - nelze studovat odděleně - ovlivňují se, existuje i vertikální členění, sys. má cíle chování - mohou být komfliktní - účelová fce
Jenkinsovu metodologii charakteriyují tato strategická pravidla:
• soubor cílú je zjišťován dotazováním a oceňováním, podle celé řady hledisek,
• konfliktnost cílů - uplatnění váhových faktorů nebo omezení na určité proměnné
• budování modelu iterační adaptibilní
• konečná správa - diskutovat s vedoucími pracovníky
Checklendova metodologie měkkých systémů
existuje celá řada pohledů na věc, 7 fází metodologie, je velmi vhodná pro popis postupu, ale nemusí se přesně podle ní postupovat, je potřeba se vracet a postupovat iterativně, fáze jen rámec ne recept, simultativní práce na všech etapách : 1 2) nestrukturované problémové situace - vyjádření problémové situace - získání reprezentace problémové situace v neutrální podobě - rich pictures
3) základní definice relevantních sys. - má odrážet aspekty - CHTWOE - customer, actor kdo má provádět, jaké vstupy na jaké výstupy, kdo může sys zničit, prostředí atd
4) základní tvůrčí příspěvek - vytvoření vlastní koncepce problému, návrh konkrétních kroků
5) porovnání se skutečností - doporučení ke změnám
6 7) vybrání žádoucích a proveditelných změn
základ - systémové zobrazení problému, definice sys. CATWOF, vytvoření konkrétního modelu, návrhy a přijetí změn
Další model NIMSAD - ověřen pro metodologie, - analýza strukt. techn. měkkých sys.,
Akční přístup – (Jenkins)
Předchází Cheklendově metodologie a Chekland na ní později navázal. Tato metodologie zahrnuje čtyři základní fáze:
1. Analýzu systému
2. Systémový projekt
3. Implementaci
4. Provoz systému
Sys. je složité seskupení lidí a strojů , vhodné dekomponovat na subsystémy, výstupy jednoho subsys. jsou vtupy druhého subsys. - nelze studovat odděleně - ovlivňují se, existuje i vertikální členění, sys. má cíle chování - mohou být komfliktní - účelová fce
Jenkinsovu metodologii charakteriyují tato strategická pravidla:
• soubor cílú je zjišťován dotazováním a oceňováním, podle celé řady hledisek,
• konfliktnost cílů - uplatnění váhových faktorů nebo omezení na určité proměnné
• budování modelu iterační adaptibilní
• konečná správa - diskutovat s vedoucími pracovníky
Pojem metodologie měkkých systémů vznikl a stává se populární úměrně snahám analytiků a systémových inženýrů ovládnout nebo alespoň ovlivnit chování sociálních a sociálně technický systémů. V takových případech se formalizované metody ukazovali jako neadekvátní povaze problémů, jejich pestrobarevnosti. Formalizované metody jsou používány k řešení dílčích problémů, zatímco strategie celkového řešení pod vlivem metodologie měkkých systémů. Existují dva přístupy:
Akční přístup – (Jenkins)
Předchází Cheklendově metodologie a Chekland na ní později navázal. Tato metodologie zahrnuje čtyři základní fáze:
1. Analýzu systému
2. Systémový projekt
3. Implementaci
4. Provoz systému
Sys. je složité seskupení lidí a strojů , vhodné dekomponovat na subsystémy, výstupy jednoho subsys. jsou vtupy druhého subsys. - nelze studovat odděleně - ovlivňují se, existuje i vertikální členění, sys. má cíle chování - mohou být komfliktní - účelová fce
Jenkinsovu metodologii charakteriyují tato strategická pravidla:
• soubor cílú je zjišťován dotazováním a oceňováním, podle celé řady hledisek,
• konfliktnost cílů - uplatnění váhových faktorů nebo omezení na určité proměnné
• budování modelu iterační adaptibilní
• konečná správa - diskutovat s vedoucími pracovníky
Checklendova metodologie měkkých systémů
existuje celá řada pohledů na věc, 7 fází metodologie, je velmi vhodná pro popis postupu, ale nemusí se přesně podle ní postupovat, je potřeba se vracet a postupovat iterativně, fáze jen rámec ne recept, simultativní práce na všech etapách : 1 2) nestrukturované problémové situace - vyjádření problémové situace - získání reprezentace problémové situace v neutrální podobě - rich pictures
3) základní definice relevantních sys. - má odrážet aspekty - CHTWOE - customer, actor kdo má provádět, jaké vstupy na jaké výstupy, kdo může sys zničit, prostředí atd
4) základní tvůrčí příspěvek - vytvoření vlastní koncepce problému, návrh konkrétních kroků
5) porovnání se skutečností - doporučení ke změnám
6 7) vybrání žádoucích a proveditelných změn
základ - systémové zobrazení problému, definice sys. CATWOF, vytvoření konkrétního modelu, návrhy a přijetí změn
Další model NIMSAD - ověřen pro metodologie, - analýza strukt. techn. měkkých sys.,
Měkké systémy – přístupy
Základní myšlenky měkkého systémového myšlení jsou tyto:
• Systémy ve kterých figuruje člověk, je možné dostatečně přesně popsat jen tehdy, pokud je vztáhneme k určitým sociálním, kulturním, historickým, politickým atd. vlastnostem světového názoru.
• Svět je problematický a proto je systémovost v procesech zkoumání reality a nikoliv v realitě samé
Systémové inženýrství
- určitý druh lidské činnosti
- soubor uspořádaných poznatků o tomto oboru lidské činnosti
- nástup VTR - roste složitost celé společnosti - složité soustavy (mnoho prvků a vazeb) - např. velké dopravní soustavy, systém automatického zabezpečení a řešení železnic atd. Každá složitá soustava se označuje především vyhraněnou celistvostí - jde o to, aby jako celek dokázala správně reagovat na podněty z okolí. Pro velké soustavy - jsou automatizované - je potřeba si vyjasnit vztah stroje a objektu (musí vyhovovat člověku)
- nákladnost vývoje a časová náročnost - optimalizace už v procesu tvorby (funkční a provozní schopnosti, požadavky, obsluha, životnost, spolehlivost)
- nové poznatky, metody - nová disciplína - vědecké inženýrství. Založeno na týmové práci odborníků s širokým rozhledem. Vychází z principů inženýrství: pararelizace a měřitelnost jevů, standartizace a typizace prvků, přenositelnost
- velké projekty - spolupráce celých týmů - skupina vědců a inženýrů
- pro pracovníky, kteří se nabývají celosystémovými záležitostmi = systémový inženýr - metody syst. inženýrství - syst. projektování (první BELL USA) budování tel.systémů -technický problém (ostrý) - postupné rozšíření i na systémy s lidmi - neostré (mlhavé) problémy, u nás úloha SI mnohem širší
SI - kvalifikovaná tvůrčí činnost zaměřená na vytvoření účelově orientovvaných systémů (podle výsledku výzkumu, požadavky uživatele)
• Systémy ve kterých figuruje člověk, je možné dostatečně přesně popsat jen tehdy, pokud je vztáhneme k určitým sociálním, kulturním, historickým, politickým atd. vlastnostem světového názoru.
• Svět je problematický a proto je systémovost v procesech zkoumání reality a nikoliv v realitě samé
Systémové inženýrství
- určitý druh lidské činnosti
- soubor uspořádaných poznatků o tomto oboru lidské činnosti
- nástup VTR - roste složitost celé společnosti - složité soustavy (mnoho prvků a vazeb) - např. velké dopravní soustavy, systém automatického zabezpečení a řešení železnic atd. Každá složitá soustava se označuje především vyhraněnou celistvostí - jde o to, aby jako celek dokázala správně reagovat na podněty z okolí. Pro velké soustavy - jsou automatizované - je potřeba si vyjasnit vztah stroje a objektu (musí vyhovovat člověku)
- nákladnost vývoje a časová náročnost - optimalizace už v procesu tvorby (funkční a provozní schopnosti, požadavky, obsluha, životnost, spolehlivost)
- nové poznatky, metody - nová disciplína - vědecké inženýrství. Založeno na týmové práci odborníků s širokým rozhledem. Vychází z principů inženýrství: pararelizace a měřitelnost jevů, standartizace a typizace prvků, přenositelnost
- velké projekty - spolupráce celých týmů - skupina vědců a inženýrů
- pro pracovníky, kteří se nabývají celosystémovými záležitostmi = systémový inženýr - metody syst. inženýrství - syst. projektování (první BELL USA) budování tel.systémů -technický problém (ostrý) - postupné rozšíření i na systémy s lidmi - neostré (mlhavé) problémy, u nás úloha SI mnohem širší
SI - kvalifikovaná tvůrčí činnost zaměřená na vytvoření účelově orientovvaných systémů (podle výsledku výzkumu, požadavky uživatele)
Globální úroveň
Důraz na globální úroveň souvisí i s potřebou neautomatizovat pouze stávající stav tj. nekonzervovat stávající způsob řízení. V konkrétní rovině to znamená přenesení nebo nepřenesení algoritmizovatelných činností na prostředky výpočetní techniky. Tvorba informačního systému rozhodně nespočívá pouze v „naprogramování" nebo „přeprogramování" stávajícího řešení.
Projektování by mělo být úzce svázáno s úvahou o možné změně - efektivnějším způsobu řízení. Impulsy ke změnám mohou přicházet jak ze strany projektantů tak ze strany uživatelů iniciovaných postupem projekce. Toto je další z argumentů ve prospěch globální koncepce informačních zdrojů - na globální úrovní se projektant pohybuje převážně na vyšší úrovni řízení a dochází tedy k výše uvedené interakci jako základu budoucích změn. Globální úroveň projektování již svojí povahou umožňuje odstínit vrcholové manažery od implementačních problémů, které je nezajímají a ani zajímat nemají a které by je odváděly od řešení podstatných problémů a koncepčních úvah.
Chápání dat jako důležitých informačních zdrojů a preference globálního přístupu k projektování umožňuje i realizaci technologie prototypů a tím volit strategii postupného posunu vpřed s možností cyklických návratů při nutnosti revidovat navržené řešení. Tento postup umožňuje ověřit si v praxi, byť jen na malém výseku reality a na relativně nedokonalém řešení chování uživatele, koncepci dané části řešení a využít těchto zkušeností při dalším postupu resp. iniciovat případné korekce. Kromě jiného přináší i možnost postupného náběhu vědomí informační potřeby, postupné adaptace na nový způsob práce, ale i prohloubení informovanosti projektanta o požadavcích uživatele, které někdy nelze ani při detailní analýze odhalit.
Uživatel, zapojený do projekčních prací, si uvědomuje přítomnost a důležitost informačních zdrojů, což samo o sobě racionalizuje jeho chování ve vztahu k informačnímu systému.
Projektování by mělo být úzce svázáno s úvahou o možné změně - efektivnějším způsobu řízení. Impulsy ke změnám mohou přicházet jak ze strany projektantů tak ze strany uživatelů iniciovaných postupem projekce. Toto je další z argumentů ve prospěch globální koncepce informačních zdrojů - na globální úrovní se projektant pohybuje převážně na vyšší úrovni řízení a dochází tedy k výše uvedené interakci jako základu budoucích změn. Globální úroveň projektování již svojí povahou umožňuje odstínit vrcholové manažery od implementačních problémů, které je nezajímají a ani zajímat nemají a které by je odváděly od řešení podstatných problémů a koncepčních úvah.
Chápání dat jako důležitých informačních zdrojů a preference globálního přístupu k projektování umožňuje i realizaci technologie prototypů a tím volit strategii postupného posunu vpřed s možností cyklických návratů při nutnosti revidovat navržené řešení. Tento postup umožňuje ověřit si v praxi, byť jen na malém výseku reality a na relativně nedokonalém řešení chování uživatele, koncepci dané části řešení a využít těchto zkušeností při dalším postupu resp. iniciovat případné korekce. Kromě jiného přináší i možnost postupného náběhu vědomí informační potřeby, postupné adaptace na nový způsob práce, ale i prohloubení informovanosti projektanta o požadavcích uživatele, které někdy nelze ani při detailní analýze odhalit.
Uživatel, zapojený do projekčních prací, si uvědomuje přítomnost a důležitost informačních zdrojů, což samo o sobě racionalizuje jeho chování ve vztahu k informačnímu systému.
Systémová metodologie
Vznik a vývoj systémových metodologií je úzce spjat s praktickými potřebami, které vznikají při řešení problémů reálného světa. Systémové metodologie jsou průřezové v důsledku využívání analogií. Díky snaze řešit společenskou problematiku si vynucuje i další kvalitu systémových metodologií, kterou můžeme označovat jako humanizaci. Humanizací metodologií rozumíme především reprezentaci a respektování zájmů člověka při formulování úloh i volbě jejich řešení. Tato vlastnost je typická především pro tzv. měkké metodologie.
Podobně jako rozlišujeme systémy tak i metodologie rozlišujeme na měkké a tvrdé. Tvrdé systémové metodologie jsou klasickým nástrojem systémového inženýrství.
Systémové teorie
Ludwig von Bertalanfy, biolog organizmů, navrhl koncem 40. let, že myšlenky o organismech jako celistvých entitách by mohli být zobecněny pro libovolné celky, zvané systémy. Člověk se snaží najít smysl ve vnímané realitě pomocí myšlenkových konceptů(systémů), uplatňovaných v myšlenkových procesech nebo-li metodologiích. Vnímaná realita a koncepty jsou v neustálém kontaktu a interakci a vzájemně na sebe působí.
Tvrdé systémy – přístupy
Analytici sledující tvrdé systémové myšlení vycházejí z předpokladu, že termíny systému existují jako takové a je možné je popsat, měřit, vylepšovat. Tvrdé systémové myšlení je založeno na těchto myšlenkách:
• Systém není problematický a lze definovat jeho cíle
• K dosažení cíle vedou různé cesty, které lze modelovat, porovnávat a vybrat nejlepší variantu
• Schéma prostředek - cíl
• Systémovost je součástí reálného světa
Rozsáhlý a prověřený aparát tvrdých přístupů je založen především na tzv. úlohách na systému, operačního výzkumu, teorie grafů, matematické statistiky atd. a bude představovat podstatnou část systémového inženýrství a v tomto duchu bude také rozvíjen. Předností těchto metodologií je snadná přenositelnost, objektivita, dokazovatelnost vlastností, algoritmizovatelnost a tím i automatizovanost řešení. Naopak je zde ale nebezpečí, že aparát zobrazení řešeného problému je mnohdy podřízen syntaxi použitých formalizovaných prostředků a může dojít k deformaci obsahu.
Podobně jako rozlišujeme systémy tak i metodologie rozlišujeme na měkké a tvrdé. Tvrdé systémové metodologie jsou klasickým nástrojem systémového inženýrství.
Systémové teorie
Ludwig von Bertalanfy, biolog organizmů, navrhl koncem 40. let, že myšlenky o organismech jako celistvých entitách by mohli být zobecněny pro libovolné celky, zvané systémy. Člověk se snaží najít smysl ve vnímané realitě pomocí myšlenkových konceptů(systémů), uplatňovaných v myšlenkových procesech nebo-li metodologiích. Vnímaná realita a koncepty jsou v neustálém kontaktu a interakci a vzájemně na sebe působí.
Tvrdé systémy – přístupy
Analytici sledující tvrdé systémové myšlení vycházejí z předpokladu, že termíny systému existují jako takové a je možné je popsat, měřit, vylepšovat. Tvrdé systémové myšlení je založeno na těchto myšlenkách:
• Systém není problematický a lze definovat jeho cíle
• K dosažení cíle vedou různé cesty, které lze modelovat, porovnávat a vybrat nejlepší variantu
• Schéma prostředek - cíl
• Systémovost je součástí reálného světa
Rozsáhlý a prověřený aparát tvrdých přístupů je založen především na tzv. úlohách na systému, operačního výzkumu, teorie grafů, matematické statistiky atd. a bude představovat podstatnou část systémového inženýrství a v tomto duchu bude také rozvíjen. Předností těchto metodologií je snadná přenositelnost, objektivita, dokazovatelnost vlastností, algoritmizovatelnost a tím i automatizovanost řešení. Naopak je zde ale nebezpečí, že aparát zobrazení řešeného problému je mnohdy podřízen syntaxi použitých formalizovaných prostředků a může dojít k deformaci obsahu.
Základní principy projektování
Projektování je činnost, kterou se vymezuje a dokumentuje vzájemný vztah činitelů (lidského, technického a metodického) vstupujících do daného procesu a jejich působení směřující k dosažení zadaných cílů. Vzájemný vztah a působení těchto činitelů se realizuje ve třech rovinách: v čase, tj. v určité posloupnosti, v prostoru (dispozičně) a strukturálně (odpovědnostně, kompetentně).
Těmto rovinám odpovídá i forma dokumentace, kterou se projekty vyjadřují. Působení činitelů v čase se charakterizuje technologickými postupy, jejich působení v prostoru dispozičními schématy a jejich kompetence strukturálními schématy. Projektování informačních systémů v sobě zahrnuje po určitém zjednodušení dva základní okruhy: analýzu systému a návrh systému. Projektování informačních systémů dále charakterizujeme jako posloupnost určitých činností, které lze dělit do tří základních okruhů:
Analýza a modelování. Při analýze a modelování zkoumáme daný podnik, firmu, mapujeme jeho strukturu a chování po stránce funkční i datové. Výsledkem je vytvoření modelu dané části ekonomické reality, který umožní plně obsáhnout a řešit zadanou problematiku, vzhledem k rozumné míře abstrakce oproti složitosti reality. Stanovení cílů. Specifikujeme cíle celé akce, provádíme jejich vyhodnocení, konkretizaci a realizaci. Řešitel prostřednictvím své tvůrčí aktivity navrhuje na základě aktuálního stavu ekonomického subjektu a specifikovaných cílů, takovou strukturu a náplň informačního systému, která by naplnila specifikované cíle.
Těmto rovinám odpovídá i forma dokumentace, kterou se projekty vyjadřují. Působení činitelů v čase se charakterizuje technologickými postupy, jejich působení v prostoru dispozičními schématy a jejich kompetence strukturálními schématy. Projektování informačních systémů v sobě zahrnuje po určitém zjednodušení dva základní okruhy: analýzu systému a návrh systému. Projektování informačních systémů dále charakterizujeme jako posloupnost určitých činností, které lze dělit do tří základních okruhů:
Analýza a modelování. Při analýze a modelování zkoumáme daný podnik, firmu, mapujeme jeho strukturu a chování po stránce funkční i datové. Výsledkem je vytvoření modelu dané části ekonomické reality, který umožní plně obsáhnout a řešit zadanou problematiku, vzhledem k rozumné míře abstrakce oproti složitosti reality. Stanovení cílů. Specifikujeme cíle celé akce, provádíme jejich vyhodnocení, konkretizaci a realizaci. Řešitel prostřednictvím své tvůrčí aktivity navrhuje na základě aktuálního stavu ekonomického subjektu a specifikovaných cílů, takovou strukturu a náplň informačního systému, která by naplnila specifikované cíle.
Komunikace.
Komunikace mezi všemi zainteresovanými lidmi a odděleními je jedna z nejdůležitějších charakteristik procesu projektování. Hlavním cílem projektových prací je: zdokonalení řídících postupů, zajištění potřebných informací na správném místě, zajištění potřebných informací ve správný časový okamžik, získání nových zdrojů pro proces řízení, rozumnější organizaci řídících procesů, zlepšení komunikace ve firmě, adekvátní technologické zabezpečení řídících procesů.
Analýza a návrh systému
Klíčovou fází projekčního procesu je analýza systému, která předurčuje budoucí charakteristiky a účinnosti projektovaného systému. Smyslem analýzy systému je poznání a vyhodnocení struktury a chování firmy jako systému před zrcadlem nastíněných cílů. Klíčovou fází projekčního procesu je právě analýza systému. Smyslem analýzy je poznání struktury a chování firmy. Výsledkem je specifikace problémových oblastí k následnému řešení. Hlavním cílem analýzy systémů je především:
• popis stávajícího IS a s čím byli uživatele nespokojeni
• požadavky a priority uživatelů, základní procesy jejich práce
• popis systému řízení
• popis alternativ řešení.
Po fázi analýzy následuje fáze návrhová, při které specifikujeme nové charakteristiky systému - nové struktury v systému řízení (prvky, vazby, procesy). Výsledkem je specifikace problémových oblastí k následnému řešení. Podstatné jsou především:
• návrh nových struktur v systému řízení (prvků a vazeb)
• návrh nových řídících procesů v navrhovaných strukturách (toky dat, algoritmy zpracování)
• návrh charakteristik řídících struktur a procesů
• návrh vztahů struktur a procesů.
Analýza a návrh systému
Klíčovou fází projekčního procesu je analýza systému, která předurčuje budoucí charakteristiky a účinnosti projektovaného systému. Smyslem analýzy systému je poznání a vyhodnocení struktury a chování firmy jako systému před zrcadlem nastíněných cílů. Klíčovou fází projekčního procesu je právě analýza systému. Smyslem analýzy je poznání struktury a chování firmy. Výsledkem je specifikace problémových oblastí k následnému řešení. Hlavním cílem analýzy systémů je především:
• popis stávajícího IS a s čím byli uživatele nespokojeni
• požadavky a priority uživatelů, základní procesy jejich práce
• popis systému řízení
• popis alternativ řešení.
Po fázi analýzy následuje fáze návrhová, při které specifikujeme nové charakteristiky systému - nové struktury v systému řízení (prvky, vazby, procesy). Výsledkem je specifikace problémových oblastí k následnému řešení. Podstatné jsou především:
• návrh nových struktur v systému řízení (prvků a vazeb)
• návrh nových řídících procesů v navrhovaných strukturách (toky dat, algoritmy zpracování)
• návrh charakteristik řídících struktur a procesů
• návrh vztahů struktur a procesů.
Koncepce informačních zdrojů
Podstatou zdrojove'ho přístupu k projektování informačních systémů je chápání dat jako potenciálních zdrojů (na stejné úrovni jako člověk, energie atd.), které umožňují zabezpečit uspokojování informačních potřeb manažerů i běžných pracovníků včetně potřebných vazeb. Vychází se přitom z modelování dat jako funkce reality tzn. primárně z předmětu zpracování (viz dále tzv. předmětné báze dat), který určuje jaká data, o čem, a až sekundárně z nároků na zpracování dat.
Data jsou relativně stabilnější než požadavky na informace z dat odvoditelné. Typy prvků, které jsou objektem řízení se dramaticky nemění, pokud se nemění cílový stav nebo chování objektu. Lze říci, že hodnoty datových prvků se mění, ale typy prvků a jejich vlastnosti se nemění. Vhodně navržený model reality je tedy stabilnější než informační potřeby. Při tomto způsobu bude splněn i požadavek, aby z potencionálních zdrojů informací- dat bylo možné odvodit co nejširší varietu zpráv, hlášení atd. Projekční metody používané v klasických systémech - bez prvků distribuce, které byly primárně zaměřeny na analýzu informačních potřeb a způsobu transformace dat vedou k dlouhým časovým horizontům projekčního cyklu a především k systémům, které jsou-li plně realizovány, vykazují značnou nepružnost, malou flexibilitu vzhledem k měnícím se podmínkám.
V systémech s prvky distribuce je kladen důraz na vzájemnou komunikaci mezi jednotlivými prvky řízení - na zajištění jejich informačních vazeb. K tomu je bezpodmínečně nutné, aby jednotlivé prvky (tj. jediný uživatel a jeho osobní informační systém, skupina a její informační systém, a konečně i informační systém pokrývající celou firmu), byly účelně provázány a navenek působily jako integrovaný systém. Tato skutečnost vyžaduje zvýšený důraz na globální uvažování a řešení systému jako celku. Jedná se nejenom o strategické rozvrhování informačních zdrojů -prvků datové základny (tj. tvorba globální koncepce informačních zdrojů) ale i o koncepci nákupu techniky, rozvoje systému atd. Proto je důležité prioritně věnovat zvýšenou pozornost globální úrovni projekce. Špatně navržený globální návrh již nelze zachránit sebelepší realizací na detailní úrovni. Navíc lze s trochou nadsázky prohlásit, že detailní realizace, při současné úrovni dostupných programových prostředků není již v současné době intelektuálně náročný problém - zde přechází těžiště spíše do rutinní oblasti a sestavení konečného řešení stavebnicovým způsobem z dostupných modulů.
Data jsou relativně stabilnější než požadavky na informace z dat odvoditelné. Typy prvků, které jsou objektem řízení se dramaticky nemění, pokud se nemění cílový stav nebo chování objektu. Lze říci, že hodnoty datových prvků se mění, ale typy prvků a jejich vlastnosti se nemění. Vhodně navržený model reality je tedy stabilnější než informační potřeby. Při tomto způsobu bude splněn i požadavek, aby z potencionálních zdrojů informací- dat bylo možné odvodit co nejširší varietu zpráv, hlášení atd. Projekční metody používané v klasických systémech - bez prvků distribuce, které byly primárně zaměřeny na analýzu informačních potřeb a způsobu transformace dat vedou k dlouhým časovým horizontům projekčního cyklu a především k systémům, které jsou-li plně realizovány, vykazují značnou nepružnost, malou flexibilitu vzhledem k měnícím se podmínkám.
V systémech s prvky distribuce je kladen důraz na vzájemnou komunikaci mezi jednotlivými prvky řízení - na zajištění jejich informačních vazeb. K tomu je bezpodmínečně nutné, aby jednotlivé prvky (tj. jediný uživatel a jeho osobní informační systém, skupina a její informační systém, a konečně i informační systém pokrývající celou firmu), byly účelně provázány a navenek působily jako integrovaný systém. Tato skutečnost vyžaduje zvýšený důraz na globální uvažování a řešení systému jako celku. Jedná se nejenom o strategické rozvrhování informačních zdrojů -prvků datové základny (tj. tvorba globální koncepce informačních zdrojů) ale i o koncepci nákupu techniky, rozvoje systému atd. Proto je důležité prioritně věnovat zvýšenou pozornost globální úrovni projekce. Špatně navržený globální návrh již nelze zachránit sebelepší realizací na detailní úrovni. Navíc lze s trochou nadsázky prohlásit, že detailní realizace, při současné úrovni dostupných programových prostředků není již v současné době intelektuálně náročný problém - zde přechází těžiště spíše do rutinní oblasti a sestavení konečného řešení stavebnicovým způsobem z dostupných modulů.
Postupy analýzy
Při projektování informačních systémů rozlišujeme dva (tři) základní postupy: postup zdola-nahoru (bottom-up) a postup shora-dolů (top-down) a postup kombinovaný (middle-out), který je kombinací obou předchozích postupů.
Základem shora-dolů přístupu je přesné vymezení projektované reality, postupná dekompozice celků na skupiny, až po nejnižší stupeň hierarchie. Lze dekomponovat funkční celky i datové objekty a toky. Postup shora-dolů následně v případech, kdy se spíše snažíme o podporu nové kvality systému jako celku.
Základem zdola-nahoru přístupu je zkoumání reálného světa a posupná definice entit a akcí. Teprve posléze se tyto poznatky převádějí do strukturované podoby, vytváří se model a zkoumá jeho konzistentnost s reálným světem. Postup zdola-nahoru je vhodné použít spíše v těch případech, kdy se primárně zaměňme na uspokojení stávajících informačních požadavků uživatelů
Dřívější oddělené projektování jednotlivých subsystémů vedlo k velké nejednotnosti, neúčetných duplicitám v datech a programech, nepřehlednosti a podpoře stávajícího stavu. Po realizaci jednotlivých subsystémů se sice projevila nutnost jejich propojení, to však bylo mnohdy umělé, a nebo vedlo ke změnám již hotových projektů. Každá aplikace používala své údaje a i když se jednalo o stejné údaje, byly uloženy v jiné struktuře apod. Také některé úlohy prováděné v různých aplikacích byly ve své podstat stejné, zabezpečovaly je však různé programy. Jakákoliv změna v organizaci firmy vyvolávala zásahy a změny v programech i v datové základně. Systém nebyl otevřen pro svůj rozvoj.
Dobrý návrh systému vyžaduje komplexní přístup. Zvláště u distribuovaných informačních systémů je nutné dodržovat určitá pravidla komplexního přístupu, při respektování samostatně analyzovaných a navržených celků. Distribuovaný informační systém se musí skládat ze samostatných částí - subsystémů, z nichž každý je natolik jednoduchý, aby mohl být kompletně sám analyzován a efektivně navržen.
Zároveň všechny subsystémy musejí tvořit ucelený systém. Těchto cílů lze dosáhnout projektováním shora dolů v prvních fázích a teprve v dalších fázích kombinací s postupem zdola nahoru - tj. dodržováním zásady analýzy shora a tvorbou zdola.
Základem shora-dolů přístupu je přesné vymezení projektované reality, postupná dekompozice celků na skupiny, až po nejnižší stupeň hierarchie. Lze dekomponovat funkční celky i datové objekty a toky. Postup shora-dolů následně v případech, kdy se spíše snažíme o podporu nové kvality systému jako celku.
Základem zdola-nahoru přístupu je zkoumání reálného světa a posupná definice entit a akcí. Teprve posléze se tyto poznatky převádějí do strukturované podoby, vytváří se model a zkoumá jeho konzistentnost s reálným světem. Postup zdola-nahoru je vhodné použít spíše v těch případech, kdy se primárně zaměňme na uspokojení stávajících informačních požadavků uživatelů
Dřívější oddělené projektování jednotlivých subsystémů vedlo k velké nejednotnosti, neúčetných duplicitám v datech a programech, nepřehlednosti a podpoře stávajícího stavu. Po realizaci jednotlivých subsystémů se sice projevila nutnost jejich propojení, to však bylo mnohdy umělé, a nebo vedlo ke změnám již hotových projektů. Každá aplikace používala své údaje a i když se jednalo o stejné údaje, byly uloženy v jiné struktuře apod. Také některé úlohy prováděné v různých aplikacích byly ve své podstat stejné, zabezpečovaly je však různé programy. Jakákoliv změna v organizaci firmy vyvolávala zásahy a změny v programech i v datové základně. Systém nebyl otevřen pro svůj rozvoj.
Dobrý návrh systému vyžaduje komplexní přístup. Zvláště u distribuovaných informačních systémů je nutné dodržovat určitá pravidla komplexního přístupu, při respektování samostatně analyzovaných a navržených celků. Distribuovaný informační systém se musí skládat ze samostatných částí - subsystémů, z nichž každý je natolik jednoduchý, aby mohl být kompletně sám analyzován a efektivně navržen.
Zároveň všechny subsystémy musejí tvořit ucelený systém. Těchto cílů lze dosáhnout projektováním shora dolů v prvních fázích a teprve v dalších fázích kombinací s postupem zdola nahoru - tj. dodržováním zásady analýzy shora a tvorbou zdola.
Analýza shora a tvorba zdola
Analýza shora a výstavba zdola je postup (nebo spíše princip, doporučení) známé v literatuře pod pojmem „Top down analysis and bottom up design". Tento princip je založen na počátečním rozkladu (dekompozici) firmy (řešeného subjektu) postupným rozkládáním (strukturalizací) na menší a stále menší celky. Následně jsou tyto celky postupně navrhovány, tvořeny (programové a datové prvky) a zaváděny. Postup realizace těchto jednotlivých celků vychází z priorit potřebnosti a z cílů „existence" těchto celků.
Tento princip si lze představit jako vytvoření jakési (pevně vzájemně provázané) železobetonové konstrukce budoucí stavby, do které jsou následně vkládány jednotlivé prvky jako kamínky do mozaiky. Hlavní výhody tohoto postupu:
• poskytuje všeobecný - integrovaný pohled na všechny firemní procesy (aktivity), objekty těchto procesů a na hrubé úrovni i na data
• poskytuje odrazový můstek pro následné členění a zpodrobňování firemní datové základny do jednotlivých samostatně projektovatelných databází
• umožňuje definovat relativně uzavřené programové celky (již v rámci jednotlivých subsystémů), které je možno samostatně implementovat (lze využít i jednotlivých typových řešení nabízených na trhu)
• v průběhu tvorby lze využít budoucích uživatelů ke kontrole správnosti.
Tento princip si lze představit jako vytvoření jakési (pevně vzájemně provázané) železobetonové konstrukce budoucí stavby, do které jsou následně vkládány jednotlivé prvky jako kamínky do mozaiky. Hlavní výhody tohoto postupu:
• poskytuje všeobecný - integrovaný pohled na všechny firemní procesy (aktivity), objekty těchto procesů a na hrubé úrovni i na data
• poskytuje odrazový můstek pro následné členění a zpodrobňování firemní datové základny do jednotlivých samostatně projektovatelných databází
• umožňuje definovat relativně uzavřené programové celky (již v rámci jednotlivých subsystémů), které je možno samostatně implementovat (lze využít i jednotlivých typových řešení nabízených na trhu)
• v průběhu tvorby lze využít budoucích uživatelů ke kontrole správnosti.
Příloha: Funkční a zdrojový přístup
Funkční přístup
Funkční přístup primárně vychází z požadavků na výstupní informace jako reakce na funkce v systému a zaměřuje se především na možnosti, jak tyto informace ze systému získat. Zaměřuje se proto především na algoritmy potřebné k získání těchto informací. Základem je funkční analýza prostředí. Nevýhodou tohoto přístupu je pomalá reakce na změny v realitě, například na změny informačních potřeb uživatelů.
Metody funkční analýzy se zaměřují na algoritmy, zajišťující uspokojování informačních potřeb. Smyslem funkční analýzy je tedy specifikace algoritmu zpracování dat, který vychází ze specifikace požadavků na služby informačních systémů a čerpá z existujících vstupních dat. Funkční analýza se zaměřuje na stanovení cílů, které by měl nový systém splňovat. Nástroji funkční analýzy jsou různé formy funkčních a procedurálních modelů, které zpravidla vycházejí z globální specifikace požadavků na automatizovaný informační systém a pomocí funkční dekompozice směřují k funkcím, které uspokojují tyto požadavky.
Zdrojový přístup
Zdrojový přístup se zaměřuje především na uspokojování informačních potřeb. Primárně se proto orientuje na jejich analýzu, podstatou přístupu je konstrukce datového modelu reality. Základem je informační analýza. Metody datové analýzy, jako podmnožiny informační analýzy, se zaměřují na vymezení obsahu datové základny, návrh její struktury a její realizaci. Centrem zájmu jsou tedy data, která jsou stabilní a jsou datovým odrazem reálných prvků. Nástrojem datové analýzy jsou různé formy datových modelů. Předmětem datového modelování jsou:
• reálné objekty (entity)
• vazby mezi entitami
• změny ve vazbách mezi entitami, tj. dynamická stránka reality, zohledňující časový faktor.
Cílem datového modelování je vymezení objektů v prostoru a čase. Při této analýze se vychází buď z reálných objektů, procesů a událostí a hledání možností jejich optimálního zobrazení v datové základně, nebo (a současně) z analýzy informačních potřeb resp. informací jako vstupů a výstupů ve vazbě na jednotlivé potřeby.
Východiskem může být analýza reálných procesů a objektů resp. jejich chování a hledání jejich optimálního zobrazení v datové základně. Předmětem takto pojaté analýzy jsou objekty, jejich vazby, aktivace a deaktivace těchto vazeb jako výsledek událostí v realitě. Podstatou tohoto přistupuje zaměření na tvorbu datového modelu reality, který je ve své podstatě stabilnější než informační požadavky. Realitou rozumíme jak existující systém, tak i představu budoucího projektovaného systému.
Nevýhodou funkčního přístupu je malá flexibilita, nevýhodou zdrojového přístupu je možnost nezahrnutí některých podstatných funkcí do výsledného řešení (což lze však minimalizovat v počátečních fázích projektování).
Nejenom z důvodu těchto nejpodstatnějších omezení je nutné si uvědomit, že nelze upřednostňovat jeden způsob před druhým a není možné přistoupit k řešení pouze z hlediska funkcí nebo dat. Metody informační a funkční analýzy se vzájemně doplňuji a prolínají. Každá z nich je zaměřena na jiné hledisko. Lze je v konkrétní situaci vzájemné nahrazovat, výsledky dosažené jedním způsobem lze ověřovat druhým. Je proto vhodné účelně propojovat informační a funkční analýzu. Informační resp. datová analýza by měla mít před funkční analýzou určitý předstih resp. měla by modifikovat závěry informační analýzy.
Funkční přístup primárně vychází z požadavků na výstupní informace jako reakce na funkce v systému a zaměřuje se především na možnosti, jak tyto informace ze systému získat. Zaměřuje se proto především na algoritmy potřebné k získání těchto informací. Základem je funkční analýza prostředí. Nevýhodou tohoto přístupu je pomalá reakce na změny v realitě, například na změny informačních potřeb uživatelů.
Metody funkční analýzy se zaměřují na algoritmy, zajišťující uspokojování informačních potřeb. Smyslem funkční analýzy je tedy specifikace algoritmu zpracování dat, který vychází ze specifikace požadavků na služby informačních systémů a čerpá z existujících vstupních dat. Funkční analýza se zaměřuje na stanovení cílů, které by měl nový systém splňovat. Nástroji funkční analýzy jsou různé formy funkčních a procedurálních modelů, které zpravidla vycházejí z globální specifikace požadavků na automatizovaný informační systém a pomocí funkční dekompozice směřují k funkcím, které uspokojují tyto požadavky.
Zdrojový přístup
Zdrojový přístup se zaměřuje především na uspokojování informačních potřeb. Primárně se proto orientuje na jejich analýzu, podstatou přístupu je konstrukce datového modelu reality. Základem je informační analýza. Metody datové analýzy, jako podmnožiny informační analýzy, se zaměřují na vymezení obsahu datové základny, návrh její struktury a její realizaci. Centrem zájmu jsou tedy data, která jsou stabilní a jsou datovým odrazem reálných prvků. Nástrojem datové analýzy jsou různé formy datových modelů. Předmětem datového modelování jsou:
• reálné objekty (entity)
• vazby mezi entitami
• změny ve vazbách mezi entitami, tj. dynamická stránka reality, zohledňující časový faktor.
Cílem datového modelování je vymezení objektů v prostoru a čase. Při této analýze se vychází buď z reálných objektů, procesů a událostí a hledání možností jejich optimálního zobrazení v datové základně, nebo (a současně) z analýzy informačních potřeb resp. informací jako vstupů a výstupů ve vazbě na jednotlivé potřeby.
Východiskem může být analýza reálných procesů a objektů resp. jejich chování a hledání jejich optimálního zobrazení v datové základně. Předmětem takto pojaté analýzy jsou objekty, jejich vazby, aktivace a deaktivace těchto vazeb jako výsledek událostí v realitě. Podstatou tohoto přistupuje zaměření na tvorbu datového modelu reality, který je ve své podstatě stabilnější než informační požadavky. Realitou rozumíme jak existující systém, tak i představu budoucího projektovaného systému.
Nevýhodou funkčního přístupu je malá flexibilita, nevýhodou zdrojového přístupu je možnost nezahrnutí některých podstatných funkcí do výsledného řešení (což lze však minimalizovat v počátečních fázích projektování).
Nejenom z důvodu těchto nejpodstatnějších omezení je nutné si uvědomit, že nelze upřednostňovat jeden způsob před druhým a není možné přistoupit k řešení pouze z hlediska funkcí nebo dat. Metody informační a funkční analýzy se vzájemně doplňuji a prolínají. Každá z nich je zaměřena na jiné hledisko. Lze je v konkrétní situaci vzájemné nahrazovat, výsledky dosažené jedním způsobem lze ověřovat druhým. Je proto vhodné účelně propojovat informační a funkční analýzu. Informační resp. datová analýza by měla mít před funkční analýzou určitý předstih resp. měla by modifikovat závěry informační analýzy.
Další spolupracovníci
• Správce - Provozovatel
• správce bývá osoba, provozovatel bývá firma,
• u externích systémů provádí přejímku systému, u podnikových se přejímky zúčastní, O ošetřuje provoz systému a zajišťuje jeho funkčnost,
• pečuje o datovou základnu systému, určuje přístupová práva, řídí aktualizace, O provádí drobné modifikace systému, O udržuje dokumentaci systému v aktuálním stavu,
• u komerčních systémů sleduje a vyhodnocuje uživatelské aktivity, u placených služeb zajišťuje fakturace a veškeré finanční aktivity, provádí marketingové průzkumy,
doporučuje změny a inovace systému.
• Uživatel
O Role uživatele v průběhu řešení se výrazně odlišují podle toho, je-li uživatel prvkem systému nebo prvkem jeho okolí:
• je-li uživatel prvkem systému, podílí se na zadání, výběru řešitele, objednávce i na vlastním řešení (konzultuje, spolupracuje s řešitelem a ostatními partnery),
• je-li uživatel prvkem okolí, nepodílí se zpravidla na celé fázi řešení vůbec, neboť není konkretizován.
Při zkušebním a ověřovacím provozu se uživatel - prvek systému plně zúčastňuje celého procesu; jestliže však je
prvkem okolí, podílí se jen vybraní uživatelé jen na ověřovacím provozu. O Při rutinním provozu se výrazně liší role uživatele podle toho, zda je prvkem systému nebo okolí:
« uživatel jako prvek systému je částí nějakého řízeného celku a bývá spolu s provozovatelem (správcem)
součástí jediné firmy nebo organizace, « uživatel v okolí systému užívá systémové služby, je zákazníkem (klientem) provozovatele.
Obecně ovšem může docházet k různým kombinacím; např. zadavatel může být spoluautorem systému, tvůrce může být i provozovatelem apod. V takových případech je mimořádně důležité předem dohodnout všechny organizační vztahy ve všech fázích tvorby systému - zejména pak při přejímce.
Spolupráce jednotlivých skupin,lidí při tvorbě IS
Tvorba nových systémů i reegineering vyžadují důkladnou a těsnou spolupráci všech partnerů. Spolupráce se uskutečňuje jak formálně tak neformálně. Probíhají oponentury, kontrolní dny, pracovní porady, emailový i poštovní styk, dělají se zápisy, záznamy, dohody, smlouvy, memoranda apod. Náležitosti těchto věcí jsou asi každému dostatečně známy.
Dále viz. otázka SR12 – různé skupiny lidí
• správce bývá osoba, provozovatel bývá firma,
• u externích systémů provádí přejímku systému, u podnikových se přejímky zúčastní, O ošetřuje provoz systému a zajišťuje jeho funkčnost,
• pečuje o datovou základnu systému, určuje přístupová práva, řídí aktualizace, O provádí drobné modifikace systému, O udržuje dokumentaci systému v aktuálním stavu,
• u komerčních systémů sleduje a vyhodnocuje uživatelské aktivity, u placených služeb zajišťuje fakturace a veškeré finanční aktivity, provádí marketingové průzkumy,
doporučuje změny a inovace systému.
• Uživatel
O Role uživatele v průběhu řešení se výrazně odlišují podle toho, je-li uživatel prvkem systému nebo prvkem jeho okolí:
• je-li uživatel prvkem systému, podílí se na zadání, výběru řešitele, objednávce i na vlastním řešení (konzultuje, spolupracuje s řešitelem a ostatními partnery),
• je-li uživatel prvkem okolí, nepodílí se zpravidla na celé fázi řešení vůbec, neboť není konkretizován.
Při zkušebním a ověřovacím provozu se uživatel - prvek systému plně zúčastňuje celého procesu; jestliže však je
prvkem okolí, podílí se jen vybraní uživatelé jen na ověřovacím provozu. O Při rutinním provozu se výrazně liší role uživatele podle toho, zda je prvkem systému nebo okolí:
« uživatel jako prvek systému je částí nějakého řízeného celku a bývá spolu s provozovatelem (správcem)
součástí jediné firmy nebo organizace, « uživatel v okolí systému užívá systémové služby, je zákazníkem (klientem) provozovatele.
Obecně ovšem může docházet k různým kombinacím; např. zadavatel může být spoluautorem systému, tvůrce může být i provozovatelem apod. V takových případech je mimořádně důležité předem dohodnout všechny organizační vztahy ve všech fázích tvorby systému - zejména pak při přejímce.
Spolupráce jednotlivých skupin,lidí při tvorbě IS
Tvorba nových systémů i reegineering vyžadují důkladnou a těsnou spolupráci všech partnerů. Spolupráce se uskutečňuje jak formálně tak neformálně. Probíhají oponentury, kontrolní dny, pracovní porady, emailový i poštovní styk, dělají se zápisy, záznamy, dohody, smlouvy, memoranda apod. Náležitosti těchto věcí jsou asi každému dostatečně známy.
Dále viz. otázka SR12 – různé skupiny lidí
Zdroje pro tvorbu a implementaci informačního systému podniku
To je v Douckově skriptech, které bohužel nemám, dopíšu to 2.1.2005 po workshopu
Zdroje:
1) personální – včetně znalostí, schopností a dovedností pracovníků včetně jejich „know-how“ v oblasti projektového řízení,
2) časové
3) finanční
4) technologické – nástroje, postupy, modely, které jsou určenz pro nasazení na určitém projektu, jeho součástí je metodika řízení projektů.
Str. 33 Doucek – Řízení projektů
Tvorba systému
Přístup k tvorbě systému
Ideami situace nastane, když máme vytvořit systém „na zelené louce". To znamená, že ještě není nic hotovo a systém zatím existuje jen v mlhavých představách. V tomto případě můžeme postupovat s využitím všech nejmodernějších poznatků a informačních technologií i vlastní fantazie a imaginace. Taková práce je velmi zajímavá a pro dobrého odborníka přímo potěšující.
» Poznámka: nikdy samozřejmě nemáme „zcela volné ruce". Musíme vždy respektovat určité zvyklosti, know-how, platné a vžité organizační a personální zásady apod. To však nic nemění na charakteru práce na novém systému.
Jestliže však již existuje nějaký systém nebo alespoň několik dílčích systémů, mluvíme o inovaci resp. reengineeringu. To je práce nadmíru komplikovaná a obtížná, vyžadující mimořádné praktické zkušenosti a mnoho invence.
Podnikové systémy jsou dnes již natolik rozšířené, že se u nich prakticky vždy setkáváme jen s inovacemi. Síť externích systémů ještě není a dlouho nebude dostatečně vybudovaná a proto nás v tomto oboru může často potkat práce „na zelené louce".
Inovace řešíme s mnoha zadanými (existujícími) výchozími podmínkami. Systém můžeme vylepšit hodně nebo méně, málokdy však můžeme výsledek úplně pokazit. Zcela nový systém lze realizovat jako špičkový a takřka geniální, je tu však také riziko naprostého nezdaru; vědomí absolutní „tvůrčí svobody" nás může přivést k podceňování detailů, k zanedbávání důležitých vazeb a vztahů. Tvůrčí svoboda mnohdy vede ke zdůrazňování formy na úkor obsahu, k použití efektních a zdánlivě elegantních (přitom však často nesmyslných) postupů, k neekonomickému nasazování nejdražších technologií tam, kde ani nejsou zapotřebí atd. Je tedy tento typ práce velice zajímavý, avšak také riskantní, mimořádně odpovědný a náročný na sebekázeň.
V každém případě - při novém řešení i při inovacích - je tvorba a realizace informačního systému záležitostí týmové práce. Podílí se na ní celé skupiny pracovníků nejrůznějšího zaměření i kvalifikace a jedním z nejobtížnějších úkolů je sladit jejich práci tak, aby byla smysluplná a produktivní a aby byla především podřízena základnímu cíly – vybudování efektivně fungujícího systému, plnícího základní funkci – uspokojení potřeb uživatelů.
Týmová práce a spolupráce vyžaduje určité věcné i formální náležitosti, organizační důmysl a vysokou kvalitu řízení všech činností. V této kapitole se budeme problémy z této oblasti zabývat podrobněji.
Zdroje:
1) personální – včetně znalostí, schopností a dovedností pracovníků včetně jejich „know-how“ v oblasti projektového řízení,
2) časové
3) finanční
4) technologické – nástroje, postupy, modely, které jsou určenz pro nasazení na určitém projektu, jeho součástí je metodika řízení projektů.
Str. 33 Doucek – Řízení projektů
Tvorba systému
Přístup k tvorbě systému
Ideami situace nastane, když máme vytvořit systém „na zelené louce". To znamená, že ještě není nic hotovo a systém zatím existuje jen v mlhavých představách. V tomto případě můžeme postupovat s využitím všech nejmodernějších poznatků a informačních technologií i vlastní fantazie a imaginace. Taková práce je velmi zajímavá a pro dobrého odborníka přímo potěšující.
» Poznámka: nikdy samozřejmě nemáme „zcela volné ruce". Musíme vždy respektovat určité zvyklosti, know-how, platné a vžité organizační a personální zásady apod. To však nic nemění na charakteru práce na novém systému.
Jestliže však již existuje nějaký systém nebo alespoň několik dílčích systémů, mluvíme o inovaci resp. reengineeringu. To je práce nadmíru komplikovaná a obtížná, vyžadující mimořádné praktické zkušenosti a mnoho invence.
Podnikové systémy jsou dnes již natolik rozšířené, že se u nich prakticky vždy setkáváme jen s inovacemi. Síť externích systémů ještě není a dlouho nebude dostatečně vybudovaná a proto nás v tomto oboru může často potkat práce „na zelené louce".
Inovace řešíme s mnoha zadanými (existujícími) výchozími podmínkami. Systém můžeme vylepšit hodně nebo méně, málokdy však můžeme výsledek úplně pokazit. Zcela nový systém lze realizovat jako špičkový a takřka geniální, je tu však také riziko naprostého nezdaru; vědomí absolutní „tvůrčí svobody" nás může přivést k podceňování detailů, k zanedbávání důležitých vazeb a vztahů. Tvůrčí svoboda mnohdy vede ke zdůrazňování formy na úkor obsahu, k použití efektních a zdánlivě elegantních (přitom však často nesmyslných) postupů, k neekonomickému nasazování nejdražších technologií tam, kde ani nejsou zapotřebí atd. Je tedy tento typ práce velice zajímavý, avšak také riskantní, mimořádně odpovědný a náročný na sebekázeň.
V každém případě - při novém řešení i při inovacích - je tvorba a realizace informačního systému záležitostí týmové práce. Podílí se na ní celé skupiny pracovníků nejrůznějšího zaměření i kvalifikace a jedním z nejobtížnějších úkolů je sladit jejich práci tak, aby byla smysluplná a produktivní a aby byla především podřízena základnímu cíly – vybudování efektivně fungujícího systému, plnícího základní funkci – uspokojení potřeb uživatelů.
Týmová práce a spolupráce vyžaduje určité věcné i formální náležitosti, organizační důmysl a vysokou kvalitu řízení všech činností. V této kapitole se budeme problémy z této oblasti zabývat podrobněji.
Přihlásit se k odběru:
Příspěvky (Atom)