Posts Tagged ‘Oracle’

Business Intelligence – An Oracle Future?

July 5, 2010

In ERP terms, there is little dispute that the big two, SAP and Oracle, basically have control of a very large part of the ERP market for medium and large scale organizations.

However in terms of Business Intelligence, the market has always been extremely competitive. Recently, quiet strategic moves by SAP and Oracle threaten that status quo. Possibly changing the landscape with a quiet, yet fundamental revolution.

There is a fundamental shift away from the concept of stand-alone data warehouses to the concept of embedding analytics into every day Business activities. Stand alone data warehouses are very much a 20th century view of the world. The new view is stand-alone yet fully integrated data warehouses to ERP, augmented with the 21st century concept of embedded analytics directly in your ERP Systems. This is a truly profound shift.

Both Oracle and SAP are now investing to this 21st century view. Both are turning what are, lets face it, pretty boring looking applications into stunning, state of the art applications. Both companies see Embedded Analytics in their respective ERP Suites as a strategic positioning of their products to gain market share. But this ain’t happening today, right? Wrong.

When Oracle released 12.1.2 (which is already out), this had in place rich container support, in OA Framework. This little gem should, in theory, allow you to put a fantastic Oracle BIEE Page directly into a transactional screen. Imagine the sales pitch you can give your users as you embed Business Analytics directly into your applications. Now this is not creating a simple link between BIEE and ERP or vice versa as you could previously do with Oracle BIEE/ERP – this allows you to create a custom transactional screen with half of it transactional and the other half analytics – ALL IN THE SAME SCREEN.

It’s an easy bet that Oracle Corporation will, with the release of 12.1.3 in 2010 (or a version in 2011), start to embed analytics directly in R12 itself. Why? Firstly it differentiates itself from boring, old ERP’s. Secondly it’s amazingly easy to write a BI Page with fantastic drill down, graphics, etc, reducing development and future maintenance costs. Lets face it, Embedded Analytics will be everywhere in your Oracle Applications.

Now when you look at the new Fusion Applications, and there’s not much info, but these are basically dashboards and ADF mix. Fusion Applications are built on Oracle Business Intelligence as a key foundation. Embedded Analytics is now viewed as essential to Operational work. You put in an invoice, your chart is there showing if the client has disputed invoices or other relevant info. Analytics at the fingertips of your basic frontline functions. Powerful stuff indeed.

So as an R11 or R12 Oracle ERP Customer where does this leave you?

If you haven’t upgraded to R12 (and your one of 95% of customers according to independent research that hasn’t) you have the opportunity to jump your competitors and move to Oracle BI embedded with R12.1.2. That’s a very interesting option to cut your costs in future for custom development, make support easier and make user acceptance of Oracle ERP a whole lot more easy.

More worrying if you are on a 3rd party Business Intelligence toolset, the writing is on the wall:

1. Oracle and SAP will embed their own analytics products directly into their applications. Now of course those companies will not “force” you to buy their BIEE Products, but well, if you want to change the screens in future, it’s looking likely you won’t have a choice. BIEE will become as essential as Oracle Forms or Java to Oracle ERP………..

2. If most large companies who use Oracle and SAP have to buy Oracle BIEE and SAP’s own product respectively, this ain’t going to be good for 3rd party BI products. Indeed Gartner expects an 8.5% migration from customers of one key BI vendor to other vendors. It’s easy to read between the lines of this argument……..

3. Gartner further states that due to the pure-play BI vendors weakness in the ERP market, this is going to hurt those particular vendors. Or to put it another way, with an aggressive and extremely smart policy from SAP and Oracle to embed their own products, 3rd party vendors are going to get squeezed. Imagine what this will do to the BI market – do you really want to be unaligned in terms of Business Intelligence with your ERP that supports your core business? That’s certainly a very dangerous, multi-million dollar Las Vegas style gamble.

4. As Oracle has now become, according to Gartner the clear leader in BI, the writing is very much on the wall. The Gartner research on this has been deep (and excellent as always) and reading between the lines, although Gartner never explicitly states it, has some pretty profound implications for organizations worldwide.

The full Gartner report can be found here and makes sobering reading for those planning a BI Strategy for the next 5-10 years.

