Enterprise 2.0 und Unternehmenskultur …

… nicht von Alpha bis Omega – aber fast.

Das ist der Titel meiner Session am BarCamp Stuttgart.

Themen sind u.a. die Implementierung von Enterprise 2.0 und der Faktor Unternehmenskultur, einige kurze Stichworte sind dabei Punkte wie:

  • Implementierungsverläufe
  • Potenziallücke
  • Zielgruppen des Wandels sowie Gewinner und Verlierer des Wandels (durch Enterprise 2.0) & Stakeholder-Analyse
  • Empfohlene Vorgehensweisen der Implementierung

Aufbauend darauf werde ich verschiedene Ansatzpunkte der Implementierung diskutieren, und ganz konkret auf die Bedeutung von Organisationskulturen in diesem Zusammenhang eingehen. Ausgehend vom klassischen Modell harter und weicher Faktoren „7 S“ (nach Peters und Waterman) das als einfache Systematisierung dient, komme ich zu den Ebenen, Funktionen und Herausforderungen von Organisationskulturen. U.a. werden dabei das 3-Ebenen Modell von Schein dem kritischen Blick der BarCamper vorgestellt und ein paar schöne Bilder von Artefakten präsentiert …

Open Source platforms for Enterprise 2.0

John Eckman also moderated a panel on Open Source Platforms at the recent Boston Enterprise 2.0 conference. He talked to Bob Bickel , John Newton (of Alfresco) and Jeff Whatcott from Acquia. I like this take – if we want to achieve more adoption in the world of SMBs (that are lacking adoption drive) it’s necessary to have inexpensive, adaptive tools as an alternative to the established systems. There’s a record of the panel’s audio (mp3). And John links to various places where the panel was covered, I found some interesting things there:

He has some good points why Drupal should be considered, forget about the stabs at proprietary software and take it with good humour even if you’re non-organic …

She’s noting Socialtext’s (here) and Jive Software’s (here) efforts in open source but yes, it’s not their primary model. By the way, Kathleen has a nice summary too (“Enterprise 2.0: the good and the bad“). She’s complaining about too much talk on cultural change. Well yes, I agree but out of other reasons – I think there’s too much talk on these issues by people who basically don’t get it. It’s like the revenge of technology people for INATT (“it’s not about the technology”). Then it were people who want to cover up that they don’t understand these technologies, now too often it’s lighthearted chit-chat about organizational culture, motivational structures, change management etc. (“We’ve all read our Dilbert so we can all talk at lenghts about this fluffy stuff, can’t we?”). But hey, this is no “fluffy stuff” and that’s the real reason why these discussions are so unnerving – deep inside we all know that cultural and people issues are central and that they need to be thought through thoroughly (sic!) and not chatted about lightly

Intranet.days 2008 – Keynote by Martin White

First report from Intranet.days 2008 at Frankfurt: Martin White of Intranet Focus Ltd (blog is here) is doing the keynote, key points are
– enterprise 2.0 is here to stay – companies are in an experimenting mood now
– we need to integrate legacy applications & enterprise search must be considered
– he’s seeing plenty of opportunities for intranet managers that get it

Interesting point he makes: “Enterprise 2.0 technology without an Enterprise 2.0 culture will have a negative impact”. Hmm, I am not sure about that, to me culture is a journey not a destination, and I’ve seen discrete applications of E2.0 technologies without the culture being ready to all extent. Will try to get a word with him later on, and ask him about that …

Social Software for Motivation and Involvement

Found via Bertrand Duperrin: An inspiring slideshow on the role social software inside the enterprise may play for HR and organizational culture (“Web 2.0 at work: get passionate employees”). Reflect a changing nature of work – one that places more interest on interaction“ than on information. It’s not only easy information access, it’s more “interacting with one another”. Enterprises thus need to connect the right people, identify experts (yes, by position too but probably we need more reliance on relevant activities, associations, interests etc.) and build up involvement.

Stumbled upon – innovative organization and organizations …

Klaus Eck interviews CoreMedia’s Sören Stamer (german language) on what is his definition of Enterprise 2.0, and how it gets “on the road” at CoreMedia, i.e. agility, organizational culture and more:

Als vereinfachende Formel könnte man sagen: Enterprise 2.0 = Web 2.0 in the Enterprise + Privacy + Relevance

Sören himself has an interesting post here, pointing towards Toward High-Performance Organizations: A Strategic Role for Groupware by Douglas Engelbart:

