您的企业中是否有人考虑过他们是否从分享Point中获得了最大的价值? 从表面上看，这似乎是一个荒谬的问题. 如果一个公司还没有确定分享Point的真正好处和整体价值，他们为什么要实施它呢?

但在我与其他技术人员和业务人员的日常对话中，我惊讶于他们经常无法识别和量化真实 ROI 他们在分享Point中看到的. 更令人惊讶的是，许多公司并没有充分利用他们的分享Point环境来降低整体业务成本和提高生产力.

分享Point的技术细节很重要, 但在这篇文章中, 我想和你们分享更多关于使用分享Point的公司通常缺少的商业策略.

为什么要使用分享Point:一个愿景…

2009年冬天的一个周日，我坐在靠窗的座位上，急切地盯着一架747飞机外面. 我正前往旧金山参加我的第一次会议，VSLive.

当时，我在一家大型化妆品公司工作. 我很兴奋能参加 分享Point 这是公司内部一个相对较新的技术栈，我想亲自看看分享Point到底能为公司做些什么.

我没有失望. 我兴奋地离开了旧金山, 我曾以为这种感觉早已从我的职业生涯中消失了. 我是如此渴望回到办公室与我的团队讨论这个神奇的工具……只是被拉回到我作为全球信息系统团队主管的现实:

[执行董事-地理资讯系统]当然，我听说过分享Point. 我不认为这有什么好大惊小怪的，我们可以在自己的网站农场里做同样的网页. 我认为你是在浪费时间.”

[业务关系经理- GIS]“它太普通太难看了. 我永远不能把这个卖给我的任何商业客户.”

[高级发展商-地理资讯系统]这有什么大不了的? 我看不出它有任何价值. 它看起来太复杂了. 我认为Active Server Pages是一个更好的方向.”

唯一对我表现出一点点兴趣的人是我直接向他汇报工作的主管. 他对分享Point内部的技术了解不多, 但他确实知道我对这个太兴奋了，不能简单地忽略它.

他让我安排一个简短的会议，让我进一步讨论一下这项技术. 那次会议促使我们为高级管理层设计了分享Point概念验证(POC)，最终成为GIS部门的核心组件. 它将使我们新的软件开发生命周期(SDLC)过程自动化和流程化，并为公司带来许多分享Point的优势, 让我一跃成为“分享Point达人”. 在接下来的八年里, 我在公司的大部分时间都在使用分享Point作为一个惊人的低成本生产力工具. 对于那些愿意倾听的人, 我会改进许多业务流程并降低其成本, 但是公司中仍然有太多的站点是带有文档库的简单团队站点. 我只是一个人, 逆流而上销售分享Point不仅仅是我的业务, 而是组织内的最高层.

这听起来熟悉吗??

在过去的九年里, 我观察到，大多数公司使用分享Point有两种基本情况.

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

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

2. 完全定制的网站与一个大的，复杂的代码库

通常，这些都是更大的网站，拥有更多的受众:企业 内部网企业人力资源和企业IT网站通常是这种类型的分享Point使用的候选者.

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

从这里开始，事情通常会失去控制. 开发团队已经放弃了使用有限代码库的开箱即用(OOTB)功能的前提. 而不是, 他们有一个完全定制的方法, 从完全定制的母版页到可能的提供商托管应用程序(PHA)，或者像他们现在所说的那样 provider-hosted插件.

我已经能听到他们的叹息，看到他们翻白眼. “托尼，这些都是完全有效的利用方法.“这两个网站我们都有，我们的用户喜欢这些网站，我们支持它们没有问题。.“我绝不认为这两种方法都是错误的, 也不是说一个比另一个更有利, 但我相信这两种方法都错过了充分利用分享Point平台的机会.

我进一步认为，这两种模式导致企业感觉分享Point对于他们使用它的用途来说太贵了, 或者IT部门觉得他们可以简单地通过web服务器和HTML页面或罐头开发相同的功能 CMS 云解决方案. 这两种观点都让业务和IT部门觉得分享Point似乎不是满足他们需求的正确工具.

