Talk:Integrated logistics support

An ILS Imperative?

I just did some quick edits mainly directed at reducing the implication that certain parts of the ILS discipline are essential. Whether there are in fact some essential elements might be arguable, but ILS should be presented more like a tool box of tasks that can contribute to meeting general or specific goals of ILS. If anyone wishes to debate this, please comment.67.69.19.58 (talk) 14:53, 7 November 2008 (UTC)

No debate for my part. I just made a number of changes to do just that! Hope you like it.

There's a lot of very relevant detail provided, so I've mostly just focused on reorganization, but I get the impression that this was taken verbatim from a particular ILS framework. I've tried to make the presentation more open, allowing more room for growth from subject-matter experts. I anticipate entire articles for many of the sections. 70.251.6.19 (talk) 21:45, 6 June 2010 (UTC)

Diagnostic Impact on ILS

Having engineered integrated diagnostic systems on multiple "smart" aircraft programs I am always confused as to why the diagnostic system does not get more emphasis during Integrate Logistic System discussions. The Reliability and Maintainability predictions are still the foundation from which programs build a support system on, but the data and software that enables an integrated logistics system is provided by an integrated diagnostic system not the artifacts that go into developing it. Whether it be the tracking and trending of mechanical degradation or the sifting through of data coming from electronic systems in order to arrive at the root cause of failure, the diagnostic system is the responsible entity to the success or failure of an ILS. After all even the best designed support system will not be effective if the system data it operates on is not accurate and that data comes directly from the platform's diagnostic system. Until we, military customers and contractors alike, start to acknowledge the importance of these dependencies I do not believe the level of maturity that we all hope for will be achievable. —Preceding unsigned comment added by 192.249.47.165 (talk) 19:23, 1 July 2010 (UTC)

I believe I see your point, but I disagree somewhat. ILS as a concept doesn't necessarily entail the idea of continuous improvement. If a customer is willing to buy off on a certain level of design reliability and maintainability, along with support, then the purpose of diagnostics isn't really improvement, it is cost-effective execution. That is, diagnostics can be leveraged to make sure that you're repairing the right parts (which saves money), but as long as this is within reasonable expectations of design performance, no red flags need be raised. It sounds like what you seek is more in line with the idea of Performance-based logistics (PBL). In an ILS environment subject to PBL, the idea of continuous improvement is built-in, and more effective diagnostic systems are more valued. It can be expensive to "track and trend" as I'm sure you're aware. You need to show that this expense is less than the benefit to all contracting parties. Under PBL, you just need to demonstrate it to the contractor. 70.247.169.197 (talk) 01:19, 8 August 2010 (UTC)

Let me add that I'm very much in favor of improving the accuracy of "system data". I'm not, however, convinced that the weak link is in the area of diagnostics. As a particular example, prognostics have come a long way in recent years, especially on "smart" aircraft programs. 70.247.169.197 (talk) 01:43, 8 August 2010 (UTC)

Material vs Materiel

The word with an 'a' is more common than with an 'e' but for the topic of ILS, materiel is more appropriate, meaning equipment and supplies, not the products used to make it (the materials). --DeknMike (talk) 20:54, 29 June 2012 (UTC)