Eficiência de faturamento de uma empresa de serviços

Reduzir custos é uma preocupação constante de pessoas e empresas. Na área de informática, o downsizing e a terceirização já são regra há muito tempo. Devido à atual recessão econômica mais profunda e duradoura, mais um "produto" tem ficado crescentemente difícil de vender: manutenção de servidores (e.g. quanto à segurança) mediante contraprestação fixa mensal. As empresas têm preferido correr o risco de gastos maiores e/ou atrasos maiores, no caso de realmente ocorrer uma falha.

Não condeno essa atitude. É uma opção legítima que pode ajudar a diminuir custos na área de informática. Mas há o outro lado da moeda: os fornecedores desses serviços, que perdem receita ao trabalharem apenas sob demanda.

Tipicamente, as pequenas empresas e consultores independentes de informática têm atuado da seguinte forma:

recebem X pela instalação;
dão garantia de Y dias na instalação;
faturam sob demanda, Z por hora, quando ocorre algum problema ou necessidade de melhoria;
o "normal", se o sistema é perfeito sob todos os aspectos, é não receber nada.

Até aqui, nada de errado. O problema são as "condições ocultas" dessa relação comercial:

quando ocorrer algum problema, o cliente espera que o fornecedor atenda prontamente;
se esse atendimento não for imediato, o cliente ficará zangado e trocará de fornecedor;
diferente de assistência técnica em hardware, a consultoria em software ou redes não é uma "commodity", ou seja, não é fácil para um novo fornecedor, num primeiro momento, manter um sistema existente;
uma vez que precisou trocar de fornecedor, o cliente não retornará ao antigo, como talvez faria no caso de uma empresa de assistência técnica.

Está claro que é uma relação financeiramente vantajosa para o cliente. O objetivo desse artigo é quantificar a viabilidade financeira desse ''modus operandi'' para o fornecedor.

A esperança de todo consultor ou empresa é conseguir arregimentar clientes até que haja um fluxo mais ou menos contínuo de chamadas, e assim haja trabalho 100% do tempo. Enquanto isso não acontece, é preciso ocupar o tempo vago com projetos novos, que exigem esforço de pré-venda.

Será que faturar 100% do tempo é possível? Esse problema é análogo ao das redes que compartilham um meio físico sem coordenação central (e.g. Ethernet e ALOHA). Vamos começar analisando o ALOHA, que foi criado como um enlace wireless entre três pontos do Havaí, isso ainda nos anos 60.

Na tecnologia ALOHA, qualquer estação transmite quando quiser, sem qualquer mecanismo de contenção. Se uma estação estiver transmitindo, e outra transmitir também, os pacotes das duas serão corrompidos e perdidos. Cabe às camadas de rede superiores solicitar retransmissão.

Então, na medida em que aumenta o número de estações e a carga imposta à rede, aumenta o número de colisões destrutivas, o que diminui a eficiência do ALOHA. Se tivermos poucos clientes, ou clientes com carga muito leve, as colisões são raras, mas nesta situação a rede fica ociosa e isto também conta como baixa eficiência.

O ponto ótimo do ALOHA é em torno de 18% (vide Tannenbaum) - surpreendentemente baixo.

Se substituirmos "estação" por "cliente", e "rede" por "consultor", aí temos uma primeira estimativa do nosso potencial máximo de faturamento, que é bastante desencorajadora. Para atender bem o cliente, precisamos manter uma grande capacidade ociosa. Se tentarmos agendar cada horário, o resultado será um mau atendimento de emergências.

Mas talvez eu tenha sido pessimista.

Cometi um erro grave na comparação acima. No ALOHA, se o pacote 1 for sobreposto, ainda que seja por um único bit, ao pacote 2, ambos estão perdidos. Mas, se eu estou atendendo o cliente 1, e o cliente 2 liga, isso não destrói o trabalho já executado no cliente 1. Portanto, posso suspeitar que eficiência de um consultor será um pouco maior que a do ALOHA.

Existe uma versão denominada Slotted ALOHA, onde existe um sincronismo entre as estações. Elas tentarão transmitir não a qualquer momento, mas sim em instantes predeterminados por um coordenador. Ainda há grande chance de colisão, mas uma vez que uma estação consiga iniciar a transmissão do pacote, é quase certo que terminará sem ser interrompida (a não ser por algum ruído).

Essa versão do ALOHA tem eficiência máxima de 36%. Como o pacote, uma vez iniciado, terminará bem, ela presta-se melhor à metáfora do consultor. Ainda assim, é uma eficiência bem aquém do sonhado 100%.

O Slotted ALOHA "marca hora" para a transmissão dos pacotes: a estação tem de esperar um tempo entre 0 e 1 largura de pacote, média 1/2, para transmitir.

