Enterprise Collaboration Education

My previous post talks about enterprise social software and my theory for slow adoption. Basically, as long as enterprises use email as the de facto collaboration standard, we will not see the growth or benefits of truly collaborative platforms.

To expound upon that point, look how humans collaborate outside of the knowledge workers' enterprise. Collectively working on a task does not imply a serial process. In fact, parallel work streams are more efficient and generally more productive when a cooperative group drives an idea forward. Yet when knowledge workers coalesce to produce a deliverable, why do we still create documents in strict, structured, proprietary standards with little flexibility for parallel processing?

My take on an ideal content management, knowledge management, enterprise social collaboration platform is probably pie in the sky. You can incorporate all the profile, following, "Like" button, activity stream, Facebook-like, status update, blogging, wiki, odds and ends since that's what people expect. Of course there is a document dumping ground to provide a web-based front-end for a file share. But what is really needed is online, real-time, editing of content by multiple people simultaneously in a more free-form forum that allows for the manipulation and aggregation of the information in a - or many - customized template for extraction. Sound like a mouthful of impossibility?

This blog you are reading is dynamically generated from the content posts and all the other links and widgets populating a template called on demand as you navigate to this site. This page does not exist in its entirety in the view you see now (save for on caching servers perhaps). That fundamental principle is what we as document creators and consumers need to grasp. Our documentation does not need to live in a neat file format stored away ready for portability should the need arise. Instead, it should be created on-demand and only when there is a demand for the information. Furhtermore, the type of demand (status report, final deliverable) could also determine the amount and/or order of the content presented.

I've done this many years ago eliminating useless network documentation that cataloged switch and router information like serial numbers and part numbers. The information was needed, but was also accessible via SNMP. A script to collect the information and present it in a tabular format was much more useful than maintaining a static document that begged for constant care and feeding when network changes where made. In effect, we used the network itself as a database and the script was a query launched against the database. The information was guaranteed accurate to represent current state as the network itself created the documentation dynamically.

If we've mastered this dynamic documentation skill in some instances, why not where it really matters - on the day to day tasks of creating documents, status updates, statistic and metric correlating reports, presentations and any number of other creative processes that yield static self-contained information in a structured format not readily available for parsing, sharing or collaborating? The short answer is because no solution exists in a nice package. The real answer is because no one is asking for it - content to collaborate content with email