Příloha č. 4 Smlouvy o dílo
Příloha č. 4 Smlouvy o dílo
Zadavatel: Statutární město Plzeň, xxxxxxx Xxxxxxxxx 0/0, 000 00 Xxxxx, IČ: 00075370
Zhotovitel: S&T CZ, s.r.o., Xx Xxxxx 0000/00, 000 00 Xxxxx 0, IČ: 44846029
OBSAH:
1
1. Harmonogram plnění veřejné zakázky
Činnost / Milník | Zahájení | Dokončení |
Základní dokument projektu | T1 | T2 = T1 + 2 týden |
Schválení základního dokumentu projektu | T2 | |
Kick off projektu | T3 | |
Detailní seznámení se stávajícím stavem a analýza požadavků Vyhlašovatele | T3 | T4 = T3 + 4 týdnů |
Schválení dokumentu Cílový koncept | T4 | |
Realizace projektu | T4 | T5 = T4 + 8 týdnů |
Představení funkčního systému v testovacím prostředí | T5 | |
Funkční a integrační testování | T5 | T6 = T5 + 4 týdnů |
Akceptační testy | T6 | |
Příprava přechodu do produktivního provozu | T6 | T7 = T6 + 4 týdnů |
Spuštění produktivního provozu | T7 | |
Post-implementační podpora | T7 | T8 = T7 + 8 týdnů |
2. Způsob implementace sytémů a architektura systému
2.1 Způsob implementace
K implementaci systému bude využita metodologie ASAP.
Použití této metodiky zaručuje efektivní týmové vypracování zadání pro nastavení systému již na úrovni projektového záměru v první fázi projektu (tvoří součást Základního dokumentu projektu) a jeho detailní upřesnění ve druhé fázi projektu – Cílový koncept.
Systém bude implementován projektovým týmem a to na základě schválené Definice projektu a schváleného Cílového konceptu projektu implementace. Jednotlivé fáze projektu budou protokolárně uzavírány na základě akceptačního protokolu.
Projekt bude probíhat v následujících fázích, které se vzhledem k množství práce a termínu dokončení mohou u některých činností překrývat:
▪ Příprava projektu
▪ Cílový koncept
▪ Realizace a testování
▪ Příprava produktivního provozu
▪ Podpora produktivního provozu
Fáze 1: Příprava projektu
Účelem této fáze je počáteční plánování a příprava projektu. Výstupním dokumentem je dokument Žákladní document projektu, který také definuje rozpočet zdrojů potřebných k realizaci (finance, lidé, technika atd.).
Fáze Příprava projektu se stává z následujících pracovních kroků:
▪ řízení projektové fáze,
▪ úvodní plánování projektu,
▪ postupy projektu,
▪ zahájení projektu,
▪ plán technických požadavků.
Fáze 2: Cílový koncept
Účelem této fáze je vytvořit dokument Cílový koncept, který zachycuje výsledky jednání projektového týmu a popisuje cílový stav řešení informačního systému. V rámci analýzy stávajícího stavu proběhne místní šetření. Na základě shromážděných informací sestavíme definici jednotlivých procesů s osobami odpovědnými za centralizaci jednotlivých oblastí. Bude provedena analýza nejen věcného obsahu a očekávaných procesů, ale také doporučení technologií, které by pro jednotlivé aplikace byly přínosem pro uživatele, a zároveň umožnily dlouhodobý rozvoj. Po schválení Cílového konceptu se tento stává základním dokumentem pro další fáze projektu a dle něho se provádí implementace.
Během této fáze se také:
▪ dále upřesňuji původní cíle projektu,
▪ upřesňuje se základní rozsah,
▪ detailněji se definuje celkový harmonogram projektu a pořadí implementace.
Tato fáze obsahuje následující pracovní kroky:
▪ řízení projektové fáze Cílový koncept,
▪ školení projektového týmu pro fázi Cílový koncept,
▪ vytvoření prostředí pro systém,
▪ podniková organizační struktura,
▪ definování podnikových procesů,
▪ definování konverzí a rozhraní.
Fáze 3: Realizace
Cílem této fáze je implementovat požadavky a procesy projektu implementace informačního systému na základě schváleného Cílového konceptu a uskutečnit funkční a integrační testy implementovaného systému na základě předem připravených testovacích scénářů. Jak doporučuje metodika ASAP, testovací scénáře jsou připravovány stranou Vyhlašovatele, neboť tento nejlépe zná své podnikové prostředí, dotčené procesy a vhodná reprezentativní testovací data.
Tato fáze obsahuje následující pracovní kroky:
▪ řízení projektové fáze Realizace a testování,
▪ školení projektového týmu pro fázi Realizace a testování,
▪ základní nastavení a jeho schválení,
▪ správa systému,
▪ vypracování převodních programů,
▪ vypracování aplikačních programů pro rozhraní,
▪ vypracování eventuálních rozšiřujících programů,
▪ stanovení koncepce oprávnění,
▪ příprava testovacích scénářů klíčovými uživateli,
▪ nastavení testovacího prostředí tak, aby maximální možnou měrou odpovídalo nastavení produktivního prostředí
▪ provedení funkčních testů systému
▪ opravy a optimalizace systému na základě výsledků provedených testů
▪ provedení integračních a akceptačních testů systému
Fáze 4: Příprava produktivního provozu
Účelem této fáze je ukončit celou přípravu, včetně testování, školení uživatelů a připravit systém k uvedení do produktivního provozu. Tato fáze závěrečné přípravy slouží také k dořešení otevřených otázek. Po úspěšném zakončení a akceptaci je možné začít s provozem produktivního systému.
Tato fáze obsahuje následující pracovní kroky:
▪ řízení projektové fáze Příprava produktivního provozu,
▪ detailní plánování projektu,
▪ školení koncových uživatelů,
▪ předání technické dokumentace, užuvatelské dokumentace a školících materiálů
▪ nastavení produktivního prostředí (provedení testu systému, realizace systému oprávnění v produktivním provozu, atd.),
▪ přenos veškerého vývoje z testovacího prostředí do prostředí produktivního,
▪ přechod do produktivního systému - převod kmenových dat,
▪ definování řešení problémů ve fázi Produktivního provozu a jeho podpory.
Fáze 5: Produktivní provoz a podpora
Účelem této fáze je podpora uživatelů nejen pro první kritické dny produktivního provozu, ale i v dlouhodobém výhledu. Proto musí být vybudován systém podpory uživatelů, který efektivně podpoří bezproblémový produktivní provoz systému. Během této fáze je nutno též provádět optimalizaci systému. Provádí se též monitorování systémových transakcí k optimalizaci celkového výkonu systému. V závěru této fáze je projekt protokolárně uzavřen a předán.
Pracovní kroky:
▪ podpora produktivního provozu,
▪ příprava uživatelské a technické dokumentace,
▪ činnosti po startu produktivního provozu.
2.2 Existence základních dokumentů, dokumentovaný průběh implementace
Fáze | Dokument | Stručný popis obsahu dokumentu |
Definice projektu | Základní document projektu | Jsou definovány zejména cíle projektu, akceptační kritéria, zodpovědnosti členů týmu a komunikační matice |
Cílový concept | Cílový koncept | Analýza stávajícího řešení, návrh TO BE cílového stavu řešení, včetně schematu architektury systému a návrhu technického řešení |
Realizace a testování | Testovací scénáře | Popis a pořadí kroků vedoucích k provedení funkčních/intergačních testů, včetně očekavaných vstupů a výstupů systému. Vytváří klíčoví uživatelé Zadavatele. |
Protokol o testování | Protokol o průběhu a skutečném výsledku provedených testů. Vytváří klíčoví uživatelé Zadavatele. | |
Příprava produktivní ho provozu | Plánování | Switch-over plan - plán startu produktivního provozu Plán školení koncových uživatelů klíčovými uživateli |
Všechny fáze | Zápis z jednání | Zápis z proběhlých jednání obsahující popis diskutovaných témat, přijatých závěrů/opatření a seznam úkolů včetně přiděleného řešitele |
Změnový požadavek | Popis požadavku vzniklého v rámci změnového řízení |
3. Metoda organizace a řízení projektu
3.1 Navrhovaný způsob řízení realizace veřejné zakázky
Na nejvyšší hierarchické úrovni organizační struktury bude řídící výbor, který je obvykle tvořen pracovníky managementu na straně Uchazeče i Vyhlašovatele. Řídící výbor rozhoduje o zásadních otázkách projektu (zahájení, ukončení projektu, schválení jednotlivých fází projektu).
Členem řídícího výboru je sponzor projektu, který dozoruje projekt za stranu Vyhlašovatele.
Nižší organizační úroveň projektu představují vedoucí projektu na straně Vyhlašovatele i Uchazeče. Jejich hlavní úlohou je řízení a koordinace činností jednotlivých týmů projektu. Při své činnosti jsou podřízení řídícímu výboru projektu, pro který připravují sumární report o postupech prací na projektu za dané období.
Úlohy vedoucího projektu:
▪ Vypracovávat status projektu pro řídící výbor
▪ Koordinovat práce jednotlivých týmů
▪ Činit rozhodnutí do úrovně své kompetence
▪ Sledovat změnové požadavky
▪ Sledovat dodržování harmonogramu projektu
▪ Sledovat čerpání kapacit
▪ Kontroluje vypracování dokumentu analýzy řešení
Jednotliví členové týmu budou zodpovědní za realizaci dílčích úloh na projektu. V čele týmu bude za stranu Uchazeče vedoucí projektu. Za stranu Vyhlašovatele bude v týmu definovaný klíčový uživatel se znalostí za určenou oblast.
3.2 Existence a způsob řízení kvality
Při analýze stávajícího stavu a návrhu optimálního řešení se budeme snažit v maximální míře vyvarovat vniku případných konfliktních stavů. Z toho důvodu navrhujeme pravidelné svolávání tzv. Hlavního týmu projektu, kde budou za účasti zástupců všech týmů ze strany Vyhlašovatele i Uchazeče:
▪ kontrolovány a řešeny aktuálně rozpracované úlohy projektu
▪ řešeny integrační vazby mezi jednotlivými úlohami a týmy
▪ kontrolováno průběžné plnění termínů a předcházení termínovým kolizím
Řešení konfliktů, které vzniknou během projektu, navrhujeme řešit v závislosti na fázi projektu.
V rámci všech fází před spuštěním produktivního provozu navrhujeme využití postupů dle metodiky ASAP. Tzn. jednotlivé konflikty budou eskalovány přesně dle organizační struktury projektu:
▪ z úrovně vedoucích týmů na vedoucí projektu,
▪ úrovně vedoucích projektu na řídící výbor.
Za průběžný monitoring a kontrolu realizace projektu na každodenní bázi jsou zodpovědní všichni členové projektového týmu, zejména však vedoucí projektu.
V rámci procesu řízení kvality projektu budou sledovány následující záležitosti:
▪ včasná informovanost zainteresovaných osoby
▪ realističnost plánů a jejich dosažitelnost
▪ rozsah projektu je jasně definován a komunikován
▪ obchodní, personální a technologická rizika jsou včas identifikována a efektivně řešena
▪ alokované zdroje do projektu musí být včas informovány o požadavcích a je zajištěna jejich
dostupnost
▪ požadované schvalování a akceptace dokumentů je prováděno bez zbytečných průtahů
3.3 Existence a způsob řízení rizik
Analýza, evidence rizik a jejich sledování je součástí řízení projektu.
Rizikové faktory (obecně)
▪ Dostupné kapacity, zdroje projektu
▪ Nedostatečná součinnost jednotlivých členů týmu, procesních týmů
▪ Nedostatečné podklady pro analýzu
▪ Přístup do stávajících systémů
Proces řízení rizik na projektu
Plánování řízení rizik
Řízení rizik bude na pořadu jednání pravidelných schůzek o stavu projektu, avšak může existovat potřeba svolávat zvláštní pracovní porady za účelem vyhodnocení a řízení určitého rizika. Vedoucí projektu shrne vyhodnocení rizika provedené projektovým týmem a v případě potřeby aktualizuje registr rizik.
Identifikace rizik
Identifikace rizik znamená stanovení nejistot, které mohou mít potenciálně negativní následky na projekt. Tuto aktivitu je třeba začít provádět průběžně od zahájení projektu a provádět po celou dobu projektu.
Po prvotní identifikaci rizik projektu budou všichni členové projektového týmu odpovědní za
identifikaci potenciálních rizik ve své oblasti, za kterou odpovídají a za upozornění ostatních členů
projektového týmu na tato rizika během týdenních schůzek projektového týmu, nebo individuálně projektového manažera, pokud bude hrozit nebezpečí z prodlení.
Výstupem procesu identifikace rizik je zpracování a aktualizace registru rizik, včetně vyhodnocení míry rizika. Toto vyhodnocení se provádí na úrovni projektového týmu a výsledek je zaznamenán formou protokolu.
Analýza rizik
Analýza rizik bude průběžným procesem, prováděným po celou dobu trvání projektu. Každé identifikované riziko bude zaznamenáno v registru rizik. Pro účely analýzy rizik se bude zaznamenávat:
▪ identifikace rizika
▪ popis rizika
▪ druh dopadu a pravděpodobné datum dopadu
▪ pravděpodobnost rizika
▪ potenciální a pravděpodobné náklady s rizikem spojené
▪ priorita rizika
Řešení rizik
Proces řešení rizik definuje postupy, které identifikovaná rizika ošetřují tak, aby jejich negativní dopady na projekt byly minimalizovány a projekt byl s vysokou pravděpodobností úspěšně realizován.
Je třeba mít strategii preventivních opatření, které mohou zajistit, že dané riziko nenastane.
V případě, že riziko přesto nastane, použijeme následující strategie řešení rizik:
▪ Eliminace rizika
▪ Princip spočívá v nalezení jiného řešení dané situace, které riziko vyloučí nebo minimalizuje
▪ Optimalizace
▪ Při této strategii se snažíme nalézt opatření, která snižují dopady rizika na projekt.
▪ Zajištění transferu (přenesení) rizika
▪ Tato strategie řeší přenesení dopadů rizika na „třetí stranu“ např. pojištění. Je nutno si uvědomit, že v případě, že riziko nastane, může se do projektu promítnout komplikace z tohoto rizika.
Kontrola rizik:
Pokud máme provedenu identifikaci možných rizik, je nutno průběžně tyto rizika kontrolovat, protože
v průběhu implementace mohou nastat události, které mění charakter rizika. Proto se musí provádět:
▪ Pravidelná revize rizikových faktorů na Řídícím výboru
▪ Revize výstupů projektu
▪ Revize harmonogramu
▪ Minimalizace změnových požadavků, které jsou zdrojem rizik
3.4 Existence a způsob řízení změn
Změny v průběhu projektu jsou identifikované odpovídajícím klíčovým uživatelem týmu.
Následně musí být změnový požadavek zaznamenán do dokumentu Změnový požadavek, který vypracovává klíčový uživatel Vyhlašovatele do předem definovaného formuláře. Při vypracování změnového požadavku spolupracuje s odpovědným konzultantem Uchazeče (upřesňuje zadání, pomáhá s vypracováním algoritmu atd).
Vypracovaný změnový požadavek předává vedoucí týmu Vyhlašovatele vedoucímu projektu Uchazeče, který provede ocenění pracnosti a zjištění reálného termínu realizace, popř. stanoví prioritu řešení jednotlivých požadavků.
Takto vypracovaný změnový požadavek předává vedoucí projektu Uchazeče řídícímu výboru (ŘV) ke schválení.
Po schválení změnového požadavku v ŘV, předá vedoucí projektu Uchazeče změnový požadavek k realizaci příslušným konzultantům k realizaci. Vedoucí projektu Uchazeče eviduje stav jednotlivých ZP a následně kontroluje práci na realizaci daného změnového požadavku a případně se účastní testovacích prací spojených se změnovým požadavkem.
Pravidla změnového řízení | ||||||
Činnost | Vyhlašovatel | Uchazeč | ||||
Identifikace ZP | klíčový uživatel týmu - provádí | |||||
Konzultace požadujícími změnu | s osobami | klíčový uživatel týmu - provádí | poradce - součinnost | |||
Vytvoření dokumentu ZP | klíčový uživatel týmu - provádí | poradce - součinnost | ||||
Ocenění pracnosti ZP | - | vedoucí projektu - provádí | ||||
Zjištění reálného realizace | termínu | - | vedoucí projektu - provádí | |||
Předání ZP ke schválení | - | vedoucí projektu - provádí | ||||
Rozhodnutí o schválení | ŘV – provádí | ŘV – provádí | ||||
Předání ZP k realizaci | - | vedoucí projektu - provádí | ||||
Realizace ZP | - | poradci | ||||
Testování ZP | členové provádí | odborného | týmu | - | poradci – součinnost | |
Předávací protokol ZP | vedoucí projektu - schvaluje | vedoucí projektu vypracovává, schvaluje | – | |||
4. Záruční doba
Uchazeč poskytne na vytvořené dílo záruční dobu ve výši 24 měsíců, přičemž tato záruční doba bude v souběhu s řádně uzavřenou servisní smlouvou. Po dobu záruční doby bude Uchazeč Vyhlašovateli zdarma odstraňovat vady systému.
Položka | Údaje vyplněné Uchazečem |
Nabízená délka záruční doby | 24 měsíců |
Rozsah a podmínky záruky | Záruka se nevztahuje na chyby ve standardu systému SAP. Záruka se nevztahuje na chyby v systémech/aplikacích třetích stran integrovaných s implementovaným řešením. Záruka se nevztahuje na chyby způsobené chybami v systémech/aplikacích třetích stran integrovaných s implementovaným řešením. Záruka se nevztahuje na chyby způsobené změnami v systémech/aplikacích třetích stran integrovaných s immplementovaným řešením. Např. po upgradech těchto systémů, aplikací patchů apod. Záruka se nevztahuje na chyby v programech, do nichž po provedených integračních testech provedla zásah osoba, kterou tímto nepověřil dodavatel implementovaného řešení. |
5. Předpoklady pro úspěšné splnění dodávky
Seznam předpokladů pro úspěšné splnění dodávky:
▪ Vyhlašovatel poskytne potřebnou součinnost ve všech fázích projektu. Spočívat bude zejména v poskytování informací o stávajícím nastavení systémů, o podnikových procesech souvisejících s implementovaným řešením, typech technologií, v účasti na kontrolních dnech projektu, na jednáních jednotlivých týmů a atd.
▪ Vyhlašovatel zajistí jednotný tým klíčových uživatelů, který se bude scházet s konzultanty Uchazeče, a jednoho odborného vedoucího týmu, který bude mít kvalifikaci a potřebné rozhodovací pravomoci. Tento odborný vedoucí týmu bude i centrálním kontaktem pro odpovědného konzultanta Uchazeče, s rozhodujícím slovem při definici řešení a procesů.
▪ Zřízení vzdáleného přístupu pracovníků Uchazeče do sítě Vyhlašovatele.
▪ Zřízení přístupu pracovníků Uchazeče k dotčeným systémům Vyhlašovatele, a to včetně potřebných oprávnění, vývojářských klíčů apod.
▪ Vyhlašovatel připraví testovací scénáře a testovací data pro provedení funkčních a integračních testů řešení a take zajistí zaškolení koncových uživatelů. Uchazeč k tomuto poskytne potřebnou podporu.
▪ Vyhlašovatel zajistí nebo zakoupí dostatečný počet SAP licencí
▪ Vyhlašovatel zajistí HW infrastrukturu potřebnou pro provoz webových aplikací běžících v systému SAP (např. server, síťové propojení, firewallové prostupy, SSL certifikáty apod.).
▪ Pro funkční integraci Active Directory do implementovaného portálu je nutné, aby Vyhlašovatel zajistil integraci Active Directory do systému SAP.
6. Závazné poskytnutí projektového týmu
6.1 Složení projektového týmu
Uchazeč se zavazuje, že poskytne Vyhlašovateli projektový tým ve struktuře podle níže uvedené
tabulky.
Role pracovníka | Jméno pracovníka |
Vedoucí projektu | Xxxx Xxxxx |
Technik implementace | Xxxxx Xxxxxx |
Technik implementace | Xxxx Xxxxxxxx |
Technik implementace | Xxxxxx Xxxxx |
Technik implementace | Xxx Xxxxxxxxxx |
Uchazeč dále prohlašuje a podpisem Nabídky řešení potvrzuje, že:
▪ si je vědom, že jednacím jazykem projektu je český jazyk a zajistí komunikaci s
Vyhlašovatelem v českém jazyce;
▪ zajistí dostatečnou disponibilní kapacitu všech pracovníků pro realizaci Xxxxxxx u
Vyhlašovatele;
▪ pracovník, který zastává roli určitého specialisty, bude při realizaci Xxxxxxx u Vyhlašovatele využit současně pro maximálně dvě role;
▪ všichni pracovníci projektového týmu byli vyškoleni v metodě vedení projektu, která je navrhována pro realizaci Xxxxxxx;
▪ v případě, kdy se některý z pracovníků týmu, nebude moci ze závažných důvodů na realizaci Zakázky podílet, nahradí tohoto pracovníka jiným pracovníkem s obdobnou odbornou kvalifikací a zkušeností a po řádném převzetí, avšak vždy po předchozím oznámení Uchazeče a pouze se souhlasem Vyhlašovatele, přičemž Vyhlašovatel má právo si tyto skutečnosti ověřit.
7. Popis nabízeného řešení
7.1 Popis navrhované architektury
Zaměstnanecký portál bude implementován v prostředí SAP Fiori jako sada standardních webových
FIORI SAPUI5 aplikací.
Celé řešení se skládá ze 4 komponent:
▪ Back-end server
• Stávající systém SAP ERP, případně SAP BI
• Zdroj dat všech aplikací portálu
• Z bezpečnostních důvodů tento server nebude zpřístupněn do internetu
▪ Front-end server
• Systém SAP NetWeaver Gateway
• Na tomto systému budou provozovány všechny SAPUI5 aplikace zaměstnaneckého portálu
• Systém komunikuje s back-serverem prostřednictvím RFC spojení
• Z bezpečnostních důvodů tento server nebude zpřístupněn do internet
▪ Webdispatcher
• Systém sloužící ke zpřístupnění front-end serveru do internet
▪ Klient
• Webový prohlížeč, prostřednictvím něhož uživatelé portálu spouští webové aplikace
na front-end serveru (použitý protocol: HTTPS).
Navrhovaná architektura uvedená v zadávací dokumentaci nepočítá s oddělenou instalací back-end a front-end serveru. Resp. počítá s tím, že roli back-end a front-end serveru bude zastupovat 1 systém – stávající SAP ERP (případně SAP BI). Toto řešení však nedoporučujeme, a to hlavně z bezpečnostích důvodů. Systém SAP ERP (resp. SAP BI) by musel být zpřístupněn do internetu, z čehož plynou určitá bezpečností rizika. Technicky ale zadané řešení možné je a uvedené rozdíly v návrhu architektury nemají vliv na funkční obsah řešení.
Z důvodu srovnatelnosti nabídek v základní verzi nabízíme a oceňujeme architekturu dle zadání.
Variantně doporučujeme zvážit řešení, které počítá s tím, že by stávající systémy byly od internetu odděleny webdipatcherem a front-end serverem. Navíc toto řešení umožňuje patchování front-end serveru nezávisle na back-end serveru. Součástí tohoto řešení je instalace nových systémů (SAP NW Gateway, SAP Webdispatcher) ve všech 3 prostředích (DEV, QAS, PRD).
Součástí dodávky není dodávka HW vybavení nutného pro provoz nově instalovaných systémů.
7.2 Popis navrhovaného řešení
Základ řešení se opírá o standardní SAP Fiori aplikace. Ty mohou být následně na základě separátní Objednávky rozšířeny dle zákaznických požadavků.
Seznam předpokládaných Fiori aplikací k implementaci:
Požafovaná funkcionalita | Fiori App (Fiori 2.0) | |
Osobní data, profil zaměstnance | Osobní profil zaměstnance – souhrnný přehled | My Profile |
Xxxxx, příjmení, titul, datum narození | My Personal Data | |
Bydliště | My Addresses | |
Stav | My Personal Data | |
Rodinní příslušníci | My Family Members | |
Bankovní účet | My Bank Details | |
Povinné zdravotní prohlídky | My Profile | |
Absolvovaná předepsaná školení | My Profile | |
Kvalifikace a schopnosti | My Profile | |
Data platového výměru, včetně historie | My Profile | |
Výplatní páska | My Paystubs | |
Žádost o nepřítomnost, schválení | Žádost o nepřítomnost | My Leave Request |
Schválení nepřítomnosti | Approve Leave Requests | |
Kalendář týmu / odboru | My Team Calendar | |
Časová data / docházka | Docházka | My Timesheet |
Schválení docházky | Approve Timesheets | |
Žádost o služební cestu evidence a schválení cestovních výkazů | Žádost o pracovní cestu | My Travel Request |
Schválení žádosti | My Inbox - Approve Travel Requests Approve Travel Requests | |
Vyúčtování pracovní cesty | My Travel and Expenses | |
Schválení vyúčtování | My Inbox - Approve Travel Expenses Approve Travel Expenses | |
Osobní data – profil zaměstnace: poptávané služby jsou kumolovány v osobním profilu zaměstnance, případně je možné je mít jako separátní Fiori aplikace. V případě změny údajů ze strany zaměstnance, které lze povolit nebo zakázat, lze ukládat záznamy jako blokované a až po kontrole odborným útvarem uvolnit k ostrému použití. Zdravotní prohlídky jsou řešeny formou kvalifikací a tedy se zobrazují v kvalifikačním profilu zaměstnance / profilu požadavků na plánované místo.
Výplatní páska: vzhled výplatní pásky vychází ze standarní pásky v SAP a je možné jej tisknout / ukládat v pdf formátu. Standardně se výplatní páska za aktuální období zobrazí ve výplatním termínu, v exitu toto datum lze řídit jiným způsobem.
Žádosti o nepřítomnosti / schválení: standardní aplikace umožňuje v žádat o nepřítomnost podle nastavení a zobrazuje zůstatky jednotlivých drhů kontingentů z infotypu 2006. Po schválení nepřítomnosti probíhá zápis do nepřítomností v infotypu 2001.
Kalendář týmu / odboru: aplikace umožňuje náhled členy vlastní organizační jednotky pro její jednotlivé členy.
Časová data / docházka: pro evidenci docházky byla navržena aplikace My Timesheet, která umožňuje zobrazovat a upravovat data nepřítomností (které nebyly pořízeny přes žádosti o nepřítomnosti).
Evidence docházky je v každé organizaci velmi individuální a nelze tedy vyloučit, že při detailní analýze požadavků bude zjištěna potřeba jiného řešení, což může mít vliv na pracnost implementace tohoto požadavku.
Žádost o služební cestu / schválení: aplikace umožňuje podávat žádost o služební cesty (tuzemské i zahraniční). Žádosti vždy přes Fiori zakládá zaměstnanec a manažer je schvaluje.
Aplikace vyžaduje nastavení komponenty SAP ERP Žádosti o pracovní cesty.
Vyúčtování služební cesty / schválení: aplikace umožňuje podávat zaměstnancům vyúčtování služebních cest (tuzemských i zahraničních) a následné vyúčtování se zaměstnancem ve mzdě (doplatek / srážka) a zaúčtování cestovních náhrad
Fiori aplikace vyžaduje nastavení komponenty SAP ERP Pracovní cesty. Tato komponenta je velmi komplexní a nelze tedy vyloučit, že při detailní analýze požadavků bude zjištěna potřeba, které budou mít vliv na pracnost implementace tohoto požadavku.
8. Popis licenčního modelu
Popis, seznam a cena nabízeného programového vybavení potřebného pro dodávku a zprovoznění zaměstnaneckého portálu, implementace díla a produktivní provoz:
Material no: | popis licence | počet licencí | cena licence |
7001126 | SAP Business Suite Employee User | 261 | 893 889 Kč |
7011045 | SAP Manager Self-Service User | 1 | 5 137 Kč |
Database DB2 Enterprise Server Edition f. LUW | 1 | 134 854 Kč | |
TOTAL | 1 033 881 Kč | ||
Popis, seznam a cena nabízeného programového vybavení potřebného pro dodávku a zprovoznění zaměstnaneckého portálu a implementace díla a produktivní provoz při odebrání nižšího počtu licencí:
Material no: | popis licence | počet licencí | cena licence |
7001126 | SAP Business Suite Employee User | 150 | 847 654 Kč |
7011045 | SAP Manager Self-Service User | 1 | 8 477 Kč |
Database DB2 Enterprise Server Edition f. LUW | 1 | 127 879 Kč | |
TOTAL | 984 009 Kč | ||