Fleet management: capabilities and optimization of interoperability

Throughout the article I will mention the “80\20” distribution law.
This is a rough division linked to the normal distribution and its derivatives.
It is often illustrated as a logarithmic curve or f(x) = 1-1/x.

From one extreme to the other

Often, the fleet management debate is divided between:

• a set of dedicated fleets, cheaper, less complex and less risky
• and a single, multi-role fleet, allowing a smaller fleet

Dedicated, cheaper fleets?

Not necessarily :

If the devices are less expensive per unit, or even when acquiring fleets, the multiplication of these devices generates a multiplication of direct operating costs: number of flight crew, maintenance costs, etc.
Sadly, a lot (quantity) of a little (unit cost), gives a lot (cost of fleet operability).

In contrast, the omnirole fleet (single multirole fleet):

Based on this observation, the solution of a single, omnirole fleet is often considered…
At the cost of a more complex system (more expensive to acquire, but also to maintain), it is possible to considerably reduce the fleet (sometimes up to 1/3) and therefore multiply direct costs.
But, a little (quantity) a lot (unit cost), also gives a lot (cost of fleet operability).

Often poorly calculated, sized while ignoring issues of space and time, it is then required to have a certain gift of impossible ubiquity.
This problem is often resolved retrospectively by an additional order of a few additional copies.

I will not go over all these aspects that I have already had the opportunity to address and treat in other articles.

The Economic Point:

Between these 2 extremes, there is a more nuanced compromise, called Economic Point, or economic quantity.

Let's remember the need:

• Meet operational needs
• At the best cost at completion (i.e. acquisition + operation, all costs included, including management of flight crew)

A quick reminder of the cost at completion:
Too often, analytics is reduced to device management. However, the need is not to acquire and manage a fleet of aircraft, but to satisfy mission needs.
This of course includes the devices, but not only: let's just talk about the cabin crew.

The ability of a system (i.e. a set of elements) to satisfy a need dimensioned in space and time is what we call the Capability.

fundamentals

Correctly define your need

I am not going to return to the calculation of fleet size optimization, which I address in the article “ Calculate Fleet Capability« 
The purpose of this article is to address the fair distribution between a set of dedicated fleets and a single, omnirole fleet.

Talking about capability means talking about the dimensioning of skills and abilities.
So a set of means providing a response to a set of needs.

What are these needs?
The need for a resource is each time it is “assigned” to a use:

• Employment for a mission (whatever it may be)
• But also “available on request” (example: SAR)
• Without forgetting downtime for maintenance (online or periodic)
• And above all, the level of risk of unreliability that we choose to take into account with regard to the expected specifications (and which is too often forgotten, which leads to capacity disruptions).

This results in a probability of need:

From this probability a rate of need is deduced, i.e. allocations:

To put it simply, let's take the hypothesis in relation to this graph of a fleet of 200 aircraft.
Technically, these first steps are a little more complex, especially because of the risk consideration aspect. I will pass you these steps which, although they participate, are not the heart of the subject.

For more information on these aspects, I invite you to read the book “6 Sigma: how to apply it” by Maurice Pillet.

Note in passing that the integral of this integral makes it possible to deduce a rate of flexibility to absorb various hazards such as:

• Failure (i.e. the unforeseen deviation from the estimated reliability of the equipment).
• A certain evolution of the need.
• Management of mid-life retrofits and/or major inspections, resulting in an increase in need over a specific period.

Compared to the size of the fleet, this flexibility rate will give a “depth of flexibility”, i.e. an outstanding amount.

Interoperability optimization:

To illustrate, I will consider the 2 needs:

• one requiring a fleet of 140 to 200 aircraft
• the other ranging from 60 to 100 devices

(I specify for all intents and purposes that these values ​​were chosen at random prior to the exercise)

First of all, let us remember that this optimization only concerns what is common, interchangeable, and in no case dedicated equipment which must be dimensioned according to all of its own needs.

Extreme 1: 2 dedicated fleets

• All fleets = 300 (200 + 100)
• Average employment = 250 ((140+200)/2 + (60+100)/2)

Note that you therefore have, on average, 50 “dormant” devices, or 17% of your fleet or, as some calculate: 20% (Average_Dormant / Average_Employment = 50 / 250).

