Gazd.info szak eBusiness (Dobay, 2010)6. előadás 1/26 eBusiness: 6. Az e-Vállalkozás architektúrája PTE KTK GINFO szak Dr. Dobay Péter 2009 őszi félév.

Az előadások a következő témára: "Gazd.info szak eBusiness (Dobay, 2010)6. előadás 1/26 eBusiness: 6. Az e-Vállalkozás architektúrája PTE KTK GINFO szak Dr. Dobay Péter 2009 őszi félév."— Előadás másolata:

1 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 1/26 eBusiness: 6. Az e-Vállalkozás architektúrája PTE KTK GINFO szak Dr. Dobay Péter 2009 őszi félév „…the decision process, the management structure, and even the way work gets done has to be transformed.” Peter F. Drucker E-Gazdaság – B2C – B2B – eVállalat – e-Info Arch – eICT - Megoldások

2 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 2/26 Következik: 6. Az e-Vállalkozás architektúrája 6.1. Áttekintés 6.2. A feltételek kialakítása, a szokásos követelmények rendszere 6.3. Az üzleti felépítés megváltoztatása 6.4. A technológia megváltoztatása 6.5. Készen „beépíthető” komponensek

3 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 3/26 6.1. A feltételek kialakítása: áttekintés Az eVállalat kialakítása NEM technikai kérdés: a két oldalnak együtt kell működnie A fejlesztés folyamatos kell legyen A változás által érintett elemek, jelenségek: –eB „üzleti” modellek felhasználása –eFolyamatok kialakítása –eAlkalmazások bevezetése –eAlkalmazások használatával kapcsolatos szabályozások –eAlkalmazások integrálása a többi alkalmazásba –eAdatkezelés követelményei, adattárházak, adatbázisok –eNetwork: biztonság, titkosítások, összeköttetések kiépítése és üzemeltetése Mindezek mögött-felett: eROI, eMérések kialakítása

4 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 4/26 Az eArchitektúra áttekintése Az eVállalat üzleti modelljei és eljárásai A vállalatközi e-eljárások technológiája Vállalatközi e-Alkalmazások eAlkalmazások modelljei eEljárások létrehozása E-Üzleti modellek eVízió, eStratégia eAdatkezelés eHálózat- kezelés eAlkalmazások elterjesztése eAlkalmazások szabályozása eROI: megtérülés? eMértékek: Siker? Kudarc?

5 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 5/26 Vegyük sorra! 1.eBusiness „üzleti” modellek felhasználása A felső szintű elképzelés arról, hogy milyen piacokon, milyen termékekkel/szolgáltatásokkal, milyen erőforrásokkal jelenünk meg, kikkel fogunk együttműködni. Példa: csomagküldő értékesítés, futárszolgálat, bankkártyás fizetés, Kelet-Európa, és „A terméklista a következő:” 2. eFolyamatok kialakítása Hogyan használjuk ki a Net lehetőségeit az új folyamatokban? Kivel kell kapcsolatokat kiépíteni, hogyan? Mit használhatunk fel meglévő rendszereinkből? Mi lesz teljesen új? Példa: Portál építése, két új informatikus, szerverhosting, a megrendelés és fizetés új eljárásainak kialakítása; ÉS: régi weblap elemeinek átvétele, régi nyomtatott katalógus e- formájának kialakítása saját erőből, vevő-adatbázisból email kampány, …

6 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 6/26 Tovább: 3. eAlkalmazások bevezetése Vegyük szemügyre a kínált alkalmazásokat: építsünk saját modellt, a mi vevőinkre, specifikáljuk a méreteket, kapacitásokat, a felhasználható régebbi elemeket – ne bízzunk mindent egy csomagra! Példa: A kialakítandó katalógus-áruházhoz nézzünk meg vezető alkalmazásokat, nézzünk meg amatőröket. Kérjünk fel saját designert. Ha volt spéci értékesítési formánk, építtessük bele (törzsvevők, kedvezmények, akciók, stb.). „Beszéljen a mi nyelvünkön”: színek, stílus, képanyag, logók, sebesség, szöveg bősége, stb. Vessük össze: IKEA, Vatera, LEGO, … 4. eAlkalmazások használatával kapcsolatos szabályozások Alakítsuk át a belső üzletszabályzatokat, munkaköri utasításokat, szervezeti rendszert, adjunk teret eB-ben tapasztalt új vezetőknek, készüljünk fel hibákra. Mai divatos irány: COMPLIANCE – megfelelés EU, vagy USA pénzügyi szabályoknak, APEH-nek, adatbiztosnak, Greenpeace-nek…

