Defining Enterprise 2.0 : Emergence
Jim McGee has a well worth reading post about emergence and its importance in enterprise 2.0. He contends that:
“In some respects, “emergence” is a fancy organizational development word for “messy.” The more our systems must deal with the complexities of the real world, the messier they must be to accommodate that messiness.”
There’s definitely some truth to this. Part of the appeal of these “2.0″ technologies comes from the fact that they are easier to adopt and less rigid. The innate flexibility of tools like del.icio.us and flickr is an important part of their acceptance and appeal. Billy Cripe also weighs in with his idea of where to find the ROI in Enterprise 2.0:
“Don’t be a hammer looking for a nail. Someone “implementing Enterprise 2.0″ is either too high up to understand what problem is being solved by a particular approach or simply wants to impress with the latest buzzwords.“
Both of these points got me thinking about how best to define emergence and Enterprise 2.0. In order to fully understand this notion of emergence within the enterprise, I thought it might be worth taking a look at a few different models of “Enterprise Software” and how this concept of emergence affects their ability to actually improve the way that an organization functions. As an example, let’s take the following enterprise:
Figure 1: An enterprise of people with no necks.
This typical organizational hierarchy consists of various layers of management and knowledge workers performing tasks. Some of those tasks require software that is only used by specialist teams. For example, an ERP accounting system like SAP or Great Plains requires training and subject matter expertise to use effectively. Systems like these are a critical part of the modern enterprise, but they aren’t emergent, nor are they designed to be emergent. There’s not much, if anything, that additional flexibility, or ‘messiness’ can bring to this aspect of an enterprise. (If del.icio.us only allowed me to bookmark my favorite financial transactions, I doubt it would have the same appeal…)
Figure 2: Adoption of an ERP tool within an enterprise.
So we probably aren’t going to see things like Great Plains, or SAP Financials implement a bunch of Web 2.0 features (unless they get really caught up in fad-thinking).
However, not all enterprise software works like this. There is a class of enterprise software that requires that it be adopted by the whole organization. Because of my background, I think automatically about Enterprise Content Management, but the same is true for groupware like Notes or Outlook, and to a lesser extent, for collaborative systems like eRoom or SharePoint.
Let’s use the ECM example. In any organization, people have systems for managing content. Most of them suck, because they are messy, ill defined, inconsistent, and often made up on the spot. So far, the only approach to solving this has been to implement a new, improved, well defined content management system. Of course, this only really becomes effective if you can implement it across the whole enterprise – otherwise you’ve just added yet another method of managing content to a messy, disorganized enterprise. So the goal for something like ECM is this:
Figure 3: The Ultimate Goal of ECM (that’s what the E is for)
Anyone who’s tried to deploy an ECM system to an enterprise knows that this is no easy feat. In fact, I can’t think of a single enterprise where this is true. (Although I’m willing to entertain the possibility that one may exist. Maybe some of the ECM Bloggers like James and Laurence can set me straight.) In my experience, most efforts at deploying ECM within an organization end up looking like this:
Figure 4: What lots of “Enterprise” Rollouts really look like.
How did we get here? The system was sold to someone in middle management with purchasing authority, who encouraged his direct reports to use it, and maybe they did, and maybe a couple of other teams somewhere along the line jumped on board, and maybe Harold from Accounting moved teams to HR, so he uses the ECM system properly, even though his colleagues still plonk everything onto a share drive… and so on. You get the picture.
This is precisely the problem that Enterprise 2.0 can solve.
The traditional approach is to build something autocratic, and deployed from the top down, that works along vertical reporting lines. Working this way, silos of information are preserved. and communication is kept within the traditional areas.
The emergent approach is work from the bottom up, in a manner than allows the system to spread virally along horizontal functional lines. By making the system less restrictive, and easy to use the system is more likely to become the solution of choice for knowledge workers. And as they communicate better, they share information and increase their awareness.
Figure 5: An Emergent system, on the path to Enterprise 2.0 domination
It’s very elegantly explained by Euan Semple, discussing the quickest way to ‘do Enterprise 2.0′:
“Do Nothing! And then your bright, thoughtful and energetic staff will do it for you. Trouble is they will do it outside your firewall on bulletin boards, instant message exchanges personal blogs and probably on islands in Second Life and you will have lost the ability to understand it, influence it, and integrate it into how you do business.”
So, in an enterprise context, does ‘emergent’ have to mean ‘messy’?
I don’t think so. For a system to be emergent, the emphasis needs to be on how quickly the users will adopt the system rather than on its structure. That explains why a hallmark of these Web 2.0 technologies is that they are accessible and less restrictive.
I don’t think this notion necessarily precludes systems that offer a traditional structured approach to enterprise information, but it does mean that if your notion of “best practices” don’t ‘t fit perfectly with your users are actually doing, you will find that your enterprise solution won’t emerge very far at all…
Related Posts
- State of Emergence-y
- What is Emergent Software?
- Choose Your Own Enterprise
- Paul Graham on Enterprise 2.0
- Seven Aspirations for Enterprise Software
[...] a recent post, Gordon talked about deploying Enterprise 2.0 tools in an emergent way. But what about the software itself? What characteristics make software [...]
[...] talked about this a lot in the past, so I’ll try to keep this brief…How can we make enterprise software [...]
[...] spoken about this at length before, because we see emergence as a crucial property for any system that’s going to be able to [...]
[...] Gordon Taylor “The traditional approach is to build something autocratic, and deployed from the top down, that works along vertical reporting lines. Working this way, silos of information are preserved. and communication is kept within the traditional areas. [...]
[...] a huge motivator for us when we started Infovark. One of our most popular posts to date our post on Emergence in the Enterprise – a rant that was a direct result of me spending far too long as part of the Enterprise Software [...]
[...] why we’ve found that the most successful Enterprise 2.0 roll-outs tend to be bottom-up, emergent [...]
[...] why we’ve found that the most successful Enterprise 2.0 roll-outs tend to be bottom-up, emergent [...]
[...] a tal proposito, è l’articolo di Infovark che espone in modo chiaro e diretto le dinamiche di diffusione di un applicativo all’interno [...]