Thursday, July 15, 2010

Per l'acquisto? O per costruire? Questo è il problema!

Quindi, avete individuato l'esigenza che nella vostra azienda per la quale si ritiene sarebbe un ottimo candidato per una soluzione software.

Ora la domanda è ...

Avete "run off" e ad impegnarsi (uno o più) agli sviluppatori di creare questo software di sistema (s) per voi?

E / o ...

Avete "scappare" al "più vicino" e / o il vostro preferito negozio di software e compra un on-/off-line commerciale-off-the-shelf (COTS) soluzioni a pacchetto, e se sì quale?, Per soddisfare tali esigenze di business?

Quale di queste alternative è la più efficiente e (globale) soluzione redditizia per soddisfare le vostre esigenze di business il più presto possibile?

Questo è "The Question"!, Di comprare? oppure costruire?, no?

Avere la risposta a questa domanda è in realtà non così difficile come si potrebbe immaginare! ;)

Tutto quello che dovete fare è eseguire un "Buy vs Build" analisi e / o un processo software di selezione per il tipo di (s) di software che soddisfano le esigenze di business della tua e ha scelto i migliori, più efficienti e (globale) conveniente soluzione, giusto?

Il "Big Boys", grandi aziende e imprese, spesso si esibiscono, e / o consulenti di impegnarsi a svolgere, una "analisi formale" Buy vs costruire e / o di un processo di selezione del software su molte a tutti i loro acquisti di software significativi.

Si dovrebbe eseguire uno "Buy vs Build" analisi e / o di uno processo di software di selezione, per ogni acquisto di software significant, before si decide se sarebbe essere più efficiente ed economico, nel lungo termine, a creare una domanda "from scratch "vs comprare un COTS (Commercial-off-the-shelf) pacchetto, e se sì, quale sarà meglio misura i vostri bisogni attuali e futuri!

Questo può risparmiare una notevole quantità di denaro, tempo, fatica e mal di testa * * sia il breve che nel lungo termine!

Altrimenti, si può finire per pagare di ricreare "la ruota (s)", che in realtà non ha senso, vero?, E quindi nessuno di noi vuole fare, vero?

Oppure ...

L'acquisto di un pacchetto solo per scoprire che non lo fa (e forse non può) rispondere alle vostre esigenze e / o il costo di modificare tale pacchetto per soddisfare le vostre esigenze è proibitivo, in cui entrambi i casi è molto probabile che "ritagli" questo pacchetto (ora in avanti "shelfware"), che hai appena comprato e pagato, e scegliere o costruire un altro e, eventualmente, ripetere tutto questo (costoso) ciclo di nuovo, sai?

Noi non abbiamo il lusso di entrare in dettaglio su entrambi come eseguire una "analisi formale" Buy vs Build, perché ciò richiederebbe discussioni estesa di come definire, analizzare e estimate progetti di sviluppo software per i quali vi sono molti libri su queste soggetti, e / o come eseguire un formale processo di selezione del software, in quanto questo è un argomento per il quale Metodologie tutto sono stati sviluppati e vengono utilizzati (lo so, come ho collaborato allo sviluppo iniziale e utilizzato solo come un software di selezione Metodologia per uno delle più grandi società di software a livello mondiale e dei servizi;)).

Noi, però, in questo articolo, tentativo di delineare alcuni dei fattori che dovreste considerare quando si esegue proprio "Buy vs Build" la tua analisi e / o software di processo di selezione (es) per lei.

In primo luogo, in entrambi i casi sarà necessario definire (e priorità), i requisiti / criteri di selezione che si può valutare come ciascuna di queste "Buy vs Build" alternative soddisferà le vostre esigenze aziendali immediate ed a lungo termine, giusto?

Inoltre, nel corso di questi processi, si vuole assicurare che si confrontano queste opzioni in termini di "mele alle mele", sai?

Pertanto, mi consiglia di confrontare i due (/ tutti) di queste opzioni in termini (del "total cost of ownership"), compreso il tempo totale e il costo per ottenere l'applicazione in produzione e / o di mercato e il costo totale del sostegno e di mantenere la domanda per la sua durata di vita prevista.

