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