Tag Archives: location

Fifth Annual Enterprise 2.0 Conference Illuminates Current State of Social in Organizations

Milestone birthdays customarily spark reflection on the past and future of the celebrant. The Enterprise 2.0 Conference celebrated its 5th birthday last week with a solid program of pre-conference workshops, keynote speeches, and breakout sessions. The event, as always, provided attendees with a good feel for both the current state, as well as the future, of enterprise social software, networking, and business. This post will focus on insights, gleaned from the conference, about the here and now of social in the enterprise. A subsequent post will address the implications for its future.

Practice: A Bias Toward “How”

An early observation from the Enterprise 2.0 Conference was that several of the most visible “doers” of enterprise social were not participating this year. Dion Hinchcliffe, Gia Lyons, and David Armano (among others) were too busy helping customers plan and deliver enterprise social initiatives to attend. Their absence is, of course, a positive indicator of the current interest in, and embrace of, social activity in organizations.

Those who were at the conference also voiced a bias toward action. One of the most commonly heard pieces of feedback on the event was that the content focused too much on selling and justifying the concepts of E2.0 and social business. Attendees were looking for more information and knowledge about how to use social to successfully achieve business objectives. To paraphrase one attendee’s tweet, we get why, but thirst for how.

One tell-tale sign of this sentiment was the prevalence of the topic of adoption in informal conversations, despite it’s (intentional?) exclusion from the official E2.0 Conference program. Perhaps the early adopters who have attended multiple iterations of the conference have largely moved beyond adoption concerns, but the fresh faces at the event have not and asked for more of the kind of guidance provided in the pre-conference Practitioner’s Black Belt workshop.

Another indication of the need to understand how, as opposed to why, was the enthusiastically positive reactions to the conference sessions that dealt with topics such as organizational design and behavior, leadership, and performance management. Past E2.0 Conferences have conveniently put forth organizational culture as a bogey man standing in the way of adopting social behaviors and tools, without offering ways to affect cultural transformation. Several of this year’s sessions addressed concrete aspects of organizational change management. Most notable were the remarks delivered by Cisco’s Jim Grubb, Sara Roberts of Roberts Golden, Electronic Arts’ Bert Sandie, Deb Lavoy from OpenText, Amy Wilson of Wilson Insight, and Altimeter Group Fellow Marcia Connor.

Technology: Focus on Integration

It was clear before the conference even began that the topic of integration of newer social technologies with well-established enterprise systems would be front and center this year. While that topic was in the spotlight, the current lack of meaningful integration stood out against the talk of plans to integrate enterprise social software with other applications, systems, and business processes. The harsh truth is that the current crop of enterprise social software is dominated by stand-alone applications and suites – collaboration destinations that are not in the flow of work for most and that have created new silos of information and knowledge in organizations.

Enterprise social software vendors have begun to build and offer integrations between their systems of engagement and established systems of record (to use Geoffrey Moore’s crystal-clear terms) such as Enterprise Resource Planning, Customer Relationship Management, and Enterprise Content Management. However, most of these integrations assume that the social application/suite will be the place where people do the majority of their work. Data and information from other enterprise systems are brought into the social layer, where it can be commented upon and shared (socialized) with others. This flies in the face of reality, as evidenced by the limited success of enterprise portals deployments intended to create a personalized aggregation layer sitting on top of existing enterprise systems. People want to communicate and collaborate with others in the original context of specific business tasks. Accordingly, social technology should be embedded (or, at least, exposed) in the systems of record where decisions are made and business process activities are completed, not the other way around.

It was interesting to observe that the need to integrate with systems of record was primarily voiced by enterprise social software vendors exhibiting at the E2.0 Conference. Those vendors claimed that their customers are demanding these integrations, but the topic did not prominently appear in customer-led sessions or conversations. Only one system of record was universally identified as a critical integration point – Microsoft SharePoint. This observation seems to underscore deploying organizations’ preference to communicate and collaborate directly in systems of record.

There was also much discussion of the need to integrate social into business processes themselves. A prominent theme from the E2.0 Conference was that enterprise social software can, and should, support specific business processes to make them more transparent and efficient. Presentations and vendor demos at the event revealed that the current generation of enterprise social software can effectively speed resolution of process exceptions through expertise location and engagement features. However, integration with normal business process activity is essentially non-existent in most enterprise social software offerings, and the vision of social process support remains unfulfilled.

Summary

The 2011 Enterprise 2.0 Conference Boston was a very well run event that provided attendees with a fairly clear picture of the current state of enterprise social practices and technologies. It is clear that practitioners are past experimenting with social concepts and technologies and have moved on to applying them in their organizations. However, it also clear that practitioners need more information on how to organize for, lead, and incent social business practices. Social technology adoption remains a key concern for the second wave of adopters.

Over the last 5 years, enterprise social software has matured and added functionality needed to build comprehensive, enterprise-ready systems of engagement. However, integration of that functionality into the flow of work – within traditional enterprise systems of record and business processes – has yet to be achieved. It will be interesting to see if that marriage of social and transactional systems can be accomplished. If it can, we will have created next-generation technology that supports a new, better way of working.

This entry was cross-posted from Meanders: The Dow Brook Blog

Advertisements

Filtering in Social Software: Protective Bubble v. Serendipitous Awareness

Bubble Boy DavidThere was an interesting conversation on Twitter yesterday about the personalization of information via algorithm-based filters. It was started by Megan Murray, and Thomas Vander Wal, Gordon Ross, and Susan Scrupski quickly joined in with their viewpoints. Rachel Happe and I were late to the conversation, but we were able to interact with some of the original participants.

