Home > Demand side research > Creating a Typology of Enterprise 2.0 Use Cases

Creating a Typology of Enterprise 2.0 Use Cases

Update: The most up-to-date version of the typology is published on p.14 of the Interim Report.

I’ll admit that when I first read the term ‘typology’ in the EC’s tender for this research project I wasn’t entirely sure what it meant. I knew it was something to do with organising things by type, but beyond that I wasn’t sure. I looked it up and found that a typology is a “classification according to general type” (http://wordnetweb.princeton.edu/perl/webwn?s=typology) or a “systematic classification of types that have characteristics or traits in common” (http://dictionary.reference.com/browse/typology). That sounded reasonable, but the thought that followed immediately was: “Is this something that can be done with enterprise 2.0 use cases?”

Prior Work

I came across two attempts to do something similar: a blog post by Bjorn Negelman explaining a classification of enterprise 2.0 use cases he created and an internal project at Headshift to catalogue and group use cases we had come across. I didn’t find either of these attempts completely persuasive: they both took the approach of trying to put the use cases into broad buckets such as ‘knowledge sharing’, ‘user engagement’ or ‘innovation management 2.0′. I felt that this was useful to an extent, but that a better approach would be to situate these archetypal use cases in a structure that spoke to something fairly fundamental about enterprise 2.0 tools.

First Attempt

After the initial research into the various use cases and a period of mulling them over, this was my first attempt at organising them:

The above attempts to define use cases by the sort of interaction they facilitate and where they facilitate them: within an organisation or between an organisation and its environment. Apart from my terrible handwriting, I didn’t think the bottom axis–degree of interaction–was quite right: one use case could contain both conversation and collaboration. The form of the representation also seemed to suggest that use cases in the bottom left are bad and those in the top right are good.

The Current Version

After discussions with some colleagues and a few more iterations I came up with this:

This representation organises use cases based on the sort of interpersonal tie they support and based on the size of the system that contains that interpersonal tie. I should point out a debt here to Andrew McAfee who first applied the idea of interpersonal ties to enterprise 2.0 (as far as I know).

I think this really does capture something fundamental about enterprise 2.0 (or at least the way I think about enterprise 2.0). Traditional IT facilitates formal processes, where the interaction is typically not person-to-person. Newer IT tools, and particularly enterprise 2.0, facilitate informal processes comprised of person-to-person connections and in so doing enable the breaking down of traditional organisational barriers.

Please do let me know what you think: have I left out important use cases? Are some of them positioned wrongly? Am I naming them at the wrong level of detail? Do you disagree with the organisation scheme entirely?

Note: I found Jacob Morgan’s collection of enterprise 2.0 case studies as well as Headshift’s own case studies useful when creating this.

About these ads
Categories: Demand side research
  1. April 30, 2010 at 6:19 pm

    Excellent analysis and a great summary diagram! I’d suggest just one more use case for the Internal-Ecosystem column “joint work”. This would extend your “supplier distributor communities” to cover: joint product work with each customer firm (typically manufacturers of complex, customized products with each of their customer firms); joint work each client (typically law firms, consultants, PR firms, accountants etc with each of their external clients).

    In the “joint work” pattern, internal stakeholders typically shares a separate space with each individual customer or client firm. Think of a law firm with a collaboration space for each of its clients – you wouldn’t want Client A to be a party to Client B’s work with the firm. However, all members of the firm typically may have good reason to see or participate across all client spaces. A law firm would need very reliable security guards to make this work.

    The relationship between an aircraft manufacturer and each operating airline customer is a good example for definition, design, production, and maintenance of complex engineered products. Like the law firm, the aircraft manufacturer and each individual operating airline would typically share a by-invitation (and secure) space to define, contract for, purchase and maintain that airline customer’s fleet. Each aircraft is a complex, individually identified engineered product with a lifetime measured in decades.

    Call this a “hub and spoke” collaboration pattern, where insiders are typically have privileged access across all spaces, but individual clients have a strong – or legal – expectation of privacy in dealing with the firm, see

    Borders, Spaces, and Places
    http://www.tractionsoftware.com/traction/permalink/Blog691

    The joint work case can be clearly distinguished from your “Internal – External customer communities” which (to me) have the connotation of communication with internal stakeholders and the set of all external customer stakeholders as a group. This would specifically include customer to customer communication and collaboration in a commons that also includes internal stakeholders.

    This commons would typically be open to the general Web, but some external customer communities might require registration or “by invitation” access. More private groups could be anything from your “alumni group” Internal – Ecosystem example to “all airline customers” of the hypothetical aircraft manufacturer (which would explicitly aim to promote a community connecting of that manufacturer’s customers and insiders).

    • May 5, 2010 at 11:11 am

      Thanks for the considered comment Greg.

      I was trying to accommodate the “joint work” use case by extending the project collaboration use case into the “internal-ecosystem” column. But actually, “joint work” should probably be a separate use case and almost certainly belongs in the “weak ties” section.

      I’m now also thinking that “customer communities” probably belongs in the “internal-ecosystem” column. What do you think?

      • May 5, 2010 at 5:21 pm

        I like your explanation to Dave in comment #8 on interpretation of “internal – ecosystem” vs “internal – external”

        “customer communities” is a loose term which could apply to either column, but which most people seem to use as shorthand for outward facing marketing and brand / product discussion.

        You’ve done a great job and put a lot of thought into the diagram and terminology, so I’ll just suggest three patterns that seem significantly different and would benefit by use of three different terms in your diagram:

        1) Internal-external: “Public brand community” or “Public product community”. Try not to use the term “customer” to clarify that no business relationship is required. Typically open to Web commons with self-registration.

        2) Internal-ecosystem: “Joint Work” could be reserved for project, product or client work with between internal stakeholders and *each* customer or client. Weak ties are common. Strong assurance of privacy to handle confidential project, product, client work. I like the term “hub and spoke collaboration” but would be happy to find a better term.

        In extreme cases external suppliers or customers work as “co-developers” of highly specialized products and strong ties would be appropriate (this seems to be more common in Japan).

        You could try to extend “Project collaboration” across the first two columns, but that would loose the hub and spoke pattern that seems important to law firms, consulting firms, accounting firms, PR firms etc.

        3) Internal-ecosystem “Stakeholder community” e.g. between internal stakeholders and an alumni group, a product user group, a distributor council, a supplier council, etc where the external stakeholders are invited and encouraged to participate with each other as well as internal stakeholders.

        Typically weak ties, by invitation with an expectation of privacy versus the public web. In business use cases this may include plans, prices, and other material covered by non-disclosure agreements.

      • May 19, 2010 at 5:54 pm

        I can’t reply directly to your reply to my reply (if you see what I mean) so I’m replying here.

        I’m going to try and incorporate your suggestions into the final version, but I think I will still group public communities with customer communities because they very often contain actual customers and potential ones. Communities that have more client involvement are perhaps better covered under project collaboration or some kind of shared awareness use case.

        On your second point, I’m going to admit the limitations of my idea and say that I think it’s covered by project collaboration still, but that I don’t want to rotate the bubble 45 degrees and have it cutting into the weak ties section as well!

        On the stakeholder communities, do you know of any actual examples of this happening in practice?

        I also think that project collaborat

      • May 31, 2010 at 7:56 pm

        Extending the width of the “Project Collaboration” and “Communities of Interest” bars to more visibly intersect the “Internal-Ecosystem” column would be helpful awa any other addition or change you might consider. When I first looked at the diagram, overlap into the second column was not obvious.

  2. May 4, 2010 at 10:10 am

    This challenge of coming up with a typology to categorize use cases also keeps my mind busy; and I like the axes chosen in the above diagram.

    Overall I think there are multiple typologies, depending on the lens or purpose you choose to categorize. Therefore it is more like defining metadata-sets to characterize use cases, to be able to retrieve them for specific purposes.

    This leads to the question: What are the “purposes”, what are the “query-intentions” to retrieve use cases? After all, when we recommend use cases to readers, they should give them an answer to their questions. Our group that organizes http://www.e20cases.org is working on understanding different stakeholders’ needs to use and learn from the use cases and design the metadata and the case templates accordingly. So this is work in progress.

    But I also agree very much that there should be a generic overview. As we are talking to businesses, I like the labels “Open Innovation”, “Project Collaboration”, because that is how businesses have organized their work (terms). When I read “crowdsourcing”, I think this is a general 2.0-principle that works in prediction markets (they can be open to externals), in customer communities, in open innovation. To say it in short, I do not have the solution, and also I thing the labels in the diagram will need quite some discussion. The point is, that borders disappear, and all becomes a mash-up of core 2.0 patterns.

    Also, I strongly agree that “joint work” so far is missing in the diagram (meaning that internal stakeholders typically share a separate space with each individual customer or client firm, and sometimes they even use various software solutions, depending on the 2.0-maturity or familiarity of the client with a project spaces; often the client has the power to determine the degree and kind of 2.0-work-pattern).

    So much for the moment …, Andrea

    • May 5, 2010 at 11:18 am

      Thanks Andrea. I agree that there are certainly other organisation schemes that you could come up with that would be equally valid and each have their own advantages and disadvantages.

      On your point about crowd-sourcing, I agree again. This is one of the challenges we face – how to disentangle the various use cases in a meaningful and useful way. We’ve tried to do that by citing ‘archetypal’ use cases but then acknowledging that they can be combined and embedded in each other.

  3. May 4, 2010 at 11:51 am

    Great matrix! There’s some heavy thinking behind this, I bet!

    However, I would say that some of the ‘boxes’ should spread accross more than one ‘internal – x’ categories :

    - project collaboration, communities of interest, collective intelligence, and others : could be done with the ‘ecosystem’ and/or the ‘external’
    - expertise location, for instance, could be extended to the ‘ecosystem’ as well, wouldn’t?
    - …

    What do you think?

    • May 5, 2010 at 11:43 am

      Thanks Xavier. Yes, you could argue that some of these boxes should be spread across various sections and, as I said to Andrea above, this is one of the hardest aspects of this sort of task.

      I don’t think it’s possible to tease apart all the concepts we’re dealing with to come up with a set of mutually exclusive use cases that have clearly definable characteristics, so I’ve tried to position the use cases where I think they are *most* useful but this doesn’t mean they aren’t useful elsewhere. For example, you could use a prediction market in a small company of 20 people where everyone is strongly tied to each other, but the archetypal use of a prediction market is where there are many people who don’t necessarily know each other.

  4. May 5, 2010 at 4:54 am

    Mike, The diagram is good and effective. The items in it should be consistent with our original list which had more items. I would use both.
    Project collaboration should extend across internal/external. Collaborative filtering should apply both to weak and strong ties.

    • May 5, 2010 at 11:59 am

      Thanks David. I don’t completely agree with this and I’m starting to think that we need to define the three columns more carefully to really know what we’re each talking about.

      I see the middle column as encompassing a company’s partners, suppliers, distributors and customers whereas the right-most column is everyone the company doesn’t have a business relationship with: potential customers, former employees, potential employees, the media etc. If that were the definition then project collaboration would extend only across the first two columns.

      On collaborative filtering, see my comment to Xavier. I think it could be useful for strongly-tied relationships, but is most useful in weakly-tied ones.

  5. May 11, 2010 at 12:22 pm

    Interesting exercise in classifying resources that… have not happened yet :)
    As I told Mike during a recent “London Wiki Wednesday” meeting, I believe there is no enough literary warrant so far. That means, beyond the librarians’ old fashioned terminology, there are not enough cases and experiences so far, as anyone can notice accessing the interesting http://eu.headshift.com/ directory.
    Nevertheless the exercise is useful for strategic reasons, policy makers and proactive marketing. In this direction I would suggest to classify the problems that are currently solved through Wikis developments: environmental monitoring, music scores cataloguing, etc etc. Nothing more that few personal notes about cases I have considered, thanks also to the EU Headshift Directory, are here: Wikis for business and semantic wikis http://brunellalongo.wikispaces.com/Wikis+for+business+and+semantic+wikis
    Brunella Longo

    I have browsed the whole directory

  6. May 12, 2010 at 3:35 pm

    Maybe an interesting observation from our interaction with SME business leaders: For our case study network, we asked two Web-Business (Start-up) Companies: “How do you work? What Tools do you use?”. They talk in “traditional” business process&applications categories and then mention the “tools & apps” (mostly cloudbased; The term “online office” was used).
    The 2.0-principles&patterns are another lens (if I get it right, you see them as archtypes which for me translates into 2.0-patterns instantiated in a real use case). They are embedded, sort of in the DNA of these “tools”, some of them are active others not. Therefore I would try to come up with a view on the above (multidimensional) diagram that would separates both these lenses.

    Here some insights into what has been said:
    HR (LinkedIn, Xing)
    Project Management (Basecamp)
    CRM, SRM, ERP, (e.g. Salesforce, Highrise, …)
    Marketing (Slideshare, Blog, Twitter, Facebook, …)
    Internal Communication and Collaboration (GMail, Skype for Chat/VideoConf, external shared storage, …)
    Website (Content Management)
    Business Intelligence (Social Media Monitoring functionalities are part of this; Market Intelligence e.g. Netvibes)
    Innovation
    Software Development (…)
    Fun&Leisure ? (e.g. Online Radio, e.g. Last FM)
    Financial

    • May 19, 2010 at 5:43 pm

      Thanks Andrea, that’s interesting. It’s certainly difficult coming up with a way of looking at this that brings enough clarity to all the concepts involved.

  7. December 2, 2011 at 8:32 am

    You, the opposite hand watch out for your points clear, concise and interesting. IпїЅпїЅm glad I have been capable of read your content regularly.

  8. August 24, 2012 at 8:25 am

    Interesting approach and really nice article, thanks for sharing… now your hand-writting is un-readable! :)

  1. January 18, 2011 at 12:50 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: