07. November 2012

Uwe Matrisch: Agiles Publizieren mit höherer Schlagzahl statt neuer Schlagwörter


Welcher Verlag weiß genau, was in der derzeitigen und zukünftigen Medienwelt das richtige Geschäftsmodell für ihn ist? Wie findet man die Antworten und welche Halbwertszeit haben diese? Agiles Publizieren kann eine Antwort auf diese Fragen sein, ohne diese eindeutig zu beantworten.

Der Ansatz des agilen Publizierens basiert auf dem Konzept der “agilen Softwareentwicklung” und akzeptiert, dass wir ständig lernen und nie vollständig wissen. Da der Ansatz des agilen Publizierens durchaus auf dem Ansatz der agilen Softwareentwicklung beruht, lässt sich dies auch gut mit der Definition der agilen Softwareentwicklung illustrieren: “Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen”.(1)

In einem Webcast der Book Industry Study Group (BISG)(2) werden Grundzüge des agilen Publizierens beschrieben. Dabei wird vorausgestellt, dass agiles Publizieren auf dem direkten Kontakt mit dem Nutzer bzw. Kunden basiert und es in erster Linie auf Geschwindigkeit ankommt. Da wir nicht sofort wissen, was die richtige Antwort auf eine Vielzahl sehr individueller Kundenbedürfnisse ist, müssen wir schnell viele Antworten geben, Feedbacks des Marktes einfordern, einsammeln und bewerten, und dann auf diese mit weiteren Antworten, also Produkten, reagieren. Agiles Publizieren ist also ein ständiges Experiment, ein ständiger Dialog, eine beständige Veränderung in einer sich beständig ändernden Welt.

Im Folgenden habe ich ein paar Gedanken darüber niedergeschrieben, was es braucht, um in einem Verlag agil handeln zu können. Ich hoffe, dass einige Antworten überraschen.

Verlagsstrategie

Bei Softwareprojekten, die nach den Prinzipien der agilen Softwareentwicklung (3) betrieben werden, habe ich beobachtet, dass es einen grundlegenden Rahmen geben muss, da sonst die Ziele der am Projekt Beteiligten die Ziele des Projektes gefährden können. Es muss also einen grundlegenden Konsens, eine Art Spielfeld geben, auf dem sich alle in ihren (veränderbaren) Rollen entsprechend bewegen dürfen.

In einem Verlag macht es Sinn, dies in einer Verlagsstrategie festzulegen. Aus dieser gehen die Konstanten hervor (z. B. die Festlegung auf eine bestimmte Zielgruppe oder die Festlegung auf bestimmte Produkte) und damit auch die Variablen. Bei der Festlegung auf eine Zielgruppe können die Variablen z. B. Produkte, Preise, Service-Intervalle und viele andere Parameter sein.

Kontakt zu Kunden, Nähe zum Markt

Alle, aber auch wirklich alle am Publikationsprozess beteiligten Personen müssen Kontakt zum Markt haben. Zu bevorzugen ist dabei der direkte Kontakt bei Messen, in sozialen Netzwerken, durch die Betreuung von Kundenhotlines o. Ä. Die eigene Nutzung der eigenen Produkte und die grundlegende Beschäftigung mit Konkurrenzprodukten sollte für alle am Publikationsprozess Beteiligten selbstverständlich sein.

Feedback vom Markt muss systematisch ausgewertet werden. Die Ergebnisse fließen in die Weiterentwicklung der Produkte ein und sind deren wichtigster Gradmesser. Idealer Weise sind Produkte so konzipiert, dass Sie Rückkanäle anbieten, die den Kunden einen Mehrwert bieten.

Leichter Zugang zu Inhalten

Um experimentieren zu können, muss man etwas zum Experimentieren haben. Verlagsprodukte bestehen aus Inhalten. Um schnell neue Produkte erstellen zu können, muss man schnellen Zugang zu Inhalten haben. Hier denken viele nicht zu Unrecht an Content Management Systeme. Dort, wo es diese nicht gibt, ist eine Einführung meist langwierig und teuer. Und dort, wo es diese gibt, stößt man, wenn man schnell und agil publizieren will, oft an deren Grenzen.

Bei der Verwaltung und Archivierung von Inhalten gilt dabei ein Leitspruch des agilen Publizierens: Keep it simple. Wichtig sind die Strukturen der Inhalte und nicht die Tools. Das heißt, dass gut strukturierte und in weiten Teilen homogene und gut archivierte Word-Daten, die schnell vorliegen, wertvoller sein können als eine XML-Datenbank, die man erst in 14 Monaten hat.

Content Management sollte für die Nutzung im agilen Prozess modular aufgebaut sein. Die Komponenten sollten weit verbreiteten, möglichst offenen Standards folgen. Bei der schnellen Anpassung der Module sollte man nur bedingt auf Dienstleister angewiesen sein bzw. die Beziehungen zu diesen sehr gut pflegen. Know-how in diesem Bereich gehört, wenn man agil publizieren will, zu den Kernkompetenzen im Verlag. Die IT-Abteilung verliert dabei völlig ihre administrative Rolle und wird Teil der Kernteams um den Publikationsprozess.

Der Zugang zu Inhalten ist in vielen Verlagen leider noch ein Problem. Mitarbeiter von Buchverlagen, die schnell auf den Markt reagieren und ihre Backlist in E-Books wandeln wollen, werden hier wahrscheinlich zustimmend nicken.

