並行採用

‹テンプレート How-toは統合が検討されています。› 

並行導入とは、組織内の以前の ( IT ) システムからターゲット ( IT ) システムに移行する方法です。リスクを軽減するために、一定期間、古いシステムと新しいシステムを同時に実行し、その後、新しいシステムの基準が満たされると、古いシステムを無効にします。このプロセスには、慎重な計画と管理、および多大な労働時間の投資が必要です。

このエントリでは、並行導入の一般的なプロセスに焦点を当てています。必要に応じて、プロセスをより有意義に解釈するために (実際の) 例を使用します。さらに、並行導入に含まれるすべての手順の完全な概要を提供することを目的としたプロセスを視覚化するためにプロセス データ モデルを使用しますが、並行導入の固有の特性に重点を置きます。一般的な 4 種類の導入すべてに共通するいくつかの特性、特に実装戦略の定義については、「導入 (ソフトウェア実装)」で説明します。

並行導入の他に、一般的な導入の種類が 3 つあります。特定の導入方法の選択は組織の特性によって異なります。このトピックに関する詳しい情報は以下で説明します。他の 3 つの導入方法は次のとおりです。

• ビッグバン導入/プランジ導入: ビッグバン導入では、組織全体を古いシステムから新しいシステムに瞬時に移行します。これは最も安価なオプションですが、新しいシステムに障害が発生した場合、組織は大きな問題に陥ります。また、システムがユーザーに受け入れられないリスクも生じます。ただし、2 つのシステムが共存できない場合、または新しいシステムの起動が緊急の場合は、これが唯一のアプローチとなる場合があります。
• 段階的導入(段階的変換とも呼ばれます): 段階的導入の実装では、組織はモジュールまたはサブシステムごとに異なるフェーズで新しいシステムに徐々に移行します。一部のシステムは、システム全体に依存しすぎるため、部分的に導入することができません。段階的導入を使用するとリスクは少なくなりますが、古いシステムから新しいシステムへの移行に最も時間がかかるため、最も多くの混乱が生じます。
• パイロット導入: パイロット導入方法は、複数の拠点や大部分が独立した部門を持つ大規模な組織で使用されます。新しいシステムは拠点または部門の 1 つに導入され、時間の経過とともに他の拠点または部門に拡張されます。(新しいシステムが失敗した場合の境界は限定されます) (Turban、2002)

並列変換が実行可能な変換戦略とみなせない場合がいくつかあります。まず、新しいシステムに大幅なスキーマ変更が含まれているかどうかを検討します。一方のシステムで必要なデータ要素が他方のシステムで設定されていない場合、データの不正確さ、最悪の場合はデータの破損につながる可能性があります。もう 1 つの懸念は、システムが消費者向け既製テクノロジ (COTS) に依存しているかどうかです。COTS ベンダーのドキュメントに、複数のアプリケーションで同じデータベースを共有できないと記載されている場合、並列変換はオプションではありません。例としては、Oracle の Siebel 製品が挙げられます。他の COTS 製品でも、パッチまたはメジャー アップグレードに固有のライセンス キーが必要な場合に制限が課される場合があります。適用されると、データベースが変更され、ライセンス制御を回避しようとする試みとして、同じデータベースに対して並列システムが実行されていることをアプリケーションが誤って検出し、システムが無効になる可能性があります。

並行導入のプロセスに関する慣習はほとんどないようです。いくつかの情報源 (例: Turban、2002、Eason、1988、Rooijmans、2003、Brown、1999) では、単一のプロセス記述名が使用されていません。並行導入という用語はこれらの情報源で示されていますが、情報源ごとに一貫して、並行変換、並行実行、シャドウ実行、並行カットオーバー、および並行実装と示されています。これは、プロセスの一般的な記述に明確な分類が必要ないためと思われます。標準的な実装方法はいくつかあり、さまざまな導入手法が説明されていますが、多くの場合は実用的なコンテキストで説明されています。実際のケース シナリオや、Regatta: 導入方法、SIM、PRINCE2などのより包括的な実装手法のセットです。一般に、並行導入は、新しいシステムを実装するシステム エンジニアリングの方法と見なすことができます。

原則として、並行導入方法は、組織内のシステムを変更する決定とは異なり、その目標を達成するための 1 つの可能な手段と見なすことができます。ただし、最適な実装戦略を決定する際に考慮される要素はかなりあります。さらに、実装が成功するかどうかは、導入方法に大きく左右されます。(Lee、2004)

並行導入プロセスは、実際の変換の前のステップ、つまり変換シナリオの構築とすべての要件の特定とテストに注意を払わずに表現することはできません。したがって、図 1 で特定されたすべてのプロセスを実行し、特定された変換戦略のいずれにも必要な共通のアクティビティを簡単に取り上げながら、プロセスを説明します。

