Flådestyring: kapaciteter og optimering af interoperabilitet

Igennem artiklen vil jeg nævne "80\20" distributionsloven.
Dette er en grov opdeling knyttet til normalfordelingen og dens derivater.
Det er ofte illustreret som en logaritmisk kurve eller f(x) = 1-1/x.

Fra den ene yderlighed til den anden

Ofte er flådestyringsdebatten delt mellem:

• et sæt dedikerede flåder, billigere, mindre komplekse og mindre risikable
• og en enkelt flåde med flere funktioner, hvilket muliggør en mindre flåde

Dedikerede, billigere flåder?

Ikke nødvendigvis :

Hvis enhederne er billigere pr. enhed, eller endda ved anskaffelse af flåder, genererer multiplikationen af ​​disse enheder en multiplikation af direkte driftsomkostninger: antal flybesætninger, vedligeholdelsesomkostninger osv.
desværre, meget (mængde) af lidt (enhedspris), giver meget (omkostninger ved drift af flåden).

I modsætning hertil, omnirole flåden (enkelt multirolle flåde):

Baseret på denne observation betragtes løsningen af ​​en enkelt, omnirole flåde ofte...
På bekostning af et mere komplekst system (dyrere at anskaffe, men også at vedligeholde), er det muligt at reducere flåden betydeligt (nogle gange op til 1/3) og derfor multiplicere de direkte omkostninger.
dog lidt (mængde) meget (enhedsomkostninger), giver også meget (omkostninger ved drift af flåden).

Ofte dårligt beregnet, størrelse, mens man ignorerer spørgsmål om rum og tid, er det så nødvendigt at have en vis gave af umulig allestedsnærværende.
Dette problem løses ofte retrospektivt ved en ekstra bestilling på et par ekstra kopier.

Jeg vil ikke gennemgå alle disse aspekter, som jeg allerede har haft mulighed for at behandle og behandle i andre artikler.

Det økonomiske punkt:

Mellem disse 2 yderpunkter er der et mere nuanceret kompromis, kaldet Economic Point eller økonomisk kvantitet.

Lad os huske behovet:

• Imødekomme operationelle behov
• Til den bedste pris ved færdiggørelse (dvs. anskaffelse + drift, alle omkostninger inkluderet, inklusive ledelse af flyvebesætning)

En hurtig påmindelse om omkostningerne ved færdiggørelse:
Alt for ofte reduceres analyser til enhedsadministration. Behovet er dog ikke at erhverve og administrere en flåde af fly, men at tilfredsstille missionsbehov.
Dette inkluderer selvfølgelig enheder, men ikke kun: Lad os lige tale om kabinepersonalet.

Et systems (dvs. et sæt af elementer) evne til at tilfredsstille et behov dimensioneret i rum og tid er det, vi kalder Evne.

fundamentals

Definer dit behov korrekt

Jeg vil ikke vende tilbage til beregningen af ​​flådestørrelsesoptimering, som jeg behandler i artiklen " Beregn flådekapacitet« 
Formålet med denne artikel er at behandle den retfærdige fordeling mellem et sæt dedikerede flåder og en enkelt, allemandsflåde.

At tale om kapacitet betyder at tale om dimensionering af færdigheder og evner.
Altså et sæt midler, der giver et svar på et sæt behov.

Hvad er disse behov?
Behovet for en ressource er hver gang den "tildeles" til en anvendelse:

• Ansættelse til en mission (hvad det end måtte være)
• Men også "tilgængelig på anmodning" (eksempel: SAR)
• Uden at glemme nedetid for vedligeholdelse (online eller periodisk)
• Og frem for alt det risikoniveau for upålidelighed, som vi vælger at tage højde for i forhold til de forventede specifikationer (og som alt for ofte glemmes, hvilket fører til kapacitetsafbrydelser).

Dette resulterer i en sandsynlighed for behov:

Ud fra denne sandsynlighed udledes en behovsgrad, dvs. allokeringer:

For at sige det enkelt, lad os tage hypotesen i forhold til denne graf af en flåde på 200 fly.
Teknisk set er disse første trin lidt mere komplekse, især på grund af risikoovervejelsesaspektet. Jeg vil give dig disse trin, som, selvom de deltager, ikke er kernen i emnet.