http://www.gartner.com/technology/media-products/reprints/oracle/article121/article121.html

Oracle has already recommended that a key step to Fusion Applications is to move to Oracle BIEE. It’s a great paper written by Nadia Bendjedou, Director of Product Strategy at Oracle Corporation that can be found at:

http://www.oracle.com/technology/products/applications/events/oow-2008/10-things-to-do-nadiabendjedou.pdf

The picture will hopefully become clearer in Oracle Open World 2010, where everyone is waiting for Fusion Applications to be formally announced and hopefully available at the booths to test-drive.

Still don’t believe the prophecy? We’ll leave it to Larry Ellison, CEO of Oracle Corporation, to spell out the future, which we believe equally applies to R12 and Fusion. 

“You can’t use the system without using business intelligence,” Ellison said.

All we can say is you’d better be on the right Business Intelligence train…………

Advertisements

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.

R12 – The Worst Oracle Release Ever?

May 19, 2009

Star Date 2009, these are the voyages of the Starship Oracle……sorry too much Star Trek at the weekend. The new movie is great and I’m not a big Star Trek fan generally. So I’d recommend Star Trek for anyone to see (its a great movie), but would I recommend Oracle R12 and is R12 the worst Release of Oracle ERP ever?

Looking back over the last decade or so there have been some fairly classic (and truly atrocious) releases of Oracle ERP)

MPL 7 and MPL 8 way back in the 90’s were  not great, but then again it was fairly cutting edge stuff in many respects so you needed to admire what Oracle was doing. I remember Oracle Support phoning me and asking how I got the autoinvoice running so fast…….the good old days although not quite the idea of how Oracle Support should be working……

The first truly atrocious release for me was the 10.6 Release. That was swiftly followed by 10.7SC which was so full of bugs that if it had been a dog, it would definitely be put down. And trying to modify forms on a PC when you were doing mods to the invoice workbench (and no documentation)…….well you do look back and smile. I believe Oracle did apologize for this version (should Larry have been flogged?)  and funnily enough AP was a real issue…..I remember asking a client (with a straight face) to log onto the character version to void checks, as the GUI didn’t work yet.

The next release for me that was a standout was the early 11.5.0 (or was it 11.5.1). Now to actually put an Order into Order Management you had to apply a patch, then another, then another……….The beauty of the patch that wiped out the flexfield setup, phoning up Oracle and having the response (yes we know about that) was certainly a response that floored me. It was another classic release for all the consultants around the world just trying to deliver a good result for the clients.

Now looking at 11.5.9 and 11.5.10, these were actually pretty good releases. Not bad, stable and upgrade wise pretty OK. We went to 11.5.10 in 2005 and it wasn’t actually that hard.

So what do I reckon to R12? We thought we’d be safe by waiting a year or so after release of R12 before diving in. With a slow burn upgrade, that would give a decent time for all the suckers to dive in, find the bugs and get them resolved on our behalf before we had the heartache of doing this ourselves and actually going live 2.5 years after initial release.

We started seriously on 12.0.3 and overall it wasn’t bad. We then went to 12.0.4 and then up to RUP5 on Finance and HRMS. On the Procurement, HRMS and some Financials, its actually been a pretty good release, even on the initial 12.0.3. Most major stuff in HRMS Suite and Procurement Suite actually worked !!!

However onto the bad. What’s really disappointed me on this release is the quality of the Accounts Payable module. We’re now on 12.0.4 (RUP5) and we’re applying quite a few more patches to resolve very serious problems. The news is the same from other companies where month end closing, accounting and reconciliation have been causing a lot of heartache. For us we found the accruals were converted wrongly between 11.5.10 CU1 and 12.0.4. The Trial Balance has been hit and miss, the accounting had issues, invoice workbench had issues…………We’re lucky we caught these pre go-live and testing heavily is an absolute must for any R12 release.

The support on this has also been extremely patchy, especially when it gets into Payables and SLA related issues, where we seem to be passed round Oracle Support. Getting issues resolved has been a slow and painful process, with our upgrade taking an extra 3 months longer (like many other companies).

