Leveraging your Parcel TMS Data
Your Parcel TMS (PTMS) should be providing a plethora of valuable data as you assess performance, plan for the future, and resolve issues. While the data may be available, without access and a plan it is useless. Given the power trapped within this data, you should ask yourself, “Am I leveraging available data to its full potential?” If not, what should you do to harness the power of data?
There is no shortage of material suggesting the magnitude of data created in the digital economy or that this data harnesses super-powers. Most individuals understand that the world is exponentially storing more data than the year prior, and most companies have no shortage of data, data access tools, reports, databases, data engineers, and good intentions – but execution often falls short. While there are many avenues worth analysis, we will explore the types of data often trapped specifically in a PTMS, and some suggestions on how you may want to use it to plan, improve, and operate your fulfillment function.
What types of data should be in a PTMS?
While not every PTMS is created equal (and one may argue most do not deliver to their full potential), a PTMS should provide access to the following data via a single source. While an organization may opt to ingest this data into a broader organization data warehouse for enterprise-wide reporting, a PTMS should provide access to this data directly via reporting, dashboards, and analytical tools directly targeting the needs of the Parcel professional. Essentially, this data set will provide the line item detail for every individual parcel.
Parcel Data. These files store the original shipping information associated with your parcels as they left your dock. This represents a vast set of timestamps/UserID's as the order/carton was processed through your operations, and all data related to rating, labeling, shipping, and manifesting the parcel: customer/destination information, contents, dimension/weight, delivery date expectations, carrier/ship method selected (capturing the rate including assessorials) plus the tracking number.
Tracking information. In addition to capturing the tracking number upon generation, data is pulled from the carrier on a periodic basis to track the delivery through the entire process. All data with timestamps should be stored and normalized across carriers. Events like delays, exceptions, corrections, damage, and returns are also stored in this dataset.
Invoice Data. When available, the invoice should be parsed to the parcel level and associated to the applicable parcel. All fee line items should be stored for future analysis.
Figure 1. Sample of individual dataset for a parcel including rating, tracking and invoice data
Who would find this data useful and why?
Making the investment in a data storage system and the reporting/analytics tools to access the data is useless if the stakeholder is not taken into consideration or if the stakeholder doesn’t even know it exists. Therefore, it is important to thoroughly understand who would want this data and why they would want it.
Operations. Operators and their supervisors typically want to know their performance goals, have visibility into issues, and the resolution to these issues. Key metrics they would hope to gain access to would include processing speed along with volumes by time period, carrier and ship method, and destination. These operators often need to access to data that informs them of trailer closing or manifesting issues, and a method to quickly resolve these issues (potentially out of the reporting interface).
Management. In addition to visibility of performance by the operations team, management looks at historical/forecasted trends, on-time delivery, the root cause of delayed deliveries, cost management and avoidance, carrier incentive tracking, carrier service alert tracking and management, and upgrade/downgrade trends.
Accounting and Finance. Parcel TMS shipping and tracking data is often used by accounting and finance to calculate revenue and shipping cost accruals at month-end, allocation of shipping costs to business units or distribution centers, and potentially to audit carrier invoices (to supplement an outside auditor, or DIY if an outside auditor is not used).
Auditors. Auditing an invoice is very difficult without the original shipping or tracking information readily available. Many auditors will gather this information on a client’s behalf if this information is not available. The audit function will evaluate the accuracy of the invoice to identify erroneous charges, evaluate late deliveries to determine if refunds are due, find opportunities to reduce cost through operational performance (address correction, residential/commercial delivery, ship method selection, carrier selection DIM weight optimization, density improvement, etc.) or to support the carrier negotiation process.
Figure 2. PTMS data stakeholders
What kinds of insights should I hope to gain from this data?
The potential insights for the data are so great it can be difficult to know where to start. Following are a few examples of high-level exploration points.
Manual versus automated shipping processing – Do you see trends? What are the root causes of an increase in the percent of shipments processed manually, and what is the resolution?
Processing time – Is processing time creeping up resulting in delayed deliveries or expediting of shipments? What is the cost of this expediting in carrier costs and OTD reduction?
Expedited delivery percent – Are all of these expedited shipments necessary? What is the value that could be gained by reduction of expediting? What could be done to realize this value?
Damage – Is a particular DC, carrier, packer, or product more likely to get damaged or returned?
Carrier, ship method, and destination details – Is there a particular carrier, ship method, or destination that is an outlier for OTD performance? Is there a trend or spike in performance? Identification of these outliers and trends provides direction for deeper exploration. For example, are the time-in-transit tables reflecting reality or should they be adjusted?
Delivery Delay Root Cause – What was the stated cause of the delay reported by the carrier? Was it caused by your customer (missing apartment number), the shipper (misclassification of residential versus commercial), the carrier or nature (weather, fires, etc.)? What tools and processes could be put into place to reduce these delays?
DIM weight – How much are you paying to ship air? Where are the best opportunities to explore improvement and what is the ROI of the improvement opportunity?
Ship methods – Did you overpay for expedited delivery that was not necessary for the time-in-transit defined by the zone? Did you take advantage of zone skipping appropriately?
Processing time – How much did you pay because of processing time delays beyond your benchmark?
Ship point – Did you ship from the most optimal DC, Store, or drop ship vendor? How much would you have saved if you had selected another ship point? Was this ship point selected due to inventory availability or an algorithm deficiency?
Carriers – Does scenario analysis suggest that you could save money with alternative carriers or a carrier change? Are you using the correct ship methods with your current carriers?
Invoices – How accurate are they compared to your original shipping data? If not, is there a trend in the variance? What are the unexpected charges and can they be avoided?
Zone Skipping – Do trends show you should consider zone skipping? How much would you save? Do trends suggest that savings could be realized with improved density analysis and planning?
OTD – Are you improving and meeting your goals? Is the trend due to peak season, or it is an outlier?
Ship points – Do trends suggest it is time to expand your ship point options to additional DCs, 3PLs, Stores, or drop ship vendors?
Figure 3. PTMS data stakeholders
We discussed the types of data that should be in a PTMS, the stakeholders that need this data, and what these stakeholders should do with the data. This exploration above is just a start; there are certainly many more situations where PTMS data could be of service depending upon an organization’s unique situation. The key is to have a PTMS that is ready to serve. To be ready, the PTMS must be robust enough to capture and store all of this data, structure it in a way that is easily accessible, and provide the tools necessary to help you plan/manage/execute your organization.
We realize this piece is very high-level, and if you’d like to drill down on any of our recommendations, reach out to us with questions or comments. We also welcome opportunities to deliberate or dispute our insights and recommendations. No conversation is off limits.
You are an expert and we'd love to speak with you.