Category Archives: Cloud Software

5 Reasons Companies are Updating Legacy TMS Software

This post originally appeared on the UltraShipTMS blog (


Adrian Gonzalez of Talking Logistics recently asked the question: Why are companies replacing their legacy TMS?   We’ve definitely seen increasing momentum in the SaaS TMS market in the past few months, with shippers who have legacy TMS systems in place actively working to replace these systems with SaaS solutions.  So, OK Adrian, I’m going to take a swing that this question and share some reasons why I think this much-anticipated shift is really starting to accelerate.  

1)     Money for Nothing – I was a CIO for several years, and there’s nothing CIOs hate more than maintenance payments to legacy software vendors.  In a sense, this is money for nothing.  Sure, CIOs know they need their vendor to keep paying some staff to keep the solution alive.  But often times companies with a legacy TMS don’t install the new versions as they come out.  It’s too expensive to bring back the consultants and migrate to the new version, test it, retrain users, etc.  So you have all these companies paying 16-20% of their original license fees for maintenance every year, arguably for nothing.  Let’s say you spent $500K to license the original solution.   Hmmm…at 20% software maintenance, that’s $100K annually you could put towards a fresh, up-to-date SaaS solution; and we haven’t even considered the cost of maintaining servers, storage, and disaster recovery for the old TMS!  By contrast, all these things are included in the monthly subscription with a SaaS TMS provider.

2)     Generational Change – Peoples’ expectations have changed.  The current and emerging generation of logistics managers and executives expect their user experience to be like Amazon, not some old school, client server application, or a green screen AS/400 application (yes, there are still a few of these out there).  If your new generation staff encounters your old generation technology, expect the leaders among them to agitate for change.  If change is not forthcoming they may depart in favor of some more forward-thinking organizations.

3)     Consolidating Legacy TMS Market – In many cases, legacy TMS companies have been acquired.  The new owners may have vague product plans which may (or likely may not) involve the legacy system you’ve invested in.  The software developers who built those products are probably gone, and the new owner might not be investing to keep the product vital, and moving forward.  If that’s the case, why not consider SaaS vendors who field a modern product that’s continually moving forward?

4)     Brittleness of Old Solutions – Legacy TMS solutions were often implemented by consultants and company staff who may have moved on.   Unfortunately, these solutions don’t evolve with changing supply chains.  You acquired a new division?  How are you going to get them running on your legacy TMS?  And meanwhile, top management is eyeing freight savings as one of the synergies of the acquisition.

You want to make major changes to your carrier base in order to realize those savings?  Hmmm.  The guy who knew how to set that up in the TMS quit.

You have some new ideas for optimization?  Hmmm, that sounds like a big consulting project with your legacy TMS vendor or a consultant.

Supply chains change.  But has your legacy TMS evolved?  Chances are it’s frozen in time, circa the year it was first implemented.

5)     Getting Tired of Waiting for Your ERP Vendor’s Solution – The major ERP vendors were slow to create (or acquire) strong TMS solutions. But worse, deploying an ERP solution is a huge project and is often not the priority for your company’s ERP team.  So many companies have still not deployed their ERP vendor’s TMS.  With the availability of good SaaS TMS options, and the relative speed of implementing these, we’re seeing more logistics and supply-chain teams take charge of the situation and implement a SaaS TMS, without waiting for their ERP vendors’ solutions.


