Gerenciamento de frota: recursos e otimização da interoperabilidade

Ao longo do artigo mencionarei a lei de distribuição “80\20”.
Esta é uma divisão aproximada ligada à distribuição normal e suas derivadas.
Muitas vezes é ilustrado como uma curva logarítmica ou f(x) = 1-1/x.

De um extremo para o outro

Muitas vezes, o debate sobre gestão de frotas divide-se entre:

• um conjunto de frotas dedicadas, mais baratas, menos complexas e menos arriscadas
• e uma frota única e multifuncional, permitindo uma frota menor

Frotas dedicadas e mais baratas?

Não necessariamente :

Se os aparelhos forem mais baratos por unidade, ou mesmo na aquisição de frotas, a multiplicação desses aparelhos gera uma multiplicação dos custos operacionais diretos: número de tripulantes, custos de manutenção, etc.
Infelizmente, muito (quantidade) de pouco (custo unitário), dá muito (custo de operacionalidade da frota).

Em contraste, a frota omnirole (frota única multifunção):

Com base nesta observação, a solução de uma frota única e omnirole é frequentemente considerada…
À custa de um sistema mais complexo (mais caro de adquirir, mas também de manter), é possível reduzir consideravelmente a frota (por vezes até 1/3) e, portanto, multiplicar os custos diretos.
No entanto, um pouco (quantidade) muito (custo unitário), também dá muito (custo de operacionalidade da frota).

Muitas vezes mal calculado, dimensionado ignorando questões de espaço e tempo, é então necessário ter um certo dom de onipresença impossível.
Este problema é muitas vezes resolvido retrospectivamente através de uma encomenda adicional de algumas cópias adicionais.

Não irei abordar todos estes aspectos que já tive oportunidade de abordar e tratar em outros artigos.

O ponto econômico:

Entre estes dois extremos, existe um compromisso mais matizado, denominado Ponto Económico, ou quantidade económica.

Vamos lembrar a necessidade:

• Atender às necessidades operacionais
• Ao melhor custo na conclusão (ou seja, aquisição + operação, todos os custos incluídos, incluindo gestão da tripulação de voo)

Um rápido lembrete do custo na conclusão:
Muitas vezes, a análise é reduzida ao gerenciamento de dispositivos. Contudo, a necessidade não é adquirir e gerir uma frota de aeronaves, mas sim satisfazer as necessidades da missão.
É claro que isso inclui os dispositivos, mas não só: vamos falar apenas sobre a tripulação de cabine.

A capacidade de um sistema (ou seja, um conjunto de elementos) de satisfazer uma necessidade dimensionada no espaço e no tempo é o que chamamos de Capacidade.

fundamentos

Defina corretamente sua necessidade

Não vou voltar ao cálculo de otimização do tamanho da frota, que abordo no artigo “ Calcular a capacidade da frota« 
O objetivo deste artigo é abordar a distribuição justa entre um conjunto de frotas dedicadas e uma frota única omnirole.

Falar em capacidade significa falar em dimensionamento de competências e habilidades.
Portanto, um conjunto de meios que dá resposta a um conjunto de necessidades.

Quais são essas necessidades?
A necessidade de um recurso é cada vez que ele é “atribuído” a um uso:

• Emprego para uma missão (seja ela qual for)
• Mas também “disponível mediante solicitação” (exemplo: SAR)
• Sem esquecer o tempo de inatividade para manutenção (online ou periódica)
• E sobretudo, o nível de risco de falta de fiabilidade que optamos por ter em conta no que diz respeito às especificações esperadas (e que é muitas vezes esquecido, o que leva a rupturas de capacidade).

Isso resulta em uma probabilidade de necessidade:

Desta probabilidade é deduzida uma taxa de necessidade, ou seja, alocações:

Simplificando, tomemos a hipótese em relação a este gráfico de uma frota de 200 aeronaves.
Tecnicamente, esses primeiros passos são um pouco mais complexos, principalmente pelo aspecto de consideração de risco. Vou passar para vocês essas etapas que, embora participem, não são o cerne do assunto.

