Verschiedene Hüte und die gleiche Sprache. Interview mit Lukas Jetzig, Knowledge Engineer und Technical Communicator bei parson

von Lukas Jetzig , Uta Lange am 20. November 2024

Was ist Knowledge-Engineering und welche Aufgaben hat ein Knowledge-Engineer in der Technischen Kommunikation? Wir haben unseren Kollegen Lukas Jetzig gefragt. Er arbeitet seit 2022 als Technical Communicator und Knowledge-Engineer bei parson.

Lukas Jetzig, Technical Communicator und Knowledge-Engineer bei parson

Lukas, eine deiner Aufgaben bei parson ist Knowledge-Engineering. Was genau ist Knowledge-Engineering und wie würdest du deine Rolle beschreiben?

Im Knowledge-Engineering sorgen wir dafür, dass technische Informationen nicht nur dokumentiert, sondern auch sinnvoll organisiert und kontinuierlich nutzbar gemacht werden. Dabei geht es zunächst darum, implizites und explizites Wissen zu erfassen.

Über implizites Wissen verfügen die Expert:innen des Unternehmens, z.B. die Entwickler:innen, Product Owner, Technischen Redakteur:innen und Ingenieure. Mit diesen Personen führen wir Interviews, denn oft ist implizites Wissen nur in den Köpfen dieser Expert:innen vorhanden. Wir fragen sie zum Beispiel, welche Konfigurationen, Funktionen und Varianten es für ein bestimmtes Produkt gibt und welche Topics in der Dokumentation diese beschreiben.

Um explizites Wissen zu erfassen, identifizieren wir Inhalte, die möglicherweise über verschiedene Systeme (Silos) verstreut sind oder beobachten unternehmensinterne Prozesse.

Das gesammelte Wissen organisieren wir dann in einem strukturierten Format und überführen es in Modelle wie Ontologien, Knowledge-Graphen (Wissensnetze) oder Metadatenmodelle. Diese Modelle helfen uns, Informationen logisch zu verknüpfen, Zusammenhänge aufzudecken und das Wissen in Systemen verfügbar zu machen.

Das Wissen, das in einem Knowledge-Graphen beschrieben wird, kann verschiedene Bereiche betreffen. Ein Beispiel sind Produktdaten, u.a. Produktvarianten, Produkteigenschaften, Komponenten und Funktionen. Diese Daten können dann aus dem Graphen für verschiedene Anwendungsszenarien nutzbar gemacht werden, u.a. für die automatisierte Zuweisung von Metadaten an Inhalte der Technischen Dokumentation.

Beispiel eines Wissensgraphen zur Kategorisierung, hier von Fahrzeugen und Kraftstoffen

Ist Knowledge-Engineering eine neue Disziplin in der Technischen Dokumentation?

Knowledge-Engineering ist nicht neu, sondern hat sich über Jahrzehnte entwickelt. Sein ursprüngliches Ziel war es, menschliches Wissen in Computermodelle zu übertragen, um die Lösung von Problemen in bestimmten Bereichen zu automatisieren.

Heute ist Knowledge-Engineering ein vielseitiger Ansatz, der in vielen Bereichen verwendet wird, insbesondere bei der systematischen Verwaltung und Nutzung von Wissen. Dank moderner Anwendungen und Technologien hat sich Knowledge-Engineering weiterentwickelt und spielt eine zentrale Rolle in Bereichen wie Wissensmanagement und Technischer Dokumentation.

Wie wird man Knowledge-Engineer und welche Kenntnisse und Fähigkeiten sind dafür erforderlich?

Ich weiß nicht, ob es einen expliziten Studiengang für Knowledge-Engineering gibt. Ich bin staatlich geprüfter Übersetzer und Dolmetscher. 2022 habe ich zusätzlich den Studiengang Technisches Informationsdesign und Technische Redaktion an der Hochschule Hannover abgeschlossen.

Als Knowledge-Engineer in der Technischen Kommunikation benötigt man auf jeden Fall Grundkenntnisse in der Technischen Redaktion und praktische Erfahrungen, die man im Berufsalltag in der Technischen Dokumentation sammelt.

