Modernizing Oracle e-Business Suite with APEX

Introduction

​I have been working with Oracle e-Business Suite (EBS) since version 9.4 (that’s character mode!). Although EBS has come a long way since then, even the newer releases are starting to look long in the tooth. In this post I will explore a number of use cases where Oracle APEX was used to bring the joy back to ERP without spending a whole lot of money.

---

​The Case for Modernizing EBS

​Although many companies are moving their ERP to the cloud, many cannot because cloud ERPs offerings do not yet provide all of the features, they need to run their business. This leaves companies running on-premise ERP systems like EBS version 12.1.3 in limbo. Do they try and upgrade to version 12.2 for an incremental improvement in UX or do they wait until key cloud features are available and then move to the cloud? If they wait, how do they explain to their users that the technical acrobatics required to run Java from a browser these days is worth the effort? The user base for such companies are in full revolt and they won’t stand for it any more. This is especially challenging for companies that have introduced edge application such as HR in Workday. Users now know what is possible and want more of it.

Oracle APEX

So, how can an IT department provide a significant improvement in UX to EBS users for zero additional software cost? Oracle APEX is a no cost option of the Oracle database. APEX provides you with all the tools you need to build beautiful, scalable apps in a single, extensible platform, which runs as a part of Oracle Database. In this case it will run in the same database as EBS, providing zero latency data access.
 
What you will need

• An application server (or VM) to run Tomcat and ORDS (e.g. 25GB Disk 4GB Memory, 1 CPU)
• Install the latest version of APEX on the EBS Oracle Database
• Install Tomcat and ORDS on the Tomcat/ORDS server

Note: There is no additional cost for any of the software mentioned above.
 
I am not advocating re-writing EBS in APEX, far from it. What I am advocating is taking a few key processes that have high visibility and high impact to your organization and using APEX to provide a modern easy to use interface.

Architecture Overview

1. Users can log into EBS and access APEX pages from an EBS menu, or they can log directly into the APEX App using their EBS credentials.
   
2. APEX lives in the database for zero latency access to custom tables, custom APIs, EBS Public APIs and EBS tables and views.

Beyond APEX

I have found that using APEX to extend EBS makes it easier to introduce other technologies that can also transform the way users interact with EBS. For example:

• Voice interfaces to EBS with Alexa.
• Utilizing SMS to communicate with your employees (and process responses).
• Introducing PaaS products like Exadata Express to extend EBS outside of your firewall.
• Leveraging AWS S3 for document storage.
  
• Provide custom mobile interfaces for users to interact with EBS.

​Use Case 1 – High Impact

​In all likelihood, your organization has an annual review and performance management process. If you do then it is also likely that most people in your organization participate, making it a highly visible process. Oracle EBS has a performance management module that is fully functional and integrates well with Oracle Human Resources. The User Experience, however, is not something you can be proud of. In addition, you are probably spending a significant amount of time managing issues related to this poor UX.
 
Last year JMJ developed an APEX application to replace the employee facing side of EBS performance management. This application acted as a skin on the underlying Oracle performance management module, utilizing standard Oracle APIs to create and update records in the EBS data model.

1. Employees logged in directly to the APEX App, using their EBS credentials. The App had a URL that was easy to remember and was not associated with EBS. The UX for the app was completely unlike EBS, in fact it more closely resembled a consumer application.
2. On the back end, the HR department used the standard EBS functionality for tasks such as moving appraisals to compensation workbench.

 
The overall impact was dramatic. People actually liked using the application, not only did this make employees feel good but it increased participation in the process.

​Use Case 2 – Simplifying a Critical Business Process

My second example involves taking a critical business process and building a custom application to manage that process in a way that would not be possible with standard functionality. To some, this may sound like heresy. In fact, for the 18 years I worked for Oracle Consulting extending EBS and ERP Cloud, my mantra was always don’t customize unless you have to. The key here is the word ‘have to’. If you can save a million dollars a year (or make an additional million dollars a year) by building a product that costs 250 thousand dollars a year to maintain and upgrade, then you have to do it.
 
JMJ Cloud recently built an APEX application that managed the receipt and processing of material at over 40 manufacturing plants. In doing this, we built a whole new UI for plant staff to greatly simplify their interactions with EBS. Behind the scenes, however, were able to use significant pieces of EBS functionality to avoid having to re-invent the wheel.

1. Plant users’ gain access via either a native iOS mobile application or an APEX App. These users perform plant operations such as receiving material, creating sales orders, logging production etc.
2. Back office and corporate staff log directly into EBS to perform back office processing. e.g. pricing and booking orders, creating invoices etc.

 
Simplified overview of the business process:

• Material delivered by customer for processing:
  • User logs into APEX and created a new job.
  • The APEX UI for creating the job pulls customer information directly from EBS. When a job is created, an EBS Sales Order header is also created.
  • During the receiving process order lines are added to the EBS Sales Order via an APEX page. The receiver enters just 3 fields per order line in the APEX application making data entry simpler and faster.
• As material is processed production data is posted via the APEX App, to the associated sales order lines in EBS.
• Once the sales order is priced and booked, invoicing and collections is handled from standard EBS.

 
The APEX application in conjunction with a native iOS app that speaks to EBS using Oracle REST Data Services (ORDS), means the majority of users at the plant do not have to be concerned with EBS at all. In an environment with a high turnover of staff who have limited technical skills, having an easy to use and simplified UI is critical.

​Use Case 3 – Point Solutions

As I mentioned earlier, Oracle EBS is one of the most feature rich ERP platforms out there. This complexity can be both a blessing and a curse. A single Oracle module can take months of effort to implement and you may end up using less than 25% of the full functionality of that module. The problem is you are paying for 100% of the functionality. If you could build the pieces of the module that you really need and then integrate that with other aspects of EBS you could end up saving money and providing a more modern user experience at the same time.
 
One example of this is a Capital Expenses Tracking system which JMJ Cloud recently built for an EBS customer. This was a relatively simple 8-page (4 table) application that allows users to enter details of a Capital Expenditure request and then submit the request for approval. Having the new App build on the EBS database, allows us to leverage EBS for much of the heavy lifting.
For example:

• Authenticate users using Oracle EBS credentials
• Use EBS view, value sets and lookups as the source for List of Values to reduce dual maintenance and increase consistency. (e.g. List of GL account segments, List of GL periods)
• Utilize Oracle Workflow to handle notifications and approvals of submissions
• Provide list of Capital Project budgets (from Oracle Projects in EBS) to associate a CAPEX request with

Conclusion

​Oracle EBS is one of the most (if not the most) feature rich ERP application on the market. Often times, these features have come at the expense of UX and in 2018, the UI is showing its age more than ever. By using APEX to replace the UX of key processes in EBS, you can bring the joy back to ERP for your users. Applications that bring users joy are known to have higher adoption rates and bring more smiles. Using APEX to modernize your existing EBS implementation can buy the time you need for Cloud offerings to match the functionality that you need to run your business. 

Author

Jon Dixon, Co-Founder JMJ Cloud