Que tipo de critérios são importantes a considerar ao seleccionar um pacote de software “COTS”?
- requisitos actuais: de que precisa neste momento? Quanta configuração / personalização seria necessária?requisitos futuros: o que prevê que irá precisar mais tarde? Qual é o roteiro do Fornecedor, incluindo a frequência de lançamento? Quanto custa afastar-se desta tecnologia? Quanta influência tem sobre o roteiro?,Implementabilidade
- : de que Plataforma necessita? Quão difícil é a integração com os sistemas existentes? Tem problemas de escala de hardware? Existem pontos únicos de fracasso?apoio: o que está disponível em termos de formação? Consultoria? Documentação? Comunidade? Quão estável é o vendedor? Se o fornecedor também tem a intenção de ser um parceiro de integração, quão alinhado você está culturalmente?
- custo: quanto custará implementar (licença, hospedagem, personalização), manter, atualizar, modificar?,
- Deliverability: (se a personalização ou configuração extensa é necessária) customização será feita através de APIs (bom) ou terá de ser feito através da modificação de internais (mau)? Quão difícil é testar o pacote (especialmente de forma automatizada)? Quão difícil é automatizar a instalação, configuração e compilação (os feiticeiros são maus, as APIs programadas são boas)? Quão difícil é configurar o controle de versão especialmente integrado com o seu sistema de gerenciamento de configuração existente?,
reduzir a personalização tanto quanto possível … caso contrário, ficará sobrecarregado com o custo e o esforço das actualizações.
isto sugere que você deve modificar o processo de negócio para corresponder ao pacote em vez de vice-versa… o que, por sua vez, sugere que você geralmente não deve estar considerando pacotes para processos de Negócio estratégicos / capacidades. Isto também sugere que você quer ser muito claro sobre e impor limites para evitar que as características do pacote penetrem em áreas estratégicas.
só porque o produto oferece um recurso, não significa que você deve ligá-lo ou usá-lo.,
de acordo com Capers Jones, a 25% de personalização, é mais barato a longo prazo construir um sistema personalizado e 15% de personalização é um número mais seguro para usar. Se o fornecedor for hostil, o número cai para 5%.
personalização ou configuração extensa destaca a necessidade de entregar.
Se o pacote é como um aparelho (por exemplo, Microsoft Word), ele deve apenas funcionar. Seleção inicial e atualizações podem ser mais sobre manual, testes exploratórios., No entanto, uma vez que começamos a introduzir a personalização, então a importância de ser capaz de configurar testes automatizados (bem como outras características de desenvolvimento) cresce.configuração
, especialmente se extensa, não deve necessariamente ser tratada com menos rigor do que o desenvolvimento personalizado.
especialmente com os pacotes de COTS típicos em termos de CRM, ERP, Finanças, As principais opções tendem a ter paridade característica o que significa que você deve geralmente se concentrar em outros aspectos.
isto pode ser alinhamento do Fornecedor, testabilidade, modificabilidade, etc.,
é melhor reduzir o compromisso do que tentar comprometer-se com uma decisão perfeitamente correta.
Se o pacote não requer tanto empenho (por exemplo, serviço hospedado), temos mantido opções para mudar nossa mente mais tarde e não precisa se preocupar tanto em tomar uma decisão ideal na frente.
não escolha a tecnologia certa. Escolha a tecnologia mais barata para se afastar.,
Chris Matts
os factores que aumentam o compromisso são principalmente a dimensão do investimento inicial e o custo da migração dos dados. A dimensão do investimento inicial tem a ver com uma falácia de custos irrecuperável, o que a torna um factor psicológico/político, e não económico.
