When migrating to Oracle Fusion Cloud applications, it’s easy to become overwhelmed with the wide array of expanded options for your procurement setup. Below are the top 5 areas of change and how they can be carefully considered to provide the most impact your business. We’ve compared some of the functionality in particular with Oracle JD Edwards and described how the procurement process differs.

LET’S FIND THE BEST PATH FORWARD | GET STARTED WITH YOUR ASSESSMENT 

As a procurement officer, or an accounts payable manager, it is hard to imagine a world where you have procurement workflow approval processes beyond only purchasing documents.

When migrating to cloud, implementation teams should work with a mosaic of cross-functional representatives for a business process’s entire lifespan to identify opportunities to leverage these new approval opportunities.

Oracle Cloud has Supplier Profile version workflow approval that may enable a procurement team member to begin to adjust fields previously controlled by accounts payable, by having routed oversight of a workflow prior to enacting the data in the system.

This means less paperwork and communication hang-ups between disjointed sections of the business, which should translate in a more efficient business environment.

JD Edwards approvals are triggered by an approval route being assigned from one of four different locations:

• The user profile for the person entering the order
• The address book record for the person entering the order
• Branch/Plant constants or
• Default locations and printers

For any of these four approval routing assignment methods, the system will compare the total amount of the order to the amounts included in the approval workflow setup.

In Procurement Cloud, approvals can be based on an assortment of order information beyond the order amount. For example, it is possible to configure Rule Sets to examine the order amount along with the procurement agent and cost center to assign a workflow dedicated to that specific criteria. Instead of having to determine this assignment method based on the order type or in the P4310 processing options, cloud can dynamically analyze and react to pre-determined sets of variables.

Using standard JD Edwards for approvals means operating within the familiar P43081 application to construct the approval routes. As you may know, these routes typically involve identifying an Approval Route Name and document type followed by a list of User ID’s or address book numbers for who will be approving order types at specified thresholds. In Cloud, there are four different methods that may be used to construct these logical workflow routings (the terminology for these in Cloud is a Participant Type):

1. Single

A single, specific manager or approver overseeing the route.

2. Parallel

A parallel set of approvers that will determine whether the workflow is approved. This option can even be configured to approve requests by a vote of parallel approvers. This could be used in situations where there may be a business unit manager who must approve a request along with a corporate approver working in tandem. Remember, approvals in cloud are for more than just purchasing documents! How could a voting system of approval be leveraged in your business setting?

3. Serial

Serial approvals is the most similar to the option found in JD Edwards. In this Participant Type, you configure a string of entities together along with the criteria that defines when the order is escalated.

4. FYI

The topic of FYI workflow is a feature that many in JD Edwards have been looking for a while. These may be used for users who are inconsequential to the document’s approval but should be kept in the know during the workflow processing. This may also be users who are not in position to approve or reject a supplier’s profile changes, but may need to attach or evaluate components of the approved item. The prevalence of FYI Participant Types will certainly vary by business case, but the access to this feature out of box could be a massive advantage to any procurement organization.

Using Delegation/Escalation with Your Approval Methodology

Where JD Edwards configuration often required the usage of dummy or group email accounts to alert a range of users that a document was ready to be approved, Oracle Cloud has very clean escalation rule setup that will allow users to disregard a delegation setup (a step forgotten by many procurement managers on the night before vacation). Cloud instead uses pre-defined escalation rules to properly orient the order in the direction of the proper, available approver. This can save a great deal of time as users then are not required to use means beyond the system to track down a response. Instead, users may move on to more important tasks knowing their order will be routed to the correct user.

After examining the types of Participant Types that could be employed, it is important to also evaluate the advantages that Oracle Cloud’s approval routing employs for defining the final approval route. Where JD Edwards is largely confined to the Work with Approval Level Revisions form, Oracle Cloud takes advantage of the Setup and Maintenance work area to employ user-defined logic for the routing. Below are three examples of the types of complicated logic that can be used to determine an orders approval routing:

Organization charts

Utilize pre-configured Approval groups, job levels, positional hierarchies, or other user-defined routing. This flexibility of routing allows you to detach the specific order type/purpose from the procurement agent for means of approval. Remember, it is not required that you use any of these features, but the presence may challenge your business to determine required business processes.

Document Attributes

Cloud may additionally examine order data to determine the order’s routing. This may be fields such as procurement business unit, project or contract order. The ability to detach the procurement agent from an approval routing and route based on document data may enable many procurement departments attempting to centralize the flexibility needed to provide the correct order oversight.

Nested Conditions

Similar to an IF statement in Excel, nested conditions within cloud approval rules allows you to set up combinations of different criteria to make the approval workflow as complicated as needed to meet your organization’s oversight rules. For example, if you were to treat suppliers in one region differently from suppliers in another region, UNLESS they were considered an essential supplier, you could enable that routing using nested conditions to evaluate an order or supplier profile before generating the corresponding approval routing.

Perhaps one of the most powerful features of Oracle Cloud’s approval systems is the ability to respond in an extremely streamlined fashion, right out of the box. Sure, JD Edwards does have mobile applications to be able to handle some of this same functionality, but the ability to have all the features of cloud without any advanced configuration or enablement means Power Users can be enabled to enact these changes as soon as the system is live.

In-System

This method mirrors JD Edwards’ functionality when Notifications are enabled. As you operate within the system, if an approval is required for an order/transaction/supplier change, the notification icon within the system will change to signal an alert.

Email

One of the sleekest response methods is the auto-generated email notification that allows users to respond without logging back into the system. Many users who are in the field have found the ability to respond, using only a cellphone, and not logged into the system can save a tremendous amount of time. To be fair, this same response method is possible using JD Edwards, but of course it requires extra configuration of Orchestrator and is highly dependent on data changes not occurring. With cloud, you have all this functionality at your fingertips from the second the system is up and running.

So, now what? Learn more about Oracle Procurement Cloud. Start to analyze the difference between your procurement process that exists because of technical limitations, and the processes that exist because they are the backbone of your business. Look for examples of users complaining about “pointless” approvals or approvals that often require manual, out-of-system intervention. And start to map a path forward.