Posts Tagged ‘Subledger Accounting’

Halloween – A Time of Ghouls, Ghosts and R12 Upgrades (Pt3)

October 31, 2010

Welcome back to the R12 Upgrade House of Terror.

All I can promise you is pain, heart-ache (that Oracle Support girl for the AP Trial Balance broke mine…..ahhhhhhhhh) and impending doom. Abandon all hope on your R12 for those who read on……..

So you’ve been mad enough to start an R12 project (they’ll lock you up in the asylum they will !!!) and you’ve made it through Implementation (designing any new stuff, build, test, UAT, etc) and you are sitting there smugly thinking you’re smarter than your average 5th grader and that this column was just scare-mongering……..Well lets go to the Transition Phase and see how confident you are………

 Cutover is complex

Deployment involves high number of objects

Deployment involves significant application setup

Deployment carries high risk areas

Users are not familiar with the new software

Large number of users require training

Users are distributed across countries

Help Desk Staff are not trained to take calls

Transition is poorly documented

Transition is not rehearsed

Change in Business Procedures for R12

Before you start the cutover, just wondering if you actually trained all your users? Yes R12 is mostly the same, but there are significant variations between R11 and R12 in Payments, TCA, SLA, etc. Now if those are spread across countries, it’s going to be even worse. A new system with new features suddenly appearing will lead to a lot of angry users, all wanting to talk to you on Day 1 of R12 as you are inundated with other more serious issues……..Now I went through four audits on my R12 and got a clean bill of health on all, except for training (even though we did some). The auditor did a survey and the users said they would have liked MORE TRAINING. But the products almost the same I said bar a few key areas as we were doing a Technical Upgrade !!!!!!!! I got burnt at the Halloween stake on this – OK ever so slightly singed. Don’t make this mistake. At least offer some training on delta differences and some educational classes with no commitment to implementing (get your lawyer to write the disclaimer) new functionality.

Has anyone told the Helpdesk of your R12 transition? Has anyone told the business they will lose their systems for 4 days (weekend, plus two working days). Has anyone told the external users or put out appropriate announcements? Are there key business activities that expect to run during your upgrade? Have you scheduled your upgrade right in the middle of these? People are going to be seriously upset if payroll is delayed for your upgrade. Or month end closing is delayed and you have serious problems with your new R12 that goes live right before the preparation of those financial results. Wondering if you told your corporate website team that pulls out summary information from ERP to display to your company website that ERP won’t be available over the transition? Or how about the legacy team that are still sending you files to interface into ERP? I know you are feeling pretty insecure now. I guess you are wondering “Have I missed anyone in the announcements……”.

Cutover is a nightmare. Get this wrong and you see your entire project collapse in a pile of dust, on day 1 of Production, with the Board asking why your business has ceased to function and lost 5M US. Pulling the transition on R12 at the last minute is really bad, but even worse is going live and then finding out you have serious issues……..Either has a good chance of ending your career.

Has everything been tested? Has every bit of code your about to deploy to Production actually really been through UAT (or did the developer slip in that one last easy fix with no testing?). Does your Application Setup really reflect the setup you tested? Did the Consultant complete the BR.100 before he left for a contract paying 30% more? Can anyone actually follow that BR.100……?

So you have a thousand customization files (actually isn’t a lot when you count Java files, setup, etc). Have you ever taken that as a single software release and had your DBA’s (not your developers that know to run script 2 if script 1 falls over and hack script 3 to make it work, without anyone finding out) and applied to an exact clone of your Production system and had a 100% success rate? Have you repeated this multiple times as you roll towards the go-live date, just to make sure that any changes between the time you last ran it and any updates to Production didn’t cause any adverse impact? Are you sure that the DBA’s can run all your customization deployments in a very short-time frame. (Your typical go-live window is a maximum of 4 days with two of those the weekend, after that your business will scream if you go one hour over). Is your deployment manual and if so, will the DBA do the same steps each time? If your deployment is automated will it actually work?

We had 600 application changes. Have you ever checked how long it would take to deploy all of those changes? Have you ever done an entire setup and checked all the setup was valid and tested properly? Have you thought of the issues of letting knowledgeable people do the setup in Production in terms of access, SOX, etc? If new people need to do the setup, as the project team cannot have access to Production, are they familiar enough not to make mistakes? Have they ever practiced the setup on an R12? Interesting how long it takes to carefully setup and check 600 application setups. Just wondering if you ever thought how long it actually takes to setup 600 application setups for a single person. Do you know it’s impossible to do that setup with one person? Have you ever bothered to do a careful review of all setup, access needed and then balance setup streams across different people to make it achievable in the very short transition time the business has granted you whilst still ensuring segregation of duties, SOX compliance, etc?

Have you ever considered setting up some functions, menus, etc in R11 BEFORE you go-live. Or some new program definitions? Or perhaps having these as Loader files, so you can load them instead of manually setting up? Of course if you load them, have you checked that the developers have generated these LDT files correctly?

How many minutes will the R12 Upgrade run on Production hardware? (I ask for minutes because you should know very precisely the estimated time of this – if you don’t you are in serious trouble. For info an R12 will run for a very, very long time indeed, even on a small ERP database.). Have your DBA group ever run an R12 Upgrade with no failures? How long will it take to upgrade the Technology components or database? Have you ever seen a detailed step by step upgrade document from the DBA Team? Are there any hot wiring the DBA team apply during the upgrade due to known failures? Are you aware of these known failures and the implications? Do you know that an R12 Upgrade will require some very serious shift working? Do you know that your DBA’s will be seriously burned out as they have the very first task in the actual upgrade of running the hundreds of thousands of scripts that the standard R12 upgrade runs. And they need to actually be awake and watch this constantly, because if it falls over, you don’t have the time to lose 8 hours on an upgrade weekend…….

Wondering if you’ve actually even got a transition plan? Have you got an hour by hour schedule, with milestones and an effective method to monitor setup, customizations, actual upgrade, etc? On an R12 upgrade transition, you have no slippage time for anything. If you slip, the team will get stressed, you’ll get stressed and mistakes will be made.

Bottom line is have you REALLY rehearsed an R12 cutover BEFORE you actually do it? Do you really feel confident that first time you do it for real will be on your Production system……….if so you must be a clown……by the way do you think the McDonald’s clown is intrinsically evil????? (My Attorney has advised me at this point to clearly state that is a question and in no way implies anything on McDonalds whose food I have been legally advised to state I love and the picture below is in no way related to said company).

If you take a look at the Oracle Upgrade manuals, it’s interesting how many pre-req steps potentially have to be done. Ironically if you miss some of these you can have major support issues going live. I wouldn’t leave any Payments in the middle of process. I’d be carefully checking the effect of an upgrade half way through each of your workflows. Is there any effect on transactions that are left half completed? Do you even have these in your cutover procedures and does everyone in the Business know from your carefully documented plan exactly what their responsibilities are prior to bringing down their R11 ERP. If you (or the Business) makes mistakes here, you are in real trouble. Do you have scripts to check everything has been accounted, no payments are sitting halfway or are you just relying on your business to do the right thing with no checking whatsoever…….Just to add a little time pressure, your DBA’s will be screaming at YOU if you go one minute over the agreed time to shut down R11 and hand it to the DBA team……..of course you’ll have to herd dozens of business units across 27 countries to complete all activities before that time…….but then they want to do their business not your upgrade……which leaves the DBA’s screaming at you…….(The DBA’s will be working all through the night, so every hour you delay, means an hour extra in the middle of the night so a little empathy for them here folks……..Show them you care for their welfare….at least till your upgrade is over. Alternatively take the selfish approach that the DBA that is working all night might be the same one running your customization scripts after two hours of sleep because of your poor planning that could wreck your upgrade when he makes a serious mistake because he’s so tired……….)