For mere information om disse aspekter, inviterer jeg dig til at læse bogen "6 Sigma: hvordan man anvender det" af Maurice Pillet.

Bemærk i forbifarten, at integralet af dette integral gør det muligt at udlede en grad af fleksibilitet til at absorbere forskellige farer såsom:

• Fejl (dvs. den uforudsete afvigelse fra udstyrets estimerede pålidelighed).
• En vis udvikling af behovet.
• Håndtering af midtvejs eftermonteringer og/eller større eftersyn, hvilket resulterer i et øget behov over en specifik periode.

Sammenlignet med flådens størrelse vil denne fleksibilitetsrate give en "fleksibilitetsdybde", dvs. et udestående beløb.

Interoperabilitetsoptimering:

For at illustrere, vil jeg overveje de 2 behov:

• en, der kræver en flåde på 140 til 200 fly
• den anden spænder fra 60 til 100 enheder

(Jeg specificerer for alt i verden, at disse værdier blev valgt tilfældigt før øvelsen)

Først og fremmest, lad os huske det denne optimering vedrører kun det, der er almindeligt, udskifteligt og i intet tilfælde dedikeret udstyr, som skal dimensioneres efter alle dets egne behov.

Extreme 1: 2 dedikerede flåder

• Alle flåder = 300 (200 + 100)
• Gennemsnitlig beskæftigelse = 250 ((140+200)/2 + (60+100)/2)

Bemærk, at du derfor i gennemsnit har 50 "sovende" enheder, eller 17% af din flåde eller, som nogle regner med: 20% (Gennemsnitlig_dvalende / Gennemsnitlig_Beskæftigelse = 50 / 250).

Extreme 2: 1 fælles flerrolleflåde

Først og fremmest skal man huske det fællestrækket for de 2 flåder er ikke gennemsnittet af de 2 variationsområder !
Så det er ikke 50 ( [(100-60) + (200-140)] / 2).
Denne type fejl (begået oftere end vi tror) fører til kapacitetsforstyrrelser.

Denne fejl begås ofte ved kun at ræsonnere på gennemsnit:

• Et gennemsnitligt krav på 170 på den ene side (140 + (200-140)/2)
• Og 80 på den anden (60 + (100-60)/2)
• … Sådan kommer du til 250, hvilket uundgåeligt vil føre til kapacitetsafbrydelser

I det nuværende tilfælde med 2 flåder er fællesreglen ret enkel:
Fællesskab vil højst være den mest restriktive variabilitet og derfor den svageste:
200-140 = 60
100-60 = 40
Samfundet bliver derfor 40.

Grænserne for denne anden beregning:

Denne teoretiske beregning lider af adskillige mangler forbundet med, at der på intet tidspunkt tages hensyn til kapacitetsanalysen af ​​flådekonsolidering:

• 1. fejl: fælles behov på toppen :

Den tidligere beregning betragter som en ensidig hypotese, at når den ene flåde er ved fuld udnyttelse, er den anden ved minimal brug.
Afhængigt af graden af ​​tilpasning mellem de to flåders behov kan dette føre til kapacitetsafbrydelser.

Den gennemsnitlige sandsynlighed for at have mindst 1 enhed der går i stykker er 15 %...
7 % for at have mindst 5...
(eksklusive følgende fejlpåvirkninger)

« 15%!? Det er acceptabelt " ...
… Ikke nødvendigvis :
15 % for at have en mangel på mindst 1 enhed. Det ville være passende at vægte efter dybden af ​​defekten (for eksempel, med 5 enheder er vi på 7% sandsynlighed... Eller en mangel på 0.35).
Ved at udføre en minimumsberegning bør graden af ​​mangel være omkring 5 enheder. Dette svarer til at sige, at du vil have mangler permanent 5 enheder. Nogle aktivitetsudsættelser vil være påkrævet.

• 2. fejl: omfordeling. Dette er ikke nulafgift.

Hver omplacering kan kræve forskellige belastninger af udstyret, såsom dets transport, installation eller fjernelse af udstyr, eller endda genmaling af enheden i farverne for dens nye opgave.
Denne belastning skal tages i betragtning i ligningen.

• 3. fejl: altid omfordelingen af ​​pooling skubbet til sit klimaks.