Para mais informações sobre esses aspectos, convido você a ler o livro “6 Sigma: como aplicá-lo” por Maurice Pillet.

Note-se de passagem que a integral desta integral permite deduzir uma taxa de flexibilidade para absorver vários perigos como:

• Falha (ou seja, o desvio imprevisto da confiabilidade estimada do equipamento).
• Uma certa evolução da necessidade.
• Gestão de retrofits de meia-idade e/ou inspeções importantes, resultando em um aumento na necessidade durante um período específico.

Em comparação com a dimensão da frota, esta taxa de flexibilidade proporcionará uma “profundidade de flexibilidade”, ou seja, um montante pendente.

Otimização de interoperabilidade:

Para ilustrar, considerarei as 2 necessidades:

• um que exige uma frota de 140 a 200 aeronaves
• o outro variando de 60 a 100 dispositivos

(Especifico para todos os efeitos que esses valores foram escolhidos aleatoriamente antes do exercício)

Em primeiro lugar, lembremo-nos que esta otimização diz respeito apenas ao que é comum, intercambiável e em nenhum caso equipamento dedicado que deve ser dimensionado de acordo com todas as suas próprias necessidades.

Extreme 1: 2 frotas dedicadas

• Todas as frotas = 300 (200 + 100)
• Emprego médio = 250 ((140+200)/2 + (60+100)/2)

Observe que você tem, portanto, em média, 50 dispositivos “inativos”, ou 17% da sua frota ou, como alguns calculam: 20% (Average_Dormant / Average_Employment = 50/250).

Extreme 2: 1 frota multifuncional comum

Em primeiro lugar, convém lembrar que a semelhança das 2 frotas não é a média dos 2 intervalos de variabilidade !
Então, não é 50 ( [(100-60) + (200-140)] / 2 ).
Este tipo de erro (cometido com mais frequência do que pensamos) leva a interrupções de capacidade.

Este erro é muitas vezes cometido através do raciocínio apenas em médias:

• Uma exigência média de 170 de um lado (140 + (200-140)/2)
• E 80 do outro (60 + (100-60)/2)
• …É assim que se chega a 250, o que inevitavelmente levará a interrupções de capacidade

No presente caso de 2 frotas, a regra da comunalidade é bastante simples:
A comunalidade será, no máximo, a variabilidade mais restritiva e, portanto, a mais fraca:
200-140 60 =
100-60 40 =
A comunidade será, portanto, 40.

Os limites deste segundo cálculo:

Este cálculo teórico padece de diversas falhas ligadas ao facto de em nenhum momento ser tida em consideração a análise de capacidade de consolidação da frota:

• 1ª falha: necessidade compartilhada no auge :

O cálculo anterior considera como hipótese unilateral que quando uma frota está em plena utilização, a outra está em utilização mínima.
Dependendo do grau de alinhamento entre as necessidades das duas frotas, isto pode levar a perturbações de capacidade.

A probabilidade média de ter pelo menos 1 dispositivo quebrado é 15%...
7% ter pelo menos 5…
(excluindo os seguintes impactos de falha)

« 15%!? É aceitável »...
… Não necessariamente :
15% têm deficiência de pelo menos 1 dispositivo. Seria apropriado ponderar pela profundidade da deficiência (por exemplo, com 5 dispositivos, temos 7% de probabilidade... Ou uma deficiência de 0.35).
Fazendo um cálculo mínimo, o grau de deficiência deve ficar em torno de 5 aparelhos. Isso equivale a dizer que você terá faltando permanentemente 5 dispositivos. Serão necessários alguns adiamentos de atividades.

• 2ª falha: realocação. Isso não é cobrança zero.

Cada remanejamento pode exigir cargas diversas no equipamento, como o seu transporte, a instalação ou remoção do equipamento, ou mesmo a repintura do dispositivo nas cores de sua nova atribuição.
Esta carga deve ser levada em consideração na equação.