Michael Sadowski is a consultant on logistics and supply-chain IT issues to 3PLs, shippers, and software companies.  He’s also CEO of Cayugasoft Technologies (, a software development firm.  Previously he was a CIO in the 3PL industry (where he led numerous TMS software development projects), and an executive in a TMS company.  

What Questions Must a Great TMS Answer? Pt. III (from the UltraShipTMS Blog)

Here’s a post that was originally published on the UltraShipTMS Blog (


To date, we’ve shared the perspectives of a transportation management executive (part 1) and a transportation/carrier relations manager (part 2) to the question: “What are the most important transportation management questions a TMS should be able to answer?”

This third installment delivers the answers provided by Mike Sadowski, the principal consultant at CamiApp, a firm that provides consulting on logistics and supply-chain IT issues to 3PLs, shippers, and software companies. Mike spent years as a CIO in the 3PL industry where he led the creation and implementation of several TMS and freight audit and payment systems.  Installment 3 of 4: The Enterprise Software Consultant

Mr. Sadowski, what are the most important questions a state of the art TMS should be able to answer?

1) What carriers drive shipper inefficiency, and why?   For example, which carriers do not reply to tenders on a timely basis?  Which ones have service failures, and what’s the root cause of these?  When these things happen, they drive manual efforts on the part of shippers to resolve the situation.  So if I know which carriers are driving manual efforts, I can work with the carrier to reduce those manual efforts, or give my loads to carriers that don’t increase my manual workload.

2) What customers are difficult to service, and why?  How much more do they cost to service than average customers?   We all know that some customers are more difficult than others.  I remember one shipper who sold their products through a major US big box store.  They found that individual stores required delivery appointments, which often resulted in trucks waiting around the stores for an empty loading dock.  This, despite the fact that the corporate logistics team insisted that no stores should require appointments.  Well, if the TMS can capture this information through status messages, and prove what’s going on with real data, then in this situation (or similar situations) you can go back to corporate logistics and explain why you’re going to need to increase your rates next year.  You can prove to them that they are more difficult to service than they think.

3) Why did the TMS plan this load as it did?  Modern TMS solutions have a lot of sophistication in the area of business rules.  Shippers will (of course) have preferred carriers and this is loaded into the TMS as a set of business rules.  But some of their customers may also have prohibited carriers resulting in additional business rules.  And the shipper may be allocating shipments based on capacity constraints that the carriers have.  If the shipper is using the TMS for optimizations, there are many business rules that get applied, such as how far out of route you might allow a truck to go, the maximum time you might make a driver wait to make a pick-up en-route, equipment requirements, etc.  All of these business rules can make it difficult for transportation planners to understand why they’re getting the results they are seeing from the TMS.  If a TMS can offer some insight into why it’s making the decisions it’s making, this provides comfort to the planners and transportation managers that the TMS is doing the right thing, and the planner should go with the plan provided by the TMS.  Without this capability, I find that planners will often question why the TMS is making the decisions it’s making, and they begin to lose confidence in the system’s decision making, when in reality the TMS is making the correct decisions, or it would do so with some simple changes to the business rules.

SaaS TMS expert, SadowskiMichael Sadowski is Principal Consultant at CamiApp, a firm that provides consulting on logistics and supply-chain IT issues to 3PLs, shippers, and software companies.

Freight Payment & Audit – Options and Best Practices (Part II)

Here’s a post that originally appeared on the UltraShipTMS blog.

My last post examined the main options for handling freight audit and payment, weighing the pros and cons of each. If you’re a shipper interested in the option of implementing a TMS freight audit and payment module, this follow-up discusses key features you’ll want in a solution.

A TMS Freight Audit Module’s basic process is:

  1. Receive invoices;
  2. Check invoices vs. expected rates, and validate payments;
  3. If invoices are equal (or close) to expectations, pay them;
  4. If invoices are not within expectations, resolve the issue and determine what to do with the invoice;

There are some variations on this process like the frequently discussed “auto-pay”, wherein a TMS determines the expected freight charges and pays carriers without requiring invoices. It’s a nice idea in principle, but it’s still rarely used, for various reasons. Most of those using auto-pay typically implement it only with amenable carriers wherein shippers calculate the costs very accurately, making for slow roll-outs. Like most, you’re likely going to utilize the aforementioned mainstream process.

To get the most out of this process, the freight audit and payment system must receive freight invoices by EDI, or other electronic formats, such as XML. You’ll also want efficient and friendly user screens for freight invoice data entry when hard copies are received. Some systems offer invoice entry screens intended for use by carriers, which are convenient for shippers. But many carriers have their own processes for billing and likely prefer EDI invoicing as opposed to using shippers’ data entry screens.

To check freight invoices vs. expected rates, freight audit modules need a strong rating engine like those included in good TMS solutions. Using a TMS freight audit module (as opposed to a freight audit and payment service) puts you in great shape for auditing once rates are established in the TMS. The system should match the invoice to known shipments in your system, verifying the shipment truly occurred and was properly authorized.  Also, it’s common practice to verify the carrier delivered the shipment and reported delivery to your system via an EDI 214 status message before paying.

Discrepancies and Tolerances

In some cases you’ll receive invoices for shipments not planned in TMS, and you’ll need to deal with those too.  Clearly, your system is going to require sophistication and configurability to handle these scenarios without manual workarounds.

