Modernize Order To Cash without replacing your ERP

Modernize Order To Cash without replacing your ERP

Simplify Your Order-to-Invoice Processes with Oracle APEX

·

8 min read

If you've been looking for confirmation whether it's possible to successfully modernize your order to cash and supply chain applications without having to customize, upgrade or replace your ERP, this post is for you. The solution below is the most sought-after demo by our customers. Why? Because it proves that a multi-billion dollar enterprise can run its end-to-end, high volume Order To Cash operations on a low-code platform, in sync with its legacy ERP.

💡
Although the solution described revolves around the Oracle ecosystem, Oracle ERP and Oracle APEX, the principles apply with any ERP (SAP, Microsoft Dynamics, Net Suite, etc.).

Here's what I'll cover:

  1. Why is Order To Cash so hard?

  2. My customer's problem statement

  3. Oracle APEX to the rescue

  4. Approach and design principles

  5. Tools and Integrations

  6. Results

Why is Order To Cash so hard?

Order To Cash, typically abbreviated as OTC or O2C, spans multiple functions including sales, credit, demand planning, inventory, warehousing, shipping, finance, collections and customer support. The numerous hand-offs, dependencies and exceptions situated across departments make automation and efficiencies difficult to achieve. And the more product lines, revenue models and fulfillment channels introduced, the more moving parts are put in motion, further compounding the problem of reaching cross-functional alignment and efficiencies.

Per a recent Boston Consulting Group article,

"Our analysis of O2C in a sample of manufacturing and service companies found that it comprised as many as 27 sub-processes across seven different functions. That’s why O2C often falls between the cracks or is regarded as being too complicated to re-engineer."

No two companies perform O2C in the same way, making it almost impossible for ERPs and other systems to provide standardized offerings.

"In the two decades I have spent leading O2C ERP transformation programs at companies, all have used ERPs to automate the backend financial processes. And, all of them relied on custom applications and manual processes when it came to order-to-cash.” - Nishant Nair, CEO of RecVue (Forbes article)

This variability across companies and industries presents an optimal opportunity for a low-code development platform such as Oracle Application Express (APEX) to meet a company's O2C needs. APEX offers the flexibility to build only the features you need today, with the malleability to enhance and adapt them for the future.

My Customer's Problem Statement

My client needed the ability to fast-track the order to cash operations for a company they had just acquired.

The acquired company objected to using an ERP to run its operations because it perceived ERP as too slow and complex and required too many windows and clicks. They believed an ERP could not compete in speed, performance, or efficiency with the QuickBooks solution they had configured to meet their exact needs.

So we were tasked with moving them away from QuickBooks to a solution that would not only meet the acquired company's expectations of speed and ease of use, but also seamlessly integrate with the existing ERP, ensuring a smooth and efficient transition.

The reluctance to move away from what they had in place today was so strong, I had to gamify the situation with a challenge. I proposed to the head of the acquired company that if the demo of our solution did not beat their current system in speed, performance and enhanced features, they didn't have to move. "Game on!", he proclaimed. The challenge was on!

Oracle APEX to the rescue

The initial aim was to deliver a solution entirely within Oracle ERP. However, if the solution proved unfeasible, our backup plan was to construct a custom web app with integrations to the parent company’s Oracle ERP.

They were right—ERP was slow and drawn out. Compared to their existing solution, it required many more forms, fields, pop-ups, and clicks to operate O2C end-to-end, and it took three times as long. ERP was a no-sell. A custom app was going to be the best route forward.

Good news—Oracle APEX is quick for standing up an application. Within a week, we had a working demo. Oracle APEX to the rescue!

Approach and Design Principles

An important design principle for custom enterprise apps is to design the custom app in lock-step with EBS the entire way. We referenced customers, suppliers, and items from the ERP and took advantage of standard ERP APIs to decrement inventory and generate invoices.

Table 1: Data Objects & Transactions Leveraged in the ERP

All these links minimized duplicity and ensured Oracle ERP remained the source of truth for master data and transactions.

Note - there is more to an ERP than just data and transactions. One of the primary reasons to have an ERP is to take advantage of its business rules and recommendation engines. These engines are powerful - they automate decision-making and enforce policies and procedures. We synced APEX with three key Oracle ERP robust engines:

