- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (75)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (41)
- Dodavatelé CRM (38)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (66)
- Informační bezpečnost (48)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)
Tematické sekce


















Branžové sekce
![]() | Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | |
![]() | ||
Partneři webu
IT SYSTEM 9/2000
Is pro řízení lidských zdrojů, IV. část - zavádění IS pro řízení lidských zdrojů
František Haluška
Základní strategie zavádění IS
Další část článků vychází z předpokladu, že budoucí uživatel učinil strategické rozhodnutí a s tím související kroky:
· podepsal s dodavatelem obchodní smlouvu na vypracování studie realizovatelnosti
· je rozhodnut učinit resp. již zahájil kroky potřebné pro zavedení SW ve firmě dle podmínek stanovených dodavatelem
· je rozhodnut SW zavést a používat v rutinním provozu
Nad výše uvedenými kroky je nezbytné, aby vzali záštitu kompetentní představitelé vrcholového managementu. Proto je vhodné, aby na samém počátku zavádění IS došlo k osobnímu setkání vrcholových představitelů obou stran a např. formou písemného memoranda deklarovali:
· zahájení procesu zavádění IS
· zájem na zavedení s podporou vrcholového managementu obou stran
Podpora vrcholového managementu ze strany zákazníka (uživatele) je klíčovým předpokladem úspěšného zavedení SW produktu ve firmě.
Dosavadní zkušenosti říkají, že tam, kde se jí nepodařilo získat v dostatečné míře, je postup zavádění mnohem složitější.
Zavádění IS jako firemní projekt
Renomovaní dodavatelé SW produktů (obecně) doporučují jejich zavádění formou tzv. firemního projektu
Firemní projekt je charakteristický několika znaky
· vede jej manažer projektu zpravidla jmenovaný vrcholovým vedením firmy
· manažer projektu ve spolupráci s ostatními vedoucími nominuje příslušné odborníky - členy projekčního (realizačního) týmu a to i napříč organizační strukturou
· projekt má svou vlastní formalizovanou dokumentaci (zápisy, protokoly, zprávy........) ukládanou na dohodnutých místech a dohodnutým způsobem
· projekt je dočasný - např. pouze pro určitou etapu implementace SW
· projektové řízení implementace SW je vhodné zrcadlově zavést jak na straně uživatele, tak na straně dodavatele
· projekt je oficiálně iniciován (vyhlášen) a rovněž i ukončen a to písemnou formou
· průběh projektových prací se pravidelně dokumentuje a podávají se informace příslušným vedoucím
Realizační týmy
Jak bylo naznačeno v předchozí části, je vhodné pro zdárný průběh implementace SW produktu stanovit na obou stranách - uživatel i dodavatel tzv. realizační týmy . Týmy sestávají z odborníků obou stran a jsou sestaveny tak, aby zavádění SW proběhlo maximálně možným optimálním způsobem. Žádná ze zúčastněných zpravidla neovlivňuje konkrétní personální obsazení týmu strany druhé.
Dodavatel pouze doporučuje z kterých oborů mají být odborníci nominováni a v jakém počtu, aby byla práce zvládnutelná v plánovaných časech.
Realizační tým na straně dodavatele sestává zpravidla z těchto struktur
· manažer projektu
· garanti odborných oblastí (personální, mzdová, vzdělávání, hodnocení, technická oblast.......)
· řadoví konzultanti (řešitelé dílčích problémů, školitelé ......)
Realizační tým na straně uživatele má zpravidla poněkud jinou strukturu, avšak pro dodržení standardu komunikace je vhodné, aby sestával přibližně z odpovídajících partnerů:
· vedoucí realizačního týmu - manažer projektu uživatele
· odborní pracovníci jednotlivých oblastí řešení - partneři garantů oblastí dodavatele
Protože lze reálně předpokládat, že v průběhu zavádění SW budou vznikat jisté odborné třecí plochy, doporučuje se, aby obě strany ustanovili tzv. řídící výbor (rada) , což je orgán, který je uváděn v činnost pro řešení sporných bodů řešení a rovněž může dohodou obou stran přijímat rozhodnutí o uzavření příslušné etapy projektu.
Členové řídícího výboru se zpravidla rekrutují z členů vrcholového managementu obou stran.
Úvodní projekt - studie realizovatelnosti
Studie realizovatelnosti (SR) je spolu s implementační studií jedním z klíčových dokumentů projektu a je zpravidla dodávána za úplatu jako samostatná část projektu. Tudíž je nutné jí věnovat náležitou pozornost a to oběma stranami. Studii realizovatelnosti vypracovává vždy dodavatel SW produktu na základě zjištěných skutečností u uživatele.
Z uvedených důvodů je uživatel (zákazník) oprávněn striktně trvat na zásadách týkajících se jejího obsahu a formy.
Patří mezi ně zejména
· Přiměřená míra srozumitelnosti - dokument budou posuzovat a používat nejen uzcí specialisté z oboru HR, ale i jiní příslušníci managementu zákazníka.
· Vysoká grafická úroveň dokumentu - formát písma a nadpisů, rozčlenění do kapitol a odstavců, vložené objekty a obrázky apod.
· Vysoká stylizační forma a naprostá gramatická správnost.
· Vysoká přehlednost dokumentu - obsah a rejstřík, pojmenování kapitol a jejich číslování, tematická návaznost, oddělování témat apod.
· Použití dohodnutých grafických standardů - šablony, styly, logo apod.
Konkrétní podoba SR je určena především dohodnutým řešením se zákazníkem ve smlouvě o zpracování studie realizovatelnosti a dalších dokumentech, jimiž je projekt doprovázen.
Rozpočet projektu, smluvní garance dodávky
Jak již bylo dříve několikrát zdůrazněno, je důležité dojednat s dodavatelem nejen celkovou částku, za níž bude IS pořízen, ale i věcnou skladbu rozpočtu tj. jeho relativně detailní specifikaci a rozložení čerpání finančních prostředků v čase. Zákazník zpravidla bude muset postupně vynaložit finanční prostředky na tyto položky:
· Pořízení vlastního SW pro řízení lidských zdrojů tzv. uživatelské licence.
· Pořízení jiného SW, např. operační systém, databázová platforma apod. - většinou od jiného subjektu.
· Pořízení HW vybavení - většinou od jiného subjektu.
· Platby za implementační práce - předem ve smlouvě dohodnuté sazby, pokud se nepracuje za tzv. fixní cenu za celou dodávku.
· Platby za pravidelnou údržbu SW v rámci rutinního provozu.
· Finanční rezerva pro fázi implementace - specifikuje se po dohodě s dodavatelem kvalifikovaným odhadem.
· Finanční strategická rezerva na plánovaný rozvoj systému - např. nové moduly a rozšíření počtu licencí apod.
Tento výčet je odrazovou bází pro stanovení vnitrofiremního rozpočtu, který bude do značné míry po promítnutí do časové osy i platebním kalendářem.
Z pohledu druhé strany tj. dodavatele, je rozpočet a jeho sledování kontrolním nástrojem pro efektivnost jeho vlastního počínání a tím i racionalizačním prvkem ve vztahu k zákazníkovi, neboť obě strany mají zájem na maximální efektivitě spolupráce tak, aby byly finanční prostředky vynakládány maximálně účelně.
Pokud je projekt "rozpočtován" nekvalitně - povrchně, nepřesně, neúplně apod., pak je velmi pravděpodobné, že některá z obou stran (případně obě) se může dostat do potíží a být rozčarována z výsledného efektu ve vztahu k vynaloženým nákladům.
Je zcela běžné, že ve vztahu k vynaloženým finančním prostředkům má zákazník plné právo požadovat určité garance za dodávku IS a jeho komponent. Tyto garance jsou vždy specifikovány obvyklým způsobem v oboru IS/IT a to v obchodní smlouvě. Patří sem zejména:
· Údržba programového vybavení - viz další text.
· Hot -line - viz další text.
· Bezplatná záruka na bezporuchový provoz SW po stanovenou dobu.
· Záruka za bezporuchovost předávacích médií po stanovenou dobu.
· Předání kompletní technické dokumentace pro možné pokračování funkce SW po event. ukončení činnosti dodavatele.
· Přednostní nabídka všech vyšších verzí SW za "zvýhodněné" (rozdílové) ceny.
· Úhradu škod způsobených prokazatelně zaviněným prodlením ze strany dodavatele.
· Záruky za počínání pracovníků dodavatele u zákazníka (implementační a jiné práce) a případné škody vzniklé jejich nedbalostí.
Jisté garance však poskytuje i zákazník dodavateli. Patří sem zejména
· Závazek neposkytovat SW a dokumentaci třetím osobám.
· Neprovozovat SW pro třetí osoby.
· Splnit podmínky určené v závazné provozní dokumentaci a odsouhlasených dokumentech.
· Zajistit kontakt s dodavatelem (přístup dodavatele k SW pro smluvní úkony) a interní správu SW dle ujednání ve smlouvě.
Kvalitní dodavatel zpravidla nabízí zákazníkům smlouvu opatřenou veškerými běžnými garancemi obvyklými pro oblast IS/IT, takže zákazník se zakotvení garancí do smlouvy nemusí domáhat a smlouvu dává pouze ke konzultaci svému právnímu útvaru.
Prováděcí projekt - implementační studie (IS)
Implementační studie (IS) též někdy nazývaná prováděcí projekt, je spolu se studií realizovatelnosti (SR) jedním z klíčových dokumentů projektu a je zpravidla dodávána za úplatu jako samostatná část projektu. Tudíž je nutné jí věnovat nejméně takovou pozornost, jako studii realizovatelnosti, a to oběma stranami. Implementační studii vypracovává vždy dodavatel SW produktu na základě zjištěných skutečností u uživatele zachycených v SR a dále dle dílčích písemných dohod a smluvních ujednání.
Z uvedených důvodů je uživatel (zákazník) oprávněn striktně trvat na zásadách týkajících se jejího obsahu a formy.
Patří mezi ně zejména stejně jako u SR
· Přiměřená míra srozumitelnosti
· Vysoká grafická úroveň dokumentu
· Vysoká stylizační forma a naprostá gramatická správnost.
· Vysoká přehlednost dokumentu
· Použití dohodnutých grafických standardů
Přes skutečnost, že IS zhotovuje dodavatel SW je výsledný dokument do značné míry kolektivní dílo dodavatele a zákazníka, zejména co do obsahové stránky.
Zásadní rozdíl mezi studií realizovatelnosti a implementační studií lze vyvozovat z těchto typických znaků obou dokumentů:
SR
· mapování současného celkového stavu u zákazníka
· výčet přínosů dosažitelných nasazením SW
· bilance společně definovaných cílů řešených oblastí
· určení rámcových časových ohraničení budoucí realizace
· upozornění na "úzká místa"
IS
· vymezení všech oblastí, které budou nasazením SW řešeny
· detailní postupy jak budou řešeny
· detailní specifikace v jakých termínech budou řešeny
· detailní specifikace všech materiálních prostředků (nástrojů) k dosažení cílového stavu
· detailní specifikace personálního zajištění projektu včetně nasazení jednotlivých osob na řešení
· detailní popis vyřešení vazeb na jiné SW produkty používané zákazníkem
· specifikace vazeb na externí subjekty
· specifikace nestandardních postupů a popis event. překonání problémových míst popsaných v SR
Z uvedeného je zřejmé, že kladla-li si SR jako základní cíl popsat jak to u zákazníka vypadá a co by si přál, pak IS je pokud možno maximálně možným podrobným postupem, jakým způsobem a kdy bude specifikovaných požadavků dosaženo.
Pokud za jistých okolností mohla SR připustit, že projekt nebude dále pokračovat, tj. že obě strany nejsou současně schopny zajistit potřebné podmínky pro realizaci, pak IS již tuto možnost prakticky nepřipouští, neboť vychází z dohody obou stran na realizaci projektu, byť další vývoj prací může přinést i jeho rozsáhlejší modifikaci proti původním cílům deklarovaným ve SR.
Konkrétní podoba IS je určena především dohodnutým řešením se zákazníkem ve smlouvě o zpracování studie realizovatelnosti a dalších dokumentech, jimiž je projekt doprovázen.
Vypracovaná IS je předmětem jednak vnitřní oponentury na straně dodavatele SW a to ještě před předáním zákazníkovi, a dále následně navazující schvalovací procedura u zákazníka.
Schvalovací procedura je zpravidla vícekolový proces, z něhož vznikají akceptací jednotlivých připomínek verze IS.
Dojde-li ke konečné dohodě mezi oběma stranami, je finální verze IS protokolárně předána a stává se závazným dokumentem pro obě strany pro postup nasazení SW produktu.
Od tohoto momentu může být zahájen předem řádně popsaný a zdokumentovaný proces zavádění IS - tj. SW produktu.


