As I toured the warehouse, I couldn’t help but notice the pile of boxes next to two narrow work areas with computers. There was a short, gravity-fed, roller conveyor that was full of parcels. Other boxes on the floor surrounded the area at the end of the conveyor. The computers in the middle of this sea of beige were the factory’s shipping stations. The log-jam of parcels was waiting to be processed by their shipping personnel.
Anticipating my question, the manager let me know that the back-end host application was down, and that’s why the packages were starting to pile up; the shipping software could not retrieve the data it required. If there was any consolation, it was that the next wave had not been released to the warehouse yet, and so the picking and packing was about to stop too.
The factory prints custom logos on a variety of merchandise and is shipping about a thousand parcels a day. Some of the items were for special events and were time-sensitive deliveries. Talk about your shipping nightmares!
On another trip, to a different company/warehouse, I was once told about a farmer who dug up a company’s T1 line and shut the shipping operation down. This customer was an Internet retailer, and it was the start of the holiday season. The main distribution center was OK, but none of the satellite DCs had access to the network.
On yet another trip, to a totally different company, the operations manager told me that 20% of their requirements were not met by their current shipping solution. A whole section of the warehouse was set aside for “exception” processing. In an exasperated sigh, he said that these “exceptions” were the biggest anticipated area of growth over the coming year. This area too was a log-jam of parcels waiting to be processed. Indeed, it was the reason they were looking for a new solution.
Shipping Software 25 Years Ago
As shipping software matures, and we can say that it’s been around for about 25 years, these anecdotal issues that have caused “shipping nightmares” can strongly influence a consumer’s requirements when they look at updating their shipping software. One incident becomes institutionalized in the mantra of the purchasing requirements.
At the highest level, the two requirements that resonate with them the most are: Reduce my manual processes, and ensure I have minimal (if any) downtime.
Today, the requirements have shifted from simply being able to integrate to an application, produce a label and write back the tracking number and charges. That is expected. Today, customers have experienced downtime, are shouldering their manual processes and many — through journals such as this one — understand there can be a huge ROI in working intelligently through a design process to maximize every transportation dollar spent and being able to adapt to the myriad situations that present themselves.
Let’s start with the last example and discuss specifics. The customer indicated that the 20% that are exceptions is the fastest growing opportunity for his company. This is often the case; new customers or new geographies can often require new carriers or services. New carriers or services can often offer some degree of cost savings or improved customer satisfaction. New commodities, especially some of the high-tech devices in the market today, can require special paperwork and licenses for export.
In a recent survey of over 450 respondents (80% of which had over $50 million a year in revenue) only 25, or five percent, stated that they have fully automated, hands free, shipping solutions. Only 95, or 21%, had a “scan & ship” type solution. Incredibly, over 60% needed to manually enter data to complete their shipments. Moreover, 59% of the respondents said it took 10 minutes or more to prepare their export documentation for each international shipment.
Why? Their shipping systems couldn’t easily adapt and/or support the new customers, new commodities, new geographies, new compliance mandates, etc...
The manual processes, or the software’s in ability to easily adapt, drive the exception process.
The statistics shown for export documentation is just one example of an excessive amount of time for shipment processing resulting in an exception process. Other examples include not being able to enter in a new commodity’s hazardous data into the solution (e.g. ID number or subsidiary risk) or not being able to quickly add a new carrier/service or billing option required by a new customer’s routing guide.
A robust shipping system today needs to keep pace with the compliance; offer databases that augment ‘content less’ systems (such as an ERP system) to store mandatory data elements; and provide business analysts, or the like, with the ability to manage their own set of rules for routing against a broad mix of carriers and services. The fact that your shipping software supports AES filing doesn’t do you much good if you’re constantly typing in the same mandatory data elements, for example, or you’re constantly missing opportunities because there’s a four-week lead time to get your software partner engaged to make simple changes to the system.
As this article began I narrated two different scenarios when the factories couldn’t ship product. How do you prevent that type of downtime? All of the best practices I’ve seen start with a solid architecture that provides for high availability. At a minimum, the software architecture should provide for separating the application server from the database. This facilitates implementing active and passive application servers handled by an application controller, which can be complimented with separate, active node databases with one of the active nodes on a separate network. Set up properly, this provides extremely high availability for any mission critical shipping operation.
With a high available architecture in place, there are also other ways to mitigate down time:
1) Purchase software that maintains the compliance locally (some inexpensive shipping solutions rely totally on a carrier’s web API for each transaction), thus eliminating any dependency on internet connectivity on a per shipment basis.
2) Produce shipping labels at pick release
3) Print more than one wave at a time (large/fast batch processing at pick release)
Sometimes actually printing the label at pick release doesn’t work with the logistics of the warehouse operation, so a virtual print can be implemented, ensuring all of the templates are available at the start of a shift. The physical printing is actually just a simple copy of a file to the printer port.
While nothing is fool-proof, a properly thought out architecture and business approach can greatly reduce the shipping nightmares. The key is to pick a software solution that:
• Provides a broad carrier and service mix (to eliminate manual processes for unsupported requirements)
• Provides the ability to store data elements to extend ERP capabilities and system automation (to eliminate manual steps for completing required data elements)
• Gives the ability to pre-label (at pick-release to limit any dependency on a constant connection to the ERP system for each shipment transaction)
• Supports a multi-tiered architecture (to facilitate a high availability solution)
And finally, the solution should be agile enough to turn exceptions into the opportunities they deserve to be.
Peter Starvaski is the director of product management at Kewill Inc. With over 10 years in the parcel shipping industry, Peter is a recognized industry expert in parcel shipping. Peter has an undergraduate degree in Electrical Engineering from Nichols College.
Anticipating my question, the manager let me know that the back-end host application was down, and that’s why the packages were starting to pile up; the shipping software could not retrieve the data it required. If there was any consolation, it was that the next wave had not been released to the warehouse yet, and so the picking and packing was about to stop too.
The factory prints custom logos on a variety of merchandise and is shipping about a thousand parcels a day. Some of the items were for special events and were time-sensitive deliveries. Talk about your shipping nightmares!
On another trip, to a different company/warehouse, I was once told about a farmer who dug up a company’s T1 line and shut the shipping operation down. This customer was an Internet retailer, and it was the start of the holiday season. The main distribution center was OK, but none of the satellite DCs had access to the network.
On yet another trip, to a totally different company, the operations manager told me that 20% of their requirements were not met by their current shipping solution. A whole section of the warehouse was set aside for “exception” processing. In an exasperated sigh, he said that these “exceptions” were the biggest anticipated area of growth over the coming year. This area too was a log-jam of parcels waiting to be processed. Indeed, it was the reason they were looking for a new solution.
Shipping Software 25 Years Ago
As shipping software matures, and we can say that it’s been around for about 25 years, these anecdotal issues that have caused “shipping nightmares” can strongly influence a consumer’s requirements when they look at updating their shipping software. One incident becomes institutionalized in the mantra of the purchasing requirements.
At the highest level, the two requirements that resonate with them the most are: Reduce my manual processes, and ensure I have minimal (if any) downtime.
Today, the requirements have shifted from simply being able to integrate to an application, produce a label and write back the tracking number and charges. That is expected. Today, customers have experienced downtime, are shouldering their manual processes and many — through journals such as this one — understand there can be a huge ROI in working intelligently through a design process to maximize every transportation dollar spent and being able to adapt to the myriad situations that present themselves.
Let’s start with the last example and discuss specifics. The customer indicated that the 20% that are exceptions is the fastest growing opportunity for his company. This is often the case; new customers or new geographies can often require new carriers or services. New carriers or services can often offer some degree of cost savings or improved customer satisfaction. New commodities, especially some of the high-tech devices in the market today, can require special paperwork and licenses for export.
In a recent survey of over 450 respondents (80% of which had over $50 million a year in revenue) only 25, or five percent, stated that they have fully automated, hands free, shipping solutions. Only 95, or 21%, had a “scan & ship” type solution. Incredibly, over 60% needed to manually enter data to complete their shipments. Moreover, 59% of the respondents said it took 10 minutes or more to prepare their export documentation for each international shipment.
Why? Their shipping systems couldn’t easily adapt and/or support the new customers, new commodities, new geographies, new compliance mandates, etc...
The manual processes, or the software’s in ability to easily adapt, drive the exception process.
The statistics shown for export documentation is just one example of an excessive amount of time for shipment processing resulting in an exception process. Other examples include not being able to enter in a new commodity’s hazardous data into the solution (e.g. ID number or subsidiary risk) or not being able to quickly add a new carrier/service or billing option required by a new customer’s routing guide.
A robust shipping system today needs to keep pace with the compliance; offer databases that augment ‘content less’ systems (such as an ERP system) to store mandatory data elements; and provide business analysts, or the like, with the ability to manage their own set of rules for routing against a broad mix of carriers and services. The fact that your shipping software supports AES filing doesn’t do you much good if you’re constantly typing in the same mandatory data elements, for example, or you’re constantly missing opportunities because there’s a four-week lead time to get your software partner engaged to make simple changes to the system.
As this article began I narrated two different scenarios when the factories couldn’t ship product. How do you prevent that type of downtime? All of the best practices I’ve seen start with a solid architecture that provides for high availability. At a minimum, the software architecture should provide for separating the application server from the database. This facilitates implementing active and passive application servers handled by an application controller, which can be complimented with separate, active node databases with one of the active nodes on a separate network. Set up properly, this provides extremely high availability for any mission critical shipping operation.
With a high available architecture in place, there are also other ways to mitigate down time:
1) Purchase software that maintains the compliance locally (some inexpensive shipping solutions rely totally on a carrier’s web API for each transaction), thus eliminating any dependency on internet connectivity on a per shipment basis.
2) Produce shipping labels at pick release
3) Print more than one wave at a time (large/fast batch processing at pick release)
Sometimes actually printing the label at pick release doesn’t work with the logistics of the warehouse operation, so a virtual print can be implemented, ensuring all of the templates are available at the start of a shift. The physical printing is actually just a simple copy of a file to the printer port.
While nothing is fool-proof, a properly thought out architecture and business approach can greatly reduce the shipping nightmares. The key is to pick a software solution that:
• Provides a broad carrier and service mix (to eliminate manual processes for unsupported requirements)
• Provides the ability to store data elements to extend ERP capabilities and system automation (to eliminate manual steps for completing required data elements)
• Gives the ability to pre-label (at pick-release to limit any dependency on a constant connection to the ERP system for each shipment transaction)
• Supports a multi-tiered architecture (to facilitate a high availability solution)
And finally, the solution should be agile enough to turn exceptions into the opportunities they deserve to be.
Peter Starvaski is the director of product management at Kewill Inc. With over 10 years in the parcel shipping industry, Peter is a recognized industry expert in parcel shipping. Peter has an undergraduate degree in Electrical Engineering from Nichols College.
