Share via


Como ser um comprador de soluções

Este artigo faz parte da nossa coleção "From the Trenches". Ele descreve como os potenciais compradores de software podem tornar as interações com fornecedores de software mais eficazes aplicando métodos de análise de negócios facilmente compreendidos. Ele orienta você através de um exercício que pode ajudar a criar critérios de avaliação de software determinando efetivamente quais problemas precisam ser resolvidos pela solução de software.

Para ver mais artigos, consulte white papers "From the Trenches".

Ser um comprador de soluções

Muitas vezes, uma compra de software é baseada em uma lista de recursos, uma campanha publicitária ou uma recomendação de um amigo. Este artigo descreve como os potenciais compradores de software podem tornar as interações com fornecedores de software mais eficazes aplicando métodos de análise de negócios facilmente compreendidos.

Com certeza não é como costumava ser. Fazer com que o software funcione em uma configuração corporativa nem é mais chamado de instalação. Atualmente, os termos de implementação ou implantação descrevem melhor o que é necessário para colocar um novo pacote em execução.

Cada vez mais fornecedores de software estão falando sobre o que vendem como soluções, e não é de admirar. Quando pensamos em implantar um sistema empresarial como o Microsoft Project Server ou Microsoft CRM, primeiro temos que pensar nas diferentes camadas de tecnologia que estarão envolvidas e, antes mesmo de chegarmos a isso, temos que pensar no impacto em nossos negócios gerais.

Com soluções para vender vem, é claro, vendas de soluções. Se você seguiu isso, sabe que quase todas as organizações de alta tecnologia do planeta que visam organizações de médio e grande porte estão trabalhando para se recriar como um entregador de vendas de soluções. A Microsoft certamente está entre essas organizações. A Microsoft tem trabalhado extensivamente nos últimos anos para estabelecer soluções que vendem como um princípio norteador em suas forças de vendas e implementação de campo.

Então, o que é um vendedor de soluções? É verdade que ainda são vendedores. No entanto, os vendedores de soluções visam não apenas mover uma caixa de software, mas criar algo que ajude o cliente a melhorar sua situação.

Parece ótimo até agora; um Nirvana de vendedores todos procurando melhorar seu lote na vida. Mas isso vem com um desafio e abordar esse desafio é algo em que você, o cliente em potencial, pode participar.

Focando no problema

O desafio que a maioria das soluções que os vendedores enfrentam quando chegam ao mercado é nosso preconceito sobre como uma solução deve ser. Estamos tão acostumados a nos concentrar em funções e recursos de software, quando falamos com um vendedor de software que a conversa quase inevitavelmente leva diretamente a: "Seu software pode fazer isso? Seu software pode fazer isso?" Vendedores de software experientes — e esses são os tipos que são movidos para posições de venda de soluções — estão tão acostumados a vender funções e recursos que muitas vezes esquecem de fazer a pergunta mais básica de todas: "Qual é o problema?"

Isso pode parecer bobagem, mas se você pensar em suas últimas conversas com vendedores de software, talvez se surpreenda com o quão raramente essa pergunta aparece. Fornecedores como a Microsoft e seus parceiros recebem muitas solicitações de propostas a cada ano. Eu vi centenas deles ao longo dos anos, e uma coisa que está quase sempre presente é uma longa grade de funções que o fornecedor deve preencher. Essa planilha grande geralmente é o núcleo da resposta ao cliente.

O que raramente está presente é uma descrição das necessidades de negócios que serão abordadas por cada uma dessas funções. É tão fácil se envolver em um recurso que estamos familiarizados com um produto anterior ou que vimos promovido em algum lugar que é preciso disciplina real para se concentrar no que nos interessou por este novo produto em primeiro lugar. Isso pode ser especialmente assim em uma configuração corporativa em que há muita entrada em que tipo de solução está sendo procurada. É muito mais fácil enviar uma solicitação pedindo que as pessoas listem todas as funções que gostariam em um novo sistema de software do que falar sobre suas necessidades comerciais específicas.

