In every application environment, even if with different intensity, the software customization is a very diffused phenomenon which increases costs, lengthens the realization times, compromises the quality and complicate the software management.
Many are the reasons and I would highlight the most important ones while sharing some reflections.
- The software does not include a function or information. It can depend on a poor analysis and in this case the development will enrich the product; or may be a particular need which, once satisfied will remain specific and delimited (circumscribed).
- The software includes a function or information which result different from what needed – such as free text field instead of structured data or vice-versa. In this case the valuation is often individual and conditioned by different factors such as the usability, the routine, the aim for collecting data.
- The software includes a function or manages a process in a way different from the customer’s one. In my experience, the request of the health organization in this case is to adapt the software instead of modifying the process, also when a digital transformation of a previous paper-managed process is on course.
- The software manages a lot of information, often deriving from different customizations, and is judged too complicate; in this case the request is to simplify forms and functions. The problem increases when the customization was faced in a unparametric or unengineered way (additive customization).
- The software manages information that, in the particular context of the healthcare organization, are unavailable, making it necessary workaround to bypass the problem. Also in this case the customization impact depends on software engineering and if that has been foreseen when designed.
- The software user interface is not completely accepted by the users who want to make some changes to the graphic look. Sometimes those requests are justified and aimed to ameliorate the usability, while other requests seem to be very individual and erroneous.
- There are some devices characteristics, such as the monitor resolution, the installed operating systems, the database, the employment of mobile devices which do not conciliate or are in conflict with the software. As per the previous point, this kind of modifications / customizations can result very complex and onerous, so often they are not made.
- The software operates with peripheral devices as printer, barcode readers and others which are not supported and cannot be replaced. Also in this case the customization impact strongly depends on the software architecture.
- The software has to be integrated with other systems. If the software is not based on a service architecture and does not foresee an integration middleware, this activity can result very complex and onerous.
- The software should be compliant to local or regional rules. Is the software was not designed to manage this problem, the implementation of new functionalities or the management of additional information can result very complex and considerably impact on the software, often upsetting it.
When the parametrization is not enough to satisfy the above mentioned requests, or the engineering is not able to adapt the software, then code-embedded modifications are used, determining the creation of a new software generated from the original one, so becoming a semi-worked tool to start realizing the solutions for the customer.
Such approach presents several negative aspects, requiring resources for the development; increasing the costs, lengthening the realization times; compromising the quality and implying many tests and verifications. The future software management is compromised, becoming an “ad-hoc” solutions, difficult and costly to maintain and evolve.
There is another aspect this approach can cause: the supplier does not feel responsible for limited investment in analysis and research when designing functionalities and processes, since the customers will dictate rules and requisites of the software. From an economic point of view this activity will be more expensive than selling software licences and related services.
The software value so becomes secondary to the detriment of configuration and customization activities, which are generally captive, due to a mechanism of lock-in that imposes on customer, during the entire software life, the choose of the supplier winning the tender maybe marking down the cost of software licences.
This approach is uneconomical generating inefficiency and a certain level of unsatisfaction among the users, either the health organizations and the suppliers; those ones will obtain very low margins from a series of unrepeatable activities, often at low price.
This is the reason why in healthcare, like in other sectors already happened, we need to go beyond the logic of “custom-made dress” in favor of products which in certain cases could be certified as IIA medical devices.
To obtain this result a real cultural revolution is needed: either users and suppliers are called to review their business approach, the type of professional resources to engage and the level of investment for realizing new products.