SharePointのビジネス上の利点を探る
公開: 2022-03-11あなたのビジネスの誰かが、SharePointから最大の価値を得ているかどうかを考えたことはありますか？ 一見すると、これはばかげた質問のようです。 真のメリットと全体的な価値をまだ決定していないのに、なぜ企業はSharePointを実装するのでしょうか。
しかし、他の技術者やビジネスマンとの日常の会話では、SharePointで見られる実際のROIを特定して定量化できない頻度に驚いています。 さらに驚くべきことは、SharePoint環境を十分に活用して全体的なビジネスコストを削減し、生産性を向上させていない企業がいくつあるかということです。
SharePointの技術的な詳細は重要ですが、この記事では、SharePointを使用する企業のビジネス戦略に通常欠けているものについて詳しく説明します。
SharePointを使用する理由：ビジョン…
2009年の冬の日曜日に、私は窓際の席に座って、747を熱心に見つめていました。サンフランシスコに向かい、初めての会議であるVSLiveに参加しました。
当時、私は大手化粧品会社で働いていました。 登録したSharePointクラスに参加することに興奮しました。これは社内の比較的新しいテクノロジスタックであり、SharePointが会社に対して実際に何ができるかを自分で確認したかったのです。
がっかりしませんでした。 そんなワクワクしながらサンフランシスコを離れたのですが、プロとしてのキャリアからは遠い昔のことだと思っていました。 私はオフィスに戻ってこの素晴らしいツールについてチームと話し合うことにとても熱心でした…グローバル情報システムチームのディレクターとしての私の存在の現実に立ち返るだけでした。
[常務取締役– GIS] ：「確かにSharePointについて聞いたことがあります。 大騒ぎが何なのかわかりません…自分のWebファーム内で同じWebページを作成できます。 時間を無駄にしていると思います。」
[ビジネスリレーションシップマネージャー– GIS] ：「それはあまりにも単純で醜いです。 これを私のビジネスクライアントに販売することは決してできません。」
[シニア開発者– GIS] ：「大したことは何ですか？ 私はそれが何の価値も加えていないようです。 複雑すぎて作業できないようです。ActiveServerPagesの方がはるかに優れていると思います。」
少しでも興味を示したのは、直接報告した監督だけでした。 彼はSharePoint内のテクノロジについてはあまり知りませんでしたが、私がこれに興奮しすぎて単に無視できないことを知っていました。
彼は私に、このテクノロジーについてもう少し話し合うための短い会議を開くように頼みました。 その会議により、上級管理職向けにSharePointの概念実証（POC）を設計し、最終的にはGIS部門のコアコンポーネントになりました。 これにより、新しいソフトウェア開発ライフサイクル（SDLC）プロセスが自動化および合理化され、SharePointの多くの利点を採用する企業への道が開かれ、私は「SharePointGuy」の卓越したレベルに躍り出ます。 次の8年間、私はSharePointを驚くべき低コストの生産性ツールとして利用して会社で多くの時間を過ごしました。 耳を傾ける人のために、私は多くのビジネスプロセスを改善し、コストを削減しますが、ドキュメントライブラリを備えた単純なチームサイトであるサイトが社内に多すぎました。 私はたった一人で、SharePointを自分のビジネスだけでなく、組織内の最上級レベルに販売するために上流に泳いでいました。
これはおなじみですか？
過去9年間、ほとんどの企業でSharePointを使用するのは、2つの基本的なシナリオのいずれかであることに気づきました。
1.ドキュメントライブラリを使用したチームサイト
これらのサイトは通常、チームテンプレートから作成され、非常に複雑なフォルダー構造を持つ可能性のある1つ以上のドキュメントライブラリが含まれています。 コンテンツタイプ、メタデータタグ、またはワークフローはほとんど使用されていません。 サイトはビジネスユニットによって完全にサポートされています。ビジネスユニットのメンバーはSharePointを正式に理解しておらず、「パワーユーザー」の役割を担っていません。 このサイトは、簡単なヘルプデスクリクエストチケットからサイトをすばやく生成できるインフラストラクチャまたはサポートチームによって作成されました。
2.大規模で複雑なコードベースを備えた完全にカスタマイズされたサイト
通常、これらははるかに大規模なサイトであり、非常に多くのユーザーがいます。企業のイントラネット、企業のHR、および企業のITサイトは、このタイプのSharePointの使用の通常の候補です。
これらのプロジェクトは通常、大きな方向性と期待から始まります。 これらは、企業がすでに調査した多くのハイエンドで高価なコンテンツ管理システム（CMS）の低コストの代替品として販売されています。 その後、プロジェクトが進むにつれて、要件は変化し、より複雑になります。 より多くのカスタムコードが必要ですが、最終的にはコードのサポートが問題になるほど複雑になります。
ここから、物事は通常制御不能になります。 開発チームは、限られたコードベースですぐに使用できる（OOTB）機能を維持することを前提として諦めました。 代わりに、完全にカスタマイズされたマスターページから、場合によってはプロバイダーがホストするアプリ（PHA）、または現在はプロバイダーがホストするアドインまで、完全にカスタマイズされたアプローチを採用しています。
私はすでにため息を聞いて目を転がしているのを見ることができます。 「トニー、これらは完全に有効な利用アプローチです。」 「私たちはこれらの両方を持っており、ユーザーはサイトを気に入っており、それらをサポートするのに問題はありません。」 これらの方法のいずれかが間違っているとか、一方が他方よりも有利であるとは決して主張していませんが、どちらのアプローチも、SharePointプラットフォームが提供するものを十分に活用する機会を逃しているだけだと思います。
さらに、これら2つのモデルは、SharePointを使用するにはコストがかかりすぎる、またはIT部門がWebサーバーとHTMLページまたは既定のCMSを介して同じ機能を開発できたと感じているビジネスにつながると信じています。クラウドソリューション。 どちらの意見も、SharePointが彼らのニーズに適したツールではないように思われるように、ビジネスとITの両方に感じさせます。
SharePointのメリットはAWOLになりましたか？
私たちがどこにいるのかをよりよく理解するために、私たちは一歩下がって、どのようにしてここにたどり着いたかを確認する必要があります。
「SharePointについてどのように知りましたか？」という簡単な質問に戻ります。 私の個人的な経験、および私が話をした他の多くのITリーダーの経験から、技術プラットフォームとしてのSharePointは、MicrosoftEnterpriseアドバイザーの支援を受けてインフラストラクチャチームから会社に紹介されました。
通常、最初のSharePointファームは、マイクロソフトとのエンタープライズ契約の一部として会社に提供される一種のテストベッドです。 この時点で、ほとんどの企業はビジネスクライアントと契約し、単一のチームサイトで最初のサイトコレクションを展開しています。 ビジネスクライアントは、ドキュメントライブラリと、ドキュメントを共同編集および共有する機能を気に入っているため、ビジネスプロセスの一部としてサイトを使用し始めます。
これは多くの人にとって完全に受け入れられるように聞こえるかもしれませんし、正直なところ、SharePointの実行可能なユースケースになる可能性があります。 しかし、SharePointをもう少し深く掘り下げてみると、SharePointは、インフラストラクチャチームが実装およびサポートする単なるプラットフォームではないことがわかります。これは、インフラストラクチャ、エンタープライズアーキテクチャ、およびアプリケーションチームの緊密なコラボレーションを必要とする堅牢なアプリケーションスペースです。
私は「反インフラストラクチャ」の人でも、インフラストラクチャチームに政治的に反対している人でもありませんが、最初から適切なパートナーのコラボレーションがなければ、SharePointプラットフォームの全範囲を理解できないリスクがあります。適切なビジネス戦略と利用計画の準備ができていません。 この状況はSharePointプラットフォームに固有のものではなく、多くのIT部門が直面している、適切なコラボレーションと戦略のはるかに大きな問題を示しています。
あなたのビジネスクライアントが鍵です
多くの場合、SharePointに関しては、多くの技術組織がビジネス戦略をまったく持っていません。 SharePointサイトを要求および作成する方法について、既存のプロセスに小さなプロセスを追加するだけです。 サイト作成プロセスに関するガバナンスが含まれていない場合もあります。これにより、大量のサイトコレクションが発生し、最終的にはサポートの問題が発生する可能性があります。
サイトコレクションやSharePointでの検索など、より大きな概念の使用に関する基本的な会話や教育があるかもしれません。 しかし、戦略の議論は非常に複雑になる可能性があります。 このため、多くの技術組織は、サイト作成プロセスで戦略を終了することを決定します。 代わりに、ゆっくりと、SharePointの基本的な主要機能から始めましょう。
あなたのビジネスクライアントは誰ですか？ 彼らは企業の技術チームですか、地域のマーケティングチームですか、それともR＆Dチームですか。 前に述べたように、SharePointの実装は通常、インフラストラクチャチームによって開始され、その後、ビジネスクライアントの母集団に徐々に浸透していきます。
場合によっては、ビジネスクライアントは、SharePointの2回目の使用が通常開始される大規模な主要な基幹業務アプリケーションを検討しているときに、より単純なコンテキストでSharePointについてすでに聞いているでしょう。 明確なビジネス採用戦略がなければ、技術チームがSharePointファームに適切な量の採用と使用を確実に行うことは、非常に遅く困難な道のりになります。
私の場合、SharePointを紹介されたときにすでに作成されていたSharePointサイトのほとんどは、非常に複雑で複雑なフォルダー構造を持つ大規模なドキュメントライブラリを備えた単なるコラボレーションサイトでした。
チームがフォルダ内のドキュメントの種類を正確に理解できるように、フォルダ名の一部は実際には小さな文でした。 メタデータタグもコンテンツタイプもありませんでした。単にフォルダにあるドキュメントだけでした。
コラボレーションのプロセス全体は、実際のドキュメントの共有でした。 誰もがドキュメントを共有できる単一のリポジトリがあり、それがチームのコラボレーションの範囲でした。 これが、ビジネスクライアントがSharePointの最大の価値と見なしたものです。
私がビジネスの人々と話し始めたとき、SharePointに対する彼らの印象はせいぜい熱狂的ではなかったのも不思議ではありません。 私の技術担当者の何人かでさえ、ファイルとフォルダ構造を処理するためにファイル共有を購入するだけで、大幅なコストを節約できると主張し始めました。
基本的なSharePoint機能の多くは、私のビジネスや、ある程度は技術チームにも適切に伝達されていませんでした。 これらは、コラボレーションとイノベーションを強化する大きな可能性を秘めた素晴らしいCMSツールとしてSharePointで販売されましたが、私たちが思いついた最高のものはファイル共有でした。
私のビジネスでの最初のインタビューの1つで、長いフォルダー構造のいくつかの理由は、人々が特定のファイルを見つけるためのある程度の構造を提供するためであることがわかりました。 ビジネスは、SharePointのベストプラクティスに従うことは言うまでもなく、 SharePointの基本的な検索機能さえ認識していませんでした。 SharePointをより効率的に利用できるだけでなく、プラットフォームの真の強みのいくつかについてクライアントを教育できるように、ビジネスクライアントを関与させる方法を見つける必要がありました。
より良いビジネスケースの提示
上記のビジネスクライアントへのインタビューからのフィードバックに基づいて、私は教育からやり直す必要があることに気づきました。 しかし、私たちが現在持っていたすでに大きな農場に基づいて、物事がすでに進んでいるときに、どうやって「最初からやり直す」ことができるのでしょうか？
ほとんどのサイトは、ドキュメントライブラリを備えたチームコラボレーションサイトでした。 そこで、ドキュメントライブラリから始めることにしました。 私のビジネスクライアントの1人に、ユーザーが探している適切なファイルを見つける可視性を高めながら、フォルダー構造を最小限に抑える方法でライブラリを再構築することに同意してもらいました。
一部のサイトの構造を深く掘り下げていくと、フォルダー構造が実際にはデータ要素であり、チームが共同作業しているさまざまな種類のファイルのグループであることがわかりました。 そこで、SharePointの非常に基本的でありながら強力な機能であるメタデータタグから始めることにしました。
クライアントにテクノロジーを教育する最も強力な方法の1つは、ある種のPOCを開発することだといつも感じていました。 POCの問題は、POCがコストに影響を与えることです。 アプリケーションを完全に開発しないように注意して、ビジネスが望んでいるものではないと判断するだけにする必要があります。
私の場合、コストは最小限でしたが、その価値は潜在的に巨大でした。 それぞれが20以上の個別のフォルダーを持つ複数のドキュメントライブラリを取得し、メタデータとコンテンツタイプを使用して1つのドキュメントライブラリとして再作成することにしました。 コンテンツタイプを説明するよりも、コンテンツタイプを使用することでデータ構造を追加できるだけでなく、ファイルに関連付けられた追加のメタデータを適切に管理できるようにする方法を紹介する方が簡単でした。
雪玉効果
多くのファイルには、重要で非常に役立つ情報が含まれていました。 ビジネスでは、非常に複雑なフォルダ構造を使用してファイルをグループ化することにしました。 たとえば、15のブランドごとにフォルダがあり、それらのフォルダ内に、マーケティング、財務、およびその他の主要なカテゴリのサブフォルダがありました。 それらのサブフォルダー内には、さらに多くのサブフォルダーがありました。
これにより、個々のファイルを開いて表示する必要がなく、特定のファイルをより簡単に見つけることができました。 しかし、この複雑なフォルダー構造のために、すべてのファイルが正しいフォルダーに配置されるようにするためのビジネスプロセスが必要になりました。 彼らが知ったように、新しいビジネスプロセスは管理が非常に難しく、多くのファイルが間違った場所に置かれてしまいました。
これにより、メタデータの使用法をビジネスに取り入れて説明することができました。 ファイル構造をいくつかの主要なコンテンツタイプに分解し、重要なデータ検証とともに主要なデータ要素を含めるために使用しました。 SharePointのより良いビジネスケースをビジネスに提示するための私の旅の最初の大きな成功は、コンテンツタイプ、メタデータ、およびデータ検証のこの単純なアプローチでした。
ビジネスの注目を集めたので、主要な利害関係者と一緒にドキュメントライブラリの簡単なウォークスルーを行うことにしました。 データをフィルタリングして並べ替えることで、メタデータとコンテンツタイプの真の価値を紹介しました。
驚いたことに、彼らは、存在すら知らなかった基本的なSharePoint機能のいくつかに単に驚かされました。 次に、カスタムフィルターページを含めて、簡単なページ作成、Webパーツ、およびフィルター処理で何ができるかを実際に示すことにしました。
これらのページを完全にカスタマイズしないように細心の注意を払いました。 OOTBWebパーツのみを使用したかったのです。 そうすれば、私がより複雑なシナリオに進む前に、SharePointの基本的な機能をよりよく理解できるようになります。 カスタムページは大成功で、検索エンジンがそれらに提供する拡張機能についても話し合いませんでした。 SharePointの基本をよりよく採用するまで、検索エンジンを延期したかったのです。
SharePointワークフロー：鍵
私の謙虚な意見では、SharePointワークフローは、ビジネスクライアントを教育し、組織内でSharePointを確実に採用および使用するための最も重要な要素の1つです。 ワークフローは、私が最初に言及したVSLiveで最初に注目した機能であり、SDLCプロセスを組み込んだ最初の完全なSharePointPOCに大きく貢献しました。
SharePointに関して言えば、ビジネスクライアントとの最初の会話は、通常、ビジネスプロセスに関するものです。 ビジネスプロセスは、SharePointを使用して生産性を高め、コストを削減するための鍵です。これは、ビジネスクライアントが熱心に話し合うことです。
多くの上級ITエグゼクティブに言ったように、ビジネスプロセスを通じて、SharePointの使用と採用を実質的に保証できます。 すべてのビジネスユニットにはプロセスがあり、これらのプロセスのほとんどにはチェックポイントまたは承認ポイントがあります。これは、承認メールの送信または承認タスクの作成のいずれであっても、ワークフローが役立つ場所です。
ワークフローがプロセスを改善し、コストを削減する方法をビジネスクライアントに納得させたら、同じ承認タスクを使用してサービスレベルアグリーメント（SLA）または主要業績評価指標（KPI）を作成する方法についてビジネスクライアントを教育します。
ドキュメントがレビューおよび承認されるまでにかかる時間をビジネスユニットが理解することは、どれほど素晴らしいことでしょうか。 次に、その情報を取得して、プロセス全体を改善するための戦略を採用することができます。 これにより、プロセスを監視および管理するためのKPIを作成できるようになります。
プロセスの改善に対する上級管理職のコミットメントを示すために、ボーナス目標プログラムの一部として改善を含めることもできます。 これは通常、SharePointの採用と使用を通じて達成できる真の価値をビジネスクライアントに納得させるホームランです。
未来
Office365とSharePointOnlineについて最初に聞いたとき、ホストされたSharePoint環境の価値を理解しましたが、この新しい方向性が将来に最適であることをビジネスクライアントに納得させる方法に再び苦労しました。 PHAについて聞いて興奮しましたが、アプリケーションサポートの観点からこれがもたらす可能性のある潜在的なコストについても慎重でした。
私の会社は、アウトソーシングモデルを使用してサードパーティの開発ベンダーの方向性を開始しました。これにより、ベンダーは、メンテナンスと拡張のための大きな残余コストを伴う複雑なビジネスアプリケーションを簡単に作成できます。
すべてのホストモデルと同様に、変更に備える必要があります。 人間として、私たちは変化が本当に好きではありません。テクニカルサポートチームとして、私たちは変化とそれがチームの前進能力にどのように影響するかを恐れることがよくあります。
InfoPathを廃止するというMicrosoftの決定を最初に聞いたとき、そしてワークフローエンジンとしてFlowが導入されたとき、私の反応は「また行きます！」でした。 Microsoftは、私が最新のSharePointの方向性を「販売」することをより困難にする別のビジネス上の決定を下そうとしていました。 Flowが提供するものを確認し始めたとき、私は自分が見たものに失望しました。
しかし、Microsoftには将来のビジョンがあり、統合ポイントに関するFlowの機能の一部を確認し始めるまで、私はそれを理解できませんでした。 Flowは、今日の既存のアプリケーションの多くと統合されますが、企業が独自の統合ポイントを作成することもできます。 これにより、さまざまな基幹業務アプリケーションとの統合によるビジネスプロセスの改善に関する私のビジネスディスカッションの主要なプレーヤーになりました。
可動性
これは、テクニカルエグゼクティブとして、多くのビジネスクライアントとの会話の標準的なトピックになっています。 レスポンシブウェブデザインと、それを最大化してモバイルウェブプレゼンスを向上させる方法について話し合うのは問題ありません。 また、SharePointがレスポンシブWebページを利用して、モバイルデバイスでより優れたSharePointエクスペリエンスを作成する方法についても説明します。 Microsoftは、モバイルSharePointアプリケーションも開発しました。 しかし、通常、議論はスタンドアロンのモバイルアプリケーションを持つ方向に向かっています。
「スタンドアロンモバイルアプリケーション」という言葉を聞くとすぐに、レジの問題が発生します。多くのモバイルアプリケーションは、特殊なサポートモデルに加えて、コストのフットプリントが高くなっています。 SharePointの世界からの私の答えはPowerAppsです。
過去に行ったように、私はすぐにモバイルPowerAppsPOCアプリケーションの開発を開始します。 アプリケーションのバックエンドデータソースとして、既存のSharePointリストとライブラリを利用します。 PowerAppsは、私が構成ベースの開発プラットフォームと呼んでいるものです。これにより、モバイルアプリケーションの非常に迅速な開発が可能になります。
ユーザーは、SharePointでPowerAppsオプションを選択するだけで、独自のPowerAppsモバイルアプリケーションを作成できます。 新しいアイテムをリストまたはライブラリに追加および編集するための画面の多くを自動的に作成します。 また、モバイルデバイス分野の現在のすべてのリーダーでテストされています。 独自のIDEと、技術開発者または技術に精通したパワーユーザーでさえも簡単に適応できる非常に単純な構成ベースの言語を備えています。
ここでも、SharePointプラットフォームの採用と使用を改善するために使用できるSharePointの優れたツール/機能があります。 この新しいツールをSharePointとFlowに組み込み、プッシュ通知と、位置情報サービスや電話などの本質的にモバイル機能を使用する機能を組み込みます。PowerAppsは、ビジネスクライアントとの採用と利用について話し合うための新しいお気に入りの会話ポイントになりました。共有ポイント。
実際、私のPOCは私のビジネスに熱心に受け入れられただけでなく、位置情報サービスやGPSナビゲーションなどのモバイル機能を使用したため、PowerAppsエンジニアリングにPOCアプリケーションを提示するように依頼されました。道具。
VSLiveからSharePointソリューションへ
サンフランシスコに向かう窓際の席に座っていたので、その単純な旅行が私の技術的なキャリアにどのように大きな影響を与えるか想像もできませんでした。 SharePointは真に革新的で協調的なツールであり、MicrosoftはSharePointでビジョンと方向性を提供し続けています。
現在利用可能な数千のSaaSまたはPaaSソリューションのいずれかと同様に、これらのソリューションを最大限に活用する方法を真に理解していることを確認する必要があります。 全体的なビジネスプロセスを改善し、ビジネスクライアントを満足させ続けることで、SharePointは私の武器の重要なツールになりました。 将来と、SharePointが私と私のビジネスに提供するものを楽しみにしています。