Az ebusiness gyakorlata

Az eBusiness gyakorlata

Schwarczenberger Istvánné dr.


A XXI. század vállalatirányításában egyre jelentısebb szerepet játszik az informatika. A versenyben maradás, a versenyelınyök megszerzése, egyre inkább azon múlik, mennyire gyorsan, korszerően, magas színvonalon tudunk megfelelni a piaci elsárásoknak úgy, hogy közben profitot is realizáljunk. A gyorsaság, rugalmasság, hatékonyság, profitabilitás nem éhetı el korszerő ICT (Information Communication Technology) rendszer alkalmazása nélkül. Ma már sok vállalkozásban az üzleti stratégia része a megfelelı ICT rendszer, a kettıt együtt, egymással kölcsönhatásban vizsgálják és fejlesztik. Ez az írás egyfajta receptet kíván adni arra, hogy globalizált, hálózatos világunkban hogyan lehet a megfelelı üzleti modellt felépíteni, az ICT rendszert és az üzleti stratégiát összehangolni.

© Schwarczenberger Istvánné dr. 2007.

1./64


TARTALOMJEGYZÉK

1

BEVEZETİ

4

2

A „HAGYOMÁNYOS” ÉS AZ „ONLINE” ÜZLET ÖSSZEHASONLÍTÁSA

7

3

KÉNYSZERÍTİ TÉNYEZİK

11

4

AZ ONLINE ÜZLETVITEL BUKTATÓI

13

5 ÚJ ÜZLETI MODELL, VAGY A HAGYOMÁNYOS FOKOZATOS ÁTALAKÍTÁSA?

15

6

18

6.1

AZ ONLINE ÜZLET FELÉPÍTÉSE Üzleti stratégia elemzése, stratégiai célok kitőzése

20

6.2 Új üzleti modell kidolgozása 6.2.1 Termékek, szolgáltatások körének meghatározása 6.2.2 Szereplık meghatározása 6.2.3 Szereplık kapcsolatának meghatározása 6.2.4 Üzleti folyamatok megtervezése 6.2.5 Beruházás gazdaságossági elemzés 6.2.6 Döntés az új üzleti modell bevezetésérıl

23 23 23 24 26 27 28

6.3 Stratégia elkészítése az online üzlet felépítésére 6.3.1 Marketing-terv kidolgozása 6.3.2 ICT rendszer fejlesztési/beruházási projektterv kidolgozása 6.3.3 BPR projektterv kidolgozása 6.3.4 Beruházási terv kidolgozása 6.3.5 Pénzügyi terv kidolgozása 6.3.6 Kockázatelemzés 6.3.7 A projekt stratégiai tervének jóváhagyása

28 28 29 42 46 48 48 49

6.4 A projektek végrehajtása 6.4.1 Elıkészítési fázis 6.4.2 Kivitelezési fázis

49 49 49

6.5

52

A rendszer átadás-átvétele

7

EBUSINESS CONTROLLING

54

7.1

A controlling rendszer felépítése

54

7.2

Mutatószám rendszer a logisztikában

55

7.3

A tervezési folyamat átalakítása

57


2./64


7.4

Az input adatok megadása

60

8

TUDÁSMENEDZSMENT

62

8.1

Tudásmenedzsment rendszer kialakítása


63

3./64


1 BEVEZETİ Az Európai Unió stratégiai fejlesztési tervében célként a tudásalapú társadalom megteremtését fogalmazta meg, amely öt pillérre épül: • • • • •

eGovernment eLearning eBusiness eHealth eContent

Az öt „e” terület egymással kölcsönhatásban mőködik, amelyet az alábbi ábrán szemléltetünk:

eBusiness eGovernment B2C B2B

B2C B2B eHealth

B2C

B2C eContent

B2C

eLearning

TUDÁSALAPÚ TÁRSADALOM

A halmazok közös metszetében a tudásalapú társadalom van, amelyet hosszútávon szeretnénk elérni. Az eGovernment területén a lakosság, cégek, intézmények kerülnek kapcsolatba az államigazgatási, önkormányzati szolgáltatókkal, az eContent területén a tartalomszolgáltatók kerülnek kapcsolatba az emberekkel, az eHealth területén a lakosság az egészségügyi szolgáltatókkal, az eLearning területén az oktatók a hallgatókkal, míg az eBusiness területén a gyártók, szolgáltatók kerülnek kapcsolatba a vásárlókkal, ügyfelekkel, akik lehetnek magánszemélyek, vagy cégek, intézmények. Ebben a megközelítésben kétféle kapcsolat típust különböztethetünk meg a különbözı minıségben fellépı szolgáltató (B) és az eltérı szerepekben megjelenı magánszemély (C) között: B2B (business to business) ill. B2C (business to citizen). Ennek az öt „e” területnek a fejlesztése napjaink nagy kihívását jelenti. Mindegyik területen lehet önmagában végrehajtani fejlesztéseket, de célszerő figyelnünk arra is,


4./64


hogy ezek egymással kölcsönhatásban vannak. Így az egyik területen történı fejlesztések hatással vannak más területekre is. Például az eGovernment kialakítása nagyban megkönnyíti mind a cégek, mind a magánszemélyek adatszolgáltatásait, hivatalos ügyintézéseit (kevesebb munka- és költségráfordítás). Az eGovernment megvalósításával jelentısen csökkenteni lehet az apparátusok létszámát, a fenntartási költségeket, amelyek az állampolgárok és vállalkozások számára a gyorsabb és egyszerőbb ügyintézésen túl hosszútávon a fizetendı adók mértékére is várhatóan kihatnak. Az eLearning lehetıvé teszi a „humán erıforrás” gazdaságos képzését, továbbfejlesztését a vállalatoknál és intézményeknél, kedvezıen befolyásolhatja pl. a társadalmilag hátrányos helyzető emberek felkészülését, pozitívan hat az esélyegyenlıség megteremtésére. A tudásalapú vállalkozásoknál lerövidítheti az új belépık felkészülési idejét, a munkatársak továbbképzését, biztosítja az egyéni tudás szervezeti tudássá konvertálását. Az eContent – tartalomszolgáltatás - akár önálló üzleti tevékenységgé is válhat, amely a társadalom legkülönbözıbb rétegei, érdeklıdési csoportjai részére adhat át tudást, széleskörő információkat, melyekbıl könnyen és gyorsan tájékozódhatunk. Ez kihat a kulturális életünkre, a turizmusra, szabadidıs tevékenységünkre, de még a tudományos kutatásokra, fejlesztésekre is, vagy megkönnyíti cégeken belüli ismeretátadást, tudásmegosztást. Az eHealth többek között az egészségügyi intézmények gazdaságos mőködését teszi lehetıvé hasonlóan, mint az üzleti szférában, ahol a kontrolling szemléletü irányítás ma már a legtöbb helyen napi gyakorlat, továbbá tudásmegosztást és gyors információ szolgáltatást tesz lehetıvé, ami a betegek szempontjából esetenként akár életmentı is lehet. Az egészségügyi adatbázisok segíthetik az egészségügyi fejlesztéseket, beruházásokat, átszervezéseket, hiszen ma még egyes betegségcsoportokról azt sem tudjuk, pontosan hányan érintettek (pl. diabetes). Kiegyenlítik az orvosok tudásában meglévı egyenlıtlenségeket, azáltal, hogy kollektív tudásbázist bocsátanak a rendelkezésükre, mellyel a betegek számára is esélyegyenlıséget tudnak biztosítani függetlenül attól, hogy az ország mely táján veszik igénybe a szolgáltatást. Nem véletlen a fenti területeken az „e” használata, ami az informatikára és a modern kommunikációra utal. Vagyis a fejlıdés ma már elképzelhetetlen korszerő információés kommunikációs technológia alkalmazása nélkül. Értelmezésünk szerint az „e” a cselekvéshez egy eszközt, egy módszert jelent, ami a „hogyan” kérdésére ad választ. Egyik területen sem változnak az alapvetı célok, a stratégiák, az üzleti modell alapjai, hanem a technológia, a mőködési mód változik, ahogyan a célokat el akarjuk érni. Nincs másról szó, minthogy az információt megosztjuk, rendelkezésre bocsátjuk – azaz szolgáltatjuk - és a folyamatokat jelentıs mértékben automatizáljuk. Így van ez az üzleti életben is, az eBusiness csak abban különbözik a „hagyományos Business”-tıl, hogy az üzleti folyamatok jelentıs része automatikusan megy végbe, az információk pedig online módon minden jogosult számára a keletkezésük pillanatában (real time) rendelkezésre állnak. Persze ez a technológia visszahat az üzleti stratégiánkra, új lehetıségeket, új piacokat, új vevıket hozhat a számunkra, ha megfelelıen élni tudunk vele. Mindenesetre elmondhatjuk, hogy ma már a stratégiai üzletfejlesztésnek az informatikai rendszer fejlesztése szerves részét kell, hogy képezze. A kettıt együtt, egymással kölcsönhatásban kell vizsgálnunk és az új üzleti modellt az informatikai stratégiával párhuzamosan kialakítanunk. Az üzleti stratégiánk megváltoztatását számos kényszerítı tényezı válthatja ki, de tudatos elhatározásból is eredhet a változtatási szándék. Mindenki csak saját maga


5./64


döntheti el, hogy vállalkozásának piaci poziciója, mőködési környzete, versenyképessége, stb. szempontjából mennyire fontos áttérnie új mőködési módra, az elektronikus folyamatok alkalmazására. Az eBusiness azonban nem mentesít minket attól, hogy jól ismerjük a vevıkörünket, a termékeinket, szolgáltatásainkat, emberi- és egyéb erıforrásainkat, a termék-elıállítási folyamatainkat, a versenytársainkat, a piac viselkedését, változásait – ugyanúgy mint a „hagyományos Business”-ben. A továbbiakban az eBusiness szinonímájaként használjuk az elektronikus-, vagy online üzletvitel, -folyamatok, -kommunikáció kifejezéseket. A mai gazdasági környezetben azonban a változások jelentısen felgyorsultak, sokkal gyorsabban kell reagálni ezekre, mint az internet nélküli világban. Így az idıtényezı a versenyképesség egyik meghatározó szempontjává vált! Természetesen – mint minden változásnak – ennek is megvannak a maga buktatói, amelyeket gondos tervezéssel fel tudunk mérni, ill. fel tudunk készülni a veszélyhelyzetek elkerülésére, vagy bekövetkezésük esetén a károk csökkentésére. Az eBusiness sokkal nagyobb mértékben épül a bizalomra, mint a hagyományos üzlet. A kockázatok jelentıs része a bizalom Erre próbálunk ebben az írásban egyfajta receptet adni, melyhez a gyakorlatban szerzett tapasztalataink nyújtanak támpontot. Igyekeztünk a praktikum oldaláról bemutatni a folyamatokat, a problémákat, a teendıket, a módszereket, eszközöket, minél kevesebb elméleti eszmefuttatással. Az ismertetett metodika nem jelent semmilyen kizárólagos megoldási módot arra, hogyan tudunk egy eBusiness üzleti modellt felépíteni és mőködtetni, hanem csak egyfajta összegzését és rendszerezését jelenti a prakszisunknak.

A szerzı


6./64


2 A „HAGYOMÁNYOS” ÉS AZ „ONLINE” ÜZLET ÖSSZEHASONLÍTÁSA Ma már a „hagyományos” üzletvitelben is megkövetelik a cégvezetık, tulajdonosok a pontos és gyors információszolgáltatást, a folyamatok átláthatóságát. Ezért a nagyvállalatokon túl, a kis- és középvállalatok (KKV-k) is egyre nagyobb számban alkalmaznak integrált vállalatirányítási (ún. ERP – Enterprise Resource Planning) rendszert, amellyel a vezetık információs igényei kielégíthetık. Az ERP rendszer bevezetésével a mőködési rendszer szervezettebbé válik, az üzleti folyamatok átláthatóak lesznek, a munkavégzés jobban kényszerpályára terelhetı. Általában elmondható, hogy az ERP rendszer bevezetése az elsı lépcsıfok annak irányában, hogy egy cég a versenyképességét hosszútávon is megtarthassa. Az ERP rendszerek többsége azonban elsısorban a belsı üzleti folyamatokat, azon belül a gazdálkodási folyamatokat fedi le, a mőködési rendszert teszik átláthatóvá és ezáltal könnyebben irányíthatóvá. Az eBusiness-ben az ERP rendszer általában ún. back-office funkciókat lát el, amelyeket ki kell egészíteni ún. front-office funkciókkal. A front-office funkciók segítségével építjük ki a kommunikációs csatornákat a külsı környezettel. A két részrendszert biztonsági okokból nem célszerő összevonni, hanem egy ún. kommunikációs rendszerrel teremtjük meg köztük a kapcsolatot, valósítjuk meg az integrációt. (Számos olyan szoftver létezik, amely a kommunikációt biztonságosan megoldja, pl. IBM MQSeries és WebSpheare, Magic Enterprise Server és iBOLT, MS SharePoint, MS Infopath.) Alexander Osterwalder (Universitè de Lausanne) nyomán az eBusiness üzleti modell lényegét az alábbi ábra szemlélteti:

INFRASTRUKTÚRA MENEDZSMENT TERMÉK / SZOLGÁLTATÁS FEJLESZTÉS Képességek

VEVİKAPCSOLATOK (CRM)

Információs Stratégia

Erıforrások

Értékteremtés

Üzleti Érték

Partner Hálózat

Költség struktúra

Elégedettség & Szolgáltatás

Célközönség

Bizalom & Hőség

Nyereség/ Veszteség

Árbevételi Modell

PÉNZÜGYI NÉZİPONT

Az üzleti modell célja az üzletérték növelése, amely több aspektusból közelíthetı meg: •

A vevıkapcsolatokban realizálódik a szolgáltatások, termékek megvétele, melynek színvonalát jelzi a vevık elégedettsége, bizalma, hősége a cég iránt, illetve realizálódik az árbevétel, ami a profit forrása. Az eBussiness modellt jelzi az informatikai stratégia, amit a vevıkapcsolatok javítása érdekében valósítunk meg.


7./64


•

Az üzleti érték elıállítása termékek szolgáltatások formájában az értékteremtı folyamatokon keresztül valósul meg. Ezek megtervezése, mőködtetése a célvevı érdekében történik a képességek és erıforrások felhasználásával.

•

Az infrastruktúra menedzsment képezi az alapját a cég mőködésének, amelybe nemcsak az eszközök, technológiák, mőködési feltételek, IT rendszer tartoznak, hanem a dolgozói csapat és a partnerhálózat is.

•

A pénzügyi nézıponton keresztül mérhetı le az üzleti modell profitabilitása, amely a költségstruktúra és az árbevételi struktúra különbözetébıl adódik.

Minden vállalkozás sikeres fejlıdésének alapja a jó üzleti modell, melynek fıbb összetevıi a gyakorlat nyelvén: • • • • • • • • • • • • •

A jól megválasztott és kézbentartott vevıkör, ügyfélkör; A kiválasztott piaci szegmenshez illeszkedı termékválaszték és szolgáltatás kínálat; A vevık számára nyújtott szolgáltatások és termékek minısége, ára és megbízhatósága a megígért színvonalon; Az elıállítási költségek megfelelı szinten tartása; Rugalmas alkalmazkodó képesség és gyors reagálás a piaci változásokra; Megbízható beszállító és alvállalkozó partnerek; A likviditási egyensúly folyamatos fenntartása; Megfelelı mérető és struktúrájú szervezeti-mőködési rendszer kialakítása; Az üzleti folymatokhoz illeszkedı informatikai rendszer, Jól mőködı érdekeltségi rendszer; Hatékony csapatmunka és az ebben résztvevı munkatársak; A munkatársak tudásának folyamatos szintentartása, ill. fejlesztése; Az eszközök, eljárások, technológiák folyamatos fejlesztése, stb.

A fenti összetevık nem különböznek attól, hogy eBusiness-t, vagy „hagyományos Business”-t folytatunk, de igen nagy eltérés van a módszerekben, eljárásokban, ahogyan az üzletmenetet kialakítjuk. Nézzünk néhány példát: A vevıinkrıl általában rendelkezésünkre állnak információk az ajánlatok, megrendelések alapján az ERP rendszerbıl is. Ezeket az információkat utólag elemezhetjük, vevıcsoportokat, kategóriákat alakíthatunk ki, melynek alapján differenciált értékesítési és marketing tevékenységet folytathatunk. Ez a megoldás ún. követı magatartást tesz lehetıvé a számunkra, nem látjuk elıre, hogy milyen történések várhatóak a piacon. Amennyiben kiterjesztjük az ERP rendszerünket a vevıfolyamatok támogatására is, további információkat szerezhetünk érdeklıdésekrıl, vevıi szokásokról, magatartásokról, véleményekrıl, igényekrıl, vagy akár a konkurrencia akcióiról, árairól is. Ennek birtokában már kezdeményezıkként léphetünk fel az adott piaci szegmensben, ill. rugalmasan tudunk alkalmazkodni a piaci változásokhoz. A tömegközlekedésben, ha olyan jegyeket alkalmaznának, amelyek használata elektronikusan feldolgozható lenne (ld. London, Párizs, New York és egyéb nagyvárosok metróit), az utasok a jegyek leolvasásával egyben információt is szolgáltatnának automatikusan az utazási szokásaikról, melynek alapján a járatszervezést optimalizálni lehet, a kapacitásokat jobban ki lehetne használni és mellesleg a bliccelıket is jobban ki lehetne szőrni. Mivel a jegykezelı automatáink jelenleg nem alkalmasak információ leolvasására és tárolására, az alkalmazási


8./64


rendszerek ezek fogadására, a közlekedési vállalatok kénytelenek drága pénzen elvégzett utasszámláláshoz folyamodni, aminek az eredménye statikus információ: a felmérés idıtartama alatt milyen volt az utasforgalom? Nem látható folyamatában, hogy az egyes járatokon milyen az utasforgalom, a szállítóeszköz kihasználás, így nem is nagyon tudnak beavatkozni a járatszervezésbe, de a beruházási, fejlesztési döntéseik is többnyire feltételezéseken alapulnak. A vevıi megelégedettség rendszeres mérése közvetett és közvetlen módon képet adhat arról, hogy termékeink, szolgáltatásaink minıségi színvonala és az alkalmazott árak megfelelıek-e? Ha online módon be tudjuk győjteni ezeket az információkat, akkor meg tudjuk elızni a panaszokat, fel tudjuk készíteni munkatársainkat a hibák kiküszöbölésére, sıt mérhetıvé tesszük a CRM (Customer Relationship Management) területén dolgozók teljesítményét és költségeit is, ill. jól megtervezett akciókat indíthatunk a kiválasztott célcsoportok számára. A nagyobb sípályákon például ma már elterjedt gyakorlat, hogy fényképes bérleteket, jegyeket adnak ki, melyek használatával automatikusan győlik az információ a sípályák kihasználtságáról, a síelık szokásairól, nemérıl, koráról, származási helyükrıl, stb. anélkül, hogy ezeket az adatokat bárki külön rögzítené. Az információk birtokában számos elemzés végezhetı, melynek alapján még több síelıt lehet vonzani az adott helyre, de jó támpontot nyújt a fejlesztési, beruházási döntések meghozatalához is. A beszállítókkal, partnerekkel kialakított online kommunikáció lehetıvé teszi számunkra a partnerek teljesítményének folyamatos mérését, értékelését, sıt gyakran jótékony hatással van a készletszintekre és a készlet forgási sebességekre, ha a szállítók a szükségletek szerint ütemezik a szállításaikat. Szervíz szolgáltatás esetén jobban megtarthatjuk a vevıinket, ha mi kezdeményezünk szolgáltatásokat, mielıtt a hiba bekövetkezne. Vevıként pozitívan értékeljük például, ha a kereskedı, akitıl az autónkat vásároltuk, telefonál a karbantartás esedékessége miatt, idıpontot egyeztet és mellesleg felhívja figyelmünket az újdonságokra. A rendszeres, megelızı karbantartás esedékességének elırejelzésével és a vevıkapcsolatok ápolásával hosszútávon stabil vevıkört alakíthatunk ki. Az érdekeltségi rendszer akkor tekinthetı jónak, ha mindenki a saját teljesítményével összhangban álló javadalmazásban részesül, ha a feladatok, hatáskörök a teljesítménytıl függı bevételi- és költségelemekhez kapcsolódnak, amire valóban befolyással rendelkeznek a dolgozók. Ezért a teljesítmények és fedezetek alakulásáról, a terv-tény költségekrıl jó, ha mindenki a saját szintjén naprakész információval rendelkezik, mert ez ösztönözheti nagyobb teljesítményre. Az eBusiness megoldásokban a folyamatok jelentıs mértékben automatikusan mennek végbe, az információ azon a ponton kerül be az adatbázisba, ahol az keletkezik és mindenki online hozzájut azokhoz az információkhoz, amelyekkel a feladatait magas szinten el tudja végezni, míg a hagyományos üzletvitel esetén jelentısen több adatbeviteli munkával, fáziskéséssel, vagy pedig egyáltalán nem jutnak hozzá a szükséges információkhoz.


