Posts Tagged ‘Self Service’

Star Wars Episode IV: A New Hope – R12 Self Service Jedis

April 14, 2011

Now I can’t do the scrolling Yellow Text and the famous Star Wars fanfare, but I reckon most people will have already got the Star Wars theme for this blog. The force is obviously strong in you.

There is a serious disturbance in the force across the corporate Galaxy. Have you ever thought that your company is built up of numerous Sith Lords, all wanting to basically build a Galactic Empire of epic proportions, with no relevance to the goals of your Business.

Think of it this way. Each of those Empires is building deathstars 0f immense power over decades. Each of these wields terrible power across your company reaching to every corner of your corporate universe. At the head of these powerful empires are your typical Darth Vaders, Darth Sidius’s and other villains that steal the lifeblood from your company and quash any rebellions against them with absolute force.

However despite the absolute power, in our galactic quadrant, a small group of Rebels started a rebellion with a view to wipe out the tyranny of the Evil Empires and bring freedom to the corporate galaxy. These few were the R12 Self Service Jedis. Or perhaps you’re a Princess Leia wanna-be? (If you’re a guy and a Princess Leia wanna-be then I’d certainly find you a little strange in a long flowing white dress, but each to their own……)

So what better way to start with than a movie  recommendation. It has to be Star Wars Episode IV: A New Hope. This was a truly cutting edge movie (which a top movie critic in the UK stated was “rubbish” at the time of release – there was a truly epic screw-up……..). Well Star Wars was the thing of dreams for millions of kids (and adults) and continues to be to this very day. It’s a 10 out of 10 movie and you should buy it on DVD.

In 2001, our company built an ERP deathstar providing the various Empires powerful facilities that did everything to consolidate their power. Bar one item. Included in this deathstar was one area that could, maybe just could, undermine the Empire. There was a small part of Oracle ERP dedicated to the galactic citizens. This allowed galactic citizens to check Galactic HR records for:

Payslip

Staff Receivables (*)

Pension (*)

Company Savings Scheme (*)

Bank Account designated for Payroll

Personal Information

Staff Information

Education

(*) Indicates custom Screens we have written in OA Framework

What is interesting is that many of the above screens are pure standard functionality. Easily and very quickly enabled across the entire Galactic Empire.

Enabling the simple Staff Information gives your staff access to Employment, Salary, Performance, Training and Job Applications with a simple addition to a menu. (The screen has most of the data removed for privacy reasons).

Now perhaps you are thinking big-deal, who cares about Payslips. Well we have 2500 staff across 27 Galaxies each requiring a Payslip twice per month of 3 pages. We also have 1,000 Pensioners requiring a Payslip across 66 Galaxies. That’s over 200,000 pieces of paper that have to be printed, put in an envelope, sent to the various far flung corners of the galaxy and all that costs a huge amount of time, money and bureaucracy. Putting a Payslip online (and have it populated as a natural part of Payroll) wipes out this pointless costly burueacracy in one swift action. Start to consider the effect for a Galactic Corporation of 25,000 employees, or 50,000 employees. The savings year after year after year are immense. Not to mention that online Payslips are delivered at the speed of light, being available seconds after Payroll is completed.