La "formalità" con cui si esegue questi processi dovrebbero essere proporzionati al vostro investimento (in termini di lungo termine / "total cost of ownership") del ricorso e la sua criticità nella vostra azienda.

In primo luogo, prendiamo in considerazione l'opzione "Build.

Alcuni dei vantaggi della "Build includere l'opzione":

1) Si ottiene un'applicazione appositamente sviluppata per soddisfare i requisiti aziendali / esigenze e progettati per soddisfare i vostri processi di business specifici.

2) E 'più probabile che si sarà in grado di adattare il proprio software di sistema (s) a cambiamenti nel vostro business needs e / o processi, come ci si sia presumibilmente avere l'applicazione originaria del codice e / o l'accesso al sviluppatori original of esso , giusto?

3) Si può sviluppare la tua nuova applicazione (s) per l'interfaccia e "giocare bene" con gli altri software nella propria architettura applicazione generale.

Alcuni degli svantaggi del "Build includere l'opzione":

1) La durata del progetto tipico, dal concepimento alla produzione (/ mercato), attraverso il ciclo completo di vita di sviluppo del software, per un'applicazione personalizzata sviluppati possono essere notevolmente più lungo che per implementare una soluzione package.

2) I costi di sviluppo iniziale di produrre la prima versione (s) di your applicazione (s), compresa la documentazione associati e materiali di formazione, sono in genere superiori a quelli degli purchasing uno soluzione pacchetto.

Brevemente qui sono solo alcuni dei fattori aggiuntivi che, IMHO (a mio modesto parere), si potrebbe prendere in considerazione per determinare se o non è meglio di "costruire" una domanda "da" zero, tra cui:

1) Oltre alla stima "" tempo di codifica e di costo, assicurarsi di considerare anche tutto il tempo e costi possibili per completare la definizione, l'analisi e le fasi di progettazione, prima di "codifica", e il collaudo subsequent e le fasi di attuazione richiesto per completare il ciclo di sviluppo del software globale per voi vita dell'applicazione.

2) Avete in programma per la gestione del progetto e team di progetto (s), te stesso? E / o pensate di "esternalizzare parte a tutti la gestione del vostro progetto? Quali sono i costi in termini di tempo, energie e denaro per ciascuna di queste alternative? Quale di queste alternative ha dei rischi minimi per il positivo completamento del progetto di sviluppo di applicazioni?, Queste sono considerazioni * * importante in quanto non per completare lo sviluppo della vostra applicazione (s) può rendere tale opzione molto costoso!

3) Quali sono i costi - tempo, fatica e / o soldi - a sviluppare anche la documentazione e la formazione (se applicabile) per la vostra applicazione (s)?

4) Come pensate di sostenere l'applicazione sviluppata (s)? Con la formazione "in house" al personale di sostegno? E / o coinvolgente sviluppatori esterni e / o personale di sostegno?

5) Come pensa di gestire la manutenzione su questa nuova applicazione (s)? Avete il codice sorgente? Avete intenzione di gestire la manutenzione futura te / "in casa"? e / o Avete intenzione di coinvolgere il team originale di sviluppo (ammesso che sono disposti e disponibili) per effettuare eventuali integrazioni e / o futura delle modifiche al sistema (s)? Se è così avete negoziato / "dentro" un tasso per questi sforzi di manutenzione futuro?

Etc. Etc.

Ora, vediamo l'opzione "Acquista".

Alcuni dei vantaggi della "opzione" Acquista includono:

1) Il tempo per ottenere una soluzione pacchetto implementato such that si può iniziare con essa e raccogliendo i frutti corrispondenti per il vostro business è typically più veloce di quello per costruire l'applicazione "da zero".

2) Il prezzo di acquisto iniziale di un pacchetto software, anche se può essere considerevole, è spesso inferiore a quella (iniziale) i costi di sviluppo personalizzati.

