OTM (Oracle Transport Management) bulk plan is totally designed for 2PL. It is ideal when your orders can be assigned and planned nicely into your desired equipment. On the other hand, you may want to design differently for 3PL (3rd Party Logistics). These are some quick tips that you want to consider in your 3PL bulk plan design.
Masterdata is Not Complete
Bulk plan configuration is dependent on masterdata availability. For 3PL, masterdata is never complete because you are a third party. Your bulk plan will definitely run into error if you design based on a comprehensive set of masterdata. Thus, the rule of thumb for 3PL is to assume incomplete masterdata from your bulk plan design. The key method is to set default values for missing masterdata.
Speed vs Optimisation
As 3PL, you usually have contractual rates or preferred service providers. Thus, you can speed up bulk plan by auto assignment of your constraints values. On the other hand, there are not much optimisation required for your shipments. Due to missing masterdata, optimisation will also be inaccurate or even result in bulk plan performance issues.
You cannot configure OTM bulk plan using the standard approach for 3PL. You must always assign default values for your missing masterdata. It is also obvious that you cannot optimise your shipment planning fully for 3PL. Thus, you should go for bulk plan design for speed with constraints rather shipment optimisation.
Oracle VPD (Virtual Private Database) is a good feature for OTM (Oracle Transportation Management to control access. However, it is still technically challenging to maintain VPD directly for users. This is why we can configure VPD to parameterise for users. This way, users can maintain access control via the screen or masterdata setup. Contact group and attribute field VPD are the most common ways to extend OTM VPD for users.
Contact Group VPD
The most common configuration of VPD setup in order release or shipment is to set the involved party. Then, you will create the same name of involved party for your contact group. Users that required access to the data will be added to this contact group. This way, you can control access without amending the VPD.
Attribute Field VPD
Another common method is to VPD to the attribute fields. The field will be a variable control to determine what can be shown to the users. This attribute can be dynamic or a masterdata setup. The usage of attribute is to speed up the VPD as it reside on the data table itself. Another key reason is that you can allow super user to inline edit attribute field to allow access.
OTM VPD are useful for access control to data. However, updating VPD directly is highly technical and cannot be maintained by users. This is why you can configure contact group or use attribute fields to dynamic control your VPD. Users also have the options to amend this fields as well.
OTM FTL (Full Truckload) rates are one of the required configuration to setup for your shipment planning. You should always configure this rate model to be setup as a default rates. These are some tips that you will find useful for FTL rates setup.
A Default FTL Rate
The setup of FTL default rate will always help you in shipment planning and testing. There are times where you need to test shipments without the need of accurate rating. The basic FTL setup are usually by shipment or equipment. The key parameters to take note for equipment rate model are:
Below settings can be defaulted to dummy values. If not, you can populate these fields in your rates to fine tune your ratings:
It is best to keep your FTL to the simplest form because it will speed up your masterdata collection.
Dummy Rate Cost
OTM will pick the lowest cost for these shipment planning. Thus, you may set a dummy high value for these rare costs. Do take note that these default are suitable for initial testing and debugging of your agents. Once you are moving to production, do deactivate these rate cost. You may also wish to retain these dummy values to allow shipment planning to proceed for no rates scenarios.
FTL rates should always be the first rate model to setup when you configure OTM for the first time. This will help you in testing and configuration for fresh OTM setup.
OTM (Oracle Transportation Management) depends on a lot of masterdata and conditions. You can try this planning tips to optimise your bulk plan. One of the key masterdata is the location. How should you setup your location masterdata for bulk plan?
Location masterdata can be a double edge sword for your bulk plan. If the location is setup correctly, optimisation will be fast and efficient. If you have many ambiguous locations, your bulk plan will end up taking longer than usual. Thus, locations should not be created as you wish but it needs to be properly updated in zones coverage. A single ambiguous location is sufficient to block the progress of your bulk plan!
The completeness of location masterdata is a common issue. You will need to consider default value for all missing location fields. Utilise the 80/20 rule and judgment when you load location masterdata. If you have missing information for 80% of the location fields, you may consider to omit that field to improve your bulk plan. Common fields that will impact are:
Location masterdata is a critical for bulk plan. The accuracy of location plays an important part in shipment optimisation. If you are using many dummy locations, it is common to run into inefficient and ambiguity scenarios. It is always advisable to use realistic locations for your bulk plan.
OTM (Oracle Transportation Management) last version for on premise is 6.4.3 since 2017. Many are encouraged to move to OTM Cloud as Oracle had stated there will not new version. Fast forward to 2021, there is a new update to the on premise approach. To my surprise, Oracle announce that there will be further patches to extend the life of on premise from 6.4.3 to 6.5.x till 6.5.3.
The surprise turnaround from Oracle is good news because many customers are unable to move to Cloud on time. This is not surprising as Cloud platform was faced with risk and uncertainty 3 years ago. Many struggle to migrate without a clear picture of OTM Cloud as it becomes a huge black box of PaaS (Platform as a Service).
OTM Cloud remains Innovation Platform
Those with OTM on prem will still be faced with a decision to move to OTM Cloud. The message from Oracle is that OTM Cloud will remain their innovation platform. It seem that we are unlikely to see much changes for on prem version for 6.5.x except for patches and minor enhancements.
In summary, the extension to 6.5.x will give many customers more time to migrate on premise to OTM Cloud. This is a big relief because migration to OTM Cloud is not just a technical change but a digital transformation strategy.
If you are working on OTM (Oracle Transportation Management), one of the challenging points is shipment planning error. It can really frustrating when you are trying the make sense of the planning error with OTM log files. This is a summary of OTM planning tips which I find useful.
Experience will tell you that things get worst when we panic. If you are a beginner to shipment planning, it is advisable to be systematic and follow your checklist. These are some of tips which may helps.
Setup a baseline masterdata which works. This could be rates, itinerary, equipment or planning parameter.
Plan your testing data and test matrix properly. Majority of shipment planning error is due to order data.
Configure and test often. Sometimes, the error is due to a mixture of wrong data.
Make use of constraints to force the results you wanted. If this fails, remove all constraints to check if order can be planned. Then, you can add and test the required constraints one by one.
Focus your OTM log file to include planning and planning details. The error usually happen to be at the last page of the log file.
Always check status e.g. planning hold or inactive rates.
Take a break if you are stuck for a long time. You will find a new perspective if you are refresh.
Practice Makes Perfect
There is no shortcut to learning shipment planning in OTM. The only way is to practice. You should only ask someone to guide you if you are really stuck. This is because the steps to find out your own mistake is more memorable than getting it fixed quickly by others.
OTM shipment planning is a challenging but fun step. I realise the only way to learn is to practice and be exposed to different data. You must always be positive and systematic in finding the issue.
One of key features in OTM (Oracle Transportation Management) is its rates engine. You can setup OTM rates engine into different model. These are the key tips you can use to build your rating model.
TL and LTL Base
The 2 most common rate types are TL (Truck Load) and (Less than Truck Load). You need to have the majority of masterdata to complete these 2 rates model from end to end. The basic masterdata required are:
Equipment for TL
LTL rating by weight or volume
Testing and Building
With this 2 rate models, you can cover up to 70% of rates out there. The next steps are to setup the processes for these 2 rates model. These processes are grouped by:
Update of masterdata
Loading of rates
Testing of rates
Expiry and updates of rates
If you are new to OTM, do focus on these basic rate model and know the rate processes well yourself. This will helps your build your confidence before you add more rates model. The processes are the most difficult for users understand and self service in OTM. Follow these steps and you will be rewarded!
OTM (Oracle Transportation Management) Shipment Management module have a shipment planning feature which allows you to optimise your load. However, there is a catch that is not known to users. The optimisation is as good as your masterdata. These are some quick tips to have a basic optimisation in shipment planning.
For basic optimisation, you will need the following conditions to get it up and running.
Assume a constant settings
Obtain a base masterdata
Basic optimisation rule will require some constant settings. The common constant setting to use is time. You will need to assume your shipment planning without time constraint or configuration. With this assumption, you can focus on a base masterdata set. This set of masterdata will consist of :
The basic optimisation provides the minimum start point for all shipment planning. Advanced optimisation will restore the time duration as a factor for your optimisation. The additional masterdata will include :
You can provide shipment planning in OTM into two key flavors
The options will determine the amount of masterdata required. Subsequently, this translates to your project scope, time and efforts. If you are new to OTM shipment planning, do go for basic optimisation configuration. This will help you familiarise with the base masterdata. Only then, you can tackle the advanced one.
Dates format are a nightmare for application if you are handling a global system. Most application provide a certain level of configuration for user preference. OTM (Oracle Transportation Management) is one such application that allows you to configure date format for users. However, this can be quite painful because the date format can vary in each module. These are the OTM portions where you should take note.
OTM Date Configuration
You can configure date format with user preference. The user preference can also be superseded by the preference in contact module. Some of the OTM fields are in date type. There is also attribute date fields as placeholder. Report parameters date format can be overwritten by date format in report library.
Dates to Take Note
You will find many painful points when you are using character field for dates. This can be in the form of refnum or integration xml. Many of the reports required dates filter. You may want to consider the usage of date field for these filter instead of character data type. You will find a lot of conversion format between to_char and to_date in your report query.
Whether you are upgrading or migrating, the impact on date format is very huge. OTM is one such application with flexibility on date format usage. This caused a challenging task for technical team who will be maintaining a global system. Should you standardise your date format instead?
OTM (Oracle Transportation Management) can be a big dilemma if we are moving to cloud or upgrading. It is a configurable system that allows customisation from small degree of change to major one. A major part would be your decision to upgrade or migrate to cloud from the amount of configuration or customisation done to OTM.
Many organisations would prefer to migrate to cloud for future support and upgrades. separate the customisation Cloud, like its name, really is cloud. You cannot foresee what will happen in Cloud until you are in Cloud. Your risk appetite will need to be high if you have done a lot of customisation on OTM. Prior your move to Cloud, a major task is to separate the customisation into REST services. How much time and effort will you invest? Should you forgo your customisation instead?
Upgrading OTM major version can be quite a slow painful experience. The 6.4.3 is the last available version that is non Cloud based. The decision not to move to Cloud usually lies with the amount of customisation done. The biggest changes from old version to 6.4.3 version are architectural, user interface (UI) and report server. The dilemma comes in the sequence of upgrade you want to take. Report server is now mandatory after the removal of embedded reports. Should you move your embedded report first or do together with upgrade? How much training period should you allow for the new UI? How much time will it take to fix your customisation during the upgrade?
OTM upgrade or migration to cloud is a painful dilemma. There is always a temptation to status quo the version due to the massive efforts to factor risk and change management. In many cases, you need lots of patience and alternate plans while you are upgrading or migrating.