Extreme 2: 1 common multirole fleet

First of all, it should be remembered that the commonality of the 2 fleets is not the average of the 2 ranges of variability !
So, it is not 50 ( [(100-60) + (200-140)] / 2 ).
This type of error (committed more often than we think) leads to capacity disruptions.

This error is often made by reasoning on averages only:

• An average requirement of 170 on one side (140 + (200-140)/2)
• And 80 on the other (60 + (100-60)/2)
• … This is how you get to 250, which will inevitably lead to capacity disruptions

In the present case of 2 fleets, the commonality rule is quite simple:
Communality will be at most the most restrictive variability, and therefore the weakest:
200-140 = 60
100-60 = 40
The community will therefore be 40.

The limits of this second calculation:

This theoretical calculation suffers from several flaws linked to the fact that at no time is the capacity analysis of fleet consolidation taken into consideration:

• 1st flaw: shared need at the peak :

The previous calculation considers as a unilateral hypothesis that when one fleet is at full use, the other is at minimal use.
Depending on the degree of alignment between the needs of the two fleets, this may lead to capacity disruptions.

The average probability of having at least 1 device breaking is 15%...
7% to have at least 5…
(excluding the following fault impacts)

« 15%!? It is acceptable »...
… Not necessarily :
15% to have a deficiency of at least 1 device. It would be appropriate to weight by the depth of the deficiency (for example, with 5 devices, we are at 7% probability... Or a deficiency of 0.35).
Performing a minimum calculation, the degree of deficiency should be around 5 devices. This is equivalent to saying that you will have permanently missing 5 devices. Some activity postponements will be required.

• 2nd flaw: reallocation. This is not zero charge.

Each reassignment may require various loads on the equipment, such as its conveying, the installation or removal of equipment, or even repainting the device in the colors of its new assignment.
This load must be taken into account in the equation.

• 3rd flaw: always the reallocation of pooling pushed to its climax.

The less flexibility you have, the more you will be forced to make reallocations. While flexibility depth will give you the “pre-positioned” reserve, all the way to the opposite end where, with the 2 dedicated fleets, you have no reallocation to make.

3rd flaw which naturally leads us towards our more moderate solution:

Pooling depth

As mentioned in the article on capacity calculation, there are 3 notions linked to pooling:

• The shared fleet
• The dedicated fleet
• And the prepositioning of the shared fleet

As we've seen, full pooling is not necessarily wise (unless we have flexibility levers on the reallocation factors, allowing these reallocations to be moderated).

80\20:
Below 20% of the maximum possible pooling (i.e. 8 in our example), we can consider that it is not interesting to pool: the gain, if there is any, will be too low.
Beyond 80% (i.e. 32), we can reasonably assume that there will be capacity disruptions.

Without going into explanatory details, placing yourself at 80% of the maximum pooling reduces the risk of outage by 45% (i.e. more than 8% average risk of a capacity outage of at least 1 device).

Economic Point: cost optimization :
I spoke to you in the introduction about the notion of Economic Point.
You can evaluate the optimal pooling in terms of costs by taking into account the factors:

• For each shared device, there is 1 less device ordered (note: the cost of the versions is not necessarily the same)
• Which is opposed by the cost of reallocation (conveying, installation/removal, etc.)
• Weighted by the average probability of reallocations over a period, multiplied by the number of periods of the hardware lifespan

But let’s address the real issue of commonality:

Asymmetric pooling

To begin, let's end a totem:
No, it is absolutely not necessary to have a single, single, common interchangeable fleet to enjoy its benefits.

If you have followed the instructions correctly, you will have understood that there is a fleet base on both sides which does not need to be made interchangeable.
If full interchangeability is desirable, it is because it simplifies the equation in fleet management.

But he is a special case where asymmetric pooling is more advantageous :

I addressed the aspect of sharing, sometimes evoking the notion of commonality. But what is this commonality?
If in the first extreme, no commonality is required, the two fleets being distinct, the chapters on the pooling of a single fleet therefore assume complete commonality.
That is to say that all of the aircraft from the 2 fleets (so 260 to 300 aircraft, 268 recommended) can meet the needs of fleet A or fleet B.