図 1 は、並行導入プロセスの概要を示しています。左側は、プロセスに貢献するアクティビティの流れを示しています。同時に実行されるアクティビティの前には、太い黒線が引かれています。アクティビティの並行実行が終了すると、アクティビティは同様の黒線で再び結合されます。アクティビティから別のアクティビティへの矢印がない場合は、そのアクティビティが上にあるより大きなアクティビティの集合体であることを示しています。アクティビティは、次の 4 つの主要なフェーズに分かれています。

• どのような実装戦略を実行する必要があるかを扱う実装戦略を定義します。
• 実装前は、実装に関わるすべての側面と要件の計画を構築することに関係します。
• 組織を準備する前のフェーズに従って、組織を適切に準備する必要があります。
• 変換では、実際の変換プロセスと変換プロセスの終了、つまり新しいシステムでの続行を扱います。

主なフェーズは他のアクティビティに細分化されており、表 1-1 から 1-4 で簡単に説明します。

モデルの右側は、プロセスに関係するデータについて説明します。重なり合う開いた長方形のペアとして表されるこれらの概念の一部は、複数の概念に細分化できます。重なり合う閉じた長方形のペアは閉じた概念を示します。つまり、より多くの概念に細分化できますが、並列採用プロセスではそれ以上重要ではありません。ダイヤモンド形の図は、それにリンクされている概念が集約概念として機能し、この概念が他の概念で構成されていることを示します。最後に、開いた矢印はスーパークラスとサブクラスの関係を表します。矢印でリンクされている概念は、それにリンクされている概念のスーパークラスです。図 1 のこの構文は、統一モデリング言語 ( UML ) 標準に準拠しています。図 1 の概念は、表 2 で定義されています。プロセス内のこれらのサブアクティビティの詳細なコンテキストは、表の下に示します。

図 1 の概念は、以下の表 2-1 で定義されています。

並行導入の前に、実装戦略を決定します。これは並行導入に特有のものではなく、組織が行う変更管理プロセスの一部と見なすことができます。(Lee、2004) 導入方法に関する実装戦略の決定に関係するいくつかの要素については、 「導入 (ソフトウェア実装)」で詳しく説明しています。

組織がパイロット変換、ビッグバン、または段階的導入ではなく並行導入を選択する理由は、多くの場合、コストとリスクのトレードオフです (Andersson、Hanson、2003)。並行導入は、最もコストのかかる導入方法です (Chng、Vathanopas、2002、Microsoft、2004、Anderson 他、2003)。これは、組織が 2 つのシステムを一定期間並行して実行する必要があるためです。2 つのシステムを同時に実行するには、人材への投資が必要です。(追加の)人員を十分に準備する必要があるほか、手順が交差する並行実行のストレスの多い期間を乗り切らなければなりません (Rooijmans、2003、Eason、1988)。2 つのシステム間のデータの一貫性とデータ破損の防止に努める必要があります。 (Chng 他 2002、Yusuf、2004) 変換プロセス自体だけでなく、新しいシステムを扱うためのトレーニングにも影響があります。

ビッグバン方式に従って新しいシステムを実装する必要がある場合、失敗するリスクが高くなります (Lee、2004)。組織が古い (レガシー) システムの変更を強く要求する場合、リスクの少ない並行アプローチと追加コストのトレードオフは、それらの追加コストを優先する必要があります (Lee、2004)。それにもかかわらず、ERP の導入はほとんどの場合ビッグバン方式に従っています (Microsoft、2004、Yusuf、2004)。 つまり、組織は導入戦略を明確に検討し、この決定をリスク管理または変更管理

分析 に統合する必要があります。

組織を適切に準備するには、IT 要件と組織要件の両方の要件分析が必要です。要件分析と変更管理の詳細については、他の場所を参照してください。並行導入の場合、最も重要な IT 要件 (該当する場合) は、2 つのシステムを同時に実行することです。変換フェーズには、古いシステムが主導するタイムスロットがあります。キャッチアップ期間中に古いシステムから新しいシステムにデータを転送するには、移行モジュールが必要です (Microsoft、2004)。他の実装方法には、この要件は直接ありません。IT 要件の詳細については、ソフトウェア エンジニアリングを参照してください。

IT 要件に加えて、組織要件には、人材のトレーニング、変化する可能性のある組織構造、組織の有機的組織または機械的組織特性への対処 (Daft、1998) などの人事管理の問題、そして最も重要なトップマネジメントのサポート (Brown、Vessey、1999) が必要です。Brown ら (1999) は、トップマネジメントが開始できる 2 つの異なる役割、いわゆるスポンサーとチャンピオンの役割を特定しています。

• 「プロジェクト スポンサーは、予算のサポートと、主要なビジネス担当者がプロジェクト チームで役割を果たすことを保証する責任を負います。」
• 「プロジェクト チャンピオンは、プロジェクト チームの正式なメンバーであるかどうかは関係ありませんが、変更管理の取り組みにおいて重要な役割を果たすことができます。」