Have you made any plans to backup the original system? What are your fallback plans if the upgrade fails? When will you be prepared to pull the plug and under what criteria, over the transition cutover to R12? Who is going to take responsibility to give the green light to go live? Will the senior management even be there at the weekend to make that decision?

Just wondering if you told your team and others (Unix, Email, Legacy, etc) that they would need to work some very stressful and long hours over the cutover weekend. Wondering if any of those key staff have their holidays planned…….?

Have you made plans to clone and test the actual R12 on the cutover weekend? If not how do you know all your setup, customizations, etc actually were promoted cleanly and your R12 actually works? You will need a large team to test in such a short period of time. Do you even have a cutdown test plan to make sure you hit the key functionality? Have you got all this planned? Probably not…….And if you find stuff missed, do you have a proper controlled mechanism to track it, test it and release it to Production in a horrifically short and highly pressured weekend in a safe manner?

What’s amazing is that everyone plans a transition, but no-one actually thinks about turning on the R12……….when you enable the workflow and the concurrent managers are you just going to open the tap, or are you carefully going to release production jobs and monitor. I’ll tell you that your single most stressful time is when you commit to switching on these elements over the weekend. I bet you that your heart will be pounding and you will be sweating at this point. The entire company ERP and Business hangs on your Go or No-Go signal. Once you’ve done that, there is no turning back, there is no backing out and you are on R12. At that point if you’ve got it wrong, you’ll be looking for another job. (Doesn’t that picture below remind you of your boss when it all goes wrong……?????). I wonder if that Oracle Support girl I dealt with for the AP Trial Balance wore red lipstick…….ahhhhhhh……..

So your live, but it’s not over……..

Serious Outages can occur

Lack of Staff to address serious support issues post go-live

Patches are required after go-live

Are you ready for serious outages? Did your transition plan have proper contingency plans for these events? If not exactly what will you tell the Board and the Business?

Do you have the appropriate staffing plan to handle what could be a very rough few days (or weeks) or months? An R12 will almost always lead to a spike in calls. Are you ready? Did you bother to give your people proper notification that they may be required to work late nights and weekends for the first few weeks after go-live? Or is it just a line item on your plan that you didn’t bother to communicate?

Did you re-synchronize all of your ERP and Legacy systems in terms of interfaces? Some of these integrations may require manually running interfaces to catch-up with transactions for the days you were down.

With major business events such as payroll and closing, do you have any plans to clone and rehearse these events, prior to these happening? Now if you can clone and simulate an R12 closing after you are live, but before the closing happens, it’s better to find out serious problems and have a few weeks to fix them right? (Of course this has you wondering if you should close in R11 and then immediately move to R12, but of course, then your Financial reporting would be straight after go-live, so you can’t win right?)

Have you got any plans for patches after go-live? What happens if you really need to apply patches? Are your project team still there? Did you set business expectations just in case? Always better to make business aware of the real risks inherent in an R12 Upgrade. That way, they’ll be incredibly happy if you manage to get it right.

I hope you remembered to get before and after reports from key areas, such as your AP Trial Balance (that Oracle Support girl was just so nice, ahhhhhhhhh), GL Trial Balance, etc. And keep a copy of your Production database on R11, whether on tape or disk. When the auditors come and take an interest in it, as they will it would be unfortunate if you’ve not done this and it causes issues with your auditor’s signing off your company accounts.

Also before you go live just have a quick review of JVM sizing and parameters. If you fail to tune and size this properly you could see your Applications crashing, intermittent crashes, etc. Getting your JVM sizing wrong leads to absolute nightmares……..Ask your DBA’s “Have you size the JVM’s and if they say what’s that, start to worry……”. If you have too many users and not enough JVM’s and OACORES then BOOM !!!!!!!!

Finally is there monitoring of key components in place? Are you touching base with all the areas of Business (and Legacy and Web and email and and DBA and Unix and other teams). Are you even aware of major production issues or is your Production setup so poor in terms of support that you’ll be the last to know……..

And lets break for another movie recommendation. The single scariest movie I have EVER seen. This was the 1970’s television mini series called Salem’s Lot. It is absolutely terrifying. Get it on DVD….it’s one creepy movie from the Master of Horror Mr. Stephen King. I saw this when I was ten, and I didn’t go out for weeks after dark……It’s a classic ten out of ten movie. But REALLY TERRIFYING.

This isn’t an exhaustive list of what can go wrong in an R12. Now note this article has been written in a strong manner to scare the crap out of you because if I do that then you’ll start to take every last point out of this article and make sure you’ve covered it. Make no mistake – R12 Upgrades are a serious risk to your career. (However don’t let some consulting company come in and scare the crap out of you. They are in it to make as much money as possible from you for an R12 by scaring you as much as possible. I write these articles for FREE and hope people can avoid the mistakes that I and others made in our R12 Upgrades). If you read this article and take everything on board, you’ll be strongly versed in R12 risks and be able to evaluate what these consulting companies are telling you and separate the fact from the fiction…….

And a final note. Premier Support for 11.5.2 ends in November 2010…..that gives you about a month left……Interestingly you also need to have minimum baselines in place for R11 if you want proper support from November 2010……….And will you get hit by fees if your still on R11 in November 2011??????

Have you read Metalink Note 1178133.1…….

“Starting on Dec 01, 2010, Oracle E-Business Suite customers on Release 11i10 will only receive extended support for new bugfixes as described in My Oracle Support, Minimum Baseline Patch Requirements for Extended Support on Oracle E-Business Suite 11.5.10.”

That’s a lovely little bit of legal small print from Oracle with major implications for you………Getting to those minimum levels will be enough to “persuade” most customers to jump to R12 instead.

It’s funny also that so many people don’t think they can start doing preparatory work in R11 that will greatly ease R12. Have a look at the references below. Work spread over R11 and R12 will greatly ease your stress in the R12 Upgrade itself, as you’ll have less to do. (Did you know Solution Beacon even has Vision instances you can play with for free, even before you install an R12 in your company’s test environment…..)

Let me tell you briefly our R12 story. We had some very serious problems with quality (12.0.4 RUP5) – an early R12 release in many respects. However despite that we got through a Finance, HRMS and Procurement Suite R12 Upgrade across 20+ countries with strong planning. Our transition finished 30 minutes ahead of the planned 96 hour time window (I wasn’t kidding when I said you should know the transition in minutes…..). Yes, I was terrified when I made the call to go-live. But due to all the planning and a great Project team, we went live with no major issues on 3rd August 2009 and I went home at 5PM two days after go-live (And for the cynics, no I didn’t spend the first two days constantly in the office 48 hours straight…..I got home at a reasonable time the first two days as well). We cleared Payroll, breezed through month end and went live on two Payroll rollouts to two new countries one month after go-live.

Of course now I’ve told you all the risks, well you’d be a fool to actually fall into those holes right? Take this article, make a list, make sure you cover each and every one. Then you’ll make your R12 a huge success.

An R12 is certainly a very achievable project, with significantly reduced stress and risk, if planned correctly.

Hope I haven’t scared you too much……..

Enjoy your Halloween.

References

As always, my appreciation goes to the kind authors and contributors of the following articles and resources. Some of these are especially note-worthy, because those people are putting out their failings (as well as successes) on R12 in a very public and open way, for the benefit of those about to travel the R12 Upgrade road.

