Ohne eine sinnvolle Analyse des Vorgehens, des Ablaufs, der Vorteile und der Nachteile und ohne eine breite Diskussion im Unternehmen brauche ich bei den anderen aber gar nicht erst aufzuschlagen. Und all das können weder Chat noch Microblog leisten.

Ich lege also eine Wiki-Seite im Intranet an. Nein, kein Word-Dokument und auch kein Google Doc, sondern eine Wiki-Seite, denn diese hält für unseren Anwendungsfall alle nötigen Werkzeuge bereit. 

In das neue Dokument zum Thema ISO-Zertifizierung stelle ich zunächst die folgende Infos ein:

1. Ziele und Vorteile des ISO-Projekts in unserem Unternehmen

2. Vorteile der Umsetzung

3. Nachteile und mögliche Risiken der Umsetzung

4. Projektteilnehmer

5. Interne und externe Kosten für die Umsetzung

Das ist natürlich noch nicht umfassend genug für eine Entscheidung. Aber es ist ein guter erster Schritt. Gucken Sie mal auf meinen Bildschirm rüber; so könnte das Ergebnis aussehen:

Beispiel einer Wiki-Seite ganz am Anfang. Siehe auch: https://seibert.biz/beispielwikiseite1 

Beispiel einer Wiki-Seite nach ein paar Iterationen. Siehe auch: https://seibert.biz/beispielwikiseite2 

Hier wird von der Art und Weise, wie wir uns einen digitalen Arbeitsplatz vorstellen, schon einiges deutlich. Wir und auch unsere Kunden teilen Zwischenstände früh. 

Als wir vor etlichen Jahren intern begonnen haben, mit einem Wiki zu arbeiten, sind oft Diskussionen wie diese entstanden: “Warum kommentierst und änderst du denn mein Dokument? Das ist doch noch ein Entwurf! Das ist doch noch gar nicht fertig! Irgendwie fühle ich mich von dir kritisiert, wenn du in meiner Arbeit rumpfuschst, obwohl ich eigentlich noch daran arbeite.”

Ja, es gibt in einem Wiki die Möglichkeit, mithilfe von Rechtebeschränkungen dafür zu sorgen, dass nur Sie selbst (oder nur das Intranet-Projektteam oder hier eben lediglich mein ISO-Zertifizierungs-Projektteam) eine Seite einsehen und bearbeiten können. Ich räume auch ein, dass es eines Gewöhnungsprozesses bedarf, um die Wiki-Nutzung intern wirklich richtig voranzubringen und dafür zu sorgen, dass sich alle mit dieser Arbeitsform anfreunden können.

Die jahrelange Erfahrung im Umgang mit Wikis hat bei uns mittlerweile dazu geführt, dass so ein Entwurf schon früh im System verfügbar gemacht wird. Natürlich bewerbe ich diesen Zwischenstand jetzt nicht im Chat oder per Micropost. Ich bin ja noch am Arbeiten. Aber trotzdem können andere Nutzer im System zum Beispiel über die Änderungsliste oder auch über Bereichsabonnements die neue Seite sehen.

So könnte etwa mein Kollege Karl den Wiki-Bereich “ISO-Zertifizierung”, den ich für diesen Zweck angelegt habe, komplett abonniert haben. Tun wir doch mal so, als wäre der Bereich wirklich nur für die fünfzehn Personen freigeschaltet, die auch tatsächlich in dem Projekt mitmachen werden. Wenn Sie an Ihr Unternehmen denken, finden Sie das vielleicht näher an Ihrer eigenen Wirklichkeit.

Karl sieht also meine neue Seite, weil Confluence (oder das Wiki-System Ihrer Wahl) ihn per Benachrichtigung darauf hingewiesen hat, dass es neue Inhalte gibt. Wir haben ja vorhin schon über das Thema Relevanz gesprochen – und dieser Aspekt ist hier wichtig: Da Karl sich für die ISO-Geschichte interessiert, nervt ihn diese zusätzliche Mail überhaupt nicht. Falls doch, würde er die Beobachtung einfach abstellen (siehe “Personalisierte Nachrichten”).