What really shows the quality is the critical patch sets for Finance. These are coming out on a regular basis and fixing some pretty major issues that have been causing a lot of pain to many, many clients. I think in term of AP, Oracle has had a quality issue overall. The idea that clients are sitting and have lots of time to apply these patches is a really frustrating view – testing by both IT and Users does take a long, long time and the patches frustratingly still cause more major issues – “Can we get a patch for the patch please is a common, recurring question”. We are afraid to put in patches, as a previous one actually stopped our AP/PO matching completely…..

So was R12 a good or a bad release? I’d say R12 was a very good release, let down by Payables and Subledger Accounting module. Everything else was overall pretty good and pretty easy to upgrade. Now I know that Payables was re-architected and Subledger Accounting is a superb idea and will be great for us in future, but R12 really should have been released at least 1 year later, to provide a more stable and higher quality initial release.

Would I recommend Oracle R12 Upgrade to clients today? Absolutely yes. It has got a lot better and if your starting an upgrade now I think you’ll have a smoother path than those other clients who started earlier. There is a lot of very good new areas of R12 and Oracle is heading in the right direction, but it is also a huge step to take for any organization so caution and careful planning are recommended.

In summary, 2009 and 2010 are going to be ideal times to upgrade – more R12 literate people, less bugs and very good functionality overall in R12. It is the right time to consider moving to R12 (in consultation with your business users) for those who have not considered it currently.

So what about 12.0.6 and 12.1? Anyone been brave enough to take the jump on these yet? What are your experiences (good and bad for R12) ? Is anyone upgrading from a lower 12.0.2 or 12.0.3 to the latest R12.0.6/R12.1 due to problems caused.

Please do share your views as others will really benefit from the mistakes (and lessons learned)

R12 Upgrade Plan

April 9, 2009

1. The most important part prior to starting an R12 Upgrade is to build support for the project. If the Business isn’t on board, it’s going to hit real problems when you want their time – and it’ll take a lot of their time……Look for the key drivers of why your business needs an upgrade; for us we had many new Oracle modules and we felt it was better to do those projects on R12. rather than implement in 11.5.10 and upgrade in R12 later. A move to Linux and the age of 11.5.10 were other critical factors. With R12 being out for 2.5 years by the time we implement we figured it would be relatively stable overall – a lot of companies got badly burned by jumping way too early into R12.

For those companies not in R12 now is a good time to start thinking – the product is stable in most areas (even AP is getting there) and the market is depressed, so there are a lot of available resources (albeit mainly in 11.5.10, but most modules remain pretty similar overall)

2. A study approach of building a Business Case to assess the Upgrade may be a good idea. It won’t cost a lot, but will allow you to make a very informed choice ; the new functionality, the customizations you have, the estimate of effort, time and cash it going to take, pitfalls and other issues.

This approach lets you build concensus and support. It minimizes risk and allows you to build a strong business case to get necessary funding.

For us, we identified several major issues upfront; Payables was a complete re-implementation for us. Payments was a complete re-implementation. We had a LOT of customizations. General Ledger customizations require re-work; small but 60% of our customizations were hit…..Self Service screens must be migrated. All Payment formats require new build. This was going to be the biggest upgrade I have seen in a very long time…..Understand also the architecture – Oracle ERP isn’t an island. It usually talks to an awful lot of other systems and if you don’t understand this at the outset it may hit you just before go-live or worse……after.

We also used a lot of good documentation on R12. Look on Metalink, google, OAUG. People have made plenty of mistakes and published where they went wrong – with the documents available now you should avoid the pitfalls for most.

Remember this is not just an upgrade – Oracle has brand new modules so this is also a major implementation project; Payments is new and completely different, EBiz Tax is new, Subledger Accounting is new and if you are running AP , you have no choice but to implement the Payments. The other two are now core modules that must be implemented, even if your not using Tax………

Be careful of your plans for current Production during the Upgrade. Most of your resources will sink into R12, so try and reduce big new commitments.

3. Starting the project. Make sure you have enough hardware……you’ll need to run a lot of instances AND still support your existing Production on 11.5.10…….If you don’t have the hardware your project will suffer badly. Resourcing wise there are lots of options, but it will take a lot more than an upgrade from 11.5.5 to 11.5.10. I can’t stress enough how important it is to get top tier consultants – a few really good people (albeit expensive) actually saves you money. Depending on your customizations, you’ll need a fair chunk of development resources. But by doing the study you’ll be able to make good estimates. (Don’t underestimate Payables and Payments – these will take a VERY LONG TIME).

