Závěrečný CASE Implementace IS/ICT d pdniku návrh řešení IS/ICT pstavenéh na pen surce ERP/CRM balíku COMPIERE Tým S11: Hrník Jiří (xhrj37@vse.cz) Měska Matěj (xmesm05@vse.cz) Mihulka Martin (xmihm01@vse.cz)
Obsah Manažerské shrnutí... 3 Shrnutí sučasnéh stavu dle zadání...4 Přestavení ERP/CRM Cmpiere...5 Open surce a jeh výhdy...5 Obecná charakteristika Cmpiere... 6 Reference a kmpetence S11... 6 Shrnutí výhd Cmpiere pr...7 Nasazení Cmpiere na prcesy zákazníka... 8 Řešení jedntlivých blastí se systémem Cmpiere... 8 Příklad reprtu...10 Příklad BPR knkrétníh prcesu...11 Kncepce řešení... 12 Metdika S11 Cmpiere Implementatin Methdlgy... 12 Architektura buducíh řešení... 13 Scénář a harmngram implementace... 16 Organizační struktura prjektu...20 Zajištění prjektu smluvami...20 Parametry SLA...20 Pžadavky na sučinnst... 21 Pužité standardy a nrmy...22 Kalkulace ceny řešení... 24 LS 2005/2006 Strana 2 (celkem 26) VŠE Praha
Manažerské shrnutí Ddělat, neb vypustit. Shrnuje rzsah prjektu, c se bude řešit, klik t bude stát a jaku sučinnst vyžadujeme. Jaké přínsy se čekávají. V pdstatě t nahrazuje závěr. Měl by t dpvídat cca tmu, c budeme říkat při prezentaci. LS 2005/2006 Strana 3 (celkem 26) VŠE Praha
Shrnutí sučasnéh stavu dle zadání Firma má tři ddělené lkality (Centrum, závd Alfa a závd Beta). V těcht lkalitách existují různé aplikace pr různé úlhy. Prblémem je (krmě drbných chyb v sučasných prgramech) především dezintegrace jedntlivých systémů. Ta se ptm prjevuje v neefektivní kmunikaci mezi závdy a centrem, nejedntnsti evidence, nemžnsti sdílet infrmace apd. Kmunikace uvnitř firmy prbíhá pmcí telefnu a e-mailu nestandardizvaná. Administrativa je zpmalvána velkým pdílem ruční práce (např. reprty) a znepřehledňvána velkým pčtem ddělených evidencí. Pužívané aplikace jsu následující: Duble účetní prgram tvřící páteř eknmickéh systému firmy. Baláš, Premiér, Prgram dcházka sftware pužívaný persnalisty (3 různé prgramy) MS Excel pmcné evidence (velké mnžství) MS Wrd textvý editr (někde i psací strj) Amipr DTP a textvý editr (speciální dkumenty) Fxpr speciální evidence (legacy?) EVI kmplexní evidence dpadů (není integrace s statními kmpnentami ruční přepisvání dat) EJSD Intrastat + cl speciální aplikace (není integrace ruční přepisvání dat) Hlavním cílem zavedení nvéh IS/ICT je sjedncení vnitrfiremní administrativy vytvřením jasných pravidel a její autmatizace pmcí infrmačních technlgií. Eliminací ruční práce při předávání infrmací (mezi aplikacemi i lidmi) bude dsažen úspry nákladů na administrativu. LS 2005/2006 Strana 4 (celkem 26) VŠE Praha
Přestavení ERP/CRM Cmpiere Open surce a jeh výhdy Vzhledem k tmu, že námi nabízený balík patří d kategrie tzv. pen surce sftware a naše firma se specializuje na pdpru pen surce sftware, pvažujeme za důležité nejprve uvést základní charakteristiky tht velmi perspektivníh mdelu ddávek sftware. Základní myšlenku pen surce je, že zdrjvý kód prgramu je zdarma pskytnut veřejnsti k libvlnému účelu (kmpilace, úpravy ). Kdkli, kd má ptřebné znalsti může prgram zdarma pužívat a upravvat. Prtže tt ptřebné knw-hw nemají firmy, které se přím nezabývají IT (jak jsu České slévárny s.r..), vzniká na trhu prstr pr systémvé integrátry (jak je S11). Služby těcht integrátrů jsu ptm již placené (stejně jak u ne-pen surce balíků stále je ale cena řešení levnější SW licence). Těmit službami se myslí například analýzy, BPR, zakázkvé prgramvání, šklení uživatelů, service desk apd. Asi největší výhdu pen surce sftware je t, že zákazník má přím k dispzici zdrjvý kód (dle metdiky S11 i s vývjářsku dkumentací) k veškerému ddanému SW (i k zakázkvě dprgramvaným mdulům). Tent fakt dává zákazníkvi unikátní nezávislst na systémvém integrátrvi i výrbci. Umžňuje mu ttiž kdykli přejít k jinému subjektu, případně nechat si jinde zakázkvě dprgramvat část funkcinality třeba za 10 let. Pzn. metdika S11 CIM rzděluje prjekt implementace d etap, které vždy knčí ddávku určitéh díla, včetně fakturace. P každé fázi zákazník dstává pužitelný výstup (analýzu, funkční mdul, uživatelsku příručku atd.). V krajním případě je tak mžné měnit ddavatele i v průběhu prjektu, cž umžňuje i případná smluva. Eliminván je také rizik zániku výrbce. Pkud budete ptřebvat další funkcinalitu, úpravu vyplývající ze změny legislativy atd., nemusíte čekat na nvý release d výrbce, můžete si jej nechat kdykli d khkli dprgramvat. Díky tmu, že OSS (pen surce sftware) vyvíjejí stvky nezávislých vývjářů, je vždy rganicku sučástí vývje ddržvání standardů. Tent fakt dává OSS výhdu maximální mžné tevřensti a tím integrvatelnsti a interperability. V dalším textu bychm rádi uvedli a vyvrátili některé mýty OSS, které mhu neprávem budit pchybnsti jeh využití v prfesinálních aplikacích. OSS je méně kvalitní a uživatelsky nepřívětivý jak ddavatel OSS za jeh kvalitu zákazníkům ručíme. Námi ddávaný sftware je před uvedením v naší nabídce analyzván na úrvni zdrjvéh kódu a testván z uživatelskéh hlediska. OSS je amatérsky lkalizván za kvalitu lkalizace zákazníkvi pět ručíme smluvu. Lkalizaci prvádíme ve splupráci s dbrníky na česku legislativu a pdrbujeme testvání (i v případě jazykvé lkalizace). Pr OSS není technická pdpra technicku pdpru můžete získat na našem service desku 24/7 (něklik úrvní pdpry), neb zdarma v diskusních fórech, kmunitních webech a dalších vlně dstupných zdrjích. LS 2005/2006 Strana 5 (celkem 26) VŠE Praha
Obecná charakteristika Cmpiere P stručném úvdu d prblematiky OSS bychm nyní rádi stručně představili ERP/CRM balík Cmpiere. Cmpiere [kmpjere z italštiny splnit ] je americký balík ERP/CRM 1, který je jak OSS dstupný zdarma. Jedná se jeden z nejrzšířenějších a nejprpracvanějších OSS ERP systémů, cž dkládá i 1 milin dwnladů zdrjvéh kódu. Zralst tht systému umžňuje jeh bezprblémvé nasazení v pdnicích, a t bez zvýšených rizik a s velmi příznivými TCO (Ttal Cst f Ownership). Cmpiere je zalžen na technlgiích Java, cž umžňuje jeh platfrmní nezávislst (běží všude, kde lze nainstalvat JVM a JBss (pen surce) server). Je mžné h prvzvat v hetergenních prstředích na Vaší stávající infrastruktuře. Řešení je plně databázvě nezávislé. Lze prvzvat např. s databázemi Firebird (zdarma), neb Oracle (pr velmi rzsáhlá řešení) a s dalšími. Krmě ERP a CRM dispnuje další funkcinalitu PRM (prdej přes partnery), SCM (řízení ddavatelů), OLAP (BI manažerské analýzy), HRMS (persnalistika), E-cmmerce (B2B i B2C webvé sambsluhy), pdpra řízení prjektů a wrkflw. Veškerá funkcinalita je v prgramu rganizvána prcesně a integrvána. Systém navíc bsahuje vlastní vývjvý framewrk, který usnadní rzšiřvání funkcinality. Můžete tedy na jedné straně získat světvé prcesní knw-hw, ale na druhé straně nepřijdete knkurenční výhdu vyplývající z unikátnsti Vašich prcesů. K aplikaci lze přistupvat pmcí tenkéh klienta (Java), neb webvéh rzhraní (prhlížeč) přes internet. Tt řešení umžňuje prvz aplikace a databáze centralizvaně (umístění v datacentru) a přístup uživatelů přes internet z jakéhkli místa na světě. Tímt dpadne zákazníkvi starst správu serveru a aplikace a zvýší se mbilita například bchdníků i dalších zaměstnanců. Vyžadvána je dbrá dstupnst přístupvých linek (d internetu) na straně zákazníka t však již dnes není větší prblém. Výhdu je ptm n-line prvz a práce puze s jedněmi aktuálními daty. Reference a kmpetence S11 S11 je firma, která se věnuje pdpře a ppularizaci pen surce sftware v českém bchdním prstředí. Mim jiné se zabýváme lkalizací nejlepších světvých pen surce řešení, které ptm implementujeme u našich zákazníků. K těmt řešením pskytujeme všechny běžné služby jak je analýza, BPR (business prcess reengineering), zakázkvé prgramvání, šklení uživatelů, pdpra v rutinním prvzu a rzvj systému. Mezi našimi zaměstnanci jsu zkušení prject manažeři, analytici, knzultanti a vývjáři s praxí z předních českých i světvých IT firem. Máme vyvinutu vlastní metdiku IT prjektů, která je zalžena na maximální škálvatelnsti našich kapacit a na myšlence, že zákazník má platit jen za t, c chce a ptřebuje a ne za balíčky služeb. Zdůrazňujeme 1 ERP = Enterprise Resurce Planning - eknmický systém CRM = Custmer relatinship management - infrmační pdpra řízení vztahů se zákazníky LS 2005/2006 Strana 6 (celkem 26) VŠE Praha
maximální kvalitu námi ddaných služeb, díky metdice rychlé implementace systémů, můžeme ptm věnvat větší pdíl času důkladnému testvání a dlaďvání uživatelských pžadavků. Cílem je aby námi ddaný sftware práci lidem ulehčil a ne aby byl překážku efektivní práce. S našimi službami pdpry v rutinním prvzu dstanete s pen surce aplikací kmfrt velkých kmerčních balíků. Na závěr uvádíme reference sftware Cmpiere ve světě a v ČR: Gdyear Germany (distributr pneumatik) Le Plmb Français (výrbce uzávěrů) Audaxis (mezinárdní distribuce -Belgie) ActFact (Hlandský direct marketing) CmDivisin (knižní vydavatel -Německ) Firma Walter - distributr zbraní Madalbal ERP/CRM Cmpiere řešení v distribuční splečnsti Shrnutí výhd Cmpiere pr Stručně řečen výhdy systému Cmpiere nad knkurenčními balíky jsu následující: Nižší cena díky úspře za SW licence a využití stávající infrastruktury. Nezávislst na výrbci a ddavateli. Plná integrace funkcinality a tevřenst (imprty, exprty dat, n-line prpjení). Převzetí světvých best practice. Splupráce s partnery, zákazníky i ddavateli přes webvu sambsluhu. Flexibilita a nastavitelnst, mžnst dprgramvat ckliv, kýmkliv. Nízké nárky na interní IT persnál díky utsurcingu prvzu aplikace (mžn implementvat také jak in-huse včetně šklení administrátrů, neb jak ASP s měsíčním paušálním pplatkem). LS 2005/2006 Strana 7 (celkem 26) VŠE Praha
Nasazení Cmpiere na prcesy zákazníka Řešení jedntlivých blastí se systémem Cmpiere Segment/ Oddělení/Mdul Účetnictví Očekávání d nvéh IS Řízení výrby Řešení Cmpiere Bezchybné fungvání v nline (nční dávky) =denně platné údaje v závdě i pražské centrále umžní akční kmunikaci s partnery, v rámci zavedení bude uplatněn přísné střediskvé dělení nákladů, dhad splečných nákladů atd. Režie dle dsavadníh trendu Pdpra účetnictví dle platné české legislativy v rámci lkalizace (garantván). On-line zpracvání, mžnst ad-hc i předem definvaných reprtů. Sklady Vedeny n-line ve všech ptřebných veličinách, umžňující sledvat např. realizvané prdejní ceny d pzice, přes dběratele p celé středisk neb náklady buducí výrby = vstupy pr kalkulace Reálný stav skladvých zásb v průměrných cenách On-line zpracvání v reálném čase, reprty a exprty dat v mnha frmátech dle přání. Mžnst napjení třetíh sftware přím na databázi. Odbyt Pptávky Jedntná evidence bch.dd. umžní ad hc přehled stavu plnění zakázky, bjemech dvedené výrby i nasmluvanéh plnění k následné výrbě, skluzech, a t vše p zákaznících, pzicích, střediscích Nadstandardní mdul na zakázku Reálný stav přijatých bjednávek = plán výrby Pdpra bchdu je sučástí funkcinality CRM. Libvlné reprty. Mžnst dprgramvání dle analýzy prcesů a BPR, neb mžnst napjení již existujícíh SW. Předpkládáme využití standardní funkcinality CRM s úpravami dle specifických ptřeb. Nákup Systém bjednávek právněných (veducích středisek), schvalvacíh prcesu bez fyzickéh bíhání sb právněných, přehledu stavu zásb, nasmluvaných ddávek = tj. průměrných nákladech buducíh bdbí, jedntný přehled a kntrla výběrvých řízeních, vývji cen atd. Reklamace Nadstandardní mdul sdílená evidence prpjitelná s evidencí dbrpisů a párvání s vráceným zbžím = kntrla vyřízení reklamace a vrácení materiálu Reálný stav skladvých zásb + bjednané vstupy = v průměrných cenách Odhad dle trendu Wrkflw engine je rganicku sučástí systému a všechny administrativní prcesy jsu řízeny jak wrkflw. Mžnst definvání prcesů pmcí vizuálníh nástrje. Standardně sučástí CRM funkcinality s mžnstí custmizace dle analýzy prcesů a BPR LS 2005/2006 Strana 8 (celkem 26) VŠE Praha
Segment/ Očekávání d nvéh IS Řízení výrby Řešení Cmpiere Oddělení/Mdul Zmetkvitst Nadstandardní mdul sdílená evidence prpjitelná s evidencí umžňující histricky sledvat trendy Odhad dle trendu Dprgramvání na základě analýzy pžadavků uživatelů. Objem výrby Mzdy Autmaticky vyplývá z vkládání přijatých bjednávek a dvdů htvé výrby na sklad, vše p střediscích, dběratelích i pzicích Autmatické prpjení údajů dcházce a dměnách vkládaných na střediscích, dat persnálníh, pužití zvlených parametrů (např. dsažení limitu prduktivity) k výpčtu dměn, průměrných mezd atd. Persnalistika - dtt - Majetek Autmatická evidence nákladů na pravy a výpčet dpisů Manažerské Veškeré vznikají autmaticky přehledy dle zvlenéh přednastavení Plán výrby = reálný stav přijatých bjednávek Průměrné mzdy * plánem definvaný pčet hdin Pdpra plánvání výrby je standardní sučástí ERP funkcinality. Údaje vkládány ručně veducími (příp. imprt z MS Excel), neb mžnst napjení na elektrnický dcházkvý systém (píchačky) není sučástí ddávky dpručen. Mžnst napjení kdykli v buducnu. HR funkcinalita je plánvána d knce rku, mžn dprgramvat individuálně. standardně an + mžnst ad-hc reprtů + BI třetích stran. Další Rekapitulace dběratele (pr jednání s db.) histrie měsíčních dběrů v kg,ks,kč v členění dle typu prdukce, dle pzic dle jedntlivých výrbků inf mnžství ddaných kusů, zmetkvitsti, reklamacích, cenách a jejich změn,.. Výstupy značených mdulů pužité v jedntném systému kalkulací s přijatelnu dchylku dhadnu buducí zisk/ztrátu = pdklad pr rzhdvání, bchdní jednání i mtivaci Mžnst sestavení reprtu pdle kteréhkli atributu, kterékli entity. Zalžen na datvém slvníku (data dictinary). Knkrétně v seznamu zákazníků klikneme na jmén zákazníka a můžeme zvlit kritérium, které chceme sledvat např. suma tržeb d-d. Můžeme také zahrnut všechny zákazníky atd. Lgika sestavvání reprtů je pdbná práci s MS Access. Definice reprtů lze ukládat. Obecné výhdy / nevýhdy Jedntná data nenesu chybvst přepisem, sdílí je veškeří právnění uživatelé ve stejné pdbě, šetří se pracvní dba využitelná pr zdknalení technlgie výrby neb hledání a realizvání eknmických výhd, umžňuje ve strukturvané pdbě a de fact n-line využívat reálné či čekávané hdnty k jednání či rzhdvání Výše uvedené samzřejmě nad rámec ptimalizace vytížení výrbních kapacit, vytížení směn pracvníky, relevantníh sledvání prav strjů a jejich vytížení Tabulka 1 - Řešení prblémvých blastí systémem Cmpiere An. LS 2005/2006 Strana 9 (celkem 26) VŠE Praha
Výše uvedená tabulka bsahuje dpvědi na čekávání d zavedení nvéh ERP systému, která frmulval vedení Českých sléváren s.r.. v pptávkvém dkumentu (zadání CASE). V zadání byl taktéž pžadván příklad sestavy. Ten je uveden v následující pdkapitle. Příklad reprtu Standardní sestavy lze genervat z každé brazvky stiskem tlačítka. Na brázku je příklad reprtu aktivních bjednávek. Sestavu můžeme dále custmizvat, neb vybírat z přednastavených pmcí rzvíracích (drill-dwn) menu. Je mžn definvat libvlný dtaz nad celu databází (pdbně jak v MS Access). Zde jsu zhledněna uživatelská práva - každý manažer má přístup k určité mnžině datvých bjektů. Šablna, d které se budu sestavy genervat, bude při implementaci upravena prfesinálním grafikem dle pžadavků zákazníka. Obrázek 1 - Snímek brazvky se sestavu LS 2005/2006 Strana 10 (celkem 26) VŠE Praha
Příklad BPR knkrétníh prcesu Ddělá Matěj - Plně v jeh kmpetenci. LS 2005/2006 Strana 11 (celkem 26) VŠE Praha
Kncepce řešení Metdika S11 Cmpiere Implementatin Methdlgy Pr řízení prjektu pužíváme v případě ERP systému Cmpiere metdiku (Cmpiere Implementatin Methdlgy) /http://www.cmpiere.rg/supprt/implement/methdlgy.html/, navrženu výrbcem systému firmu CmPiere, Inc. Metdiku jsme bhatili garance a prcesy řízení kvality, které služí k eliminaci případných rizik rzsáhléh prjektu. Základním cílem metdiky je rychle umžnit testvání systému reálnými uživateli. Knkrétně se jedná přístup pdbný prttypingu, kdy v prvním kle relativně rychle implementujeme prdukční verzi systému, která má služit pr testvání uživateli. Vzhledem ke zkušensti, že žádná analýza nemůže zachytit všechny nuance prvzu nvéh systému, pčítáme s dalšími (až n) kly úprav. Nasazení tedy prběhne iterativně s tím, že v každé další iteraci se budu realizvat menší a menší úpravy. Pr nasazení v Českých slévárnách s.r.. pčítáme se základní velku implementací a dvěma kly následných úprav. Velmi důležitými aspekty tedy jsu: Šklení uživatelů - prbíhá před uživatelským testváním. Pr úspru nákladů dpručujeme v tmt prjektu pršklit tzv. klíčvé uživatele frmu něklikadenníh wrkshpu. Klíčví uživatelé ptm pršklí statní své klegy. Testvání Interní - Testy prvádí tým ddavatele za účelem eliminace chyb a zajištění suladu s buducím stavem definvaným v analýze. Zákaznické - Testy prvádí pracvníci zákazníka, který simuluje průběh prcesů, tak jak mají prbíhat v praxi s cílem genervat návrhy na zlepšení funkcinality a ergnmie systému (úpravy vládacích prvků brazvek, návrhy sestav, apd.) Zátěžvé (simulvané) - schpnst prdukčníh systému ddržet parametry kvality. Zátěž je simulvána speciálním sftwarem s cílem dhalit a eliminvat slabá místa v systému. Zátěžvé (uživatelské) - všichni uživatelé budu pracvat se systémem tak, aby se dhalila případná úzká místa, která se neprjeví při simulvaných testech. Finální uživatelský test - jedná se prvz ve stavu, kdy je schválena a implementvána finální pdba aplikace. Systém se před nasazením pužívá duplicitně vedle staréh systému a jedná se tak generální zkušku. V bdbí tht testu je třeba pčítat se zvýšenými nárky na pracvníky, kteří budu najednu pracvat starým i nvým způsbem. V tét fázi budu již dstraňvány puze případné kritické chyby (jejich výskyt se nepředpkládá). Případné pžadavky na úpravu vlastnstí systému budu řešeny pdle rzsahu v rámci běžné údržby či nvéh rzvjvéh prjektu. LS 2005/2006 Strana 12 (celkem 26) VŠE Praha
Řízení změn - incidenty jsu přijímány a evidvány v helpdesku ddavatele. T je systém, který služí jak rzhraní mezi ddavatelem a uživateli/testery (v prvzu a testvání). Incidenty se dále třídí na Chyby Kritické Závažné S nízku priritu Pžadavky na změnu funkcinality - se prjednávají na různých úrvních rganizační struktury prjektu, dle závažnsti a nutnsti rzhdnut, jaké úpravy budu v ceně a jaké případně nad rámec ceny prjektu. Dkumentace se dělí na něklik dalších typů, které jsu sučástí řešení v každé etapě. Vývjvá - analýzy a návrhy řešení. Uživatelská - uživatelské manuály, šklící materiály. Testvací - testvací scénáře, výsledky testů. Prjektvá - smluvy, zápisy z jednání, příkazy, pžadavky z helpdesku. Živtní cyklus prjektu je rzdělen na základní etapy. Každá etapa je uknčena akceptačním řízení, p která spčívá v předání výsledků etapy a fakturaci za dané díl. Etapa tedy vždy musí mít knkrétní výsledek, který je pužitelný jak vstup navazující etapy. V jedntlivých etapách prbíhají paralelně neb sérivě činnsti, které jsu knkrétní náplní etapy. Více živtním cyklu bude zřejmé z harmngramu prjektu. Prjektvý tým bude mít k dispzici elektrnické úlžiště dkumentů, které je standardně pužíván ddavatelem. Zákazník bude mít přístup k finálním verzím dkumentů na extranetu v elektrnické verzi. Pdklady pr akceptaci a další dkumenty, které jsu sučástí výstupu každé etapy, budu předány v listinné pdbě v předem dhdnutém pčtu kpií (např. uživatelské příručky, šklící materiály apd.). Zákazník má práv nechat na své náklady kvalitu všech předávaných výstupů věřit nezávislu třetí stranu (auditrem). Pžadavky na sučinnst vyplývají z jedntlivých etap rientačníh harmngramu prjektu. Architektura buducíh řešení Vzhledem k dnešní cenvé dstupnsti kmunikačních linek a ptřebě pdniku mít všechna data (např. ve frmě manažerských reprtů) k dispzici v reálném čase, dpručujeme zalžit systém na centralizvané databázi. Již dnes systém řízení částečně dpvídá centralizvanému mdelu (bchd a finance v centru, výrba ve střediscích.). Předpkládáme, že nadcházející BPR tyt tendence jen psílí. Centralizvanému zpracvání dat také dpvídá architektura samtnéh systému Cmpiere, který je řešen jak třívrstvý client-server mdel. Pr maximalizaci pdílu efektu na nákladech (TCO) dpručujeme utsurcvat prvz a údržbu servervé části (databáze a aplikační lgika). Servery budu umístěny v prfesinálním datacentru. Výhdu je, že budu LS 2005/2006 Strana 13 (celkem 26) VŠE Praha
napjeny přím na páteřní síti internetu a bude značně snížen rizik (prfesinální zálhvání, disaster recvery, dstupnst apd. budu garantvány v SLA). V kmpetenci interníh IT bude puze starst kncvé stanice a internetvé připjení, jak tmu byl dpsud. Tím se značně sníží ptřeba zašklvat IT persnál.. Buducí architektura bude nejlépe vidět na následujícím zjedndušeném schématu. Schéma bsahuje něklik úrvní detailu. Uprstřed nalezneme prpjení na úrvni lkalit páteřními linkami internetu (různé technlgie, na které nemáme vliv). Další úrvní je úrveň lkalit patřících zainteresvaným na IS (budvy). Na tét úrvní vlíme přístupvé linky pslední míle (zůstává v kmpetenci zákazníka - ddavatel puze uvede minimální parametry ptřebné k zajištění kvality služby). Nejdetailnější úrveň má naznačit jedntlivé LAN v knkrétních budvách (závdech) a kncvé stanice. Na kncvých stanicích může běžet JAVA klientská aplikace, neb může být klientem webvý prhlížeč. Zeleně pdbarveny jsu segmenty, které zůstávají v kmpetenci interníh IT ddělení (ale prvz je mžn utsurcvat v rámci zvláštníh prjektu). Červeně pdbarvená plcha vyznačuje segment, jehž prvz dpručujeme utsurcvat (prvz za paušální pplatek). Bíle pdbarvená plcha vyznačuje segmenty, které nemá přím pd kntrlu ani zákazník, ani ddavatel. Jejich parametry jsu nasmluvány v SLA. Minimální pžadavky budu upřesněny dále. Obrázek 2 - Architektura řešení ERP Jiný phled na architekturu řešení nabízí následující schéma. LS 2005/2006 Strana 14 (celkem 26) VŠE Praha
Obrázek 3 - Technlgie v Cmpiere ERP V následující tabulce uvádíme minimální pžadavky na technlgicku infrastrukturu. Za těcht pdmínek je mžn garantvat plnu pužitelnst aplikace. Systémvé pžadavky pr servervu část Operační systém Jakýkli s pdpru prstředí JAVA a databáze Firebird SQL (Windws 2003 server) Prcesr dpručen Intel P4 3GHz a vyšší Diskvý prstr 5GB (včetně databáze) dpručen RAID 10 pr DB server Operační paměť 1 GB Síť TCP/IP spjení ke klientům Systémvé pžadavky pr klientsku část Operační systém Jakýkli s pdpru JAVA Prcesr Dpručen Intel Celern 1GHz a vyšší Diskvý prstr 3MB (bez JRE) Operační paměť Minimálně 128MB dpručen 256MB Zbrazení 1024 x 768 hi-clr Síť TCP/IP Systémvé pžadavky na kmunikační linky Přensvá kapacita 512 kbps + 32kbps na uživatele dwnstream a 32kbps na uživatele upstream Odezvy ping k serveru <100ms Tabulka 2 - Pžadavky na infrastrukturu LS 2005/2006 Strana 15 (celkem 26) VŠE Praha
Scénář a harmngram implementace Vzhledem k centralizaci aplikace je nejlgičtější implementvat systém metdu velkéh třesku (big bang). Navrhvaný pstup je také pdstatněný vzhledem k relativně malému pčtu uživatelů (33). Prakticky t znamená instalvat aplikaci, dladit ji, testvat, zašklit uživatele, namigrvat data, prvést testvací prvz s reálnými daty a k 1.1. 2007 (big bang) přestat využívat staré aplikace. Zvláště v psledních etapách je třeba pčítat s větší zátěží uživatelů, kteří budu duplicitně pracvat ve starém i nvém systému. Tt řešení je všem nezbytné z hlediska řízení rizik. Orientační harmngram prjektu je uveden v následující tabulce. Detailní plán prjektu je zpracván v aplikaci MS Prject. Tabulka ppisuje jedntlivé etapy, jejich náplň (činnsti), výstupy, které jsu předávány jak pdklad pr akceptaci, rle ddavatele a zákazníka s pčtem člvěkhdin uvedeným v závrce. Pzn. D ceny prjektu nejsu zapčítány náklady na zdrje zákazníka. Tyt hdnty je nutné brát jak pžadavek ddavatele na sučinnst. Celý prjekt startuje rámcvu smluvu, na kteru navazují další tři (resp. čtyři smluvy): Smluva na BPR Smluva na řešení Smluva na implementaci Smluva na prvz (ta startuje nvý prjekt prvzu IS/ICT). V ceně tht prjektu je dle zadání kalkulvána cena 1 rku prvzu. Prjekt je nabízen jak celek. Nicméně v případě zájmu zákazníka je mžn realizvat jen část prjektu. Z harmngramu je vidět velký důraz na testvání a šklení uživatelů, čímž významně eliminujeme rizika prjektu. Při práci taktéž aplikujeme pravidla řízení kvality, která zaručují minimální chybvst jak v samtném systému, tak v ddané dkumentaci. LS 2005/2006 Strana 16 (celkem 26) VŠE Praha
Milník 3.6. Etapa Činnsti v rámci etapy Předané výstupy Rle ddavatele Rle zákazníka Uzavření rámcvé Rámcvá smluva Prject manažer (16) Prject manažer (16) smluvy Uzavření rámcvé smluvy Milník Analýza prcesů a BPR Akceptace výsledků analýzy Uzavření smluvy na Smluva na BPR Prject manažer (16) Prject manažer (16) BPR Analýza prcesů Analýza rganizace Analýza dat Business analyst (96) Management (16); Klíčvý uživatelé (40) BPR Návrh rganizace Návrh datvých bjektů Business analyst (96); ERP Management (56) Tvrba studie nvéh systému Studie nvéh systému Cnsultatnt (48) Business analyst (56); ERP Cnsultatnt (48) Akceptační prtkl Prject manažer (16) Prject manažer (16) Milník Analýza a návrh systému Akceptace návrhu Uzavření smluvy na řešení Detailní návrh buducí architektury IS Návrh parametrizace Cmpiere Tvrba testvacích scénářů Návrh dprgramvávaných sučástí Tvrba vývjvé dkumentace Analýza sučasnéh stavu IT infrastruktury Návrh změn IT infrastruktury Tvrba uživatelské dkumentace a šklících materiálů Vývjvá dkumentace; Uživatelská dkumentace; Testvací scénáře Prject manažer (16) Prject manažer (16) Slutin architect (96); Technik (40) Slutin architect (96); Technik (40) Slutin architect (96); ERP Cnsultatnt (96) IT manažer (20); Správce IT (20) IT manažer (10); Správce IT (10) Akceptační prtkl Prject manažer (16) Prject manažer (16) LS 2005/2006 Strana 17 (celkem 26) VŠE Praha
Milník Milník Etapa Činnsti v rámci etapy Předané výstupy Rle ddavatele Rle zákazníka Uzavření smluvy na Prject manažer (16) Prject manažer (16) implementaci Instalace jádra na Prgramvání Tvrba Technik (40); testvací i prdukční administrátrské Prgramátr (80); prstředí dkumentace ERP Cnsultant (40) Parametrizace Klíčvý uživatel (80) Implementace Akceptace I. kl úprav Akceptace Interní testvání Opravy chyb z interníh testvání Interní testvání Sběr a správa pžadavků Nasazení dprgramvaných mdulů Řešení interface na další prgramy Zákaznické testvání Šklení klíčvých uživatelů Šklení všech uživatelů Závěry interníh testvání, Prtkly šklení uživatelů, Detailní administrátrská dkumentace ERP Cnsultatnt (40); Prgramátr (80); Šklitel (40) Tester (40); ERP Cnsultatnt (24); Šklitel (40) Tester (40); Slutin architect (20), Prgramátr (20); Šklitel (40) Klíčvý uživatel (80) Klíčvý uživatel (80) Akceptační prtkl Prject manažer (16) Prject manažer (16) Závěry interníh testvání; Prtkly šklení; Seznam změn k zapracvání Prgramátr (20);;Šklitel (40) Tester (40);;Šklitel (40) Prject manažer (40); Šklitel (40) Klíčvý uživatel (40); Uživatel (40) Klíčvý uživatel (40); Uživatel (40) Klíčvý uživatel (40); Uživatel (40) Akceptační prtkl Prject manažer (16) Prject manažer (16) LS 2005/2006 Strana 18 (celkem 26) VŠE Praha
Milník 30.11 Milník 29.12 1.1.2007 Etapa Činnsti v rámci etapy Předané výstupy Rle ddavatele Rle zákazníka Zapracvání Úprava dkumentace Prgramátr pžadavků (20);ERP Cnsultant (60) II. kl úprav Akceptace Generální zkuška Akceptac e Rutinní prvz Interní testvání Zátěžvé testvání Zátěžvé simulvané testy Optimalizace Tester (40); Prgramátr (10); ERP knzultant (10) Závěry testů, Upravená dkumentace Tester (20); Technik (20); Prject manager (10) Uživatel (60), Správce IT (10) Akceptační prtkl Prject manažer (16) Prject manažer (16) Migrace dat ERP Cnsultant (80); Prject manažer (40); Prgramátr (20) Duplicitní prvz Pdpra Optimalizace Zpráva z generální zkušky Knec prjektu - navazuje prjekt prvzu a pskytvání pdpry (viz cenvá kalkulace prvzu). ERP Cnsultant (80); Technik (20); Prgramátr (20); Správce IT (10); Klíčvý uživatel (80) Uživatelé (300) Akceptační prtkl Prject manažer (16) Prject manažer (16) Pznámky V závrce za názvem rle je uveden pčet člvěkhdin. Jednu rli může zastávat více lidí, neb může mít asistenta Prject manažer je řízením prjektu a vedením prjektvé dkumentace, kmunikací a krdinací vytížen 20 hdin týdně. V bdbí akceptací navíc dalších 16 hdin. Smluvy pdepisuje statutární rgán, prject manažeři se účastní přípravy smluvy. Tabulka 3 - Orientační harmngram řešení LS 2005/2006 Strana 19 (celkem 26) VŠE Praha
Organizační struktura prjektu Ddělá Martin, tak aby t byl kmpatibilní s tabulku (Tabulka 3). Případně může v tabulce měnit člvěkhdiny a rle jak chce. Etapy mhu být v MS prjektu rzebrány detailněji. Zajištění prjektu smluvami Ddání prjektu je zajištěn něklika druhy smluv. Základní smluvu je smluva rámcvá, která stanvuje becné pdmínky splupráce a definuje pdby následujících smluv. Ddavatel se v ní zavazuje uzavřít smluvy na všechny následující etapy (pdmínku je splacení faktury za předcházející etapu). Zákazník má napak práv, kterukli následnu smluvu neuzavřít a vyřešit danu etapu jiným subjektem. Pkud by ddavatel měl pužít výstupy třetí strany, může uzavření smluvy na následující etapu dmítnut, dkud nebudu dané materiály dpvídat jeh pžadavkům. Z hlediska právníh tat smluva vychází z 50a a 50b ObčZ, které upravují smluvu smluvě buducí. Sučástí tét smluvy jsu již i parametry SLA ddanéh infrmačníh systému, které všem platí za pdmínky, že implementace bude dhdnuta s S11. Obecné platební pdmínky jsu již také definvány v rámcvé smluvě. Na rámcvu smluvu navazují tři smluvy typu smluva díl pdle 536 a násl. ObchZ. Jedná se : Smluvu na BPR - jejímž předmětem je studie bsahující analýzu stávajících prcesů a jejich reengeneering. Výsledkem je tedy návrh nvé bchdní lgiky s tím, že je předem zhledněn využití EPR Cmpiere. Smluva na řešení - jejímž předmětem je detailní technická specifikace řešení na základě Cmpiere ERP, včetně vývjvé, uživatelské, administrátrské, šklící a testvací dkumentace. Smluva na implementaci - zahrnuje netypicky 4 etapy prjektu (dpručujeme prvést jak jeden celek). Tyt etapy zahrnují implementaci, testvání na různé úrvni a úpravy dle uživatelských pžadavků. Výstupem těcht etap je kmpletní ERP systém testvaný a dladěný dle ptřeb firmy. P ddání systému a přechdu d rutinníh prvzu je mžn uzavřít smluvu na prvz ERP systému, která je zalžena na příkazní smluvě dle 724 a následujících ObčZ. V ní je, krmě ceny za prvz, znvu definvána dhda úrvni služby (SLA), tentkráte nejen na infrmační systém, ale také na služby jak service desk a další. Parametry SLA Něklikrát v tmt textu byly zmíněny parametry kvality služby SLA. Vzhledem k tmu, že jsu dhdnuty v různých smluvách, pvažujeme za vhdné shrnut je na jednm místě. Parametry jsu rzděleny na nrmální, při kterých je ddavateli placen servisní pplatek (v prvzu) v plné výši. Sankční, při kterých je ddavatel sankcinván 50% servisníh pplatku a kritické, při kterých není účtván žádný servisní pplatek. Při neddržení kritických parametrů je účtvána ddavateli smluvní pkuta (bvykle ve výši servisníh pplatku). LS 2005/2006 Strana 20 (celkem 26) VŠE Praha