• 3ª falha: sempre a realocação do pooling levada ao seu clímax.

Quanto menos flexibilidade você tiver, mais será forçado a fazer realocações. Embora a profundidade de flexibilidade lhe proporcione a reserva “pré-posicionada”, até ao extremo oposto onde, com as 2 frotas dedicadas, não terá de realocar.

3ª falha que naturalmente nos leva à nossa solução mais moderada:

Profundidade de agrupamento

Conforme mencionado no artigo sobre cálculo de capacidade, existem 3 noções ligadas ao pooling:

• A frota compartilhada
• A frota dedicada
• E o pré-posicionamento da frota compartilhada

Como vimos, pooling completo não é necessariamente sábio (a menos que tenhamos alavancas de flexibilidade nos factores de reafectação, permitindo que essas reafectações sejam moderadas).

80\20:
Abaixo de 20% do pool máximo possível (ou seja, 8 no nosso exemplo), podemos considerar que não é interessante fazer pool: o ganho, se houver, será muito baixo.
Acima de 80% (ou seja, 32), podemos razoavelmente assumir que haverá interrupções de capacidade.

Sem entrar em detalhes explicativos, colocar-se em 80% do pool máximo reduz o risco de interrupção em 45% (ou seja, mais de 8% de risco médio de interrupção de capacidade de pelo menos 1 dispositivo).

Ponto Econômico: otimização de custos :
Falei com vocês na introdução sobre a noção de Ponto Econômico.
Você pode avaliar o pooling ideal em termos de custos levando em consideração os fatores:

• Para cada dispositivo compartilhado, há 1 dispositivo a menos encomendado (nota: o custo das versões não é necessariamente o mesmo)
• Ao qual se opõe o custo de realocação (transporte, instalação/remoção, etc.)
• Ponderado pela probabilidade média de realocações durante um período, multiplicada pelo número de períodos de vida útil do hardware

Mas vamos abordar a verdadeira questão da semelhança:

Pool assimétrico

Para começar, vamos encerrar um totem:
Não, não é absolutamente necessário ter uma frota intercambiável única e comum para desfrutar de seus benefícios.

Se você seguiu as instruções corretamente, terá entendido que existe uma base de frota em ambos os lados que não precisa ser intercambiável.
Se a intercambialidade total é desejável, é porque simplifica a equação na gestão de frotas.

Mas ele é um caso especial em que o agrupamento assimétrico é mais vantajoso :

Abordei o aspecto da partilha, evocando por vezes a noção de comunhão. Mas o que é essa semelhança?
Se no primeiro extremo não for necessária qualquer semelhança, sendo as duas frotas distintas, os capítulos sobre a partilha de uma única frota pressupõem, portanto, uma total semelhança.
Isso quer dizer que todas as aeronaves das 2 frotas (ou seja, 260 a 300 aeronaves, 268 recomendado) podem atender às necessidades da frota A ou da frota B.

Comunidade ascendente

Amplamente utilizada na computação, a compatibilidade com versões anteriores é o princípio segundo o qual uma nova versão garante o funcionamento de uma ou mais versões anteriores.

No caso do desenvolvimento de uma versão base A, da qual as demais provêm do desenvolvimento de desvios desta versão, este tipo de compatibilidade é inteiramente aplicável.
Ainsi, o Tiger HAD, derivado do HAP, é capaz de realizar todas as missões do HAD e do HAP; enquanto o HAP só pode realizar as suas missões HAP.

Neste tipo de caso de comunalidade ascendente, não é necessário haver comunalidade em toda a frota, estimando corretamente as bases.
Assim, no caso do Tiger, 2/3 dos requisitos da sua missão são do tipo HAP. Sabendo também que a implantação geralmente é feita em trigêmeos e que um HAD nunca sai em missão sem um HAP, 1/3 dos dispositivos poderiam ter sido mantidos na versão HAP sem risco.

exemplo prático

