エンタープライズ システムのベスト プラクティス

  • [アーティクル]

この記事は、"From the Trenches" コレクションの一部です。 エンタープライズ システム全般 (Microsoft Project Server を含む) の運用上のベスト プラクティスについて説明します。 エンタープライズ システムはユーザー レベルの使いやすいインターフェイスを提供することを目指していますが、このホワイト ペーパーでは、それを提供するために必要なテクノロジとインフラストラクチャがどのくらい複雑になるかについて言及しています。 また、この複雑さに対応するために、エンタープライズ システムにおいて高レベルな信頼性を維持するための最善の方法を提供する基本的なベスト プラクティスをどのように使用するかを説明します。

この記事の Word バージョンをダウンロードするには、「 Enterprise Management のベスト プラクティス」を参照してください。

その他の記事については、「 溝から」ホワイト ペーパーを参照してください。

エンタープライズ管理のベスト プラクティス

私は主にエンタープライズ タイムシートまたはエンタープライズ プロジェクト管理システムについて書いています。そのようなシステムと話す展開の最も一般的なフェーズは、選択フェーズまたは構成フェーズです。戦略的な観点について話します。 この記事では、運用プラクティスについて詳しく説明します。これは、エンタープライズ タイムシートや Microsoft Project Server などのプロジェクト システムだけに限定された記事ではありません。 むしろ、一般的にはエンタープライズ システムに関するものですが、この問題は確かにほぼすべての Project Server デプロイに関連します。

既に展開されている Project Server システムに遭遇したり、既存のクライアントと話したりすると、組織がどのように展開され、システムとその環境がサポートされているかについてよく質問されます。 私たちが業界で始めたとき、私たちがインストールするプロジェクトソフトウェアは常にエンドユーザーのPC上に住んでいたので、これらは簡単な会話でした。そして、システムの世話は常にローカルの概念でした。 最近ではまれに当てはまる。 エンタープライズ システムは、エンド ユーザーが通常、他の Web ページと同様に Web ブラウザーを介して機能にアクセスできるインターフェイスまたは表示レベルで簡単です。 これらのシステムが前面にあるのと同じくらい単純なのは、後ろにあるのと同じくらい複雑です。 そのインターフェイスを表示するために必要なテクノロジは、多くのレイヤーを持つ可能性があり、テクノロジとインフラストラクチャの複数のソースに依存し、(それが十分でない場合は) 常に更新されている可能性があります。

ただし、エンタープライズ システムで高い信頼性を維持する可能性を最大限に高めることができる基本的なベスト プラクティスがいくつかあります。

所有者を検索する

実際、成功したエンタープライズ システムにはビジネス所有者と技術所有者の両方があるため、これを 2 人の所有者に分割する必要があります。 ビジネス所有者が IT 部門のエグゼクティブであり、エンタープライズ システムが主にその部門用である場合にのみ、所有者は同じことができます。 それでは、次の 2 つの部分でこれを見てみましょう。

ビジネス所有者を見つける

この人物は、プロジェクト管理システムの結果に既得権を持つエグゼクティブ レベルまたは上級管理レベルの人物である必要があります。 システムが提供する必要がある利点、またはシステムが克服しなければならないビジネス上の課題は、このエグゼクティブに直接影響を与える利点と課題である必要があります。 そして、誰かがそれを言う前に。いいえ。通常、委員会や複数の人にすることはできません。

責任はどこかに置かねばなりませんが、それはほとんど常に一人の人を意味します。 この人は、システムの実装のエグゼクティブ スポンサーでもあるかもしれませんが、そうでない場合もあります。 多くの場合、エグゼクティブ スポンサーはエンタープライズ システムの最終的なビジネス所有者ではありません。

展開プロジェクトが終了しても、ビジネス所有者はシステムを所有し、不要になった場合は、別のビジネス所有者を特定し、システムにコミットする必要があるか、システムを廃止する必要があります。

技術所有者を見つける

