r12 átállás Tóth Sándor DBA Menedzser Vágó Csaba IT Alkalmazásfejlesztési Vezető ni.com NI CONFIDENTIAL

Méret: px

Mutatás kezdődik a ... oldaltól:

Download "r12 átállás Tóth Sándor DBA Menedzser Vágó Csaba IT Alkalmazásfejlesztési Vezető ni.com NI CONFIDENTIAL"

Lilla Lakatos
7 évvel ezelőtt
Látták:

1 ni.com

2 r12 átállás Tóth Sándor DBA Menedzser Vágó Csaba IT Alkalmazásfejlesztési Vezető

3 Témák A National Instruments Oracle ebs történelem az NI-nál Definíciók Az upgrade projekt Az újraimplementációs projekt Technikai áttekintés Kérdések

4 National Instruments Mérés- és tesztautomatizálás Grafikus rendszertervezés, grafikus fejlesztőkörnyezet moduláris hardverelemekkel

5 National Instruments Az alkalmazásaink változatossága

National Instruments Non-GAAP bevétel: 1,14 milliárd USD Globális működés: Kb. 6.

6 National Instruments Non-GAAP bevétel: 1,14 milliárd USD Globális működés: Kb ember világszerte több mint 40 országban Széles vásárlói bázis: Több mint cég Cégkultúra: A Fortune magazin felmérésében a világ 25 legjobb cége közt szerepel

200 ember világszerte több mint 40 országban Széles vásárlói

7 ebs történelem az NI-nál Oracle Order Entry & Inventory 10.x verzión AR, AP és GL OSM (Marketing, Pre-Sales), OSS (Install Base, Post-Sales) július NI Japan 11i-re vált (11.5.6) július NI Corporate 11i-re vált (11.5.8) április NI Japán upgrade (11.5.8) február NI Europe és NI Hungary 11i-re vált (11.5.9) február NI Japan => NI Europe migráció november NI Europe / NI Hungary Operating Unit szétválasztás

július NI Japan 11i-re vált (11.5.6) 2003. július NI Corporate 11i-re vált (11.5.8) 2004.

8 ebs környezetek Két implementáció Amerika Európa, Ázsia, minden más ebs modulok Marketing, Campaigns Events, Scripting, Customer Data Lead, Opportunity Quoting Order Management, Advanced Pricing Service, Install Base, Contracts, Depot Repair Advanced Supply Chain Planning, Procurement Discrete Manufacturing, Inventory, Shipping Financials: AP, AR, GL, SLA, Tax, Cost HR, Projects, Time & Labour és még sok más

Install Base, Contracts, Depot Repair Advanced Supply Chain Planning, Procurement Discrete

9 Definíciók Upgrade Az Oracle által biztosított eszközkészlet az adatok, és alkalmazások átkonvertálása r12-es verzióra Szükséges lehet előzetes technikai upgrade-ekre A konfigurációk, beállítások többsége öröklődik Újraimplementálás Tiszta r12-s implementáció Konfigurációk, és egyedi testreszabások újbóli beállítása Adatmigrálás a régi rendszerből

konfigurációk, beállítások többsége öröklődik Újraimplementálás Tiszta r12-s

10 r12 Roadmap Planning Map&Gap Development Testing GoLive July 2010 Americas Upgrade to Planning PoC & DM Map&Gap Development Testing GoLive August 2011 Europe & Asia Re-Implementation to Q3 09 Q4 09 Q1 10 Q2 10 Q3 10 Q4 10 Q1 11 Q2 11 Q3 11 Q4 11

11 Amerikai szerver Döntési tényezők Viszonylag egyszerű üzleti környezet Nincs szervezeti-, és üzleti modell változás Szignifikáns változások a pénzügyi modulokban As-is funkcionalitás Módszer: Upgrade Oracle szkriptek; Néhol finomhangolva Hosszú és komplex átállás (~55 óra) o => CU2 => 10g DB => => 11g DB => Átállás hétvégén plusz két munkanap