Often, actual shipments differ from those planned. The system should easily distinguish between the two. Causes of discrepancies between planned and actual shipments may include weight differentials, differences in the line items shipped (e.g., the inventory system showed some SKU was available, but the warehouse staff couldn’t find it), different shipment dates (which could affect fuel surcharges), etc.  If you don’t have an accurate picture of what actually shipped (and when) you’re going to have a lot of exceptions when auditing carrier invoices.

The system needs the ability to establish cost tolerances. If within the tolerance limits, the invoice will be paid. I’ve had clients tell me they don’t favor tolerance limits. They want to force the carrier to get it exactly right. I reply, “Some minor discrepancies are completely legitimate, and having a tolerance avoids expending more costly man-hours resolving very minor issues.”

Payment Processing

The system should integrate with the shipper’s ERP payables system to create a payable voucher for carriers. You’ll need some way of ensuring that the carrier list in the freight audit module syncs with the list of vendors in the ERP, so that as new carrier contracts are negotiated, the carrier is known in both systems.  Ideally, carriers get access to payment status over the web, to see when they’ll be paid for any given invoice. This reduces the call volume to your payables group and is a significant labor saver.

Finally, an effective freight audit tool implements a freight audit process focusing on automation, only requiring user intervention for exceptions. An effective freight audit process using a strong TMS freight audit module succeeds at automating a large portion of invoice processing, and keeps manual efforts to a minimum.

SaaS TMS expert, SadowskiMichael Sadowski is Principal Consultant at CamiApp, a firm that provides consulting on logistics and supply-chain IT issues to 3PLs, shippers, and software companies. Previously he was a CIO in the 3PL industry (where he led the creation and implementation of several TMS and freight audit and payment systems), and an executive in a TMS company.

Freight Payment & Audit – Options and Best Practices (from the UltraShipTMS Blog)

Here’s a blog post I wrote that appeared on the UltraShipTMS blog:!

If you could save a conservative 3% on $100 million in freight spend via freight audit and payment automation, your $3 million savings would easily pay for a TMS investment.

What are your options when it comes to freight audit and payment? Here are the main ones:

1. Do It Manually – Handle your freight invoices through your normal AP process, using your ERP system’s payable module. It’s good enough for paying your other bills, so why not freight bills? However, an ERP system won’t provide your AP staff with much insight into the rates carriers should be charging you. Worse, you might be prone to paying duplicate invoices, or even paying fraudulent invoices. Lacking proper tools, even the sharpest AP department will leave a lot of money on the table.

2. Freight Payment Provider – All of your freight invoices are received, checked for correctness, and then paid by an outsourced provider. But understand, this requires an IT system implementation with the service provider in order to work properly. Carefully consider if this service provider will perform over the long run before awarding the contract. The major risk is – should the provider do a poor job managing relations with your key carriers or paying them promptly – you’ll have problems getting carriers to accept your freight, or difficulty negotiating good rates, being perceived as a “difficult customer”.  Some freight audit providers require the shipper to advance the funds to make payments to the carriers, putting shippers at risk for fraud or loss due to provider insolvency. Why give a service provider an interest free loan? Many shippers are rightly uncomfortable with this model for these reasons. An alternative approach is to only advance the provider enough to make specific carrier payments, or better yet, let the provider instruct the shipper when to make each carrier payment. These approaches are improvements, but require more sophisticated systems integration.

3. Use a TMS Freight Audit Module – Wherein shippers use a module within Transportation Management Systems to receive, audit and pay carrier invoices. While the downside is that you need to provide staff to run the audit process, if you implement a good TMS freight audit module, with a lot of automation, the staff required to keep the process running is minimal; likely less than your current levels. Several other benefits include:

a. Shipper keeps control of payments, and has peace-of-mind vs. outsourced models, which are prone to operational issues or even fraud;
b. Implemented well, TMS can be the low cost solution, since you don’t need to pay a freight payment provider, year-after-year;
c. You can provide rapid feedback to carriers on their billing issues, allowing you to coax them into improving their billing quality;
d. Finally, your freight payment history data is your best data source on your true spending on various carriers. Keeping this in-house is valuable since this is a strategic asset you should use for supply-chain analysis, modeling cost savings programs, and carrier negotiations.

Next time we’ll talk about key features to look for in a TMS Freight Audit and Payment module.

