What is Logistic Support Analysis - LSA?

Having published an article asking the question "What is ILS" it seems sensible to reprise the question "what is LSA". The ILS article can be found here: https://www.dhirubhai.net/pulse/what-ils-sequel-peter-stuttard/.

I meet and talk to a lot of people about Support Engineering, ILS and LSA and I am disturbed at the number of “ILS Managers” and “ILS Engineers” who quite simply, do not know what ILS is or what LSA is. There is a belief, increasingly prevalent, that if an organisation is producing technical publications, delivering spares and training courses, supplying support and test equipment, then it is performing ILS and LSA.

If this were true then the engineers of the world have been applying ILS and LSA since the time of the Trojan war (and they haven't...). 

I have also had some disturbing conversations, consider the typical discussion with some organisations, when discussing the topic of Reliability Centred Maintenance [RCM]; these tend to go along the lines of:

Me: “Why don’t you integrate the RCM process and the associated tools with the ILS / LSA process?”

Respondent: “They are in a different part of the organisation, we will never be able to get agreement or approval…”

Me: “You could have common data sets, share data, use common tools between projects, get control configuration of your output…”

Respondent: “Our project won’t fund any such initiatives… and that would need the say so of the IT department…”

Me: “You could rationalise your processes, streamline your data flows…”

Respondent: “We certainly need to do that, but it will take years, if it happens at all…”

Now I have had this conversation (or as near to this as makes no difference…) with at least three, not insignificant, organisations who are therefore passing up on the opportunity to make appreciable improvements to their support offerings. 

They all claim to be doing ILS and LSA, but they are not. 

To recap first "What is ILS", well we can identify at least six categories of “Integration” or coherence that we need to address if we are claiming that we are implementing ILS, they are:

1.      The Mission System design has to take cognisance of the probable operational environments, the terrain, the length of the Lines of Communication [LOCs], the physical environment, enemy action, etc

2.      The Support System design (the support infrastructure) also needs to take cognisance of the probable operational environments, the terrain, the length of the Lines of Communication [LOCs], the physical environment, enemy action, etc

3.      The support aspects of the Mission System design need to be considered as a whole, these include system architecture, the ability to conduct battle damage repair, upgradability, standardisation, human factors, the use of low risk resources (including, but not limited to considering the risk of obsolescence) etc, as well as durability, robustness, reliability, maintainability and testability.

4.      Similarly, the elements of the Support System design have to be regarded as a whole, (this is why we refer to it as the Support System), all the processes, the organisations, the infrastructure and the resources that comprise the Support System should be complementary.

5.      The Support System has to complement the Mission System, and vice versa.

6.      Finally, the processes by which the five aims above are achieved, the ILS or Support Solution Engineering processes, should be coherent; nugatory effort and omissions should be eliminated. 

In simple terms we should implement an optimal management and engineering process which aims to deliver optimal Support Solutions.

This article is about LSA however (or Support Analysis if you prefer). LSA is a subset of the activities addressed in bullet 6 above.

There are two facets of LSA, the first is simple, the aim is to apply engineering and analytical techniques that will facilitate the optimisation of the Support Solution. Hence LSA calls for modelling techniques (tradeoffs, optimisation etc), structured analyses, learning from experience, risk and opportunity identification, mitigation and exploitation etc.

The second aspect is the application of some simple logic; the original authors of the first LSA standard studied a range of disparate support activities and discovered that the same, or very similar analytical activities were being implemented, independently, by many of them. For example, reliability engineers would conduct a Failure Modes, Effects and Criticality Analysis [FMECA] for the purpose of ensuring a system was safe, RCM analyst would also conduct an FMECA to identify maintenance tasks, elsewhere people would be conducting “Warranty Analysis”; there would be no consistency across these disparate FMECA (Warranty Analysis is similar to an FMECA). Similarly, separate organisations would address training, technical publications, and spares provisioning etc, and do so in splendid isolation. Not only was this inefficient, there being significant duplication of effort (they would all require some definition of the system for example), but the results were, inevitably, inconsistent and divergent. 

LSA was designed so as to consolidate these disparate processes into a more coherent approach, to remove duplication, to strive for a single set of supporting information, a single version of the truth, (this is where the dreaded LSAR comes in). 

A very laudable aim.

(There are people who argue that different FMECA’s are required for different tasks, but it is perfectly possible to develop the FMECA, in an iterative manner that will satisfy the needs of all disciplines).

The LSA process was also designed as an integral element of a Systems Engineering process, it was designed to applied in an iterative manner, (evolutionary, incremental or agile if you prefer).

What is disappointing is that this excellent approach has barely evolved since its inception in the early 1980’s and it has, very frequently, been misapplied. As one of my friends stated in response to the article on “What is ILS” if you try to translate 5 discrete processes into one coherent process, you end up with 6 discrete processes. This has been the fate of LSA on a great many programmes, it hasn’t been applied “instead of” the extant approaches, but “as-well as”.

Now many techniques and technologies have been transformed in the 30+ or so years since the first US Mil Std 1388-1A was published, but this is rarely reflected in the standards and the methods that are applied. 

To illustrate:

• There is significant potential to improve the FMECA methodology, we could integrate this with Fault or Event Tree Analysis [FTA / ETA] we should and could, be analysing “System Failure Dynamics”. 
• We could integrate the TNA process with the LSA process, consolidating it with Task Analysis
• We could integrate the Training and Technical Documentation development processes and the resulting products. 
• We could capitalise on the capabilities of modern simulation modelling tools when conducting Level Of Repair Analysis, Spares Optimisation, Through Life Costing [TLC] analyses (to support investment appraisals) and trade?offs of all descriptions.
• We could capitalise on the capabilities of modern software and produce a series of really effective, flexible and dynamic (i.e. they can evolve, and do so readily) tools. (Modern LSAR’s are still based on a standard developed in the early 1990’s).
• etc

We have to ask ourselves why the tools and the methods have changed so little over the years? We have to ask ourselves why separate, very prescriptive, standards are being developed today e.g. for RCM and LSA, rather than integrated, high level standards that propound fundamental principles. 

Why we are following a path of disintegration rather than integration; why would anyone suggest that we should conduct one FMECA to identify preventative maintenance tasks and another FMECA to identify corrective maintenance tasks?

It is time we adopted a Systems approach, it is time we developed a Systems Engineering based standard for Support Solution Engineering, it is time we revisited and updated the LSA process. This is perfectly feasible, it would not take long, (it would need the right people), it would have a significant, positive, impact on the operational effectiveness and TLC of our Defence equipment.