Quali sono gli argomenti per i prodotti COTS (Commercial Off the shelf)?

Devo aggiungere agli aspetti positivi, i prodotti COTS (commerciali immediatamente disponibili in commercio) sono spesso progettati male e si comportano peggio. Sono progettati per vendere funzionalità come flessibilità, ma in genere nella mia esperienza usano il database in modo errato (spesso a causa dell'aderenza a SQL ANSI piuttosto che a SQL con prestazioni specifiche del database perché potrebbero avere un numero qualsiasi di database backend e generalmente con un design di database che mostra di non avere nessuno con esperienza nel database nel proprio team di progettazione) e sono performanti.

La flessibilità (che non viene quasi mai utilizzata in quanto è solitamente così difficile da fare e spesso richiede di pagare costosissimi appaltatori aziendali per poter vedere i campi aggiunti nei report, ecc.) solitamente ha un prezzo enorme tag in prestazioni, design scomodo e avversione generale. Questi prodotti non prendono quasi mai il tempo per definire correttamente i requisiti (affidandosi invece alla loro problematica "flessibilità") e quindi si ottiene un software di gestione del progetto che non ha nemmeno un campo per il cliente (quale azienda è abbastanza grande da richiedere un software di gestione dei progetti che i costi superiori a 100K non hanno client interni ed esterni da filtrare?) e altre sciocchezze.

L'ultimo prodotto COTS che abbiamo acquistato è stato così negativo che i nostri sviluppatori ci hanno offerto di aggiustare il nostro vecchio prodotto aziendale nel loro tempo libero per dargli quello che pensavano di ottenere (ma in realtà non lo erano) in questo costoso PM software che abbiamo comprato. Il 100% degli utenti di questo sistema lo odiava a causa del cattivo design e delle prestazioni peggiori. Non forniva a nessuno in azienda ciò di cui avevano bisogno in termini di rapporti o documentazione e non potevamo liberarci di questo pezzo di spazzatura perché avevamo speso troppi soldi su di esso. Ora disponiamo di una documentazione meno dettagliata del nostro processo di sviluppo e di ciò che facciamo quando il sistema impiega gli sviluppatori per implementare effettivamente e porta i manager in modo esponenziale più tempo a gestire.

Un altro prodotto COTS è stata la mia sfortuna nel sostenere che i call taker in un call center dovevano attendere minuti per passare alla schermata successiva mentre si parlava ai clienti già irritati (abbiamo gestito i reclami sui prodotti). I timeout erano così frequenti che non dovevamo nemmeno segnalarli più all'help desk.

Un altro prodotto COTS è stato creato da un'azienda francese e, anche se sembrava funzionare bene, la scrittura di report personalizzati era un vero e proprio lavoro divertente dal momento che lo schema del database era in francese anche se gli schermi degli utenti erano in inglese.

Poi c'era l'orribile prodotto HR COTS per fare i timesheet con quello che non riuscivamo nemmeno a far entrare le persone nei dati originali per capire come cambiare un supervisore quando la persona si spostava verso un nuovo capo o il vecchio lasciava. È stato piuttosto difficile ottenere il mio permesso approvato quando la persona che era due supervisori precedente alla mia attuale e che ha lasciato la società più di un anno fa è il mio approvatore e nessuno può capire come risolverlo. E l'altrettanto cattivo software di revisione delle prestazioni che ha perso le recensioni di metà anno e che non avrebbe stampato una versione in cui potevi vedere la tua valutazione su ogni oggetto accanto alla valutazione del tuo capo (chi vorrebbe vederle entrambe?) E quale no? in realtà dare abbastanza spazio per elencare le tue realizzazioni per l'anno (perché chiedermi cosa fossero se non posso elencarle?). Ovviamente quei prodotti HR erano così mal progettati che i nostri sviluppatori web stavano ridendo di loro quando eravamo addestrati su come usarli.

Non ho quasi mai usato un prodotto COTS in un'organizzazione aziendale che funzionasse bene o facesse il lavoro che avrebbe dovuto fare secondo il suo marketing. E ho visto molti di questi prodotti nel corso degli anni. L'eccezione sarebbero i prodotti di Red-Gate (ottimi prodotti e supporto stellare e no non lavoro per loro) e alcuni piccoli strumenti specializzati, ma mai una grande cosa di tipo enterprisy.

Reinventare la ruota (scrivendo la propria versione piuttosto che usare uno di questi prodotti) va bene quando la ruota è deformata e traballante per cominciare.

Non acquistare uno di questi prodotti senza un periodo di prova. Non puoi dire con che lavoro lavorare finché i tuoi utenti non tentano di usarli.

Se non è il core della tua attività, compralo. Non progettate e create i vostri computer, li comprate. Usa le tue risorse di sviluppo solo su qualcosa che ti farà guadagnare denaro. Una società produce un prodotto COTS perché questa è la sua competenza principale. Molto probabilmente, non è la tua esperienza di base e realizzerai qualcosa di qualità inferiore E più costoso.

L'unica eccezione sarebbe se c'è bisogno di qualcosa che non esiste. Se poi ti impegni a crearlo, fallo con l'idea che, se ti è utile, potrebbe essere utile a qualcun altro. Producilo!

Pro

• Il costo di sviluppo è generalmente inferiore. (Se il prodotto è utilizzato da molte persone, allora la società che produce il prodotto può probabilmente permettersi molti più sviluppatori e può estrarre molte più funzionalità che sono più ben collaudate di quanto si possa fare con il proprio team di sviluppo allo stesso prezzo)
• Il costo del supporto e della manutenzione è generalmente inferiore
• Con le nuove versioni del prodotto COTS, puoi "automaticamente" dare ai tuoi utenti nuove funzionalità senza molto lavoro (lo paghi comunque, naturalmente, ma il costo è distribuito su tutti gli acquirenti del prodotto COTS.
• Altri utenti, oltre a te, stanno utilizzando il prodotto e danno feedback. Ciò generalmente si traduce in un prodotto più solido.

Se vuoi leggere un articolo accademico peer-reviewed sull'argomento, prova qui .

CONS

• Con i prodotti COTS, potresti pagare per funzionalità che non utilizzerai mai.
• Le applicazioni COT potrebbero non fornire tutte le funzionalità di cui hai bisogno e potrebbero comunque richiedere lo sviluppo di 'plugin' personalizzati.
• L'integrazione di applicazioni COTS con applicazioni esistenti potrebbe essere difficile e costosa. L'integrazione può anche richiedere sviluppatori specializzati (che di solito si traducono in costosi)
• Il supporto COTS potrebbe essere limitato e potrebbe risultare costoso per le grandi aziende (o installazioni complesse). Alcune aziende optano per il supporto interno, ma ciò potrebbe richiedere ancora un addestramento speciale.
• La maggior parte delle applicazioni COTS sono pensate per un pubblico più vasto. Ciò significa che in genere le applicazioni richiedono la configurazione prima di metterle in produzione. A seconda della complessità, la configu razione potrebbe essere dispendiosa se gli appaltatori sono richiesti.

Prima di intraprendere qualsiasi progetto, le aziende dovrebbero prima vedere se ci sono prodotti COTS che soddisfano i requisiti. Sia i pro che i contro devono essere valutati prima di scegliere uno sviluppo interno o un acquisto personalizzato (COTS).

Quando le aziende devono risolvere un problema, iniziano con l'ovvia decisione "costruire contro comprare". A volte vale la pena di costruire una soluzione e molte volte è necessaria una soluzione ibrida. Raramente una grande azienda costruisce da zero un importante software, a meno che non sia il loro core business.

Ciò implica che l'acquisto di COTS è molto più alto del valore in dollari per le licenze. Non è inimmaginabile acquistare qualcosa di costoso come SAP, e spendere altri $ 25.000 USD per personalizzarlo perché ha esigenze di business critiche. Lo sviluppo di un sistema con lo stesso livello di stabilità e sicurezza delle transazioni probabilmente farà impallidire i costi di acquisto della soluzione pronta e di personalizzazione.

Quando prendi una decisione di acquisto o di acquisto, una cosa da considerare è che hai il talento in-house?

Prendi in considerazione un pacchetto di statistiche, ad esempio. Un pacchetto come SPSS o SAS è stato sviluppato nel corso di molti anni, utilizzato da molti clienti e progettato e verificato da più statistici di dottorato.

Se la tua azienda ha bisogno di un pacchetto di statistiche, hai personale di dottorato di statistica sul personale per verificare l'accuratezza dei calcoli che programmi?

Sulla base dell'esperienza, in particolare con una piattaforma come ERP, che le aziende usano per gestire la loro attività, è veloce per la Management andare sulla piattaforma ERP COTS piuttosto che guardare effettivamente ciò che è già funzionante, attualmente in uso o guardare su altre piattaforme open source che hanno una struttura di supporto di grandi dimensioni e successivi. Detesto nominare i prodotti qui, ma se qualcuno che conosce piattaforme ERP, sa di quale prodotto ERP di cui sto parlando.

Vedo le implementazioni top down e le decisioni prese, in cui agli utenti viene detto che l'acquisto è una decisione di gestione, che tutti dovranno collaborare e che la società ha già investito troppo in esso. Hai mai sentito parlare di cigni neri?

I grandi ERP commerciali sono presentati come flessibili e modificabili per il tuo processo aziendale. Ti viene dato il consueto periodo di tempo di 6 mesi per l'implementazione e un anno dopo sei ancora in modalità di implementazione. Gli utenti la odiano, ricrea i flussi di lavoro ei dipartimenti devono spendere tonnellate di tempo e denaro per riadattare gli utenti sui nuovi flussi di lavoro. Quando non è in vigore entro sei mesi, viene investito più denaro e più appaltatori vengono assunti per lavorare su questioni che avrebbero dovuto essere identificate se avessero adottato l'approccio dal basso verso l'alto.

Ascolta i tuoi utenti, adatta i flussi di lavoro correnti ai tuoi moduli ERP invece di dire semplicemente che funziona come "ERP". Vietare che qualsiasi modifica sia richiesta sul modulo, di solito significa più tempo e denaro. Ti danno sempre la stessa vecchia risposta.

Lavoro in un gruppo di supporto e il nostro obiettivo sono i nostri clienti. Abbiamo degli SLA che dobbiamo soddisfare e l'ultima cosa di cui abbiamo bisogno è una piattaforma di supporto che crei più problemi rispetto al problema del supporto reale. Tutto dovrebbe essere progettato per garantire che soddisfiamo i nostri SLA, ma il cambiamento diventa allora che l'azienda si focalizza internamente piuttosto che all'esterno, osservando le esigenze dei nostri clienti. Il personale di supporto impiega troppo tempo per assicurarsi che ogni ordine di lavoro o ticket sia compilato in un modo specifico anziché avere uno strumento per documentare in che modo è stato ricevuto, risolto e risolto il problema del cliente.

Quindi, se viene chiesto se preferisco COTS in casa? Vorrei selezionare i prodotti COTS con un buon riscontro da parte degli utenti, ma pensarci davvero se dovesse gestire tutta la mia attività. Entrambi hanno pro e contro come supporto, flessibilità, integrazione del sistema, aggiornamenti e patch e altri sviluppi di crescita del sistema.