Remember that resourcing won’t just be Oracle people; you will need people from the feeder systems involved (Legacy Teams, Data Warehouse Teams – the stuff you change may create work for them), the DBA Team, the Unix Team, the Email Team, the ERP System Admins, potentially people from external (such as Citibank). Most of all , your going to need your users.

4. So your ready to start. Once your over the ubiquitous kickoff meetings (which shouldn’t have any surprises as you did all the planning, lobbying, studies in advance right :-)? ), its time to get the team going.

Obviously an R12 ERP would be helpful. Make sure that you have the hardware, know how to upgrade a copy of Production and have it available BEFORE you have your Upgrade army. It’s a lot of cash to burn through otherwise….If you’ve got a good DBA Team they should be able to get you an instance in 2-4 Week timeframe.

If you have good internal resources, then this really helps. Otherwise external consultant will need to take a bit of time to understand how you use Oracle ERP – sure most companies work in roughly the same way, but every company has its difference; some are very different indeed.

At this point I normally split off into streams; I split into modules, team leads across each module (we have 31 standard and custom modules, spanning HRMS, Procurement and Finance).

The Functional Team should be preparing an initial high level Test Plan, working closely with Business. In parallel they should use their knowledge (and the R12 Upgrade Guides) to identify the relevant changes to the company. The Test Plan should be comprehensive and signed off once complete. This should cover all Test Scenarios across all Business Areas, including external systems. The Functional Team should also try to identify, in conjunction with the Business and Development Team, customizatons that can be removed with new functionality provided as standard. (We removed 10 check formats in a single morning – imagine the saving when you need to rewrite these, do Technical MD.070, Functional MD.050, Testing, etc. A Little time doing this could bring significant savings).

The Development Team should again be split across Modules. If you have a customization register (and we have all 1,600 customizations registered so we don’t miss any) you can use this as a very good monitoring tool. Working closely with Functional Team, identify the core stuff – there is no point in working on a report first, if you can’t enter the invoice to test the report. Once you prioritize the customizations (and possibly modules if you have limited resources), start working to upgrade these, document and test.

Now based on R12 experience, from a Technical Perspective, AP and Payments are very difficult. GL customizations had 60% small updates required. Self Service needed a re-implementation to move from MOD*PLSQL to standard Java pages. Custom modules were largely unaffacted and OAF upgrades with minimal overall issues.

If the Developers update the Customization Register with flags saying Unit Tested, Fixed, Require Fix, it becomes an excellent monitoring tool providing exact progress on your project. Ensure that you use source control. There are cheap, cheerful and excellent solutions including Subversion. This is a great tool.

Once the Test Plan is signed off, Consultants and QA’s should start ensuring that comprehensive Test Scripts are available. As they are being written, the application should be tested initially to throw up the bugs. The earlier you find them the earlier you get them to Oracle Support to get fixes. R12 does have quite a chunk of bugs, especially in Payables. Keeping a close eye on Metalink is important – when new RUP’s 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….they’ll cause a lot of issues, it’s newly released and 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 to provide single patches. If you are early in the project stage, then apply the RUP’s, but do it on a Patch System and check it first…..they can cause real damage. At some point though your going to have to freeze patches, otherwise you will never finish.

Whilst all this is going on your DBA team should be working on practise upgrades and optimization. It will take many upgrades to get it right.

5. So you have your Test Plan, Test Scripts and Customizations. We run what we call an Internal UAT. Basically its a UAT but it is carried out by the R12 Upgrade Team, not the user. Try and get an exact copy of Production, upgrade fully, deploy the objects and do the setup. (Be careful to carry out pre and post upgrade steps)

Given that some modules are going to be delivered before others, 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 HRMS track? I would argue no.

The point of the Internal UAT is to run through the entire test, as the users would do. This includes external systems such as Legacy, your planning systems, Citibank, or whatever. All bugs should be recorded. (We use a tool called JIRA which is fantastic)