エンタープライズ レベルのシステムでは、技術者を使用するだけでは不十分です。 エンタープライズ システムは、テクノロジの多くの層に依存しています。 技術所有者は、IT 部門の十分なマネージャーまたはエグゼクティブである必要があります。これにより、他のテクノロジレイヤーの所有者とすぐにやり取りできるようになります。 これには、SQL Server データベースを所有するシニアユーザー、SQL Serverがインストールされているデータベース サーバー、Project Server がインストールされているアプリケーション サーバー、ネットワーク、Web サーバーまたはサーバー ファーム、インターネット接続、ファイアウォール、Active Directory および Exchange サーバー、セキュリティ サーバーまたはシステム、クライアント レベルのオペレーティング システム イメージが含まれます。 シニアは、環境の他の側面を制御するマネージャーに対して、このエンタープライズ システムを表すことができる必要があります。

目的を持つ

Project Server a) に目的があり、b) がその目的を果たしていることを確認します。 明らかに聞こえますか? そうじゃありません。 多くの場合、エンタープライズ システムは間違った理由で取得され、システムを適用する目的を探すために IT 部門の誰かに該当します。 エンタープライズ システムのビジネス目的でサインオフするユーザーは、ビジネス所有者である必要がありますが、他のユーザーが関与している可能性があります。 私はいつもそのようなエグゼクティブに私が何年も使ってきた質問を尋ねます,「今、あなたは何のビジネス上の決定を行うことができますか、あなたは大きな困難だけで行うことができます, その作成は、このシステムの展開によって有効になります?"ビジネス要件 (目的の機能は言わなかったことに注意してください) が解決されたら、エンタープライズ システムがその要件を実際に満たしていることを確認します。 私は、機能の買い物リストを持っているが、彼らが彼らと一緒に達成しようとしているものについての理解がほとんどない多くの人々に会います。

組織が進化するにつれて、ビジネス所有者がこの基本的な概念に戻っていることを確認します。 Project Server のようなエンタープライズ システムを展開するだけで、展開先のビジネスが根本的に変わる可能性があるため、システムに対する組織の要件が変わる可能性がある点は驚くべきことではありません。

Project Server が採用され、展開されてから数年後に組織に入ってくるのは、組織にとって重要な理由を知っているユーザーを見つけることが不可能である場合に限られます。 システムは確実に使用されています。 それは完全な慣性で進められているが、目的は失われ、毎日それを恩恵を受ける幹部は、その利益がどこから来ているのかを認識していない。

エンタープライズ アーキテクチャに取り込む

何年か前に、私は私たちの技術スタッフの一人と一緒にクライアントの場所を混乱した場所に行ったのを覚えています。 自分でインストールした Project Server のインスタンスが、あらゆる種類の問題を引き起こしていました。 実際にそこにいる間、私たちは多くの技術担当者にインタビューし、システムをその層を通して戻ってトレースするように頼みました。 データベースレイヤーに着いたとき、私たちは驚きました。 組織の標準データベース サーバーの 1 つではなく、システムをインストールしたSQL Serverバージョンはエンド ユーザーの PC にありました。 PC を再起動したり、PC をオフにしたり、何かをインストールしたりするたびに、データベースは使用できなくなります。 これは文字通り何百人ものエンド ユーザーに影響を与えました。

組織は大規模な組織であるため、依存するエンタープライズ サーバーやインフラストラクチャが不足していません。 この場合、問題は簡単に修正されました。 良いレッスンでした。 展開しているシステムは、組織が安定し、信頼性が高く、安全になるという膨大な労力を費やした可能性がある既存の企業インフラストラクチャに織り込まれていますか?

バックアップする

わかっています。 これは愚かですよね? 驚くほど残念ながら、それはありません。 エンタープライズ システムは、同時にバックアップされるシステムの複数の側面に依存する可能性があるため、バックアップが複雑になるという悪名高い場合があります。 もちろん、基本的なデータだけでなく、実装のメタデータと構成データもあります。 また、システムと一致する必要がある補助システムからの関連データは、同じバックアップ スキームの一部である必要があります。 Project Server について考えるときは、プロジェクト データベースだけでなく、SharePoint Server データベースもバックアップすることを考える必要があります。 2010 より前の Project Server バージョンでは、グローバル テンプレートのバックアップが必要になる場合があります。 現在でも、個々の PC 上にあるテンプレートの要素が存在する可能性があります。