(As above all the key information has been removed for privacy reason, i.e. my privacy……. although as can be seen last month I cleared 34 cents – it was better than usual 🙂

For 30 years this Payroll Empire outpost had created tyranny and bureaucracy by making citizens beg for key information that was held on the Empire’s central computers. This functionality brought a small part of freedom to the citizens in this far flung quadrant.  However the Jedis from the Oracle Corporation sect quickly left in 2001 as these were mercenaries, who would only stay whilst the galactic credits kept flowing. After that the Galactic Empire’s consolidated their power, insisting each citizen continue to file vast quantities of paper with no specific purpose.

Our journey to restore freedom to our corporate Galaxy fighting against the Empire began on the small planet of Tatooine some 6 years ago back in 2005. Surveying the corporate galaxy the Jedi’s looked for areas of maximum gain where an attack would carry minimum cost and risk.

The Empire ran a facility to give Loans to Galactic Citizens (Employees). The loans were ironically managed by an army of Galactic clones that actually managed the loans and deductions to Payroll MANUALLY using spreadsheets. There was no risk on this, given they were TRIPLED CHECKED, leading to even more clones.

The Jedi’s reviewed this facility. A citizen could loan based on their Galactic Salary and length of service to their company. The Jedi’s checked and  they could get this information from the HR System. A citizen could request for a loan to be paid into their Bank Account. This could also be found in the Payroll/Payables system. The Loan could be paid using Accounts Payable and R12 Payments modules. Finally Loan interest was deducted each month from the citizens Payroll. Check – The Jedi’s could do this through 100% automation.

So exactly what were these clones doing that they demanded citizens to fill out reams of paper, have it checked in 6 separate Empire facilities shuffling paper between each, wait for weeks or months for the approval, then finally pay the loan. This was Galactic madness, purely to justify the Empire’s existence.

With a simple OA Framework screen linked to the Empire’s Accounts Payable facility, the Jedi’s managed to remove the Empire’s clone army in a six month operation. Citizens would apply for a Loan with a few clicks of a Self Service screen. This sent an invoice to Payables (pre-approved) and fed through to R12 Payments, then through SWIFT to the citizens Bank Account. The end to end application process moved from 2 weeks to 2 minutes, with no Empire intervention.

The second part of this sytem, the Loan Engine created by the Jedi’s plugged into the Empire’s computers and automatically removed the correct interest each month from the citizen’s Payroll, with no Empire intervention from clones. The Loan Deduction fed through automatically to the Self Service Payslip.

This system now processes over 4,000 Employee Loans every year. Imagine the manual work that was done before this Self Service System was deployed.

Given this was the first attack on the Empire, everything was automated, except for the R12 Payments module, which still required manual runs of the Payment Cycle Programs in R12 Payments. The Jedi’s were careful about picking full scale battles with the much feared Sith Lord Dollarius at this early stage in case the Empire became aware of the serious challenge that was growing within. A key tactic in the Jedi Wars to bring the freedom of Self Service to the Corporate Galaxy was to carefully choose their battles, delivering quick wins, at limited cost and risk.

(Again the screen is censored, but normally you could see the Loan amounts you can borrow, current loans, etc)

The next obvious move was to take out an Empire facility that did nothing but produce Certificates for Citizens. These Certificates could be for Employment, Salary, Wages, Tax and many more. Staff used ancient technology from the days of the Old Republic to fill out Old Republic Excel sheets and sign, and send to the Empire Central Processing Facility. The Empire demanded citizens wait two weeks for their own information, whilst armies of Empire Drones ran reports, got the information, sent memos to other facilities, got returned information from said facilities, cut and paste a variety of sources into an Old Republic Excel or Word document, checked the information and waited for the return of Darth Vader, the feared Head of the HR Facility to physically sign. This was the information tyranny that was feared throughout the corporate galaxy, draining desperately needed funds from well run Republic planets to fund an army of mindless Empire drones in bureaucracy.

With the plans from Princess Leia to the facilities HRMS System, the Jedi’s worked out that a small custom system to access this could be used by the citizens of the Old Republic to access their own information, removing the need for the endless army of Empire clones.

“There is something very wrong when it takes so long to get your own information from the Empire”

Obi Wan Kenobi

With a small OA Framework screen, loading of electronically scanned signatures and a little bit of BI Publisher force, the Jedi’s slashed through the endless bureaucracy of the Empire. The Empire’s Darth Attornius questioned the validity of scanned signatures, but traders and governments throughout the Empire readily accepted these, allowing citizens to apply easily for Bank Accounts, Tax Refunds and all manner of other necessities.

A signed (scanned) certificate with the citizen’s own information could be generated within seconds by the citizen themselves simply by selecting the certificate type in a Self Service screen, pressing a button and waiting a few seconds for a PDF file to be generated, with a scanned signature attached. Imagine a process that involved many people, many departments and took weeks to deliver information that citizens often needed quickly. Imagine that process where absolutely no-one was required, the citizen pressed a button and got what they needed within 5 seconds. That was the power of the Jedi Self Service.

Another small Empire outpost fell without a fight to the R12 Self Service Jedis.

In 2006, the year we launched this Self Service feature, we had 2,500 Certificates created. By 2010 that had grown to over 6,000. (For a company of 2,500 people).

This could be delivered by any small Jedi strike team in a very short period of time at minimal cost. Scale this up to a global entity of 50,000 and savings are immense. The other immediate payback is a lot of very happy citizens who get what they need in seconds.

(Note there are confirmed rumors that the Jedi Sect from Oracle Corporation has provided Certificates in R12 which the Empire and most Jedis are unaware of. See Employment Verification in Oracle Self-Service Human Resources Deploy Self-Service Capability Guide (Part B31648-03)

This short episode outlined the initial skirmishes with the Empire, mostly which went to plan, to deliver the initial foundations of Self Service functionality and freedom to the Corporate Galaxy with rapid ROI.

The R12 Self Service Jedi’s will continue with Episode V – The Empire Strikes back shortly…….

Further Prophecies can be found at https://oracleprophet.wordpress.com

Advertisements

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

An iRecruitment Odyssey

September 13, 2010

 Too many companies do recruitment in a not dissimilar way that would probably have happened around the time that Homer wrote his famous Odyssey poem back in 850 BC. Exaggeration – maybe a little, but consider someone needs a person, they advertise, interview and the person gets a job. Want another person, repeat the same process. That’s the way it happened three thousand years ago and it’s still largely unchanged today for too many companies.

Now the 20th century has added some refinement to the recruitment process, but it still left an awful lot to be desired. Your average organization still posts into newspapers or into the (almost) 21st century job boards on the internet. Your average applicant will have a nice shiny resume to send.  Your average organization will still process the same loser that you’ve rejected twenty times on each application. In short, recruitment still remains for most companies, a very intensive process indeed with many non-value added processes involved.

Our organization was somewhere between 850BC and the 21st Century in terms of recruitment, although probably leaning to the former rather than the latter…….

This led to some pretty serious problems for our organization:

  1. Recruitment cycles were incredibly slow
  2. Adverts cost a lot and don’t really hit the correct audience most of the time
  3. Good candidates were lost for future positions as it was all paper based. There was no corporate memory of candidates
  4. There was no option of pro-active recruitment, unless you looked through millions of papers in filing cabinets
  5. By the time you get the process going, the candidate is not available
  6. Candidates rarely find your organization, unless they read the right newspaper on the right day – recruitment is not a process, it’s a chance encounter between the applicant and the organizations advert
  7. Processing large volumes of candidates was slow and time-consuming as the HR department was swamped by job seekers
  8. After going through 200 resumes, you work out that 90% of those are not even relevant, but you still need to check every resume just in case………
  9. For staff away from the office, it was difficult to apply as paper submissions were required

In 2008, our organization decided something had to give. We were in major expansion mode needing considerably more staff (around 20%), but our recruitment processes could simply not support the business need. The case for iRecruitment was born and the odyssey began.

Our project followed the typical standard AIM lifecycle model, with the usual BR.100 Setup documents, MD.050 Functional Designs, etc.

 

We won’t dwell on the lifecycle model as its standard Oracle AIM. But what we did find was that for an average iRecruitment implementation, it could be achieved in 6-9 months, giving a pretty fast win and an even faster ROI.

Pre iRecruitment, our recruitment process was pretty archaic (and probably familiar to way too many readers…….)

  1. HR writes a job specification
  2. HR asks web developers to post job specification on organization website (and many don’t even have this today…..)
  3. Web developers enter this into the website
  4. Contact the newspaper with the specific advert, even though you have no idea if the adverts actually get you candidates or if it’s just a waste of your dollars or yen or euro……..
  5. Applicant views jobs either from website or by chance in the newspaper
  6. Applicant downloads a form from our website
  7. Applicant fills in form
  8. Applicant emails form to our organization’s HR Department
  9. HR Department files form in a very large room with millions of other forms – if you remember the scene from Indian Jones when they put the Ark of the Covenant in a huge warehouse never to be seen again. That’s kind of what happens to a lot of job applications……
  10. HR Department types form details into Oracle HRMS – the form is hugely complex and we needed teams of people to do this. Even more interesting was that only a fraction of the details were ever recorded and many details were wrong……….
  11. HR Department reviews each applicant
  12. HR retrieves forms from filing cabinet for shortlisted candidates
  13. Shortlisted candidates are kept in an Excel Spreadsheet
  14. Unsuccessful candidates aren’t told anything as processing 100 rejections would take too long. The impact here is that candidates think your organization doesn’t really care, so they won’t bother applying again
  15. HR prints short-listed candidate forms and sends to relevant department through internal mail
  16. Department Co-coordinator gets forms one week later
  17. Department Co-coordinator sends forms to relevant person one week later…….
  18. Person reviews forms, writes comments manually and gives back to Department Co-coordinator
  19. Department Co-coordinator sends forms back to HR department, where they manually update the comments into HRMS (sometimes……)
  20. HR arranges interviews with the person (if by this time they are still available)
  21. Department wonders what is going on as this process can take weeks
  22. Department finally gets all the forms back in triplicate for applicant interview
  23. All the other applicants are wondering what is going on as nobody informs them of progress of vacancy
  24. Interview takes place – notes are all paper based
  25. End User Department informs HR of the results
  26. HR validates the results
  27. HR send offer to candidate (via email)
  28. Candidate accepts or rejects
  29. All details are then typed fully into Oracle HRMS
  30. If someone wanted to find the same skills in the future, the process either had to be repeated or someone had to look through millions of pieces of paper or someone had to remember that two years ago they saw a really good resume…….not exactly a good process…….more a recruitment lottery than process.

This was a long and extremely painful process for the Applicants, the HR Department and the End User Departments requiring the resource.

By bringing in iRecruitment there was a very radical shift, both in terms of process, but also in terms of the mindset of everyone involved.

 

With the new process 100% online, we reduced the overall process by more than 50%…..

  1. HR writes the job spec and presses a button to enable on the website
  2. Applicants fill out their own details online, directly into HRMS
  3. HR reviews the applicants online and presses a button to refer to the End User Departments
  4. End User Department shortlists online, with full visibility to the HR Department
  5. HR arranges the interviews, with candidate automatically informed of status of either interview or rejection with regrets at all times during the process
  6. End User Department interviews
  7. HR validates results online
  8. HR Department sends the offer
  9. HR Department changes the Person Type in HRMS to Employee with no other changes required

10.  It’s a wrap!!!!!

The advantages of this process are very obvious indeed:

  1. Immediate savings by removing the need for a team of people to type in potentially 60,000+ resumes per year, with all the mistakes that entails
  2. Electronically link your advert to either your website or job sites, all under the control of your HR Department
  3. Removal of over 1 Million pieces of paper per year – good for the planet and good for your business
  4. Candidates are kept in the loop at all times and this shows your organization in an extremely positive light
  5. Reduces the need for expensive newspaper adverts
  6. End User Departments have far quicker access to Candidates
  7. Reduces the recruitment cycle time significantly, giving you the edge in recruiting the best people
  8. Massive online, searchable resource database that allows pro-active recruitment
  9. Reduces significantly the amount of HR time spent on recruitment
  10. Online referrals
  11. Apply anywhere, anytime and attract candidates GLOBALLY
  12. Hugely flexible model can be applied to centralize the HR process and federate the recruitment process

The biggest challenges and pitfalls we faced were on the Change Management and some issues very much specific to putting Oracle ERP into the outside world:

  1. The Technical Team (DBA Group) had to become very familiar with the DMZ Configuration to allow iRecruitment (and effectively therefore your ERP) to be put into the big, bad internet world.
  2.  Keeping up to date in terms of security patches in Oracle ERP is key. A prime example of a security flaw reported can be found on the following link.
  3. Keeping up with the latest ATG (Technology Patches) is critical, as you are now moving from your nice “my company has these PC’s with this Windows version” to “any candidate with any device (PC, Apple Mac, Ipad, etc) running any O/S with any browser wants to use your site”. The only manageable way to do address this major technology issue is to let Oracle Corporation do it for you: watch Steven Chan’s column, watch My Oracle Support and make sure you keep reasonably up to date on ATG Patches. Plan carefully as some of these patches are massive and although generally very good with limited impacts to your ERP, care as always with Oracle patches is mandatory. 
  4. The concept of a support team for external users was not really there – although iRecruitment saves a huge amount of resources, someone still has to answer the user calls. A solid user support structure must be in place and it’s a real grey area whether this is an IT or Business Responsibility. Our HR Department took the lead in this. Supporting a massive global user community is very different from internal support. 
  5. Our biggest User Support problems were related to:
    1.  Character Sets (make sure you have a multi-byte character set on the database, otherwise cut and paste from Word, etc fails……..This will cause support chaos and I am sure some companies are still running without multi-byte character sets)
    2. Login issues (Make sure you have very clear Quick Guides)
    3. Browser issues (make sure you are on the latest ATG Patches and keep updated)
    4. General User errors (good User Guides are essential)
  6. What was actually most difficult about this process was really getting the HR Department to let go of non-value added functions. This required a huge amount of Change Management effort and even 9 months on we are still not there. Letting go of functions that have been performed for the last 40 years is understandably very difficult, even when they add no value (and actually detract value from the process). 
  7. The other aspect of iRecruitment is again on Change Management. It really is a revolution to go from passive recruitment (wait for people to apply) to suddenly having a massive database of resumes that you can actively search on. This hasn’t really quite hit home yet in terms of changing mindsets within our HR area. Suddenly they have a resource pool of 40,000+ applicants, 2,500 staff and 20,000+ Consultants available to search at their fingertips with highly advanced resume search capabilities. 
  8. Customizations were required which ideally would have been better avoided. However the iRecruitment module is pretty flexible in this respect.

What we also found is that there is a wealth of companies out there using iRecruitment. We learned a lot simply by trying some of the sites and looking at their Help Guides. You never know, I may even get a new job with one of the registrations 🙂

However as the statistics show, the rollout of iRecruitment has been a huge success, with a massive and very active user base.

iRecruitment Statistics
Months Live Applicants Database Growth Per Month Vacancies Applicants Per Vacancy Successful Recruitment Paper Saved Process Reduction
9 Months 45,000 5,000 700 73 241 1M+ Sheets 50%

 What is amazing is the real global reach of systems like iRecruitment. A quick look at our statistics shows applicants from 85 countries from countries across Europe, the US, Asia and Africa. Countries as diverse as Philippines, Japan, Canada, Australia, Italy, Vietnam, Mongolia, Afghanistan, Tonga,  Russia, Iraq, Jamaica, Peru and South Africa to name but a few.

Great talent is in every culture, race, religion and every corner of the planet. iRecruitment allows you to very effectively tap into that huge wealth of human talent, wherever it may be.

All of the above of course can lead to some interesting support issues that you will not generally encounter in your average day to day support of internal Oracle ERP systems.

Of course we’re not there yet. So what does our future hold in terms of iRecruitment?

  1. Upgrade of the database to support documents in Microsoft 2007. This support comes with 11G and above.
  2. Questionnaires to filter out the 90% of unsuitable applicants so that resumes don’t even have to be reviewed. A sample is shown below.

 

3. Skills and Competencies – a very advanced feature that will allow you to match Job Specification skills and competencies to that of the candidate (including both internal and external resources)

4. Rollout to 28 countries worldwide to support our other offices across the globe (happening in September 2010)

5. At some point upgrading to 12.1.3 or above to take advantage of the extensive interview functionality available.

6. Finally persuading the HR Department to let go of the short-listing and let candidate details go straight through to the End User Department, to allow our HR personnel to move from low value added activities to pro-active recruitment

7. Assess Oracle Business Intelligence iRecruitment, to allow our HR personnel to move from low value added activities to analysis and improvement of the process worldwide

 

 Looking back, our iRecruitment project certainly had some fairly unique challenges, given this was dealing with a very large outside user base. However, overall our iRecruitment Odyssey was a short journey, relatively painless and low-cost with huge rewards at the end.

This was definitely a journey worth undertaking.

Other Resources

There are a huge amount of resources on the Web that is interesting for any company implementing iRecruitment. My thanks go to the generous authors and organizations that make these resources available to all.

For those with Oracle Open World On Demand access, the following may be of interest from 2009:

End to End Talent Acquisition in Oracle iRecruitment 12.1

How to achieve High Volume Recruiting with iRecruitment