.The gist of the conversation was that some consumer social services (i.e. Facebook, Google Search, Yahoo News) have gotten rather aggressive about applying algorithms to narrow what we see in our personal activity streams. As a result, we aren’t able to see other information that might be useful or entertaining in our default view; we may only digest what the algorithm “thinks” is important or relevant to us. Or we must switch to a different view to see additional information (e.g. Live Feed v. News Feed in Facebook). Even worse, in some cases, the other information is simply not available to us, because the service doesn’t provide a way to override the algorithm that excluded it.

It was also noted in the Twitter conversation that the current crop of enterprise social software lacks sophisticated personalization facilities. In fact, it works the opposite way of consumer social services; the entire activity stream is usually exposed to an individual, who then has to narrow it by manually selecting and applying pre-defined filters. IBM, Jive, NewsGator, and others are beginning to use algorithms to include certain status events and updates in the stream, and to exclude others, but their efforts will require fine tuning after organizations have experimented with these nascent (or yet-to-be released) personalization features.

The default view of an enterprise activity stream should be highly personalized to the context in which an individual is working (e.g. role, business process, location, time, etc.) Optional views should allow individuals to override the algorithmically chosen results and see information relevant to a specific parameter (e.g. person, group, application, task, tag, etc.) Finally, an individual should be able to view the entire stream, if he or she so desires.

Why is the latter important? It introduces serendipity into the mix. Highly personalized information views can increase productivity for an individual as they do their job, but at the expense of awareness of what else is occurring around them (I wrote about this earlier this week, in this post.) This condition of overly-personalized information presentation has been called a “filter bubble”. The bubble is a virtual, protective barrier against information overload that is analogous to a plastic enclosure used in hospitals to shield highly vulnerable patients from potential infections.

Organizations must consciously balance the need to protect (and maximize the productivity of) their constituents from information overload with the desire to encourage and increase innovation (through serendipitous connection of individuals, their knowledge and ideas, and information they produce and consume.) That balance point is different for every organization and every individual who works in or with it.

Enterprise social software must be designed to accommodate the varying needs of organizations with respect to the productivity versus awareness issue. Personalization algorithms should be easily tunable, so an organization can configure an appropriate level of personalization (for example, InMagic’s core Presto technology features a “Social Volume Knob” that allows an an administrator to control what and how content is affected by social media. Different kinds of social content from certain people can carry different weight or influence.) More discrete, granular filters should be built into social software so individuals can customize their activity stream view on the fly (I made that case, just over a year ago, in this post.) A contextually personalized view should be the default, but enterprise social software must be designed so individuals can quickly and easily switch to a different (highly specific or broader) view of organizational activity.

What do you think? Should personalization be the default, or applied only when desired? What specific filters would you like to see in enterprise social software that aren’t currently available? What role does/could portal technology play in the personalization of organizational information and activity flows? What other concerns do you have about information overload, filter bubbles, and missed opportunities for serendipity and innovation? Please weigh in with a comment below.

This entry was cross-posted from Meanders: The Dow Brook Blog

Image © 2003 Texas Children’s Hospital

Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns

In my last post, I examined whether or not Enterprise Social Software (ESS) is the functional equivalent of enterprise portal applications as they existed ten years ago. My conclusion was:

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgment, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

In this post, I will focus on the observation that ESS resembles enterprise portals in another regard – how and why it is deployed.

Enterprise v. Smaller Deployments

Portals were initially marketed as a tool for enterprise-wide communication and interaction, with each internal or external user role having its own personalized set of resources available in the user interface. While there were some early enterprise-wide deployments, portal software was deployed far more often at the functional level to support specific business processes (e.g. sales, procurement, and research portals) or at the departmental level to support operations.

Enterprise social software has also been touted as most valuable when deployed across an organization. However, like portal software, ESS has most often been deployed at the functional level in support of activities such as marketing, customer service, and competitive intelligence. As a result, the promised network effects of enterprise-wide deployments have not been realized to-date, just as they were not with most portal deployments.

Internal- v. External-Facing Deployments

Most early portal deployments were internally-focused, as shown in this InformationWeek summary of market research conducted in 2001. Not only was there a smaller number of externally-focused deployments, mixed-audience deployments did not begin to appear until the portal market was extremely mature. ESS deployments have followed this same pattern, and we are just now seeing early efforts to blend inward- and outward-facing business activity in common ESS environments.

Internal Use Cases

Portal software was often deployed in response to a specific business need. Among the most common were:

  • intranet replacement/updgrade
  • self-service HR
  • application aggregation
  • document/content management
  • expertise location
  • knowledge sharing
  • executive dashboards

ESS has been deployed for many of the same reasons, especially intranet replacement, application aggregation, expertise location, and knowledge sharing.

External Use Cases

Portal software was deployed externally to provide self-service access to corporate information. In some cases, access to selected application functionality was also provided to key business partners. Retail and B2B portals enabled customers to purchase goods and services online. Process acceleration, revenue growth, and cost reduction were the key business drivers behind nearly all external portal uses.

ESS doesn’t seem to have the same goals. I have seen some, but little, evidence that external communities are being leveraged to accelerate business processes or reduce costs. Peer support communities are a good example of cost reduction via ESS. The goal of most outward-facing ESS deployments seems to be customer engagement that translates (eventually) into increased innovation and revenue for the deploying organization.

Conclusions

ESS deployments today strongly resemble portal projects that were undertaken ten years ago. Few, if any, ESS deployments have been enterprise-wide. Instead, ESS is deployed to many of the same department and functional groups, to support the same business processes, and to drive many of the same business results as portals were a decade ago (and still are.)

What does this commonality with early portal deployments mean for ESS? I will examine that in my next post. Until then, I would love to hear your reaction to what I have presented here.