7 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 7/26 Tovább: 5. eAlkalmazások integrálása a többi alkalmazásba Az új alkalmazások hova kerüljenek: új szerverek, vagy kapcsolatteremtés régiekkel? Middleware megoldások? Kommunikáció? Adatbázisok? Példa: Régi vevő-adatbázis használata az új megrendelési rendszerben; termék-katalógus integrálása, reklamációk egybevetése megrendelési-szállítási adatokkal, stb. 6. eAdatkezelés követelményei, adattárházak, adatbázisok A legalsó szinten újra kell gondolni az adatmodelleket és kapcsolataikat. Építsünk OLAP/DW vezetői elemző rendszert az eBus kiszolgálására. Példa: Elemezzük az adatszolgáltatást IM szempontok szerint. Ott van a régi ERP. Nézzük át szakértőkkel, vegyünk OLAP/DW modult. Építsünk be a web-portált figyelő-elemző rendszereket. 7. eNetwork: a hálózati infrastruktúra kiépítése. Biztonság, titkosítások, összeköttetések kiépítése és üzemeltetése Példa: Szolgáltató? Kapacitások? Adatforgalom becslése? Havaria? Kiszervezés? Mobil is?

8 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 8/26 6.2. Amit érdemes célbavenni Ha egy komplett audio rendszert veszünk, tucatnyi végtermékből építhetjük azt össze – akár egy autót is! Ráadásul itt egy technikai szempontrendszer találkozik egy másfajta üzleti szempontrendszerrel. 1.„Legyél fürge” – agility Ez az adaptáció egyik legfontosabb eleme: cseréljük le a régi technikát, ha kell, szabaduljunk meg a koloncoktól, ha lejárt az idejük. Ennek feltétele, hogy olyan architektúrát tudjunk összehozni, ami nincs „becementezve” (technológia, gyártó, kapacitások, flexibilitás…) – ki tudja, mi lesz holnap, kihez kell alkalmazkodni? Figyelni kell a szabványokat (Open Standards!). Sokszor „be kell csomagolni” a régi alkalmazást, hogy az új fogadni tudja az outputot. Illeszkedni kell a fő vevők/szállítók rendszereihez, különben elveszítjük őket,m ha sokat habozunk egy technológia bevezetésével (pl. RFID, smart kártyák, mobil, stb.)

9 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 9/26 Amit érdemes célbavenni /2 2. „Lépj velük közvetlen kapcsolatba” – inter-operability Az eBusiness alrendszernek be kell ágyazódnia a meglévő ERP, DBMS, spéci web-alkalmazások, szerver-platformok, C/S alrendszerek, DMS és más rendszerek környezetébe. Több telephely, globális terjeszkedés esetén??? Aztán: a külső partnerek rendszerei? Mi adjuk nekik a „javaslatot”, vagy ők nekünk? NEM LEHET papíron kommunikálni. A kérdés: túl kevés – túl sok technológiai integráció? Ha „mindent elveszünk” és egységesítünk, jó kis alkalmazások, részleges verseny-előnyök, tudás megy veszendőbe. Mindenki függővé válik mások teljesítményétől, ellenőrizhetetlen, motiválatlan lesz a rendszer sok eleme!! Ha „mindent meghagyunk”, akkor a szükséges együttműködés nagyon sokba kerülhet és feláldozzuk a gyorsaságot és a biztonságot, ami az eBusiness fő hajtóereje.

10 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 10/26 Amit érdemes célbavenni /3 3. „Használd fel, amit lehet” Ott van a számviteli rendszer, a termelésirányítás, a raktár- menedzselő szoftver – biztosan lehet használni ezeket továbbra is. A „vállalati tudás”, amit a korábbi ICT rendszerek felhalmoztak, egy felhasználandó vagyon! Sok különálló rendszer mögött van azonos technológia, platformokkal kapcsolatos tudás, adatkezelési tapasztalat, kimutatások, stb. Tehát: olyan rugalmas szoftver-komponenseket kell megrendelnünk (megkövetelnünk), amelyek az általunk értékesnek tartott technológiai (és emberi!) erőforrásokat fel tudják használni. Ami ehhez kell: dokumentáció-tárak, use-case vagy más jellegű folyamatleírások, terminológia-adatbankok, szabványos gyűjteménye, kezelési utasítások összegyűjtése, szoftver objektum-könyvtárak, stb stb – vállalati tudásbázis!