バックアップだけでは不十分です。 システムが変更またはアップグレードされたら、少なくとも 1 回データベースの復元を行います。 私は何年も前に、バックアップ戦略の設計を支援していたクライアントと一緒にいたことを覚えています。 彼はサーバーをシャットダウンし、ハードディスクを引き出し、別のハードディスクに入れて、私たちを見て「そこに。 ハード ディスクがクラッシュしました。 これは、新しくフォーマットされたハード ディスクです。 Project Server を復元してください。私は後戻りしましたが、より多くの私はそれがいかに良い要求であるかに気づいたので、それを考えるほど、誰も(またはそれ以来)要求をしなかったことがいかに衝撃的であるかに気づきました。 そのため、少なくとも 1 回は復元テストを行います。 ところで、そのシステムを復元できましたが、それが疑われるほどきれいに戻らず、バックアップ手順を更新する必要がありました。

ステージング/運用

シェイクスピア氏は「すべての世界は舞台であり、すべての男女は単なるプレイヤー」と語った。 この場合、ステージはステージングに関する詳細であり、それが任意のエンタープライズ システムにとって重要です。 システムが運用環境になったら、新しい構成を試したり、新しいカスタマイズを追加したり、新しいレポート、リンク、フィールド、その他の変更を試したりできます。 更新とアップグレードが行われ、運用環境のユーザーに影響を与える前に、これらのすべてをステージング環境または開発環境で最初に試す必要があります。 ブラウザーの更新やデータベースの更新と同じくらい基本的なものは、エンタープライズ システムをループにスローする可能性があるため、運用環境とは別のステージング環境を維持し、維持してください。 この時代の仮想サーバーでは、これは以前よりも簡単な場合があります。 多くの場合、環境全体を運用システムから複製できますが、デプロイ方法によっては、簡単に行うことができます。 サーバー全体をコピーした場合でも、テクノロジ パズルのさまざまな部分が参照される可能性があることを思い出してください。

監視、監視、監視

エンタープライズ システムの監視に使用できる監視ポイントは多数あります。 まず第一に、エンド ユーザーが Project Server を使用できるようにすることが重要であり、適切な技術スタッフが利用できない場合は、できるだけ早く通知を受け取ることも不可欠です。 ありがたいことに、エンドユーザーがまだ問題に気付いていない場合でも、技術スタッフに自動的に通知できるシステムが機能し、利用可能であることを保証するための多くのツールが市場にあります。 しかし、監視には他にも重要な側面があります。 アプリケーションの正常性の監視とログを保持することをお勧めします。これには、使用しているメモリの量、使用している CPU の量、システム自体から復旧した場合でも報告された可能性があるエラー、必要なサーバーの再起動、および技術インフラストラクチャの他の要素の関連する正常性が含まれます。 たとえば、IIS に技術的な問題があることを知ることは、エンタープライズ アプリケーションの可用性を維持するために非常に重要な場合があります。

小さな変更でも変更です

Project Server のベースとなるテクノロジは、日ごとに変化します。 これらの変更をすべて回避することは不可能です。 Windows Server オペレーティング システムは、多くの場合、数日ごとに更新プログラムを受け取ります。SQL Serverは数週間ごとに更新プログラムを受け取ることができます。 個々の Windows クライアント オペレーティング システム、ウイルス スキャナー、ファイアウォール、Internet Explorer とそのアドインは、定期的に更新プログラムを取得します。 データとエンド ユーザーの間のチェーンの任意の部分は、アプリケーションを分解できる潜在的なポイントであるため、テクノロジのスタック全体で変更を管理するための構造を作成します。

多くの異なるエンタープライズ アプリケーションがスタックの同様の側面に依存する可能性があるため、これは困難な場合があります。 SharePoint Server 環境全体がダウンしているのを見つけるために、しばらくの間、Project Server を無邪気に更新したクライアントが 1 人いました。 明らかに、Project Server/SharePoint Server 更新プログラムの適用方法にエラーが発生しました。 完全なバックアップがあり、データは失われませんでしたが、アップグレード プロセスには即時ロールバック プロビジョニングがないため、逆に数日かかったため、影響は壊滅的でした。

