|
 
|
MADDIX Business Elements: strategický systém pro podporu marketinkových procesů středních a velkých obchodních společností. Vyvinut pro Cisco Systems Inc. San Jose, USA jako world-wide globální systém pro podporu marketinkových procesů společnosti. Pod názvem Tsunami implementován a spuštěn v roce 2003, po neštěstí v Indickém oceány v prosinci 2004 byl systém přejmenován na GMAPP (Global Marketing Planning & Processing). |

|
| Přináší zavádění webových systémů novou kvalitu? |
Často je nám kladena otázka, co vlastně naše systémy přinášejí nového. Když pak probereme a vysvětlíme všechny konkrétní pozitivní změny ve firmě zákazníka, které získá zavedením některého našeho systému, obvykle nakonec dojdeme ke dvěma obecným kvalitativním změnám.
První je možnost se kdykoliv a odkudkoliv podívat na primární "malá" čísla, ze kterých se pak skládají čísla větší až největší. Jestliže obecně platí, že požadovaný úspěch ve "velkých" číslech je daný souhrnem drobných malých úspěchů u čísel malých, pak tato možnost přináší managementu zcela novou kvalitu. Jestliže systémy dokáží na jedno dvě kliknutí ukázat v reálném čase, jak se k velkým číslům došlo, pak je mnohem snažší úzká místa rychle identifikovat a pak se na ně zaměřit.
Druhá kvalitativní novinka je možnost "měřit procesy". Měřením nerozumíme jenom klasické kvantitativní údaje na výstupech procesů (např. denní produkci jednoho stroje nebo kolik balení něčeho se dnes prodalo), ale i "Jak dlouho trvalo, než se něco posunulo z bodu A do bodu B". Tato měření umožňuji velmi efektivně zlepšovat zejména rychlost toků interních informací v obchodních činnostech u velkých společností, kde v terénu pracují početné týmy obchodních zástupců, na ně navazují firemní struktury zpracování obchodních případů a následné podpory zákazníků.

Princip "puzzle", kdy se na první pohled nejprve zdá, že to nikdy nikdo přece nemůže dát dohromaty, ale postupně se skládá políčko k políčku a najednou máte celý obraz, který navíc pěkně drží pohrmadě!
Stejně je tomu u informačních systémů, které se dnes již nebududí na "zelených loukách" (kde jsou ty časy ...), ale již v nesourodém prostředí, kde všechny informace sice již někde jsou, ale je potřeba je najít, očistit a připojit na jiné.
Proto byl princip "puzzle" zvolen jako leit-motiv ilustrací našeho presentačního webu. Když si o tom popřemýšlíte, tak asociace jsou (téměř) dokonalé a daly by se o tom napsat rozsáhlé duchaplné eseje. |
|