SaaS TMS expert, SadowskiMichael Sadowski is Principal Consultant at CamiApp, a firm that provides consulting on logistics and supply-chain IT issues to 3PLs, shippers, and software companies. Previously he was a CIO in the 3PL industry (where he led the creation and implementation of several TMS and freight audit and payment systems), and an executive in a TMS company.

– See more at:!

Saas TMS Obliterates Outdated Attitudes Toward Logistics Software (from the UltraShipTMS Blog)

Here’s a blog post of mine about SaaS Transportation Management Systems (TMS) that appears on the UltraShipTMS Blog.  UltraShipTMS is a shipper-oriented SaaS TMS provider that’s won a number of awards for their products.

According to Logistics Management’s Annual Software Users Survey conducted by PRG, 37 percent of companies were using TMS in 2012, up from 32 percent the prior year. Twenty-five percent of respondents say they plan to buy or upgrade-steady from 2011′s numbers-and a net 50 percent were either using or planning to buy a TMS. Clearly TMS adoption is on the rise.

About four years ago I wrote an article for Industry Week, in which I took a look at the reasons for what was, at the time, surprisingly low penetration of TMS systems. Today, I’ll revisit the topic and discuss why a surprising number of shippers have changed their minds regarding using a TMS, and look at how SaaS TMS systems are a large part of the reason why.

In addition to the many, well-documented case studies showing that transportation management systems deliver a strong ROI, there are a number of other factors contributing to the invigorated interest in TMS. However, a few historical biases still remain as impediments to adoption among shippers who may not know enough about how recent advances in TMS solution offerings have changed the experience for shippers of all sizes:

1) IT Priorities – Before the jump in fuel prices over the past few years, logistics was not typically a high priority when it came to IT investment. Until recently, transportation and logistics projects were often shelved in favor of ERP upgrades or CRM implementations.

2) Difficult implementation – A perennial complaint about technology implementations in general, TMS had been characterized as especially “tough to implement”. It wasn’t uncommon to find shippers with a partially implemented TMS. Many grew frustrated with implementation challenges and simply gave up before completing the full deployment.

3) Expensive to Operate and Manage – It used to be relatively costly to operate a traditional TMS, year after year. Pre-SaaS solutions entailed significant hardware and software maintenance costs as well as personnel with arcane skill sets to keep the system working. All of which cost a fair bit of money.

Today, by contrast, companies are finding TMS solutions that:

• Reduce the cost and burden on the shipper’s IT team, who would rather focus on their core ERP system. SaaS TMS systems still require integrations to the shipper’s ERP systems, but a SaaS TMS reduces the burden of hosting, monitoring, and managing the application.

• Don’t require large up-front expenses, and provide value quickly. SaaS systems don’t require big up-front capital expenditures. Additionally, SaaS vendors seem to have figured out how to do implementation projects quicker and for less money than the traditional non-SaaS TMS vendors have. They do this largely by controlling the implementation themselves, rather than by depending on armies of “Big Six” or “Big Four” consultants, as the traditional vendors often did.

• Don’t require companies to add new hardware, software, staff or skill sets. SaaS solutions are hosted in the cloud and don’t require anything more than an internet connection for client users. Moreover, SaaS-based TMS providers reduce the arcane skills a shipper must maintain in order to get value from the system. The SaaS TMS vendor helps provide some of this know-how to the shipper. For example, a SaaS vendor can easily do a checkup to ensure their optimization algorithms are tuned and achieving good results for a shipper.

A few years ago, SaaS vendors were behind the traditional TMS vendors in terms of functionality, and their products were probably more appropriate for mid-sized shippers than for large shippers. That’s not the case today. Strong SaaS vendors have competitive functionality that’s sufficient for the largest shippers. Additionally, they can implement their systems in a reasonable timeframe, and at a lower cost than traditional vendors. Over the next few years we can expect that SaaS TMS vendors will continue to penetrate shippers who’ve resisted implementing a TMS until now due to the objections I’ve described above.

Bridging the Gap — Traditional TMS and Fleet Management

UltraShipTMS has an interesting positioning vs. traditional TMS vendors (the ones whose systems are used mainly to manage common carriers, i.e., trucking companies who carry goods for a number of shippers).  They’re targeting companies that have a mix of private/dedicated fleet, and common carrier shipments.  Check out their recent white paper:

