12 Steps to R12

Date: 16th August 2010

During the Oracle OpenWorld 2009 in San Francisco, the average

conference session started with “How many of you are on R12?” The
show of hands was no more than 5% in any given session. Recent
research suggests only 5% of companies are on R12 as of mid 2010.

Many organizations will be starting the journey to R12 in 2010, given the
end of Premier Support for 11.5.10.2 in November 2010. Our
organization successfully completed an Oracle E-Business Suite Release
12 Upgrade (R12) in August 2009. This article shares our experiences so
that readers can benefit from what we did right and avoid what we did
wrong.

Following are the twelve steps our organization followed during its R12
upgrade, along with suggestions and insights that others might use in
their own upgrade projects.

Step 1 – R12 Study

It is recommended that before doing an R12 Upgrade, you do an

assessment/study to determine the impact an R12 would have.

Get a little funding, do test upgrades, an impact analysis, try the new
functionality and then go for full funding of the project. This leads to a
highly informed and carefully scoped project.

Many companies got burned very badly by early adoption of R12. If a

study had been done first, I doubt they would have upgraded so early –
saving a lot of time, money and heartache.

Step 2 – Business Case

The key foundation to any project is a good Business Case that everyone
agrees on. It gets the funding, visibility and users onboard. Emphasize
the benefits of improved Oracle Support and significant new functionality.

I would recommend that you keep the R12 Upgrade as much as possible
a Technical Upgrade (utilizing new functionality where appropriate), but it
is a daunting task and the fewer new things thrown in the better.

Step 3 – Planning and Preparation

There are a few things you should check prior to recruiting an upgrade
team.

Make sure you have the hardware to do the upgrade. Your typical
upgrade will require an extra 6-12 Instances and you still need 11.5.x
instances for ongoing production support. Prior to bringing any expensive
external resources in ensure you have R12 Instances to work on.

Write a detailed project plan. Figure 1 shows a very high level approach.
Doing an upgrade is not rocket science…..the devil is very much in the
detail. Remember you will need to schedule time with many different
groups – Legacy, Data Warehouse, Business Users, DBA, Server Team
and the ERP Team. During an Upgrade all major initiatives will need to
stop to allow you to focus on R12, so be sure to set user expectations in
advance.

Recruiting – Each company varies on how they staff an upgrade. Unless

you have a very good in-house team, you will need help. Consultants will
save you time and money. R12 has a lot of new modules and
functionality, so we brought in expertise. It really helped and knowledge
was transitioned to our internal resources.

The DBA Team will take between 2-4 weeks to get an R12 instance,
depending on their skills. Put this into your plan.

Doing a PM.010 – Project Management Plan helps you to focus, together

with a solid Work Breakdown Structure. Together with a good Risk
Register (brainstorm with your team) you’ll protect yourself from some of
the pitfalls.

R12 is a lot bigger than any previous upgrade in Oracle ERP. Your plan
should reflect this. Planning is everything for a successful R12 Upgrade.

Figure 1 – 12 Steps to R12

Step 4 – Review and Design

A short amount of time reviewing what you have and what is new will
vastly improve your upgrade. The Functional Team should use the R12
Upgrade Guides to identify the relevant changes in Functionality.

The Functional Team should also try to identify with the Business and
Development Teams, customizations that can be removed with new
functionality provided as standard. A little time doing this could bring
significant savings.

There is significant new functionality in R12 and the Functional Team

should review with the Business to show the possibilities. Keep a balance
– the focus should remain on the R12 Upgrade, not new functionality.
The Functional Team should also be writing new MD.050 Functional
Designs – there will be customization needed in R12 and other Functional
Designs may need updated.

Working closely with Functional Team, identify the core customizations.

Once you prioritize the customizations you have a solid basis for moving
into the Build and Test Phase.

Step 5 – Build and Test

Functional Stream

The Team should prepare high level Test Plans, working closely with
Business. The Test Plans should be comprehensive and signed off. This
should cover all Test Scenarios across all Business Areas, including
external systems.

Once the Test Plans are signed off, ensure that comprehensive Test
Scripts are written. As these are being written, the application should be
tested initially to throw up the bugs. The earlier you find bugs the earlier
you get them to Oracle Support to get fixes.

Technical Stream

The Technical Team MUST have a customization register. This can be

used as a very good monitoring tool. If you don’t have this, how do you
know what to upgrade? Customizations should be upgraded methodically
according to your plan from the Design phase.

Technical Summary – Our Customization Upgrade Impact

General Ledger 80% Minor issues – Set of Books ->Ledger_ID

Self Service 30% MOD*PLSQL Dessupported

Accounts Payable 30% Change of Database Structure

Payments 60% Upgrade Check Formats

OA Framework <5% Minimal Issues

HRMS <5% Minimal Issues

Payroll <5% Minimal Issues

Procurement <5% Minimal Issues

Receivables/Fixed Assets <5% Minimal Issues

Source Control

This is essential so if you are not using any tools, you are doing
something very wrong and risking your Production System. Open Source
tools such as Subversion are ideal.

Patch Management

