Mein Blog-Kollege Jan Poczynek hat eine interessante Präsentation zum Management des Projektmanagements erstellt. Er beschäftigt sich mit dem Spannungsfeld, das Projekte innerhalb von Stammorganisationen erzeugen und welche Maßnahmen ergriffen werden können die Integration zu verbessern.
Aber seht selbst:
Einen Vertiefung ist mit dem ausführlichen Artikel möglich.
Wir sind derzeit dabei ein Wiki für einen bestimmten Teilbereich neu einzuführen. Dieser Bereich hat sich bisher vor dieser Technologie verschlossen und möchte das nun ändern. Bei der Präsentation stellten die Stakeholder natürlich die Frage, wie wir die Qualität der Wiki-Inhalte sicherstellen.
Im Vergleich zu Wikipedia, wo mehrere 100 Autoren die Beiträge prüfen, ist ein Firmenwiki auf sich alleine gestellt. Sofern ein Wiki überhaupt eine Qualitätssicherung benötigt, sollte man sich vielleicht nochmal vor Augen führen was zu Qualität führt:
Unter Beachtung dieser Punkte können auch in einem vermeintlich unstrukturierten Wiki Beiträge hoher Qualität erzeugt werden. Ideen für die Umsetzung dieser Punkte möchte ich in diesem Beitrag anregen.
Punkt 1: Strukturiertes Vorgehen
Es muss zu Beginn klar sein was in das Wiki gestellt wird. Es muss ein Zielbild entwickelt, Kategorien geschaffen, Namensräume und klare Rollendefinitionen vergeben werden. Dies zielt auf die Planung vor Einführung eines Wikis ab. So können beispielsweise Mitarbeiter die Rolle des “Wiki Gärtners” übernehmen, der die Beiträge kontrolliert. Dabei sollte sich die Kontrolle auf folgende Bereiche konzentrieren:
Es ist also ein manueller Aufwand erforderlich, um die Qualität des Systems zu gewährleisten.
Punkt 2: Einsatz von Hilfsmitteln / Werkzeugen
Es ist inzwischen unbestritten, dass der richtige Einsatz von Werkzeugen die Qualität eines Systems erhöht. So bleibt bei einem Wiki die Frage wie ein “Wiki Gärtner” über neu zu prüfende Beiträge informiert wird. Hier scheiden sich die Geister ob ein Push- oder Pull-Mechanismus die richtige Wahl ist. So kann der Wiki-Gärtner über alle neuen Einträge informiert werden, oder der Autor eines jeweiligen Beitrags einen Benachrichtigungs-Button aktivieren. So kann durch einen Workflow versucht werden, eine Bewertung der Beiträge zu organisieren. Vielleicht reicht es einfach, wenn der Wiki-Gärtner sich über bestimmte Suchkriterien einen RSS-Feed abonniert, um auf die neuen Beiträge aufmerksam zu werden.
Punkt 3: Ausbildung
Die Mitarbeiter, die ein das Wiki nutzen sollen, müssen über die notwendigen Fähigkeiten verfügen dieses zu tun. Viele werden da sagen, dass das selbstverständlich ist, in der Praxis wird dieser Faktor leider häufig unterschätzt. Es sollte also vorab klar sein, was in das Wiki eingestellt werden soll. Es muss transparent sein, was ein Howto ist, ein Artikel, eine Notiz etc. Ebenso sollte die Meta-Syntax des Wiki-Systems klar und eine Hilfe zur Benutzung verfügbar sein. Denn mangelnde Ausbildung des Personals kann gleichzeitig auch das Scheitern des Wiki-Projekts zur Folge haben. Nämlich genau dann, wenn die beteiligten Personen das Wiki boykottieren und immer noch die Dokumente per Email versenden, die eigentlich in das Wiki gehören.
Fazit:
Die Bedenken bei einer Wiki-Einführung, die oft vom Management eingebracht werden, können durch eine gute Planung ausgeräumt werden. Die Qualität eines Wikis steht insgesamt mit der Art und Weise, wie das Projekt Enterprise 2.0 angegangen wird. Leider werden die Ziele häufig zu hoch angesetzt und die Erwartungen nicht erfüllt. Das Wiki ist auch nur ein Werkzeug, und bildet mit vielen anderen Arbeitsmethoden und Hilfsmitteln einen Weg zum Enterprise 2.0.
Nach all den Jahren bin ich nun fertig mit meinem Studium. Hier meine Präsentation, die ich zu meinem Kolloquium erstellt habe. Mir ist natürlich klar, dass die Tonspur fehlt und daher der Zusammenhang nicht wirklich klar wird - dennoch finde ich sie sehenswert (auch auf die Gefahr hin, dass Eigenlob stinkt) 
Die Message, die ich rüber bringen möchte:
“Mashups haben deutliches Potential, um in Integrationsprojekten einen schnelleren Zugang zu Informationen zu liefern. Sie können bestehende Anwendungen aufwerten, verschaffen den Benutzern die benötigten Informationen und können insgesamt zu kürzeren Entwicklungszeiten führen, sofern sie die vorhandenen Hürden überwinden.”
Im aktuellen Linux Magazin habe ich einen interessanten Artikel zum Thema agile Methoden in der Systemadministration gefunden. In der Softwareentwicklung ist der agile Gedanke zunehmend verbreitet. In dem Tagesgeschäft eines IT-Administrators wird agilen Ansätzen derzeit wenig Beachtung geschenkt.
Marcel Wegermann beschreibt in dem Artikel wie sich die agilen Praktiken auf die Arbeit eines Administrators übertragen lassen. Durch Anpassen der Regeln lässt sich so eine ASA (Agile Systemadministration) auf die Beine stellen. So werden in diesem Artikel Zehn agile Regeln für die Systemadministration aufgestellt, die sich an XP Grundpraktiken orientieren:
Mein Fazit:
Für mich der erste Beitrag zum Thema ASA. Als großer Anhänger der agilen Methoden sind für mich die Punkte eins bis acht lohnend und sicherlich in den meisten Rechenzentren anwendbar. Eine Nagios-Installation leistet bereits in vielen Unternehmen seine Dienste und kann für die gesamte Testautomatisierung herangezogen werden. Allerdings ist es dann umso wichtiger qualifizierte Kommentare in der Konfiguration zu finden.
Punkt zwei und acht sehe ich als besonders effektiv an. Denn hier steht nicht nur der agile Gedanke im Vordergrund, sondern das Vorhandene Wissen wird auf mehrere Köpfe verteilt. Damit kann dem Problem mangelnder Vertretungen entgegen gewirkt und die Abhängigkeit von Einzelpersonen aufgelöst werden.
Aber nicht alle Ansätze lassen sich so einfach umsetzen. Insbesondere den Punkt neun sehe ich als kritisch an, denn in Zeiten von Outsourcing und Service-Rechenzentren ist die örtliche Nähe zum Kunden nicht immer möglich.
Der Einsatz von Whiteboards, Pinnwänden oder Flipcharts im Administrationsbereich kann zur Sprintplanung genutzt werden oder die Teambesprechungen unterstützen. Wie Teamräume aussehen können ist hier zu sehen. Ein Ticket-Trouble-System wie OTRS kann die auftretenden Störungen kanalisieren und ist zudem revisionssicher. Darüberhinaus ist für die Projekte ein Wiki das Tool der Wahl und zur Kommunikation mit der „Außenwelt“ kann ein Blog sehr hilfreich sein. So könnten dort aktuelle Störungen oder Planungen von Downtimes kommuniziert werden.
Insgesamt haben die agilen Methoden potenzial auch in der Systemadministration einzuziehen. Die bisherigen strikten Zuständigkeiten für Systeme oder Anwendungen können so effektiv aufgebrochen und eine höhere Dienstleistungsqualität erreichet werden.
In dem dritten Teil der Reihe “Wissensmanagement im Enterprise 2.0″ berichten Simone, Frank und Christoph auf ihrem Blog wie das Potenzial von Enterprise 2.0 genutzt und die Tools (Wikis, Blogs etc.) eingeführt werden können.
Entscheidend ist es, klein anzufangen und nicht gleich die gesamte Organisation zu verändern. Hier ist der Weg das Ziel. Sobald sich die Social-Software etabliert hat, besitzt man eine unverzichtbare Wissensstruktur im Unternehmen, die einen Mehrwert für jeden Einzelnen darstellt.