If you look at the functionality of most TMS systems, the focus is on selecting a common carrier based on a routing guide, tendering to the carrier, freight audit and payment, track and trace, and grouping of shipments in order to save on freight spending (“optimization”).  If you talk to the sales team for traditional TMS vendors, they’ll tell you they can handle private and dedicated fleets, but that normally means “just load in the private fleet as if it’s just another carrier.”  That’s not a great answer, unfortunately.  That means you don’t have a system that lets you operationally control your power units and drivers (e.g., via Qualcomm integration) or help you pay your drivers based on the miles they’ve driven.  And worse, you might need to use some tricks to “fake out” the system, for example, to ensure that the private/dedicated fleet gets selected for the right shipments.

Instead, Ultraship combines functionality from fleet management tools (tools for managing your own fleet of trucks) and common carrier management tools (traditional TMS).  So shippers that have a mix of common carriers and private/dedicated fleets (which turns out to be a lot of companies in some verticals!) now have a better option.  By focusing on this market–shippers who use both common carriers and private/dedicated fleets–I think UltraShipTMS may have found a market segment that’s both under-served, and quite large.

Supply Chain Visibility – Impossible Dreams (Part 3)

“Like a lot of technologies, supply-chain visibility didn’t live up to the early hype.  But just like the Internet, where and Webvan failed, we can’t write off the whole concept of supply chain visibility due to some disappointments.”

Last time I wrote about some of the early work in area of supply chain visibility systems and why those systems didn’t match the early hype.  So given the fact that supply-chain visibility systems haven’t evolved into all-seeing, all-knowing, supply chain monitors and controllers, are they worth bothering with?  Sure.  These tools still provide a lot of utility (just not everything that’s been promised over the years):

1)      Source of data for metrics monitoring, and continuous improvements – If you can achieve a certain critical mass of data completeness and accuracy, supply-chain visibility tools provide you with a great data source for measuring key supply chain metrics such as on-time delivery to the customer, and the performance of your supply-chain vendors.  Once you have a measure of where you are now, you can determine root causes of why you’re not achieving your goals, and figure out how to improve.  A lot of companies still rely on their transportation providers to tell them what their on-time performance was.  Those providers will tell you their interpretation of those metrics, but even assuming they are being “honest”, that’s still a very incomplete picture of your supply-chain performance.  Your trucking firm may say an order was delivered on time, but if you can’t match that up to the problem in manufacturing or in your warehouse that prevented you from handing it to the carrier as planned, then you really can’t determine the root causes of your problems or understand your true customer service level.  If you look at companies like IBM and Oracle’s marketing messages on the supply-chain, and “big data” and “smarter planets”, it’s a bit vague what they are talking about, but what comes across to me is the idea that there are new technologies for analyzing mass quantities of data that have, thus far, not provided many useful insights.  So the data gathered by a supply-chain visibility tool is ideal for this “big data” approach—lots of data that’s being under-utilized, and which probably has a lot of stories to tell.

2)      Tools for customer self-service – Customers today have an expectation that they can look up the status of their orders, as if your company was Amazon or Fedex.  Never mind that you don’t have the IT budget that Amazon has, and that Amazon, for the most part, uses only 3 transportation carriers, and you use tens or hundreds.  Or that you don’t own your logistics assets like Fedex does.  Your customers don’t care—Amazon and Fedex are training them to expect this level of service.  What you provide won’t be as complete as what Fedex provides, but the good news is that it’s still possible to impress customers and outdo your competitors here.

3)      Tools for pro-active monitoring of critical supply-chain steps, with human follow-up – While I’m a skeptic of the idea that visibility systems will soon use all-knowing, Artificial Intelligence-like capabilities, and automatically take actions to save your butt, I’ve helped companies to pro-actively utilize visibility system data to monitor critical steps in their supply chains.  And anyway, as I said in my last post, trying to use automation to solve this problem is probably overkill.  Managing exceptions is actually something people are good at.  So automate routine processes and let people manage the exceptions.  They key here is to focus on a couple of error prone points in your supply chain.  Work at getting better, more granular, and more accurate data for these steps into the visibility tool.  Don’t worry too much about other, less issue-prone steps.

Like a lot of technologies, supply-chain visibility didn’t live up to the early hype.  And a lot of money was wasted based on some science fiction notions of what the supply chain systems of the future might look like.  But just like the Internet, where and Webvan failed, we can’t write off the whole concept of supply chain visibility due to some disappointments.  There’s a kernel of value there, and there are still plenty of opportunities to outdo your competitors by improving your supply-chain processes and your service to customers using these systems.

