12
Mrz

Stell dir vor: „Wir haben ein Enterprise Social Network und keiner macht mit!“

Immer mehr Unternehmen möchten im Zuge der Digitalisierung und der Forderung nach vernetzten, flexiblen, offenen und ortsunabhängigen Arbeiten ein funktionierendes Social Enterprise Network (ESN) aufbauen. Die Unternehmen haben dabei oft die folgenden Ansprüche:

Social Collaboration Tools sollen…

  • …alle Wissensprobleme in Unternehmen lösen.
  • …den Mitarbeiter ermöglichen selbstorganisiert arbeiten
  • …die Mitarbeiter automatisch dazu bringen durch Vernetzung ihr Wissen zu teilen.
  • …Wissen und Experten an einem Ort zentral verfügbar machen.
  • …Wissen immer aktuell halten und über Abteilungsgrenzen hinweg nutzen
  • …die Innovationskraft steigern.

Wenn man sich dann aber die Wirklichkeit anschaut, dann sieht dies ganz anders aus.

Ich habe eher die folgenden Erfahrungen gemacht:

In Wirklichkeit werden…

  • …Dokumente und gespeichertes Wissen nur schlecht gefunden und kaum abgerufen
  • …viele parellel laufende Systeme implementiert
  • …private Wissens- und Datenbestände geschaffen
  • …Social Collaboration Tools kaum genutzt
  • …Vernetzung und Wissenstransfer über Teams und Abteilungen hinweg aufgrund fehlender organisatorischer Rahmenbedingungen kaum erreicht.

 

Da kommt die Frage auf, was hier schiefläuft.

Jeder Bereich hat andere Anforderungen. Die Arbeitswelten der Mitarbeiter unterscheiden sich teilweise sehr. Wenn nun ein Tool für alle ausgerollt wird, werden jedoch die unterschiedlichen Anforderungen nicht berücksichtigt. Letztendlich soll ein Werkzeug ein Mittel zum Zweck sein, ein bestimmtes Problem zu lösen. Erst dann wird auch seitens der Mitarbeiter der Nutzen erkannt, was die Voraussetzung für Akzeptanz der Tools ist.

 

Mythos: Vernetzung kann eingekauft werden

Das denken viele Unternehmen. Denn es gibt so viele einfache Tools, die ohne große IT-Kenntnisse schnell implementiert sind. Diese werden dann den Mitarbeitern vorgesetzt, von oben verordnet und reglementiert. Fertige Lösungen von außen dem Unternehmen aufzustülpen, führt selten zum Erfolg. Der Prozesse des eigenen Findens, was konkret zum Unternehmen und auch zu den Mitarbeitern und deren Tätigkeiten passt, ist elementar, damit ein ESN Social Collaboration funktioniert.

 

Was sollte also beachtet werden, damit ein ESN und Social Collaboration gelingt?

In diesem Artikel beschreibe ich einige Anregungen und Best Practices aus einer Vielzahl an Projekten zur Konzeption, Aufbau und Einführung von ESN und Social Collaboration Tools.

 

1) Enterprise Social Network und Social Collaboration als Business Case sehen

Die 1. Hausaufgabe ist es, dass die Unternehmen herausarbeiten, was ein ESN bringt, welches Ziel erreicht werden soll und wie die Zielerreichung bewertet werden kann. Es sollte im Vorfeld Business Case erarbeitet werden. Letztendlich muss ein Budget – auch bei kostenlosen Tools – eingeplant werden. Unternehmen sollten die einzelnen Ziele der verschiedenen Collaboration-Projekte im Zusammenhang betrachten. Es geht darum, Wechselwirkungen festzustellen. Oft geschieht es, dass verschiedene Teams unterschiedliche Tools einsetzen und somit viele Insellösungen entstehen, die nicht miteinander in Einklang stehe und intelligent verknüpft werden können. Es entstehen dann schnell Irritationen, was wo zu finden ist und welche Tools welche Prozesse am besten unterstützen. Schlecht ist es, wenn dazu auch noch unterschiedliche Logins notwendig sind.

 

2) Seien Sie sich über die Geschäftsabläufe und Change im Klaren, bevor Sie Tools einführen

Ein weiterer häufig verkommener Stolperstein ist es, die Mitarbeiter und die Unternehmenskultur zu ignorieren: Es darf sich nicht nur auf das Tool konzentriert werden. Im Vordergrund steht die Art und Weise der Zusammenarbeit und Vernetzung. Allen Beteiligten sollte klar sein, wie die Arbeitsweise heute aussieht und was in Zukunft anders laufen soll und was dafür die einzelnen Mitarbeiter und Teams benötigen. Daraufhin wird entschieden, welche Tools Prozesse, neue Strukturen und Formen der Zusammenarbeit unterstützen können.

 

3) Mit Change schrittweise umgehen und eine Pilotgruppe auswählen

