Se ştie că unii dezvoltatori gândesc un produs software să soluţioneze o problemă în toată complexitatea ei. Clienţii sunt cei care-şi dau seama că unele aspecte nu le sunt necesare şi de aceea ar prefera ca respectivele aspecte nici să nu fie cuprinse în produsul software pe care-l achiziţionează. Să ne imaginăm că cineva vrea să cumpere un ERP pentru:
- gestiunea resursei umane,
- gestiunea contractelor,
- gestiunea livrărilor,
fără a avea nevoie de componentele de ordonanţare a producţiei şi de optimizare a stocurilor sau de cele destinate analizelor statistice pentru randamente.
Dacă acel ERP este creat customizabil, la achiziţionare clientul va spune ce-l interesează şi i se va genera automat varianta de produs software care execută doar ceea ce-l interesează. Administratorul de variante va da valori pentru o serie de parametrii şi automat se va genera varianta care se potriveşte obiectivelor clientului sau mai corect, varianta cea mai apropiată de exigenţele acestuia, căci varianta care i se potriveşte 100% este foarte dificil de obţinut, datorită unor restricţii de structurare a produsului, care ţin seama de dependenţele dintre funcţiile de prelucrare.
Se va obţine un produs care:
- va avea toate funcţiile activate de client,
- ocupă cu mult mai puţine resurse,
- costă ceva mai ieftin,
- are gradul de utilizare a câmpurilor în bazele de date foarte ridicat.
Dacă produsul software nu este customizabil, clientul va plăti componente pe care nu le activează niciodată. Dacă este un produs rigid, clientul va întâmpina dificultăţi în încărcarea bazelor de date cu valori pe care nu le va folosi niciodată.
Trebuie spus că a face un produs software customizabil nu este o treabă uşoară. Se studiază grupul ţintă şi structurarea produsului se face dacă şi numai adcă numărul de utilizatori total diferiţi este suficient de mare ca să se justifice efortul.