Oracle ERP Prophecies

Business Intelligence and the Kung Fu Dragons of Wudang

October 3, 2010

I recently watched an interesting program on TV about the Kung Fu Dragons in Wudang, China. The students join from a very young age and basically study 16 hours a day to become a Kung Fu Dragon Master over many, many years. The training is difficult, filled with risks of failure and many give up before ever coming close to becoming a Kung Fu Dragon master. Indeed the truth is most simply don’t have the skills, time or patience to reach the heights of a true Kung Fu Dragon Master. Very few will ever become a Kung Fu Dragon Master.

Now you look at data warehouses and Business Intelligence and ERP. It’s extremely difficult, filled with risks of failure and many give up (after spending a fortune) before they even get close after many, many years of trying. The truth is most simply don’t have the skills, time or patience to reach the heights of a true Kung Fu Dragon Master in Business Intelligence and ERP. The parallels and similarities are indeed striking.

Now the Art of Zen Patching article talked about patience and a non-aggressive approach. Not so this article. This article is really designed to allow you to become a true Kung Fu Dragon Master in Business Intelligence in 9-12 weeks (in vanilla implementation) and stresses a highly aggressive approach to Business Intelligence and ERP. (This article doesn’t ask for any money to be sent for some dodgy DVD and a certificate I printed in my bedroom. This is free, it’s not marketing hype – this is the real deal).

A cautionary tale before I start.

I’ve seen the two sides of data warehousing with Oracle ERP. One European company I know bought a bunch of expensive, state of the art tools almost a decade ago. Almost a decade on, with a lot of tears and pain (sounds like a Kung Fu Dragon training course…..???), 2 million bucks and a change in system architecture that will require massive re-work, users simply not adopting because what has been achieved is small, fragmented and ad-hoc, and performs like a three legged dog (indeed in the user manual it instructs the person to submit the report and then get a coffee for 20 minutes before coming back or lunch if it’s a larger report) - the dreams of being a Kung Fu Dragon Master in ERP Data Warehousing lie in shattered pieces, a ruin of what should have been a shining example of 21^st Century technology. This isn’t a one off – according to independent research a huge percentage of projects fail in the custom approach. Indeed it is the minority of ERP Data Warehouse projects that succeed.

Sure they bought the most expensive software, they put in piles of money, but they never sought a Kung Fu Dragon master to train them properly, preferring naively to think that they could learn the art of the Kung Fu Dragon Business Intelligence off a DVD in front of the bedroom mirror whilst their parents wondered what the weird shouts and snake hissing sounds were from upstairs………Instead of being a Kung Fu Dragon Master of Business Intelligence, they ended up as more like something of a joke reminiscent from the movie Kung Fu Panda……….Trust me if you’re a Kung Fu Business Intelligence Panda, people are laughing at you, not with you…….

(By the way, if you haven’t got the DVD for Kung Fu Panda movie, it’s highly recommended). As well as Oracle Fusion Apps being released in 2011, Kung Fu Panda 2 will also be out…..

Here’s the other side. I’ve seen Oracle come in with the prebuilt ERP Analytics, install the database, ETL tools, dashboards, KPI’s and reports and do all the data orchestration, extracts and imports in……..seven hours………Now I’m an utter skeptic when it comes to Oracle marketing and consultancy, but yes, I watched as one single Kung Fu Dragon Master in Business Intelligence and Pre-Built ERP Analytics achieved in 7 hours what could not be achieved in 7 years by an army of untrained people in another European company. Now this was only a demo (done for free as a demonstration of what could be achieved), but it took all our historical R12 Oracle ERP Accounts Payable data for 7 years and transformed it in a fully defined, fully functional data warehouse with dashboards in 7 hours. This guy was an Indian Kung Fu Dragon Master in Business Intelligence from Oracle Singapore. I was in utter awe of what could be achieved so easily and so quickly by one talented individual.

Have a look at Haemonetics Corporation story at Oracle Open World on Demand (Oracle On Demand Access Required) and then the results when they moved to Oracle’s prebuilt BI Applications approach.

The reason this utterly amazing complete data warehouse could be achieved is due to the pre-built Analytics packs that Oracle now provides (for of course, an additional license fee), together with of course an incredibly talented Indian Kung Fu Dragon Master.

So what’s the deal with Oracle BI and Pre-built Analytics?

Oracle is moving heavily into the BI market, taking the overall lead in terms of BI according to Gartner, much to the surprise of many.

In parallel Oracle is moving to create an unprecedented amount of pre-built content for Oracle ERP (including R11, R12, Peoplesoft, Siebel, JD Edwards with SAP in the works in 7.9.7…..) moving the task of creating a data warehouse from a vast army over many years (with a horrific failure rate) to a guy with an installation disk. Or that’s the single great hope and prophecy of Oracle Corporation. OK, we’ll never get to an installation disk, but if the guy with the installation disk can get us to 70% I won’t be complaining……..

Finally Oracle is now heading towards, probably in R12.1.4 to embedding the BI content directly into Oracle ERP screens. (The technology to do this by embedding into Java screens – not hanging a BIEE screen of an ERP menu by the way – was released as part of 12.1.2). If you also look at the new Fusion Apps, embedded dashboards are now an integral part of each module. According to Oracle at Open World 2010, there will be “hundreds of pre-built embedded analytics in (Fusion V1) or as they put it another way “Analytics are always available in Fusion Apps”.

Whatever BI tool or preference, you have to admit Oracle’s strategy and growth is certainly very impressive. With the recent release of Oracle BIEE 11G it just gets even better. The presentation layer is truly fantastic.

So many are probably asking, what’s the pre-built content for Oracle ERP?

Oracle has effectively written for you the following components:

Data Extraction from Oracle ERP (and many other ERP’s)
Data Orchestration (pulling dependent tables as needed with full synchronization)
Data Import to Data Warehouse with full management and restart capabilities
Data Model Design of Warehouse
Standard Dashboards
Standard KPI’s
Standard Reports
Security Models
Integration both to and from Oracle ERP
and a whole lot more

Now all of the above have been done not by a single Kung Fu Dragon Master in Business Intelligence, but by an army of Kung Fu Dragon Masters in Business Intelligence and ERP at Oracle Corporation.

These guys are experts in Business.

These guys are experts in Data Warehouse modeling.

These guys are experts in BI.

These guys are experts integrating BI to ERP.

These guys are experts at extracting data reliably from ERP to a data-warehouse.

The product line has come from a huge amount of hours collaborating with top businesses around the globe to find out what an ERP Data Warehouse should be

They have created something that no matter how much money and how deep your pockets, you will never be able to match, because Oracle Corporation is in the software business and can use economies of scale. Your company isn’t, despite the best intentions of your IT department.

The Pre-Built Analytics module list for Oracle ERP is equally impressive and is growing substantially on a consistent basis. This now covers:

Now it’s almost definite that this list will continue rapidly expanding, so that not only is there prebuilt content on ERP, but you’ll find it integrated directly into ERP (R12, Fusion, etc) and I bet into all of the other tools that Oracle has in the coming years including their database and other management tools. Basically if you are running Oracle ERP now, you WILL be running Oracle BIEE in the years to come.

Not only does Oracle Pre-Built Analytics create entire date warehouse content, they also add to it on a frequent basis. So when Pre-Built Analytics 7.9.6 was released it had a whole raft of brand new areas of HR addressed including Talent Management, Learning and iRecruitment.

So if you are still considering building using a custom approach to Oracle ERP Data warehousing, think about this foolish Kung Fu Panda……

Imagine that Oracle ERP has some 14,000 tables – do you really want to build a data warehouse from this (and will it actually perform…….????)

Imagine having to write extracts from the key tables which although much smaller is still huge. Imagine writing all the complex logic on something like Order Management for the extracts.

Imagine having to define a complex data warehouse model (and no, ERP and standard database design don’t work for data warehouses – it’s a completely different approach from a relational database model so your skills won’t work here……).

