Skip to content

Governance-Konzept für Sharepoint: Spezifische Wiki-Anforderungen

27. Februar 2012

Dieser Artikel ist im Grunde der Abschluss einer kleinen Serie namens : „Wikis in Sharepoint: Eine notwendige Ergänzung von Teamsites zur Zusammenarbeit und Innovation!“, funktioniert aber auch für sich.

Bislang ging es darin um folgende Fragen:

  1. Zusammenfassung der Überlegungen (Link)
  2. Wozu sind Wikis grundsätzlich geeignet? (Link)
  3. Was lässt sich mit einer Sharepoint-Teamsite besser als mit einem Wiki umsetzen? (Link)
  4. Was ist der spezifische Nutzen eines Sharepoint-Wikis in Abgrenzung zur Teamsite? (Link)

Im Anschluss daran machte ich mir mit der geschätzten Kollegin Nicole Illek noch einige Gedanken über spezifischen Anforderungen an die Governance, wenn man die Einsatzszenarien von Teamsites und Wikis im Sharepoint wie oben skizziert. Voilá, hier die Zusammenfassung der Überlegungen:

5.) Wie passt das SP-Wiki in die Sharepoint Governance?

Soviel vorweg: Ein Sharepoint-Wiki passt grundsätzlich in ein Governance-Konzept. Außerdem setze ich Vorkenntnisse voraus, was Governance ist, wie so ein Governance-Konzept grundsätzlich aufgebaut ist, und auf was es im Umgang mit Sharepoint ankommt. Dieser Artikel behandelt das „Aber“, das zusätzlich für die Nutzung von Wikis im Sharepoint gilt!

Ähnlichkeiten zur Governance beispielsweise einer Collaboration-Umgebung auf  Teamsitebasis sind gegeben, aber bestimmte Dinge sollten berücksichtigt werden, um die für ein Wiki notwendige (soziale) Dynamik zu ermöglichen.

Zu aller erst, und am wichtigsten: Zeit. Wenn das Management/Controlling keine Zeiten vorsieht, in denen sich Mitarbeiter – neben den Aufgaben des Tagesgeschäfts – mit Dingen befassen können, die sie für ihre Arbeit in einem erweiterten Sinn für notwendig erachten, dann werden sie es auch nicht tun. Ganz einfach. Ist das aber der Fall, dann gelten noch ein paar andere Regeln:

***

Die grundsätzlichen Fragen der Navigation stellen sich natürlich auch hier: Welche Reichweite soll das Wiki haben? Für wen und was ist es gedacht? Soll es gar nur einen eingeschränkten Zugang geben, für eine bestimmte Personengruppe? Wie prominent soll auf das Wiki hingewiesen, sprich: verlinkt werden?

Auch Fragen zum Life Cycle Management ähneln sich. Gerade bei einem Werkzeug mit derart dynamischen Inhalten sollte grundsätzlich geklärt sein, wie lange einzelne Inhalte oder das ganze Wiki zur Verfügung stehen sollen. Ob begrenzt oder dauerhaft? Sollen Inhalte über Policies und Workflows zur Wiedervorlage stehen?

Ein deutlicher Unterschied zur Teamsite-Governance ist dagegen das Berechtigungsmanagement, oder besser: die zugrundeliegenden Rollen und Zuständigkeiten. Beispielsweise macht die Rolle des „Moderators“ viel Sinn, die nicht zu verwechseln ist mit der eines „Administrators“. Denn ein Moderator hat Aufgaben, die stärker in die inhaltliche Gestaltung eingreifen. Außerdem gibt es in funktionierenden Wikis erfahrungsgemäß weitere nützliche Rollen, die in kleinerem Umfang Inhalt und Layout gestalten, und damit sowohl für Usability und Akzeptanz der Inhalte sorgen. Steward Mader hat diese Rollen unter www.wikipatterns.com zusammengefasst.

Damit wären grundsätzliche Management-Fragen angesprochen, die sich in der internen Kommunikation wiederfinden. Für was ist das Wiki geeignet? Wie grenzt sich das Wiki von den anderen Werkzeugen im Intranet ab? Für welche und in welchen Prozessen wird es eingesetzt? Welches Zeitbudget steht zur initiativen Nutzung zusätzlich zur Verfügung?

Dem was kommuniziert wird, liegen Aspekte des Steuerungsmodells zugrunde. Mein Lieblingsbild ist hier das der Marktwirtschaft. Von der Grundidee verstehe ich Marktwirtschaft, dass der Staat einen Rahmen definiert aus Gesetzen und ggf. Subventionen, um innerhalb dieses Rahmens dem freien Spiel der Kräfte Raum zu geben. Das zugrundeliegende Menschenbild ist das eigentlich interessante. „Marktwirtschaft“ geht von der Eigeninitiative der Menschen aus. Vom Willen zur Verbesserung, von Schöpfungswille, von Eigenverantwortung. Was bleibt sind Nachjustierungen der Rahmenbedingungen und gelegentliche Korrekturen.

Ein Wiki funktioniert ähnlich. Das Unternehmen definiert einen Rahmen, der nicht enger gezogen werden sollte als unbedingt notwendig. Eine sinnvolle eingrenzende Möglichkeit wäre z.B. die Verwendung von geschlossenen Term Sets für die Wiki Categories, um die Verschlagwortung thematisch einzugrenzen. Auch eine thematisch eingegrenzte Verwendung eines Wikis kann so erreicht werden.

***

Abschließend sollten noch Aspekte der Kultur als Teil der Governance berücksichtigt werden. Neben dem „Was?“ und „Wozu?“ des Managements ist noch das „Wie?“ zu beachten.

Ein Wiki-Einsatzszenario, wie oben skizziert, wird nur stattfinden in einem Klima der Fehlerakzeptanz, des „Suchens und Findens“. Unfertiges zu veröffentlichen, zur Diskussion zu stellen, ist auch unter günstigen Bedingungen eine persönliche Herausforderung. Menschen machen das nur in einem Klima, in dem das nicht nur erlaubt, sondern auch erwünscht ist. Die entsprechende Ansage durch das Management ist unverzichtbar – was sich nicht nur rhetorisch, sondern auch in tatsächlichen Zeitbudgets niederschlagen darf. Letztlich geht es um „Empowerment“ der Mitarbeiter. Durch Zeit einerseits, und durch klare Vorgaben des Zwecks, die begleitet werden von Schulungen des Wiki-Arbeitsprozesses.

***

Governance dieser Art befähigt nicht nur Mitarbeiter, sie befähigt Unternehmen. Zur Weiterentwicklung des bestehenden Know-Hows, und um neue Lösungen für die Kunden zu finden, mit dem was an Potential im Unternehmen vorhanden ist.

 

Blogger lieben Kommentare und Diskussionen! Wie ist deine Meinung dazu?

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s