White paper Os desafios da escolha de um software corporativo

Este white paper faz parte da nossa coluna “From the trenches” (Nas trincheiras). Descreve como as implantações de sistemas corporativos precisam ser capazes de se adaptar e evoluir para serem bem-sucedidas.

Para baixar a versão do Word deste documento, consulte White paper Os desafios da escolha de um software corporativo.

Para ver mais white papers, consulte os white papers da coluna "From the Trenches".

Os desafios da escolha de um software corporativo

Isto acontece o tempo todo por aqui. Um cliente envia uma "Solicitação de proposta" (RFP, Request for Proposal) para o nosso escritório com instruções para redigirmos uma resposta em um prazo de alguns dias ou uma semana e enviá-la de volta para nosso sistema corporativo ser avaliado para compra. As RFPs são bastante parecidas entre si. Normalmente, há uma breve visão geral, instruções sobre o que você precisa fazer para ter sua resposta avaliada, incluindo como ela precisa ser formatada e quando enviá-la de volta, etc. Em seguida, há uma longa grade de recursos exigidos e um questionário com uma série de perguntas adicionais que devem ser respondidas.

O desafio com as RFPs é que elas não foram desenvolvidas exclusivamente para escolher um software corporativo, portanto, quando um processo de RFP é seguido, isso não necessariamente garante as melhores decisões para a organização. RFPs foram criadas pela comunidade de consumidores como uma maneira de obter a melhor mercadoria pelo melhor preço, e ainda cumprem muito bem esse papel. Quando as ofertas são comparáveis, então o processo de tomada de decisão pode se concentrar no melhor preço com apenas uma ou outra variável a mais (como datas de envio) acrescentada à disputa. Quando as soluções possíveis estão todas na mesma categoria geral, mas não são de forma alguma comparáveis (como no caso do software corporativo), então o número de variáveis que deve ser considerado pelos compradores é enorme, e o processo de RFP não agrega valor à seleção. Como a maioria das companhias escolhem um software corporativo Vamos começar analisando o processo que ocorre todas as vezes com qualquer fornecedor ou provedor de soluções de software corporativo. Falarei sobre software de gerenciamento de projetos corporativos ou software de quadro de horários corporativo, pois é isso que minha empresa fornece, mas o paradigma é o mesmo para praticamente qualquer escolha de sistema corporativo.

Como a maioria das companhias escolhe um software corporativo

Vamos começar analisando o processo que ocorre todas as vezes com qualquer fornecedor ou provedor de soluções de software corporativo. Falarei sobre software de gerenciamento de projetos corporativos ou software de quadro de horários corporativo, pois é isso que minha empresa fornece, mas o paradigma é o mesmo para praticamente qualquer escolha de sistema corporativo.

Na maioria das organizações, o impulso de buscar por um software corporativo vem de algum tipo de problema. Talvez o problema tenha sido apresentado pelo pessoal de campo. Talvez ele tenha sido detectado por alguém na gerência sênior. Seja como for, a iniciativa precisa obter o apoio de alguém na gerência sênior. A escolha de um sistema que irá afetar toda a empresa não virá da base; isso é uma fantasia até mesmo nas organizações mais progressistas. Então, é um gerente sênior quem decide: “nós precisamos deste tipo de sistema corporativo.”

O processo de escolha de software corporativo típico ocorre da seguinte forma:

  1. A gerência diz que precisamos de um novo sistema corporativo

  2. Um gerente de projeto é escolhido

  3. Obtém pedidos de todos os departamentos envolvidos

  4. Reúne todos os pedidos em uma grande planilha

  5. Envia a grade de requerimentos para vários fornecedores

  6. Recebe várias repostas

  7. Faça uma triagem

  8. Assiste a demonstrações

  9. Negocia

  10. Obtém a aprovação da gerência

  11. Solicita outra decisão da gerência

Um gerente de projeto para o processo de seleção é sugerido. Ele ou ela faz tudo o que nós fazemos: acessa a Internet, carrega um mecanismo de pesquisa, digita “EPM Software” (ou qualquer outro sistema corporativo desejado). No mesmo instante, recebe meio milhão de resultados. Talvez um gerente de projetos dedicado navegue pela primeira dezena deles para descobrir que tipo de sistemas estão disponíveis antes de ir fazer outra coisa. Obviamente, ninguém tem tempo para navegar por meio milhão de resultados ou mais para ver se talvez o último seria o sistema ideal para a organização.