Isso equivale dizer que, se seus atendimentos duram em média 4h, os clientes têm de estar avisados que uma chamada pode levar até 4h para ser atendida. E, num dia ruim, ainda pode acontecer de formar-se uma fila. Se seu cliente quer você "em 5 minutos, ou procuro outro fornecedor", perderá (destruirá) o cliente e voltamos ao ALOHA original com seus 18% de eficiência.

Alguém poderia dizer que "bem, se eu chegar nesse ponto, contrato mais um funcionário". Isso não melhora a eficiência. Mas pode melhorar a lucratividade se o funcionário trabalhar por um salário de fome (uma solução que, por temperamento, não aprecio). É como usar duas redes ALOHA ao invés de uma: a banda passante efetiva vai dobrar, mas a eficiência global máxima continuará sendo 18%.

Moral da história até aqui:

a garantia de atendimento imediato não é possível nem exigível, pois implica em enorme perda de potencial de faturamento para o consultor;
a garantia de atendimento num tempo razoavelmente curto é algo plausível, porém implica em perda razoavelmente grande de potencial de faturamento, e mesmo assim não pode ser garantida em 100%;
se o cliente quiser garantia de atendimento num prazo máximo, tem de pagar por isso, ou seja, tem de pagar pela respectiva perda de potencial de faturamento. Pagar pela ociosidade de um funcionário encarregado apenas de manter um sistema funcionando costuma sair mais caro, então ainda é vantagem para o cliente;
outra opção de compensação seria praticar um valor/hora suficientemente alto para cobrir a perda de potencial de faturamento. Só que a) os clientes pagantes não deveriam pagar pela sua disponibilidade de atendimento aos clientes não-pagantes; b) o valor provavelmente seria alto demais, empurrando o consultor para fora do mercado.

Aí eu pergunto:

você deixou claro a seu cliente que o atendimento pode não ser imediato?
se você não deixou claro, será que ele tem bom-senso suficiente para saber disso sozinho?
você tomou providências para garantir o atendimento em tempo hábil ao (raro) cliente que paga uma taxa de manutenção, ou ele é só um otário no meio dos espertos?
no caso de clientes fisicamente distantes, você criou um plano de contingência (e.g. contatou outro fornecedor mais próximo), para o caso de ele necessitar intervenção física e você não poder ir até lá?

Uma discrepância mais sutil refere-se à modelagem do tráfego gerado pela estação/cliente. Tipicamente é usada a distribuição de Poisson: o tráfego médio é baixo, porém sujeito a rajadas. É o modelo que mais bem modela o cliente típico, mas como o próprio Tanenbaum frisa, não é perfeito.

Se as estações tivessem um tráfego não-Poisson, mais previsível, seria possível atingir eficiências maiores. Num exemplo extremo, se numa rede ALOHA simples cada estação transmite no momento certo, pode-se atingir 100% de eficiência. Mas isso exigiria coordenação entre os clientes, o que exige um segundo canal de comunicação... Para modelagem de elementos-surpresa, Poisson é realmente o menos pior.

Transpondo isso para o mundo real. Aquele cliente que fica 8 meses sem ligar, e de repente quer sua presença em 10 minutos, é bem modelado por Poisson. Porém existem clientes mais benignos. Aquele cliente que proporciona algumas horas de faturamento todo mês pela execução tarefas sem urgência, é mais bem modelado por uma distribuição normal.

Deste modo, você pode atingir eficiências acima de 36%, se o perfil de cliente for favorável. Mas não seja muito otimista. Assim como há os clientes bons, há os clientes-encrenca, que só te chamam quando a coisa já ficou preta e devidamente arrematada pela gauchada do "outro" consultor, ou do sobrinho do dono.

Por outro lado, se você cobrar o mesmo valor/hora do cliente "Poisson" e do cliente "Normal", este último será penalizado, pois o primeiro exige uma disponibilidade maior e está sendo subsidiado.

As redes CSMA atingem eficiências mais próximas de 100%. Isso ocorre porque, em tais redes, colisões só ocorrem por "acidente". Cada estação transmite apenas quando sente o meio livre. O tempo de timeout (quando a estação desiste de transmitir) é muito longo em comparação com o tamanho do pacote.

Não creio que uma rede CSMA possa ser comparada ao relacionamento do consultor típico com seus clientes típicos, pois com certeza os clientes não terão "timeout" muito longo. Uma situação (atípica) que poderia ser comparável ao CSMA é o consultor que executa apenas trabalhos agendados, sem urgência e fáceis de reagendar. Mas isso foge completamente do nosso assunto, que é modelar o consultor que trabalha apenas sob demanda.