Managementul flotei: capabilități și optimizare a interoperabilității

Pe parcursul articolului voi menționa legea distribuției „80\20”.
Aceasta este o diviziune brută legată de distribuția normală și de derivatele acesteia.
Este adesea ilustrată ca o curbă logaritmică sau f(x) = 1-1/x.

De la o extremă la alta

Adesea, dezbaterea privind managementul flotei este împărțită între:

• un set de flote dedicate, mai ieftine, mai puțin complexe și mai puțin riscante
• și o flotă unică, cu mai multe roluri, permițând o flotă mai mică

Flote dedicate, mai ieftine?

Nu neaparat :

Dacă dispozitivele sunt mai puțin costisitoare pe unitate, sau chiar la achiziționarea de flote, înmulțirea acestor dispozitive generează o multiplicare a costurilor directe de operare: număr de echipaj de zbor, costuri de întreținere etc.
Din păcate, mult (cantitate) de puțin (cost unitar), dă mult (costul operabilității flotei).

În schimb, flota omnirol (flota unică multirol):

Pe baza acestei observații, soluția unei singure flote omnirole este adesea considerată...
Cu prețul unui sistem mai complex (mai scump de achiziționat, dar și de întreținut), este posibil să se reducă considerabil flota (uneori până la 1/3) și prin urmare să se înmulțească costurile directe.
Cu toate acestea, puțin (cantitate) mult (cost unitar), oferă și mult (costul operabilității flotei).

Adesea prost calculat, dimensionat ignorând problemele de spațiu și timp, se cere apoi să aibă un anumit dar de omniprezentare imposibilă.
Această problemă este adesea rezolvată retroactiv printr-o comandă suplimentară de câteva exemplare suplimentare.

Nu voi trece peste toate aceste aspecte pe care deja am avut ocazia să le abordez și să le tratez în alte articole.

Punctul economic:

Între aceste 2 extreme, există un compromis mai nuanțat, numit Punct Economic, sau cantitate economică.

Să ne amintim nevoia:

• Satisface nevoile operationale
• La cel mai bun cost la finalizare (adică achiziție + exploatare, toate costurile incluse, inclusiv gestionarea echipajului de zbor)

O reamintire rapidă a costului la finalizare:
De prea multe ori, analiza se reduce la managementul dispozitivelor. Totuși, necesitatea nu este de a achiziționa și gestiona o flotă de aeronave, ci de a satisface nevoile misiunii.
Aceasta include, desigur, dispozitivele, dar nu numai: să vorbim doar despre echipajul de cabină.

Capacitatea unui sistem (adică a unui set de elemente) de a satisface o nevoie dimensionată în spațiu și timp este ceea ce numim Capacitate.

Fundamentals

Definiți-vă corect nevoia

Nu mă voi întoarce la calculul optimizării dimensiunii flotei, pe care îl abordez în articolul „ Calculați capacitatea flotei« 
Scopul acestui articol este de a aborda distribuția echitabilă între un set de flote dedicate și o singură flotă omnirolă.

A vorbi despre capacitate înseamnă a vorbi despre dimensionarea aptitudinilor și abilităților.
Deci un set de mijloace care oferă un răspuns la un set de nevoi.

Care sunt aceste nevoi?
Necesitatea unei resurse este de fiecare dată când aceasta este „alocată” unei utilizări:

• Angajare pentru o misiune (oricare ar fi aceasta)
• Dar și „disponibil la cerere” (exemplu: SAR)
• Fără a uita de oprirea pentru întreținere (online sau periodice)
• Și mai presus de toate, nivelul de risc de nefiabilitate pe care alegem să-l luăm în considerare în ceea ce privește specificațiile așteptate (și care este prea des uitat, ceea ce duce la întreruperi de capacitate).

Aceasta are ca rezultat o probabilitate de nevoie:

Din această probabilitate se deduce o rată a nevoii, adică alocările:

Pentru a spune simplu, să luăm ipoteza în raport cu acest grafic al unei flote de 200 de aeronave.
Din punct de vedere tehnic, acești primi pași sunt puțin mai complexi, mai ales din cauza aspectului luării în considerare a riscului. Vă voi trece acești pași care, deși participă, nu sunt inima subiectului.