Sem se deixar intimidar, o gerente de projetos reúne um comitê de seleção a partir daqueles que serão afetados pela implantação deste novo sistema corporativo. Alguns dos membros desse comitê podem até mesmo ter vindo do pessoal de campo que identificou essa necessidade para a organização. Outros talvez não. Este comitê de seleção será composto de uma mistura de pessoas que possuem seus próprios interesses quanto a que tipo de sistema será escolhido.

O pobre gerente de projeto então pede que cada membro do comitê faça uma apuração junto ao grupo que representa para descobrir o que eles querem do novo sistema corporativo. Como cada um dos representantes do comitê faz isso? Bem, em primeiro lugar, nem todos demonstram o mesmo grau de dedicação, mas aqueles que fazem seu dever de casa pedem que sua equipe apresente uma lista de recursos que considerariam importantes. Então essas pessoas também irão acessar a internet e navegar pelos sites de alguns fornecedores. Elas poderão copiar e colar recursos que encontram nos informativos desses sites à medida que cada um deles lhes dá novas ideias sobre os tipos de coisas que podem exigir de um novo sistema.

Então o comitê volta a se reunir e as longas planilhas de cada membro do comitê são combinadas em uma planilha gigantesca. Essa mega-planilha de requisições é categorizada, mas surgem desafios. Em primeiro lugar, as diversas necessidades do comitê agora estão mais claras, uma vez que recursos foram solicitados a partir de uma ampla variedade de perspectivas. O comitê pode ser composto de membros de vários departamentos, mas também de vários países ou até várias divisões. Haverá quase sempre um pedido que estará em conflito com outro pedido na mesma lista (por exemplo, o sistema deve ser simples e não ter muitos prompts e o sistema deve ser muito flexível, com um grande número de opções para cada usuário).

Finalmente, a planilha combinada que será apresentada aos fornecedores está completa. Ela possui centenas de pedidos de recursos em relação aos quais o fornecedor deverá responder “Sim”, “Não”, ou “Sim, com algum trabalho”. Talvez um sistema de ponderação também seja incluído para dizer se um determinado recursos é “Fundamental”, “Importante” ou “Opcional”.

Trecho de código da planilha de seleção do recurso

A RFP está quase pronta. Haverá ainda um breve questionário, geralmente sobre a arquitetura técnica da seleção e, dependendo de quantas pessoas tenham sido entrevistadas sobre esses requisitos, as solicitações de arquitetura poderão ser igualmente conflitantes (por exemplo, o sistema deve ter todos os dados armazenados de forma centralizada no banco de dados do SQL Server E deve permitir que quaisquer dados sejam armazenados localmente no computador do usuário).

Na verdade, até agora tudo parece estar indo muito bem, você não acha? Afinal de contas, nós receberemos de volta um monte de respostas do fornecedor que nos mostrarão quem poderá oferecer todos os recursos de que necessitamos. Na verdade, até agora tudo parece estar indo muito bem, você não acha? Afinal de contas, nós receberemos de volta um monte de respostas do fornecedor que nos mostrarão quem poderá oferecer todos os recursos de que necessitamos.

Mas há um problema fundamental com o que venho descrevendo até o momento: Um problema que não ocorre quando você está usando o processo de RFP para uma mercadoria, e não para um sistema corporativo. Ele é o seguinte: um sistema corporativo é uma solução para um problema, mas, até aqui, não falamos nada sobre o problema. Isso acontece com tanta frequência no setor de tecnologia que passamos a considerar algo normal e aceitável.

Por que escolher um software corporativo dessa maneira não funciona

Consumidores têm usado esse método há décadas e ninguém o questiona, mas as pessoas que trabalham no ramo do software corporativo sabem que há um problema fundamental em usar o método clássico de RFP para escolher um software corporativo.

Em primeiro lugar, o simples fato de você ter uma lista gigantesca de recursos não significa necessariamente que está mais perto de solucionar um problema comercial. Na verdade, se você nem sequer articulou quais problemas comerciais específicos está tentando solucionar, então é mais provável que torne as coisas mais complicadas e em última análise piores, e não melhores. O processo de RFP foi criado para a compra de mercadorias. Quando temos produtos homogêneos como sapatos, batatas ou açúcar, então comprar tais itens dessa maneira pode resultar no concorrente mais barato e na melhor escolha entre os fornecedores em potencial. As respostas a uma RFP para produtos semelhantes tornam a comparação entre fornecedores em potencial muito simples. Quando as variantes para cada produto em oferta são infinitas (como o são no caso do software corporativo), então as respostas a uma RFP possuem um número infinito de variáveis, de modo que o processo gera resultados de pouco valor.

