今天提到文档方案的问题，正好我们的一个工程师也提出了协作问题。指出目前团队协作方面的欠缺，同时应该发现，目前对于文档管理这块，部门还是欠缺 的，虽然像某些服务单位已经有了较为完善的文档，但是由于独立和修改次数的增多，如何确立一个“正确、标准”的版本成为一个比较复杂的问题。而更大的问题 就是文档传播的问题。当然，你说工程师写好了文档，放在这里，你来拿，或者我给你邮寄。首先，我们的工程师处于市内各个地点，通讯交流有一定的阻碍，也不 能快速迅捷的复制文件，使用email更会造成邮件系统的资源占用，并且如果需要修改一处错误，难道要群发邮件？

观目前使用的知识库，首先 仅仅按照服务地点来组合，就不是很科学的方法。文档的建立，并不是为了记录，而是为了查阅的方便。keso说过，GoogleNotebook目前失败在 于既不方便于存储也不方便提取。目前查询系统和分类界面都不是很令人满意。所以服务文档看似很多，但却很少有人去查询。
    较为科学的分类方式，借鉴当今比较火的web2.0的概念叫做tag（标签）,我们通过tag文档，作为日后搜索文档和查询文档的关键字。这个关键词可以 是服务地，也可以是问题类型等。这样，一个文档被贴上多个tag后存档。比如：A单位，网络，cisco。日后a单位网络出现问题 在查询的时候，输入a单位，网络 即可搜索到相关文档。或许就是相同的问题。比如我想了解关于cisco的问题，那么同样通过cisco tag，我们也可以了解到相关信息。当然，如何组织tag的定义分类 对于快速搜索是很有帮助的。

另一个就是版本控制。当一篇文档以标准的 格式完成的时候，我们把它加入到存档中。随着时间的增长，必然会产生新的问题或者对原有问题有了新的看法。还有新的工程师发现了问题。那么就要去修改。共 享文档自由修改虽然方便，但是版本控制就成问题。如何确保不被错改，误改？所以引入了“权威版本”的概念。比如一篇关于某系统的详细文档，经过管理人员审 订的初稿可以定为“权威版本”。日后如果发现问题或者有了新的解决需要更新，那么工程师可以立即去修改。但是这个修改并不影响到权威版本，当修改稿被广泛 接受或者经测试无误，则并入“权威版本”并相应的版本号进步。
    版本控制其实在office中已经实现，但是很少有人关注，并且其应用也受到一定的限制。并且由word组成文档组并不利于迅速的搜索，对于常见问题来说，建立长篇的大型word文档不是一个很棒的选择。

wiki系统自出生以来，就实现了协作、共享和查阅。所以基于这种特性，很是看好wiki在日后企业中的应用。不仅仅是实现项目和文档的管理，如果实现相应的权限控制，甚至可以实现组织和运作的管理。

通过网络的传播，不仅仅是在局域网中，在任何地方，工程师们都可以访问到OA中的文档，有效快捷的针对性查询。在家里，可以系统地看到其他项目组的有条理文档。

EA（Electronic Arts） 公司就在其内部实现了类wiki系统的组织管理和项目管理。