Imagine having to write processes to manage the extraction and import of data.

Imagine having to do the Security models.

Imagine having to do all the integration to and from your ERP.

Imagine trying to keep your custom built data warehouse in synch with Oracle patches, upgrades, etc

Imagine designing and building 100’s of dashboards with no idea of the proper principles of dashboard design and usability

Still fancy your chances of building a BI Apps comparable product Kung Fu Panda? Have a look at the summary data warehouse of BI Apps…….I guess you would be a whole lot less confident if it was your own money at stake on your custom build rather than your company’s……

The above represents years of work by an army of highly skilled, highly paid people, where the company must wait for a very significant time to get the results if you choose to custom build. Where you don’t get these highly trained people (as too many companies don’t), the consequence is simple – utter failure and massive cost.

And of course, even if you build it, what happens when you add another 2,000 users? Is it scalable or will you find major flaws in the design that are incredibly costly to fix? With Oracle Pre-Built Analytics scalability has already been designed in by the experts.

Still not convinced? Well let me give you the stats on Oracle’s prebuilt analytics:

350 Fact Tables

550 Dimension Tables

5,200 Pre-Built Metrics

15,000 Data Elements

And Kung Fu Panda, do you really think that the quality and performance and design can match that of the Kung Fu Dragon Masters from Oracle Corporation that do nothing but BI Applications? If so put down that Vodka bottle (or whatever else you are smoking) and get a reality check.

Or how about this Dashboard, with all the extracts, imports, data model behind it? For info this is Oracle Projects, one of the hardest niche modules in the entire ERP Suite, with links to EVERYTHING…….

In BI Apps just for HRMS there are 9 dashboards with a whopping 47 pages, 230 reports and 330+ metrics. And that’s just ONE MODULE OF BI APPS !

By the time you build that using a custom build approach (that’s so 1990’s in terms of approach – are you also still using Computer Punch Cards?) you’ll be retired or fired before you see it go-live……..

Today Oracle has the capability to deploy in 9-12 weeks (in vanilla implementation). Marketing slogans and nothing else? Absolutely not. We watched Oracle install everything (from database, to tools, to dashboards and migrate 7 years of data) and bring up Accounts Payable in 7 hours as a proof of concept. I can be pretty skeptical and hard on vendors, but believe me, this was truly amazing the ease with which this product could be brought up.

Now true there are some serious challenges around also, even with the Pre-built Analytics. Anyone thinking they can buy this and that’s it, well that unfortunately is naïve. I wish life was that simple……

The fit of the BI Analytics needs to be checked in terms of dashboards. What we found was that a lot of dashboards fitted very well onto the Business Requirements. Please bear in mind that dashboards are very easy to build (and BIEE is very easy to learn), especially when the Kung Fu Dragon Masters at Oracle Corporation have done the hardest part of building the entire data model and all the data extractions for you. Even if you find no use for the pre-built dashboards, simply having the data model and extracts will save you a huge amount of time. Now looking at Infosys they reckon a 70-80% fit in terms of BI Apps. I’d tend to agree that would be a ballpark figure when we assessed this against our ERP. (And remember a fit means data extraction, import, data models, dashboards and all the other components).

If you do have custom modules, then you will need to build the extracts, data model, etc. However don’t be fooled by naïve arguments that if you’ve customized your ERP, BI Apps will not work. I’ve rarely seen a company modify base tables in ERP (add new custom tables yes) as they would be extremely foolish to do so. Therefore BI Apps will have just about every key table from the core ERP model you could possibly need. That’s a huge chunk of work already done.

You will need to define further dashboards and reports. That is a given. BI Apps will get you very far down the line, but it won’t be a silver bullet.

You will need to design data models and extracts for any custom modules you have. That can be a difficult task, but your ERP will already have all the data models, extracts provided by BI Apps. Custom modules are almost always a whole lot simpler than Oracle ERP Data models.

One of the biggest tasks that not even pre-built analytics will address is Training and user adoption. Moving from reports and Excel to Analytics is a major business change exercise and should be treated accordingly. The project can still fail even with great pre-built content, because users are not trained appropriately and there is a lack of vision in how this can really change the way the user community work.

The cost of prebuilt analytics is still a major problem I think. There are alternates out there that are much, much cheaper but then you have to consider upgrades, risk of building, integration and a whole host of other problems. I love the Oracle BIEE and the Pre-Built analytics but the cost is still pretty high. Of course compare the cost of that to the cost of building all this yourself and there is just no comparison between the two, like for like. Playing hardball with Oracle Corporation (ideally at their year end when the best deals can be achieved) can pay dividends in terms of price, although I’m not going to give away how cheaply we got offered the prebuilt analytics……There are still alternates to Oracle in many areas, solution wise and Oracle should be reminded that you can go elsewhere…..

Pre-Built analytics for ERP can get you there fast. But a big bang approach is not recommended. A fast initial deployment to a small community followed by consistent wins over a period of time, slowly building up the user base and expanding across the lines of the business is the way to go, bringing in and training champions each and every step of the journey. Then you’ll succeed where so many others fail. When everyone can see frequent wins (and with BI Apps it can be every few months), it becomes an unstoppable train that everyone wants to get on. BI Apps is beautiful eye candy that users seem to love. (Or is it that they finally can get their own answers in seconds without waiting 12 weeks for the IT Department…..)

You can buy the software, but you need to sell the vision, otherwise you fail. IT Alignment to Business Alignment and support from Business is the key to any successful project.

I’d still recommend having a BI Expert around who you can gain the knowledge from. Again Pre-Built Analytics is not a silver bullet and your staff will need to be properly trained by an expert.

I think all companies running ERP should be looking seriously at BI Apps, even those with the approach of building everything. In the 90’s companies realized the value of letting Oracle, SAP and the rest build their ERP applications. That’s now a generally accepted principal by most companies around the globe.

Over 2,500 companies have already adopted the BI Applications. If it was cheaper (a message to Oracle Corporation and Larry Ellison) the uptake I am sure would be massive.

In the coming months, I’ll write a few more articles on deep-dive into some of the core areas of BI Applications – HRMS, Financials and Procurement, time permitting.

I think in the 21^st century, that same principal will gain general acceptance on the value of pre-built analytics for ERP. Put quite simply, in the cut-throat economy companies can’t wait ten years to become a Kung Fu Dragon Master of Business Intelligence with Oracle ERP.

Companies need to achieve that in 9-12 weeks (vanilla implementation) and the only way to do that is to rely on the Kung Fu Dragon Masters from Oracle Corporation that have already done this for you…………before your competitors beat you to it……..

Related Articles

Below are a number of articles. Some are your average Oracle Sales pitches, but all the same very informative overall. Others are written by generous authors whom I acknowledge and extend my thanks to for writing very interesting and useful articles, which were used as background research during writing this article. (I particularly enjoyed the articles by Jeff McQuigg and Mark Rittman, both renowned experts in their field and excellent authors. Their articles are highly recommended reading).

For those lucky enough to have been to the Oracle Open World 2010 show (hope you enjoyed the Black Eyed Peas !!! Turn down the volume before you click that link……), the following can be accessed from Oracle Open World On Demand.

(Note there were many more sessions, but many do not yet have the content uploaded at the time of writing – 2^nd October 2010. I have chosen to hyperlink only a few of my favorite session links. Others are available in Oracle Open World On Demand).

End-to-End Oracle Business Intelligence: From Warehouse to Advanced Analytics
Enterprise Sales Analytics with Oracle Business Intelligence Enterprise Edition
Oracle BI Applications Roadmap, Including Support for Oracle Fusion Applications
Oracle Business Intelligence Enterprise Edition Integration at Comcast
Oracle Human Resources/Oracle Financial Analytics for ResCare Decision-Making
What’s New in Oracle Business Intelligence Suite, Enterprise Edition Plus 11g
Gain the Insight You Need with Oracle Business Intelligence Applications
Implementation Experiences with Oracle Business Intelligence Applications
Implementation Experiences with Oracle BI Applications
Oracle Transactional Business Intelligence (OTBI)
Haemonetics Corporation: Better Decisions with Oracle Human Resources Analytics
Get Real-Time and Actionable Information with New Reporting and Analytics

