by Ron Lichty
I've been mentally classing internal community / collaboration solutions as KM -- knowledge management. But realized through some of the conversations I've been having via email and voice that my mental model has been much too "clean".
Certainly KM is a piece of internal enterprise community / collaboration solutions. And a necessary one.
Apple, in my last year there, '93-'94, was pressing Radar, its bug tracking system (!), to this use, making it a system in which employees could share their interests and knowledge bases with each other.
In the three-year initiative I ran at Schwab to transform application development from any-language-goes to a single cost-effective Java platform company-wide, my first hire was a webmaster. Fundamental to the challenge, it seemed to me, would be getting the organization to share and move toward common best practices, standards, tools, patterns, frameworks and other forms of reuse. That would require building a sense of being part of a Java community at Schwab. And that meant everyone would need to know who the other members of the community were and what they were doing.
We attempted to make our Schwab internal "Java Portal" comprehensive, with links to everything significant that was Java, both internally and externally. The first functionality on the Schwava Portal was a page that listed every Java project in the company, who worked on it in what capacities, what tools and application servers they'd used, and what approaches they'd taken. When we started, mid-'99, there were only a score of Java applications at Schwab and probably 40 developers. We went out and gathered data and had a static HTML page up with all that information in just two weeks. Three and a half years later, with 400 Java applications and a thousand developers, testers, project managers, and people managers involved with developing all of them, we were working in a virtual Java user group. We'd achieved our goal. By then, we'd coded and re-coded our knowledge base twice, and the "projects" section of the site had become a searchable, sortable database.
With the Event focus on blogs and message boards and wikis, it was easy to think of the software that supports internal communities at companies as being knowledge management software. But I was ignoring what I had just, over the weekend, thought through, when I listed email as one of the early community enabling solutions.
Intercommunication software is, in addition to KM repositories, also core to building community. At Schwab, even before we built our Schwava Portal, we'd created an Outlook group email list to include every Java developer (and later created similar email groups of managers and testers). And we started our initiative's email group from a group we'd started two years earlier, in '97, to facilitate creating our first Java developer community, an internal Java Developers Group.
And beyond email and other communication tools, the internal community/collaboration space includes groupware...
The tools core to internal enterprise communities are not so easily classed.