One of the key differentiators between the community solutions developed by Jive Software and those from IBM and Microsoft (talking Sharepoint rather than Yammer) is the relative lack of focus on the requirement for document management.
That’s not to say that Jive platforms do not allow the sharing and management of documents – far from it – but that instead, these are simply embedded within the standard content types and information architecture of the platform rather than treated as a specific pillar of the platform itself.
Just as a user can create a native Jive document or discussion, so they can upload a file (e.g. a Word document) that can be previewed, downloaded, commented on, updated by others and managed from a version perspective. However, these files do not have a hierarchy beyond the place containers they reside within – there’s no concept of folders or libraries for instance. Files are primarily stored within Jive documents (or can be attached to other content types), and are managed using the same tags and categories that apply to all other content.
At the end of the day, in Jive communities, files are just one of the many ways in which users can collaborate. In many situations they are actually discouraged – group and team work can be much more effective when using native content types than when having to deal with the upload/download of sizeable files, the need for compatible editor support and so on.
This differs from IBM Connections in a pretty significant way…
File sharing was added to the IBM Connections product back the 2.5 release in 2009 alongside Wikis (back when it was still badged as Lotus Connections).
Initially, IBM seemed to envisage this support as being intended for lightweight social file sharing – the file management features were limited, meta data was very simplistic and all files were shared at a single level, relying on tags to provide any structure required. Right from the first implementations of Connections 2.5 it was pretty clear that this was not going to be enough for most IBM customers. Whether because users were typically migrating from Lotus Quickr or Domino Team Rooms, or because Connections customers tended to be large enterprises that had become conditioned to heavy use of document and content management platforms, users were adamant that they needed hierarchical storage architectures, heavy-duty file meta-data, complex library permissions and so on.
IBM responded to these demands by steadily adding more features to the Files feature in subsequent Connections releases. From the Windows Explorer connector to allow direct browsing of files from the desktop, through folder support (firstly for standalone files and then within communities), then the addition of industrial-grade Connections Content Manager (CCM) file libraries (built on IBM FileNet), to document editing and preview in IBM Docs and so on. Looking at the Connections portfolio from the outside last year, it seemed as if almost every new Connections feature and enhancement was somehow related to the management of files in the platform! (I’m sure that wasn’t the reality, but that was how it read from the press releases and announcement letters.)
Personally, I find this difficult to comprehend (and I’ve had long and passionate discussions with both IBM product managers and IBM partners about this topic). I find files (particularly Microsoft Office documents) to be fine for point-in-time exports of collaborative content, workflows or decisions, but they are not supportive of productive team or community thinking, discussion or working in a general sense.
There are, of course, situations where files are necessary – for example a creative team working on an image or video that needs to be shared outside the organisation, or a finance team working on a complex report. However, in the vast majority of situations, my personal belief is that the content should be stored in a native form in the best application to support the act of working together around that information, decision or process. For most general knowledge work, that should likely be a native document, question or discussion in the collaborative platform, rather than a proprietary file that then needs to be managed as a separate entity. In addition, I continue to propose that folksonomy almost always beats taxonomy when it comes to collaborative use cases, and therefore that tags and categories are more appropriate ways to manage information than hierarchical folders.
Sadly, but probably inevitably, I seem to be in the minority on this discussion. So many people (particularly those in their 30s and 40s) remain so subconsciously wedded to the concept of their knowledge being stored in a collection of files in a hierarchy of folders, all still named with long-unnecessary legacy three-character file extensions. It’s these folks that are demanding that IBM support this out-dated means of working within Connections, and thus it’s perfectly understandable that IBM is responding by supporting this left-over 1980s paradigm within Connections.
Why the difference between IBM and Jive customer demands?
Interestingly, in my time as a Jive Software strategist, I was rarely asked for similar file management features within Jive-n communities, whereas when working with Connections the requirement came up in virtually every workshop. There seemed to be a general understanding that a change in work culture was required in their organisations, and thus the deployment of a new community was more than simply a new platform, it required users to adopt new practices and work styles.
A second factor that often came into play is that most Jive customers also had another document management solution in place, whether for specific use cases, or for general access across the organisation – usually this was Microsoft Sharepoint. Typically this was universally detested by the users – described as unintuitive, hard to manage and impossible to search – but provided enough functionality that it could be left to handle the specific use cases where large-scale file storage was required. This is less common in the IBM world where Domino is more common as the legacy team collaboration platform, and where Sharepoint can sometimes be seen as the enemy. That’s not to say that I would propose anyone deploy Sharepoint specifically for document management (there are better tools out there if that is what is required), but simply that ‘good enough‘ is sometimes all that is needed for specific use cases that cannot be supported yet in the common collaboration platform.
But what if I want document management in my Jive community?
All that said (and I really do hope and believe that file management will no longer be an issue in 5-10 years time), it is good to have options and alternatives – no matter what your community platform of choice. Therefore I am pleased that there is a new option for Jive customers… fme Document Manager for Jive.
This partner extension for Jive, gives a brand new way to explore your files stored in the community, allowing documents to be found more quickly, files to be uploaded in bulk, inline metadata editing and direct support for almost all office applications (rather than just Microsoft Office). This 10-minute demo video covers it well:
As I made clear above, I would love us to look to transition away from formal file and document management as our primary technique for collaboration. However, if this is still required for your use cases, then do take a look a fme’s product datasheet and contact either myself or fme direct if you need more info or to discuss the options available.
Thinking of launching your own online ESN or external community?
First of all, consider each and every requirement as an individual use case, that requires its own definition, configuration and community management. As part of the definition process, one of the key discussion points is to look at how the business processes and workflows can be best supported in the community – what content types, functionality and user interactions are required. Only once these aspects are understood then look at what content types and/or files are required…
If formal document management is a necessity, then that ‘s the point at which to start considering whether something integrated like CCM or the fme solution is required, or whether those specific use cases would be better supported on a more formal and structured platform.
How do you approach this topic? Are you an advocate for document management, or do you believe that more open and unstructured collaboration is the correct approach? I’d love to hear from you in the comments below…
So why this now? The future is bright, but is it not always that bright? Would we want to go forward if the future was bad? So I am a realistic optimist, we need to start to iterate. To take baby steps. It’s not just tools, it is also about people who need to change, too. But that takes time. In the mean time, it should become easier to collaborate. It should be a goal to break the unnatural boundaries of the current products out in the marketplace (and yes, I dream of looking beyond the “one” supplier). The current boundaries make it hard to see how this will end up.
When you ask adoption consultants what the problem is most of them will tell you that it’s a training and habit problem. So you just need to educate people more, teach them where to do their tasks more efficiently and how to collaborate more efficiently. Thus the movement of “Zero eMail”. But lots of tasks still happen in e-mail and people just have plain bad habits. But to be honest, the tools to communicate and collaborate don’t help you… In the last 5 years we have seen more and more options to collaborate to work differently. And yes, we just gave people yet another option to worry about, we added a channel, we called it a “social platform” (Connections). So basically we just added one more channel to their daily work habits. What do you think, did that help? It depends, it all depends on who you ask.
of exchanging e-mails with individuals, fragmenting the discussions. You can involve your whole team, they can all see and comment on work items (aka documents). Thus you build on each other’s knowledge (
So this is the context of most enterprise organizations that have started down the route to become a more social or a more connected enterprise. Some start with a clear vision of a more collaborative future of the work environment, where people can collaborate seamlessly with others, where leadership recognizes that they need to differentiate themselves from their competitors. There are different strategies to reach those goals of course. But as we all know culture eats strategy for lunch. In large organizations it is very hard to change culture . Strong leadership is needed. But even if you have strong leadership and a great vision of the future, even if that’s there that’s not a recipient for success. Why? Well leadership changes. The change of culture is difficult. The payoff takes a while. Value is not immediately apparent. People resist change. And tools are flawed. But, but, but, in time this will all be fixed. If we just switch to a tool that works? Or it will work the tools will become better and work seamlessly. Tools are simple to change, it is just the technology. And then people will see the benefit in the end and start working differently. And while this is all happening around us, people suffer. They are faced with an ever growing multitude of tools and choices. Choices they have to make. People have become the “integrators” between all the tools for their new way of working. And most enterprises fail to implement this better future effortlessly. Simply because you need long term leadership in place and that’s not the way most companies are built. It’s about short term and immediate return.