Enterprise 2.0

Reinventing the modern workplace

• Defining Enterprise 2.0 : Emergence

  17 Oct 2007 by Gordon / 8 Comments

  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…

   

   

  Continue Reading

• The Distributed Team

  12 Oct 2007 by Gordon / 1 Comment

  I enjoyed reading the Socialtext response to Assembla’s piece on why distributed teams are great.

  When it comes to distributed teams, I’m more in the ‘suck’ camp, than the ‘rule’ camp.

  From my perspective as a developer, and a manager of development teams, I think that the biggest problem with distributed teams is idea decay.

  Once somebody has a thought in their brains, most of us need to get it into another brain quickly to validate it. The quickest known route, even in our super connected “universe 2.0″ is:

  brain>mouth>ear>brain.

  Instead, if you have something like:

  brain>fingers>keyboard>XMPP>monitor>eyes>brain

  there are too many connection points. People seem to somehow sense that they are more inhibited, and they don’t end up sharing as much. Or good ideas seem to never make it across the wire.

  This is a challenge for people who are making software – but it’s also more of a challenge for people who are developing business systems. As good as the latest collaborative tools may be, they still aren’t close to co-location for maximizing the innovative process.

  When you’re trying to figure out the best way to solve a business problem, it’s probably worth bearing this in mind. (like lots of nerds, I automatically try to solve problems with technology. Sadly, sometimes – low-tech is better : )

  Continue Reading