[who] makes a strong case for Enterprise 2.0 long before this term was coined. Especially his framework for improving the improvement process is eye-opening. Inventing hypertext to share information easily was definitely a great C activity. And I guess the same is true for Wikis, Blogs and Micro-Blogs.

When he describes the interdependencies between the human system and the tool system, Douglas Engelbart captures the whole challenge of transforming a conventional Enterprise into an Enterprise 2.0. Without changing our paradigms, organizations, procedures, language and attitudes we won’t see the benefits of new tools.

We’re not alone in this, Vineet Nayar, CEO of India-based information technology services HCL Technologies explains why he believes that in the future, democratic companies will outperform the command-and-control dictatorships that have persisted since the industrial revolution, his learnings include:

– Let go of command and control. In business, as in nations, dictatorship is out. Democracy is in.
– Business leaders must be open to criticism, just as elected officials are.
– Customers don’t come first, employees do, because employees are the product that your customers are buying.
– Democracy and feedback allow employees and managers to gravitate toward their strengths.

Wiki – Gegenargumente und Gegengegenargumente

KoopTech hat eine Liste von Wiki-Gegenargumenten vorgestellt. Nicht alles davon ist stichhaltig. Manche Punkte benötigen schon einer Relativierung – oder auch direktem Widerspruch. Aber ich will nicht überkritisch sein, denn Kooptech hat ja auch 10 Gründe für den Wiki-Einsatz gefunden.

Johannes Moskaliuk hat die 8 Gegenargumente analysiert – unterteilt in funktionale und psychosoziale “Lösungsmöglichkeiten”. Gefällt mir sehr, und ja, es geht hier nicht um absolute “Wahrheiten” sondern mehr um Gefühle, Einschätzungen und eben auch alternative Umsetzungs- und “Lösungsmöglichkeiten”. Also erweitere und kommentiere ich Johannes’ Ideen aus meiner Sicht:

1. Die krude Wiki-Syntax ist oftmals ein Akzeptanzproblem.

Psychosozial: Neue Software erfordert neue Kompetenzen. Ohne Schulung der Mitarbeiter, Supportfunktion und eine Beteiligung der Nutzer bei der Entscheidungsfindung geht es auch im Wikizeitalter nicht.

Funktional: Mit dem Einsatz eines WYSIWYG-Editors ist das Problem lösbar. Technisch möglich ist auch die weitergehende Integration ins Betriebssytem, wie z.B. beim TWiki mit dem Kupu-Add-on (Linux) oder beim der Confluence-Software mit MS Office (Microsoft).

Zum einen: WYSIWYG-Editoren sind kein Allheilmittel und weisen nach jetzigem Stand der Technik auch gewichtige Nachteile auf. Es ist kein Zufall dass Enterprise Wikis wie Socialtext beide Editor-Alternativen parallel anbieten. Eine ausführlichere Analyse von Pro und Contra findet sich hier (“Simplicity, adoption and WYSIWYG editors”).

Zum anderen: Eine Einschätzung als krude Syntax (sic!) gilt nicht für jeden Markup-Dialekt, man vergleiche einmal die Auszeichnungsalternativen von bspw. Mediawiki für kursiv und bold (” und ”’, bold und kursiv sieht dann so aus: '''''fett und kursiv''''' – eingängig nicht wahr?) mit denen von Wikicreole, an die sich u.a. DokuWiki anlehnt.

Aber die eigentliche Aufgabe liegt natürlich im Bereich “psychosoziale Akzeptanz”, und es ist zweifellos richtig, dass Markup ein Akzeptanzproblem hat. Letztlich gilt das für alle Werkzeuge, die nicht wie Word aussehen (interessanterweise werden manche andere Werkzeuge und Systeme nicht so stark hinterfragt was Usability und Akzeptanz angeht, sie werden Mitarbeitern aufgezwungen und diese müssen damit mit SAP R/3 arbeiten – auch wenn die Usability bescheiden ist). Pragmatisch gesehen liegt die Antwort daher meist in einem “sowohl als auch”, in Verbindung mit einer gewissenhaften Analyse von Anforderungen und Zielgruppen, die Frage ob WYSIWYG sein muss, sollte dabei ergebnisoffen und vorurteilsfrei angegangen werden.

2. Kategorien und Hierarchien lassen sich zwar aufbauen, doch eine entsprechende Navigation kann nur über einen Eingriff im Backend eingerichtet werden.

Funktional: Über den Einsatz semantischer Technologien oder – einen Schritt vorher – die konsequente Anreicherung von Informationen mit Metadaten (z.B. Tags, Projektzuordnung, Themen, Inhaltsklassen) sind die Inhalte letztlich schneller über eine Suchfunktion als über eine Navigationsstruktur zugänglich.

