Rocela values its values!

From before Rocela was born (circa 2001), fundamental values have been key to its evolution. In fact, the real trigger for Rocela was the jarring of cultures between Oracle and its largest clients and the tension that this created – a tension that Rocela would go on to soothe.

Although not realizing it at the time Rocela’s founders (Kenny Wilson and Martin Mutch) shared core personal values and attached significance to them in the boundary between personal and business lives. It is therefore no surprise that Rocela has always had a strong moral and cultural identity, and its core values have always been evident through behaviours, even when they were not specifically a focal point for development.

Over the past few years as we have grown, we have realised that scaling ‘appropriate’ behaviours and the Company culture would benefit from clarity of our values. After a full company workshop on values early 2011, we encouraged a staff workgroup to explore and define those values that our staff felt to be true of us, valued by us and important to mature and live by.

This workgroup proposed a set of core values that was fully recognised by founders and senior managers and was approved without iteration – a full description of what these values mean can be downloaded from here. Our values are:

• Customer Focus
• Expertise
• Integrity
• Professionalism
• Passion

Since then, core values have been promoted visibly, and top down are used increasingly as a guide and input to any daily decision including hiring, customer situations, investment and withdrawal, and appraisals through our performance management methodology.

So now what? It’s all very well having the values on mugs and posters – how do we actually make them come to life? A question tackled by our CEO Martin Mutch in December last year who formed the ‘next generation’ values workgroup – a group of colleagues whose task it was to devise and propose a programme for ‘Employee Values Recognition’ for our Company meeting in February 2012.

This workgroup approached all staff to ask for stories that would exemplify the company values – not so much ‘awards’ but recognition of staff ‘living the values’. The response was tremendous – over 150 separate recognition stories from all around the business.

And so began the challenging task of narrowing this considerable list down to a manageable and representative record of individuals covering all 5 values. The entire exercise was no mean feat – the values workgroup worked a miracle in getting everything in place for the Company meeting and the individuals recognised were truly humbled as a result.

We will continue to focus on our values throughout 2012 – in the way that we work, make decisions and recognise the exemplary efforts of our co-workers.


Top 5 Tips for upgrading customisations to R12

by Kenny Miller, Principal Consultant for Rocela

My colleague Ray Brown’s recent blog “Top 5 Tips for Oracle R12 Upgrade Success”  highlighted how the cost of upgrading customisations can be a significant proportion of the total cost of an R12 upgrade project.

This got me thinking about my own experiences with R12 upgrades. I doubt you’ll be surprised to learn that there is no “silver bullet” to provide an easy path for upgrading your customisations. There is no substitute for hard-work, and for approaching this work in a sensible and structured manner.

The key to success is having the correct resources available at the appropriate time in the project life-cycle, and accepting that considerable effort will be required from these resources. To help understand this better, I’ve put together my top 5 tips for upgrading customisations to R12:

1. Prepare

It’ll really help if you have some knowledge of R12. You can’t beat “hands-on” when it comes to learning, so consider installing a R12 Vision demo instance. Make sure it’s fully patched up, to get all the latest functionality and bug fixes.

Business and Super Users: Your business needs to understand how R12 functions; what’s new, what’s changed etc. This task is really part of the wider R12 project but, as we’ll see later, this knowledge is important when you review your current customisations.

I’d recommend starting with Oracle note 403349.1 which details all the Transfer of Information (TOI) content which Oracle has provided for R12. Another good resource is the Documentation Library, which for R12.1.3 is available here.

This is where having a R12 demo instance will help – it’s “play area” where you can try things out without the risk of hurting yourself!

Developers: Have a look at the usual suspects in the Documentation Library, but be aware that Oracle has started to move interface/API documentation to the “Integration Repository”. In R12, this is available in the “Integrated SOA Gateway” responsibility (see Oracle note 462586.1 for more details).

I’d also recommend the following material:

2. Quantify

If you haven’t already got one, then you’re going to need a list of all your customisations. Don’t under-estimate how long this might take to prepare – there are so many different ways to customise EBS, not all of which are obvious and easy to find. Most “mature” EBS systems have many hundreds of customisations.

I’ve done this for quite a few of our customer recently and, despite knowing what to look for, it still takes me between 3 and 5 days to complete.