Se você está começando a pensar que talvez você tenha perdido algo óbvio, você não está sozinho. Essa condição é tão prevalente no setor de software no momento que uma nova categoria de consultor chamada Business Analyst surgiu. Essas pessoas são treinadas para fazer com que a conexão das empresas precise para a funcionalidade de software. Vamos levar alguns minutos para ver como você pode aplicar os conceitos básicos, da maneira que um Analista de Negócios os aplicaria, em suas avaliações de software de nível empresarial.

Identificar a necessidade de negócios

A primeira coisa a pensar é sobre o que os negócios precisam que você procure por um novo sistema de software em primeiro lugar. Nossa própria organização geralmente consulta empresas na implementação de software de gerenciamento de projetos corporativos. Quando chego a uma organização como consultor, muito antes de falarmos sobre se compraremos software, pergunto como a organização está fazendo o gerenciamento de projetos agora.

Quando eles terminam a resposta, eu sempre faço esta pergunta de acompanhamento: "Esse método está funcionando para você?" Surpreendentemente, o cliente geralmente responde que é. Para mim, a conversa de implementação tem que parar por aí. "Se não houver problema", eu explico, "não há como eu criar uma solução!" Muitas vezes, essa resposta faz as pessoas pausarem. "Por que fomos chamados?" Eu vou perguntar. As respostas podem variar bastante, e não é incomum que as pessoas olhem ao redor da sala percebendo que há várias agendas em andamento que devem ser reconciliadas e nossa conversa tem menos de cinco minutos!

Então, perguntar "Qual é a nossa necessidade de negócios?" é um ótimo lugar para começar. Há quase sempre uma meta geral que responde a essa pergunta: uma meta que iniciou a iniciativa em primeiro lugar.

Realizando um exercício de visão

Em seguida, você precisará examinar um pouco mais profundamente o que isso significa em termos de funcionalidade de software. Quando implementamos o software de gerenciamento de projetos corporativos como o Microsoft Project Server em uma organização, sempre começamos com um exercício de visão que envolve o pessoal-chave , aqueles que estão avaliando o software e o gerenciamento sênior, aqueles que estão patrocinando o exercício. Não basta fazer esse exercício apenas com pessoal técnico, pois o objetivo deste exercício é conectar metas de negócios a funções técnicas.

Aqui está uma maneira eficaz de fazer isso: colocar o pessoal da chave em uma sala com um grande quadro de brancos. Divida o quadro em 4 colunas: comece com um título apenas na coluna de extrema direita. Chame de "Decisão comercial".

Quadro de dados com quatro colunas, incluindo uma coluna Decisão comercial.

Na coluna à direita, você lista as decisões de negócios que espera tomar usando o novo sistema que está considerando. Quando fazemos isso com um cliente, a primeira coisa que as pessoas querem fazer é listar muitos recursos, então você terá que insistir que as respostas que são importantes são decisões de negócios. Por exemplo, um participante pode dizer imediatamente: "Preciso de uma lista de todos os recursos e sua carga de trabalho". Isso pode ser verdade, é claro, mas o que você precisa descobrir é qual decisão de negócios eles tomarão com essa lista.

Alguns exemplos de decisões comerciais podem ser:

  • Contratação ou demissão em um departamento específico

  • Tomando uma decisão ir ou não em um projeto

Coluna Whiteboard com Decisões empresariais e uma lista de decisões de negócios.

Depois de ter uma lista decente de decisões de negócios, pausar. Agora é um bom momento para revisar a lista de decisões empresariais e identificar as decisões de prioridade máxima. Você pode querer fazer esta pergunta a si mesmos: se você só pudesse obter respostas para uma dessas decisões de negócios, o que entregaria mais valor à organização? Escolher as três principais decisões é sempre mais fácil neste momento do processo.

Se você chegou até aqui, já realizou mais do que a maioria das organizações que buscam software de gerenciamento de projetos corporativos. Ser capaz de fornecer uma lista priorizada das decisões de negócios mais significativas para fornecedores de sistemas é um grande passo em frente para todo o processo. Quando você pode dizer aos fornecedores do sistema quais decisões de negócios você precisa tomar, eles têm o poder de ir além de falar sobre funcionalidade simples para falar sobre como tornar a organização mais eficaz.