Supply Chain Visibility – Impossible Dreams (Part 2)

“Despite hundreds of millions of dollars invested in supply-chain visibility systems in the 90’s and the 00’s, we’re still far from having systems that can automatically diagnose the state of your supply chain on a given day, and take operational actions to save your butt.”

Last post, I talked a bit about the history of supply chain visibility systems, and about how much of the money invested in creating such systems was flushed down the toilet.  So why are some of these supply chain visibility dreams—the dream of having a system that can somehow foretell your supply-chain future and intelligently and automatically take action, given the occurrence of some supply chain event—so far from being realized?

1)      The systems don’t solve “black swan” supply chain problems – The supply chain issues that cause executives to really lose sleep are the black swans that they haven’t thought of yet, and could never have imagined if they tried.  They aren’t losing sleep about what will happen if one shipment is late, which tends to be the problem that many supply-chain visibility systems are designed to solve.  They are worrying about huge events that could cause serious supply-chain disruptions.  A nuclear accident and tsunami in Japan.  A flood in Thailand.  The only problem is that we all have no clue what the next massively disruptive event will be.  And if fact, as the geniuses on Wall street learned when their models failed to predict the sub-prime melt down, your systems might blind you to the existence of these black swans and make you overconfident of your ability to avoid them, because by definition your systems model the known world, not the unknown events that we have trouble even envisioning.   If you’re most concerned about these colossal supply-chain interruptions, most supply-chain visibility systems aren’t going to be much help.

2)      Inability to model the supply chain sufficiently well – In order to create some kind of supply-chain monitoring system that can actually detect problems and take actions, you need to have a model of your supply chain.  Let’s leave black swan events aside, for the moment.  Even then, our supply chain model needs to be mostly correct, and it needs to then be implemented in a piece of software.  We are far from understanding our supply chains in enough depth to be able to do this.  E.g., if a truck shipment misses a connection with an ocean container vessel, you might want your system to discover this and rebook the shipment on another ocean vessel.  Or even better, you might like the system might be able to expedite the shipment somehow and get it to the port on time for the original vessel sailing.  At least, that was the theory.  Anybody who’s ever been operationally involved in logistics will roll their eyes about the possibility of achieving these things through some automated system.  It’s hard enough to do in the real world, much less automate this through software.  At best, you might get an email telling you that there’s a problem, in most cases hours after the fact.  But if your freight forwarder is any good, they would know about the issue long before you got that email from a supply chain visibility system.

3)      Data – Supply chain visibility is a big B2B integration problem.  You need to gather timely and accurate data from multiple other parties in the supply chain, pull that data into one system, and make some sense out of it.  The technology required to receive and transform this data exists and is getting better every year.  You can do it with your own in-house TMS or ERP system, or with a cloud based supply-chain visibility system, or you can get a 3PL or 4PL to help you.  The problem remains, though, that the data still isn’t as timely and as accurate as it needs to be.  If you look at typical EDI in-transit status messaging from US-based trucking firms, these are sent hours (and in some cases days) after the events that they describe occurred.  People imagine that these messages might have the accuracy of Fedex and UPS package delivery status messages.  Sorry.  Most trucking firms can’t do that.  They may have cab-based systems for tracking trucks, but they aren’t oriented towards providing data to their customers–their purpose is to provide operating data for the carrier.  I’ve implemented in-transit visibility systems in Europe and Asia and the data is much worse there.  Whereas in North America, where in-transit tracking data is merely shitty and late, in Europe and Asia (apart from giants like DHL), you find yourself in a discussion with the carriers that makes you feel like you are inventing in-transit messaging from first principles.  (OK, and now try doing that with a carrier in Japan, when the meetings are held in Japanese, with a translator!)   The technology exists to vastly improve on this–satellite tags, RFID.  And there are pockets of the supply chain where these technologies have been implemented.  But deployment in the “real economy” has been slow.

4)      People are the best “tools” for managing exceptions—Reacting to exceptions is exactly when you want humans involved.  Do you really want a machine to authorize chartering a plane to get a shipment there on time just because your visibility system discovered that the trucking carrier dropped the ball on it?   A good human being is going to be able to think creatively about the problem and take action.  A machine?  Maybe one day.  Machines are great at automating routine tasks.  But humans are still the best exception management tools invented.  So your best bet is to present the information from your supply-chain visibility system to a human being, and let them handle the exceptions, rather than try to automate this.

