Recently, I’ve been asked from a number of places about Oracle’s Approvals Management Engine, or AME, so in the next few blog posts, I’ll be taking a look in more detail about what it is and what it can do for you and your organization.

AME is an “easy” way for a business analyst / functional consultant to define business rules for transaction approvals within eBusiness Suite. Not all applications modules support AME, however, in which case you are back to the age-old bespoke method of identifying approvers and including custom logic to ensure that the right people are included within the approvals process. Note that I have used inverted commas for the word “easy” – AME provides the opportunity to include business rules which can vary widely in complexity.

In this post, I’ll be looking at the components of AME which are required for configuration, and in later posts I’ll move onto some practical examples from within iRecruitment and Financials.

AME Basics

As I said earlier, the purpose of using AME is to implement specific business rules within the framework of the application to manage the approval of a transaction. This can always be done outside of AME (and for some modules, this is still a requirement!), but if the approvals process can be captured within AME then this makes for a more straightforward implementation which (theoretically at least) is easier to maintain over the long-term. When approval is sought, AME uses Workflow notifications to inform the approver that they need to action the request, and to capture their response.

AME (as I said earlier) allows you to implement rules of differing complexity – for example, any invoices which are over £500 must be approved by the requester’s supervisor; all vacancies created in iRecruitment must be approved by Bob in HR; and so forth. Many organizations, however, have much more complicated – for example, any invoice which is matched to a purchase order and has any lines which are over £5000 and include heavy machinery must be approved by the Operations Manager and his immediate supervisor (or the next available supervisor with the appropriate authorization limit). The flexibility that AME brings means that the same method can be adopted for any of these requirements.

So, why bother with AME?

As I said earlier, you can already build all of this through custom code – and in versions of the eBusiness Suite that were availably prior to AME, that is what most organizations did. However, there are some clear advantages of managing the approvals process using AME over using bespoke software.

Firstly, in many cases, business rules can be defined and implemented without the need for any code. Now that’s a big one, so I’ll say it again – IN MANY CASES, BUSINESS RULES CAN BE IMPLEMENTED WITHOUT THE NEED FOR ANY CODE. Less code means less things to maintain, and less things to go wrong (assuming that the functional configuration is correct and the code is always the thing to go wrong, but we’ll not go there in this post!!).

Secondly, if there are already hierarchical structures defined in the application, then AME can leverage these as standard – again, there is no need to write custom code to find the next available approver, since AME does it automatically.

Another advantage of using AME is that if there are specific requirements to route an approval to a specific group of people or an individual, then AME provides the person making the functional configuration with the ability to setup specific hierarchies or approval groups which can be used to determine where to route the approval.

The last main benefit (and it’s a good one!) is that AME has the ability to respond to any changes in the approvals process whilst the process is still going on. This includes, for example, a change in the approvals hierarchy (which can be included fairly easily within custom code) but also if the business rules themselves are modified during the process, or even if the values of the transaction themselves change during the process – now that’s clever! Every time an approver for a transaction responds with an approval, AME checks the rules as they stand at that point in time, and rebuilds the approver list to determine who the next approver should be. So, let’s take the simple example above where if the invoice is over £500 then the supervisor must approve the invoice. An invoice for £1500 is created, AME checks the business rules and notifies the supervisor. The business analyst then decides that if the invoice is over £1000, it requires three levels of approval, and so makes the change within AME. When the supervisor responds to the notification, AME rebuilds the approval list using the new rules, identifies who the next approver should be, and then routes the transaction to them for approval.

That’s the end of my very quick overview of what AME is and why you should use it – in the next post, I’ll go into the components of AME and how they work together.

This entry was posted on Thursday, February 4th, 2010 at 8:32 pm and is filed under Functional, Oracle. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.