Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování
Zlepšování reprodukčních procesů v České Trubky a.s. s využitím IT Diplomová práce
Autor:
Bc. Monika Cochlarová Obor Informační technologie a management
Vedoucí práce:
Praha
Ing. Otakar Král Ph.D., CSc.
Duben, 2010
Prohlášení:
Prohlašuji, ţe jsem diplomovou práci zpracovala samostatně a s pouţitím uvedené literatury.
V Praze dne 30. 4. 2010
Monika Cochlarová
2
Poděkování Ráda bych poděkovala panu Milanovi Rejholcovi za odborné rady a konzultace a panu Ondřeji Mejzlíkovi MSc. za informace z oddělení Výroby. V neposlední řadě patří mé poděkování panu Ing. Otakarovi Královi Ph.D., CSc. za odborné vedení mé diplomové práce.
3
Anotace práce Tato práce se zabývá analýzou podnikových procesů s ohledem na vyuţití informačního systému Navison ve společnosti České Trubky a.s. a návrhem řešení nalezených problémů a nedostatků s odvoláním na teoretickou část. Podrobnější analýza byla provedena především v oddělení Obchod, ve kterém sám autor pracuje. Cílem je najít moţnosti efektivnějšího vyuţití informačního systému v tomto oddělení a odstranit veškeré chyby a nedostatky, které byly ve vyuţití IS systému zjištěny na konkrétních obchodních případech. V průběhu analýzy byly odhaleny také závaţné nedostatky v oblasti bezpečnosti a byly navrhnuty kroky pro jejich odstranění.Závěr práce je zaměřen na komplexní návrh řešení, který přinese celkové zlepšení především v oblastech vyuţití informačního systému, zlepšení podnikových procesů, sníţení nákladů a zvýšení bezpečnosti. Tyto řešení vycházejí z postupů uvedených v teoretické části. Součástí práce je také harmonogram projektu a návrh projektového týmu pro celkové zlepšení včetně kvantifikace.
Annotation The goal of this thesis is an analysis of the corporate operations in České Trubky a.s. with respect to the use of Navison information system and a proposal of solution of detected problems and shortcomings based on the theoretical part of the thesis. A more detailed analysis was carried out especially in the Sales department, in which the author herself is an employee. The goal is to find possibilities of a more effective use of the information system (IS) in this department and to remove all bugs and shortcomings found in the use of the IS in specific business cases. In the analysis, severe shortcomings were also found with respect to security. Procedures to correct these were proposed. The conclusion of the work focuses on suggestion of a comprehensive solution, which would bring overall improvement, in particular in the fields of information system use, corporate operations improvement, costs reduction, and security improvement. This solution is based on procedures defined in the theoretical part. This work moreover includes a time plan of the project and a suggested nomination for a project team, which would ensure overall improvement. 4
Obsah 1
Úvod .............................................................................................................................. 8
2
Data v informačním systému ....................................................................................... 10
3
Systémová integrace .................................................................................................... 12
4
CRM –řízení vztahu se zákazníky ............................................................................... 14 4.1 Současné trendy v CRM ............................................................................................ 15
5
ERP podnikový informační systém ............................................................................. 17 5.1 Současné trendy v ERP: ............................................................................................ 18
6
Projektový management .............................................................................................. 20 6.1 Specifický cíl ......................................................................................................... 20 6.2 Začátek-konec uskutečnění.................................................................................... 21 6.3 Čerpání zdrojů ....................................................................................................... 22
7
Softwarová podpora pro řízení projektu ...................................................................... 23 7.1 Rozhovor ............................................................................................................... 23
8
Bezpečnost IS .............................................................................................................. 24 8.1
Průběh zavádění bezpečnosti informačního systému v podniku .......................... 26
8.2
Normy stanovující metodiku pro výstavbu bezpečnosti IS .................................. 29
8.3
Příklad doporučeného postupu odborníky U.S.Data Trust Corporation ............... 30
8.3.1 Hodnocení dat ..................................................................................................... 30 8.3.2 Soupis rizik ......................................................................................................... 30 8.3.3
Hodnocení rizik ............................................................................................. 32
8.3.4
Opatření k povýšení ochrany dat ................................................................... 32
8.3.5
Pokrytí zbytkových rizik - zálohy a archivace .............................................. 33
9 Základní údaje o společnosti ........................................................................................... 35 9.1
Organizační struktura ............................................................................................ 36
9.2
Generální ředitel.................................................................................................... 36 5
9.3
Certifikace ............................................................................................................. 37
9.4
Přehled certifikace ................................................................................................ 37
9.4.1
Výrobkové certifikace: .................................................................................. 38
Systém Navision ................................................................................................... 39
9.6
Klíčoví uţivatelé systému ..................................................................................... 41
10
9.5
Prodej a marketing ....................................................................................................... 42 10.1
Vyuţití ISN v rámci obchodu – popis aktuálního stavu ................................... 43
10.2
Proces překupu materiálu .................................................................................. 47
10.2.1
Přijetí poptávky a vytvoření nabídky ............................................................ 49
10.2.2
Objednávka zboţí .......................................................................................... 49
10.2.3
Předání zboţí zákazníkovi a fakturace .......................................................... 50
10.3 11
Výběrové řízení ................................................................................................. 54
Úseky divize výroba .................................................................................................... 55 Úsek řízení zakázek ..................................................................................................... 55 Obchodně technický úsek ............................................................................................ 55 Výroba ......................................................................................................................... 56 Kvalita ......................................................................................................................... 56 11.1
12
Vyuţití ISN v rámci výroby – popis aktuálního stavu ...................................... 57
11.1.1
Úsek řízení zakázek (UŘZ) ........................................................................... 58
11.1.2
Obchodně technický úsek (OTÚ) .................................................................. 59
Projektové řízení .......................................................................................................... 66 12.1
Realizace projektů ............................................................................................. 66
12.2
Realizace Engineering ....................................................................................... 67
13
Divize Finance a Controlling....................................................................................... 68
14
Oddělení obchod .......................................................................................................... 70 14.1
Proces překupu materiálu .................................................................................. 73
14.2
Návrh vyuţití maticové organizační struktury .................................................. 74 6
15
Oddělení výroba .......................................................................................................... 78
16
Návrh na zlepšení celkové situace ............................................................................... 81 16.1
Reorganizace dat ............................................................................................... 81
16.2
Zavedení intranetu ............................................................................................. 82
16.2.1
Návrh vytvoření intranetu.............................................................................. 83
16.2.2
Návrh ukládání dílčích dat společnosti .......................................................... 84
16.2.3
Návrh struktury intranetu............................................................................... 85
16.3
Analýza podnikových procesů .......................................................................... 86
16.4
Analýza aktivních funkcí systému .................................................................... 88
16.5
Rozšíření funkcionalit ....................................................................................... 89
16.6
Bezpečnost ........................................................................................................ 90
16.7
Testování systému ............................................................................................. 92
16.8
Vytvoření dokumentace .................................................................................... 94
16.9
Školeni............................................................................................................... 95
17
Harmonogram projektu ............................................................................................... 97 17.1
Projektový tým .................................................................................................. 98
18
Přínosy práce ............................................................................................................... 99
19.
Závěr ....................................................................................................................... 101
7
1
Úvod
Ve své práci jsem se rozhodla zabývat skutečnou firmou České trubky, a.s. (dále téţ jen ČT), pro kterou od ledna roku 2009 pracuji v obchodním oddělení na pozici specialisty prodeje, především pro výběrová řízení pro komplexní obnovu elektráren. Jiţ krátce po mém nástupu jsem si všimla velkých nedostatků v oblasti správy a sdílení informací, či moţných změn v informačním systému Navision, který povaţuji za kvalitní nástroj řízení. Nejdříve se v této práci zaměřím na analýzu jednotlivých oddělení, ze kterých jsem měla moţnost získat informace jak z hlediska organizačního, tak s ohledem na vyuţívání informačního systému a sdílení dat. Některá oddělní mi bohuţel neumoţnila tyto informace získat. Cílem je analyzovat současný stav informačního systému, získání přehledu o jeho vyuţití, popsat průběh procesu s důrazem na vyuţití IS, odhalit jeho nedostatky a případná očekávání a to především v obchodním oddělení, ve kterém pracuji. Zabývala jsem se nejen postupem, který vyuţívám při své práci já, ale také jsem se zaměřila na problémy svých kolegů, které se od mé pracovní činnosti liší. Jedná se především o analýzu procesu mezi obchodním a finančním oddělením při překupech materiálu, formu jakou probíhá a dokumenty, které během procesu vznikají. Největší problém vidím ve velké snaze veškerá data ukládat do adresářů na společný disk I a vytvářet nekonečné mnoţství excelových tabulek. Adresy nabývají bohuţel nekonečně dlouhých cest, neexistuje jasný přehled o tom, co se kde nachází a mnohá data vznikají duplicitně. I při skutečnosti, ţe společnost vlastní vynikající systém pro správu dat, nedochází k jeho vyuţívání, tak, jak by bylo potřeba a práce se v mnoha směrech stává neefektivní a dovolím si říct aţ zbytečná. Proto v této práci na základě analýzy navrhuji jak dílčí moţnosti zlepšení práce, tak především ucelený proces zlepšení celkového chodu společnosti s vyuţitím informačního systému. Klíčovým bodem, který jsem na začátku práce neočekávala, se stala bezpečnost informačního systému. Jelikoţ jsem během analýzy se zodpovědným pracovníkem došla k závěru, ţe současný stav je velmi kritický. Opřela jsem se o postup uvedený v teoretické 8
části této práce navrţený společnosti U.S data Trust Corporation. Jejich návrh řešení a postup povaţuji za kvalitní, proto jsem jej pouţila jako stěţejní bod. Přestoţe v této fázi v případě implementace bude důleţité vyuţít externích sluţeb odborníků s odbornými znalostmi. V závěru návrhu řešení jsem se zaměřila na komplexní projekt zlepšení celkové situace, jehoţ součástí je také harmonogram. Toto řešení slouţí jako návrh pro vedení společnosti České Trubky a.s. jako návod pro zvýšení konkurence schopnosti a efektivnosti s vyuţitím informačního systému.
9
2
Data v informačním systému
Informační systém a s ním spojená data neodmyslitelně zasahují do všech lidských činností. S tím je také spojený obrovský nárůst dat. Dle průzkumu společnosti IDC na kaţdého obyvatele planety připadá 45GB dat. Dohromady se tedy jedná o 281 miliard GB. 5% z těchto dat je umístěno na podnikových serverech, ovšem ročně tento objem dat narůstá o 60%. Jiţ v příštím roce budeme konfrontování s 11 miliardy GB podnikových dat. Ovšem 85% těchto dat není uloţeno v databázích a aţ 80% podnikatelských aktivit je na těchto datech závislých. Jsou to data především z webových stránek, z mailů, telefonních hovorů atd. Vlivem dostupných informačních technologií objem dat a dostupných informací velmi rychlé narůstá. Bohuţel na druhou stranu, schopnost člověka absorbovat nové informace neroste tak rychle. 1 V dnešní době je informační systém součástí skoro kaţdého podniku. Liší se pouze v tom, v jaké míře podnik informační systém vyuţívá a jak je začleněn do celkového chodu společnosti. V současné době jsou jiţ elektronická data stejně plnohodnotná jako data v papírově podobě. I kdyţ v mnoha případech stále podvědomě víc věříme tomu, kdyţ informace vidíme „černé na bílém“, neţ na monitoru. Přesto elektronická data mají nesrovnatelně lepší vlastnosti, neţ data na papíře. Lehce modifikovatelná – je velmi jednoduché změnit v dokumentu datum v elektronické podobě, neţ přepsat celý dokument v papírové podobě Lehce a rychle přenosná – ve velmi krátkém okamţiku můţe dokument obdrţet člověk, který je na druhém konci světa Menší nároky na archivaci – jedná se především o úschovný prostor, kdy pro papírová data potřebujeme sklady, kdeţto pro elektronická nám postačí disk.
1
Informace z ICT Revue, Hospodářské noviny
10
S těmito vlastnostmi souvisí také nemalá rizika, která není dobré opomíjet: Modifikovatelnost – uloţený soubor jde velmi lehce zaměnit, aniţ bychom později zjistili, k jaké změně došlo a kdo ji provedl. V případě přepsání a uloţení dokumentu, jiţ nemusíme nikdy zjistit, jaká byla původní verze. K tomuto dochází i omylem. Kaţdý z nás známe situace, kdy si přepíšeme souboru nebo ho bez uloţení zavřeme. Tímto přicházíme někdy nenávratně o kus práce.
Přenos dat – na jedné straně z mého hlediska nejlepší vlastnost elektronických formátů, která na druhou stranu přináší obrovské riziko úniků informací. V krátkém okamţiku můţe nesprávná osoba stáhnout a tím získat veškeré vaše informace o podniku a odnést si je na malé flash paměti.
Kopie – pokud je dokument vytištěn z elektronického formátu a provedu jeho kopii, je téměř identický, nerozpoznatelný a tudíţ lehce padělatelný. U kopie písma psaného rukou, kopii skoro vţdy poznáte.
Ukládání – vzhledem k jednoduchému ukládání elektronických dochází k archivaci velkého mnoţství dokumentů. Pokud tyto data správně neoznačíme, neagregujeme a nekatalogizujeme, můţeme se dostat do situace, kdy data sice na disku uloţené máme, ale nemůţeme je najít a tudíţ s nimi pracovat.
Provázanost – komplexní provázanost dat v systému je efektivní nástroj pro práci v tom, ţe data do systému zavedeme pouze jednou a napříč celým systémem je budeme mít stejná. Bohuţel velmi často dochází k redundanci dat a v případě změny v jedné části systému, můţeme zapomenout na změnu v jiné části. Další nevýhodou můţe být, ţe nesprávná změna můţe mít za následek negativní dopad do celého systému. Strategické řízení informačních systémů.
11
3
Systémová integrace
„Cílem systémové integrace je vytvoření a permanentní údrţba integrovaného informačního systému, který optimálně vyuţívá potenciálu dostupných IT k maximální podpoře podnikových cílů. Informační systém je přitom vytvářen integrací různých zdrojů, tj. různých produktů sluţeb.“ „Systémový integrátor vystupuje vůči zákazníkovi jako hlavní dodavatel IS/IT a odpovídá na základě kontraktu za kvalitní a včasné vytvoření a zavedení informačního systému v podniku. Na systémového integrátora přechází i odpovědnost za koordinaci práce všech subdodavatelů komponent a sluţeb IS/IT.“2 Při změně v IS/IT musíme vţdy uvaţovat, ţe vše je úzce spjato s podnikovými procesy, na které má jakákoliv změna v IS/IT dopad a naopak. Důleţité je vţdy před zahájením jakýkoliv změn důkladně zmapovat a analyzovat jednotlivé podnikové procesy.
2
Jiří Voříšek, Strategické řízení informačního systému a systémové integrace
12
Obrázek 1 Vztah změn podnikových procesů a změn IS/IT
13
4
CRM –řízení vztahu se zákazníky
„Cílem řízení vztahu se zákazníky není maximální zvyšování trţeb z jednotlivých nákupů, nýbrţ vytvoření trvalého vztahu se zákazníkem. V řízených vztazích se zákazníky je v centru pozornosti vztah se zákazníkem a cíl přizpůsobit procesy společnosti a zákazníka navzájem tak, aby se staly efektivnějšími. Ve světě obchodu můţe orientace na zákazníka snadno vést k tomu, ţe společnosti bud vydána zákazníkovi na milost. Naproti tomu řízený vztah se zákazníkem vyţaduje přizpůsobit proces na obou stranách a sobě vzájemně tak, aby se hodnota (úspora, efektivnost, lepší kvalita) vytvářela na obou stranách.“3
Podle prof. Ing. Jaromíra Vebera, CSc. z VŚE lze nasazení CRM rozdělit do následujících fází: 1. "pre-pre - stádium CRM": iniciativa obchodu na straně zákazníka, dodavatel zpracuje v obchodním oddělení, respektování základních technických a záručních legislativních poţadavků 2. "pre - stádium CRM": obchodní oddělení/marketingové oddělení, řada prodejců, nekoordinovaný přístup, indikátor prodeje „trţby“ – tlak na cenu 3. "0. stádium CRM": tradiční marketing – zaměření na produkt, marketingový mix – 4P 4. "1. stádium CRM": orientace na zákazníka – např. ve smyslu normy ISO 9001, reaktivní přístupy – hodnocení spokojenosti zákazníka 5. "2. stádium CRM": proaktivní přístupy k zákazníkovi, win-win, vztahy, hodnoty, partnerství, CRM-software
3
Jak Storbacha, Ph.D, Jarmo R. Lehlinen Ph.D, Řízení vztahu se zákazníky
14
„Klíčem pro úspěšnou CRM iniciativu jsou správná a konzistentní data zákazníka přístupná on-line v celé IT infrastruktuře. Důleţité je si uvědomit, ţe řešení CRM se dotýká prodeje, servisu i marketingu, a to při udrţování spokojenosti zákazníka.“4
4.1 Současné trendy v CRM5 Obchod: Databáze potenciálních a stávajících zákazníků Příleţitosti Aktivity Podpora procesů směřujících k rychlejšímu obchodování a lepšímu uspokojování potřeb zákazníků Vyhodnocení činnosti obchodního týmu.
Marketing: Lepší práce s cílovou skupinou (definice, rozčlenění) Marketingové aktivity (inzerce, direkt marketingové aktivity) Vyhodnocení efektivity marketingových aktivit.
Servis: Dispečink nebo dohledové centrum Aktivity servisu Záruční a pozáruční servis 4 5
Informace z ponikovy.software.cz Informace z ICT Revue, Hospodářské noviny
15
Evidence zařízení a lhůt Plánování zdrojů a zásahů Vyhodnocení.
16
5
ERP podnikový informační systém
Enterprise resource planning Zkratkou ERP jsou označovány komplexní informační systémy, který v sobě integruje podnikové procesy, především výrobu, prodej, správu majetku, finance a účetnictví, logistiku, distribuci a řízení lidských zdrojů v jediné databázi. Systémy jsou transakční, tzn., umoţňují vytvářet a aktualizovat rozsáhlé datové báze.
ERP je charakteristické6: grafickým uţivatelským rozhraním relačním systémem řízení báze dat pouţitím vysoce výkonných vývojových prostředků pro analýzu, návrh a implementaci informačního systému architekturou klient/server přenositelností v otevřených systémech.
Dříve byly ERP systémy aplikované ve velkých průmyslových společnostech. V současné době tento typ systému vyuţívají společnosti různých velikostí, v jakékoli oblasti podnikání. Hlavním cílem vyuţití tohoto systému je integrovat informace, data různých formátů a postupy napříč jednotlivými divizemi organizace, zvýšení produktivity práce a s níţení chybovosti. Mezi přínosné vlastnosti ERP systému je jeho schopnost komunikovat s ostatními aplikacemi v podniku a zpracovávat jejich data pro další pouţití.
6
Prof. Ing. Lenka Praţská, CSc. a kolektiv, Obchodní podnikání
17
Dalším výhodou těchto systému je modularita, která nám umoţní pořízení pouze takových částí systémů, které budeme vyuţívat, a tím nám šetří náklady na pořízení systému. V průběhu času a zjištění potřeby doplnění systému o další funkci, můţe být chybějící modul doimplementován. Většina ERP systému se přizpůsobí konkrétní organizaci na míru. Pro implementaci ERP systému je nutné zmapování procesů napříč podniku a zjištění vazeb mezi nimi.
5.1 Současné trendy v ERP:7 Příjemné uživatelské prostředí - GUI (Grafical User Interface) – co nejpřirozenější ovládání, intuitivní prostředí Provázanost s kancelářskými aplikacemi Elektronická komunikace mezi subjekty Business-to-business (B2B) – „obchodní vztahy se elektronicky realizují mezi dvěma podniky, resp. právními subjekty, většinou na bázi výměny strukturovaných dat (objednávek, potvrzení, faktury).“ Výrazným modelem B2B je větší důraz na logistiku a zajištění samotného obchodu, oproti důrazu na zákazníka“ Business-to-customer (B2C) – „označení pro obchodní vztahy mezi obchodními společnostmi a koncovými zákazníky, realizované webovými aplikacemi, virtuálními obchody na internetu apod. Tato oblast je označovaná i jako ecommerce“8 Business-to-empoleye (B2E) – „ je součástí e-commerce zaloţeno zejména na komunikaci obchodníka s jeho zaměstnanci a zaměstnanci mezi sebou. Cílem B2E nástrojů je především zlepšování informovanosti a znalostí zaměstnanců, zvyšování
7 8
Informace z ICT Revue, Hospodářské noviny Prof. Ing. Lenka Praţská, CSc. a kolektiv, Obchodní podnikání
18
jejich motivovanosti a celkové produktivity práce zaměstnanců. B2E systémy se často podobají intranetu, na rozdíl od něj jsou však více personalizované.9 Budoucnost komunikace se státní správou (aplikace nad „datovými schránkami“) Provázanost se zdroji informací pomocí internetového připojení – obchodní rejstřík, mapy a navigace, kurzovní lístky, bankovní sluţby – výpisy z bankovních účtů, platby Workflow – nezbytnost pro dokonalé řízení procesů, nastavení procesů, eskalace, „response time“ jednotlivých operací, výstrahy a delegování včetně změn pomocí e-mailů a SMS zpráv, vyhodnocování. Rychlost Otevřenost a integrace – schopnost systémů pokud moţno rychle provázat vnitřní agendy s jinými systémy, počínaje webshopem přes redakční systémy, kontrolingové systémy nebo třeba jen intranet pro zaměstnance Saas –software as a service „je model nasazení softwaru kdy dochází k hosting aplikace provozovatelem sluţby. Eliminováním potřeb instalace a provozu aplikace na vlastních zařízení se SaaS v poslední době stává oblíbeným způsobem provozu aplikace“10 Outsourcing – „v praxi znamená outsourcing přenesení určitých aktivit a odpovědnosti za ně na externí zdroje. Firma tak většinou činí z důvodů finančních, nebo pro nedostatek kapacity interních pracovníků.“11
9
Informace z adaptic.cz www.wikipedia.cz 11 doc. Ing. Miloslav Keřkovský, CSc., MBA, Ing. Miloš Drdla, Dr., MBA, Strategické řízení firemních informací 10
19
6
Projektový management
„Projektový management je souhrn aktivit spočívající v plánování, organizování řízení a kontrole zdrojů společnosti s relativné krátkodobým cílem, který byl stanoven pro realizaci specifických cílů a záměrů“ 12 Projekt – projekt je jakýkoliv sled aktivit a úkolů, který má:
6.1 Specifický cíl Dán specifický cíl, který má být jeho realizací splněn – projekt je vţdy unikátní sled aktivit, nejedná se o rutinní opakující se procesy. Základními nástroji je projektová komunikaci a týmová práce. Kaţdý projekt má své specifické vlastnosti. Pro kaţdý projekt je vymezený projektový tým, ve kterém mají jednotliví členové jasně stanovené povinnosti a zodpovědnost a celkově usilují o dosaţení cíle projektu ve stanoveném čase. Cíl projektu musí být: S – specific – specifický a konkrétní M – Measurable – měřitelný – jasně definované parametry, na základě kterých lze rozpoznat, zda bylo cíle dosaţeno. A – Assignable – přidělitelný – vymezení odpovědnosti k rozhodnutí R – Realistic – reálný – kaţdý cíl musí mít dosaţitelný cíl T – Time-bound – časově ohraničený – určený začátek a konec
12
Ing. Alena Svozilová, MBA, Projektový management
20
6.2 Začátek-konec uskutečnění Definováno datum začátku a konce uskutečnění – kaţdý projekt má určitý časový rámec. Má přesné vymezený datum, resp. čas zahájí a ukončení projektu – jedná se o tzv. časovou dočasnost a „ţivotní cyklus“.
Obrázek 2 Typické rozložení fází životního cyklu projektu
Součástí kaţdého projektu jsou také diagramy a harmonogramy, které hrají významnou úlohu pro projektového managera. Mezi základní diagramy patří: Síťové diagramy – PERT, CPM – nám slouţí k časovému plánování a zachytit vazby mezi jednotlivými činnostmi – posloupnost činností, stanovit tak celkovou dobu trvání projektu, určit časové rezervy a nalézt kritickou cestu, která nemá ţádnou časovou rezervu. Díky těmto informacím jsme schopni určit priority jednotlivých činností a současně nám síťový diagram slouţí také jako kontrolní nástroj pro vyhodnocování.
21
Ganttovy diagramy – informace získané ze síťového grafu nám slouţí prezentovat plánované termíny pomocí Ganttova diagramu. GD je úsečkový graf, na základě kterého máme moţnost efektivně řídit zdroje projektu a zároveň slouţí také jako harmonogram. Diagramy milníků – v jakémkoliv projektu je dán určitý počet milníků, díky kterým kontrolujeme průběh plnění časového harmonogramu. Histogramy - jedná se o grafy četnosti. Vyuţívány např. u histogramu montáţí.
6.3 Čerpání zdrojů Stanoven rámec pro čerpání zdrojů potřebných pro jeho realizaci – jedná se o přesné vymezení, lidský, hmotných a finančních zdrojů a limitů pro jejich čerpání. Rozpočet projektu je vţdy součástí Plánu projektu. Rozpočet je nutno jiţ v jeho dílčích částech realizace dodrţovat a slouţí nám také pro zpětnou kontrolu a vyhodnocení celého projektu.
Obrázek 3 Typický průběh čerpání nákladů v průběhu životního cyklu projektu
22
7
Softwarová podpora pro řízení projektu
Softwarové nástroje pro řízení projektu můţeme dle Harolda Kerznera rozdělit do tří úrovní dle jejich vlastností a funkcionalit13: 1. Úroveň - jednoduché programy pro vedení projektu. Vzhledem k nepříliš propracované databázi nám neumoţňují provádět analýzy a nejsou schopny automatických úprav při jednoduchých změnách v diagramech. 2. Úroveň – středně vybavené programové balíky, které jsou rozšířené o moduly funkce pro plánování a optimalizaci. 3. Úroveň – zde se jedná jiţ o plně vybavené programové balíky, které obsahují veškeré potřebné moduly pro plánování, organizování i kontrolu a zároveň umoţňují průběh a vedení i několika projektů současně.
7.1 Rozhovor „Je vhodná metoda, pokud je cílem výzkumu získat názory, postoje nebo přesvědčení lidí. Vyuţívá se i hloubkový rozhovor - časově rozsáhlejší s pečlivě připraveným sledem otázek. V některých případech je vhodné vyuţít tzv. skupinové dynamiky a provádět skupinové rozhovory. V poslední době se stále častěji vyuţívá tzv. ohnisková skupina, která spočívá ve vedení skupinového rozhovoru moderátorem, který členům skupiny klade otázky a prezentuje úkoly na základě předem připraveného scénáře. Jedna z velkých výhod rozhovoru je jeho flexibilita.“14
13 14
Harold Kerzner, Project Management Ondřej Mejzlík, MSc., Definice korporátní strategie společnosti Michal Halík – ElektroDream
23
8
Bezpečnost IS
„Bezpečnost IS/IT se stává v současnosti jednou z klíčových vlastností informačních systémů. Problémem zabezpečení vlastního informačního systému se zabývá pravděpodobně naprostá většina podniků rozličného zaměření a velikosti.“15 Vztahy mezi základními pojmy bezpečnosti můţeme vyjádřit následujícím obrázkem:
Obrázek 4 Vztahy mezi základními pojmy bezpečnosti
Hrozby = vyuţití zranitelného místa informačního systému. Tyto hrozby mohou být: Aktivní – škody způsobené lidským faktorem. Ty mohou být úmyslné nebo neúmyslné. Pasivní – škody vzniklé z přírodních, fyzických nebo fyzikálních skutečností. Zranitelné místo umoţňuje útok na IS. Jakékoliv zranitelné místo nám zvyšuje riziko pravděpodobnosti jeho vyuţití k útoku. Proto v informačním systému uplatňujeme, pomocí bezpečnostních mechanismů bezpečnostní funkce, neboli opatření proti útoku.
15
Informace k této kapitole byly pouţity z přednášek https://akela.mendelu.cz
24
Mezi zranitelná místa informačního sytému patří: Fyzická podstata – nevhodné umístění komponenty IS – nutné klimatizované místnosti, napojení na UPS, pro výpadky elektřiny Přírodní podstata – neovlivnitelné přírodní jevy (vyplavení, údery blesku, poţáry) Konstrukce HW – nekvalitní disky, špatné zdroje, poddimenzované řešení Softwarové řešení – nutné specializované softwary pro vysoké kapacity, zálohování, počítačový virus Lidský faktor – nejslabší článek bezpečnosti – nízká kvalifikace, nepozornost, nedodrţování směrnic, špatný úmysl, krádeţ.
Bezpečnostní mechanismy mohou být: Fyzické – přístup k serverům pouze určitým a kvalifikovaným osobám, klimatizovaná místnost Hardwarové – výběr správného hardwaru s dostačující kapacitou Softwarové – antivirové programy, zákaz instalace vlastního softwaru, zálohování Administrativní – kvalifikovaní uţivatelé, pouţívaní hesel a nastavení přístupových práv.
25
Průběh řešení bezpečnostní politiky v podniku
Obrázek 5 Průběh řešení bezpečnostní politiky v podniku
8.1
Průběh zavádění bezpečnosti informačního systému v podniku
1. Krok – „nultý krok“ – rozhodnutí managementu zabývat se bezpečnostní politikou určení zásadních cílů, strategií a politik pro informační zabezpečení organizace určení požadavků na informační zabezpečení organizace 26
určit pravomoci a zodpovědnosti identifikace a analýza hrozeb pro informační aktiva organizace identifikace a analýza rizik plynoucích z provozování IS určení přiměřených bezpečnostních opatření (BO) sniţujících rizika na přijatelnou úroveň sledování implementaci BO a provoz IS se zavedenými BO zavedení programu pro zvyšování kvalifikace uţivatelů IS v oblasti informační bezpečnosti sledování a zaznamenávání všech bezpečnostních incidentů a pokusů o ně s vyvozením patřičných důsledků 2. 1. krok - "Analýza rizik" (AR) - klíčová aktivita celého procesu, výstupem jsou dokumenty obsahující výsledek analýzy (popis systému, zjištěná úroveň hrozeb, zjištěná zranitelná místa, zjištěná úroveň stávajících bezpečnostních opatření, návrh bezpečnostních opatření sniţujících rizika na přijatelnou úroveň) 3. 2. krok - dokument "Celková bezpečnostní politika" (CBP) - dlouhodobá platnost - nezávislost na současně pouţívaných IT - definice citlivých dat - potřebné síly bezpečnostních mechanismů - stanovení hierarchie zodpovědnosti, pravomocí a práv pro subjekty a objekty IS. Dokument musí být v souladu s organizačním řádem podniku. 4. 3. Krok – „Systémová bezpečnostní politika“ (SBP)- definuje způsob implementace Celkové bezpečnostní politiky v konkrétním prostředí (na konkrétních informačních technologiích) – rozpracování zásad do detailní podoby – do závazných podnikových směrnic, předpisů, norem. Musí být zcela v souladu s CBP. Častější frekvence úprav v závislosti na změnách v infrastruktuře IS. Vychází z výsledků AR, zahrnuje: Fyzickou SBP – ochrana fyzických aktiv Personální SBP – řeší ochranu před hrozbami představovanými uţivateli IS a neautorizovanými lidskými subjekty Komunikační SBP – zabezpečení objektů zajišťujících komunikaci
27
Provozní SBP – programy zvyšování kvalifikace, postupy při provádění preventivních opatření, postupy pro detekci podezřelých událostí a pokusů o útok, postupy po uskutečněných útocích („Havarijní plán“), postupy při zajištění znovuzprovoznění IS („Plán obnovy“, „Plán provozní kontinuity“) „Havarijní plán“ – plán činnosti po útoku (včetně určení skladů náhradních dílů, archivů záloh atd.), průběh reakce na incident pro konkrétní osoby tvořící havarijní tým, stanovení adresné zodpovědnosti za postupy „Plán obnovy“, „Plán kontinuity provozu“ (zahrnuje definici „havárie“, „podezření na průnik do IS“) – stanoví postupy pro definované situace – určuje priority z hlediska poslání organizace (tzv. „kritické zdroje“) – směrnice pro vytváření záloh a archivů dat – směrnice pro skartace nepotřebných zdrojů informací (hrozba „ztráta důvěrnosti“). 5. 4. krok - implementace informační bezpečnosti, přijetí a uvedení do života SBP postupné řešení dílčích kroků a projektů (např. systém monitorování, zajištění bezpečnostního vzdělávání…)
Problémy a chyby: mnoho kompromisů nereálná politika - v současném stavu věcí nevyhovuje - potřeba postupného řešení neadekvátní rozsah politiky - negativní dopad na výkonnost IS nedostatečná propagace BP přebírání nevhodných vzorů. 6. 5. krok - monitoring a audit - průběţné sledování provozu IS a vyhodnocování stupně jeho zabezpečení, vytvářejí zpětnou vazbu se všemi předchozími fázemi výstavby informační bezpečnosti a implikují změny v bezpečnostním systému. „Řešení řízené informační bezpečnosti je projekt náročný časově i finančně. Informační bezpečnost je nutné řešit také v organizacích, které provozují informační systému menšího rozsahu a které se dosud bezpečností informací důsledně nezabývaly. Průzkumy (University of Texas, U.S. Small Business Administration) prokazují, ţe přístup k 28
informacím je kritická oblast komerce. Z podniků, u nichţ došlo k totální ztrátě podnikových dat v důsledku havárie informačního systému, zaniklo téměř 50% takto postiţených podniků. Na svou původní úroveň se nedostalo ani po dvou létech působení téměř 90% podniků. Dále tyto průzkumy zjistily, ţe ani u většiny nových podniků není informační bezpečnosti věnována dostatečná pozornost, přestoţe ztráta dat významně ohroţuje podnikání. U informačních systémů menšího rozsahu je moţno volit postup, kdy na základě praktických zkušeností a doporučení odborníků na informační bezpečnost je proveden soupis rizik, jejich vyhodnocení a následná opatření na jejich vyloučení nebo pokrytí. Takové řešení můţe dočasně překlenout závaţné bezpečnostní trhliny v IS podniku. Současně musí ovšem probíhat řešení projektu informační bezpečnosti podle normalizovaného postupu.“
8.2
Normy stanovující metodiku pro výstavbu bezpečnosti IS
ČSN ISO/IEC TR 13335-1 - Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 1: Pojetí a modely bezpečnosti IT ČSN ISO/IEC TR 13335-2 - Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 2: Řízení a plánování bezpečnosti IT ČSN ISO/IEC TR 13335-3 Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 3: Techniky pro řízení bezpečnosti IT ČSN ISO/IEC TR 13335-4 Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 4: Výběr bezpečnostních opatření
29
8.3
Příklad doporučeného postupu odborníky U.S.Data Trust Corporation
8.3.1 Hodnocení dat 1. určení ceny dat
součet nákladů nutných k obnově dat
ztráta vzniklá nečinností po dobu obnovy dat (krátkodobá ztráta)
ztráta dobrého jména (dlouhodobá ztráta).
2. určení typu dat
zákaznické databáze
účetnické záznamy
podnikové dokumenty (zápisy porad, pošta...)
....
8.3.2 Soupis rizik dotazníky budou vyplněny vybranými uţivateli IS a následně vyhodnoceny (viz "Hodnocení rizik") 1.
Fyzická bezpečnost
Jsou servery umístěny v klimatizovaném prostoru s protipoţární ochranou? (ano/ne)
Provádí se průběţně kontrola těchto prostorů? (ano/ne)
Mají servery zálohové napájení? (ano/ne)
Jsou servery fyzicky přístupné pouze autorizovaným osobám? (ano/ne)
2.
Logická bezpečnost
Je systémová administrativa prováděna vyškoleným personálem? (ano/ne)
Je na kaţdém externím síťovém přístupu instalován firewall? (ano/ne)
Jsou uţivatelská přístupová oprávnění určována v souladu s poţadavky podniku? (ano/ne) 30
Jsou uţivatelská oprávnění periodicky hodnocena z hlediska změn v personálním zařazení a zodpovědnosti? (ano/ne)
Mají všechna přístupová hesla k serverům s kritickými daty 8 znaků a znaky alfabetické i numerické? (ano/ne)
Musí uţivatelé periodicky měnit svá hesla se zákazem znovupouţití po dobu minimálně jednoho roku? (ano/ne)
Je na všech počítačích a serverech naistalovaný a updatovaný antivirový SW? (ano/ne)
Je zákaz instalace SW, který není pověřenými pracovníky ověřen? (ano/ne)
3.
Je zakázáno pouţívat na pracovištích bezdrátové LAN? (ano/ne)
Záloha a obnova dat
Jak často se provádí backup? ( a)průběţně b)denně c)týdně d)měsíčně e)ročně f)nikdy )
Jakým postupem se provádí? ( a)automaticky b)manuálně odborníkem c)manuálně neodborníkem)
Jak dlouho jsou data uchovávána? (a)rok a více b)nejméně měsíc c)týden d)den e)nejsou uchovávána)
Jak často jsou zálohy ověřovány na čitelnost? (a)denně b)týdně c)měsíčně d)občas/nikdy )
Kde jsou zálohy uchovávány? ( a)mimo provoz IS b)na stejném serveru c) v prostorách s protipoţární ochranou d)na jiném serveru e)jinde)
Za jakou dobu po vytvoření záloh jsou média přemístěna mimo provoz IS? (a)bezprostředně b)do 8 hodin c)do 24 hodin d)do 7 dní e)do 1 měsíce f)nikdy)
Jak dlouho trvá nalezení a obnovení ztraceného souboru? ( a)několik minut b)několik hodin c)den a více d)týden a více e)měsíc a více )
31
8.3.3 Hodnocení rizik Hodnocení rizik bezpečnosti systému můţeme vyhodnotit dle následující tabulky, která vychází z otázek z kapitoly 8.3.1. Odpovědi je doporučené získat od odpovědné a osoby, která má příslušné znalosti a informace ohledně podnikové bezpečnosti informačního systému.
Odhalené riziko
Nízké
Střední
vysoké
Fyzická bezpečnost
Logická bezpečnost
Záloha a obnovení
"ano"
"ano"
"a)"
u všech odpovědí
u všech odpovědí
u všech odpovědí
"ano"
"ano"
"a)" nebo "b)"
nejméně 3 odpovědi
nejméně 6 odpovědí
u všech odpovědí
"ano"
"ano"
jiné neţ "a)" nebo "b)"
méně neţ 3 odpovědi
méně neţ 6 odpovědí
u všech odpovědí
Tabulka 1 Hodnocení bezpečnosti
1. nízké riziko - výborný stav (nevyţaduje bezprostřední opatření) 2. střední riziko - varující stav (vyţaduje v některých oblastech opatření) 3. vysoké riziko - provoz IS je váţně ohroţen (vyţaduje bezprostřední opatření)
8.3.4 Opatření k povýšení ochrany dat Pro příklad zde uvádím nezákladnější kroky opatření vedoucí ke zvýšení bezpečnosti informačního systému.
1. Bezpečný fyzický přístup - pouze pro autorizované osoby 2. Řízení provozních podmínek - klimatizace, měření teploty… 32
3. Zálohové napájení - ochrana proti výkyvům elektrické sítě 4. Firewally - instalace na všech připojeních do externích sítí 5. Antivirový SW - instalace, periodický update, mail servery s obsahovými skenery 6. Omezení uţivatelských přístupů - řízení přidělování oprávnění, změnová řízení, sledování uţivatelských práv zaměstnanců odcházejících z organizace 7. Hesla uţivatelů - nastavení pravidel a period vynucených změn hesla (běţný uţivatel - 3 měsíce, správce - 1 měsíc).
8.3.5 Pokrytí zbytkových rizik - zálohy a archivace 1. Identifikace kritických dat - provádí vedení organizace. Jsou určena: data s nejvyšší hodnotou - základní data potřebná pro klíčové funkce organizace. Je vyţadována jejich okamţitá obnova. potřebná data - není vyţadována okamţitá obnova, data nezbytná z dlouhodobějšího hlediska, nesmí být ztracena nepotřebná data - data mohou být ztracena, ztráta má minimální dopad na chod organizace. 2. Určení objemu a umístění kritických dat objem dat v GB místo uloţení (pracovní stanice, servery…) typy a formáty dat (databáze, soubory textové, multimediální… fyzické lokality (v jedné budově, dislokovaná pracoviště…). 3. Určení požadované doby obnovy kritických dat - reálné poţadavky - výchozí problém: jak dlouho můţe být organizace bez těchto dat? (čím rychlejší obnova, tím nákladnější provedení) 4. Určení osobní zodpovědnosti (i zástupci) - zálohy nesmí být prováděny nedostatečně kvalifikovanými pracovníky - vyţadují se školení, průběţné testy
33
5. Implementace zálohování a obnovy dat (základní čtyři kroky) 1.
vytvoření záloţního datového zdroje - spolehlivě a přesně, s dostatečnou časovou četností (kritické u databází), s okamţitým ověřováním funkčnosti zálohy
2.
přemístění záloţního datového zdroje - nejlépe bezprostředně po dokončení, správné zacházení s médii (fyzickými), zajištění spolehlivého transportu (fyzického i síťového)
3.
zajištění úloţiště pro záloţní zdroj dat- ochrana proti průniku nebo zničení, stálý rychlý přístup ke zdroji (fyzický i síťový)
4.
zajištění doby obnovy v souladu s poţadavky organizace.
34
9 Základní údaje o společnosti České trubky, a.s. (dále ČT) jsou v současné době největším českým výrobcem spojovacího potrubí pro energetiku a jediným výrobcem potrubí primárního okruhu jaderných elektráren. Společnost zajišťuje jak kompletní dodávky na klíč, zahrnující dodávku, výrobu, montáţ a uvedení díla do provozu, tak kusové dodávky potrubních dílů. Kromě výroby zajišťuje i projekční a poradenskou činnost.
Právní forma:
akciová společnost
Počet zaměstnanců:
236
Roční obrat:
2 mld. Kč
Sídlo firmy:
Praha
Dislokovaná pracoviště: Brno České Budějovice Dukovany Temelín Tušimice.
Ke společnosti dále patří dvě dceřiné společnosti. První sídlí v Mělníku a druhá v Bratislavě.
35
9.1
Organizační struktura
Obrázek 6 Organizační struktura podniku
9.2
Generální ředitel
GŘ řídí chod společnosti s cílem plnit strategické plány. Mezi další činnosti patří: končená odpovědnost za plnění poţadavků stanovených normou EN ISO 9001:2000 konečná odpovědnost za plnění poţadavků stanovených normou ČSN EN ISO 14001:2005 schvaluje organizační směrnice, pracovní pokyny. schvaluje personální obsazení odborných ředitelů, případně jejich odvolání 36
udrţuje vztahy s obchodními partnery atd.
9.3
Certifikace
Certifikace znamená potvrzení souladu, shody (obvykle po přiměřeném prověření) skutečného stavu produktu, systému, znalostí apod. se stanovenými specifikacemi, obvykle nějakým standardem, normou. Společnost ČT prošla také řadou certifikace a to z důvodů: společnost je na základě certifikátů schopna především zákazníkům doloţit doklad o tom, ţe má zavedený systém ve společnosti se při zavádění systémů řízení jakosti stanoví jasné odpovědnosti a nastaví se řád a přesný průběh procesů tak, aby docházelo co k nejefektivnějšímu vyuţívání všech zdrojů a neustálému zlepšování. tím je zajištěno také lepší uspokojování poţadavků zákazníka a zvýšení konkurenceschopnosti, jiţ od nákupu, přes výrobu aţ po odevzdání díla a případného servisu.
9.4
Přehled certifikace
Systém jakosti Certifikát systému řízení jakosti podle ISO 9001:2000 pro projektování, vývoj, výrobu, montáţ a prodej spojovacího potrubí pro klasickou a jadernou energetiku a průmysl
Enviromentální systém řízení jakosti Certifikát systém environmentálního řízení jakosti podle ĆSN EN ISO 14001:2005
37
Politika jakosti a environmentu Cílem České Trubky a.s. je především trvalé uspokojování potřeb a očekávání všech zainteresovaných stran - zákazníků, dodavatelů, zaměstnanců i akcionářů. Základní prioritou je důsledné uplatňování poţadavků systémů řízení jakosti a environmentu, jejich neustále zlepšování. Nutnou podmínkou je tudíţ rozvíjet a zlepšovat veškeré procesy a postupy v celé společnosti a také jakost výrobků.
9.4.1 Výrobkové certifikace: podle „ČSN” oprávnění k výrobě, montáţi, opravám a rekonstrukcím vyhrazených technických zařízení v jaderné energetice a jaderných elektráren typu VVER 440 a VVER 1000 (ITI Praha) oprávnění k montáţi, rekonstrukcím a opravám tlakových nádob (ITI Praha) oprávnění k montáţi, rekonstrukcím a opravám parních a plynových kotlů (ITI Praha) oprávnění k revizím a zkouškám tlakových nádob (ITI Praha) osvědčení o způsobilosti k provádění revizí, zkoušek těsnosti a tlakových zkoušek tlakové nádoby (ITI Praha) osvědčení o způsobilosti k provádění stavební a první tlakové zkoušky – parní a kapalinové kotle (ITI Praha) osvědčení o způsobilosti k provádění stavební a první tlakové zkoušky – tlakové nádoby (ITI Praha) Velký průkaz způsobilosti o posouzení odborné způsobilosti dle poţadavků normy ČSN 73 2601 změna Z2:1994 k provádění ocelových konstrukcí v rozsahu prvního stupně podle čl. 203 normy vydaný TÜV SÜD (platnost 14. 2. 2011).
podle „EN” certifikát o ověření systému zabezpečení jakosti výrobce materiálu pro tlaková zařízení podle směrnice 97/23/EG, modul G, na základě norem AD 2000-Merkblatt
38
HP0, TRD 100, 201, DIN EN 3834-2, vydaný TÜV Industrie Service (platnost: březen 2010) certifikát pro značení tlakových nádob a potrubí symbolem CE 0035 a certifikát pro přenášení značení kovových materiálů se zkušebními osvědčeními 2.1, 2.2, 2.3 a 3.1 dle DGR 97/23/EG vydaný TÜV Industrie Service (platnost: březen 2010).
podle „ASME“ certifikát o způsobilosti k výrobě tlakových nádob Stamp „U“ certifikát o způsobilosti k výrobě energetických kotlů Stamp „S“ vydané certifikačním orgánem ASME, New York, USA (platnost: do 8. srpna 2011).
9.5
Systém Navision
Hlavní informační systém ve společnosti České Trubky a.s. je Navision. Jedná se o integrovaný adaptabilní podnikový systém určený pro střední podniky. Jelikoţ systém Navison je dalším produktem společnosti Microsoft, je zajištěna kompatibilita např. s nejčastěji vyuţívaným kancelářským balíkem Microsoft Office. Jednotlivá řešení se zaměřují především na: zjednodušení procesu souvisejícím s financemi vztahy se zákazníky odběratelsko-dodavatelským řetězcem.
39
Obrázek 7 Microsoft Dynamics
Hlavním přínosem pouţívání systému Navision je sdílení dat společnosti na jednom místě, přístupné všem kdo je potřebují. Tato vlastnost nám umoţní automatizaci či zrychlení procesů, minimalizci chyb a přijímání lepších rozhodnutí. IS Navison byl ve společnosti nasazen při poslední změně vlastníka v červnu v roce 2006. V rámci ISN se uchovávají zejména data spojená s realizací projektů a účetnictví. Většina analýz se provádí externě v rámci MS Excel (snadnost přenosů dat je jednou z hlavních předností tohoto systému). Ostatní informace jsou shromaţďovány na serveru společnosti, pro zaměstnance disk I.
Hlavní problémy sdíleného datového prostoru představuje: nepřehledná datová struktura. Kaţdá divize má svůj vlastní adresář rozdělený na veřejnou a neveřejnou část. To často způsobuje duplicitní ukládání informací, protoţe pracovníci jiných divizí do neveřejných sloţek z pochopitelných důvodů přístup nemají. problematická správa aktuálních verzí jednotlivých dokumentů. Jedná se zejména o různé šablony, vzory dokumentů, manuály, certifikáty a v neposlední řadě i interní směrnice a předpisy. na disku je neustále ukládáno velké mnoţství dat, a to způsobuje rostoucí nároky na hardware i komplikuje se i zálohování. komplikované vyhledávání. Nikde neexistuje „obsah“ disku ani nebyla stanovena jasná pravidla pro pojmenovávání jednotlivých souborů. 40
avizování aktualizací obsahu lze provádět pouze e-mailem, coţ v konečném důsledku opět zvyšuje objem dat ve schránkách jednotlivých uţivatelů. Jako první krok jsem provedla analýzu bezpečnosti informačního systému dle teorie kapitola 8. se zodpovědným pracovníkem. Vyplněný dotazník s otázkami je součástí této práce jako příloha č 1.
9.6
Klíčoví uživatelé systému
Obrázek 8 Klíčoví uživatelé systému
41
10 Prodej a marketing
Divize prodej – komplexní zakázky – udrţuje vztahy se stávajícími zákazníky a navazuje nové kontakty nejen v ČR, ale také v zahraničí. Koordinuje činnost prodejců (KAMů) s cílem plnění strategického plánu podniku a získávání nových obchodních případů či příleţitostí. Získává, analyzuje a vyhodnocuje informace o trhu a konkurenci. Na základě zjištění upravuje a přizpůsobuje taktické plány. Úzce spolupracuje s úsekem nabídky. Úsek nabídky – vypracovává detailní návrh nabídky včetně cenové specifikace, na základě podkladů předaných odbornými útvary podniku. Vypracovává kalkulační list, který slouţí jako podklad pro informaci o nákladech zakázky. Divize prodej – specializované zakázky – zde spadá především nákup a prodej externích produktů třetím stranám a veškeré činnosti s touto funkcí spojené. Úsek Corporate Identity – znamená v překladu firemní styl či firemní kulturu. Jedná se především o vystupování firmy vůči zákazníkům. S tím souvisí tiskoviny, reklama, internet nebo také organizování společenských akcí pro obchodní partnery a zajišťování reklamních předmětů. 42
10.1 Využití ISN v rámci obchodu – popis aktuálního stavu
Jednotlivé obchodní příleţitosti se jiţ od formy nabídky, aţ po předání do projektového řízení zpracovávají v divizi Obchod. S tím souvisí velké mnoţství dokumentů - papírová forma nabídky, smlouvy, prezentace a kalkulační listy, které připravuje divize Výroba či Nákup a které jsou následně po uzavření smlouvy předávány divizi Projektové řízení. Veškeré dokumenty (přijaté podklady zákazníka, specifikace, dokumenty pro nabídku, kalkulační listy atd.) jsou ukládány na disk I ve formátech MS Office. Databáze obchodních případů je ukládána pod vlastním evidenčním číslem do systému Navision. Toto oddělení také vykazuje měsíční přehledy přijatých poptávek, odeslaných nabídek, a realizovaných zakázek ve formě Power Point pro Bussiness review meeting. Jelikoţ zde pracuji, ráda bych největší pozornost věnovala tomuto oddělení. Ke své práci aktivně vyuţívám informační systém Navision a také data uloţená na disku I, kde také já, velmi často ukládám své dokumenty. V této části práce, se chci zaměřit na zpracování postupu vyuţívání informačního systému a zaměření se na jeho nedostatky, duplicity, či zbytečnosti tak, aby následné navrţené řešení přispívalo k efektivnějšímu průběhu a zlepšení celého procesu. Veškerá činnost související s obchodním případem začíná se zavedením dat do informačního systému Navision. Data uložena v systému nám poskytují evidenci: Příchozích poptávek Odeslaných nabídek Očekávaných příleţitostí Katalogu kontaktů. K zavedení obchodní příleţitosti do informačního systému je nutné vybrat z katalogů kontaků příslušného zákazníka s přiřazeným číslém kontaktu, případně ho do informačního systému zavést. Tvorbu nových kontaktů provádí několik vybraných zaměstnanců, kteří ovšem neprošli řádným školením, pouze byli seznámeni s vybranými poloţkami systému, které je nutné vyplnit, aby byl zákazník resp. dodavatel zaveden do katalogu kontaktů. Jelikoţ se jedná o pracovníky z odborných úseků, nevyplňují data pravdivě (např. náhodné IČO, DIČ), protoţe je vyhledávání informací o zákazníkovi zdrţuje od jejich práce. Z tohoto důvodu se na některá data v informačním systému nedá spolehnout. 43
Jakmile vybereme příslušného zákazníka, přistoupíme k evidenci samotného obchodního případu. Prvním krokem evidence našich obchodních případů je zaloţení příleţitosti. Za příleţitost povaţujeme jakoukoliv zakázku, která přijde například formou mailu jako poptávka, či dlouhodobě očekávané obchodní případy, které budou realizovány během pár let. Zaloţení příleţitosti ovšem neznamená realizaci zakázky. O určitém procentu (přibliţně 10%) obchodních případů se rozhodne, ţe nebudou nabízeny, vzhledem pro nás nereálnému splnění technických poţadavků, včasnému odevzdání plnohodnotné nabídky v termínu, či plnění termínu dodání nebo montáţe. Pro tyto účely slouţí porady jednotlivých oddělení „Bid no bid“, na kterých se o přijmutí zakázky rozhoduje. „Bid no Bid“ neprobíhá u všech příleţitostí. Pokud se jedná o překupy, či zakázky do hodnoty 100.000,- Kč, bývají vţdy nabídnuty bez předchozí porady, na základě rozhodnutí vedoucího Nabídkového oddělení. Karta příležitosti obsahuje: Evidenční číslo příleţitosti Evidenční číslo zákazníka Datum příleţitosti Popis příleţitosti Předpokládané datum uzavření Pravděpodobnost uzavření KAM Kód prodejního cyklu Očekávaná hodnota obchodního případu Číslo prodejní nabídky – v případě, ţe je přiřazena.
Každá příležitost probíhá určitou fází. Příleţitost Poptávka/BNB RRM 44
Nabídka Hot Tender Smlouva Předání k realizaci Příleţitosti nám slouţí k přehledu obchodních případů. Moţnost filtrace dle prodejců či zákazníků nám umoţňuje je zapracovat do obchodních plánů společnosti.
Obrázek 9 Karta Nabídky
Každá karta nabídky nám nabízí přehled: Identifikační údaje o zákazníkovi KAM a nabídkáře dané nabídky Hodnotu zakázky 45
Datum přijetí zakázky Údaje o zakázce (popis, typ zakázky, incoterms….) Stav zakázky (Nabídka – Poptávka – Příprava – Realizace – Storno) V případě storna uvádíme také důvod. Systém Navision nám umoţňuje rychlou filtraci, dle jakýchkoliv zmíněných údajů či kombinaci údajů. Díky tomu, můţeme kdykoliv získat přehled např. o otevřených zakázkách, ať uţ například dle typu zakázek, či odpovědných KAMů. Zde vidím především problém v mnohočetném zapínání filtrů, kdy ztrácíme přehled, jaký filtr máme nastavený, tudíţ vzniká velké riziko, ţe nám systém neposkytne přesné a úplné hledané informace. Systém Navision nabízí moţnost tvorby sestav, které jsou v systému defaultně nastaveny a parametry pro vyhledávání jsou zadávány v jednom místě, tudíţ nedochází k chybám. Parametry či návrh sestavy, do systému zavádí odpovědný pracovník, tím zajistí, ţe nebude docházet ke vzniku duplicitních sestav s minimálními odlišnostmi. Bohuţel u nás ve společnosti tento nástroj vůbec nevyuţíváme. Místo toho zbytečně a neustále dokola přepisujeme a kopírujeme data do nekonečného mnoţství tabulek v Excelu. Největší problém v opakovaném vkládání identických informací je skutečnost, ţe obchodní případ zavedený v informačním systému se v jeho jednotlivých částech promítá v různých stavech a fázích. To nám neumoţňuje tato data správně pouţívat a následně zpracovávat.
46
Obrázek 10 Redundance údajů
10.2 Proces překupu materiálu Celkový proces a vyuţívání systému Navison předvedu v následující kapitole, kde detailně popíši cyklus činností mezi obchodním oddělením a oddělením finance. Zaměřím se také na problém, zda je aktivně a efektivně vyuţíván systém Navision. Naše společnost se velmi často stává prostředníkem mezi výrobcem a zákazníkem při překupech materiálu. Jak proces probíhá, vidíme na vývojovém diagramu.
47
Poptávka zákazníka
Žádost o zpřesnění
Poptávka výrobci
Ne Má přesné informace?
Ano
Nabídka od výrobce
Nabídka pro zákazníka
Je spokojený?
Ne
Sleva
Ano
Přijde objednávka
Objedná?
Nová nabídka
Ne
Storno
Vystavení nákupní objednávky na výrobce
Obejdnání dopravy – odvoz k zákazníkovi
Fakturace
Obrázek 11 Vývojový diagram
48
Průběh procesu při překupu materiálu
10.2.1 Přijetí poptávky a vytvoření nabídky Výchozím stavem je přijetí poptávky od zákazníka v obchodním oddělení. Veškeré poptávky chodí formou mailu, jelikoţ jako přílohy obsahují většinou výkresy nebo schéma poptávaného zboţí. V tento okamţik příslušný obchodník zadá obchodní případ do systému Navision (systém zavádění příleţitostí a nabídek, jeho klady a zápory jsou popsány v kapitole detailního popisu práce s kartou Nabídky a Příleţitost) a přidělí mu obchodní evidenční číslo. Jiţ nyní jsou krátce za sebou do systému zavedeny dvakrát identické detailní informace o zakázce. Následně obchodník přepošle poptávku výrobci, který na základě dostatečných informací o zboţí vytvoří nabídku pro prodávajícího. Podle této nabídky od výrobce, obchodník vypracuje v předpřipraveném dokumentu Word nabídku pro zákazníka, po podpisu vytiskne, naskenuje a odešle zákazníkovi. Zároveň tuto nabídku ve formátu PDF spolu s formátem Word uloţí na disk I, pod příslušné evidenční číslo zakázky. Je nutné také vyplnit Kalkulační list nákladů ve formátu Excel a opět uloţit na disk I pod stejné evidenční číslo. Ke kalkulačnímu listu náleţí také výpočet cash-flow v programu KEFIS. V případě, ţe zákazník není s cenou spokojen, a je to moţné, nabídneme případnou slevu. To obnáší nové přepsání nabídky ve formátu Word, opětovné tisknutí, skenování a ukládaní na disk jako revize nabídky. V případě zamítnutí nabídky, příslušný obchodník v systému Navision uvede kartu obchodního případu Nabídky do stavu Storno. Toto ovšem neprovádí v kartě Příleţitost, a jelikoţ není ani propojena s kartou Nabídky, zůstává stav v původním znění Příleţitost. Protoţe nedochází k důslednému uzavření obchodních zakázek ve všech částech informačního systému, jsou místě, kde obchodní případy stále figurují jako aktivní.
10.2.2 Objednávka zboží Potvrzení objednávky zboţí zákazník stvrdí podpisem a razítkem na formuláři naší nabídky nebo vlastním interním tiskopisem. V tomto okamţiku, další pracovník (v případě naší společnosti se jedná o asistentku obchodního ředitele) přidělí zakázce číslo smlouvy a 49
jiţ veškeré fakturační činnosti probíhají pod hlavičkou čísla ve formátu číslo smlouvy/evidenční číslo zakázky z ISN. Často se stává, ţe dochází k zpětnému opravení čísla smlouvy. Toto je evidentně způsobeno přístupem několika zaměstnanců do systému v jeden okamţik současně. Dále obchodní oddělení vytvoří podle objednávky v ISN poptávku pro nákupní objednávku pro oddělení Nákup. To souvisí s opětovným vyplněním informací o zakázce, tzn. popis, cena, počet ks, technické podmínky, termín dodání, místo dodání. Oddělení nákup přidělí v systému Navision poptávce své evidenční číslo a tím vytvoří nákupní objednávku na dodavatele, kterou po podpisu generálního ředitele odešle. Obchodník mezitím nechá příslušný kalkulační list podepsat ředitelem rozdělení Realizace. Následuje opět skenování a ukládaní na disk I. Po opsání kalkulačního listu z papírové podoby do ISN – záloţka Projekty, jej odešleme ve formátu PDF spolu s objednávkou a číslem smlouvy na oddělení controlling s ţádostí o otevření do realizace. Tím je myšlena změna stavu v ISN ze stavu Hot Tender na stav REAL.
10.2.3 Předání zboží zákazníkovi a fakturace Po obdrţení informace od výrobce o přichystání zboţí k expedici, obchodní oddělení vytvoří objednávku dopravy. Jedná se o vyplnění formuláře pro dopravu, který nám poskytl dopravce. Neţ dojde předání zboţí dopravci a dodání k zákazníkovi, obchodní oddělení vyplní dodácí list. Jedná se o formulář ve formátu Excel.
50
D o d a va te l :
poč et lis tů : lis t č . :
D O D A C Í L IS T č .
P říje m ce :
D opravc e : K am ion : M ísto d o d á n í :
z a ká z ka k ontak t : č. sm lo u vy : o d b ě ra te lská : d o d a va te lská :
z a ká z ka
p o lo ž ka
p o če t
Ná z e v
TO TAL
B T T O /kg / :
TO TAL
N T T O /kg / :
M a te riá l
P o z n á m ka
V y s tavil : D atum :
V y dal :
P řevz al :
Obrázek 12 Dodací list
Jedná se o další dokument obsahující identické informace o zakázce, které jiţ byly opakovaně vyplňovány v ostatních dokumentech. Dochází opět ke skenování a ukládání na disk I. Tento formulář obchodník osobně doručí výrobci, který si ho nechá dopravcem při převzetí potvrdit. Potvrzený dodací list vrací obchodnímu oddělení naší společnosti. Tento dokument má více kopií, kdy poslední potvrzenou o příjmu zboţí nám následně zákazník po obdrţení zasílá jako originál zpět. Po získání tohoto dokumentu přecházíme k fakturaci. Obchodní oddělení připraví pro oddělení finance příkaz k vystavení faktury.
51
P řík a z k v y s ta v e n í:
DODA V A T EL
F AK T U R A - d a ň o v ý d o k la d
IČ O
IČ O
ODBĚRA T EL
DIČ :
DIČ :
BA NK. SPOJENÍ / HOT OV OST
PŘÍJEM C E
DA T UM V YST A V ENÍ DOKL A DU DA T UM Z DA NIT EL NÉHO PL NĚNÍ KÓD PL A T EBNÍ PODM ÍNKY T YP Z A KÁ Z KY So D ODBĚRA T EL E So D DODA V A T EL E ST ŘEDISKO / DIV IZ E Č ÍSL O Z A KÁ Z KY
M ÍST O PL NĚNÍ PŘEDM ĚT PL NĚNÍ
Z BOŽ Í
POPIS
SL UŽ BA
M NOŽ ST V Í
JEDN. C ENA
M ĚRNÁ JEDNOT KA
C EL KEM
0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Z Á KL A D DPH - C EL KEM
19%
DPH
0,00
CELKO V Á ČÁS TKA
Č ÍSL O Z Á L OHY
Č Á ST KA vč. DPH
Obrázek 13 Příkaz k vystavení faktury
I zde dochází k dalšímu přepisování údajů do dokumentu ve formátu Excel, který se vytiskne, naskenuje a zašle mailem finančnímu oddělení. Toto oddělení po přijetí příkazu k vystavení faktury, fakturu vytiskne a zašle zákazníkovi. Opět ve formátu PDF uloţí na disk I a kopii předá obchodnímu oddělení.
52
0,00
Poslední fází je poţadavek na oddělení controlling na uzavření zakázky v systému Navision. K tomu nám slouţí excelová tabulka Uzavření zakázky. Controlling na základě tohoto dokumentu provede v systému Navision – záloţka Projekty změnu stavu zakázky z REAL na DOKONČENO. Obchodník v systému Prodej a Marketing změní stav zakázky z Nabídka na Real. P o ž a d a v e k n a u z a v ře n í z a k á z k y v IS N P oz n.: údaje v b arevně oz nač enýc h políč k ác h volte výb ěrem z nab ídk y D iviz e :
02 - P ro je kty
Za ká z ka :
e x te rn í
Evid e n čn í číslo : P o p is: PM: D a tu m p o sle d n í fa ktu ra ce :
Zá d rž n é :
ne
ne
ne
ne
ne
ne
ne
ne
ne
ne
O db ěratel: Č ás tk a: S platnos t: Zá d rž n é : D odavatel: Č ás tk a: S platnos t: B a n ko vn í z á ru ka :
ne
Č ás tk a: Ty p:
z a z á d rž n é
P latnos t do: G a ra n čn í re z e rva :
a no
Č ás tk a: P latnos t do: R iz iko vá re z e rva :
a no
Č ás tk a: P ředpok ládaný term ín roz puš tění: D ůvod: P o h le d á vky k d a tu u ko n če n í z a ká z ky:
a no
O dběratel:
Č ás tk a:
Zá va z ky k d a tu u ko n če n í z a ká z ky: D odavatel:
ne Č ás tk a:
Obrázek 14 Požadavek na uzavření
53
10.3 Výběrové řízení Mezi další časté obchodní případy patří výběrová řízení obchodních balíčků pro komplexní obnovy elektráren. V této oblasti mám velké zkušenosti, jelikoţ pracuji jako specialista prodeje pro tendrová vypsání komplexní obnovy elektrárny Prunéřov a Ledvice. Jednotlivý tendr od vypsání aţ po podepsání smlouvy probíhá v časovém horizontu 1-2 let. Kaţdé vypsání je povaţováno za samostatný projekt. V současné době po obdrţení zadávací dokumentace, vyzvu ředitele případně vedoucí jednotlivých Oddělení (případně delegovaných zástupců) k účasti na nabídkové poradě. Těmto přítomným předám předběţný harmonogram a podklady pro zpracování jednotlivých částí výběrového řízení. Výběrové řízení je zaloţeno na zpracování jednotlivých podkladů vypsání, které mají určitou návaznost a vyţadují spoluprací jednotlivých oddělení. Bohuţel v současné době organizování této činnosti není dostačující. Nejsou stanoveny zodpovědné osoby za jednotlivé oddělení a veškeré komunikace je prováděna přes ředitele/vedoucí oddělení, kteří delegují práci na momentálně volné pracovníky. V okamţiku revizí vznikají značné problémy, jelikoţ pracovníci neznají historii zakázky, nemají potřebné podklady, případně je zpracují duplicitně atd., revize v průběhu projektu probíhají opakovaně.
54
11 Úseky divize výroba
Úsek řízení zakázek Útvar zajišťuje proces řízení výrobních zakázek prostřednictvím projektových manaţerů v rámci procesu výroby divize Výroba. Vedoucí koordinuje činnost úseku, přijímá nové zakázky a rozděluje je jednotlivým manaţerům zakázek k další realizaci a v konečné fázi zajišťuje ukončení zakázky a fakturaci. Sleduje průběh realizace jednotlivých zakázek, zejména pak plnění harmonogramů i dodrţování schváleného rozpočtu. Determinuje příleţitosti a rizika, které během realizace vyplynou. Zajišťuje kooperaci, kumuluje klíčové ukazatele do manaţerských reportů, které dále prezentuje vedení společnosti, a je odpovědný za tvorbu kapacitních plánů divize výroby.
Obchodně technický úsek Zajišťuje technické zpracování zakázek přes fázi kalkulace a nabídky aţ v případě přijetí zakázky přípravy zakázky do výroby (výrobní postupy, směrnice pro svařování, ohýbání, tepelné zpracování, povrchovou úpravu apod.).
55
Výroba
Provozní úsek výroby zajišťuje v rámci společnosti vlastní proces výroby v předem stanoveném termínu, kvalitě a ceně.
Kvalita Zodpovídá za řízení a kontrolu jakosti během výrobního procesu i následné zpracování průvodní technické dokumentace. Oddělení zodpovídá i za kvalitu (kontrolu kvality) veškerých vstupů. Úsek eviduje veškeré neshody a dohlíţí na jejich řešení – primárním cílem je vyřešení daného problému, ale pokud se zjistí systémová chyba, navrhuje návrh jejího odstranění (nejčastěji změnou příslušné směrnice)
Vzhledem k přístupovým právům zaměstnanců, kteří mají přístup a moţnost práce s informačním systémem pouze v částech, které přísluší jejich oddělení, provedla jsem analýzu v oddělení Výroba na základě rozhovoru se zodpovědným pracovníkem Ondřejem Mejzlíkem MSc., který mi poskytl velmi cenné informace.
Prioritním úkolem výroby je realizace přijatých zakázek v předem dohodnutém termínu, kvalitě a ceně. Zejména z hlediska termínů je pro výrobu bezpodmínečně nutný přístup k aktuálním informacím o očekávaných zakázkách. Na základě těchto informací jsou rozpracovávány kapacitní plány a ty jsou pak východiskem pro optimalizaci výrobních kapacit – zejména v oblasti lidských zdrojů s vyuţitím externích (agenturních) pracovníků. Ve výrobě jsou dva typy pracovišť: 1.
Kapacitu lze zvýšit dodatečným přiřazením pracovníků. Jedná se zejména o ruční
zámečnické práce, svařování a povrchovou úprava – nátěry. 2.
Úzká místa – kapacita je omezena technickými vlastnostmi strojního vybavení.
Jedná se zejména o ohýbačky, pece a tryskací box.
56
Kapacitní plány výroby jsou zpětně vyuţívány úsekem Prodej a marketing při uzavírání nových kontraktů – termíny jsou nabízeny s ohledem na aktuální výrobní moţnosti a tím se předchází případným kolizím ve fázi realizace
11.1 Využití ISN v rámci výroby – popis aktuálního stavu „Cílem kaţdého IS je koncentrace dat, eliminace duplicitních záznamů a distribuce relevantních informací jednotlivým uţivatelům. Přestoţe je z hlediska organizační struktury společnosti divize výroba zcela samostatná a soběstačná organizační jednotka, INS tyto „hranice“ stírá a předpokládá kontinuální zpracování dat napříč celou společností. To znamená, ţe výroba navazuje na práci jiných úseků a naopak výstupy z výroby jsou dále vyuţívány. Dalším důleţitým faktorem je stále probíhající proces implementace ISN; systém byl sice nasazen jiţ v roce 2005 s příchodem nového investora do společnosti, ale od té doby se několikrát změnila organizační struktura i střední management. Tyto změny sebou vţdy přinesly změnu v nárocích na informační systém; vývoj některých funkcionalit nebyl dotaţen k pouţitelnosti (zejména plánování výroby), a jindy byly zase standardní funkce modifikovány k obrazu aktuálních uţivatelů. Zřejmě největší chybou bylo, ţe nebyla vytvořena ucelená koncepce, ale kaţdý úsek si modifikoval „svůj“ modul individuálně bez ohledu na ostatní uţivatele. Za chybu povaţuji i to, ţe ve společnosti není za informační systém nikdo přímo zodpovědný, někdo s nadhledem, který by dokázal harmonizovat poţadavky jednotlivých uţivatelů tak, aby systém zůstal celkově kompaktní. Ironií je, ţe se během posledního roku v mnoha oblastech opustilo mnoho nově zavedených funkcí a společnost se vrací ke standardu.“
57
V další části našeho rozhovoru jsme se zaměřili na současnou míru vyuţívaní a očekávání pracovníků v jednotlivých úsecích.
11.1.1 Úsek řízení zakázek (UŘZ) Současné využívání systému: Vytvoření nové výrobní zakázky – Při vytvoření nové výrobní zakázky, vţdy vybírá z jiţ přístupného seznamu zákazníků. Zákazníky, příp. dodavatele do systému nezakládá. V informačním systému také nikdy nevyuţívám vytvoření obchodní příleţitosti a veškeré výrobní zakázky zavedené v systému (Nabídky) nejsou spojeny s ţádnou obchodních příleţitostí. Vytvoření prodejní objednávky Komplexní přehled o průběhu realizace 1. Kdy byly vytvořeny jednotlivé výrobní příkazy 2. Sledování změn (změny norem, změny postupů, změny materiálových vstupů) 3. Kolik hodin bylo na výrobu vydáno a kolik je jiţ vyčerpáno 4. Průběh prací v úseku výroba, přehled o dokončených operacích 5. Náklady vstupující do zakázky – data pořízená finanční účtárnou 6. Datum dokončení jednotlivých výrobních příkazů – konečná výrobní kontrola 7. Přehled o frontách práce (vytíţení jednotlivých pracovišť, plán průchodu dané poloţky výrobním procesem. Vývoj modulu plánování nebyl ukončen (vedení změnilo priority) a pro praktické vyuţití je NEPOUŢITELNÝ. Moţnost převést dokončenou výrobní zakázku na sklad
58
Očekávání použití možných funkcionalit systému Navision: Komplexní přehled o náročnosti všech realizovaných zakázek (workload) – v současné době je tato funkce nepouţitelná. Kapacitní plány jsou prozatím vedeny v podruţné evidenci ve formátu MS Excel a sdílena v rámci souboru na serveru. Výstupem je graf, který zobrazuje očekávané vytíţení jednotlivých pracovišť v čase a zároveň zobrazuje vlastní kapacity. Snadný přístup ke smlouvám – nyní jsou smlouvy přístupné formou odkazů uvedených v informačním systému Navision na příslušný soubor na serveru. Problémy vznikají v případě, ţe je cílový soubor přesunut nebo přejmenován, v tom okamţiku se odkaz stane neplatný a tudíţ nepouţitelný. Jako další nedostatek pan Mejzlík v tom, ţe nám informační systém nedovoluje sledovat historii změn. Tzn. jednotlivý vývoj schválených připomínek a změn smlouvy v čase a jejich dopady.
11.1.2 Obchodně technický úsek (OTÚ) Moţnost vytvořit technologický postup – skládá se z těchto kroků ve dvou úrovních 1.
Konstrukce Zaloţení karty zboţí (definice finálního výrobku) Vytvoření ţádanky – sumář poloţek – slouţí jako podklad pro příjem zboţí na sklad Vytvořit kusovník – kompletní výčetka všech komponent, ze kterých je daná zakázka tvořena. Vytvoření konstrukční rozpisky – definuje komponenty jednotlivých logických celků – většinou se jedná o kompletní montáţní trasu.
2.
Technologie Vytvořit technologický postup – sled operací vč. předepsaných kontrol a zkoušek Jednotlivé operace ohodnotit časem 59
Vytisknout technologický postup.
Výroba (V) 1. Moţnost odepsat výkony pracovníků (hodiny) do ISN 2. Mít přehled o odpracovaných hodinách (kdo, co, kdy a kolik) 3. Komplexní přehled náročnosti všech realizovaných zakázkách – NEPOUŢITELNÉ (viz. ÚŘZ výše) 4. Přehled o frontách práce – NEPOUŢITELNÉ.
Kvalita (K) 1. Moţnost potvrdit konečnou výrobní kontrolu
Další částí našeho rozhovoru byl popis dílčích kroků při průchodu zakázky tímto oddělením. Krok 1 - Přijetí zakázky do realizace – UŘZ převzetí zakázky do realizace (výrobní dokumentace, smlouvy, historie komunikace před uzavřením kontraktu, harmonogramy apod.) – papírová podoba zaloţení karty projektu v ISN (viz. obr. 15). Karta projektu obsahuje: 1. Informace o zákazníkovi 2. Popis díla 3. Osoby zodpovědné za projekt (projektový manaţer, hlavní inţenýr projektu, nákupčí) 4. Kalkulační list – detail rozpočtu projektu (plánované výrobní hodiny, nakupovaný materiál a sluţby, finanční náklady apod.). 60
Obrázek 15 Karta projektu
Krok 2 – Otevření zakázky - Controlling Zajišťuje firemní controlling na základě ţádosti z ÚŘZ. Ţádost je písemná a její součástí je kalkulační list a smlouva.
Krok 3 – Vytvoření prodejní objednávky – ÚŘZ Prodejní objednávka (obr. 16) obsahuje údaje o zákazníkovi a konkrétní expediční poloţky, které jsou v dalších fázích rozpracovávány do pracovních postupů.
61
Obrázek 16
- Prodejní objednávka
Krok 4 – Vytvoření vydané výrobní zakázky – ÚŘZ Vydaná zakázka (obr. 17) přebírá údaje z prodejní objednávky + umoţňuje vytvářet technologické postupy u jednotlivých expedičních poloţek. Současně s postupy vzniká i konstrukční rozpiska a kusovník zakázky.
Obrázek 17 - Vydaná výrobní zakázka
62
Přímo na kartě je vidět číslo poslední operace, která je dokončená (samozřejmostí je zobrazení všech předešlých operací vč. vykázaných časů pracovníků – viz. obr. č. 19). Seznam automaticky označuje čas práce přes normu.
Krok 5 – Vytvoření technologického postupu - OTÚ Technologický postup je návodka pro výrobu, která určuje sled jednotlivých operací (jednotlivá pracovní centra, způsob výroby a plán kontrol a zkoušek). V rámci technologického postupu byla zavedena evidence změn – zpětně je moţné zjistit, kdo, kdy a co v postupu měnil (obr. 18). Po dokončení technologického postupu je vytištěn a předán do ÚŘZ
Krok 6 – Předání technologického postupu do realizace - ÚŘZ Kromě fyzického předání je nutné v rámci karty vydané výrobní zakázky u příslušné expediční poloţky potvrdit pole „uvolněno“ (obr. 17). Bez této operace nemůţe úsek výroba odvádět odpracované hodiny. Po uvolnění se naopak zablokuje moţnost OTÚ do postupu zasahovat. Tímto způsobem má ÚŘZ zajištěn přehled nad jednotlivými expedičními poloţkami.
Krok 7 – Výroba Výroba probíhá podle připravených technologických postupů. V rámci výroby jsou pořizována pouze data o provedených operacích a časech práce (zakázka, pracovník, datum, operace a délka práce).
Krok 8 – Konečná výrobní kontrola (KVK) – Kvalita Je posledním krokem v rámci výroby. Pozitivní KVK je zaznamenáno v rámci karty vydané výrobní zakázky v příslušném sloupci. Z informace je zřejmé, kdo a kdy KVK za kvalitu provedl (obr. 20). 63
Bez potvrzení KVK není moţné zakázku v ISN ukončit ani převést do skladu – viz. krok 9
Krok 9 – Odvádění výroby na sklad – ÚŘZ Odvádění provádí úsek výroba na ţádost ÚŘZ. Odvádění je poslední operací v rámci kaţdého technologického postupu, a pokud je tato operace potvrzena, expediční poloţka je automaticky převedena na sklad. Tato operace je místem častých problémů mezi divizí výroba a úsekem sklady. Většinou se aţ zde projeví chyby, které vznikly během zadávání jednotlivých zakázek do ISN – chyby ve vyskladňování materiálu, špatně zadané karty zboţí, špatná číselná řada účtování apod. a tyto chyby se přenášejí do jiného úseku. Úsek sklady je v rámci procesu poslední a další odklad problému jiţ není moţný.
Krok 10 – ukončení zakázky v ISN – ÚŘZ Zakázku je moţné ukončit aţ po odvedení všech expedičních poloţek na sklad. Ukončení zakázky je jednosměrný akt – po provedení se přesune nenávratně do historie.
Obrázek 18 - Vydaná výrobní zakázka - historie změn
64
Obrázek 19 – Vydaná výrobní zakázka - seznam dokončených operací
Obrázek 20
- Vydaná výrobní zakázka - potvrzení konečné výrobní kontroly
65
12 Projektové řízení Dle organizační struktury tento segment je také přímo podřízen GŘ a sám je zodpovědný za divizi Engineering a Realizace projektů. Má na starosti koordinaci činností spojených s řízením zakázek, především soulad s obchodními podmínkami, dodrţování plánovaných nákladů s odvoláním na kalkulační list, výběr správného dodavatele, který včasně zajistí kvalitu dodávky.
12.1 Realizace projektů
Řízení projektů Klíčovými osobami, zodpovědnými za řízení projektů jsou:¨ Projektový manager – koordinuje členy projektového týmu Ekonom Projektu – analyuje cash flow projektu, eviduje faktury, naklady atd. Hlavní inženýr projektu – řídí projekční práce Plánovač – spravuje celý harmonogram projektu.
66
Kvalita Zajišťuje fungován procesů v rámci projektového řízení v oblasti řízení a kontroly kvality, pokrývající zejména oblast kontroly kvality subdodávek a výstupní kontrolu kvality předávaného díla. Klíčové osoby jsou: Inženýr kvality – řídí a kontroluje poţadavky na kvalitu Přejímač – kontroluje přejímky se zákazníkem, kontroluje soulad se smlouvou
Projektový nákup Toto oddělení má na starosti zajištění nákupu materiálu, zboţí na základě stanovených specifikací pro jednotlivé zakázky. Náplní práce je především vyhodnocení nejvhodnějšího dodavatele na základě dodavatelských vztahů, kvality či ceny.
12.2 Realizace Engineering
Ředitel divize Engineering je podřízen řediteli segmentu Projekty. Řídí a kontroluje zpracování dokumentačních částí projektů a naplnění poţadavků na dokumentaci definovaných smluvními ujednáními.
67
13 Divize Finance a Controlling
Tato divize se zodpovídá přímo GŘ, jelikoţ její činnosti jsou spojené s řízením finančních toků a zdrojů nutných pro zajištění chodu společnosti. Typickými reprodukčními procesy v jednotlivých oddělení jsou: Finance: vedení účetnictví společnosti a archivován účetních dokladů zpracování uzávěrek a výkazů aktivní podíl na zpracování směrnic a postupů v této oblasti Controlling: zpracovává finanční ekonomický a investiční plán společnosti kontroluje, analyzuje a vyhodnocuje plnění plánů projektuje a vyhodnocuje cash-flow jednotlivých zakázek
68
Obrázek 21 Workload
V rámci naší společnosti nemám přístup do funkcí této divize. Vyuţila jsem tedy informace, z analýzy informačního systému z poloviny roku 2008. Jedním z pravidelných výstupů oddělení je dokument Kontrolní a řídící tabulka projektů v MS Excel. Dalším pravidelně zpracovávaným dokumentem je výhled pracovní náplně workload. Tabulka v MS Excel obsahuje obecnější výhled na zakázkovou náplň, v jeho rámci zpracovává i výhled pracovní náplně na existujících zakázkách. V oddělení Controlling a Finance je mnoho moţností jak systém lépe vyuţívat, pro jasné detailní a přesné zpracování, by bylo nutné se systémem určitou časovou dobu pracovat. Bohuţel k záloţkám tohoto oddělení nemám přístup, tudíţ byly navrţené pouze změny uplatňované v rámci obchodního oddělení uvedené v kapitole.
69
14 Oddělení obchod Veškeré činnosti a práce s informační v tomto oddělení je vţdy spjata s kontaktem (zákazníkem, dodavatelem) zavedeným v IS. Je nezbytné nutné stanovit jednu osobu, která bude zodpovědná za přiřazování kontaktů. Za nezbytné informace uvedené v kartě zákazníka povaţuji.
Obrázek 22 Katalog kontaktů
70
Přístup do modulu zavádění kontaktů je vhodné přidělit minimálnímu počtu zaměstnanců, ale tak, aby byla zajištěna jejich zastupitelnost. Budou plně zodpovědní za uvedené údaje s nutností periodické aktualizace.
Jiţ v počáteční fázi zavádění příleţitostí bych zavedla radikální změnu. Celou funkci Příleţitost bych zrušila, či zavedla striktní evidování s reálnými údaji, aktualizování a důkladné propojení s funkcí Nabídky, tak, aby vznikla moţnost tuto funkci efektivně vyuţívat. V tomto stádiu a formě vyuţívání ztrácí jakýkoliv smysl. Pokud by byla snaha funkci Příleţitost zachovat, navrhuji redukování fází nabídky.
Obrázek 23 Fáze Nabídky
Navrţené fáze jsou dostačující, vzhledem k tomu, ţe nyní skoro ţádný z uţivatelů systému fáze nemění, a aţ do přijetí, či storna zakázky zůstanou stejné. Tzn. Většinou ve stavu Příleţitost. Důvod neochoty aktualizovat data, připisuji také tomu, ţe fáze má zbytečně velké mnoţství kroků, které by bylo nutno velmi často měnit, a přitom by změna stavu našemu obchodnímu rozhodování neposkytla ţádnou novou informaci, na základě které by se změnilo obchodní rozhodnutí.
71
Velký přínos aktualizace fází příleţitostí by byla moţnost statistik, či přehledů vyuţít při Bussines Review Meetingu, ve kterém se promítá přehled zakázek před uzavřením. Jednoduchá sestava vytvořená v programu Navision, by nám dala okamţitou představu, dostupnou v jakémkoliv časovém okamţiku. Tento nástroj by ocenil především vrcholový management, který by měl kdykoliv moţnost vidět vývoj obchodních případů. Přehled je opět moţno pozorovat z pohledu Key account managera či typu zakázky. Nyní musí vedení společnosti čekat na BRM, které probíhá jednou měsíčně. Podklady pro tuto poradu se opět připravují ve formátu Excel, a to překopírováním dat ze systému Navision. Dále bych se zaměřila ne duplicitní údaje zadávané do karty příleţitost a karta nabídky. Povaţuji za důleţité tyto nedostatky odstranit, protoţe vznikají nesouhlasné informace v kartě Příleţitosti a nabídky u stejného obchodního případu. Rozdíly jsou dány opakovaným vyplňováním stejných informačních polí. Data uvedená v kartě příleţitosti by se měla propojit do karty Nabídky.
Obrázek 24 Propojení karet Příležitost - Nabídka
72
Největší problém v opakovaném vkládání identických informací je skutečnost, ţe obchodní případ zavedený v informačním systému se v jeho jednotlivých částech promítá v různých stavech a fázích. To nám neumoţňuje tato data správně pouţívat a následně zpracovávat.
14.1 Proces překupu materiálu Přijetí poptávky a vytvoření nabídky – navazuje na analýzu kapitola 10. Aţ do tohoto místa, vytváření nabídky ve formátu generovaného z ISN, který bere data námi jiţ jednou zadaná. Není třeba opravovat formát Word. Stačí pouze změnit prodejní cenu, či zadat výši slevy v ISN,která se nám zároveň uchová jako informace o zakázce a umoţní nám rychlý tisk. Je zde také nutná inventura otevřených obchodních případů, a pokud došlo k zamítnutí ze strany zákazníka nebo ze strany naší společnosti, Příleţitost uzavřít.
Objednávka zboží Je nutné zajistit a ošetřit, aby do funkce přiřazování čísla smluv v ISN měla v jeden okamţik zajištěna přístup pouze jedna osoba a nedocházelo k duplicitnímu přivlastňování čísel. Opět zde vidíme nedostatky v nepropojenosti informačního systému a stálého a opakovaného vyplňování identických poloţek. Jak v záloţkách jednotlivých oddělení, tak mezi záloţkami vzájemně. Dalším problémem je čekání na podpis nákupní objednávky od generálního ředitele. Vzhledem k tomu, ţe GŘ se nevyskytuje ve firmě stále, navrhuji, aby pro zakázky do určitého objemu peněz, byla příslušnému pracovníkovi přidělena kompetence tyto objednávky podepisovat. Můţe se jednat například o vedoucího nákupu.
73
Předání zboží zákazníkovi a fakturace V této fázi dochází k vytvoření dalších dokumentů. Za zcela zbytečný povaţuji dokument Příkaz k vystavení faktury. Navrhuji, aby obchodní oddělení provedlo samostatně tisk faktury ze systému Navison a pouze o tom informovalo oddělení controlling, který provede kontrolu faktury v systému a pokud nezjistí ţádné nejasnosti, odešle fakturu zákazníkovi. Tím eliminujeme jeden celý dokument. Druhý dokument, který pokládám za nepotřebný, je Požadavek na uzavření v systému ISN. Navrhuji nastavení systému tak, aby v případě platby zákazníka, obchodní případ sám uzavřel. Kaţdému, kdo se s tímto systémem procesu seznámil, je jasné, ţe zde dochází k zbytečnému a opětovnému vyplňování stejných informací neustále dokola. Tím dochází k navyšování nákladů jak na tisk, papír, ale především na lidské zdroje, které nám nepřináší ţádný uţitek a jejich práce se stává neefektivní, a dovolím si říct, ţe v některém okamţiku aţ zbytečná. Mnoho dokumentů, např. Dodací list, je moţno generovat z informačního systému a pouţívat informace jiţ jednou zadané.
14.2 Návrh využití maticové organizační struktury Návrh maticové organizační struktury opírám o analýzu v kapitole 10.3. a pro projekty – tendry ji povaţuji za vhodnou a přínosnou. Je nutné ji vytvořit pro kaţdý projekt samostatně. Za kaţdé oddělení navrhuji zvolit zodpovědnou osobu, která se bude zakázce věnovat po celou dobu. Na dílčích svazcích velmi často pracuje několik oddělení současně a maticová organizační struktura by jasně definovala, kdo je za kterou část zodpovědný. Mnoho konfliktů vzniká, jelikoţ se některé oddělení odvolávají na to, ţe určitě svazky neviděli, ţe jim nebyla předána revize, tudíţ neměli moţnost se vyjádřit.
74
Proto navrhuji následující postup: 1. Jiţ na nabídkové poradě stanovit zodpovědné pracovníky, kteří se budou zakázce detailně věnovat, zpracují resp. zrevidují předané podklady pro odevzdání, budou znát veškerou historii a vznášet návrhy. 2. Vyuţijeme formu maticové struktury, kde budou zvolené zodpovědné osoby označeny. 3. Kaţdý zvolený zástupce si kromě svých primárních svazků, můţe zvolit ty, ke kterým chce v průběhu projektu vznášet připomínky. 4. Maticová struktura dále bude obsahovat seznam veškerých svazků pro výběrové řízení a spojitost s dílčím oddělením. 5. Dle této stanovené struktury jednotlivé oddělení vţdy obdrţí zadávací podklady a do stanoveného termínu zašlou svá vyjádření a to i v případě, ţe nebudou mít ke svazku ţádné připomínky. 6. Vţdy toto celé organizační schéma bude zastřešovat specialista prodeje, který má zakázku na starosti. Ten stanovuje termíny odevzdání/revizí svazků, vzhledem k tomu, ţe je v přímém kontaktu se zákazníkem. Vytvoří také návrh maticové struktury spolu s harmonogramem. 7. Jelikoţ tendrová vypsání, například od společnosti ČEZ a.s., jsou ve stejném formátu a obsahují identické svazky, máme moţnost vytvořené maticové organizační schéma pouţít opakovaně.
Pro konkrétní případ mých zakázek navrhuji následující maticovou organizační strukturu, kdy na horizontální ose stanovíme jednotlivá oddělení a k nim příslušnou zodpovědnou osobu. Osa vertikální bude obsahovat jednotlivé svazky ze zadávací dokumentace projektu. Toto schéma nám okamţitě poskytne přehled o provázanosti napříč celým podnikem. Pro tento návrh jsem pouţila zkrácenou verzi jednotlivých svazků, jelikoţ jejich počet je mnohem vyšší. Pro ukázku, ale povaţuji toto schéma za dostačující.
75
Obrázek 25 Maticová organizační struktura
Proč považuji maticovou strukturu za vhodnou? V našem případě stanoví zodpovědné osoby a odstraní pochybnosti o kompetenci ve vztahu k jednotlivým svazkům. Zvýšení celkové pruţnosti procesu. Větší informovanost a znalost historie. Rychlejší přenos informací ke klíčovým osobám projektu. Sníţení rizika a chyb. Zkrácení času zpracování revizí. Zvýšení vzájemné spolupráce. Opakovatelnost.
76
Možné nevýhody: Moţnost vzniku kompetenčních konfliktů. Při prvních projektech očekávám snahu jednotlivých oddělení mít kompetenci za příliš velké mnoţství svazků.
77
15 Oddělení výroba Návrh řešení Krok 1 Jiţ v počáteční fázi navrhuji přiřadit ke kaţdé zakázce příleţitost, která bude propojena s kartou projektu a pouţije jiţ jednou zavedené údaje a tím sníţíme redundanci a případné odchylky a chyby vznikající při opakovaném přepisování dat v systému. Také navrhuji veškeré dokumenty (viz kapitola analýza) zavést pod příslušným evidenčním číslem do systému.
Krok 2 Na základě rozhovoru a připomínek navrhuji zachovat v současném postupu procesu.
Krok 3 Při této operaci dochází k opětnému vybrání zákazníka, proto navrhuji důkladně propojit systém a pouţít jiţ jednou zavedené informace.
Krok 4 Opět navrhuji zachovat současný stav.
Krok 5 Technolog v rámci přípravy technologického postupu často kopíruje uţ dříve vytvořený postup. Problém vzniká v rámci normování výrobních časů jednotlivých operací – pokud ve „zdrojovém“ postupu uvaţoval třeba 1,5 nebo 2 pracovníky, po zkopírování se vţdy tato informace ztratí a systém uvaţuje jednoho pracovníka – technolog to musí znovu opravit na správnou hodnotu. 78
Navrhuji oslovit systémového integrátora a chybu odstranit.
Krok 6 Navrhuji zachovat současný stav.
Krok 7 Stávající systém je funkční, ale znovu nutno připomenou, ţe výroba nemá z ISN ţádnou podporu v oblasti plánování. Lze konstatovat, ţe pouze pořizuje data.
Krok 8 Navrhuji zachovat současný stav
Krok 9 Funkcionalita systému splňuje poţadavky. Bohuţel v této fázi se projeví chyby, které vznikly nedůsledným zadáváním dat v rámci předešlých kroků – zejména ve fázi zakládání zakázky do ISN. Jedná se zejména o chybně nastavená střediska, coţ konečném důsledku způsobí, ţe se na sklad automaticky odvádí i výrobky, které výroba vůbec nevyráběla (přímé dodávky na stavbu, subdodávky). Navrhuji jmenovat zodpovědnou osobu, která by zadávání dat do ISN sledovala jiţ v prvopočátku a případné nedostatky včas odhalila – pokud u takto chybně zadané zakázky vznikne jakýkoliv pohyb, oprava jiţ není moţná.
Krok 10 Funkcionalita je v pořádku, bohuţel ale po archivaci zakázky ztrácí uţivatelé přístup k některým údajům. Vzhledem k budoucímu vyuţití dat je toto dost zásadní nedostatek.
79
Navrhuji, aby byla data v archivu uchovávána ve stejném rozsahu, jako u zakázek v realizaci.
80
16 Návrh na zlepšení celkové situace Moţnost zlepšení současné situace z pohledu vyuţívaní informačního systému je nutno brát jako komplexní problém a i takto ho řešit. Nestačí pouze opravit dílčí kroky funkcí informačního a systému, ale přistoupit k celkové změně k lepšímu.
Navrhuji proto následující postup, rozdělený na jednotlivé fáze:
Obrázek 26 Komplexní postup
16.1 Reorganizace dat Předpokladem tohoto návrhu je vytvořit pevnou strukturu ukládaných dat, tak aby se dokumenty neukládaly duplicitně a byly snadno k nalezení. Zároveň je nutné vytvořit mapu serveru, která by slouţila jako nástroj k rychlému vyhledávání a zajistit její aktualizaci pro přehledný přístup. Pro aktuální informace je potřeba spolupráci všech oddělení, aby byly vymazány jiţ nepotřebné data. Pro ukládání nových dat je důleţité stanovit pravidla. Co všechno je nutné ukládat, zda je opravdu nutné mít takové 81
mnoţství dat ve formátech Excel, Word, Power Point atd. Zda by tyto dokumenty nenahradili výkazy z Navisionu, které jsou kdykoliv přístupné. Dále bych zaloţila sloţku archiv, kam bych přesunula staré nepotřebné dokumenty, proto, aby vyhledávání na disku nebylo tak sloţité a zdlouhavé vzhledem k mnoţství dokumentů, které se zde nachází. Z vlastní zkušenosti vidím tuto cestu v dlouhodobém hledisku jako problematickou a časově náročnou. Přesto zde vidím výhody investice času do této změny. Reorganizace dat bude stát minimální náklady poskytne nám efektivnější práci s uloţenými dokumenty nemůţeme vše ukládat do nekonečna, v jistém časovém okamţiku tento „úklid“ bude potřeba. Čím dřív, tím líp i kdyţ prostřední nikdy nebude interaktivní, opět dojde ke zlepšení. Jelikoţ se na disku I nachází velmi mnoho dokumentů a informací, které jsou nutné pro rutinní chod podnikových procesů, navrhuji jako další bod zavedení Intranetu.
16.2 Zavedení intranetu Proč považuji intranet za vhodný nástroj? Jediný oficiální zdroj všech všeobecných i chráněných informací v podniku Přehledný a jednoduchý přístup k informacím Snadné publikování nových informací všem zaměstnancům Dokumentovaný a hodnotitelný kanál vnitropodnikové komunikace Moţnost personalizace přístupových práv k určitým druhům informací
82
16.2.1 Návrh vytvoření intranetu
Vzhledem k tomu, ţe ve společnosti není nikdo, kdo by měl globální přehled o všech ukládaných datech i potřebách jednotlivých organizačních sloţek, je zřejmé, ţe celý projekt bude nutné jiţ v začátku rozdělit do dílčích fází. Od intranetu si slibuji vytvoření společného a uţivatelský přívětivého prostoru, kde bude moţno snadno sdílet data a informace v rámci celé společnosti
Fáze 1 – vytvoření projektového týmu Cílem je vytvořit zodpovědnou skupinu lidí v čele s projektovým manaţerem, který bude za celý projekt zodpovědný.
Fáze 2 – vytvoření „startovací verze“
Cílem tohoto kroku je zprovoznit startovací verzi, která bude nadále rozvíjena a rozšiřována. Dílčí kroky: úvodní informační analýza. Jako nejrychlejší a nejefektivnější moţnost navrhuji řízené rozhovory. Rozhovor je vhodná metoda, pokud je cílem výzkumu získat názory, postoje nebo přesvědčení lidí. Výhodou řízených rozhovoru je rychlý sběr informací a flexibilita. Přímá Interakce mezi tazatelem a dotazovaným umoţňuje operativní upřesňování nejasností a eliminuje různá nepochopení. Cílem analýzy je zmapovat individuální potřeby jednotlivých uţivatelů a odhalit místa, kde se potřeby překrývají. na základě informační analýzy navrhnout organizační strukturu intranetu navrhnout design – ve spolupráci s marketingovým oddělením navrhnout IT strukturu – ve spolupráci s oddělením IT. Navrhované řešení musí odpovídat technickému vybavení vytvoření a nasazení startovací verzi 83
testování a ladění Fáze 3 – vytvoření „ostré verze“ Cílem je navázat na startovací verzi a rozšířit její funkčnost dle zjištěných ohlasů uţivatelů. Dílčí kroky: podrobná informační analýza rozšíření a doplnění Intranetu na základě podrobné analýzy reorganizace dat uloţených na serveru – přesun příslušných dat na Intranet.
16.2.2 Návrh ukládání dílčích dat společnosti
Jednotlivá data navrhuji uchovávat a sdílet podle následujícího klíče: MAIL SERVER
INTRANET
IS NAVISION
DATA SERVER
e-mailová
obecné
ekonomická a
Pracovní
komunikace
informace
projektová data
adresáře,
sdílené
sdílená data
sledování a
sdílená data
kalendáře
vzorové
vyhodnocování
jednotlivých
rezervace
dokumenty a
divizí a úseků,
zdrojů
šablony
data, která
(referentská
návody a
nelze
vozidla,
manuály
zpracovávat
zasedací
aktuální
prostřednictví
místnosti
informace o
m IS Navision
apod.)
dění ve
a nebudou
společnosti
součástí Intranetu
Tabulka 2 Návrh ukládání dat
84
16.2.3 Návrh struktury intranetu Důležité dokumenty Je důleţité, aby na intranetu byly k dispozici základní dokumenty, pouţívané při kaţdodenní činnosti. Především tyto: šablony, formuláře vzorové dokumenty manuály, návody pracovní postupy zápisy ze školení interní směrnice a předpisy právní dokumenty normy. Informace společnosti V této části intranetu uţivatelé mají mít k dispozici informace typu: historie profil společnosti přehled organizační struktury reference.
Informace managementu Cílem této části je seznámit zaměstnance s klíčovým děním ve společnosti a výhledovým plánem managementu. Jedná se zejména o: strategie, záměry rozhovory usnesení, doporučení výroční zprávy zápisy z jednání.
85
Informace o projektech a ekonomickém vývoji Zde uţivatelé naleznou informace: přijaté zakázky aktuální projekty s termíny realizace dokončené projekty včetně hodnocení výsledků projektu ekonomické ukazatele – náklady jednotlivých středisek, plnění rozpočtu atd. Plán porad V této části navrhuji instalovat modul umoţňující: rezervovat zasedací místnosti přihlašování na plánované školení kalendář plánování porad.
Kontakty Jako základní část intranetu je samozřejmě aktuální seznam kontaktů s těmito údaji: jméno útvar funkce telefonní a jiné kontaktní údaje.
16.3 Analýza podnikových procesů S analýzou funkcionalit informačního systému souvisí také analýza podnikových procesů. Tento krok je nutný: 1.
Pro vyjasnění vlastnictví procesů, přidělení přístupových práv a odpovědnost za
data v informačním systému. 2.
Systém musí vţdy drţet krok s vývojem firmy. Protoţe během tohoto vývoje
dochází ke změnám procesů, je důleţité po určitém časovém intervalu procesy nové zmapovat a systém realitě přizpůsobit. 86
Analýzu podnikových procesů navrhuji v následujícím postupu: 1.
Důkladné zmapování podnikových procesů – v okamţiku kdy se rozhodneme
pro kvalitní zlepšení informačního systému, navrhuji provést důkladné zmapování procesů v podniku a vzájemné souvislosti mezi nimi. Kaţdé oddělení popíše průběh procesů, tak jak odpovídají realitě, nikoliv jak jsou popsány ve směrnicích, jelikoţ v některých případech se od sebe tyto dvě skutečnosti velmi liší. Nesmíme zapomenout také vyzdvihnout podpůrné procesy, které povaţuje za důleţité.
2.
Analýza procesů – jiţ při mapování procesů, zjistíme ve kterých místech se
postupy liší od směrnic. Ve většině případů jsou tyto změny způsobeny vynecháním určitých kroků, které nepřináší ţádný uţitek, proces komplikují a zdrţují nebo jsou vzhledem k časovým termínům nesplnitelné. Zde je moţné navrhnout nové postupy, které eliminují zbytečné kroky. Je ovšem nutná konzultace, především s oddělením, které v procesu následuje. Protoţe to, co se nám zdá někdy zbytečné a nesmyslné, můţe být velmi důleţité a nepostradatelné pro někoho jiného. Samotné rozhodnutí o přijetí změny je samozřejmě na vedení firmy. 3.
Zpětná kontrola – nikdy nesmíme zapomenout na ověření procesu v praxi, jelikoţ
při popsání dochází k opomenutí maličkostí, či k vynechání celého kroku. Tudíţ systém můţe být správně implementován, ale v jistém okamţiku se pro nás stane sloţitý či dokonce nepouţitelný.
4.
Zjištění výjimečných situací – při mapovaní procesů se většinou zaměřuje pouze
na standardní situace. Z praxe ale známe, ţe velmi často dochází k situacím výjimečným, nestandardním, které s sebou mohou přinést řadu problémů. I na tyto situace je nutné pamatovat a počítat s nimi před implementací změn do informačního systému. Systém by měl být schopný většinu těchto výjimek pojmout a zpracovat.
87
16.4 Analýza aktivních funkcí systému Jako první krok, před jakýmkoliv zaváděním, přeorganizováním funkcí či dat v systému je důleţité data aktualizovat. Jak jsem jiţ zmiňovala v bodě je potřeba, aby veškerá data byla aktuální, jinak nám sestavy budou vykazovat nepravdivé informace. V tomto stádiu jednotliví zaměstnanci neznají moţnosti, do jaké míry mohou systém vyuţívat. Vzhledem ke skutečnosti, ţe ve společnosti neprobíhá školení zaměstnanců, naučí se pouze v omezené míře postupem času vyuţívat svou část systému, kterou mají přístupnou. Nevědí ale, z jakého důvodu například mají vyplňovat určitá okna nebo co svou prací v systému provedou ostatním uţivatelům vzhledem k provázanosti některých části systému. Navrhuji, aby určení zaměstnanci provedli popis vyuţívaní systému při své práci a kaţdý navrhl případnou změnu. Jakákoliv, i kdyţ malá změna, je vţdy postup k lepšímu a rozhodně se vyplatí mnohem víc, neţ změna ţádná. Odborně vyškolený školící pracovník, můţe při konzultaci poţadavků se zaměstnanci, také přispět jistou změnou z pohledu znalce systému a tím opět o krůček zlepšit, usnadnit, zautomatizovat a zrychlit práci se systémem. Dále je důleţité určit uţivatelům systému jasná pravidla pro aktualizaci dat. Tak, aby informace, které nám systém nabízí, byly: úplné aktuální pravdivé srozumitelné včasné. Nutností je, naučit se veškeré funkce co nejvíc vyuţívat a oprostit se od stálého kopírování dat do tabulek Excel. Při vytváření těchto excelovských tabulek, dochází k velkému počtu chyb zapříčiněných opakovaným kopírováním stejných dat. Čímţ se nám neustále zvětšuje pravděpodobnost chybovosti a s tím nám narůstá doba práce při jejich vyhledávání. 88
S vyuţíváním všech funkcionalit systému také souvisí nezapomenout na propojenost systému, která by měla být kaţdému uţivateli zcela jasná. Zaměstnanci společnosti potřebují mít představu o tom, co svou prací v systému způsobí, proč daná data vyplňují a kdo s nimi dále pracuje. V otázce propojenosti systému je také nutné, veškeré informace zadávat pouze jednou. Nemohu posoudit jak jiná oddělení společnosti, ale oddělení obchod (zmíněno v bodě ) má v tomto směru nedostatky, které by měly být řešeny mezi prvními. Zajistit, ţe kaţdá informace, se bude do systému zadávat vţdy jedinkrát a nikoliv duplicitně a pro veškeré další vyuţití i v rámci ostatních oddělení jiţ bude systémově propojena. Tím bude zachována její pravdivost a aktuálnost.
16.5 Rozšíření funkcionalit Rozšíření funkcionalit systému je závislé na informacích jednotlivých oddělení získané postupném zlepšování. Viz kapitola výše. Návrhy oddělení Obchod a Výroba jsou uvedeny v kapitole1. Stejným postupem je nutné, aby pokračovala veškerá oddělení. Rozšíření funkcí nemůţeme aplikovat najednou. Nesmíme zapomenout provést analýzu závislosti jednotlivých funkcí napříč celým systémem. Systém Navision nabízí moţnost pojmout a pracovat s téměř všemi daty uloţenými na disku I. Pro veškeré data by bylo nutné investovat do dalších modulů systému, či nechat si vytvořit systém přímo na míru. To by mělo za následek: velkých finančních nákladů precizního vytvoření postupů a seznamu všech funkcí, které by měl systém pokrývat nutnost spolupráce všech oddělení pro detailní znalost podnikových procesů velkou časovou náročnost.
89
16.6 Bezpečnost Na základě doporučení U.S.Data Trust Corporation kapitola 8.3 vyšlo v našem podniku následující hodnocení:
Riziko
Fyzická
Logická
Zálohování a
bezpečnost
bezpečnost
obnovení Odpověď A – 2x Odpověď B – 2x
Opovědi
3x ANO
5x ANO
2x NE
4x NE
Odpověď C – 0x
odborného pracovníka
Odpověď D – 2x Odpověď E – 1x
Hodnocení rizika
STŘEDNÍ
VYSOKÉ
VYSOKÉ
Tabulka 3 Vyhodnocení bezpečnosti
Návrh řešení bezpečnosti informačního systému navrhuji rozčlenit ve stejných kapitolách, jak je zmíněno v teorii kapitola 8 a vyhodnocovací tabulce. Fyzická bezpečnost Fyzická bezpečnost nám dle vyhodnocovací tabulky vyšla jako nejlepší, přestoţe riziko je STŘEDNÍ. Lepšího hodnocení nebylo dosaţeno pouze vlivem, špatného zabezpečení serverů proti poţární ochraně.
Logická bezpečnost Riziko logické bezpečnosti je velmi VYSOKÉ. Tento stav si vyţaduje navrhnout okamţitá opatření, které zajistí bezpečnost systému. Důleţité je začít od prvotních uţivatelů informačního systému, kteří se pod svým uţivatelským heslem opakovaně přihlašují. Oproti přístupovým heslům k serverům, 90
nemají pracovníci povinnost skládat svá přihlašovací hesla z alfabetických a numerických znaků, či je periodicky měnit. V mnoha případech letití zaměstnanci stále pouţívají přidělené heslo, které obdrţeli při nástupu a které je pro většinu pracovníku identické, tudíţ velmi jednoduše zneuţitelné a jelikoţ systém obsahuje citlivé informace, nedoporučuji tento fakt podceňovat. Dle teorie kapitola 8 povaţuji za dostačující měnit hesla uţivatelů v průběhu 3-6měsíců. Ke kaţdému externímu síťovému přístupu nainstalovat firewall, který ochrání vnitřní sít před útoky z venku. Ochrana těchto míst je zcela klíčová, protoţe dle analýz U.S. Data Trust Corporation je toto druhé nejnáchylnější místo k průmyslové špionáţi a úniku dat. Pomocí virů a červů.
Záloha a obnova dat Stávající frekvence zálohování dat je dle mého dostatečná. Denní záloha probíhá v noci tak, aby nezatěţovala systém. Vzhledem k povaze dat, se kterými se ve společnosti České Trubky a.s. pracuje, by byla pravidelnější záloha neefektivní a zbytečně finančně náročná. Tím, ţe je záloha nastavena automaticky, vyhovuje vysokým standardům a pouze kontrola pověřeným pracovníkem je dostatečná. A toto je jedno z doporučení, protoţe občasná kontrola je zcela nevyhovující. Integrita a čitelnost dat je velmi důleţitá, proto navrhuji mnohem pravidelnější kontrolu pověřeným pracovníkem. Zálohy dat jsou dle analýzy uchovávány na stejném serveru. Toto vidím jako jedno z největších bezpečnostních rizik. Tyto rizika jsou jak Logická tak Fyzický. Proto navrhuji data zálohovat na jiném serveru, který bude fyzicky umístěn mimo prostory společnosti. Tento server by měl být takzvaně housován u profesionální housingové společnosti, která splňuje veškeré potřebné ISO standarty. Primárně je důleţité, aby byl server v místností která je chráněna protipoţárním systémem. Servery a datové uloţiště produkují mnoho tepla, proto je nebezpečí poţáru vysoké. Dále musí být servery chráněny proti fyzické krádeţi. Server musí být pod 24 hodinovou kontrolou bezpečnostní agentury. Měl by být uzamčen v samostatném racku (skříňi) a přístup k němu mají jen povolané osoby. 91
Celý server musí být redundantní. Data musí být ukládaná v RAID 1. To znamená, ţe by byla data zrcadlená na dvou nebo více discích. Tímto se zabrání ztátě dat při výpadku jednoho z disků. U serveru musí být také zajištěna nonstop technická podpora ze strany housingové společnosti, která v případě hardwarového výpadku můţe zajistit okamţitou opravu.
16.7 Testování systému Nikdy nesmíme, ať uţ zavádíme zcela nový informační systém, či pouze stávající systém opravujeme a rozšiřujeme, zapomenout na testování. Testováním systému simulujeme ostrý provoz a ověříme schopnost systému pracovat jak v rutinních procesech, tak i ve výjimečných situacích. Většinou odhalíme chyby, případně narazíme na opomenuté funkce. V této fázi máme stále moţnost chyby v systému opravit bez následků a škod. Na základě předpokládaného rozsahu zákaznických úprav je vhodné posoudit vhodnost vyuţití nástrojů pro automatizované testování. Zvláště v případě, ţe si necháváme ke stávajícímu systému vyvíjet vlastní moduly, můţe automatizované testování ušetřit velké mnoţství času, nikdy však nesmíme dopustit, aby výsledky automatizovaných testů byly tím jediným výstupem z testování.
Navrhuji následující postup testování: 1.
krok - vytvoření Scénářů
Jako první krok před testováním systému navrhuji vytvoření Scénářů. Jednotlivé scénáře si musí vytvořit kaţdé oddělení, dle konkrétních pracovních procesů. V této fázi stanovíme zodpovědné osoby za přípravu scénářů a definujeme jaké testy a za jakých podmínek se budou provádět. Za kaţdé oddělení navrhuji jednu osobu, která má co moţná největší znalost informačního systému. Scénáře budou vycházet z reálných situací a musí testovat celé sady funkcí a reálné procesy. Scénáře nesmí být v tzv. „zrychlené variantě“, ale musí proces precizně popisovat a to nejen ve smyslu jednotlivých kroků, ale i co do očekávaných výsledků. Cílem scénáře nesmí být úspora času a hledání nových řešení problémů, ale naopak přesně definovaný postup nejlépe odpovídající stávajícím pracovním postupům. Lze očekávat, ţe pro kaţdé oddělení 92
vznikne více scénářů, které budou kopírovat kaţdodenní chod oddělení a zakázek. V případě, ţe bude vyuţito automatizovaného testování, je nutné zvolené scénáře, které jsou pro tento druh testování vhodné vloţit do testovacího software a ověřit jejich funkčnost.
2.
krok – testování
Systém testujeme vţdy dle vytvořených scénářů jako celek, nikoliv jen dílčí funkce. Tzn. místo testování zda systém tiskne faktury, je nutné testovat kompletně celý proces, od zaloţení zákazníka, přes nabídku, smlouvu, realizaci atd. aţ po vystavení konečné faktury a samotného tisku tak jak byl definován ve scénáři. Zároveň kontrolujeme zda výstupy systému odpovídají očekávaným výsledkům určeným ve scénáři. U výstupů z automatizovaného testování pak provádíme kontrolu výstupních dat. V okamţiku kdy výsledky automatizovaného testování plně odpovídají poţadavkům a není zaznamenána ţádná chyba, provedeme manuální ověření podle totoţných scénářů.
3.
krok – záznam chyb, tvorba Podscénářů
Jednotlivé chyby zaznamenáme a posuzujeme jako chyby dílčí. U odhalených chyb následně vytvoříme podscénáře, které otestují, zda tyto chyby jsou izolované (tzn. jsou na jednom místě a nemají kontext na nic jiného a nebo se jedná o chyby, které se projevují v kontextu se zadanými hodnotami, či ovlivňují další následné kroky. Takto vytvořené podscénáře nám pomohou při zápisu opakovatelnosti chyby, neboli návodu, jak danou chybu kdykoliv zopakovat. Podle toho zda se jedná o izolované chyby nebo kontextové se pak liší i komplexnost takového zápisu opakovatelnosti. Tento zápis musí být dostatečně detailní, aby podle něj mohl dodavatel tuto chybu replikovat ve svém systému a měl by obsahovat popis všech proměnných hodnot, které mají vliv na výsledek. Pouţíváme-li automatizovaného testování, testovací software nám vytvoří kompletní záznam chyb a v některých případech i částečný podscénář, nicméně ve většině případů bude nutné připravit podscénáře a zápisy opakovatelnosti ručně. Tyto podscénáře pak lze zpětně zadat do testovacího software, aby při příštím testu provedl tyto testy automaticky a nebylo tak nutné provádět vţdy ruční dotestování.
93
4.
krok – jednotný report
Na základě všech provedených testů, vznikne jednotný report, který musí obsahovat následující údaje: Jaký test byl prováděn V jakém místě a jaká chyba nastala Kontext chyby a její moţná reprodukovatelnost Pouţité hodnoty Případně očekávaný výsledek (víme, ţe mělo vyjít X a vyšlo Y) Kdo test prováděl.
5.
krok – odstranění chyb, testování
Konsolidovaný výstup testování je předán dodavateli k odstranění závad. Po odstranění závad je nutné provést kompletní testy dle původních scénářů. V případě, ţe došlo k zásadní změně v systému, nesmíme zapomenout zkontrolovat, zda je moţné uplatnit původní scénáře nebo je nutná revize. Pokud můţeme pouţít původní scénáře, musíme provést opět kompletní testování. V případě pouţití automatizovaného testování pak musíme provést aktualizaci scénářů a případných podscénářů i v našem testovacím software. Nesmíme testovat pouze to, zda došlo k odstranění chyb dle reportu. Velmi často se stává, ţe odstranění chyby jedné, můţe přinést chybu jinou. Kontext je vţdy to nejdůleţitější.
16.8 Vytvoření dokumentace Dokumentace je dvojího druhu: 1. Systémová – kterou vytváří tvůrce systému, při jeho tvorbě a slouţí k tomu, aby všichni programátoři jak současní a budoucí věděli co v systému kde je a jak to funguje. Jak a kde se to pouţívá. Obecně slouţí k tomu aby se systém dal vyvíjet. Tu vlastní výrobce softwaru a zákazníkovi ji neposkytuje. 2. Technická dokumentace – ve které výrobce softwaru popisuje technickou stránku celého systému a jeho rozhraní. Tzn. Například dokumentace k API, instalační dokumentace. Tuto dokumentaci u jednodušších systému má k dispozicí zákazník, 94
u sloţitějších systému integrátor, který provádí implementaci. Jedná se o veřejnou dokumentaci. 3. Uživatelská dokumentace – slouţí koncovému uţivateli k tomu, aby se dozvěděl, jak se systémem pracovat, kde se co nachází atd. Jelikoţ se jedná o standardní systém, musí existovat jiţ hotová dokumentace od výrobce pro standardní ovládání systému.
4. Příručka – popisuje přesný stav toho, jak byl systém implementován přímo u nás v podniku. Většinou tuto příručku tvoří integrátor.
Příručka by měla obsahovat: Popis jednotlivých modů a vazeb mezi nimi Jednotlivé procesy Detailní popis dílčího modulu a detailního návodu k pouţití Nejčastější a nejdůleţitější operace v systému popsány v tzv. „rychlé příručce“ Kvalitní indexy – podle termínů, funkcí atd..
Důleţitým faktorem je kvalita, forma a rozsah dokumentace. Ta by měla usnadňovat ovládání programu, popisovat vyuţití všech jeho funkcí, měla by dávat odpovědi na nejčastější otázky (FAQ), řešit problémy s pouţíváním programu atd. Neméně důleţitá je orientace v této nápovědě, které napomáhá existence obsahu nebo rejstříku. Nejpraktičtější je dokumentace v elektronické podobě, samozřejmě můţe vycházet i v tištěné podobě a to, jako jedna příručka nebo rozdělena do několika samostatných částí.
16.9 Školeni Školení by mělo probíhat v následujících fázích: 1.
obecné vlastnosti a jeho uţivatelské rozhraní – jedná se o funkce, které vychází ze
základní příručky Navisionu.
95
2.
konkrétní funkce a postupy týkající se implementace v konkrétním oddělení –
školení zabývající se specifickými funkcemi v modulech, které vyuţívá dané oddělení a postupy jak je nejlépe vyuţít
3.
pokročilé funkce – vyuţití pokročilých funkcí.
Ke kaţdému školení by měla existovat jiţ vytištěná dokumentace v textové podobě, do které si zaměstnanci v případě potřeby mohou dělat poznámky a kterou následně kdykoliv mohou vyuţít jako „rychlou příručku.“
Tyto dva body Školení a Dokumentace spolu neodlučitelně souvisí. V tomto okamţiku zaměstnanci bohuţel neví, co všechno tento systém dokáţe a jakými nástroji by si mohli svou práci značně zjednodušit a zefektivnit. Proto, aby zjistili jaké moţnosti jimi pouţívaný integrovaný informační systém Navision nabízí, je nutné školení od odborného člověka, který systém ve společnosti zaváděl a zná veškeré funkce. Toto školení by mělo probíhat ihned po nástupu nového zaměstnance, aby se mohl co nejrychleji do práce se systémem začlenit. Bohuţel z vlastní zkušenosti vím, ţe se toto nestává. Ale ani po několika školení, si zaměstnanec není schopen zapamatovat všechny moţnosti, funkce a spojitosti, které systém nabízí. A právě z tohoto důvodů se opět odvolávám na bod 5. a nutnost existence dokumentace!
96
17 Harmonogram projektu Reorganizace dat na disku I
1 Vytvoření pevne struktury dat Vytvoření mapy serveru Založení archivu
Zavedení intranetu
2 Fáze I - projektový tým Fáze II - startovací verze Fáze III - ostrá verze
Analýza podnikových procesů
3 Zmapovaní procesů Analýza procesů Zpětná kontrola Zjištění výjimečných situací
Analýza aktivních funkcí systému
4 Popis využívaní systému Návrh změn Provázanost
Rozšíření funkcionalit systému
5 Rozšíření dle jednotlivých propojení Provázanost
Bezpečnost
6 Stanovení cílů a způsobu řešení Analýza rizik Celková bezpečností politika Systémová bezpečností politika Realizace bezpečnostních směrnic a norem Monitoring a audit
Testování
7 Vytvoření scénářů Testování Záznam chyb a tvorba podscénářů Jednotný report Odstranění chyb
Vytvoření dokumentace
8
Obrázek 27 Harmonogram projektu
97
17.1 Projektový tým Členové projektového týmu: Externí poradce v otázce bezpečnosti Pracovníci IT Systémový integrátor Zástupci oddělení Obchod Zástupci oddělení Výroba Zástupci oddělení Řízení projektů Zástupci oddělení Finance a Controlling Manager projektu Konzultant
Detailní harmonogram včetně časového určení vytvoření pomocí Microsoft Project je součástí této práce jako Příloha č.2.
98
18 Přínosy práce Celkový přínos navrţeného řešení je především v efektivním vyuţívání současného informačního systému s minimálními náklady na inovaci, případně rozšíření. Jelikoţ je návrh brán jako komplexní řešení, pokryjeme zároveň nejen informační systém, ale také provedeme důkladnou analýzu jednotlivých podnikových procesů. Jelikoţ k tomuto procesu v podniku jiţ dlouho nedošlo, očekávám sníţení nákladů na administrativu, vlivem zjednodušení procesu oběhu dokumentů, zprůhlednění jednotlivých procesů a odstranění neefektivních postupů. Při důsledném dodrţení navrţeného postupu analýzy a rozšíření funkcionalit informačního systému, nám v ten okamţik začne poskytovat ucelené, pravdivé a aktuální informace, které budou vytvářet rychlé výstupy nejen pro vedení firmy. S tím je spojena zvýšená flexibilita a konkurenceschopnost a zároveň sníţení objemu dat, vzhledem k odstranění duplicity dat. Tato důvěryhodnost a rychlá dostupnost jakýchkoliv informací napříč celou společností můţe být jeden z rozhodujících faktorů zdravého fungování firmy. To, ţe jedno oddělení můţe snadno přejímat data z jiného oddělení a navzájem mít tato data provázaná a aktuální, velice zjednodušuje práci celé firmy. A fakt, ţe důleţité dokumenty budou v jejich aktuální podobě vţdy dostupné všem uţivatelům, kteří s nimi potřebují pracovat je pro efektivní chod firmy velmi důleţitý. Velice důleţitý přínos navrhovaného řešení je i celková integrita dat z pohledu uţivatele. Vzhledem k tomu, ţe všechna oddělení budou pracovat s daty stejně, jejich spolupráce bude mnohem jednodušší a rychlejší. A kaţdý uţivatel bude mnohem snadněji zastupitelný, protoţe bude pouţívat stejnou metodiku na práci s daty. A protoţe v návrhu řešení je i zpracování dokumentace a jasných metod práce s IS / IT, bude školení i nových pracovníků mnohem jednodušší a zaručuje to, ţe i nový pracovník bude schopen se systémem pracovat, ale hlavně svou vlastní prací nenaruší integritu zbytku systému. S tímto souvisí i zodpovědnost zaměstnanců za data v systému. Kdykoliv je jasně patrné kdo jaká data do systému vkládal a kdo ručí za jejich kvalitu a správnost. Toto je velice důleţité, pokud chceme zachovat komplexní funkčnost systému. Pokud budou jiţ vstupní data chybná, nemůţe fungovat systém jako celek.
99
Díky jiţ zmíněné moţnosti sledování kdo s jakými daty pracuje, systém je téţ bezpečnější z pozice ochrany dat před únikem a zneuţitím. V dnešním velice konkurenčním prostředí je únik dat pro společnost velmi nebezpečný a proto je důleţité podniknout všechny dostupné kroky k jeho prevenci. Navrhované řešení chrání data nejen před jejich únikem mimo společnost, ale i před jejich ztrátou. Díky novému navrhovanému řešení správy dat a uloţišť všeobecně, budou data mnohem více a lépe ochráněna před poškozením. Takovéto poškození můţe být jak formou lidské chyby (náhodné smazání souboru uţivatelem), tak formou zásahu vyšší moci (výboj v elektrickém vedení a následný poţár v místnosti s uloţenými daty). Důleţitým přínosem je také skutečnost, ţe dle analýzy hodnocení bezpečnosti jsme došli ke zjištění, ţe se jedná o velmi rizikový stav, který je důleţitý bezodkladně řešit! V této analýze jsem objevila několik bezpečnostních rizik, které jsou pro IS / IT velmi nebezpečné. Zajištěním bezpečnosti dat firmy i zajišťujeme její bezproblémový chod do budoucna. Hlavním přínosem této práce je dozajisté komplexní pohled na IS / IT systém a procesy fungování firmy, jejich vzájemná harmonizace a zefektivnění.
100
19. Závěr V závěru práce se zaměřím na zhodnocení práce z pohledu analýzy, návrhu řešení a přínosů. Cílem práce bylo provést co nejhlubší analýzu podnikových procesů, vyuţití informačního systému a provést návrh moţného řešení k celkovému zlepšení. Jako první jsem se zaměřila na oddělení obchod, kde byly během analýzy zjištěny problémy uţ v samotném začátku vyuţívání systému a to v katalogu kontaktů. Mnou navrţené řešení – podrobněji viz kapitola 14, povaţuji za základní krok a velký přínos, jelikoţ aktuální a pravdivý seznam obchodních partnerů je základem kaţdé společnosti. Souhrnně: Určení zodpovědné osoby za správu informačního systému v oblasti tvorby katalogu zákazníků. Nutnost vyplňování všech stanovených údajů. Periodická aktualizace. Nutnost odstranit opakované vkládání identických údajů. Přínos v oblasti CRM a napříč celou společností. Sníţení chybovosti o 30%. Na konkrétním případu u překupu materiálu nám analýza ukázala závislost na dokumentech ve formátech Word, Excel, tisknutí, skenování nekonečného počtu dokumentů a ukládání na disk I. Tento proces s veškerými činnostmi probíhá jak u zakázky za několik milionů korun, tak u obchodního případu za pár stokorun, kde předpokládám, ţe náklady vynaloţené na tyto činnosti, nepokryjí zisk a především nepřinesou ţádný uţitek. Podrobněji kapitola 10.2. V analýze – kapitola 10.3 a následně návrh - kapitola14.2 jsem se zaměřila na vyuţití maticové organizační struktury, které by vnesla jasná kompetenční pravidla za zpracované svazky pro výběrová řízení. Souhrnně: Zjednodušení jednotlivých vývojových fází zakázky. Nutnost redukovat tvorbu dokumentů ve formátu Microsoft Office o 80%. 101
Tyto dokumenty vytvářet v informačním systému Navision. Sníţení času trvání procesu aţ o 2 dny. Zvýšení flexibility. Návrh vyuţití maticové organizační struktury.
Provedená analýza ve Výrobě upozornila také na některé nedostatky, přesto by bylo vhodné v této části provést analýzu podrobněji s vyuţitím informací od většího počtu pracovníků, jelikoţ rozhovor proběhl pouze se zaměstnancem úseku řízení zakázek. Jako kritický bod povaţuji zjištěné problémy v bezpečnosti systému. Podrobněji kapitola 16.6 a příloha č.1. Souhrnně: Zjištěné vysoké riziko v oblasti bezpečnosti informačního systému Detailní návrhy ke zvýšení bezpečnosti podrobněji kapitola 16.6. Návrh vyuţití externího poradce s kvalitními znalostmi, který provede podrobnější analýzu. Vysoké náklady cca (1500-3000Kč/hod – systémový integrátor, expertní poradce pro bezpečnost) povaţuji za přínosnější s porovnáním s případnou ztrátou a rizikem, které hrozí. Jedná se především o finanční riziko ztrátu dobrého jména či ztrátu trhu. Dalším problematickým bodem ve společnosti je také nedůsledná práce s daty v informačním systému Navision a nedostatečné vyuţívaní jeho funkcí. Ověřila jsem v analýze, ţe je také způsobeno tím, ţe uţivatelé systému neznají vazby funkcí napříč jednotlivými divizemi a z toho důvodu je ani neuţívají. Souhrnně: Příprava našich návrhů a očekávání od jednotlivých funkcí systému Nutnost vyuţití externí sluţby implementující informační systém. V případě změny navrhuji postupovat dle mého návrhu řešení pro komplexní změnu vyuţívání se zaměřením se na jednotlivé procesy. Nevidím moţný výsledek zlepšení při
102
zaměření se pouze na jednu část problému, vzhledem ke skutečnosti, ţe se jednotlivé problémy prolínají. Návrh komplexního postupu: 1. Reorganizace dat – podrobněji kapitola 16.1 2. Zavedení intranetu – podrobněji kapitola 16.2 3. Analýza podnikových procesů – podrobněji kapitola 16.3 4. Analýza systémových funkcí – podrobněji kapitola 16.4 5. Rozšíření funkcionalit systému – podrobněji kapitola 16.5 6. Bezpečnost systému – podrobněji kapitola 16.6 7. Testování systému – podrobněji kapitola 16.7 8. Vytvoření dokumentace – podrobněji kapitola 16.8 9. Školení – podrobněji kapitola 16.9. Jelikoţ nemám přístup do systému v oddělení projektové řízení a finance a controlling, chybí v této práci jejich úplná analýza a návrhy řešení. Komplexně zjištěné problémy by byly velkým přínosem pro tuto práci a přinesly by nové návrhy jak pro dílčí, tak pro výsledné řešení. Celá práce by vedena s cílem analyzovat a navrhnout postup řešení pro vedení společnosti. Jelikoţ se jedná o velký zásah do současného stavu a s tím i spojené náklady, nebyly toto návrhy zatím aplikovány. Vedení společnosti je ve svých návrzích a rozhodnutí limitováno a omezeno vlastníky společnosti, kteří pro vyuţití externích sluţeb mají jiţ nasmlouvané obchodní partnery. Proto se také nemohou v tomto směru sami rozhodovat. Při aplikování komplexního návrhu očekávám tyto přínosy: Sníţení nákladů na administrativu, vlivem zjednodušení podnikových procesů. Zprůhlednění jednotlivých procesů a odstranění neefektivních procesů. Aktualizace údajů v informačním systému. Odstranění redundance údajů. Sníţení chybovosti, mající dopad na objem reklamací a cca 15%. Zvýšení flexibility společnosti. Zvýšení konkurence schopnosti. Zkvalitnění analýz výkazů podniku pro jeho vedení. 103
Provázanost informací napříč podnikem. Zvýšení výkonnosti pracovníků a jejich produktivity. Vznik podpůrných dokumentů. Sníţení nákladů o 10000,-Kč/měsíc na školení, jelikoţ vzniknou dokumenty, které jiţ mohou být opětovně pouţívány např. pro školení nových pracovníků a zároveň poslouţí jako příručky pro zaměstnance současné. Zvýšení bezpečnosti informačního systému a podnikových informací.
Na základě provedené analýzy a návrhů opatření pro zlepšení procesů v podniku České Trubky a.s. je zpracován komplexní harmonogram, viz. příloha 2, ze kterého vyplývají celkové přínosy řešení diplomové práce. Významným dosavadním nedostatkem v řízení podniku se jeví nevyuţívaní moţností, které poskytuje informační a řídicí systém NAVISION, coţ má dopady do všech procesů podniku. V řešení jsem se zaměřila na ty, které v současné době se jeví, jako nejvýznamnější viz uvedený harmonogram. Při řešení svého zadání jsem naráţela na problémy v důsledku mé zatím krátké doby v zaměstnání v tomto podniku a na nedostatek kontaktů se zodpovědnými pracovníky podniku pro zjišťování informací pro kompletní řešení. S dílčími výsledky mé práce jsem seznámila pracovníky vedení podniku a navrţená řešení budou v dalších etapách vyuţita pro racionalizaci podnikového řízení.
104
Seznam použité literatury
1.
Jiří Voříšek, Strategické řízení informačního systému a systémové integrace, Management Press, Ringier ČR, a.s., 1999
2.
Jak Starbacka, PhD., Jarmo R. Lehlinen, PhD., Řízení vztahů se zákazníky, Grada Publishing spol. s.r.o, 2002
3.
Prof. Ing. Leo Vodáček, Dr. Sc., Ing. Olga Vodáčková, CSc., Moderní management v teorii a praxi, Management Press, Ringier ČR, a.s., 2009
4.
Mike Robson, Philip Ullah, Praktická příručka podnikového Reengineeringu, Gower Pubhlising Limited
5.
Ing. Alena Svozilová, MBA, Projektový management, Grada Publishing, 2006
6.
Prof. Ing. Lenka Praţská, CSc. a kolektiv, Obchodní podnikání, Management Press, Ringier ČR, a.s., 2002
7.
Doc. Ing. Jaromír Veber CSc. a kolektiv, Management Management Press, Ringier ČR, a.s., 2003
8.
Mik Wisniewski, Metody manaţerského rozhodování, Grada Publishing spol. s.r.o., 1996
9.
Doc. Ing. Miloslav Keřkovský, CSc. MBA, Ing. Miloš Drdla, Dr., MBA, Strategické řízení firemních informací, 2003
10. Ing. Karel Vlásek, Ph.D, Systémy Jakosti dle normy ČSN EN ISO 9001:2001,
pro vnitřní potřebu ISQ Praha, s.r.o.
Podnikové dokumenty
1.
Organizační a kompetenční řád z roku 2009
2.
Příručka jakosti z roku 2020
3.
Příručka environmentálního managementu z roku 2010
105
Seznam použitých obrázků
Obrázek 1 Vztah změn podnikových procesů a změn IS/IT ............................................... 13 Obrázek 2 Typické rozloţení fází ţivotního cyklu projektu ............................................... 21 Obrázek 3 Typický průběh čerpání nákladů v průběhu ţivotního cyklu projektu .............. 22 Obrázek 4 Vztahy mezi základními pojmy bezpečnosti ..................................................... 24 Obrázek 5 Průběh řešení bezpečnostní politiky v podniku ................................................. 26 Obrázek 6 Organizační struktura podniku ........................................................................... 36 Obrázek 7 Microsoft Dynamics ........................................................................................... 40 Obrázek 8 Klíčoví uţivatelé systému .................................................................................. 41 Obrázek 9 Karta Nabídky .................................................................................................... 45 Obrázek 10 Redundance údajů ............................................................................................ 47 Obrázek 11 Vývojový diagram ........................................................................................... 48 Obrázek 12 Dodací list ........................................................................................................ 51 Obrázek 13 Příkaz k vystavení faktury................................................................................ 52 Obrázek 14 Poţadavek na uzavření ..................................................................................... 53 Obrázek 15 Karta projektu .................................................................................................. 61 Obrázek 16 - Prodejní objednávka ...................................................................................... 62 Obrázek 17 - Vydaná výrobní zakázka................................................................................ 62 Obrázek 18 - Vydaná výrobní zakázka - historie změn....................................................... 64 Obrázek 19 – Vydaná výrobní zakázka - seznam dokončených operací ............................ 65 Obrázek 20 - Vydaná výrobní zakázka - potvrzení konečné výrobní kontroly ................... 65 Obrázek 21 Workload.......................................................................................................... 69 Obrázek 22 Katalog kontaktů .............................................................................................. 70 Obrázek 23 Fáze Nabídky ................................................................................................... 71 Obrázek 24 Propojení karet Příleţitost - Nabídka ............................................................... 72 Obrázek 25 Maticová organizační struktura........................................................................ 76 106
Obrázek 26 Komplexní postup ............................................................................................ 81 Obrázek 27 Harmonogram projektu .................................................................................... 97
Seznam Příloh
Příloha 1 Dotazník ............................................................................................................. 109 Příloha 2 Harmonogram .................................................................................................... 110 Příloha 3 Certifikát ISO 9001:2008 ................................................................................... 111 Příloha 4 Certifikát ČSN EN ISO 14001:2005.................................................................. 112
107
Dotazník – Bezpečnost
Vyplněno odborným pracovníkem: Fyzická bezpečnost
Jsou servery umístěny v klimatizovaném prostoru s protipoţární ochranou? (ano/ne) – ne s protipoţární ochranou
Provádí se průběţně kontrola těchto prostorů? (ano/ne) - ano
Mají servery zálohové napájení? (ano/ne) - ano
Jsou servery fyzicky přístupné pouze autorizovaným osobám? (ano/ne) - ano Logická bezpečnost
Je systémová administrativa prováděna vyškoleným personálem? (ano/ne) ano
Je na kaţdém externím síťovém přístupu instalován firewall? (ano/ne) - ne
Jsou uţivatelská přístupová oprávnění určována v souladu s poţadavky podniku? (ano/ne) - ano
Jsou uţivatelská oprávnění periodicky hodnocena z hlediska změn v personálním zařazení a zodpovědnosti? (ano/ne) - ne
Mají všechna přístupová hesla k serverům s kritickými daty 8 znaků a znaky alfabetické i numerické? (ano/ne) - ano
Musí uţivatelé periodicky měnit svá hesla se zákazem znovupouţití po dobu minimálně jednoho roku? (ano/ne) - ne
Je na všech počítačích a serverech naistalovaný a updatovaný antivirový SW? (ano/ne) - ano
Je zákaz instalace SW, který není pověřenými pracovníky ověřen? (ano/ne) ano
Je zakázáno pouţívat na pracovištích bezdrátové LAN? (ano/ne) - ne Záloha a obnova dat
Jak často se provádí backup? (a)průběţně b)denně c)týdně d)měsíčně e)ročně f)nikdy) - denně
Jakým postupem se provádí? (a)automaticky b)manuálně odborníkem c)manuálně neodborníkem) - automaticky 108
Jak dlouho jsou data uchovávána? (a)rok a více b)nejméně měsíc c)týden d)den e)nejsou uchovávána) – nejméně měsíc
Jak často jsou zálohy ověřovány na čitelnost? (a)denně b)týdně c)měsíčně d)občas/nikdy ) – občas
Kde jsou zálohy uchovávány? (a)mimo provoz IS b)na stejném serveru c) v prostorách s protipoţární ochranou d)na jiném serveru e)jinde) – na stejném serveru
Za jakou dobu po vytvoření záloh jsou média přemístěna mimo provoz IS? (a)bezprostředně b)do 8 hodin c)do 24 hodin d)do 7 dní e)do 1 měsíce f)nikdy) – do 1 měsíce
Jak dlouho trvá nalezení a obnovení ztraceného souboru? (a)několik minut b)několik hodin c)den a více d)týden a více e)měsíc a více) – několik minut Příloha 1 Dotazník
109
Harmonogram projektu
Příloha 2 Harmonogram
110
Systém managementu kvality
Příloha 3 Certifikát ISO 9001:2008
111
Systém environmentálního managementu
Příloha 4 Certifikát ČSN EN ISO 14001:2005
112