OK so now that I’ve depressed you about the inability of supply-chain systems to automatically diagnose the state of your supply chain on a given day, and take operational actions to save your butt, next time we’ll talk about some reasonable goals for supply-chain visibility systems and how they can help your business.

Supply Chain Visibility – Impossible Dreams (Part I)

“Often, it’s better to go with simple solutions that require teamwork and individual accountability rather than trying to automate the hell out of something.”

When I was in graduate school I studied with Prof. Dick Conway, who is considered one of the “fathers of scheduling” for his early work on production scheduling.  In one class, we formed small teams and were given the challenge of designing a manufacturing system for an electronic product.  I can’t remember what the product was, exactly, but it was roughly as complex as, say, an office copier.  My team, and most others, envisioned a highly automated production line, run by software that would provide a sort of electronic Kanban system that would send signals down the production line to the various work stations.  This (overly) complex software system was supposed to balance the production steps so that work-in-process inventory could be kept to a minimum.  In retrospect, it was a kind of sci-fi solution that would have never worked well, especially given the sophistication of supply-chain systems at that time (the early 1990’s), and given the amount of processing power you could buy on a typical CPU at the time.  But apart from those limitations, Prof. Conway showed us that the complexity of our solutions was both detrimental, and unnecessary.

It turned out that the best solution was not to use an automated production line at all.  Instead, it was better to use small teams of workers that built a unit, essentially from start to finish, testing the unit after each step in the manufacturing process.  Part of our course of study was to drive around the Northeast in a couple of vans with the Professor, and tour various manufacturing facilities and discuss what we saw.  During one of those trips, sure enough, we visited a factory that was building their products exactly like this—with small teams of workers taking ownership of their work–with good results.  This approach had many benefits vs. the fancy approach that we (the grad students) proposed: assuring that defects were caught promptly and fixed before they started piling up at the next step in the production process, minimizing work in process inventory, and allowing the team to take ownership over the quality of their work and productivity.  Maybe my team’s fancy, automated approach could have worked, but it probably would have failed, and it wasn’t the best approach to solving the problem anyway.  Often, it’s better to go with simple solutions that require teamwork and individual accountability rather than trying to automate the hell out of something.

I’m reminded of this story when people talk about other attempts to apply computers to solve problems that are best solved with less elaborate approaches.  In this case I’m talking about supply-chain systems.  Or at least the idea that supply-chain systems will one day have all seeing, all knowing “visibility” into the supply-chain, and an ability to respond to supply-chain events with automated, intelligent actions.  Maybe these systems will come along one day, but I don’t think that day is close at hand.  Over a decade ago, I was the head of product management at RELY Software, which was a logistics software vendor that was one of the early companies that built a web-based supply-chain visibility solution.  I think the product we built at RELY was ahead of its time—it was a genuine SaaS product built in the early 2000’s, with all customers supported on a single hosted instance of the software (a so-called multi-tenant system).  There were other software startups around with similar ideas and products (Celarix was one that had a lot of funding and that people seem to remember).  There were some companies involved in supply-chain visibility that came at the problem from the ocean transportation side of logistics (e.g., GT Nexus).  And there were some companies that came at the supply-chain visibility problem from the perspective of the railroad business, such as Transentric.  The Enterprise Application Integration (EAI) vendors like WebMethods framed the supply chain visibility problem as a B2B integration problem, and proposed their own solutions based on their strengths (and now that I think about it, to an extent they were correct–more next time).  And most of the Transportation Management System (TMS) vendors, such as GLog (now Oracle TM) and i2 (now JDA), developed modules that could gather logistics events from the supply chain, and show you the status of a shipment.   They could also apply rules to the data they were gathering and alert you if certain conditions occurred, or didn’t occur, just like the system we built at RELY Software could.

If you add up the venture money invested in these (and similar) companies it comes to hundreds of millions of dollars.  Seriously.  It seems strange to say this now, but E-Logistics (as people called it at the time) was once a hot investment area.  I don’t want to say that it all came to nothing, but there sure was a lot of money wasted.  At the time there was an idea that supply-chain visibility systems could somehow foretell the future or be used to intelligently and automatically re-route a shipment, given the occurrence of some supply chain event.  I still hear people say things like this, sometimes, but this possibility remains far in the future.   Why?   I’ll tell you next time.