9./64


Például az ITC rendszer hatása a logisztikára az alábbi ábrával szemléltethetı: Az ICT képessé tesz

Mobil adatkommu nikáció Integrált vállalati információs rendszer

információ

Gyors azonosítási technika

Real-time tranzakciókezelés

Gyors reagálás a vevıi igényekre

Logisztikai folyamatok támogatása

A logisztikai folyamatokban kiemelten fontos az áru útjának teljeskörő nyomonkövethetısége, minden mozzanat dokumentálása és visszakövethetısége, ami az áruval kapcsolatban történik. A logisztikai folyamatok pontossága, minısége, a felhasznált teljesítmények meghatározzák az ilyen szolgáltatással foglalkozó cégek verseny pozícióját, ezért nem mindegy, hogy milyen technikával történik az áru azonosítása (ld. vonalkód, RFID), milyen gyorsan és mennyi munkával lehet az elvégzett feladatokat (tranzakciókat) az adatbázisba bevinni (ld. mobil eszközök), az árumozgások útvonalát követni (pl. GPRS). Ma már erre specializált informatikai megoldások állnak rendelkezésre.


10./64


3 KÉNYSZERÍTİ TÉNYEZİK Számos tényezı indokolhatja, hogy vállalkozásunk továbblépjen az eBusiness irányába. Ezek közül a legfontosabbakat emeljük ki: •

Elsıdleges fontosságú az idıtényezı! Amilyen gyorsan értesülünk az üzletünk szempontjából fontos eseményekrıl, olyan gyorsan tudunk reagálni ezekre. Pl. ha az áruházban a konkurrencia a hasonló termékeire jelentıs árengedményt ad, mi is idıben tudjunk hasonlót nyújtani, ha van róla információnk. Vagy ha valamelyik médiában megjelenik egy általunk is forgalmazott termék reklámja, kapcsolódjunk hozzá saját akciókkal, vagy készüljünk fel készlettel a nagyobb keresletre, mert így növelhetjük a forgalmunkat különösebb marketing befektetés nélkül. Vagy ha nyomkövetı rendszerrel szereljük fel szállítóeszközeinket, azonnal értesülhetünk, ha valami baj van és elhárító intézkedéseket tehetünk;

•

Vevıink elvárják tılünk az online szolgáltatást, iparági standardként kezelik, enélkül már szóba sem állnak velünk - ld. banki szolgáltatások, túrizmus, biztosítási szolgáltatások, stb.;

•

Rövidebb szállítási, teljesítési határidık vállalásával, alacsonyabb árakkal (és önköltséggel) tudjuk csak a vevıinket megtartani, ami magasabb szintő szervezettséget igényel a vevı kiszolgálási folyamatokban és ez a folyamatok automatizálását igényli (ld. repülés a „fapados” járatokkal);

•

Versenytársaink már áttértek az online üzletvitelre, emiatt csökkent a piaci részesedésünk;

•

Tevékenységünk jellegébıl következıen területileg megosztott, nem tudjuk átlátni a folyamatokat (pl. építési, beruházási projektek, helyszíni tanácsadások, szakértıi munkák, stb.);

•

Vevıink területileg szétszórtan, a világ különbözı pontjain helyezkednek el;

•

Szállítóink, alvállalkozóink szintén területileg szétszórtan helyezkednek el;

•

A cég szervezeti egységei eltérı helyen mőködnek, miközben tevékenységük egymásra épül;

•

Területi-, ill. termékképviselıi rendszert mőködtetünk, lokálisan telepített egységekkel, képviselıkkel, akiknek mind egymással, mind pedig a központi irányítással folyamatosan kommunikálniuk kell;

•

Nagyszámú ügyféllel, ill. vevıvel kell napi kapcsolatot tartanunk (pl. szerviz szolgáltatás, kis- és nagykereskedelem, stb.);

•

Kihelyezett (outsourcing) szolgáltatást nyújtunk logisztika, informatika, könyvelés, gyártás stb. terén);

•

Tevékenységünk csoportmunka jellegő, tudásmegosztást igényel (pl. tanácsadási projektek, kutatási-fejlesztési projektek, szoftverfejlesztés, stb.);

•

Online tartalomszolgáltatást végzünk, ami csak elektronikus kommunikációval lehetséges;