Darüber hinaus kann eine gezielte Weiterbildung zur Modellierung von Metadaten oder der Entwicklung von Knowledge-Graphen sinnvoll sein. Beispielsweise, indem man sich mit gängigen formalen Sprachen beschäftigt, die zur Definition von Ontologien genutzt werden. Spezifisch denke ich dabei an die Standards RDF und OWL. Aber auch eine gezielte Einarbeitung in Modellierungs-Tools für Wissensnetze kann sich lohnen. Einige Beispiele, mit denen ich zu tun hatte, sind Empolis Knowledge Express, PoolParty sowie die klar:suite. Womit man sich genau beschäftigt, hängt letztendlich vom Anwendungsfall und dem Projekt ab.

Wichtig ist auch ein Gespür dafür, wo Informationen zu finden sind und wie man mit Menschen spricht, um ihnen die wichtigen Informationen zu entlocken.

Wie ein Technische/r Redakteur:in muss auch ein Knowledge-Engineer über gute Kommunikationsfähigkeiten verfügen und in der Lage sein, Informationen zu sammeln, zu identifizieren, zu ordnen und durch Interviews und Analysen miteinander in Beziehung zu setzen.

Wie unterscheidet sich die Arbeit von Knowledge-Engineers und Technischen Redakteur:innen?

Die Arbeit von Knowledge-Engineers ist abstrakter und weniger inhaltsorientiert. Technische Redakteur:innen erstellen, strukturieren und pflegen verständliche und präzise Dokumentation wie Bedienungsanleitungen und Online-Hilfen, die komplexe technische Informationen für unterschiedliche Zielgruppen zugänglich machen.

Ein Knowledge-Engineer beschreibt Konzepte und Kategorien und ihre Beziehungen zueinander. Dabei beschränkt sich ein Knowledge-Engineer nicht auf Technische Dokumentation, sondern kann auch Wissen über Produkte oder andere Bereiche modellieren. Wenn Wissen für die Technische Kommunikation modelliert wird, legt ein Knowledge-Engineer unter anderem fest, wie die Informationen der Dokumentation in Module aufgeteilt und kategorisiert werden, damit sie sinnvoll gefunden und ausgegeben werden können.

Schreibst du als Knowledge-Engineer auch Dokumentation?

In der reinen Rolle nicht. Aber die meisten von uns bei parson sind auch Technische Redakteur:innen. Deshalb kommt es vor, dass wir in einem Projekt beide Rollen innehaben und auch schreiben. Das heißt, ich bin in einem Projekt erst Knowledge-Engineer und dann Technischer Redakteur.

Deshalb ist sehr hilfreich, wenn man als Knowledge Engineer auch das Wissen eines Technischen Redakteurs hat.

Mit wem arbeitest du in Projekten häufig zusammen, und wie sieht diese Zusammenarbeit aus?

Auf Kundenseite arbeite ich mit denjenigen zusammen, die das Wissen über die Produkte haben. Da sind zum einen die Product Owner, die die Fäden zusammenhalten und für Produktänderungen und die Produktdokumentation verantwortlich sind. Dann gibt es die Entwickler:innen und Technische/n Redakteur:innen, aber auch die Informationsarchitekt:innen, die sich mit dem Redaktionssystem auskennen, und die IT-Mitarbeiter:innen: Die wissen oft viel über die Verwaltung von Produktdaten und in welchem Format bestimmte Daten vorhanden sind.

Darüber hinaus arbeiten wir in Kundenprojekten auch mit anderen Dienstleistern zusammen, z.B. mit Herstellern von Content-Delivery-Portalen und Redaktionssystemen.

Das parson-Team besteht aus Informationsarchitekt:innen, Technischen Redakteur:innen und anderen erfahrenen Kolleg:innen, die bereits in ähnlichen Projekten gearbeitet haben. Mit ihnen besprechen wir Best Practices und beraten uns, welche Ansätze für ein Projekt am besten funktionieren. Wie bei allen parson-Projekten gilt das Vier-Augen-Prinzip, nicht nur bei der Erstellung von Technischer Dokumentation.

Worauf achtet ihr bei der Zusammenarbeit mit den verschiedenen Expert:innen? Gibt es manchmal Probleme?

Für uns ist wichtig, immer im Dialog zu bleiben. Auf der Kundenseite klopfen wir immer wieder ab: Entspricht das, was wir hier identifiziert haben, auch wirklich eurer Realität? Produktwelten sind oft so komplex; dass sie sich nicht zweidimensional abbilden lassen.

Wir setzen uns auch die verschiedenen "Unternehmenshüte" auf. Wir sprechen zum Beispiel immer mit der IT-Abteilung und fragen: Passen unsere Datenstruktur zu euren Systemen? Und wir versetzen uns in die Rolle der Produktentwicklung und der Technischen Redaktion. Denn das Wichtigste ist, dass wir eine gemeinsame Sprache finden!