Tagged ,

Snarky Comments on Cloud SLAs (Part II)

In my last post I wrote about the problems with Cloud Service Level Agreements (SLAs), and why they tend to be less useful than one would like.  OK, so what can you do about it?

1) Ask Questions — If your service provider offers an SLA, study it and ask questions.  “Is that all you can promise?  What’s your historical performance?  Can you show me some documentation of that from your monitoring tools?  Have you had any downtime incidents in the last five years?  What were the root causes, and what did you do to address those?”  The discussion will be useful in filling in your picture of their capabilities.  In the end, an SLA is just a number (or a few numbers), and it doesn’t give you much insight into the provider’s ability to deliver.  An SLA is a bit like a car warranty—it’s nice to know you have it, but your real hope is that it won’t be needed and the thing won’t have any significant breakdowns.

2) Try to Negotiate — Good luck on this, but give it a try.  I’ve found that, normally, the salesman doesn’t have the discretion to change the penalties in the SLA.  However, if the vendor doesn’t offer you an SLA, just asking might get you somewhere.  In the logistics software space, there is a company called SMC3 that creates a system used for calculating the rate of a Less than Truck Load (LTL) shipment, and most companies in the industry use this product.  They recently converted from a traditional licensed software model to a cloud model.  I was at their conference in Atlanta a few days ago, and asked about their SLA policy.  They don’t promise an out-of-the-box SLA, but they say that they’ll negotiate one on occasion.  So it seems that if you are a big enough customer to them, you’ve got a chance of getting an SLA in writing.  You’re not doing this to negotiate the SLA up to a level with which the vendor isn’t comfortable, because that isn’t going to change their real-world ability to deliver on the SLA.  But you want to understand what they can deliver, and get comfortable (or not) with this level of performance, assuming the vendor’s service is critical to your business.  In the case of SMC3, if you are moving LTL shipments for a living and you need to quote prices to your customers, then you’re really depending on SMC3 to deliver, because if their service goes down you can’t provide price quotes to customers.  So you owe it to yourself to understand their capabilities.

3) Look at Audit Reports – If the vendor has been audited (e.g., using the SAS 70 standard) then you should get a copy of the audit report.  Read it.  DO NOT just treat this as a check mark—“great, they passed an audit.”  Look where that got investors in Enron and Worldcom.  Like most standards of this nature, the audit “control objectives” for SAS 70 are essentially whatever the cloud vendor says they are.  So the cloud vendor tells the audit firm their control objectives, and the auditor audits to check that there is a reasonable assurance they would achieve those objectives (the auditor will state very clearly, though, that this is not a guarantee).  The auditor will make sure the business objectives that the cloud vendor uses are not completely stupid, but I find that a lot of people assume (wrongly) that SAS 70 is some kind of seal of approval that the vendor is doing “all the right things”.  SAS 70, for example, says nothing about providing disaster recovery (DR) capabilities.  A vendor can provide zero DR, and pass an SAS 70 audit with flying colors, simply by not stating any control objectives regarding DR, but showing compliance with whatever control objectives they do have.

4) Do Your Own Audit — While it might make you feel good to host your systems in-house, because you feel you have more control, chances are that you can’t do as good a job as a strong cloud vendor.  You probably know someone who feels comfortable driving a car, since they control it, but who doesn’t like flying in an airplane because they have to trust the pilot, even though flying is statistically safer than driving a car.  So maybe you should find out if your cloud vendor knows how to “run an airline”.  If the service provider is critical to you, arrange an audit where you visit them and understand their capabilities.  Are they doing the basics?  Do they have multiple power supplies on each server, or only on some of them?  Do they have multiple NICs on every server?  Ask them to show you.  Do they have current maintenance contracts with their key vendors (server hardware, network hardware, etc.) or did they “forget” to renew them?  How fast would that vendor promise to rush in a part required to fix their box if it went down?  Next business day? Hmmmm.  One of my customers once did an audit like this on my data center, and while it was painful at the time, ultimately it was beneficial for me and my team, and for the customer, since they had a much deeper knowledge of our real capabilities, and in the end they grew comfortable that we knew what we were doing.

Tagged ,