Em seguida, olhe para cada decisão e pergunte: "Para tomar essa decisão comercial, que relatório você exigiria?" Praticamente todas as decisões são tomadas depois de examinar um ou mais relatórios. Rotule a 3ª coluna "Relatório". Para cada uma das três principais decisões, liste nessa coluna os relatórios necessários para a decisão correspondente.

Por exemplo, podemos dizer que, para determinar se devemos contratar ou demitir pessoal para um determinado departamento, precisamos de um relatório por departamento mostrando os dados de planejamento de capacidade de recursos. Isso inclui uma previsão avançada da carga de trabalho esperada, disponibilidade de recursos esperada e agendamento. Se você é um negócio de médio porte, o fluxo de caixa também pode ser uma preocupação. Você pode, por exemplo, ter uma necessidade de pessoal adicional, mas não conseguir encontrar o dinheiro para contratá-los. O relatório de fluxo de caixa incluiria rendimentos estimados e saídas de dinheiro com um saldo em execução.

Quadro de dados com uma coluna Decisão de Relatório e Negócios.

Se preenchermos a coluna Relatório para cada uma das decisões que identificamos como nossas prioridades, a forma do que exigiremos já está começando a ficar clara. Depois de terminar, você tem uma lista de saída física que você precisa do seu sistema em potencial.

Pausar novamente aqui para descobrir se já há relatórios do tipo que você já identificou em uso na organização. As chances são de que esses relatórios existam, mas em vários formatos e possivelmente com dados incompletos ou com esforço excessivo necessário para gerá-los. Se você encontrar formatos de relatórios que funcionaram na organização, poderá adicioná-los à sua lista de requisitos de sistemas. Agora você pode fornecer ainda mais informações aos fornecedores do sistema.

Com os principais relatórios agora identificados, podemos mover para os elementos de um sistema necessário para gerar esses relatórios. Adicione o título "Analysis" à 2ª coluna do gráfico. Para cada relatório, identifique as análises ou algoritmos necessários para gerar o relatório. Por exemplo, para um relatório de planejamento de capacidade de recursos, podemos exigir um cronograma de caminho crítico do sistema de gerenciamento de projetos e uma análise de nivelamento de recursos.

Quadro de dados com colunas Análise, Relatório e Decisão empresarial.

Essas análises geralmente são comercializadas por fornecedores com base na miríade de recursos que cada um inclui. (Sim, a venda de recursos por recurso ainda está viva e bem!) O que você precisa ser capaz de determinar é a funcionalidade mínima que fornecerá os relatórios necessários com os quais você pode tomar ou melhorar a decisão comercial que você identificou. Você pode se surpreender com o quão básica é a funcionalidade necessária para atender aos seus requisitos de negócios reais. Para alguns relatórios, nenhuma análise ou cálculo será necessário; os relatórios precisam ser apenas agregações simples que podem ser geradas diretamente dos dados do novo sistema.

Por fim, chegamos à primeira coluna em nosso gráfico. Depois de identificar as análises necessárias, você pode mover para determinar quais elementos de dados são necessários para alimentar as análises.

Adicione o título "Entrada" à 1ª coluna do gráfico.

No exemplo que estamos usando, podemos exigir uma lista completa de tarefas para cada projeto implicado no trabalho do departamento. Isso pode muito bem ser todos os projetos da organização. Também precisaremos de um perfil completo da disponibilidade de cada recurso, juntamente com a carga de trabalho definida em cada tarefa, de modo que, quando a tarefa se move na análise de agendamento, a carga de trabalho se move na análise de nivelamento de recursos. Além disso, lembra como começamos com a decisão de contratar ou demitir em um determinado departamento? Também precisamos ser capazes de identificar os recursos por departamento.

Quadro de dados com colunas Entrada, Análise, Relatório e Decisão Empresarial.

Podemos mover assim das saídas à direita para as entradas à esquerda até identificarmos tudo o que precisaremos em nosso novo sistema empresarial.

