The build versus buy conundrum is without doubt a big decision for any company looking to adopt a new piece of software; each route has its own merits and both will be a costly exercise so it’s very important to make the right decision.
Although packaged software has now been used for decades there are still many systems developed in-house, perhaps increasingly so now that development skills are on the increase and coding is getting easier and even being taught to children in schools. In fact, IT analyst IDC recently predicted that most of 2017’s IT spending will go on “application development and deployment.” However, by 2020 it expects software purchases to “edge out” app development costs as the largest spend. Clearly the balance is starting to shift with more skilled developers available to bolster in-house teams, but for the more complex applications such as the procurement arena, the jury is still out over the decision of whether to develop or buy.
Let’s imagine you’re a procurement professional and you’re looking to roll out an eProcurement system to help control your organization’s internal buying processes. You’re faced with the decision of asking the in-house development team to build it or to buy an off the shelf commercial solution. Which way do you turn?
Firstly let’s consider the build your own software scenario. If you’ve got a skilled and willing team at your disposal why wouldn’t you use them to build your bespoke software? On the face of it, it makes total sense to use internal resource and you can work closely with them to ensure it’s built to your exact specification and look and feel. It’ll also be great when it’s finished because as they’re the team that built it any deployment or technical issues can be dealt with by the same people.
Sounds ideal in theory, doesn’t it? However, procurement professionals face specific challenges when it comes to the whole source-to-contract process, from automating the eAuctions and eTendering process through to enabling slicker supplier sourcing and contract management practice. Is your software team able to create a bespoke application that can be optimized to provide this degree of functionality? Complex integration issues also need to be assessed, as seamless integration to back office and finance systems may also be a necessity.
Developing custom built systems without the experience of the wider supplier, customer and end-user community puts the in-house team at a distinct disadvantage and inevitably it’s only once the system has gone live that you come to realize the vital functions and features that have been missed.
And don’t underestimate the time or cost of a custom build. No matter how large your in-house development team, there is inevitably a tension between the available resource and the demands of the business on that resource, making it difficult to secure it in the first place and often impossible to guarantee for the lifetime of the entire project.
It’s not just resourcing the initial design, build and test and implementation that needs to be taken into account either. Without planned and allocated development headcount upgrades, patches and general maintenance could also suffer, before you even consider securing additional time and manpower for developing any future extensions and enhancements. And, in the event of a conflict with another part of the business, whose project will win — your procurement software deliverable or the need to perform critical maintenance work on your organization’s core finance system?
Off the shelf
The build your own scenario may not seem such a compelling choice now after all, so let’s consider the alternative. Technology across the source to pay lifecycle has evolved hugely in recent years and when you buy eProcurement software you invest in something that has been developed over millions of hours of aggregated expertise, driven by the feedback and input from procurement and finance professionals worldwide.
Today, software-as-a-service (SaaS) provides all development, hosting, support and maintenance costs in the “per seat” subscription fee model. And typically, any SaaS provider would ensure a prompt response to any technical issues that occur; whereby an in-house team would find this difficult to compete with, especially when they have a significant array of systems to manage and maintain.
Off-the-shelf eProcurement software is developed by teams that fully understand the sector and bring functionality that reflects a host of learnings from across the industry, often performing agile development cycles to keep the software ahead of its game and in line with carefully gathered and analyzed user feedback. It has also been tried and tested extensively with any glitches ironed out before it’s released to market.
Whichever route you choose, cost is most likely to be a major determining factor. Internal IT projects are typically re-charged against departmental budgets. While the argument might be made that this is a “sunk cost,” since the development team already works for the business, they nonetheless still represent a cost — and often a high one for the department who is being charged for the development, and it is rarely charged at a level calculated simply to cover any overheads.
What is more of a concern however is the project risk, both in terms of cost and timelines of in-house development for applications that are new to the business. In a build scenario there’s always the risk that the project will take longer than may have been first anticipated and could end up being far more costly to the business than investing in an off the shelf solution in the first place.
The route to getting the software that meets your exact business requirement can be complicated, but understanding the pros and cons of the build versus buy conundrum can certainly help justify the business case for whichever route you choose.
Published under license from ITProPortal.com, a Future plc Publication. All rights reserved.
Daniel Ball, director, Wax Digital.
Image Credit: Rafal Olechowski / Shutterstock