I interviewed Brad Forester Founder of JBF Consulting who discussed Adding Realism to Discussion of Supply Chain Technology.
I’m looking forward today to discussing with you the debunking of some buzzwords regarding visibility in omnichannel and, more specifically, bringing some realism to this discussion of supply chain technology. My first question is: What is the biggest barrier to generating return on investment of a TMS?
Thanks, Dustin, for having me on this call. I think the first thing that most companies need to clean up or look at is how they’re coming up with the definition of return on investment in the first place. I see a lot of companies put together these business cases with huge benefits and a huge return when, really, those are very aggressive types of numbers to hit, and they don’t necessarily create an implementation that will deliver on those benefits.
I think that, in addition to the actual implementation, too many companies focus on that first implementation of a TMS or any technology, really. Typically, those first initial projects are so constrained by time, budget, or by the system complexity that the advanced features are never really activated or turned on. In a lot of implementations, the client is left with having to do this work and figure out on their own after that initial implementation, and too many times it’s just not happening.
We’ve been working a lot with our clients in the transportation-management system space, and a concept that we’ve kind of come up with through discussions with our clients is around this gardening analogy where you can’t just design and build a perfect vegetable garden; you actually have to do some work after it’s done in order to have any value come out of it. That’s resonated well and I think the analogy’s just easy in that clients can understand that after that first implementation, that’s when the actual work starts. We help them figure out how to do it and how to get the value after the technology’s already been implemented.
And why is cloud/TMS becoming so popular?
I think for a lot of those same reasons. From a technology standpoint, these on-premise systems or on-premise TMS where the client will actually license the technology and install it on their own servers, there’s a lot of complexity in those implementations. These products are very mature, they’re very feature-rich, and the implementations are lengthy and complex. I think that a lot of clients have gone through that, and they’ve realized that they’re just not mature enough from an IT standpoint or a business stewardship standpoint to really get the most out of those systems in the implementation.
A lot of them turn to service-based technology—SaaS, cloud, whatever you want to call it—as a way to help ease the burden of the implementation time, the implementation complexity, implementation costs. Companies kind of see this as a way to faster return on investment even though it might be a smaller, addressable return just because the SaaS tools are relatively much newer than the on-premise tools—from a transportation standpoint, anyway—and they’re not quite as feature-rich. You might expect a lower return on investment for cloud-based technologies but a faster return on investment, which might be the key there.
Also, I think the new cloud technologies could add additional benefit over on-premise in that they do add a network-effect component for those who are truly multitenant TMS, like Cloud Logistics, like Lean Logistics; they have some potential to add value over and above the on-premise TMS.
Why is this ability [think you mean "Visibility"] such a difficult goal to achieve?
I think this goes back to that gardening and stewardship concept we use with a lot of our clients. The old way of implementing a TMS is just to come up and stand up to technology. We’ll do a current-state business-process analysis, and, essentially, what we’re doing in that old-school methodology is replicating existing business processes.
When we talk about visibility, that visibility kind of buzzword is difficult to achieve because visibility needs to be interdepartmental. We have business functions from planning, forecasting, manufacturing, or sourcing, movement or the transportation, and then fulfillment and returns; each of those functions within an organization might have their own systems—might have several different systems—that all have different goals and objectives. They also have, probably, different sets of master data, different transactional data, and the departments that run those applications will probably have different goals, different objectives, different measurements within their organization.
When we talk about visibility, we’re typically talking about physical product movement or tracking the physical product as it goes through those business functions and through those systems, if you think of those things linearly. The challenge comes from—like something as simple, for example, master data. A SKU might be totally different to your demand forecasting tool as opposed to your warehouse-management tool. When you look at the TMS in its own bubble for that movement component of the physical product moving, you may not have SKU-level information at all. But when you ask an organization like a retailer or consumer-products company how they want to track end-to-end supply chain visibility, it’s usually at the SKU level. It becomes very challenging to harmonize all of those functional elements and sift them together from an integration standpoint to really achieve that end-to-end visibility objective.
How are visibility and omnichannel similar to a transportation function?
I think omnichannel is kind of another one of those real topical type buzzwords. Omnichannel and visibility are very similar in that they all require a significant amount of cross-functional integration, and not just from a technology standpoint like technically integrating systems—that’s challenging—but also integrating the functions. If we have customers who are placing orders online for a retailer who can then also come into the store to make a return and possibly purchase items from a brick-and-mortar store and then have a return going back through the post, being able to tie all of that together requires many different systems to be integrated, it requires many different functions to be integrated, and I think that omnichannel retail is just an extension of visibility challenges but from an execution, at an execution level, where visibility is kind of a passive tracking or an active tracking, depending on how you want to look at it.
We’re now adding, with omnichannel a transaction; there’s a buy, there’s an order, there’s a sell order [Brad: this was unclear a little...I meant a "buy order" and a "sell order", FYI]. There is some sort of customer at the end of that, whereas with visibility, we’re kind of looking to leverage the information within our organization to support multiple functions. Omnichannel is harder because it adds that transaction element.
My final question is: How can shippers leverage their TMS to become more carrier-friendly?
I think we go back to the gardeners’ methodology concept. This works well with regard to shippers or large shippers who use TMS—technology transportation systems—to go back and really look at things from a strategic standpoint. If one of their strategic goals as a shipper is to become a carrier-friendly shipper, then the department needs to figure out what they can do within the TMS to help them achieve that objective.
The easiest way for me to explain that is through a client analogy. I worked with this large apparel retailer for probably 15 years or more. They implemented a TMS many years ago, over 10 years ago. The first piece of their implementation was to bring in inbound transportation; they currently run inbound on their TMS. For whatever reason, phase two never happened, where they were going to do an outbound TMS deployment on the same platform.
Over the course of 10 years, they’ve run an operation where their inbound carriers are running on a different process from an invoicing and payment standpoint than the outbound carriers. When you consider that the outbound carriers are probably the same carriers hauling their freight on the inbound side, then you’re running into a situation where you’ve got a number of large carriers who handle your freight for both inbound and outbound who are on totally different payment and invoices processes because you installed inbound in your TMS, never got around to deploying it on the outbound for whatever reason, and now you have a carrier who’s looking at this as, “If I’m going to now haul freight for you, in my bid, my rate has to reflect the extra cost—presumably—of doing business with you, because I have a different process for hauling your inbound freight versus your outbound freight, and I have to accommodate for those things from a cost standpoint.”
I think the ultimate output of that is that it just decreases that favorability, that subjective component that carriers use to grade shipper favorability and carrier friendliness of their policies. I think in this regard, looking at things from a systems-landscape standpoint, tying them with your company’s strategic goals and then the logistics or transportation organization’s, support of those organizational goals, all of those things have to be integrated and harmonized so the TMS is able to give you that carrier-friendly perspective that your company needs in order to secure capacity, reduce freight rates, and things like that.
It’s essentially just a matter of rolling up your sleeves and doing the work and not just relying on that initial implementation to drive all the value out of your TMS.
Thanks, Brad. Can you provide a brief background of yourself?
Sure. I attended Michigan State University. I have a degree in transportation and logistics. I spent a few years working on the carrier side at FedEx Ground. I spent a few years as a shipper at Lucent Technologies, managing multiple-facility transportation organization. I then moved into software, where I spent several years at a company called Manugistics, which is now JDA Software, doing consulting and implementation work, as well as product marketing within their transportation-management systems application.
Back in 2003, I started up my own consulting business, JBF Consulting. Since 2003, we’ve really focused on implementation of transportation-management systems. We recently brought on a new partner, Mike Mulqueen from Manhattan Associates. Mike is now running our transportation-strategy practice. We’re really focused on transportation as our niche, transportation-management software as our specialty from an implementation standpoint.
Thanks again for sharing today.
Thank you, Dustin, I appreciate the call.
About Brad Forester
Brad Forester is Founder of JBF Consulting, a unique technology consulting firm focused on supply chain and logistics management
Transportation Management Systems (TMS) Consultant & Implementation Expert