Quando usamos o método de RFP para escolher um sistema corporativo, as RFPs parecem em sua maioria umas iguais às outras. Isso é porque elas são todas criadas em resposta ao mesmo estímulo. O gerente de projeto pede uma lista “do que você irá precisar neste sistema corporativo”, e o único vocabulário que a maioria dos gerentes de nível médio possui para responder a essa solicitação é uma lista de recursos. Consequentemente, as respostas às RFPs parecem todas iguais. São uma lista de verificação de todos os recursos disponíveis tanto como parte do sistema, como quanto parte do sistema com algum trabalho.

O que é mais comum para as equipes de seleção é que elas recebam uma série de respostas a suas RFPs, analisem penosamente as centenas de páginas e, depois que terminam, não se sintam nem um pouco mais perto de uma solução do que quando começaram. Isso é terrivelmente frustrante para o comprador que dedicou um esforço tremendo para criar o que deveria ser uma boa solicitação de proposta e para avaliar as respostas, apenas para descobrir que foi tudo em vão.

Pior que tudo isso é o fato de vendedores empresariais experientes saberem que o processo trará resultados decepcionantes e estarem em ação desde o instante em que são informados de que uma RFP será criada. Eles não estão trabalhando nas respostas à RFP. Isso não é relevante. Em vez disso, estão trabalhando dois ou três níveis acima na estrutura de gerenciamento, em busca do impulso original que deu início à RFP. Eles estão procurando o executivo sênior que articulou algum desafio comercial e colocou as engrenagens para girar de modo que compradores e outras equipes da gerência de nível médio terminassem por criar a RFP e a enviassem para os fornecedores.

Quando as respostas à RFP não oferecem uma solução clara para os problemas comerciais que quase nunca são expostos durante o processo de compra, o vendedor empresarial está pronto para entrar em ação, fazendo com que um executivo sênior passe por cima de todo o processo e escolha um sistema baseado em sua própria relação pessoal com o vendedor empresarial sênior.

Se pensa que isso parece cinismo, está enganado. Na verdade, é mais fácil defender que um software seja escolhido através de relacionamentos pessoais no nível executivo do que através de um processo de RFP.

Mas e quanto a uma Prova de conceito ou um Piloto?

Então, nós sabemos que o processo de compra clássico não funciona quando aplicado à compra de software corporativo. Se é assim, como devemos escolher um software corporativo como um sistema de gerenciamento de projetos corporativos? Um método popular é usar o método da Prova de conceito ou Fase piloto.

Esses dois termos muitas vezes são usados como sinônimos, então vamos começar falando sobre o que é a implantação de uma Prova de conceito ou Piloto.

Prova de conceito   . Em uma Prova de conceito, a organização interessada implanta o software corporativo de forma limitada para provar que ela pode executar um desafio técnico quando há dúvidas quanto à capacidade da solução para superá-lo. Um exemplo possível é o volume de dados. “Não estamos seguros de que o produto consiga gerenciar a quantidade de tarefas que temos por projeto. Gostaríamos que nos trouxessem o software, pegassem dois ou três exemplos de projetos com 500 tarefas cada e nos mostrassem como eles podem ser carregados no software e que o software ainda é capaz de desempenhar suas tarefas básicas com todo este volume.”

Fase piloto   . Uma Fase piloto é uma instalação de um software corporativo, mas com um alcance limitado. A implantação de um piloto pode ser para um subconjunto de usuários; por exemplo, apenas 10 de 1.000 pessoas usarão o software de forma completa por um período de quatro semanas. Ou pode ser para uma subseção da funcionalidade, ou um subconjunto do volume de dados; por exemplo, apenas 10 de 500 projetos serão carregados.

Como é usada a Prova de conceito ou Fase piloto?    Um problema que surge com frequência é como a Fase piloto ou a Prova de conceito é aplicada. É muito raro que uma organização interessada entre em contato conosco para solicitar uma proposta de Prova de conceito já sabendo identificar qual conceito técnico precisa ser provado. “O que vocês pretendem provar e como poderemos avaliar que o provamos?”, nós perguntamos.

