Archiv der Kategorie: Technische Dokumentation

Dokumentationspflichten von Unternehmen

Der Gesetzgeber fordert in nahezu allen organisatorischen Bereichen eines Unternehmens nicht nur ein strukturiertes Vorgehen sondern auch eine klare und nachvollziehbare Dokumentation:

  • Strukturen (Organisation von Material, Unterlagen/Ablage und Verantwortlichkeiten)
  • Verfahren (allgemeine Abläufe)
  • Vorgehensweisen (konkrete Aufgabenbeschreibung)

Hinzu kommt, das ursprüngliche Dokumente, also Vorgängerversionen, auch nach einer Änderung für bestimmte Zeit archiviert und jederzeit zugänglich sein müssen.

Beispiel
Verfahrensbeschreibungen gemäß GoBD, die bis zum 31. Januar 2011 gültig waren (also zum 1. Februar 2011 geändert wurden), müssen genauso lange aufbewahrt werden wie die Buchhaltungsunterlagen und deren Aufzeichnungen aus dem Jahr 2011, also 10 volle Kalenderjahre bis Ende 2022.

Unterschiedliche Gesetze oder Verordnungen, z.B. GoBD (auch noch (!) GoB), DS-GVO, TMG, BSIG (IT-Gesetz), BDSG und LDSG, fordern eine Dokumentation der Organisation, Prozesse und Aufgaben.
Auch wenn es meist unterschiedliche Unternehmensbereiche betrifft, so haben sie alle eines gemeinsam: Die digitale Datenhaltung und Datenverarbeitung (EDV).
D.h., mit einer detaillierten Beschreibung seiner IT-Landschaft (Hardware, Software, Schnittstellen, ausgelagerte Dienste wie “Cloud”) kann ein Unternehmen schon einen wichtigen Grundstein für die geforderten Dokumente legen.

Die Anbieter der Technik (Hardware oder Software) oder Dienste liefern meistens auch gleich mit ihren Handbüchern und Beschreibungen einen wichtigen und wiederverwendbaren Teil der Verfahrensdokumentation. Ebenfalls gute Quellen sind die eigenen Anforderungskataloge, die zum Kauf, zur Anpassung oder zum Einsatz von Technik (Hardware oder Software) oder Diensten geführt haben.

Allen gesetzlichen Anforderungen fordern die Beschreibung von Organisation, Verfahren und das konkrete Vorgehen, also “wie” eine Aufgabe durchgeführt wird. Alle Anforderung können in allen Unternehmensbereichen auf dieselbe strukturierte Herangehensweise erfüllt werden. Außerdem bietet diese Herangehensweise die Chance, die eigenen Prozesse zu hinterfragen und eventuell zu verbessern:

  1. Gesetzliche Anforderung analysieren
  2. Resultierende Aufgaben definieren und beschreiben
  3. Werkzeuge evaluieren*
  4. Reihenfolge festlegen
  5. Kontrolle und Überprüfung der Aufgabendurchführung
  6. Werkzeuge evaluieren*
  7. Kontrolle und Überprüfung der Ergebnisse, z.B Plausibilitätsprüfung
  8. Werkzeuge evaluieren*
  9. Nachvollziehbarkeit gewährleisten und Nachweispflicht erfüllen: Dokumentation der Durchführung
  10. Werkzeuge evaluieren*
  11. Basierend auf den definierten Prozessen und Vorgehensweisen: Werkzeuge festlegen*

[* ob Stift und Papier, Hard- und Software, Cloud-Dienste, oder externe Dienstleister]

Wenn eine Aufgabe bereits digital durchgeführt oder unmittelbar revisionssicher dokumentiert wird, z.B. durch ein Versionsmanagement-System, ein elektronisches Diagnosesystem oder ein Kassensystem, können die Daten dieser Werkzeuge direkt genutzt werden. Z.B. könnte eine Export-Funktion außer Patientendaten auch “Metadaten” liefern, die als Kontrolle der Durchführung von bestimmten Aufgaben dienen können. Diese Metadaten können so beschaffen sein, dass gleichzeitig der Datenschutz gewährleistet ist, also keine sensiblen Daten mit exportiert werden.

Da die meisten Prozesse mittlerweile digital unterstützt oder sogar vollständig in der EDV abgebildet werden, kommt es auch zu einigen Überschneidungen von Anforderungen aus unterschiedlichen Gesetzen oder Verordnungen. D.h., mit einer geschickten Aufteilung und Struktur der gesamten Unternehmensdokumentation können bereits bestehende Beschreibungen wieder verwendet werden, ohne sie ein weiteres Mal erfassen oder dokumentieren zu müssen.

Dies kann durch eine Aufteilung der Dokumentation für jedes Gesetz auf mehrere Schriftstücke (oder Dateien) auf Kapitelebene erfolgen. Zur Nachvollziehbarkeit werden Querverweise verwendet. Und damit die Querverweise auch nach jeder Änderung noch auf das richtige Ziel verweisen, sollte ausgereifte Software dafür verwendet werden: Für das Erfassen und Schreiben sowie für die Nachvollziehbarkeit.

