想象一下，您正在向银行的呼叫中心提出问题，并得到一个答案。 然后到达销售点，但先前获得的信息无关紧要。 为了确保避免这些差异，我们决定将在银行中创建的现有解决方案保留在SharePoint中，处理所有内容，确定数据源和使用者，并将所有必要信息重新打包到新的知识管理系统中-所有部门都一样。 在这篇文章中，我们将分享我们的经验。
问题陈述和解决方案选择
首先，与客户服务，我们的产品和服务有关的所有信息必须统一。 历史上，知识存储在不同时间创建的三个大型知识库中，实际上是在不同的银行中。 同时，关键要求之一就是能够提供不同数量的数据，例如，针对销售点和ATP（呼叫中心）。 在第一种情况下，详细信息很重要：当人们来到离线部门时，他们希望听到有关所关注问题的所有详细信息。 相反，在第二种情况下，简短的信息就足够了-主要是要快速，清楚地提供它。
我们有多达六个内部客户，这使任务变得复杂。 相应地，还有不同类型的要求。 每个人在功能，性能和支持方面都有不同的标准。 例如，SSO的存在，与Active Directory的集成等。 团队的快速实施能力很重要。 我们预计，新系统将使呼叫中心25％的呼叫的服务时间减少5秒。 它还将减少培训时间。 以前，所有工作时间的3％都花在了它上—当涉及30,000多名工人时，花费了相当多的费用。
此外，在项目期间，VTB处于合并其结构中的两个大型银行的阶段，并且未来系统的客户位于不同子网，不同细分市场中。 所有这些都必须合并并提供给使用该系统的员工，端到端访问，考虑角色，对信息的各种访问级别等。 需要解决许多其他基础结构问题。
我们将所有必要的条件和标准放在一张评分表中。 我们查看了市场上现有的所有关键解决方案，无论是俄罗斯还是国外的，都将我们的内容的一部分上传到其中，并评估了可行的方法。 最后，我们选择了KMS Lighthouse的统一知识管理系统。 通过介绍，我们得到了DIS集团团队的帮助，该团队在俄罗斯市场提供KMS Lighthouse。
16个模板中的2500条文章可供6万用户使用
在我们的新知识管理系统中，有两个关键实体-“模板”和“文章”。 文章是带有信息的正式页面。 对于所有用户角色组（银行员工），同一篇文章看起来都不同。 根据员工的组织，职能或业务从属关系组成小组。
在分析了我们拥有的内容之后，我们意识到我们正在处理2500篇文章。 需要将大量信息分解为最少数量的模板。 而且，这些物品应保持上述的柔韧性。 在创建模板，协调和对帐方面进行了大量的人工工作。 但是最后，我设法满足了16个模板-对于2500篇文章，这是一个很好的系统化水平。
处理内容
16个模板分布在三组内容管理器中。 第一组负责与呼叫中心关联的内容。 第二个是产品，服务和相关信息。 第三个是我们的后台操作单元（DOPB）的内容块。 此外，我们还有一个在银行层面运作的方法学部门。 银行的几乎所有信息都将通过它传递，就像通过过滤器一样，因此，仅应保留在知识库中的信息得以保留。
我们讨论了更复杂的划分。 想介绍负责过程和系统的组的“所有者”。 我们讨论了“首席编辑”的职位，他将验证所有更改。 但是最后，我们决定将重点放在三个组上，因为它们之间的内容非常明确。
KMS Lighthouse允许您快速建立多个层次的协调，但是我们决定不使该系统复杂化，并且在内容管理器的层次上，我们将层次划分为两个层次-写作层次和发布层次。 在最后一级，负责团队中所有内容的人员脱颖而出。 没错，这里出现了向成功销售食品部门制造材料的问题，但到目前为止，他们决定保留一切。
因此，可以毫不拖延地开发知识库。 假设食品部门希望立即发布有关新产品的信息。 通过邮件向内容管理员发送请求：“同事，我们需要在此处发布此文章。” 通过反馈机制发布后，正在进行完善：某个地方的信息可能不足，某些地方的信息与模板不符。 依此类推，直到该部门和内容管理员满意为止。 现在，我们仅介绍这种交互所必需的元素：通知，调查，批准表格。 如果正在创建的文章涵盖内容管理器不同组的区域，那么每个人都应对自己的标签负责。
为内容管理器分配了单独的应用程序服务器，您可以在其中编辑文章或使用现有模板创建新文章。 在这里，您可以获取有关搜索查询，答案的相关性，转化次数等的必要统计信息。 文章不仅可以更改，而且可以优化-例如，创建元标记以改善搜索。 另外，可以通过将某些文章强制添加到某些查询来改进搜索。 这称为“编辑者的选择”；搜索时，用户会在单独的列中看到此类材料。
基础搜索
在SharePoint中，人们习惯于呈现信息并与选项卡进行交互的树形结构。 KMS Lighthouse涉及使用完整搜索。 当有6万名用户使用该系统时（一次平均约1600个），值得考虑负载平衡。 现在，KMS Lighthouse可在10台服务器上运行。 每个部署两个虚拟机。 一堆20个虚拟机可以工作。 在它们之间是银行平衡器。
搜索基于对所有内容进行索引的三个搜索引擎。 搜索索引的构建考虑了传入请求及其频率。 答案的相关性及其在输出结果中的位置取决于此。 Lighthouse分析请求，并可以16种不同的报告的形式呈现请求，内容管理者将借助这些报告来填充系统。
附加功能
使用该系统的所有员工大约分为35个角色组。 每个人都可以访问文章的某些部分。 用户可以分为几个组-然后他可以立即看到所有这些组的内容。
组与电子邮件和SMS网关集成在一起。 与银行客户一起工作时，员工可以快速向他发送必要的信息，例如在电话咨询期间。 如果可以，当然可以发送信息； 有关披露（以及印刷品可采性）的文章指出了各个属性。 无需重写和复制粘贴任何内容。
Yandex.Maps也已集成到知识库中，员工可以通过该数据库查看某些部门的繁忙程度。 信息每半小时更新一次。 因此，在确定了客户可以在哪个部门中接收该服务或该服务之后，员工可以建议在哪里解决该问题最好，以便节省时间。
KMS Lighthouse与我们的前端系统集成在一起，可以作为小部件直接带到其界面。 与任何搜索引擎一样，您可以在其中快速请求并立即转到该文章。
这就是我们新的知识库的组织方式。 现在，我们正在完成该过程，并希望不仅员工，而且VTB客户都将欣赏KMS Lighthouse实施的积极作用。
最后，我们要分享我们的喜悦。 1月，根据全球CIO，我们的业务Wikipedia被宣布为年度项目。 我们将及时通知您，并告诉我们新的固定方法及其对工作的帮助。