探索SharePoint的业务利益

本文概述

• 为什么使用SharePoint：愿景…
• 这听起来很熟悉吗？
• SharePoint AWOL的好处？
• 你的业​​务客户是关键
• 提出更好的业务案例
• 雪球效应
• SharePoint工作流：关键
• 未来
• 从VSLive到SharePoint解决方案

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

但是, 在与其他技术人员和业务人员的日常对话中, 我惊讶于他们经常无法识别和量化他们在SharePoint中看到的实际ROI的频率。更令人惊讶的是, 有多少公司没有充分利用其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.具有文档库的团队站点

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

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

通常, 这些站点是更大的站点, 具有更大的受众群体：公司Intranet, 公司HR和公司IT站点通常是此类SharePoint使用的候选对象。

这些项目通常在开始时会有很好的方向和期望。它们是企业已经研究过的许多高端, 昂贵的内容管理系统(CMS)的低成本替代品。然后随着项目的进行, 需求不断变化并变得更加复杂。它需要更多的自定义代码, 这最终变得足够复杂, 以至于无法支持代码。

从这里开始, 事情通常会失控。开发团队已经放弃了在有限的代码库中保留开箱即用(OOTB)功能的前提。取而代之的是, 他们采用了完全自定义的方法, 范围从完全自定义的母版页, 到可能由提供商托管的应用程序(PHA)或现在由提供商提供的加载项。

我已经可以听到叹息声和眼神。 “托尼, 这些都是完全有效的利用方法。” “我们都拥有这两个网站, 我们的用户喜欢这些网站, 我们在支持它们方面没有任何问题。”我决不是宣称这两种方法都是错误的, 也不是一种相对于另一种方法是有优势的, 但是我确实相信, 这两种方法都完全错过了充分利用SharePoint平台所提供功能的机会。

我进一步相信, 这两种模型会导致业务感觉像SharePoint对于其用途而言太昂贵了, 或者IT部门认为他们可以简单地通过Web服务器和HTML页面或罐装CMS开发相同的功能。云解决方案。两种观点都使业务和IT都感觉到SharePoint似乎并不是满足其需求的正确工具。

SharePoint AWOL的好处？

为了让我们更好地了解我们的位置, 我们需要退后一步, 并回顾一下如何到达这里。

我将带你回到”你是如何得知SharePoint的？”这一简单问题的。根据我的个人经验以及与我交谈过的许多其他IT领导者的经验, 基础架构团队在他们的Microsoft Enterprise顾问的帮助下向公司介绍了SharePoint作为技术平台。

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

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

我不是”反基础架构”人员, 也不是在政治上反对基础架构团队的人, 但是从一开始就没有正确的合作伙伴的协作, 你将冒着无法理解SharePoint平台的全部范围的风险, 因此没有为适当的业务策略和使用计划做好准备。这种情况并非SharePoint平台所独有, 它指出了一个更大的问题, 即适当的协作和战略, 这是许多IT部门面临的问题。

你的业​​务客户是关键

很多时候, 许多技术组织在SharePoint方面绝对没有业务策略。他们只是在现有过程中添加了一个很小的过程, 即如何请求和创建SharePoint网站。它们甚至可能不包括围绕网站创建过程的任何形式的管理, 这可能导致大量的网站集, 并最终导致支持问题。

围绕一些较大的概念(例如网站集和SharePoint中的搜索)的使用, 可能会有一些基本的对话和教育。但是关于策略的讨论可能会变得非常复杂。因此, 许多技术组织仅决定在站点创建过程中终止其策略。相反, 让我们从SharePoint的基本关键功能开始, 慢慢来。

谁是你的企业客户？他们是公司技术团队, 你的区域营销团队, 还是研发团队？如前所述, SharePoint实施通常是由基础结构团队开始的, 然后慢慢地滴入业务客户群。

在某些情况下, 你的业务客户在考虑一些大型的关键业务线应用程序时, 已经在较简单的上下文中听说过SharePoint, 这通常是SharePoint的第二种用途。没有明确的业务采用策略, 技术团队要确保其SharePoint服务器场具有正确的采用和使用量, 这将是一个非常漫长而艰巨的旅程。

就我而言, 当我被介绍给SharePoint时, 已经创建的大多数SharePoint网站都是具有大型文档库且具有非常复杂且复杂的文件夹结构的协作网站。

某些文件夹名称实际上只是一些小句子, 因此团队可以准确了解文件夹中包含哪些类型的文档。没有元数据标签, 没有内容类型, 仅是文件夹中的文档。

整个协作过程就是共享实际文件。只有一个资源库, 每个人都可以共享文档, 这就是团队协作的程度。这就是业务客户认为SharePoint的最大价值。

毫不奇怪, 当我开始与企业中的人们交谈时, 他们对SharePoint的印象充其量不过是一种热情。甚至我的一些技术同行也开始争辩说, 如果我们仅购买文件共享来处理文件和文件夹结构, 就可以节省大量成本。

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

在我公司的第一次面试中, 我发现某些冗长的文件夹结构的原因是为人们查找某些文件提供了某种程度的结构。企业甚至没有意识到SharePoint的基本搜索功能, 更不用说遵循SharePoint最佳实践了。我需要找到一种方法来吸引我的业务客户, 以便他们不仅可以更有效地利用SharePoint, 还可以对他们进行平台的某些真正优势教育。

