Why choose a WMS vendor rather than writing your own?
James Wilmer MCIEx
Sales, ERP, FI, Supply Chain and SaaS specialist £130m+ in new sales, High selling novelist & multiple poet laureat finalist. Record breaking. Also qualified in tech (up to coding), sales MEDDPICC, SPIN etc.
The usual suspect
(Updated 12/04/2019)
Most organizations that have a stock-holding will look at bringing in a new WMS, or as they grow looking at a more comprehensive one that grows with their needs more than their current system. One thing that seems to happen time and time again in this process (as it did when I was an IT Manager and Programmer over two decades ago) is that the IT department or a manger internally will suggest writing your own system. While I see the benefits on paper to writing your own system as everybody is convinced their operation works differently to other businesses, so a self-written system will fit better this ignores several conditions.
1: Best practice. The system should not be made to fit the process in every case. Best practice is usually best practice for a reason and fitting system to processes doesn’t enforce or encourage the industry accepted benefits best practice can bring. Particularly as industry is moving more and more to cloud based variations now, as it natively incorporates Disaster Recovery, automatic updating etc.
2: Amount of code. Where I have been in-to many hundreds of businesses in my career, even the most diverse stockholder will run 90% of the standard processes without even realizing it, meaning that there is only a 10% divergence – this usually being around process like returns, cross-docking, stock segregation, visibility to third party systems and eCommerce (along with several similar examples). This being the case we are usually talking about configuration within commercial WMS systems as opposed to writing code. Even where new code specific for the business may need to be written it will usually sit at around 2-5% of the total system. This being the case it’s much easier to have somebody write 2-5% of a system than 100%.
3: Risk ownership. Internal development puts all the risk and therefore insured liability on the company. Having previously been involved in risk strategy and disaster recovery at a high level I am aware of many cases that a failing IT system has brought down businesses (I can provide examples if needed). There is usually a cap on damages within an insurance policy and if a business is not trading for more than a month or loses the ability to trade with certain partners the costs can quickly exceed an insured policy amount. By going with an external WMS provider, they will also carry insurance and by the nature of previous successful implementations (your due diligence should always include thoroughly doing reference visits) risk will be mitigated.
4: Links to third party software. While with most big ERP and third-party systems using clearly open data exchange formats like XML or flat files, transported by Web Services or FTP / SFTP this means writing the interactions isn’t as hard as it used to be, however most WMS providers have probably already done the integrations to ERP, couriers, Magento etc. so there is no extra work/ or less to do.
5: Lack of control or structural stability? IT departments often like the idea of writing their own systems as it feels you can touch every part of a system and move it around and rewrite as needed. As anybody who has done an ERP or WMS implementation before knows there are good reasons that this should not happen. By changing any one element of the software structure the whole system needs testing again (with 2/3 stage testing), however even then it is testing the software element and not necessarily the Operational element. The technologist’s businesses employ to write their software are not necessarily Warehouse operational experts (they are usually totally different skillsets than just coders), this being the case operational reduction usually creeps in over time the more structural changes are made. WMS providers will test and plan the whole systems based on these tested in multiple environments which don’t just look at localized conditions and are tested and coproduced by warehousing experts. This leads to a less and less effective system holistically for every additional or benefit the self-written coders add.
6: New technology. As new technology is added by your business your internal developers need to add bridging technology (which sometimes needs to be certified) to add the extra functionality it will bring. Most WMS providers will probably have these interfaces already written so there is no extra work (if it’s even possible to do internally based on resource and relationship with the automation provider). A good example might be adding Qubiscan or conveyors.
7: Upfront and ongoing cost. A WMS for a £10-200 million-pound turnover business will probably involve an upfront cost of around £100k-250k depending on complexity and integration, ongoing costs vary depending on who you choose to go with. From a purely cost basis a WMS vendor usually works out much better value than self-written.
8: Timescales. The recognized average timescales for WMS implementations of a business between £10-200 million turnover is between 4-12 months (dependent on a lot of factors, including busy periods, 3 lots of testing and training). As a developer I can tell you that to write a basic system would be the top end of that with testing which would then roll over to ongoing work and development (I would probably expect it to be more like 24 months to do reasonably with a couple of developers solidly on it and working to a recognized methodology and PPM).
One other thing that I should mention and is becoming more and more prevalent in self written systems is; Big WMS providers like Snapfulfil are often being asked to provide quick/ easy implementations for smaller DCs where a large Self-written system or even Manhattan or/Red Prairie are used at a main site. It's due to the cost and timescales, particularly at how simple it is with open architecture to work with a multi-provider approach. If you want to know more how this could work for you drop me a mail on [email protected].
This being the case unfortunately as somebody who was a developer and implementer to blue chips and SME’s I cannot recognize a case where self-developed systems can in anyway be justified over WMS vendor versions (the shared testing and cost of ownership alone make it invalid, as well as the benefits of historical improvement and testing).