Jeff Schick @ E20Summit

Now, last slot before lunchtime (and me meeting the guys from BlueKiwi, perhaps Bertrand ttoo?) Jeff Schick of IBM (Vice President, Social Computing Software, in the IBM Software Group) is up, speaking on the practical experiences with social software in the enterprise.

Looks back into the long past, argues for cave dwellers as early archetypes of collaborators, then only a little bit back: Usenet, whois, IRC and other early communication tools). Nodding smiles in the audience, oh the joys of nostalgia.

Interesting insights into IBMs practice

– wide spectrum of corporate blogs inside IBM (purposeful / semi-purposeful as he coins it)
– communication mashups (I would call it that way)

He argues that Enterprise 2.0 can be seen well from a very pragmatic point of view, that’s what IBM is doing. Yes, there are LOADS of bloggers inside, the reasons and rationales are diverse, but individual uses are OK.

Nice insights into the virtues of meandering around, doodling around in communities of interest. I would call this fishing for serendipity …

Another cool thing, Emergence seems to be a big theme for IBM this CeBIT, I will add my snapshot later on, batteries are runnng low now.

Selbstorganisation in Unternehmen und Erfolgsfaktoren der Beratung

Die Diskussion rund um den ROI von Social Software für das Projektmanagement hat sich mittlerweile in Richtung grundsätzlicherer Fragen gedreht. Ausgangspunkt meines zweiten Kommentars war die Argumentation von Matthias Schwenk mit bewusst einfachen Lösung Social Software zum Einsatz in Unternehmen zu bringen, um später Lösungen Schritt für Schritt von innen und nicht nur von einem externen Berater entwickeln zu lassen:

[…] “pädagogisches” Ideal wäre es, die Betriebe setzen Social Software zunächst eher experimentell ein und erkunden so deren Potenziale. Läuft alles gut, entdecken die Menschen im Betrieb im Lauf der Zeit von allein, was noch so alles möglich wäre und entwickeln die Systeme weiter bzw. bauen neue auf.

[…]

Der einzelne Betrieb soll ja auf Dauer nicht vom Berater abhängig sein, sondern sich die Kompetenz selbst erwerben. Das ist mir insbesondere bei den mittelständischen Betrieben wichtig, die nur wenige Hundert Mitarbeiter haben.

Worauf ich das hier kommentiert habe:

Es tut mir leid, mit deiner Argumentation habe ich mehrere Schwierigkeiten, insbesondere an den Nahtstellen von “Bedienbarkeit und Einfachheit” und dem Verhältnis zu Unternehmensanforderungen und -nutzen. Das sehe ich etwas anders, ich plädiere ja auch nicht aus “Berateregoismus” für eine ergebnisoffene Anforderungsanalyse und Auswahl aus dem “Werkzeugkasten Enterprise Social Software”, sondern gerade weil so nachhaltig erfolgreiche Lösungen entstehen können.

Dass der Startpunkt noch für längere Zeit und in den allermeisten Fällen “Pilotprojekt” heißen wird ist klar und vernünftig – ich empfehle meinen potenziellen und tatsächlichen Beratungskunden auch nichts anderes. In einem Pilotprojekt können die Chancen und Risiken sehr schön und in einem kleinen und überschaubaren Rahmen erprobt werden.

Dazu kommt dass in diesen “Experimenten” neue und angrenzende Einsatzpotenziale und -arenen entdeckt und evaluiert werden können. Was wiederum den Berater freut, der dann die Skalierung und Übertragung vorbereiten und begleiten kann …

Es geht nicht darum (komplexe) Lösungen zu verkaufen, die Kunden in die Abhängigkeit führen. Auch wenn der “sich selbst überflüssig machende Berater” von oben nicht viel mehr als eine platte Marketingfloskel ist – jeder Berater hat gerne Folgeaufträge – ist hier also wichtiges enthalten: Nur zufriedene Kunden empfehlen den Berater weiter und machen Projekte aus “Pilotprojekten”, entwickeln gemeinsam mit ihm Konzepte für neue Einsatzarenen oder überlegen wie die Lösung in andere Größenordnungen und Unternehmensbereiche übertragen werden kann.

