12 Steps to 

R12
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!!!

Oracle Implementation Options

A typical ERP Deployment for any Global company typical consider as Global,
Regional or Local Deployment , which can be best understood as:

 Global ERP -Corporations with common business areas that are seeking to
centralize management and standardize business processes across geographies and
divisions
 Regional ERP -Corporations that operate in group of regional businesses which
need to meet unique requirements of particular markets and comply with statutory
or legal requirements
 Local ERP -Corporations with significantly different business areas having
significantly different business process requirements

Implementation : Reason why companies undertake

ERP?
This was a reader question : What are major reason, why companies undertake
ERP in there business Line?

Answering to this question is very subjective matter and if you ask to ERP implementor,
they can figure out n number of reason , but outmost these are very common:

1. A need to replace Outdated Business application

o As we required Common processes and procedures
o As need common shared data
o As Need common reporting
2. A need to consolidate IT Platform
o need to replace legacy system
o Need to reduce the IT cost(will see this in another post , how this affected)
o Need to connect with emerging technology gateway.

In simple words, these are major five reason why companies undertake ERP.

Integrated Financial Information

Integrated supply Chain Information(Customer Order Information)

 Standardize and speed up manufacturing operation

Reduce Inventory and decrease Procurement Cycle

Standardize HR Information