並行導入プロセスは非常にストレスが多く、古いシステムに保守的に固執することなく、起こりつつある間違いに対処できる十分に準備された従業員が必要です。(Eason、1988)

組織内で新しいシステムを導入するための詳細な計画を立てることは非常に重要です (Lee、2004、Eason、1988)。並行して移行を行うための時間計画で最も重要なことは、物事を急がず、実際の移行フェーズで遅延が発生する可能性を恐れないことです (Lee、2004)。PRINCE2 メソッドと同様に、明確に定義されたマイルストーンを使用して作業することも非常に有益です (Rooijmans、2003)。時間計画の詳細については、 「計画」および「戦略計画」を参照してください。

要件評価には、実装スクリプトの再定義が含まれます。作成された IT 要件と (可能な場合) 組織要件をテストする必要があります。IT 要件だけでなく、組織の責任を評価できるテストも実行できます (Rooijmans、2003)。ここでも、トップマネジメントのサポートと関与が重要です (Eason、1988)。評価に利用できるリソースが提供されない場合、直接的な結果として実装が失敗する可能性があります。この評価の後、実装スクリプトはより明確な変換シナリオに再定義されます。

このように、変換シナリオは、あらゆる側面における組織変更の青写真で構成されています。ただし、並行導入の範囲でまだ十分な注意が払われていないトピックが 2 つあります。

• 回避策戦略 / ロールバック計画:他の導入シナリオとは異なり、ロールバック計画を伴う回避策またはコンティンジェンシー戦略も変換シナリオに組み込まれています。回避策戦略は、別のエントリでより広い範囲で定義されていますが、このコンテキストでは、上記の表で定義されているように、次のことを示します。バックアップ プラン。変換シナリオで、変換プロセスでのエラーを防ぎ、エラーを回避して実装を成功させるために採用される戦略です。(Microsoft、2004)。ロールバック計画は、回避策戦略の 1 つとして、変換フェーズで問題が発生した場合に開始されます。並列導入では 2 つのシステムが同時に実行されるため、ロールバック計画では、トランザクションを処理するデータベースまたは他のシステムがレガシー システムで完全に追跡可能である必要があることを示しています (Microsoft、2004)。実際、並列導入では、先行システムと (非先行)バックアップシステムの性質により、定義ごとにこのロールバック計画が提供されます。
• 基準指標:変換シナリオは 2 つのシステムの移行を実行するための青写真であるため、定量化可能な基準も必要になります。再定義された IT 要件と組織要件は、測定可能なコンポーネントに転送されます。テスト変換で基準が満たされない場合は、回避策戦略を展開する必要があります。

実際の変換フェーズが始まりました。このプロセスの間、組織はストレスの多い時期にあります (Eason、1988、Rooijmans、2003)。 2 つのシステムは変換シナリオに従って並行して実行され、新しいシステムは綿密に監視されています。 新しいシステムの基準が満たされると、古いシステムは主要なシステムではなくなり、新しいシステムが引き継ぎます。回避策戦略の一部であるキャッチアップは、古いシステムのバックアップであり、信頼性エンジニアリングとデータ回復の手段を提供します。 キャッチアップを行うには、自動キャッチアップと手動キャッチアップの 2 種類の方法があります (Rooijmans、2003)。 該当する場合は、リモート バックアップ サービスも展開できます。

• 自動キャッチアップ:組織の準備段階で作成された自動システムによって転送されるキャッチアップ。このシステムは、古い主要システムから新しい主要システムへの変換時に、データまたは情報を新しいシステムに自動的に転送します。自動システムの利点は、高速で正確であることです。欠点は、早い段階で転送システムを作成するのに時間がかかることです。
• 手作業によるキャッチアップ:実際の変換に要する時間が短い場合、または新しいシステムに転送する情報の複雑さが小さい場合、組織はキャッチアップを手動で転送することを選択できます。この手順の利点は、情報を転送するためのシステム (ソフトウェア プログラム) が不要であり、このような転送プログラムに伴う可能性のある問題がないことです。トレードオフは、正確性と時間です。キャッチアップを手動で転送するには、かなりの余分な時間がかかり、小さな人的エラーに対して脆弱になります (Rooijmans、2003)。さらに、労働時間への追加投資はすでに高いのに、手動キャッチアップ システムは人員にさらに大きなプレッシャーをかけます。