(pl.

szállítmányozás,

11./64


•

Üzleti folyamatainkat optimalizálni akarjuk a fajlagos költségek csökkentése céljából;

•

Számos hálózatos mőködési formában veszünk részt (pl. szövetségek, klaszterek, társulások, szövetkezetek, stb.);

•

A hálózatos, hierarchikus és mátrix struktúrák egyszerre vannak jelen a mőködési rendszerünkben, és már nem tudjuk követni a folyamatokat, teljesítményeket;

•

Dinamikusan növekszik az üzleti tranzakciók száma, melyet hagyományos eszközökkel és emberi erıforrással nem tudunk lekezelni.

A fenti kényszerítı tényezıkön túl felismerhetünk olyan piaci jelenségeket, ahol a szereplık közötti kooperáció, együttmőködés hiánya gazdaságtalan, nem hatékony mőködési módot tesz csak lehetıvé az érdekeltek számára. Ha megtaláljuk azt a közös érdekeltségi rendszert, amely minden érintett számára elınyös, akkor érdemes egy új üzleti modellt felépíteni és az együttmőködést ICT eszközökkel hatékonnyá tenni.


12./64


4 AZ ONLINE ÜZLETVITEL BUKTATÓI Az online üzletvitelnek számos akadálya lehet, amelyek miatt az elvárt haszon nem jelentkezik a beruházás után. Nem térnék ki a jogi környezet hiányosságaira, ill. követelményeire, mely egy másik írás témája lehet. Ezeket adottságként kezeljük és tudomásul vesszük, hogy alkalmazkodnunk kell hozzájuk (ld. elektronikus aláírás, adatvédelmi törvény, stb.). Inkább az üzleti oldalról közelítsük meg ezt a kérdést: •

Mi történik, ha nem teljesítjük ígéreteinket, nem tartjuk be az ígért határidıket, rosszabb minıségő terméket szállítunk, vagy nem teljesítünk? Miután vevıinkkel elsıdlegesen online kapcsolatban állunk és ez személytelen jellegő, azonnali bizalomvesztést okozhat, ami könnyen vezethet nemcsak egy, hanem akár több vevı elvesztéséhez. Ezért az online üzletvitelben a pontos teljesítés, szállítás, a vevık naprakész tájékoztatása - alapvetı követelmény, míg a hagyományos üzletvitelben nincs ilyen mértékő hatása egy-egy pontatlan teljesítésnek.

•

Mi történik, ha alul- vagy felültervezzük a szolgáltatási szinteket, amit a vevıink számára biztosítani akarunk? Alultervezés esetén a vevıink elégedetlenek lesznek, míg a felültervezés esetén indokolatlanul magas költségekbe kényszerítjük magunkat.

•

Kulcsvevıink, kiemelt ügyfeleink általában fokozott figyelmet, személyes törıdést igényelnek, amelyet ha nem biztosítunk, elveszítjük ıket. Számukra lehetıvé kell tenni a személyes kontaktusokat, folyamatosan informálni kell ıket a rájuk vonatkozó folyamatok állásáról, esetleg online hozzáférést biztosítva a rendszerünkhöz. Személyre szabott kommunikációt kell velük folytatnunk, ami különbözı dátum figyeléseket, eseménykövetéseket tesz szükségessé.

•

A határidık pontos betartása, a megfelelı minıségő termékek, szolgáltatások elıállítása magas szervezettségi színvonalat igényel a belsı folyamatokban. Nem lehetnek csúszások az anyagbeszerzésben, a termelésben, a projektekben, a szolgáltatási folyamatokban. Ez elsısorban az emberi tényezın múlik, van-e olyan csapat, amely képes összehangoltan magas színvonalon végezni a tevékenységét, ill. mindenki idıben értesül-e a rá váró feladatokról és rendelkezik-e megfelelı információval, ami az elvégzésükhöz szükséges?

•

A mőködési folyamatok nagyfokú automatizálása miatt a rutinszerő feladatok végzése helyett áttevıdik a hangsúly az ellenırzésekre és elemzésekre. Emiatt nem biztos, hogy a munkaerı összetétele azonos maradhat a korábbival. Más szemlélettel kell dolgozni egy eBusiness rendszerben, mint a hagyományosban. Az ügyvitelben közremőködı munkatársaknak folyamatokban kell gondolkodniuk, rendszerösszefüggésekre odafigyelniük, tendenciákat, várható eredményeket kimutatniuk és elemezniük. A tevékenységek sokkal szigorúbban függnek egymástól, ha valaki nem végzi el a feladatát, akadályozza a kapcsolódó mőveleteket. Ha nem változik a szemlélet, nem fog jól mőködni a rendszer.

•

A területi megosztottság miatt átláthatatlanok a folyamataink, a leadott teljesítmények, az információ késve jut el a vezetıkhöz, melynek


13./64


következményeképpen az idıbeni beavatkozás lehetısége kizárt. Információs monopóliumok alakulnak ki a cégen belül, nem valósítható meg az egyéni tudás szervezeti tudássá történı transzformálása. Ha nem történik meg a folyamatok és információs rendszer megfelelı átszervezése, magasabb mőködési költségekkel kell továbbra is számolnunk amellett, hogy információhiány lép fel mindekinél. •

Az eBusiness alapja a megbízhatóan és biztonságosan mőködı informatikai és kommunikációs (ICT – information communication technology) rendszer. Sokkal magasabb minıségi követelményeket kell támasztanunk egy folyamatos üzemben mőködı rendszerrel szemben, amelyen a teljes üzleti tevékenységünk alapul, mint egy „hagyományos” informatikai rendszerrel szemben. Ha az ICT rendszer nem mőködik, egyszerően leáll az üzlet, nem lehet rendelést feladni, nem indulnak el a kiszállítások, leállhat a termelés, szolgáltatás. Ezért igen nagy hangsúlyt kell helyezni az ICT rendszer biztonságos és megbízható üzemeltetésének feltételeire.

•

A folyamatok automatizálása elıtt nagyon fontos azok megtervezése, alapos átgondolása. Fıleg a kivételes helyzeteket kell felmérnünk és definiálnunk, mert ha ezt nem tesszük, rosszul fog mőködni az alkalmazási rendszer, elvesznek tranzakciók, a rendeltetéstıl eltérıen kezdik el használni, ami adat inkonzisztenciákhoz vezet és végeredményben bizalmatlanok lesznek a vevıink.

•

Az online üzletvitel miatt a vevıkapcsolatok ápolása kiemelt feladattá válik (CRM-Customer Relationship Management), amelyre megfelelı ügyfélszolgálati rendszerrel fel kell készülni. Ha ezt nem tesszük, a panaszokra, problémákra, igényekre, javaslatokra nem reagálunk, elégedetlenek lesznek a vevıink és elveszítjük ıket.


14./64


5 ÚJ ÜZLETI MODELL, VAGY A HAGYOMÁNYOS FOKOZATOS ÁTALAKÍTÁSA? A valódi eBusiness elterjedése a „Dot-com (.com)” válságot követıen – bármilyen ezzel kapcsolatos felmérést, elemzést veszünk figyelembe – megállíthatatlan a világ bármely részében (ld. az eBusiness ciklus Hype diagram ábrát). A folyamat sebességében, mértékében vannak vélemény különbségek, de általánosan elfogadott, hogy „aki kimarad, az lemarad”. Ezért elıbb-utóbb minden cégvezetınek, tulajdonosnak el kell gondolkodnia azon, hogyan tudja vállalkozását átalakítani a XXI. század követelményei szerint.

eBusiness Ciklus Market Hype Itt vagyunk most „e-business forever” forever” DotDot-com share fallout

DotDot-com

Investor disillusionment

starts

Optimized ee-business Business disillusionment

Internet WWW „True” True” e-business emerges Peak of Technology Trigger

Inflated Expectations

Trough of Disillusionment

Slope of Enlightenment

1990 - 96 1997 1998 1999 2000 2001 2002 2003 2004 2004 2005 2006

Year

Forrás: Gartner Research

A Microsoft által kidolgozott IT infrastruktúra-optimalizációs modell szerint elsı lépésben fel kell mérni, milyen fejlettségi, érettségi szinten áll a szervezet. A modell szerint négy szintet definiáltak, melyek a következık: 1. Alapszint Jellemzıi: a folyamatok jelentıs része manuális, lokális alkalmazások, központi rendszerfelügyelet gyenge, biztonságpolitika, biztonsági szabályzat hiánya. Az IT infrastruktúrát nehéz felügyelni, minden módosítás jelentıs költséggel jár, az üzemeltetés felügyelet drága, az üzleti célokkal nincs összhangban. 2. Szabványos szint Jellemzıi: egységesítés, léteznek szabályok a felhasználói munkahelyek és kiszolgálók (szerverek) üzemeltetésére, új felhasználók beléptetésére, központilag felügyelt hozzáférés menedzsment, licenc-menedzsment, váratlan eseményekre utólagos reagálás, belsı biztonsági rendszer hiánya. Az alapszinthez viszonyítva az IT infrastruktúra kevesebb költséggel üzemeltethetı, kockázatok csökkennek, értékteremtı üzleti folyamatok támogatása.


15./64


3. Racionalizált szint Jellemzıi: egységes, homogén, jól átlátható és kézbentartható infrastruktúra, minimális felügyeleti költség, kiforrott eljárások és szabályzatok, váratlan eseményekre szabályozott reagálás, az üzleti tevékenység nagyfokú támogatása, proaktív (megelızı) eljárások, optimalizált eszközök és szoftverek. 4. Dinamikus szint Jellemzıi: a folyamatok teljesen automatizáltak, az információs folyamatok teljes összhangban mőködnek az üzleti folyamatokkal, az üzleti szükségletekhez, változásokhoz folyamatosan igazodnak. A költségek teljesen szabályozottak, mindenre kiterjedt integráció: felhasználókra, adatokra, hardverekre, szoftverekre, kommunikációra, hálózatra. Karanténszerő javításkezelı rendszer, biztonsági szabályzat, automatizált eljárások. Az eBusiness megvalósítása a negyedik, dinamikus szint elérését igényli! Az online üzletvitelre való áttérés döntésének meghozatala elıtt – elemezve a kényszerítı tényezıket és az iparági sajátosságokat – két lehetıséget vizsgáljunk meg: • •

Saját magunk alakítjuk át (vagy ki) cégünk mőködését, vagy Csatlakozunk-e valamilyen, már mőködı eBusiness rendszerhez érdekeltségi alapon?

közös

A KKV-k (kis- és középvállalkozások) általában az utóbbi megoldásban gondolkodhatnak egyrészt a tıkehiány, másrészt a cégméret miatt. Kisebb cégeknek érdemes érdekszövetségeket, klasztereket, társulásokat, stb. létrehozniuk annak érdekében, hogy amit egyenként saját erıbıl nem képesek elérni, együttesen már képessé váljanak nagyobb üzleti sikerek elérésére. Ez már felveti a hálózatosodás kérdését, amit csak megfelelı informatikai háttérrel lehet hatékonyan mőködtetni. Az átalakításnak két módja lehetséges: • Új üzleti modell alapján a vállalkozás újraépítése, vagy új vállalkozás létrehozása, ami ugrásszerő fejlıdést jelent; • Fokozatos, folyamatonkénti átalakítás, ami egy hosszabb átmenetet, fejlıdési ütemet jelent. Mindkét módszernek vannak elınyei és hátrányai, melyek közül néhányat az alábbi táblázatban foglaltunk össze (az összehasonlítások a másik módszerhez képest értendık): Jellemzı Beruházás átfutási ideje Beruházási költségek

Járulékos költségek Optimális mőködési rendszer Szervezet befogadóképessége

Szemléletváltás Fejlesztési projekt kockázata Megtérülés Folyamatok automatizálása


Új üzleti modellre való áttérés

Fokozatos fejlesztés

Rövid Koncentráltan merülnek fel, összességében kisebbek

Hosszú Idıben elhúzódva, kisebb tételekben merülnek fel, összességében nagyobbak Nem jellemzı Mindig felmerülnek Rövidtávon elérhetı Kockázatos, hogy mikor érhetı el Hirtelen nagy változás, Folyamatos, hoszabb ideig nagyon fontos a körültekintı tartó változásra kell elıkészítés felkészülni Azonnal szükséges Lépcsızetesen alakítható ki Nagyobb Kisebb Rövidebb idı Hosszabb idı Teljeskörő Részleges

16./64


Nincs általános recept arra, hogy egy vállalkozásnál mikor és hogyan lépjünk az eBusiness irányába! Minden esetben egyedileg kell mérlegelni, hogy a piaci körülmények, a kényszerítı tényezık, a lehetıségek és adottságok függvényében milyen stratégiát válasszunk. Néhány gyakorlati kérdés, melyet a stratégia tervezésénél célszerő megfontolni: • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Milyen kényszerítı tényezık igénylik, hogy áttérjünk az eBusiness-re? Vevıink, ügyfeleink hogyan fogadnák a változást? Milyen következményekkel jár, ha nem változtatunk (piacvesztés, árbevétel kiesés)? Milyen termékekre, szolgáltatásokra terjedjen ki az új mőködési modell? Képesek vagyunk-e a folyamatok automatizálásával magasabb szolgáltatási szintet biztosítani vevıink számára? Milyen kockázatokat vállalhatunk? Miképp kezeljük a kockázatokat? Milyen várható eredményekkel jár az áttérés? Mekkora beruházási költséget jelent a projekt? Mennyi idı alatt térülne meg a beruházás? A fokozatos fejlesztést, vagy egy teljesen új üzleti modell bevezetését alkalmazzuk? Mennyi ideig tartson a projekt? Mely üzleti folyamataink épüljenek az informatikára? Mely informatikai szolgáltatások terjedjenek ki az egész vállalatra? Szükségünk van-e és milyen mértékben saját informatikai rendszerre? A szervezeti struktúra alkalmas-e az online üzletvitelre, vagy át kell alakítani? Az üzleti folyamatok milyen mértékben automatizálhatóak? A szervezeti-mőködési rendszer átalakítása milyen módon és ütemben történjen? Hogyan alakítsuk át az érdekeltségi rendszert? A jelenlegi dolgozók alkalmasak-e az új rendszerben történı együttmőködésre? Mennyit költsünk informatikára? Mennyit költsünk informatikai továbbképzésekre? Milyen szintő informatikai szolgáltatásokra van szükségünk és milyen áron? Milyen szervezeti formában irányítsuk az informatikát? Miképp támogatja az informatika az üzleti változásokat? Milyen informatikai beruházásaink voltak és milyen eredményeket hoztak? Milyen az informatikai rendszer biztonsága? stb.

Mint a fentiekbıl látható, jelentıs hangsúlyt kapnak az informatikával kapcsolatos kérdések, de ezek megválaszolása stratégiai szintő döntéseket jelent (vagyis nem a rendszergazda kompetenciájába tartozik)! Továbbá át kell gondolni a teljes ICT rendszer irányítását, mőködési módját, költségeit, valamint a teljesítmények mérésének kérdését is, hiszen elıfordulhat, hogy egy kis programhiba esetleg jóval nagyobb üzleti kárt okoz, mint amekkora költségbe a hiba kijavítása kerül.


17./64


6 AZ ONLINE ÜZLET FELÉPÍTÉSE Alexander Osterwalder (Universitè de Lausanne) nyomán az eBusiness üzleti modellben a négy nézıpont közötti kapcsolat az alábbi ábrával szemléltethetı:

TERMÉKTERMÉKFEJLESZTÉS FEJLESZTÉS

CRM CRM VEVİKAPCSOLATOK VEVİKAPCSOLATOK

CÉLVEVİ/ÜGYFÉL szükséges

Értéket hozzáad

INFORMÁCIÓ értékesítés

feltételez

visszajelzés

KÉPESSÉGEK

Beépít

erıforrásokat biztosít

győjt

ELÉGEDETTSÉG & SZOLGÁLTATÁS

ÜZLETÉRTÉK Képessé tesz

javít

létrehoz

javít

BIZALOM & HŐSÉG

erıforrást bizt.

árbevétel beépít

INFRASTRUKTÚRA INFRASTRUKTÚRA MENEDZSMENT MENEDZSMENT

PÉNZÜGYI PÉNZÜGYI SZEMPONTOK SZEMPONTOK

ERİFORRÁSOK & ESZKÖZÖK

Erıforrás bizt.

beépít

ÁRBEVÉTELI MODELL

költségek

MŐKÖDÉSI RENDSZER Erıforrás bizt.

beépít

PARTNERHÁLÓZAT

növel PROFIT / VESZTESÉG

Erıforrásokat biztosít

csökkent

KÖLTSÉG MODELL

Az üzleti modellben a termékfejlesztés a célvevı / célügyfél igényeinek figyelembe vételével történik és ennek minısége jelentısen befolyásolja az üzlet értéket. A termékek szolgáltatások minısége az értékesítés során mérhetı le, egyrészt a piaci kereslet alakulásában, másrészt a visszajelzések alapján mérhetı vevıi elégedettségen, a vevık loyalitásán, hőségén keresztül. Az üzleti modellben gondoskodni kell a vevık visszajelzéseinek a beépítésérıl a termékfejlesztési folyamatba, valamint az infrastruktúra fejlesztésébe, átalakításába. Minden cég stabil mőködésének alapja a likviditási egyensúly kézbentartása, ezért meg kell találni az optimumot a ráfordítások és bevételek arányában. Vagyis a fejlesztésekben és a mőködésben felhasznált erıforrások költségeinek vissza kell térülniük az értékesített termékek, szolgáltatások árában. Az eBusiness üzleti modellt a fenti aspektusokból kell végiggondolni és megtervezni. Amennyiben eldöntöttük, hogy vállalkozásunk üzleti folyamatait elektronikus rendszerrel támogatjuk, elı kell készítenünk a fejlesztési-beruházási projektet, melynek folyamatát a következı ábra foglalja össze.


18./64


1. Üzleti stratégia elemzése, stratégiai célok kitőzése

Döntés a projekt elıkészítésérıl

2. Új üzleti modell kidolgozása

Új üzleti modell elfogadása

3. Átalakításhoz stratégiai terv kidolgozása

4. Marketing-terv kidolgozása

5. Pénzügyi terv kidolgozása

6. ICT r. fejlesztési projektterv kidolg.

7. Szervezeti-mők.r. és érd.r. átalakítási projektterv kidolg.

8. Beruházási terv kidolgozása

Stratégiai terv jóváhagyása

9. Marketing projekt elıkészítése

10. Financális feltételek biztosítása

11. ICT fejl. projekt elıkészítése

12. BPR projekt elıkészítése

13. Beruházási proj. elıkészítése

14. Marketing projekt végrehajtása

15. Finanszírozás, controlling

16. ICT fejl. projekt végrehajtása

17. BPR projekt végrehajtása

18. Beruházási proj. végrehajtása

19. Rendszerindítás elıkészítése

20.üzembehelyezési eljárás végrehajt.

21. Az új rendszer üzemeltetése

22. Korrekciók végrehajtása, változáskövetés

A továbbiakban lépésenként részletezzük a teendıket az üzlet átalakításának folyamatában.


19./64


6.1

Üzleti stratégia elemzése, stratégiai célok kitőzése A cég hosszútávú céljaiból kiindulva elemeznünk kell a cég mőködését, melyek azok a kényszerítı tényezık, amelyek a mőködési rendszer megváltoztatását igénylik? Miután minden cégnek megvan a saját stratégiája, ami egyedi, nincs általános recept arra, hogy az elemzéseket hogyan hajtsuk végre. Számos módszer áll rendelkezésre, melyet alkalmazhatunk, pl. SWOT-analízis, benchmarking, stb. Az elemzés eredményeképpen megfogalmazzuk a stratégiai célokat, melyeket hosszútávon el szeretnénk érni. Az alábbiakban néhány tapasztalati példát mutatunk be konkrét számok nélkül: A Sunbooks könyvpiaci rendszer tervezését megelızıen a cégtulajdonosok hosszútávú célként tőzték ki, hogy átalakítják a magyar könyvpiac mőködését úgy, hogy új szereplıként, mint semleges szolgáltatók belépnek erre a piacra. A döntés 1999-ben történt és 2000-ben Magyarországon zöldmezıs beruházásként megvalósították és üzembehelyezték az elsı iparági mérető B2B (business to business) rendszert. Átvállalták a szereplıktıl az üzleti adminisztrációs feladatokat, ami nem a fı tevékenységükhöz tartozik. Elemezték a könyvpiaci szereplık problémáit, melyek közül néhányat emeltem ki: Könyvkiadók: • A könyvkiadás nagy kockázatú, hosszútávú befektetést igénylı tevékenység, emiatt a finanszírozása nagyon nehéz. • Nem tudni, hol tart a könyvek értékesítése, ki, hol, kinek, mit, milyen példányszámban értékesít, mikor folyik be ebbıl az árbevétel? A kiadó finanszírozza a teljes ellátási láncot, anélkül hogy tudná, mikor jut a pénzéhez, mikor térül meg a befektetése. • Nem lehet tudni, hogy hol milyen készletek vannak. • A raktározási költségek nagyon magasak, sok az elfekvı készlet. • Nehéz követni a bizományosi készletek útját. • Egy új könyv kiadása nagy kockázat, nem lehet tudni, mekkora lesz a kereslet. Könyvkereskedık: • A kisboltok vezetıi idejük nagy részét a beszerzésre fordítják, országjáró körutakat tesznek, hogy megtalálják a szükséges készleteket. • Nem tudják elıre, hol, milyen készleteket tudnak beszerezni. • A vevıkörükkel nincs elég idejük foglalkozni. • A bolti készletek finanszírozása problémát jelent, folyamatos likviditási gondokkal küzdenek. • Nem tudnak rugalmasan megfelelni a vevıi keresletnek. • Sok az elfekvı készlet. • A bizományosi készletek elszámolása, adminisztrálása sok idıt igényel. • Nincs naprakész információjuk a vevıi igényekrıl, a kiadói tervekrıl. • Marketing tevékenységet nem nagyon folytatnak, mert drága. • Meg kell küzdeniük az áruházláncokkal. A fenti problémákat elemezve fogalmazták meg a cégvezetık a Sunbooks üzleti stratégiáját: Olyan professzionális szintő szolgáltatásokat nyújtani mind a könyvkiadók, mind az értékesítık számára, amellyel a szereplık üzleti tevékenysége hatékonyabbá tehetı és a fenti problémák kiküszöbölhetık: pl. finanszírozás kérdése – hitelkeretek bitosításával, a számlázás és pénzbeszedés átvállalásával, bizományosi készletekkel, ingyen raktározással, az elszámolás automatizálásával, logisztikai szolgáltatások biztosításával, a teljes logisztikai lánc (betárolás, raktári folyamatok,


20./64


kiszállítás) automatikussá tételével, marketing információk eljuttatásával minden érdekelthez. Erre legalkalmasabb megoldás egy business to business (B2B – market place) rendszer kialakítása és ezen keresztül professzionális szolgáltatások nyújtása, amelyet a szereplık önmagukban nem képesek létrehozni, de a szolgáltatás igénybevételét már meg tudják fizetni és ezáltal jelentıs költségeket takaríthatnak meg. A piaci szereplık száma mindkét vonalon (kiadói és eladói oldalon) többezer, a cikkféleségek száma többtízezer. Ki lehetne alakítani olyan szolgáltatási díjakat, mely mindkét félnek megéri. A stratégia sikerességét bizonyítja, hogy 2000. augusztusa (amikor az eBusiness ciklus a mélypontján volt) óta a Sunbooks-rendszer folyamatosan mőködik, az évenkénti forgalom növekedési üteme pedig 50% fölötti. Nézzük egy informatikai fejlesztı, szolgáltató cég példáját. Kis magyar cégrıl lévén szó, hosszútávú célként a talpon maradást és egy szolíd nyereséget, ill. növekedést tervez. A SWOT analízis eredménye: Erısségek (Strenghts): • Felhalmozott tudásanyag és gyakorlati minták (best practice) • Hatékony szoftverfejlesztési technológia alkalmazása • Kipróbált projektvezetési módszertan, a határidık és költségkeretek betartása • Megbízható support tevékenység • Folyamat- és rendszerszemlélet alkalmazása a szoftverfejlesztésben • Standard, paraméterezhetı megoldások ötvözése egyedi fejlesztésekkel • Rugalmas, ütıképes csapat • Megbízható stratégiai partnerkör és együttmőködés • Interdiszciplináris (vezetés-irányítás-controllinginformatika) gyakorlat

Gyengeségek (Weaknesses): • Tıkehiány, idınként likviditási problémák • Az erıforrások (gépi és humán) kapacitásai túlterheltek • Internet sávszélesség szők keresztmetszet • Fiatal cég, kis létszámmal

Piaci lehetıségek: (Opportunities) • Speciális, ún. réspiaci (niche market) megoldásokra (kasztomizálás) van igény • A tartalomszolgáltatások és a hálózati tartalomelérés iránti kereslet megnövekedett • Outsourcing szolgáltatás miatt az ügyfelek száma nı • Termékek funkcióinak folyamatos továbbfejlesztése, többnyelvő verziók elıállítása • Dobozos szoftver bevezetése a teljes magyarnyelvő (határon túli) piacon • Az elıállított tartalmak „eBook” technológiával való terjesztése • Futó tanfolyamok kibıvítése elektronikus tananyagok kifejlesztésével

Piaci veszélyek (Threats): • Alacsony belépési korlát • Multinacionális piaci fölény • KKV-k (potenciális vevık) tıkehiányosak, nehezen szánják rá magukat ERP rendszer beruházásra • Üzletfejlesztési tanácsadásra, tanfolyamokra szintén a nagycégek szánnak forrásokat, mely szolgáltatásokat elsısorban a vezetı tanácsadó cégektıl vesznek igénybe • KKV-knál szemléletváltás lenne szükséges, ami hosszú idıt vesz igénybe.

Miután a cégben elsısorban a szellemi tıke a jelentıs (ami nem jelentkezik a fıkönyvben), érdemes a stratégiát a tudás értékesítésére irányítani és ennek megfelelı üzleti modellt kidolgozni pl. egy tartalomszolgáltató portál fejlesztésével, vagy a tanfolyami oktatások eLearning növelésével. Másik példánkban vegyünk egy nagykereskedı céget, amely elsısorban áruházláncoknak szállít több mint 10.000 féle iparcikket. Ebben az esetben a vevık diktálnak, megkövetelik a pontos szállítást, a megfelelı minıséget és behatárolják az árakat, ugyanakkor hosszú fizetési határidıvel fizetnek. Milyen kihívásokkal kell a nagykereskedı cégnek szembenéznie: •

Nagy a konkurrencia, ha nem teljesíti a feltételeket, könnyen kilistázzák,


21./64


• • •

• • • • • • •

A pontos és gyors kiszállításokhoz online információ szükséges az igényekrıl, A szállítandó cikkféleségek száma tízezres nagyságrendő, amit nagyon nehéz követni, A megfelelı minıségő termékek elıállítása és szállítása magas szintő szervezettséget igényel a logisztikai (értékesítési-, beszerzési-, csomagolási-, raktározási-, szállítási-) folyamatokban, mert egyébként csúsznak a kiszállítások, A versenytársak árait folyamatosan figyelni kell és az akciókra azonnal reagálni, Figyelemmel kell kísérni a vevıi keresletet, a készlet forgási sebességeket és a megfelelı intézkedéseket idıben meghozni, A szigorú EU elıírásokat be kell tartani (pl. származási hely dokumentálása, visszahívási lista, stb.) Alacsony szinten kell tartani a mőködési költségeket, Mérni kell a teljesítményeket és teljesítményarányos javadalmazást alkalmazni, A likviditási egyensúlyt folyamatosan fenn kell tartani, A vevıi problémákat azonnal orvosolni kell, stb.

Teljesen egyértelmő, hogy a nagykereskedı cég a tervezett növekedési ütemét csak integrált eBusiness rendszerrel lesz képes elérni, amelyben a kereskedelmi és logisztikai folyamatok nagymértékben automatizálva vannak, a logisztikai költségeket pedig minimális szintre szorítják le. Ezért a back-office ERP rendszer bevezetését követıen megkezdték az integrációt az áruházláncok rendszereivel EDI-n keresztül. Újabb példánkban vegyünk egy tanácsadó céget, amely elsısorban könyvelési és adótanácsadási szolgáltatást nyújt ügyfelei részére outsourcing formában. Mi kényszerítheti az eBusiness irányába a céget? •

•

• •

• • • •

Nagyszámú ügyfélnek szolgáltat, akik különbözı telephelyen vannak. A munkavégzés nagy része a helyszínen szükséges. A cég munkatársai számára ezért nagyon fontos, hogy külsı helyszínrıl is el tudják érni a cég belsı adatbázisát és tudásbázisát, amellyel a munkájukat megfelelı színvonalon végezhetik. Nagyon fontos a kommunikáció biztosítása a munkatársak között. Adott probléma megoldása, jogszabály értelmezés kérdése a tanácsadók között gyors információ cserét tesz szükségessé. Naprakészen követni kell minden tanácsadónak a jogszabály változásokat. A megoldott esetek, problémák leírásával a tudásbázist folyamatosan bıvíteni és tartalmát naprakészen tartani szükséges, melyhez az azonnali hozzáférést lehetıvé kell tenni a tanácsadók részére. Az ügyfelek folyamatos visszajelzést igényelnek a szolgáltatótól, hol tartanak a folyamatok (pl. mennyi lesz a nyereség)? Célszerő lenne kidolgozni ún. típus workflow-kat a jellemzı feladatokra, hogy a megszerzett tapasztalatok és tudás közkinccsé váljanak. Követni kell a tanácsadók teljesítményét és munkavégzésük színvonalát. Belsı szabványokat kell kidolgozni és alkalmazni a szolgáltatások nyújtására, melyet a tudásbázisban bármikor és bárhonnan elérhetıvé kell tenni.

Az elemzések alapján a tanácsadó cég a csoportmunkát hatékonyan támogató integrált informatikai rendszer kialakítását határozta el, melyben az ERP rendszer adatbázisának és a vállalati dokumentumoknak az elérése, a felhasználók közötti hatékony kommunikáció, workflow-k kezelése, a tudásbázishoz való online hozzáférés biztosítva van.


22./64


A fenti elemzések elvégzése után elkészítjük a cég stratégiai tervét, számszerősítjük a célokat, elvárásokat, meghatározzuk a cég növekedési ütemét, fejlesztési irányait a „szokásos” tervezési módszerekkel (pl. balance scorecard). Erre itt nem térünk ki, hiszen nagyszámú tervezési kézikönyv, szakirodalom áll e témában rendelkezésre.

6.2

Új üzleti modell kidolgozása Amennyiben az üzleti stratégia elemzésének eredményeképpen arra a következtetésre jutunk, hogy megérett a helyzet a cég átalakítására, ki kell dolgoznunk az új üzleti modellt, amelyre felépíthetjük a cég jövıbeni szervezetimőködési- és informatikai-kommunikációs rendszerét. Az üzleti modellben a következıket célszerő definiálnunk:

6.2.1 Termékek, szolgáltatások körének meghatározása A stratégiából kiindulva meghatározzuk, hogy a meglévı termék-, ill. szolgáltatás kínálatunkból melyeket akarunk online folyamatokban elıállítani és értékesíteni, ill. mivel és hogyan akarjuk azt bıvíteni. Természetesen meghatározzuk a vevıi célcsoportokat is, amelyeket el akarunk a kiválasztott termékeinkkel, szolgáltatásainkkal érni és megtervezzük az értékesítés elvárt felfutását. Új üzletágak, termékek, szolgáltatások bevezetése mindenképpen igényli a szervezeti-mőködési rendszer átalakítását, míg a jelenlegi profilunk folytatása kisebb átalakítást igényel. Fokozatos áttérés esetén mindig folyamat láncokban ajánlott gondolkodnunk. Nem célszerő horizontálisan, folyamatszakaszok szerint ütemezni az áttérést, hanem inkább tegyük ezt vertikálisan, pl. egy termékcsoportot kiválasztva, de a teljes logisztikai lánc lefedésével. Hiába valósítjuk meg pl. a vevıi rendelésfelvétel interneten keresztüli fogadását, ha az azt követı készletfoglalási, beszerzési, raktározási, kiszállítási, számlázási folyamatok nincsenek szintén automatizálva, nem tudunk idıben teljesíteni. Volt rá példa egy kereskedelmi láncot mőködtetı multicégnél, hogy gyönyörően megcsinálták a „kirakatot”, az internetes rendeléskezelı rendszert, majd az operátorok csapata kézzel vitte föl a beérkezett adatokat a logisztikai rendszerbe. Nem kell részleteznünk, hogy ez milyen többletköltséggel járt amellett, hogy a duplikált rögzítések hibái miatt gyakoriak voltak a reklamációk, a határidıcsúszások, duplán eladtak azonos készleteket és igazából senki nem volt elégedett.

6.2.2 Szereplık meghatározása Kik lesznek az üzlet szereplıi, akiket felhasználóként (IT értelemben) be akarunk vonni a rendszerbe? Általában a következı körökbıl tudjuk ıket kiválasztani: •

• • • •

Vevık, ügyfelek, ill. ezek csoportjai – akikkel már eddig is szerzıdéses kapcsolatban álltunk „hagyományos kommunikációs technológián” keresztül (szóbeli, telefon, fax, levél, esetleg e-mail kapcsolat); Potenciális vevık, ügyfelek – akiket meg akarunk szerezni; Szállítók – eldöntendı, hogy csak a kiemelt szállítók, vagy minden szállító, vagy minden potenciális szállító; Alvállalkozók – akik közremőködnek a teljesítés folyamatában; Gyártók – akikkel közvetlen kapcsolatban állunk, pl. termékképviseletet látunk el;


23./64


•

•

• • • • • • • •

Szolgáltatók – ha pl. kiszervezünk folyamatokat, melyet külsı szolgáltatók vesznek át, ezáltal részévé válnak az üzletünknek és teljesítményük befolyással van a mi teljesítményünk megítélésére is (pl. logisztika, szállítmányozás, ICT rendszer üzemeltetése, termelés, szerviz, bérszámfejtés, könyvelés, controlling); Partnerek, akikkel valamilyen témában együttmőködünk (pl. fejlesztési projektre létrehozott konzorcium tagjai, vagy holding szervezetben a tagvállalatok, leányvállalatok); Bank – a pénzügyi, finanszírozási kérdésekben, banki folyamatokban; Befektetı, finanszírozó – a projekt kockázatának csökkentése miatt átláthatóvá kell tenni számára az üzlet fejlıdését, növekedését; Belsı szervezeti egységek, ill. a szervezet tagjai – akik kapcsolatban állnak a külsı szereplıkkel és egymással is; Felsıvezetık, tulajdonosok – akik át akarják látni a cég teljes mőködését; Értékesítı hálózat tagjai (pl. területi képviselık, ügynökök, polcszervizesek, orvoslátogatók, key account managerek, stb.); Ügyfélszolgálat, vevıszolgálat tagjai; Hálózati pertnerek, akikkel valamilyen érdekszövetségben mőködünk együtt; Hatóságok, hivatalok – ha tevékenységünk szorosabban kapcsolódik hozzájuk (pl. vám, APEH).

6.2.3 Szereplık kapcsolatának meghatározása Ha feltérképeztük valamennyi szereplıjét a rendszernek, akkor meghatározzuk, hogy milyen kapcsolatban állnak egymással? Az ún. top-down (felülrıl lefelé) tervezési módot célszerő alkalmaznunk, mert egyébként elveszünk a részletekben. A kapcsolatok definiálása elıtt el kell döntenünk, hogy az egyes szereplık milyen szerepkörben, ill. tevékenységekkel vesznek részt a folyamatokban, pl.: •

• • •

Vevık – ajánlatkérés, ajánlat fogadás, megrendelés, áruátvétel, teljesítésigazolás, vásárlás, számlák pénzügyi kiegyenlítése, marketing akciók fogadása, ügyfélszolgálat igénybevétele, stb. Szállítók – ajánlatkérések fogadása, ajánlatadás, megrendelések fogadása, rendelés visszaigazolás, szállítás, számlázás, stb. Alvállalkozók – ajánlatadás, megállapodás, szerzıdéskötés, feladatok fogadása, teljesítés, adminisztráció, számlázás, stb. Potencális vevık – érdeklıdés, ajánlatok, marketing akciók fogadása, termékkatalógus, szolgáltatás kínálat, felmérések, stb.

Ha definiáltuk nagyvonalakban a szerepköröket, meg tudjuk határozni a szereplık közötti kapcsolatokat is. Sok esetben ez nagyon bonyolult kapcsolatrendszert eredményez, amit célszerő ábrázolnunk is. Pl. a Sunbooks rendszer üzembehelyezését megelızıen a könyvpiac kapcsolati rendszerét a következı ábra szemlélteti:


24./64


Könyvesbolt

Kiadó

Könyvesbolt

Kiadó Nagyker

Hipermarket

Kiadó Nagyker.

Könyvtár

Kiadó

Egyéb vevık

Gyakorlatilag minden szereplı kapcsolatba kerülhet bármelyik másik szereplıvel és a kapcsolat véletlenszerő, kiszámíthatatlan. Dr. Rényi Gábor – a Sunbooks rendszer szülıatyja – szerint: „A könyv csak véletlenül van a megfelelı idıben és helyen a szükséges mennyiségben! Információhiány mindenkinél! Vagyis - ideális helyzet egy komplex B2B megoldás számára!” A Sunbooks rendszer bevezetését követıen a kapcsolatrendszer átalakult és átláthatóvá, kiszámíthatóvá váltak a folyamatok:

Könyves -bolt hálózat

Könyvesbolt

Könyvesbolt

Kiadó

SUNBOOKS Kiadó

és logisztikai partnere

Hipermarket

Könyvtár

Kiadó

Egyéb vevık

Létrejött egy közös piactér, melyen egyforma módon, egyenrangú félként kapcsolatba kerülhet minden kiadó minden eladóval. Mindenki a saját üzletmenetére fókuszálhat, mert a háttérfolyamatokat a Sunbooks szolgáltatja és így valamennyi szereplı a saját üzletét sokkal nagyobb hatékonysággal bonyolíthatja.


25./64


A Sunbooks piactér üzleti koncepcióját az alábbi ábra szemlélteti:

VEVİK

MARKETING MARKETING

INFOLÁNC

INFOLÁNC

KIADÓK

Szegmentáció Árelemzés

Forgalomelemzés

Vevı-értékelés

Értékesítési csatornák

KönyvKönyv-

ÉRTÉKESÍTÉS ÉRTÉKESÍTÉS

Fogyás-figyelés

SBS

KönyvKönyv-

Központi

KIADÁS KIADÁS

adatbázis

Szolgáltatás fedezet

Kiadói elszámolás

Pénzforgalom

Bizományi készlet

Logisztikai teljesítmények

MONITORING MONITORING Szállítás

ÁRULÁNC

Tárolás

ÁRULÁNC

A Sunbooks rendszer boztosítja minden szerzıdött partner számára, hogy online rendeléseket adjon fel, melynek alapján a ki- és beszállításokat a logisztikai partner teljesíti, mindenki pontosan látja, hogy milyen feltételekkel vásárolhat, a rendszer biztosítja a számlázást, a pénzügyi teljesítések könyvelését, a bizományosi készletek fogyásjelentését, stb. Vagyis mindazon funkciót, amely nem tartozik szorosan a partnerek értékteremtı tevékenységéhez. 6.2.4 Üzleti folyamatok megtervezése Az üzleti folyamatok megtervezésénél az értékteremtı folyamatokra fókuszáljunk. Itt is a top-down tervezési módszert alkalmazzuk, azaz elıször azonosítjuk az egyes folyamatokat, csoportokba rendezzük, meghatározzuk a szereplıket, akik résztvesznek bennük és meghatározzuk, hogy az egyes szereplık a folyamaton belül milyen feladatokat, funkciókat látnak el. A csoportosítás alapja lehet például: funkcionálisan összetartozó folyamatok, szolgáltatási áganként, termékcsoportonként, vevıtípusonként, ügyfélkörönként, ahogy a cég mőködési rendszere szabályozza. Online rendszer építésérıl lévén szó, célszerő hozzárendelni a fıbb adatcsoportokat is az egyes funkciókhoz, ill. meghatározni, hogy ki legyen az adatgazda szervezet. Ennél a lépésnél még nem szükséges teljes mélységükben specifikálni a folyamatokat, de elegendı részletességünek kell lenniük a következı döntések megalapozásához: • • • • • •

• • • •

Milyen mértékben fedjük le az üzleti folyamatokat? Milyen mértékü automatizálást akarunk elérni az egyes folyamatoknál? Mely szervezeteket, felhasználói köröket érint az átalakítás? Szükséges-e a szervezeti struktúra átalakítása és milyen módon? Hogyan kell átalakítani, vagy kialakítani az ICT rendszert? Új rendszert vezessünk be, vagy a meglévıt fejlesszük tovább és integráljunk? A folyamatok automatizálása hogyan lehetséges? Szükség van-e technológia fejlesztésre és beruházásra az ICT rendszer fejlesztése mellett (pl. raktártechnológia, vagy gyártástechnológia fejlesztése)? Kiszervezzünk-e folyamatokat? Ha igen, milyen követelményekkel? Milyen módon biztosítsuk a kommunikációt a szereplık között? Az informatikai fejlesztés, beruházás milyen humán-, pénzügyi-, eszköz erıforrásokat igényel? Az ICT rendszert hogyan akarjuk üzemeltetni?


26./64


6.2.5 Beruházás gazdaságossági elemzés Mielıtt eldöntjük, hogy fokozatos fejlesztést, vagy adott idıpontban a teljes átállást valósítjuk meg, részletes gazdaságossági elemzést kell készítenünk, melynek során meghatározzuk: • • • • • •

A beruházási költségeket A várható árbevétel növekedést A mőködési költségek változását Megtérülési idıt A fedezeti pontot Várható eredményeket.

A beruházási költségeknél a következı tételeket javasoljuk figyelembe venni: •

• • •

•

• •

Az online üzleti modell piaci bevezetésének költségei (pl. szerzıdések elıkészítése, marketing költségek, a piaci szereplık meggyızése, árpolitika kialakításának költsége, ügyfelek részére kihelyezett számítógép, stb.); Az ICT alkalmazási rendszer fejlesztési és bevezetési projekt költségei; Az ICT infrastruktúra beruházási költségei; A szervezeti-mőködési rendszer átalakításának költségei (képzési költségek, projektben való közremőködés miatt kiesett idık, többletmunkák, új szervezeti egységek felállítása, vagy a jelenlegi átszervezése, dolgozók cseréjével kapcsolatos költségek, szabályzatok kidolgozásának költsége, stb.); Az esetleges technológia fejlesztés, beruházás költségei (például: raktártechnológia korszerősítése, gyártásirányítás átszervezése vonalkód alapján, automata gépsorok üzembehelyezése, ingatlanbıvítı beruházás); Az átállás költségei (párhuzamos mőködés, adatmigráció, teljesítések csúszása miatt esetleges árbevétel kiesés, stb.); Minıségbiztosítás költségei.

Célszerő számszerősíteni az elmaradt hasznot is, amely annak következtében jelentkezne, ha nem hajtjuk végre a beruházást. A beruházási költségek és az elmaradt haszon összehasonlításával fontos információt nyerünk a projekt szükségességére – bár nem mindig a megtérülés a döntı tényezı! Ha a konkurrencia már meglépte, ill. vevıink, ügyfeleink elvárják tılünk az online szolgáltatást, akkor már kényszerpályán vagyunk, hiszen egyébként nem tudjuk megtartani a piaci pozícióinkat. Fentiek alapján összesítjük, hogy milyen eszköz beruházásokra van szükség az ICT rendszer fejlesztése, ill. a technológiai fejlesztések alapján. A beruházási tervben tételesen meghatározzuk, hogy milyen áron fogjuk beszerezni az eszközöket. Ehhez információt győjthetünk az internetrıl, de konkrét árajánlatokat is bekérhetünk több potenciális szállítótól. A beruházási tételek beárazását követıen meghatározzuk, hogy az ICT projekt ütemterve és ha szükséges a technológiafejlesztési projekt ütemterve szerint a beruházási összegek milyen ütemezésben merülnek fel. A fedezeti pont és a megtérülési idı számításánál meg kell becsülnünk az új rendszer mőködtetésével kapcsolatos költségeket is, amely általában a következı tételekbıl tevıdik össze: • •

ICT rendszer karbantartási és üzemeltetési költsége; Vásárolt eszközök értékcsökkenése;


27./64


• • • • •

Változáskövetéssel összefüggı fejlesztések költsége; Szükséges szolgáltatások költsége (pl. internet); Képzési költségek; Minıségbiztosítás költsége; Biztonsággal kapcsolatos költségek.

A szakirodalomból ismert módszerek egyikével kiszámoljuk a beruházás teljes összegét (pl. nettó jelenérték számítással) és a megtérülési idıt, valamint a fedezeti pontot, melynek elérését követıen a képzıdı fedezet már a befektetett összeg visszatérülését szolgálja. A beruházási költségek felmerülésére célszerő egy cash-flow tervet is készítenünk, amely alapja lehet a projekt finanszírozási tervnek.

6.2.6 Döntés az új üzleti modell bevezetésérıl A fentiekben részletezett elıkészítı munka alapján megalapozottan dönthetünk arról, hogy: • • • • • • • • •

6.3

elfogadjuk-e az új üzleti modellt, melynek alapján elindítjuk-e az átalakítási projektet, milyen idıponttól, milyen fázisokban és milyen határidıkkel, milyen projektvezetési módszerrel, milyen projektszervezettel, kiknek a részvételével mekkora budget-tel?

Stratégia elkészítése az online üzlet felépítésére Pozitív döntés esetén stratégiai tervet készítünk arra, hogyan tudjuk a cég szervezetimőködési és informatikai rendszerét az új üzleti modell szerint átalakítani. Az átalakítás felfogható reorganizációs (BPR-business process re-enginering) projektként, amely az egész céget érintı, komplex feladat. Célszerő egymással párhuzamosan futó alprojekteket indítanunk az átfutási idı csökkentése, a jobb átláthatóság, ellenırízhetıség és kockázatok csökkentése érdekében az alábbiak szerint:

6.3.1 Marketing-terv kidolgozása Az üzleti modellben meghatározott termékek, szolgáltatások piaci bevezetésére, ill. az új vevıfolyamatok elfogadtatása érdekében marketing tervet kell kidolgoznunk, hogyan tudjuk a piaci szereplıkkel megismertetni és elfogadtatni a cég szolgáltatásait, melyeket a megszokottól eltérı módon tervez nyújtani. Minden jó üzlet alapja a kölcsönösen elınyös (win-win alapú) megállapodás, amelyben mindkét fél, az eladó és a vevı is megtalálja a számítását, érdekelt az üzlet létrejöttében. Ezen az elven kell meghatározni a szolgáltatások körét és színvonalát, a termékválasztékot, a feltételeket és az árakat.


28./64


A marketing-terv javasolt fejezetei: •

• • • • • • •

Marketing akcióterv – amelyben részletezzük, milyen akciókat, milyen ütemezéssel és költségráfordítással javasolunk végrehajtani a vevık meggyızése érdekében, Milyen marketing anyagokat tervezünk elkészíttetni milyen ütemezéssel és költségráfordítással, Típus-szerzıdések, megrendelés minták, üzleti feltételek kidolgozása és szabályozása, amelyek szerint a cég mőködni fog, Árképzési politika, kedvezményrendszer kidolgozása Tervezett szállítók, alvállalkozók és általuk adott ajánlatok, akik közremőködnek a marketing-terv végrehajtásában, Marketing költségterv, Szállítók, alvállalkozók kiválasztását segítı kritérium-rendszer meghatározása, Esetleges pályázati felhívás kidolgozása.

Továbbá át kell gondolnunk a kockázati tényezıket, amelyek a marketingterv sikeres végrehajtását befolyásolhatják. A kockázati tényezık azonosítását követıen meghatározzuk, hogy milyen hatással vannak az új üzleti modell sikerére, bekövetkezésük mennyire valószínő és a kockázatok milyen intézkedésekkel csökkenthetık.

6.3.2 ICT rendszer fejlesztési/beruházási projektterv kidolgozása Miután az eBusiness alapja az ICT rendszer (enélkül nem mőködik), kivitelezése nagyon körültekintı elıkészítı munkát igényel. Az informatikai rendszer fejlesztésénél ajánlott minıségvezérelt projektmenedzsment módszert (pl. CMMI) alkalmaznunk.1 Ehhez azonban mérnünk kell a szoftverfejlesztési folyamatot, amellyel a következı elınyökhöz jutunk: • • • • • •

Objektív információk állnak rendelkezésre a szubjektív megítélés helyett A problémák idıben felismerhetıek, azonosíthatóak és megoldhatóak A specifikus projekttermékek állapota és minısége nyomonkövethetı Tudatos kockázatkezelés valósítható meg A döntések megalapozottak lesznek Hatékony lesz a kommunikáció

amelyek eredményeképpen a szoftverfejlesztési projekt összköltsége akár 20 %-kal is csökkenthetı ahhoz képest, mintha nem alkalmaznánk tudatosan minıségvezérelt projektmenedzsment módszert. A projekttervezés során a következıkre érdemes figyelnünk: 1. ICT rendszerrel szemben támasztott követelmények meghatározása A Követelményjegyzék, vagy Követelmény specifikáció az alapja az ICT rendszerfejlesztési, ill. beruházási projekt végrehajtásának, ezért érdemes erre elegendı idıt és munkát ráfordítanunk. A Követelményjegyzék fıbb fejezetei: •

Funkcionális követelmények

1

A fejezetet Ph.D Dr. Pataricza András, Szıke Ákos, Dobán Orsolya, a BMGE MIT oktatóinak elıadása alapján állítottuk össze, mely a Magic Napok konferencián 2005.06.07-én hangzott el Visegrádon


29./64


Az online folyamatokhoz, amelyekben nagyfokú automatizálást valósítunk meg, pontosan illeszkednie kell az informatikai rendszernek. Különös figyelmet kell fordítanunk a normál funkcionális definíciók mellett a kivételes helyzetek azonosítására és kezelésük módjára. Ha ezt nem tesszük, a folyamatok megszakadnak, nem jut el az információ a megfelelı helyre, emiatt nem végzik el az adott feladatot, aminek „eredményeképpen” pl. a vevı nem fizeti ki a számlát. A funkcionális követelmények tartalmazzák a szoftver összes elvárt szolgáltatásait funkció elemekre lebontva, a folyamatok leírását, a beépített ellenırzési algoritmusokat, a rendszer összefüggések definiálását. •

Biztonsági követelmények Meghatározzuk, hogy milyen biztonsági szintet várunk el az ICT rendszertıl. Milyen leállási idıket engedhetünk meg, adataink milyen szintő adatvédelmet igényelnek, stb. – melyet aszerint tudunk mérlegelni, hogy a rendszer leállásából következı elmaradt üzleti eredmény, vagy adatvesztés hatása milyen arányban áll a biztonságra fordítható költségekkel.

•

Kommunikációs követelmények Meghatározzuk, hogy a szereplık között milyen típusú kommunikáció szükséges, milyen sebesség elvárások vannak, a kommunikáció során milyen biztonsági szintet kell garantálni.

•

Platform Általában minden cég rendelkezik már valamilyen informatikai infrastruktúrával. El kell dönteni, hogy saját eszközökkel, azonos platformon, az infrastruktúra bıvítésével, továbbfejlesztésével tervezzük az új rendszert, vagy másik környezetre akarunk áttérni (például: MS Windows-ról LINUX-ra, vagy UNIX operációs rendszerre, Oracle-rıl IBM DB2, vagy MS SQL adatbáziskezelı rendszerre). Másik lehetıség, hogy kiszervezzük az informatikát és nem a saját eszközparkunkra alapozunk. A platformváltás általában jelentıs többletköltséget okoz, hiszen az informatikai csapatba új szakértı bevonása szükséges.

•

Egyéb követelmények Meghatározzuk, hogy az IT rendszer hány telephelyen, hol mőködjön, az egyidejő, nevesített, összes felhasználók számát, az adatbázis várható méretét, a napi tranzakciók számát, az adatbázis növekedési ütemét, a kommunikáció módját, szükséges-e és milyen mértékő adatmigráció, az alkalmazást hány nyelven fogják használni, és minden olyan egyéb követelményt, amelyet fontosnak tartunk.

•

Ügyfélszolgálat A folyamatos üzemben mőködı eBusiness rendszer magasabb szintő ügyfélszolgálatot igényel, mint a hagyományos parciális, vagy ERP rendszerek. Ezért meghatározzuk, hogy milyen szolgáltatási szinteket (SLA – Service Level Agreement) várunk el az ügyfélszolgálattól a hibaelhárítás, a problémák kezelése, a felhasználói támogatás terén.

•

Változáskezelés Számítanunk kell arra, hogy az üzleti folyamatokban folyamatos változások következnek be, amelyeket az informatikai rendszerben is követni kell amellett, hogy a rendszer éles üzeme nem, vagy legfeljebb csak rövid idıre állhat le. Ezért a változások kezelése, az új, vagy módosított folyamatok, funkciók beillesztése az informatikai rendszerbe olyan szoftverfejlesztési technológiát és módszertant igényel, amelyekkel a változáskezelés hatékonyan és biztonságosan megoldható (ld. Microsoft „karanténszerő javításkezelés”) A


30./64


Követelményjegyzékben ezért meg kell fogalmazni az ezzel kapcsolatos elvárásokat is.

2. Az ICT rendszer architektúra terve A fenti követelményekbıl kiindulva, a szereplık, üzleti folyamatok figyelembe vételével elkészítjük az informatikai rendszer architektúra tervét, melynek meghatározó szempontjai: • • • • • • • • • • • • • • • •

Telephelyek száma; Telephelyenként a felhasználók száma; Telephelyek közötti kommunikáció módja; Felhasználói csoportok és a csoportok mérete; A felhasználói csoportok közötti kommunikáció módja; A funkciók megosztása a felhasználói csoportok között; Felhasználói munkahelyek kiépítésének szempontjai; Kiszolgálók (szerverek) száma, szükséges konfigurációi; Szükséges mobil eszközök; Tervezett alapszoftverek és alkalmazások; A tranzakciók száma; Az adatbázis mérete és növekedési üteme; Biztonsági követelmények; Sebesség elvárások; A jelenlegi és jövıbeni alkalmazások együttmőködésének tervezett módja; Beruházási keret nagysága.

Az architektúraterv fıbb elemei: •

Szerverpark (biztonsági okokból célszerő különválasztani az adatbázis-, applikációs-, kommunikációs- és levelezı szervereket, a fejlesztı szervert, esetleges tartalék szervert);

•

Felhasználói munkahelyek – amelyekbe beleértendık nemcsak a szokásos asztali gépek, note-book-ok, hanem az ún mobil eszközök is, melyek tárháza egyre bıvül (palmtop-ok, adatgyőjtık, mobil telefon, stb.);

•

Szoftverek: operációs rendszer, adatbáziskezelı rendszer, kommunikációs rendszer, tőzfal, vírusvédı, levelezı rendszer, rendszerfelügyeleti szoftverek, alkalmazási rendszerek, stb.;

•

Hálózat kiépítés, kommunikációs módok a felhasználói csoportok között (internet, intranet, extranet), hálózati topológia;

•

Egyéb hardvereszközök (nyomtatók, video eszközök, vonalkód olvasók, stb.);

•

Sávszélesség, szolgáltató(k).

Az architektúraterv alapján meg kell tudnunk határozni, hogy milyen informatikai eszközbeszerzésekre van szükség a meglévı eszközpark beszámításával.

3. Alkalmazási rendszer fejlesztési terve A funkcionális követelményekbıl kiindulva meghatározzuk, hogy milyen mértékő alkalmazásfejlesztésre van szükség. A fejlesztésnek három módja lehetséges:


31./64


•

A jelenleg alkalmazott ERP rendszernek vannak olyan további moduljai, amelyekkel az ún. front-office funkciók kielégíthetık és a rendszerintegráció nem sérül. Ebben az esetben legegyszerőbb ezeket is megvásárolni és bevezetni;

•

Egyedi fejlesztéssel valósítjuk meg, vagy külön programcsomagban vásároljuk meg a hiányzó modulokat. Ebben az esetben rendszerintegrációt kell végrehajtanunk a különbözı alkalmazások között, hogy a folyamatok online menjenek végbe;

•

Új alkalmazási rendszert vásárolunk, vagy fejlesztünk, ill. fejlesztetünk és vezetünk be, amivel a jelenlegit kiváltjuk.

A második módszer alkalmazása esetén a funkcionális követelményekbıl kiindulva meghatározzuk, hogy melyik funkció valósítható meg csak egyedi fejlesztéssel, ill. a rendszerintegráció milyen egyedi fejlesztési feladatokat igényel. A rendszerintegráció általában mindkét (vagy több) oldalon igényel kiegészítéseket attól függıen, hogy milyen fejlesztıeszközt alkalmazunk, ill. milyen szintő integrációt akarunk megvalósítani. A rendszerintegráció rétegeit a következı ábra szemlélteti:

•

Üzenetszint – az alkalmazási rendszerek közötti adatcserét, amelyek önálló adatbázissal rendelkeznek, egy üzenetkezelı szoftver biztosítja, pl. a frontoffice funkciók használatakor keletkezett adatok üzeneteken keresztül jutnak el a back-office rendszerbe és fordítva. Az üzenetek hatására adatok generálódnak és a programok futtatása automatikusan történik. A részrendszerek közötti kommunikáció ún. log file-okban követhetı nyomon, melyekbıl a hibák is kiszőrhetık.

•

Adatbázis szint – az adatbázisok tartalmát összehangoljuk (szinkronizáljuk), ill. a különbözı alkalmazások programjai azonos adatbázisokon dolgoznak. A különbözı adatbázisok tartalmának összehangolása különösen a törzsadatoknál szükséges, mert a tranzakciós hivatkozások így hozhatók közös nevezıre. Ezt általában ún. fordítótáblák beiktatásával valósíthatjuk meg, amelyekben megfeleltetjük az egyik adatbázis törzsadatát a másik adatbázis törzsadatával (pl. ügyfélkód, cikkszám, stb.) A tranzakcióknál szintén fontos a


32./64


fogalmi egyeztetés, hogy az adatokat azonos értelemben használjuk (pl. teljesítés dátuma, vagy árfolyam azonos módon legyen értelmezve). •

Programszint – a különbözı alkalmazások programjai meghívják a másik alkalmazás programjait az üzleti logika szerint. Pl. ha az ERP rendszer külsı HR (Human resources – emberi erıforrás) modullal kapcsolódik, a HR rendszerben a dolgozótörzs karbantartása meghívhatja az ERP rendszerbıl a költséghely karbantartó programot, hogy egy új költséghelyet vehessünk fel az új dolgozóra, ill. a felvett új dolgozó a többi ERP funkció számára azonnal láthatóvá és hivatkozhatóvá váljon).