Letztendlich muss entschieden werden, wie die Einführung erfolgt: eher von oben Top Down oder von unten Bottom up. Beim Top Down-Ansatz werden die Ziele und Maßnahmen vom Management vorgegeben. Das Risiko besteht in einer eventuell auftretenden Realitätsnähe zu den operativen Bereichen. Dagegen kommt beim Bottom up-Ansatz der Rahmenplan von den operativen Abteilungen. Hier ist das Risiko, dass eventuell die Akzeptanz des Top-Managements fehlt und kein Budget genehmigt wird. Am aussichtsreichsten ist ein Strategie-Mix aus beiden Ansätzen: das Management schafft die Rahmenbedingungen, die operativen Bereiche geben Handlungsempfehlungen. So wird eine Orientierung an der Unternehmensstrategie sichergestellt und Insellösungen verhindert. Dennoch sind die Mitarbeiter direkt eingebunden und geben ihre Ideen in das Projekt mit ein. Es bewährt sich auch, dass das Management eine Auswahl an adäquaten Tools, Funktionen und konzipierten Rahmen vorgibt und eine oder mehrere Pilotgruppen probiert dies im operativen Geschehen aus und gibt Feedback. Das Ziel ist es immer alle Beteiligten abzuholen und Veränderungen schrittweise so umzusetzen und Gewohnheiten nicht alle auf einmal zu ändern.

 

4) Passende Schulungen realisieren

Des Weiteren benötigen Mitarbeiter sinnvolle Schulungen: hierzu gehört neben der reinen IT-Schulung auch die Vermittlung des geschäftlichen Nutzens. Anstatt reine „Feature and Functions“ sollten praktisch anfallende Szenarien und Uses Cases vermittelt werden – so haben wir es früher gemacht, so arbeiten wir ab heute und dies hat den folgenden konkreten Nutzen und Arbeitserleichterung.

Generell sollten die Werkzeuge so nutzerfreundlich sein, dass diese intuitiv bedient werden können. Aber auch eine gute Usability ersetzt keine Schulung.

Die Schulung hat auch den Zweck, die Kommunikation mit den Nutzergruppen zu intensivieren. Die Nutzer haben eine Anlaufstelle für Fragen, die nicht nur das Werkzeug, sondern auch organisatorische Rahmenbedingungen betreffen. Dies darf man meiner Meinung nicht unterschätzen. Meistens geht es nicht nur um IT, sondern um Fragestellungen, wie mit Wissen und neue Formen der Zusammenarbeit richtig umgegangen werden soll und ob es von der Führungsebene aus Unterstützung gibt. Mitarbeiter sollen auch ihre Bedenken äußern dürfen. Und erst schulen, wenn das Tool zur Verfügung steht. Sonst ist wieder alles vergessen. Man glaubt es kaum, aber dies wird in vielen Fällen nicht beachtet.

 

5) Richtiger Zeitpunkt zur Kommunikation festlegen

Wenn man die Einführung nicht vermarktet und bei den Mitarbeitern bekannt macht, wird niemand das Tool nutzen. Dabei ist wie bei der Schulung der richtige Zeitpunkt wichtig: erst die Kommunikation starten, wenn das Tool zur Verfügung steht. Wenn erst noch Wochen auf die Einführung gewartet werden muss, ist die Begeisterung schon wieder verflogen.

 

6) Hürden durch Struktur abbauen

Wissenstransfer und das Sichern oder Aufschreiben des eigenen Erfahrungswissens kostet den Mitarbeiter sehr viel Zeit. Oftmals wird das Dokumentieren als eine große Hürde und als eine sehr unangenehme Arbeit empfunden. Es ist auch teilweise unklar, welches Wissen für eine Dokumentation relevant ist. Wenn dem Mitarbeiter Struktur geliefert wird, werden solche Hürden abgebaut. Was empfinden Sie als angenehmer? Ein weißes leeres Blatt Papier oder Wiki-Artikel mit der Aufforderung, schreib alles auf, was du weißt und was für die Tätigkeit wichtig ist oder ein vorstrukturierter Wiki-Artikel mit Kästchen und Hinweisen, Beispiel Listenpunkten und dem Anspruch in Form von Checklisten zu schreiben?

 

7) Informationen und Wissen immer in Prozesskontext stellen

Die Basis aller Überlegungen sind immer die Geschäftsprozesse und die Tätigkeiten der Mitarbeiter. Es sollte immer die Arbeitswelt der Mitarbeiter abgebildet werden, diese müssen sich schnell wiederfinden können. Ich sage immer: Wir kommen vom Workflow zum Lernflow. Die Prozesse sollten zentral und rollenbasiert abgebildet werden zum Beispiel in agilen Workflow-und Prozessplattformen. Auf Basis der Prozesse werden alle Inhalte/Wissensobjekte kontextsensitiv platziert, die der Mitarbeiter für seine Tätigkeit benötigt. Grundlage hierfür sind die Anforderungen, die die Aufgabe mit sich bringt. Der Nutzen ist für den Mitarbeiter direkt erkennbar, wenn er dadurch Aufgaben und Probleme schneller lösen kann. Es sollten auch Feedbackmöglichkeiten für die Mitarbeiter vorhanden sein, gemachte Erfahrungen selbst einzustellen oder vorhandene Inhalte auf den Nutzen hin stetig zu verbessern.

 

Fazit

Ein ESN und Social Collaboration funktioniert nicht automatisch durch die Bereitstellung von Tools. Nicht das Werkzeug ist die Basis aller Überlegungen, sondern die jeweiligen Anforderungen aus der Arbeitswelt – also der Kontext – der Mitarbeiter. Erst dann kann der Nutzen eines ESN und Social Collaboration Tools erkannt werden und die Mitarbeiter machen mit.

You are donating to :

How much would you like to donate?
$10 $20 $30
Would you like to make regular donations? I would like to make donation(s)
How many times would you like this to recur? (including this payment) *
Name *
Last Name *
Email *
Phone
Address
Additional Note
paypalstripe
Loading...