Der Sinn oder Nicht-Sinn von Enterprise 2.0 „Best Cases“

René Sternberg hat in einem Blogpost völlig zu recht darauf hingewiesen, dass ein und dieselbe Social Software in verschiedenen Unternehmen zu ganz unterschiedlichem Nutzungsverhalten führen kann. In diesem Zusammenhang verweist er darauf, dass „Best Cases“ zu Enterprise 2.0 aus diesem Grund nur bedingt Sinn machen.

Da hat er Recht. Bedingt heißt aber eben – nur unter bestimmten Bedingungen. Darauf bin ich bereits in einem Kommentar zu seinem Post eingegangen und möchte das an dieser Stelle wiederholen:

Denn das Stu­die­ren von “Best Cases” kann durchaus sinnvoll sein: Wenn näm­lich mög­lichst viele Rah­men­fak­to­ren, die das Nut­zungs­ver­hal­ten beein­flus­sen (kön­nen), in den Best Cases mit­be­schrie­ben wer­den. Diese kön­nen dann mit der Situa­ti­ons­ana­lyse des eige­nen Cases ver­gli­chen werden. Und die ist ein Muss!

So ist es z.B. nicht nur von Inter­esse, wel­cher Bran­che die jewei­lige Orga­ni­sa­tion ange­hört, son­dern auch durch wel­che Funk­tio­nen die ent­spre­chende Orga­ni­sa­tion domi­niert wird. Also, sind bspw. Pro­duk­tion, Mar­ke­ting, Ver­trieb, IT etc. die domi­nan­ten Berei­che oder liegt der Schwer­punkt woan­ders? Oder anders gesagt: Wer sind die leute, die das zeug nutzen sollen? Wie gestaltet sich ihre tägliche Arbeit? Welche Bedürfnisse haben sie?

Denn unter­schied­li­che Funk­ti­ons­be­rei­che arbei­ten auf unter­schied­li­che Art und Weise, so dass der Mehr­wert von Anwen­dun­gen für die Mit­ar­bei­ter|innen ganz ver­schie­den aus­fal­len kann und sie dem­ent­spre­chend Social Soft­ware auf spe­zi­fi­sche Art und Weise nutzen.

Beispiel: Nutzung von Lotus Notes

Dieses Prinzip der nutzerspezifischen Aneignung von Software hat Wanda Orli­kow­ski vom MIT bereits 2000 in einem inter­es­san­ten Arti­kel beschrie­ben, und zwar am Bei­spiel der Nut­zung von Lotus Notes durch einer­seits Con­sul­tants und ande­rer­seits IT-Spezialisten. Beide Grup­pen nutz­ten Lotus Notes unter­schied­lich stark, adap­tier­ten die Soft­ware unter­schied­lich schnell und sahen ganz ver­schie­dene Anwen­dungs­mög­lich­kei­ten.

Orlikowski illustriert in ihrem Artikel sehr einleuchtend die Gründe für das unterschiedliche Verhalten:

Die Nutzergruppen unterschieden sich hinsichtlich

• ihres technischen Backgrounds,
• ihrer Aufgabe und damit verbundenen Wokflows (IT-Staff: technischer Support vs. Consultants: Management von Klienten),
• … und unterlagen in ihrer Arbeit verschiedenen for­ma­len Rah­men­be­din­gun­gen.

Die IT-ler waren aufgrund ihrer Erfahrung im technischen Support an das kooperative Arbeiten mit Softwarelösungen gewöhnt, erkannten dementsprechend schnell die Vorteile von Lotus Notes für ihren täglichen Workflow, experimentierten mit der Software und bauten sie in ihre Arbeit ein. Die Consultants hingegen hatten große Schwierigkeiten, überhaupt einen Mehrwert der Anwendung ausfindig zu machen – und es machte ihnen auch niemand vor.

Die IT-Worker konnten darüber hinaus die Zeit, die sie mit Lotus Notes ver­brach­ten, ganz klar als Arbeits­zeit abrech­nen und wur­den von ihren Füh­rungs­kräf­ten auch zur Nut­zung ange­hal­ten. Die Con­sul­tants hingegen hatten Schwie­rig­kei­ten, die Nutzung von Lotus Notes mit den sehr rigiden Vorgaben der Zeitabrechnung in Einklang zu bringen..

(Orli­kow­ski (2000): Using Tech­no­logy and Con­sti­tu­ting Struc­tures: A Prac­tice Lens for Stu­dy­ing Tech­no­logy in Organizations)

Der letzt­ge­nannte Punkt, ob näm­lich die Beschäf­ti­gung mit Social Soft­ware als Arbeit aner­kannt wird und ob ent­spre­chende Wert­schät­zung durch die Unter­neh­mens­füh­rung erfolgt, zeigte sich auch in mei­ner Stu­die zur Deut­schen Tele­kom als äußerst bedeut­sam. Siehe hierzu mei­nen entsprechenden Blog­post.

Die Affinität zu Technik wiederum – im Beispiel von Orlikowski mit der Abteilungszugehörigkeit (IT) verknüpft – kann auch aus anderen Faktoren resultieren, wie z.B. der Alters­struk­tur der Beschäf­tig­ten einer Abteilung.

Ergo: Wenn man Best Cases erstellt, sollte man so  viele Rah­men­fak­to­ren wie mög­lich erhe­ben und dokumentieren. Nur dann ist ein beobachtetes Nutzungsverhalten erklärbar.

Und bevor man Social Soft­ware im Unter­neh­men ein­führt, sollte eine ent­spre­chende Ana­lyse der unter­schied­li­chen Ziel­grup­pen im Unter­neh­men erfol­gen! Jeder seriöse Bera­tungs­an­satz beginnt aus gutem Grund mit einer Stakeholderanalyse.

Bzgl. des Ein­sat­zes von Social Soft­ware im Unter­neh­men gilt: Für eine der­ar­tige Ana­lyse hat ins­be­son­dere
die Sozio­lo­gie das ent­spre­chende Metho­den­in­ven­tar und das gedank­li­che Grund­ge­rüst! Sozio­lo­gie ist eben nicht nur gut, um abge­ho­bene Theo­rien zu ent­wi­ckeln oder Sta­tis­ti­ken zu fäl­schen, son­dern hat eben auch einen ganz prak­ti­schen Nutzen.

Die erfolgreiche Einführung von Social Software in Unternehmen ist davon abhängig, ob die eingesetzten Tools zum Unternehmen „passen“. Diese Passung ist aber leider eine, die von erheblicher Komplexität geprägt ist. Denn Social Software lebt von Sozialität – daher hat sie ihren Namen.

Wie es der Zufall so will, ist gerade die Soziologie eine Disziplin, die sich seit jeher mit der Komplexität sozialer Sachverhalte auseinandersetzt. Glücklicherweise ist sie in der Lage, nicht nur Komplexität zu erfassen, sondern eben auch, praktische Handlungsanweisungen aus ihren Analysen zu generieren.  Diese Einsicht scheint sich in der Praktiker-Community immer weiter durchzusetzen.