Introdução

Eventualmente, as empresas precisam ir ao mercado para escolher uma solução/software/ferramenta visando apoiar o seu negócio. A pergunta principal neste momento é: como essa escolha deve ser feita? A dheka responde: através de um projeto de software selection.

Por que utilizar uma metodologia de Software Selection?

As consequências de uma má escolha de software podem causar grandes impactos em uma empresa, como já aconteceu com Hershey’s, Nike e HP. Assim, erros na seleção de software podem culminar em prejuízos financeiros e comprometimento da reputação dessas empresas perante os seus clientes (JADHAV; SONAR, 2009). Por outro lado, uma boa escolha de software pode representar uma vantagem competitiva para uma organização quando implementada corretamente.

Há diversos fatores que devem ser levados em consideração para a escolha de um novo software para a empresa como, por exemplo, os profissionais envolvidos na seleção de software. Além disso, o fato de se ter como critério de escolha primordial o preço pode comprometer a qualidade. Obviamente, os critérios comerciais como preço e forma de pagamento são de alta importância para qualquer empresa. Entretanto, fatores relacionados à aderência do software aos requisitos, integração com sistemas legados e  cronograma de implantação também são fundamentais.

Outros fatores que podem impactar negativamente uma escolha de software que não seja guiada por uma metodologia de software selection são: o discurso do vendedor de software, que é treinado para fazer com o que o seu software pareça ser a melhor escolha para o cliente; a paralisia por análise, que é quando se gasta muito tempo e esforço para uma tomada de decisão e mesmo assim os envolvidos não conseguem fazer uma escolha (DOIG, 2017).

Um projeto de software selection com metodologia apropriada evita também que a decisão seja justificada por fatores políticos ou direcionada pela opinião de alguém influente na empresa (BANDOR, 2006). Portanto, é importante que se tenha uma metodologia de seleção de software para guiar o projeto que irá indicar o software que melhor se encaixa com os diferentes aspectos que representam as necessidades da empresa.

Metodologia de Software Selection

A metodologia de Software Selection utilizada pela dheka é composta por 10 etapas:

Etapas da metodologia de software selection

Planejamento do projeto de Software Selection

Assim como é feito em qualquer tipo projeto, um projeto de software selection também requer um planejamento minucioso acerca da execução de cada etapa do projeto considerado escopo, prazo, custo e qualidade. Portanto, deve ser elaborado um plano de projeto que leve em consideração os recursos a serem utilizados em cada etapa e é recomendável que se estabeleça um cronograma dentro do qual o projeto será executado.  

Modelagem da situação atual (AS-IS) dos processos

Tipicamente, inicia-se um projeto de software selection mapeando os processos atuais (AS-IS), para que seja possível entender como a empresa funciona hoje. É realizado um levantamento dos processos. Estes processos são modelados utilizando uma ferramenta de modelagem de processos, que deve dar suporte à notação de modelagem de processos escolhida.

Após a modelagem de processos, é importante realizar a validação dos processos junto ao cliente para que haja certeza que os processos levantados e modelados são os processos que realmente são praticados na empresa.

Levantamento, modelagem e validação de processos

Diagnóstico da situação atual (AS-IS)

A partir do mapeamento da situação atual (AS-IS) dos processos na empresa, é feito um diagnóstico: analisando os processos atuais, são identificados os pontos fortes e pontos fracos. Para identificar os pontos de melhoria nos processos de uma empresa podemos utilizar uma ou mais técnicas de análise de processos: análise do ponto de vista dos stakeholders, dimensões de análise do processo ou análise da FOFA (ou SWOT). A partir daí, pode ser traçado um roadmap para a introdução das melhorias de curto, médio e longo prazo.

Processos futuros (TO-BE)

Com o resultado do diagnóstico realizado podemos trabalhar nos processos futuros, ou seja, nos processos TO-BE, e criar os processos novos para a empresa. A partir do momento em que os processos TO-BE estão definidos, eles refletem o modo como a empresa quer trabalhar daqui para frente, ou seja, o modo como a empresa quer inovar em seus processos e como ela quer funcionar sendo mais eficaz e mais eficiente.

Requisitos futuros (TO-BE) e arquitetura

A partir desse modelo futuro (TO-BE) dos processos da empresa é possível extrair os requisitos necessários ao novo sistema, ou seja, é possível definir como o sistema novo deverá funcionar. Portanto, é possível saber quais são os requisitos necessários ao sistema para atender aos processos TO-BE. 

Nós já falamos um pouco sobre isso em um vídeo no qual comentamos sobre a derivação de requisitos a partir de processos e na dheka também oferecemos este serviço. 

Além disso, nessa etapa também ocorre a Identificação dos modelos de arquitetura sistêmica adequados, considerando os diversos aspectos técnicos já existentes e os requeridos pelas soluções e pelos novos processos, assim como os direcionadores estratégicos de tecnologia.

1ª ida ao mercado: RFI (Request for Information) – Tomada de preços

Uma vez que os requisitos do sistema são definidos, é criada a RFI (Request for Information). Tipicamente, é comum que seja enviada primeiramente a RFI, que tem como um dos objetivos principais realizar uma tomada de preço no mercado. Para isso os fornecedores são contatados e uma primeira estimativa de valor, prazo e abordagem técnica são solicitadas para a solução que se tem em vista. 

