A Support Engineer's Thoughts on Tech Pubs, S1000D and Where They Fit
S1000D is both the most mature and the most widely adopted of the S-Series of Specifications for Integrated Product Support (the S-Series). Perhaps, this is why, despite all of the graft and the work that goes on in the shadows, it’s so often the success of the technical publications that determines whether a support engineering programme is seen as successful or not.
OK, that’s not always true - nor is it fair - but it is true to say that, as the most obvious interface between the support engineers and the user community, technical publications are the face of the support engineering effort. If the technical publications are sub-standard, in the eyes of the user group, the support engineering is sub-standard.
What’s worse, is that those associated with the technical publications discipline seem to know it. Technical publications often dominate discussion regarding the world of support engineering, as though the rest of the support engineering disciplines don’t exist.
It’s not their fault.
It’s because they do something that most of the people in the other support engineering disciplines don’t do. They make a product - a tangible output - that goes directly from the technical publications team, into the hands of the user community.
The rest of the support engineering disciplines - those whose work is less tangible and not customer-facing - are hidden in the background, their efforts shrouded in obscurity and treated, all too often, with contempt and indifference; attitudes that can blight support engineering as a whole.
Despite being the obvious face of the support engineering world, technical publications are not the centre of it, in fact, in terms of the development of support engineering data, technical publications are the end of the line. The last step is a long and complex process.
That begs a question or two…
Are technical publications people support engineers at all or, are they manufacturers dressed in support engineer’s clothing?
‘Technical publications’ appears as an element in both the integrated logistics support and integrated product support concepts but, has the technical publications element been watered down? Has it been diluted to the point where it excludes many aspects of the process, to focus almost exclusively on the production of the manuals?
Where are the processes that marry the right format of technical publication, to the right task? Where are the techniques that justify the inclusion of content in the technical publications, or not? Where are the techniques that determine how information is displayed in the technical publications to best support the user in performing the task? Where are the standard processes for selecting tools and software solutions that are the right fit, for the right context?
The technical publications support engineering discipline should be more than simply producing maintenance and operation manuals.
What does any of this have to do with S1000D in particular?
There is an unhealthy tendency within the S-Series community to assume that the specifications define the disciplines that employ those specifications. S1000D, for example, is often treated as though it defines the technical publications discipline but, does it?
Or, even, should it?
If you follow the S1000D - International Specification for Technical Publications you will produce a tangible product (a technical publication) and in that, within the S-Series, S1000D is on its own.
If you follow another specification from the S-Series, you will produce, in the main, what is in effect a specification for some element of support which must then be procured.
Change is coming though…
You can see it in the smattering of training data modules that have been worked their way into S1000D. You can see that this specification is going to evolve so that it addresses far more than just technical publications.
There is now an opportunity to change the focus of S1000D. To stop thinking of it as the technical publication specification and to start thinking of it as the product support data reporting environment (or something less convoluted and more catchy).
A technical publication, after all, is just a published report.
The S1000D specification should evolve beyond the production of technical publications, to the production of training artefacts and maintenance plans, and arguably, to the production of the process reports that emerge from the product support analyses. Process reports like the results of a maintainability assessment, a maintenance task analysis, or a reliability-centred maintenance analysis or ‘cases’ like the reliability and maintainability case or the support case.
Earlier in this article, I suggested that technical publications are not the centre of the support engineering world and that is absolutely right but, that doesn’t mean that S1000D can’t move toward the centre of the support ’data’ world.
The production of user community deliverables, like technical publications, training artefacts or product support reports can move S1000D from its present focus on the end of the development process to a more integrated role.
S1000D could also take on a more central role during the in-service phase of the lifecycle. This process has already started with technical publication concepts like the process data module, which allows the user to record data at the point of relevance within a procedure.
If S1000D evolves (and I suggest that it should) to produce the technical publications, training artefacts and process reports and, if development then continues and allows the capture of a wide range of information from the user community, it will become a bridge - a two-way bridge - between the intangible world of support engineering and the tangible world of the user.
There is an argument to say that this isn’t so much about evolution as it is about integration. S1000D, in terms of the S-Series, is the elder statesman and has its own slightly different ownership to the rest of the suite and, because it was out on its own for quite some time, there are some concepts that the S1000D community had to develop, like standard numbering systems or applicability, for example, which don’t necessarily make sense as part of S1000D, now that we’re looking at it as part of the integrated suite. Those concepts have a far wider application - and should apply far earlier in the support analysis process - than the technical publication process and perhaps they should belong in a specification with a more central role, like S3000L.
Whether this is a process of evolution or integration, it doesn’t really matter, the S1000D specification should be reclaimed by the wider support engineering community. Not to put technical publications at the heart of support engineering but to provide the support engineer with a specification for interfacing with the user.
Lead Expert at Sopra Steria
3 年I am not sure I fully agree. S1000D has a couple of issues that are usually not that helpful in a program. One of the issues is that it has a common source database in the title. A database usually implies a granular set of data elements, that can be addressed individually. S1000D states that the smallest level is the XML file, a data module. A data module can be a paragraph, but is usually a complete "job card". This means that it is impossible to see the contents of the data module from the outside. I have taken a few complete documentation sets apart and listed the contents of the fields. It shows typos, different spelling of part numbers, different names and anything else you can think of. Following the ASD flowchart, there should not be any part in the documentation that is not listed in the LSA (S3000L). The ASD specs specify the data exchange files between two or more parties, not everything that is needed for a database, so S3000L is not a database, but is the export from a database (technically it can be anything, including a database). IF S1000D were fed directly from the database, it would be impossible to have these typos. This disconnect originates in times before I was born, but also the status of S1000D in the S-Series. S1000D is a joint spec between ASD, AIA and ATA and is not fully governed by the IPS council and the Data Model and Exchange Working Group, where the specs are harmonized. The IPS Council is ASD/AIA only. This means that S1000D does not have a UML model and 'occasionally' aligns with the CDM. The breakdown structures in all specs are the same and allow the user to build nearly whatever they want. S1000D is limited to the SNS with limited depth and prescribed structure. S1000D uses a lot of codes that were once project specific, are not used anymore and have not been removed. The spec itself has 3.500 pages, which is too much. The training modules landed in S1000D because S6000T was on the design table but made no progress. The need still existed, so this was a shortcut. S6000T has been developed in a very short time by dedicated effort of two companies and stand on its own. S1000D is used for publications, as far as needed, but does not control the content. This is similar to S2000M. S2000M specifies the contents of the Illustrated Parts Catalogue (IPC), S1000D is used for the representation. I do not think that S1000D (at least in its current form) should be used for reports. Firstly S1000D does not control the content, so it is unnecessary complex. This process is too costly, takes too much time, is too prescriptive in content and structure, requires (expensive!) authoring (and viewing) software and there are existing established solutions that already offer this solution. S1000D should absolutely evolve, but not into the realm of the other specs. It should focus on the core reason for its existence: make technical information available in a controlled manner, but easy, fast, flexible and at low costs. It should not require a set of experts to create a manual. The only expert should be the technical author. Just my 2 cents! Happy to discuss :)
Independent Consultant at Sunite Limited
3 年I wholeheartedly agree, Lee. You describe the world we should be in in order to save money in both the design of support solutions and the delivery of that support. Sadly, the real world we inhabit is a lot different; .. the design of the tech pubs is often decided arbitrarily in the SOR before the physical solution is finalised or the support solution thought of. The customer decides what the documentation solution physically looks like before the support designer has decided what is needed. .. TNA follows and may specify different training resources resulting in a second set of technical information. .. Project managers thirst for information to provide evidence that the supplier is doing what was asked of them. Creating multiple additional reports and documents with much the same data. The same data is repeated many times in different formats at different times in the project lifecycle, for different users; building in configuration management issues that will last the life of the equipment. Our projects have shifted from managing data (which can be interrogated and reported when needed) to managing stovepiped documents which fix a view of the system that is often out of date as soon as it is issued). We have forgotten the old CALS mantra - create data once, use it many times. I wonder how many people remember the CALS (Computer Aided Logistic Support) initiative that gave birth to ILS. Lee has just described CALS.