The major issue with upgrading and migration to Cloud is backward compatibility. This process is like an evolution where an entire species will be extinct unless you evolved. Take OTM upgrade as an example, the nonsensical troublemaker Glog XML is forever not backward compatibility. This creates a ripple effect to legacy systems who have to conform to this change. While we are lamenting this issue, what should be done?
Where to Change?
When the product do not support backward compatibility, this raise the issue on where you are willing to invest on change. Usually, there are two areas of change that could be done. The standard approach is to make the change on your end to conform to the upgraded Glog. What happens when the change impact is huge and take a long time? The other approach is to seek the vendor help to raising a product change request to support the backward compatibility?
You will be in a deadlock when both approaches have difficulty to meet the required change. Thankfully for Cloud, you can now easily create transitional application to connect and translates the changes for backward compatibility. This is a common interim solution to maintain the change impact to minimum. The transitional application will be transition in nature and allows migration or upgrade activities to proceed. It also helps you to conduct full change to the new Glog at a later stage.
In the bid to upgrade for cloud, many applications are not backward compatibility to older versions. This creates a dilemma on where to manage the change. You may want to consider building transitional application minimise the change impact of backward compatibility like OTM Glog.
OTM (Oracle Transportation Management) upgrading has its own challenges and risks. Thus, a major upgrade or major version increase will typically take more than six months or so. You should have standard risk mitigation action plans. The major risks from upgrades comes from both internal and external factors. These are some common ones that you can take note.
Know your Application
Upgrade errors usually comes from customisation that are done to the product. Such errors usually need product team to analyse the root cause and provide a resolution plan. You should always remove or isolate customisation prior to upgrades as part of your risk mitigation plan. Another risk comes from the potential changes to your customised modules. It is advisable to develop configurable settings instead of hardcoding them to your application.
Know your Architecture
OTM upgrading impact for on premise is a much difficult than managing on the Cloud. This is because your infrastructure is likely non configurable and needs to be manually changed one by one. The complexity setup of your OTM architecture should be prepared prior to upgrading to lower the risks. This makes you aware of the firewall or SSL certs to be deployed when you conduct the upgrading.
The common risks for OTM upgrading is customised features and architecture setup. Customisation impacts patches or upgrading scripts. This often leads to specific architecture requirements and firewall with your on premise applications. Although these risks are not new, they are time consuming and impact the upgrading duration. Thus, you should always be proactive to mitigate the risks.
OTM (Oracle Transportation Management) is a product for transportation management usage. However, its usage can varies for different organisations. Knowledge of OTM does not mean you can instantly create a solution based on your past experiences. It only helps you to understand OTM terminology. On the contrary, you may end up fixated with your own mental model of OTM and neglect the model in current organisations.
Adopt a Flexi Mindset
The tricky part of OTM is the ability to create many transportation model. It is easy to fall into the mind trap of a particular design with OTM model. Thus, you must acquire a flexi mindset. This will help you learn the different model being adopted within the same organisation. Your past experiences with OTM is to help you quickly spot the differences and approach being used in the OTM model.
OTMis Process Driven
OTM is a process driven tool. Many will relate OTM as a technology tool and go straight into then OTM configuration. This is a basic elementary mistake by all noob OTM. You must always find out the current process before jumping into OTM solution. Time have shown that OTM configuration is easiest when process flow is provided.
OTM allows fluid design of different transportation model. You need to have a flexible mindset to study. Do note that OTM is process driven. Thus, the OTM model should be driven by process and not technical features.
OTM (Oracle Transportation Management) upgrades are a challenge on its own. It is expected that majority of on premise OTM should move to Cloud by 202x. This push factor is spurred by the end of support of on premise enhancements. However, the switch to Cloud is met with resistance and lack of clarity on how Cloud can cater to customisation of OTM aka CEMLI. Finally, it seems that an extension is given with the release of OTM version 6.5.x. The question is what’s next? Should you continue with on premise?
Message from OTM 6.5.x
The release of OTM 6.5.x give a sign of relief for organisations who are still using on premise OTM. The push to Cloud remains and the vision to innovate OTM Cloud is still the key objective. It is likely the feature gap between 6.5.x and OTM Cloud widen to the extent that it is no longer advantageous to remain with on premise version.
Flipping the Switch to Cloud
Migration to Cloud will always be a painful process. It is a matter of time before you need to flip that switch to Cloud. There are many case studies on migration to Cloud for OTM with lesser customisation. However, it is unclear on how heavily customised OTM shall proceed with the switch. What are the type of approach available? How can we make the switch with minimum disruption to operations?
OTM upgrade remains a long marathon for on premise. Time has shown that OTM Cloud will be the de facto platform. It is estimated that on premise upgrade journey may end in 5 years time. Who knows? Maybe, there will be OTM 6.6.x.
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.