IPS - From the horse's mouth
Integrated Product Support - From the horse's mouth

IPS - From the horse's mouth

A little while ago I wrote an article called ‘ILS is dead but, what’s in a name?’ in which I used the semantics of the terms ‘integrated logistic support’ and ‘integrated product support’ to discuss what I perceived to be the difference in scope, or role, between those two concepts.

Are there really two concepts? I think so. I think there is an elegance to the idea that at some point in the enterprise, probably the interface between the buyer and the prime supplier, the focus shifts from product considerations to the broader logistics considerations.

Integrated Support Hierarchy with integrated logistic support and integrated product support depicted

Is it that clear cut? No, of course not. In practice, I know it doesn’t work like that. People in the ILS space will often contract those in the IPS space to fulfil their duties. Even with that said though, with two concepts it is not only far easier to delineate the different responsibilities and viewpoints of those in ILS and IPS but, also to recognise that the benefits of running a support engineering programme are different for the two groups.

So, what’s the point of this article?

Well, much of the body of ‘ILS is dead…’ was written because I didn’t explicitly understand the motivations of the IPS Specification Council or the intent behind changing the name of ILS to IPS or, more importantly, the intent of the S-Series Specifications for IPS. While I understand that ambiguity, grey areas and interpretation provide a safe space for opinion pieces, they don’t necessarily help the community to answer the questions.

So, I asked Phil Williams - Chair of the IPS Council - to help clarify a few points that were raised, his words are in italics below.

How/what is the IPS Specification Council?

The IPS Council was formed a number of years ago when the Aerospace and Defence Industries Association of Europe (ASD) in Brussels signed a Memorandum of Understanding with the Aerospace Industries Association in Washington to co-develop the S-Series specifications. The IPS Council therefore has oversight of the development of the specifications and draws its membership from the S-Series chairs, the Defence Interest Group and other appointed officials.

The IPS Council meets twice a year, alternating between Europe and the USA and maintains regular contact via monthly contact calls; in a nutshell the IPS Council provides the global policy for the specifications.

Bearing in mind that this article is an offshoot of a piece based on semantics, you won’t be surprised to note that I picked up the fact that I called it the ‘IPS Specification Council’ and Phil refers to it as the ‘IPS Council’. What I find interesting in that discrepancy is that one suggests that the council is the arbiter of the IPS discipline and the other suggests that the council is the arbiter of the specification suite.

While Phil clarified that, though referred to as the IPS Council, it’s remit is to unify the international community that is responsible for developing the specifications and not to be the arbiter of the IPS discipline.

That made me wonder, given that IPS as a term existed in the US long before the decision was taken to rename this council (and these specifications), if there is a chance that the US definition of IPS and the S-Series definition of IPS could be different and, therefore, cause confusion. 

What drove the change in name from ILS to IPS?

The change from ILS, (Logistics) to IPS (Product) came in no small part due to the changing perception of the word logistics. In days of yore, logistics seemed to cover all those elements of through life support that the S-Series specification world sought to embrace. However, with the growth in global trade and the public perception of “logistics”, the word’s meaning shifted to become narrower in its interpretation, in short it came to mean the movement of goods, the delivery of product via the new global behemoths such as FedEx.

While the S-Series continued to service a limited community, who would claim to understand a more traditional meaning of logistics, an aspiration to encourage the adoption of the S-Series into a wider world, automotive, rail, shipping highlighted a need for clarification. The IPS Council therefore determined that the new users would gain a better understanding of through life support, if we set them off on the right foot.

the word’s meaning shifted to become narrower in its interpretation, in short it came to mean the movement of goods

In ‘ILS is dead…’, I offered a version of this story whereby ‘product’ had been adopted to allow industry to take control of their portion of the ILS concept. As stated earlier in this article, I believe there is merit in that idea.

As it turns out though, the motivation for renaming the concept is both two-fold and, a little underwhelming. The term ‘logistics’ has been ditched, in the first instance, to distance the support engineering concept from the string of haulage firms that have adopted and diluted its meaning. In truth, I struggle to get on board with this argument, it feels like a capitulation when perhaps a more valiant course would be to lead support engineers in a bid to reclaim the logistics mantle.