Schon in der Mail sieht er alle von mir erstellten Inhalte und denkt sich: “Sehr gut. Endlich fängt der oberflächliche Seibert an zu dokumentieren. Das wird das Projekt voranbringen. Aber mich hat er in der Liste mit den Projektteilnehmern mal wieder vergessen.”

Also ruft Karl die Seite auf, drückt auf “Bearbeiten” und fügt bei den Teilnehmern seinen Namen ein. So geht es auch noch Alisa und Benjamin, die ich beim initialen Aufsetzen der Seite vergessen habe. Benjamin hatte sogar schon mit einem befreundeten Unternehmen telefoniert und sich über die dortigen Erfahrungen mit der ISO-Zertifizierung ausgetauscht. Das Protokoll dieses Telefonats hat er in unserem Customer-Relationship-Managementsystem (CRM) dokumentiert. Er fügt einen Link zu dieser Dokumentation in das Konzeptionsdokument ein und ergänzt die Kostenerfahrungen seines Ansprechpartners mit einem kurzen Text.

Als eigentlichen Autor des Dokuments hat Confluence mich automatisch zu einem Beobachter der Seite gemacht, weshalb ich über die vorgenommenen Änderungen jeweils Benachrichtigungen erhalte. Als ich meine Mail-Benachrichtigungen sichtete, fiel es mir wie Schuppen von den Augen: “Natürlich! Daran hätte ich auch denken können.” Zum einen hatte Benjamin mir ja schon von seinem Telefonat erzählt. Und dass er, Karl und Alisa im Projektteam sein wollen, wusste ich eigentlich auch. Aber ich bin halt auch nur ein Mensch. Schön, dass die Ergänzungen über unser Wiki einfach und übersichtlich dargestellt werden. Die neu hinzugekommenen Inhalte sind grün hervorgehoben:

Siehe auch: https://seibert.biz/wikiaenderungsmail 

Was mir an der Sache am besten gefällt, ist, dass ich von unterwegs auf meinem Smartphone während einer unproduktiven Wartezeit schnell durch diese Benachrichtigungs-Mails springen kann und binnen weniger Sekunden etwas gelernt habe: Mein Protokoll und mein Konzept konnten schnell und einfach sinnvoll ergänzt werden. Benjamin, Alisa und Karl interessieren sich dafür und haben aktiv mitgeholfen, die Sache voranzubringen.

Das fühlt sich nicht nur gut an, es kurbelt auch das Projekt an. Und es gibt mir einen Anlass, die drei bei unserem nächsten Treffen auf dem Gang im Büro kurz anzusprechen und mich zu bedanken. Mit solchen persönlichen Interaktionen schließt sich ein sehr produktiver und sinnvoller Kreislauf aus digitaler Zusammenarbeit und persönlicher Abstimmung. Denn in den persönlichen Gesprächen kommen immer auch neue Ideen auf, die dann einer der Beteiligten wieder ins Wiki eintragen kann.

In Workshops, die wir halten, hat die Hälfte der Teilnehmer Fragezeichen im Gesicht, wenn wir erzählen, wie viele Leute über das Wiki an unseren Projekten mitarbeiten. Kann da wirklich jeder einfach so Änderungen vornehmen? Ist das nicht total unproduktiv, wenn man ständig den Quatsch und die Unwissenheit der Azubis und Neulinge ausbügeln muss? Muss ich dann die ganzen Wiki-Dokumente per Mail überwachen? Das ist ja der reine Benachrichtigungswahnsinn! Dann sieht ja am Ende gar keiner mehr, wessen Arbeitsergebnis das ist: Jeder rührt da mal darin rum, oder was?

