Comprando Software Corporativo (parte 2)

Metodologia para compra de software

Parte 1 – Comprar pronto, desenvolver internamente ou desenvolver externamente?
Parte 3 – Requisitos para compra de software
Parte 4 – Conclusão

Bem, você optou por comprar um software pronto. Então chegou a hora de escolher a solução que melhor atende às suas necessidades e que se encaixe no seu orçamento. É claro que você já sabe exatamente como deve ser o software que você necessita… não é?

É claro que não! Um software corporativo é muito grande e complexo. É muito difícil alguém conhecer exatamente todas as regras de negócio envolvidas, todos os processos que vão envolver o software e ainda conhecer a melhor tecnologia a ser utilizada. Você deverá reunir uma equipe, talvez com o apoio de uma consultoria externa para ajudar a definir quais são as suas demandas reais. Aqui, já partimos do principio que toda a implantação de software tem como impacto uma reengenharia de processos e ao mesmo tempo a necessidade de se manter o foco nas demandas centrais para não buscar uma aplicação com um custo impraticável.

Aqui, existe uma boa bibliografia que indica alguns caminhos a seguir. Em geral o processo conta com um levantamento de requisitos técnicos e funcionais entre os potenciais usuários, gestores e equipe de TI. Deve-se levantar também quais requisitos são essenciais e quais são desejáveis. Quais precisam ser implantados primeiro e quais podem ser implantados posteriormente.

Feito isto, deve se ir a campo e procurar empresas de software que forneçam soluções que aparentemente atendam às suas expectativas. Visitar a empresa na sua sede, assistir demonstrações e conhecer a sua fábrica de software são essenciais. Deve-se enviar um questionário para cada fornecedor com a sua lista de requisitos que você levantou, para que você possa comparar as soluções. Você também deve agregar as suas próprias observações de forma sistemática para cada visita realizada às empresas. É fundamental que a mesma equipe visite todos os fornecedores para que eles realizem a comparação de forma mais precisa.

Outro passo importante é visitar outras empresas onde o sistema já esteja implantado. Para isso solicite uma listagem de locais onde o sistema foi implantado e agende visitas nestes locais sem avisar o fornecedor. Não vá em locais indicados pelo fornecedor. Verifique se as funcionalidades destacadas pelo fornecedor conferem com as observadas em produção.

Feito isto, você deve planilhar todas estas informações e solicitar orçamentos dos fornecedores que atenderam as exigências mínimas requeridas. Você deve estabelecer uma métrica de pontuação para chegar a uma nota final de avaliação dos sistemas. Aqui, a questão mais difícil é ponderar qual é o peso de cada área. Você não deve jamais se deixar levar apenas pelo preço ou pelas funcionalidades apresentadas. É preciso balanciar vários fatores observados:

  • Reputação da empresa no mercado
  • Qualidade, tamanho e estabilidade da equipe envolvida no desenvolvimento e manutenção
  • Metodologia adotada no desenvolvimento e manutenção
  • Carteira de clientes e satisfação dos mesmos
  • Qualidade e veracidade das informações fornecidas
  • Funcionalidades presentes
  • Maturidade das regras de negócio
  • Técnologia adotada
  • Custo de manutenção
  • Custo de implantação

Existem conjuntos de indicadores e pesos bastante utilizados na aquisição de software. No entanto, estes pesos são apenas modelos que você deve adaptar a sua realidade e percepção de importância. Muitos destes itens são de avaliação subjetiva e tem que ser utilizados com cautela e bom senso. Na esfera pública, isto se torna bem mais complexo, uma vez que é preciso realizar uma licitação do tipo Técnica e Preço onde os critérios de avaliação da nota técnica tem de ser estritamente objetivos.

É impossível abordar aqui questões pertinentes às regras de negócio de devem compor a nota de um software, pois cada organização terá demandas específicas. No entanto, existem necessidades técnicas na área de informática que não são menos ou mais importantes que as regras de negócio em si. Ainda assim, os critérios técnicos são muitas vezes relevados para um segundo plano na escolha de um software. Estes critérios só mostram sua importância quando o sistema precisa ser adaptado ou depois que ele entra em produção. E neste momento costuma ser tarde demais para voltar atrás sem causar um grande estrago.

As funcionalidades de um sistema são fáceis de serem demonstrar e costumam satisfazer a maioria dos gestores, porém, a área de TI deve assegurar que o software seja robusto, flexível, confiável, rápido, etc. Estas questões são todas de responsabilidade da área de TI pontuar uma a uma e definir métricas para a sua avaliação.

Dependendo da situação, os pesos da aplicação podem variar bastante:

  • Sistemas utilizados por um grande volume de usuários tem grande vantagem se rodarem via WEB. No entanto inserção bruta de grande volume de dados ainda ocorrem de maneira mais eficientes em interfaces GUI ou mesmo em modo texto.
  • Sistemas que podem ser acessados por um público externo devem ter um cuidado especial com a usabilidade e acessibilidade.
  • Sistemas que devem se integrar com outros sistemas devem suportar padrões abertos de comunicação.
  • Sistemas que envolvam a manipulação de informações sensíveis devem ter um cuidado especial com a segurança e com a auditoria.
  • Sistemas que envolvem muitas transações concorrentes devem ter um cuidado especial em relação ao controle de transações e o uso de um bom SGDB.
  • Sistemas com regras de negócio complexas devem utilizar modelos com 3 ou mais camadas.
  • Sistemas de missão crítica que admitam um downtime muito pequeno devem ser desenvolvidos com ferramentas robustas e confiáveis.
  • Sistemas que devam entrar em operação por vários anos devem dar prioridade para tecnologias e padrões abertos.
  • Comprar o código fonte de um software sem uma excelente documentação é como comprar uma Ferrari sem freios.
  • Softwares que dependam de legislação local devem ter casos de implementação local e equipe de desenvolvimento local.

Compartilhe

Você pode gostar

Sobre minha saída da Timbira

Há 14 anos, durante o PGConf.Brasil 2009, lá na UNICAMP em Campinas/SP, 4 pessoas se reuniram e idealizaram a criação da primeira empresa dedicada exclusivamente

Split brain

Já tem algum tempo que eu pensava em fazer isso e chegou a hora. Este blog vai se dividir em 2 partes a partir de

plugins premium WordPress