Be particularly careful to look at the upgrade process itself. You should simulate a close on your R11.5.10, reconcile on 11.5.10, then do the upgrade then reconcile again on R12 and make sure the R11.5.10 and R12 add up. This is critical and we found what we think is a major issue on accruals when we did this.

6. Another clone of Production should be taken. All objects, customizations, setup should be done on the UAT environment (If you have not been keeping deployment registers, BR.100 would strongly suggest you start doing so……) Usual 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, a lot of new and 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.

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 an Upgrade Manager you can then review and summarize easily progress across the entire ERP Suite. Now that is sweet…….Again 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.

Make sure all Test Scripts are tested. Make sure Month End and Year End are similuted, 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 cookies and drinks (non alcoholic please…..don’t want people testing when they are drunk….) creates a good ambience.

Record all issues and bugs as you go – again a tool like JIRA is great. Monitor closely and ensure that when your users are doing UAT, your R12 Team are there to assist. Some areas may need twice weekly meetings on certain modules. 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.

On completion, ask the head of each area and other users to sign off a standard AIM Acceptance certificate.

7. Whilst the UAT was going on I hope you were also planning to do something else right? As UAT goes on, you should be planning what will be a very compex 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.

Don’t underestimate the deployment.

You should have deployment registers for each module, including tasks for DBA, System Admin, etc. You should also have a big thick document on the steps the DBA’s do in the actual upgrade. Separate deployment registers with hyperlinks to relevant setup docs, BR.100, etc.

Review the deployment registers and figure out what can be done in advance of R12. We transferred new programs, menus, value sets, etc to R11.5.10 without switching on certain components. All of this saves a little bit of time and will ease the stress of the upgrade weekend.

Ensure the BR.100 (or other setup instructions) are clear, concise and complete.

Call meetings with the users and make sure that the cutover (and possibly closing processes) are clear.  We are doing the closing in R11.5.10 just before cutover, closing down all transactions, etc. Why? Couple of reasons. If data is left open in R11 (say unaccounted) it will give real problems in R12. (We worked for months to get the script from Oracle and luckily we found this prior to go-live). Secondly it allows you a whole month before your first closing in R12. You can do a couple of simulations of Production and sort out issues if needed. The users will lose Production for a few business days, unless you do it on a holiday……..its a big upgrade. Our’s runs for 42 hours.

Get a register of who needs what responsibility on the day and how many setups they need to do. Set these up in advance so you know who needs what access and are not scrambling on the day. It also lets you balance the workload. We have almost 600 setups. A lot in Payments.

Deployment of code. If you have used Subversion (or another Source control system) then you can grab all changes and give to the DBA’s. Make sure your directories match Oracle’s and Subversion as that will make deployment easier. A lot can be automated and this will save a lot of time on the cutover. Now with all the prep work the DBA’s started over the previous months maybe this is something they could also have been working on…..There are a lot of standard Loaders that can save lots of time.

Talk to Oracle 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.

Make sure you do patch reconciliations between your UAT and Rehearsal databases.

Hold a few internal meetings to ensure that everyone in IT knows exactly their role. Watch out for people booking holidays in advance. One key person out could derail your go-live.

As PM, you should be writing a PM.030 Transition and Continegency Plan that covers all the angles.

If the cutover fails all your hardwork will have gone to waste.  Rehearse, Rehearse, Rehearse……

8. Cutover

Generally over a four day window. Holidays are ideal but make sure you tell Business well in advance if their key system is going to be down during business hours. We plan to be down by 5:00PM on a Wednesday and up by 7:00AM Monday. We also have a migration to Linux thrown in. Wednesday, Thursday are days for the actual Upgrade, Friday the Upgrade Team roll in to do setup, customizations, etc. Saturday and Sunday are for testing with a go-live decision on Sunday evening. As we are moving server, our contingency is simple; if the cutover is a no-go we simply turn 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 Practises from Oracle for more detailed advice. If you don’t do this you will hit serious problems.

9. Post Go-Live. There are going to be problems on anything of this scale. Thats a given. Have all teams on standby so that when issues arise, they can be addressed. With Oracle Critical Support you’ll hopefully be in better shape than with standard support. As soon as possible clone production to a test system and simulate the payroll, closing and other key events in advance.

10. Party? 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. Good Luck !!!