Módszer: Upgrade Oracle szkriptek; Néhol finomhangolva Hosszú és komplex átállás (~55 óra) o

12 Európai/Ázsiai szerver Döntési tényezők Rendkívül komplex üzleti környezet Európában sok változással az eredeti implementáció óta o Operating Unit használat Európában o Operating Unit pénznem változtatás o Készletstruktúra újradefiniálása o Számlatükör (CoA) kiterjesztése és a főkönyvi struktúra újratervezése o HR modul beállítások egy esetleges szerverkonszolidációt elősegítendő Kockázatcsökkentés o Hosszú átállás o Új, ázsiai gyártási központ beállítása o RAC migráció Régi adatok törlése, konfigurációk tisztítása Háttér ebs r12 tudás és tapasztalat a korábbi projektből RDBMS 11g ismerete korábbi projektekből Működő házon belül fejlesztett adatmigrációs motor Tapasztalt projekt vezetés (1 projekt-, és 12 alprojekt vezető) Kb. 120 ember a projekten Céges szintű sztenderdizálás

Kockázatcsökkentés o Hosszú átállás o Új, ázsiai gyártási központ beállítása o RAC migráció Régi adatok törlése, konfigurációk tisztítása Háttér ebs r12 tudás és tapasztalat a korábbi projektből

13 Európai/Ázsiai szerver Módszer: Újraimplementáció Proof of Concept fázis o Üzleti követelmények összegyűjtése, elemzése és meghatározása a következő 7 évre o Az alapvető beállítások meghatározása, ami ezt lehetővé teszi o Csak a legtapasztaltabb kollégák (programozók, rendszerelemzők) bevonásával o Fókusz csak a kulcs területeken o Adatmigrációs mapping Map & Gap fázis o A hiányosságok, különbségek meghatározása az aktuális folyamatok és az r12 által az új beállításokkal kínált funkcionalitások között o Fókusz már minden területen, az egész csapat bevonásával Konfiguráció, Fejlesztés, Tesztelés fázis o Iteratív megközelítés egyre finomodó beállításokkal o Az üzleti felhasználók bevonása Élesítés o Konfiguráció előre tesztelve, jóváhagyva o Adatmigráció kb. 50 óra alatt o Hétvégi átállás plusz egy munkanap

különbségek meghatározása az aktuális folyamatok és az r12 által az új beállításokkal kínált funkcionalitások között o Fókusz már minden területen, az egész csapat bevonásával Konfiguráció,

14 Konfigurációs stratégia

15 Európai/Ázsiai szerver Legfőbb változások Európa átállt multi-org-ra Számlatükör újratervezve Funkcionális pénznem változás az európai Operating Unit-okban Depot Repair bevezetés ebusiness Tax bevezetés Új készletstruktúra A konkurens menedzser átment az alkalmazásrétegre RAC átállás Adatmennyiség csökkentése 70%-kal az NI saját migrációs motorját felhasználva Pénzügy Kihívások A legnagyobb funkcionalitásbeli változás a 11i és az r12 között Multi-org és számlatükör hatások az összes pénzügyi modulon Pénznem konverzió Adatmigráció hatása az Adattárházon Rendkívül komplex átállás, és a nyitott megrendelések migrálása A projektvezetés, és a stakeholder-ek 3 kontinensen és még több időzónában Adattörlési, -megtartási irányelvek hiánya

Pénzügy Kihívások A legnagyobb funkcionalitásbeli változás a 11i és az r12 között Multi-org és számlatükör hatások az összes pénzügyi modulon Pénznem konverzió Adatmigráció hatása az

16 Upgrade vagy újraimplementáció Upgrade Az aktuális beállítások megfelelnek a jövő várható kihívásinak Nincs r12 és adatmigrációs tapasztalat Nincs szükség adattörlésre Korlátozott idő és pénz Fontos: alatti verziók esetében két technikai upgrade szükséges Adatminőség és konfiguráció nem fog javulni Újraimplementáció Alapkonfigurációk, üzleti környezet, folyamatok változnak Számlatükör és főkönyv struktúra Business Groups, Operating Units, Inventory Organizations, Kulcs flexfield-ek Nagymennyiségű adattörlés, - tisztítás Fontos: r12 és adatmigrációs tapasztalat szükséges Új hardver Magasabb kezdeti költségek

