Photo by Clément H on Unsplash
It used to be the case that you could predict, based on what industry a company was in, what the software suite was that they used. For example, if you would pass past a printing company, you could bet money on them using QuarkXPress or InDesign (also dependant on the year you would make this guess). Or if it were an accounting firm, it would have been Sage 9 out of 10 times.
Nowadays we live in a world of constant interconnectivity and a myriad of data streams we need to manage, combine and analyze. The sheer number of software tools at our disposal, especially with the explosion of software as a service (SaaS) solutions, the options seem endless. Because of this, with a solution to almost every problem, we have been designing software around or work processes rather than the other way around. In most cases, this has been liberating and led to efficiency gains we could not have achieved otherwise when we were locked into specific solutions. However, with the wide, almost endless, range of options comes a whole new set of problems, such as the lack of transparency on selecting the right tool for the job, the unpredictability of a tool receiving continuous support (what appears quickly could also disappear as rapidly) and the support you might receive from software developers.
It’s not uncommon that we start deploying different tools for individual stages of our work processes, that might work well when first designed, but are fragile, to say the least. One tool becoming unresponsive can be utterly disruptive for the entire process. As we fragment services more and more, we run the risks of creating complex ecosystems of tools that are extremely dependant on each other.
Let’s assume you sell shoes via your webshop. You have stock but also an agreement with a supplier to place backorders directly. This is a classic example of extract, transform and load (ETL). Say you have two tools for extraction of data. One is an API connector that connects to your supplier via a web service (to manage backorders), and one is a tool that grabs data from your ERP solution (your actual inventory). Call these two tools A and B. The two data streams are slightly different, as they usually are, and you have brought in tool C to transform and manipulate the data streams in such a way they can be combined. Finally, you need tool D to load this uniform data stream into your system (your CMS for example), so it can be read and worked with.
In this example, you can see that if any of the tools stop working, the whole process grinds to a halt. Some tools might just eliminate functionality (backorder capability via supplier API), others just stop the business (inventory, combining data, populating CMS). Especially when you are relying on free tools that are created by one-man bands, you run the risk that one single update will make the whole tool obsolete.
When selecting software tools, one should always consider continuity and support, and in most cases make contingency plans of when a tool catastrophically fails. SaaS solutions, free software tools are great for rapid prototyping, but less suitable to build your core business around or have core business processes be reliant on.
Some companies would choose to have a complete ERP solution developed, albeit on larger platforms such as SAP or Oracle. If you have the resources and capital expenditure to do so, that might be a solution. With a proper ERP development usually comes training, support and the guarantee of continuity (against a price). For most smaller to medium-sized businesses, this will be out of reach. The cost of (Western) software developers, project managers, onsite teams will run the bill up high very rapidly, not even considering licensing costs.
What a lot of smaller businesses do fed up with just piecing together software tool off the shelf, is to consider offshore software development, for example with companies such as FullScale.io. You get all the benefits of having the quality of Western software development such as project management, quality of communications and expectation management, without some of the pitfalls associated with offshore development, such as miscommunication due to language barriers, frustration at not getting responses and missing deadlines. By providing you the best of both worlds, you can get the expected service against a sharper price. And price matters, as after all the development you will still need resources to train people and embed software into core business processes properly.
