- 実装は、ビジネスプロセスのチェーンがすでに実装されているプロトタイプから始まります。これは、顧客がターゲットとして受け入れることができます。同時に、プロジェクト中に排除しなければならない違いがあるかもしれません。
- プロジェクトに取り組むために、コンサルタント、ビジネスおよびITサービスの顧客担当者で構成される単一のチームが作成されます。顧客担当者はプロジェクト中にトレーニングを受け、コンサルタントと一緒にシステムのプロトタイプをテストし、システムの要件を策定して、その実装を受け入れます。ITサービスは積極的に参加し、いくつかの要件を実装し、プロジェクトの最後にシステムをサポートします。
- プロジェクト中に、さらにいくつかのプロトタイプがセットアップされ、各反復で顧客の要件に近づきます。プロジェクトの過程で、要件が指定され、数回変更されます。
実際、大規模なERP実装プロジェクトでは、俊敏性の原則が適用されます。人と相互作用はプロセスよりも重要であり、実用的な製品は文書化よりも重要であり、顧客との協力は契約よりも重要であり、変更への準備は初期計画に従うよりも重要です。
ただし、大規模な統一システムを使用して、固定価格で署名された契約の条件では、これらの原則を採用する必要があります。追加の条件と制限がなければ、プロジェクトはほとんど完了せず、確実に予算を超えます。
まず、これは、アジャイルプロジェクトでよくあるように、各反復をすぐに使用できる完全な機能ブロックの開発で終了する必要がある場合に、分割して開始できるシステム開発ではありません。 ERPシステムは、部分的にではなく、全体としてのみ実行できます。
第二に、要件を制限しない場合、要件の明確化と変更は無限になり、プロジェクトは拡大し、追加の資金が必要になります。
したがって、最初の問題は、ERPシステムが密接に相互接続され、エンドツーエンドのプロセスが浸透しているパーツで構成されていることです。したがって、各反復で、そのすべての範囲で全体的なシステムが必要です。システムが最初から作成されるのではなく、完成品であるという事実によって、タスクは容易になります。多くの場合、最初の実用的なプロトタイプとして使用できる標準プロセスを備えた業界ソリューションまたは事前構成済みシステムがあります。
次のプロトタイプの準備には時間がかかります。システムは大規模で複雑であり、プロジェクトの参加者が多いため、プロトタイプの準備、テスト、コメントの作成には少なくとも2か月かかります。私たちの場合、反復は通常のアジャイルのように2週間ではなく、2〜5か月です。
各反復で完全なシステムを作成しますが、それらの間には違いがあります。最初の反復では、これは標準または業界固有のプロセスを備えた典型的なシステムです。標準的なプロセスは、顧客が最終的に期待するものとはかなりかけ離れている可能性があります。トップレベルのプロセスは同じですが、詳細は大きく異なります。私が「顧客」と言うとき、私はシステムを使用する人々を意味します-彼と請負業者との関係に関係なく-契約、またはそれは請負業者がIT部門になることができる会社の内部プロジェクトです。
最初のプロトタイプのテスト結果に基づいて要件を収集した後、2番目のプロトタイプをセットアップします。ここでは、設定で実装できるすべての要件が実装され、顧客のテストデータが読み込まれ、最初のプロトタイプのテスト中に浮上したすべての質問が解決されます。お客様は、システム内のビジネスプロセスを確認し、現在の実装がどの程度適しているか、システムがどの程度効率的であり、要件を満たしているかを確認します。
2回目の繰り返しで、システムの将来のユーザーは、初めてではなく、より快適に感じ、すでにより意味があり詳細な新しい要件を提示します。理想的には、すべての重要な問題はこの期間中に解決する必要があります。変更はより高価になり、リリースまでの時間が少なくなるためです。
3回目の繰り返しでは、拡張機能の開発を開始する余裕があります。つまり、用語で言うと、システムの「カスタマイズ」です。これらは、標準システムにはないレポート、手順、フォームの場合がありますが、ビジネスプロセスをシステムの標準に合わせることが常に可能であるとは限らないため、非常に必要です。拡張機能を開発する決定は、他のすべての可能性を考慮した後に行われます。彼らの開発とサポートはかなり高価な喜びであり、これは追加のお金です。
3つ目のプロトタイプは、目標に近い本格的なシステムとなるよう、数ヶ月間準備を進めています。通常、システムは完全に構成されており、大量のデータがそこにロードされ、すべての重要な拡張機能がインストールされています。多数のユーザーで徹底的にテストされています。このテストは通常約1か月続きます。
3番目のプロトタイプをテストした後、コメントと質問が残り、それらの開発計画を作成します。そして、すべての重要な発言は、ローンチによって排除されるべきです。
この時までにプロジェクトのペースは非常に激しくなり、戦いの間のように時間が圧縮されます。指示の準備、ユーザーのトレーニング、データの変換、組織の変更を行う必要があります。以前は未解決の問題が発生し、誰かが重要な状況を発表するのを忘れたことを覚えています...ローンチの前に、別の問題が実行され、受け入れテストが行われ、新しいシステムの開始が行われます。
もちろん、これはERPシステムの実装に対する反復アプローチの非常に表面的な説明です。この方法では、文書化、プロジェクトチームとユーザーのトレーニング、データ変換、組織の変更など、実際にはプロジェクト管理の他のアプローチと変わらないすべてのプロセスを詳細に説明します。
合理的な疑問が生じます。4回目、次に5回目または6回目の反復に進まないようにプロセスを編成する方法は？制御できない変更や要件の明確化のリスクをどのように回避できますか。これは、詳細を掘り下げるにつれて、場合によってはビジネスの変更によって自然に発生します。
もちろん、そのようなリスクがあり、それは非常に重要です。プロジェクトの入り口では、要件は契約で固定されていますが、原則として、それらは一般的な方法で定式化されており、悪魔は詳細にあります。
プロジェクト開始時の「ウォーターフォールアプローチ」では、要件が修正され、技術的な割り当てが署名されます。これは、後で要件の変更を拒否したり、変更のために追加のお金を要求したりするための正式な基盤になります。反復的なアプローチでは、このトリックは適用できません。
要件は変更される可能性があり、必ず変更されることを理解しています。私たちは時間とお金に投資しています。問題は、これらの変更の範囲です。私たちは大きな間違いを犯し、最後に新しいコメントの波を受け取る可能性があります。特に、顧客が最初にプロジェクト「slipshod」への参加について言及し、参加のために間違った人を選択し、明確な要件を策定せず、「すべてがうまくいく」ことを望んでいる場合は特にそうです。コンサルタントに依存しています-そして結局、私たちは深刻な問題を抱えています。
したがって、プロジェクトの終了時に要件が広まるリスクを軽減するための最も重要な要素は、顧客の関与です。アジャイル開発の原則のまったく同じ実装。これによれば、チームはプロジェクトの最初から緊密に連絡を取り合って、顧客と開発者が協力します。これにはいくつかの重要な結果があります。まず、システムの実際のニーズとこれらのニーズへの不適合を早期に特定します。第二に、システムの準備プロセスに関与することで、顧客は完成した形での転送時ではなく、プロジェクト全体を通して徐々に所有者になります。それは彼の仕事の結果となり、プロジェクトの終わりまでに、これが彼のシステムであるため、「あなたのシステムは機能していません」のような主張をすることができなくなります。
決定を下すことができる最も有能な人々が100％の時間プロジェクトに割り当てられるとき、それは良い習慣です。私たちの実践では、これらはビジネスプロセスの所有者、その代理人、またはサービスマネージャーの完全な信頼を享受する従業員でした。はい、それは難しいです、はい-余分な人はいない、はい-最善を尽くすことは難しいです。しかし、これがプロジェクトを迅速に作成し、高品質のシステムを取得する唯一の方法です。プロジェクトの参加者は、企業がどのように機能するかを理解し、新しい知識を習得し、新しい方法で作業することを学び、原則として、彼らに新しいキャリアの機会を生み出します。 ERP実装プロジェクトは、マネージャーのための新しい人員予備の作成として、非常に強力な人員育成イベントと見なすことができます。
次に注意すべきことは、プロジェクトの厳しい時間的制約です。プロジェクトのスケジュールは積極的で、開始日は変更しないでください。プロジェクトが拡大されると、ビジネス要件が変更される可能性が高くなります。プロジェクトの日付がずれ、新しい要件が表示され、状況が繰り返される場合は、システムの準備ができていないので、起動を延期しましょう。非常に長いプロジェクト期間でもシステムの完成度は達成されず、すべての要件が発売前に完全に特定されることはありません。実際の操作だけがすべてのボトルネックと本当に重要なことを示しています。したがって、リリース後、少なくとも3か月の安定化期間があり、その間、プロジェクトチームはユーザーを支援および教育し、エラーを修正し、新しい要件を受け取り、必要な改善を行います。
締め切りを延期して需要を拡大したいという誘惑に抵抗するには、誰もがそれらの締め切りに間に合わせる強いインセンティブを持っている必要があります。もちろん、請負業者にとって、これらは契約上の義務と予算です。顧客の動機は通常、上から、会社の経営者または株主から形成されます。たとえば、発売準備の決定を行うCEOは、株主への義務によって束縛される可能性があります。プロジェクトマネージャーとプロジェクトチームは、期限を守ることを条件として、プロジェクトの終了時にボーナスによって動機付けられます。部門の責任者は、企業の命令によって立ち上げる必要性に直面するでしょう。
それが提供する新しい機会への満足のいく期待のために、できるだけ早くシステムを立ち上げたいという誠実な願望があるとき、それはめったに起こりません。新しいシステムは、まず第一に、ストレスと、最初のインターフェースで慣れ親しんだものから不快なものへ、より多くの制御、より多くの情報を入力する必要性に移行する必要性です。エンドユーザーが新しいシステムを歓迎することはほとんどありません。彼らが合意に達し、その利点を見つけるには時間がかかります。また、時間どおりに起動するという内部の動機が最初にプロジェクトに組み込まれていない場合、システムが100％起動する準備ができていないため、起動は延期されます。
発売日が厳しいため、要件を際限なく拡大および改良することは不可能になります。顧客の代表者を含むプロジェクトチームは、彼らの指名をやめ、必然的に差し迫った締め切りに直面して、優先順位、何かを延期する可能性について考え始めます。プロジェクトマネージャーの仕事は、プロジェクトの最初から、この差し迫った立ち上げの感覚、時間の不足を形成することです。プロジェクトの前半は落ち着いた雰囲気で、後半は必然的なレースで非常にストレスがたまります。これを行うには、中間目標を設定する必要があり、プロジェクトの最初のフェーズが時間内に圧縮されるようにプロジェクトスケジュールが形成されます。これにより、開始前の最後のフェーズのために予備が形成されます。長距離走行にはさまざまな戦略がありますが、しかし、ここでは戦略は同じである必要があります。最初からすばやく実行する必要があり、最後に加速するのに十分な力がない可能性があります。
上記のすべての要約：
- 反復的なアプローチは、システムが明示的および暗黙的な顧客の要件に近接しているという点で、はるかに優れた結果をもたらします。
- このアプローチを実装するには、プロジェクトへの顧客の完全な関与が絶対に不可欠です。
- 要件の急増と際限のない改善を回避するには、プロジェクトのタイムラインを厳しく制限し、プロジェクトの参加者がそれらを遵守するように動機付けられる必要があります。
もちろん、これらは基本的な原則に過ぎず、特定の条件、会社の特性、参加者の個性に依存する微妙な点はまだたくさんあります。いずれの場合も、すべてが個別に決定されます。