8 alatti verziók esetében két technikai upgrade szükséges Adatminőség és konfiguráció nem fog javulni Újraimplementáció Alapkonfigurációk, üzleti

17 11i áttekintés Redhat AS 2 Oracle 9iAS Redhat AS 4 Oracle 9iAS Americas Oracle Solaris 9 Solaris Europe & Asia Oracle

18 R12 újraimplementáció + SSO 2011

19 11i áttekintés újraimplementáció előtt

20 R12 áttekintés újraimplementáció

21 r12 architektúra áttekintés Adatbázis kezelő és RAC Az első, nagy tranzakciós adatbázis, ami a RAC-ra megy Mentés, frissítés sokkal komplexebb Előre felkészültünk a különféle technikai problémák kezelésére (pl Queue propagáció) Szokatlanul magas SGA/PGA beállításokkal indultunk, amit menet közben finomítottunk o SGA/PGA: 75 GB/25 GB RAC adatbázis példányonként Az adatbázis már 11gR2-n van ( )

22 r12 architektúra áttekintés SSO Egyszerűbb felhasználói bejelentkezés Tapasztalat a korábbi R12 upgarde projekt során

23 r12 architektúra áttekintés Adatmigráció Az előző R12 áttérés klasszikus upgrade volt Ennél a rendszernél az újraimplementáció mellett döntöttünk Saját fejlesztésű migrációs keretrendszerrel vittük át az adatokat: o Tábla oszlopokat összerendeltük o Majd az alaptáblákba insert műveletekkel vittük át az adatokat o A sémák többsége nagyon hasonló a és verziókban o Alapos teszteléssel számolt a projekt o Nem minden adatot vittünk át ( takarítás ) o Előre kalkulált üzleti kockázat: Várhatóan nem minden nyitott rendelés tudunk átvinni a célrendszerbe A Pénzügynek hóközi zárással kell számolni

24 r12 architektúra áttekintés Párhuzamos konkurrens feldolgozás Nagyobb feldolgozó kapacitás és stabilitás Kipróbált módszer (előző R12 upgrade során is ezt implementáltuk) A konkurrens feldolgozás már nem a db réteg szerverén fut A konkurrens feldolgozás kimeneti állományai központi helyen tárolódnak Mindez a végfelhasználók számára transzparens

25 r12 architektúra áttekintés Megosztott APPL_TOP architektúra Szükésges lépés a párhuzamos konkurrens feldolgozás implementálása érdekében Felhasználtuk a cég NetApp alapú fájlszerver kapacitását Ez a legelterjedtebb architektúra az EBS használó cégeknél A továbbiakban nem kell manuálisan szinkronizálni a közbenső réteg (App Tier) állományait

26 Megosztott APPL_TOP architektúra

27 Technikai problémák, amikkel előre számoltunk Citrix elérés és performancia problémák Támogatott böngészők köre Adatbázis és közbenső réteg instabilitás Adatbázis lockok Konkurens feldolgozó kapacitás túlterhelése Nyomtatási problémák Felhasználók hozzáférése a lezárt könyvtárakhoz SSO problémák Mod PL/SQL elérések Elveszett responsibility-k Elveszett funkciók Kódok, amik még mindig a régi adatbázist akarják használni

28 Kérdések

Hasonló dokumentumok

Adattárház automatizálási tapasztalatok a Generali Biztosítóban

Adattárház automatizálási tapasztalatok a Generali Biztosítóban Csonka Zoltán Adattárház architekt csonka.zoltan@generali.com DW Fórum 2014 Cégismertető A Generali Biztosító hazánk egyik vezető biztosítótársasága,