For a long time, and because many thought they could import the social web’s behaviors in the enterprise as is, the projects aiming at bringing the social dimension within employee’s work tried to structure the enterprise the way the web was. That means people will looking for “communities” that were supposed to fill “social spaces”, each community being a project itself. It lead to a very paradoxical situation since it lead enterprises to organize spontaneity.
That’s the reason why, and even if the above mentioned way made sense in some cases, it appeared that facilitating what was really spontaneous was what made the most sense. And, in my opinion, there’s nothing more spontaneous that people’s day do day job, processes and routine they follow even unconciously. Of course, that’s less impressive than trying to mobilize, if not create, a community from scratch (even if it means wasting energy to make communities that don’t exist live), but it ensures that the most obvious communities are adressed, those that are sometimes too obvious to be seen : the communities of people who need other’s help to do the job they’re asked to do. The problem is that these communities are very versatile : they may last a few minutes, a few hours, even be permanent.
There used to be two ways to face this kind of need.
The first is to allow on-demand groups, community, “social spaces” (call it as you want) creation by employees. It’s rather about governance.
The second is more functional and is translated into the integration of microblogging functionalities in social platforms to allow people to exchange and mobilize outside of the formalism of a structured space (yes…sometimes even a blog or a community is too formal) when people does not have a rich content to share but rather one or two lines.
The purpose is to work like what I call a Service Oriented Organization : allowing someone facing a problem to mobilize the right system (people + tools, + way of doing things) in order to solve it and go back to their work.
From the more structured (opening a group, a community, writing a blog post) to the more unformal (microblogging), every problem has a well dimensioned tool, what favors adoption. It’s because employees are often ask to kill flees with a baseball bat and are not allowed to use a flyswatter that they give up and complain.
That’s the best way to make sure tools are serving a need instead rather than trying to create needs to make people use the tools.
Adressing the “fluid” layer of these interactions is the purpose of Google Wave. I won’t explain what Google Wave is since so many experts already wrote exhaustive posts about it.
The tool is still yound and its success will depends on its ability to integrate with more traditional tools, what is challenged shared with all social tools. A good example of its potential is shown by Timo Elliott, with a Wave / SAP intégration. That’s only the beginning and it seems promising.
But :
• If people were about to work 3 months on that process, a more structured space should have been open because the Wave should have become quite unreadable and informations hard to find for new joiners.
And, last but not leas : I can believe that all the people in this story join the discussion as needed. But it supposes that they know each other what is seldom the case in a merger. They even may have forgotten a fourth skilled person who was not in their radar. Hence the need for a social network to identify the people that need to be invited in the wave. Why ? Because their identification is made possible by a rich profile, fed by both people themselves and datas extracted from their social activities, publications etc… what takes us back to blogs, groups, communties etc…
So, the social part of an information system is more like a napoleon than a monolithic brick. Each layer is necessary to adress a specific part of a global need. If one misses, the whole chain breaks.