分享Point擅离职守的好处?

为了更好地理解我们所处的位置，我们需要退后一步，回顾一下我们是如何走到这一步的.

我要带你回到这个简单的问题:“你是怎么听说分享Point的??“从我个人的经验来看, 以及与我交谈过的许多其他IT领导者的经历, 在微软企业顾问的协助下，基础架构团队将分享Point作为一个技术平台引入了公司.

通常, 第一个分享Point农场是一种测试平台，作为公司与微软企业协议的一部分. 此时此刻, 大多数公司都有一个业务客户，并使用一个团队站点部署他们的第一个站点集. 业务客户喜欢文档库以及协作和共享文档的能力，因此开始使用该站点作为其业务流程的一部分.

对于你们中的许多人来说，这听起来是完全可以接受的, 说实话, 能否成为分享Point的一个可行用例. 但是，一旦你深入研究分享Point，你就会意识到它不仅仅是一个基础架构团队实现和支持的平台:它是一个强大的应用程序空间，需要基础架构的紧密协作, 企业架构, 应用团队.

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

你的商业客户是关键

太频繁, 当涉及到分享Point时，许多技术组织完全没有商业战略. 他们只是在现有的基础上增加了一个关于如何请求和创建分享Point站点的小流程. 它们甚至可能不包括围绕站点创建过程的任何形式的治理, 这可能导致大量的站点集合，并最终导致支持问题.

可能会有一些基本的对话和教育，围绕一些更大的概念的使用，比如站点集合和 在分享Point中搜索. 但是关于战略的讨论可能会变得非常复杂. 正因为如此, 许多技术组织只是决定在站点创建过程中结束他们的策略. 相反，让我们慢慢地从基本的关键分享Point特性开始.

谁是你的商业客户? 他们是公司的技术团队，你的区域营销团队，还是R&D团队? 正如我之前所说的, 分享Point的实现通常是由基础设施团队开始的，然后慢慢地渗透到商业客户群体中.

在某些情况下, 你的商业客户在考虑一些大型项目时，可能已经在一个更简单的环境中听说过分享Point, 关键业务线应用程序, 第二次使用分享Point通常是从哪里开始的. 没有清晰的业务采用策略, 对于技术团队来说，确保他们的分享Point农场得到适当的采用和使用将是一个非常缓慢和艰巨的过程.

就我而言, 当我开始接触分享Point时，大多数已经创建的分享Point网站都是简单的协作网站，带有大型文档库和非常复杂的文件夹结构.

有些文件夹名称实际上是小句子，以便团队能够准确地理解文件夹中是什么类型的文档. 没有元数据标签，没有内容类型，只有放在文件夹中的简单文档.

整个协作过程就是实际文档的共享. 有一个单独的存储库，每个人都可以共享文档，这是团队协作的范围. 这就是商业客户所看到的分享Point的最大价值.

这并不奇怪, 当我开始和公司里的人交谈时, 他们对分享Point的印象最多也就是不怎么热情. 甚至我的一些技术同行也开始争辩说，如果我们只是购买文件共享来处理文件和文件夹结构，我们可以节省大量的成本.

许多基本的分享Point功能根本没有正确地传达给我的业务，在某种程度上甚至是技术团队. 他们在分享Point上被推销为一个令人惊叹的CMS工具，具有加强协作和创新的巨大可能性, 然而，我们能想到的最好的办法就是文件共享.

在我公司的第一次面试中, 我发现，一些冗长的文件夹结构的原因是为了提供某种层次的结构，以便人们找到某些文件. 生意是 甚至不知道分享Point的基本搜索功能，更不用说遵循分享Point最佳实践了. 我需要找到一种方法来吸引我的商业客户，这样他们不仅可以更有效地利用分享Point，而且还可以让他们了解这个平台的真正优势.

展示一个更好的商业案例