Pentru mai multe informații despre aceste aspecte, vă invit să citiți cartea „6 Sigma: cum se aplică” de Maurice Pillet.

Rețineți în trecere că integrala acestei integrale face posibilă deducerea unei rate de flexibilitate pentru a absorbi diferite pericole, cum ar fi:

• Defecțiune (adică abaterea neprevăzută de la fiabilitatea estimată a echipamentului).
• O anumită evoluție a nevoii.
• Gestionarea modernizărilor la mijlocul perioadei de viață și/sau a inspecțiilor majore, care rezultă într-o creștere a nevoii într-o anumită perioadă.

În comparație cu dimensiunea flotei, această rată de flexibilitate va oferi o „profunzime de flexibilitate”, adică o sumă excepțională.

Optimizarea interoperabilității:

Pentru a ilustra, voi lua în considerare cele 2 nevoi:

• unul care necesită o flotă de 140 până la 200 de aeronave
• celălalt variind de la 60 la 100 de dispozitive

(Precizez pentru toate scopurile că aceste valori au fost alese la întâmplare înainte de exercițiu)

În primul rând, să ne amintim asta această optimizare se referă doar la ceea ce este comun, interschimbabil și în niciun caz echipamente dedicate care trebuie dimensionate în funcție de toate nevoile proprii..

Flote dedicate Extreme 1: 2

• Toate flotele = 300 (200 + 100)
• Angajare medie = 250 ((140+200)/2 + (60+100)/2)

Rețineți că aveți așadar, în medie, 50 de dispozitive „latente”, sau 17% din flota dvs. sau, după cum calculează unii: 20% (Average_Dormant / Average_Employment = 50 / 250).

Flotă multirol comună Extreme 2: 1

În primul rând, trebuie amintit că comunitatea celor 2 flote nu este media celor 2 intervale de variabilitate !
Deci, nu este 50 ( [(100-60) + (200-140)] / 2 ).
Acest tip de eroare (comită mai des decât credem) duce la întreruperi de capacitate.

Această eroare este adesea făcută prin raționament numai pe medii:

• O cerință medie de 170 pe o parte (140 + (200-140)/2)
• Și 80 pe de altă parte (60 + (100-60)/2)
• … Așa ajungeți la 250, ceea ce va duce inevitabil la întreruperi de capacitate

În cazul de față a 2 flote, regula comunității este destul de simplă:
Comunitatea va fi cel mult variabilitatea cea mai restrictivă și, prin urmare, cea mai slabă:
200-140 = 60
100-60 = 40
Prin urmare, comunitatea va avea 40 de ani.

Limitele acestui al doilea calcul:

Acest calcul teoretic suferă de câteva defecte legate de faptul că analiza capacității de consolidare a flotei nu este luată în considerare în niciun moment:

• Primul defect: nevoia comună la vârf :

Calculul anterior consideră ca o ipoteză unilaterală că atunci când o flotă este la maxim utilizare, cealaltă este la utilizare minimă.
În funcție de gradul de aliniere între nevoile celor două flote, acest lucru poate duce la întreruperi de capacitate.

Probabilitatea medie de a avea cel puțin 1 dispozitiv spart este de 15%...
7% pentru a avea cel puțin 5...
(excluzând următoarele impacturi ale defectelor)

« 15%!? Este acceptabil “...
… Nu neaparat :
15% să aibă o deficiență a cel puțin 1 dispozitiv. Ar fi potrivit să ponderăm după adâncimea deficienței (de exemplu, cu 5 aparate, suntem la 7% probabilitate... Sau o deficiență de 0.35).
Efectuând un calcul minim, gradul de deficiență ar trebui să fie în jur de 5 dispozitive. Acest lucru este echivalent cu a spune că vei avea lipsesc definitiv 5 dispozitive. Vor fi necesare unele amânări de activitate.

• Al 2-lea defect: realocare. Aceasta nu este taxa zero.

Fiecare reatribuire poate necesita diferite sarcini asupra echipamentului, cum ar fi transportul acestuia, instalarea sau îndepărtarea echipamentului sau chiar revopsirea dispozitivului în culorile noii sale atribuiri.
Această sarcină trebuie luată în considerare în ecuație.