Voltemos às nossas 2 necessidades de 100 (60 a 100) e 200 (160 a 200):
O cálculo pode ser refinado, se soubermos estimar corretamente, se não medir, o dimensionamento da capacidade.
O exercício pode tornar-se rapidamente complexo se considerarmos que cada frota está na realidade dividida em subfrotas (as diferentes bases, as implantações de Opex, a frota em manutenção, etc.).
(aqui novamente, convido você a consultar o artigo citado acima para mais detalhes)

Por padrão, permanecerei em uma divisão 80/20:

As hipóteses a ter em consideração são, portanto:

• Para manter uma certa flexibilidade na gestão de frotas dedicadas:
  • 20% da variabilidade continuará a ser considerada como pertencente a frotas dedicadas
    (Na verdade, há 95% de chance de emprego para esses primeiros 20%)
  • Na verdade, a sobreposição de variabilidades (portanto a otimização do tamanho da frota) será feita num máximo de 80% destas.
• Para também ter flexibilidade na gestão de remanejamentos:
  • a sobreposição deve representar um máximo de 80% da frota agrupada. Idealmente: 80% ^ number_Axis_Reallocations.
    (Assim, se você quiser levar em conta as alocações locais [bases, Opex…], você tem um 2º eixo e portanto 80%^2 = 64%)
• Finalmente, para moderar as realocações:
  • a sobreposição deverá representar apenas um máximo de 80% da frota partilhada.

Dependendo da frota com capacidade de Comunalidade Ascendente, obtemos:

Note que em ambos os casos o total das 2 frotas é 2:
200 do Requisito A + 60 do requisito mínimo de B + 8 (40 x 0.2) dos primeiros 20% da variabilidade de B.

Da mesma forma, a distribuição na atribuição de base (e o pré-posicionamento associado) depende sobretudo da probabilidade do nível de emprego das 2 frotas, da sua parte sobreposta, e não da extensão da frota partilhada:

Necessito de um	89	88	87	86
Probabilidade	9%	12%	15%	18%
Precisa de B	186	187	188	189
Probabilidade	16%	14%	12%	10%

Conclusão

A Mutualização Assimétrica, aproveitando a Comunalidade Ascendente, permite o melhor compromisso entre:

• Otimize o tamanho da frota
• Sem fornecer tudo isso com a versão mais cara
• Embora beneficie, em grande medida, das mesmas vantagens de uma frota única

Na ausência de avaliações orçamentais quantificadas, deixo a cada um a liberdade de formar a sua própria opinião.
No entanto, aqui está minha conclusão e recomendação:

• Se a frota da Marinha é de 200 [#°1], não é interessante manter frotas dedicadas. Devemos avançar para o pooling (completo [em 250] ou assimétrico)
• Se a frota da Marinha for de 100 [#°2] (o que é mais provável), o melhor cenário é o agrupamento assimétrico
• Em qualquer caso, não é recomendado agrupar uma única frota:
  • O de 260 pressupõe um risco de 15% de deficiência de capacidade de pelo menos 1 dispositivo, ou seja, uma deficiência média de cerca de 5 dispositivos
  • A solução 268 é uma solução bastante mista: mais cara do que soluções assimétricas para pooling, que não são melhores.

No entanto, este agrupamento assimétrico só é possível quando:

• Existe isso Comunalidade Ascendente em capacidades [por exemplo: HAD = (HAP + x)]
• A reatribuição é viável em termos de custos e prazos
• Existe um alto grau de semelhança no design (para processos MCO e peças sobressalentes) para que a coexistência não resulte numa duplicação de custos em comparação com uma única frota multifuncional.
• Finalmente, embora seja possível em frotas com elevada variabilidade, esta solução pode, no entanto, ser menos interessante do que uma frota única.

(Nota: evitei deliberadamente este aspecto da gestão de stocks, pois poderia envolver diversas estratégias que, embora devessem ser tidas em consideração no caso de um tal estudo, teriam complicado a compreensão aqui.)

© Julien Maire.