ni.com
r12 átállás Tóth Sándor DBA Menedzser Vágó Csaba IT Alkalmazásfejlesztési Vezető
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
National Instruments Mérés- és tesztautomatizálás Grafikus rendszertervezés, grafikus fejlesztőkörnyezet moduláris hardverelemekkel
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.200 ember világszerte több mint 40 országban Széles vásárlói bázis: Több mint 30.000 cég Cégkultúra: A Fortune magazin felmérésében a világ 25 legjobb cége közt szerepel
ebs történelem az NI-nál 1994-2000 Oracle Order Entry & Inventory 10.x verzión AR, AP és GL OSM (Marketing, Pre-Sales), OSS (Install Base, Post-Sales) 2002. július NI Japan 11i-re vált (11.5.6) 2003. július NI Corporate 11i-re vált (11.5.8) 2004. április NI Japán upgrade (11.5.8) 2005. február NI Europe és NI Hungary 11i-re vált (11.5.9) 2007. február NI Japan => NI Europe migráció 2008. november NI Europe / NI Hungary Operating Unit szétválasztás
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
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
r12 Roadmap Planning Map&Gap Development Testing GoLive July 2010 Americas Upgrade 11.5.8 to12.1.2 Planning PoC & DM Map&Gap Development Testing GoLive August 2011 Europe & Asia Re-Implementation 11.5.9 to 12.1.3 Q3 09 Q4 09 Q1 10 Q2 10 Q3 10 Q4 10 Q1 11 Q2 11 Q3 11 Q4 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 11.5.8 => 11.5.9 CU2 => 10g DB => 12.1.1 => 11g DB => 12.1.2 Átállás hétvégén plusz két munkanap
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
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
Konfigurációs stratégia
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
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: 11.5.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 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
11i áttekintés 2009 11.5.8 11.5.9 Redhat AS 2 Oracle 9iAS Redhat AS 4 Oracle 9iAS Americas Oracle Solaris 9 Solaris 10 9.0.2.8 Europe & Asia Oracle 9.0.2.8
R12 újraimplementáció + SSO 2011
11i áttekintés újraimplementáció előtt - 2011
R12 áttekintés újraimplementáció
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 (11.2.0.1)
r12 architektúra áttekintés SSO Egyszerűbb felhasználói bejelentkezés Tapasztalat a korábbi R12 upgarde projekt során
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 11.5.9 és 12.1.3 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
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
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
Megosztott APPL_TOP architektúra
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
Kérdések