Oracle Application User Metric – Best Practices for Remaining Compliant

One of the most common, yet easily avoidable compliance issues stems from a customer’s misunderstanding of how license requirements are assessed for the Application User metric by Oracle.

Below are some quick wins for gaining some clarity on how Oracle measures its licensing requirements as well as some license management best practices so you do not become inadvertently non-compliant.

Oracle has largely standardized on the Application User metric across many of its application programs, be they the home-grown E-Business Suite or technologies added to the portfolio through an acquisition. While Application User is not the only way to license Oracle applications, it is the most common user based metric. To their credit, as they have acquired companies like Hyperion, Agile, JD Edwards, etc. that historically had a variety of confusing user based license metrics, Oracle has simplified things by allowing customers to migrate legacy metrics to Application User.

In many cases, this removes the burden of a customer having to keep track of which users are provisioned, for example, as a “Power User” versus which users only provisioned as a “Read-only,” and so on. An Application User is simply any user given access to the licensed application, regardless of whether they are acting as an administrator, or are only performing a single task.

A basic principle of good license management is understanding how metrics are defined contractually, and Application User is no exception. In fact, as mentioned earlier, misunderstanding the metric can lead to large compliance gaps that could cost customers a lot of money with little or no added value.

An Application User is an individual that is authorized to use the licensed program, regardless of whether they are actually using the program at any given time. In other words, licensing is determined by access, not by actual use; anyone given access to the program must be licensed. This distinction between access and actual use is crucial. One of the common pitfalls for customers is failing to properly end-date or otherwise de-provision users that no longer use the system. As long as an individual is provisioned, Oracle can and likely will deem them to be licensable during an audit, even if that user no longer works for the company in question.

Don’t get penalized for phantom users. Stay diligent about controlling user provisioning for Oracle applications licensed by Application User.

A quick recap of the key points:

• Even an ex-employee is still considered licensed as an Application User until you de-provision the user.
• Develop processes for end-dating user accounts as provisioned individuals leave the company or otherwise no longer require access.
• Remain aware of application users that log into the system under more than one user name or ID. Oracle is interested in the number of individuals with access, so if multiple user IDs map to one user, the customer will need to demonstrate to Oracle that only one user should be counted.
• Conversely, ensure that every person using a generic user ID is properly licensed.

One of the most important principles in maintaining a compliant approach to Oracle is understanding the crucial difference between access and practical use. When programs are licensed by the ubiquitous Application User metric, access to the program is what determines licensing. Customers can easily avoid compliance headaches and unexpected license fees by making sure only active users are provisioned for Oracle applications.