探索 SharePoint 的业务优势

您的企业中是否有人考虑过他们是否从 SharePoint 中获得了最大价值？ 从表面上看，这似乎是一个荒谬的问题。 如果公司尚未确定 SharePoint 的真正优势和总体价值，为什么还要实施呢？

但在我与其他技术人员和业务人员的日常对话中，我很惊讶他们经常无法识别和量化他们在 SharePoint 中看到的真实投资回报率。 更令人惊讶的是，有多少公司没有充分利用他们的 SharePoint 环境来降低总体业务成本并提高生产力。

SharePoint 的技术细节很重要，但在本文中，我想与您分享更多关于使用 SharePoint 的公司的业务战略中通常缺少的内容。

为什么使用 SharePoint：愿景……

2009 年冬天的一个星期天，我坐在靠窗的座位上，热切地凝视着一架 747。我正前往旧金山参加我的第一次会议 VSLive。

当时，我在一家大型化妆品公司工作。 我很高兴参加我注册的 SharePoint 课程：这是公司内部相对较新的技术堆栈，我想亲眼看看 SharePoint 能为公司真正做些什么。

我没有失望。 我带着如此激动的心情离开了旧金山，这种感觉在我的职业生涯中早已荡然无存。 我非常渴望回到办公室与我的团队讨论这个神奇的工具……只是被猛地拉回了我作为全球信息系统团队主管的现实：

[执行董事 – GIS] ：“当然，我听说过 SharePoint。 我看不出有什么大惊小怪的……我们可以在自己的网络农场中制作相同的网页。 我觉得你在浪费时间。”

[业务关系经理 – GIS] ：“这太简单和丑陋了。 我永远无法把它卖给我的任何商业客户。”

[高级开发人员 – GIS] ：“有什么大不了的？ 我认为它没有增加任何价值。 它看起来太复杂了。我认为 Active Server Pages 是一个更好的方向。

唯一表现出一点兴趣的人是我直接向其汇报的导演。 他对 SharePoint 中的技术知之甚少，但他确实知道我对此太兴奋了，无法简单地忽略它。

他让我为我安排一个简短的会议，进一步讨论这项技术。 那次会议让我们为我们的高级管理层设计了一个 SharePoint 概念验证 (POC)，最终将成为 GIS 部门的核心组件。 它将自动化和简化我们新的软件开发生命周期 (SDLC) 流程，并引领公司采用许多 SharePoint 优势，将我提升到“SharePoint Guy”的杰出水平。 在接下来的八年中，我将在公司花费大量时间将 SharePoint 作为一种惊人的低成本生产力工具。 对于那些愿意倾听的人，我会改进许多业务流程并降低其成本，但公司内部仍然有太多网站是带有文档库的简单团队网站。 我只是一个人，逆流而上，不仅将 SharePoint 推销给我的企业，而且推销给组织内的最高层。

这听起来很熟悉吗？

在过去的九年中，我观察到大多数公司对 SharePoint 的使用属于两种基本情况之一。

1. 带有文档库的团队网站

这些站点通常是从团队模板创建的，并包含一个或多个文档库，这些文档库可能具有非常复杂的文件夹结构。 很少使用内容类型、元数据标签或工作流。 这些网站得到了业务部门的全面支持，其成员对 SharePoint 没有正式的了解，也没有接受“高级用户”角色。 该站点由基础架构或支持团队创建，他们可以从简单的帮助台请求单快速生成站点。

2. 具有大型复杂代码库的完全定制站点

通常，这些站点是具有更多受众的大型站点：企业内部网、企业 HR 和企业 IT 站点是此类 SharePoint 使用的通常候选者。

这些项目通常以很好的方向和期望开始。 它们作为企业已经调查过的许多高端、昂贵的内容管理系统 (CMS) 的低成本替代品出售。 然后随着项目的进行，需求会发生变化并变得更加复杂。 它需要更多的自定义代码，最终变得足够复杂，以至于支持代码成为一个问题。

从这里开始，事情通常会失控。 开发团队已经放弃了以有限的代码库保持开箱即用（OOTB）功能的前提。 相反，他们有一个完全定制的方法，从完全定制的母版页到可能的提供商托管应用程序 (PHA)，或者——正如他们现在所说的——提供商托管的插件。

