+44 (0) 1827 723 820

🚀 OPEN: ASK Surgery CLICK HERE to book your appointment now! 🚀 | 🎓 Upcoming training events: Task analysis on 2/DEC/2024, Reliability-centered maintenance on 9/DEC/2024, ILS to IPS transition on 21/JAN/2025 CLICK HERE to book your place now! 🎓 | 📅 NOW LIVE: Our 2025 schedule training calendar has been published. You can download a copy of our 2025 calendar HERE 📅

info@aspirecl.com

+44 (0) 1827 723 820 | info@aspirecl.com

OUR NEXT COURSES: 9 Sept RCM – 28 Oct DSAT – 4 Nov PSE & LSA

What is ILS?

What is ILS?

“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 it is defined in the standards or text books let’s adopt an alternative approach and ask what ILS should be, any fundamental principles should then 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 means, 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, the ‘Mission System’ needs to be “supportable”. In addition 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, we call the definition of the operating and support environment the Employment Plan. The Employment Plan must take cognisance of the Support System, its capabilities and its limitations. Now the Mission System design has many features that will influence support (reliability, robustness, durability, architecture, built-in obsolescence and many more), so wherever possible an ILS programme should strive to optimise, to achieve the right balance, between these aspects of the Mission System design (within the given constraint, e.g. cost and technical feasibility).

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, and collectively, they must form a coherent, integrated, optimal system, the Total System; it is this system and the interactions between its elements 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; and we have to consider the Process that will be 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 agent-based 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.

However, there are many Support Engineering disciplines. We need to define a coherent Support Engineering process if we are to avoid nugatory effort and minimise divergence between their outputs. For example, several disciplines use Failure Modes, Effects, and Criticality Analysis [FMECA]. Each discipline has its own priorities and 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. This is just one illustration, 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]: wherever possible, a single set of analyses should be performed, eliminating duplication and preventing divergence. This approach also enables us to exploit common information sets.

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.

In summary, if we review the argument above, we can identify six categories of “Integration” that we need to address if we are to implement ILS effectively, they are:

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

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

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), durability, robustness, reliability, maintainability, and testability.

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, organisations, infrastructure, and resources that comprise the Support System should be complementary.

The Support System must complement the Mission System, and vice versa.

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.

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, reduce programme effectiveness, and 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.

ILS is a series of optimal, highly integrated processes where nugatory effort has been eliminated, and there are no omissions. ILS processes utilise common information sets, employ systems thinking and systems engineering techniques, and 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, practicable, and cost-effective methodology for developing an optimal Support Solution.

If your ILS programme doesn’t fit this description, then you need to develop an alternative approach.

About Aspire

What does Aspire do? Almost every organisation on the planet uses equipment to deliver its service. Very few are always happy with the performance of that equipment. We train, guide and collaborate with organisations to design support solutions that keep equipment performing, so they can deliver their service, consistently and effectively.
Follow Aspire on LinkedIn

About the Author

Peter has been involved in Defence support for all of his working life, initially in the Army and then as a specialist in Supportability Engineering. He has extensive experience as a lecturer and trainer in Supportability Engineering; he has been actively engaged in the development and training of US and UK Defence Standards, including ASD S-Series specifications. As an Army veteran, Peter served in the UK, Canada (BATUS), and Germany maintaining Army and Commando aircraft, he has operated on land and at sea, having deployed on Royal Navy [RN] and Royal Fleet Auxiliary [RFA] vessels. Connect with Peter on LinkedIn

Download this article as a PDF