Interesting times at the Enterprise 2.0 Conference in Boston this week. The conference has become the core of our little but growing industry. Recall if you will that it started as the Collaborative Technologies Conference in 2005, when organizer Jen Pahlka noted in the kickoff:
Interop is the genesis of this conference, even the first shows had a collaboration thread. But most of Interop focuses on IT. Business side of collaboration is the harder problem to solve, the focus of this event and one of the goals is to credentialize the concept of collaboration.
Shortly after, collaboration emerged as a strategic imperative for enterprises. And the state of the art for solving line of business collaboration continues to evolve.
A big change from back then is the vendor sports. Susan Scrupski saw a difference in how three of the top four enterprise software vendors (IBM, Microsoft & Oracle) were major sponsors. These big companies may be the drag queens of Enterprise 2.0, and an old French proverb says "they are not free who drag their chains after them," but everyones major vendor sports (otherwise we wouldn't be reading so much about Microo).
The backchannel was particularly damning of Sharepoint compared to Lotus Connections (release 2.0 around the corner) and Microsoft got slammed again in a later panel. Sharepoint is stuck between major releases (that is, until the forced upgrade of Office 42.0), and Lawrence Liu is doing his best without a social software leg to stand on. Oracle didn't do any better or get kid glove treatment. All this made for good entertainment, but I'd take a McAfee-Davenport debate over all this.
In stark contrast to the vendor sports and paid speaking slots was Enterprise2Open. Two people tried to hold sessions pitching their companies, and the law of two feet worked against them. There were solid conversations on adoption, use cases, business cases and edge cases like gaming. It provided a pressure relief valve for the structure of the commercial event, enabling Booz Allen Hamilton and BearingPoint to share their implementation stories that didn't get on the program for example. About half of the attendees has been at a Barcamp before, some came only for this free portion of the event and while there were self-organized hiccups, participants valued the experience.
There are some things I learned to refine it. I was purposely hands off in facilitation, but there should be an available host in some sessions, particularly merged ones. Format follows space, and having a major stage for one room lead to broadcasted presentations, where by contrast the room where people naturally circled chairs was more conversational. Time was left to one afternoon, and we could have had more, as well as more concurrent sessions. Next year it may be more suited to run in parallel to the workshops and I'm looking for further feedback.
Adoption and Markets
A common thread for customers, facilitators and vendors was on adoption and culture. There were a lot of IT managers in attendance sharing the failures of their utility deployments. One open space session spent most of the time listing barriers to adoption.
AIIM research presented the results of their adoption survey in the keynote before mine. Among their findings was age doesn't matter (Boomers vs. Milennials), some early IT adopters are frustrated and those who adopted KM were more inclined towards Enterprise 2.0. Other analyst firms (Gartner, Forrester) have psychodemogaphic profiles of organizations that can aid vendors in identifying earlier targets.
- Early IT Adoption frustration comes from IT-driven deployments. Previous bottom up demand from PCs, Spreadsheets, LANs, email and instant messaging was met by rolling it out as a utility. But unlike email or IM, this isn't a communication tool, collaboration requires engagement with the line of business. IT is good at the engagement required for process modeling and hard coding structured workflows. But the unstructured and collaborative nature of these tools requires line of business leadership, partnership with IT and applying best practices that are deeper than patterns. Simply opening up a wiki utility for people to consume results in a 1,000 dead wikis.
- Generations may not matter, but they are different. While there is no doubt about the social software proclivity of NetGens, and their demand for working this way, a more blended solution needs to address all generations.
- Some of the best implementations are happening where they shouldn't. One of our favorite customers has a self-described command-and-control culture. The best sessions at the Enterprise 2.0 conference were the case studies of cultures where people get "slapped down" for sharing (the CIA Intellipedia), highly regulated (Wacovia) and security-conscious (Lockheed-Martin).
Flow and Solutions
In my talk I noted the evolution of Enterprise 2.0 use cases:
- 2002: techies for project communication
- 2004: business user alternative to email
- 2006: internal Wikipedia
- 2008: process-specific solutions
The Wikipedia-inside use case is representative of most Enterprise 2.0 implementations today, not just wikis, what Michael Idinopolus calls above-the-flow:
- In-the-Flow wikis enable people do their day-to-day work in the wiki itself. These wikis are typically replacing email, virtual team rooms, and project management systems.
- Above-the-Flow wikis invite users to step out of the daily flow of work and reflect, codify, and share something about what they do. These wikis are typically replacing knowledge management systems (or creating knowledge management systems for the first time).
Above-the-flow generally has a softer ROI, involves what can be at least perceived as a side activity and different and more difficult adoption characteristics. Adoption is closer to community building, but in the context where many forces want to work against the community. When it does succeed, and with the right practices it does, the benefits are worthwhile. But I believe that above-the-flow is less than half the opportunity for employees, partners and customers.
This is where in-the-flow solutions come in. They speak to real business problems, can be repeatably implemented and adopted with the right practices, have harder ROI and are process-specific. Making them work requires coaching and management consulting services that are rare today.
Through in-the-flow and above-the-flow solutions, use of Enterprise 2.0 tools and practices will be as common for knowledge workers in ten years as the PC is today. In 2.018, feel free to fact check me on this.
Process and Practice
Clay Shirky said business process is an embedded reaction to prior stupidity. Traditional enterprise software serves the goal of automating business process to drive down cost. I've held for some time that your average knowledge worker spends most of their time handling exceptions to process not executing it and augmenting those activities is an opportunity for social software.
Mike Gotta chatted some golden nuggets during my talk that process is the way work should be done - work practices are how work is done (localized to a given situational context ... Some processes need work practices to be precise, other processes have more elasticity ... the more elastic a process is, the greater the opportunity to apply participatory applications.
And he is right, especially about work practices, except we have to consider:
- Most processes are out of date almost as soon as they are defined because of changes to the environment
- Many processes are defined in ways that current executors can't understand and nobody knows who authored them
- Many more processes are barely written down
Broadly, software that supports work practices, implemented with best practices, enables better decisions, faster cycle and resolution times and adaptivity. I no longer believe we are headed towards an end of process (although that was a stimulating conversation). Because of social software, I do believe that we will redesign most processes with more transparency and participation -- and work practices will finally have context-aware tools that augment them and best practices will gain continual improvement through execution itself.
This post is too long