Area 1 – The Oracle Business Network
Historically, Oracle has taken a hands-off approach to trading partner connectivity. Either the shipper had to build their own integrations with carriers or rely on 3rd parties to build out the typical EDI and/or API integrations. This approach seemed to align with Oracle’s strategy of focusing on building generalized yet highly configurable software instead of developing content, which would include carrier-specific mapping for rate inquiries, booking, tracking, and invoice ingestion, among others.
In JBF-led TMS vendor selections where OTM was recommended, the lack of out-of-the-box carrier connectivity was viewed as a gap that needed to be addressed both during the implementation and in perpetuity as shippers and 3PLs added carriers, customers, geographies, and modes to their OTM instance.
The OTM team has pivoted from this hands-off approach and is now enabling trading partner connectivity through their Oracle Business Network. Competition from SAP’s Business Network, the promise of reduced customer TCO, and enhanced capabilities that expand on the legacy EDI transactions are likely the catalysts that led to the shift in tactics.
As no statistics were given in terms of OBN adoption, transaction counts, or the number of enterprises that are actively using the platform, the network is likely relatively small at the moment. However, Oracle has a large array of enterprise shippers that can require their transportation service providers and suppliers to begin using the OBN. For the transition to take place, OBN will need to be faster, better, and cheaper than the current point-to-point approach used by the majority of OTM customers.
JBF Perspective (3 out of 5)
While cautiously optimistic, JBF is taking a wait-and-see approach to the OBN. Given that this concept addresses one of the largest gaps we see in the overall OTM offering, we appreciate the concept, but we are also aware that building a network of shippers and carriers takes time. The value is highly correlated to the size and quality of the network; since we have not seen any information regarding either, we cannot judge the efficacy of the solution.
We are also eager to see how the OBN improves traditional carrier communications and collaboration, as a hub-based approach to transportation communications opens up the opportunity to provide new capabilities that current point-to-point API and/or EDI solutions lack.
Area 2 – UX Re-Design
Oracle is redesigning the look and feel, and as they put it, the “philosophy” of their entire cloud-based application set under a strategic Initiative called “Oracle Redwood.” Both Oracle Transportation Management and Global Trade Management have adopted some of these changes already and will continue to do so over the next year as part of their quarterly releases. The full transition to the Redwood UX is expected to be completed by the end of 2026.
The goal of the initiative is not simply to have a common user experience across the Oracle application suite but to rethink how enterprise applications can enable users to be more productive. The expectations are that the UX will include embedded machine learning, agentic AI, virtual assistants, and natural language processing. Additionally, Redwood supports contextual searches across applications, meaning that an OTM user can search for information in the Oracle Fusion Cloud ERP, the WMS, or the supply chain planning applications.
JBF Perspective (4 out of 5)
Enterprise applications have long been known for their unfriendly, clunky user interfaces. The TMS user interfaces are typically object-based (e.g. order screen, shipment screen, rates screen) versus workflow-based, seemingly built by engineers who never actually had to build a load or manage a rate tariff. These systems have historically required significant and costly training and, in many cases, drive end-user dissatisfaction and workarounds that compromise system and data integrity.
While we have yet to see the full capabilities of Redwood, we like what we are hearing. Over time, we have seen enterprise application usability stagnate, which becomes especially frustrating for users as they compare their unwieldy enterprise application with various consumer grade applications they use on a day-to-day basis, which are, simply put, much smarter and easier to use.
Cross-application contextual searching, natural language processing queries, and passive machine learning that adjusts system behavior based on a user’s past actions are things that we as consumers have come to expect, yet in the logistics technology space, systems are just now starting to address these needs.
The promise of Redwood is that it will enhance end-user productivity through a more intuitive framework that learns and adapts to user behavior, while strategically embedding various flavors of AI into the solution to both automate redundant processes and identify and recommend actionable insights.
A potential area of concern is that the transition to Redwood is not optional. OTM and GTM users will need to understand how to move to the new framework in a manner that takes advantage of the new capabilities without exposing the business to operational risk. At a minimum, this will require user training, but our expectation is that some processes may need to be redesigned to fully maximize the value of the enhanced UX.
Area 3 – Artificial Intelligence
As one would expect, AI had a front-and-center role at the conference. Dr. Srini Rajagopal, Oracle’s VP of Logistics Product Strategy, provided a keynote that primarily focused on how the Oracle suite of supply chain execution products (i.e. WMS, TMS, GTM) are using AI today and how he sees the use extending in the future.
Dr. Rajagopal discussed three types of AI—predictive, generative, and agentic—and provided examples of each in terms of how Oracle is using each type based on the specific problem.
The quintessential example of predictive AI in transport is using current events and historical data for predictive ETAs. Typically, they are used while a shipment is in-transit. However, Oracle can now predict ETAs during the planning process. Instead of relying on static transit tables or travel time heuristics, OTM can estimate transit time based on specific carrier, lane, and service level combinations. In theory, this could drive value in a few ways:
- Minimization of OTIF fines by selecting carriers that have a high probability of on-time performance when delivering to retail customers
- Downgrade the selected parcel service level when ground transport will enable delivery within the required delivery date
Another interesting use case presented was how AI agents can be used to decipher planning logs and provide feedback as to why the bulk plan optimization engine did what it did.
Historically, these logs have been nearly indecipherable to a lay user, but Oracle indicated that in the future, AI Agents will interrogate a log after optimization and provide the user with the rationale behind the engine’s heuristics. This would enable planners to correct issues quickly instead of letting them go unaddressed.
The creation of code used to drive OTM’s workflow agents is an additional area ripe for AI. Workflow agents have long been a core capability and differentiator of OTM, letting customers code specific actions, such as an alert or the execution of an API, based on if/then logic embedded into the agent. While powerful, these agents require a deep understanding of the underlying data structures of Oracle’s logistics applications.
Using natural language processing, workflow agents could be built without the need to employ OTM/GTM workflow agent experts. This should lead to better adoption and system automation.
While Oracle is building out OTM/GTM-specific agents that can be used as is or with some modification, the company is also providing a tool to enable Oracle Fusion Cloud customers to build their own agents. The Oracle AI Agent Studio supports building, testing, and training of AI agents in a no-code/low-code environment.
The AI agent studio comes with a native understanding of the Oracle business objects, which reduces development time and, in theory, puts the capabilities into the business, versus requiring AI expertise. The agents can be developed as one-offs or as part of an “Agent Team” that enables agents to work in concert with one another to solve more complex tasks.
The tool comes free with the Oracle Cloud Fusion application set.
JBF Perspective (5 out of 5)
In general, we continue to see significant advancements in the adoption and implementation of AI within TMS applications, and Oracle did not disappoint. We have long been fans of the event framework that Oracle developed. Putting AI agents on top of that framework promises to automate even more capabilities.
Embedding AI into the solution in a way that comes "out of the box" is another feature that JBF appreciates. This is facilitated by the Oracle Logistics R&D team’s efforts and will not only be driven by specific logistics needs, but also by Oracle’s broader Redwood initiative, which, as noted above, has embedded AI use cases such as contextual searches and digital assistants in the UX framework.
Finally, the Oracle AI Agent Studio provides the opportunity for OTM logistics customers to develop agents that are customized to their unique business requirements, seemingly without the need for heavy IT involvement. This will enable shippers to reduce the effort to develop, deploy, and maintain AI agents. The agents or agent teams can span multiple applications and automate repetitive and redundant processes, such as log reviews or even email interrogation and response. By leaving gaps in the automation that require human approval, this is all done with the necessary level of user oversight.
AI is evolving rapidly and holds the potential to add significant value to organizations that are able to adapt to the fast-changing technology. Oracle is providing both an embedded, out-of-the-box AI solution, along with a toolkit, to enable this transformation.
While we would have liked to see more hands-on demonstrations, especially on how to build agents, we did like what we heard. Given the size and scale of the effort and talent needed to truly re-invent a complex solution such as OTM with an “AI-First” mindset, Oracle may be one of the few enterprise providers out there that can make this transition.
Area 4 – Integrated Supply Chain Planning and Execution
There is ongoing interest among our shipper clients regarding the interplay between supply chain planning and execution systems. The use cases primarily center on long-term planning and forecasting and how they impact freight operations. During the keynote, Oracle teased, albeit without providing much in the way of detail, that their Supply Chain Planning and logistics applications can work in concert to provide mid to long-term transportation forecasts.
For instance, the output of the S&OP, demand or supply modules, could be converted into a transportation forecast. This would enable the logistics team to see demand surges or lulls in advance and make the proper adjustments to the freight network.
An example would be a scheduled trade promotion that is expected to increase the volumes on specific lanes. If not identified in advance, the promotion could lead to a capacity shortage on the lanes in question and, therefore, generate higher-than-expected transport rates. These disconnects between planning and execution systems continue to generate needless inefficiencies due to the historic and real application silos between planning and execution.
JBF Perspective (3 out of 5)
We like the concept, but JBF would like to see more examples of how this works in practice. Historically, the outputs of supply chain planning applications are converted into order signals (e.g. Replenishment, Stock Transfers, Purchase Orders) and passed to the TMS for execution. But that provides little time for the transport organization to effectively prepare for surges or lulls in volume if the required freight capacity does not align with the contracted volumes.
This is especially critical for organizations that are reliant on TL transport. The ability to contrast medium and long-range network volumes identified during supply chain planning with currently available capacity earlier in the process will enable the transport organization to have contingency plans in place to minimize the impact of large lane volume deviations. Aside from ensuring lane capacity exists, providing short-term lane forecasts to carriers is a practice appreciated by carriers, as it helps them better manage their businesses.
As noted, the briefing was light on details of how this works, and while we like the concept, we do want to see more details. We also want to understand the capability of Oracle’s Logistics Network Modeling application to absorb this data from other planning systems, as many shippers will not have Oracle’s full supply chain planning suite but will instead rely on best-of-breed solutions.
Area 5 – Cross-Shipper Insights
Oracle, specifically the OTM application, is used by clients around the globe. These shippers and 3PLs have freight networks that span virtually all industry verticals, use all modes of transport, and support freight spends of a few million to multibillions of dollars annually.
Each OTM customer has access to one of, if not, the best TMS/GTM solutions in the market. Oracle continues to invest in tactical enhancements to the logistics solutions and is also able to leverage the Oracle “Mothership” to develop tools and capabilities that many smaller logistics technology organizations do not have the budget or expertise to deliver.
However, an opportunity we would like to see Oracle pursue, which they have thus far been hesitant to do, is the ability to generate cross-shipper insights through the consolidation, aggregation, and anonymization of the vast amount of freight data held across all OTM clients. Shippers are hungry for logistics information that is held not just within their own data eco-system, but from sources outside of their organization.
JBF Perspective (2 out of 5)
While we understand that there are privacy concerns and some shippers may not want to participate in a cross-shipper data consortium, we feel this is a missed opportunity. The transport information that is currently siloed within each shipper’s instance of OTM, if presented carefully in an anonymous, consensual way, would generate insights and customer value that would be hard, if not impossible, for virtually any other TMS provider to replicate.
The sheer amount of data available to Oracle, assuming a high degree of adoption, makes the use cases nearly endless and invaluable to a shipper. Imagine a logistics-specific LLM made up of OTM shipper data, as well as select freight information from other sources. Users who sign up for the service would be able to ask questions in natural language, such as:
- Who are the top 5 flatbed carriers on the Dallas to Chicago Lane?
- For a live load, what is the typical dwell time for the Widget Company DC in Albany, NY?
- Who is the best freight forwarder that can assist me in moving from the East Coast to Rotterdam?
- What shippers have dry van freight on the Atlanta to Philadelphia Lane that I could potentially sell my fleet capacity to?
- What are the pros and cons of importing into Long Beach vs. Houston?
One could see these insights tied to an AI agent that would then be able to populate a modeling solution, initiate an RFI, or send an email based on the findings. This could all be done with minimal human interaction and may represent the next truly significant evolution of freight logistics, namely, cross-shipper collaboration that seeks to reduce empty space and empty miles.