Tags: Accounts Payable, BI Apps, BIEE, Business Intelligence, Data Warehouse, Fusion, Fusion Applications, HRMS, iRecruitment, OBIEE, Oracle BIEE, Oracle Corporation, Oracle ERP, Oracle Financials, Peoplesoft, Prebuilt Analytics, R12, Siebel
Posted in Business Intelligence, ERP Management | Leave a Comment »

R12 Patching and the Art of Zen

September 18, 2010

Reading through Wikipedia, I found an interesting article on the concepts of Zen. Now I’m not really into that type of stuff myself (each to their own), but I thought it would make an original way to present this article

“One practice of Zen Buddhist’s is Koan Inquiry. A koan is a question, or statement, the meaning of which cannot be understood by rational thinking but may be accessible through intuition. The answer can occur during meditation or during your typical daily life with all the mundane tasks you do.

To Zen Buddhist’s the Koan is “the place and the time and the event where truth reveals itself”. It is a way to induce an experience of enlightenment or realization, not through rational reasoning, but through intuition.

Answering a Koan requires a student to let go of conceptual thinking and of the logical way we order the world, so that like creativity in art, the appropriate insight and response arises naturally and spontaneously in the mind.”

Or to quote from a very non-Zen perspective, you think about a problem very hard all day. You fail to make any breakthrough. During the next morning, in the shower, without even thinking of the problem, you suddenly think of the idea. Ironically perhaps we are all practicing Koan Inquiry as a natural state of mind to solve difficult problems, without even having to think about the problem at hand.

Now let’s look at ERP Patching in relation to Zen We need to be clear from the outset that this form of Zen Patching applies only to the following patches below. This is extremely important to keep in mind.

Security Patches

ATG Patches

Database Patches

This form of Zen does not apply to other ERP Patches

Applying this form of Zen Patching to any other types of patches will cause you some serious grief in your career when you report to your boss that your ERP for your entire organization worldwide is trashed because you read some amazing article by some “new age ERP guy called the Oracle Prophet” on a radical new method using the Art of Zen for ERP Patching and thought it was worth a try on your Production System……….

Do note that this form of Zen Patching does work on both R11 and R12, but not on R10. It also works on 9i, 10G and 11G databases. Please check Oracle Certification matrices and raise the question to Oracle Support if in doubt.

Oracle Support – Good morning. Can I help you?

Reader – Yes could you tell me if the Art of Zen patching is certified against R12 Apps please?

If the phone goes dead at this point, we suggest you assume Oracle Support is not aware of the Art of Zen patching and you should not pursue your question with them……….We also suggest you give your colleagues name during any telephone calls with Oracle, in case Oracle raises a complaint for nuisance phone calls to your company…..:-)

So where does the Art of Zen fit into Oracle ERP patching?

Let’s use a typical a koan to provide an illustration.

“We will test the patch by not testing the patch. Only then will we know that the patch has worked.”

Now at this point in time, you are probably thinking I’ve been hitting some fairly strong stuff to get to this state of mind, or I’ve completely lost the plot.

I can hear everyone thinking “So let me get this straight. You are going to test the patch by not testing the patch, so that you know the patch is working”. To which I’d reply, great you’ve got it. You are certainly a quick learner on this Zen Patching stuff!!!

Our R12 Patching Philosophy actually made our auditors jaws drop, not in terms of the Zen stuff (trust me, keep this stuff between yourself and myself please and maybe better not mention to your management or auditors……), but on the thoroughness of approach.

We always have five databases for our patching (at a minimum). This is probably a lot more than most have but let me explain why and you’ll probably want to then copy this model.

Our DBA Environment. This is where the patches are applied to make sure, well they actually apply. Believe it or not some patches from Oracle don’t even apply cleanly.

Our Patch Environment. This is where they are applied with a little bit of testing. OK we deviate a little from the Zen stuff, but give me a break……This makes sure they at least do what they say on the box without major functional failure.

Our development environment, which is always busy with daily activity by our development team , functional team and testers.

Our test environment which is always busy with daily activity by our users.

Our Production environment. I’ve been pushing our company to drop this as it uses a lot of space and we hear most of our complaints from this database, but management insist it is important and needed.

We should also state our databases are pretty heavily used so application flows naturally are being used throughout development and test databases. We also apply any patches onto any other instances we have at that point in time, so that the patch is naturally tested by the simple day to day activity in as many places as possible, with a careful rollout to each environment.

The Art of Zen Patching

The point is simple on these types of patches. Oracle does release patches that should be applied at some point.

The Security Patches typically come quarterly and we try to apply 3-6 months after they come out. Security patches represent a serious risk to apply, although generally apply well. However security patches also represent a risk if you do not apply. You need to find the balance, but you SHOULD apply these regularly.

The ATG Patches are less frequent but provide critical updates to Browsers (especially if you have DMZ applications) and other technology components, including diagnostics.

The Database patches (and we’re talking 10G to 11G for instance) do come out periodically and at some point you need to decide to keep at least supported, although we’re very picky on applying these, but are in the process of an 11G Upgrade. (Various 10G database versions are losing or have lost premier support). This activity is every couple of years or so.

We’re not talking about applying every patch. No company in their right mind can achieve this. We’re talking about keeping your head above water and staying supportable.

The point is this. To test every time on these types of patches across every last item is impossible. The conventional way is to get the patch, apply, test everything and then move to Production in a few weeks. That’s a very logical way to order the world of Oracle ERP. But unfortunately this is not a very practical or safe way. These patches are by their very nature too broad and silently hit too many areas to be open to a logical, standardized testing process. The conventional approach actually increases risk with these types of patches because it is by no means obvious what could be impacted.

There must be a better way where you find that balance. This is the Art of R12 Zen Patching.

Our philosophy is simple. We plan carefully on all these types of patches well ahead of applying.

We do not apply these patches immediately they come out. We are kind enough to give others the opportunity to be the heroes or unenlightened who find the bugs, log them in My Oracle Support and make our life so much simpler because we heavily research each patch to find the problems the unenlightened logged. This way we avoid the bulk of the problems. Are you one of the unenlightened? If so we appreciate you finding the bugs for us, causing issues for your users on Production systems and generally making our life so much easier and less stressful.

Our philosophy then rests correctly on a peace of mind that these patches are largely stable, largely trusted and tested by others around the world. This isn’t just a philosophy, it’s backed up by hard facts based on an incredibly low failure rate of patches we have applied. The patch types listed are generally very mature, very stable and very reliable. The quality of these types of patches is far higher than the Oracle ERP patches for the application modules.

