“I want a scalable product that meets customers’ specific needs” is one of the most common oxymorons of our time.
Unfortunately, you cannot have everything, and IT is no exception. It is the science in which the art of compromise applies more than any other.
There are applications, such as Software as a Service (Saas), in which the same functionality is delivered to several different customers, whose needs are fully satisfied by the functionality available and who are content to have nothing else outside the package of features they have purchased or subscribed to. In some extreme cases, they may at best be able to obtain a certain function with ad-hoc modifications for them.
Standardisation, areas of feasibility
For example, services of this kind can be those that enable the acquisition and analysis of data on user behaviour on social networks in terms of how many people talk about a certain topic and how they talk about it (so-called sentiment).
Every customer will search for different keywords, but everyone is interested in ‘how much’ and ‘how’.
In other cases, on the other hand, the requirements are heterogeneous and cannot be handled in a standard way without incurring a high loss of data quality.
Let us suppose, for example, that we are a tour operator and we have to manage different types of travel by several means: planes, trains, ships…
Each means has its peculiarities, for example:
- Air travel has no stops, but possible stopovers.
- The types of seats (economy, business…), vary for each company managing the trip but also for each specific trip itself
- Prerequisites such as documentation vary for each type of travel and destination.
- Purchase channels (web, physical, travel agency…)
- …
All these differences between potential customers mean that each software user will need access to customised functionalities to meet specific business needs. In a scenario like this, a well-standardised application will make it possible to handle 90% of the cases required by each customer without having to write more code or change settings, but there will come a point where, for the remaining 10%, it will be necessary to act, perhaps by modifying a large part of the code that all customers use, with the risk of regressions and a high impact on operations.
Standardisation, is there a risk of diminishing the quality of output?
At this point, every developer or software house is faced with a big question: do I accept customisations and therefore develop ad-hoc for at least a subset of customers, or do I stick to developments by providing a service that covers 90 per cent of requests and nothing more?
On the second option, it must be added that the remaining 10% can be the discriminating factor between ‘I ask others’ and ‘I’ll keep it that way for now.
This is a business choice before a technical one. One must properly analyse the risk/benefit ratio in sticking to standardisation.
Standardisation, the costs of a custom approach
Sometimes, at least for larger customers with highly complex requirements, it may make sense to think about customisation, but these should remain limited otherwise the costs of IT personnel and the time spent on maintenance of processes, which are no longer standard, are bound to increase exponentially.
The maintenance impact at the IT level is often underestimated by the business world, but it is a crucial aspect to pay attention to. Not least because the concept that software must be ‘cultivated’ and continuously monitored to perform satisfactorily must be promoted.
At Premoneo, we have chosen to look to those clients with specific needs who could not find adequate support in the areas of pricing, forecasting and segmentation in the software available on the market, offering cloud software developed ad hoc according to the needs of each, making the accuracy of the analyses and suggestions our strenght.
