Von A nach B – 6 Tipps zur Contentmigration

Pelikane im Flug

Nur selten ist Migration so einfach wie bei Zugvögeln…

Wenn es um die Bestandsdatenübernahme geht, kann man beim Wechsel des CMS einige böse Überraschungen erleben. Denn bei der Übernahme von Altdaten steckt der Teufel im Detail. Deshalb wollen wir heute einmal ein paar Tipps zu den Details geben, auf die Sie in Ihrem Contentmigrations-Projekt achten sollten.

Zeichenkodierung beachten

Welche Zeichenkodierung haben eigentlich die Ausgangsdaten: ISO-8859-1, Windows-1252, Unicode oder etwas noch Exotischeres? Und welche Zeichenkodierung erlaubt bzw. verlangt das Zielsystem. Gibt es im Ausgangstext ein durchgehendes Escaping (Kodierung von Sonderzeichen durch Zeichenfolgen, z. B. „äußerst“ wird zu „äußerst“) und wie lässt sich dieses in das Zielsystem transformieren? Wer hier die Daten vorab genau analysiert, kann eine Menge Probleme im Migrationsprozess vermeiden.

Inkompatible Layout- und Textkonstrukte

Sind die Textkonstrukte zwischen Ausgangs- und Zielsystem kompatibel zueinander.  Komplexe semantische Handlungsanweisungen, tief geschachtelte Listen oder Zeichenformatkombinationen sind typische Problemstellen. Manches System lässt schon die Kombination aus Fett- und Kursivmarkierung (<b><i>Si meliora…</i></b>) aus der Kurve fliegen.

Makros machen Ärger

Gelegentlich werden auch statische Dokumente teilweise dynamisch gestaltet (z. B. durch eingebundene Excel-Berechnungen) oder nachträglich verändert (z. B. durch Word-Makros). Im eigentlichen Bestandscontent sind solche Mechanismen oft nicht leicht zu erkennen und manchmal sind sie den Benutzern nicht einmal bewusst. Hier ist also Recherche angesagt und ein Vergleich zwischen dem Bestandscontent und den ausgelieferten Dokumenten. Hat man solche Mechanismen entdeckt, gilt es zu entscheiden, ob sich auf sie verzichten lässt, ob sie im Zielsystem nachimplementiert werden können oder ob sie durch geeignete Mechanismen des Zielsystems ersetzt werden müssen.

Grafikformate

Auch bei Grafiken gibt es Formatprobleme – und nicht nur wenn es um print oder online als Ausgabemedien geht. Immer wieder kommen bestimmte Zielsysteme nicht mit den Formaten des Ausgangssystems zurecht. Word kann zum Beispiel nicht mit SVG umgehen. Umgekehrt stellen Word-Zeichnungen für fast alle anderen Systeme ein Problem dar. Also: Auch hier genau prüfen, was möglich ist und im Problemfall zum Beispiel ein Kompromissformat finden, mit dem beide Systeme zurechtkommen.

Beschriftungen

Neben den eigentlichen Grafikformaten sollten Sie sich auch die Art der Beschriftung in den Grafiken ansehen. Hier sind ganz unterschiedliche Varianten üblich: fest im Bild integriert (eher selten), als gruppierte Objekte (häufig und schwierig zu migrieren), mit einer eigenständigen, unabhängigen Legende (aufpassen, damit die Zusammenhänge nicht verloren gehen) u. v. m. Bedenken Sie auch die Optionen, die das Zielsystem bietet. Vielleicht ist ja z. B. eine Clickmap die bessere Lösung für die Beschriftung. Denn wenn man schon den Aufwand für die Migration betreibt, dann sollte der Content im Zielsystem auch besser sein als zuvor.

Ein Raum für Informationen

Uwe Reißenweber (c) DOCUFY

Im ersten Teil unserer Reihe zu Trends in der Technischen Dokumentation begrüßen wir Uwe Reißenweber. Er ist Geschäftsführer der DOCUFY GmbH und gilt als Experte für die Implementierung, Einführung und Weiterentwicklung von Technischen Redaktionssystemen. 2016 begründete er die Strategie der Multi-Level-Dokumentation und ebnet so den Weg für die Zukunft der Technischen Dokumentation in einer digitalen Welt.

Aktuelle Trends wie Digitalisierung, Industrie 4.0, Mobile Computing, Social Selling Big Data und Co. beeinflussen die Produkte von morgen und prägen letztlich die zukünftige Entwicklung unserer gesamten Gesellschaft.

Die Technische Dokumentation bleibt davon natürlich nicht verschont. Im Gegenteil, Informationen entwickeln sich immer mehr zum Schmierstoff unserer digitalen Welt und wer könnte diese besser liefern als die Technische Dokumentation? Für sie besteht also die einmalige Chance, das traditionelle Mauerblümchendasein zu verlassen und zu einem der Big Player im Unternehmensgefüge aufzusteigen.

Die Dokumentation von morgen

Damit dies möglich wird, muss sich die Technische Dokumentation ganz neu erfinden: Der Informationsnutzer von morgen wird erwarten, dass ihm die richtige Information im Kontext seiner aktuellen Nutzung durch intelligente Informationssysteme quasi automatisch wie auf dem Silbertablett serviert wird. Selbstverständlich müssen die Informationen dabei mehrdimensional miteinander verknüpft sein. So möchte man in einem Produktkonfigurator von der Nutzerbeschreibung einer bestimmten Produktoption mal schnell in die zugehörige Bedienungsinformation wechseln, den Entsorgungshinweis einsehen oder sinnvolles Zubehör sichten, bevor es dann an die tatsächliche Kaufentscheidung geht. Im Servicefall soll am besten zeitgleich mit dem Serviceauftrag, die notwendige Dokumentation der anstehenden Serviceprozeduren mitgeliefert werden, idealerweise in der richtigen Reihenfolge. Und natürlich wären Tipps und Tricks der Kollegen sehr praktisch, wenn diese sich bereits zu einer bestimmten Tätigkeit oder Fragestellung geäußert haben. Notfalls wäre man sicher auch selbst bereit, eigene Tipps und Kommentare hinzuzufügen – zum Beispiel, wenn es eine besonders gute Lösung für ein Problem gibt.

Im privaten Alltag sind all diese genannten Dinge mit facebook, Google, Amazon und Co. schon gelebte Realität. Nur im professionellen Arbeitsumfeld ist das vorherrschende Informationssystem heute leider noch oft die PDF-Datei.

Das Dokument hat ausgedient