Our key philosophy can be defined by the koan below. (As you raise a smile, remember this is used in leadership teaching by guys that make more in a month than you make in 5 years and sell books by the truckload at Amazon

“Once upon a time in ancient Japan, a young man was studying martial arts under a famous teacher. Every day the young man would practice in a courtyard along with the other students. One day, as the master watched, he could see that the other students were consistently interfering with the young man’s technique. Sensing the student’s frustration, the master approached the student and tapped him on the shoulder. “What is wrong?” inquired the teacher. “I cannot execute my technique and I do not understand why,” replied the student. “This is because you do not understand harmony. Please follow me,” said the master. Leaving the practice hall, the master and student walked a short distance into the woods until they came upon a stream. After standing silently beside the streambed for a few minutes, the master spoke. “Look at the water,” he instructed. “It does not slam into the rocks and stop out of frustration, but instead flows around them and continues down the stream. Become like the water and you will understand harmony.” Soon, the student learned to move and flow like the stream, and none of the other students could keep him from executing his techniques” – Timothy H. Warneka

Now I’m not into all this stuff and I’m as skeptical as anyone else, but maybe they have a point. Too many companies are simply slamming into the rocks with patches, rather than working with the flow of Oracle Corporation. Working with Oracle, you often feel that you are not talking of a stream but more a raging torrent of patches. The problem is you are always fighting against the flood of patches, rather than finding what these guys would refer to as “harmony”.

The very essence of our philosophy and the koan itself can now be answered

“We will test the patch by not testing the patch. Only then will we know that the patch has worked.”

After rolling the patch through DBA and Patch environments very carefully over many weeks, we are ready to proceed to our main development and testing environments.

We typically roll patches into our development environment for a minimum of 4 weeks. We observe the behavior of the environment and record any bugs. We carefully investigate all bug occurrences.

Once we are comfortable at that point, we do run testing. OK so we broke our mantra, but nowhere near the testing that would normally be required. Why? Because we have seen the bugs naturally arise through our normal daily activity (as a Project Manager you’ll know typically what is going on and where the gaps may be I would hope). So to quote the Art of Zen,” the appropriate insight and response arises naturally.” This is the beauty of the Art of Zen Patching You do your daily stuff to get to the answer of whether the patch causes major grief.

At this point we normally release the patches to our Test Instance, again allowing patches to settle for 4-8 weeks. Again using normal user activity, we gain further appropriate insight and responses, in terms of stability of the patch and subsequent bugs, arising from the natural process of user activity.

We do ask our users to test and hit the key functionality, but again, with the insight given from normal daily use, we have achieved ” the appropriate insight and response which arises naturally” as a Zen Master or Leadership or Lifestyle coach would tell you for quite a lot of cash

Even our DBA Team reaches a relaxed Zen like state and if you know your average DBA guys……… With planning comes time for our DBA Team to work and document carefully the steps needed for each patch. The timeframes create space for many, many practice runs, so that on the day of application to Production, they know exactly what to do and what to expect. It also creates the space and time for good old fashioned research on My Oracle Support. (A tip is that as we’re doing this approach over a number of months, the DBA’s always get copies of Production on a regular basis to run through the patching process, so any production specific issues are always encountered early).

In addition, we carefully plan for releases. So if you take our last security patches, these were rolled into an ATG RUP6 and a minor database point release (to stay supported). This reduces a constant patch cycle to a more manageable ITIL Release concept, reducing your workload overall. The raging torrent of patches becomes a much more manageable stream.

Most companies have huge stress over these types of patches. Most companies don’t even bother applying, much to the detriment in terms of support, future upgrades and security.

We are like every other company in many respects. We are highly conservative on applying patches. We like to stick on what we know.

But we do pay attention and plan for security, de-support of databases, new browser support in ATG RUP’s, etc in a very careful manner well ahead of time, allowing us to practice the Art of Zen Patching

Companies stress out, rush patches and therefore make mistakes. That is not the Art of Zen Patching. Zen Patching stresses the very opposite approach. Put the patch into your environments, slowly observe and watch over many months, then test and finally you will see the appropriate insight and responses that it has worked. Now looking at Wiki again, Monks meditate over many months or even years to answer a Koan. There is no difference in the approach of Zen Patching The time the patches spend in your environments can be thought of as your meditation period over many months (typically 3-6 months depending on risk assessment) to find the answer to the koan of “how to test the patch without testing the patch to know the patch has worked”.

But with our R12 Zen Patching, we’ve reached an almost Zen like state Patches are simply a natural part of the lifecycle of ERP. We have accepted that. They are planned and are allowed to settle for several months, to give insight into their nature and risk. Patches still require testing, but to a far lesser extent than a fully focused, high risk “lets test this patch and apply this patch in two weeks time”, which is similar to slamming into the rocks in the stream.

So where are we today with such an approach?

R12.0.4 RUP5 (yes this was a nightmare of testing the old fashioned way, definitely slamming into the rocks in the stream, but our go-live was incredibly smooth. Zen Patching doesn’t work here I’m afraid for those embarking on an R12 Upgrade. It’s the good old fashioned conventional testing approach that is needed here).

Security Patches to April 2010

ATG RUP6

11G and July Security Patches are currently under the Zen method as is a SUSE Linux Upgrade

We have never had a failure or serious outage as a result of Zen Patching (should I trademark this perhaps and make a lot of cash like those leadership guys??????), although as with all Oracle patches, it is a very serious business, with serious risks, so there is no place for complacency.

So what about the opinions of others on our ERP and how up to date we are overall with patches? To quote one Senior Consultant DBA recently, we are way ahead of most companies in terms of patching, and have an “aggressive patching policy”.

I would say that the Art of Zen Patching can never be described with words like “aggressive” . In fact it is quite the opposite. It is a very slow and considered process, stressing great patience, over many months, waiting for insight as a part of a natural process to reduce the risks we face, as the real Zen guys would put it

We simply achieve a lot more than most companies, with a lot less effort and a lot less risk. I think the Zen guys and leadership/lifestyle gurus would term it as “simply learning to move and flow with the Oracle stream creating harmony and peace of mind”. Obviously they’d be charging a thousand US Bucks an hour for this type of advice. (I remember we had one such IT Guru in our company. Cost us 6 figures for six weeks of work – we ended up using his laminated b*llshit as coffee mats……that was about the only value we got……). Now maybe the Consultant our company hired wasn’t too hot except for the coffee mats, but with some of these leadership and other philosophies, well maybe there’s something in it after all……

Call it Zen. Call it Lifestyle (or is it Patch) Management , but to have a safe, low risk and stress free approach to this type of patching which works with reduced effort (rather than increased effort) is not a bad place to be, as an ERP Manager…….

Health Warning

This article was designed to present a very serious subject in a hopefully entertaining and educational manner utilizing both conventional approaches of testing, in conjunction with a more unconventional approach. However applying any patches on a Production Database is a very serious business. Patches do need testing and this should never be underestimated. However the point of this article is that by allowing patches to settle into various instances over time, you vastly increase the chances of spotting serious issues and vastly reduce the risk of issues in production that conventional testing can never address. This is the safest way to apply such patches that I have found, using a conventional testing approach, together with a far less conventional approach. 21^st Century Testing meets 5^th Century Zen Philosophy.

Disclaimer

(By the way, I haven’t been smoking anything….the intention of this article is to present a very serious subject – Oracle Patching – in hopefully what some will find a very funny and original manner, that can then be remembered and applied to help all of us that face the very serious risks of patching global ERP Systems, so don’ take all the Zen references for Patching too seriously………otherwise someone may think you’ve been smoking something………). Think Monty Python British humour as you read it……..

If you remember the article, change patching from a rush to a planned perspective and patch carefully over a period of months, then the article did it’s job

I hope you find it as funny to read as I did writing it

Tags: ATG Patches, EBS Security, ERP Patches, Oracle Corporation, Oracle ERP, Oracle Patches, Oracle Upgrade, R11, R12, R12 Patches, R12 Upgrade
Posted in ERP Management | 9 Comments »

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 20^th 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) 21^st 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 21^st 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:

Recruitment cycles were incredibly slow
Adverts cost a lot and don’t really hit the correct audience most of the time
Good candidates were lost for future positions as it was all paper based. There was no corporate memory of candidates
There was no option of pro-active recruitment, unless you looked through millions of papers in filing cabinets
By the time you get the process going, the candidate is not available
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
Processing large volumes of candidates was slow and time-consuming as the HR department was swamped by job seekers
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………
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…….)