3. Review

Eliminate: The easiest, and therefore cheapest, way to upgrade customisations to R12 is not to upgrade them at all! Eliminate any customisations that the business no longer needs, or those that can be replaced with new standard functionality.

This is why it’s so helpful that your business/super users “immerse” themselves in R12. Only with this knowledge can they properly understand the requirements for R12 customisation. If your organisation doesn’t feel confident enough to do this, then seek assistance. You really should avoid upgrading redundant customisations.

Prioritise: What is business-critical? What is not needed until the next year-end etc? It makes sense to focus first on the most important customisations.

4. Plan

To plan properly, you need to know how much effort is going to be required. This is a challenging task, even for those of us that have considerable experience with R12. You need to know R12 well before you can attempt this with any degree of accuracy.

It’s not just about estimating either – it’s also about establishing your approach and identifying the skillsets needed. For example, your custom Sales Invoice program is likely to upgrade with little or no rework, but your custom Payables BACS program will need to be completely redeveloped using BI Publisher.

R12 is not as different from R11 as you’d think, but it is different. The “devil is in the detail” and in this case the “detail” is the differences between R11 and R12.

5. Test

If ever there was a time to believe the old adage about “never being able to test enough” then this is it. Test, test, then test again.

Be comprehensive with your testing. If you use the Transaction Import interface then create invoices both for existing customers upgraded from R11, and with new customers created in R12. Test your redeveloped BACS program by paying invoices created in R11 and R12. I’m sure you get the idea.

Also be realistic with your testing. If you typically import 100,000 invoices at the month-end, then don’t test with 10,000 and assume that 100,000 will take 10 times longer.

Finally, be pragmatic enough to accept that no matter how much testing you do, there will always be something you miss. It’s called “sod’s law”.


Upgrading your customisations to R12 will be a challenge, but hopefully the tips above should help provide some direction. Be prepared to work hard, and get external assistance if required. Plenty of others have been there before you, so don’t be hesitate to take advantage of this experience.

Finally, we have just recently added a new case study to our website on Oracle R12 Upgrades – you can read this here.  We hope you find it interesting.

How to manage Named Users (Part 2)

By Paul Bullen, Technical License Consultant at Rocela

In the last post, we started to explain the Named User-type licenses by defining the term. And we also started to look at how understanding it’s measurement can make all the difference to taking full advantage of this Oracle licensing metric.

In this post, we move on to consider some of the complexities of this licensing metric in more detail. We look into questions such as; how do you measure Named Users, and what is the best way to track Named Users?

Hopefully, you’ll remember from the last post that Named User licenses apply to individuals or devices interacting with the Oracle software on your servers. So you should be able to measure them easily from your databases, right?

Well, despite appearing easy and intuitive, measuring Named Users generically based on databases is actually a dead-end. We’ll look at why in a second.

Database users

Oracle databases have a users table (dba_users). You may think that you can simply find out the number of users recorded in this table and use it as your Named User count for that database. Unfortunately, as with many things Oracle, it’s not that simple. These database user accounts do not map 1:1 with Named Users, and there is no flag to classify users.

In order to prove this, we’ve just logged on to a small test database. In this database I’m the only Named User, however it has 21 database user accounts. The example below demonstrates what a list of database users could look like in this instance:

  • app_user: used by an application server, which actually allows 250 Named Users to connect as one user identifier (this is a ‘multi-plexing front-end’ in Oracle’s terminology)
  • app_object_owner: an account which stores application objects, and could be used by anyone in the application support team or the database administration team
  • system: an account which is used for database administration, so there could be a number of people using this single account
  • paul_bullen: maybe this is an account that maps to a single Named User account. However, if this user was to give his password to someone else, two Named User licenses would be required
  • paulbullen02: this may be the same Named User as ‘paul_bullen’ but there may be an additional user

This example should point out that you cannot reliably or generically measure Named Users from a database. You may be lucky and have an application, which holds Named User-type information (SAP is a good example), but you still need to consider the non-application user accounts in the database.

If you really want to get your measurement and reporting on this licensing metric up to scratch, it’s time to start looking at users in more detail on an application basis. To do this you have to realise that counting Named Users is a matter of knowing your application architecture and the individual users of the application thoroughly.

