Tag Archives: process

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

TIBCO Launches tibbr and Demonstrates the Difference Between Social Business and Enterprise 2.0

There has been a debate raging for a couple of months now on whether there is a difference between “Enterprise 2.0” and “Social Business” and, if so, what it is. The debate began concurrently with the Enterprise 2.0 Conference, held in Santa Clara, in November 2010. I weighed in then with my take in this post. Since then, the debate has moved over to Quora, where someone asked, “What are the distinctions between Social Business and Enterprise 2.0”.

In spite of all this discussion, it was not until today that the difference between Enterprise 2.0 and Social Business truly became clear to me. The event that triggered my new-found understanding of these terms was the launch of tibbr, TIBCO’s “social computing tool”.

As TIBCO Chairman and CEO Vivek Ranadivé explained during the launch event, tibbr was built to deliver the right information, to the right people, in the right context. A noble goal indeed. tibbr takes advantage of TIBCO’s well-honed expertise in the management of real-time messaging at scale, their extensive library of enterprise system adapters, and a real-time rules engine that creates context for content.

Note the discrepancy between Ranadivé’s statement and the actual focus of the tool. tibbr is all about systems integration and message delivery; people are incidental objects in the system. This is intentional, as stated in TIBCO’s press release on tibbr:

“tibbr breaks business users free from one-dimensional social tools that focus on people…”

Ram Menon, EVP Worldwide Marketing at TIBCO further underscored the notion that tibbr is not about people relationships in two remarks. In the first instance, Menon described tibbr in terms of “process, subjects, applications, and people”, literally in that order. Later, Menon said that within tibbr, one “can follow people, but most importantly [textual emphasis mine, but reflects his vocal inflection]…can follow applications, can follow data.”

Do you see it? tibbr is the poster child for Enterprise 2.0, as it was originally defined by Professor Andrew McAfee. tibbr is literally about applying Web 2.0 technology design principles to enterprise systems. Social Business, on the other hand, puts people first – before applications, processes, and subject entries in the corporate taxonomy. The difference could not be clearer.

Yes, one can follow another individual in tibbr. However, as Jon Scarpelli, VP of CIBER’s Outsourcing Practice recounted during the launch event, his company switched from Yammer to tibbr because CIBER employees were “more interested in following subjects”.

My point? Social Business is about people first. Enterprise 2.0 is primarily about technology that enables business processes (or, more accurately, barely repeatable processes and process exceptions) via human interaction. Both are valid and valuable approaches to structuring and running an organization, but it is critical to know which one your company values most. Does it want to be a social business that emphasizes and connects people, or an entity that uses Web 2.0 technologies to achieve business goals when rigid, transactional systems can’t help? Answer that question first, then choose your technology solution.

Social Business Transformation: Focus on Small, Not Sweeping, Change

“…transformation happens less by arguing cogently for something new than by generating active, ongoing practices that shift a culture’s experience of the basis for reality.” — Roz and Ben Zander, The Art of Possibility

The recent debates, at the Enterprise 2.0 Conference and in the blogosphere, about E2.0 and Social Business have made one thing clear to me. Too many of us dwell on the transformative aspects of social business. Myself included.

This is likely so because most organizations value other things more highly than their people and act accordingly. Their behaviors cry out for transformation to those who envision a better way of doing business.

However, achieving sweeping transformation of the way that people are considered and treated is the wrong goal for most organizations.

It is important to remember that not all companies wish to transform themselves into social businesses, much less anything else. In fact, most begrudgingly embrace transformation only when they are forced to do so by changes occurring around them.

Instead of concentrating on “big bang” transformation, we should seek to make a series of small changes to a business’s people practices and systems. In other words, leave the organization alone. Do not focus social change efforts directly on organizational structure or culture.

It is more effective to address specific policy, process, and technology problems at the individual or role level. Let those snowflakes of change add up on top of each other to create a snowball that, when put in motion, will continue to grow until it becomes an unstoppable force. Measure impact in the same additive manner instead of seeking the big, single instance of benefit favored by traditional ROI analysis.