•

Folyamatszint – az üzleti logika szerint kialakított workflow-k vezérlésével indítjuk el automatikusan az alkalmazási rendszer(ek) egyes funkcióit. Például: a front office rendszerben interneten keresztül feladott rendelés elindítja a back office rendszerben a készletfoglalást és visszaadja az információt a lefoglalt mennyiségrıl a rendelésfeladó számára, vagy a raktárlogisztikai rendszerbıl a kiszedés befejezése elindítja a számlakészítést az ERP pénzügyszámviteli moduljában.

•

Megjelenítés szintje – a képernyın a felhasználók egységes felületen minden alkalmazás funkciót el tudnak érni a jogosultságuk szerint, függetlenül attól, hogy a rendszer belsejében hányféle alkalmazás milyen adatbázisokon dolgozik és közöttük milyen kommunikáció zajlik.

Ma már számos rendszerintegrációs célszoftvert találunk a piacon, amelyek segítségével az integrációs feladatokat hatékonyan, rövid átfutási idı alatt meg lehet oldani. (Pl. IBM WebSpheare, Magic iBOLT, vagy Microsoft SharePoint, InfoPath és BizTalk, stb.). Ezek a szoftverek különbözı szintü work-flow támogatást is nyújtanak, amelynek segítségével automatizálhatjuk az alkalmazási rendszerek funkcióinak lefutását anélkül, hogy nagyobb programozási munkára lenne szükség. A rendszerintegráció további elınye, hogy a régi, bevált alkalmazási rendszereket nem kell lecserélni, hanem egy magasabb szinten tudjuk hasznosítani az információkat. Akár új alkalmazási rendszert vásárolunk és vezetünk be, akár fejlesztünk, további egyedi fejlesztési feladatként jelentkezik az adatmigráció, amelynek során a régi adatainkat áttöltjük az új rendszer adatbázisába, ill. kiegészítjük a hiányzó törzsadatokkal. Az áttöltés során ki kell küszöbölni az adat inkonzisztenciákat, ami sokesetben jelentıs manuális munkát is igényel.

