目標は、システムの構造と動作に直接影響する基本的なメカニズムです。 システムの各モジュール（参加者）は単一のメカニズムのフレームワーク内で動作し、それから独自の利益を得ることができますが、各参加者が独自の目標を追求する場合、結果はシステムではなく、有名な著者の別のf話になります。
サードパーティのソフトウェアを企業の情報システムに導入するプロジェクトでは、共通のビジョンの問題が特に深刻です。 このようなプロジェクトには通常、多くの参加者がいます。
- 実装された自動化のメリットを最大化することを目的とするビジネス。
- 実装から重要な利益を引き出すことを目的とする請負業者。
- 人件費と責任を最小化しようとする独自の顧客開発チーム。
- 変更に対する保護が必要なシステムのエンドユーザー。
そして、目標の違いはしばしば製品の失敗につながり、この相反するアイデアの鍋で「調理」されます。
この記事では、視覚的な例によって、矛盾した目標がもたらす否定的なプロセスを検討します。 私たちのケースで検討されているプロジェクトは、ERPシステムの実装です。
問題解決
通常、ERPを実装する最初のステップは、会計単位（参照データ（MDM段階））を編成することです。 ERP参照データは非常に不機嫌です。 EXCELでの名前による検索と比較が半自動アカウンティングの場合に十分な場合、ERPボウラーには一意の識別子が必要です。 さらに、さまざまなシステムでの参照データの再入力はかなりの努力です。 問題の説明に基づいて、「参照データ（MDM）の統一システムを作成し、ディレクトリの管理で順序を復元する」という共通の目標があります。 しかし、それは明確に形成されておらず、この段階では、共通の目標に関する意見の相違にすでに直面しています。
- 企業は、ディレクトリを自動化することで何人/時間を節約できるかをすでに考慮しています。
- 請負業者はすでに見積もりを準備しています-これは最小限の労力でかなり迅速な利益です。
- 開発チームは、変更を最小限に抑えるために、異なるデータ構造を持つシステムのオブジェクトをマッピングしようとし、その情報ランドスケープの新しい「異物」に精通しようとします
- ビジネスユーザーは、既存のプロセスを中断せずにそのままにしておくために、より多くの「ウィッシュリスト」を表現しています。「これが必要な理由」を達成することは困難であり、場合によっては妥協が必要です。
短期的な結果
そして、このような状況でも、プロジェクトチームは誠意を持って作業しました。 設計、開発、テストに合格。 ほぼ期限に間に合い、すぐに安定しました。 ビジネスは新しいシステムに慣れてきています。 これが最後かもしれません-プロジェクトのストレッチで成功と呼ぶことができますが、私たちは主なことを忘れていました。 つまり、このステージを強調する本当の目的は何でしたか？
「データマスター」の導入後、単一のMDMシステムからこの情報のすべての可能な消費者へのディレクトリの転送が自動化されました。 同期できるシステムオブジェクトのID。 不可能な場合-変換テーブルが構成されます。 ディレクトリは同期されますが、会計システムは参照データの信頼性をそれほど要求しない古いルールに従って動作するため、これまでのところ誰も実際に使用していません。
最初の果物
ERPシステムの実装の次の段階（ドキュメントを配布し始めた）で、多くの症状とその発生原因がありますが、根本原因は1つである災害が発生しました。 「症状」とその原因のいくつかをリストすることから始めます。
- 現在のシステムから参照データを削除することはできませんが、ERPはディレクトリのボリューム全体をドラッグしないことを決定しました。 そのため、一部のデータにはERP IDがありませんでした。 そして、判明したように、「ERP接続」を持たない参照データが誤って積極的に使用されたため、多くのドキュメントを処理できなくなりました。
- ERPシステムの一部のオブジェクトには「寿命」がありました。 たとえば、ERPでは、取引相手はアクティブでも非アクティブでもかまいません。 非アクティブなカウンターパーティでドキュメントを作成することはできませんが、ソースシステムで誤って作成されました
- ERPの可能性はLS（レガシーシステム）の機能よりもはるかに広く、ユーザーが使用しないことを約束したビジネスプロセスは、システムのライフサイクルの新しい段階への移行に関連して積極的に使用されました。 つまり、LSはERPに関して柔軟性が低いことが判明しました。
そして、そのような例がたくさんありました。 しかし、根本的な原因は1つだけです 。それはシステムの目標です 。
失敗の原因の特定
振り返ってみると、MDMステージの目標は会社の参照データをクリーンアップすることでした。なぜなら、ERPデータを非常に要求するシステムは、少なくとも1つのセクションに曲線データを含む複数のドキュメントを見逃さないからです。
この目標が設定されている場合：
- ビジネスは、参照データおよび関連するビジネスプロセスの順序の復元に積極的に参加します。
- 独自の開発チーム-データ構造とERPビジネスプロセスに注目したシステムを設計します
- ビジネスユーザーは、将来のドキュメントプロセスについて積極的に相談し、建設的な提案を行います。
- 請負業者-彼のシステムの運用について積極的に助言されました。それは、ビジネスと顧客のITから彼にとってより魅力的だったからです。
結果
大規模なプロジェクトでは、コミュニケーションの問題がしばしば発生します。 どうしてそれが起こったのかは覚えていませんが、特定の時間の目標は非常に明白であり、目の前にありました。 特定の段階で、各チームメンバーはそれぞれの能力と責任範囲内で作業に没頭します。 同時に、誰もが十分な品質と効果でタスクを遂行します。
プロジェクトの実施と大規模で明らかな問題の「解決」の後、実施チームは停滞期に直面しました。 この期間中、システムは一定のポイントの問題で安定しました。これらの問題は、「松葉杖」の開発によって最大限に解決され、最悪の場合、これらのシステムへの手動介入によって解決されます。 そして、それをどうするか誰も知りませんでした。
いいえ、私たちの物語では、スーパーヒーローは登場しなかったため、元の目標に戻り、いくつかのアプローチを根本的に変更しました。 できる最大のことは、これらの目標のプリズムを介して新しい松葉杖を検討し、「...一時的な決定が下されました...次のプロセスへのアプローチを改訂することを強くお勧めします...」という精神で人々に行動を起こさせることでした。
結論
- 目標はシステムの基礎であり、たとえばインターフェース仕様の文書化と同じくらい真剣に受け止める必要があります。
私は個人的にそれらをアーキテクチャ文書に書き留め、私の決定のプレゼンテーション中にそれらを表明します。 - 各決定は目標のプリズムを通して見る必要があり、少なくとも各プロジェクト参加者の目標は、プロジェクトの基本的な目標と矛盾してはなりません。
各ソリューションがプロジェクトの目標をどのように実現するのか、どのようにしてこの決定に至ったのか、代替ソリューションは何かを書き留めます。 - 多くの場合、目標を知ることは非常に困難です。
しかし、目標が明確に記述されていない場合、それらについて推測し、すべての参加者と調整します。
この記事の目的は、読者に大規模なITプロジェクトの暗黙的でかなり調査が不十分な問題を理解し、推論と結論において正しい方向に進んでいるかどうかを理解することです。