Das Teamwork-Blog

Eine gemeinsame Ablage kann viel Stress aus der täglichen Projektarbeit nehmen. Aber irgendwie ist nie Zeit zum Umziehen der Dokumente von der alten Struktur in die neue gemeinsame Ablage. Hier eine Kurzanleitung, wie es trotzdem schnell gehen kann.

Es gibt zunehmend Unternehmen und öffentliche Einrichtungen, die Dokumentenmanagementsysteme einführen. Die "DMS" sind längst aus ihrem Namen herausgewachsen - die guten Produkte unter ihnen "managen" nicht nur Dokumente, sondern Unternehmensinformationen aller Art. Und vor allem strukturieren sie sie so, dass sie auch die Vielzahl von Prozessen, Kontakten, Vorgängen, Notizen überschaubar halten. Es gab Vorschläge, die Bezeichnungen entsprechend zu ändern - ECM ("Enterprise Content Management") oder EIM ("Enterprise Information Management"). Aber keine hat sich so richtig durchgesetzt. Bleiben wir also bei DMS. Tendenziell ersetzt ein DMS Windows als allgegenwärtige Arbeitsoberfläche (oder besser: Arbeitsuntergrund). Bei der Einführung von DMS spielen aber falsche Erwartungen der Entscheidungsträger eine große Rolle. Es werden große Hoffnungen gesetzt in Features, über die DMS nicht verfügen. Und auf der anderen Seite werden Dinge, die uns das Le...

Manche Projekte klappen einigermaßen gut, andere ziehen sich wie Kaugummi und man hat ständig das Gefühl: „Bald versandet’s.“ Wo liegt der Unterschied? Auf die Frage gibt es wahrscheinlich nicht nur eine Antwort. Aber zumindest einem Faktor kommen wir auf die Spur, wenn wir fragen: „Wer macht’s?“

Der Begriff des „Workflows“ wird in ERP- und DMS-Projekten gerne verwandt, um die Vorteile eines reibungslosen Arbeitens im Team an die Wand der Zukunft zu projizieren. Damit parallel geht die Vorstellung, Büroprozesse und Wissensarbeit ließen sich in ihrer Gänze mit ähnlichen Methoden effizienter gestalten, wie sie aus der Güterproduktion bekannt sind: quasi wie am Fließband. Aber diese Versprechen können in der Realität (fast) nie eingelöst werden.

Die IT und hier wiederum der Bereich der Entwicklung ist zur ständigen Quelle neuer Ideen und neuer Rollenmuster geworden. Hier wurden zuerst die agilen Methoden wie Scrum, Kanban entworfen, erprobt, verbreitet. Kein Grund, diese Methoden hier einzusperren. Die Übertragung auf andere Bereiche bis hin zur Agilisierung ganzer Unternehmen ist eine spannende Vision. Das Wort „Übertragung“ aber trifft es nicht ganz: einige Konzepte zum Beispiel von Scrum müssen dabei sorgfältig angepasst werden.

Damit ist gemeint: Jedes IT-Projekt muss einen Wert liefern, aus dem heraus es sich rechtfertigt. Aber was verstehen wir unter dem Begriff „Wert“? Und kann man diesen Wert immer messen? Vorgestern bin ich dieser Frage anhand von X-Unternehmen nachgegangen – also traditionellen, gewinnorientierten Unternehmen. Heute will ich auf Y-Unternehmen eingehen. Dabei stoßen wir auf die Frage, ob es sich beim „Wert“ immer um Geld handeln muss.

„IT-Projekte werden nicht genehmigt, sondern finanziert“, ist eine unserer Kernaussagen. Im Teamworkblog haben wir schon öfter darüber geschrieben. /1/ Damit ist gemeint: Jedes IT-Projekt muss einen Wert liefern, aus dem heraus es sich rechtfertigt. Aber was verstehen wir unter dem Begriff „Wert“? Handelt es sich immer um Geld, oder kann es auch etwas anderes sein? Und kann man Wert immer messen?

„Schluss mit dem vielen theoretischen Schwätzen! Jetzt die Ärmel hockrempeln und loslegen!“, ist das Motto mancher Projektverantwortlicher zu Projektbeginn. Nichts macht Projekte so langsam wie diese Parole. Will man Projekte beschleunigen, muss man am Anfang lang genug an der Begriffsklärung arbeiten. Der Aufwand wird später im Projektverlauf um ein Vielfaches zurückerstattet.

„Schluss mit dem vielen theoretischen Schwätzen! Jetzt die Ärmel hochkrempeln und loslegen!“, ist das Motto mancher Projektverantwortlicher zu Projektbeginn. Nichts macht Projekte so langsam wie diese Parole. Will man Projekte beschleunigen, muss man am Anfang lang genug an der Begriffsklärung arbeiten. Der Aufwand wird später im Projektverlauf um ein Vielfaches zurückerstattet.