4. IT fejlesztési projektszervezet meghatározása Az alkalmazási rendszer fejlesztését megvalósíthatjuk házon belül, saját fejlesztı csapattal – ha rendelkezünk velük. A cégek többségénél azonban, ahol nem az informatika a fı tevékenység (core business), külsı szállítókat vesznek igénybe az IT fejlesztési projekt végrehajtására. A projektszervezetben azonban az IT fejlesztıkön kívül mindenképpen részt kell venniük a funkcionális szakterületek képviselıinek is, függetlenül attól, hogy külsı, vagy saját fejlesztıkkel dolgozunk. Csak így tudjuk biztosítani, hogy a felhasználói igényeknek megfeleljen a szoftver. A projektszervezet felépítése általában a következı, amelyben mindkét oldalról – az üzleti oldalról, ill. az IT oldalról is – delegálni kell a résztvevıket: Projektszponzor, vagy projekttulajdonos A projekt felügyeletét látja el. Ez a kellı hatáskörrel rendelkezı testület, vagy személy hagyja jóvá a Projektalapító Okiratot, valamint a terveket és veszi át elsıdlegesen a projekt elkészült termékeit. Feladata a projekt számára szükséges


33./64


erıforrások és költségkeretek rendelkezésre bocsátása. A bizottság, vagy felelıs a projekt mérföldkı eseményeinek idıpontjában áttekinti, ellenırzi és értékeli a projekt elırehaladását és a szükséges intézkedéseket megteszi. Általában a cég felsıvezetıi a bizottság tagjai. Projektvezetı A projekt napi mőködésének és a projekttagok munkájának operatív irányítója. İ a felelıs a Projektalapító Okirat és a tervek elkészítéséért, a terv szerinti haladásért, a projekttermékek elkészítéséért, valamint a minıségbiztosítás projekten belüli érvényesítéséért. A projektszponzor felé beszámolási kötelezettsége van. Tájékoztatja a felsıvezetıséget az elırehaladásról és a kivételes eseményekrıl. Funkcionális szakértık Adott szakterületet összefüggésében átlátó szakértık, akik a szükséges szakmai döntéseket meghozzák. Projekttagok A projektben kitőzött feladatok végrehajtói, a projektvezetık felügyelete és irányítása alatt látják el feladataikat. Projektadminisztrátor A projektadminisztrátorok feladata a projekt dokumentálása, a koordinációs feladatok, egyeztetések elvégzése, a projekt mőködéséhez szükséges eszközfeltételek biztosítása. Továbbá feladata még a projekt során keletkezett valamennyi dokumentáció kezelése és ırzése, a változások kezelése.

6. Minıségbiztosítás A szoftverfejlesztésben a megrendelı által támasztott minıségi elvárások: • • • • •

A szállítás gyorsasága (fejlesztés átfutási ideje) A szoftver minısége (a Követelményjegyzéknek való megfelelés mértéke és a programok hibamentessége) Költségek minimalizálása A határidık betartása Egyéb.

A fenti tényezık többnyire egymás ellen hatnak, ezért meg kell találnunk egy optimumot, amelynél a tényezık egyensúlyba hozhatók. Pl. a fejlesztés átfutási idejének csökkentése, vagy a minıségi követelmények szigorítása elég nehezen valósítható meg a költségek csökkentése mellett. Az alábbiakban bemutatunk egy minıségvezérelt projektmenedzsment módszert, amelyet a kritikus alkalmazásfejlesztési projekteknél célszerő alkalmaznunk. A CMMI (Capability Maturity Model Integration) minıségvezérelt projektmenedzsment módszer – amelynek alkalmazása az USA-ban már az 1990-es évek óta alapvetı elvárás a szoftverfejlesztı cégekkel szemben - több szinten értelmezhetı az alábbiak szerint:


34./64


CMMI szintek értelmezése Kezdetleges

(Nincs)

Menedzselt

1. Tervezés

Kvantitatívan menedzselt

Definiált

4. Integrált projekt mgt

2. Monitoring és kontroll 5. Integrált csapat 3. Szállító mgt

Optimalizált

8. Kvantitatív projekt mgt

6. Kockázatkezelés 7. Integrált szállító mgt

Minıségvezérlés alapja

A projekt tervezett költségkerete és az elvárt átfutási idık függvényében kell mérlegelnünk, hogy a minıségvezérlést melyik szinten valósítjuk meg. A minıségvezérlés legmagasabb foka, amikor az optimalizálást folyamatos méréssel, elemzéssel és változáskezeléssel végezzük, melynek feltételeit a projekt során biztosítjuk. Hogyan mérhetı a szoftverfejlesztési folyamat? Ennek általános modelljét az alábbi ábra szemlélteti:

C é l je lle m z ı k

J e lle m zı k

M e triká k

H ib a e lı fo rd u lá s m o d e lle z é s e

H ib a s z á m id ı b e li m e g je le n é s e /m é re t

E le m zı m ó d s ze re k

P é ld a : K v a n tita tív p ro j m g t F o ly a m a t te lje s ítm é n y é n e k s ta tis z tik a i m e n e d z s e lé s e

R a y le ig h m o d e ll 18

Még a legkisebb projektben is javasolt metrikák: • •

Earned value – becslés az ütemezésre, szkópra (mőveleti hatókör, alkalmazási terület) Hibatrend – döntéstámogatás a tesztelési erıforrás allokáláshoz, termékátadáshoz


35./64


•

Tesztelés elırehaladási trend

Az elırehaladás mérésére alkalmazható az Earned value analysis, amelynek során a hasonló feladatok végrehajtásának Performance Index-ét (PI – teljesítménymutató) mérjük, ill. rendszeresen újraszámoljuk. A Hibatrend a nyitott és lezárt hibák idıbeni lefutását mutatja a hibák súlyozásával. A Tesztelés elırehaladási trend a szoftverfejlesztés elırehaladásának fokát mutatja, amelyben a különbözı teszt-esetek eltérı súllyal szerepelnek. A mérésekre és elemzésekre számos módszer áll rendelkezésre (pl. COCOMOII, COQUALMO) melyek részletezésére itt nem térünk ki. Természetesen a CMMI mellett számos más minıségbiztosítási módszert (pl. CMM, ISO9001, 6Ơ – six sigma, V-modell, stb.) is alkalmazhatunk a szoftverfejlesztési projektekhez, vagy akár kialakíthatjuk a saját egyedi módszertanunkat is.

6. Szállítók, alvállalkozók kiválasztása Amennyiben külsı csapattal szeretnénk az informatikai projektet végrehajtani, ebben a fázisban meg kell határoznunk azt a szempontrendszert, amelynek alapján a szállító(k) kiválasztása megtörténik. Mielıtt a szempontrendszert definiáljuk, eldöntjük, hogy kész szoftvercsomag megvételével és bevezetésével, vagy egyedi fejlesztéssel, ill. a kettı kombinációjával hajtjuk végre a projektet. A döntés eredménye behatárolja a lehetséges szállítók körét. A szállító kiválasztásánál alkalmazott fontosabb szempontok: • • • • • • • • • • • • • • • •

Lehetséges szoftvercsomag(ok) szállítói Funkcionalitás teljeskörősége, egyedi fejlesztés mértéke Ár/Érték (milyen mértékő funkcionalitást valósít meg az alkalmazás a követelmények alapján és milyen áron) Referenciák Szakembergárda felkészültsége Megbízhatóság, eszközháttér Pénzügyi stabilitás Helyettesíthetıség (fıleg az egyedi fejlesztés esetén) Projektvezetési és szoftverfejlesztési módszertan és technológiák Átfutási idı Járulékos beruházási igény – ami csak az adott termék bevezetése esetén szükséges Karbantartás, üzemeltetés támogatás színvonala és ára Rugalmasság, reakcióidık Garancia Az üzleti folyamatokban bekövetkezı változások követése, leképezése az alkalmazásban milyen feltételekkel Stb.

A szempontokat egymáshoz képest súlyozzuk, és az egyes szempontokhoz skálaértékeket rendelünk, melynek alapján a beérkezett ajánlatokat értékeljük. Eldöntjük, hogy a kiválasztás (nyilvános, vagy meghívásos) pályázat útján, vagy ajánlatkérés alapján történjen és ennek megfelelıen elıkészítjük a pályázat / ajánlatkérés szövegét.


36./64


7. Informatikai biztonság kérdése

2

Az eBusiness üzleti modellben az informatikai rendszertıl folyamatos biztonságos üzemő mőködést várunk el, mert ellenkezı esetben mérhetı veszteségeink adódnak az ICT rendszer kiesése miatt. Általában a biztonság fogalma alatt azt értjük, hogy a múlt tapasztalatai alapján a jelenben vizsgáljuk, hogy a rendszer a jövıben kiszámíthatóan fog mőködni. Az ICT rendszereknél azért nehéz a biztonságot menedzselni, mivel az informatika más technológiákhoz képest még nagyon rövid múltra tekint vissza, így a statisztikai és az esetlegesen rendelkezésre álló benchmark adatok nem mutatnak stacionaritást, másrészt rendkívül gyorsan változik mind a technológia, mind a környezet, mely változások elıre nem látható problémákat vetnek fel. Mégis meg kell próbálnunk úgy felállítani és üzemeltetni az ICT rendszerünket, hogy a rendszer leállások lehetıleg ne következzenek be. A biztonság mérıszáma a kockázat: R = Σ p t * dt tΕT

ahol:

R – Risk (kockázat) T – Threat (veszélyforrások halmaza) pt – probability (egy adott veszélyforrás bekövetkezési valószínősége) d – damage (kár mértéke adott veszélyforrás bekövetkezésekor)

vagyis a kockázat nagyságát a lehetséges károk nagysága és bekövetkezési valószínőségeinek szorzata, ill. ezek összege határozza meg egy idıintervallumon belül. Az informatikában a veszélyforrások rendszerelem szinten következnek be, de az üzleti folyamatok szintjén okoznak károkat, melynek következtében a másodlagos, harmadlagos károk sokkal nagyobbak az elsıdleges károknál. Ezek összefüggéseit szemlélteti a következı ábra:

2

A fejezetet Hornák Zoltán, a BMGE MIT oktatójának elıadása alapján állítottuk össze, mely a BMS Informatika Kft. által bonyolított „Mérhetı és értékelhetı informatika” tanfolyamon hangzott el.


37./64


A kockázat menedzsment során meg kell határoznunk, hogy az egyes rendszerelemek kiesése milyen hatással van a rendszer mőködésének egészére és ez milyen nagyságrendő károkat okozhat az üzleti folyamatokban. Az ICT rendszer komplexitása miatt az elméleti kockázat-elemzés helyett a gyakorlati kockázatmendzsmentet javasoljuk alkalmazni, ahol a kockázat pontos meghatározása helyett – ill. anélkül – a célszerő védelmi intézkedéseket közvetlenül határozzuk meg. Ennek során ún. Fuzzy fogalmakkal dolgozunk, vagyis konkrét kvantitatív értékek helyett szemantikailag értelmezhetı kategóriákat állítunk fel. A gyakorlati kockázatmenedzsment fı lépései:


38./64


1. Kategóriák felállítása: - bekövetkezési valószínőség kategóriái - Kár kategóriák - Kockázati kategóriák - Kockázati szorzótábla meghatározása

2. Veszélyforrások listájának összeállítása

3. Bekövetkezési valószínőségek nagyságrendi becslése

4. Kárérték nagyságrendi meghatározása

5. Kockázati tényezık származtatása

6. Elviselhetetlen kockázatok kezelése

7. Lehetséges védelmi intézkedések számbavétele és a megfelelı alternatívák kiválasztása

A folyamat során az alábbi kockázatelemzési táblázat fokozatos kitöltése történik:

ID

Bekövetkezés Veszélyforrás valószínősége P

Az ID pl.: • • • • •

Kár C

I

Kockázat A

Védelmi intézkedés

R

azonosítóban célszerő a veszélyforrás természetére utaló jelölést alkalmazni, Sz – szervezeti H - humán L - logikai T - természeti F - fizikai

A veszélyforrás bekövetkezésének valószínőségére javasolt kategória definíciók: • PVS – nagyon kicsi (very small) – ritkán, kb. 10 évben egyszer várható az elıfordulása • PS - kicsi (small) – kb. 5-10 évente elıforduló, vagy csak profi támadó által kihasználható gyengeség • PL - nagy (large) – évente egyszer elıforduló, vagy átlagos szakember által végrehajtható visszaélés


39./64


•

PVL - nagyon nagy (very large) – évente többször elıforduló, vagy bárki által kihasználható gyengeség

A károkat az általuk bekövetkezı hatásmechanizmusok szerint szokás csoportosítani: • • •

C – confidentiality – a bizalmasság megsértésébıl, jogtalan információszerzésbıl (pl. betörés) adódó károk I - integrity – a rendszerintegritás megsértésébıl, pl. adatmanipulációval keletkezı károk A – availabilty – rendelkezésre állás fennakadásából bekövetkezı károk (pl. szerver leállás, áramszünet, szolgáltatás kiesés, stb.)

A kár mértékét a fenti csoportosításon belül a következıképpen lehet kategorizálni: • • • • •

DVS – elhanyagolható (very small) – elsıdleges, elhanyagolható mértékő kár DS - kicsi (small) – másodlagos, nagyobb összegő kár DA - közepes – fennakadás az alkalmazói rendszerben, könnyő emberi sérülés DL - nagy (large) – az üzletmenetben idıleges fennakadás, ügyfélkörben is érezhetı változás, haláleset DVL - katasztrofális (very large) – az üzletmenet hosszabb megszakadása, mely az egész cég csıdjét okozhatja

A kockázati kategóriákat a cég profiljától és méretétıl függıen határozzuk meg, pl.: • • • • •

RVS – RS RA RL RVL -

nagyon kicsi (very small) – 10 ezer Ft/év körül kicsi (small) – 100 ezer Ft/év körül közepes – 1 millió Ft/év körül nagy (large) – 10 millió Ft/év körül nagyon nagy (very large) – beláthatatlan (nem korlátos)

A kockázati kategóriákat a kockázati szorzótábla segítségével tudjuk származtatni. Amikor hosszútávra tervezünk és nagyobb beruházásra készülünk, gondolhatunk a kisebb gyakorisággal bekövetkezı, de nagy értékő károkat kiküszöbölı megoldások alkalmazására (pl. tartalék számítóközpont építése). Érdemes az ún. elviselhetetlen kockázatokat külön jelölnünk, amelyek bekövetkezése ellen mindenképpen védekeznünk kell. Külön dokumentumban érdemes az alternatív védelmi intézkedéseket összegyőjteni, feltüntetve a nagyságrendi beruházási és üzemeltetési költségeket, ill. az általuk kielégített követelményeket, majd ezekbıl rendeljük hozzá a javasolt intézkedéseket a kockázatelemzési táblázat veszélyforrásaihoz. A veszélyek hatásmechanizmusa alapján a védelmi intézkedések irányulhatnak: • • • •

A A A A

veszélyforrás kiküszöbölésére veszélyforrás bekövetkezés valószínőségének csökkentésére veszélyforrás hatásának, az okozott kár nagyságának korlátozására kockázat áthárítására (pl. biztosítás)

Az eBusiness alapját jelentı informatikai rendszerre érdemes kidolgozni az alapelveket, vezetıi döntéseket tartalmazó biztonságpolitikát és annak konkrét, utasítás szintő változatát az informatikai biztonsági szabályzatot, mert ezzel tudjuk menedzselhetıvé tenni az ICT rendszert. Ügyeljünk arra, hogy a biztonságpolitikában a biztonsági célt (control objective) kell meghatározni és nem a védelem módszerét!


40./64


8. Projekt feladat és ütemterv Amikor meghatároztuk a tervezés során: • • • • • • •

Az elvárt követelményeket A ICT rendszer architektúráját és beruházási igényeket A projektvezetés módszerét Milyen külsı, vagy belsı kivitelezıvel hajtjuk végre a projektet A projekt tervezett idıtartamát A projekt költségeit A biztonságpolitikát

akkor meg tudjuk határozni a projekt mérföldkı eseményeit, azok bekövetkezéséhez elvégzendı feladatokat, felelısöket és kapacitás igényeket, valamint az elkészítendı projekt termékeket. A projekt termékekhez definiálni kell az elfogadási kritériumokat, amelyek alapján az átadás-átvétel, ill. a teljesítés igazolása megtörténik. A feladat- és ütemterv összeállításánál necsak a külsı, hanem a belsı humán erıforrás szükségletre is legyünk figyelemmel, mert enélkül könnyen kicsúszhatunk a határidıbıl. Sokesetben a cég belsı emberei okozzák a határidı csúszásokat, mivel ık a napi feladatuk mellett, pluszmunkában teljesítik a projektfeladatokat. A projekt feladat- és ütemtervben mérföldkı eseményeket határozunk meg, melyekhez hozzárendeljük az elvárt projekt termékeket és költségeket. A feladat- és ütemterv tevékenységeihez hozzá kell rendelni a felelısöket. A feladat és ütemtervet hálóterv, vagy Gant-diagram formájában ábrázoljuk a projekt nagyságától és bonyolultságától függıen. A jóváhagyott feladat- és ütemterv lesz a teljesítés mérésének alapja. A projekt feladat- és ütemterv többszintő, a mérföldkövek közötti tevékenységeket a projekt végrehajtása során le kell bontani résztevékenységekre és határidıkre, amely a projekt átfutási idejétıl és az erıforrásoktól függıen lehet akár napi szintő is. Fontos a kritikus útvonal meghatározása, mert ha a kritikus eseményekben következik be határidı csúszás, az a teljes projekt véghatáridejét is módosítani fogja. Egy alkalmazási rendszer bevezetési projekt általában a következı fázisokból áll: • • • • • • • • • • •

Szerzıdéskötés, projektalapító okirat elkészítése és elfogadása Követelményjegyzék, követelmény specifikáció elkészítése és jóváhagyása Rendszertelepítés, paraméterezés Kulcsfelhasználók kiképzése Tesztelés, hibajavítás Átadás-átvételi teszt végrehajtása Adatmigráció végrehajtása Rendszer éles indulásának elıkészítése Felhasználók oktatása Rendszerindítás Üzemeltetés felügyelet, támogatás.

9. ICT rendszerfejlesztési projekt cash-flow terve A projekt feladat- és ütemterv szerint meghatározzuk, hogy a szoftverfejlesztési projekt egyes fázisaihoz milyen költségfelhasználások kapcsolódnak. Nemcsak a szoftverfejlesztés költségeivel kell számolnunk, hanem a kapcsolódó eszköz- és szoftverlicenc vásárlások, hálózatépítés ütemezését is figyelembe kell vennünk. Pl. a


