Should we develop our own Route Optimisation?
TLDR; Only build it if you
have over 1000 vehicles,
have a dedicated, internal, software development team with proven track record, and
are purely a logistics company.
I talk to a lot of large companies about Route Optimisation, because that's what we do at Tarot Analytics.
And one thing I often hear is that they are considering building their own Route Optimisation or Delivery Management platform.
However, for 90% of companies, building it yourself is the wrong decision.
Why? Lets dive in.
Share the cost
When you build your own platform, you pay 100% of costs for development, maintenance, hosting etc.
When you use a third party platform which is used by other companies, that same cost is shared by many companies, which means you pay far less in total.
New Features for Free
Since a third party platform is shared by many companies, whenever one company requests a new feature, it is usually made available to all other users.
This means, that the Christmas List feature that you hope to build internally in 3 years will probably be available this year in a shared platform.
Industry Best Practices
Part of the pain of working with a third party platform is that you sometimes have to adjust your operational processes to match it.
And trust me, we know how difficult it can be to change workflows in the enterprise world.
However, if that platform (after consulting with many companies in the industry) requires a specific workflow from you, it could be because that workflow is the industry best practice.
Route Optimisation is Hard
We've completely changed algorithm 3 times.
It's not that we didn't consider all the options up front - we did. But there's a lot of nuance and limitations of each algorithm, each programming language, and even each implementation.
And you can't just ask your normal developers to implement Route Optimisation. Operations Research is an extremely specialised field within computer science, with a very small number of specialists worldwide.
In our experience, most strong backend developers can get something up and running for standard problems using open source Route Optimisation libraries, but are quickly out of their depth if required to implement specialised, custom constraints.
Unfortunately for you, if you're trying to develop Route Optimisation in-house, it's probably because you have a lot of specialised, custom needs!
Software Projects are Hard
If you have an in-house software development team, this probably doesn't apply to you - your team already knows just how hard it is to build and maintain software!
However, many non-developers don't take into account a lot of the complexity of software development.
Even after the "product is finished", you're stuck managing databases, scaling, availability, deployments and security for as long as it lives.
And to really use route optimisation effectively, you need not only an algorithm, but also
a frontend so you can plan and visualise routes on a map,
a backend + database to store all the information, and
Android + iOS apps to enable real-time re-optimisation based on changes in the field.
It's harder than it looks!
Users Are Testers Too
With third party products, you share the burden of bugs with other companies.
You may have noticed that your in-house software has a lot of bugs. If it doesn't please tell me, I want to learn how you operate!
One reason for this is that your software is only used by your company. This means that there are fewer users to identify and report bugs, leading to
you being the one that discovers all the bugs, and therefore
longer lifetimes of bugs in the wild.
Return on Investment
The benefit of Route Optimisation differs based on each company's workflow and existing practices, but we often see
a 30% reduction in hours + kilometres driven and accordingly petrol consumption + CO2 emissions
a massive reduction in planning time and lost/late deliveries
a significant increase in operational visibility/reporting and end-customer satisfaction
Some of these things are difficult to quantify, but it's fair to say that they apply whether you chose to build in-house or use a third-party platform.
What differs is the cost.
We've spent 1M+ euros and 4+ years to build our full-featured, secure, stable, scalable, documented, highly available, resilient Route Optimisation and Delivery Management platform.
And that's with a team of optimisation specialists, expert software developers, testers and product managers dedicated solely to this product. Plus feedback from a diverse set of clients who shared industry best practices all along the way.
How much would it cost you to do the same?
How many vehicles, planners, trucks, deliveries, hours and kilometres do you need in order to get a return on your investment?
So why do many companies want to build their own?
There are a few reasons I hear a lot:
"We have very specific needs"
"We want all our systems integrated"
"We want to have the IP in-house"
The Real Reason that no-one ever mentions.
"We have very specific needs"
Actually, this is an important point.
Most off-the-shelf products will be able to handle most of your company's needs, since most companies do most things the same way.
But if a product cannot handle a critical use-case of yours, it prevents you from using the product at all, even if it addresses the other 90% of your needs.
When we realised this, we made it a core part of our offer:
our off-the-self product already addresses 90% of your needs (so you don't need to reinvent the wheel),
yet we regularly develop custom features for our clients. This includes workflows, optimisation constraints, integrations, access restrictions, etc.
"We want all our systems integrated"
I've seen hundreds of companies full of people switching between programs all day to do their job.
Dispatchers flicking from WMS to TMS to Google Maps all day.
Drivers opening one app for scanning, another for run-sheet, and another for navigation.
And if the driver is doing deliveries for several customers, probably they have a different set of apps for each client as well.
It's a nightmare.
But often, this happens because they're using tools which aren't built for enterprise.
As far as we're concerned, one key differentiator between SME and Enterprise software is the ability to seamlessly integrate with other systems.
Yes, that includes legacy systems.
Yes, that includes your weird Excel 97 format and that proprietary EDI format which used to be industry standard, but you had to modify it 73 times since then and didn't maintain any documentation.
No, you shouldn't have to export from one system, copy and paste excel sheets, and then upload to another.
But nonetheless, this is a legitimate concern.
It's the classic Best in Class vs Consolidated Convenience trade-off:
Should I have the perfect WMS, the perfect TMS, the perfect Route Optimisation, and switch between them? OR
Should I have one platform that does all of them reasonably well, but I don't have to switch, integrate, etc.
Actually, this is why we decided to increase the breadth of our offer. Originally, we just had an optimisation algorithm. Then we added (over the years)
an interface so you can use our platform to plan
proof of delivery
parcel-level barcode scanning
and a lot of other features so that dispatchers and drivers don't have to use multiple apps.
"We want to build the IP in-house"
If you are a software company, an algorithms company, or even a dedicated logistics company (where logistics services itself is your product), then it may make sense to invest the time and money to develop this Route Optimisation IP internally.
However, if you perform logistics incidentally to deliver your main product/service, then it's near impossible to create a software that works as well as a dedicated software provider.
It's not worth the price (in euros and in quality) to maintain the IP internally if this isn't the core of your business.
The Real Reason that no-one ever mentions
Pride and Politics
Let's start with pride. Everyone loves building their own stuff, and we always think it will better than anything that someone else has built.
Programmers call this cognitive bias NIH, and most new developers (and non-developers) fall into this trap.
Then there's Politics.
The Enterprise has a knack for creating perverse incentives, fuelled by next-year's budget, your colleague's bonus, that promotion you're expecting, your boss's ego, and all the mutual back-scratching that goes along with it.
This is the most common reason that we see an internal team push to develop an internal solution from scratch. And it saddens us, because we have seen unsuccessful outcomes almost every time.
Overall, it mostly comes down to one thing: staying focused.
Leave Route Optimisation to the experts and remain dedicated to your core business value, and we'll leave your core business to you!