O mais comum é que alguém na gerência de nível médio tenha identificado um determinado software corporativo que eles esperam poder tornar suas vidas mais fáceis na organização. A gerência sênior não está de forma alguma envolvida, e a equipe da gerência de nível médio sequer articulou quais desafios corporativos pretendem superar. Eles esperam que, se a solução estiver por ali, da próxima vez que algum gerente de alto nível estiver passando pelo corredor ele verá “por acaso” a solução em funcionamento e aprovará no mesmo instante a implantação de um sistema corporativo. Pegando emprestada uma frase do filme Campo dos Sonhos: “se construirmos, eles virão”.

Seleção de fase piloto ineficaz

Isso quase nunca dá certo. O problema com um software corporativo é que você precisa do envolvimento da gerência sênior para tornar a implantação bem-sucedida. Os gerentes sênior é que serão os “clientes” dos relatórios e análises deste sistema corporativo. Os gerentes sênior é que precisarão fazer um investimento pessoal para conceder a uma fatia da equipe o tempo necessário para elaborar, configurar e receber treinamento para o software corporativo. Os gerentes sênior é que terão que aceitar a reformulação dos processos comerciais que são parte de qualquer implantação de um sistema corporativo, ou até ajudar nela. Sem que os gerentes sênior deem não só sua aprovação, mas também seu apoio implícito e assistência direta, nenhuma prova de conceito irá ajudar.

Isso também se aplica à fase piloto. Se a companhia não se comprometer desde os seus níveis mais altos a solucionar um determinado problema corporativo por meio do uso de um sistema corporativo, então a introdução de uma fase piloto não será produtiva.

Seleção de fase piloto efetiva

Isso não quer dizer que não há lugar para fases piloto em uma implantação. Elas desempenham um papel crucial em uma implantação bem-sucedida. O momento ideal é imediatamente após a decisão de compra ser tomada e o desenvolvimento do sistema corporativo ter sido concluído. A essa altura, a fase piloto é uma excelente oportunidade de testar o nosso modelo de sistema corporativo e fazer os últimos ajustes para a implantação geral.

Quando uma fase piloto é realizada na esperança de que quando a gerência vir o software em funcionamento ela irá escolhê-lo, isso resulta em um piloto ineficaz que não irá adiante no processo de seleção.

Como as organizações deveriam escolher um software corporativo?

Sistemas corporativos são comprados por organizações de médio e grande porte todos os dias e, enquanto o método de RFP pode não ser o mais eficaz, há vários métodos altamente eficazes de seleção de software corporativo. Veja algumas dicas para criar seu próprio e eficiente processo de seleção corporativa.

  • Articule o problema   . Antes de tudo, articule o problema. Isso significa que a gerência sênior deve estar envolvida e que o problema a ser articulado é corporativo, portanto, deve ser articulado em termos corporativos. Uma boa pergunta a fazer é: “Que decisão comercial não podemos tomar agora ou só podemos tomar com grande dificuldade, e que poderia ser facilitada com a implantação deste sistema corporativo como solução?”

    Pode haver uma série de desafios comerciais que você queira solucionar utilizando este sistema corporativo.

  • Ofereça aos fornecedores alguma liberdade para criar a solução   . Assim que os problemas comerciais tiverem sido articulados, entre em contato com fornecedores em potencial e certifique-se de que o acesso ao gerente sênior que ajudou no processo aconteça de forma transparente. Reuniões “secretas” entre fornecedores e a gerência sênior tornam-se impossíveis quando a gerência faz parte do processo desde o início. Deixe os fornecedores compreenderem o problema e permita que eles tenham alguma liberdade para oferecer respostas a ele. Você poderá descobrir mais do que imagina sobre a sua organização ao explicar como esses desafios comerciais o afetam, e certamente enxergará um leque muito mais amplo de soluções possíveis para o seu problema se não tentar descrever a solução para fornecedores em potencial.

    Ao falar com possíveis fornecedores de soluções, certifique-se de que eles entendam que devem abordar tanto o desafio tecnológico, quanto o desafio do processo comercial. Não há solução de um sistema corporativo que não tenha algum impacto no processo da organização. Se o fornecedor da solução não puder ajudá-lo com a maneira como o processo será afetado, então você só está olhando para parte da solução.

  • Fale diretamente com outras pessoas   . Quando você reduzir suas opções a um par de fornecedores de soluções em potencial, peça para falar com alguns de seus clientes atuais. Melhor ainda, pergunte ao fornecedor se ele se importaria que você visitasse alguns de seus clientes. Bons fornecedores de soluções geralmente possuem clientes que tiveram sucesso com suas próprias implantações e são generosos a ponto de abrir espaço em suas agendas para se reunirem com possíveis clientes.

    Você aprenderá mais se passar duas horas com um cliente que tenha experiência com a solução em potencial do que jamais aprenderia se estivesse lendo respostas a RFPs ou assistindo a demonstrações de vendas do fornecedor. Quando pedir ao fornecedor referências de outros clientes e para visitar suas instalações, você talvez pense que a companhia ideal para tanto seria uma idêntica à sua. Mas nem sempre é o caso.

