プロジェクトを最初から最後まで費用対効果の高いものに保つ方法

の方法＃3 Dominoアプリケーションの移行の課題をマスターするための7つの新しい方法

このシリーズの前半、プロジェクトの範囲を最も重要なものに集中させる方法と、コードベースの概要を把握することで、プロジェクトの効率を高め、より適切な意思決定を行う方法について説明しました。

パート3では、私たちのほとんどが個人的および仕事関連の経験から非常によく知っている大きなハードルのXNUMXつである「開始するのに適した場所を見つける」に取り組みたいと思います。

Notes / Dominoプロジェクトがインフラストラクチャを最新化しているのか、クラウドに移行しているのか、プラットフォームを完全に離れているのかは関係ありません。 既存のインフラストラクチャを統合することは、最も成功したプロジェクトの重要な最初のステップです。 環境内の枯れ木を見つけて削除すると、プロジェクト全体の労力が大幅に削減され、コストが節約されます。

適切な質問をすることは、プロジェクトの範囲を縮小する上で重要な要素でした。 このシリーズの最初の部分。 これらの質問のいくつかをもう一度見て、回答を使用して統合の可能性を特定する方法に集中しましょう。

あなたは事業の規模を真に理解している必要があります。 統合の可能性を評価し、成功を測定するためにKPIが必要です。

ユーザー

サーバー

アプリケーション

これは、私たちが耳にする最もよくある質問のXNUMXつです。 これは、統合の明らかな出発点です。

多くの場合、最初の本能は、未使用のデータベースインスタンスをすべて削除し、迅速な勝利を祝うことです。 これは、状況によっては意味があります。たとえば、サーバーの数を減らすことだけを考えているが、どのアプリケーションを廃止できるかを判断するのは非常に信頼性が低い場合です。

さらに興味深いのは、データベースインスタンスが使用されていないアプリケーションの数を調べることです。 同じレプリカIDを共有するデータベースインスタンスのこれらのグループは、「レプリカセット」と呼ばれるものです。 レプリカセット全体が未使用で、どのサーバーでもアクティビティが発生しない場合にのみ、アプリケーションは本当に未使用と見なされます。

活動が観察される期間は、廃止措置において重要な役割を果たします。 すべてのデータベースが毎日使用されるわけではありません。 年、四半期、または月にXNUMX回だけ使用される季節的な使用量のデータベースがある場合があります。 このバリエーションをキャプチャするには、 panagenda データベースが未使用であることを確認するために、最低XNUMXか月の観察期間をお勧めします。 観察期間が長ければ長いほど、より良い決定を下すことができます。

枯れ木を特定した後、私たちは環境をきれいにするための第一歩を踏み出し、少し厳しい地域での機会を探し続けています。

統合は、未使用のライセンスのコストを見つけて排除する機会です。 ほとんどの組織は、非アクティブなユーザーと十分に活用されていないサーバーを帳簿に載せています。 この情報に基づいて行動することで、わずかな労力で多くのお金を節約できます。

環境から非アクティブなDBを見つけて削除すると、サーバーの使用率が低下します。 十分に活用されていない複数のサーバーを統合すると、ライセンス、運用、および管理のコストが削減されます。

統合は、Dominoネットワークの設計を確認する機会でもあります。 たとえば、帯域幅を考慮して15年前に設計された環境は、再評価する必要があります。 最新のインフラストラクチャでは、以前は重要だった冗長性やサーバーの分散化の概念の一部がすでに廃止されている可能性があります。

多くの組織は、複数のソリューションで実行されるアプリケーションを使用してハイブリッド環境を作成することを選択しています。 ドミノが戦略的なアプリケーションプラットフォームのままであっても、特定の汎用サービス（メール、チームルーム、ファイルライブラリなど）は、時間の経過とともにドミノから切り離される可能性があります。 このような移行シナリオでは、ユーザーアクティビティも影響を受けます。 追加のライセンス節約の可能性が生成され、データベース設計を理解することで予測できます。

現在特定のプロジェクトに従事していない場合でも、動的な作業環境の変化のペースが速いと、継続的なアクティビティのレビューを通じて全体的なIT支出を削減する絶え間ない機会が生まれます。

