We also use metadata to categorize each document by its editorial type: user guide, installation documentation, training support, functional description for example. ![]() This taxonomy allows, for each article, to identify the product and the context in which it is used. This proved to be a key factor for the success of the project.Īccording to which dimensions is the content organized?Īmong the metadata we use for organizing content, we can list: solution (among the 14 products we offer), functional component, and possibly a subset of this component. Many times we have tested, published, deleted, added a source, etc. This is how the taxonomy was enriched, modified, standardized. We would frequently review our progress so that the two subjects converge. We were able to set up procedures, for example create a taxonomy consistent and obvious to all users.Įverything was done in a very iterative way. And on the other hand, starting from the user experience: definition of metadata, taxonomies, synonyms, groups and permissions. On one hand the writing tools, including conversion of existing content, from Word to DITA. You really have to touch the benefits to be convinced.įrom an organizational point of view, we approached things “from both ends”. The logic of structured documentation is almost opposed to traditional writing logic. Now the integration is going well, despite a radical culture change. We very often kept the other team up- to-date on the progress, and from the beginning we were committed to training them 100%. And we deployed a new team dedicated to the structured documentation project which was able to take its marks without disrupting the existing processes. They were of course kept informed and involved. The team of 3 people continued to work with their tools and techniques. So we did not change everything, at least at the beginning. This plurality of audiences had no elegant solution in our existing documentation system, forcing us to create, duplicate and maintain different and redundant types of documents, without consistency, and without the possibility of switching from one audience to another.įirst, we had to preserve our “business as usual”: continue toĭeliver for our customers, maintain the existing content. The same subject can be treated from a marketing or pre-sales perspective, from a functional (user-driven) point of view, with screenshots and a manual, or from a technical point of view for engineers in charge of the implementation or maintenance of the system. Therefore, we can quickly end up with a dozen different versions of the same document, for the same software.Īnother key topic is audience. On the other hand, because each customer has specific needs, and these must of course be documented and kept up-to- date. On one hand because the product is evolving, and all customers do not have the same pace of upgrading their software. This forces us to maintain many different versions of the same documentation. One of the main problems that we have identified is that there are many variants out there for each of our products. I am responsible for quality, and the documentation has recently been integrated into my scope, with the aim of improving the user experience when searching for information and for the right document. What drove you to structured documentation? Thus, by connecting to Sharepoint sites, our customers could find both product documentation and specific project documentation – each implementation involves a significant amount of personalization related to the customer’s activity, locally applicable regulations, or interfaces with their own systems. Until recently, we would mainly produce Word documents, transformed into PDF and distributed via Sharepoint. Finally, the decision makers at our customers’, for whom HPS Pre-Sales and Marketing teams manage separately PowerPoint documents. Then, developers: hundreds of files describing the design of the software, the data model. First, the users of our 14 solutions: installation and configuration guides, technical notes, user manuals, interface and functional descriptions. In the past, the documentation team consisted of 3 people, managing a documentation corpus of several hundred documents. ![]() Historically, how was the production of documentation organized?
0 Comments
Leave a Reply. |