41./64


tesztelési fázisra már a teljes üzemelési környezetet fel kell állítanunk ahhoz, hogy a teszteléseket elvégezhessük.

6.3.3 BPR projektterv kidolgozása Az online üzletvitelre való áttéréshez nélkülözhetetlen a mőködési folyamatok elemzése, újragondolása, át-, ill. kialakítása, hiszen jelentıs mértékben automatizálni akarjuk ezeket a folyamatokat. Az automatizálás feltétele, hogy minden alkalommal a folyamat elindításakor bekövetkezzen az az eseménysor, ill. végrehajtsák azokat a feladatokat, amelyek a folyamat lezárásához szükségesek. A hagyományos üzletvitelt folytató cégeknél még sehol nem tapasztaltunk olyan magas fokú szervezettségi szintet, ahol ne lett volna szükség egy BPR (business process reengineering) projekt végrehajtására (is). Hangsúlyozni szeretnénk, hogy az online üzletvitel egyik legnagyobb kockázati tényezıje, ha az informatikai folyamatok nem tudják lekövetni a valós értékesítési, logisztikai, termelési, szolgáltatási folyamatokat, mert ennek hiányában az üzlet sem fog menni! Az üzleti folyamatok újraformálására irányuló projektben a következı lépéseket javasoljuk megtenni: 1. A folyamatok azonosítása A folyamatok azonosításánál az üzleti modell alapján megfogalmazott funkcionális követelményekbıl indulunk ki. Célszerő különválasztani a kulcsfolyamatokat, amelyek a cég fı tevékenységéhez kapcsolódnak és a háttér folyamatokat, amelyek nem befolyásolják közvetlenül az üzletvitelt (pl. könyvelés, bészámfejtés, controlling, stb.). Ennek során számbavesszük az üzleti folyamatokat, csoportosítjuk ıket, rendszerezzük mind horizontális, mind vertikális irányban (párhuzamos folyamatok, egymás alá-fölérendelt folyamatok). Pl. vevıi rendelés, rendelés visszaigazolás, készletfoglalás, rendelés módosítás, rendelés sztornózás, stb. folyamatokat azonosítunk, amelyek párhuzamos folyamatok, a vevıi rendelésen belül a vevı azonosítása, a rendelési feltételek megadása, a megrendelt tételek kiválasztása, a rendelés lezárása és elküldése részfolyamatokra bontható (egy szinttel lejjebb lévı folyamatok). A folyamatokat célszerő azonosítani a decimális számozási rendszer szerint. Horizontális folyamatokat olyan részletességgel célszerő felbontani, hogy lehetıleg egy szereplıhöz, ill. szereplı csoporthoz legyen köthetı a folyamat elindítása és azon belül a részfolyamatokra bontás ne igényeljen másik szereplı bekapcsolását. Pl. ha termelı tevékenységet folytatunk, a vevıi megrendelés gyártási folyamattal elégíthetı ki és a rendelés visszaigazolása kapacitás vizsgálatot, elıkalkulációt igényel, akkor a rendelés visszaigazolással egyenrangú folyamat legyen a határidı vizsgálat, elıkalkuláció, árképzés, míg egy kereskedı cégnél a készletfedezet vizsgálat, szállítási határidı és ár visszaigazolása részfolyamatként definiálható a rendelés visszaigazoláson belül: Példa kereskedı cég folyamatfelbontására:


42./64


Vevıi rendelések feldolgozása

Vevıi rendelések fogadása

Készletfedezet vizsgálat

Hitelképesség vizsgálat

Vevıi rendelések visszaigazolása

Árképzés

Készlet lefoglalása

Rendelés visszaigazolás elkészítése

Rendelés visszaigazolás elküldése

Példa gyártócég folyamatfelbontására

Vevıi rendelések fogadása

Elıkalkuláció

Mőszaki feltételek vizsgálata

Mőszaki tervezés

Anyagszükséglet számítás

Kapacitásszükséglet számítás

Árképzés, határidık számítása

Rendelés visszaigazolása

2. A folyamatok kapcsolatának meghatározása Az önállóan azonosított, azonos szinten lévı folyamatok között meghatározzuk a kapcsolatokat: egy folyamat lefutása milyen megelızı folyamat(ok) lefutásához kötött, ill. milyen más folyamatokat indít el. Pl. a rendelés visszaigazolás folyamat lefutásának feltétele a vevıi rendelés, a vevıi hitelkeret vizsgálat, árképzés, készletellenırzés folyamatok lefutása és elindítja a készletfoglalás folyamatát, vagy visszautasítja a rendelés felvételét a hitelkeret túllépése miatt.

3. A folyamatok szereplıinek meghatározása Minden egyes folyamatra meghatározzuk, hogy melyik felhasználói csoport (informatikai értelemben a vevı is idetartozik) indítja el az adott folyamatot – ez lesz az adatgazda szervezet, továbbá milyen adatcsoport kapcsolódik a folyamathoz és mi lesz a folyamat kimenete (outputja). Az outputokat három kategóriába sorolhatjuk: • • •

Manuális tevékenység elindítása (pl. raktári kikészítés a rendelés visszaigazolását követıen) - MT Automatikus folyamat indítás (pl. készletfoglalás a rendelés visszaigazolását követıen) - AF Információ szolgáltatás (pl. rendelés visszaigazolás adatai a vevı részére) - IS


43./64


Természetesen - mint a fenti példából is látszik - egy folyamatnak többféle outputja is lehet egyidejüleg. A folyamatok és szereplık kapcsolatát ún. kompetencia mátrixban célszerő ábrázolni: Folyamat / Szereplı Vevıi rendelés feldolgozása Vevıi rendelés feladása Vevıi rendelés visszaigazolása …

Vevı

Raktár

X X

X

Ügyintézı

…

Output AF, IS IS, AF

4. Manuális tevékenységek meghatározása Miután létrehoztuk a folyamat-térképünket a fentiek szerint, felhasználói csoportonként meg tudjuk határozni, hogy milyen manuális tevékenységekre van szükségünk a folyamatok végrehajtásához, ill. mely folyamatokat automatizáljuk. A folyamattervezés és elemzés támogatására számos célszoftver áll rendelkezésünkre, melyek közül az ARIS-t emeljük ki. A célszoftver alkalmazásának elınyei: •

• • •

• •

A folyamatjellemzıket, kapcsolatokat könnyen és gyorsan tudjuk rögzíteni, melynek alapján a folyamatábrák, kompetencia diagramok, kapcsolati ábrák automatikusan elıállíthatók; Az adatokat egy központi adatbázisban tárolja a program, amelyek jogosultsági szintektıl függıen lekérdezhetıek; Elegendı minden folyamat elemet, összetevıt (entitást) csak egyszer definiálni, utána már csak hivatkozni kell rá; A változások nyomonkövetése egyszerő, az alapadat módosításával az összes kapcsolatát aktualizálja a program, vagyis minden hivatkozási helyén az aktuális adat látszik; Az adatok széleskörő lekérdezhetısége, elemzések készítése; Hálózatos mőködési mód, web-es felület.

5. A jelenlegi mőködési rendszer és a folyamat-térkép összehasonlító elemzése A jelenlegi mőködési rendszerben megvizsgáljuk a következıket: • • • • •

•

Felhasználói csoportonként az egyes folyamatok, tevékenységek ahhoz az egységhez vannak-e rendelve, ahogy a modellben meghatároztuk? Ha máshová van jelenleg delegálva a feladat, megvizsgáljuk, hogy miért és változtassunk-e rajta? Ha nincs gazdája a feladatnak, akkor hozzárendeljük a felelıs csoportot. Mely tevékenységek válnak feleslegessé? Tevékenységenként megvizsgáljuk, hogy a jelenlegi mőködési móddal teljesíthetık-e azok a szolgáltatási szintek, termék minıségek, melyekre az üzleti modellt építjük, vagy szükséges-e technológiai korszerősítés? Milyen technológiai, szervezeti, folyamatszervezési változtatásokra van szükség, hogy a folyamatok megfelelı minıségüek legyenek? Vagyis megvizsgáljuk, hogy a folyamatokban milyen teljesítményeket kell leadni és ezeket a teljesítményeket hogyan tudjuk mérni?

Ha a fenti elemzéseket elvégezzük, meg tudjuk határozni a következıket:


44./64


• • • • • • •

Milyen változtatásokat kell végrehajtani a szervezeti struktúrában, hogy az új üzleti modell hatékonyan mőködjön? Milyen feladat átcsoportosítások szükségesek a szervezeti egységek között? Milyen létszámú, milyen felkészültségü munkatársi gárda szükséges? Milyen képzési tervet dolgozzunk ki? Milyen technológiai fejlesztésekre van szükség (pl. vonalkód alapú raktári folyamatok)? Milyen teljesítmény mérési módszereket vezessünk be? Milyen érdekeltségi rendszert dolgozzunk ki?

6.BPR projektterv kidolgozása A fentiek alapján kidolgozzuk a szervezeti-mőködési rendszer átalakítási projekt tervét, meghatározzuk, hogy milyen intézkedéseket kell végrehajtani ahhoz, hogy a cég az új üzleti modell szerint mőködjön. Számos projektvezetési módszertant alkalmazhatunk a BPR projekt végrehajtására, melyek közül a GDPM©3 (Goal Directed Project Management) ajánljuk figyelmükbe. A GDPM© – célorientált projektvezetési módszertan elmélete Norvégiából indult el és ma már kiforrott, sikertörténetekkel alátámasztott gyakorlati példák bizonyítják, hogy egyszerő szabályainak betartásával sikerre vihetünk pl. BPR projekteket is. A GDPM© új perspektívát kínál a többi projekt módszertanhoz képest: a projektek technikai kérdései helyett az ún PSO (People, System, Organization) szemléletmódra helyezi a hangsúlyt. A GDPM© abból indul ki, hogy a projektek többségében az emeberek, a rendszer és a szervezet összhangját kell biztosítani, melyhez speciális vezetési módszerek szükségesek. Nagy hangsúlyt helyez a képzésre, a PSO gondolkodásmód kialakítására. Ugyanakkor alkalmazása egyszerő, néhány őrlap formátummal megoldja a projekt dokumentálását. Ugyanakkor a projekt folyamata átláthatóvá válik és fókuszai jól kézbentarthatóak. A GDPM© szerint használandó őrlapok: • • • • • •

Mérföldkı terv Felelısségi mátrix Tevékenység ütemezés Bizonytalanság elemzés Tevékenység riport Projekt elırehaladás riport (helyzetjelentés)

(További információk a GDPM© – célvezérelt projektmenedzsment módszertanról a www.gdpm.hu honlapon olvashatók.)

3 Bıvebben ld.: Erling S Andersen, Kristoffer V Grude, Tor Haug: GDPM - Célvezérelt projektmenedzsment, BMS Informatikai Kft, 2006.


45./64


6.3.4 Beruházási terv kidolgozása A 6.2.5 pontban részletezett beruházás gazdaságossági kidolgozzuk a beruházási tervben a következıket: • • • • • •

elemzésbıl

kiindulva

A beszerzések ütemtervét A tételekhez rendelt szállítókat Potenciális szállítók körét Szállítói ajánlatok értékeléséhez alkalmazott szempontrendszert skálaértékeket A szállítók kiválasztásának döntési folyamatát A beruházási projektben résztvevıket (projektszervezet).

és

Az értékeléshez felhasználhatunk többféle módszert, melyek közül a KIPA módszert4 emelnénk ki. A KIPA módszer (Kindler József – Papp Ottó szerzık nevébıl származik) szerint a szempontrendszert csoportmunka keretében pl. brain-storming alkalmazásával határozzuk meg, melynek eredményeképpen max. 10-15 szempontba célszerő összevonni (aggregálni) az értékelési tényezıket. A szempontokat érdemes definiálni, hogy mindenki, aki a döntési folyamatban részt vesz, azonos módon értelmezze azokat. A szempontok páros összehasonlításával (Guilford eljárás) felállítjuk a szempontok rangsorát. Ez a módszer azon alapul, hogy 3 tényezı – A, B, C - között felállítunk egy preferencia sorrendet, melynek értelmében A preferált B-vel szemben és B preferált C-vel szemben, akkor – ha következetesek vagyunk – A-t preferáljuk C-vel szemben is. A csoporttagok egyéni preferencia mátrixait meghatározott konzisztencia szint felett összesítjük és szignifikancia vizsgálat alapján döntjük el, hogy a csoport véleménye nem a véletlen mőve. A KIPA módszer alkalmazásának folyamatát a következı oldali ábra szemlélteti. Néhány gyakorlati tanács a KIPA módszer alkalmazásához: A szempontrendszert brain storming módszerrel alakítsuk ki. A szakértıi csoport: • Legyen reprezentatív • A csoport tagjai függetlenek • Megfelelı nagyságú (7-10 fı) Nagyszámú értékelési tényezı aggregálása során: • Egyik tényezı sem kerülhet domináns helyzetbe az aggregálás következtében • Az aggregált tényezık függıségi szempontból hasonló irányúak legyenek, mint az eredeti aggregálandó tényezık • Elsısorban a kis preferencia súlyú tényezıket aggregáljuk • Aggregált tényezıket részletesen specifikáljuk • Az értékelési tényezıket tartalmilag definiáljuk.

4

A módszertan részletes leírását ld. „Dr. Kindler József – Dr. Papp Ottó: Komplex rendszerek vizsgálata” Mőszaki Könyvkiadó, 1997.


46./64


Probléma megfogalmazása, célok meghatározása

Szakemberek kiválasztása és bevonása

Értékelési tényezık meghatározása

Elegendı az információ?

nem

igen Páros összehasonlítás Egyéni preferencia mátrixok szignifikancia vizsgálata

Vizsgálati program elkészítése, kérdıívek

igen

nem

Megfelelıek az eredmények?

nem Szignifikancia vizsgálat eredménye elfogadható?

Aggregált preferenciamátrix összeállítása. Egyetértési együttható kiszámítása

igen

nem Egyéni értékelések figyelmen kívül hagyása

Szempontokhoz skálaértékek rendelése

Ajánlatok minısítése a szempontrendszer alapján

KIPA mátrix összeállítása

p – q szintek megállapítása

Ajánlatok preferencia sorrendjének megállapítása

Javaslatok

Döntés a szállítóról


47./64


6.3.5 Pénzügyi terv kidolgozása Új eBusiness üzleti modell alapján egy cég felépítése jelentıs befektetési költséggel jár, ezért a pénzügyi tervben a teljes projekt finanszírozási tervét dolgozzuk ki. A pénzügyi tervben meghatározzuk, hogy milyen forrásokat vonjunk be a projekt finanszírozásába, amely lehet: saját tıke, külsı befektetés, hitel, pályázati támogatás, stb. A finanszírozási tervben gondoljuk át azt is, hogy a fedezeti pont eléréséig a mőködési többletköltségeket is finanszírozni kell és ezt hogyan biztosítjuk!

6.3.6 Kockázatelemzés A 6.3.2 ponton belül a „7. Informatikai biztonság kérdése” fejezetben ismertettük a gyakorlati kockázatmenedzsment módszerét, mellyel az eBusiness alapját képezı ICT rendszer üzemeltetésének biztonságát megfelelı szinten tudjuk tartani. Az ICT rendszer biztonságán túl azonban további kockázati tényezıket is át kell gondolnunk, mielıtt belevágunk a projekt kivitelezésébe. Tapasztalataink alapján a következı fıbb kockázati tényezıket emeljük ki: •

A piac reakciója A piac reagálása az eBusiness-re ma még nehezen kiszámítható. Bejön-e a várt forgalomnövekedés, ha igen mennyi idı alatt? Valóban vevı megtartó tényezı, ha gyorsabb és kényelmesebb a kiszolgálás? Megtaláltuk-e a közös érdekeltségi pontokat? A vevıink, üzleti partnereink mennyire fogadják be az új technológiát? Mindez rendkívül mély piac ismeretet és nagyfokú szervezıkészséget igényel – megvan erre a megfelelı személy, ill. csapat?

•

Az üzleti folyamatok automatizálása Az eBusiness folyamatok sokkal nagyobb mértékő automatizáltságot és ebbıl következıen magasabb fokú szervezettséget igényelnek, mint a hagyományos üzleti folyamatok. Erre vonatkozóan még nincsenek meg a tapasztalatok, hogyan lehet egy cég mőködését, kultúráját rövid idı alatt átalakítani és mőködtetni az elektronikus folyamatokhoz illeszkedıen. Nehéz megjósolni, mennyi idıt és mekkora költséget igényel egy ilyen átalakítási folyamat? Mekkora bevétel kiesést okoz, ha a folyamatok akadozva mőködnek, mennyivel nı az átfutási idı?

•

A front-office és back-office folyamatok integrálása A B2B informatikai megoldás akkor hozhatja meg az elvárt eredményt, ha a belsı vállalati folyamatok integrált rendszerben kapcsolódnak a külsı folyamatokhoz (pl. kereskedelem, beszerzés, ügyfélszolgálat, marketing, banki folyamatok, stb.) A külsı ún. CRM folyamatok (customer relationship management) magas szinvonalú végzésére van szükség ahhoz, hogy vevıkörünket megtartsuk, ill. a tervezett módon bıvíteni tudjuk. Hány vevıt veszíthetünk, ha a két rendszer nem mőködik együtt gördülékenyen, milyen többletköltséget és idıveszteséget okoz az integráció hiányának manuális áthidalása?

•

A munkatársi csapat Az eBusiness-ben a folyamatok automatizálása révén a munkavégzésben áttevıdik a hangsúly a kivételek kezelésére, a problémák megoldására, a folyamatos elemzésekre, intézkedési tervek kidolgozására és végrehajtására, a tervezésre, az elırejelzésre, az ügyfélkapcsolatok ápolására. Milyen képzéseket,


48./64


esetleges személycseréket kell végrehajtani, hogy a csapat megfelelı felkészültségő legyen? •

Lépéstartás a változásokkal A változásokkal való rugalmas lépéstartás, az új kihívásokra való gyors reagálás azon túl, hogy idıben felismerjük ezeket, megkövetelik az alkalmazási rendszer gyors változtatását, kiegészítését, amelynek úgy kell eleget tenni, hogy közben a folyamatos üzem ne álljon le. Milyen károkat okoz, ha nem tudunk megfelelni egy új típusú vevıcsoport kiszolgálására, vagy egy új termék értékesítésére az informatikai rendszer merevsége miatt?

6.3.7 A projekt stratégiai tervének jóváhagyása A fentiek szerint kidolgozott marketingterv, ICT-rendszer fejlesztési/beruházási projektterv, BPR projektterv, beruházási terv, pénzügyi terv és kockázatelemzés kellı alapot szolgáltat ahhoz, hogy megalapozottan döntsünk a projekt elindításáról. A döntési folyamat általában többszintő, mivel komplex, stratégiai jellegő döntést kell meghozni és egyben az erıforrásokat biztosítani a projekt végrehajtásához.

6.4

A projektek végrehajtása A végrehajtási fázisban öt projekt összehangolását kell elvégeznünk: • • • • •

A marketingterv végrehajtását Az informatikai-kommunikációs rendszerfejlesztési és bevezetési projektet Az eszközbeszerzéseket és telepítéseket A folyamat optimalizálási projektet és a Finanszírozási feladatokat.

Mindegyik projekt felbontható elıkészítési és kivitelési fázisra. 6.4.1 Elıkészítési fázis A projektek elıkészítési fázisában a következıket kell elvégezni: • • • • • •

A projektcélok megfogalmazása, a projekttermékek definiálása; A projektszervezet felállítása, a projekttagok kiválasztása, a megbízások kiadása; A projekt feladat- és ütemtervének pontosítása, mérföldkı események határidejének véglegesítése; A mérföldkövekhez kapcsolódó projekttermékek és minısítési kritériumok definiálása; A projekt mőködéséhez szükséges eszköz és tárgyi feltételek rendelkezésre bocsátása; Projektalapító okirat (amely leírja a projekt mőködési feltételeit, szabályait) elıkészítése és jóváhagyása.

6.4.2 Kivitelezési fázis A projekt kivitelezési fázisa a projektindító értekezlettel veszi kezdetét. Az alkalmazott projektvezetési módszertan szerint (pl. GDPM©) el kell végezni határidıre a tervezett feladatokat, melynek eredményeképpen: • •

feláll az új informatikai rendszer, a felhasználók ki vannak képezve az új rendszer használatára,


49./64


• • •

szabályozva vannak a folyamatok, kialakítottuk az új érdekeltségi rendszert, vevıink, partnereink kellı számban elkötelezték magukat az új rendszer fogadására.

A kivitelezési fázis fı szakaszai az informatikai rendszerbevezetési projektben: 1. Felmérés, Követelményjegyzék elkészítése A projekt egy részletesebb helyszíni felméréssel kezdıdik, melynek során a funkcionális követelmények pontos specifikálására van szükség. A felmérésnek ki kell terjednie az üzleti/szolgáltatási folyamatok és a meglévı informatikai rendszerek, nyilvántartások olyan szintő felmérésére, amelynek alapján: • • •