Einfache, leicht bedienbare Lösungen haben dabei viele Vorteile – und Usability im Verhältnis zu Leistungsfähigkeit beschäftigt mich (und andere) durchaus. Zu einfach dürfen die Lösungen aber eben auch nicht sein, metaphorisch gesagt ist ein Hammer ein sehr einfaches Werkzeug, kann aber fast nur fürs Nägeleinschlagen gebraucht werden und wird langfristig nur wenig Freude machen …

Beim Einsatz von Social Software in Unternehmen muss es also mehr um skalierbare, flexible und erweiterbare Plattformen – wie bspw. hier in Olivers Konzept angedacht – gehen. In der Folge sollte Beratung rund um Enterprise Social Software vielfältige Konzepte (und Werkzeuge) beherrschen, um dem Unternehmen anforderungsgerecht und passgenau Lösungen anbieten zu können. Vielleicht sollte sich die Rolle des Social Software Beraters nicht darin erschöpfen den Unternehmen neue (IT-)Werkzeuge anzudienen, sondern auch strategische Beratung rund um das Enterprise 2.0 umfassen (“Wikipatterns, success factors and consulting“)?

There’s value in the (intranet) mess

I like this David Weinberger ( here’s another interview with him) analysis of corporate intranets:

So the intranet at your organization is outdated—far behind that of the actual Internet. It’s marked by bad navigation. There are aging documents and old newsletter articles that belong in an archive. Maybe there’s a search engine, but if so that search engine only looks for materials in one department—not companywide.

Wading through your intranet is not only time consuming, it’s demoralizing. It’s a time waster, and a waste of the knowledge employees have accrued. This needn’t be the case.

While it’s obvious that most companies don’t really leverage the potentials of their intranets, I want to make it really clear that approaching this from a “just add more content and help people digest that information” perspective is just a little bit too tempting and won’t take you far. “Embrace the chaos wherever you are” is no solution in itself – we need to focus on the emergence of structures, and we need to figure out how the pieces fit together.

Wiki usability and Enterprise software sexyness

There’s an interesting debate going on, which is definitely worthwhile to follow. Arguments are exchanged whether, and if so how enterprise software can be as “sexy” as the all new web. Robert Scoble triggered it off (but somebody else called for it in the first place), got criticized and even flamed badly, others came to help, and so on. You know the game, see Techmeme for more. I am sure you will be enjoying the discussion in all branches and forks as much as I am.

While discussing UI, usability, user-friendliness and all is interesting (though putting lipstick on a pig really doesn’t help much) – well, even the endless arguments of “industrial-strength-software proponents” are entertaining in a way because we know better (this is dire stuff, and I ask myself if those guys ever worked with enterprise-style-software like R/3) – I want to chip in some observations from another perspective.

As a long-time enterprise software user, developer (yes, I was – years ago in my old life) and today enterprise 2.0 & enterprise social software consultant, I want to offer look at this from a position of wiki advocate (-evangelist, if you want).

Are enterprise wikis sexy? Most people don’t think so – but I think they get it wrong: Enterprise wikis are interesting not because of their advanced technology, their polished user interface or their neat mark-up language – in fact these are kind of disadvantages most of the time when we want corporate adoption to take off. Like when people doubt whether the wiki markup language will be accepted in their companies – they sure don’t deem wiki markup sexy. Yes, these are no shiny tools, they don’t offer eye candy, but they are well suited for doing their job.

The key is to start from business applications and needs – not tools. If the starting point is a specific business application like e.g. project management or business development support, users will judge the sexyness of the application in a different way – they will look for personal use and business value primarily.

Wikis soon gain “cool tools status” – just because they offer room for flexible emergent uses, coupled with great simplicity. In this light Dave Snowden opens a can of worms, which should attract more discussing, when he’s pointing to the inherent differences between complex social software and standard enterprise ware.

So yes, wikis can even be fun to use, and while sexyness is always a matter of taste, this is a good start and adds to the other wiki benefits like scalabity, connectivity and cost effectiveness that stand on their own anyway. This is no “fantasy land”, this is today, the 21st century and the changes will be great, and they won’t be about technology or tools:

Enterprise 2.0 is already upon us, providing us attractive, usable, reliable and secure applications. We just haven’t made the move to adopting it. But it’s happening now, with Generation M, mobile, multimedia, multitasking and here. Now.

What is OpenSocial? Yes, it’s a business model innovation