One key consideration is your approach to patches – aggressive or

conservative. We went on an early version of R12 (released one year
previously) and we choose conservative thinking it would be relatively
stable. Towards the end of the project, we saw stability still had not been
reached. We moved to a highly aggressive patching strategy that really
did get us to stability, although it was extremely painful with multiple
regression tests and carrying considerable risk.

Reviewing Metalink is important – when new RUP’s (Roll-Up Patch Sets)

and CPC’s (Critical Patch Sets) are released, you have a very important
decision to make on whether to apply. If your well into your project, the
advice I would give is not to apply unless required….patches cause a lot
of issues. If the patch is newly released you’ll be the poor guys finding all
the new bugs. Leave that to someone else.

Obviously if you have critical errors, pile the pressure on to Oracle

Support to provide single patches. At some point you are going to have to
freeze patches, otherwise you will never finish. Learn to work with Oracle
Support and Oracle Management regionally to resolve issues.

Patch Management is critical and Oracle has some great tools for Patch
Assessment under System Administration – these will allow you to make
informed judgments on whether to apply patches or not. This will show all
the objects changed by a patch – with that list your technical people can
give you well informed advice.

Strong Patch Management is critical to any R12 Upgrade. Lose control on

this and you lose control of your entire project.

Step 6 – Internal User Acceptance Test

An Internal UAT is basically a UAT but it is carried out by the R12

Upgrade Team, not the users.

Focus strongly on key functionality – if one thing has to work on Day 1 of

Go-Live it has to be the key stuff – entering invoices, running a payroll,
etc. Too many companies focus too much on the peripheral and not
enough on the core functions. That will end in tears.

Given that some modules are going to be delivered before others into
UAT, you may want to do this staged. It’s not ideal but it does compress
the overall project time. You will have problems on Payables, and should
that hold up your whole HRMS track? I would argue no. And I am sure
some will disagree. But be pragmatic on the area of UAT and use your
judgment.

Test the entire ERP and external systems such as Legacy, your planning
systems, your banks or other external systems that interface to
customers/suppliers/etc. All bugs should be recorded.

A few other tips:

Simulate a close on your R11.5.10

Reconcile 11.5.x and R12.x

Simulate transactions half way through workflow

Check your banks migrate correctly

Step 7 – User Acceptance Testing

Another clone of Production should be taken and all customizations/setup
applied. If you have not been keeping deployment registers, setup
documents, etc I would strongly suggest you start doing so. Give the
users plenty of notice of when the UAT is coming and make sure you
clearly set the expectations.

UAT kickoff meetings should be held and contact lists given to users. Your
team will need to work hand in hand with the Business Users to co-
ordinate the UAT. It’s going to be a lot of work with new, unfamiliar
screens and quite a few complaints, no matter how well you’ve done till
now. The Test Plans and Test Scripts should have been agreed months
ago, with full review and signoff which should lessen the surprises (and
complaints) users may have. Work closely with your users throughout the
project from project initiation to way after go-live. That will lead to better
relations and when you do encounter problems; users will go a lot easier
on you, because you kept them informed right?

One trick here is to put the Test Plan on a shared drive and ask the user
to mark Pass/Fail/To Test as they progress. As a Project Manager you can
then review and summarize progress easily. Delivering some modules
into UAT before others may be an option if you want to progress quicker.
Others prefer to deliver the entire UAT. What I have found is that by
progressing some modules quicker, it gives the project momentum and
when you put out weekly progress tables to users, they don’t want to be
last to finish. A little bit of Psychology certainly helps when doing an R12
upgrade.

Make sure all Test Scripts are tested. Make sure Month End and Year End
are simulated, with proper reconciliations. Make sure all the systems to
and from Oracle ERP are tested and continue to work with R12. Make
sure integration between modules is smooth and working – organizing
this across departments is tricky. A UAT room for this can be handy.
Providing simple refreshments can create a good ambience and
encourage your testers to work for you.

Record all issues and bugs as you go. Monitor closely and ensure that
when your users are doing UAT, your R12 Team is there to assist. Some
areas may need twice weekly meetings on certain modules with the
Business Users. This will help to manage difficult UAT areas, stop user
frustration and make the UAT a little less painful for all. We did this on
Payables in particular. It worked extremely well.

One point – be pragmatic on UAT. Remember users have full-time jobs so

doing a UAT is a big favor and usually a lot of extra work. Avoid being too
pushy especially during stress points such as month-end closing and
Payroll – that will simply be counter-productive.

The UAT can also double as a training ground, but do also be prepared to
give additional training, especially in the areas of AP, Banks, Payments
and Subledger Accounting/Reconciliation as there are significant
differences here.

Step 8 – User Sign Off

On completion, ask the head of each area and other users to sign off a
standard Acceptance certificate. As you achieve sign-off let everyone
know – again it helps to push the other Business Areas that have not
signed off. I found weekly newsletters (just a single page) kept everyone
onboard. Openness and transparency is the key.

Step 9 – Transition Planning