Wondering where to start introducing social practices and technologies in your organization? Look around. What specific challenges are customers, employees, and partners turning to each other to overcome? How are they finding someone who can help, and how are they interacting once they have identified that person? How is what they have learned shared with others?

Now imagine and investigate ways that your organization can help all of its constituents work together to solve those problems faster and less expensively. Be sure to consider technology that enables this, but do not forget to examine policy and process changes that could help too.

That is the way to improve your organization while recognizing and supporting its existing, inherent social nature. Forget about large-scale transformation. Focus instead on using people power to solve specific problems and challenges that, while small by themselves, add up to a significant gain for the business when addressed and overcome.

Enterprise 2.0 or Social Business: Who Cares?!

As you may have already observed, the debate about what label to attach to the renewed focus on people in the business world has been rekindled this week, in conjunction with the Enterprise 2.0 Conference. While I will address the label question here, I do not intend to get mired in the debate. Instead, I will focus on whether or not the” people matter” movement should be described with tool talk or addressed in a more holistic fashion.

First, the label. I do not care if you call this renewed focus on people and the connections between them in the business world “Enterprise 2.0” (E2.0), “Social Business”, or anything else. The value to be gained from connecting people within and between organizations is to be found in what’s accomplished as a result of doing so, not in what the notion is called. Sure, it is helpful for the movement to have a lingua franca with which to “sell” the vision to business leaders. However, a consensus label is not necessary. A clearly articulated, holistic approach and value proposition are required.

So forget the label. Instead, focus on the substance of what we (those who believe that people matter in business) are presenting to organizational leaders that are more concerned about traditional issues like process efficiency and financial performance.

Now, on to the real debate. In his latest blog post, Andrew McAfee continues to insist that the message needs to be tool-centric. He says that we should address executives in phrases such as,

“There are some important new (social) technologies available now, and they’ll help you address longstanding and vexing challenges you have”

The movement is not just about tools. In fact, the tool-centric focus to-date of E2.0 is a primary reason why the movement’s core message that people matter has not reached the C-suite, much less sway their thinking. To suggest to a senior executive that the only way to better their organization’s performance is through the application of technology is simply, well, simplistic. We need to discuss all of the levers that they can pull to change the way their organizations consider, enable, incent, and interact with customers, employees, and partners.

To succeed in transforming an organization, leaders must change and communicate what is valued and how people are rewarded for applying those values while attaining stated goals and objectives. We must show those leaders that modifying organizational values to include (or increase) the importance of people to the business can lead to tangible increases in revenue and decreases in operating cost. The benefits statement does not need to be presented as an ROI analysis; anecdotal evidence from efforts within the organization, or from other entities, should suffice. And, yes, technology should be presented as an enabler of both the change effort itself and the new value system guiding the organization.

And one more thing. This movement, however we choose to label and describe it, is NOT a revolution. Senior leaders fear and shun revolutions. So avoid using that word when selling the vision. We are not advocating the overthrow of existing enterprise organizational or IT systems. Instead, we seek to convincingly demonstrate that augmenting the existing ways of conducting and managing business with a complementary, people-centric approach can yield substantial benefits to those organizations who do so. Do not preach revolution; instead, suggest specific actions that leaders can take to better connect people in and outside of their organization and show them the kinds of results that doing so can produce.

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.

Enterprise Social Software: The Second Coming of Enterprise Portals?

Enterprise Social Software (ESS), at first glance, is eerily similar to the portal software that was the hot enterprise toolset 10 years ago. That became very clear to me during the Enterprise 2.0 Conference in Boston last month, even though I was only able to attend the first 2 (of 4) days of the event.

I have noticed and commented on the parallels between the portal software market as it existed a decade ago and today’s enterprise social software category in a previous post. However, the notion of their similarity was reignited by a comment that I overheard as I walked through the exposition space at this year’s E2.0 Conference. One individual said to his companion something to the effect that if the branding was removed from each vendor’s ESS demo, one would be hard pressed to say which offering came from which specific provider. In other words, there was very little differentiation of user interface (UI) layout or functionality. In fact, every screenshot and live demo that I saw looked like a portal, in that the UI was a collection of data and unstructured information aggregated into a single interface and presented through a number of widgets.

