OTM Planning Tips

~ Danny Kwok ~ 1 Comment

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.

Be Systematic

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.

ODA Questions and Answers 101

~ Danny Kwok ~ 1 Comment

In my continuation of ODA (Oracle Digital Assistant) testing, I managed to try out the QnA (Questions and Answers) together with Answer Intent. They was 2 separate features but having similar objective. QnA is certainly a time consuming feature to test. In the end, I had tried out Answer Intent because of a cryptic error for QnA. While these features are similar, I have yet to uncover any noticeable pros and cons over each other. More time will be required to uncover the characteristics of these features.

Configuration Process

QnA Configuration is easy for English language and tricky for Chinese language. Luckily, QnA have included Chinese. You will need to save the csv in UTF if you want to upload QnA correctly. Multilingual setup is still challenging and I hope that this will be a default seamless process in future. Surprisingly, Answer Intent seems more straightforward and easier to configure. I will need to evaluate further if it is worthwhile to convert QnA to Answer Intent.

Thoughts so Far

It is really convenient to setup your knowledge in your Chatbot. A lot of efforts will be required to digitise these knowledge into QnA or Answer Intent. However, I still find these features to be too technical for business users. Moving forward, these features could be maintained separately by customer experience (CX) team who are less technically inclined. It is also difficult to configure multi languages as these needs to be separately and setup individually as a language rather than a product view.

QnA and Answer Intent should be a layman features. These should be built to be maintained by CX team and to be integrated by developers. We will expect to see these features separated in future.

A Tale of Two Cities

~ Danny Kwok ~ Leave a comment

Cloud and On premise reminds me of A Tale of Two Cities. One is being replaced gradually without the other having knowledge of it. It is not surprising some teams will remain in self denial of the proliferation of Cloud.

Similarities and Revolution

Cloud is nothing new and have been around for decades like hosted servers or managed services. The revolution comes about in the form of Digital Transformation from need for larger and larger server capacity in a particular entity and virtualisation. Suddenly, everyone jumps to the bandwagon as costs plummets with competition. However, not all teams are challenged to change.

How this Ends?

If you are familiar with the ending of the story, Darnay is knocked unconscious while being replaced by Carton for the guillotine. Does this sounds familiar if you are belonging to the teams who are not on Cloud? In many organisations, this replacement are taking place without involvement of on premise team. In most case, decisions are done at top management level and the teams are only engaged during migration. What a stark reminder to being at the guillotine!

A Tale of Two Cities are playing out at many organisations. However, it is a good suggestion that this should not be the plot. The ending is not pleasant for many. It is time we revisit the playbook and mirror another tale!

OTM Rates Model 101

~ Danny Kwok ~ Leave a comment

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:

  • Service Provider
  • 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!

A Shift to Cloud Upgrade

~ Danny Kwok ~ Leave a comment

Major upgrades and minor upgrades are a thing of the past. These methods are common for on premises applications where versions upgrades are costly and unstable. Usually, it is a three months efforts for minor version to a year for major upgrade. In your cloud application, it is common to see upgrade in another form. This is because you will be pushed to upgrade to a higher version.

Managing Cloud Upgrade

If you are not familiar to Cloud upgrade, you will be in for a surprise. Cloud upgrade is similar to your mobile OS upgrade. You will be notified of the newer version and its details. Then, you will be recommended “update” to the higher version. Similarly, your cloud application upgrade will be in the same process. The risk is that some of your application may break after the upgrade. Unfortunately, you cannot rollback to the other version.

Reducing Risk

The key part of Cloud applications is the ability to clone, export and import the configuration. Cloning allows you to upgrade for your testing environment and resolve pending issues before making the change in production. Another way is update your application to the latest version incrementally. This reduces the probability of big changes of the new version to your current one.

Be prepared for cloud upgrade similar to what you are facing in your mobile OS upgrade. You need to manage upgrades more often in order to reduce your risk exposure.

No Downtime Approach

~ Danny Kwok ~ Leave a comment

Application downtime is getting lesser and lesser with Cloud computing. Users are more demanding without the need of downtime. Thus, we need to move to the approach of hotfix and high availability environment.

Picture by Ethan
Shift to Zero Downtime

The design of zero downtime will require a digital transformation approach to your entire architecture. Another consideration is utilisation of the Cloud platform for different high availability approach. As this approach will incur additional cost like licences, you may want to evaluate a switch to pay as your use model instead of fixed licensing.