Psychosozial: Dieses Gegenargument ist gleichzeitig ein Pro-Argument: Die Navigation wird eben nicht „von oben“, vom Admin oder Chef festgelegt, sondern wird von der Community kollaborativ erstellt.

Hmm, Navigation nur über einen Eingriff im Backend? Gilt nicht für die Wiki-Engines zu denen ich rate. Und Navigation über Kategorien oder Hierarchien? Es muss eben evaluiert werden, ob es nicht Wiki-Engines gibt, die so etwas von Hause aus mitbringen (bspw. TWiki-Webs, eigentlich alle gängigen Enterprise Wikis oder auch DokuWiki mit dem Namespace-Konzept).

Johannes – großartiger Punkt bei psychosozial. Dieser Aspekt des emergenten Entstehens von Struktur wird zu oft vernachlässigt, obwohl er viel für die flexible Anpassung an veränderliche Aufgabenstellungen (und die Motivation der Mitarbeiter) tun kann. Arbeitsgruppen, einzelne Mitarbeiter, einzelne Projektgruppen etc. können sich situativ angepasste Arbeitsumgebungen, Portal- und Übersichtsseiten einrichten. Das habe ich mit großem Erfolg auch schon begleitet, und es war eine Freude zu sehen wie die Möglichkeiten von den Nutzern aufgenommen und schnell genutzt wurden.

3. Die Kategorisierung spielt bei den Suchergebnissen keine Rolle bzw. sorgt nicht für eine Priorisierung von Suchergebnissen.

Funktional: lösbar, siehe oben

Psychosozial: Kompetenz bei der Anwendung der Suchfunktionalität muss bei den Nutzern vorhanden sein, oder geschult werden. Außerdem kann das Finden von Informationen, nach denen eigentlich nicht gesucht wurde, Prozesse der Wissensemergenz fördern (Serendipity).

Ich würde noch ergänzen, dass wir auch die zunehmende Einbindung von Wiki-Inhalten in Enterprise Search Ansätze sehen werden. Von Social Bookmarking in the Enterprise ganz zu schweigen. Das Problem ist erkannt, daran wird gearbeitet und Wikis sind eigentlich hierbei das kleinste Problem, viel mehr wird zurzeit damit gekämpft relevante Suchergebnisse aus den vielen, verteilten Office-Dokumenten zu generieren …

4. Suchergebnisse zeigen nicht an, welche Unterthemen es zu einem Oberthema gibt oder ob es in einer anderen Sprache einen Artikel zum gesuchten Thema gibt. Die Semantik drückt sich nicht in Wiki-Strukturen aus. Ab einer gewissen Textmenge ist das nicht mehr praktikabel.

Funktional: lösbar, siehe oben. Schlagwort: Semantic Wiki.

Ja, Semantik drückt sich auch nicht in Office-Dokumenten aus. Tagging, Kategorisierung, redundanzfreie Datenhaltung – alles wichtig, das Semantic Web wird auch manches davon lösen. Psychosozial gilt Punkt 3, Informations- und Medienkompetenz ist nicht immer gleichverteilt und gut ausgeprägt. Coaching und Schulung (und Learning-by-doing) kann hier helfen.

5. Die Suche erstreckt sich nur auf Wiki-Inhalte, andere Quellen können damit nicht erschlossen werden.

Funktional: lösbar. Beispiel ist das Confluence Wiki, dass auch zum Durchsuchen von externen Quellen, z.B. Austauschordner oder Servern genutzt werden kann.

Ja, siehe auch oben die Anmerkungen zu Enterprise Search. Enterprise Wikis bieten mittlerweile fast durchgängig die Möglichkeit bspw. hochgeladene Dokumente in die Suche aufzunehmen.

6. Das Rechtemanagement für ein Wiki muss mühsam eingerichtet werden, insbesondere wenn ein nach Personen und Gruppen differenzierter Zugang für verschiedene Bereiche eingerichtet werden soll.

Funktional: Lösbar zum Beispiel durch den Einsatz von Windows Active Directory. Für das Wiki können bestehende Rechtestrukturen übernommen werden.

Psychosozial: Ein Erfolgsfaktor für den Einsatz von Wikis ist eine flache Hierarchie und der freien Zugänglichkeit von Inhalten. Idealerweise ist die Einführung von Wikis in einer Organisation verbunden mit einer Änderung der Organisationskultur im Bezug auf den Umgang mit Wissen und Informationen zwischen Hierachieebenen.

