Today, I had spend 4 hours troubleshooting OTM (Oracle Transport Management) only to realise that the mistake was due to a change of Service Provider ID. This change was not updated in the Rate Offering. As such, the shipment planning was not able to pick up the rates. It was a very silly mistake and also shows the challenge of debugging in OTM. Anyone doing OTM will know the power of OTM debugging. Here are some debugging tips which could help anyone still doing OTM!
OTM Debugging Tips
Test often with each change of configuration. Use Agile to configure and test each change within a day.
Prepare a standard checklist for checking. This is important for Shipment Planning and rates setup.
Turn on your diagnostic log. It is more friendly than the log file.
Ask your OTM buddy for second opinion in your debugging approach. You may find new perspective.
Turn on your log files as last resort. The log file can either help you or discourage you. Go to the last page for the clues.
If you still unable to find the issue, rollback the change and configure your change again. This time, configure and test more aggressively. The key to debugging OTM is patience and practice. The only way is to get your hands dirty.
If you want to know the details, you can go through the code.
Recently, I got a surprising comment from an AMS (Application Managed Support) vendor above. This really confirm my view that AMS will be obsolete in the emergence of DevOps. Luckily, our team have been less reliance on AMS and transitioning to DevOps model over the past few years. Therefore, there is totally no issue for our team to read the codes. However, such mindset is the reason why AMS will be replaced in the next few years.
There is little value add for organisations to support AMS with focus on clearing tickets and reduce SLA.
AMS objectives are outdated due to paradigm shift to Cloud and Agile.
There is no knowledge increase in AMS resources to achieve better Customer Experience (CX).
The values of AMS contradicts that of newer paradigms.
AMS is gradually being replaced by either DevOps or Self Service Technologies (SST).
New experiential indicators are gaining popularity to measure user satisfaction.
It is more cost effective and efficient to replace than to retrain existing AMS.
These reasons serve as constant reminders that new paradigm will always replace in favor of old. It helps to push us to seek long term skillset in preparation of this shift. Thus, we should not be contended in our comfort zone.
Many years ago, I was astonished that development team and support team were separated in large organisations. Coming from smaller organisation, I often need to handle support after development and relate the pain points of support. In some cases, I add the support requirements to my development efforts to factor the changes encountered during support. Time have shown that DevOps are better in many aspects compared to traditional AMS (Application Managed Support).
It is the support team issue!
Project duration is often short and development team usually code against known requirements and test cases.
For future risk and issues, development team tends to transition this to support team.
Support issues that require change is considered enhancement.
Data or user education are support team issues.
Enhancement is developmentscope
Support team are measured by support ticket and SLA (Service Level Agreement).
Known issues are easily fixed and can meet meet SLA.
RCA (Root Cause Analysis) are only done upon requested and there is no incentive to resolve root cause for support team.
Resolution of root cause falls under enhancement and belongs to development scope.
There is now a demand for DevOps as many organisations switch to Agile. The disconnect between development and support can now be resolved. However, this will comes at a steep cost as DevOps is more than development and support.
A recent project reminded me of the real world scenario where masterdata is never clean. We are being told that the textbox is a free text and city can be a street, district or even province. Of course, this creates a challenging downstream impact for your data analytics.
Masterdata POV (Point of View)
Decide the POV of masterdata. One system masterdata could be another system transactional data and vice versa.
Use a reference point and communicate a common language of masterdata.
Knowing your end game will decide what masterdata to be collected with a relevant POV.
Tips to clean your masterdata
If more than 50% of your masterdata data needs cleansing, it is worthwhile to drop this masterdata,
Know what to clean and not to clean for the sake of cleaning.
A clean masterdata exhibits consistent patterns while an unclean one is a total chaos.
Know your domain well to clean effectively!
Cleaning masterdata is a iterative process. You get better and resilient with practice. A good data sense is also advantageous. Good luck cleaning and may the force be with you!
I find an interesting item while decluttering. This item reminds me of digital transformation and migration. So what have these two subjects have in common?
DigitalTransformation of LegacySystem
Digital Transformation comes at a much steeper cost if you have legacy system. The key consideration is what you should and able to transform. Although there are many consultants who can advise on the subject of digital transformation, very few can tell you what you can transform in relative to your existing legacy systems. This creates a dilemma of whether to starting afresh or maintaining your legacy systems. Inevitably, you will need to consider migration approach instead.
Migration of legacy system
The decision on migration of legacy system is typical of big organisations. However, this comes a huge risk which are common to all migration project i.e cost and duration. Do start with a simple checklist before you make this decision. They may increase the success rate and decrease the migration costs.
Do you own all the source codes or the capabilities of your legacy system?
Can the pilot migration be completed within 3 months?
It is a simple checklist but difficult to achieve. Experience shows that duration is proportional to cost and greater success is achieved with quick deployment. In-house SME or Agile DevOps will ensure you can handle any migration constraints between legacy and your transformed system.
Unknowingly, I have spend more than 5 years with TMS (Transportation Management System) using OTM (Oracle Transportation Management) system. Overall, I enjoy the ease of configuration to deploy Agile solution using technique of DevOps. The control of global TMS solution also create high degree of adaptability for the team.
How to Agile your TMS
TMS have short transit window. It is favorable to adopt Agile.
Do design for change rather than design on sign-off requirements.
Configuration solution with custom plugins can cater for all TMS scenarios.
Determine your Agile components.
When to DevOps
DevOps complement Agile approach. This suits TMS because TMS contains many exceptions in the real world.
Use DevOps to close your loop in Agile implementation.
Consider to include monitoring tools or reports and analyse your data to determine your solution effectiveness.
TMS is usually 20% localisation. You may choose to DevOps on these localisation.
In summary, TMS needs a good product platform. You will also need to train your your TMS team to be Agile and DevOps ready.
OTM (Oracle Transportation Management) Object locks have been my nemesis lately. You can see my past battles with refactoring and code quality. In migration or upgrades, direct copy of old packages from old to new domain often do not work as expected. Of course, you will only realise it when you hit object locks.
Signs of Object Locks
If you see very long PLSQL packages, it will mean the codes will take a while to travel from end to end. Any delay will lock object or tables giving the user a non responsive feel in the UI.
Many UPDATE SQL are seen in the agent or PLSQL.
Locks in Agent are used in Modified agent.
Copying of data from different objects like Shipment to OR (Order Release).
Removal of PLSQL packages in Agent and DSU (Direct SQL Update) to bare minimal, especially Modified Agents.
Reduction of codes in PLSQL. Delete or comment out old codes.
Reduce your UPDATE to a single point.
Add exception handling in your PLSQL to allow graceful exit of your PLSQL.
Conduct unit testing to each Agent or procedures before enabling them. If in doubt, remove them.
It is a painful process and huge amount of mandays are spend. Of course, lots of practice and hair tearing are done before you realise these tips. Hopefully, they are of help to those doing migration or upgrades of OTM.
It is month end closing! The first day of the month is usually the financial closing month as well. From a system view, there is always a heavy server load from last minute orders or batch job running monthly. This usually cause a whole lot of recurrent issues. I will do a quick comparison on how AMS (Application Managed Support) and DevOps view this standard issue.
AMS (Application Managed Support)
AMS will wait for issues to occur and await instructions to react and rectify the issue.
More support tickets will mean more job done.
The issue are addressed at face value. There will not be RCA (Root Cause Analysis) unless requested.
AMS resolve symptoms to ensure low severity and faster SLA
AMS are measured by SLA from support ticket. It is usually worthwhile to repeat same ticket type as response time will be fast due to known issues.
Problems and risks are mitigated with business and system development knowledge.
Zero support tickets is the key objective to system stability.
DevOps conduct RCA for all issues and proposed enhancements or BPR (Business Process Re-engineering) resolve the root cause.
DevOps adopt short term and long term fix to prevent further recurring issues.
DevOps can be measured by low support tickets and positive Customer Experience (CX).
From the comparison, you can see the obvious benefits of transforming your AMS to DevOps. However, there is a reality that DevOps are much costly than AMS. So, which approach should you be going for?
Many organization is in need of sustainability approach and strategy. A quick dirty way to start off is always the Carbon Footprint Report. So, what exactly is a Carbon Footprint Report and how can it be dirty and quick? This is 3 simple steps to start your sustainability movement using Carbon Footprint Report.
Step 1: Communicate Report Objective
In my real life experience, building a Carbon Footprint report is actually the easiest part. Most forgot to communicate the report objective to all the stakeholders. Often, the Carbon Footprint purpose is lost in translation. So, it is not surprising that its creation is a one time event and not being utilised.
Step 2: Monitor your Checkpoints
Another positive outcome you can derive from Carbon Footprint Report is the setup of checkpoints. There are many instance where the report is generated and processed as raw data. This is unproductive as you need sustainability checkpoint. The checkpoints ensure your sustainability efforts are monitored and guided in the correct direction.
Step 3: Broadcast your Win
The last part is the most important part. With one small step using Carbon Footprint Report, you can broadcast your sustainability achievements with continuing checkpoints. This reinforce your benefits of your sustainability program and creates more awareness. You may also develop a domino effect to other applications in setting this report as a key success part of all Sustainability program.