Development with No Downtime

Another key change is your development approach. This must be changed to reflect deployment with no downtime. Instead, hotfix and patches must be applied seamlessly without any downtime or impact to user operations. Therefore, your development will need Agile and DevOps to enable this approach.

If you have intention to move to a services with no downtime, it is time to reform your architecture and development approach. This involves utilisation of Cloud platform and Agile development to achieve this vision.

Why Translation Services for ODA

~ Danny Kwok ~ Leave a comment

In my previous post, I have been testing on different languages with ODA using native language. While testing non native languages with translation service, I had found out a major constraint with ODA. You cannot mix native and translation type in a single skills or digital assistant. This is a big concern if your Chatbot is to be deployed for multiple sites across different countries.

Constraint of Native and Translation in ODA

When you cannot mix native and translation, it means you will need to choose a single type. These are the constraints that force you to choose a type.

  • You cannot version skill from native to translation type.
  • You cannot clone skill with native language to translation type.
  • Digital Assistant cannot include skills with native and translation type.
  • A channel cannot only be used for a single external bot. This means 2 Bots needs to be created for native and translation type.
  • You cannot export skill to switch from native to translation type.
Translation Choice

If you are engaging users globally, do not waste time to test the native version. Instead, you must choose the translation choice by default. Do set the language to the most commonly used for your non native language. Be assured that translation choice can also identify native languages. The only drawback is that ODA will need to detect the language type. In addition, you will need to update resource bundles for different languages to be accurate.

Overall, the language selection is clearcut. You cannot set English and use translation service at the same time. Once you identify the need for non native languages, you must use translation option.

Multicloud Approach

~ Danny Kwok ~ 2 Comments

As we are moving our applications to Cloud, you realise that you are using a combination of different cloud providers. This is what we called a multicloud approach. It is now the most commonly used approach as applications are being migrated to its Cloud version.

Managing Multicloud

Multicloud strategy will be the norm for all cloud approach. The management of cloud must be taken as a single view instead of viewing as different cloud providers. Your key strategy to manage multicloud is on how to maintain each cloud like a single entity. Thus, you will need to draw up engagement rules and accountability matrix for your team. You may even consider having a primary cloud provider to manage other cloud providers. Depending on your needs, these management of multicloud must be summarised in a concerted manner.

Measuring Multicloud

There are a few ways you can consider to measure your Multicloud usage. One way is to start the management of cloud from a consumer centric view. This view utilise a user as the unit of measure. Cloud consumptions are managed at a user level. Another way is a product view where your product is leveraging on different cloud services. The product will be your unit of measure. Your selection will depends on how you intend to ROI (return on investment) from your cloud consumptions.

Multicloud approach will be the norm for all organisation. It will take time to understand and marry these cloud providers into your desired needs. Thus, you have start considering on how to manage and measure your multicloud providers in a single view.

Chatbot Native or Translated Languages

~ Danny Kwok ~ 1 Comment

Today I encounter an interesting concept with ODA (Oracle Digital Assistant) Chatbot with native or translation languages support. A key part of Chatbot is NLP (Natural Language Processing). This is viewed in two ways in the IT world either natively or translated form.

Why Native Language Support

By default, do use Chatbot native language support. You should only switch to translation services if you cannot find your desired languages. Native support provide trained NLP model. The chat is interpreted in its native language rather than the standard one. Thus, the type of native language must be decided when you are going to design your Chatbot.

Handling Translated Language

If the option of native language option is not available, you have no choice but to use translation services. However, translation services are highly unreliable. Instead, you must factor efforts to setup your language pack to translate some of your texts properly . Do consider to maintain and update these language pack for different types of language sub-type if you are going global e.g. zh-cn, zh-tw.

In summary, a major efforts for your Chatbot will involve languages localisation. Do check the type of language support for your Chatbot. Although translation services is convenient, it is still unreliable and efforts are needed to maintain accurate translated texts.

OTM Shipment Planning 101

~ Danny Kwok ~ Leave a comment

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.

Basic Optimisation

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 :

  • Rates
  • Itinerary
  • Equipment
  • Transport Modes
Advanced Optimisation

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 :

  • Distance
  • Transit Time
  • Package count
  • Routes Information

You can provide shipment planning in OTM into two key flavors

  • Basic optimisation
  • Advanced optimisation

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.