別の組織では、会社で既に使用されている他のエンタープライズ アプリケーションが、より新しいブラウザー バージョンをサポートしていないことを検出するために、すべてのユーザーがブラウザーバージョンをアップグレードする必要があることを確認するために、別のエンタープライズ アプリケーションを更新したクライアントがいました。 それは諺の岩とハードな場所でした。 最後に、エンタープライズ システムのアップグレードをロールバックし、すべてのエンタープライズ アプリケーションが新しいブラウザーのアップグレードを進めることができるまで待つ必要がありました。

統合されるよりも、統合された見た目の方が良い場合があります

販売デモでは、常に複数のツールの統合が非常に簡単に見えます。 ねえ、データはここから始まり、そこで終わります! Project Server などの柔軟性の高いツールと Finance/ERP などの他のエンタープライズ システム間のリンクを確立することは十分に困難であり、リンクが確立される前に両方のシステムが運用環境で安定していることを常にお勧めします。 ただし、進行中の場合は、2 つのシステムの変更を監視し、引き続き適切にリンクすることを念頭に置いて監視することがさらに重要です。

いずれかのシステムをアップグレードすると、データの変更、構造の変更、または異なる技術的要件が発生する可能性があります。 また、新しい機能や利点が考えられますが、運用環境にロールアウトする前に、既存のリンク機能がステージング環境でテストされていることを確認してください。

ドキュメント、ドキュメント、ドキュメント

Project Server が選択され、展開されたときにそこにいたユーザーは、これらのロールに永遠に存在しません。 実際、優れた仕事をした場合、組織が必要とする次のエンタープライズ展開の管理はオフになります。 そのため、構成の決定、予想される利点、運用上の期待、およびそれらの決定を行うために使用されたパラメーターを文書化することが不可欠です。 将来、他の人はこのシステムを見て、「彼らは何を考えていたのか」と頭をかいているでしょう。必ず伝えてください。

エンタープライズ システム ドキュメントは、アップグレードのたびに更新されるライブ ドキュメント、ビジネス所有者または技術所有者の変更、または運用構造またはビジネス要件の大きな変更である必要があります。

ジャンプする前に見る

それは私たちが初めて暗い湖に飛び込む人々に与えるアドバイスです。 浅いですか? 表面のすぐ下に岩がありますか? Project Server のようなエンタープライズ プロジェクト管理システムは、実際に複雑なデータ要素を 1 つの場所に取り込むことができます。この場所では、そのデータに基づく決定がより効果的になり、それらの決定の利点が組織に大きな違いをもたらす可能性があります。 ただし、組織をコストやリスクにさらすことなく、必要な利点を得られるようにエンタープライズ システムを運用できるように宿題を実行する必要があります。これにより、それらの利点の価値をすぐに一掃できます。

著者について

Chris Vandersluis は、カナダに拠点を置く MICROSOFT 認定パートナーであるモントリオールの社長兼創設者です。 彼はマギル大学で経済学の学位を取得し、プロジェクト制御システムの自動化に30年以上の経験を持っています。 彼は、プロジェクト管理研究所 (PMI) の長年のメンバーであり、Microsoft Project Users Group (MPUG) のモントリオール、トロント、ケベックの各章の設立を支援しました。 クリスが執筆した出版物には、Fortune、Heavy Construction News、Computing Canada Magazine、PMI の PMNetwork が含まれており、彼は Project Times の定期的なコラムニストです。 彼はマギル大学で高度なプロジェクト管理を教え、多くの場合、北米と世界中のプロジェクト管理協会の機能で話します。 HMS Software は、TimeControl プロジェクト指向のタイムキーピング システムの発行元であり、1995 年から Microsoft Project Solution Partner です。

Chris Vandersluis には、次の電子メールで連絡できます。 chris.vandersluis@hms.ca

Chris Vandersluis による EPM 関連の記事をさらに読む場合は、HMS の EPM ガイダンス サイト (https://www.epmguidance.com/?page_id=39) を参照してください。