Maybe like King Canute we should accept that the tide is rising on this issue and the word logistics has been lost to the dark side; conversely, NATO seem to be sticking with it, so who knows?

The second reason though, I can get on board with. Encouraging the wider supply chain to adopt the mindset of processes that underpin integrated logistic support, makes a lot of sense. If the organisations that comprise the supply chain - big or small - implement logistic support as everyday business, in the integrated way intended, then the impact would be huge, for everybody. The supply chain organisations will no longer haemorrhage cash reacting to support engineering requirements that change between customers and projects; the user community will benefit from reduced procurement costs and, of course, better availability and leaner through life cost of their equipment.

What is the intent of the S-Series?

The S-Series aims to optimise through life support of complex systems, be that a ship, aircraft, train, car etc. This can only be achieved if the end customer, and traditionally this has been a Ministry of Defence, understands the through life requirements that he can pass to his supply chain. It is then imperative that all members of the supply chain, regardless of the tier, also adopts the same specifications so data can flow for top to bottom and back again.

S-Series aims to optimise through life support

This is a topic that is arguably not that well defined within the S-Series community. Are the S-Series Specifications data specifications, with processes designed to populate that data or, are they specifications that will result in an optimal through life support solution? Those two things aren’t necessarily the same thing.

The output of a support engineering data specification, is support engineering data. Whereas, the output of a support engineering specification, is a cost-effective through life support solution.

If you are towards the top of the supply chain, the buyer or the integrator or the user, and you’re trying to develop an efficient through life support solution then you need data from the supply chain to enable that. Data that you know will contribute and that you know will be the right shape, created by the right processes and will fit seamlessly into your data thread. In this, you can see that creating a series of specifications aimed at standardising and driving efficiency through the support data supply chain makes sense.

Obviously, as Phil states, it makes sense the other way around too. If you are towards the lower end of the supply chain, you know the same things about the support data coming down from on high.

That ambiguity hasn’t necessarily been addressed either, you can see hints of it in Phil’s response above. It starts with

optimise through life support

and finishes with

so data can flow

Despite the apparent ambiguity, it remains a key point. A point that lies at the heart of the S-Series identity and, answering it will shape the specifications going forward. Unfortunately, so will not answering it.

Who is the S-Series for?

It could be argued that as more customers, and again I would stress historically Government and Defence Departments, mandate the use of the S-Series, then the S-Series is for everyone involved in the procurement and support of complex systems.

Not all projects require the full suite perhaps and the somewhat Byzantine nature of the S-Series can be daunting and indeed a real barrier to adoption; an element of tailoring for each project is required. Hence, there is a need to promote the development of software tools to assist with the implementation of the S-Series and the development of training courses to ensure a consistent approach in the application of the same.

the S-Series is for everyone

When I wrote this question, it was being driven by a want to determine if the S-Series Specifications were intended to replace the plethora of well-known native specifications that are used to govern the conduct of support engineering analyses.

The answer is yes, I think, but not all of them.

They’re taking aim at the well known logistic support data standards like GEIA-STD-0007 or the long-defunct (but still ubiquitous) MIL-STD-1388-2B but, as far as I can tell, they will leave alone the principles documents like TA-STD-0017 or the UK’s Defence Logistics Framework (or its replacement).

The S-Series specifications might be for everyone, but they are not everything to everyone. Those principle-setting documents contain the guidance for creating optimal through life support, the S-Series suite will complement those principles and enable the process with efficiently produced and transmitted support engineering data.

I think though, the most worrying sentiment from this answer is that “the S-Series is for everyone involved in the procurement and support of complex systems” but, only once it has been mandated.

I worry that that sentiment is missing the point and is not learning from past mistakes. There is far more benefit, for a manufacturer in adopting IPS processes, than just the tick in the box on delivery of their wares and that is how the community should be engaged.

IPS makes sense because it is best practice for gathering this data and not just because you have to.

Is there anything else that the IPS Council would like to say to the ILS community?

The first thing the IPS Council would wish to say to the IPS community is welcome, and welcome from whatever environment you come from. The Council is keen to promote the widest possible application of the specifications, hence witness the reach out to the worlds of maritime, automotive, rail et al. Note also the global reach, with the latest IPS Defence Interest Group attracting participation from the majority of NATO partners and even our antipodean colleagues dialling-in during the wee small hours.