ケース スタディから学べる教訓がいくつかあります。Lee (2004) が説明したネバダ DMV システムのケースでは、新しいプロセスへの実装には政治的な影響もあることがわかりました。変更されるシステムが一般大衆に影響を及ぼし、変更されるのが内部システムだけではない場合は、組織に影響を与える圧力がさらにあります。この場合、顧客がたとえばコミュニケーションや商品の注文でより多くの遅延に直面すると、会社のイメージや評判などの概念が大幅に変わる可能性があります。システムが政治的に敏感な場合は、変換方法にさらに注意を払う必要があり、リスクが少ないため、できれば並行導入を選択することをお勧めします。

ビジネス コンサルタント会社 (Venture、2004) が実行した、新しいポートフォリオ システムの実装に関する実際のケース シナリオから得られた一連の教訓は、現場から得られた興味深い教訓を示しています。それらは、科学的研究の組み合わせに基づく一般的な並行導入プロセスについて言及された問題に完全に適合しているようです。要約すると、次のようになります。

• リスク評価と緊急時対応（回避策）計画は非常に重要です
• プロジェクトチームの役割を割り当てる
• トレーニングとテストの計画を含む特定のマイルストーン（PRINCE2など）を構築する
• 潜在的なリスクを特定し、必要に応じて緊急時対応計画を実行します
• プロジェクトのステータスを伝える
• 変更は適切に承認される必要がある
• 変換戦略ではデータ要件を慎重に検討する必要がある
• 新規データと変更されたデータは検証ルールに照らしてテストする必要がある
• 徹底したロールバック計画を構築する
• 可能であれば、パイロットへの転換を交渉する

並列変換には、パンチカードやテープリールを入力に使用していた時代には業界で主流だったものの、21 世紀では実用的でない可能性のある問題が少なくとも 2 つあります。その問題とは、次のとおりです。

1. 顧客、生産ラインの作業員、その他ほとんどすべてのエンドユーザーが、異なるインターフェースを介してすべてのトランザクションを 2 回入力することを期待するのは非現実的です。

2. 2 つのマルチユーザー インタラクティブ システム間のタイミングの違いにより、両方のシステムが正しく動作し、内部的に一貫性があり、単独で正常に使用できる場合でも、異なる結果が生じる可能性があります。

その結果、並列変換は、結果の絶対的な検証可能性が必須で、ユーザーがすべて組織内部でこの要件を理解しており、アクティビティの順序が出力に影響することを許さない会計システムなど、今日ではいくつかの特定の状況に限定されています。実際には、パイロットおよび段階的な変換方法の方が今日ではより適切です。

• 製品ソフトウェアの採用: ビッグバン採用
• 段階的な導入
• 採用（ソフトウェア実装）
• レガッタ：採用方法
• 変更管理
• 信頼性工学
• ロールバック（データ管理）
• リスク管理
• ソフトウェアエンジニアリング
• 実装

• Andersson I. Hanson, K. (2003)。ソフトウェア組織における技術の普及、応用情報技術の学位論文、ヨーテボリ大学
• Brown, CV & Vessey, I. (1999). ERP 導入アプローチ: 緊急時対応フレームワークに向けて、第 20 回国際情報システム会議議事録、ノースカロライナ州シャーロット、12 月 13 ～ 15 日、411 ～ 416 ページ。
• Chng, S.、Vathanophas V. (2002)。「組織間エンタープライズ システムに向けて: フォーカス グループ スタディ」第 6 回太平洋アジア情報システム会議 (PACIS 2002)。東京、日本。2002 年 9 月 2 ～ 4 日。
• Lee, O. (2004). ネバダ州 DMV システムのケーススタディ、ビジネスおよび経済アカデミージャーナル、第 3 巻
• Ribbers, P. & Schoo, KC (2002)。複雑なソフトウェア実装プログラムの設計、第 35 回ハワイ国際システム科学会議 (HICSS'02)、第 8 巻
• Yusuf, Y. & Gunasekaran, A. & Abthorpe MS (2004). エンタープライズ システム プロジェクトの実装: ロールスロイスにおける ERP のケース スタディ。International Journal of Production Economics、87、251-266。

• ダフト、RL（1998）組織理論とデザイン。ウェスト：インターナショナルトムソン
• Eason, K. (1988) 「第 9 章 実装とサポート」『情報技術と組織変革』ロンドン: Taylor & Francis
• Turban, E. & Mclean, E. & Wetherbe J. (2002)「第 14 章 情報システムの構築」、経営のための情報技術、ニューヨーク: John Wiley & Sons, inc
• ルイマンズ、R.、テー、M. デ、およびクープ、R. (2003)。レガッタ: ICT の導入は、教育現場での取り組みでもあります。ハーグ: Ten Hagen en Stam Uitgevers。

• UNIX から Windows への基幹業務アプリケーションのプラットフォーム変更 (2004)、バージョン 1.0 Microsoft、2006 年 3 月 5 日取得 [1]
• ポートフォリオ会計システムの導入：現場からの教訓（2004年）、Venture Financial Systems Group Ltd、2006年3月6日閲覧[2]