Che tipo di criteri sono importanti da considerare quando si seleziona un pacchetto software COTS?
- Requisiti attuali: di cosa hai bisogno in questo momento? Quanta configurazione / personalizzazione sarebbe necessaria?
- Requisiti futuri: Cosa prevedi che avrai sicuramente bisogno in seguito? Qual è la roadmap del fornitore, inclusa la frequenza di rilascio? Quanto è costoso allontanarsi da questa tecnologia? Quanta influenza hai sulla tabella di marcia?,
- Implementabilità: quale piattaforma richiede? Quanto è difficile integrarsi con i sistemi esistenti? Ha problemi di ridimensionamento hardware? Ci sono singoli punti di fallimento?
- Supportabilità: cosa è disponibile in termini di formazione? Consulenza? Documentazione? Comunità? Quanto è stabile il venditore? Se il venditore è anche destinato ad essere un partner di integrazione, quanto sei allineato culturalmente?
- Costo: Quanto costerà implementare (licenza, hosting, personalizzazione), mantenere, aggiornare, modificare?,
- Deliverability: (se è richiesta una personalizzazione o una configurazione estesa) La personalizzazione verrà eseguita tramite API (buona) o dovrà essere eseguita modificando interni (cattivi)? Quanto è difficile testare il pacchetto (specialmente in modo automatizzato)? Quanto è difficile automatizzare l’installazione, la configurazione e le build (le procedure guidate sono cattive, le API con script sono buone)? Quanto è difficile impostare il controllo della versione particolarmente integrato con il sistema di gestione della configurazione esistente?,
Riduci il più possibile la personalizzazione, altrimenti sarai sopraffatto dal costo e dallo sforzo degli aggiornamenti.
Ciò suggerisce che è necessario modificare il processo aziendale in modo che corrisponda al pacchetto piuttosto che viceversa, il che a sua volta suggerisce che in genere non si dovrebbero considerare pacchetti per processi / capacità aziendali strategici. Ciò suggerisce anche che si desidera essere molto chiari e applicare i confini per evitare che le funzionalità dei pacchetti si insinuino in aree strategiche.
Solo perché il prodotto offre una funzionalità, non significa che dovresti accenderlo o usarlo.,
Secondo Capers Jones, con una personalizzazione del 25%, è più economico a lungo termine costruire un sistema personalizzato e la personalizzazione del 15% è un numero più sicuro da usare. Se il venditore è ostile, il numero scende al 5%.
La personalizzazione o la configurazione estesa evidenziano la necessità di deliverability.
Se il pacchetto è come un appliance (ad esempio, Microsoft Word), dovrebbe funzionare. La selezione iniziale e gli aggiornamenti potrebbero riguardare più test manuali e esplorativi., Tuttavia, una volta che iniziamo a introdurre la personalizzazione, l’importanza di essere in grado di impostare test automatizzati (così come altre funzionalità di sviluppo) cresce.
La configurazione, specialmente se estesa, non deve necessariamente essere trattata con meno rigore rispetto allo sviluppo personalizzato.
Soprattutto con i tipici pacchetti COTS in termini di CRM, ERP, finanziari, le opzioni principali tendono ad avere parità di funzionalità, il che significa che in genere dovresti concentrarti su altri aspetti.
Questo potrebbe essere l’allineamento del fornitore, la testabilità, la modificabilità, ecc.,
È meglio ridurre l’impegno che tentare di impegnarsi in una decisione perfettamente corretta.
Se il pacchetto non richiede tanto impegno (ad esempio, servizio ospitato), abbiamo mantenuto le opzioni per cambiare idea in seguito e non dobbiamo preoccuparci tanto di prendere una decisione ottimale in anticipo.
Non scegliere la tecnologia giusta. Scegliere la tecnologia che è più economico per allontanarsi da.,
Chris Matts
I fattori che aumentano l’impegno sono principalmente la dimensione dell’investimento iniziale e il costo della migrazione dei dati. La dimensione dell’investimento iniziale riguarda l’errore di costo affondato che lo rende un fattore psicologico/politico, non economico.