Your knowledge of application architecture and the individual users of applications is what Oracle is gambling against with its licensing metrics. And this is exactly how you can win, by making a few strategic decisions up front. You should ask yourself; am I going to be able to accurately count and track Named Users? You need to be clear on the answer, as Oracle requires you to purchase the (typically) more expensive processor license if you cannot count your Named Users properly.


A simple example of how it should be done:

The diagram above shows the way you should approach simple Named User calculations: count the users of the system (including devices which access the database) and any people who have access to the database. All of them have to be counted regardless of the architecture of the infrastructure.

In this instance, the diagram indicates that you will need licenses for 68 Named Users (ignoring minimums). It is critical that the number of people using the system in each department is tracked. So, you have to be very clear on how you’ll monitor things such as employees leaving or joining the company. You will also have to take into account things such giving an additional department access to the application: each ‘user-related’ decision will have an effect on the total number of Named Users licenses.

This is just a simple example, and you have to remember with more systems, more users, more servers and user minimums to consider it can be very complicated to keep track of Named Users. But doing so is vital in order to understand your compliance position, not to mention save costs.

In Part 3:
Next week we’ll look at Named User minimums, some potential pitfalls and what ‘multi-server’ Named User licenses mean.

For now, if this post has struck a chord with you, do add your thoughts in the comments.

Oracle ULAs

When discussing an Oracle Unlimited License Agreement (ULA) with customers, there’s one issue that’s never a surprise – confusion around the pros and cons of this Oracle licensing model. Many customers don’t understand the potential benefits and return on investment that such an agreement can hold.

The initial lure of the ULA concept is having the perceived freedom to deploy Oracle products at will over the term period. And even more so the set amount to be paid upfront which includes a fixed agreement on support and maintenance over the term period of the ULA and beyond. All things considered, it certainly sounds like an easy fix to a complicated problem, but it’s not always a win-win situation for every organisation.

The initial evaluation stage of an ULA agreement is key to making the right decision, so ask yourself – Do you know the growth ambitions of your organisation?  Are you going to grow organically or acquisitively?

An Oracle ULA is ideal if you plan to increase your usage.  It is not if you don’t grow as fast as planned.  Additionally, mergers and acquisitions, divestment and changing the structure of your organisation can bring about more complications when you’re tied to a ULA.

Knowledge is key in the negotiation game with Oracle.

In terms of ULAs, knowledge is your bargaining tool.  Providing you have a very clear view of your expected growth pattern over the next few years, you should be able to negotiate effectively with Oracle.  It is not uncommon for large enterprise organisations to get independent advice and guidance on negotiation strategies that can enhance contract terms, commercial arrangements and products within the agreement, to name a few. Your entry point into the ULA is of critical importance to realising your business case ROI at the end of the term – effective negotiation is essential to achieving that.

You’ve signed on the bottom line and are now enjoying the benefits of your ULA.

Avoid the temptation to deploy your Oracle products at will by creating an effective Software Asset Management methodology to measure your deployment and usage.  This must be clearly communicated throughout the entire organisation to prevent widespread misuse of Oracle.  If you let the kids into the sweetie shop for 3 years, it’s not easy to back track.

Understanding your license position at any given point in time during the ULA term will also provide greater insight into whether you are making the best possible use of the agreement.  Under deploying will not deliver value for money whereas deployment much larger than expected can be viewed as an unfavourable outcome by Oracle.

End of term

The step where many organisations falter is at the end of the term when your organisation is required to declare to Oracle on the amount of products deployed.  Suffice to say, if you have been managing your estate over the term of the contract effectively and are in a position of knowledge, then you will be able to make the right choices at this very important stage.  If you are unprepared and unsure of your deployment therefore cannot verify whether your ULA has met your ROI and profitability target, how will you be able to make an informed decision that’s best for your business?

Ensuring the successful achievement of your initial ULA business case objectives means that you need to know your organisations’ future business growth strategy. It also means that your organisation will have to adopt an appropriate methodology to audit and track all Oracle deployments and monitor usage over the term of the agreement. All these elements combined will lead to a positive outcome and the realisation of your ROI.

When it comes to Oracle ULAs, knowledge is power and something that Rocela brings to every customer’s table.

%d bloggers like this: