Executive IT Corner
with Biju Kewalram
I’ve heard this dilemma expressed in many ways over the last 25 years: “Should we buy off-the-shelf software or should we build our own?”
Typically, this question is asked of software and systems that are core operational for logistics. Further, this question is almost always one of degrees, because every company today has some system that is developed externally. For example, it is unlikely that a logistics company will develop an in-house peripheral system like payroll.
However, the lines get blurred a little when a decision needs to be made on what is “peripheral” vis-a-vis a logistics-related function like warehouse management, transport management, or core operations functions, and not an obvious one like payroll.
There is obviously no “right” answer to the underlying build or buy question that is applicable at all times and under all circumstances.
But these are the criteria that I have heard most cited as factors in analyzing build versus buy decisions from logistics companies over the years. These same questions have led to companies coming to different conclusions — there is no standard answer that seems to work for every case.
- Is the function that is being considered for new software a source of competitive advantage?
- What resources are available for the project, and after the project goes live?
- How much (or how little) change is required to existing processes as a result of the build versus buy decision?
- Does the future pace and direction of development need to be controlled?
- Can this process change be staged and does the decision to build or buy support the evolutionary or revolutionary nature of the process change?
- What is the ROI over short and long timeframes?
- What impact will be felt by customers during and after the transition?
- Is the ability to customize in the future essential to ongoing customer support?
As previously stated, logistics companies answer each question differently (and come to different conclusions on buying versus building even when the answer is the same).
Take this question, for example: What differentiates you and defines your competitive advantage?
Logistics companies choose to compete on many different dimensions — for example, by focusing on reducing risk and increasing compliance for their customers, delivering a high level of standardization in operations around the world, providing rapid and customized pricing, or one of many other value propositions. Keep in mind that one company’s “source of competitive advantage” could be another’s “necessary evil” function.
I have seen companies providing logistics solutions that view warehouse management as a source of competitive advantage, while other companies in direct competition, also providing logistics solutions, see warehouse management as a commodity function. Both these companies may be in the same space and both provide the same multiple functions in the broader logistics service delivery, but both could take a different view on which functions should be subject to internal development and which should be put on an off-the-shelf platform.
Additionally, it is vital to not just understand where the organization gets its current competitive advantage from, but also where the organization is positioning itself in the next 10 years or so in terms of competitive advantage to align with a decision to “make or buy.”
Once the decision on whether to build or buy is made, the divergence in the pathways to execution narrows between the approaches, at least at the point that the software is ready. Under-resourcing
the implementation of an off-the-shelf software system is as fatal as not allocating enough resources to a build strategy.
Implementing a new system (whether it is built internally or sourced from a vendor) starts with a functional requirement. These projects are not typically IT projects — they are organization-wide projects, and it is important to put together a cross-functional team with representation from business development, operations and finance functions.
Secondly, a separate project management role is essential. Note that larger organizations are able to dedicate a project manager — smaller organizations are less likely to do so but the key is the creation of the role itself. Project management is not the same as leading the implementation — it is a functional role that acts as “the bad guy” when bad news needs to be communicated.
Third, identification of interfaces and accounting for the rebuilding of interfaces between the system and external organizations is vital. Change management is hard enough on internal staff — taking vendors and customers through changes to company systems is even more challenging, largely because the change process needs to be transparent to those outside.
Even smaller organizations these days have at least some interfaces to carriers and customers that need re-building when an underlying system is changed.
The key takeaway is that regardless of whether a company’s decision on some software is to develop internally or to buy an off-the-shelf system, execution is a key determinant of success, with many similarities between both pathways in that regard.
Kewalram has spent decades developing freight forwarding and NVO information technology, and now provides systems consulting and training to logistics services providers. He can be reached by email.
This article was published in the May 2014 issue of American Shipper.