Ich will nicht zu weit ausholen. Aber in der Tat: Diese Art der Zusammenarbeit ist für viele Menschen ungewöhnlich. Und klar, die Attribution von Ergebnissen und Erfolgen wird schwerer oder ganz unmöglich. Und nein, es kommt eigentlich nie zu Vandalismus oder versehentlich eingebauten Fehlern. Im Gegenteil: Die Mitarbeiter haben eher die Befürchtung, etwas Falsches beizutragen, und ändern lieber gar nichts, wenn sie sich nicht sicher sind. Immerhin wäre ein Fehler ja für viele Leute sichtbar.

Für mich ist das auch kein Benachrichtigungswahnsinn oder kein Beitrag zur E-Mail-Flut, sondern produktive Arbeit, die mir richtig Spaß macht. Wenn ich zum Beispiel dabei bin, die ISO-Sache voranzubringen, stört es mich keineswegs, wenn ich dazu eine Aktualisierungs-Mail erhalte. Das interessiert mich sogar brennend! Ich empfinde das Durchsehen von Confluence- und Jira-Benachrichtigungen als recht angenehm und nutze diese Arbeit oft als eine Art Entspannungsmaßnahme während des Arbeitstages. Die Benachrichtigungen sind in 80 Prozent der Fälle einfach und schnell zu konsumieren. Ich muss nichts tun und sehe, wie es vorangeht. Das fühlt sich gut an und ich habe das Gefühl, etwas Sinnvolles gemacht zu haben, wenn ich die Mail nach wenigen Sekunden dann einfach archiviere.

Unser Wiki-Dokument zur ISO-Zertifizierung plätschert in den nächsten Tagen nun so vor sich hin: hier und da eine Änderung, hier und da eine Benachrichtung für diejenigen, die die Seite beobachten.

Hier gilt der Grundsatz: Wer schreibt, der bleibt. Das ist genau so wie in einem Google Doc oder einem Word-Dokument in Microsoft Office 365: Es sind in der Regel einige wenige, die Entscheidendes beitragen und die Sache maßgeblich vorantreiben. Zum Beispiel weil sie besonders viel Energie haben. Oder weil sie betroffen sind. Manchmal auch einfach, weil sie glauben, mächtig genug zu sein, um eine Entscheidung herbeizuführen. 

Wir steuern nicht, wer die Themen bei uns voranbringt und wer nicht. Für uns reicht es aus, wenn wir auf Unternehmensebene gemeinsam über die Prioritäten sprechen.

In unserem Fall hat Benjamin besonders viel Energie für die ISO-27001-Zertifizierung und arbeitet viel an dem Dokument. Das Besondere an einem Wiki ist, dass durch die kontextuellen Benachrichtigungen immer diejenigen involviert werden, die tatsächlich auch an dem Thema oder ganz konkret an der speziellen Seite interessiert sind. Jede Änderung ist damit eine Erinnerung an die anderen, dass das Thema existiert und dass sich gerade etwas tut. 

Jede Aktivität führt wiederum zu Aktivität und Aufmerksamkeit bei den anderen Beteiligten. Aktivität induziert Aktivität. Dadurch entsteht ein sich selbst verstärkender Kreislauf. 

Dieses Gefühl der Zusammenarbeit an einer Sache kommt dagegen bei der Nutzung von Google Docs und Word 365 in den meisten Fällen nicht auf.

Vermutlich müsste ich das noch etwas differenzieren. Diese Werkzeuge sind wirklich toll bei der Zusammenarbeit in Echtzeit. Die kann man auch ganz großartig präsentieren. Wir wählen uns alle über die Weboberfläche in das gleiche Dokument ein und arbeiten alle gleichzeitig daran. Kombiniert mit einer Videokonferenzschaltung entsteht so auch eine wirklich produktive Zusammenarbeitssituation für Menschen, die an unterschiedlichen Standorten sind.