As UAT goes on, you should be planning what will be a very complex and
difficult cutover. The team should also be doing rehearsals by taking
copies of production, upgrading, deploying, setting up and testing. All
bugs should be recorded.

You should have deployment registers for each module, including tasks
for DBA, System Admin, etc. These should be very detailed and concise.

Review the deployment registers and figure out what can be done in
advance of R12. This saves time and will ease the stress of the upgrade
weekend.

Call meetings with the users and make sure that the cutover is
clear. The users will lose Production for a few business days, unless you
do it on a holiday.
We did the closing in R11.5.10 just before cutover, closing down all
transactions, etc. Why? There were a couple of reasons. If data is left
open in R11 (say unaccounted) it will give real problems in R12 Secondly
it allows you a whole month before your first closing in R12 to resolve
issues.

Get a register of who needs does what during cutover and ensure work is
balanced. Ensure every person knows their role in the cutover.

Deployment of code is a significant task. If you have used Subversion (or

another Source control system) then you can grab all changes and give to
the DBA’s. A lot can be automated and this will save a lot of time on the
cutover.

Talk to Oracle Corporation and make them aware of your key dates,
cutover, month end, payroll, etc. They can get you critical support
management over that time.

Try and do as many rehearsals as you can whilst users are doing UAT.
The closer the rehearsal is to an exact recent copy of Production the
better. We repeatedly cloned production for three weeks prior to
Production and checked our deployment.

Make sure you do patch reconciliations between your UAT and Rehearsal
databases on a consistent basis. Otherwise you may be testing on
completely different Patch Sets and your entire UAT would be null and
void.

As Project Manager, you should be writing a PM.030 Transition and

Contingency Plan that covers all the angles.

Make sure you go to the Change Control Board, publicize on your website
and make sure you tell every single person that needs to know that
Oracle Applications will not be available. The Cardinal Sin – missing
someone out.

If the cutover fails all the hard work of your team will have gone to
waste. Do you really want to be telling everyone publicly (including
Senior Management) that the nice, shiny R12 that was promised isn’t live
and that you had to pull out the whole upgrade at the last minute due to
your bad planning?

Rehearse, Rehearse, Rehearse……

Step 10 – Cutover

A cutover generally takes place over a four day window, depending on

your database size/speef of servers/etc. Holidays are ideal but make sure
you tell Business well in advance if their key system is going to be down
during business hours. Total Upgrade time took 96 hours, working around
the clock.

Users should run key reports on R11.x and then run the same reports
immediately after on R12.x. Your functional team should also do a mirror
reconciliation exercise quickly during the cutover. Also keep a reference
environment copy of your R11.x production.

Wednesday evening and Thursday were days for the actual Upgrade,
Friday the Upgrade Team rolled in to do setup, customizations, etc.
Saturday and Sunday were for testing with a go-live decision on Sunday
evening. As we were moving servers, our contingency was simple; if the
cutover was a no-go we simply turned our old server back on……Don’t
repeat the errors you made in rehearsals, keep a log of everything that
failed and make sure it doesn’t happen on your go-live, as you simply
won’t have time to troubleshoot.

Be very careful that all transactions are accounted, workflows complete

(as much as possible), payments complete. Review the Best Practices
from Oracle for more detailed advice. If you don’t do this you will hit
serious problems.

Cutover is a stressful time no matter how well planned. The Project

Manager should ensure everyone stays calm, ensure work is balanced
and avoid burn-out for those working shifts. Organize some food during
the cutover, step in to calm any friction quickly and monitor every last
aspect of progress.

Step 11 – Critical Support Cover

There are going to be problems on anything of this scale. That’s a given.
Have all teams on standby so that when issues arise, they can be
addressed. As soon as possible clone production to a test system and
simulate the payroll, closing and other key events in advance.

Before the Go-Live, set the expectations of users. If you do this the user
community and management will cut you a little more slack and be more
understanding of issues encountered. A little bit of psychology and
transparency will go a long way to making your transition a lot less
stressful.

One tip that is useful before go-live: Brief the Helpdesk on how to take
the calls as you go live. Brief the users on how to log issues. Make sure
there is strong reporting available to you in real-time showing all issues.
Monitor this religiously. Make sure the escalation and support teams are
in place, so calls are not lost or delayed. This will ensure you have a very
strong support structure to deal with the significant number of issues you
will have, irrespective of how well you did the upgrade.

No-one will remember all the hard work you have done to get here if
major issues are not addressed quickly. If you manage problems well and
quickly the Upgrade will be remembered as a huge success. If you don’t,
you’ve just thrown away thousands of hours of your team’s reputation
and hard work.

Strong and very well managed Critical Post-Production support is

everything in an R12 Upgrade.

Step 12 – Post-Production Support Cover

After the first month end close you should be able to move to a more
standard support footing.

Don’t celebrate the day you go-live. It could get extremely embarrassing
to celebrate Mission Accomplished and then hit major problems, right?
We left the celebrations for 6 weeks. If you do an R12 Upgrade, you
deserve a big party. R12 is the most challenging upgrade you will ever
have done in Oracle ERP.
Those who fail to plan, plan to fail. Good Luck!!!