Um aber den zukünftigen Dokumentationsanforderungen gerecht zu werden, ist eine Abkehr von unserem liebgewonnenen Dokument unausweichlich. Einerseits fordern die Informationsnutzer den direkten Zugriff auf passende und korrekte Einzelinformationen. Andererseits wird der dokumentorientierte Redaktionsprozess zunehmend mühsamer, da die zu dokumentierenden Produkte immer varianten- und umfangreicher werden. So führt die Strategie des Maximaldokuments, das alle Varianten und Optionen einer ganzen Produktreihe umfasst, immer öfter ins unbeherrschbare Chaos. In Zeiten, in denen konkrete Produkte sich immer mehr auflösen und zu einer Funktionswolke mutieren, aus der jeder Nutzer sein persönliches Produkt individuell zusammenstellen kann, ist ein dokumentorientierter Redaktionsprozess gänzlich undenkbar. Warum? Mit dem Verschwinden konkreter Produkte entfällt eben auch die Grundlage für einen dokumentorientierten Redaktionsprozess.

Der Informationsraum

Arbeiten im Informationsraum (Symbolbild) (c) DOCUFY

Aber wie sieht die Lösung der zukünftigen Dokumentationsanforderungen aus? Wer übernimmt die Strukturierung, Bündelung und Zuordnung der Information, wenn es kein Dokument mehr gibt? Aus konzeptioneller Sicht ist die Antwort ganz einfach. Wir brauchen einen Informationsraum. Doch wie muss man sich so einen Informationsraum vorstellen? Welche Aufgaben übernimmt er und welche Funktionen hat er?

Der Informationsraum liefert eindeutige Adressen für alle relevanten Informationen eines Geschäftes. Die Einsatzmöglichkeiten gehen dabei weit über die klassische Technische Dokumentation hinaus. Vielmehr können dort Informationen zum gesamten Produktlebenszyklus, von der Entwicklung über Marketing und Vertrieb, Installation, Betrieb, Wartung und schließlich Entsorgung verankert werden. Dabei ist der Informationsraum nicht als eigenständiges Softwaresystem zu verstehen, sondern vielmehr als Konzept, das die eindeutige Adressierung oder besser Klassifizierung von Einzelinformationen ermöglicht.

Auf Basis dieses Informationsraums kann dann zukünftig der Informationsbedarf geplant, die redaktionelle Erstellung gesteuert und die zielgerichtete Nutzung der Information in den verschiedensten Informationssystemen ermöglicht werden.

Zugegeben, das hört sich ziemlich abenteuerlich an und wird die gewohnte Arbeitsweise der traditionellen Technischen Redaktion auf den Kopf stellen. Und es klingt nach viel Arbeit, so einen Informationsraum initial zu erstellen und dauerhaft zu pflegen. Aber um auch zukünftig erfolgreich sein zu können, ist es für Unternehmen unerlässlich, alle geschäftsrelevanten Informationen zu konsolidieren und für verschiedenste Zwecke verfügbar zu machen. Und dies ist die ureigenste Qualifikation und Aufgabe der Technischen Dokumentation.

Ich wünsche Ihnen viel Spaß beim Aufbau Ihres Informationsraums. Und keiner hat behauptet, der Weg zum Big Player wäre leicht… 🙂

Für mehr Information:
www.multi-level-dokumentation.de
www.docufy.de

 

Technischer Content – auf dem Weg in die Zukunft

Achtung CatContent: Was die Zukunft wohl bringt?

Vor einigen Jahren noch hatte ich das Gefühl, dass sich in der Technischen Dokumentation Innovationsstillstand breit macht. Dieser Eindruck hat sich Gott sei Dank in den letzten Jahren geändert. Heute erleben wir eine Branche, die sich (wieder) neu erfindet. Einige Stichworte: mobile Dokumentation, internationale Teams und Redaktionsprozesse, Digitalisierung, Industrie 4.0 und neue Techniken wie VR-Interfaces, 3D-Druck.

Aufgefallen ist mir aber auch eine größere Offenheit gegenüber den Veränderungen. Nachdem sich Technische Redakteure über lange Jahre von den Kollegen aus den Marketing-Abteilungen abgegrenzt haben, sehe ich heute wieder eine größere Offenheit und Bereitschaft von den „anderen“ zu lernen, ohne dabei die eigenen Kernthemen und -standpunkte aufzugeben. Das mag mit einer jungen, gut ausgebildeten Schar von Technikredakteuren zu tun haben, die sich oft als Medienspezialisten und nicht als schreibende Ingenieure verstehen. Begrüßenswert ist es allemal.

Wie wird es nun weitergehen mit der Technischen Dokumentation? Wir haben dazu Hersteller von Software-Systemen aus der Dokumentationsbranche gefragt: „Was sind in den nächsten fünf bis zehn Jahren die großen Trends in der Technischen Dokumentation? Wie wird sich das Arbeiten verändern? Wird es Dokumentation im heutigen Sinn überhaupt noch geben?“ Und spannende Antworten bekommen. Die Beiträge zu dieser Reihe „Trends in der Technischen Dokumentation“ werden in loser Folge erscheinen. Den Anfang macht an diesem Donnerstag Uwe Reißenweber von DOCUFY mit einem Post über „Informationsräume“.

Posts zu dieser Themenreihe

API-Dokumentation – Was brauchen und wollen Entwickler?

Code ist undokumentiert schwer zugänglich
(c) Markus Vogelbacher via pixelio.de

Heute freuen wir uns, wieder einmal eine Gastautorin im doctima-Blog zu begrüßen. Stephanie Steinhardt ist Dipl. Technik-Redakteur (FH) und wissenschaftliche Mitarbeiterin an der Hochschule Merseburg. Als freiberufliche Technik-Redakteurin betreut sie außerdem verschiedene Kunden z. B. aus dem Automobilbereich. In ihrem Post zeigt Sie uns erste Ergebnisse aus einer gemeinsamen Forschungsarbeit mit Prof. Dr. Michael Meng und Andreas Schubert (MA) an der HS Merseburg. Doctima ist an diesem Projekt als Vernetzungspartner beteiligt.

Die Sicht von Entwicklern auf API- Dokumentation ist oftmals sehr verschieden. Während die einen davon überzeugt sind, dass guter Code keiner Dokumentation bedarf, schreiben die anderen selbst gern Dokumentation und konsultieren sie auch häufig. Die Meinungen darüber, wie sie denn aussehen soll, die perfekte API-Dokumentation, gehen ebenfalls auseinander. Es existieren unterschiedliche Ansätze zu Aussehen, Darreichung und Inhalt einer solchen.