基于以上对商业客户的采访反馈, 我意识到我需要重新开始教育. 但是基于我们目前已经拥有的大型农场, 当事情已经在向前发展时，我怎么能“重新开始”呢?

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

当我们深入挖掘一些遗址的结构时, 对我来说，很明显，文件夹结构实际上是数据元素和团队正在协作的各种类型文件的分组. 因此，我决定从分享Point的一个非常基本但功能强大的特性开始:元数据标签.

我一直认为，让客户了解一项技术的最有效方法之一就是简单地开发某种POC. poc的问题在于它们确实有成本影响. 您必须小心，不要完全开发一个应用程序，只让业务部门决定它不是他们想要的.

在我的例子中，成本是最小的，但潜在的价值是巨大的. 我决定采用多个文档库, 每个文件夹都有20个或更多的独立文件夹, 并将其重新创建为具有元数据和内容类型的文档库. 而不是试图解释内容类型, 更容易展示使用内容类型如何不仅可以添加到数据结构中，还允许它们正确地管理与文件关联的附加元数据.

雪球效应

许多文件包含重要的、非常有用的信息. 公司决定用一种非常复杂的文件夹结构对文件进行分组. 例如, 他们的15个品牌都有一个文件夹, 在这些文件夹中, 他们有营销子文件夹, 金融, and other key categories; within 那些 子文件夹他们有更多的子文件夹.

这使得他们更容易找到一个特定的文件, 或文件, 而不必打开和查看单个文件. 但是因为这个复杂的文件夹结构, 他们现在需要一个业务流程来确保每个文件都被放置在正确的文件夹中. 当他们发现, 新的业务流程太难管理了, 很多文件都被放错了地方.

这使我能够合并并向业务解释元数据的使用. 我将文件结构分解为几个关键的内容类型, 然后我们用它来包含关键数据元素, 以及重要的数据验证. 这就是内容类型的简单方法, 元数据, 以及数据验证，这是我向我的企业展示分享Point更好的商业案例的第一个重大成功.

现在我得到了公司的关注, 我决定用关键涉众对文档库进行一次简单的演练. 我通过对他们的数据进行过滤和排序，向他们展示了元数据和内容类型的真正价值.

令我惊奇的是, 他们只是对分享Point的一些基本功能感到敬畏，他们甚至不知道这些功能的存在. 然后，我决定包含一个自定义过滤器页面，以真正向他们展示通过一些简单的页面创建可以完成什么, web部件, 和过滤.

我非常小心，没有完全定制这些页面. 我想只使用OOTB web部件. 这样他们就能更好地理解分享Point的基本特性，然后我再讲解更复杂的场景. 自定义页面取得了巨大的成功，我们甚至没有讨论搜索引擎将为其提供的扩展功能. 我想在我更好地采用分享Point基础之后再使用搜索引擎.

分享Point工作流:关键

依我拙见, 分享Point工作流程一直是我教育业务客户并确保在我的组织内采用和使用分享Point的唯一最重要的因素. 在我提到的第一个VSLive上，工作流是引起我注意的第一个特性, 他们是我第一个完整的分享Point POC的主要贡献者，它包含了我们的SDLC流程.

说到分享Point, 我与业务客户的最初对话通常是围绕他们的业务流程进行的. 业务流程是使用分享Point提高生产力和降低成本的关键, 这是任何商业客户都渴望讨论的问题.

正如我对许多IT高管所说的那样, 我可以通过简单的业务流程来保证分享Point的使用和采用. 每个业务单元都有流程, 大多数这些过程都有检查点或批准点, 这就是工作流派上用场的地方, 无论是通过发送审批邮件还是创建审批任务.

一旦我让一个业务客户相信工作流可以改善他们的流程并降低他们的成本, 然后，我教育他们如何使用相同的审批任务来创建服务水平协议(sla)或关键绩效指标(kpi).