11 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 11/26 Amit érdemes célbavenni /4 4. „Ez az enyém, az a tiéd” – kié az „eBusiness”? Egy ICT – és így az eBusiness rendszer is – valamiféle részlegeket átölelő, azok felett kiépülő együttműködés. Ki legyen a „főfelelős” – akit leginkább érint, vagy aki a legjobban ért hozzá? Kié az adatállományok (átalakítása) feletti jog? Kié egyes alkalmazások feletti jog (Kidobjuk? Alakítsuk? Változatlanul hagyjuk? Új kell – melyik?) Kié egy adott hardver- architektúra feletti rendelkezés joga? Ki lesz a felelős, ha 3-4 alrendszert érintő új alkalmazást vezetünk be, s az nem sikerül? Kié a siker, ha sikerült? Szükséges valamiféle „megosztott felelősségi vezetés” létrehozása, ahol nem a vádaskodás a cél, hanem az együttműködés. Sőt: megváltoznak a szállítók, a vevőkör is! „Kié” lesz a lepusztult, régi vevőkapcsolati kör, ki kapja meg az „ígéretes újakat”?

12 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 12/26 Amit érdemes célbavenni /5 5. „Skálázhatóság”– meddig terjeszkedjen az „eBusiness”? Egy hagyományos üzletmenetnél a vásárlók számát, látogatókat, teherautókat, négyzetmétereket becsülni lehet. Egy új web-portálnál? A szerver kapacitásától a szükséges online személyzetig mindent rugalmasan alakíthatóvá kell tenni – és ezt „fürgén” módosítani kell tudni! Egy taktika: nem veszünk, hanem bérelünk, lízingelünk, kiszervezünk! Ami skálázható kell legyen: alkalmazás-szerverek kapacitásai, adatbázisok mérete (növekedése), válaszidők tartása növekedés esetén, sávszélesség, stb.

13 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 13/26 S végül: /6 7. „Gyors ciklusok, állandó megújulás”– mikor lesz „készen” az „eB”? Hagyományosan a termék fél-egyéves tervezés után kerül piacra. Az ICT iparban megtanultuk, hogy a piacra hozott termék - nagyon gyorsan (fél – egy év alatt) elavul, fel kell váltani - ezért az innovációs láncban már 2-3 új verzió, modell fejlesztése folyik, mintegy „sorban áll”, hogy kellő időben piacra kerüljön. Azaz: - iteratív módon folyamatosan készen kell állnunk a „következő generáció” beépítésére, felhasználására, miközben még az előzőt javában használjuk - nem lehet arra várni, hogy „majd jön az új technika”: apránként, inkrementális módon állandóan fejlesztgetni kell Ennek következtében nincs „nagy, új beruházás” – inkább folyamatos építgetés – és persze tanulás, tanulás, tanulás!

14 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 14/26 6.3. Az „üzleti architektúra” átalakítása Az eB architektúra az üzlet azon elemeinek összessége, amelyek a teljes modellből érintettek lesznek az újban. A szokásos tervezési alapelemek: milyen piacra, milyen termék, hogyan, aztán termékfejlesztés, vevőkapcsolat, s persze mindez: miből? Top – down: –üzleti vízió, stratégia –szervezeti modell –vállalati folyamatok modelljei (vezetéstől a mgmt szintig) –ezekhez kapcsolódó alkalmazások –részfolyamatok és azok alkalmazásai (munkafolyamatok) –adatstruktúrák, DMS –ICT architektúra, infrastruktúra

15 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 15/26 Az eVállalat „Üzleti modelljének” alkotóelemei eBusiness modellek - Célbavett vevők köre (COIN) - E-termékek, szolgáltatások - Pénzügyi modell: fizetés? - Branding lehetősége - Kiszállítási modell - ICT erőforrások, modellek eFolyamatok modelljei - üzleti egységek azonosítása -„Use Case” működési esetleírások - belső folyamatok modelljei - felhasználható régi folyamatok - üzleti erőforrások: emberek, állományok, dokumentumok, tudástárak, stb. eAlkalmazások modelljei - új alkalmazások definiálása - felhasználói interfészek „skiccei” - alkalmazások specifikálása - belső üzleti szabályzatok figyelembevétele - felhasználható régi megoldások - alkalmazás-erőforrások: modulok, elemek, adat-szerkeze- tek, „motorok”, fejlesztő- eszközök, stb. Az eAlkalmazások kialakított architektúrája

