No último texto falamos sobre os diversos ambientes que necessitam ser segregados em nome da qualidade de TI. Neste abordamos a qualidade dos softwares e sistemas adquiridos:
Será que têm a qualidade desejada?
Como podemos melhorar, ou obter garantias para a qualidade que necessitamos?
Neste texto não vamos falar sobre a aquisição de software sob medida, quando compramos o desenvolvimento de software específico, mas sim a respeito da qualidade de software adquirido pronto, ou seja, software produto.
Para adquirir software de qualidade é necessário um trabalho prévio de preparação do processo de aquisição de software, que nem sempre é um processo definido pela organização que quer adquirir um software.
Mesmo que este processo já exista na empresa, vale a pena verificar se o mesmo passa pela definição e validação de requisitos, se há indicadores definidos para qualificar os requisitos e se há metas definidas para avaliar o seu atendimento.
Todos estes aspectos devem ser revisados e aprovados com os usuários ou clientes, que serão os donos e beneficiários do software a ser adquirido. O mesmo processo deve ser revisto quanto aos requisitos operacionais revisando e aprovando-os com os responsáveis pelo ambiente produtivo e de suporte da organização.
O próximo passo deve identificar, qualificar e selecionar fornecedores do software em acordo com políticas de compras da organização.
A partir deste ponto, organiza-se o projeto de aquisição, que além dos requisitos a serem atendidos deve considerar aspectos da customização do software, adequando-o às necessidades de usuários e ambiente, aspectos de documentação e treinamento, aspectos de manutenção legal, atualização tecnológica e manutenção corretiva. Por fim, deve ser dada especial atenção à implantação dos requisitos de infraestrutura do software adquirido, já customizado, testado e homologado e, principalmente da conversão de dados necessários ao inicio da sua operação.
Falando desta forma até parece simples, não é mesmo? Mas é aí é que os problemas começam, ou a qualidade do software adquirido e, por vezes tanto elogiado, padece.
Será que os requisitos foram bem identificados? E os usuários, ou clientes, assim como a produção e o suporte, tiveram a correta compreensão dos requisitos para validar e aprová-los?
Requisitos são a base inicial para qualquer software de qualidade e não é diferente para software adquirido. Não é certo afirmar que um software produto que serve para uma organização, também serve para outra.
As empresas não são todas iguais.
E os fornecedores?
Estes também podem não se adequar a todos os clientes da mesma forma.
Organizações têm políticas de compras diferentes e já tive experiências onde fornecedores tradicionais foram desqualificados pelas mais diversas razões.
No projeto, que começa com a aquisição do software e termina com o software em operação, evidenciei uma das maiores aberrações.
Uma grande empresa do setor de serviços financeiros, que adquiriu um ERP, nomeou uma equipe de usuários para definição das customizações necessárias aos diversos módulos do software de gestão empresarial. Dois destes módulos tiveram cerca de 80% dos seus processos e regras redefinidos.
A definição em utilizar um software produto significa que a empresa quer se beneficiar das melhores práticas utilizadas pelo software selecionado. Isto significa que o mesmo deve ser implantado com o menor número de customizações; no limite, sem alterações (Vanila).
Se, ao contrário, a realidade pede um número maior de adequações e o processo não pode seguir o processo estabelecido no software, aí está um caso claro de um módulo que não serve para a organização e deve-se manter, ou desenvolver, um software específico para tal.
O treinamento é outro foco de problemas. Muitas vezes os usuários são treinados no uso do software, mas o suporte não recebe as orientações para atendimento às ocorrências.
Quanto às manutenções, os casos mais comuns são as ocorrências com atualizações tecnológicas feitas no software e que não são acompanhadas pelos clientes e que, em decorrência, fica defasado em suas versões instaladas, o que por vezes provoca custos não orçados.
Os principais problemas com a conversão de dados que tenho encontrado são planejamentos e providências deixadas para o final do projeto, ou pelo menos para próximo da fase de implantação. E, nesta altura do campeonato, com muitos prazos já comprometidos, surgem necessidades não previstas que agravam os prazos e os custos.
Problemas de ordem administrativa também podem afetar a qualidade do software adquirido. Por exemplo, não é raro encontrar contratos de manutenção mal redigidos, onde a organização não consegue ter o atendimento de suporte adequado às suas necessidades.
Planejamento faz a aquisição de software ter qualidade.
Em nosso próximo texto vamos falar sobre Qualidade em TI – Treinamento não traz melhoria na qualidade.
[Crédito da Imagem: Qualidade em TI – ShutterStock]