我已经可以听到叹息，看到翻白眼。 “托尼，这些都是非常有效的利用方法。” “我们拥有这两个网站，我们的用户喜欢这些网站，我们支持它们没有任何问题。” 我绝不声称这两种方法中的任何一种都是错误的，也没有一种方法比另一种更有利，但我确实相信这两种方法都错过了充分利用 SharePoint 平台所提供的功能的机会。

我进一步认为，这两种模型会导致企业感觉 SharePoint 对于他们使用它的用途来说过于昂贵，或者 IT 部门觉得他们可以通过 Web 服务器和 HTML 页面或罐装 CMS 简单地开发相同的功能云解决方案。 这两种意见都让业务和 IT 部门感觉 SharePoint 似乎不是满足他们需求的正确工具。

SharePoint 离开的好处？

为了让我们更好地了解我们在哪里，我们需要退后一步，回顾一下我们是如何到达这里的。

我将带您回到“您是如何听说 SharePoint？”这个简单问题。 根据我的个人经验以及与我交谈过的许多其他 IT 领导者的经验，SharePoint 作为技术平台是在 Microsoft Enterprise 顾问的帮助下从基础架构团队引入公司的。

通常，第一个 SharePoint 场是一种测试平台，作为与 Microsoft 的企业协议的一部分提供给公司。 此时，大多数公司都会聘请业务客户并使用单个团队网站部署他们的第一个网站集。 业务客户喜欢文档库以及协作和共享文档的能力，因此开始将该站点用作其业务流程的一部分。

这对你们中的许多人来说可能听起来完全可以接受，老实说，这可能是 SharePoint 的一个可行用例。 但是，一旦您更深入地研究 SharePoint，您就会意识到它不仅仅是一个基础架构团队实施和支持的平台：它是一个强大的应用程序空间，需要基础架构、企业架构和应用程序团队的紧密协作。

我不是一个“反基础设施”的人，也不是在政治上反对基础设施团队的人，但是如果从一开始就没有正确的合作伙伴的合作，您就有可能不了解 SharePoint 平台的全部范围，因此没有为适当的业务战略和利用计划做好准备。 这种情况并非 SharePoint 平台所独有，而是指向一个更大的问题，即正确的协作和战略，这是许多 IT 部门面临的问题。

您的商业客户是关键

很多时候，许多技术组织在涉及 SharePoint 时完全没有业务战略。 他们只是在现有流程中添加了一个关于如何请求和创建 SharePoint 网站的小流程。 它们甚至可能不包括围绕网站创建过程的任何类型的治理，这可能会导致大量网站集并最终导致支持问题。

可能会有一些关于使用一些更大的概念（如网站集和SharePoint中的搜索）的基本对话和教育。 但是关于战略的讨论会变得非常复杂。 正因为如此，许多技术组织只是决定在站点创建过程中结束他们的策略。 相反，让我们慢慢开始，使用基本的关键 SharePoint 功能。

谁是您的商业客户？ 他们是企业技术团队、您的区域营销团队，还是研发团队？ 正如我之前所说，SharePoint 实施通常由基础架构团队开始，然后慢慢渗透到业务客户群中。

在某些情况下，您的业务客户在考虑一些大型的关键业务线应用程序时已经在更简单的环境中听说过 SharePoint，而这通常是 SharePoint 的第二次使用开始的地方。 如果没有明确的业务采用策略，技术团队要确保他们的 SharePoint 场具有适当的采用和使用量，将是一个非常缓慢和艰巨的旅程。

就我而言，当我被介绍到 SharePoint 时，大多数已创建的 SharePoint 网站都是简单的协作网站，其中包含具有非常复杂和复杂的文件夹结构的大型文档库。

一些文件夹名称实际上是小句子，以便团队可以准确了解文件夹中的文档类型。 没有元数据标签，没有内容类型，只是文件夹中的文档。

整个协作过程是实际文档的共享。 有一个单一的存储库，每个人都可以共享文档，这就是团队协作的范围。 这就是业务客户认为 SharePoint 的最大价值所在。

难怪当我开始与企业人员交谈时，他们对 SharePoint 的印象充其量只是冷淡。 甚至我的一些技术同行也开始争辩说，如果我们简单地购买文件共享来处理文件和文件夹结构，我们可以节省大量成本。

许多基本的 SharePoint 功能根本没有正确地传达给我的企业，甚至在某种程度上甚至是技术团队。 它们在 SharePoint 上作为一个了不起的 CMS 工具出售，具有加强协作和创新的巨大可能性，但我们能想到的最好的方法是文件共享。

