Alltag in einem mittelständischem Unternehmen. Im Vorbeigehen bekommt der ohnehin schon hart im Crunch1 arbeitende Entwickler den Hinweis: “Machst Du bitte für dieses Projekt in der Übersicht aller Kunden auch noch die offenen Rechnungen sichtbar?” Er kann nur pflichtbewusst nicken, weiß er doch, dass es sich um ein wichtiges Projekt handelt, die Aufgabe keine technische Herausforderung ist und der Chef immer schnelle und unkomplizierte Lösungen mag.
Also irgendwie “zwischendrin” am späten Nachmittag die UI “aufbohren”, zusätzliche Abfragen im Frontend “packen”, die entsprechende Logik im Backend “anpassen”, mit den ermittelten Ergebnissen neue Listen in Views “zimmern”. Die extra Meile geht er mit dem Anklickbar machen und Öffnen der Rechnungen. Zufrieden lehnt der Entwickler sich kurz vor Mitternacht mit dem guten Gefühl zurück, die Anwendung weiter gebracht zu haben.
Am Morgen folgt der Knall. Die Änderungen sind mit niemandem abgestimmt. Ursprünglich gemeint war nur eine zusätzliche Spalte mit Summenübersicht. Keine zusätzlichen Listen, keine Dialoge, und schon gar keine anklickbaren Belege. Frust macht sich breit. Schadensbegrenzung für das ganze Team steht an, nicht nur für den Entwickler. Das zeitkritische Projekt ist um Tage zurückgeworfen obwohl niemand etwas falsch verstanden oder in schlechter Absicht gehandelt hat.
Nur ein fiktives Beispiel, das aber jedem sehr vertraut vorkommen dürfte. Es ist unerheblich, ob das jetzt einen Entwickler, Admin oder Projektmanager betrifft. Spontane, mündliche Kommunikation “zwischen Tür und Angel” ist immer so verlockend einfach und unkompliziert. Jeder ist instant zufrieden. Die Arbeit ist delegiert, vermeintlich schnell verstanden und gelöst. Eine langfristige und vor allem verbindliche Arbeitsgrundlage hinterlässt man so aber nicht. Und je mehr Menschen in einem Projekt involviert sind, desto mehr beginnen die Dinge Ihre eigenen Wege zu gehen. Das gilt ganz besonders in der Kommunikation mit Externen oder Nicht-Technikern, wo Begrifflichkeiten unterschiedlich interpretiert werden. Mir ist zum Beispiel in einem fortgeschrittenen ERP-Projekt jemand aufgefallen, der die ganze Zeit von Diensten sprach, technisch jedoch eigentlich Stored Procedures2 meinte. Ein Unterschied mit weitreichenden Folgen im Operations.
Was nicht geschrieben ist, existiert nicht.
Eine Abwandlung des Rechtsgrundsatzes: Quod non est in actis, non est in mundo.3 Schriftliche Präzision in der Beschreibung eines Arbeitspaketes, Tickets oder Gesprächsprotokolls verhindert Mißverständnisse. Jede Verschriftlichung, auch wenn sie einem noch so unnötig erscheint, gibt Referenz, Klarheit und die notwendige Verbindlichkeit. Oder wer weiß heute, was er zu einem persönlich weniger wichtigen Sachverhalt vor 6 Monaten, noch sagte, was jetzt eskaliert wurde?
Kontext und asynchrone Kommunikation sind wichtig
Doch Verschriftlichung allein reicht nicht. Sie muss sinnvoll strukturiert und auffindbar sein. So kann aus individuellem Erinnerungsvermögen etwas wie ein kollektives Gedächtnis in einem Unternehmen reifen.
Was ist kontextualisierte Information? Ich beginne damit, was keinen Kontext hat: Das sind Chats in Teams & Co, lose Dateien in einem SMB-Share oder Sharepoint. Verkettete Email-Threads, die für Außenstehende kaum durchdringbar sind.
Kontext hingegen haben Tickets mit einem Bezug zum Anwender, Bearbeiter und idealerweise einem Asset. Aufgaben in einem Projekt mit einem vorhergehenden oder abgeleiteten Arbeitspaket haben Kontext. Ein leicht durchsuchbarer Wiki-Artikel mit entsprechenden Tags hat einen Kontext. Alles idealerweise in einer Projektmanagement-Software, einem Ticketsystem oder Wiki.4
Kommunikation hat immer asynchron5 und strukturiert mit einem klaren Kontext zu erfolgen, damit diese unabhängig von Ort und Zeit für jeden im Zugriff bleibt. Das bedeutet Digitalisierung.
Keine Digitalisierung ohne Verschriftlichung
Beinahe zum Abfallprodukt wird die Transparenz und Nachvollziehbarkeit von Entscheidungen. Geräte, Anwender, Vorfälle bekommen einen Lebenslauf. Prozesse lassen sich qualitativ messen und verbessern. Niemand kann in einem Meeting plötzlich mit den typischen, existentiellen Fragen ankommen, warum etwas genau so umgesetzt ist und nicht anders? Meiner Erfahrung nach kommen solche Fragen meist kurz vor einem Projektende und haben das Potential, dass einem alles an genau dieser Stelle entgleitet.
Digitalisierungsprojekte scheitern aus vielen Gründen. Einer der häufigsten ist die fehlende Verschriftlichung in Kombination mit unklarer Kommunikations- und Dokumentenlenkung.6 Interessanterweise oftmals dort anzutreffen, wo man sich gerne modern und “durchdigitalisiert” zeigt, viel in Chats und Videokonferenzen sitzt und am Ende nur wertvolle Zeit vergeudet.
Ich verweise in diesem Zusammenhang gerne auf den FrOSCon-Vortrag von Florian Haas aus dem Jahr 2020: “No, we won’t have a video call for that!”7
In diesem Sinne,
Tomas Jakobs