HR writes a job specification
HR asks web developers to post job specification on organization website (and many don’t even have this today…..)
Web developers enter this into the website
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……..
Applicant views jobs either from website or by chance in the newspaper
Applicant downloads a form from our website
Applicant fills in form
Applicant emails form to our organization’s HR Department
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……
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……….
HR Department reviews each applicant
HR retrieves forms from filing cabinet for shortlisted candidates
Shortlisted candidates are kept in an Excel Spreadsheet
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
HR prints short-listed candidate forms and sends to relevant department through internal mail
Department Co-coordinator gets forms one week later
Department Co-coordinator sends forms to relevant person one week later…….
Person reviews forms, writes comments manually and gives back to Department Co-coordinator
Department Co-coordinator sends forms back to HR department, where they manually update the comments into HRMS (sometimes……)
HR arranges interviews with the person (if by this time they are still available)
Department wonders what is going on as this process can take weeks
Department finally gets all the forms back in triplicate for applicant interview
All the other applicants are wondering what is going on as nobody informs them of progress of vacancy
Interview takes place – notes are all paper based
End User Department informs HR of the results
HR validates the results
HR send offer to candidate (via email)
Candidate accepts or rejects
All details are then typed fully into Oracle HRMS
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%…..

HR writes the job spec and presses a button to enable on the website
Applicants fill out their own details online, directly into HRMS
HR reviews the applicants online and presses a button to refer to the End User Departments
End User Department shortlists online, with full visibility to the HR Department
HR arranges the interviews, with candidate automatically informed of status of either interview or rejection with regrets at all times during the process
End User Department interviews
HR validates results online
HR Department sends the offer
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:

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
Electronically link your advert to either your website or job sites, all under the control of your HR Department
Removal of over 1 Million pieces of paper per year – good for the planet and good for your business
Candidates are kept in the loop at all times and this shows your organization in an extremely positive light
Reduces the need for expensive newspaper adverts
End User Departments have far quicker access to Candidates
Reduces the recruitment cycle time significantly, giving you the edge in recruiting the best people
Massive online, searchable resource database that allows pro-active recruitment
Reduces significantly the amount of HR time spent on recruitment
Online referrals
Apply anywhere, anytime and attract candidates GLOBALLY
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:

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.
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.
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.
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.
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)
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).
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.
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?

Upgrade of the database to support documents in Microsoft 2007. This support comes with 11G and above.
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:

v End to End Talent Acquisition in Oracle iRecruitment 12.1

v How to achieve High Volume Recruiting with iRecruitment

Tags: 12.1.3, Business Intelligence, ERP, HRMS, iRecruitment, R12, Recruitment, Self Service
Posted in HRMS | 8 Comments »

Tools for a Recession – JIRA

September 1, 2010

Not exactly an optimistic title, but companies have been tightening their belts and asking for ERP Teams to do more with less. Further a lot of companies that use Oracle ERP aren’t the mega rich companies but small to medium sized businesses, so getting tools to help you with your job in ERP isn’t easy.

However there is a whole parallel universe to all your expensive, fancy vendor tools. In this article we’ll look at one company that created an incredibly useful, stable and very flexible support tool.

Now I know what you’re thinking. This is crazy running these non-fancy, inexpensive, unsupportable, high risk tools in large companies. I had a colleague who was always ranting about these tools and how open-source would take over the world. I regarded that colleague as a bit mad to be honest. However, I’m now eating my words and am totally converted and writing a blog “ranting about these tools”. Interesting turn-around………….

These tools are heavily supported. These tools have become main-stream. And these tools do provide amazing functionality. In short, any organization should have a look at these tools as they vastly improve your processes, your ERP Management and at the end of the day, improve your customer service massively.

The Tool for a Recession Product for today is called JIRA. It is ridiculously cheap and for some organizations free:

“JIRA is free for use by official non-profit organisations and charities (proof of non-profit status is required). There are certain organisations whose purpose is to make the world a better place, and we believe in helping them achieve that.”

These guys not only write great software, they also have a very positive, highly ethical and pro-active approach to helping all organizations that aim to, as they so eloquently put it, make the world a better place.

JIRA is from a company called Atlassian. The website can be found at:

JIRA Website

This website gives a very comprehensive view of the functionality, which is way beyond this articles remit.

This article is purely intended to tell you what has worked for me in managing Oracle ERP including Support and Projects (although this tool could be used for pretty much any software development or change management).

So what do we use it for?

Change Management

Our Change Management process for ERP Requests used to involve lots of paper requests from our users and a large spreadsheet. Not exactly rocket science and a huge pain to manage. Things got lost, forgotten, etc. We used this manual process to manage around 20 modules in our Oracle ERP.

We are now managing over 40 modules (including custom) in ERP, so it is fortunate we put a more automated process in place using JIRA.

With the capabilities we saw in JIRA, we figured that we could get the signed copy of the Change Request, create a Change Request in JIRA and then attach the signed Change Request. This allowed us to have lots of other information held on our Change Request, such as Impact, Risk, Department, Module, Sub-module, Audit References, etc which proves extremely useful. Actually we found that JIRA can be easily extendable (with no programming) to include a very large number of fields.

Issues can further be categorized to pretty much whatever you want – Bugs, Improvements, Patch, TAR (Sorry, Service Request – I am showing my age…), etc. A sample fully customized Change Request Screen (with no programming) is below.

We are working to remove the paper completely by allowing users to directly enter the Change Requests, get Approval from their managers and simply assign to our IT Group. This not only gives a super efficient support process (with visibility to all) but also removes completely all paper trails, but provides a vastly superior audit trail over any manual, paper based system. (It also allows collection of statistics on your processes, allowing for further process improvement, as a simple by-product of using the tool).

One of the great things about JIRA is that it has highly configurable workflows, so we mapped our ITIL Processes onto JIRA, allowing us to track where a Change Request was in the process at any point in time.

I won’t go into detail on the workflow, but basically it is totally configurable with no programming and very powerful indeed, with of course e-mail notifications, etc.

An ITIL Change Management Process was put in place so that each person in the IT Team updates their Change Request statuses as they progress.

From a Manager viewpoint, it is then very simple to assess the workload of each person, module, etc and where each request is in the overall Change Management Lifecycle.

From a Management viewpoint it’s also pretty interesting to watch the stats. A lot of Cancelled Change Requests shows a tendency for a department to ask for trivial items that are not needed. Similarly disapproved indicates a further tendency for trivial and unnecessary changes. Too many in Team Lead review suggests perhaps your Team Leads are swamped. The Summary views can also be seen by module, by developer, etc. Actually as the backend of JIRA can be Oracle, you can pull out virtually any statistics that you wish. Additionally JIRA has easy extracts of the data to Excel, making Management reporting a breeze. Key statistics such as Aging are easily available.

A Management Dashboard can be easily configured to give pretty much any view of your Project or Support for ongoing ERP Operations. JIRA has so many gadgets that can be added showing different windows in a dashboard with great configurable filters.

So adding for instance a gadget called Two Dimensional Filter Statistics can give you an exact view of all the tasks, statuses, etc of your entire team on a project, on a dashboard in real-time, at your finger-tips instantly. (Which is faster than you could say that sentence……)

(The names have been airbrushed so as not to embarrass my staff who have lots of backlog requests to do on Oracle ERP……Hence the names look messier than they would in JIRA)

One of the other interesting aspects of JIRA is that it tends to create a real community, as developers can fix items and assign to testing, then testers can put screenshots and other attachments and notes of what is failing. It tends to really increase team interaction tremendously, resulting in faster projects, less cost and better products overall to the client.

Finally JIRA has good security allowing the right information to be accessed only by those authorized to do so. We’ve found it to be pretty flexible.

I’ll be posting an ITIL compliant Change Management process in a future blog for those that are interested (that has been heavily scrutinized by the likes of Deloitte and PWC, so I guess it’s reasonable). It’s not super complex, just enough to get you by the auditors.

Bug Tracking and Management

The other area that we use JIRA for is Bug Tracking. Given a lot of people will be doing R12 Upgrades I thought the best way to show this would be to actually show a few screenshots of our R12 project itself and how it is setup in JIRA.

We setup R12 as a new project in JIRA. This keeps it simple

As we moved through the project we had different phases/instances of R12 (shown below) modeled as Versions in JIRA terminology:

If you have a look at the R12 articles elsewhere on the Blog, you’ll start to see how this all ties together. We started out with our R12IMP (a very early release) and then moved to a more stable R12 Development.

