Soluções, soluções…
Segundo o BABOK 2.0 uma solução é “um conjunto de mudanças no estado atual da organização que são feitas com o intuito de permitir que ela atenda a uma necessidade do negócio, resolva um problema ou se beneficie de uma oportunidade”.
O mais importante a respeito de soluções, fora a sua relação com a necessidade do negócio, claro, é que “grande parte das soluções envolve um sistema de componentes de solução que interagem entre si e cada componente é potencialmente uma solução em si mesmo”.
Digamos que nossa empresa preste atendimento pós-vendas, ou suporte também via telefone para os clientes atuais (caso real).
A empresa tem como meta anual um acréscimo no volume de venda sobre a sua base de clientes (clientes atuais), ela quer vender mais para quem já é cliente, ou seja, conseguir uma parcela maior da carteira dele (share of wallet).
Alguém do pós-venda e suporte lembrou que é comum clientes expressarem desejo por incrementos nos produtos atuais ou até mesmo novos produtos durante as interações do pós-venda e suporte, mas que os atendentes não sabem exatamente como proceder.
Alguns passam os dados de contato da área comercial, outros de pessoas específicas na organização que podem auxiliar, contudo, há sempre a impressão de que essas oportunidades não são bem exploradas e a certeza de que não há nenhuma informação a respeito delas para análise depois que a ligação é encerrada.
Por outro lado, a área comercial alegava que as oportunidades oriundas do pós-venda e do suporte chegavam com informações truncadas, pouca clareza da necessidade e às vezes por diferentes meios como e-mail, telefone e até bilhetes colados no monitor. Quando uma oportunidade como essa é registrada no sistema de força de vendas, responsável pelo gerenciamento, a comercial não encontra a origem correta (deveria ser suporte ou pós-venda) e acaba informando algo aproximado.
Bem, o problema seria melhorar o aproveitamento dessas oportunidades de venda, mas e a solução? Bem, neste caso a solução se dividiu em alguns componentes:
- Criação de um acordo nível operacional entre pós-venda, suporte e comercial no qual as áreas geradoras de oportunidades se comprometeram a coletar as informações junto aos clientes no formato determinado pela comercial e no qual a comercial se comprometia a iniciar o tratamento das oportunidades em no máximo um dia útil após a comunicação.
- Treinamento dos atendentes do pós-venda e do suporte para a detecção de possíveis oportunidades junto aos clientes e coleta correta de informações.
- Adequações no sistema de força de vendas para a entrada de novos atores (pós-venda e suporte), digo atores e não usuários, porque eles possuem uma interação com o sistema levemente diferente dos demais atores. Também é necessário inserir duas novas opções de origem de oportunidade (pós-venda e suporte) para que o resultado desse trabalho possa ser medido.
Fica claro para você que se ignorássemos os itens 1 e 2 e implementássemos apenas o 3 a coisa ficaria no mínimo capenga?
Pois é, isso acontece todos os dias o tempo todo em um monte de lugares. Colocar o status de solução para o sistema, para o componente tecnológico ignorando o que está ao redor nos faz correr o risco de fazermos uma entrega tecnicamente perfeita que surte pouco efeito prático.
Um bom exemplo disso são todas as features que você já entregou ao longo da vida que foram pouco ou nunca usadas. Faça um levantamento rápido aí.
A cena é clássica, alguém chama você para conversar e diz algo como “o pessoal do suporte vai começar a usar o SFA, precisamos fazer algumas adaptações. Conversa com eles, vê como tem que ser e…”.
É nesse ponto que a TI ou o fornecedor precisa tomar uma decisão consciente do que oferece e até onde vão as suas responsabilidades.
Se optar por se limitar ao componente software deve também se conformar com os limites disso e com a provável baixa relevância que terá nos resultados finais. Isso inclui quem utiliza métodos iterativos e incrementais com muito foco na entrega e pouco questionamento do que foi entregue.
Aliás, pensar em ficar restrito ao componente da solução “software” me parece ser como optar por viver em duas dimensões quando somos afetados e temos a opção de perceber três, como se fôssemos viver na Planolândia de Edwin Abbot explicada com maestria pelo saudoso Carl Sagan (assista, é sensacional).
Não sou partidário de falsas dicotomias, então adoraria se alguém apontasse uma terceira alternativa para a situação, desde que, claro, não seja a de se responsabilizar pela solução e focar apenas no seu componente. Essa é um tiro no pé.
Uma boa analogia para o pensamento fora da caixinha (nesse caso, software é apenas um componente da solução) é a campanha da Coca Cola Zero que passou a vender latinhas e garrafas contendo “nomes próprios” (a professora de português está orgulhosa agora) junto com o seu slogan “quanto mais, melhor”.
A promoção da Coca Cola Zero foi abrangente e envolveu além dos componentes tradicionais uma mudança que impactou a própria produção na fábrica.
Se você trabalhou com produção em massa sabe que quanto mais unidades de um modelo específico de alguma coisa você fizer maior será o seu ganho econômico.
Já vi casos de empresas alimentícias concorrentes que combinaram que cada uma faria um tipo de produto na sua fábrica para que todas evitassem o enorme custo do setup das máquinas na hora de produzir outra coisa.
Em suma, fazer o que a Coca fez é complicado e é caro e deu um baita resultado. Eu nem tomo mais tanta Coca Cola, mas comprei uma com o nome da minha pessoa favorita para guardar de lembrança.
O componente software da campanha da Coca permitia você publicar uma foto de uma latinha com o seu nome em uma rede social, algo que (tirando a publicação na rede social que não existia) eu teria feito com a biblioteca GD do PHP em 1999 de tão simples que é. Imagine qual seria o impacto da campanha se apenas o componente de software tivesse sido entregue.
Ahh, mas é a Coca Cola! Eles já davam minigarrafas de refrigerante antes de eu nascer. Tudo bem, mas será que trabalhar nos diferentes componentes da solução só funciona nessas circunstâncias? Claro que não.
O primeiro exemplo que eu dei é, de fato, uma situação bem ordinária e foi necessário apenas dar um passo atrás para ver a situação como um todo e desejo de aprender. Ok, e se eu quiser entregar soluções, o que eu preciso fazer? Que tal contratar alguém que entende de negócios (seja lá como se mede isso em alguém), e dar a ele a função de analista de negócios? Não resolve? Não, não mesmo.
Contratar um analista de negócios e deixá-lo restrito dentro do cercadinho do seu componente da solução não vai resolver. Isso pode até ser considerado crueldade, principalmente se o pobre analista realmente gostar de negócios e criar empatia com ele.
O caminho está em desenvolver um ambiente, um contexto que aumente a interação entre os diferentes componentes possíveis da solução. Para que eles estejam abertos para sugestões e mudanças você precisa se abrir para sugestões e mudanças no seu componente.
Isso depende de negociação, confiança e lembra a terceira frase do manifesto pelo desenvolvimento ágil de software: “Colaboração com o cliente mais que negociação de contratos”.
Tanto para a área de TI quanto para o fornecedor isso tem a ver com saber vender, com como fechar uma boa venda onde o terreno está propício para que um bom trabalho seja realizado em seguida, seja um trabalho orientado ao planejamento seja orientado à mudança.
Eu sou analista de negócios (aquele cara ali na jaula) e me interesso em atender à necessidade do negócio ficando muito frustrado quando mandam eu ficar no cercadinho, por isso já aviso bem cedo que “Quanto mais sair da caixinha melhor”.
[Post originalmente publicado em 25/10/2012 em http://blog.claudiobr.com/artigo-nos-vendemos-solucoes-ou-estamos-preso]
Claudio Kerber
Claudio Br é o melhor analista de negócios do Brasil. Ok, quem fala isso é a busca do Google e digamos que o algoritmo, por melhor que seja, (ainda) não consegue concluir esse tipo de coisa. De qualquer forma, ele sabe um bocado do assunto e o que mais gosta é de questionar premissas, desafiar o status quo e de ajudar com que desenvolvedores de sistemas e as pessoas do negócio se entendam e trabalhem em harmonia ao ponto dele poder simplesmente sair de mansinho. Para Claudio Br trabalhar na Lambda3 é um privilégio e uma satisfação.