In agilen Projekten wird iterativ gearbeitet. Alle Anforderungen stehen in einem Product Backlog, werden priorisiert und in den einzelnen Sprints schrittweise umgesetzt. Dabei wird bereits geschäftlicher Nutzen erzeugt und die jeweils neu erzeugten Funktionsbausteine soweit irgend möglich schon in den Echtbetrieb genommen.  Aber kann dabei nicht auch großer Murks erzeugt werden? Kann es nicht vorkommen, dass man nach dem 25. Sprint feststellt, dass man sich in eine Sackgasse entwickelt hat? Können sich die neuen Anforderungen Nummer 94 und 95 nicht mit  den schon realisierten Funktionalitäten 1 bis 93 widersprechen? Wie sichert man eine konsistente Gesamtlogik des Projekts über all seine Sprints hinweg?  Eine Antwort darauf heißt „Domänenmodell“.

Am 8. Juli 2015 findet in München eine Werkstatt zu diesem Thema statt. Sie wird von Wolf Steinbrecher und Peter Fischbach (beide Teamworkblog und Common Sense Team) moderiert.  Ziel ist es, mit "Promotern des Wandels", die in ihren Organisationen oft auf Mauern stoßen, in einen Dialog zu treten und sie mit Kenntnissen zu unterstützen. Auch Beraterkollegen sind herzlich willkommen.

In meinem Post am Montag habe ich ein Beispiel gebracht, wie eine Abteilung eine Projektvision mit Hilfe von Appreciative Inquiry entwickelt. Heute möchte ich diese Erfahrung auswerten: Was unterscheidet Appreciative Inquiry von herkömmlichen Methoden der Organisationsentwicklung?

Das Formulieren einer Vision für ein komplexes, langwieriges Projekt ist nicht einfach. Eine gut strukturierte Methode, die außerdem noch einen Wohlfühlgewinn abwirft, wird von Appreciative Inquiry vorgeschlagen.

Das Thema Dokumentenmanagement wirkt ein wenig angestaubt. Wer ein System sucht, um Dokumente im Unternehmen zu speichern, findet ein umfangreiches Angebot an Softwareprodukten. Dabei geht es aber gar nicht um Software, sondern um Prozesse. Wer seinen Umgang mit Dokumenten wirklich verbessern will, muss die Abläufe im Unternehmen verstehen. Das ist gar nicht so schwer.

Wir Menschen tun uns schwer mit strategischen Entscheidungen, vor allem in Gruppen. Also suchen wir uns Sündenböcke, die uns die lästige Arbeit abnehmen und die Entscheidungen für uns treffen. Diesen Sündenböcken geben wir listig einen anerkennenden Namen: „Führungskräfte“. Und immer, wenn sie etwas getan haben, was ihrer Funktion entspricht: nämlich etwas entschieden, kritisieren wir sie dafür heftig. Sie entscheiden nämlich immer alles falsch.

Bevor ein Team seine Ablage neu strukturiert oder gar die IT eine DMS-Software beschafft, sollte man sich Gedanken darüber machen, was "gute Ablage" überhaupt bedeutet. Dazu hier noch ein paar weitere Tipps.

Nicht eine neue Software hilft uns, unsere Probleme zu lösen. Sondern sie hilft uns höchstens, unsere Probleme selbst zu lösen, indem sie uns dabei unterstützt. Das gilt auch für das unbeliebte Thema Ablage. Hier ist die Versuchung besonders groß, sich eine Software zu beschaffen, statt sich selbst Gedanken zu machen. Klappt aber nicht. Vielmehr muss ein Team sich selbst auf Standards und Ziele einigen, was "gute Ablage" überhaupt bedeutet.

Der Titel dieses Blogposts zeigt: Teamworkblog ist mutig, es schwimmt gegen den Strom und scheut keinen Schmerz. Denn das Thema Ablage ist nicht wirklich der Teamfavorit. Die Zugriffszahlen auf diesen Artikel werden wieder einmal bodenlos niedrig sein und selbst von so langweiligen Themen wie Scrum haushoch überholt. Trotzdem ruft Teamworkblog die Wahrheit in das leere Universum: „Wer die Energie aufbringt, mal ein bisschen über die Teamablage nachzudenken, kann aus einer chaotischen Dokumentenhalde eine tolle Collaboration platform machen.“

Als Berater für Dokumentenmanagement werden wir oft gefragt, ob ein Team SharePoint für die Ablage der Dokumente nutzen solle. Ich habe da eine ganz klare Antwort: Jein.

Nur wenige Projekte zur Einführung von Dokumentenmanagement-Systemen bringen ihren Kunden den Nutzen, den diese sich davon erhoffen. Im vierten Teil unserer Serie beschäftigen wir uns mit der Unterstützung von Wissensprozessen durch ein DMS. Dabei orientieren wir uns an den Anforderungen, die ein Adaptive Case Management an die gemeinsame Dokumentenplattform eines Projektteams stellt.