• Al 3-lea defect: întotdeauna realocarea poolingului a dus la punctul culminant.

Cu cât ai mai puțină flexibilitate, cu atât vei fi mai forțat să faci realocări. În timp ce adâncimea de flexibilitate vă va oferi rezerva „pre-poziționată”, până la capătul opus, unde, cu cele 2 flote dedicate, nu aveți nicio realocare de făcut.

Al treilea defect care ne conduce în mod natural către soluția noastră mai moderată:

Adâncimea de împingere

După cum se menționează în articolul despre calculul capacității, există 3 noțiuni legate de pooling:

• Flota comună
• Flota dedicată
• Și prepoziționarea flotei partajate

După cum am văzut, punerea în comun completă nu este neapărat înțeleaptă (cu excepția cazului în care avem pârghii de flexibilitate privind factorii de realocare, permițând moderarea acestor realocări).

80\20:
Sub 20% din pooling-ul maxim posibil (adică 8 în exemplul nostru), putem considera că nu este interesant de pooling: câștigul, dacă există, va fi prea mic.
Dincolo de 80% (adică 32), putem presupune în mod rezonabil că vor exista întreruperi de capacitate.

Fără a intra în detalii explicative, plasarea la 80% din totalul maxim reduce riscul de întrerupere cu 45% (adică mai mult de 8% riscul mediu de întrerupere a capacității a cel puțin 1 dispozitiv).

Punct economic: optimizarea costurilor :
V-am vorbit în introducere despre noțiunea de Punct Economic.
Puteți evalua punerea în comun optimă în ceea ce privește costurile ținând cont de factorii:

• Pentru fiecare dispozitiv partajat, există 1 dispozitiv mai puțin comandat (notă: costul versiunilor nu este neapărat același)
• La care se opune costul realocării (transportare, instalare/demontare etc.)
• Ponderată cu probabilitatea medie de realocări pe o perioadă, înmulțită cu numărul de perioade ale duratei de viață a hardware-ului

Dar să abordăm adevărata problemă a comunității:

Pooling asimetric

Pentru început, să încheiem un totem:
Nu, nu este absolut necesar să existe o singură flotă comună interschimbabilă pentru a se bucura de beneficiile sale.

Dacă ați urmat corect instrucțiunile, veți fi înțeles că există o bază de flota pe ambele părți care nu trebuie să fie interschimbabilă.
Dacă interschimbabilitatea completă este de dorit, este pentru că simplifică ecuația în managementul flotei.

Dar el este un caz special în care punerea în comun asimetrică este mai avantajoasă :

Am abordat aspectul împărtășirii, evocând uneori noțiunea de comunalitate. Dar ce este această caracteristică comună?
Dacă în prima extremă nu se cere nicio asemănare, cele două flote fiind distincte, capitolele privind punerea în comun a unei singure flote presupun așadar comunalitate deplină.
Adică toate aeronavele din cele 2 flote (deci 260 până la 300 de aeronave, 268 recomandate) pot satisface nevoile flotei A sau ale flotei B.

Comunitatea ascendentă

Folosită pe scară largă în calcul, compatibilitatea inversă este principiul conform căruia o versiune nouă asigură funcționarea uneia sau mai multor versiuni anterioare.

În cazul dezvoltării unei versiuni de bază A, din care celelalte provin din dezvoltarea abaterilor de la această versiune, acest tip de compatibilitate este în întregime aplicabil.
Ainsi, Tiger HAD, derivat din HAP, este capabil să îndeplinească toate misiunile HAD și HAP; în timp ce HAP își poate îndeplini doar misiunile HAP.

În acest tip de caz de comunalitate ascendentă, nu este necesar să existe comunități în întreaga flotă, prin estimarea corectă a bazelor.
Astfel, în cazul Tigerului, 2/3 din cerințele misiunii sale sunt de tip HAP. Știind, de asemenea, că implementarea se face de obicei în tripleți și că un HAD nu merge niciodată într-o misiune fără un HAP, 1/3 dintre dispozitive ar fi putut fi păstrate în versiunea HAP fără riscuri.

Exemplu practic

