Introdução

Eventualmente, as empresas precisam ir ao mercado para escolher uma solução/software/ferramenta visando apoiar o seu negócio. Qual é a pergunta principal neste momento: como devemos fazer essa escolha? 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.

Na ausência de uma metodologia de seleção de software guiando a escolha, outros fatores que podem impactá-la negativamente incluem: o discurso treinado dos vendedores de software, que buscam fazer com que seu software pareça a melhor escolha para o cliente; e a paralisia por análise, que ocorre quando os envolvidos gastam muito tempo e esforço na tomada de decisão, mas ainda assim não conseguem fazer uma escolha (DOIG, 2017).

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

Metodologia de Software Selection

Na metodologia de Software Selection utilizada pela dheka, há 10 etapas:

Etapas da metodologia de software selection
Etapas da metodologia de software selection

Planejamento do projeto de Software Selection

Assim como qualquer tipo de projeto, também é necessário um planejamento minucioso para um projeto de seleção de software, levando em consideração a execução de cada etapa, incluindo escopo, prazo, custo e qualidade. Portanto, é importante elaborar um plano de projeto que leve em consideração os recursos a serem utilizados em cada etapa, e recomenda-se estabelecer 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. Um levantamento dos processos é realizado. Nós modelamos esses processos utilizando uma ferramenta de modelagem de processos, que deve dar suporte à notação de modelagem de processos escolhida.

Após modelar os processos, é importante validar os processos junto ao cliente para garantir que os processos levantados e modelados correspondem realmente aos processos praticados na empresa.

Passos da fase de modelagem de processos
Levantamento, modelagem e validação de processos

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

O diagnóstico é feito a partir do mapeamento da situação atual (AS-IS) dos processos na empresa, analisamos os processos atuais para identificar os pontos fortes e pontos fracos. Podemos utilizar uma ou mais técnicas de análise de processos para identificar os pontos de melhoria nos processos de uma empresa: 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í, podemos traçar 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

Assim que definimos os requisitos do sistema, criamos a RFI (Request for Information). Normalmente, geralmente enviamos primeiro a RFI, que tem como um dos principais objetivos realizar uma tomada de preço no mercado. Para isso, contatamos os fornecedores e solicitamos uma primeira estimativa de valor, prazo e abordagem técnica para a solução que estamos considerando.

Com os resultados dessa tomada de preços, nós analisamos as propostas para termos 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. Nós podemos eliminar essas ferramentas que não atendem. Então, podemos fazer uma primeira filtragem dos concorrentes a partir da long list inicial, ou seja, da lista completa de fornecedores.

Business case e decisão de make or buy

Após realizar o levantamento inicial de preços, a empresa precisa tomar uma decisão estratégica para determinar se é mais vantajoso 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 fazer a melhor escolha, é fundamental construir um business case. Este documento vai levantar informações cruciais sobre o projeto de desenvolvimento e implantação do software na empresa, tais como prazo, custo, riscos e ROI (Return on Investment). A partir dessas informações e das propostas iniciais de preços dos fornecedores, que foram levantadas na etapa de RFI, a empresa pode realizar a tomada de decisão sobre a compra do software.

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

Uma vez tomada a decisão de compra do software, é crucial prosseguir com o projeto de seleção de software. Além disso, considerando que um primeiro filtro entre os fornecedores já foi realizado, agora é possível identificar aqueles que oferecem ferramentas com maior nível de aderência. Posteriormente a essa etapa, é viável avançar para a elaboração 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 a um resultado final; assim, a empresa tem uma indicação de quais fornecedores são potenciais vencedores. Em seguida, a empresa entra em uma última etapa de negociação com esses fornecedores indicados como vencedores, a fim de negociar custo, prazo e estratégia de implementação. Nessa fase, discute-se como 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 seleção de software, você tem um processo novo; portanto, um processo que incorpora inovação, atendendo às boas práticas de mercado. Além disso, você também obtém uma solução nova que é aderente e satisfaz as necessidades da empresa. A partir desse momento, a empresa está muito mais preparada para operar o negócio de forma automatizada.

O que você achou? Além disso, gostou da abordagem? Por acaso, já teve alguma experiência que não seguiu essa metodologia e não deu tão certo na sua empresa? Se sim, precisa de ajuda para realizar um projeto de software selection na sua empresa? Portanto, 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.