在我的业务中的第一次采访中，我发现一些冗长的文件夹结构的原因是为人们提供某种级别的结构来查找某些文件。 企业甚至不了解 SharePoint 的基本搜索功能，更不用说遵循 SharePoint 最佳实践了。 我需要找到一种方法来吸引我的业务客户，以便他们不仅可以更有效地利用 SharePoint，而且还可以让他们了解该平台的一些真正优势。

展示更好的商业案例

根据上述对商业客户的采访反馈，我意识到我需要从教育重新开始。 但是基于我们目前拥有的已经很大的农场，当事情已经向前发展时，我将如何能够“重新开始”？

大多数网站都是带有文档库的团队协作网站。 所以我决定从文档库开始。 我让我的一个商业客户同意与我和我的团队合作，以一种允许他们最小化文件夹结构的方式重组他们的库，同时增加查找用户正在寻找的正确文件的可见性。

随着我们深入研究一些网站的结构，我发现文件夹结构实际上是团队正在协作处理的各种类型文件的数据元素和分组。 因此，我决定从 SharePoint 的一个非常基本但功能强大的功能开始：元数据标签。

我一直认为，对任何客户进行技术教育的最有效方法之一就是简单地开发某种 POC。 POC 的问题在于它们确实会产生成本影响。 您必须小心，不要完全开发应用程序，让业务部门认为这不是他们想要的。

就我而言，成本很小，但价值可能很大。 我决定采用多个文档库，每个文档库都有 20 个或更多单独的文件夹，并将其重新创建为一个包含元数据和内容类型的文档库。 与其尝试解释内容类型，不如展示使用内容类型如何不仅可以添加到数据结构中，还可以让它们正确管理与文件关联的其他元数据。

雪球效应

许多文件包含重要的、非常有用的信息。 企业决定使用非常复杂的文件夹结构对文件进行分组。 例如，他们为 15 个品牌中的每一个都有一个文件夹，在这些文件夹中，他们有营销、财务和其他关键类别的子文件夹； 在这些子文件夹中，他们还有更多的子文件夹。

这使他们能够更轻松地找到一个或多个特定文件，而不必打开和查看单个文件。 但是由于这种复杂的文件夹结构，他们现在需要一个业务流程来确保每个文件都放在正确的文件夹中。 他们发现，新的业务流程实在是太难管理了，而且很多文件都放错了地方。

这使我能够将元数据的使用合并到业务中并进行解释。 我将文件结构分解为几个关键内容类型，然后我们用它们来包含关键数据元素以及重要的数据验证。 正是这种简单的内容类型、元数据和数据验证方法是我在向我的企业展示更好的 SharePoint 业务案例的过程中取得的第一个重大成功。

现在我得到了业务部门的关注，我决定与主要利益相关者一起简单地浏览文档库。 我通过过滤和排序他们的数据向他们展示了元数据和内容类型的真正价值。

令我惊讶的是，他们只是对一些他们甚至不知道存在的基本 SharePoint 功能感到敬畏。 然后，我决定包含一个自定义过滤器页面，以真正向他们展示通过一些简单的页面创建、Web 部件和过滤可以完成的工作。

我非常小心地没有完全自定义这些页面中的任何一个。 我只想使用 OOTB Web 部件。 这样，在我转向更复杂的场景之前，他们将更好地了解基本的 SharePoint 功能。 自定义页面取得了巨大的成功，我们甚至没有讨论搜索引擎将为他们提供的扩展功能。 在我更好地采用 SharePoint 基础知识之前，我想推迟使用搜索引擎。

SharePoint 工作流：关键

在我看来，SharePoint 工作流一直是我能够教育我的业务客户并确保在我的组织内采用和使用 SharePoint 的最重要的因素。 在我提到的第一个 VSLive 中，工作流是第一个引起我注意的功能，它们是我第一个完整的 SharePoint POC 的主要贡献者，它包含了我们的 SDLC 流程。

谈到 SharePoint，我与业务客户的初始对话通常围绕他们的业务流程进行。 业务流程是使用 SharePoint 提高生产力和降低成本的关键，任何业务客户都渴望讨论这一点。

正如我对许多高级 IT 主管所说的那样，我实际上可以通过业务流程来保证 SharePoint 的使用和采用。 每个业务部门都有流程，这些流程中的大多数都有检查点或批准点，这就是工作流派上用场的地方，无论是通过发送批准电子邮件还是创建批准任务。

