Shrouded in myths

The software landscape has changed fundamentally in the past 20 years. What has not changed, however, is the question of whether to opt for individually developed software or whether a standard solution would ultimately be a better fit for the company’s business processes. On the one hand, our blog post on the advantages and disadvantages of standard and individual software addresses these and other questions.

In this article we want to address some persistent myths that surround individual software, but also standard software. Some of these myths hold some truth, while others should finally be put into perspective.

Myth 1: Standard software is usually based on (or even defines) a range of company or industry standards. Companies benefit the most from this.

Defined company or industry standards offer a good basis and provide orientation. However, they are intended for the general public. They therefore have to cover a lot and are based on the average. The crucial question in this respect is whether a company is basing its products on the average or whether it would rather stand out on the market. Among other things, this depends on the strategic relevance of the use case. To stand out strategically in an area, individually developed digital processes can offer a significant business advantage. At the same time, standard software can be used effectively in other areas of the company – where the company does not want or need to differentiate itself. This is typically the case with ERP, accounting software or with HR solutions.

Conclusion: Where strategic differentiation is needed, individual software can be the right choice. In some other areas, companies generally benefit from existing solutions.

Myth 2: Standard software reduces dependency on software engineers. This is because the supplier ensures that its customers are never affected by a shortage of skilled workers.

Dependencies always exist – regardless which variant is chosen. In the case of developing individual software, a company is reliant on good software developers and is therefore exposed to a shortage of skilled workers. With standard software, on the other hand, a company is dependent on the supplier and, for example, the supplier’s schedule for updates and upgrades. In addition, it is not always possible to use standard software out of the box. Customising and operation and maintenance of the software likewise require specialists with the relevant know-how.

Conclusion: If individual software is developed that works with commonplace and widespread technologies (e.g. .NET, Java, etc.), it can be easier to find the necessary specialists and service providers. However, this should not be the deciding factor in choosing a strategy.

Myth 3: Standard software forces companies to make processes more efficient and streamlined. There is a risk with an individual development that the result will be a one-size-fits-all solution that does not offer any real added value.

The risk of high costs arises, in particular, if software that has not undergone any enhancements in a long time is to be modernised. Accordingly, customising standard software is a process that can also get out of hand and become expensive. In deciding which strategy to follow, the best preparation is therefore often to perform an in-depth analysis or seek the advice of specialists. Basic questions provide insight into the course of action: Should the software be adapted to the internal processes? Or does the software specify how the business processes are to be handled internally?

Conclusion: To find basic strategies such as “Processes follow Software” or “Software follows Processes”, appropriate procedures and methodologies are needed that aim to optimise value. In terms of developing individual software, consultancy takes centre stage, so that changes to the business processes can be anticipated as quickly as possible.

Myth 4: Standard software is the cheaper solution when calculated over several years.

This argument is often quoted as the main reason for using standard software. However, the initial costs for purchasing and licensing standard software may be higher than for developing individual software. In contrast, individually developed solutions are often associated with higher costs for maintenance (for example, adjustments to new operating systems) and for enhancements.

What is often overlooked in this appraisal are, on the one hand, the opportunity costs and unexpected costs for customising the standard software. By using software that is not tailored optimally to the requirements and processes in the company, opportunity costs are often difficult to measure. This means more effort for the employees – for example, owing to training, longer lead times or qualitative defects. That is not to say that costs for maintenance and enhancements do not also arise with individual software. Only the individual calculation therefore determines the best approach.

Conclusion: As with point 3, weighing up which strategy is being pursued is important for assessing the costs. The costs vary depending on the use case.

Myth 5: Financially attractive Software-as-a-Service models (SaaS) only exist for standard software.

SaaS offers the possibility of a more interesting cost structure (variable licence costs, pay-as-you-go, etc.). This approach is not restricted, however, to standard solutions. There is potential for flexible solutions from the cloud even with individually developed solutions. While individual developments usually involve investment costs, operation based on cloud solutions, in particular, can now also be designed very flexibly and based on use.

Conclusion: The development alone is not enough. Operation, adaptation and enhanced development likewise require support from specialists and the necessary flexibility. Opportunities to benefit from SaaS models also exist for individual software.

Naturally, both individual and standard software have their raison d’être. What is important is to weigh up the options fundamentally before actual use. bbv offers companies consultancy and customising for software at different levels of individuality. In this way, the right approach can be found for every application.