So, with many thousands of copies of the specifications being downloaded annually and disparate communities joining together, the next big push will be to ensure that there is a commonality of application. The specifications work best when all tiers of the supply change operate coherently and exchange data in common formats, whether considering logistic support analysis, preventative maintenance, operational feedback etc. This will require a step change in the delivery of training to new users and the development of software packages to assist with implementation.

With the IPS Council seeking to release a harmonised suite of specifications on a 2 yearly drum beat, the ask of the marketplace is to get on board with us, develop training courses and tools to match that rhythm and help ensure the successful deployment of the S-Series to enable optimal through life support.

The specifications work best when all tiers of the supply change operate coherently and exchange data in common formats

I want to take the opportunity to thank Phil for taking the time to contribute to this article.

With every answer raising more questions, more thoughts, I found it difficult to pare this article down into a relatively small piece. There are questions unasked and thoughts unaddressed but that is your part to play and your opportunity to join the conversation. I would invite you to take it.

For my part, in sitting down to write this, I think I have cleared some of the fog. Not definitively, but enough for me to understand what some of the IPS Council’s aims are.

The rebranding from integrated logistics support to integrated product support, was simply that; a rebranding. Whether we agree with the term, or not (and I don’t) at least we can establish that the concept that we’re familiar with, is intended to endure.

What the intent of the specifications are and who they are aimed at is, perhaps, still just a little cloudy but, I think it’s fair to say that the focus of the S-Series Specifications is, and will always be, on support engineering data and that their target audience is people involved in the use, creation and maintenance of support data throughout the supply chain.

It’s important to remember though, that data is not the point of support engineering. In the throes of striving to adopt the S-Series, the user (or the buyer) cannot afford to discard the native specifications that ensure that support engineering achieves the optimal through life support solution. The community must recognise that the S-Series is complementary to that and not a replacement.

And that brings me to another recurring response to ‘ILS is dead…’, that it’s the ‘I’ that is the most important concept. Integrated.

The S-Series Specifications, as they stand, may have ‘integrated’ in the title but, dig a little deeper, and there’s a lot of work to be done to live up to that name. That work is being done. Eventually, the S-Series Specifications will include integrated processes that will produce proper, efficient and integrated, support data but the use of the S-Series will have to further integrate with the support engineering policy, guidance and practice of the customer.

'ILS is dead but, what's in a name?' can be found here https://www.dhirubhai.net/pulse/ils-dead-whats-name-lee-fitzsimons.

Daan de Lange

Lead Expert at Cimpa - a Sopra Steria company

3 年

One of the things I stumble across in the discussion that I have with customers and users of the specifications is that they miss the point that it is a specification, not a standard. The good old 1388, 0007, Def-Stan and many others prescribe what needs to be done. That makes it easy, but can also make it costly. It requires software, which is expensive and needs training. Most software is designed around a data model and the tables, it does not enable the user to do the work. It is easy once you know how it works, but that takes time. I have built LSARs by hand in Excel in half a day that took me 3 days with software, because I wanted to see the difference. The ASD Specs provide options and allow the traceability over time that the standards did not provide, to name a few aspects. Any part will have multiple identifiers: an OEM number, a supplier number, a system integrator number, the number in the CAD breakdown (with typo′s), an NSN, etc. Each number has a role at some point in the process and you need proper logistics configuration management throughout the design iterations to keep everything together. So to make the ASD Specs work, you have to take control and define what you want, then select the relevant parts of the specs and data model. The risk is focusing too much on what the Specs seem to dictate. You do not need training for the Specs, although some explanation on the data model may come in handy... Define your goals/deliverables/processes/milestones and then you take a look at the map and find the route through the data model. That bit does require training and sometimes consulting to get started. The Specs provide a structure for the data, but you have to transform the data into information to be able to use it. For a customer that means finding out what you require to be manage your assets and be in control: the information for your processes, the training for your staff, the KPI′s that you want to measure (the ILS part you talked about earlier). For a supplier that means to clarify what is contractually agreed, how your design and develop the support system that is best for the customer and for you. Particularly because you will be stuck with each other for the next 40 years. :)

回复

要查看或添加评论,请登录

Lee Fitzsimons的更多文章

社区洞察

其他会员也浏览了