a mőködési folyamatok pontosan definiálhatóak; a rendszerparaméterek beállíthatóak; az adatmigrációs és egyedi fejlesztési feladatok specifikálhatóak.

A felmérés eredményeként elkészítjük a Követelményjegyzéket, amelyben részletesen definiáljuk a mőködési folyamatokat, modulonként a funkcionális elvárásokat, és amely dokumentáció – a Megrendelı jóváhagyása után – az átadásátvétel alapját fogja képezni. A Követelményjegyzék készítése során definiáljuk az egyedi fejlesztési igényeket is, amelyek a szoftverben meglévı programok módosítását, ill. új programok beépítését igénylik.

2. Bevezetési tanácsadás Az új információs rendszernek illeszkednie kell az ügyviteli folyamatokhoz, mert csak így várható el, hogy hatékonyabbá tegye a mőködést. Az üzleti folyamatok és az információs rendszer harmóniájának biztosítása érdekében célszerő bevezetési tanácsadást igénybe venni. A bevezetési tanácsadás általában a folyamatok optimális kialakításához, az új szoftverben a rendszerparaméterek beállításához és a felhasználói tesztelés támogatásához nyújtott szakértıi támogatást, valamint a projektvezetést és a szükséges dokumentációk elkészítését tartalmazza.

3. Oktatás A felhasználók kiképzése az új rendszer használatára kulcsfontosságú a rendszer minısége szempontjából. Bármilyen jó és hibamentes alkalmazási rendszert választunk, az általa szolgáltatott információk minısége, tartalma nagyrészt attól függ, hogy a felhasználók rendeltetésszerően tudják azt használni, ill. képesek kihasználni a rendszer adta lehetıségeket. A felhasználók oktatásához célszerő oktatási segédleteket kidolgozni, amelyek segítségével gyakorolni tudják a rendszer használatát. Célszerő ebben minden funkció használatán végigmenni és mintapéldákat bemutatni lehetıleg minden olyan esetre, ami elıfordulhat a gyakorlatban. Mivel az oktatási segédletek cég specifikus példákat, feladatokat tartalmaznak, nem egyszerő a kidolgozásuk, ezért célszerő a szakterületek képviselıit is a munkába bevonni. Az oktatásnak minden felhasználói szintre és területre ki kell terjednie, így az oktatást több lépcsıben, felhasználói csoportonként szokás elvégezni. Elsı lépcsıben a projektszervezet tagjait és a bevont kulcsfelhasználókat képezik ki, melynek alapján képesek lesznek az átadás-átvételi tesztfolyamat végrehajtására. Ezt követıen kerül sor az összes felhasználó kiképzésére, melyben a projektszervezet tagjai is


50./64


közremőködhetnek. A rendszer éles indulása után néhány hónappal célszerő egy olyan szintő oktatást tartani a kulcsfelhasználók részére, amelynek során elsajátíthatják a rendszer adta lehetıségek kihasználásának módját is, melyhez a rendszerösszefüggések átfogó ismerete szükséges.

4. Egyedi szoftverfejlesztés Egyedi fejlesztés kétféle módon történhet: • •

a projekt célja egyedi szoftverfejlesztés, vagy a vásárolt szoftvercsomag programjain lényeges változtatás, ill. új programokkal való kiegészítése szükséges.

Utóbbi esetben a Követelményjegyzék készítése során szokott kiderülni, hogy ilyen igény felmerül. Ezeket a fejlesztési feladatokat részletesen specifikálni szükséges. Az információs rendszer kivitelezését – amennyiben egyedi szoftverfejlesztésrıl van szó - meg kell, hogy elızze egy rendszertervezési fázis, amelynek eredményeképpen elkészül a logikai rendszerterv. A logikai rendszerterv fıbb fejezetei: • • • • • • • • • •

A rendszerfunkciók logikai csoportosítása A funkciókat megvalósító folyamatok definiálása Input specifikáció Program specifikáció Output specifikáció Adatbázis adatmodell Ellenırzések Rendszerüzenetek Jogosultsági rendszer Architektúra-terv

A logikai rendszerterv, vagy egyszerőbb esetben a programspecifikáció Megrendelı általi elfogadását követıen kerülhet sor a programozási munkákra. A fejlesztés eredményeképpen elıállt programok többszintő tesztelését kell elvégezni elsı lépcsıben a fejlesztı team-en belül. Csak a fejlesztık által kitesztelt és jónak minısített megoldást szabad a felhasználói tesztelésekre átadni.

5. Felhasználói tesztelés Az online rendszerek tesztelése nagy körültekintést igényel, hiszen ha üzemszerő körülmények között végezzük, ki kell tennünk az alkalmazást az Internetre. Persze megoldható, hogy a hozzáférés ne legyen publikus ebben a szakaszban. Ennek a feladatnak a jelentısége sokkal nagyobb, mint a hagyományos parciális szoftverek esetében, hiszen a rendszerintegritás azt eredményezi, hogy sok folyamat nem a felhasználói felületen, hanem a háttérben zajlik. Így a megfelelı teszteléshez az ügyviteli rendszerben automatizált folyamatok alapos ismerete is szükséges. Amennyiben a tesztelés nem elég alapos, akkor késıbb kiderített hibák esetén a paraméter beállítások- és a szükséges program módosítások elvégzése után nagyobb idıszak ismételt rögzítése és feldolgozása válhat szükségessé. Tapasztalataink szerint egy online rendszer teljes kitesztelése legalább háromszor több idıt és erıforrást igényel, mint pl. egy „hagyományos” ERP rendszeré.


51./64


A tesztelési folyamat végrehajtása az egyes modulok átadás-átvételi eljárását is jelenti, amelyet a cég adataira épülı tesztfeladatok, tesztforgatókönyvek alapján kell elvégezni. Erre egy külön tesztadatbázist célszerő létrehozni. A tesztfeladatok egymásra épülnek a rendszerösszefüggések alapján, és számba vesznek minden olyan lehetıséget, ami elıre láthatólag a rendszer üzemeltetése során elıfordulhat. A tesztelési feladatok kidolgozása a Felhasználókkal közös munkában történik. A tesztelés során felmerült hibák kijavítását követıen az adott tesztelési feladatokat ismételten végre kell hajtani. A tesztelési folyamat több lépcsıben kerül végrehajtásra a projekt során. Elsı lépcsıben a programok funkcionális tesztje, helyes mőködésének ellenırzése történik a Felhasználók által, míg a második lépcsıben a rendszerösszefüggések, folyamatok tesztelését végzik el. A tesztlapok aláírásával a Felhasználók elismerik, hogy a programok a Követelményjegyzék szerint hibamentesen mőködnek. Ezt a teszteljárást célszerő csak tesztadatokkal végrehajtani, mivel így könnyebben megállapíthatók a hibaokok. Ha teljes, áttöltött adatbázison végezzük a tesztelést, sokkal több erıforrás és idı szükséges a hibaokok megállapításához, mert lehetséges, hogy egy korábban bekerült hibás adat okozza a hibás eredményt, nem pedig programhiba.

6. Bevezetési dokumentációk elkészítése A bevezetési dokumentációk tartalmazzák a bevezetni kívánt rendszer testre szabott, a cég üzleti folyamatai szerint beparaméterezett verziójának leírását, amelynek alapján a különbözı szintő felhasználók a szükséges mértékben tájékozódhatnak, és annak alapján a munkájukat el tudják végezni. Ez érvényes a rendszergazdák számára szükséges részletes ismeretektıl a felhasználói kézikönyvekig, oktatási segédletekig. A felhasználói kézikönyveket célszerő online help formájában az alkalmazásba is beépíteni, hogy a felhasználók gombnyomásra megkaphassák a szükséges információt.

7. Adatmigráció A sikeres átadás-átvételi teszteljárást követıen kerül sor a korábbi adatbázisok adatainak áttöltésére az új alkalmazási rendszer adatbázisába. Az adatok áttöltéséhez egyedi programok megírása szükséges, amelyek nemcsak az adatok átkonvertálását végzik el, hanem beépíthetık különbözı ellenırzések is, mellyel az adatok kijavítása megkönnyíthetı. A migrációs program automatikusan kiegészítheti az adatokat a hiányzó – az új rendszer által megkövetelt - adatokkal, ha ehhez a megfelelı algoritmusok rendelkezésre állnak. Az adatmigrációt követıen a tesztelési folyamatot megismételjük az áttöltött adatokkal. Ha a tesztadatokkal jól mőködtek a programok és hibát észlelünk, nagy a valószínősége, hogy a hibát nem a program, hanem a bekerült hibás adat okozza.

6.5

A rendszer átadás-átvétele Ebben a fejezetben elsısorban az ICT rendszer átadás-átvételére fókuszálunk, amely az új eBusiness rendszer alapját fogja képezni. Nem informatikai technológiai szempontból közelítjük meg ezt a kérdést, hanem a minıség oldaláról, mivel az online üzleti modell legnagyobb kockázata az ICT rendszer minıségében rejlik.


52./64


Az ICT rendszer minısége összetett fogalom. Általában beleértjük a következıket: • • •

•

•

• •

Funkcionális megfelelıség – a programok minden – a Követelményjegyzékben definiált – funkciót hiánytalanul lefednek; A programok és adatbázis hibamentessége – a programok az elvárt tartalmú és formátumú outputokat hozzák létre; Felhasználóbarát felület – az alkalmazásba mindenhol egységesen használható funkciók vannak beépítve, a képernyık jól áttekinthetıek, felesleges mezıket nem tartalmaznak, a feliratok, üzenetek könnyen értelmezhetıek, kódok helyett szöveges megjelenítés, ahol lehet az adatot csak ki kell választani, gyors keresések, az adatellenırzések az adatbevitellel párhuzamosan menjenek végbe, jól értelmezhetı hibaüzenetek, beépített helpek. Folyamatszemlélet – a logikailag egymást követı tevékenységek lehetıleg automatikusan, minél kevesebb adatbeviteli munkával valósuljanak meg. Pl. ajánlatból rendelés generálása csak a módosult adatok változtatásával egyetlen jóváhagyási gomb megnyomásával történjen. A többszörös adatbevitel egyben hibaforrás is szokott lenni. Átláthatóság és ellenırízhetıség – legyen nyomonkövethetı a rendszerben, hogy a származtatott adatok hogyan jöttek létre (ld. adatlefúrási technika) és legyenek ellenırzési lehetıségek beépítve a folyamatösszefüggések alapján, amellyel a felhasználók meggyızıdhetnek az adatok helyességérıl. Sebesség elvárásoknak való megfelelés – a tervezett üzemi terhelés mellett. Biztonsági követelményeknek való megfelelés – veszélyhelyzetek tesztelése.


53./64


7

EBUSINESS CONTROLLING

7.1

A controlling rendszer felépítése Az online rendszerben jóval több adat áll rendelkezésünkre „real time” (azonnal), mint a „hagyományos” vállalatirányítási rendszerekben. Felépíthetünk ezekre olyan mutatószámrendszert, ill. riportokat, amelyek segítségével a vezetık képesek megítélni, hogy hol kell beavatkozni a folyamatokba, láthatóak, hogy a teljesítmények hol térnek el a tervezett mértéktıl. Az online rendszer adatbázisa alkalmas az elırejelzésre, tendenciák kimutatására, esetleg hatásvizsgálatok elvégzésére is. A controlling rendszerbıl tájékozódhatnak a vezetık, hogy mikor térül meg a beruházás, jelentkezik-e az elvárt eredmény és haszon, amit terveztünk, az egyes folyamatok milyen mértékben járultak ehhez hozzá. A controlling rendszer felépítésének lépcsıit az alábbi ábra szemlélteti:

Források

Vagyonváltozás

Eszközök

Cash Flow Befizetések

Fizetıképesség

Kifizetések

Fedezeti hányad Költségek

Eredményesség

Teljesítmények

Keret / Budget

Költségek

Költséggazdálkodás

Erıforrások

Belsı átterhelések

A controlling rendszerben az elsı szint a költséggazdálkodás megvalósítása. Ennek feltétele a költséghelyi struktúra felépítése és a költséghelyek költségkereteinek tervezése és számonkérése. A költséghelyek meghatározásának általános szempontjai: • • • • • • •

Fizikailag/logikailag elhatárolt legyen, amire költségeket szeretnénk tervezni, ill. kimutatni; Elhatárolt felelısséggel rendelkezzen; Az legyen felelıs, aki befolyásolni is tudja a gazdálkodást; Pontosan meghatározottak legyenek a folyamatok, amelyekben a költséghelyek teljesítményeikkel résztvesznek; A tényköltségek legyenek mérhetıek és meghatározhatóak; Egységes elszámolási technikákat lehessen alkalmazni; A költséghelyen kell minden általa okozott költséget kimutatni;


54./64


•

Egyszerő és gazdaságos legyen a költséghely alkalmazása (ne kerüljön többe a költségek kimutatása, mint a költséghelyen felmerülı költség nagysága).

A második szint az eredményesség meghatározása. Az eredményesség a termékek, szolgáltatások elıállításában felhasznált erıforrások (költséghelyek) és az általuk leadott teljesítmények alapján ítélhetı meg. A teljesítményekhez egységköltségek rendelhetık, melyek alapján a ráfordítások kalkulálhatók. Az árbevétel és az elıállítási költségek különbségeként meghatározzuk költségviselınként a fajlagos fedezeteket, melyeket össze tudunk hasonlítani az elvárt értékekkel. A fedezeteket többféle vetületben kell kimutatnunk és vizsgálnunk ahhoz, hogy az eredményességet meghatározzuk. Például vizsgálhatjuk a fedezetek alakulását: termékenként, szolgáltatásonként, termékcsoportonként, szolgáltatási áganként, vevınként, vevıcsoportonként, értékesítési csatornánként, területenként, stb, ahogy a piacunk mőködik. Ezen a szinten valósíthatjuk meg a folyamatköltség számítást (activity based costing), ami az online folyamatoknál különösen indokolt lehet. Az elvégzett tevékenységek idıadatai az online információs rendszerbıl általában automatikusan rendelkezésre állnak, melynek alapján a folyamatköltség számítás könnyebben elvégezhetı. A controlling harmadik szintje a fizetıképesség, likviditás kézbentartása. A kibocsátott számlák, a beérkezett és a várhatóan beérkezı számlák pénzügyi teljesítésének elırejelzésével fel tudunk készülni a következı idıszak pénzforgalmára. Ha szükséges átütemezzük a kifizetéseket, vagy hitelt veszünk fel, a pénzfelesleget pedig befektetjük, lekötjük kamatozással. Tudnunk kell, hogy az egyes vevıinknél milyen fizetési fegyelmet lehet elérni, milyen hitelkereteket érdemes a rendelkezésükre bocsátani, milyen intézkedésekkel lehet a fizetıkészséget javítani. A negyedik szint a tulajdonosok számára a legfontosabb: a vállalkozásba fektetett vagyon – ami az erıforrásokban realizálódik – milyen módon mőködik, hoz-e megfelelı hasznot a számukra? Az online üzletben a vállalkozás vagyona sokkal inkább az immateriális javakban keresendı. Az informatikai rendszer értéke, melynek kb. a felét a szoftverek teszik ki, továbbá az összehangolt munkát végzı dolgozói csapat, az adatbázisok, tudásbázisok, a piaci hírnév, a vevık, ügyfelek bizalma, a márkanév elismertsége – csupa olyan tényezı, amely a cég vagyonát jelentik, ugyanakkor nem kezelhetık hagyományos erıforrásokként. Ezért a vagyonváltozás kimutatása a cégérték változásán keresztül valósítható meg, túl a fıkönyvi eszközváltozáson. Egy jól felépített on-line (információs) rendszerben a controlling információk szolgáltatása, a jelentések, riportok, beszámolók elıállítása automatizálható. Így a vezetıknek, controllereknek nem az „adatvadászattal” kell tölteniük az idejüket, hanem koncentrálhatnak a jelentések tartalmának elemzésére, értékelésére, döntéseik megalapozására.

7.2

Mutatószám rendszer a logisztikában A hagyományos kereskedelemhez képest gyökeres változást hozott a nagy áruházláncok megjelenése, a kiskereskedelem visszaszorulása a magyar piacon. A multinacionális cégek kemény árversenyre és magas minıségő szolgáltatásra tudják kényszeríteni a szállítókat amellett, hogy hosszú fizetési határidıket, a szállítókra nézve kedvezıtlen fizetési feltételeket írnak elı. Aki ezeknek az elvárásoknak nem tud megfelelni, egyszerően kilistázzák. Az alábbiakban röviden összefoglaljuk, hogy ezek az áruházláncok milyen szempontok szerint mérik a szállítói logisztikai teljesítményeket, amelyre jó, ha a beszállító is az információs rendszerével fel tud készülni. Vitás esetekben így adatokkal alátámasztott


55./64


érveket tud felhozni, míg ha saját információi nincsenek, kénytelen elfogadni a megrendelı (diktált) adatait. Kiszolgálási szint A szállítótól megrendelt és általa beszállított árumennyiségek és értékek adott idıszak alatt a megállapodott ütemezés szerint (bruttó mennyiség és érték). Ez korrigálható a késve érkezett megrendelésekkel (nettó mennyiség és érték). Szállítási pontosság A multicégek általában ún. idıablakokat határoznak meg a szállítmányok fogadására. Számukra ez azért elınyös, mert így ütemezetten tudják végezni az áruátvételi folyamatokat és nem lesznek torlódások a raktár melletti parkolóban sem, ami egyben kedvezı hatású a környezetre is. Ezért mérik a szállítóknál az idıablakon belüli érkezéseket, a korábbi érkezéseket és várakozási idıt, ill. a késve érkezéseket és a késés mértékét. Kérdés persze, hogy a magyar út- és közlekedési viszonyok között hogyan lehet ezt betartani. Ezért célszerő reális (betartható) mérető idıablakokban megegyezni. Komissiózási pontosság Ezalatt az áru csomagolását kell érteni, mennyire pontosan készítették össze az árut a megrendelés szerint, milyen minıségő a raklapképzés, mennyi utómunkára van esetleg szükség az eladótérbe történı kirakodáskor. Dokumentáció pontossága A szállítólevél, számla, származási bizonyítványok, minıségi tanusítványok, stb. mennyire felelnek meg a tényadatoknak, ill. elıírásoknak, szerepel-e rajtuk minden szükséges adat (pl. a megrendelı cikkazonosítója) mennyi reklamációs ügyintézést kell végezni a nem megfelelıség miatt. Végigkövethetı-e a dokumentumok alapján az áru útja a gyártónál felhasznált anyagbeszerzésektıl, a készterméken át az ellátási lánc teljes keresztmetszetében? Érvényesíthetınek kell lennie a termék visszahívásoknak, melynek alapja a megfelelı dokumentáció. Készletpontosság A beszállított és átvett árumennyiség mennyire egyezik meg a megrendelt és visszaigazolt mennyiséggel? Élelmiszerek esetében fontos a szavatossági idı figyelése, a lejárati idın belül, meghatározott idıtartammal korábbi idıpontban kell szállítani. Az anyagmozgatási folyamatok automatizálása érdekében elıírják az EANkódot (vonalkódot, néhány éven belül az RFID – radio frequency identification – azonosítót is), melyet megfelelı minıségben az árun fel kell tüntetni. Ennek alapján az áru azonosítása, betárolása, készletezése, ki- és áttárolása, a vevı általi megvásárlása és kifizetése hibamentesen végezhetı és utólag is visszakövethetı. Rendelés visszaigazolás A szállító a rendelés visszaigazolásakor elırejelezheti a problémákat, így a fogadó oldalon idıben intézkedni tudnak, amellyel felesleges költségek takaríthatók meg. Pl. elakad egy szállítmány hóakadályok miatt és késve fognak teljesíteni, akkor az idıablakokat át lehet ütemezni. Természetesen nemcsak a szállítói oldalt kell mérni és értékelni, hanem a kereskedıi oldalt is az alábbiak szerint: Készletszint biztosítása A szállítók számára fontos, hogy a kereskedı meghatározott készletszintet tartson a termékeibıl a polcokon. Ne fogyjon ki teljesen a készlet a belistázott termékekbıl. Ezért a mindenkori készletszintet folyamatosan figyelni kell és adott készletszintnél fel kell tölteni az eladótérben lévı készlethelyet. A feltöltéshez a háttértárolóban mindig elegendı készlettel kell rendelkezni.


56./64