|
|
| Zdeněk Strnad: Fenomén tří webových zákonů |
Tak jako jsou definovány obecně použitelné Murphyho zákony nebo zákony Parkinsonovy pro státní správu nebo velké společnosti, lze na začátku 21.století ekvivalentně definovat i zákony, platící pro webovou platfotmu. Jsou jednoduché, snadno zapamatovatelné a hlavně mají velkou vnitřní sílu:
1. webový zákon: "Kdo není na webu, jako by nebyl!"
2. webový zákon: "Co není na webu,. jako by nebylo!"
3. webový zákon: "Co by na webu mohlo být, musí tam být!"
|
| NETSYSTEM Int .a.s. jako Application Software Provider (ASP) |
Application Software Provider je podle definice mezinárodní asociace ASP Industry Consorcium dodavatelským modelem, ve kterém zákazník řeší své potřeby formou pronájmu vzdálené služby. Modelu ASP jsou dávány ve světě velké naděje. Odhady obratu se pohybují okolo 2 miliard v r. 2000 a 15 miliard USD v roce 2005.
Zájem o ASP je poměrně vysoký v USA, kde alespoň nějakou ASP aplikaci využívá (a platí za ni) cca 80 % podniků, ve Velké Británii cca 40 %, v zemích EU cca 20 % a u nás cca 5 % (dle průzkumu Deltax z jara 2001). Pouze 15 % našich firem však neuvažuje s využitím ASP v nejbližší době.
Existují odvážné předpovědi, že v budoucnu bude jediným klientem informačního sytému www prohlížeč. IS bude tvořen pronajímanými aplikacemi a rozhraní mezi nimi bude zajišťováno ASP operátory. "Inhouse" budou provozovány pouze speciální systémy.
Service Level Agreement
Cílem Service Level Agreement (dále jen SLA) je co nejpřesněji definovat rozsah, úroveň a intenzitu externě poskytovaných služeb.
SLA se skládá ze tří částí:
a) Základní specifikace, podmínky a pravidla:
- Kategorie příjemců.
- Přesné vymezení počtu a umístění příjemců dané kategorie.
- Popis služeb.
- Objem poskytovaných služeb
- Poskytovatel - bližší určení (uvádí se, má-li smysl, resp. je-li uživatelů více).
- Měření - postup, způsob, periodicita, odpovědnost a vykazování výsledků.
- Ověřování - postup, způsob, periodicita, odpovědnost a vykazování výsledků ověřování správnosti měření.
- Určení a způsobu realizace podpory (kupř. fyzicky na místě, vzdáleně apod.)
- Návazné podpůrné služby spojené s danou službou (kupř. tréning na místě, resp. na učebně)
- Cena služby.
- Platební podmínky.
- Pravidlo pro změny služby.
- Práva a povinnosti obou stran - podmínky součinnosti.
- Ostatní podmínky pro realizaci SLA (bezpečnost, právo informovanosti, odpovědnost za vady a škody apod.).
b) Tvrdé metriky:
Dostupnost (v % vyjádřený skutečný čas disponibility aplikace na daném zařízení uživatele ve vztahu k celkovému efektivnímu fondu pracovní doby za určenou časovou jednotku).
Běžná a maximální přípustná (kritická) doba odezvy na požadavek - tzv. incident (v členění na jednotlivé typy požadavků, jako je kupř. hlášení poruchy aplikace, poruchy HW, přemístění koncové stanice, apod.).
Běžná a maximální přípustná (kritická) doba řešení požadavků (v členění na jednotlivé typy požadavků). Průměrná a mezní odezva aplikace v rámci služby.
c) Měkké metriky:
Ostatní metriky pro danou službu (kvalitativní ukazatele typu "akceptace", "zápis", "potvrzení realizovaného školení a prezenční listina", "hodnocení lektora školení", "hodnocení účastníka školení", apod.).
V souvislosti s tvrdými metrikami jako součást SLA (jako jsou kupř. odezva, dostupnost apod.) jsou v některých případech stanovovány až tři úrovně tohoto parametru:
- Servisní úroveň - požadovaná hodnota parametru za standardních podmínek (kupř. dostupnost na úrovni 0,97 a vyšší)
- Minimální servisní úroveň - pod tuto mez nesmí hodnota daného parametru nikdy klesnout (kupř. dostupnost 0,94)
- Motivační (incentive) servisní úroveň - má motivovat poskytovatele k poskytování nadstandardní úrovně služeb (kupř. dostupnost nad 0,99).
Nedosažení "servisní úrovně" vede dle podmínek definovaných v SLA ke snížení plateb za služby. Nedosažení ani minimální servisní úrovně je událostí, která způsobí uplatnění předem definovaných sankcí. Dosažení motivační úrovně naopak zakládá nárok poskytovatele na bonus.
|
| Úvahy o vhodnosti či nevhodnosti outsourcingu |
Benefity zákazníka
- zdokonalení v hlavní oblasti (poskytovatel má know-how a infrastrukturu na daleko vyšší úrovni),
- soustředění se na hlavní předmět podnikání,
- zbavení se problému "jak na to",
- podstatné snížení rizika úniku interních informací,
- sdílení rizik, jejich přenesení na poskytovatele,
- informatika je v podniku na nízké úrovni a tento proces se nedaří zvládnout,
- odstranění problémů s legalizací SW.
- zjednodušení manažerské práce,
- zvýšení pružnosti,
- podnik nedisponuje dostatečnými lidskými zdroji pro řízení a realizaci IS/IT,
- odstranění problémů se zajišťováním těch správných lidí (pro IT odborníky je mnohdy práce v non IT firmě nezajímavá),
- dlouhodobé zajištění profesionálního tréningu koncových uživatelů.
- snížení operativních nákladů,
- odstranění skrytých nákladů,
- zprůhlednění nákladů na informatiku,
- uvolnění investičních zdrojů pro jiné účely,
- snížení operativních nákladů,
- předvídatelné náklady a kontrolovatelné výdaje na danou oblast - poskytování outsourcing je financováno formou platby paušálu v dané periodicitě (měsíčně, čtvrtletně, ročně),
- odstranění nákladů na sledování špičky v oblasti IT.
Praktické limity outsourcingu
- přetrvávající tržní nedůvěra v dodavatelsko-odběratelských vztazích,
- obavy se závislosti na poskytovateli,
- hrozba krachu poskytovatele,
- hrozba ukončení smlouvy,
- nestabilita podnikatelského prostředí,
- ale i interní neznalost reálných nákladů na informatiku.
|