提出更好的业务案例

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

大多数站点是带有文档库的团队协作站点。因此, 我决定从文档库开始。我有一个业务客户同意与我和我的团队合作, 以一种使他们最小化文件夹结构的方式重组他们的库, 同时增加发现用户正在寻找的正确文件的可见性。

当我们深入研究某些站点的结构时, 对我而言很明显, 文件夹结构实际上是团队正在协作的各种文件类型的数据元素和分组。因此, 我决定从SharePoint的一个非常基本但功能强大的功能入手：元数据标记。

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

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

雪球效应

许多文件包含重要的, 非常有用的信息。公司决定使用非常复杂的文件夹结构将文件分组。例如, 他们为15个品牌中的每个品牌都有一个文件夹, 并且在这些文件夹中, 它们具有营销, 财务和其他关键类别的子文件夹；在这些子文件夹中, 他们还有更多子文件夹。

这使他们可以更轻松地查找一个或多个特定文件, 而不必打开和查看单个文件。但是由于这种复杂的文件夹结构, 他们现在需要一个业务流程来确保每个文件都放在正确的文件夹中。正如他们发现的那样, 新业务流程简直太难管理了, 许多文件最终放在错误的位置。

这使我能够将元数据并入并解释给企业。我将文件结构分解为几个关键的内容类型, 然后我们将其包含关键的数据元素以及重要的数据验证。正是这种简单的内容类型, 元数据和数据验证方法, 才是我向企业展示SharePoint更好业务案例的旅程中的第一个重大成功。

现在, 我已经引起了企业的注意, 我决定与主要利益相关者一起简单浏览文档库。我通过过滤和排序数据向他们展示了元数据和内容类型的真正价值。

令我惊讶的是, 它们只是被某些根本不存在的基本SharePoint功能所敬畏。然后, 我决定包括一个自定义过滤器页面, 以真正向他们展示通过一些简单的页面创建, Web部件和过滤可以完成的工作。

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

SharePoint工作流：关键

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

关于SharePoint, 我与业务客户的最初对话通常围绕他们的业务流程。业务流程是使用SharePoint来提高生产率和降低成本的关键, 这是任何业务客户都渴望讨论的事情。

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

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

一个业务部门了解文档审核和批准需要多长时间？然后, 他们可以获取该信息并采取策略来改善整个流程。这样一来, 他们就可以创建KPI来监视和管理流程。

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

未来

当我第一次听说Office 365和SharePoint Online时, 我了解托管的SharePoint环境的价值, 但是我再次努力地使我的商业客户相信, 这个新方向对他们的未来是最好的。我很高兴听到有关PHA的消息, 但对于从应用程序支持的角度来看可能产生的潜在成本也保持谨慎。

我的公司已经开始采用外包模型来指导第三方开发供应商, 这很容易导致供应商创建复杂的业务应用程序, 而维护和增强功能的剩余成本却很高。

像每个托管模型一样, 我们需要为变化做好准备。作为人类, 我们真的不喜欢变革, 而作为技术支持团队, 我们常常担心变革及其对团队前进能力的影响。

当我第一次听说微软决定弃用InfoPath, 然后将Flow引入工作流引擎时, 我的反应是：”再来一次！”微软将做出另一个商业决定, 这将使我更难”出售”其最新的SharePoint指导。当我开始回顾Flow所提供的功能时, 我对所看到的感到失望。

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

流动性

作为技术主管, 这已成为我与许多业务客户进行对话的标准话题。可以讨论自适应网页设计以及如何将其最大化以改善其移动网络的外观。我们还可以讨论SharePoint如何利用自适应网页在移动设备上创建更好的SharePoint体验。 Microsoft甚至开发了移动SharePoint应用程序。但通常, 讨论的方向是拥有独立的移动应用程序。

一听到”独立移动应用程序”一词, 我就会听到收银机的变化：许多移动应用程序具有很高的成本, 并带有专门的支持模型。我在SharePoint世界中的答案是PowerApps。

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

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

我再次拥有SharePoint的强大工具/功能, 可以用来改善SharePoint平台的采用和使用。将此新工具与SharePoint和Flow结合在一起, 并提供推送通知和使用诸如位置服务和电话之类的固有移动功能的功能, PowerApps已成为我与企业客户讨论如何采用和利用IP的最喜欢的话题。 SharePoint。

实际上, 不仅我的企业急切地收到了我的POC, 而且由于使用了定位服务和GPS导航等移动功能, 我被要求将我的POC应用程序展示给PowerApps工程, 以作为使用该功能的示例。工具。

从VSLive到SharePoint解决方案

当我坐在靠窗的座位上前往旧金山时, 我从未想到过如此简单的旅行会对我的技术职业产生如此重大的影响。 SharePoint是一种真正的创新和协作工具, Microsoft继续通过SharePoint实现其愿景和方向。

就像今天提供给我们的数千种SaaS或PaaS解决方案中的任何一种一样, 我们必须确保我们真正了解如何最佳地利用这些解决方案。不断改进我们的整体业务流程并满足我们的业务客户需求, SharePoint已成为我的重要工具。我期待着未来, 以及SharePoint将为我和我的企业提供什么。