Hmm, was heißt mühsam? Ist in den meisten Wikis nicht aufwendiger oder anspruchsvoller als die Benutzer- und Rechteverwaltung von Windows Server etc. Eine LDAP-Anbindung ist oft vorgesehen, damit ist dann selbst SSO machbar.

7. Nach etwa ein, zwei Jahren kann es für Unternehmen problematisch werden, wenn die entsprechende Pflege fehlt.

Funktional: Tools können die Pflege unterstützen, zum Beispiel das Finden von toten oder falschen Links, das Ändern von falschen Kontaktdaten etc.

Psychosozial: Das Problem tritt bei allen Systemen zum Wissensmanagement auf. Neben der Einführung einer Technologie, müssen sich deshalb auch Arbeitsabläufe, Arbeitsaufgaben und Rollen (Wikigärtner) anpassen, so dass eine ständige Pflege und Aktualisierung von Inhalten gewährleistet bleibt. Anders als bei anderen Werkzeugen kann die Verantwortlichkeit für die Aktualität der Inhalte auf alle Mitglieder einer Organisation verteilt werden.

Ohne Pflege geht es nicht, nicht umsonst werden die Rollen des Wiki-Gärtners oder des Wiki-Gnoms so wichtig eingeschätzt. Und ja, auch in einem klassischen Intranet kann ohne strukturierende Pflege Wildwuchs, wie bspw. veraltete, widersprüchliche oder redundante Inhalte entstehen (ich gebe aber zu dass ich die Möglichkeit an veröffentlichte Seiten ein “Verfallsdatum” zu knüpfen manchmal vermisse). Aber diese Schwäche kann man durchaus auch zum Vorteil wenden, siehe Punkt 8:

8. Wikis eignen sich für Projekte. Über die Jahre werden jedoch immer mehr Wikis eingerichtet, der Überblick geht verloren – man weiß nicht mehr, in welchem Wiki man suchen muss.

Funktional: Lösbar durch eine Suche, die über mehrere Wikis ausgedehnt ist.

Psychosozial: Klassischerweise wird ein Projekt in einem Abschlussbericht dokumentiert. Auch das lässt sich auf ein Wiki übertragen: Am Ende eines Projekts werden die zentralen und wichtigen Inhalte des Projekts in ein zentrales Wiki übertragen und bleiben dort zugänglich. Das Projektwiki wird gelöscht.

Wenn im Zeitverlauf mehrere Wikis entstanden sind (oder Projektunterbereiche etc.) ist es aus meiner Sicht auch eine Chance Inhalte rückschauend zu strukturieren, und dabei positive und negative Erfahrungen zu dokumentieren. Ein After-Action Review mag zwar zeitraubend erscheinen, aus meiner Erfahrung lohnt sich die Mühe aber. Eine Zusammenfassung der wesentlichen Punkte schafft einen Überblick, der bei anderen ähnlich gelagerten Projekten hilft. Ein paar Ideen zum Einsatz von Wikis im Projektmanagement habe ich hier, hier und hier zusammengestellt.

Zusammenfassend: Einige der Punkte entstammen meiner Meinung nach einer weitverbreiteten (aber unüberlegten) Gleichsetzung von Wiki mit Mediawiki bzw. Wikipedia. Die Wikipedia ist aber kein archetypisches Wiki, und Mediawiki ist auch nicht stets die beste Wiki-Engine. So weisen bspw. Enterprise Wikis wie Socialtext oder Confluence einen Großteil der oben vermuteten Angriffspunkte überhaupt nicht auf, sprich es bestehen bereits funktionale (technologische) Lösungen.

Zudem beziehen sich viele der Kritikpunkte der originalen Liste von Kooptech auf potenzielle Nachteile, d.h. mögliche Schattenseiten von Wikis, die erst durch eine “ungeschickte” Einführung und ungeignetes (Wiki-)Management* zutage treten. Die Auswirkungen auf Strukturen und etablierte Routinen etc. können ja groß sein – das ist auch das eigentliche Motiv von Enterprise 2.0. Aber um diese Potenziale heben zu können braucht es auch ein schlüssiges Konzept, sowie die Anpassung an die Unternehmensgegebenheiten und -ziele. Aber wenn etablierte Vorgehensweisen und Erfolgsfaktoren der Implementierung nicht beachtet werden, kann es durchaus schon mal schiefgehen.

