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!

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.

Steilkurs für PR-Einsteiger

Buchcover: Steinbach: "Crashkurs Public Relations"Als Quereinsteiger hat man es nicht immer leicht. Da sind gute Tipps gefragt oder am besten jemand, der uns für den Anfang unter die Fittiche nimmt. Und genau das beabsichtigt Marion Steinbach mit ihrem „Crashkurs Public Relations“.

Eine Lektüre, die also auch für Technische Redakteure interessant ist. Denn gerade in mittelständischen Unternehmen sind von unserem Beruf ja Allrounder-Fähigkeiten gefragt. Da ist es nicht ungewöhnlich, dass man „nebenbei“ auch die PR des Unternehmens zu bewältigen hat.

Mehr als erwartet

Wer nun denkt, „Crashkurs“ und „9 Schritte“ deutet auf ein schmales Büchlein hin, der wird enttäuscht werden. Denn die neun Schritte brauchen dann doch fast 300 Seiten. Dort findet man dann aber auch alles Wesentliche, was der PR-Einsteiger oder die PR-Einsteigerin wissen muss. Wer schon ein wenig Vorerfahrung mitbringt, wird einiges wiedererkennen: SWOT-Analyse, AIDA-Formel – das hat man womöglich auch an anderer Stelle schon gelesen oder gehört.

Hin- und hergerissen

Da ist es deshalb gut, dass sich Marion Steinbach nicht lange bei den theoretischen Grundlagen aufhält. Auch Themen wie „Das PR-Konzept“ (Kapitel 1) geht sie ganz praxisnah an, mit Tipps die Lust machen, sie sofort umzusetzen. Dazu streut sie in den Text immer wieder Infoboxen („Achtung“, „Extratipp“) ein, die Wichtiges herausheben und gleichzeitig den Lesefluss auflockern. Auch Zitate und Unternehmensbeispiele tragen zur guten Lesbarkeit bei.

Man ist bei dem Crashkurs hin- und hergerissen: Einerseits möchte man das Buch am liebsten in einem Satz durchlesen, andererseits macht es große Lust, die vorgestellten Tipps und Konzepte sofort auszuprobieren. „Leser“ und „Macher“ kommen also gleichermaßen auf ihre Kosten.

Was ich mir gewünscht hätte

Neben dem ingesamt sehr positiven Eindruck stören mich aber auch ein paar Kleinigkeiten an dem Buch. Das Lektorat war leider nicht immer so gründlich, wie man sich das wünschen würde: Wenn man auf Rechtschreibfehler wie „Mediac- lipping“ oder „Präsenz“ statt „Präsens“ stößt, dann ist das zumindest ärgerlich, manchmal sogar verwirrend. Und warum alle Überschriften substantivisch formuliert sind, das letzte Kapitel aber „Events – gar nicht old fashioned“, erschließt sich mir auch nicht. Ach ja, die Überschriften: Warum verspricht man im Titel des Buchs „9 Schritte“, wenn der Begriff „Schritt“ danach nicht mehr auftaucht (außer bei der PR-Strategie als „Step“, dann aber mit nur 4 Steps). Vielleicht deshalb, weil die neun Buchkapitel eben keine Schritte sind, die man der Reihe nach geht, sondern Themeneinheiten, die man je nach Interesse und Bedarf mehr oder weniger unabhängig voneinander lesen kann.

Auch bei der Auswahl der Inhalte hätte man sich an manchen Stellen beschränken können. Themen wie Suchmaschinenoptimierung oder Social Media sind immer ein wenig problematisch, wenn man sie in Buchform packt. In diesen Bereichen ändern sich Inhalte so schnell, dass sie oft schon veraltet sind, bis das Buch erscheint. Zum Beispiel hätte ich mir bei den Social-Media-Plattformen gewünscht, dass auch LinkedIn vorgestellt wird; mittlerweile ist es auch in Deutschland verbreiteter und international sowieso der Standard. Sinnvoller wäre es deshalb wohl gewesen, die Themenkomplexe kurz anzusprechen und auf ein, zwei gute Online-Quellen zur Eigenrecherche zu verweisen.

Alles in allem sind das aber Kleinigkeiten, die höchstens zu Abzügen in der B-Note führen. Eine Sache hätte ich mir aber wirklich gewünscht: Dass dieses Buch schon erschienen wäre, als ich anfing, mich mit PR zu beschäftigen. Dann hätte ich mir manch schmerzhaftes „Trial-and-Error“ erspart. Also: Für Quereinsteiger in die PR-Arbeit eine eindeutige Lese-Empfehlung!

Literatur: Marion Steinbach [2016]: „Crashkurs Public Relations. In 9 Schritten zum Kommunikationsprofi“. UVK Verlagsgesellschaft mbH, Konstanz und München. ISBN 978-3-86496-782-5

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als elektronisches Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

5 Tipps für strukturiertes Arbeiten mit OneNote

HinweisschildOneNote ist in vielen Redaktionen ein unverzichtbares Werkzeug für das Wissensmanagement. Gerade Einsteiger sind aber mit dem Funktionsumfang des Tools auch oft überfordert. Hier ein paar Tipps um strukturierte Wissensbestände aufzubauen.

1. Hierarchien nutzen

Wer OneNote bereits kennt, weiß, dass ein Notizbuch gezielt in Abschnitte, Seiten und Unterseiten eingeteilt werden kann. Durch diese Hierarchisierung wird Wissen direkt zueinander in Bezug gesetzt. Allein dadurch lässt sich schon ein hoher Grad an Struktur erreichen. Daneben bietet OneNote aber eine ganze Palette weiterer Strukturierungsmittel, Weiterlesen

Einfach das Chaos organisieren

Gerade eben habe ich wieder auf das rote X geklickt – und Microsoft OneNote geschlossen. Eine Software, die mich nun seit gut anderthalb Jahren täglich während der Arbeit begleitet. Und nicht nur mich: Auch in meinem Team ist OneNote zu einem Standard Weiterlesen

Leben und arbeiten

Rolf van Melis / pixelio.deIn den letzten Jahren hat ein Thema in der Personalentwicklung Konjunktur bekommen, das gerne mit dem neudeutschen Begriff „Work-Life-Balance“ umrissen wird. Bei doctima beschäftigen wir uns schon seit längerem mit der Frage, wie sich Beruf, Familie und persönliche Weiterentwicklung vereinbaren lassen. Dafür sind wir auch wiederholt ausgezeichnet worden, z. B. 2010 vom Bundesfamilienministerium (Video) oder vor einigen Tagen von der Metropolregion Nürnberg mit dieser schönen Urkunde.

10 Jahre Familienorientiertung

10 Jahre Familienorientiertung

Mehr als nur Worte

Aber so schön diese Anerkennung auch ist: Bloße Worte helfen bei diesem Thema niemandem. Und in der Praxis ist es oft nicht so leicht, den unterschiedlichen Bedürfnissen gerecht zu werden. Schnell sind z. B. in einem „familienorientierten“ Unternehmen die jüngeren Kollegen unzufrieden, wenn sie den Eindruck bekommen, dass sich alles nach den Bedürfnissen der Mitarbeiter mit Kindern richtet.

Damit kein Bereich zukurz kommt, unterscheiden wir deshalb drei unterschiedliche Aspekte bei der Work-Life-Balance. Weiterlesen