Für Experimente beim agilen Publizieren könnte daher die zweite Kernkompetenz von Verlagen neben ihren bestehenden Inhalten sehr wichtig werden. Dies ist die Beziehung zu Inhalteerstellern, also Autoren, Übersetzern, Grafikern, etc. Vielleicht ist hier ein effizientes Author Management System (AMS) wichtiger als ein gutes Content Management System. Bei AMS bitte hier nicht gleich an ein weiteres großes IT-Projekt denken. Hier geht es um die Interaktion zwischen Inhalteerstellern und Verlag und um Verbesserungen in der Kommunikation, die Inhalte ggf. markt- und mediengerechter werden lassen. Inhalteersteller können je nach Verlagsstrategie also ein wichtiger Teil des agilen Publikationsprozesses sein. Sie sollten entsprechend eingebunden werden.

Klare Rechtelage

Ein guter Zugang zu den Inhalten ist nichts wert, wenn die Rechte für die Inhalte nicht klar geklärt und schnell einsichtig sind. Diese Informationen gehören in die Metadaten des Content. Auch hier kann sich der zweite Ansatz, auf neue Inhalte zu setzen und damit auf die Verbesserung der Kooperation mit Inhalteerstellern, auszahlen.

Flexible Strukturen, flache Hierarchien

Agiles Publizieren in starren Abteilungsstrukturen funktioniert nicht. Es geht immer darum, dass sich jeder kreativ beteiligt und seine Rolle im Team und im Prozess entsprechend seiner Fähigkeiten und Talente findet. Es gibt also Rollen, doch auch diese können sich im Laufe der Zeit ändern. Wichtig sind heterogen zusammengesetzte Teams, die sich für jedes Projekt immer wieder neu finden. Um dies zu unterstützen, empfiehlt sich z.B. eine Clean-Desk-Politik, bei der sich Mitarbeiter dann stunden-, tage- oder wochenweise in Arbeitsplatzgruppen zusammenfinden. Weiterhin sind Arbeitsräume nötig, die gleichzeitig Rückzugs- und Kommunikationsort sind. In einer agil agierenden Organisation geht es nicht in erster Linie um Struktur, sondern um Austausch. Es geht darum, dass sich Mitarbeiter untereinander vernetzen. Bei relativ kleinen Organisationen kann es ausreichen, dies durch eine entsprechende Gestaltung der Arbeitsplätze zu befördern. Bei größeren Strukturen können Events, aber auch firmeninterne soziale Netzwerke helfen.

Agiles Handeln setzt kurze Entscheidungswege voraus. Ohne diese verspielt man jeden zeitlichen Gewinn, der bei der Neueroberung digitaler Märkte zentral ist. Ich habe tatsächlich gute Erfahrungen mit der Regel gemacht, dass, wenn es innerhalb von 24 h keine Antwort auf ein geschildertes Projektvorhaben gibt, dieses als genehmigt gilt. Solche Regeln führen zu schnellen Kommunikationen über ein Projekt. Und Kommunikation ist der Schlüssel zur Verbesserung.

Unternehmenskultur: Mut zu Fehlern, Spaß am Job

Ich habe es schon mehrfach geäußert: Agiles Publizieren ist experimentieren. Der Sinn dessen ist, dass Ergebnisse nicht vorhersagbar sind, diese aber zu besseren Ergebnissen beim nächsten Versuch führen. In einem Beitrag zum agilen Publizieren in der Publishing Weekly stand: “It’s for learners, not knowers.”(4) Agiles Publizieren setzt also Fehler voraus. Angst vor Fehlern macht agiles Handeln unmöglich. Für den Umgang mit den Fehlern sollte es aber Regeln geben. Fehler sollten offen kommuniziert und diskutiert werden, damit der Lerneffekt schnell die Breite der Organisation erfasst.

Agiles Handeln im Verlag setzt bei allen Beteiligten eine große Fähigkeit zur Selbstmotivation voraus. Das heißt, dass wir aus Fehlern viel lernen, aber Erfolge groß feiern (müssen).

Agiles Publizieren und feste Strukturen – eine Herausforderung

Kann agiles Publizieren ein Dauerzustand in einem Verlag sein? Natürlich kann es, in einer hier zum Teil geschilderten extremen Form halte ich es aber nur für bedingt wahrscheinlich. Ziel wird wahrscheinlich oft sein, Gelerntes zu verstetigen und Erfolge in skalierbare Prozesse umzuwandeln. Bei der Erarbeitung der Strukturen und Prozesse, die diese Verstetigung tragen, können sicher auch agile Grundsätze eine Rolle spielen, bei deren Umsetzung aber weniger. Die Trennung und/oder Vermischung von agilen und streng hierarchischen und prozessualen Strukturen ist dann eine weitere Herausforderung, mit der wir uns noch zu beschäftigen haben.

Uwe Matrisch ist Herstellungsleiter / Head of Production Editing bei der le-tex publishing services GmbH.

Der Artikel ist zuerst im Newsletter von Heinold, Spiller & Partner Unternehmensberatung GmbH erschienen, hier der Link zum Archiv. Danke für die Genehmigung zur Zweitveröffentlichung.

  • Matthias Guenther

    Agiles Publishing muss ja nicht unbedingt die Art des Schreibens wie im Webcast vorgeschlagen nutzen. Die Vorgehensweise aus der agilen Softwareentwicklung lässt sich gut auf Publishingprozesse übertragen und gibt Werbeagenturen, Buchverlagen, Magazinverlagen etc. Werkzeuge an die Hand, agiler auf den Markt zu reagieren.
    Wir haben das mal versucht aufzuschreiben: http://www.agile-publishing.de/go-book
    Ich hoffe, das wirkt nicht als reiner Werbelink, wir haben uns 9 Monate intensive Gedanken zu dem Thema gemacht.