www.cmsglobalsoft.com

______________________________________________________________________________________________________________Third Party Applications, Middleware and ERP Systems: March 2008

The State of Shipping Systems TodayPage 1 of 5

Third Party Applications, Middleware and ERP Systems:

March 2008

The State of Shipping Systems Today

By Wil Fekeci, President of CMS GlobalSoft

The Model

Often I hear from potential clients the same reoccurring theme: they have had it with theirthird party shipping applications.

Ultimately thereason for poorsupport can bepinpointed to therelationship thatexists betweenthe shippingapplication, usersand the carrierrequirements.

"They don't do what they say they would do." "They can't keep up the carrier changes.""The support is terrible."These are words that I hear from CIOs or IT Managers of large volume shippers who relyon third party applications to ship small parcels. Whenever we follow a poorly executedthird party application, my job is made harder because the client has been burned so oftenthey naturally become very gun shy. Specifically a new client will want contractualassurances that what we promise will be delivered. Happily, our client retention is 100%.But why is that? What are we doing differently that the third party applications are notdoing? The answer is really simple if you look at the overall model.Why is support so awful? It seems to me that too much emphasis is centered on sales andmarketing in the IT world, and not enough on after sales support, where you build andkeep a customer base. It is too hard to get a client in the first place than risk losing themby not paying attention to their ongoing needs. Ultimately the reason for poor support canbe pinpointed to the relationship that exits between the shipping application, users and thecarrier requirements. Why third party applications can not keep up or aren't sophisticatedenough to support users is fundamentally an easy problem to address: simply put, themodel is wrong.

Three Layers

In any shipping application, there are 3 important layers: the GUI or presentation layer,the business layer, where the individual shipper rules reside, and the carrier layer, wherethe rules are dictated by the individual’s carriers' requirements. All third party applicationdevelopers have to support all three layers. The first two, the GUI and business layer, area challenge but completely within the control of a seasoned developer. The languages of choice, supported databases, schema, functionality, infrastructure, etc., fall within thedeveloper's scope. Regretfully, it is the third layer where the rules come somewhatambiguous. It is the third layer, or carrier requirements, that pose the greatest problemand, unfortunately, this is where inconsistencies come into play.

Historical Relations

A third party developer will begin by seeking the exact rules for shipping from each of thecarriers. Unfortunately, there is no standardization among the different carriers. Any thirdparty application, in the eyes of the carrier, is ultimately going to give too much power tothe shipper: they can rate shop for best rates, use delivery by features thereby sometimesselecting ground as a service versus the more costly overnight service, consolidate end of day billing, measure performance for late packages, easily switch between carriers and

www.cmsglobalsoft.com

______________________________________________________________________________________________________________Third Party Applications, Middleware and ERP Systems: March 2008

The State of Shipping Systems TodayPage 2 of 5

services, pitting carriers against each other to compete for business and lower rates, etc.Of course, carriers detest this power. Carriers realize that providing multi-carrierapplications are a necessary evil and to facilitate this request they do create specificationdocuments for their requirements. It is these sets of documents, each produced by eachcarrier, that the developers begin understanding the rules and services of the carriers. It isa complex set of rules.For instance, there are different services and each service has a different set "specialservices", different label formats and data algorithms, countries of destinationrequirements, published rates, discounted rates, consolidated rates, special services rates,call tags, hazardous requirements, end of day manifesting, posting, and so on. Mostcarriers want to control and dominate the market by being a single source to any shipper.Basic shipping 101 states that you do not want to be reliant on any one supplier all of thetime. Therefore, it makes strategic sense to empower a multi-carrier system.Historically, because of how the carriers view multi-carrier systems and the position itallows shippers to be in, a strained relationship exists between the carriers and third partydevelopers. Nonetheless, a developer will want to not only understand what a carrier'srequirements are today but what they will be in the future. However, in designing ashipping application, even the best developers do not have insight into what the carriersare (were) thinking with their specifications or where their requirements and/or futurereleases might be heading. The carriers, in a competitive market, do not want to divulgesuch trade secrets, such as new services or even rates, less they lose their competitiveedge. They don't want the competition to know what they are planning for. If you don'tknow what to plan for, how can a third party developer build any application that mightsupport future services?