16 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 16/26 Az elemek: eB modellek Ez a felsőszintű rátekintés szintje. A piaci alapcélokat definiálni kell, feltárni a lehetséges vásárlókat. Tudunk brand-et kihasználni? Bevezetési kockázat, pénz? A termék és kapcsolódó szolgáltatások keverékét ki kell alakítani. Hogyan juttatjuk el a vevőhöz? Honnan jön majd a bevétel? Mennyi? Kik a lehetséges partnerek? Kinek mihez lesz joga, ha elkezdünk belenyúlni egymás rendszereibe (belsők – külsők is!) Mik a kritikus sikertényezők (CSF)? Tudunk ROI-t,vagy valami más mértéket használni a megtérülésre, a hatékonyságra? E - Balanced Scorecard?

17 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 17/26 folytatás eFolyamatok Az új belső és külső folyamatok megtervezése. Ezeknek illeszkedniük kell az e-alapmodellhez. A folyamatok környezete: vevők, szállítók, részlegek. Jó, ha fel tudunk építeni vizualizált modelleket, „use case” esetleírásokat, ha-akkor folyamatábrákat, stb. eAlkalmazások A fentiekből kell levezetni a szükséges alkalmazásokat. Egy folyamathoz akár több alkalmazás is társulhat, integráltan. Alap: a szükséges funkcionalitások megkövetelése: adat-objektum modellek, felületek skiccelése („mockup”). Gondosan elemezni kell, mi használható fel a régebbi megoldásokból, milyen kész megoldások vannak a piacon.

18 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 18/26 6.4. A technológiai architektúra átalakítása A cél az üzleti elképzelés „lefordítása” megfelelő alkalmazásokra, technológiai megoldásokra Belső- és külső folyamatokat egyaránt figyelembe kell venni, miközben az ICT architektúrák gyorsan fejlődnek – ez egy komplex feladat! A tömegesen bevezetett C/S és ERP megoldások nincsenek felkészítve Web-es interfészek kezelésére, vállalatközi kapcsolatok menedzselésére A legacy rendszerek zártak, egyedi fejlesztések, az adatmodellek nincsenek dokumentálva, a platformok elavultak…. Munka, munka, munka – és késés! Integrációs lehetőségek: –Adatszinten: gyors, viszonylag olcsó, ismert technikák, nem érinti az üzleti alkalmazásokat – éppen ez a hátrány majd! –API/eljárás szinten: nem kell „kivenni” az adatot és „betenni” a másikba (akár GUI felületeken), hanem ezt a háttérben elintézzük, szoftver megoldásokkal, újra-felhasználható elemekkel. Mindez előny és egyben megbízhatósági veszély is, hiszen akár funkcionalitást kell szűkíteni a „megbuherált” alkalmazásoknál

19 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 19/26 Az eVállalat „Technológiai modelljének” alkotóelemei eAlkalmazások szabályai - üzleti logika, előírások - üzleti objektumok lajstroma - „szabály-tudásbank” - alkalmazások logikai váza - alkalmazások komponensei - használható keretrendszerek eAdatkezelés - alkalmazásokhoz szükséges állományok - adatkezelési megoldások - adattárház megoldások - örökölt állományok kérdései - ERP/MRP adattárak kérdése eAlkalmazások terjesztése, integrálása - alkalmazás-szerverek köre - elosztott architektúrák tervei - technológiai komponensek - middleware megoldások - integrációs szoftverek EAI Az eAlkalmazások kialakított architektúrája eNetworks -Hálózati biztonság alapelvei, technikája, garanciái - titkosítási eljárások - connectivity megoldások -Rendszer-menedzsment

20 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 20/26 Az elemek: eAlkalmazások szabályrendszere Minden üzleti folyamatnak megvan az „ellenőrzések, fékek, egyensúlyok” környezete, ami vagy dokumentált, vagy nem (pl. bank: magasabb hitelkérelmet más bírál el, más az eljárás; beszerzés: preferált szállítónak nem kell azonnal fizetni, van bizalma, stb.). Célszerű az alkalmazás tervezésekor létrehozni egy ilyen tudástárat („Rules Engine”), ahol dokumentáljuk az összes ilyen különleges eljárást, s a fejlesztők ebből dolgoznak: minden tranzakció „rákérdez” erre a bázisra. Az e-alkalmazás általában új: ki kell találni, mivel bővítsük ezeket a szabályokat ezentúl. Körül kell nézni, tanácsadót kell hívni.

