随着时间的推移，我们的信息战略已经遍布整个地方，我们希望有一个更清晰的政策和更明确的方式让每个人在信息共享上保持同步。需要注意的一点是，该组织有300多人，遍布全球多个国家。此外，我们有人在Sharepoint很舒服，人们在汇合时很舒服，所以这里肯定有一个“改变”因素
以下是我们当前的问题以及我们正在考虑采取的措施。我很想听到反馈，建议等等。
我们今天的内容：
以下是我们的一些主要问题：
数据应该在哪里 - Confluence WIKI与Sharepoint对比Intranet网站 - 我们使用汇合WIKI进行＃1，＃2，＃3，＃5但我们也使用sharepoint作为＃1，＃3 ，＃4，＃5。我们试图弄清楚我们是否应该将每个数字命令到特定的地方以使事情保持一致。我们正在使用Sharepoint更多的文档目录结构，我们正在使用汇总来获得更多特殊的可更改内容。
陈旧数据 - 这可能是组织的一个文化事物，但在某些时间点数据变得陈旧且不再相关。确保旧数据不会产生大量噪音并确保最新的正确数据是最新的最佳方法是什么。组织中是否应该有人对此负责，或者应该是隐含的“每个人的工作”。当人们离开，加入等时，这更是一个问题。 。
更积极的使用 - 什么是让人们远离电子邮件并尝试停下来思考“这对其他人有用的最佳方式。让我把它放在一个集中的地方而不是在电子邮件链中“。 。
此外，任何其他改善组织沟通和信息管理的好方法的故事
答案 0 :(得分：2)
信息混乱的根本原因是“没有所有权”。
人们被分配到项目中。项目结束（或被取消），人们继续前进，文件留下来收集“灰尘”，变得信息杂乱。
这很难预防。 wiki与sharepoint没有解决混乱问题，只是改变了用于积累混乱的技术基础。
让我们来看看杂乱
技术设计信息/架构文档。旧的并不重要。有现在和那里无关紧要。维基。
去年过时的设计信息已经过时了。
会议纪要，行动项目等。行动项目成为某人在开发冲刺中积压的一部分，或者，他们可能永远不会完成。积压是维基项目。其他一切都是可能有趣的历史，但通常不是。如果它没有创建sprint backlog项目，更新架构或解决开发问题，那么会议可能是浪费时间。
项目计划和路线图。冲刺积压很重要 - 这就是“计划和路线图”所追求的目标。如果你必须用路线图来补充你的计划，你可能应该放弃计划并只使用Scrum并保持积压的最新状态。
最初的计划是某人对项目开始时间的猜测，对当前的项目团队来说并不是很有趣。
组织业务管理信息 - 旅行，预算信息，人数信息等。这是高度结构化的东西（预算，组织）和非结构化的东西（“旅行”？）的奇怪组合。
您需要多少历史？没有？ Wiki充其量。财务或人力资源系统是它所属的地方。但是，在大型组织中，会计系统使用起来既困难又麻烦，因此我们创建了二级信息源，例如具有过期预算编号的SharePoint页面，因为实际预算编号隐藏在Oracle Financials中。
包含业务分析，需求等的项目页面。这是您的待办事项。您的项目路线图以及您的要求和分析应该是单个文档。在维基。
历史很少重要。项目开始时的某个人的概念是什么要求并不重要。最终形式的要求变化远远超过任何历史。这是wiki材料。
多大年纪'太老了'？ 我曾与拥有30年历史的软件的客户合作过。该软件显然是相关的，因为它正在生产中。
然而，文档都是垃圾。该软件已得到维护。它充满了变更控制记录。必须仔细重写“原始”规范，并将每个更改控件折叠起来。由于更改控制文档可能非常普遍，因此查看更改应用位置的唯一方法是阅读源代码 - 从中 - 逆向工程当前状态规范。
如果我们只能通过逆向工程来理解一个有30年历史的应用程序，那么，就可以查看这张30年前的纸堆。这没用。
维护完成后，“原始”规格就会贬值。
如何清理它？ 如果您创建了Wiki页面或sharepoint站点，那么您将永久拥有它。 当你离开时，你的替代者将永远拥有它。
每位经理100％负责员工创建的每一条信息。他们必须删除东西。弱解决方案是“归档”东西。这只是一种礼貌的方式，说“删除”没有“D字”。
清理必须是每位经理的持续责任。如果他们不记得它是什么，或者为什么他们拥有它，他们应该被要求（或“鼓励”）删除它。在过去两年中未被访问的所有内容都应该毫无疑问地存档。 10岁的一切都只是无关紧要的历史。
这很痛苦，而且似乎不是创造价值的工作。毕竟，我们在IT部门工作。我们的工作是“编写”软件，而不是删除它。除非被迫解雇，否则没有人会这样做。
存储成本相对较低。清理成本似乎更高。
如何停止电子邮件链？
拒绝参加。创建一个“打破链条”活动，专注于用维基更新（或共享点更新）替换电子邮件链。
确保您的wiki提供链接，并且编辑速度比电子邮件更快。
你不能强迫人们放弃真正方便的解决方案（电子邮件）。你必须使维基更有价值，几乎和电子邮件一样方便。
增加维基上的值。弃用电子邮件链。拒绝回复电子邮件链。拒绝通过电子邮件接受“待办事项”行动事项。
答案 1 :(得分：0)
您可以使用Confluence Wiki将文档存储为附件，并将Wiki的路径用作Sharepoint中的文件路径。
Re：陈旧数据：拥有数据的所有权（包括个人和团队），并确保所有者的可交付成果包括维护所有数据。
就“关闭电子邮件”而言，这很难做到，因为你不能强迫人们做主动监控所有电子邮件......但你可以尝试一些关于添加到Wiki的内容指标的可交付成果。这样人们就更有可能想要重新使用已经在电子邮件上完成的工作粘贴到Wiki中以满足“配额”而不是组成新鲜的东西。
我们的公司和/或团队在过去使用了所有这三种方法并取得了一定程度的成功
答案 2 :(得分：0)
是否有理由不让wiki保存文件？
此外，可能将邮件服务器限制为而不是允许内部电子邮件上的附件过于夸张，但要求人们将需要通过电子邮件发送多次的wiki中的所有内容放入其中非常有用。
答案 3 :(得分：0)
高效的信息管理确实是一个非常难的问题。我们发现“越简单越好”原则可以创造奇迹来解决它。
数据应该在哪里 - 我们是wiki方法的忠实信徒。实际上，我们使用Confluence来共享可能的每种类型的信息，除了非常大的二进制文件。对于那些，我们使用Dropbox。它的简洁是一个绝对的杀手级功能。 （提示：您可以将它们与Dropbox in Confluence插件集成。）
查找陈旧数据 - 在我们的定义中，陈旧数据是在特定时间段内未更新或查看的内容。 Archiving Plugin of Confluence可以快速自动地找到这些内容，然后将其报告给可能会更新它们的作者和管理员（或删除它们，请参阅下一项）。当然，信息永远不会过期，但是在标记相应页面后，插件可以跳过它们。
删除陈旧数据 - 我们对此非常积极。如果数据不再（高度）相关，请立即清理 ！我们可以安全地遵循这种做法，因为我们从未真正删除数据。我们再次使用Archiving Plugin将过时的数据移动到隐藏的存档空间。如果我们以后改变主意，很容易在档案中找到它，查看它甚至恢复它。
更积极的使用 - 我们的规则：如果要求信息是持久性的，请不要通过电子邮件发送。把它放到维基页面上。对某些人来说，最难的是找到信息的最佳位置（哪个空间？页面层次结构中的位置？）。遗憾的是，组织不清的空间是另一个重要的效率分配器。大公司可能会考虑引入wiki gardener来解决这个问题。