Dion Hinchcliffe recently did a blog post making the point that social susiness software is here. In calling this the year of the shift to Enterprise 2.0, he presents a number of good proof points:

• Forrester says half of all enterprises globally have the software despite the technologies only being about 3 years old.

• A broad new survey of over 6,000 respondents recently released by TMCnet and IntelliCom Analytics shows consistent business use of social networking tools across organizations of all sizes and around the globe, ranging from 35% to almost half, depending on the demographic.

• The Society for Information Management’s Advanced Practices Council (APC) says that at least 50% of organizations will use wikis as important work tools in 2009.

That’s the good news.

The bad news, from the same post, is that there is just as much compelling evidence that these newfound tools are highly fragmented in their usage. As he puts it, “few enterprises are taking a ‘holistic’ approach and are using them in a more targeted and/or fragmented manner.”

That’s a real pity, because we know that when a single, unifying community platform is available and done well, it can successfully knit all of the communities together so that none have to be islands.

Why do organizations wind up with lots of little communities instead of one big one? There are a lot of reasons, so like any other dysfunction, this sort of thing is hard to cure comprehensively. There are security concerns, concerns about who is allowed to talk to customers, internecine rivalries and a host of parochial control interests.

But consider whether an organization would be successful if every department had its own phone system that didn’t connect to any of the other phone systems. Would we like a business where only some employees in sales and marketing can dial outside phone numbers or receive outside calls, while everyone else can only talk to colleagues inside the walled fortress? If it doesn’t make sense for a phone system, would it make sense for email? Most people would view this as a bad idea!

Why then does it seem to make sense for social software? After all, we’re just talking about another medium for communication. The answer is that it doesn’t make sense! Just like any other communication network, the value of social software is proportional to how many connections you can make with it. In fact, each new connection is worth more than the last connection because it is a many-to-many network. When the network goes from 99 to 100, it isn’t just that you can talk to one more person, it’s that your 98 other colleagues can also talk to one more person, and that new person can talk to all 99 of you. And so it goes.

In fairness, there are some real concerns that have to be navigated successfully here. These concerns generally fall under the rubric of policies and controls.

Organizations need policies that set expectations for how social tools will be used. For example, who can and cannot engage directly with a customer in the community. (BTW, be aware that your employees are already engaging with your customers all the time on the web through social software not under the direct control of the company such as Twitter, blogs, and Facebook. You’re kidding yourselves if you think there is plenty of time to worry about policy later.)

The second issue is controls. I’ll boil down controls to mechanisms that the technology affords to help enforce and automate the policies. This is an area where a lot of social business software could use some work. I’ve written about this before on my personal blog, Smoothspan, when I penned, “In Search of Enterprise DNA for Social Sofware.”

I’ve had a number of customer conversations around the areas of exactly what kinds of controls they’re looking for, and I’m happy to report it isn’t anything very exotic. They want the kinds of controls that exist in most enterprise software, but which are oddly lacking in some social software, perhaps due to the consumer roots a lot of it has. For example, the ability to control the exact type of access every individual has (can they publish, read, delete, etc.), the ability to allow that access to vary based on some sort of group or role-based permission-setting from individual to individual, auditing, and so on. Like I said, this is vanilla stuff for the enterprise world.

What can you do with such controls?

Once you have the proper controls, it’s easy to host everyone out of a single community. Here are some specific examples of how Helpstream uses this kind of functionality:

• Both outside-facing and internally-facing community content: It’s easy to be confident that the two are not being comingled inadvertently. It’s equally as easy to promote comingling when it suits.
• Special private communities called “VIP Rooms” for customers: We use these when discussing issues that need to remain private, while leaving the other discussions public so everyone can benefit from them. VIP Rooms are also extremely useful during the go-live period to facilitate communications between the two teams involved in the project.
• Private collaborative communities for partner companies: For example, Oracle salespeople can ask us questions in their private community about how to sell our joint solution.
• Customer Use Cases: We have a variety of customer use cases that involve collaboration between subgroups of various kinds where some of the information is public and some is private. There are lots of use cases around creating special classes of users that need fairly specific permissions about what they can do or see. For example, many of our customers have “Super Customers” that often have some service agent-like permissions granted so they can help out around the community.

There are many more use cases where these controls are important on a daily basis. Make sure you are selecting software that is facile with managing this sort of thing. Your non-social enterprise software has all the right ideas, make sure your social software takes advantage of them!