If you’ve ever purchased a transportation management system (TMS) for your organization – or any enterprise software – you know that the term “software as a service” (SaaS) gets thrown around a lot. The problem is, it means different things to different people, and some vendors twist the meaning of the term to make it fit what they’re trying to sell you.
When you’re in the market for a TMS, it’s important to look beyond terms like SaaS or cloud in order to really understand your hosting options, how the data model will enable better business efficiencies and service, and the ease of integrations. With this knowledge, you’ll better understand how the TMS features fit your needs and how easily you can integrate and extend the application as your business evolves.
TMS Hosting: Public versus Private
If a TMS is multi-tenant, it allows multiple parties to exist in the same environment, but secure from each other. In a truly multi-tenant cloud SaaS offering, multiple customers in the same environment often share much of the third-party licensing costs and hardware expenses. This allows the vendor to offer the best price. The vendor maintains the application, database, integration and reporting servers, and is responsible for load balancing the servers and for performance (pretty much everything related to hosting). This is a true multi-tenant SaaS offering. The downside is that the customer (the tenant) doesn’t have access to the database because it would open up data across all customers. Additionally, the tenant is required to follow the upgrade schedule of the vendor.
In a privately-hosted environment, one TMS customer gets its own instance of the database. The TMS vendor is still responsible for the hosting, but the setup costs more because the customer has dedicated hardware and can’t share in third-party licensing. But the advantage of a private structure like this is that the customer can get direct access to the database for advanced database needs, such as their own report writer or data warehouse projects.
Private host clients also get to set their own upgrade timeline. Timing of upgrades may not sound important, but sometimes clients want to hold off on an upgrade if they are in peak season or don’t currently have the resources to test/implement new features. When on a multi-tenant system, you must follow the timing of the group. As an aside, the hosting costs for hardware are continuingly coming down, making private hosting a realistic option for an increasing number of companies.
Whether publicly or privately hosted, both offerings should use the same TMS with the same security models. Some vendors let customers start in public and change to private at a later time if needed. When considering TMS systems, know whether you have the flexibility to change hosting options – especially if you anticipate your business growing.
Data Models Influence Flexibility
However you are hosted, understanding the TMS data model is key because it helps you understand how easily you’ll be able to make the system fit your needs and how difficult product extensions may be.
A modern TMS has a well thought-out hierarchical and hybrid security scheme that will allow data sharing. Think of it like a parent, child, grandchild, great-grandchild, etc. structure: The number of layers is unlimited but every child and parent has its own security level, and each level automatically gets rights for all “children” under it and “parents” above it. Two different children from the same parent see data at the parent level, but are restricted from seeing data from each other.
Let’s translate that into a 3PL. A 3PL may have a parent level of Managed Transportation Unit 1 (“MT1” for short) and under this parent it has “CustomerA” and “CustomerB.” The 3PL at the MT1 level would set up data that applies to all customers, such as blanket less-than-truckload (LTL) rates, geographic information, carrier contacts and such. Order and shipment execution will occur at the customer or “child” level. This makes new customer onboarding significantly faster because you only need to set up customer-specific items.
When CustomerA or CustomerB uses the system, they only see shipments for themselves. But when the 3PL logs in to the MT1 level, they have access to all. In an old TMS system, the 3PL would need a work-around and write a report that shows both of the independent customers, then spend time to set up (and maintain) all data in both.
The parent/child hierarchy is also great for shippers with different divisions, especially if you need to keep them apart. A new TMS shipper customer would get a child level while the TMS project team would figure out the overall organizational setup and put in things shared across customers like geographic data, postal codes, etc. to help them on-board faster. The shipper can then create unlimited child levels under their own level.
Don’t Forget About Integration
Database security is a big factor in the ease and speed of integration. Let’s say a truckload (TL) carrier is hauling movements for 20 customers on a TMS. An old-school security data model would mean 20 different integrations points – one for each customer instance. A modern security model would provide one point and then know that a carrier has rights into all 20 different customers. Another example is a customer web service API for quotes. When the customer’s system hits the web service, you want them to only access data from their setup (the same as if they logged into the portal).
Having a good security model makes for easier systems integrations; it’s an important part of understanding the capabilities of your TMS and should be a key focus in your vendor selection.
Dig Deep When It Comes to Data, Security and Integration
Don’t settle for buzzwords and don’t assume that you and your vendor have the same definition of a term. Ask about the scenarios I’ve outlined here to get a strong understanding of how your TMS will perform when the rubber meets the road.
JP Wiggins is Co-Founder & Vice President of Logistics at 3Gtms, where he manages channels and partnerships for the company. He was most recently at SAP where he was the solution principal focusing on SAP’s transportation, warehouse and event management offerings in North America and previously directed industry marketing for the company’s transportation and logistics business unit. Before SAP, he was senior vice president and general manager for Descartes Systems Group’s supply chain, transportation and logistics applications business, and also had been vice president of product management for the company. Previously, JP was co-founder and senior vice president of logistics for Global Logistics Technologies (G-Log); co-founder and vice president of product management at dx/dt; and vice president of logistics at Weseley Software. He holds degrees in transportation & logistics and marketing from The Ohio State University.
Dig Deep: What to Know About TMS Hosting, Data Models and Integration
If you’ve ever purchased a transportation management system (TMS) for your organization – or any enterprise software – you know that the term “software as a service” (SaaS) gets thrown around a lot. The problem is, it means different things to different people, and some vendors twist the meaning of the term to make it fit what they’re trying to sell you.
When you’re in the market for a TMS, it’s important to look beyond terms like SaaS or cloud in order to really understand your hosting options, how the data model will enable better business efficiencies and service, and the ease of integrations. With this knowledge, you’ll better understand how the TMS features fit your needs and how easily you can integrate and extend the application as your business evolves.
TMS Hosting: Public versus Private
If a TMS is multi-tenant, it allows multiple parties to exist in the same environment, but secure from each other. In a truly multi-tenant cloud SaaS offering, multiple customers in the same environment often share much of the third-party licensing costs and hardware expenses. This allows the vendor to offer the best price. The vendor maintains the application, database, integration and reporting servers, and is responsible for load balancing the servers and for performance (pretty much everything related to hosting). This is a true multi-tenant SaaS offering. The downside is that the customer (the tenant) doesn’t have access to the database because it would open up data across all customers. Additionally, the tenant is required to follow the upgrade schedule of the vendor.
In a privately-hosted environment, one TMS customer gets its own instance of the database. The TMS vendor is still responsible for the hosting, but the setup costs more because the customer has dedicated hardware and can’t share in third-party licensing. But the advantage of a private structure like this is that the customer can get direct access to the database for advanced database needs, such as their own report writer or data warehouse projects.
Private host clients also get to set their own upgrade timeline. Timing of upgrades may not sound important, but sometimes clients want to hold off on an upgrade if they are in peak season or don’t currently have the resources to test/implement new features. When on a multi-tenant system, you must follow the timing of the group. As an aside, the hosting costs for hardware are continuingly coming down, making private hosting a realistic option for an increasing number of companies.
Whether publicly or privately hosted, both offerings should use the same TMS with the same security models. Some vendors let customers start in public and change to private at a later time if needed. When considering TMS systems, know whether you have the flexibility to change hosting options – especially if you anticipate your business growing.
Data Models Influence Flexibility
However you are hosted, understanding the TMS data model is key because it helps you understand how easily you’ll be able to make the system fit your needs and how difficult product extensions may be.
A modern TMS has a well thought-out hierarchical and hybrid security scheme that will allow data sharing. Think of it like a parent, child, grandchild, great-grandchild, etc. structure: The number of layers is unlimited but every child and parent has its own security level, and each level automatically gets rights for all “children” under it and “parents” above it. Two different children from the same parent see data at the parent level, but are restricted from seeing data from each other.
Let’s translate that into a 3PL. A 3PL may have a parent level of Managed Transportation Unit 1 (“MT1” for short) and under this parent it has “CustomerA” and “CustomerB.” The 3PL at the MT1 level would set up data that applies to all customers, such as blanket less-than-truckload (LTL) rates, geographic information, carrier contacts and such. Order and shipment execution will occur at the customer or “child” level. This makes new customer onboarding significantly faster because you only need to set up customer-specific items.
When CustomerA or CustomerB uses the system, they only see shipments for themselves. But when the 3PL logs in to the MT1 level, they have access to all. In an old TMS system, the 3PL would need a work-around and write a report that shows both of the independent customers, then spend time to set up (and maintain) all data in both.
The parent/child hierarchy is also great for shippers with different divisions, especially if you need to keep them apart. A new TMS shipper customer would get a child level while the TMS project team would figure out the overall organizational setup and put in things shared across customers like geographic data, postal codes, etc. to help them on-board faster. The shipper can then create unlimited child levels under their own level.
Don’t Forget About Integration
Database security is a big factor in the ease and speed of integration. Let’s say a truckload (TL) carrier is hauling movements for 20 customers on a TMS. An old-school security data model would mean 20 different integrations points – one for each customer instance. A modern security model would provide one point and then know that a carrier has rights into all 20 different customers. Another example is a customer web service API for quotes. When the customer’s system hits the web service, you want them to only access data from their setup (the same as if they logged into the portal).
Having a good security model makes for easier systems integrations; it’s an important part of understanding the capabilities of your TMS and should be a key focus in your vendor selection.
Dig Deep When It Comes to Data, Security and Integration
Don’t settle for buzzwords and don’t assume that you and your vendor have the same definition of a term. Ask about the scenarios I’ve outlined here to get a strong understanding of how your TMS will perform when the rubber meets the road.
TAGS
Subscribe to Our YouTube Channel
TOPICS
Categories
Subscribe to Our Podcast
TRENDING POSTS
Sponsors