This post was originally posted on the EC enterprise 2.0 project blog.
I’ll admit that when I first read the term ‘typology’ in the EC’stender for this research project I wasn’t entirely sure what it meant.I knew it was something to do with organising things by type, butbeyond that I wasn’t sure. I looked it up and found that a typology isa “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 Headshiftto catalogue and group use cases we had come across. I didn’t findeither of these attempts completely persuasive: they both took theapproach 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 approachwould be to situate these archetypal use cases in a structure thatspoke to something fairly fundamental about enterprise 2.0 tools.
After the initial research into the various use cases and a periodof mulling them over, this was my first attempt at organising them:
The above attempts to define use cases by the sort of interactionthey facilitate and where they facilitate them: within an organisationor between an organisation and its environment. Apart from my terriblehandwriting, I didn’t think the bottom axis–degree of interaction–wasquite right: one use case could contain both conversation andcollaboration. The form of the representation also seemed to suggestthat use cases in the bottom left are bad and those in the top rightare good.
The Current Version
This representation organises use cases based on the sort of interpersonal tiethey support and based on the size of the system that contains thatinterpersonal tie. I should point out a debt here to Andrew McAfee whofirst applied the idea of interpersonal ties to enterprise 2.0 (as far as I know).
I think this really does capture something fundamental aboutenterprise 2.0 (or at least the way I think about enterprise 2.0).Traditional IT facilitates formal processes, where the interaction istypically not person-to-person. Newer IT tools, and particularlyenterprise 2.0, facilitate informal processes comprised ofperson-to-person connections and in so doing enable the breaking downof traditional organisational barriers.
Please do let me know what you think: have I left outimportant use cases? Are some of them positioned wrongly? Am I namingthem at the wrong level of detail? Do you disagree with theorganisation 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.