Welche Voraussetzungen müssen erfüllt sein, damit ein Knowledge-Engineer ihre oder seine Arbeit machen kann?

Generell ist es wichtig, dass die richtigen Personen im Unternehmen ins Boot geholt wurden. Gemeint sind damit Systemverantwortliche für die verschiedenen Quellsysteme sowie Fachpersonen, die das nötige Wissen über die zu modellierenden Konzepte haben. Gemeinsam mit ihnen kann geklärt werden, welche Metadaten neu modelliert werden müssen bzw. welche Daten aus anderen Systemen (ihrer sogenannten Source of Truth) wiederverwendet werden können. Je nachdem, wie viele Quellsysteme verbunden werden sollen, muss es auch die Möglichkeit geben, Schnittstellen zu diesen Systemen einzurichten.

Damit diese Fragen richtig beantwortet werden können, muss auch Klarheit über die Ziele des Knowledge-Engineering-Projektes herrschen. Warum machen wir uns die Mühe? Sollen Daten unternehmensweit harmonisiert werden? Gibt es Bestrebungen hin zu einem digitalen Zwilling? Oder ist das Ziel zunächst, Produktdaten für die technische Redaktion wiederzuverwenden? Entsprechend sind auch die Herangehensweise sowie die Komplexität der Aufgabe sehr unterschiedlich. Dabei hilft es, wenn zumindest innerhalb der einzelnen Informationssilos schon Daten konsistent modelliert werden. Je einheitlicher die Daten, umso leichter lassen sich Automatismen implementieren. Das ist oft wesentlich leichter, wenn das Unternehmen eine gut durchdachte Content-Strategie für klare und konsistente Botschaften entwickelt hat. Das bedeutet, dass das Unternehmen die Bedürfnisse seiner Zielgruppen kennt und ihnen Informationen zur Verfügung stellt, die qualitativ hochwertig, verständlich und konsistent sind. Ein Unternehmen sollte auf allen Kanälen die gleiche Sprache sprechen.

Auf welche Probleme stoßen Unternehmen häufig, wenn sie ein Knowledge-Engineering-Projekt in Angriff nehmen?

In den wenigsten Fällen beginnen wir mit einem leeren Blatt. Viele Unternehmen haben sich bereits Gedanken darüber gemacht, wie sie ihre Produkte und Prozesse einheitlich darstellen können. Oft ist es aber so, dass jedes Team anders denkt und auch andere primäre Aufgaben hat.

Hinzu kommt, dass verschiedene Teams unterschiedliche Informationen erstellen: Die Technische Redaktion erstellt die Produktdokumentation, die Produktentwicklung liefert die technischen Daten und das Marketing schreibt die Inhalte für die Website. Oft werden diese Daten und Informationen in verschiedenen Systemen gepflegt, die nicht unbedingt miteinander verbunden sind, also Datensilos darstellen. Die Verknüpfung dieser Informationen zwischen den Teams ist eine Herausforderung.

Meistens muss das Knowledge-Engineering auch neben der primären Arbeit der Teams stattfinden. Wir erhalten von den Teams verschiedene "Zettel", auf denen das Problem auf unterschiedliche Weise beschrieben wird. Unsere Aufgabe und gleichzeitig Herausforderung ist es, die Informationen aus diesen Zetteln konsistent zusammenzufassen und inkonsistente Daten zu bereinigen. Denn um Inhalte auf konsequente Art find- und nutzbar machen zu können, muss man die gleiche Sprache sprechen. Die Teams müssen also zusammenarbeiten, damit das Projekt gelingt. Der Knowledge-Engineer ist die Schnittstelle.

Welche Methoden und Tools verwendest du in deiner Arbeit?

Mit Hilfe von Knowledge-Graphen führen wir Informationen zusammen und stellen diese gezielt für verschiedene Zielgruppen oder Anwendungen bereit.

In Component-Content-Management-Systemen (CCMS) bzw. Redaktionssystemen sowie Content-Delivery- Plattformen (CDP) setzen wir häufig unsere konzipierten Metadatenmodelle um. Wenn vorhandene Systeme wie z. B. Produkt-Informationsmanagement-Systeme (PIM) angebunden werden sollen, müssen wir teilweise auch die Einrichtung von Schnittstellen koordinieren.