Jo mindre fleksibilitet du har, jo mere vil du blive tvunget til at foretage omfordelinger. Mens fleksibilitetsdybden vil give dig den "forudplacerede" reserve, helt til den modsatte ende, hvor du med de 2 dedikerede flåder ikke har nogen omfordeling at foretage.

3. fejl, som naturligvis fører os mod vores mere moderate løsning:

Pooling dybde

Som nævnt i artiklen om kapacitetsberegning er der 3 begreber knyttet til pooling:

• Den fælles flåde
• Den dedikerede flåde
• Og præpositioneringen af ​​den delte flåde

Som vi har set, fuld pooling er ikke nødvendigvis klogt (medmindre vi har fleksibilitetshåndtag på omfordelingsfaktorerne, hvilket gør det muligt at moderere disse omallokeringer).

80\20:
Under 20 % af den maksimalt mulige pooling (dvs. 8 i vores eksempel), kan vi overveje, at det ikke er interessant at pulje: gevinsten, hvis der er nogen, vil være for lav.
Ud over 80 % (dvs. 32) kan vi med rimelighed antage, at der vil være kapacitetsforstyrrelser.

Uden at gå i forklarende detaljer reducerer du risikoen for udfald med 80% ved at placere dig selv på 45 % af den maksimale pooling (dvs. mere end 8 % gennemsnitlig risiko for kapacitetsudfald på mindst 1 enhed).

Økonomisk pointe: omkostningsoptimering :
Jeg talte til dig i introduktionen om begrebet Economic Point.
Du kan vurdere den optimale sammenlægning med hensyn til omkostninger ved at tage hensyn til faktorerne:

• For hver delt enhed er der bestilt 1 enhed mindre (bemærk: prisen på versionerne er ikke nødvendigvis den samme)
• Hvilket modarbejdes af omkostningerne ved omfordeling (transport, installation/fjernelse osv.)
• Vægtet med den gennemsnitlige sandsynlighed for omallokeringer over en periode, ganget med antallet af perioder af hardwarens levetid

Men lad os tage fat på det egentlige spørgsmål om fællestræk:

Asymmetrisk pooling

For at begynde, lad os afslutte et totem:
Nej, det er absolut ikke nødvendigt at have en enkelt, enkelt, fælles udskiftelig flåde at nyde dens fordele.

Hvis du har fulgt instruktionerne korrekt, har du forstået, at der er en flådebase på begge sider, som ikke skal gøres udskiftelig.
Hvis fuld udskiftelighed er ønskelig, skyldes det, at det forenkler ligningen i flådestyring.

Men han er en særligt tilfælde, hvor asymmetrisk pooling er mere fordelagtig :

Jeg behandlede aspektet af deling, undertiden fremkaldte forestillingen om fællesskab. Men hvad er dette fællestræk?
Hvis der i den første yderlighed ikke kræves fællesskab, da de to flåder er adskilte, antager kapitlerne om sammenlægningen af ​​en enkelt flåde derfor fuldstændig fællesskab.
Det vil sige, at alle flyene fra de 2 flåder (altså 260 til 300 fly, 268 anbefales) kan opfylde behovene for flåde A eller flåde B.

Stigende fællesskab

Udbredt i databehandling, bagudkompatibilitet er princippet, ifølge hvilket en ny version sikrer, at en eller flere tidligere versioner fungerer.

I tilfælde af udvikling af en basisversion A, hvorfra de andre kommer fra udvikling af afvigelser fra denne version, er denne type kompatibilitet helt anvendelig.
Ainsi, Tiger HAD, afledt af HAP, er i stand til at udføre alle HAD og HAP missioner; mens HAP kun kan udføre sine HAP-missioner.

I denne type tilfælde af stigende fællestræk er det ikke nødvendigt at have fællestræk på tværs af hele flåden ved korrekt at estimere baserne.
I tilfældet med Tiger er 2/3 af dens missionskrav af typen HAP. Velvidende også, at implementeringen normalt udføres i trillinger, og at en HAD aldrig tager på en mission uden en HAP, kunne 1/3 af enhederne have været holdt i HAP-versionen uden risiko.

Praktisk eksempel