An der Hochschule Merseburg widmet sich seit zwei Jahren ein kleines Team von Technik-Redakteuren in einem Forschungsprojekt der Optimierung von API-Dokumentation. Die Fragen nach Struktur und Inhalt der perfekten API-Dokumentation sowie nach dem Leseverhalten der Entwickler stehen dabei im Mittelpunkt der Untersuchungen. Auf Basis von 23 durchgeführten Interviews, der Erhebung von Daten aus rund 100 Fragebögen und einer Beobachtungsreihe, bei der genau verfolgt wurde, wie Entwickler Programmieraufgaben lösen, sowie unter Berücksichtigung der bereits existierenden Studien im Umfeld von Entwicklerdokumentation können wir Empfehlungen geben, die API-Dokumentationen deutlich besser und effizienter nutzbar machen.

Nicht jeder Entwickler ist wie der andere.

Entwickler unterscheiden sich nicht nur in ihrer Einstellung zur Dokumentation, in den Jahren ihrer Programmiererfahrung oder bezüglich der Systemwelt, in welcher sie zu Hause sind. Sie unterscheiden sich vor allem in ihrer Arbeitsweise. So konnten wir in unseren erhobenen Daten zwei verschiedene Ansätze identifizieren, welche vor allem bei der Einarbeitung in eine neue API deutlich hervortreten. So gibt es Entwickler, die einen eher codegetriebenen Ansatz verfolgen und nach eigener Aussage gern direkt mit einem Code-Beispiel einsteigen. Sie erarbeiten sich den Umfang einer API eher intuitiv von unten nach oben. Es gibt aber auch Entwickler, die konzeptorientiert arbeiten und sich vor der Nutzung einer neuen API zunächst einen Überblick verschaffen. Entwickler, die der Meinung sind, dass es nützlich ist, das Konzept der API in Gänze zu verstehen, auch wenn nur ein Teil der API tatsächlich zur Problemlösung genutzt wird.

Abb.: 1 – Absolute Zeitwerte: Recherchezeit (farbig) vs. Bearbeitungszeit (grau) der Probanden 01-11

Besonders deutlich traten diese Verhaltensmuster in der von uns durchgeführten Beobachtungsreihe hervor. So haben 6 der 11 beobachteten Probanden im Konzeptbereich der API-Dokumentation unserer Test-API gelesen, wohingegen die anderen 5 kaum einen Blick hinein warfen und vorrangig auf Beispielcode fixiert waren.

Lesen ist nicht gleich lesen.

Trotz der gegensätzlichen Sichtweisen der Entwickler auf API-Dokumentation hat die Beobachtung gezeigt, dass im Beobachtungszeitraum von jeweils einer Stunde alle Probanden nahezu die Hälfte der Zeit mit der Recherche in der API-Dokumentation zubrachten, während die andere Hälfte für die tatsächliche Programmierung zur Lösung der Aufgaben verwendet wurde.

Wie die Analyse der entstandenen Eyetracking-Aufnahmen zeigte, scannten und überflogen die Entwickler die einzelnen Inhalte mehr, als dass sie tatsächlich Zeile für Zeile lasen. Dabei fokussierten Sie vorrangig auf die visuell hervorgehobenen Elemente, wie Hyperlinks, die Navigation und Beispielcode. Der erklärende Fließtext wurde meist nur dann gelesen, wenn aus dem Beispielcode allein keine Lösung abzuleiten war.

Das Leseverhalten schien darüber hinaus nicht nur beeinflusst von der individuellen Arbeitsweise, sondern war auch geprägt von der Einschätzung zum Schwierigkeitsgrad der gestellten Aufgabe. Bei Aufgaben, die schwieriger zu lösen schienen, waren die Probanden eher geneigt zu lesen, als bei Aufgaben, die einfacher wirkten.

Wer die Prozesse kennt, ist klar im Vorteil.

Bereits in den Interviews und in existierenden Studien kam zum Vorschein, dass mitunter alleinige Programmiererfahrung kein Garant ist für die schnelle Einarbeitung in eine neue API. Vielmehr entscheidend ist das vorhandene Domainwissen. Wer mit den zugrunde liegenden Prozessen vertraut ist, welche die API abbildet und dazu das Fachvokabular kennt, ist deutlich schneller bei der Einarbeitung und Lösung von Programmieraufgaben. Das zeigte auch unsere Beobachtungsreihe sehr eindrücklich (vgl. Abbildung 1 – Probanden 03, 04, 05,06 und 10 besaßen Domainwissen).

Demnach kommt der Vermittlung von Domainwissen in einer API-Dokumentation eine wichtige Rolle zu. Die Platzierung dieser Informationen ist mit Hinblick auf Leseverhalten und Arbeitsweise der Entwickler elementar.

