Archive for August, 2010

Looks like 12.1.3 is Imminent

August 20, 2010

With the rapidly approaching of Oracle Open World 2010, it looks like 12.1.3 is also rapidly approaching.

The Release Notes for 12.1.3 are now out:

12.1.3 Release Documents

Having a quick look through probably the most interesting change is in the Applications Technology area.

It’s a shame that as far as I can see (correct me if I’m wrong) but they haven’t put BIEE dashboards directly into any ERP screens yet (with half the screen in OAF Framework and the other half embedded BIEE), despite enabling the technology in the previous 12.1.2 Release. For me that is a little disappointing, but hopefully by R12.1.4 we’ll see that.

It is now possible to link to Oracle Application Development Framework (ADF) Release 11g applications deployed on an Oracle Fusion Middleware Release 11g container from the Oracle E-Business Suite home page. Each ADF application will have an FND Function of type ‘ADF’ defined for it. If such a function is granted to a user, then when the user logs in, the home page automatically builds a link to the external ADF application.”

This is an interesting note on ADF Integration to ERP. I’m left wondering if clients can finally move from OAF to ADF and still have the integration to ERP. The new functionality sounds as if it will allow you to call cleanly ADF Applications from the Oracle ERP homepage. It’ll be interesting to see this as it could provide those who do go to 12.1.3 another good staging point to Fusion in the future that pre 12.1.3 sites don’t have. I’ve talked to a number of people in Oracle over the last couple of years on when to start using ADF instead of OAF, but the message has always been to use OAF. Obviously this left me wondering for the future on “will I need to convert all these OAF applications in 3 or 4 years as I move to Fusion Apps”, so not an ideal situation. Maybe over the coming months the OAF/ADF will become clearer.

On the Finance, Procurement and HRMS there is the usual small changes here and there, additional changes for different countries, but nothing overall that for my organization is really ground-breaking. 12.1.1 and 12.1.2 had a lot more functionality that we would be interested in overall.

A short reminder that demo Vision instances are available and a whole lot more from the excellent Solution Beacon site, allowing you to test drive the new features for those with a CSI Number from Oracle, before you take the plunge. Currently up to 12.1.2, as of the time of this article (20th August 2010).

R12.1.x Vision Instances

Hopefully we’ll all start to see the new mythical Fusion Apps over the coming weeks.

Footnote: A short footnote courtesy of Steven Chan’s excellent blog that 12.1.3 is now available. See the latest at:

http://blogs.oracle.com/stevenChan/

  • Oracle E-Business Suite Release 12.1.3 Release Update Pack (Patch 9239090)
  • Oracle E-Business Suite Release 12.1.3 Readme (Note 1080973.1)
  • Advertisements

    12 Steps to R12

    August 16, 2010

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

    About the Author

    Iain Robertson has been using Oracle Applications since 1990. Over 20 years in Oracle ERP starting in MPL7 through MPL8, 9.x, 10.x, 11.x and 12.0.4. He is currently working as a Program Manager running a team of 90+  in Asia Pacific, migrating complex Legacy Systems to Oracle Applications – Procurement, CRM, Financials, HRMS and Projects Suite. He also runs the Oracle Support Team. He has experience across Asia, Europe and the US, specializing in R12 and building world-class teams in Asia-Pacific providing Global Support.

    You may contact Iain at irroberts@hotmail.com

    Blog:               https://oracleprophet.wordpress.com

    LinkedIn:        http://www.linkedin.com/in/iainrrobertson

    #1 IT Service in the Company – 2008

    Oracle Innovation Award Winner 2009 – ERP

    Oracle Session Presentation Winner – Oracle Open World 2010

    R12 Successes


     

    Reference Material

    To those authors who published articles I would like to give credit, for making an almost impossible R12 Upgrade possible by kindly sharing their knowledge, their successes and their failures for the benefit of the entire Oracle Applications community.

    R12 Resources

           OAUG Website

          Chris Warticki’s Blog – EBS R12 Support Resources – Consolidated

           Oracle Applications Upgrade Guide: Release 11i to Release 12 (B31566-01)

           Upgrade Manual Script (TUMS) – Patch 5120936

           Metalink Note: 580299.1 – Best Practices for Adopting Oracle E-Business Suite, Release 12

           Metalink Note: 394692.1 Oracle E-Business Suite Upgrade Resources

           Metalink Note: 562887.1 R12: Helpful Tips for a Successful R12 Oracle Payables Implementation

           Metalink Note: 437422.1 R12 Troubleshooting Period Close in Payables

           Metalink Note: 73128.1 R12 Troubleshooting Accounting Issues

           There are many articles from Oracle Open World in 2008/2009 for R12 available at Oracle Open World Tools -> On Demand:

            http://www.oracle.com/us/openworld/index.htm

           Oracle Financials Applications Blog – R12 Lessons Learned

           Analyzing, Planning and Executing an R12 EBS Upgrade

           Rochester Institute of Technology – One Year after Upgrading our Oracle E-Business Suite from 11.5.9 to R12 – An Update 

          Talk to other companies that have done R12. Use the communities and forums.