• Jaargang 2011, editie 3 - juni 2011

Naar aanleiding van het eerdere R12 artikel in Transform magazine, is er veel reactie gekomen van lezers over wanneer het beste een upgrade ingezet kan worden. Hier is geen eenduidig antwoord op te geven omdat dit per situatie verschilt. Het advies is om een businesscase te maken die de voordelen en gepaard gaande kosten helder weergeeft. In dit artikel worden handvatten voor een upgrade, een vooronderzoek en onderbouwing van een businesscase beschreven.

Waarom is het moment van upgraden naar Oracle E-Business Suite R12 per klant verschillend? Eigenlijk is het antwoord te vergelijken met een Windows upgrade: omdat het upgraden van Windows XP naar Windows Vista en nu de 7 versie ook bij elke klant op een ander tijdstip wordt uitgevoerd. Er zijn klanten die bewust heel lang wachten en er zijn klanten die de ‘early adaptors’ willen zijn om zo snel mogelijk gebruik te kunnen maken van de nieuwe functionaliteiten binnen een nieuwe release. Voor de upgrade van R11 naar R12 geldt hetzelfde. De stabiliteit van de eerste versie van R12 was twijfelachtig. De R12.1 versies zijn echter stabiel en bieden uitgebreide functionaliteit die een businesscase voor een upgrade van R11 rechtvaardigen.

Kosten kunnen een tweede factor zijn waarom een upgrade naar een nieuwe release wordt ingezet. Bij een Oracle E-Business Suite upgrade kunnen dit de supportkosten zijn die men jaarlijks aan Oracle moet afdragen aan extended support. Deze supportkosten worden hoger omdat Oracle de reguliere support die in het percentrage van 22% zit inbegrepen niet meer aanbiedt op oudere versies. Daarnaast kan het onderhoud op maatwerk of het handmatig uitvoeren van werkzaamheden dermate kostbaar zijn dat het inzetten van standaard functionaliteit van de R12.1 release kosteneffectief kan zijn.

Oplossingen binnen de software (patches) worden bij oudere versies steeds moeilijker te plaatsen omdat ze niet meer ontwikkeld worden voor de oudere E-Business Suite releases of als ze gemaakt worden in megapacks (vele patches tezamen). Bij het plaatsen van een megapack is de impact veel groter en is het supportteam veel meer tijd kwijt om deze patches te testen vanwege alle afhankelijkheden.

Stabiliteit en betrouwbaarheid van de huidige versie is vaak een reden om juist niet te upgraden. Dit is zeker zo bij nieuwe eerste versies waarbij de betrouwbaarheid nog niet door heel veel gebruikers bewezen is. Dit gold ook voor de eerste R11.5.x en R12.0x versies.

Functionaliteiten die in een nieuwe release zitten, kunnen argumenten bieden om juist wel van een huidige versie te migreren. Let hierbij wel op dat de functionaliteiten vaak veelbelovend zijn, maar in de eerste release(s) van de nieuwe software niet altijd waargemaakt kunnen worden. Ook kan het zijn dat landspecifieke functionaliteiten -de lokalisaties- vaak jaarlijks aangepast moeten worden. Hierdoor kan het mogelijk zijn om binnen een release juist op de laatste subversie te gaan werken.

Versie upgrade versus subversie upgrade van bijvoorbeeld R11.5.x naar R12.x heeft een veel grotere impact dan een zogenaamde subversie upgrade van bijvoorbeeld R12.0.x naar R12.1.x. Belangrijk is dat een subversie upgrade zeker niet onderschat moet worden.

Het echte verschil tussen een versie upgrade en een subversie upgrade zit vaak in de techniek die gebruikt wordt. Bij een versie upgrade van R11 naar R12 is dit bijvoorbeeld het gebruik van een totaal andere leverancier en klantenmodel wat in R12 in het TCA model is ondergebracht. Tweede grote verschil is dat Oracle een BTW module heeft geïntroduceerd (E-Tax) die de R11 BTW codes in Debiteuren en Crediteuren vervangt. Dit betekent dat er veel veranderingen zijn in de tabellen en de samenhang van de tabellen waarin Oracle data opslaat. Bij een upgrade van R11 naar R12 wordt de oude structuur van gescheiden BTW in Debiteuren en BTW in Crediteuren overgenomen. Als er juist van de centrale E-Tax functies gebruik gemaakt moet gaan worden, dan moet er specifiek rekening hiermee gehouden worden anders is dit niet aanpasbaar!

Verder gebruikt Oracle een nieuwere versie application server om producten van bedrijven die men gekocht heeft in de loop van de tijd te integreren in de nieuwe Oracle versie. Deze versie gaat ook meer richting de look & feel van Fusion Applications. Hierdoor zien we onder andere steeds meer Peoplesoft technieken, kleuren en schermen in de standaard R12 versie. Dit betekent ook meteen dat het trainen van de huidige gebruikersgroep bij een upgrade een serieus deel van de upgrade moet zijn.

Veel veranderingen, ook ‘onder water’. In R12 is de toegepaste applicatieserver van een veel nieuwere generatie dan in versie R11. Veel meer schermen zijn in HTML ontwikkeld op basis van Oracle Application Development Framework (ADF). Ook zijn de rapportages door deze nieuwe techniek beschikbaar in BI-Publisher (XML Publisher) en hierdoor veel makkelijker in PDF of richting Excel te publiceren. Maar ook het datamodel van Financials helemaal aangepast is. Dit betekent voor gebruikers van datawarehouses die via ETL lagen transactiegegevens uit de E-Business Suite ophalen ook een significante aanpassing van de transactieloads. Daarnaast worden externe bronsystemen en interfacekoppelingen geraakt door de datamodel wijzigingen. Ook hier ontstaan extra werkzaamheden en dus kosten.

OC-C en F4F hebben als één van de eerste bedrijven in Nederland R12.0.4 in gebruik genomen. Hiervan hebben we veel geleerd en vooral over zaken die er fout (kunnen) gaan. Een subversie upgrade naar R12.1.3 is recentelijk uitgevoerd om stabiliteit te verkrijgen. Ons advies voor gebruikers die nog op R12.0.x van Oracle werken is om serieus na te denken om de overstap te maken naar R12.1.3. De business case hiervoor is eenvoudig te maken aan de hand van zaken die er fout gaan en blijven gaan in deze oudere R12 versies. Inmiddels is veel ervaring opgedaan met R12.1.2 en R12.1.3 door deze zelf uit te voeren. Deze ervaring passen we succesvol toe binnen klantprojecten.

Lees meer over: Implementatie & Beheer