There’s a myriad of posts on OpenSocial already and I know that I’m a latecomer to the party. Yet I will try to put down some observations and notes, if only because this has rattled the plans for my planned BarCamp session this weekend. I have to update my slide deck now, thanks Google. OK, most of the stuff I’ve written before remains valid and/or got valified through this move (see e.g. Portable soziale Netzwerke, and my post on NoseRub, german posts also touching on big hairy questions like privacy of data).

Some observations from a strategic / business point of view:

  • Google is proposing an open approach with the goal of integrating a variety of networks – they are not building up yet another social network. This is a platform approach, not a product or services innovation.
  • And this is also a cool business model innovation move – Google is opening up the social networking space to the many developers outside with a standard platform, i.e. they have learned the Facebook lesson and expanded on it – turning the table for Facebook in effect. Now who’s leading the charge in the web OS game …
  • Google understands that there’s more value to be gained from a shared ecosystem and from the long tail of distributed communities, than from a walled garden even if it’s big. There’s no need for an one and for all über-network, but for an easy way to integrate the many existing social networking sites (and communities of people in fact).

Nice before/after picture:

OpenSocial

Some snippets (via Richard MacManus, …):

OpenSocial is not a social network itself, rather it is a set of three common APIs that allow developers to access the following core functions and information at social networks:

* Profile Information (user data)
* Friends Information (social graph)
* Activities (things that happen, News Feed type stuff)

For developers there are lots of benefits. They can build an app that easily works across all the OpenSocial partners. And they can use normal HTML, Javascript and Flash – instead of the proprietary languages Facebook forces developers to use.

You may also check out the Google guys view on all this, here at the all new OpenSocial API blog (“The web is better when it’s social“)

Then, for those with more time on their hands there’s also this one-hour explanatory video:

And here’s a little video by Marc Andreesen of Ning explaining the concept of container and apps:


Find more screencasts like this on Ning Network Creators

Interested in more analyses? Go visit Techmeme and bring lots of time. Or take my short list of cool posts, starting with Jeremiah Owyang of Forrester (“Explaining OpenSocial to your Executives”), this is a good short status report, short excerpt:

What is Open Social?

Google says: “OpenSocial provides a common set of APIs for social applications across multiple websites. With standard JavaScript and HTML, developers can create apps that access a social network’s friends and update feeds.”

Translation: Social Networks, and other websites (we can call them platforms or containers) can let mini-websites (applications or widgets) to be shared and interact with existing online communities (social networks, social graphs, communities).

Jeremiah also expands on the opportunities this offers, namely in the community building space (Efficient development, harness existing communities, open standards help long term, your existing applications become social, future brings social to your website). Recommended analysis, gets you up to speed quick.

Then there’s Anil Dash of Six Apart (“OpenSocial, Killer Apps and Regular People”), on why the opened social graph can help people in their networked lifes:

This gives regular people on the web more control over the social networks and applications they use.

Interesting times ahead.

More upcoming events at Web 2.0 Expo …

Planning the next five days, here’s some more: There’s an evening session on “The Starfish and the Spider” at the newthinking store (10117 Berlin Mitte, Tucholskystraße 48) on Tuesday evening 7pm-9pm.

Warum sind Wikipedia, Craigslist und Skype so erfolgreich? Wieso versetzten Kazaa und Napster der Musikindustrie einen solchen Schlag?

Weil sie das freche Seestern-Prinzip nutzen, das auf Dezentralisierung, Vertrauen und Kommunikation unter Gleichen aufbaut. Mit ihrer Wandlungsfähigkeit setzen die flinken Seesterne die hierarchischen Spinnenorganisationen immer wieder Schachmatt – und verändern damit die Welt.

Rod is an interesting guy:

[…] Stanford-Absolvent und Unternehmer, der sein erstes Unternehmen CATS Software Inc. an die NASDAQ brachte und u.a. auch ein früher Investor bei eBay war. Er engagiert sich für Umweltthemen und soziale Belange und half etwa bei der Gründung des Silicon Valley Social Venture Funds und des Environmental Markets Network. Zur Zeit verfolgt Rod mit der Firma twiki.net die Entwicklung von Wikis als open-source enterprise software.

Some reviews of his book, via newthinking store and my del.icio.us bookmarks:

Handelsblatt (german)
Welt (german)
Firstmedia (german)

Some english reviews: David Robertson and Harold Jarche, and here are some distilled book notes at the Socialtext Open Wiki – i.e. “main content of the book, but without the stories and examples”.