一旦我说服业务客户了解工作流如何改进他们的流程并降低成本，我就会教育他们如何使用这些相同的审批任务来创建服务水平协议 (SLA) 或关键绩效指标 (KPI)。

如果业务部门了解文档审核和批准需要多长时间，该有多好？ 然后，他们可以获取这些信息并采取策略来改进整个流程。 这将允许他们创建 KPI 来监控和管理流程。

为了显示高级管理人员对改进流程的承诺，他们甚至可以将改进作为奖励目标计划的一部分。 这通常是让业务客户相信他们可以通过采用和使用 SharePoint 实现的真正价值的本垒打。

未来

当我第一次听说 Office 365 和 SharePoint Online 时，我了解托管 SharePoint 环境的价值，但我再次为如何说服我的业务客户相信这个新方向最适合他们的未来而苦恼。 我很高兴听到 PHA，但从应用程序支持的角度来看，这可能产生的潜在成本也持谨慎态度。

我的公司一开始就采用外包模式向第三方开发供应商方向发展，这很容易导致供应商创建复杂的业务应用程序，并且维护和增强的剩余成本很高。

就像每个托管模型一样，我们需要为变化做好准备。 作为人类，我们真的不喜欢变化，而作为技术支持团队，我们经常害怕变化以及它会如何影响我们团队前进的能力。

当我第一次听说 Microsoft 决定弃用 InfoPath，然后将 Flow 作为工作流引擎引入时，我的反应是，“我们又来了！” 微软将做出另一项商业决策，这将使我更难“推销”他们最新的 SharePoint 方向。 当我开始回顾 Flow 所提供的产品时，我对所见所闻感到失望。

但是微软有他们的未来愿景，而我只是没有得到它——直到我开始看到 Flow 在集成点方面的一些能力。 Flow 与当今的许多现有应用程序集成，但它也允许公司创建自己的集成点。 这使它成为我围绕通过与各种业务线应用程序集成改进业务流程的业务讨论中的主要参与者。

流动性

作为一名技术主管，这已成为我与许多商业客户的标准对话话题。 可以讨论响应式网页设计以及如何将其最大化以改善他们的移动网络存在。 我们还可以讨论 SharePoint 如何利用响应式网页在移动设备上创建更好的 SharePoint 体验。 微软甚至开发了一个移动 SharePoint 应用程序。 但通常，讨论的方向是拥有一个独立的移动应用程序。

一听到“独立移动应用程序”这个词，我就听到收银机的嗡嗡声：许多移动应用程序具有高成本足迹以及专门的支持模型。 我对 SharePoint 世界的回答是 PowerApps。

就像我过去所做的那样，我立即开始开发移动 PowerApps POC 应用程序。 它利用现有的 SharePoint 列表和库作为我的应用程序的后端数据源。 PowerApps 是我所说的基于配置的开发平台：它允许非常快速地开发移动应用程序。

用户只需在 SharePoint 中选择 PowerApps 选项即可创建自己的 PowerApps 移动应用程序。 它甚至会自动创建许多屏幕以将新项目添加和编辑到列表或库中。 它还与移动设备领域的所有当前领导者进行了测试。 它有自己的 IDE，以及非常简单的基于配置的语言，技术开发人员甚至精通技术的高级用户都可以轻松适应。

我再一次拥有了一个很棒的 SharePoint 工具/功能，我可以使用它来改进 SharePoint 平台的采用和使用。 将此新工具与 SharePoint 和 Flow 相结合，以及推送通知和使用定位服务和电话等固有移动功能的能力，PowerApps 已成为我与业务客户讨论采用和使用共享点。

事实上，我的 POC 不仅得到了我的企业的热切欢迎，而且由于我使用了定位服务和 GPS 导航等移动功能，我被要求将我的 POC 应用程序展示给 PowerApps 工程，作为可以用工具。

从 VSLive 到 SharePoint 解决方案

当我坐在靠窗的座位上前往旧金山时，我无法想象这次简单的旅行会对我的技术生涯产生如此重大的影响。 SharePoint 是一个真正的创新和协作工具，Microsoft 继续通过 SharePoint 实现他们的愿景和方向。

就像我们今天可用的数千种 SaaS 或 PaaS 解决方案中的任何一种一样，我们必须确保我们真正了解如何最好地利用这些解决方案。 为了继续改进我们的整体业务流程并满足我们的业务客户，SharePoint 已成为我武器库中的关键工具。 我期待着未来以及 SharePoint 将为我和我的业务提供什么。