Com os resultados dessa tomada de preços, as propostas são analisadas para que se tenha um primeiro levantamento de quais ferramentas estão muito distantes dos requisitos colocados, ou seja têm um nível de aderência baixo aos requisitos. Essas ferramentas que não atendem podem ser eliminadas. Então, da long list inicial, ou seja, da lista completa de fornecedores, já pode ser feita uma primeira filtragem dos concorrentes.

Business case e decisão de make or buy

Após o levantamento inicial de preços chega o momento da tomada de decisão estratégica para que seja definido se é mais vantajoso para a empresa comprar ou desenvolver o software internamente. Essa decisão é também conhecida como make or buy.

Leia também:

Muitas vezes, os requisitos do software são tão específicos para as necessidades daquela empresa que a compra de um software pronto exige um alto nível de customização, ou seja, o fornecedor de software precisa desenvolver funcionalidades que atenderão exclusivamente aquele software, o que aumenta o preço do software.

Para que a melhor escolha seja feita, pode ser construído um business case, que vai levantar informações sobre o projeto de desenvolvimento e implantação do software na empresa como o prazo, o custo, os riscos e o ROI (Return on Investment). Com essas informações e as propostas iniciais de preços dos fornecedores que foram levantadas na etapa de RFI, é possível realizar a tomada de decisão acerca da compra do software.

2ª ida ao mercado: RFP (Request for Proposal) – Concorrência

Uma vez tomada a decisão de compra do software, deve-se prosseguir o projeto de software selection. Como foi realizado um primeiro filtro entre os fornecedores, também já é possível saber aqueles fornecedores que têm ferramentas com maior nível de aderência. Depois dessa etapa, é possível avançar para a etapa da RFP. 

A RFP não é só uma sondagem de mercado ou uma tomada de preços, ela é de fato parte do processo de contratação. Caso a empresa interessada na compra da solução seja privada isso é um pouco mais simples e no caso de empresas públicas ocorre uma licitação. De qualquer forma, nessa etapa a empresa vai ao mercado dizer aos fornecedores que ela vai escolher uma solução, ou seja, vai escolher um fornecedor para implantar um sistema novo na empresa. Ao lançar a RFP ao mercado, a empresa expõe qual é a demanda e quais são os requisitos. Aqueles fornecedores que já haviam sido previamente selecionados vão responder com uma proposta técnica e uma proposta comercial. Essas propostas apresentam o prazo e custo de cada um dos fornecedores para atender aos requisitos apresentados pela empresa. A partir dessas propostas é possível realizar outro filtro para que seja feita a escolha daqueles fornecedores que estão mais próximos do que a empresa gostaria. 

Análise de aderência e POC (Prova de Conceito)

A próxima etapa desse projeto de software selection é a POC (Proof of Concept ou Prova de Conceito), que é onde será testado na prática e dentro da empresa que deseja adquirir o software se as ferramentas dos fornecedores funcionam e se atendem de fato aos requisitos.

Esta etapa é importante porque é quando os usuários podem utilizar a ferramenta e ver se ela de fato apresenta todas as características, as funcionalidades e os requisitos que a empresa necessita. Então, essa é a etapa onde se faz uma avaliação da ferramenta em diversos requisitos verificando se a ferramenta atende, atende parcialmente ou não atende aos requisitos. 

Seleção, negociação e contratação

Após todas essas etapas chegamos em um resultado final, onde a empresa tem uma indicação de qual(is) fornecedor(es) são potenciais vencedores. Então, a empresa entra em uma última etapa de negociação com esses fornecedores indicados como vencedores para negociar custo, prazo e estratégia de implementação, que é como vai ser a abordagem de implementação: se o fornecedor vai implementar tudo de uma única vez ou se vai dividir em fases. 

Ao final da etapa de negociação a empresa tem de fato um fornecedor, com uma solução que foi escolhida para a qual será iniciado um projeto de implantação. Ao término do projeto de implantação, aquela solução começará a ser utilizada na empresa que está escolhendo esse fornecedor. 

Conclusão

É importante lembrar que essa solução vai estar aderente ao processo novo (TO-BE), que foi proposto pela empresa e aos requisitos de negócio e técnicos que essa empresa estabeleceu. Então, muitas vezes, para aumentar a aderência do software aos requisitos, o fornecedor precisa desenvolver a solução mais um pouco, ou seja, ele precisa construir um pouco mais da solução adicionando funcionalidades específicas para satisfazer aos usuários de negócio. 

Ao final do projeto de software selection você tem um processo novo, um processo que tem inovação, que atende às boas práticas de mercado e você também tem uma solução nova que é aderente e atende ao que a empresa precisa. A partir desse momento a empresa está muito mais preparada para rodar o negócio de forma automatizada.

O que você achou? Gostou da abordagem? Já teve alguma experiência que não seguiu essa metodologia e não deu tão certo na sua empresa? Precisa de ajuda para realizar um projeto de software selection na sua empresa? Entre em contato conosco e agende uma reunião para encontrar o software que melhor satisfaça as necessidades do seu negócio!

Referências

BANDOR, M. Quantitative Methods for Software Selection and Evaluation. , no CMU/SEI-2006-TN-026. HQ ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2116: Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213, set. 2006. Disponível em: <https://drive.google.com/file/d/1VQECNRqC2557kOTstus0nhRJ0Z7BU-4h/view?usp=sharing>.

DOIG, C. Rethinking Enterprise Software Selection: Stop buying square pegs for round holes. CreateSpace Independent Publishing Platform, 2017.

JADHAV, A. S.; SONAR, R. M. Evaluating and selecting software packages: A review. Information and Software Technology, v. 51, n. 3, p. 555–563, 1 mar. 2009.