Lad os vende tilbage til vores 2 behov på 100 (60 til 100) og 200 (160 til 200):
Beregningen kan forfines, hvis vi ved, hvordan man korrekt estimerer, hvis ikke måle, kapacitetsstørrelsen.
Øvelsen kan hurtigt blive kompleks, hvis vi tænker på, at hver flåde i realiteten er opdelt i delflåder (de forskellige baser, Opex-udrulninger, flåden under vedligeholdelse osv.).
(her igen inviterer jeg dig til at konsultere artiklen citeret ovenfor for flere detaljer)

Som standard forbliver jeg på en 80\20-deling:

Hypoteserne der skal tages i betragtning er derfor:

• For at opretholde en vis fleksibilitet i forvaltningen af ​​dedikerede flåder:
  • 20 % af variabiliteten vil fortsat blive betragtet som tilhørende dedikerede flåder
    (Der er faktisk 95 % chance for beskæftigelse for disse første 20 procent)
  • Faktisk vil overlapningen af ​​variabiliteter (derfor optimering af flådestørrelsen) ske på maksimalt 80 % af disse.
• For også at have fleksibilitet i håndteringen af ​​omplaceringer:
  • overlapningen må maksimalt udgøre 80 % af den poolbare flåde. Ideelt set: 80 % ^ number_Axis_Reallocations.
    (Hvis du altså vil tage højde for lokale allokeringer [baser, Opex...], har du en 2. akse og derfor 80%^2 = 64%)
• Til sidst, for at moderere omfordelinger:
  • overlapningen bør højst udgøre 80 % af den delte flåde.

Afhængigt af flåden med Ascending Communality-kapaciteten opnår vi:

Bemærk, at i begge tilfælde er det samlede antal af de 2 flåder 2:
200 i krav A + 60 af minimumskravet på B + 8 (40 x 0.2) af de første 20 % af variabiliteten af ​​B.

Ligeledes afhænger fordelingen i basisopgaven (og den tilhørende præpositionering) frem for alt af sandsynligheden for beskæftigelsesniveauet for de 2 flåder, på deres overlappende del, og ikke af omfanget af den delte flåde:

Behøver en	89	88	87	86
Sandsynlighed	9%	12 %	15 %	18 %
Har brug for B	186	187	188	189
Sandsynlighed	16 %	14 %	12 %	10 %

Konklusion

Asymmetrisk gensidighed, der drager fordel af Ascending Community, giver det bedste kompromis mellem:

• Optimer flådestørrelsen
• Uden at give alt dette med den dyreste version
• Mens de i vid udstrækning drager fordel af de samme fordele som en enkelt flåde

I mangel af kvantificerede budgetevalueringer overlader jeg det til enhver at danne sig deres egen mening.
Men her er min konklusion og anbefaling:

• Hvis marineflåden er på 200 [#°1], er det ikke interessant at beholde dedikerede flåder. Vi skal bevæge os mod pooling (fuldstændig [ved 250] eller asymmetrisk)
• Hvis flådens flåde er på 100 [#°2] (hvilket er mere sandsynligt), er det bedste scenarie asymmetrisk pooling
• Under alle omstændigheder anbefales det ikke at samle en enkelt flåde her:
  • Den på 260 antager en 15 % risiko for at have en kapacitetsmangel på mindst 1 enhed, dvs. en gennemsnitlig mangel på omkring 5 enheder
  • 268-løsningen er en ret blandet løsning: dyrere end asymmetriske løsninger til pooling, hvilket ikke er bedre.

Denne asymmetriske pooling er ikke desto mindre kun mulig, når:

• Der er dette Stigende Fællesskab i kapaciteter [f.eks.: HAD = (HAP + x)]
• Omplaceringen er rentabelt i forhold til omkostninger og deadlines
• Der er en høj grad af fælles design (for MCO-proces & reservedele), så sameksistens ikke resulterer i en duplikering af omkostninger sammenlignet med en enkelt flerrolleflåde.
• Endelig, selvom det er muligt på flåder med høj variabilitet, kan denne løsning alligevel være mindre interessant end en enkelt flåde.

(Bemærk: Jeg har bevidst undgået dette aspekt af lagerstyring, da dette kunne involvere forskellige strategier, som, selv om de bør tages i betragtning i tilfælde af en sådan undersøgelse, ville have kompliceret forståelsen her.)

© Julien Maire.