Finger Pointing

Poor support can also be traced to the model that exists between carrier and third partydevelopers. For instance, if a shipper of a third party application is having trouble runninga specific carrier transaction, which happens all too frequently, is the carrier willing tohelp troubleshoot the problem? No. A classic example is how one carrier considers PuertoRico a Domestic service, while the other considers it an International service. If a shipperdoes not select the correct service type per carrier, the shipment will fail. When a carrieris queried for support, their response is usually it must be something in the third partydeveloper's own code, in how they built and compiled the transaction, not in therequirements for that transaction. Fingers get pointed very quickly.

Too Many Cooks

Also, there are too many cooks in the kitchen. The carriers define the rules, the third partydevelopers interpret the rules, and the code is then compiled and passed to an integratorwho installs it at a shipping location. In the meantime, the carrier's salesperson isknocking on the front door trying to sell additional services that the shipping applicationdoes not support, or doesn't support correctly. When this happens, who does the shipperturn to? The carrier salesperson? They won't know how the application works. Theintegrator? They can't help because they don't understand the carrier rules? Thedeveloper? They are not available? The carrier? They will redirect you to the integrator.And on and on.

www.cmsglobalsoft.com

______________________________________________________________________________________________________________Third Party Applications, Middleware and ERP Systems: March 2008

The State of Shipping Systems TodayPage 3 of 5

Ultimately therelationship does notwork for third partyapplications. Yes, theyhave the carrier rules,and sometimes theyget it right, but theycan not keep up withthe dynamic nature of the business, which issupporting the carriers'requirements. This isultimately what wedecided at CMS, whenwe began designingour web based TMSapplication; CMSWorldLink would notbe a third party carrierapplication, in thetraditional sense.Instead we chose to e a middleware product. Our application manages data but has nocarrier rules within it. So how do we support the carrier rules then? In our framework, weembedded server side API applications that come directly from the carriers. We use theFedEx FSMS application for all FedEx shipments and the UPS owned ConnectShipproduct for all UPS transactions. The relationship works very, very well. Since eachcarrier supports their own development efforts and transactions, they are always willing tokeep up-to-date with their own latest changes as well as support their own product when aspecific transaction fails. Unlike a third party application, if a specific carrier transactionfails, we immediately contact the carrier support team to determine the root of the failure.

Figure 1-0.

UPS, UPS ConnectShip and Third Party Developers

I am told that the official policy at UPS is that they will tell a third party developer thatthe relationship they maintain with them will be the same relationship UPS will maintainwith their own subsidiary ConnectShip. Mmmmmmm is all I can say. ConnectShip is anawesome company and the best of breed at keeping up with UPS changes on a worldwidescope. The reasons are obvious: 1) they are owned by UPS and know exactly what thelong term strategy is 2) it is in their best interest to keep up with new solutions that willdrive more service based revenues to UPS.CMS WorldLink then relies entirely on a carrier's supplied rating engines to be compliantwith themselves. CMS WorldLink developers are free to concentrate their efforts on thedevelopment of the other two layers: the GUI and the business rules. ConnectShip doeshave similar tools but again, their absolute strength is keeping up UPS carrier rules.ConnectShip does not manage the overall enterprise solution well; such as they can'tdefine one site's currency or time zone versus another, they don't support users withActive Directory, the GUI is not site specific, etc. But nor should they be an enterprisesolution for anything other than the carrier layer. What they do, they do better thananyone in the industry and that is support UPS transactions from a global perspective!You want to ship from the UK, ConnectShip supports that. Want to ship from Canada,