Is Every Company a Technology Company?

A couple of weeks ago, Meg Whitman, the CEO of the new Hewlett Packard Enterprise, wrote a post on LinkedIn that included the following excerpt:

Every Company is a Technology Company

As I’ve mentioned in earlier posts, we’re now living in an era of disruption, what we call the Idea Economy. Companies today can turn ideas into reality in a fraction of the time it took just five or 10 years ago. And it’s no secret that technology is fueling that speed.

Across every industry, IT strategy is now business strategy. Winners and losers are determined by how quickly they can adapt to take advantage of new opportunities or deal with competitive threats.

Every company is a technology company. I agree with Ms. Whitman, especially with how she’s defined it — that across every industry, IT strategy is now business strategy, and that speed of execution will define winners and losers.

This is certainly true in the third-party logistics (3PL) industry, where we continue to see the convergence of business models, specifically the business models of service providers, technology companies, and consulting firms. Today, 3PLs are in the IT business as much as they’re in the freight-handling business. This point was underscored for me at the Kenco Customer Summit a few weeks ago:

When it comes to addressing their IT needs, most of the attendees viewed their 3PL partners as playing a more critical role moving forward. Generally speaking, it’s still difficult for supply chain and logistics executives to obtain IT support and funding for technology (in many cases, money and resources are tied up with other initiatives, such as multi-year ERP rollouts), so executives are looking to their 3PL partners to meet their technology needs, whether it’s software like a transportation management system (TMS) or automation technology in the warehouse.

But does “every company is a technology company” mean that you have to design, build, and support your own technology products and solutions? That’s certainly not what Ms. Whitman is implying. She wants customers to execute their IT strategy using Hewlett Packard Enterprise solutions.

Many 3PLs, however, continue to develop their own IT solutions, a decision driven primarily by two factors that are inherently linked:

IT as a Competitive Differentiator: Having the ability to offer customers different and more targeted and enhanced functionality than their competitors, such as better visibility and business intelligence tools. Here is how one 3PL put it to me: If we and most of our competitors are using the same vendor’s transportation management system (TMS), then how can we differentiate if we’re all basically offering the same capabilities to customers?

Faster, More Responsive Innovation: Having full control of the innovation cycle versus being at the mercy of a software vendor’s release schedule. Simply put, when new functionally is required, either by a customer or an internal request, 3PLs want to enable it as quickly as possible. In many cases, developing the functionality in-house is faster than submitting a new feature request to a third-party vendor and keeping your fingers crossed that it gets included in the next release, which could take six months or more.

The “build our own” strategy has been successful for some logistics service providers and disastrous for others, as Deutsche Post-DHL has painfully learned (as reported by Gavin van Marle in The Loadstar):

Deutsche Post-DHL this morning revealed that it is to write off €345m of costs and abandon the ill-fated New Forwarding Environment (NFE) IT system it has been developing.

“Given the decreased likelihood that DHL Global Forwarding will be able to realise benefits from the New Forwarding Environment system in its current state, the group will recognise, in the result of the first nine months of 2015, one-off effects of a total of €345m,” it said in a statement today.

The total cost of the failed project is a €308m write-down of “assets capitalised in relation to NFE”, and another €37m of expected expenses for the “roll back” of NFE in the countries where it has been piloted.

Over the years, I’ve asked logistics service providers and technology companies about the build vs. buy IT dilemma, and I’ve received valid arguments for both options. It’s a question I’ve asked many of my guests on Talking Logistics. For example, Rick Jordon from Panalpina, who has also worked in the software industry, had this to say:

The dilemma you run into when you write your own system is that they’re typically great out of the gate, they really are differentiators, but as the people who developed them move on in their career, whether they move up within the organization or move out of the organization, you lose a huge piece of that knowledge base and over time that proprietary system becomes more and more difficult to operate.

So, I see both sides of the argument on this one, but in my opinion, I try to standardize as much as possible on [third-party solutions]. I also think there will be continued opportunities for 3PLs to create new software for some piece of the supply chain [not addressed by existing software solutions] or you’ll see startups emerge that will do it, and they’ll likely get acquired by the bigger, entrenched software vendors.

The bottom line: Yes, every company is a technology company, but how you interpret that phrase and act on it can spell the difference between market failure and success, and this is especially true for third-party logistics providers. There is no universal correct answer to the build vs. buy question, and in some cases, a hybrid of the two approaches is the best path forward. Regardless of which path you take, the key is understanding upfront the critical factors for success — the pitfalls to avoid, the hurdles to overcome — and make the necessary investments in time and resources to make it work.

What do you think? Is every company a technology company? Is the build vs. buy IT decision for 3PLs easier or more difficult today than in the past? Post a comment and share your perspective!