Abb.: 2 – Beispiellayout für Codekommentare im Beispielcode (adaptierter Inhalt, basierend auf https://developers.shipcloud.io/reference/)

Der beste Ort für wichtige Informationen in einer API-Dokumentation ist einer, den alle Entwickler tatsächlich anschauen. Auf Basis der Interviews, den Fragebögen und der Beobachtung können nur Codebeispiele dieser Anforderung genügen. Sie werden von allen Entwicklern angesehen und als Basis der eigenen Programmierung verwendet. „Verkleidet“ man wichtige Informationen als Codekommentar und setzt diese deutlich vom restlichen Codebeispiel ab, kann man sicher sein, dass sie gesehen und, wenn kurz, auch gelesen werden. Auf ausführlichere Beschreibungen sollte zugunsten der eher konzeptorientierten Entwickler aber dennoch nicht verzichtet werden.

Dieser konkrete Optimierungsvorschlag und die zuvor genannten Erkenntnisse sind natürlich nur ein kleiner Teil der bisher gewonnenen Forschungsergebnisse. Unsere Untersuchungen dauern im Moment noch an. Daher sind wir auch sehr interessiert an Unternehmen, die bereit sind, sich an ähnlichen Studien zu beteiligen und damit die Zahl der möglichen Probanden vergrößern.

Kontakt: stephanie.steinhardt@hs-merseburg.de

Verständlichkeit – wissenschaftlich und praktisch

„verständlich kommunizieren“ an der Hochschule Luzern

Verständlichkeit ist bei uns ja eines der Kernthemen. Dass sich dazu auf wissenschaftlicher Seite leider weniger tut, als wir uns wünschen, habe ich im doctima Blog schon beklagt. Umso mehr hat mich gefreut, dass mich Sascha Demarmels vor kurzem auf ihr Blog an der Hochschule Luzern aufmerksam gemacht hat. Unter dem Titel verständlich kommunizieren bloggt ihre Arbeitsgruppe zu verschiedenen Themen rund um die Verständlichkeit – aus wissenschaftlicher Sicht wie auch in der praktischen Anwendung.

Leider sind die meisten Posts schon ein wenig älter. Das nimmt den Beiträgen zwar nicht ihren Wert (Verständlichkeit ist ja kein Hype-Thema, das man tagesaktuell verfolgen muss). Aber es wäre wirklich schade, wenn das bedeutet, dass das Blog nun still und leise einschläft. Deshalb meine ich diesen Post nicht nur als Leseempfehlung, sondern auch als Ermutigung an die Bloggenden von der HS Luzern: „Wir wollen gerne mehr davon sehen!“

 

Weihnachten, gecheckt! Unser Gutzi 2016

Geht es Ihnen auch so? Ist die ach so besinnliche Adventszeit mit beruflichen und privaten Terminen bis zum Platzen gefüllt? Und wünschen Sie sich auch, dass nächstes Jahr alles besser wird?

Dann haben wir dieses Jahr genau das Richtige für Sie. Denn immer, wenn wir in Stress kommen, dann sorgen wir mit Checklisten für Überblick. Johannes Dreikorn hat das auf der tekom Herbsttagung dieses Jahr anschaulich vorgestellt. Klar, dass wir mit Checklisten auch für mehr Freiraum im nächsten Jahr sorgen wollen.

Und deshalb haben wir Ihnen vier Checklisten gestaltet, damit beruflich und privat alles geschmeidig läuft:

  • eine Checkliste für das Berufliche, mit der Sie die Content-Qualität Ihrer Dokumentation schnell abprüfen können,
  • eine Checkliste für das Team, um die Kaffeemaschine fit zu halten,
  • eine Checkliste für das ganze Jahr, mit der Sie Ihre Einkäufe leichter organisieren und
  • eine Checkliste für Weihnachten 2017, damit die „staade Zeit“ dieses Mal auch wirklich besinnlich wird.

Mit unserem Weihnachts-Gutzi wünschen wir allen unseren Lesern und Leserinnen besinnliche Feiertage und einen guten Start für 2017.

Migration – eine neue Heimat für den Content

Edgar Hellfritsch

Edgar Hellfritsch

Daten und Content: Ein Schatz, den wir im Lauf der Jahre mühsam aufgebaut haben. Und der zum Problem wird, wenn wir uns zum Beispiel entscheiden von der altgedienten Textverarbeitung (z. B. Word oder FrameMaker) auf ein Content-Management-System umzusteigen. Seltene Aufgabe, die aber doch immer wieder zu erledigen ist, wenn ein Systemumstieg ansteht. Wir haben mit Edgar Hellfritsch geredet. Er beschäftigt sich seit über zwanzig Jahren mit der Frage, wie man Daten und Content am besten migriert und hat über hundert Migrationsprojekte geleitet. In diesem Interview schildert er uns seine Erfahrungen.

doctima: Edgar, wie sieht denn das typische Migrationsprojekt aus?

Jedes Projekt ist irgendwie natürlich wieder anders. Aber grundsätzlich kann man sagen: Ein typisches Migrationsprojekt hat etwa 10.000 Seiten DIN A4, die in etwa 30 Sprachen vorliegen. Migriert wird meistens von einem layout-orientierten Textverarbeitungssystem in ein strukturiertes Format, also ein CMS oder xml-basierte Standards wie DITA. Letzten Endes kommt aber alles vor. Wir hatten auch schon Fälle wo wir DITA nach DITA migriert haben, weil zwei Unternehmensteile sich für einen gemeinsamen Standard entschieden haben.

doctima: Und wie geht man dabei vor?

Grundsätzlich muss man sich entscheiden, ob der Content schrittweise nach und nach migriert werden soll oder zu einem Stichtag in einer großen Hauruck-Aktion. Welches Vorgehen da sinnvoll ist, lässt sich nicht pauschal sagen. Das hängt von der Gesamtdatenmenge, vom Vernetzungsgrad des Contents, von den Redaktions- und Freigabeprozessen und natürlich von der Terminplanung für den Produktionsstart im neuen System ab.

Nach und nach zu migrieren erscheint auf den ersten Blick oft erst einmal wünschenswerter. Altdaten können fallweise auch einmal unmigriert bleiben, der Aufwand ist überschaubarer und die ersten Erfolgserlebnisse sind schnell vorhanden. Aber: Nach und nach zu migrieren bedeutet einen deutlichen Mehraufwand, denn beide Systeme müssen über einen längeren Zeitraum weiterbetreut werden. Und wenn die Redaktion diesen Mehraufwand personell nicht leisten kann, kommt es im schlimmsten Fall dazu, dass die (produktive) Systemeinführung sich so lange verzögert, bis sie komplett scheitert.

Und dann gibt es noch eine Fülle weitere Entscheidungen: intern oder extern, automatisiert oder manuell und, und, und. Jede dieser Entscheidungen hat ihr eigenes Für und Wider. Aber ich glaube das würde jetzt zu weit führen, wenn ich da im Detail darauf eingehe.

doctima: Übernimmt so eine Migration der Systemhersteller?

In den seltensten Fällen. Denn Migration bedeutet eine ganz eigene Art von Expertise, bei der man Ausgangsformat und Endformat genau im Blick haben muss. Auf dem Weg gibt es dabei einige Tücken, die für Systemhersteller schwer zu kalkulieren sind. Im Normalfall ist es hier besser, sich einen Dienstleister ins Boot zu holen, der auf Migrationsprojekte spezialisiert ist.

doctima: Welche Formate sind denn besonders schwer zu migrieren?

Wahrscheinlich erwarten jetzt viele als Antwort: Word! Das ist aber gar nicht so. Denn das Problem liegt nicht so sehr im Format selbst, sondern eher darin, wie strukturiert die Redakteure gearbeitet haben und wie konsequent sie ihre Standards eingehalten haben. Da sind mir Word-Dokumente, bei denen sauber mit Formatvorlagen gearbeitet wurde, tausendmal lieber als Dokumente, bei denen die Redakteure versucht haben, mit XML zu layouten.

Umgekehrt kann eine scheinbar einfache Anforderung, wie DITA nach DITA zu migrieren, sich im Projektverlauf als extrem heikel erweisen, wenn z. B. Metadaten zur Steuerung des Publikationsprozesses verwendet wurden oder eben semantische Strukturen missbraucht wurden, um ein bestimmtes Erscheinungsbild zu erzeugen. Da werden dann Informationssequenzen als Bildbeschriftung getaggt, weil man das Ganze gerne in einer Box darstellen will. Für die Migration ist so etwas ein Desaster.

doctima: Ein Erfolgserlebnis?

Für unsere Kunden ist der größte Erfolg wohl immer, wenn sie sehen, wie schnell ein Großteil des Contents migriert ist. Als derjenige, der sich um die Umsetzung kümmert, sind die ERfolge für mich aber oft eher die Kleinigkeiten am Rande. Vor einiger Zeit ist es mir z. B. in einem Projekt gelungen, komplexe Tabellen automatisiert von CALS nach HTML und wieder zurück umzuwandeln. Der Weg von CALS nach HTML ist mehr oder weniger trivial. Der Weg zurück ist aber ziemlich trickreich, weil das CALS-Tabellenmodell – na sagen wir mal – „originell“ ist. Da muss man sich letzten Endes jede Tabellenzelle einzeln angesehen haben, bevor man die Tabelle zusammenbauen kann. Für den Laien ist das dann nicht weiter spektakulär, wenn am Ende alles klappt. Aber als Spezialist ist man da schon ein wenig stolz.

doctima: Zum Abschluss: Was würdest du jemandem für die Migration raten,  bevor er einen Systemumstieg plant?

Sich neben dem Dokumentbestand auch den Redaktionsprozess vorher genau anzusehen und sich im Zweifelsfall Hilfe von außen zu suchen.  Ohne Bestandsanalyse kann man sonst manche böse Überraschung erleben, weil zum Beispiel im Publikationsprozess Makros nachträglich noch den Content verändern. Generell ist es sinnvoll sich anzusehen, welche Strukturen im Content vorhanden sind und welche davon erhalten bleiben müssen. Wir haben dazu automatisierte Verfahren mit denen wir Bestands-Content analysieren. Da stellt sich dann eigentlich meistens heraus, dass es eine ganze Reihe von Dokumentstrukturen gibt, die bei 10.000 Seiten vielleicht nur drei oder vier Mal vorkommen. Und da sollte man sich dann schon fragen, ob es sich lohnt, das auch im Zielsystem abzubilden.

doctima: Danke für das spannende Interview.

Gerne.

 

Information 4.0 – Schritte auf dem Weg zur Intelligenten Information

Industrielle Steuerung?Die Digitalisierung der Arbeitswelt ist derzeit eines der meist diskutierten Themen. Auch unserer Branche, der Technischen Dokumentation, stehen tief greifende Veränderungen bevor.
Seit Anfang 2016 bin ich Mitglied der tekom-AG „Information 4.0“ und gestalte dadurch diese Veränderungen mit. In der AG arbeiten wir iiRDS aus, einen Standard zur Bereitstellung von intelligenter Information in digitalisierten, vernetzten Umgebungen. Mit diesem Beitrag fasse ich einige meiner Gedanken zum Thema Industrie 4.0 und intelligente Information zusammen.

Einige Begriffe

  • Industrie 4.0, digitale Fabrik: Sich selbst steuernde, weitestgehend automatisierte Fertigungsprozesse, die der Mensch nur noch „orchestriert“ und bei Bedarf eingreift.
  • Cyberphysikalisches System: Komponente, die aus einem dinglichen Objekt und aus einer digitalen, vernetzten Repräsentation besteht.
  • RAMI 4.0: dreidimensionales Referenzarchitekturmodell der Plattform Industrie 4.0. Strukturiert das Thema nach Lebenszklus von Entwurf bis Entsorgung, Hierarchie von Einzelkomponente bis zur umgebenden Cloud und nach Integrationslevel von Objekt („Asset“) bis Geschäftsmodell („Business“).
  • Verwaltungsschale: Digitale Repräsentation eines cyberphysikalischen Systems. Enthält beschreibende und identifizierende Eigenschaften, Sensordaten und Zugriffsmöglichkeiten zu digitalen Funktionen.

Technische Dokumentation heute

Für die meisten Akteure im Umfeld Industrie 4.0 findet Technische Dokumentation auf dem sog. „Asset Level“ in der digitalen Fabrik statt. Sie gehen gedanklich vom aktuellen Status Quo (oder eigentlich von dem Stand vor zehn Jahren) aus, und der heißt PDF. Dokumente für Installation, Wartung, Betrieb und ggf. Entsorgung werden als Einheiten betrachtet und als abrufbare Eigenschaften in der Verwaltungsschale eingeplant.

Auf diese Granularität zielt wohl auch die in Arbeit befindliche VDI-Richtlinie 2770 zur digitalen Herstellerinformation ab. Für einige Branchen (gerade ältere Industrieanlagen sind in der Regel auf Papier dokumentiert) ist das auch sicher ein Fortschritt. Aber natürlich geht viel mehr.

Intelligente Information

Technische Dokumentation lässt sich viel präziser modularisieren. In vielen Redaktionen wird das bereits heute betrieben, v. a. als Basis des Variantenmanagements: Die Filterung nach Zielgruppen, Sprachen, Gerätevarianten findet heute bereits statt und zwar beim Publizieren von Dokumentvarianten.

In einer Industrie-4.0-Umgebung lässt sich diese Filterung zum Lesezeitpunkt hin verlagern. Damit werden gezielte Abfragen möglich, die dem Anwender die von ihm benötigte Information passend zu seiner aktuellen Aufgabe bereitstellen.

Dazu werden Metadaten benötigt, die die einzelnen Informationsmodule klassifizieren und identifizieren. Zuordnung zu Hersteller, Gerät, Variante, Komponente und Funktionsgruppe sind ebenso entscheidend wie Sprache, Zielgruppe und Informationstyp. Außerdem erfordert die Integration ein Auslieferungsformat, das sich embedded, mobil und am Schreibtisch sauber anzeigen lässt. Standardisierung ist nötig, damit sich die Dokumentation unterschiedlicher Hersteller zu einer Gesamtinformation integrieren lässt.

Bei der tekom arbeiten wir an einem solchen Standard, dem iiRDS. Die Arbeitsgruppe hat ihre Zwischenergebnisse auf der tekom-Jahrestagung vorgestellt. Der Standard soll Mitte nächsten Jahres verfügbar sein.

Wo am Ende die Informationen bereitgestellt werden, ob direkt beim Komponentenhersteller, beim Anlagenbauer, vor Ort beim Betreiber der digitalen Fabrik oder direkt auf der Komponente, ist dabei offen. Ebenso ist offen, ob die Information auf einem eigenen Content Delivery Server, einem integrierten Webservice (der zum Beispiel über den doctima ContentConnect mit Inhalten versorgt wird) oder als Informationsbausteine in einem Asset Management System wie SAP AIN zu liegen kommen. Das abstrakte Konzept der Verwaltungsschale erlaubt hier viele Wege zu gehen.

Die Idee, dass alle (bleiben wir realistisch: möglichst viele) Ersteller von Technischer Information ein gemeinsames Format bereitstellen, um dem Anwender einen integrierten Wissensschatz zu einem aus vielen Komponenten bestehenden System bereitzustellen, erscheint mir auch ohne den direkten Bezug zu Industrie 4.0 ein absolut erstrebenswertes Ziel zu sein – weil es u. a. zu Verbesserungen für das leidige Thema Zulieferdokumentation bringen kann. In der Denkweise des RAMI 4.0 lässt sich die Dokumentation von der untersten Ebene mit PDF-Dokumenten als „Assets“ auf die vierte Ebene, das Information Layer, mit Content-Delivery-Diensten als funktionaler Teil der übergreifenden Verwaltungsschale aufwerten.

Ich bin sehr gespannt auf die kommenden Entwicklungen und wie sich das iiRDS-Format in der Praxis bewähren wird – und auf Ihre Meinung. Wie sind Ihre Erwartungen bezüglich der Digitalisierung der Arbeitswelt? Diskutieren Sie mit uns in den Kommentaren!

#4.0, die tekom-Jahrestagung 2016

img_9629Information 4.0, Dokumentation 4.0, Industrie 4.0, #4.0. Überall versucht man neue und innovative Wege zu gehen, so auch in der Branche der Technischen Kommunikation und Technischen Dokumentation. Unser Rückblick auf die tekom-Jahrestagung 2016.

Markus Nickl

P1080459-SWtekom Herbsttagung 2016. Für mich ein besonderes Datum. Denn wenn ich richtig rechne, dann ist es genau 20 Jahre her, dass ich auf meiner ersten „tekom“ war – damals in Berlin mit einem eigenen Vortrag über historische Gebrauchsanleitungen. Seitdem hat sich eine Menge getan. Besonders die Dimensionen, die die begleitende Messe angenommen hat, hätte ich mir damals nicht vorstellen können. Und die Internationalisierung der Veranstaltung ist ebenfalls beeindruckend. An nur einem Messetag habe ich (unter anderem und nur so als Beispiel) mit einem ungarischen Übersetzer, einer chinesischen Expertin für Simplified English, einem niederländischen Industriedesigner und einem US-amerikanischen Marketingexperten gesprochen. Das hätte ich mir damals vor zwanzig Jahren nie träumen lassen. Toll welchen Weg die tekom in dieser Zeit genommen hat. Ach ja, aus guter Tradition war ich auch diesmal wieder mit einem Vortrag dabei: „SEO – Technische Dokumentation für die Suchmaschine“.  Wen’s interessiert, der kann mehr dazu im Parson-Blog lesen.

Edgar Hellfritsch

rp_P1090805_SW-e1447767838366.jpgDieses Jahr bin ich kaum dazu gekommen, meiner Rolle als Tagungsbeirat gerecht zu werden und möglichst viele Vorträge zu besuchen. Die Vorträge, die ich mitbekommen habe, waren v. a. die, an denen ich selbst beteiligt war: Den „Showcase Mobile Dokumentation“ habe ich mit moderiert. Alle sechs Vorträge waren interessant und von durchgängig hohem Niveau. Die vielen Gespräche, die ich an unserem Stand mit Besuchern gerade zu diesem Thema geführt habe, zeigen mir, dass die mobile Bereitstellung von Inhalten langsam die Bedeutung gewinnt, die ich ihr zuschreibe. Mein anderes Thema dieses Jahr war Information 4.0 und mit ihm der Standard iiRDS, an dem ich mitarbeiten darf. Hier haben mich vor allem die Prototypen der Systemhersteller beeindruckt, die bereits sehr schön das Nutzpotenzial des in Arbeit befindlichen Bereitstellungsstandards gezeigt haben.

Johannes Dreikorn

p1090631-b-hoch-swDrei Tage tekom-Tagung – das sind drei Tage intensivsten Austauschs. Das war eigentlich schon immer so, aber dieses Jahr habe ich das besonders stark empfunden. Ganz sicher deswegen, weil ich die vollen drei Tage an unserem Stand präsent war. Der Blick auf meine Notizen macht mir noch einmal deutlich, wie viel spannende Gespräche auf unserem „grünen Teppich“ stattgefunden haben mit Kunden, Interessenten und Job-Bewerbern. Dabei durfte ich auch mein Lieblingskind, das ContentRuleset, mehrmals vorführen.
Intensiver Austausch auch in den beiden Workshops, die ich gehalten habe. Mit der Textsorte Checklisten ein Thema ganz aus der Praxis, eine herausfordernde Aufgabenstellung – und das mit 30 motivierten Teilnehmern durcharbeiten. Ich liebe diese angeregte Arbeitsatmosphäre einfach. Und dann all die Begegnungen am Rande – ein Gespräch beim Mittagessen mit jemand bis dato ganz Unbekannten, ein Plausch unter langjährigen Weggefährten. Eins ist klar: tekom-Jahrestagung auch nächstes Jahr wieder mit mir – und wieder volle drei Tage.

Christian Hammer

P1090233-SWStuttgart Anfang November? Na klar – tekom-Tagung! In diesem Jahr kann ich Tagung für mich getrost durch Messe ersetzen. Ich habe es zum ersten Mal in nicht einen einzigen Vortrag geschafft. Nicht, weil ich die große Nähe zu unserem Hallen-Nachbarn der Kaffee-Insel nicht aufgeben wollte, sondern weil wir eigentlich immer Interessenten und Interessante am Stand hatten.
Hier nochmal ein großes Lob an unseren Ober-Location-Scout Benny Rauschenberger. Auch dieses Jahr waren unsere 20 Quadratmeter doctima wieder sehr gut in Halle 1 aufgehoben. Abseits des Gedränges und der Hektik der größeren Halle 2 hatten wir die richtige Atmosphäre für persönliche und konstruktive Gespräche, die sich teilweise schon fast zu kleinen Workshops entwickelten.
Am schönsten finde ich es immer zu sehen, dass unsere Kunden einen Besuch bei uns am Stand nicht als lästigen Pflichttermin wahrnehmen, sondern sich darauf freuen. So waren viele immer mal wieder bei uns, um ein kleines Pläuschchen  zu halten oder auch um sich mit anderen Besuchern auszutauschen. Unsere Kunden fühlen sich also wohl bei uns. Gut so!

Daniel Rieß

danielDie tekom-Jahrestagung ist im Hause doctima seit jeher ein wichtiges Thema, um das ich die letzten Jahre kaum herumkam, auch wenn ich nicht vor Ort war. Das sollte sich 2016 ändern, denn nun war ich ebenfalls stolzer Besitzer eines Tickets und hatte die Möglichkeit Mittwoch und Donnerstag auf der Messe mitzuerleben.
Nach dem Einlass fand ich den doctima-Stand nach wenigen Minuten, der unter anderem durch den 3D-Drucker auffiel, der zugleich Preis unserer Verlosung und Fabrik von personalisierten Legosteinen war, die die Standbesucher auf Anfrage drucken lassen konnten.
Doch ich musste gleich wieder los, denn der erste Vortrag wartete auf mich. Was auf den ersten Blick nach stressigem Hin und Her klingt, nahm ich vielmehr als kurzweilige Abwechslung zwischen innovativem fachlichem Input in den Vorträgen und tollen Gesprächen sowie interessanten Kontakten an unserem Stand wahr. So machte es mir nicht zuletzt großen Spaß, Menschen, mit denen ich sonst via Mail und Telefon zusammenarbeite, in Lebensgröße kennenzulernen.
Nein, es ging gerade nicht um 3D-Modelle, die durch eine AR-Brille unfassbar real dargestellt werden – das konnte ich aber dennoch am Ende von „Augmented Reality solution for delivering complex instructions“ (Andrew Head, Semcon) am Donnerstag ausprobieren. Weitere Highlights waren für mich die Umsetzung der AR-App bei SAF-Holland (Thomas Piroth, Tim Rausch) und die smarte Wartung einer Klimaanlage nach Industrie 4.0 (Jürgen Sapara, Thomas Gering). Kurz gesagt: Der Besuch der tekom-Jahrestagung 2016 hat sich voll und ganz gelohnt.

Benjamin Rauschenberger

P1080932-B-SWAls Vater des Messeauftritts von der Konzeption über die Organisation bis hin zum Einschwören der Kollegen war ich natürlich besonders unter Strom. Anreise mit Aufbau des Messestandes und dann drei Tage bangen, dass auch wirklich alles so klappt wie geplant und dass auch nichts zu Hause vergessen wurde. Abschalten kann man da nicht wirklich. Aber der ganze Aufwand hat sich wieder einmal gelohnt. Wir hatten tolle Gespräche. Wir haben ein super Feedback von allen Seiten bekommen. Sei es zu unseren Vorträgen, zu unserem Messestand oder zu unserem Auftreten auf der Tagung. Und wir hatten wahnsinnig viel Spaß dabei. Das hat sicherlich zur guten Stimmung beigetragen. Danke an alle doctima-Kollegen und an alle Besucher unseres Standes, das war toll!
Was die Themen betrifft, nehme ich vor allem zwei Strömungen mit. Einerseits Content Delivery: Die Unternehmen wollen ihren Doku-Content über verschiedene Kanäle ausliefern, gerade heutzutage, da viele digitale Möglichkeiten dazu bestehen. Großteils auch als Mobile Dokumentation. Kein Wunder, dass wir viele Gespräche dazu hatten, da wir ja Projekte in dem Themengebiet haben und über unsere Erfahrungen berichten können. Andererseits Content-Wiederverwendung, was nicht so weit weg ist von erstem Thema: Content aus der Doku, vor allem guter Content, soll weiter und wieder genutzt werden. Und da spielt es keine Rolle ob intern oder extern, ob für Service, Support, Marketing, Vertrieb, Interessenten oder Kunden. Wichtig ist, eine Strategie dahinter zu haben, dann bietet der Doku-Content einen nicht zu unterschätzenden Mehrwert. Das waren für mich die beiden, als Marketeer und Vertriebler naheliegenden und daher zu erwartenden, Hauptthemen der Jahrestagung.

Michael Mann

Auf meine erste tekom-Tagung bin ich mit vorsichtiger Neugier gefahren: Einerseits haben die Berichte der Kollegen schon Hoffnung auf eine spannende Veranstaltung gemacht – andererseits will man ja nicht mit zu großen Erwartungen anreisen, die dann nicht erfüllt werden können. Umso besser, dass die Erwartungen dann tatsächlich erfüllt worden sind. Sehr gut gefallen hat mir, dass in den Vorträge „echte“ Produkte und tatsächlich umgesetzte Prozesse mit ihren Ergebnissen vorgestellt wurden und nicht ein „könnte man mal“ oder ein „wäre schön, wenn“. Wenn man in einem Vortrag (zugegebenermaßen als „für Anfänger“ eingestuft) auch mal nichts Neues lernt, kann man sich ja immer noch mit der Schlussfolgerung trösten, dass man in dem Thema auch keine ganz grundlegenden Entwicklungen verpasst hat.
Der Messebesuch führt ganz deutlich vor Augen, dass man in einer Branche arbeitet, die immer noch ein bisschen vielfältiger ist, als man das eigentlich schon wusste. Fazit: Für mich ein rundum gelungener Besuch – nächstes Jahr komme ich gerne wieder!

Was ist Ihr Feedback zur tekom-Jahrestagung 2016? Welche Vorträge oder Workshops fanden Sie gut? Welche Themen haben auf der Tagung gefehlt oder waren eher schwach vertreten? Kommentieren Sie und lassen Sie uns darüber reden.

Lasten- und Pflichtenhefte – der Erfolg entscheidet sich am Dokumentkonzept

Vorgefertigte Lastenhefte wollen viele. Aber wären die sinnvoll?

Vorgefertigte Lastenhefte wollen viele. Aber wären die sinnvoll?

Seit gut zehn Jahren bin ich in Unternehmen unterwegs, um mit Entwicklungsabteilungen einen für die Ingenieure oft lästigen Dokumenttyp auf Vordermann zu bringen: Lasten- und Pflichtenhefte. Egal wohin ich komme, hegen meine Kunden eine ganz bestimmte Hoffnung. Eine Hoffnung, die sich in zwei Fragen ausdrückt:

Frage 1: Gibt es Normen, die man unbedingt beachten muss, um ein wirklich sauberes (und damit vollständiges und möglichst rechtssicheres) Lastenheft oder Pflichtenheft zu erstellen?

Und Frage 2: Gibt es nicht allgemeingültige Dokumentvorlagen mit allen benötigten Inhalten – am besten downloadbar aus dem Web? Und dann ist alles gut?

Unerfüllbare Hoffnungen

Diese Hoffnung muss ich regelmäßig enttäuschen. Leider – könnte man erst einmal meinen.

Natürlich gibt es Normen, die Lasten- und Pflichtenhefte thematisieren, zum Beispiel die DIN 69901. Aber diese Normen helfen bei den Fragen, die die Unternehmen umtreiben, nicht wirklich weiter. Normen kann man vor allem Definitionen entnehmen, was ein Lasten- oder Pflichtenheft ist, was als Gliederung eventuell sinnvoll ist und wie man diese Dokumente in Entwicklungsprozessen am besten einsetzt. Gewonnen ist damit nicht viel.

Dasselbe gilt für downloadbare Vorlagen: Sie können einem einen ersten Eindruck geben, was vielleicht wichtig ist. Aber eine Dokumentvorlage und vor allem die darin enthalten Inhaltspunkte entspringen immer einem bestimmten Kontext und treffen nie passgenau zu. Oder sie sind so allgemein gehalten, dass sie im Grunde nichts aussagen.

Die gute Nachricht – Freiraum für passgenaue Dokumentkonzepte

Mit „Kontext“ ist das relevante Stichwort schon gefallen. Jedes Unternehmen arbeitet (egal ob Auftragnehmer oder Auftraggeber, egal ob Lastenheft oder Pflichtenheft) unter anderen Rahmenbedingungen. Produkte unterscheiden sich technologisch grundlegend, die Vertragspartner sind unterschiedliche, interne Dokumente benötigen andere Inhalte als Dokumente, die über Unternehmensgrenzen ausgetauscht werden. Abhängig davon, wer die Designverantwortung trägt, entwickeln Lasten- und Pflichtenhefte erst ihre eigentliche Gestalt.

Eine Lösung von der Stange – das zeigt mir die Praxis immer wieder ganz deutlich – kann es eigentlich gar nicht geben.

Genau hier aber liegt die große Chance für die Unternehmen. Und das ist die Botschaft, die die Miene meiner Kunden ganz schnell wieder aufhellt. Weil der Kontext hochgradig individuell ist, besteht große Freiheit in der Gestaltung von Lastenheften und Pflichtenheften. Ganz sicher keine Beliebigkeit, aber ein Freiraum, in dem man eine unternehmensspezifisches Dokumentenkonzept entwickeln kann. Ein Konzept, das dann wirklich funktionierende Dokumente ermöglicht.

Was so ein spezifisches Dokumentenkonzept ganz konkret ausmacht, möchte ich hier noch an drei Beispielen zeigen:

Beispiel 1: Es muss nicht immer viel sein

Dieses Konzept ist vor gut zwei Jahren in München entstanden. Ein Unternehmen der Schwerindustrie liefert als Auftragnehmer eine Presseinrichtung für eine große Stahlverarbeitungsanlage. Das spezifizierte Produkt ist für meine Vorstellungen riesengroß, das Pflichtenheft dazu ist aber maximal schlank geworden. Es ist wenige Seiten lang und macht zusammen mit dem Maschinenplan trotzdem eine vollumfängliche Leistungszusage an den Auftraggeber.

Der Kunde hat sehr aufgeatmet: Dass ein Projekt mit Pflichtenheft die Dokumentationsaufwände der Ingenieure, die ja sowieso schon unter hohem Zeitdruck arbeiten, vervielfachen würde – diese Befürchtung hat sich nicht bewahrheitet.

Beispiel 2: Ein Dokument, das skaliert

Genau hinsehen! Auf dem Weg zu einer passgenauen Dokumentkonzeption

Genau hinsehen! Auf dem Weg zu einer passgenauen Dokumentkonzeption

Ein Unternehmen für Fenster- und Fassadentechnologie definiert seinen Entwicklungsprozess für Innovationsprojekte neu. Damit die Entwicklung koordiniert abläuft, soll der Vertrieb als unternehmensinterner Auftraggeber ein Lastenheft schreiben. Das Problem an der bisherigen Praxis: Das Lastenheft des Vertriebs ist der Entwicklung zu unspezifisch, der Vertrieb möchte aber nichts vorgeben und spezifizieren, worüber er noch keine Aussagen machen kann. Eine klassische Patt-Situation.

Als Lösung haben wir ein Lastenheft konzipiert, das mitwachsen kann. In seiner ersten Fassung (das „Lastenheft light“) formuliert der Vertrieb die Produktidee und die zentralen Leistungsmerkmale des neu zu entwickelnden Produkts. Dieser Stand dient der internen Abstimmung. Erst wenn klar ist, ob sich dieses Produktkonzept technologisch und wirtschaftlich umsetzen lässt (und in diesem Bewertungs- und Aushandlungsprozess sitzt die Entwicklung mit am Tisch), wird ein „richtiges“ und umfassendes Lastenheft erstellt, das für die Entwicklungsabteilung die Vorgaben in relevanter Breite und Tiefe niederlegt.

Dass dieses Konzept aufgeht, ist konzeptionell vor allem der Gliederung der neuen Lastenheftvorlage zu verdanken. Sie kann angelehnt an den Fortschritt im Entwicklungsprozess von vorne nach hinten wachsen. Es ist als Lastenheft-Standard eine ganz individuelle Lösung entstanden, die sich durch ein hohes Maß an Flexibilität und Skalierbarkeit auszeichnet.

Beispiel 3: Antworten auf 1500 Anforderungen

Ein letztes Beispiel: Ein Automobilzulieferer bekommt von seinen Auftraggebern in schöner Regelmäßigkeit Lastenhefte vorgelegt, die 300 Seiten und länger sind. Um noch einmal eine Zahl zu nennen: Wir reden von 1200 bis 1500 Anforderungen.

Wie kann nun ein Pflichtenheft bzw. die Leistungszusage in so einem Szenario aussehen? Und zwar ohne dass als Pflichtenheft ein noch längeres Monsterdokument entsteht, das unsinnige Aufwände erzeugt? Denn immerhin sagt die reine Lehre – und auch die Auftraggeber aus dem Automobilsektor fordern es: Ein Pflichtenheft muss Antwort geben auf alle Anforderungen des Auftraggebers.

In diesem Fall entwickeln wir eine Lösung aus zwei Dokumenten:  Die Detailantworten stehen in einer Excel-Liste, die eine maximal kurze Antwort auf wirklich jede Anforderung gibt. Dazu kommt aber – und das war hier das Aha-Erlebnis – ein Rahmendokument, in dem der Auftragnehmer noch einmal losgelöst von dem Detaildokument seine Lösung und seine Leistungsfähigkeit konzentriert darstellt. Das zudem Punkte hervorhebt und anbringt, die ihm aus seiner Rolle heraus wichtig sind – und nicht nur solche, die der Auftraggeber aktiv nachfragt. Und das zu guter Letzt sogar – auch das ein Novum – den Auftraggeber in die Pflicht nimmt.

Seit diesem Jahr gehen alle „Antworten“ dieses Kunden auf diese Weise zurück an seine Auftraggeber.

Buchbar als Praxispaket Lastenhefte/Praxispaket Pflichtenhefte

Die konzeptionelle Anlage eines Lasten- oder Pflichtenheftes halte ich im Rückblick auf bestimmt 60 Beratungs-Einsätze als den wesentlichen Schlüssel zum Erfolg. Und das Schöne ist, dass man die Konzepte so auslegen kann, dass daraus ein wirklicher Standard entsteht – also Vorlagen und Definitionen, die für ganze Klassen von Projekten tragen und nicht nur für einen Einzelfall.

Sollten Ihnen diese Sorte Spezifikationsdokumente auch im Magen liegen: Schauen Sie sich doch einfach einmal unser ‚Praxispaket Lastenhefte/Praxispaket Pflichtenhefte‚ an. Ein bewährtes Verfahren, in dem wir schon ganz viele Unternehmen begleitet haben.