如果业务部门能够了解文档的审核和批准需要多长时间，那该有多好? 然后，他们可以利用这些信息并采取策略来改进整个过程. 这样他们就可以创建kpi来监控和管理流程.

显示高级管理层对改进其流程的承诺, 他们甚至可以将这些改进作为奖励目标计划的一部分. 这通常是说服商业客户通过采用和使用分享Point可以实现真正价值的本垒打.

未来

当我第一次听说Office 365和分享Point Online的时候, 我理解托管分享Point环境的价值, 但我又一次纠结于如何说服我的商业客户，这个新方向对他们的未来是最好的. 听到pha的消息我很兴奋，但从应用程序支持的角度来看，我也对它可能带来的潜在成本持谨慎态度.

我的公司已经开始朝着第三方开发供应商的方向发展，采用外包模式, 哪一点很容易导致供应商创建复杂的业务应用程序，而维护和增强的剩余成本又很大.

与每个托管模型一样，我们需要为更改做好准备. 作为人类, 我们真的不喜欢改变, 作为技术支持团队, 我们常常害怕改变，害怕改变会影响团队前进的能力.

当我第一次听说微软决定弃用InfoPath时, 然后介绍Flow作为工作流引擎, 我的反应是, “我们又来了!“微软将做出另一个商业决定，这将使我更难“推销”他们最新的分享Point方向. 当我开始回顾《欧博体育app下载》所提供的内容时，我对所看到的内容感到失望.

但微软有他们的未来愿景, 直到我开始看到Flow在集成点方面的一些功能，我才明白这一点. Flow集成了许多现有的应用程序, 但它也允许公司创建自己的集成点. 这使得它成为我关于通过与各种业务线应用程序集成来改进业务流程的业务讨论中的主要参与者.

流动性

这已经成为一个标准的话题，我, 作为一名技术主管, 和我的很多商业客户都有过吗. 讨论响应式网页设计以及如何最大限度地提高他们的移动网络存在感是可以的. 我们还可以讨论分享Point如何利用响应式网页在移动设备上创造更好的分享Point体验. 微软甚至开发了一个移动分享Point应用程序. 但通常，讨论的方向是拥有一个独立的移动应用程序.

当我听到“独立移动应用程序”这个词时，我听到的是 唰唰 许多移动应用程序的成本很高，而且还需要专门的支持模型. 我从分享Point世界得到的答案是 PowerApps.

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

用户可以简单地选择分享Point中的PowerApps选项来创建自己的PowerApps移动应用程序. 它甚至会自动创建许多屏幕，以便在列表或库中添加和编辑新项目. 它还经过了移动设备领域所有当前领导者的测试. 它有自己的IDE, 同时还有一种非常简单的基于配置的语言，技术开发人员甚至精通技术的高级用户都可以很容易地适应这种语言.

再一次，我有一个很棒的分享Point工具/特性，我可以用它来提高分享Point平台的采用和使用. 将这个新工具与分享Point和Flow结合起来, 此外还有推送通知和使用定位服务和电话等固有的移动功能的能力, PowerApps已经成为我和我的商业客户讨论采用和使用分享Point时最喜欢的话题.

事实上, 我的POC不仅被我的公司热切地接受，而且因为我使用了定位服务和GPS导航等移动功能, 我被要求向PowerApps工程师展示我的POC应用程序，作为使用该工具可以做什么的一个例子.

从VSLive到分享Point解决方案

当时我正坐在飞往旧金山的靠窗座位上, 我从来没有想过这次简单的旅行会对我的技术生涯产生如此重大的影响. 分享Point是一个真正的 创新 协作工具, 微软将继续通过分享Point实现他们的愿景和方向.

就像我们今天可以使用的数千种SaaS或PaaS解决方案中的任何一种一样, 我们必须确保我们真正了解如何最好地利用这些解决方案. 持续改进我们的整体业务流程，满足我们的业务客户, 分享Point已经成为我的一个重要工具. 我期待着未来，以及分享Point将为我和我的企业提供什么.