3) il fornitore di software può fornire una manutenzione regolare per gli aggiornamenti del pacchetto software, tra cui una serie di "bug fix" e / o miglioramenti, il che può essere visualizzato per un "canone di manutenzione fissi" in modo tale che non si devono sostenere i costi di tutti questi "bug fix" e miglioramenti da solo.

Alcuni degli svantaggi di l'opzione "Acquista includono:

1) Un pacchetto di lettini per bambini non può soddisfare tutte le vostre esigenze di business / bisogni e non il tuo business specifici processi bene "out of the box". Il fornitore di software può o non può essere disposto e in grado di modificare il pacchetto per soddisfare meglio le vostre esigenze aziendali e / o processi e anche se è così, questo può essere costoso.

2) Un pacchetto software può essere meno in grado di adattarsi rapidamente ai cambiamenti nelle vostre esigenze di business e / o processi. Potrebbe essere necessario attendere la release di manutenzione successiva del venditore per ottenere il changes desiderato o si potrebbe dover pagare il fornitore per apportare queste modifiche specifically just per te e aspettare che, o non può essere disposta (e / o able ) per apportare queste modifiche al loro pacchetto software per te a tutti.

Brevemente qui sono solo alcuni dei fattori the supplementari che, IMHO, si consiglia di considerare nella valutazione e selezione soluzione di uno dei pacchetti (s), come parte of your "opzioni Buy", compresi:

1) Qual è il tempo e spese aggiuntive, se è anche possibile / un'opzione, di modificare il pacchetto per soddisfare le vostre attuali esigenze / bisogni? Una "regola generale" Ho utilizzato nel corso degli anni è che ... Se è necessario modificare il 50% o più del "codice" per renderlo soddisfare le vostre esigenze, poi si sono probabilmente meglio riscriverlo da zero ", sai?

2) E 'gestibile?
Significato, vi, il fornitore e / o gli sviluppatori si coinvolgere in grado di modificare il pacchetto per soddisfare eventuali cambiamenti dello stato attuale e / o future esigenze / bisogni? Se no, allora questo pacchetto può diventare "shelfware" dovrebbe esigenze cambiano ad un certo punto, sai?

3) Come si comporta la integrano e / o "giocare bene" con le altre applicazioni in architettura dell'applicazione generale?
Se non si "interfaccia bene" con le altre applicazioni in architettura applicazione generale e si dovrà, allora si potrebbe scoprire che hai bisogno di avere queste interfacce personalizzate sviluppate. Pertanto, si dovrebbe anche prendere in considerazione lo sviluppo di queste interfacce in "total cost of ownership" di questo pacchetto, giusto?

4) Che tipo di documentazione, formazione e supporto sono disponibili? E quanto sono bravi? Bottom line ... un pacchetto di voi e / o il vostro personale non può utilizzare non vale molto ora è?

Etc. Etc.

Concesso, di nuovo, c'è molto di più sia una "buona analisi formale" Buy vs Costruire e / o Software processo di selezione, come discusso in precedenza, ma ...

Una volta che avete limitato giù verso l'alto "punteggio" COTS candidato pacchetti software dal vostro processo di selezione del software, questo insieme alla valutazione dei vantaggi, gli svantaggi e costi del "Buy" vs il "alternativo Build, come discusso in precedenza , vi permetterà di prendere una buona decisione informata su quale soluzione è meglio per voi e il vostro business, vale a dire la "Build" o "Buy", in questo caso, giusto?

Mi auguro che le discussioni qui saranno almeno aiutare tutti vedere il valore (e di tempo potenziale, impegno e denaro di risparmio) di eseguire un "Buy vs Build" analisi e / o di un processo di selezione del software "in anticipo" rispetto a finire con qualcosa che o non soddisfa le vostre (a breve e / o lungo termine) esigenze e / o è troppo costoso da mantenere.

Se avete ulteriori domande in merito e / o vorrebbe ulteriore assistenza con tutto questo, non esitate a contattarci tramite le informazioni di contatto disponibili sotto.

Spero che tutto questo ti aiuta a tutti ed avere un grande giorno! :)

- Michael S. DeVries

No comments:

Post a Comment