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 pristino, 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 tenha trabalho 100% do tempo. Enquanto isso não acontece, é preciso ocupar o tempo vago com projetos novos, que são de iniciativa não do cliente, mas do consultor (que é livre para aceitar ou rejeitar o trabalho, e via de regra teve de "conquistar" o cliente).

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 a rede fica a maior parte do tempo sem uso, o que também é uso ineficiente do meio.

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, e se pressionarmos nossa capacidade, atenderemos mal.

Mas talvez eu tenha sido pessimista.

Cometi um erro grave na comparação acima. No ALOHA, se o pacote 1 for sobreposto, que seja por um 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á feito no cliente 1. Portanto, posso suspeitar que a minha eficiência será 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 podem esperar tipicamente de 0 a 4h para serem atendidos. Digo "tipicamente" pois pode perfeitamente 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 dez-réis de mel coado). É 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 sempre imediato não é possível nem exigível, pois implica em enorme perda de eficiência para o consultor;
• a garantia de atendimento num tempo razoavelmente curto é algo plausível, porém implica em perda razoavelmente grande de eficiência, e mesmo assim não pode ser garantida para 100% dos eventos;
• se o cliente quiser qualquer garantia de atendimento pristino, tem de pagar por isso, ou seja, tem de pagar pela infra-estrutura ociosa, tal qual ele faria se pagasse um empregado para manter tudo funcionando;
• outra opção de compensação seria praticar um valor/hora suficientemente alto para cobrir a baixa eficiência. Mas meu palpite é que tal valor colocaria o consultor 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 te paga valor fixo mensal, 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 menos pior aproxima o cliente de rede 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, o que exigiria uma segunda rede ;) 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 você em 10 minutos ("mas *como* você não pode vir agora ?!?!! Você TEM que vir!!!!!!") é bem representado por Poisson, porém existem clientes mais benignos. Aquele cliente que te proporciona algumas horas de faturamento todo mês, e em geral pede coisas nada urgentes, é 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. (Vocês instalaram, vocês consertam!! Que? Alguém mexeu? Ou foram vocês, ou então foi invadido!! Vocês não disseram que era 100% seguro?? Ah, a alteração foi feita localmente? Hmm... Er... <silêncio> )

Por outro lado, se você cobrar o mesmo valor/hora do cliente "Poisson" e do cliente "Normal", este último será penalizado, pois está subsidiando ao outro a disponibilidade do fornecedor.

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 ou reordenáveis. Mas isso foge completamente do nosso assunto, que é modelar o consultor que trabalha apenas sob demanda.

TO BE CONCLUDED