Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
Keeping track of your stuff
Puneet Gupta over at ConnectBeam has an interesting post about the Enterprise Knowledge market. He references an intriguing study from McKinsey:
…An individual’s knowledge is self-contained, always available. But in companies—including small ones—it can be hard to exploit the valuable knowledge in the heads of even a few hundred employees, particularly if they are scattered in different locations…
Knowledge Management as a technology discipline is one that I’ve never really been comfortable with. And it’s really only been since I started working on Infovark that I realized why — because using your computer for knowledge is like trying to get your pocket calculator to write you a love song.
Computer’s can’t actually know anything.
To your computer, that brilliantly composed document you just wrote is a bunch of bits on a disk. They are no different to the bits that make up the pictures of your cat or your operating system.
The real knowledge in your enterprise is in your colleagues’ brains. There may be a great deal of information lying around the place too, but that isn’t knowledge.
Let’s look at Twitter. Somewhere, Twitter is a collection of servers siting in a dark server room. Those computers are managing lots of bits on lots of disks. The only thing that Twitter really “knows” is how to connect blobs of data that represent people to the blobs of data that represent tweets.
So Twitter is certainly not a knowledge management system — there’s no managing of anything going on. And yet Twitter is an immensely powerful knowledge catalyst. Huge volumes of information are exchanged every minute. I learn something nearly every day by using Twitter, not because Twitter itself has much to say, but because my twitterfriends are so interesting.
Knowledge, in the Oxford English sense of “expertise gained through experience or study”, can’t be effectively stored, retained, or disposed of. It can’t be centralized or codified easily. Most attempts at knowledge management to date amount to little more than information collection and storage.
This “build a giant library of things we know” approach is a lousy way to transmit knowledge from one person to another. And distributing knowledge is the only sure way of making sure that your organization will retain it. The reason that this “social revolution” is sweeping the enterprise is that by connecting people with better communication and collaboration tools, we facilitate the exchange of information and increase the opportunity to learn.
Most people learn more things from each other than from reading a procedure manual or browsing the corporate library. They learn through on-the-job training and through discussion with their colleagues.
Let’s leave the technology to manage the bits — knowledge is for humans.
Laurence Hart over at Word of Pie calls us out on our approach to content management . Dean and I are both big fans of his blog, so we were pretty stoked to see a whole post about us.
Laurence raises a lot of valid concerns, all of which we’ve spent loads of time mulling over, and I’ll get to those in a second.
But first, to really understand our solution, you need to know how we got here. Dean and I absolutely understand where Pie is coming from. We have a long history of working in the ECM space with TOWER Software. We’ve read through countless customer requirement lists about compliance, Sarbanes-Oxley, retention, discovery and authoritative versioning. We’ve spent hours designing taxonomies, file plans, and security and access policies. We’ve drafted tender responses, and drawn large Visio diagrams. We’ve written integrations to nearly all the of ECM products in the market today.
After all this effort, once an organization deployed our tailored solution, we’d observe the same pattern. The content management software met the business needs, but it didn’t help the end users. Instead, It got in their way. It often made it harder to find things, and it made them work to understand things that they weren’t specialists in — like taxonomies and retention. User acceptance and training overheads were huge. We had to work like crazy to get people to use our carefully crafted solutions.
OK, you might say — that’s fine. Work isn’t supposed to be fun. You just do what you’re instructed to do. As long as the enterprise as a whole benefits from the solution, the content management program is doing its job.
Except that the enterprises weren’t really benefiting. The push-back from the user community meant that people wouldn’t actively use the solutions to do their daily work. Large, corporate, and eminently scalable repositories all over the world are filling up with dusty, useless content, most of which is almost certainly never going to be seen again. Traditional content management is extremely effective at preserving things. It’s terrible at solving the kinds of tactical problems that people deal with every day. Sure, retention was up. But productivity was down.
(Pie knows this. That’s why he talks so much about invisible, or transparent ECM . Because yes, preserving things is important, but knowledge workers don’t care.)
So, when we started Infovark, we set out explicitly to solve the other problem. The people problem. The fact that people couldn’t connect and share with each other. We decided to build an enterprise product that people would want to use, first and foremost. The capture and retention come second. The point of a transaction is not to get the paper receipt.
OK, that’s where we came from. Now to answer some of Pie’s more technical questions:
Groove is a disk hog. Transferring files from a peer through a peer is not what we do. For one thing, Groove places content on your machine that’s merely “passing through”, i.e. unrelated to your work. This can be something of a security nightmare. How do you keep that information secure? For another, Groove is about pushing updates out to subscribers. Infovark works like RSS; we pull updates. And we only pull data relevant to you and to which you have access. The network usage is about the same as if I email a document from my computer to yours.
The Wiki pages are indeed stored locally and accessed remotely.
As of right now, we don’t do anything! One of the great things about the REST-based approach that Infovark takes is that that content is accessible and available to the whole enterprise. Any content-spidering search product, like the Google search appliance, can easily scoop up the latest version and index it. Periodic backup or archiving would work in the same way. Use your favorite off-the-shelf tools. We’re also planning some specialized versions of Infovark that can address all three needs in the same package.
That’s up to the IT guys. The user’s Infovark could easily be picked up and hosted on a server. Then all you’d need to do is change a DNS entry or leave behind a permanent redirect. It’s kind of like an “Employee Graveyard”. Creepy…
Gah! Stop asking hard questions. We’re working on that right now. We’ll get back to you when we get to Alpha in June.
Tree view controls were very much in vogue when I first learned to write code, some 10 years ago. They’re a common user interface convention that still features heavily in software:
I don’t like tree views because they tie you to a hierarchical world. Every element has to be described relative to its parent — which assumes that each piece of information has one direct ancestor and potentially multiple descendants. So if I put my album collection into a tree view, all my song files would be directly related to the album folder.
This is all well and good, but it assumes that the only way I care about organizing my music is by album. But I’m a complex individual. I classify my music in many different ways: music of a particular genre, music I like to listen to in the mornings, etc. Sometimes I use less tangible criteria that I can’t really explain to iTunes — like music I like right now, or music that a friend recommended to me that I think might suck but I might listen to later…
When you consider all the ways that I think about music in my head, the two-dimensional tree view seems remarkably quaint. It will only tell me that each track exists against a particular album. Which is nice, but, well — you know…
The problem here is something that academics call multifaceted classification. Simply put, it means classifying things in lots of dimensions, not just one. This creates a huge problem for our two-dimensional tree: Suddenly each track could be in thousands of different categories at the same time.
The Web 2.0 way to approach this problem is with tags. Just stick a tag on all the things that you care about: jazz, morningMusic, etc. This works well because you can tag multiple things with the same tag and put multiple tags on the same item. This is a form of multifaceted classification.
The drawback comes from the fact that this tag-based classification is hard to fit in your head. You can’t display tags very nicely. (The tag cloud is about the closest you can get, and it doesn’t really show you anything of much use.) A tag itself doesn’t have a concept of timeliness or uniqueness. I’m forgetful, so I mis-tag things. (Did I use blog or blogs last time?) Sometimes what seems like a great tag never gets used again, so I have lots of orphans and one-offs in my del.icio.us account.
Computers can do math in multiple dimensions — that’s not the hard bit. The hard bit is trying to fit the whole thing onto a two-dimensional screen in a way that doesn’t hurt people’s heads or require them to get a library science degree.
Right now, infovark is thinking about the best way to solve these problems. We know that people intuitively understand multifaceted classification, even if they don’t know what it’s called. I do multifaceted classification with my music library and I could explain my system to you if I tried. People seem to cope just fine with multiple ways of organizing things. We want our software to be able to do that, too.
At least, that’s our challenge for today. If you’d like to check out some newer approaches to information visualization, head over to Information Aesthetics — they seem to always have great stuff!