設計の継承の概念は、プロジェクトの過程全体で重要なトピックになります。 このシリーズの第XNUMX部 一般的なトピックと、それがNotes / Domino環境の成長に与える影響を紹介しました。 一般に、設計は、移行および近代化プロジェクトにおいて非常に重要です。 その重要性は、早くも統合フェーズから始まる可能性があります。

標準テンプレートから設計を継承するデータベースを特定することは、いくつかの異なる理由から重要です。 組織的な観点からは、彼らが関与するビジネスプロセスを知らなくても、彼らが果たす目的を比較的簡単に理解できます。たとえば、ドキュメントライブラリは、ファイルの交換、ドキュメントのアーカイブなどに使用されます。 調達部門、管理部門、製造部門のいずれで使用されているかは関係ありません。 カスタム開発されたアプリケーションについてそのレベルの洞察を得るのは、それらのアプリケーションが何年にもわたって進化している場合、非常に困難な場合があります。 これは、XNUMXつかXNUMXつだけでなく、数百または数千を見ている場合に特に当てはまります。

技術的な観点から、このような標準データベースが提供する技術的機能を知ることは非常に価値があります。 Web経由で使用できるのか、モバイルデバイスで利用できるようにするのかについての見通しを提供します。 特にHCLはクラシックテンプレートのモダナイゼーションに多くの投資を行っているため、モダナイゼーションプロジェクトでは大きな利益になる可能性があります。 ほとんどの標準テンプレートには、他のプラットフォームへの標準の移行パスを提供するISVが存在するため、移行では非常に有益な場合もあります。 これらは、手動移行作業の範囲からほぼ除外できます。これは、「アクティブなユーザー」や「サーバーで使用されるDB」などのさまざまなKPIに影響を及ぼします。 パスが何であれ、標準のテンプレートベースのアプリケーションでの作業は、カスタム開発されたアプリケーションの変換よりもはるかに安価です。

これらのトピックを組み合わせて統合プロジェクトに適用し、調査結果から最大の利益を得る方法をまとめましょう。 ステップバイステップで使用する小さなチェックリストを作成することもできます guide 考慮すべき最も重要なことを通して：

タスク：未使用のアプリケーションを特定する

タスク：標準テンプレートに基づいてアプリケーションを特定する

タスク：非アクティブなユーザーを特定する

タスク：十分に活用されていないサーバーを特定する

タスク：Dominoネットワーク設計を確認する

その最初の統合フェーズの後、すべてが削減され、手に負えない成果が選択され、ライセンスコストの節約の可能性が明確になったら、時間とリソースをより多く消費するタスクを引き受けます。 ここでは、近代化プロジェクトと移行プロジェクトの違いがより顕著になります。 しかし、それはあなたの背後にある計算を検証する時でもあります business case。 詳細を知りたい場合は、このトピックについて last blog ポストと webinar このシリーズの.

プロジェクトが何であれ、常に必要となる戦略的な情報がいくつかあります。 今後の最も重要なトピックのXNUMXつをカバーします blog 投稿と webinars:

アプリケーションの将来を決定する際には、アプリケーションの利害関係者を特定する機能が非常に重要です。 アプリケーションを使用する部門または担当者が、ビジネスプロセスにおけるアプリケーションの役割を理解する必要があります。 ただし、モダナイゼーションまたは移行作業のコストを分配できるようにするために、どの部門または場所がそれを使用しているかを知る必要もあります。

ほとんどのアプリケーションは、環境のいずれかの部分に依存しています。 それらの多くはコード自体に根ざしています：ハードコードされたサーバーまたはユーザー名、IPアドレス、外部ライブラリ、ファックスシステムなど。これらの依存関係がどこにあるか、それらがどのような影響を及ぼし、どのように修正できるかを知る必要があります。数百または数千の設計を再設計する必要なしに、最も効率的な方法。

これからは、私たちが取り組んでいるアプリケーションの輪が継続的に拡大していきます。 各ステップはよりコストがかかり、慎重な計画はこれまで以上に大きな利益をもたらします。

世界中の多くの企業が HCL Notes/Domino* 長年。 彼らはその関係から来る多くの利点を知っています。 さらに、Notes / Dominoは、プロセスとその動作の中心にあります。 これらすべてにもかかわらず、世界中のIT意思決定者は、Notes / Dominoが役割を減らすか、まったく役割を果たさない未来を想像し始めています。

*以前のIBMNotes / Domino