Další část článků vychází z předpokladu, že budoucí uživatel učinil strategické rozhodnutí a s tím související kroky:
· podepsal s dodavatelem obchodní smlouvu na vypracování studie realizovatelnosti
· je rozhodnut učinit resp. již zahájil kroky potřebné pro zavedení SW ve firmě dle podmínek stanovených dodavatelem
· je rozhodnut SW zavést a používat v rutinním provozu
Nad výše uvedenými kroky je nezbytné, aby vzali záštitu kompetentní představitelé vrcholového managementu. Proto je vhodné, aby na samém počátku zavádění IS došlo k osobnímu setkání vrcholových představitelů obou stran a např. formou písemného memoranda deklarovali:
· zahájení procesu zavádění IS
· zájem na zavedení s podporou vrcholového managementu obou stran
Podpora vrcholového managementu ze strany zákazníka (uživatele) je klíčovým předpokladem úspěšného zavedení SW produktu ve firmě.
Dosavadní zkušenosti říkají, že tam, kde se jí nepodařilo získat v dostatečné míře, je postup zavádění mnohem složitější.
Zavádění IS jako firemní projekt
Renomovaní dodavatelé SW produktů (obecně) doporučují jejich zavádění formou tzv. firemního projektu
Firemní projekt je charakteristický několika znaky
· vede jej manažer projektu zpravidla jmenovaný vrcholovým vedením firmy
· manažer projektu ve spolupráci s ostatními vedoucími nominuje příslušné odborníky - členy projekčního (realizačního) týmu a to i napříč organizační strukturou
· projekt má svou vlastní formalizovanou dokumentaci (zápisy, protokoly, zprávy........) ukládanou na dohodnutých místech a dohodnutým způsobem
· projekt je dočasný - např. pouze pro určitou etapu implementace SW
· projektové řízení implementace SW je vhodné zrcadlově zavést jak na straně uživatele, tak na straně dodavatele
· projekt je oficiálně iniciován (vyhlášen) a rovněž i ukončen a to písemnou formou
· průběh projektových prací se pravidelně dokumentuje a podávají se informace příslušným vedoucím
Realizační týmy
Jak bylo naznačeno v předchozí části, je vhodné pro zdárný průběh implementace SW produktu stanovit na obou stranách - uživatel i dodavatel tzv. realizační týmy . Týmy sestávají z odborníků obou stran a jsou sestaveny tak, aby zavádění SW proběhlo maximálně možným optimálním způsobem. Žádná ze zúčastněných zpravidla neovlivňuje konkrétní personální obsazení týmu strany druhé.
Dodavatel pouze doporučuje z kterých oborů mají být odborníci nominováni a v jakém počtu, aby byla práce zvládnutelná v plánovaných časech.
Realizační tým na straně dodavatele sestává zpravidla z těchto struktur
· manažer projektu
· garanti odborných oblastí (personální, mzdová, vzdělávání, hodnocení, technická oblast.......)
· řadoví konzultanti (řešitelé dílčích problémů, školitelé ......)
Realizační tým na straně uživatele má zpravidla poněkud jinou strukturu, avšak pro dodržení standardu komunikace je vhodné, aby sestával přibližně z odpovídajících partnerů:
· vedoucí realizačního týmu - manažer projektu uživatele
· odborní pracovníci jednotlivých oblastí řešení - partneři garantů oblastí dodavatele
Protože lze reálně předpokládat, že v průběhu zavádění SW budou vznikat jisté odborné třecí plochy, doporučuje se, aby obě strany ustanovili tzv. řídící výbor (rada) , což je orgán, který je uváděn v činnost pro řešení sporných bodů řešení a rovněž může dohodou obou stran přijímat rozhodnutí o uzavření příslušné etapy projektu.
Členové řídícího výboru se zpravidla rekrutují z členů vrcholového managementu obou stran.
Úvodní projekt - studie realizovatelnosti
Studie realizovatelnosti (SR) je spolu s implementační studií jedním z klíčových dokumentů projektu a je zpravidla dodávána za úplatu jako samostatná část projektu. Tudíž je nutné jí věnovat náležitou pozornost a to oběma stranami. Studii realizovatelnosti vypracovává vždy dodavatel SW produktu na základě zjištěných skutečností u uživatele.
Z uvedených důvodů je uživatel (zákazník) oprávněn striktně trvat na zásadách týkajících se jejího obsahu a formy.
Patří mezi ně zejména
· Přiměřená míra srozumitelnosti - dokument budou posuzovat a používat nejen uzcí specialisté z oboru HR, ale i jiní příslušníci managementu zákazníka.
· Vysoká grafická úroveň dokumentu - formát písma a nadpisů, rozčlenění do kapitol a odstavců, vložené objekty a obrázky apod.
· Vysoká stylizační forma a naprostá gramatická správnost.
· Vysoká přehlednost dokumentu - obsah a rejstřík, pojmenování kapitol a jejich číslování, tematická návaznost, oddělování témat apod.
· Použití dohodnutých grafických standardů - šablony, styly, logo apod.
Konkrétní podoba SR je určena především dohodnutým řešením se zákazníkem ve smlouvě o zpracování studie realizovatelnosti a dalších dokumentech, jimiž je projekt doprovázen.
Rozpočet projektu, smluvní garance dodávky
Jak již bylo dříve několikrát zdůrazněno, je důležité dojednat s dodavatelem nejen celkovou částku, za níž bude IS pořízen, ale i věcnou skladbu rozpočtu tj. jeho relativně detailní specifikaci a rozložení čerpání finančních prostředků v čase. Zákazník zpravidla bude muset postupně vynaložit finanční prostředky na tyto položky:
· Pořízení vlastního SW pro řízení lidských zdrojů tzv. uživatelské licence.
· Pořízení jiného SW, např. operační systém, databázová platforma apod. - většinou od jiného subjektu.
· Pořízení HW vybavení - většinou od jiného subjektu.
· Platby za implementační práce - předem ve smlouvě dohodnuté sazby, pokud se nepracuje za tzv. fixní cenu za celou dodávku.
· Platby za pravidelnou údržbu SW v rámci rutinního provozu.
· Finanční rezerva pro fázi implementace - specifikuje se po dohodě s dodavatelem kvalifikovaným odhadem.
· Finanční strategická rezerva na plánovaný rozvoj systému - např. nové moduly a rozšíření počtu licencí apod.
Tento výčet je odrazovou bází pro stanovení vnitrofiremního rozpočtu, který bude do značné míry po promítnutí do časové osy i platebním kalendářem.
Z pohledu druhé strany tj. dodavatele, je rozpočet a jeho sledování kontrolním nástrojem pro efektivnost jeho vlastního počínání a tím i racionalizačním prvkem ve vztahu k zákazníkovi, neboť obě strany mají zájem na maximální efektivitě spolupráce tak, aby byly finanční prostředky vynakládány maximálně účelně.
Pokud je projekt "rozpočtován" nekvalitně - povrchně, nepřesně, neúplně apod., pak je velmi pravděpodobné, že některá z obou stran (případně obě) se může dostat do potíží a být rozčarována z výsledného efektu ve vztahu k vynaloženým nákladům.
Je zcela běžné, že ve vztahu k vynaloženým finančním prostředkům má zákazník plné právo požadovat určité garance za dodávku IS a jeho komponent. Tyto garance jsou vždy specifikovány obvyklým způsobem v oboru IS/IT a to v obchodní smlouvě. Patří sem zejména:
· Údržba programového vybavení - viz další text.
· Hot -line - viz další text.
· Bezplatná záruka na bezporuchový provoz SW po stanovenou dobu.
· Záruka za bezporuchovost předávacích médií po stanovenou dobu.
· Předání kompletní technické dokumentace pro možné pokračování funkce SW po event. ukončení činnosti dodavatele.
· Přednostní nabídka všech vyšších verzí SW za "zvýhodněné" (rozdílové) ceny.
· Úhradu škod způsobených prokazatelně zaviněným prodlením ze strany dodavatele.
· Záruky za počínání pracovníků dodavatele u zákazníka (implementační a jiné práce) a případné škody vzniklé jejich nedbalostí.
Jisté garance však poskytuje i zákazník dodavateli. Patří sem zejména
· Závazek neposkytovat SW a dokumentaci třetím osobám.
· Neprovozovat SW pro třetí osoby.
· Splnit podmínky určené v závazné provozní dokumentaci a odsouhlasených dokumentech.
· Zajistit kontakt s dodavatelem (přístup dodavatele k SW pro smluvní úkony) a interní správu SW dle ujednání ve smlouvě.
Kvalitní dodavatel zpravidla nabízí zákazníkům smlouvu opatřenou veškerými běžnými garancemi obvyklými pro oblast IS/IT, takže zákazník se zakotvení garancí do smlouvy nemusí domáhat a smlouvu dává pouze ke konzultaci svému právnímu útvaru.
Prováděcí projekt - implementační studie (IS)
Implementační studie (IS) též někdy nazývaná prováděcí projekt, je spolu se studií realizovatelnosti (SR) jedním z klíčových dokumentů projektu a je zpravidla dodávána za úplatu jako samostatná část projektu. Tudíž je nutné jí věnovat nejméně takovou pozornost, jako studii realizovatelnosti, a to oběma stranami. Implementační studii vypracovává vždy dodavatel SW produktu na základě zjištěných skutečností u uživatele zachycených v SR a dále dle dílčích písemných dohod a smluvních ujednání.
Z uvedených důvodů je uživatel (zákazník) oprávněn striktně trvat na zásadách týkajících se jejího obsahu a formy.
Patří mezi ně zejména stejně jako u SR
· Přiměřená míra srozumitelnosti
· Vysoká grafická úroveň dokumentu
· Vysoká stylizační forma a naprostá gramatická správnost.
· Vysoká přehlednost dokumentu
· Použití dohodnutých grafických standardů
Přes skutečnost, že IS zhotovuje dodavatel SW je výsledný dokument do značné míry kolektivní dílo dodavatele a zákazníka, zejména co do obsahové stránky.
Zásadní rozdíl mezi studií realizovatelnosti a implementační studií lze vyvozovat z těchto typických znaků obou dokumentů:
SR
· mapování současného celkového stavu u zákazníka
· výčet přínosů dosažitelných nasazením SW
· bilance společně definovaných cílů řešených oblastí
· určení rámcových časových ohraničení budoucí realizace
· upozornění na "úzká místa"
IS
· vymezení všech oblastí, které budou nasazením SW řešeny
· detailní postupy jak budou řešeny
· detailní specifikace v jakých termínech budou řešeny
· detailní specifikace všech materiálních prostředků (nástrojů) k dosažení cílového stavu
· detailní specifikace personálního zajištění projektu včetně nasazení jednotlivých osob na řešení
· detailní popis vyřešení vazeb na jiné SW produkty používané zákazníkem
· specifikace vazeb na externí subjekty
· specifikace nestandardních postupů a popis event. překonání problémových míst popsaných v SR
Z uvedeného je zřejmé, že kladla-li si SR jako základní cíl popsat jak to u zákazníka vypadá a co by si přál, pak IS je pokud možno maximálně možným podrobným postupem, jakým způsobem a kdy bude specifikovaných požadavků dosaženo.
Pokud za jistých okolností mohla SR připustit, že projekt nebude dále pokračovat, tj. že obě strany nejsou současně schopny zajistit potřebné podmínky pro realizaci, pak IS již tuto možnost prakticky nepřipouští, neboť vychází z dohody obou stran na realizaci projektu, byť další vývoj prací může přinést i jeho rozsáhlejší modifikaci proti původním cílům deklarovaným ve SR.
Konkrétní podoba IS je určena především dohodnutým řešením se zákazníkem ve smlouvě o zpracování studie realizovatelnosti a dalších dokumentech, jimiž je projekt doprovázen.
Vypracovaná IS je předmětem jednak vnitřní oponentury na straně dodavatele SW a to ještě před předáním zákazníkovi, a dále následně navazující schvalovací procedura u zákazníka.
Schvalovací procedura je zpravidla vícekolový proces, z něhož vznikají akceptací jednotlivých připomínek verze IS.
Dojde-li ke konečné dohodě mezi oběma stranami, je finální verze IS protokolárně předána a stává se závazným dokumentem pro obě strany pro postup nasazení SW produktu.
Od tohoto momentu může být zahájen předem řádně popsaný a zdokumentovaný proces zavádění IS - tj. SW produktu.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.
![]() ![]() | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
IT Systems podporuje
Formulář pro přidání akce
Další vybrané akce
15.5. | Konference SCADA Security |
22.5. | Akce pro automobilové dodavatele "3DEXPERIENCE... |
12.6. | Konference ABIA CZ 2025: setkání zákazníků a partnerů... |
29.9. | The Massive IoT Conference |