<werbung>Deshalb bietet es sich ja auch an professionelle Unterstützung ins (Projekt-)Boot zu holen. Berater wie wir bringen zum einen spezifische Erfahrungen ein, aber auch

  1. einen Überblick über bewährte Vorgehensweisen und
  2. Ideen, d.h. innovative, kreative Problemlösungsstrategien.

Davon kann die organisationsseitige Einpassung – sprich das Change Management in Bezug auf die eigentlich spannenden sozialen und unternehmenskulturellen Aspekte – profitieren. Und weil es bei Enterprise Social Software wie Wikis meist weniger um Technologie, denn um diese weichen Faktoren geht ist eben weniger Technologieberatung denn Organisationsberatung notwendig.</werbung>

* ich lese gerade das Buch Wikimanagement von Prof. Komus, Review folgt.

Cultural change and developing collaboration capabilities

Scott Anthony – president of Innosight (see some of my innovation related posts over at bmid) – compiles some of the drivers needed for organizational change, based on a panel discussion he moderated with CEOs from Dow Corning, Eastman Kodak, Procter & Gamble etc.:

  1. The need for a crisis or some kind of “burning platform” to motivate transformational change
  2. A clear vision and strategy … that allows room for iteration
  3. A recognition that transformation is a multi-year journey
  4. A need to put the customer or consumer in the center of the transformation equation
  5. The critical importance of demonstrating to skeptics that different actions can lead to different results
  6. The need to over-communicate to employees, customers, stakeholders, and shareholders

While I doubt that implementing social software in the enterprise profits much from a state of crisis (we need some careful planning and concepts which suffer from too much fuzz, social software doesn’t help turning the ship around quickly – at least not in financial terms, etc.), the other success factors make perfect sense. And they’re people centered success factors – highlighting communication, leadership and (customer) relations.

So it’s kind of disheartening when Susan Scrupski paints a bleak picture and perspective of the setting, the context and the understanding of organizational change for enterprise social software (“Corporate Antisocial Behavior: the Enemy is Us“):

I once heard from a Wall Street executive that he was no longer permitted to use the word “social” when describing 2.0 opportunities. It made senior management uncomfortable. Similarly, if there is more emphasis on social than networking, our clients raise the justifiable question of employee productivity. When we talk about collaboration and breaking down barriers with earnest information-sharing and knowledge harvesting, the conversation is more intriguing. But, realistically, can technologies engender cultural change? That is the $5 billion dollar question that will be answered over the next few years.

It’s 4,52 billion USD by Forresters account (btw, I’ve made a long german language comment arguing it’s actually a lot more). What stresses me out is this “being uncomfortable” – this is strange: Management is supposed to be people business, it is inherently social by all accounts.

Well, here’s my answer to Susan: It’s the social stuff that makes “Enterprise Social Software” projects both complex and worthwhile. Technology is easy to figure out, while it can effect interesting and complex changes. And some technologies can engender cultural change:

the way I see it is that social software is both a driver and an enabler (or infrastructure) of organizational change.

All the while this changing of work practices, routines etc. doesn’t come easily. So I’m glad I am a subscriber to the Anecdote newsletter, because I learned early that Shawn Callahan, Mark Schenk and Nancy White have published a new Anecdote Whitepaper entitled “Building a Collaborative Workplace” (pdf):

Today we all need to be collaboration superstars. The trouble is, collaboration is a skill and set of practices we are rarely taught. It’s something we learn on the job in a hit-or-miss fashion. Some people are naturals at it, but most of us are clueless.

Our challenge doesn’t stop there. An organisation’s ability to support collaboration is highly dependent on its own organisational culture. Some cultures foster collaboration while others stop it dead in its tracks.

To make matters worse, technology providers have convinced many organisations that they only need to purchase collaboration software to foster collaboration. There are many large organisations that have bought enterprise licences for products like IBM’s Collaboration Suite or Microsoft’s Solutions for Collaboration who are not getting good value for money, simply because people don’t know how to collaborate effectively or because their culture works against collaboration.

Of course technology plays an important role in effective collaboration. We are not anti-technology. Rather we want to help redress the balance and shift the emphasis from merely thinking about collaboration technology to thinking about collaboration skills, practices, technology and supporting culture. Technology makes things possible; people collaborating makes it happen.

This paper has three parts. We start by briefly exploring what we mean by collaboration and why organisations and individuals should build their collaboration capability. Then, based on that understanding, we lay out a series of steps for developing a collaboration capability. We finish the paper with a simple test of your current collaboration capability.

Looks like an interesting read for enterprise social software (who really need to understand change management deeply) consultants.