Să revenim la cele 2 nevoi ale noastre de 100 (60 la 100) și 200 (160 la 200):
Calculul poate fi rafinat, daca stim sa estimam corect, daca nu masuram, dimensionarea capacitatii.
Exercițiul poate deveni rapid complex dacă avem în vedere că fiecare flotă este în realitate împărțită în sub-flote (diferitele baze, desfășurări Opex, flota în întreținere etc.).
(din nou aici, va invit sa consultati articolul citat mai sus pentru mai multe detalii)

În mod implicit, voi rămâne pe o împărțire 80\20:

Ipotezele de luat în considerare sunt deci:

• Pentru a menține o anumită flexibilitate în gestionarea flotelor dedicate:
  • 20% din variabilitate va rămâne considerată ca aparținând flotelor dedicate
    (Într-adevăr, există o șansă de angajare de 95% pentru aceste prime 20 la sută)
  • De fapt, suprapunerea variabilităţilor (deci optimizarea dimensiunii flotei) se va face pe maximum 80% dintre acestea.
• Pentru a avea și flexibilitate în gestionarea realocărilor:
  • suprapunerea trebuie să reprezinte maximum 80% din flota care poate fi pusă în comun. Ideal: 80% ^ number_Axis_Reallocations.
    (Astfel, dacă doriți să luați în considerare alocările locale [baze, Opex...], aveți o a 2-a axă și deci 80%^2 = 64%)
• În cele din urmă, pentru a modera realocările:
  • suprapunerea ar trebui să reprezinte doar maximum 80% din flota partajată.

În funcție de flota cu capacitatea de Comunitate Crescătoare, obținem:

Rețineți că, în ambele cazuri, totalul celor 2 flote este de 2:
200 din cerința A + 60 din cerința minimă a lui B + 8 (40 x 0.2) din primele 20% din variabilitatea lui B.

La fel, distribuția în atribuirea de bază (și prepoziționarea asociată) depinde în primul rând de nivelul probabilității de angajare a celor 2 flote, de partea suprapusă a acestora, și nu de amploarea flotei partajate:

Am nevoie de	89	88	87	86
Probabilitate	9%	12%	15%	18%
Am nevoie de B	186	187	188	189
Probabilitate	16%	14%	12%	10%

Concluzie

Mutualizarea asimetrică, profitând de comunitatea ascendentă, permite cel mai bun compromis între:

• Optimizați dimensiunea flotei
• Fără a oferi toate acestea cu cea mai scumpă versiune
• Beneficiind deși, în mare măsură, de aceleași avantaje ca și o singură flotă

În lipsa unor evaluări bugetare cuantificate, las pe seama fiecăruia să-și formeze propria opinie.
Totuși, iată concluzia și recomandarea mea:

• Dacă flota Marine este cea de 200 [#°1], nu este interesant să păstrăm flote dedicate. Trebuie să trecem spre pooling (complet [la 250] sau asimetric)
• Dacă flota Marinei este cea de 100 [#°2] (ceea ce este mai probabil), cel mai bun scenariu este punerea în comun asimetrică
• În orice caz, punerea în comun a unei singure flote nu este recomandată aici:
  • Cel de 260 presupune un risc de 15% de a avea o deficiență de capacitate de cel puțin 1 dispozitiv, adică o deficiență medie de aproximativ 5 dispozitive
  • Soluția 268 este o soluție destul de mixtă: mai scumpă decât soluțiile asimetrice pentru pooling, care nu este mai bună.

Această punere în comun asimetrică este totuși posibilă numai atunci când:

• Există asta Comunitatea ascendentă în capabilități [de ex.: HAD = (HAP + x)]
• Reatribuirea este viabil din punct de vedere al costurilor și al termenelor limită
• Există un grad ridicat de comunitatea în design (pentru procesul MCO și piese de schimb) astfel încât coexistența să nu ducă la o duplicare a costurilor în comparație cu o singură flotă multirol.
• În cele din urmă, deși este posibilă pentru flotele cu variabilitate mare, această soluție poate fi totuși mai puțin interesantă decât o singură flotă.

(Notă: am evitat în mod deliberat acest aspect al gestionării stocurilor, deoarece ar putea implica diverse strategii care, deși ar trebui luate în considerare în cazul unui astfel de studiu, ar fi complicat înțelegerea aici.)

© Julien Maire.