“ILS is a construct made up by consultants, to spend the available budget, to generate employment and to confuse senior executives, it is the last refuge of the charlatan”.
…Or so it has been described… and given some of the ILS programmes we have witnessed, we can understand such cynicism.
There are many standards which attempt to define what ILS is and to describe the ILS methodology, whether they have been successful or not is open to debate. In part, such standards fail, as many ILS programmes fail, because they do not address the most fundamental principles that should lie at the core of any ILS methodology or ILS programme.
So perhaps it is time to get back to basics, time to ask some dumb questions such as what do we mean by “Integrated”, and what, precisely, is “logistic support”, what is LSA, what is the “product” of an ILS programme?
Rather than attempting to describe, or to interpret ILS, as defined in the standards or text books let’s adopt an alternative approach and ask what ILS should be, and then any fundamental principles should become clear.
We can do this by approaching the problem in a logical and structured manner, applying a healthy dollop of good old fashioned common sense and a bit of clear thinking as we go.
We can start with a simple statement:
The output, the ‘Product’, of an ILS programme is a Support Solution. The aim of an ILS programme is to develop and then to maintain an optimal Support Solution. That Support Solution should be developed and maintained by applying the most logical, practicable, most cost effective methodology that it is possible to define.
I think this statement is uncontentious, we can develop our argument from here. The first point to note is that we need to optimise two things, the Support Solution and the methodology by which that solution is developed. In other words, we need to optimise the Product and the Process of ILS.
An “Optimal” ILS Product will be a Support Solution that delivers the maximum Operational Capability, at minimum Through Life Cost [TLC]. We should note that 2,3 and 4* officers from the Front Line Commands [FLCs] are asking for flexible, agile, dynamic and adaptable Support Solutions; they want greater support velocity, greater support precision, the ability to “Fight Hurt”, and greater visibility. We need to deliver this with shrinking finances and fewer resources.
We could spend a lot of time discussing what each of these statements mean, which we haven’t the space to do here, but I think we can agree that what the FLCs want, that what they need, is an improved standard of engineering support, a better Support Solution.
We now need to define what we mean by a “Support Solution”. This is a relatively simple question to answer; if we are going to support a piece of complex military equipment, that equipment needs to be “supportable” and we will need a lot of stuff, we will need physical resources, spares, tools, test equipment, consumables, transport, facilities, we will need a lot of information and information management systems, and we will need a lot of people, maintainers, suppliers, drivers, etc.
But plainly this is not enough, resources on their own will not meet the need, we will also need systems and processes to move, to deliver, to repair, to recover, to update, to resupply, to train and to retrain personnel …
…and these processes will then require additional resources, for example training materials, class rooms, training aids and teachers.
i.e. we need a support infrastructure that will get the right stuff, the right resources, in the right place, in the right quantities, in the right condition, at the right time.
This support infrastructure will be very complex, it can be regarded as a system, the Support System. This Support System must complement the Mission System and it must take account of the manner and the environment in which that Mission System is operated and supported, I am going to call the definition of the operating and support environment the Employment Plan. The Mission System design has many features that will influence support (reliability, robustness, durability, architecture, built in obsolescence and many more), wherever possible an ILS programme should strive to optimise the support aspects of the Mission System design. Similarly, the Employment Plan must take cognisance of Support requirements.
A support solution
The first principles are now apparent, we need to take a “Systems” approach to support engineering, the Support Solution addresses the support aspects of the Mission System design, the Support System and key aspects of the Employment Plan. Each should be optimal but collectively they must form a coherent, integrated, optimal system, the Total System, it is this system and the interactions between its element that determine through life cost and operational capability.
We have addressed the Product of ILS, the Support Solution, we must also consider how this support solution is developed, we have to consider the Process that is required if we are to develop an optimal Support Solution.
The ILS process requires us to design and to optimise a very complex system, to manage this complexity, we need to employ Systems Engineering concepts. Whenever practicable we should design the Mission System, the Support System and the Employment Plan concurrently. We should implement spiral development, make extensive use of in service feedback and historical data and deploy tools that facilitate our understanding of complex system dynamics, tools that allow us to predict the behaviour of complex systems. There are many tools and techniques available to the ILS fraternity and the options available increase every year, the trend is for such tools to become more sophisticated, easier to use, and cheaper. Such tools include, complex system models using free agent modelling techniques, data gathering, information management and analysis tools and techniques that facilitate effective feedback, sophisticated training and technical information presentation and management tools, and a range of sophisticated, and affordable, test technologies to mention just a few.
There are however many Support Engineering disciplines, we need to define a common support engineering process if we are to avoid nugatory effort and to minimise divergence between the disciplines outputs. For example, several disciplines make use of Failure Modes, Effects and Criticality Analysis [FMECA], each discipline has their own priorities and each may therefore adopt a slightly different approach.
Effective ILS requires a common FMECA, developed iteratively, in a manner that satisfies the needs of all members of the engineering community, (the Reliability and Maintainability Engineer, the Reliability Centred Maintenance [RCM] analyst and the Safety Engineer) and which does so in a timely manner. There are many other examples of duplication that can be eliminated.
This is the fundamental principle that underpins the concept of Logistic Support Analysis [LSA], that wherever possible a single set of analyses should be performed, eliminating duplication, and preventing divergence. This approach also enables common information sets to be exploited.
An effective ILS methodology replaces a range of disparate analyses with a coherent common approach and a single supporting information set, the R&M engineer, the RCM analyst, the technical author, the provisioning or training specialist, etc, apply their skills to different aspects of a common, integrated, process.
This is a principle that is not addressed in some more recent ILS standards.
Poorly implemented ILS programmes reduce the level of integration, they introduce ILS processes that run in parallel to, rather than replacing, those of the individual support disciplines, they reduce programme effectiveness and they drive in cost. Such programmes squander the significant benefits that accrue if a genuinely integrated set of processes are applied. They are the reason why ILS has gained such a negative reputation.
To summarise, ILS is a series of optimal, highly integrated processes, where nugatory effort has been eliminated, (there is no duplication, no pointless activity), where there are no omissions. Processes which utilise common information sets, that utilise systems thinking and which apply systems engineering techniques, which capitalise on available technologies and techniques, to develop highly integrated and coherent Support Solutions – solutions that are optimal within the given constraints.
ILS is the most logical, most practicable, most cost effective methodology by which an optimal Support Solution can be developed. If your ILS programme doesn’t fit this description, then you need to find an alternative approach.
This article is based on the webinar of the same name I presented last week. This seminar is the the first of a series addressing ILS and related issues that Aspîre are presenting in collaboration with Tech Docs World – TDW.
If you missed it, you can watch the full 40 minute webinar here.
The series of webinars continues with “Decision Theory for Engineering Support – Spares, repairs or logistics – where do we put our money?” which gives a practical exploration of analytical and evidence-based decision making techniques. Matthew Gibbon, leading modelling expert at Aspire, describes just exactly what decision theory is, and how it can be used to influence engineering, logistics and supply chain decision making. You can watch that webinar here.
If you would like to explore these subjects further, Aspîre are running an LSA course in September that will address the ideas presented in these webinars, further details can be found here.