Rendelések pontossága A készletszintekkel, akciókkal, az elvárt áruforgási sebességgel összhangban kell a kereskedınek a rendeléseket feladni a szállító felé. A rendelési mennyiséget réteg/raklap/autó szerint határozzák meg a komissiózás megkönnyítése érdekében, ill. megadják a cikkek EAN kódját is az egyértelmő azonosítás érdekében. Itt mérhetı az idıbeniség, a mennyiség és az adatok pontossága. Elırejelzés pontossága A szállítóknak idıben fel kell készülniük elegendı készletmennyiséggel pl. az akciókra, amelyeket a kereskedı tervez, ezért nem mindegy, hogy mikor értesül ezekrıl a tervekrıl. Fordulási idı A szállításszervezésnél fontos adat a jármővekrıl az áru lepakolására fordítandó idı, ami a bejárási útvonal szerint fordított sorrendben történı felrakodástól függ. Raklapcsere Szintén a szállításszervezés szempontjából fontos adat a raklapcserére, göngyölegek kezelésére és elszámolására fordítandó idı. A polc elérhetısége A kiskereskedelemben meghatározó szempont az áru elhelyezése, hiszen nem mindegy, hogy szemmagasságban, vagy afölött, ill. alatt található az áru, esetleg nehezen hozzáférhetı helyen tárolják. Továbbá fontos a készlet mennyisége és a polc feltöltöttségi szintje, ill. az utántöltési folyamat minısége, amely az áruház rendelési pontosságának, a készletnyilvántartás pontosságának, a készletgazdálkodási politikájának a függvénye. Miután mindkét fél értékeli a partnere teljesítményét, célszerő azt rendszeres idıközönként egyeztetni egymással, a mutatószámokat közösen kiértékelni és a javító intézkedésekben megállapodni. Mindez akkor mőködik hatékonyan, ha a felek információs rendszerei bizonyos szintig összhangban vannak egymással. Minimális követelmény, hogy egységes termék törzsadatbázissal kell rendelkeznie mindkét félnek, amelyben a termékek vonalkódja, logisztikai adatai (fizikai méretek, súly, lejárati idı, tárolási hımérséklet, csomagolási egység, raklap mennyiség, stb.), szállítási átfutási idı, új termékek rendelhetıségének dátuma, megszőnt termékek forgalomból való kivonásának dátuma, az árak és kedvezmények szinkronban vannak egymással. Megkönnyíti az adatbázisok szinkronizálását, ha közvetlen kommunikációs kapcsolat van az informatikai rendszerek között, pl. EDI (eletronic data interchange), TCP/IP kapcsolat, internet, stb. Korszerő kommunikációs rendszerrel a terméktörzs szinkronizáláson túl további funkciók is automatizálhatók az IT rendszerek integrálásával. Pl. a megrendelések feladása, visszaigazolása, problémák elırejelzése, szállítói idıablak egyeztetése, akciók elırejelzése, készletek lekérdezése, számlázás online történik úgy, hogy a fogadó rendszerben az adatok automatikusan jelennek meg, egyben elindítva a szükséges cselekvéssort a másik fél felhasználóinál. Ezzel a megoldással kiküszöböljük a duplikált adatrögzítéseket, az ebbıl eredı hibák kijavítását, az adategyeztetések és hibaok keresések költségét és jelentısen felgyorsítjuk a folyamatokat.

7.3

A tervezési folyamat átalakítása Az eBusiness-ben a folyamatok felgyorsulása miatt már nehezen alkalmazhatjuk a hagyományos tervezési módszereket, technikákat. Nem lehet fenntartani hatalmas


57./64


apparátusokat, amelyek az éves terveket lebontják havi, heti tervekre, mert mire ez megtörténik, esetleg a tényidı már túl is haladta ezeket. Mindez nem vonatkozik a stratégiai és éves budget tervezésre, ott a szokásos tervezési módszereket, terv-lebontásos struktúrát alkalmazhatjuk és az éves sarokszámokat kitőzhetjük. Az operatív tervezési folyamatot azonban dinamikussá kell tenni, sokkal inkább a közeljövıben várhatóra kell a hangsúlyt helyezni. Meg kell valósítani a gördülı tervezés módszerét, amit a termelésirányítási rendszereknél már évtizedek óta használnak. A mutatószám rendszert úgy kell felépítenünk, hogy a jó átláthatóság, könnyő mérhetıség mellett, fejezze ki a folyamatok dinamikáját is, amely a tevékenységek intenzitására utal. Pl. a rendelések száma, értéke és gyakorisága, idıbeli eloszlása alapján meg tudjuk ítélni, hogy az üzletünk szempontjából egy adott vevı mennyire fontos és a vele foglalkozó értékesítı munkatárs milyen színvonalú munkát végez, ill. hova szeretnénk eljutni a jövıben. A gördülı tervezés során folyamatosan (pl. hetente, vagy havonta), mindig egy elıre jól belátható idıszakot (pl. 3 hónap) tervezünk meg részleteiben úgy, hogy az elızı tervet a tényadatokkal korrigáljuk (visszacsatolás) és a következı idıszakot újratervezzük.

1.

2.

3.

4.

5.

Terv 1

6.

7.

T – idı (hónap)

Tény visszacsatolás

Terv 2

Tény visszacsatolás

Terv 3

A gördülı tervezés folyamata

Online üzletvitel esetén a dinamikus tervezés másik markáns jellemzıje, hogy a tervezési folyamatba a külsı partnereinket is bevonjuk. Vagyis nemcsak az operatív folyamataink szereplıivé tesszük ıket, hanem meg kell valósítanunk az ún. „Collaborative Planning & Forecasting”-ot (csoportos tervezés és elırejelzés módszere) is, mert csak így tudjuk biztosítani, hogy reális célkitőzésekhez viszonyítsuk a tényleges teljesítményeket. Ennél a módszernél nem annyira a tervszámok részletes lebontása dominál, hanem inkább jól megválasztott aggregált számokkal dolgozunk és a tendenciák minél pontosabb felismerésére törekszünk. Tapasztalatunk szerint így egyre pontosabb terveket vagyunk képesek kidolgozni, viszonylag kevesebb munkaráfordítással. Az operatív tervezés ezáltal már nem egy


58./64


szervezeti egység feladata, hanem mindazoké, akik közel vannak a partnerekhez, piaci szereplıkhöz és velük egyeztetni tudják az elképzeléseket. Vagyis decentralizálnunk kell a tervezési folyamatot is, mert a releváns információval elsısorban a „végeken” dolgozók rendelkeznek. Vegyük egy online nagykereskedı cég példáját, ahol a vevık három nagy kategóriába sorolhatók: áruházláncok, bolthálózatok, kiskereskedı boltok, míg a beszállítók közvetlenül a gyártók. A vevık száma többezer, a gyártók száma százas nagyságrendő. A forgalmazott termékféleségek száma igen nagy, százezres nagyságrendő. A vevıkkel való kapcsolattartásra területi képviselıi hálózatot alakítottak ki (TEK-ek), a kiemelt partnerekkel key account managerek (KAM) foglalkoznak, míg az áruházakban helyszíni polcszervizesek (PSZ) mőködnek. A szállítókkal (gyártókkal) szintén kijelölt képviselık (GYK) tartják a napi kapcsolatot. Elsı lépésként a vevıket kategorizálták, a forgalom nagysága alapján a három kategóriát – áruházlánc, bolthálózat, kiskereskedık - tovább finomították és ennek eredményeképpen 50 kiemelt vevıt, ill. vevı csoportot határoztak meg, amelyre a tervezést végzik. A százezres cikkféleségre szintén nem lehet tervezni ezért a forgalom tervezését mindössze 15 cikkcsoportra szőkítették minden vevıcsoporton belül. A bevételi tervadatok tételszáma egy hetes idıperiódusokat alapul véve így is 50*15*52=39.000 db/év. A múltbeli adatok alakulásával pontosan ismerik a cikkcsoportok szezonalitását, melynek alapján a program le tudja generálni a következı idıszak tervét. A TEK-ek, KAM-ok ezeket egyeztetni tudják az ügyfeleikkel és megbeszélhetik velük, hogy milyen körülmények befolyásolhatják ezeket a tervszámokat és hol kellene korrigálni. Milyen marketing akciókat terveznek, amelynek hatására nagyobb forgalmat prognosztizálnak. A beszállító gyártókkal éves szerzıdésekben állapodnak meg a szállítási kondíciókról, árakról, kedvezményekrıl. A gyártók beleszólnak a végfelhasználói (fogyasztói) árakba, adott ár fölé a kiskereskedı nem mehet. A gyártók is kezdeményezhetnek akciókat, idıszakos dömpingárakat, a kereskedık mellett. Jól látható, hogy az értékesítési lánc a gyártóknál kezdıdik és a kiskereskedıknél ér véget, akiknél a fogyasztó megvásárolja a terméket. A fogyasztói szokásokról legtöbb információval a kiskereskedık rendelkeznek, így ık tudják a legjobban megmondani mikor, milyen akciókkal lehet a termékvásárlást ösztönözni, a szezonális vásárlásokat jobban kiegyenlíteni. A cég éves tervében rögzítik a sarokszámokat: az elvárt forgalmat, árbevételt, nyereséget, mőködési költségeket, fejlesztéseket, stb, meghatározzák a globális mutatószámok elvárt értékeit (top-down tervezés). Következı lépésben a tervszámok kitöltése történik tartalommal, vagyis mind a vevıkkel foglalkozó KAM-ok és TEK-ek, mind pedig a szállítókkal foglalkozó GYK-k a partnerekkel történı egyeztetések alapján csoportonként meghatározzák a tervszámokat, melyeket addig gyúrnak, amíg hasonló eredményre nem jutnak. (bottom-up tervezés). A végsı konszenzus egy iterációs folyamaton keresztül alakul ki, melynek eredményeképpen megszületik az elfogadott éves terv havi bontásban. Az éves terv operatív tervvé történı lebontása a gördülı tervezés módszerével, három hónapos idıszakra, heti rendszerességgel történik. Online rendszerrıl lévén szó, a tényadatok naprakészen rendelkezésre állnak. Ismertek az elırendelések és megrendelések adatai, a teljesítettség, a számlázott és a pénzügyileg rendezett tételek adatai, amelynek alapján a közeljövı (2-3 hét) nagyon pontosan tervezhetı, míg a további hetek számai valószínőségi alapon határozhatók meg. A bevételi tervadatok száma egy hetes idıperiódusokban 12 hetes idıszakot figyelembe véve így is 50*15*12=9.000. Ebbıl is látszik, hogy manuálisan lehetetlen ilyen tervezést végezni, szoftvertámogatás nélkül.


59./64


Jól használható módszer, ha meghatározott valószínőségeket rendelünk a számokhoz és a valószínőséggel korrigált értékeket vesszük alapul. A költségek tervezésekor kiindulhatunk a költséghelyi kalkulációkból, ill. az elmúlt idıszakokban realizált fedezeti hányadokból. Nagy valószínőséggel a fajlagos fedezet tartalom egy adott idıszak alatt állandó, ha lényeges változás nem következik be mondjuk például a gyártástechnológiában, vagy a szervezeti struktúrában. Így elegendı százalékos arányokkal számolnunk a tervezés során és nem kell bonyolult számításokat végeznünk.

7.4

Az input adatok megadása Mint korábban említettük, az online rendszerekben jóval nagyobb mennyiségő adat áll rendelkezésre, mint egy „hagyományos” ERP rendszerben. Az adatok egy jelentıs része automatikusan keletkezik, másik részének bevitelérıl viszont gondoskodnunk kell. Az adatok megadására a hagyományos klaviatúrán, érintıképernyın keresztüli adatbeviteli módok mellett ma már számos egyéb eszközt is felhasználhatunk, amellyel a felhasználók életét megkönnyíthetjük:

Az automatikus adatbeviteli módok elsısorban a logisztika területén terjedtek el. Az áru mozgásának nyomonkövetésére ma már teljesen megszokott a különbözı rádiófrekvenciás adatátvitellel mőködı eszközök használata. Gondoljunk a szállító jármővekre, amelyeket GPS nyomkövetı rendszerrel szerelnek fel, vagy a nagy raktárakra, ahol a dolgozónál lévı kézi számítógép (PDA), vagy vonalkódolvasó, a targoncákra szerelt speciális számítógépek, a „pick by voice” technológia mennyire átalakította a logisztikai folyamatokat. Ezek az eszközök nemcsak az adatbevitelt automatizálják, hanem a munkafolyamatokat is teljesen átalakítják, melyeket jóval hatékonyabban lehet végezni. A dolgozók sokkal nagyobb teljesítményekre képesek amellett, hogy a hibázási lehetıségek szinte teljesen kiküszöbölhetıek. Továbbá az információ real-time rendelkezésre állása jól átláthatóvá teszi a folyamatokat, minden pillanatban tudni lehet az áru helyzetét, az elvégzett feladatokat, a bekövetkezett eseményeket, amelynek alapján gyors, operatív döntések hozhatók. Nincs messze az az idı, amikor az áruházláncokban nem a pénztárosnak kell egyenként leolvasnia a vonalkódot az árukról, hanem egy kapun keresztülhaladva a kosárban lévı áruk RFID cimkéjének (rádiófrekvenciás egyedi azonosító) leolvasásával automatikusan kijelzi a pénztárgép a vásárolt tételeket és a fizetendı összeget. Az elektronikus banki szolgáltatások igénybevétele ma már szinte természetes része az életünknek. Nem kell hozzá más, csak egy elektronikus bankkártya, vagy egy internet hozzáférés, de itt van már a mobil telefonról használható elektronikus


60./64


pénztárca is, amellyel fizethetünk, képeket készíthetünk és küldhetünk, e-mailezhetünk. Az intelligens chip-kártyák nagyon sokféle célra használhatók, az egyszerő azonosításon túl további adatok tárolására, információ befogadására, ill. közlésére is. Ezek alkalmazásával tehetjük hatékonyabbá a hivatalos ügyintézési folyamatokat, a járóbetegellátást, a közlekedés szervezését, az oktatással járó adminisztrációt. Biztosíthatjuk az esélyegyenlıséget, óvhatjuk a környezetünket, takarékoskodhatunk az energiafelhasználással, egyszerősíthetjük az adóbevallásunkat, stb. Nincs nagyon messze az az idı, amikor már csak beszélgetnünk kell a számítógéppel, szóban adjuk ki az utasításainkat, a gép, vagy robot pedig végrehajtja azokat. Az információ technológia lehetıségei ma már adottak és egyre bıvülnek, csak a fantáziánkon és a gazdaságosságon múlik, hogyan hasznosítjuk ezeket a lehetıségeket és eszközöket az üzleti folyamatainkban.


61./64


8 TUDÁSMENEDZSMENT Az innovációval, kutatás-fejlesztéssel, magas hozzáadott értékü termékek elıállításával, tanácsadással, informatikai fejlesztéssel foglalkozó vállalkozásoknál egyre kritikusabb kérdéssé válik a tudásmenedzsment. Egyes felmérések szerint a tudás 80 %-a a fejekben, az elektronikus levelekben, ill. a számítógépek „C” könyvtárában van. Ennek a felhalmozódott egyszemélyi tudásnak a közkinccsé tétele fontos gazdasági érdek minden szervezetben. A személyes tudás szervezetbe integrálása és megosztása, elérhetıvé tétele versenyelınyt jelent a vállalkozás számára. Az új munkatársak felkészítése az adott munkakörre az ilyen típusú tevékenységet folytató cégeknél gyakran fél-egy évet is igénybe vehet, amelynek esetleg csak a végén derül ki a dolgozó alkalmatlansága. Mindez nagy kockázatot és egyben nagy befektetést igényel a menedzsment részérıl. Hogyan lehet az egyéni tudást, tapasztalatot szervezeti tudássá konvertálni? Ebben is segíthet az informatika, a modern kommunikációs eszközök használata. Ha megpróbáljuk rendszerezni azokat a tudásokat (tartalmakat), amelyek elsajátítása a szervezet szempontjából fontosak, a következı ismerethalmazokat érdemes megkülönböztetnünk: •

Az értékteremtı tevékenység szempontjából alapvetıen fontos ismeretanyag, amelyet rendszerezve, hivatkozásokkal kiegészítve, folyamatosan aktualizálva hozzáférhetıvé teszünk a szakértık, kutatók, fejlesztık, tanácsadók, egyéb munkatársak számára. Ide tartoznak pl. a szabályok, törvények, szabványok, a szervezeti-mőködési rendszert leíró dokumentációk, workflow-k, szakmai adatbázisok, amelyek megismerése és alkalmazása a belépési pontot jelenti a gyakorlati munkába.

•

A „best practice” témakörbe tartozó leírások, információk, amelybe beletartozhatnak a technológiai leírások, workflow-k, esettanulmányok, rendszerleírások.

•

A tudásalapú tevékenységeknél elengedhetetlen a folyamatos konzultációs lehetıség biztosítása a szakmai csoporttagok között. Egy probléma többszempontú megvitatása, egy elvégzett munka tanulságainak közzététele és mások általi véleményezése, szakmai viták lefolytatása az internet segítségével akár egymástól távol levı résztvevık között gyakran eredményhez vezetnek: lerövidülhet a probléma megoldására fordított idı, gyorsabban döntést lehet hozni, magasabb színvonalú szakmai színvonalat lehet elérni, az esettanulmányok pedig a „letisztulás” után átkerülhetnek a „best practice” csoportba. Ha ezeket a konzultációkat, párbeszédeket struktúrált keretekben tudjuk folytatni, már megtettük az elsı lépést az egyéni tudás szervezeti tudássá történı integrálása irányába.

•

A kezdeti betanulási folyamatot, ill. a szervezett továbbképzéseket hatékonnyá tehetjük egy belsı eLearning rendszerrel, amelyben a dolgozók öntanuló módon sajátíthatják el a szükséges tudnivalókat és a számonkérést is beépíthetjük. Ezzel lecsökkenthetjük a felkészülési idıt, de csökken a tapasztalt munkatársak kiesı ideje is, amit az új dolgozók betanítására kell fordítaniuk.


62./64


•

8.1

Külön érdemes kezelni, önálló csoportba szervezni az újdonságokat, amelyek szakmailag érdekesek lehetnek a szervezet számára. Ha valaki rábukkan egy friss publikációra, vagy részt vesz egy konferencián és az ott hallottakat meg akarja osztani a többiekkel, ha valamilyen változás következik be, vagy valaki saját publikációra akarja felhívni a figyelmet, stb. elıször ebbe a témakörbe érdemes besorolni, ahonnan egy idı után átkerülhet az információ, ill. dokumentum az elsı két csoportba.

Tudásmenedzsment rendszer kialakítása

A tudásmenedzsment rendszer kialakításánál az alábbi ábrát vehetjük alapul:

A tudásmenedzsment rendszernek biztosítania kell a felhasználók számára a folyamatos megújulás lehetıségét, a szakértelem naprakészségét, a nagyobb teljesítmény elérését, az új ismeretek megszerzésére irányuló fogékonyságot. A folyamat három részbıl áll: 1. Tudásbázis létrehozása Elsı lépésként létrehozzuk a tartalmakat, amelyek a szervezet számára alapvetı fontosságúak. Ehhez rendszerezni kell a rendelkezésre álló dokumentumokat, leírásokat, információs anyagokat, valamint meg kell határozni az állandó kapcsolódási pontokat (linkek), amelyeken keresztül ezek az ismereteket kibıvíthetıek, aktualizálhatóak. A lényeg a rendszerezésen, a struktúra felépítésében van. A struktúrának tükröznie kell a szakmai szempontokat, amelyek szerint a tartalom keresések hatékonyan megvalósíthatóak. A tudásbázist folyamatosan karban is kell tartani. Ez a folyamat hasonlít a dokumentum menedzsmenthez, amelynél az informatikai rendszerben


63./64


lehetıség van verziókövetésre, eltérı jogosultságok kezelésére, kisebb dokumentum feldolgozó workflow-k alkalmazására, új dokumentumok feltöltésére, stb. 2. Tudás megosztás A tudás megosztása a tartalomhoz történı hozzáférés biztosítását jelenti a szervezet tagjai számára. A hozzáférés során biztosítani kell: • • • •

A A A A

hatékony keresést a tudásbázisban; megfelelı tartalmak elıállítását a jogosultsági kereteken belül; hozzáférések naplózását; kommunikációs folyamatok dokumentálását.

3. Tudás alkalmazás A folyamat eredménye a tudás alkalmazás, amikor a megszerzett tudás felhasználásra kerül egy feladat megoldása során, vagy beépül egy termékbe, vagy eljárásba, vagy szolgáltatásba. A tudás felhasználása eredményezhet magasabb szakmai színvonalat, vagy minıséget, nagyobb teljesítményt, hatékonyabb problémamegoldást, gördülékenyebb együttmőködést a szervezet számára. Egy cég tudásmenedzsment rendszerének felépítése hasonló módon történik, mint az egyéb integrált szoftveralkalmazásoké: • • • • • • • • •

Követelmények specifikálása; Logikai rendszertervezés; Kivitelezés; Keretrendszer implementálása; Induló tartalmak feltöltése; Jogosultsági rendszer beállítása; Felhasználók (tartalomszerkesztık, karbantartók) oktatása; Tesztelés, hibajavítás; Éles üzem indítása.

A tudásmenedzsment rendszerre való áttérés nagyfokú szervezettséget (rendet) igényel, továbbá gondoskodni kell a tartalmak folyamatos karbantartásáról. Erre érdemes egy új munkakört kialakítani. Az informatikai eszközök széles skálája áll rendelkezésünkre, melyekkel a megfelelı tudásmenedzsment rendszer a vállalkozás igényei szerint kialakítható.


64./64

Az ebusiness gyakorlata

Recommend Documents