Os desafios na escolha do software empresarial
Este artigo faz parte da nossa coleção "From the Trenches". Ele descreve como as implementações do sistema empresarial precisam ser capazes de se adaptar e evoluir para serem bem-sucedidas.
Para baixar a versão Word deste artigo, confira Os Desafios de Selecionar Software Empresarial.
Para ver mais artigos, consulte white papers "From the Trenches".
Os desafios da seleção do software empresarial
Acontece por aqui o tempo todo. Um cliente envia uma RFP ("Solicitação de Proposta" para o escritório com instruções para concluir uma resposta em alguns dias ou semana e enviá-la de volta para ter nosso sistema empresarial considerado para compra. RfPs praticamente todos parecem iguais. Geralmente há uma breve visão geral, instruções sobre o que você precisa fazer para que sua resposta seja considerada, incluindo como ela precisa ser formatada e quando enviá-la de volta, etc. Em seguida, há uma longa grade de recursos que são necessários e uma série de perguntas adicionais de ensaio para escrever respostas.
O desafio com RFPs é que eles não eram idealmente adequados para selecionar software corporativo e o que se segue quando um processo RFP é seguido não garante as melhores decisões para a organização. Os RFPs foram projetados pela comunidade compradora como uma maneira de obter a melhor mercadoria com o melhor preço e ainda fazem um ótimo trabalho disso. Quando as ofertas são comparáveis, o processo de tomada de decisão pode se concentrar no melhor preço com apenas uma ou duas variáveis adicionais (como datas de envio) para enfrentar. Quando as possíveis soluções estão na mesma categoria geral, mas não são comparáveis (como é o caso do software empresarial), o número de variáveis que devem ser consideradas pelos compradores é enorme e o processo RFP não agrega valor à seleção. Como a maioria das empresas seleciona o software empresarial Vamos começar analisando o processo que acontece o tempo todo em qualquer fornecedor ou provedor de soluções de software corporativo. Falarei sobre software de gerenciamento de projetos corporativos ou software de folha de tempo da empresa, pois é isso que minha empresa fornece, mas o paradigma é o mesmo para praticamente qualquer seleção do sistema empresarial.
Como a maioria das empresas seleciona software empresarial
Vamos começar analisando o processo que acontece o tempo todo em qualquer fornecedor ou provedor de soluções de software corporativo. Falarei sobre software de gerenciamento de projetos corporativos ou software de folha de tempo da empresa, pois é isso que minha empresa fornece, mas o paradigma é o mesmo para praticamente qualquer seleção do sistema empresarial.
Na maioria das organizações, o impulso para procurar software corporativo vem de algum problema. Talvez o problema seja apresentado pelo pessoal do campo. Talvez o problema seja identificado por alguém da alta administração. No entanto, a iniciativa tem que obter apoio de alguém da alta administração. A seleção popular de um sistema que afetará toda a empresa é uma fantasia até mesmo nas organizações mais progressistas. Então um gerente sênior decide: "Precisamos desse tipo de sistema empresarial.".
O processo de seleção de software empresarial típico é assim:
O gerenciamento diz que precisamos de um novo sistema empresarial
O gerenciador de projetos está selecionado
Solicitar solicitações de todos os departamentos envolvidos
Mesclar todas as solicitações em uma planilha grande
Enviar a grade de requisitos para muitos fornecedores
Obter muitas respostas
Lista curta
Assistir a demonstrações
Negociar
Obter aceitação de gerenciamento
Fazer com que o gerenciamento decida sobre outra coisa
Um gerente de projeto para o esforço de seleção é voluntário. Ele ou ela faz o que todos nós fazemos — vá para a Internet, carregue um mecanismo de pesquisa e digite "EPM Software" (ou qualquer sistema empresarial desejado). Imediatamente, meio milhão de acessos são retornados. Talvez o gerente de projeto diligente surfe a primeira dúzia ou mais para saber que tipo de sistemas podem estar disponíveis antes de seguir em frente. Claramente ninguém tem tempo para navegar por meio milhão ou mais acessos para ver se talvez o último seja o sistema ideal para a organização.
Sem medo, o gerente de projeto agora reúne um comitê de seleção entre aqueles que serão afetados pela implementação desse novo sistema empresarial. Alguns dos que estão no comitê podem ser de entre os funcionários de campo que identificaram a necessidade na organização em primeiro lugar. Outros podem não. Pode haver uma mistura de pessoas neste comitê de seleção que têm diversos interesses em que tipo de sistema será selecionado.
O infeliz gerente de projetos agora solicita a cada membro do comitê para sondar seu grupo representativo para o que eles exigem no novo sistema empresarial. Como cada representante do comitê faz isso? Bem, em primeiro lugar, nem todos se esforçam, mas para aqueles que fazem o dever de casa, eles pedem à sua equipe para enviar uma lista de recursos que eles achariam importantes. Em seguida, eles também chegam à Internet e navegam em alguns sites de fornecedores. Eles podem copiar e colar de recursos que veem nos folhetos desses sites, pois cada site lhes dá novas ideias de que tipos de solicitações eles podem ser capazes de fazer de um novo sistema.
Agora o comitê é remontado e a planilha longa de cada membro do comitê é mesclada com os outros em uma planilha maciça. A mega planilha de requisitos é categorizada, mas há desafios. Em primeiro lugar, as diversas necessidades do comitê agora se tornam mais evidentes à medida que os recursos são solicitados de uma ampla gama de perspectivas. Pode haver membros do comitê em diferentes departamentos, mas também em diferentes países/regiões ou até mesmo em divisões diferentes. Há quase sempre uma solicitação que está em conflito com outra solicitação na mesma lista (por exemplo, o sistema deve ser muito fácil 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).
Por fim, a planilha combinada que os fornecedores verão está concluída. Ele tem centenas de solicitações de recurso e, para cada uma, espera-se que o fornecedor diga "Sim", "Não" ou "Sim com algum esforço". Um sistema de ponderação também pode ser anexado para dizer se esse recurso é um "Obrigatório", um "Importante para ter" ou um "Nice-to-have".
O RFP está quase pronto para ir. Haverá algumas perguntas de ensaio, geralmente sobre a arquitetura técnica da seleção e, dependendo de quantas pessoas foram pesquisadas sobre esses requisitos, as solicitações de arquitetura podem ser igualmente conflitantes (por exemplo, o sistema deve ter todos os dados armazenados centralmente no banco de dados SQL Server ¬e¬ o sistema deve permitir que todos os dados sejam armazenados localmente no computador do usuário).
Na verdade, está soando muito bem até agora, não acha? Afinal, vamos receber de volta um monte de respostas do fornecedor que mostram quem pode entregar todos os recursos que precisaremos. Na verdade, está soando muito bem até agora, não acha? Afinal, vamos receber de volta um monte de respostas do fornecedor que mostram quem pode entregar todos os recursos que precisaremos.
Mas há realmente um problema fundamental com o que descrevi até agora: um problema que não ocorre quando estamos usando o processo RFP para uma mercadoria em vez de um sistema empresarial. É isso: um sistema empresarial é uma solução para algo. Mas não dissemos nada até agora sobre o problema. Essa é uma ocorrência tão comum que a indústria de tecnologia passou a aceitá-la como normal e aceitável.
Por que selecionar o software corporativo dessa forma não funciona
Os compradores usam esse método há décadas e ninguém o questiona, mas as pessoas no negócio de software empresarial sabem que há um problema fundamental com o método rfp clássico de selecionar software empresarial.
Em primeiro lugar, só porque você tem uma lista extremamente longa de recursos, isso não significa necessariamente que você esteja mais perto de resolver um problema de negócios. Na verdade, se você ainda não articulou quais problemas comerciais específicos você está tentando resolver, então é provável que você torne as coisas mais complexas e, em última análise, piores, não melhores. O processo RFP foi projetado para comprar mercadorias. Quando temos produtos homogêneos como sapatos, batatas ou açúcar, então comprar esses itens dessa forma pode resultar no licitante de menor custo e na melhor seleção entre os possíveis fornecedores. As respostas a um RFP para uma mercadoria semelhante facilitam muito a comparação de possíveis fornecedores. Quando as variáveis para cada produto na mistura são infinitas (como são com o software empresarial), as respostas ao RFP têm um número infinito de variáveis também e o processo gera resultados que têm pouco valor.
Quando usamos o método RFP de selecionar sistemas empresariais, os RFPs geralmente são todos iguais. Isso ocorre porque todos eles são criados em resposta ao mesmo estímulo. O gerenciador de projetos solicita uma lista de "o que você precisará neste sistema empresarial" e o único vocabulário que a maioria dos gerentes intermediários precisa responder a essa solicitação é uma lista de recursos. Consequentemente, as respostas aos RFPs são todas iguais. Eles são uma lista de verificação de todos os recursos disponíveis como parte do sistema ou como parte do sistema com algum esforço.
O que é mais comum para as equipes de seleção é que eles receberão uma série de respostas aos seus RFPs, eles percorrerão as centenas de páginas e, quando terminarem, não se sentirão mais próximos de uma solução do que quando começarem. Isso é terrivelmente frustrante para os compradores que se esforçaram enormemente na criação do que deveria ser um pedido justo de proposta e na avaliação das respostas apenas para descobrir que o exercício era em vão.
Pior do que tudo isso é que vendedores empresariais experientes sabem que o processo produzirá resultados frustrantes e estão no trabalho a partir do momento em que ouvirem que haverá uma RFP criada. Eles não estão trabalhando na resposta RFP. Isso não é relevante. Em vez disso, eles estão trabalhando dois ou três níveis mais altos na estrutura de gerenciamento, procurando o impulso original que iniciou o RFP. Eles procuram o executivo sênior que articulou algum desafio de negócios e colocou as rodas em movimento para que os compradores e outras equipes de gerenciamento médio finalmente criassem o RFP e o enviassem aos fornecedores.
Quando as respostas rfp acabam sem uma resposta clara para os problemas de negócios que quase nunca são articulados no processo de compra, o vendedor corporativo está pronto para entrar em ação, tendo um executivo sênior ignorando completamente o processo e selecionando um sistema com base em sua própria relação pessoal com o vendedor sênior da empresa.
Se você acha que isso parece cansado, você está errado. Na verdade, você pode criar um caso melhor para ter o software selecionado por meio de relações pessoais no nível executivo do que pode para comprar por meio do processo RFP.
Mas e uma prova de conceito ou piloto?
Portanto, sabemos que o processo de compra clássico é falho quando o aplicamos à compra de software corporativo. Se esse for o caso, como devemos escolher o software empresarial, como um sistema de gerenciamento de projetos corporativos? Um método popular é usar o método Proof of Concept ou Pilot Phase.
Esses dois termos geralmente são usados sinônimos, então vamos começar falando sobre o que é uma Prova de Conceito ou uma implantação piloto.
Prova de Conceito. Em uma Prova de Conceito, a organização em potencial implanta o software empresarial de forma limitada, a fim de provar que pode realizar um desafio técnico em que há alguma questão sobre a capacidade da solução de superar esse desafio. Um exemplo pode ser para o volume de dados. "Estamos preocupados que o produto possa não ser capaz de lidar com tantas tarefas quanto temos por projeto. Gostaríamos que você viesse com o software, pegue dois ou três projetos de exemplo com 500 tarefas cada e nos mostre como eles podem ser carregados no software e que o software ainda pode executar suas funções básicas com esse volume nele.".
Fase Piloto. Uma Fase Piloto é uma instalação do software empresarial, mas com um escopo limitado. Uma implantação piloto pode ser para um subconjunto de usuários; por exemplo, apenas 10 em cada 1000 pessoas usarão o software totalmente 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 dos 500 projetos serão carregados.
Como a Prova de Conceito ou Fase Piloto é usada? O problema que geralmente é encontrado é como a Fase Piloto ou a Prova de Conceito é aplicada. É muito raro quando uma organização em potencial chama e nos pede uma proposta de Prova de Conceito e também pode identificar qual conceito técnico precisa ser comprovado. "O que você está esperando provar e como seremos capazes de medir que provamos isso?", perguntamos.
O mais comum é que alguém no gerenciamento intermediário identificou um software corporativo que espera facilitar suas vidas em sua organização. A alta administração não está envolvida, e a equipe de gerenciamento médio nem sequer articulou quais desafios empresariais estão tentando superar. É sua esperança que, se a solução estivesse apenas no prédio, que na próxima vez que alguém da administração vagasse pelo corredor, eles veriam "acidentalmente" a solução em operação e dariam instantaneamente sua bênção a uma implantação empresarial. Para emprestar uma frase do filme Campo dos Sonhos, "Se construí-lo, eles virão."
Raramente é bem sucedido. O problema com o software empresarial é que precisamos do envolvimento da alta administração para tornar a implantação um sucesso. É o gerenciamento sênior que será o 'cliente' dos relatórios e análises desse sistema empresarial. É o gerenciamento sênior que precisará investir pessoalmente para permitir a um intervalo de funcionários o tempo necessário para projetar, configurar e ser treinado no software corporativo. É a alta administração que terá que aceitar ou até mesmo ajudar a redesenhar os processos de negócios que fazem parte de qualquer implantação do sistema empresarial. Sem a alta administração dando não apenas sua bênção, mas também seu apoio implícito e assistência direta, nenhuma prova de conceito ajudará.
Isso também é verdade para uma fase piloto. Se a empresa não se comprometeu do mais alto nível a resolver algum problema de negócios por meio do uso de software corporativo, a introdução de uma fase piloto não será produtiva.
Isso não quer dizer que as fases piloto de uma implantação não tenham lugar. Eles carregam um ponto crítico em uma implantação bem-sucedida. Esse local é imediatamente após a conclusão da decisão de compra e a conclusão do design do sistema empresarial. Agora, uma fase piloto faz um ótimo lugar para testar nosso design do sistema empresarial e ajustá-lo para implantação geral.
Quando uma fase piloto é feita na esperança de que ver o software em ação resultará em gerenciamento selecionando-o, então temos um Piloto ineficaz e não obteremos mais adiante no processo de seleção.
Como as organizações devem selecionar o software empresarial?
Os sistemas empresariais são comprados por organizações de médio e grande porte todos os dias e, embora o método RFP possa não ser o mais eficaz, há vários métodos de seleção de software corporativo que são muito eficazes. Aqui estão algumas dicas para criar seu próprio processo de seleção empresarial eficaz.
Articular o problema. Em primeiro lugar, articule o problema. Isso significa que a alta administração deve estar envolvida e o problema de articulação é um problema comercial, por isso deve ser articulado em termos comerciais. Uma boa pergunta a ser feita é: "Que decisão de negócios não podemos tomar agora ou podemos tomar apenas com grande dificuldade, cujo uso poderia ser facilitado com a implantação dessa solução do sistema empresarial?"
Pode haver uma série de desafios de negócios que você deseja resolver com o uso desse sistema empresarial.
Dê aos fornecedores alguma latitude para criar a solução. Depois que o problema ou os problemas de negócios tiverem sido articulados, entre em contato com possíveis fornecedores e verifique se o acesso à alta administração que ajudou no processo é transparente. As reuniões de fornecedores "secretas" com a alta administração tornam-se impossíveis quando o gerenciamento faz parte do processo desde o início. Deixe que os fornecedores entendam o problema e dê a eles alguma latitude para respondê-lo. Você pode descobrir mais sobre sua organização ao explicar como esses desafios de negócios afetam você do que você imagina e certamente verá uma gama muito maior de soluções possíveis para o seu problema quando você não tentar descrever a solução para os fornecedores em potencial.
Ao conversar com possíveis provedores de soluções, verifique se eles entendem que eles devem falar com a tecnologia e o desafio do processo de negócios. Nunca houve uma solução do sistema empresarial que não tenha tido algum impacto no processo da organização. Se o provedor de soluções não puder ajudar na forma como o processo será afetado, você só está olhando para parte da solução.
Vá conhecer algumas pessoas. Quando você chegar a alguns provedores de soluções possíveis, peça para conversar com alguns de seus clientes existentes. Melhor ainda, confira se o fornecedor permitirá que você visite alguns de seus clientes existentes. Os bons provedores de solução geralmente têm clientes que tiveram sucesso em suas próprias implantações e que são generosos o suficiente para ter tempo para atender clientes em potencial.
Você aprenderá mais com algumas horas com um cliente experiente da possível solução do que jamais teria aprendido lendo respostas RFP ou olhando para demonstrações de vendas do fornecedor. Quando você pede ao fornecedor possíveis referências de cliente e visitas ao site, você pode pensar que a empresa ideal para atender seria exatamente como a sua. Nem sempre é assim.
Muitas vezes é extremamente valioso conhecer empresas em outros setores que estão relacionadas ou um pouco semelhantes às suas. Você também pode aprender muito com organizações maiores ou menores do que você. Coloque mais ênfase na experiência que a organização teve com a solução em vez de em que versão eles estão usando ou se eles são do tamanho exato ou na indústria exata em que você está.
Se você tiver a sorte de visitar um cliente existente, lembre-se de que ele não é o fornecedor. Seja respeitoso, corês e grato. Trazendo um pequeno presente, talvez o material promocional do logotipo da empresa seja muitas vezes bem apreciado. Enquanto você estiver com a organização ou enquanto estiver conversando com referências no telefone, algumas possíveis perguntas podem incluir:
Qual processo você usou para selecionar essa solução em vez de outras pessoas?
Qual impacto essa solução teve em seus processos comerciais?
Qual foi o aspecto mais desafiador da implantação?
Qual foi o retorno mais valioso do investimento até agora?
Como você vê a solução evoluindo daqui?
Não espere apenas respostas felizes.
Um fornecedor que não consegue fornecer referências tem que ser um pouco mais suspeito do que um que tenha vários clientes satisfeitos.
Por fim, quando você fizer sua seleção, implante em fases. Você pode encontrar outros artigos nesta coluna sobre como implantar em um modo em fases versus big-bang. Isso atenuará os riscos envolvidos em qualquer implantação do sistema empresarial e ajudará a ajustar o processo de implantação à medida que o sistema evolui.
Lembre-se de que qualquer implantação do sistema empresarial é um processo dinâmico. Não é uma decisão única com resultados felizes chegando mês após mês para sempre. As implantações empresariais mais bem-sucedidas começam com uma seleção que envolve o pessoal-chave que fará parte do processo de implantação desde o mais sênior em gerenciamento até o mais tático no campo e continuar pela evolução do sistema em fase após fase.
Uma seleção efetiva do sistema empresarial é apenas a primeira fase do processo.
Sobre o autor
Chris Vandersluis é presidente e fundador da Montreal, hms software com sede no Canadá, um parceiro certificado pela Microsoft. Ele é formado em economia pela Universidade McGill e tem mais de 30 anos de experiência na automação de sistemas de controle de projetos. Ele é membro de longa data do PMI (Project Management Institute) e ajudou a fundar os capítulos montreal, Toronto e Quebec do Grupo de Usuários do Projeto Microsoft (MPUG). As publicações para as quais Chris escreveu incluem Fortune, Heavy Construction News, Computing Canada magazine, e PMNetwork do PMI, e ele é um colunista regular do Project Times. Ele ensina Gerenciamento Avançado de Projetos na Universidade McGill e frequentemente fala em funções de associação de gerenciamento de projetos em América do Norte e em todo o mundo. O HMS Software é o editor do sistema de timekeeping orientado ao projeto TimeControl e é um Parceiro de Solução de Projeto da Microsoft desde 1995.
Chris Vandersluis pode ser contatado por email em: chris.vandersluis@hms.ca
Se você quiser ler mais artigos relacionados ao EPM por Chris Vandersluis, consulte o site de Diretrizes do EPM do HMS (https://www.epmguidance.com/?page_id=39).