Der Software-Markt bietet viele Lösungen zu unterschiedlichen Anforderungen und Preisen als kommerzielle Lösungen aber auch “freie Software” (korrekterweise “Open Source” Software = nicht komplett “frei” aber zu akzeptablen Bedingungen kostenlos nutzbar).

Gedanken zu einem leistungsfähigen und quelloffenen Redaktionssystem in der technischen Dokumentation

Anlässlich einer Diskussion meine Gedanken zu einem leistungsfähigen und quelloffenen Redaktionssystem in der technischen Dokumentation.

Aus welcher Motivation heraus entstehen “leistungsfähige” Open Source-Projekte? Und für welche Zielgruppe, welchen Markt werden derartige Software-Produkte geschaffen?
Damit meine ich die originäre Zielrichtung, und nicht, für welche Bereiche die Produkte auch “in etwa” geeignet wären. Denn “leistungsfähig” ist für mich ein Produkt, dessen Entwickler die Zielgruppe und deren Anforderungen sehr gut kennen und verstanden haben.

In der technischen Dokumentation gibt es sehr viele unterschiedliche Arten, die aus meiner Sicht Folgendes eint:

  • (Geforderte) Verständlichkeit (zunächst unabhängig vom diskutierten Werkzeug)
  • Standardisierung (abhängig vom Werkzeug)
  • Struktur (abhängig vom Werkzeug)
  • Wiederverwendbarkeit (abhängig vom Werkzeug)
  • Verschiedene Ausgabemedien/-formate (abhängig vom Werkzeug)

Eine landläufig als Content Management System bezeichnete Software, sei es Drupal, Typo 3, oder welche auch immer, ist primär mit dem Ziel HTML/Web-Ausgabe konzipiert. Diese Systeme sind erweiterbar, aber gibt es ernsthafte und brauchbare Ergebnisse für die technische Dokumentation?

Spätestens bei der Wiederverwendung wird es sehr schwer. Selbst viele spezialisierte Systeme schaffen lediglich einfache Konzepte umzusetzen.
Komplexe Produkte aber auch Prozessdokumentationen und auch nicht technische Texte, wie im Marketing, benötigen für einen ausgewogenen wirtschaftlichen Einsatz (Balance des Aufwandes zwischen Erstellung, Pflege und Weiterentwicklung von Inhalten) eine höhere Flexibilität von einer Dokumentationssoftware.

Konzepte, wie DITA, bieten einen strukturellen Ansatz, die die (technischen) Forderungen erfüllen. Auf einem solchen Konzept sollte ein leistungsfähiges und quelloffenes Redaktionssystem aufgebaut sein.

Ein existierendes System, das mit anderen Zielen konzipiert wurde, an diese Forderungen anzupassen, dürfte aufwendiger sein, als ein von Grund auf neues System zu konzipieren. Dabei soll nicht jeder Dialog neu programmiert werden. Nicht ohne Grund setzen Ixiasoft und Instinctools für ihre DITA-Lösungen auf Eclipse und DITA-OT. Leider scheitern auch solche Lösungen oft, da Produkte meist ohne ausreichende Kundennähe (weiter-)entwickelt werden. Damit könnte ich jetzt abschweifen und die agile Produktentwicklung (für Software) diskutieren.

Einen interessanten Ansatz hat einmal die quelloffene Software Daisy CMS verfolgt (Anonymous read-only SVN: http://dev.outerthought.org/svn_public/outerthought_daisy/).

Jetzt bietet Oxygen ein gutes (kommerzielles) Produkt, dass gut individuell in Eclipse mit quelloffener Software erweitert werden kann.

Einen weiteren Aspekt habe ich noch nicht erwähnt: Validität der Verarbeitungsprozesse einer Software. Die ist in den Branchen Automotive und Aviation und damit auch für der Zulieferindustrie verpflichtend.

S1000D Release 4.2 veröffentlicht

Issue 4.2 of S1000D, International specification for technical publications using a common source database, is now available for download. S1000D specifies the production of technical publications and is used for defense systems (air, land and sea), civil aviation and other products. The specification is jointly produced by the AeroSpace and Defence Industries Association of Europe (ASD), the Aerospace Industries Association of America (AIA) and the ATA e-Business Program.

Key highlights for Issue 4.2 include:
– Applicability
– Improvements on product attributes
– Alignment with Bike examples
– Data typing
– Guidance for display
– Business Rules
– Introduction of BrDoc. A new Schema for capturing business rules
– Improvements on readability
– Added unique references to id’s in the default BREX
– Referencing from BRDPs to the associated rule in the default BREX
– Severity levels
– Bike samples
– Alignment with display guidance
– Added support for BRDP
– Graphics
– Overhaul of guidance
– Metadata for ICN (new Schema)
– Enhancements to: CIR, Schedules, References
– General clean-up
Quelle: E-Mail

Download here: http://public.s1000d.org/Downloads/Pages/S1000DDownloads.aspx