Avaliando riscos

Depois que esse exercício for concluído, vale a pena voltar para cada uma das entradas e determinar a disponibilidade desses elementos de dados. Você pode descobrir, como costumamos fazer, que alguns desses itens nem sequer existem. Por exemplo, algumas organizações não mantêm uma lista completa de disponibilidade de recursos. Você também pode descobrir que nem todo projeto tem uma agenda carregada de recursos mostrando a carga de recursos gerada por esse projeto. Em muitas organizações, certos tipos de projetos não são colocados em um sistema de qualquer tipo. Trabalho de emergência, trabalho de suporte técnico ou trabalho de manutenção regular são alguns exemplos comuns.

Se você não tiver acesso aos dados fundamentais necessários para fornecer o valor comercial, você terá que examinar esse elemento do sistema como de alto risco. Por exemplo, se descobrirmos que podemos identificar agendamentos carregados de recursos para 80% dos projetos da organização, podemos razoavelmente esperar melhorar nossa decisão comercial de aumentar ou diminuir a equipe? A resposta é provável, "Não". Porque? Porque talvez os 20% dos projetos que não estão no sistema possam representar 80% da carga de trabalho para um determinado departamento. Se você não tiver todos os dados, nunca saberá se o relatório final é preciso.

Há maneiras de contornar esse tipo de problemas, é claro. Um método é isolar todos os processos de negócios desses aspectos da organização em que você não pode obter acesso aos elementos de dados. Uma divisão cujos projetos podem não estar no sistema também não teria seus recursos listados. Isso não pode ser feito simplesmente em todos os casos; você terá que procurar item por item para descobrir quanto risco esses processos empresariais e decisões de negócios são para sua implementação. Não é incomum neste momento no processo priorizar novamente as decisões finais de negócios que você espera melhorar. Você pode ter uma decisão que é muito desejável, mas acaba por ser um risco muito alto e, portanto, não vale a pena prosseguir nas fases iniciais de sua implantação.

Documentando o que você fez

Ao realizar esse tipo de reunião, atribua um escriba — alguém cujo trabalho será gravar anotações e comentários durante todo o processo. As razões pelas quais uma determinada decisão comercial foi classificada como de alta ou baixa prioridade ou por que algo foi considerado de alto risco serão rapidamente esquecidos se você não tiver boas notas para se referir.

É muito importante registrar:

  • O que você escreveu no quadro de texto

  • Quem participou do processo

  • Quem é o dono de cada decisão de negócios final

Se você está se sentindo sobrecarregado neste momento, não tenha medo. Todo esse exercício pode ser realizado muito rapidamente, mesmo nas maiores organizações. Não é incomum poder concluir todo o processo em um ou talvez dois dias. A chave para ser bem-sucedido é colocar o nível certo de gerenciamento na sala. Além disso, esse tipo de reunião é melhor facilitado por alguém de fora da organização que não está predisposto a fazer as coisas da maneira que sempre foi feito.

Do saber vem o ter

Se você estiver olhando para sistemas de gerenciamento de projetos empresariais, de fato, em sistemas empresariais de qualquer tipo, concluir esse exercício lhe dará uma enorme quantidade de energia ao interagir com fornecedores de sistemas de software. Você pode distinguir imediatamente entre esses elementos de um sistema que são importantes para você e aqueles que não são. Os fornecedores de software podem ser fornecidos com a lista de relatórios e decisões que você deseja tomar.

Você pode se surpreender com algumas das respostas que voltam para você dos fornecedores. Liberados para responder de uma maneira diferente de uma base de recursos por recurso, ou seja, tentando encaixar uma função quadrada em um requisito redondo, os melhores fornecedores poderão mostrar como você pode responder aos seus desafios comerciais usando seus sistemas com a melhor vantagem deles.

Aqui está o maior benefício da realização deste exercício: você criou critérios de avaliação prontos. Agora, durante a fase de prova de conceito, você pode se concentrar imediatamente em saber se o sistema fornece as informações necessárias para melhorar as decisões de negócios que você deve tomar.

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).