General Blogs and Websites

OAUG Website

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

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

Oracle Financials Applications Blog – R12 Lessons Learned

Analyzing, Planning and Executing an R12 EBS Upgrade

Steven Chan Blog

Risk Management: Tricks of the Trade for Project Managers (Rita Mulcahy)

My example of an R12 Risk Spreadsheet (Excel 2007) – Available on Request

 

Metalink

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)    

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

Metalink Note: Oracle Support Upgrade Advisors (250.1)

                             Tech Stack                     Note 253.1

                             Financials                     Note 256.1

                             HRMS HCM                    Note 257.1

                             Manufacturing              Note 258.1

Metalink Note: Extended Support Patch Level Verification in Oracle E-Business Suite Release 11.5.10 (Note 1178133.1)

Metalink Note: R12 Upgrade Considerations by Product (Note: 889733.1)

Oracle E-Business Suite R12.1 Financials Pre-Upgrade, Setup and Operational Tips (Note: 1104163.1)

Oracle E-Business Suite Release 12.1 Information Center (806593.1)

Database Preparation Guidelines for an Oracle E-Business Suite Release 12.1.1 Upgrade (Note: 761570.1)

Oracle Applications Installation and Upgrade Notes Release 12 (12.1.1)

R12: Period-End Procedures for Oracle Financials E-Business Suite (Note: 961285.1)

Oracle Open World 2010 – On Demand

For those with access to Oracle Open World 2010 On Demand there are good references at http://www.oracle.com/us/openworld/index.htm

Mission Impossible: Oracle E-Business Suite 12 Upgrade on 3 Continents in 6 Months

Success with Oracle E-Business Suite Release 12.1.2 Upgrade Drivers

Algar Telecom Upgrades to Oracle E-Business Suite R12   

Get Ready for Oracle E-Business Suite Release 12.1: Tasks to Complete Now

Oracle E-Business Suite 12 Upgrade : Best Practices to Obtain Business Value

Planning your Oracle E-Business Suite Upgrade from Release 11i to Release 12.1 (Superb presentation – highly recommended)

Oracle E-Business Suite 12 Upgrade: An Easier Ride on Nine Miles of Bad Road

Oracle E-Business Suite R12 Upgrades: Have you Thought about the Details?

Real-Time System Assessment of Oracle E-Business Suite 12 Upgrade: Case Study