Um zunächst ein Konzept zu entwerfen, nutzen wir aber auch gerne Excel-Tabellen, Mindmaps oder Concept- Maps.

Welche aktuellen Trends im Bereich der Technischen Dokumentation und Knowledge-Engineering findest du besonders spannend?

Sehr spannend finde ich die Entwicklung von Knowledge-Graphen (Wissensnetzen). Oder wenn Unternehmen versuchen, einen Digital Twin aufzubauen. Auch hier ist interessant, welche Möglichkeiten generative KI bietet. Die tatsächlichen Anwendungsfälle dafür sind für mich noch nicht absehbar, aber es gibt Potentiale, zum Beispiel bei der Homogenisierung von Daten.

Ich hatte mal ein Projekt, in dem Produktfunktionen sehr unterschiedlich modelliert waren. Teilweise wurde dem jeweiligen Objekt ein einfaches Ja/Nein zugewiesen, an anderen Stellen wurde als Text "ist vorhanden" oder "ist nicht vorhanden" notiert. So etwas ließe sich potentiell schneller mit einer KI-Anwendung vereinheitlichen, als wenn man das händisch macht. Die Zuverlässigkeit eines solchen Ansatzes müsste man aber vorher gründlich testen.

An welchen Projekten arbeitest du derzeit als Knowledge-Engineer bei parson?

Für einen unserer Kunden haben wir Metadaten für die Anreicherung von Selbsthilfe-Inhalten basierend auf iiRDS modelliert. Als Datenquellen hatten wir zum einen Metadaten aus dem Redaktionssystem, die dort für das Variantenmanagement genutzt wurden. Eine weitere Quellen waren Produktdaten, die eigentlich für Marketingzecke aufbereitet waren. Mit dem Knowledge-Graphen bot sich die Chance, beide Datensätze zu kombinieren, damit Kunden Inhalte in einem Dokumentationsportal besser filtern können. Die Herausforderung bestand aber darin, diese gänzlich anders konzipierten Metadaten zusammenzuführen und mit Hilfe eines Knowledge-Graphen zu vereinheitlichen.

Wir haben es geschafft, dass zwei Metadatenmodelle die gleiche Sprache sprechen, in diesem Fall über das iiRDS-Modell. Durch die Verwendung von iiRDS konnten wir Ordnung ins Chaos bringen.

Weitere Referenzen 

Was wünschst du dir für ein zukünftiges Projekt?

Ich fände es sehr spannend, einmal mit einem leeren Blatt Papier anzufangen, sozusagen bei Null. Zum Beispiel, das Metadatenkonzept für ein Redaktionssystem gänzlich neu aufzubauen, verschiedene Teams zusammenzubringen und ein einheitliches Informationskonzept zu entwickeln. So wäre ich nicht gleich von Anfang an in Gegebenheiten gefangen, sondern könnte mich auf die optimale Lösung konzentrieren.

Wo findet man einen Job als Knowledge-Engineer?

Knowledge-Engineers werden in jeder Organisation gebraucht, die die Notwendigkeit erkennen, das Wissen aus den Silos und den Köpfen der Menschen herauszuholen und eine einheitliche Sprache zu sprechen. Eine Organisation, die erkennt, dass ihr Wissen strukturiert werden muss, braucht die Expertise eines Knowledge-Engineers. Es gibt immer mehr Dienstleister, die Beratungen dafür anbieten, darunter auch parson.

Weitere lesenswerte Beiträge zum Thema

Weitere Interviews mit parson-Mitarbeiter:innen

Neuen Kommentar hinzufügen

Ihre E-Mail-Adresse wird nicht veröffentlicht.

Das könnte Sie auch interessieren

Zehn Fragen zu iiRDS

von am 20. November 2024

Wie bewährt sich iiRDS in der Praxis, etwa bei einem Hersteller von Messgeräten? Welchen Nutzen hat der Standard und wo liegen seine Potenziale? Ulrike Parson und Thomas Ziesing haben die Antworten. Die Fragen stellte Susanne Lohmüller, tekom. mehr...

Neue Partnerschaft: parson wird Beratungspartner für PoolParty

04. November 2024

parson ist jetzt Beratungspartner rund um semantische Technologien für die PoolParty Semantic Suite der Semantic Web Company (SWC). parson erhält damit exklusiven Zugang zu den Ressourcen der PoolParty Semantic Suite, dem weltweit führenden semantischen Middleware-Produkt der SWC. mehr...