Similarities in Functionality

In 1999, Delphi Group published a portal architecture diagram, which depicted the layers of functionality that the firm thought were required of a robust enterprise portal solution.

Examining each layer of the portal architecture model and commenting on its applicability to ESS as it exists today will allow us to determine whether ESS really is just another incarnation of portals or if there is something significantly different being offered.

Presentation: In portals, data, unstructured content, and application functionality were  aggregated from multiple sources and presented in widgets, whose layout on the screen was usually customizable by individual users. ESS strongly mimics this UI design, including, in some cases, the ability to customize which widgets are displayed. Most ESS providers are beginning to offer application stores stocked with widgets that can be run in their offerings, exactly like portal software vendors rolled out portlet libraries for their users a decade ago. Finally, portal access on mobile devices was big deal 10 years ago, as is mobile access to ESS functionality today. So portals and ESS certainly appear to be the same.

Personalization: The primary value-add of portal software, in addition to it aggregation capabilities, was its ability to personalize (and, thus, filter) information based on a user’s unique digital identity and organizational role. ESS needs to improve vastly in this area; currently, most information must be manually filtered. This typically occurs via selection of one or more parameters ( to narrow the organization’s activity stream) or by following an individual, group, space, or tag. ESS should apply more profile information and use heuristics to dynamically effect what information is applied on an individuals dashboard or home page.

Collaboration: Some portal deployments embedded collaboration workspaces or their individual elements (IM or chat, discussion forums, polls) into the UI, but, in general, most deployed portals fell short as full-fledged collaboration tools. ESS is a definite improvement here. The array of available collaboration tools is richer and they are more usable, which results in higher adoption.

Process: There was a lot of ink spilled about process portals, but the promise was never fully realized, although there were some exemplary deployments. Process portals had workflow (BPM) either embedded directly into the portal technology or available though an integration with a stand-alone process engine. Similarly, there has been much talk about the need to process enable ESS. The good news is that we might actually execute on the vision this time around. We are beginning to see process-related notifications generated by applications integrated with ESS appear in activity streams. The next step will be to add lightweight activity and information coordination functionality (not full-blown, rules-based BPM) to ESS.

Publishing & Distribution: Portals were (and are) used to publish links to documents, syndicated content, and web clippings. ESS is also used heavily to publish and distribute content and goes well beyond what was possible in portals 10 years ago by adding additional content sources such as status messages, shared bookmarks, blogs, and wikis.

Search: Despite the push nature of information flow in portals, the ability for individuals to find and pull information was also very important for portal users. Search is equally important in ESS and, generally speaking, has under-performed, as it did in portal implementations. So, unfortunately, the similarity in this aspect between portals and ESS is negative in effect.

Categorization: Taxonomies were widely used in portals deployments to aid information personalization. They are still important in ESS, but their new relative, Tagging, is equally valuable in its ability to aid information personalization, browsing, and recall. We now have more tools at our disposal to apply to the information overload challenge than we did 10 years ago.

Integration: Integration of other enterprise applications and content sources was key to realizing the value that portals offered through their ability to aggregate information into a single interface. Portal integration was accomplished using a combination of hard-coded connectors, XML, and JSR-168/WSRP standards. The ESS value proposition also seems to be closely tied to the integration and aggregation model. However, ESS makes better use of defacto integration standards, including REST, RSS, and OpenSocial.

Conclusions

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 judgement, 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.

Are there similarities in deployment patterns between ESS and portal software as it existed 10 years ago? If so, what do the functional and deployment affinities between the two software categories mean for the evolution of the ESS market? I will attempt to answer those questions in my next post. Until then, I would would appreciate any comments or questions you have on my analysis of their overall functional likeness and differences.