2) Den opprinnelige kjøpesummen for en programvarepakke, selv om det kan være betydelige, er ofte mindre enn de (initial) tilpasset utviklingskostnadene.
3) programvareleverandør kan levere regelmessige vedlikeholds oppgraderinger til programvarepakken, inkludert en rekke "feilrettinger" og /eller forbedringer, som du kan få for en "fast vedlikehold fee" slik at du ikke trenger å bære kostnadene ved alle disse "feilrettinger" og forbedringer alene.
Noen av ulempene med "Kjøp" alternativet inkluderer:
1) En COTS pakken kan ikke tilfredsstille alle dine forretningsmessige krav /behov og kan ikke passe dine spesifikke forretningsprosesser vel "out of the box". Programvareleverandøren kan eller ikke kan være villig og i stand til å endre den pakken for å bedre individuelle forretningsbehov og /eller prosesser, og selv om det, kan dette være kostbart.
2) En programvarepakke som kan være mindre i stand å raskt tilpasse seg endringer i virksomhetens behov og /eller prosesser.
Du må kanskje vente til leverandørens neste vedlikehold utgivelse for å få de endringene du ønsker, eller du kan ha til å betale leverandøren for å gjøre disse endringene spesielt for deg og vente på dem, eller de kan ikke være villig (og /eller stand ) for å gjøre disse endringene i sin programvarepakke for deg i det hele tatt.
I korthet her er også bare noen av flere faktorer som, IMHO, kan du ønsker å vurdere i å vurdere /velge en pakkeløsning (s) Som en del av din "Kjøp alternativer", inkludert:
1) Hva er den ekstra tid og kostnad, hvis det er enda mulig /et alternativ, å endre pakken for å tilfredsstille gjeldende krav /behov? En "tommelfingerregel" Jeg har brukt opp gjennom årene er at ...
Hvis du må endre 50% eller mer av den "koden" for å gjøre det møte dine behov, så er du sannsynligvis bedre omskrivninger det " fra scratch ", vet du?
2) Er det å vedlikeholde? Meaning, vil du, leverandøren, og /eller utviklere du engasjere kunne endre pakken for å møte eventuelle endringer i din nåværende og /eller fremtidig krav /behov? Hvis ikke, så denne pakken kan bli "hyllevare" bør behovet endrer på et tidspunkt, du vet?
3) Hvor godt det integreres og /eller "spille bra" med de andre programmene i din generelle søknad arkitektur? Hvis den ikke gjør det "grensesnittet pent" med andre applikasjoner i din generelle søknaden arkitektur, og det må, så kan du oppleve at du må ha disse grensesnittene