探索 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 將為我和我的業務提供什麼。