Table 2: ERP Business Rule & Recommendation Engines

A table showing 3 ERP Business Rule and Recommendation Engines including a Credit Check Engine and ATP and Scheduling Engine.

Having said all the above, it does not always make sense to originate all objects from the ERP. Our design tenets guide us to prioritize the user experience, simplicity, and longevity of the APEX apps we build. Thus, we created and maintained sales orders, pricing rules, work orders, and shipments, fully confined within the low-code app.

Table 3: Entities and Transactions Unique to APEX

Designing in lock-step with ERP can also mean complementing the ERP in a modular approach. As the list above shows, we built these four "modules" to house the transactions completely outside the ERP. The flexibility of our APEX platform allows us to amend or replace these 'modules' as future requirements dictate.


As mentioned earlier, a second design principle is designing for longevity. It's essential to avoid hard-coding whenever possible. Instead, consider storing variables in ERP constructs like ERP profile options and lookups or opt for the creation of custom tables managed by APEX pages. This approach avoids the pitfalls of hard coding and allows business users to update the variables themselves instead of relying on a code update.


There are many other design principles for building enterprise apps, but I'll end with a third one: optimizing the user experience. To optimize the UI experience, we designed the most frequently used functions to be accessible from one place—an OTC workbench. It provided buttons for saving, booking, generating a work order, printing paperwork, shipping, and invoicing all on one page. No more having to go to multiple pages to perform or access a function.

Every potential click was evaluated and optimized. We utilized defaulting-rule logic wherever possible and placed the fields in the exact sequence they needed. we ensured users never had to lift their hand to move a mouse; every section and button could be activated with keyboard clicks, eliminating steps and clicks along the way.

One key win was automating seven procedures, all with the click of one button. We called it “Rocket Ship”. See table below for the seven procedures it automates for end users.

Table 4: Procedures the Rocket Ship automates for end users

Tools & Integrations Used

No enterprise app worth its weight stands alone. Here's a list of key integrations we built:

Table 5: Integrations with our low-code APEX application

Table showing integrations with Oracle APEX including APEX Office Print and AWS S3.

Integration between APEX and Oracle ERP is easy. If you're on an Oracle ERP EBS version, both APEX and ERP are in the same database, so it’s as simple as a SQL query or PL/SQL call to the specific table and column in the database - no API or Web Service configuration required. If you're on Oracle Fusion Cloud ERP, it's hosted by Oracle, so you'll need to stand up another Oracle database to host APEX. For examples of where to host, see Oracle APEX Service or the Autonomous Database Service on OCI.

Results

It took two of us (me and a developer) less than six months, start to finish, to gather requirements, prototype, design, build, iterate, iterate, and iterate and then launch to Production. This included full integration of the app's inventory and revenue transactions with Oracle Financials. The build was the easy part. The bulk of the time was spent educating my client on the features of ERP they could now take advantage of and redrawing their business process for optimal efficiency.

Automation and optimization of the user experience reduced order processing overhead by 80% compared to their legacy Quickbooks application.

And the 'Rocket Ship' button enabled no-touch order processing for 30% of orders. That's over seven clicks per order. if you extrapolate that over all its plants, that’s a savings of over 1/2 million clicks per year. Not to mention the context- switching each user saves - users only have to attend to an order once.

🎲
And the bet with the Head of the acquired company - Oracle APEX kicked butt!

APEX came out ahead of Quickbooks in terms of speed, scale, performance, accuracy and enhanced features to their legacy system.

Summary

OTC is universal. Every company that sells a product or service engages in O2C operations, and each company's O2C workflows are unique. The variables, hand-offs, and exceptions involved in O2C demand a tailored solution for most.

The flexibility, security, and performance provided by Oracle APEX and its pre-built integrations with Oracle ERPs allow you to make the most of your ERP investment.

This post could have easily been 10,000 words—there is so much I didn't get to cover when enhancing an ERP with an app that spans multiple departments and processes. Optimizing ERPs is my passion—reach out if you'd like more information regarding this use case or if you'd like to bounce ideas about how this could work in your environment.