コンセプト証明

コンセプト証明を使用すると、設計をビジネス環境でテストできます。組織には、たいていの場合、期待される結果と一体になった設定済みの一連のテストケースである、テストケースデータベースが存在します。このテストデータベースには、コンセプト証明を適用できます。そして、すべてが順調に進めば、ドキュメント化された結果は新しい結果と等しくなります。コンセプト証明の目的は、「配備の設計」で提起されたすべての疑問に答えることにより、すべてのニーズを効果的に、最小限のリスクで満たせることを証明することです。

これは一般にすばやく実行されるため、限られたデータセットに基づいて設計を改良するための十分な時間を取ることができます。通常は、コンセプト証明とそれに続く設計改良を、数回繰り返す必要があります。最後に実行するコンセプト証明は、いくつかの内部アプリケーションが統合されたものになるはずです。企業の共有サービス統合は、一般に、初期採用者によるサインオン標準モデル、次に一般の参加者によるサインオン標準モデル、最後に残された者たちによるサインオン標準モデルに準拠したものになります。初期の採用者で成功すると、そのアプリケーションを一般の採用での参照用として使用しやすくなります。

初期採用

ミッションクリティカルなアプリケーションや収益を創出するためのアプリケーションは、最初のアプリケーションとして選択すべきではありません。よりリスクの少ない戦略は、重要なアプリケーションの中でもロールアウト時に問題が発生しても企業運営に大きな混乱をきたさないものを選択することです。たとえば、部門ポータルは、会計年度末の会計システムよりも、シングルサインオン (SSO) ロールアウト用の拠点として適しています。

また、プロセスの弱点を排除し、結果が立証され、成功が迅速に認識されるように、初期段階でアプリケーションロールアウトの数を制限してください。最良のロールアウトの戦略は、可視性を最大限に高めながら、組織上のリスクを最小限に抑えることです。このため、製品に関する適切な経験を持つ配備チームがクリティカルアプリケーションを担当するようにします。

一般の参加

配備プロジェクトは単一のアプリケーションで始まりますが、多目的システムを構築できるように、他の内部顧客の要件も同時に評価する必要があります。中心的な IT グループは、より大規模な組織を代表するサービスを提供するため、サテライトグループのさまざまな基準およびスケジュールを受け入れることができなければなりません。スケジュールは十分に大きなウィンドウに表示し、サテライトグループが変更およびアップグレードを自分たちのアプリケーションの配備および品質保証 (QA) サイクルに組み入れる時間を取れるようにする必要があります。