Muitas vezes é extremamente valioso entrar em contato com empresas de outros setores que estejam relacionadas ou sejam de alguma forma semelhantes à sua. Você pode aprender muito de organizações maiores ou menores do que a sua própria. Dê mais importância a quanta experiência a organização possui com a solução do que à versão que ela está usando ou se ela é exatamente do mesmo tamanho ou setor do que o seu.

Se tiver a sorte de visitar um desses clientes, lembre-se de que ele não é o fornecedor Seja respeitoso, cortês e agradecido. Levar um pequeno presente, como algum material promocional da sua empresa, é geralmente bem visto. Quando estiver visitando a organização ou conversando com referências ao telefone, pode fazer algumas das seguintes perguntas:

  1. Qual processo você utilizou para escolher esta solução no lugar de outras?

  2. Que impacto esta solução teve em seus processos comerciais?

  3. Qual foi o aspecto mais desafiador da implantação?

  4. Qual foi o maior retorno sobre o investimento até o momento?

  5. Como vê a solução evoluir a partir daqui?

Não espere apenas respostas positivas.

Um fornecedor que seja totalmente incapaz de oferecer referências é necessariamente mais suspeito do que outro que tenha certo número de clientes satisfeitos.

Finalmente, depois que fizer a sua escolha, realize a implantação em fases. Você encontrará outros artigos desta coluna sobre como realizar uma implantação em fases, em vez de uma implantação em grande escala Isso reduzirá os riscos que existem em qualquer implantação de sistema corporativo e ajudará a ajustar o processo de implantação à medida que o sistema evolui.

Lembre-se de que qualquer implantação de sistema corporativo é um processo dinâmico. Não é uma decisão de uma só etapa com bons resultados garantidos mês após mês e para sempre. As implantações de sistemas corporativos mais bem-sucedidas começam com uma seleção que envolve membros-chave da equipe que farão parte do processo de implantação, desde o gerente mais sênior até o pessoal de campo mais tático, e prosseguem ao longo da evolução do sistema fase após fase.

A seleção eficaz de um sistema corporativo é apenas a primeira fase do processo.

Sobre o autor

Chris Vandersluis é presidente e fundador da HMS Software, com base em Montreal, Canadá, um parceiro certificado da Microsoft. Ele é formado em Economia pela McGill University e tem mais de 30 anos de experiência em automação de sistemas de controle de projetos. Membro do Project Management Institute (PMI), ele participou da fundação dos capítulos de Montreal, Toronto e Quebec do Microsoft Project Users Group (MPUG). As publicações para as quais Chris já escreveu incluem a Fortune, a Heavy Construction News, a Computing Canada e a PMNetwork, além de ser colunista regular da Project Times. Professor de Gerenciamento Avançado de Projetos na McGill University, frequentemente dá palestras sobre as funções da associação de gerenciamento de projetos na América do Norte e no mundo. A HMS Software é a fornecedora do sistema TimeControl de controle de horas orientado para projetos e tem sido Parceira de Soluções de Projetos da Microsoft desde 1995.

Chris Vandersluis pode ser contatado pelo email: chris.vandersluis@hms.ca.

Se quiser ler mais artigos relacionados a Gerenciamento de projetos corporativos (EPM) de Chris Vandersluis, consulte o site da HMS (http://www.epmguidance.com/?page_id=39).

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Office Insider

Essas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×