And finally talk to other companies, use forums, other areas (such as http://www.linkedin.com) and make contacts with people that have done R12. This again will help you considerably on your R12.

Footnote:

Some of the great graphics were the work of:

WWW.MYSPACEGRAPHICSANDANIMATIONS.COM

Advertisements

Halloween – A Time of Ghouls, Ghosts and R12 Upgrades (Pt 2)

October 23, 2010

So it’s heading for Halloween. Only a few days left……..And looks like you’ve come back for the 2nd part of the R12 Halloween Upgrade. So I guess you don’t scare too easy? Prepare to be afraid. Prepare to be very, very afraid.

So after a whopping amount of things that can go wrong just in the initial stages of an R12, we can finally talk about the actual R12 Implementation in terms of analyzing, designing, building, testing, new functionality, etc. It’s amazing so much can go wrong BEFORE you even start……..here’s a previous Project Manager that was running an R12…….(he’s the guy 3rd from the right, the one 2nd from the right did the R11 Upgrade and the one on the right did the initial ERP implementation….isn’t Oracle ERP pretty unforgiving project wise……)

Here’s a few things on Implementation to help you lose sleep.

Applications do not provide a good fit to Business Requirements

Subsequent Analysis during the Project drives Significant Change

Not possible to achieve a consistent Business Process across all units

Some modules are largely custom built

Large number of customizations

Undocumented customizations

Lack of development standards

Information is confidential

System Integration is complex

System integration is high risk

System integrates with non Oracle technology

Complex Oracle Application Configuration Management

Complex custom development configuration management

Poor Technical Designs

Customizations are delayed or lacks resources in Development Team

Functional Designs are late or incomplete

Technical Designs are late or incomplete

Patch Management is poor

Complex Setup

Testing misses requirements or scenarios

Testing is incomplete by Project Team

Testing is incomplete by Business Team

Testing is delayed or lacks resources for Project Team

Testing is delayed or lacks resource for Business Team

Testing integration is delayed by dependencies

Legacy data is of poor quality

Legacy Data requires data cleansing

Legacy Data has complex structure

Legacy data involved high data volumes

Changes in Legacy System required

Oracle does not have interfaces to support conversion

Oracle uses complex API’s for conversion

Ignore the Legacy Conversion stuff. I use this spreadsheet for more than just R12 Upgrades…..

Now if you’ve ignored the advice to aim for a R12 Technical upgrade, then you may find yourself knee deep in very long, difficult and time consuming business requirements, business change, etc. On an R12 Upgrade, trust me just don’t go there. Keep it clearly 100% out of the scope of the project. It can wipe out your project unless absolutely forced to. Which brings us nicely on to R12 Oracle Payments.

Payments module is a re-implementation. This will take some adjusting as it looks nothing like the R11. With this and other new features, you run the risk of not fitting to business requirements, or wanting new processes or wanting changes. The problem is if you show the new stuff (and with Payments you have to….) you could have significant change in your project scope and therefore significant risk. If you don’t show the new stuff you are going to be accused of not showing it, not training users, not taking advantage of the “amazing” new functionality, etc. So if you show it, you are screwed. If you don’t you are screwed. For me R12 is complex enough to pull off without adding anything other than like for like. New functionality for us could wait (and it did in 99% of cases, despite some fairly tough fights).

Of course if you are rolling out R12 across multiple countries, then it’s even worse to agree all the new functionality, legislative stuff, etc.

Then you get into your biggest nightmare of all. Customizations. Imagine someone having a decade to write customizations on R11. Imagine no discipline, documentation or standards. And you’ve got to upgrade something that you have no clue what it is you actually have to upgrade. Talk about a Pandora’s box……Or worse does anyone remember the Hellraiser horror 80’s movie flick with the box that brought out the demons…….Do you really want to open that R12 box??????

When you open an R12 Upgrade project, you are opening a Pandora’s box unless you did an advance study. Or worse you could be the guy hearing the doorbell, going to his door and seeing a burning brown paper bag with R12 written on it on his doorstep. You go to stamp it out and find something VERY unpleasant on your feet that your company that implemented your ERP left you with but didn’t tell you…….Is your current R11 a brown paper bag with a pile of crap inside waiting for you to stamp on it with your R12 Upgrade?

One single customization missed can cause a catastrophic failure. Funnily enough I saw one Upgrade where they had account generators in the hooks of a standard package for Costing. Now yes, this was supported, but totally undocumented. Funny that generated a pile of entries to General Ledger that took weeks to figure out and calculate the reversals to, after the code was fixed post go-live. So the message is, it isn’t even enough to look at the obvious custom code. What about the standard packages that support hooks? What about overwriting standard code in packages, forms, reports and other customs? What about the change of seeded menus? None of this should happen, but don’t count that it hasn’t.

If you don’t have a customization register before you start you are in very serious trouble. You are going to miss stuff, and that one thing you miss could wipe you out in Production.

Also do you have any idea what R12 will do to your customizations. We saw our Payment customizations wiped out and need completely rewritten. (BI Publisher). Any workflow changes? They’ll need to be redone. Any Self Service in the old MOD PL*SQL? They’ll need to be redone. Any interfaces to GL or reports or anything else? They’ll need to be fixed as 80% of our stuff stopped working. Small changes on a lot of customizations add up to a lot of work, time and risk that can seriously delay your schedules. Did you know there have been very significant changes to the data models between R11 and R12 in certain areas……all that will cause your existing R11 customizations to crash and burn……

If you are doing an R12 Upgrade, you’ll have frequent clones. If you don’t encrypt data you could be incurring serious risk as all those outside resources can see vast amounts of confidential information. (See R12 Security and the Auditors from Mars article to scare you some more).

From a Systems Integration viewpoint, watch out that your R12 Upgrade doesn’t just focus on Oracle ERP. When we did the upgrade, we had Legacy, email , Web, external 3rd parties (Citibank and others), Health Insurers, etc. Now us Oracle guys like to think ERP is the center of the universe. Sometimes it is, sometimes it isn’t. But your typical R12 (or R11) can have interfaces, data extractions, data imports, links to spreadsheets, etc that can number many, many hundreds of integration points. Are you aware of what they are and if not how the hell are you going to test and make sure everything works day 1? Think about missing the testing on say Payroll interface to the Bank. That would be a nice one to find out doesn’t work on say, Payroll day for 50,000 employees. Or perhaps you forgot to test the interface to your planning system that orders the parts to build the products you make, which would stop your production line for 5 days, cost your copy millions of dollars and definitely get you on the “skull decoration” shown at the start of the article in the Boardroom or hanging on your managers wall….. . Hope you sleep well thinking of your integration points to ERP and the catastrophic damage it does if you get it wrong. I bet you that your one of these people that DOESN”T EVEN HAVE an architecture diagram of your ERP integration points. And your company spent like what 50 Million on that system with your integrator and you didn’t even get a coffee mat Integration and Interface Architecture chart????? You were ripped off and it may come back to haunt you…….

By the way, speaking of integration, does all the tech stack count? Just think, adding Forms 10G, Reports 10G, JDeveloper 10G, downloading the extensions for OA Framework, your Discoverer upgraded, BI Publisher. I guess not so much integration as getting the absolute basic tools to even start your R12, as all of these change between R11…….so you’d better sort that before you hire all those developers to upgrade your customizations…..

There will be a need to update or add new functional designs unless you are really a vanilla site. We did a lot of work again around Payments. Will those designs be decent and cover the requirements? Will they be reviewed in a timely manner? Will they be signed off? Keep this to a minimum (no new functionality, that’s gold plating an R12 Project) and you’ll avoid this risk.

A lot of companies also do MD.070 Technical Specifications. I’m not a fan of these to be honest as they have too much info, take too much time, are subject to not getting updated so become quickly outdated, and are largely done by many to tick the box. If you are doing these, make sure the quality and approach of customizations is correct for R12. (And don’t build what R12 provides – that’s one area I would add to an R12 to replace customizations with standard functionality where possible. We took out a raft of custom modifications which are the worst types of customs and vastly reduced our risk both to our upgrade and future upgrades/patches).

So I saw a movie with my kid. It was called The Hole (and it was in 3D so the ticket price is like double !!!!) Now this was a PG13 which meant that it shouldn’t have been that scarey, except it scared the crap out of my kid. More to the point it scared the crap out of me even more. So what’s it about? The hole generates your darkest fears and then these monsters come out. And what’s my darkest R12 fear? It’s about managing all of the configurations on an R12 Upgrade Project – that is my worst nightmare. The Hole gets a 7 out of 10 on the movie review. Well worth seeing, but if your kids get scared easy, approach with caution.

Now managing all your environments, patches, setup and customizations is a truly epic and very complex task. Really someone could write a book on this by itself, but the point is, you lose track of this and you lose track of your project. The lack of source control, the lack of BR.100’s, the lack of configuration management spreadsheets (or software) will cause your project to descend into chaos, especially as your ERP clones spiral from a development instance, to a sandbox, to a project team test instance, to a UAT instance, to a patch instance, to a DBA instance, to an instance with a DMZ, to an instance just for one module as it’s getting piles of patches and needs isolated……..your configuration management isn’t about a single instance. We had 10 instances at one point during the upgrade…….Or to put it another way our R12 had over 600 Functional Setups between R11 and R12, dozens of patches, thousands of test scripts all requiring data/setup to be in exact scenarios and thousands of customization files, loaders, packages, etc……Just curious on how exactly you are going to manage that………..? Are you one of these people that manage this type of thing on the backs of bits of paper or a cigarette packet? If so you’ll need to become a chain smoker as you’ll need a mountain of cigarette packets to keep track of all your configurations items on an R12 Upgrade project……

What I always find most worrying on an upgrade is playing the Oracle Patch Lottery. This is cool. You’ve got your R12 say Test environment all setup. You’ve got your thousand customization files, 600 setups and all the test data ready and you apply a patch, having no idea what that patch changes. And it trashes your entire environment, wipes out your 80% test completion and trashes the modules down-line of your testing. Every patch you apply is a roll of the dice unless you very carefully manage each and every patch. So when you apply a patch during your upgrade and have no clue/plan/analysis of that patch, the question is, do you feel lucky punk?

Testing is full of pitfalls on any upgrade. Have you got all the scenarios covered? Are your test scripts complete? Is your test data valid? Have you covered month end testing? Have you covered year end testing? Have you covered integration testing? Did you try the Web ADI? What about tools like Discoverer? Have you covered testing to and from Oracle and 3rd party companies that you barely even talk to (and met in 2007 when you put in your interface to their products which run offsite – think bank interfaces). Does your new patch invalidate Test Scenario 220, 221, 222 all the way through to 230 for Payables and therefore invalidate your testing across 80% of Payments? Or what if you apply a patch on TCA? Does it hit PO, AP and Payments? Or if you apply your customization, what have you invalidated? Will the auditors pick you up for claiming a sign off from the user, when they tested on a completely different configuration of custom, patch, etc? Are you sure your environments are all the same? Or do some differ in terms of setup/customizations/etc? If so, then how valid is your testing?

Here’s another great one to keep you awake. So all your systems around ERP. I bet you one joker that owns for instance your Legacy planning system or say your Payment middleware is planning to upgrade at exactly the most inconvenient time for your R12. Now you’ve always hated that guy and he’s always hated you. I mean is he doing this at the most inconvenient time in your R12 Upgrade without telling you just to screw you over yet again to get that next promotion over you ? If your not aware of everything you need in your R12 Upgrade and everything in your company’s universe (planned upgrades, planned business initiatives, politics, etc) that can screw you over, I need to ask, why did they even give you the R12 upgrade to do?????

Even if you get all this right, does your team have enough time to thoroughly test? Did you properly track all the bugs? Are you monitoring the bugs? Are you monitoring the Service Requests? What happens if Oracle decides to give a RUP (Rollup Patch) for you in your UAT and refuses to provide a single patch? Do you also take that latest security patch? Did you know that security patches have been known to screw up the Applications…….

It’s also interesting that an R12 DOES have data migration. Think about all those scripts running for the upgrade from Oracle Corporation. They are re-arranging your ERP data pretty substantially in some areas. What if the standard upgrade scripts for changing the structure of the Bank data (to TCA) goes wrong or cause problems? Think that won’t happen? Have a look at our Risk Register for R12………Or did you know you can run a script to convert your previous data to Subledger Accounting? Did you know R12 actually does some fairly heavy data conversion for SLA as standard? Are you confident it will all work with no need to reconcile? Are you confident that the new way that R12 handles accruals will work, as you actually have to run programs to build all the Accrual data………If so have a look at our Risk Register…..we didn’t spend 4 months reconciling and talking to the guy that had written this (in ironically Redwood shores…..those conference calls time-wise between Asia and California, weren’t easy) and apply multiple patches because it was working first time or second time or third time or fourth time……..Again have a look at the risk register from us. Or how about your AP data being converted? Again R12 does some very serious data conversion in the background. Try running the AP Trial Balance and see if you can reconcile…I didn’t spend two months just trying to talk to the lovely girl at Oracle Support to get a date from her….there honestly was a problem with the AP Trial Balance although I did close the SR immediately once it was transferred to a guy……..And did you know all your supplier data is converted by Oracle’s Upgrade process to TCA……..

The good news is that newer versions of R12 are a lot better, largely thanks to “suckers” like me that spent months with Oracle making all of the above data conversions that the standard R12 does in the background work. Of course until you check and reconcile all this for yourself, how confident do you really feel trusting some guy on a blog that claims to be a prophet yet never picks decents stocks………?

On top of all that resource management across your R12 will be the usual nightmare. Competing projects, production issues and users screaming for enhancements of R11. Key Project People walking off to lucrative new contracts and positions. Lack of R12 experience in the market. The time delays finding and hiring people to replace those that walk off. Dealing with unexpected issues that you didn’t plan for that have a catastrophic effect on your resourcing across the project (try cleaning up 3,000 banks when you find out what Oracle does to these during an R12 Upgrade….)

We’ve pretty much covered the testing phase above but just a quick recap to really scare you…..

Testing misses requirements or scenarios

Testing is incomplete by Project Team

Testing is incomplete by Business Team

Testing is delayed or lacks resources for Project Team

Testing is delayed or lacks resource for Business Team

Testing integration is delayed by dependencies

Test Plans are poor

Test Scripts are poor

Reconciliation of Ledgers and Subledgers is not carried out

Test Coverage is poor

Numerous Patches are required disrupting Test Cycle

All of the above can wreck an R12 Upgrade. It’s easy to miss key scenarios. Test scripts can run into thousands. Integration testing can have hundreds of points including external parties making it very complex indeed. User testing is beyond your control in many respects, especially for those that see no need for an R12 Upgrade. Reconciliation of ledgers and data that R12 has converted in the background is a significant task. Patches create havoc on internal test cycles and formal UAT. Remember you can’t just get each group of users to test each module. Each module talks to the other modules. Data from one module flows to the other for the next scenarios. PO needs Inventory. PO feeds the receipts. AP matches on PO receipts which then feeds to assets. IRecruitment flows to HRMS which then trigger hiring which then triggers Payroll which then relies on Advanced Benefits which then drives Self Service. The beauty and wonder of a fully integrated system makes testing co-ordination far from a stand alone list of test plans for each module………Managing an R12 in terms of testing is an extremely complex and challenging endeavor. Try doing that across 45 business areas and 27 countries, each speaking a different language……What’s Halloween in Spanish……??????

With an R12 Upgrade, vendor management is unavoidable…..

Software has significant patches

Software purchased is unstable

Hardware Vendor provides poor support

Software Vendor provides poor support

Poor quality in Product (bugs)

Software purchased is recently released

You are going to spend a significant amount of time dealing with Oracle Support. Depending on who you get on your Service Request can really screw you up big-time, as quality varies significantly. Get the right person (such as the lovely Indian girl we got on our Trial Balance problem, ahhhhhhhh…….) and you could get an immediate response. Get the wrong person and you could see weeks or months wasted, with the “apply this next rollup patch, we’re sure one of the thousand+ fixes will fix your minor problem and retest your entire R12 again” attitude.

R12 was highly unstable in 2008. 2009 saw it got better. By now reports are it is solid……….but I wouldn’t make that assumption, until I had actually implemented it and got my UAT signed off 100%.

When you implement R12 you may need to upgrade your database. (most will). When you upgrade your database you may need to upgrade your Operating System. When you upgrade to R12 you may upgrade or replace your servers, depending on where they are in their lifecycle. Now companies don’t generally have massive dealings with their hardware vendors (as Unix/Linux is incredibly reliable). But during an upgrade that relaxed relationship is going to be potentially very heavily tested. Question is, can the vendor provide strong support, resolve issues quickly and get you safely onto a server that is the very foundations of your business? If you fail to install the correct O/S plus interoperability patches you could see your business crippled…….It’s funny that the Infrastructure Manager that you were fighting with two weeks ago, kind of holds your entire career in the balance and you don’t really know anything about Servers, questions to ask, etc so are 100% dependent on him for your project to succeed.

Just wondering if your R12 needs more resources in terms of CPU, disk, memory, etc? Have you checked? It would be a shame if the server collapsed on day 1 of go-live.

Lastly the million dollar question. Oracle is on R12.1.3 at time of writing. Do you implement this version (and be the one to find the bugs as no one else is using it) or do you go for say 12.1.1. At this stage of the R12 lifecycle I’d go for R12.1.3 but then again you will get some additional pain of being one of the first. Obviously by the time you get to UAT, 12.1.4 will be out……….then do you jump to that or perhaps apply that new ATG patch or a RUP Patch that has come out as it has some really needed functionality……..All of these create massive risks not just for the stability of the project but also your budget, timescales and resourcing. Larry Ellison is a little devil….always releasing new ATG, Security or RUP Patches just at key points in your project, just to tempt you and cause major indecision in your mind. Question is, is that patch a poisoned apple that will drop your project at a key time??????

All hail Larry Ellison. The True and Only Oracle Prophet !!!!!

Happy Halloween. The clock is ticking down to the midnight hour. Before Halloween is over, I will scare you. The witching hour is coming with Transitioning from your R11 to R12, the actual cutover and post go-live, with all the reference material and a prebuilt R12 Risk Spreadsheet as a treat for all the kids in the next article……

Delivered on Halloween !!!!! Enjoy………..

 

See the other Prophecies including Business Intelligence and the Kung Fu Dragons of Wudang at

https://oracleprophet.wordpress.com

Halloween – A Time of Ghouls, Ghosts and R12 Upgrades (Pt 1)

October 20, 2010

Darkness falls across the land
The midnight hour is close at hand
Creatures crawl in search of blood
To terrorize the neighborhood

Now if you don’t know that song intro, shame on you. It’s from one of the biggest hits of all time – Michael Jackson’s thriller. A very appropriate one for Halloween I’m sure you’ll agree.

So first movie recommendation of the day. This would be “This is It”. There’s something very poignant about seeing him performing in what was his final curtain call.

Now Halloween has always been a time to scare the crap out of people. Kids dress up as Ghouls, Vampires and the like and go “trick or treating”, sometimes with some very nasty tricks indeed. Either the local neighborhood pays the kids with sweets, etc or the kids do something nasty.

Back when I was a kid, there was one particularly nasty kid who didn’t bother with the treat stuff. He figured he could go beat up the other kids at the end of the evening and steal their sweets. This saved him the effort allowing him to do his favorite trick of all.

This kid had a real nasty trick. What this kid would do would be to get some dog crap, put it in a brown paper bag and then go place it on someone’s doorstep. He’d quickly set the bag on fire, ring the doorbell and wait for someone to answer.

Now what is amazing is that the immediate reaction of an adult to a small burning paper bag (even if they are not wearing shoes) is to try to stamp out the fire with their feet. Irrespective of wearing shoes or not, this had some pretty unpleasant results for the poor neighbor at the end of this “trick”.
Before we start, let’s put our other movie recommendation out. It’s the original Halloween movie. Now I saw this when I was 13 and it scared the absolute crap out of me. Well worth getting the video. A classic 70’s horror flick for Halloween, but definitely not for the kids. (Don’t see the more recent one, it sucks).

So seeing as it’s Halloween, I should scare the crap out of everyone reading this right? So everyone’s moving to an R12 Upgrade in 2011. So what better way to scare you than tell you how horribly wrong it can all go on an R12 Upgrade !!!

So R11 Oracle Apps Premier Support is ending in November. That means you are screwed. OK, not completely (but Oracle will be putting the pressure on you and telling you that you are) but seriously you should be looking at R12 now.

Now let me tell you that an R12 Upgrade will be the biggest, toughest upgrade of ERP that you will EVER have done. It can go disastrously wrong. You could corrupt your data, you could have major functional failures dropping your business to it’s knees. Or your entire ERP could disintegrate and you could lose your job because at the end of the day your boss will need a sacrificial lamb and you seem to fit the bill.

Are you starting to get scared? You will be by the time you read this article, because it contains a very long list of every single thing that I can possibly think of that can wreck your R12 upgrade.

So let’s start at the very beginning. Getting the Project Started. If you get this wrong, it’s probably not worth bothering about the rest of the project. Here’s a short list of things to worry about. (Now the purists will say these are not risks). For me I like to have everything that can go wrong on one spreadsheet. Call it risk, call it a list, doesn’t bother me, because I can quickly mentally check each month how things are going and make sure I haven’t forgotten anything. It also gives me a nice risk score and lets me manage that to hopefully give the project a fighting chance of delivery.

Let’s start with the Project Management risks and everything that can go wrong here:

Weak Business Commitment to Project

Funding is not secured for Project

Project Decisions are not Timely and On Time

Weak Business Commitment to Change

Review of Project Deliverables and Sign-Off is not timely

Weak Support of Business Case

Scope is not defined clearly or completely

Business process model is not defined clearly

Planning is of poor quality

Project involves large number of departments

Tight Time-Frames, Minimal Slack between Dependent Tasks

Go-Live Date accommodates limited UAT

Project Milestones are not achievable (Project Schedule)

Dependency on other Projects

Project requires complex organizational changes

Contract involves significant cost

Project involves time-critical Procurement

Significant Scope creep

Gold Plating by Implementation Team

Project Budget is not sufficient with Current Progress

Project Resources are no sufficient with Current Progress

Project schedule is delayed

Project Cost is overrunning

Product does not meet client expectations

The very first thing you need to do is get your most knowledgeable and trusted people in a room and do proper planning, taking into account your organizations political landscape, resources, expected funding and other commitments. If you fail to plan, you plan to fail. Your planning must give ample slack time for delays in UAT, delays in decisions, procurement delays, bugs, resource problems (only 5% of people have done R12. The other 95% of people will do R12 in 2011, so can you get resources??????)

The most important part of any project is to get high level buy-in and commitment from the senior people across your organization. From a resource viewpoint an R12 Upgrade requires intense Business and IT Commitment. Fail to get every area of Business and IT involved and agreed, then you are screwed 100% come UAT, if not even earlier. You need to make it clear when you need the business, what you need them for, how long and how many resources right at the onset of the Project Initiation. IT resources need to be equally onboard.

Securing realistic and adequate funding is critical to an R12. It is bigger. It is more complex. It does take longer. An R10 to R11 or a 11.0.3 to say 11.5.10 is NOT the same as an R12. Build in a decent contingency.

An R12 is not a basic like for like Technical Upgrade. You should ideally keep R12 as a pure technical upgrade and not a re-implementation, unless there are very good reasons, otherwise your risks and costs will escalate severely. However even doing a technical upgrade involves a pile of new modules and new functionality (albeit some can be deferred). But you’d better be prepared to implement Subledger Accounting, EBiz Tax, TCA (changes in Banks), Payments and Self Service (new functionality and removal of MOD PL*SQL). All of these will need user review, functional designs (if customizations on top), setup and decisions, as well as time for your own team to learn the implications.  This can lead to multiple risks including your own team wanting to add “cool functionality” or users not making timely decisions or being prepared to adopt new processes to account for changes in say TCA or Payments.

If you are dealing with contracts for consultants, firms (outsourcing or otherwise) or need hardware, etc, be prepared for the heavy risks of delays in Procurement. IT guys often overlook that it may take a while, despite having the cash to get resources onsite or hardware commissioned, etc.

Talking of resources this should be viewed as a serious risk throughout your project. R12 resources are still less rather than more common.

As well as all of the above, you still have to worry about all the usual Project Management stuff of quality, schedule, cost, delays, budget, etc. And think about it, we’ve not even got to the actual project yet…….

So the very first thing you need to do (before your project team arrives) or is internally deployed is to make sure they actually have an R12 Instance to work on…..

Infrastructure is often overlooked for projects. Unfortunately this can cripple the project team (and therefore your project) very rapidly indeed.

Network Speed

Performance Issues on Project hardware

Performance on Production may not be acceptable Go-Live

Deployment involves new hardware

Hardware is not sized correctly

Database is not sized correctly (do you have enough disk space for R12)

Hardware is no available for Project Use

Backups are not available for Projects

Project Environments not available

Network availability is poor (if teams distributed)

DMZ Configuration is not available

Architecture is new

R12 Instances are not available

Space for Project Instances is not available

Missing interoperability patches

Missing patches to Operating System

If you are going R12, either you have a lot of servers around spare, or you are going to need to buy (or lease) additional hardware. Otherwise what is your team going to use? Ten Consultants onsite doing nothing is some serious cash burn.

Then you have to have a plan for environments needed, dates needed, who prepares them, who sets them up, etc. DBA’s will shout at you if you need environments the next day. And what if there is no space? Did you check the disk space as part of your project? Your average R12 environment requires considerably more space than your R11.

During an R12 Upgrade you’ll need a pile more databases. We used around 8 additional (and we still needed all our R11 Development, Patch, Test as R11 Production work could not be completely halted).

Now just think when you finally deliver that R12, and it crumbles on day 1 into a performance black hole. Did anyone bother to do proper sizing either on CPU or disk or Memory? If not, try www.jobserve.com when it all fails on day 1.

Even when you are starting the project, insufficient hardware will kill you.

Did anyone ask for backups of your project databases? It would be a real shame to see your R12 go down and no backup, losing months of effort.

If your Production is a DMZ enabled configuration, I hope that someone is also going to emulate this for some of your R12 databases as you go through the project.

 

So lets get to the one that usually gives R12 Project Managers nightmares. Resourcing.

Poor IT Staff Skills – Functional

Poor IT Staff Skills – Business

Poor IT Staff Skills – Quality Assurance

Poor IT Staff Skills – Java

Poor IT Staff Skills – Oracle Development

Poor IT Staff Skills – ERP

Poor IT Staff Skills – Modules Implemented (or new modules)

Poor IT Staff Skills – Technology

Poor IT Staff Skills – Unix/Linux

Poor IT Staff Skills – DBA

Poor IT Staff Skills – Project Management

Poor IT Staff Skills – Senior IT Management

Poor IT Project Team Rating – Skills

Poor Business Project Team Rating – Skills

User Department Staff not available for Project

IT Staff not available for Project

Poor User Department Staff Skills

Poor or lack of Project Team Lead (s) per Functional Stream

Experience of Business Area is Low

Project has competing projects for Resources

Custom Development relies on 3rd party

Project Manager is inexperienced in Upgrades/ERP

Legacy Staff unavailable for Data Conversions

IT Staff skills – training required

Low retention of project  team during implementation

Low availability of Trained and Experienced reasonable cost alternate resources externally

No IT Staff available for existing Production Support

Oracle Support provides poor support

Have you even contemplated the vast variety of resources you are going to need to pull off an R12 Upgrade? Have a look above if you think you can use a couple of consultants over a few months.

Will your internal IT guys be good enough? Do they know the R12 functionality? Probably not. Will you train them? Probably not. So how can they deliver? And even if you want to train them, can you get the appropriate training completed before they actually do the upgrade. Training courses from Oracle can be hard to come by, especially on some of the niche modules and require booking way in advance.

Do your IT guys REALLY know the business? If not are you sure you’ll catch every scenario and every nuance during implementation.

Do you have decent Oracle skills? Do you have decent Java skills? Do you have decent Oracle ERP Technical people? If not, you are going to need to ramp up or get someone that does to do your upgrade (unless your complete vanilla ERP).

Do you have anyone that knows all the new R12 modules, such as EBiz Tax, Subledger Accounting, Payments, etc? These are not optional modules (except Payments, but if your running Payables in R11, then Payments becomes essential in R12 and it’s a new module). Most companies will require to have knowledge on these and something like Payments has heavy changes between R11 and R12 – indeed it is a rewrite between R11 and R12.

New technology components are included across the board. Are your people ready and capable?

Your typical upgrade will require some pretty heavy Unix or Linux skills. You might have to upgrade the O/S or you may take the opportunity to switch to cheaper, less proprietary hardware or Linux. Do you have any clue what’s involved? (we did this and yes it saved us a pile of cash for the future, but it ain’t easy and is littered with risks).

Did you tell the Infrastructure guys you’d be needing a full time DBA for the R12; to clone R11 Production; to work on the upgrade process; to write detailed upgrade documents that give step by step guides; to optimize the process so that it can fit into a long weekend on a huge global database? To apply all the patches? You probably thought your DBA’s sit around doing nothing and can do all this at the drop of a hat…….Count on the initial upgrade where your DBA’s find out the nuances of R12 to take quite a chunk of initial time and plan that into your environments and people coming onboard project wise.

R12 Project Management. Words fail me on this one. If you are not an ERP person don’t even think of doing an R12 without a strong R12 Project Manager, ideally someone that has done R12 Upgrades. It’s horrendously complex, extremely technical and the risks are catastrophic if you get it wrong. (I can be contacted on the following number for lucrative job offers……… 🙂   )

Are the Senior Management (both in IT and Business) in full support of both you and the R12 Upgrade, or are they ready to crucify you at the first delay? R12 will have delays, it will throw horrendous curveballs in terms of bugs and other complexities. Just make sure everyone is on your side politically before you start. The guy below thought everyone was his friend, until he forgot to order the hardware in time……

Now this is a weird one, but how well do your Business know the Business and Oracle ERP? Look for the weak spots here before you start. If a Business Unit has a lot of new people or inexperienced people or are anti-Oracle ERP (and some are), how are you going to get them to assist (or write) Test Plans and Test Scripts and do actual testing. Now if your IT and Consultants don’t test well (and they are NOT business experts) the one hope of catching everything before Go-Live is the Business. I never build 100% dependency on the Business for testing, but if your IT and Business guys can’t be relied upon for testing, you’ve got a perfect storm.

The other thing to check is everybody’s schedules. We’re not talking dinner dates, or when they plan to see a movie. Are the Business available for an R12 (which won’t add vast value to be honest) or do they have a planned move to say IFRS planned from June to December 2011. If so you won’t get a look-in resource wise for UAT and your project will be dead in the water.

Same goes for IT. If they have some major high profile initiatives, your R12 is bottom of the list, as in the priority list, it’s just one of these unpleasant tasks that needs to be done.

Watch out that your R12 Upgrade doesn’t just focus on Oracle ERP resources. When we did the upgrade, we had Legacy guys, email guys, Web guys, external 3rd parties (Citibank and others), Health Insurers, etc. Miss those guys out and who can help you complete your UAT?

What’s amazing about an R12 Upgrade is that you’ll need exactly the same resources that are getting used for your R11 Maintenance and Support. That leads to automatic conflict and resource contention and delays (and when it comes to Production problems or R12 Upgrade, you’ll lose that argument every single time). So ensure you augment your team to not be 100% reliant on goodwill.

If you are getting a company to do it for you, be careful. Have they done an R12? If yes, will they give you resources that have ACTUALLY DONE AN R12? Most outsourcing or consulting companies might have done R12’s, but they are as keen as anyone else to stack your project with their guys who can then learn R12 at your expense. Nice how they’ll happily charge you for the privilege of training their people…….Interview all people, before they deploy onsite. Hire an independent highly knowledgeable freelancer Consultant to fight your corner and keep the vendor on the right track, working in your interests, not the vendors.

Do you know the effort involved in training people for R12? The IT guys, the Business guys, etc? If not, start to worry.

The great thing about an R12 Upgrade is that your team (and maybe your consultants or outsourcers) will all get fantastic R12 skills, in the midst of the hell of an R12 project. Trust me that’s a great way to learn. Of course all those companies that have not done R12 (and that’s 95% worldwide) will be looking and admiring your very skilled people. And your loyal people that you’ve spent time and money training in R12, will of course be looking for that next payrise with their new found skills. Losing key resources (say for instance your Payments expert) is your worst nightmare. Suddenly one single module can derail your entire R12 Upgrade. If you think this is the stuff of nightmares, well during our R12 back in 2008/2009 we lost our Payments Consultant (one of the few in Asia at the time). Luckily we had him shadowed throughout the project by another staff. The demand for R12 skills will hugely increase in 2011 and your guys will be headhunted or tempted away. Just be ready. I am sure the resigning employee will feel your pain as your project is now doomed, in the same way you felt his pain when you froze his pay last year, as part of a corporate wide pay freeze…….

Our final resource issue is to prepare for the maelstrom of Production support hell. Just make sure your well staffed and haven’t let the entire project team go, just before you get deluged with Production issues. (and yes you should start thinking about this not at the end of your project when everyone is jumping ship as the project for them is over, but at the very start of your project). It’s funny as R12 projects get to go-live, most of the work is done, and you start letting consultants/contractors go. Do you have any idea the pyschology in play with the others that you expect to see remaining to do the support work and provide critical support for a few months after go-live? Why should they stay when they can get a far longer, far higher paying and far easier (i.e. not pressured go-live support) contract with their fantastic R12 skills you gave them? Sleep on that one, assuming you can still sleep……..

And I hope you’ve got a full communication plan going on – an upgrade can take time and if you are not informing and working with the users throughout…..don’t expect them to be enthusiastic about putting large amounts of time into your UAT. Of course if you run workshops and demos and mini training throughout your R12 you’ll have a whole lot more acceptance during UAT and go-live…….

And finally Oracle Support………..now R12 should be stable now, but back in the early days, we had these jokers on the phone daily. We even had a few removed from our support calls because progress was atrocious. Are you ready to deal with Oracle Support? Do you know how to escalate calls effectively? Do you know how to work around Oracle stalling for time or sending you on a wild goose chase? If not hire someone that does. Good ERP people with strong experience are essential for your R12. It’s funny but I bet you didn’t even think about informing Oracle Support of your upgrade, which is a shame as they might have given you a Critical Account Manager that could have helped you push all your Service Requests….

And that’s all for now folks. Part 2 will cover more in ghost, ghouls, implementation, transition and onto go-live, together with a whole pile of great references, covering fantastic presentations from experts in R12 and great Oracle Open World links of R12 Presentations there, together with a heavily researched bunch of Metalink articles around R12.

I’ll be scaring you very shortly with Part 2 before the full moon of halloween is over.

The other blogs can be found on https://oracleprophet.wordpress.com

Enjoy.

Footnote:

The great graphics were the work of:

WWW.MYSPACEGRAPHICSANDANIMATIONS.COM

R12 – A Detailed Transition Plan

September 19, 2009

So your UAT is heading for completion, you’ve got as many bugs out as you can and your ready for go-live.

Problem is…..this is the most dangerous part of the entire project. All the hard work and success could go be wrecked over a poorly planned weekend (or long weekend if your upgrade is really tricky or big)

Planning is the key.

It’s recommended that everything is documented very, very heavily. Start off with a PM.030 and get into your head exactly what your going to do.  And a PMP.030 Transition Plan isn’t just what you will do over the cutover weekend; its before, during and after – how are you going to support the R12 when live? Are your teams ready for that?

Get all your Functional Setup into a Spreadsheet, BR.100 per module or other installation documents. Give assignments to each person. Make it clear who does what, when they do it, order, dependencies, etc. On a cutover weekend there is ZERO time for mistakes.

Have a spreadsheet of all tasks to countdown, dates, people, etc. Mark them off one by one as you go.

Have another spreadsheet for all cutover tasks. I suggest some sort of matrix where setup is assigned and you can see each persons workload. Then try to balance that workload. If one person is too slow or too busy on the cutover, you’ll hit major delays on cutover weekend.

Your source code should be in a Source Control System (we used Subversion – it’s FREE – it’s GREAT). You should repeatedly clone Production and Test the deployment until very close to Production. Also apply Functional Setup and retest.

Are you confident that what was passed in UAT is what you’ll put in Production?

Keep doing the clone, setup and test until your happy that the answer is 99.9% yes.

Also during final approach to go-live, do a simulated financial close on the Clone. Trust me this will save you a lot of heartache. Wouldn’t you rather find disastrous stuff you need to do before you hit it in the crazy, high pressured time after go-live. Pay careful attention to AP closing. It’s tough. Run the accounting health checks.

You must have an automated mechanism for code application and your DBA’s should be familiar with this. And by automated it can be as simple as a shell script to move stuff to the right place and a script to cut and paste and compile objects. Get this 100% before you do it.

One tactic that worked well for us was to do setup on 11.5.10. We’re not saying everything, but some menus, some value sets, messages…..every little helps. Of course you can also do these on the day using FNDLOAD, but the point is the more you can do ahead, the less you have to do in a high pressured weekend.

Get the meetings going with Business. Make sure everyone is aware of how and what is getting done. We closed on R11.5.10 for all subledgers prior to R12 apart from GL. This really helped reduce overall errors and risk, as all that had to be done in week one of R12 was a GL close. It went very smoothly. And then you have 4 weeks until your first real R12 close – gives you time to simulate another close 3 weeks into your financial period. Now some may disagree with this approach and prefer to go-live after month end closing. I understand this is another perfectly valid option. In our case we made the decision to jump immediately after subledger closing as we also run two large payrolls twice a month…….so our cutover windows for making the jumps were seriously limited. Also we had done this procedure many, many times (including on very recent clones), so had a level of confidence that this was safe to do. If your cutover testing isn’t giving you that confidence, suggest you close in R11 fully then jump to R12.

Make sure you have plenty of meetings with your DBA Team, Unix Team and Management. I prefer to plan for the worst; set the expectations low and then everyone will be prepared mentally for a tough time. If it goes smooth then everyone is happy. Doing an R12 is the toughest upgrade anyone will have ever done, don’t underestimate the issues you will have. Many, many companies have had horror stories during go-live.

So your plans are done, teams are briefed and your now ready for launch. Did you actually remember in advance to tell all users (and post notices on your website internal and external) that your system is unavailable due to upgrade? Did you remember to tell all the other systems (Legacy, data warehouse, etc) that your system is unavailable?

Oracle people (including myself think the world is Oracle). Remember there’s more to life than Oracle…..and most companies have a lot more systems than just Oracle, although Oracle is the foundation…..so if you take that away and forget to announce, you’ll have some very unhappy people……

Make sure you brief your helpdesk. Make sure they know the escalation procedures. Even if you do a great job, it’s going to be a busy time. Make sure you Oracle ERP Team is also ready to work round the clock post go-live, just in case…….

We brought our ERP down at 5:00PM on a Wednesday after closing all subledgers. Actually it was 5:52PM and the DBA’s were already complaining like crazy.

The DBA’s in our case brought the system down and started the export. They worked through the night to export from IBM and bring this into HP Linux. (Yes, we throw in not only an upgrade but also a migration for fun…..)

The Upgrade started on the Thursday and was then backed up early Friday morning.

The DBA’s automatically deployed the code (7,000+ files) onto what was effectively a live Production system. (with no one else on and of course backed up on R12 AND R11.5.10  before we started).

The Deployment Team rolled in at 10AM on Friday, sat around for a few hours and then started at 11:45AM to do setup. Of course we screamed at the DBA’s for being 1hour and 45 minutes late, but they claimed we were 52 minutes late handing the system over on Wednesday…….things are always tense during an upgrade cutover.

Functional Setup continued until 9PM on Friday night (remember all those new modules, Payments is a large setup, and there are loads of System Admin tasks  – Hint split some setup into Application Developer responsibility. Do others setup using FND_LOADER. I think your System Admin may be a bottle neck – that’s what happened with us as there were just so many changes between R11.5.10 and R12)

Around 9:30PM Friday the database was ready to be backed up and cloned. DBA’s worked to clone the database and make it available at 10:00AM Saturday.

Testing Team rolled in on Saturday and did a quick Financial Reconciliation. All well and good testing started on major key functionality. I hope in your cutover plan you detailed what would be tested, who would test, etc.  In addition each Team Lead should prepare a more detailed Test Plan for the transition and brief their respective teams. Concentrate on key functionality. If you do this, you’ll be doing well if it all works on day 1. Testing continued for about 10 hours on Saturday and started at 9:00AM Sunday.

As we caught problems, we logged them and got our System Admins/DBA to deploy missing items to Production (with heavily controlled approval, logging of bugs, etc so we tracked every single change)

Around about 4:00PM on Sunday we had a Team Lead meeting. Each Lead was asked for a go/no go signal. With the decision to go made, we went to Management. The current status was reported and management after discussion gave the green light.

All workflow services were turned on (with emails being caught in our email system so we could monitor and then release – nice little trick). Once we were happy emails/workflow was OK, we released one (a Leave from one of my staff) and tried the complete cycle. Once we were happy with this, we released all workflow, all concurrent jobs (we had simulated release of all concurrent jobs on Saturday to avoid surprises) and there was no going back.

We went live on R12.0.4 (RUP5) at 5:00PM on 2nd August 2009, some 96 hours after bringing down the R11.5.10. (Although we are on RUP5 we’re really heavily patched on Financials so RUP5 is a bit misleading)

Teams had worked round the clock, across all areas to make the cutover a huge success – we finished 30 minutes ahead of planned time. Now that’s pretty good planning. Have you planned to that level? If not you should be.

On 3rd August, our users logged on to R12 and we were fully operational.