21 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 21/26 Folytatás: eAlkalmazások elterjesztése, integrációja Az eVállalatban kialakított platformok részlegeken átnyúlnak, sőt, más cégek rendszereihez kapcsolódnak. A kulcs-szerep az elosztott architektúráé: az alkalmazások (erőforrások) delegált szervereken ülnek, és szabványos módon lekérdezhetők (CORBA*, COM/DCOM). Ha a rendszerek felépítése ezt nem támogatja, akkor ún. middleware megoldásokat kell fejleszteni, vagy igénybevenni (IBM MQSeries, BEA’s Tuxedo, stb.). Az ERP II-kben egyfajta Enterprise Application Integration EAI rendszer szolgál arra, hogy zárt részrendszerekből adatokat lehessen átvenni, vagy működési válaszokat lehessen kapni. * A Common Object Request Broker Architecture egy szabványgyűjtemény a számítógépes hálózatok kommunikációjára; lehetővé teszik különböző operációs rendszereken futó, eltérő programozási nyelveken megírt alkalmazások kommunikációját. Az alkalmazások, programok között az interfészt egy interfészleíró nyelven (Interface Definition Language, IDL) kell definiálni.

22 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 22/26 Folytatás: eAdatkezelés Az adatokat sokféle alkalmazás használhatja. Ezért az adatbázist, vagy az ETL-eljárásokkal létrehozott adattárházat, adatpiacokat ún. nyílt-szabványú megoldásokkal (JavaDBC/OpenDBC) kell lekérdezhetővé tenni. Sokszor az adat nem relációs adatbázisban van, hanem valamilyen tetszőleges, „custom” állományban, ERP/MRP modulban. A barkácsolás során nagyon vigyázni kell az érzékeny (vevői-szállítói, akár idegen!) adatok biztonságára! eNetworks Az eVállalat működésének hátterében áll a gerinchálózat, valamilyen hálózati OS, aztán a tűzfalak rendszere, és kapcsolatteremtő eszközök, ha inhomogén elemekből van összerakva a kommunikációs lánc. Az e-aláírás, időbélyegek, PKI Public Key Infrastructure szintén része ennek a problémakörnek.

23 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 23/26 Mit használhatunk fel, elemekből? Legtöbbször szoftver-modulok azok, amiket (először, vagy újra) hasznosíthatunk: interfész-megoldások, adatkezelés, stb. Itt mindig felmerül a „vegyem, vagy csináljam meg” kérdés. A Web indulásakor minden elemet programozni kellett: ma fejlesztői környezetek és „generálható/hangolható” megoldások léteznek. Még ma is igen fejletlen a piac, nagyon sok az egyéni fejlesztgetés. Elképzelhető kisebb komplexek, „üzleti megoldások” beépítése: pl. „bevásárlókosár-megoldás”; „CRM megoldás”, „fizetési csomag”. Az ilyen importtal felgyorsítjuk a munkát, koncentrálhatunk a speciális problémákra. Cloud computing? A kérdés: megbízhatok egy (pl. ingyen!) szoftver-modulban? A válasz: csak a standard elemeket építsük be, a spéci üzleti logika legyen a miénk. Ez az ún. komponens-alapú programozás, CORBA, DCOM/COM+, Enterprise JavaBeans, J2EE, Java EE 5, stb. – szerver-oldali támogatás osztott rendszerek megvalósításához. Megvalósul valamiféle „szoftver-gyártás”, futószalagon?

24 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 24/26 David A. McAfee: The eBus Architecture

25 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 25/26 eBusiness „konzorciumok” Korábban csak B2B egyedi megoldások léteztek („proprietary EDI systems”) Lassan kialakulnak az inter-kommunikációt támogató, szabványosító szerveződések: –CommerceNet (ún „eBusiness Chamber”, tagsággal – kb. 500 cég – díjakkal, ajánlásokkal, pl. Catalog Interoperability Project, vagy Secure Electronic Transaction Project, etc.) –RosettaNet www.rosettanet.org, 1998, „közös terminológia, szabványok kidolgozása” céljával (tagság)www.rosettanet.org –Open Buying Initiative OBI www,openbuy.org –Open Financial Exchange www.ofx.net –Internet Content & Exchange: 80 cég, a nagyok, W3C

26 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 26/26

27 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 27/26 RosettaNet Standards The RosettaNet standard is based on XML and defines message guidelines, business processes interface and implementation frameworks for interactions between companies. Mostly addressed is the supply chain area, but also manufacturing, product and material data and service processesXML are in scope. The standard is widely spread in the semiconductor industry, but also electronic components, consumer electronics, telecommunication and logistics. RosettaNet originated in the US and is widely used there, but it is also well accepted and even supported by governments in Asia. Due to the wide spread use of EDIFACT in Europe, RosettaNet is used less, but it is growing.EDIFACT The RosettaNet Automated Enablement standard (RAE) uses the Office Open XMLOffice Open XML document standard.s

28 Gazd.info szak eBusiness (Dobay, 2010)6. előadás 28/26