We spawned off various testing environments (R12UP4, R12UP5, R12UP6, R12UP7) as we went through a horrific number of patches (this was 2008 and R12 wasn’t stable back then).

We finally moved into R12UA1 (our internal testing – IT Group) and R12UA2 (External Testing – User Group).

Finally you can see our R12CUT. This recorded all bugs during cutover to Production on 3^rd August 2009, making sure that everything was recorded (we cloned PRD to R12CUT after upgrading PRD and tested on the clone before the users got onto PRD) and all bugs fixed. This was done over a four day window. Not an easy task, but JIRA certainly helped hugely in that process. We went live with no major issues.

So going back to the bugs, JIRA again made it incredibly easy for us on the R12. Bugs were logged by QA’s, developers, Functional guys, etc. These were then assigned to the appropriate resource to resolve, then re-assigned to test, then closed. Service Requests could be tracked (as JIRA can add additional fields) as can Patches. This gave a complete view of the entire R12 Project in terms of health and overall bugs. A detailed view is shown below (that of course has drill downs). As with just about everything else in JIRA, the views are also highly configurable.

During testing, Developers or QA’s or Functional guys could also take a quick screenshot and attach to the bug, change request, etc.

The great thing is that as we went through our Versions (effectively stages in your project or environments depending on what you prefer), JIRA can be modelled to track each and every stage. So if you apply for example a patch in a new instance, you can retest and track all the bugs associated with that particular patch on that particular version. (Configuration takes a few minutes in JIRA to allow this).

As well as Versions (Phases of Project or Environments) we also modelled each module as a component in JIRA. This allowed an easy and quick view of progress, bugs, etc across our R12 ERP Suite.

Again this gives easy access to Team Leads, Functional and Management to see problem areas, before they become problem areas…….

And hopefully at the end of your R12 Upgrade you’ll have a screen of lovely green in JIRA, with minimal issues left as you go-live. Our final status report in JIRA shows completion across all environments and phases, with no major issues outstanding.

Summary

The important take-away from this blog is that JIRA provides great Change Management and Bug Tracking (ideal for R12 projects or indeed any IT project).

Of course, we suggest you also go and have a look at the JIRA website on

JIRA Website

as there is so much more to JIRA than we covered here.

A truly remarkable piece of software.

Tags: Change Management, ERP, ITIL, JIRA, R12, R12 Upgrade
Posted in ERP Tools | 2 Comments »

Looks like 12.1.3 is Imminent

August 20, 2010

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

The Release Notes for 12.1.3 are now out:

12.1.3 Release Documents

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

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

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

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

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

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

R12.1.x Vision Instances

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

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

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

Oracle E-Business Suite Release 12.1.3 Release Update Pack (Patch 9239090)

Oracle E-Business Suite Release 12.1.3 Readme (Note 1080973.1)

Tags: Oracle ERP, R12, R12 Upgrade
Posted in R12 Upgrade | Leave a Comment »

12 Steps to R12

August 16, 2010

Date: 16th August 2010

During the Oracle OpenWorld 2009 in San Francisco, the average conference session started with “How many of you are on R12?” The show of hands was no more than 5% in any given session. Recent research suggests only 5% of companies are on R12 as of mid 2010.

Many organizations will be starting the journey to R12 in 2010, given the end of Premier Support for 11.5.10.2 in November 2010. Our organization successfully completed an Oracle E-Business Suite Release 12 Upgrade (R12) in August 2009. This article shares our experiences so that readers can benefit from what we did right and avoid what we did wrong.

Following are the twelve steps our organization followed during its R12 upgrade, along with suggestions and insights that others might use in their own upgrade projects.

Step 1 – R12 Study

It is recommended that before doing an R12 Upgrade, you do an assessment/study to determine the impact an R12 would have.

Get a little funding, do test upgrades, an impact analysis, try the new functionality and then go for full funding of the project. This leads to a highly informed and carefully scoped project.

Many companies got burned very badly by early adoption of R12. If a study had been done first, I doubt they would have upgraded so early – saving a lot of time, money and heartache.

Step 2 – Business Case

The key foundation to any project is a good Business Case that everyone agrees on. It gets the funding, visibility and users onboard. Emphasize the benefits of improved Oracle Support and significant new functionality.

I would recommend that you keep the R12 Upgrade as much as possible a Technical Upgrade (utilizing new functionality where appropriate), but it is a daunting task and the fewer new things thrown in the better.

Step 3 – Planning and Preparation

There are a few things you should check prior to recruiting an upgrade team.

Make sure you have the hardware to do the upgrade. Your typical upgrade will require an extra 6-12 Instances and you still need 11.5.x instances for ongoing production support. Prior to bringing any expensive external resources in ensure you have R12 Instances to work on.

Write a detailed project plan. Figure 1 shows a very high level approach. Doing an upgrade is not rocket science…..the devil is very much in the detail. Remember you will need to schedule time with many different groups – Legacy, Data Warehouse, Business Users, DBA, Server Team and the ERP Team. During an Upgrade all major initiatives will need to stop to allow you to focus on R12, so be sure to set user expectations in advance.

Recruiting – Each company varies on how they staff an upgrade. Unless you have a very good in-house team, you will need help. Consultants will save you time and money. R12 has a lot of new modules and functionality, so we brought in expertise. It really helped and knowledge was transitioned to our internal resources.

The DBA Team will take between 2-4 weeks to get an R12 instance, depending on their skills. Put this into your plan.

Doing a PM.010 – Project Management Plan helps you to focus, together with a solid Work Breakdown Structure. Together with a good Risk Register (brainstorm with your team) you’ll protect yourself from some of the pitfalls.

R12 is a lot bigger than any previous upgrade in Oracle ERP. Your plan should reflect this. Planning is everything for a successful R12 Upgrade.

Figure 1 – 12 Steps to R12

Step 4 – Review and Design

A short amount of time reviewing what you have and what is new will vastly improve your upgrade. The Functional Team should use the R12 Upgrade Guides to identify the relevant changes in Functionality.

The Functional Team should also try to identify with the Business and Development Teams, customizations that can be removed with new functionality provided as standard. A little time doing this could bring significant savings.

There is significant new functionality in R12 and the Functional Team should review with the Business to show the possibilities. Keep a balance – the focus should remain on the R12 Upgrade, not new functionality.

The Functional Team should also be writing new MD.050 Functional Designs – there will be customization needed in R12 and other Functional Designs may need updated.

Working closely with Functional Team, identify the core customizations. Once you prioritize the customizations you have a solid basis for moving into the Build and Test Phase.

Step 5 – Build and Test

Functional Stream

The Team should prepare high level Test Plans, working closely with Business. The Test Plans should be comprehensive and signed off. This should cover all Test Scenarios across all Business Areas, including external systems.

Once the Test Plans are signed off, ensure that comprehensive Test Scripts are written. As these are being written, the application should be tested initially to throw up the bugs. The earlier you find bugs the earlier you get them to Oracle Support to get fixes.

Technical Stream

The Technical Team MUST have a customization register. This can be used as a very good monitoring tool. If you don’t have this, how do you know what to upgrade? Customizations should be upgraded methodically according to your plan from the Design phase.

Technical Summary – Our Customization Upgrade Impact

General Ledger 80% Minor issues – Set of Books ->Ledger_ID

Self Service 30% MOD*PLSQL Dessupported

Accounts Payable 30% Change of Database Structure

Payments 60% Upgrade Check Formats

OA Framework <5% Minimal Issues

HRMS <5% Minimal Issues

Payroll <5% Minimal Issues

Procurement <5% Minimal Issues

Receivables/Fixed Assets <5% Minimal Issues

Source Control

This is essential so if you are not using any tools, you are doing something very wrong and risking your Production System. Open Source tools such as Subversion are ideal.

Patch Management