Ascending communality

Widely used in computing, backward compatibility is the principle according to which a new version ensures the functioning of one or more previous versions.

In the case of the development of a base version A, from which the others come from the development of deviations from this version, this type of compatibility is entirely applicable.
Ainsi, the Tiger HAD, derived from the HAP, is capable of carrying out all HAD and HAP missions; while the HAP can only carry out its HAP missions.

In this type of case of ascending commonality, it is not necessary to have commonality across the entire fleet, by correctly estimating the bases.
Thus, in the case of the Tiger, 2/3 of its mission requirements are of the HAP type. Knowing also that deployment is usually done in triplets and that a HAD never goes on a mission without a HAP, 1/3 of the devices could have been kept in the HAP version without risk.

practical example

Let's return to our 2 needs of 100 (60 to 100) and 200 (160 to 200):
The calculation can be refined, if we know how to correctly estimate, if not measure, the capacity sizing.
The exercise can quickly become complex if we consider that each fleet is in reality divided into sub-fleets (the different bases, Opex deployments, the fleet under maintenance, etc.).
(here again, I invite you to consult the article cited above for more details)

By default, I will stay on an 80\20 split:

The hypotheses to take into consideration are therefore:

• In order to maintain a certain flexibility in the management of dedicated fleets:
  • 20% of variability will remain considered as belonging to dedicated fleets
    (Indeed, there is a 95% chance of employment for these first 20 percent)
  • In fact, the overlap of variabilities (therefore the optimization of the fleet size) will be done on a maximum of 80% of these.
• In order to also have flexibility in the management of reassignments:
  • the overlap must represent a maximum of 80% of the poolable fleet. Ideally: 80% ^ number_Axis_Reallocations.
    (Thus, if you want to take into account local allocations [bases, Opex…], you have a 2nd axis and therefore 80%^2 = 64%)
• Finally, in order to moderate reallocations:
  • the overlap should only represent a maximum of 80% of the shared fleet.

Depending on the fleet with the Ascending Communality capability, we obtain:

Note that in both cases the total of the 2 fleets is 2:
200 of Requirement A + 60 of the minimum requirement of B + 8 (40 x 0.2) of the first 20% of the variability of B.

Likewise, the distribution in the base assignment (and the associated prepositioning) depends above all on the probability of employment level of the 2 fleets, on their overlapped part, and not on the extent of the shared fleet:

Need A	89	88	87	86
Probability	9%	Present in several = 12%	Present in several = 15%	Present in several = 18%
Need B	186	187	188	189
Probability	Present in several = 16%	Present in several = 14%	Present in several = 12%	Present in several = 10%

Conclusion

Asymmetric Mutualization, taking advantage of Ascending Communality, allows the best compromise between:

• Optimize fleet size
• Without providing all of this with the most expensive version
• While benefiting, to a large extent, from the same advantages as a single fleet

In the absence of quantified budgetary evaluations, I leave it to everyone to form their own opinion.
However, here is my conclusion & recommendation:

• If the Marine fleet is that of 200 [#°1], it is not interesting to keep dedicated fleets. We must move towards pooling (complete [at 250] or asymmetrical)
• If the Navy fleet is that of 100 [#°2] (which is more likely), the best scenario is asymmetric pooling
• In any case, pooling a single fleet is not recommended here:
  • That of 260 assumes a 15% risk of having a capacity deficiency of at least 1 device, i.e. an average deficiency of around 5 devices
  • The 268 solution is a fairly mixed solution: more expensive than asymmetric solutions for pooling which is not better.

This Asymmetric Pooling is nevertheless only possible when:

• There is this Ascending Communality in capabilities [e.g.: HAD = (HAP + x)]
• The reassignment is viable in terms of costs and deadlines
• There is a high degree of commonality in design (for MCO process & spare parts) so that coexistence does not result in a duplication of costs compared to a single multi-role fleet.
• Finally, although possible on fleets with high variability, this solution may nevertheless be less interesting than a single fleet.

(Note: I have deliberately avoided this aspect of stock management, as this could involve various strategies which, although they should be taken into consideration in the case of such a study, would have complicated the understanding here.)

© Julien Maire.