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?”
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.
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
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.