One key consideration is your approach to patches – aggressive or conservative. We went on an early version of R12 (released one year previously) and we choose conservative thinking it would be relatively stable. Towards the end of the project, we saw stability still had not been reached. We moved to a highly aggressive patching strategy that really did get us to stability, although it was extremely painful with multiple regression tests and carrying considerable risk.

Reviewing Metalink is important – when new RUP’s (Roll-Up Patch Sets) and CPC’s (Critical Patch Sets) are released, you have a very important decision to make on whether to apply. If your well into your project, the advice I would give is not to apply unless required….patches cause a lot of issues. If the patch is newly released you’ll be the poor guys finding all the new bugs. Leave that to someone else.

Obviously if you have critical errors, pile the pressure on to Oracle Support to provide single patches. At some point you are going to have to freeze patches, otherwise you will never finish. Learn to work with Oracle Support and Oracle Management regionally to resolve issues.

Patch Management is critical and Oracle has some great tools for Patch Assessment under System Administration – these will allow you to make informed judgments on whether to apply patches or not. This will show all the objects changed by a patch – with that list your technical people can give you well informed advice.

Strong Patch Management is critical to any R12 Upgrade. Lose control on this and you lose control of your entire project.

Step 6 – Internal User Acceptance Test

An Internal UAT is basically a UAT but it is carried out by the R12 Upgrade Team, not the users.

Focus strongly on key functionality – if one thing has to work on Day 1 of Go-Live it has to be the key stuff – entering invoices, running a payroll, etc. Too many companies focus too much on the peripheral and not enough on the core functions. That will end in tears.

Given that some modules are going to be delivered before others into UAT, you may want to do this staged. It’s not ideal but it does compress the overall project time. You will have problems on Payables, and should that hold up your whole HRMS track? I would argue no. And I am sure some will disagree. But be pragmatic on the area of UAT and use your judgment.

Test the entire ERP and external systems such as Legacy, your planning systems, your banks or other external systems that interface to customers/suppliers/etc. All bugs should be recorded.

A few other tips:

Simulate a close on your R11.5.10

Reconcile 11.5.x and R12.x

Simulate transactions half way through workflow

Check your banks migrate correctly

Step 7 – User Acceptance Testing

Another clone of Production should be taken and all customizations/setup applied. If you have not been keeping deployment registers, setup documents, etc I would strongly suggest you start doing so. Give the users plenty of notice of when the UAT is coming and make sure you clearly set the expectations.

UAT kickoff meetings should be held and contact lists given to users. Your team will need to work hand in hand with the Business Users to co-ordinate the UAT. It’s going to be a lot of work with new, unfamiliar screens and quite a few complaints, no matter how well you’ve done till now. The Test Plans and Test Scripts should have been agreed months ago, with full review and signoff which should lessen the surprises (and complaints) users may have. Work closely with your users throughout the project from project initiation to way after go-live. That will lead to better relations and when you do encounter problems; users will go a lot easier on you, because you kept them informed right?

One trick here is to put the Test Plan on a shared drive and ask the user to mark Pass/Fail/To Test as they progress. As a Project Manager you can then review and summarize progress easily. Delivering some modules into UAT before others may be an option if you want to progress quicker. Others prefer to deliver the entire UAT. What I have found is that by progressing some modules quicker, it gives the project momentum and when you put out weekly progress tables to users, they don’t want to be last to finish. A little bit of Psychology certainly helps when doing an R12 upgrade.

Make sure all Test Scripts are tested. Make sure Month End and Year End are simulated, with proper reconciliations. Make sure all the systems to and from Oracle ERP are tested and continue to work with R12. Make sure integration between modules is smooth and working – organizing this across departments is tricky. A UAT room for this can be handy. Providing simple refreshments can create a good ambience and encourage your testers to work for you.

Record all issues and bugs as you go. Monitor closely and ensure that when your users are doing UAT, your R12 Team is there to assist. Some areas may need twice weekly meetings on certain modules with the Business Users. This will help to manage difficult UAT areas, stop user frustration and make the UAT a little less painful for all. We did this on Payables in particular. It worked extremely well.

One point – be pragmatic on UAT. Remember users have full-time jobs so doing a UAT is a big favor and usually a lot of extra work. Avoid being too pushy especially during stress points such as month-end closing and Payroll – that will simply be counter-productive.

The UAT can also double as a training ground, but do also be prepared to give additional training, especially in the areas of AP, Banks, Payments and Subledger Accounting/Reconciliation as there are significant differences here.

Step 8 – User Sign Off

On completion, ask the head of each area and other users to sign off a standard Acceptance certificate. As you achieve sign-off let everyone know – again it helps to push the other Business Areas that have not signed off. I found weekly newsletters (just a single page) kept everyone onboard. Openness and transparency is the key.

Step 9 – Transition Planning

As UAT goes on, you should be planning what will be a very complex and difficult cutover. The team should also be doing rehearsals by taking copies of production, upgrading, deploying, setting up and testing. All bugs should be recorded.

You should have deployment registers for each module, including tasks for DBA, System Admin, etc. These should be very detailed and concise.

Review the deployment registers and figure out what can be done in advance of R12. This saves time and will ease the stress of the upgrade weekend.

Call meetings with the users and make sure that the cutover is clear. The users will lose Production for a few business days, unless you do it on a holiday.

We did the closing in R11.5.10 just before cutover, closing down all transactions, etc. Why? There were a couple of reasons. If data is left open in R11 (say unaccounted) it will give real problems in R12 Secondly it allows you a whole month before your first closing in R12 to resolve issues.

Get a register of who needs does what during cutover and ensure work is balanced. Ensure every person knows their role in the cutover.

Deployment of code is a significant task. If you have used Subversion (or another Source control system) then you can grab all changes and give to the DBA’s. A lot can be automated and this will save a lot of time on the cutover.

Talk to Oracle Corporation and make them aware of your key dates, cutover, month end, payroll, etc. They can get you critical support management over that time.

Try and do as many rehearsals as you can whilst users are doing UAT. The closer the rehearsal is to an exact recent copy of Production the better. We repeatedly cloned production for three weeks prior to Production and checked our deployment.

Make sure you do patch reconciliations between your UAT and Rehearsal databases on a consistent basis. Otherwise you may be testing on completely different Patch Sets and your entire UAT would be null and void.

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

Make sure you go to the Change Control Board, publicize on your website and make sure you tell every single person that needs to know that Oracle Applications will not be available. The Cardinal Sin – missing someone out.

If the cutover fails all the hard work of your team will have gone to waste. Do you really want to be telling everyone publicly (including Senior Management) that the nice, shiny R12 that was promised isn’t live and that you had to pull out the whole upgrade at the last minute due to your bad planning?

Rehearse, Rehearse, Rehearse……

Step 10 – Cutover

A cutover generally takes place over a four day window, depending on your database size/speef of servers/etc. Holidays are ideal but make sure you tell Business well in advance if their key system is going to be down during business hours. Total Upgrade time took 96 hours, working around the clock.

Users should run key reports on R11.x and then run the same reports immediately after on R12.x. Your functional team should also do a mirror reconciliation exercise quickly during the cutover. Also keep a reference environment copy of your R11.x production.

Wednesday evening and Thursday were days for the actual Upgrade, Friday the Upgrade Team rolled in to do setup, customizations, etc. Saturday and Sunday were for testing with a go-live decision on Sunday evening. As we were moving servers, our contingency was simple; if the cutover was a no-go we simply turned our old server back on……Don’t repeat the errors you made in rehearsals, keep a log of everything that failed and make sure it doesn’t happen on your go-live, as you simply won’t have time to troubleshoot.

Be very careful that all transactions are accounted, workflows complete (as much as possible), payments complete. Review the Best Practices from Oracle for more detailed advice. If you don’t do this you will hit serious problems.

Cutover is a stressful time no matter how well planned. The Project Manager should ensure everyone stays calm, ensure work is balanced and avoid burn-out for those working shifts. Organize some food during the cutover, step in to calm any friction quickly and monitor every last aspect of progress.

Step 11 – Critical Support Cover

There are going to be problems on anything of this scale. That’s a given. Have all teams on standby so that when issues arise, they can be addressed. As soon as possible clone production to a test system and simulate the payroll, closing and other key events in advance.

Before the Go-Live, set the expectations of users. If you do this the user community and management will cut you a little more slack and be more understanding of issues encountered. A little bit of psychology and transparency will go a long way to making your transition a lot less stressful.

One tip that is useful before go-live: Brief the Helpdesk on how to take the calls as you go live. Brief the users on how to log issues. Make sure there is strong reporting available to you in real-time showing all issues. Monitor this religiously. Make sure the escalation and support teams are in place, so calls are not lost or delayed. This will ensure you have a very strong support structure to deal with the significant number of issues you will have, irrespective of how well you did the upgrade.

No-one will remember all the hard work you have done to get here if major issues are not addressed quickly. If you manage problems well and quickly the Upgrade will be remembered as a huge success. If you don’t, you’ve just thrown away thousands of hours of your team’s reputation and hard work.

Strong and very well managed Critical Post-Production support is everything in an R12 Upgrade.

Step 12 – Post-Production Support Cover

After the first month end close you should be able to move to a more standard support footing.

Don’t celebrate the day you go-live. It could get extremely embarrassing to celebrate Mission Accomplished and then hit major problems, right? We left the celebrations for 6 weeks. If you do an R12 Upgrade, you deserve a big party. R12 is the most challenging upgrade you will ever have done in Oracle ERP.

Those who fail to plan, plan to fail. Good Luck!!!

About the Author

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

You may contact Iain at irroberts@hotmail.com

Blog: http://oracleprophet.wordpress.com

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

#1 IT Service in the Company – 2008

Oracle Innovation Award Winner 2009 – ERP

Oracle Session Presentation Winner – Oracle Open World 2010

R12 Successes

Reference Material

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

R12 Resources

OAUG Website

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

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

Upgrade Manual Script (TUMS) – Patch 5120936

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

Metalink Note: 394692.1 Oracle E-Business Suite Upgrade Resources

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

Metalink Note: 437422.1 R12 Troubleshooting Period Close in Payables

Metalink Note: 73128.1 R12 Troubleshooting Accounting Issues

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

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

Oracle Financials Applications Blog – R12 Lessons Learned

Analyzing, Planning and Executing an R12 EBS Upgrade

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

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

Posted in R12 Upgrade | 6 Comments »

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

Fusion Apps questions Oracle still needs to answer (infoworld.com)
Oracle set to launch new BI suite (infoworld.com)

Tags: BIEE, Business Intelligence, Enterprise resource planning, ERP, Fusion Applications, Gartner, Larry Ellison, OBIEE, Oracle, Oracle Analytics, Oracle BIEE, Oracle Corporation, R12, SAP
Posted in Business Intelligence | Leave a Comment »

Oracle Open World 2009

October 17, 2009

Just got back from Oracle Open World 2009 and it was a fantastic show. Points of interest for me?

1. Most of the sessions started off with the question “How many companies are on R12, please raise your hands”. What really surprised me was how few companies were actually on R12. Now I assume that the ones that go to Open World are the more zealous of Oracle companies and therefore you’d expect a higher uptake of R12. Now I have no idea what the official figures are but I’d say no more than 5% of all people (and we are talking hundreds at each session) raised there hands. Most when asked were still on 11.5.x………..Which means that 2010 may well be a boom year for upgrades to R12.

2. Oracle Business Intelligence and Pre-built Analytics. I’ve loved this product since the day I saw it. Basically it was acquired from Siebel and it’s the best Oracle product I have seen in the last decade, even if it ain’t really Oracle’s……..This is really the unstated direction for Discoverer in the future and I think this product (BIEE) will really gain very substantial market share in the coming years. What they also have is pre-built analytics (entire data warehouse, dashboards, KPI’s, reports, etc) for most of the Oracle ERP. The quality and coverage of these is again superb with new products and more coverage being released on a very frequent basis. What really gets you about these products is the time it takes to implement – Oracle came on site to us and put in the entire technology, software, database, etc and extracted our data and got the dashboards running – IN SEVEN HOURS as a demo. If you heavily use ERP this is something everyone should be looking at. It’s not cheap, but then building your data warehouse from scratch usually ends in disaster………BI Analytics is built by professionals at Oracle and it shows. Absolutely stunning product that can allow management to keep a real eye on how business is doing and provides powerful reporting and analytics across the business.

3. GRC – This is another acquired product and again looks very interesting. Basically this allows you to keep track of all setup changes (although unfortunately not across all modules). Now when the auditors come in and ask to show what has been changed, nice and easy – just run a report. Or if one module stops working after changes, then if you’ve created a snapshot you can see the difference, ending hours or days of minute researching to find the problem……Or compare a UAT to a newly upgraded R12 to check you’ve got identical setup within minutes……what a great tool.

Now this has other parts to it as well including access controls, enforcing segregation of duties, adding rules, workflow and analytics (in BIEE separate license called GRCI) and other areas. Now apparently the Consulting company reckoned they could have this up and running in two months……

4. Another one I loved was the Imaging and Process Management. Basically we want to streamline Payables by imaging all invoices and workflowing them to the users. Oracle seems to be heading towards creating modules that provide services ERP wide and this is one of them. Basically this can do imaging, workflow, etc and has prebuilt adapters for Accounts Payable. Text Recognition is also coming out in the coming quarters, so it’s a very exciting product that could streamline not just AP operations, but many other areas as well.

5. When wandering around the demo grounds saw a Product called Oracle Application Testing Suite. Now this looks like the Mercury tools and it’s a great addition to Oracle’s suite. Basically it will allow you to build automated test scripts for Oracle ERP. They reckon they will also be adding pre-built test scripts, but no commitment on that. So basically you apply your patch, run the Test Suite, go get a coffee and come back and see what failed. Now my one doubt is always how long it takes to actually build the test suite – it’s not easy and I have seen a lot of companies fail. However if you can actually build a robust test suite, this could save a huge amount of time and money in the future. A very interesting product.

6. IFRS – with most companies heading towards IFRS it sounds like Oracle is already prepared. Indeed some companies are already using IFRS with Oracle. It was hard to stay awake as a bunch of accountants talked about the exciting features of IFRS, but as someone in the IT area, its good to know that Oracle should have it covered (although there will still be a chunk of work, possibly changes to your existing applications and certainly changes in the reporting sphere, so don’t assume that Oracle has it totally covered – it provides the foundations only).

7. Another interesting product was the Oracle Application Change Management Pack. Basically this allows you to build your own patches for customizations and deploy. Very nice product that should ease DBA workload and make applying customizations much more reliable and safe.

With 1800 sessions, it was hard to do anything except scrape the surface. But as an average company using ERP, hope these areas will be as interesting to you as they were to me.

Tags: OpenWord, Oracle ERP, Oracle Open World, R12, R12 Upgrade
Posted in Oracle Open World 2009 | Leave a Comment »

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.

Tags: 12.0, Accounts Payable, Go-Live, Migration, Oracle, Oracle ERP, Payments, R12, Subledger Accounting, Upgrade
Posted in R12 Upgrade | Leave a Comment »

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)

Tags: Accounts Payable, Oracle, R12, R12 Upgrade, Upgrade
Posted in R12 Upgrade | 8 Comments »

Oracle ERP Prophecies

Business Intelligence and the Kung Fu Dragons of Wudang

R12 Patching and the Art of Zen

An iRecruitment Odyssey

Tools for a Recession – JIRA

Looks like 12.1.3 is Imminent

12 Steps to R12

Business Intelligence – An Oracle Future?

Oracle Open World 2009

R12 – A Detailed Transition Plan

R12 – The Worst Oracle Release Ever?

Prophecy Archives

Prophecy Categories

Prophecy Pages

Prophecy Stats

Email Subscription

Recent Prophecies

Follow “Oracle ERP Prophecies”