ERPパッケージ適合分析おススメのアプローチ【前編】

fit & gap

ERPパッケージの導入では、ERPの標準機能でどのぐらい現行の業務を運用することができるかが、プロジェクトのコストと期間、そして機能的な品質に影響を与えます。プロジェクト方針では、ERPパッケージに業務を合わせるという方針を掲げたものの、気がつけばERPの標準機能が適合している割合が小さく、膨大なアドオン開発のリストができてしまった、いうことを耳にすることもあります。

最近、そのような相談を受けることがありまして、今回はERPパッケージが持つ標準機能でどのぐらい現行の業務を運用することができるか検証する(いわゆるプロトタイプと呼ばれる作業をする)際のポイントを整理してみたいと思います。

一回目の今日は具体的なプロトタイプ作業のコツの前に、これまで私自身が途中から支援に入ったり、身近なところで聞いたプロジェクトを振り返り、よくある失敗例を見てみます(なお、様々なERPパッケージが存在しますが、ここではある程度規模が大きいERPパッケージを想定して話を進めます)。

ERP開発が始まるまでに明確にすべきアウトプット

パッケージの購入が決まって、導入作業に着手し、実際の開発が始まるまでの期間で明確にしなければいけないこと(アウトプット)は次の3点です(要件定義とか設計フェーズなどと呼ばれる段階です)。

  1. ERPパッケージを使用した新しい業務プロセスの設計
  2. ERPパッケージの標準機能を適用する領域と不足している機能をアドオン開発して適用する領域の切り分け
  3. ERPパッケージの基本セットアップ(マスタとコードの設計方針、主要なキー項目など)の定義

これらアウトプットのために、プロジェクトでは現行業務及び情報システムの調査を実施して、適合分析と呼ぶタスクを実施します。いわゆるパッケージの適合率が高いとか低いとかいう場合、上記②の標準機能を適用する領域の大きさを指しています。

アドオン開発がどの程度であれば適正かというよりも、問題となるのは、パッケージの適合率が実態と乖離してしまうことだと思います。例えば、本来ERPパッケージの標準機能を活用した業務運用ができるにも関わらず必要以上にアドオン開発の領域が大きかったり、当初は標準機能を適用できるとしていたのが調査不足であとになってアドオンが増えてしまったりすることです。

経験上、このようなプロジェクトにて実施される適合分析は、次のいずれかのケースに該当することが多いようです。

ERPよくある失敗(その1)-実機を使用しない/一般的なデモ環境しか利用しない適合分析

現行の情報システムのユーザー部門にヒアリングをかけて業務要件をパッケージの標準機能にあてはめていきますが、ユーザーにはERPの画面ハードコピーなどが入った紙芝居(スライト資料)しか提供されないケースです。実機を使用する場合でも、一般的なデモ環境がセットされたものを使用します。

このケースでは、ユーザーはベンダーによる説明を通じてERPパッケージの機能を理解するよう努めますが、概して紙芝居(スライト資料)によるERPパッケージの説明について、スピードが早い(消化不良的な)感覚を持ちます。また、このような状況では、説明を受けると同時にERPパッケージを使用した自社の業務運用をイメージすることは困難です。

ユーザーとしては自社の業務に適用できるかどうかを知りたいため、個々人が気になる機能について”点”の質問(えてして例外的な処理)になる傾向があります。ベンダーは質問に対して答えながら、頭の中ではパッケージの適合性を評価しています。

結果としてこのケースでは、ERPパッケージが持つ標準機能でどのぐらい現行の業務を運用することができるかをベンダーが主観的に判断します。そのため、ERPパッケージにはつきものですが、”機能があること”と”業務で使用できること”は違うということに後になって気付くかもしれません。

ERPプロトタイプによって適合分析の精度を向上させる

上記の「よくある失敗(その1)」を回避するための手法がプロトタイプです。ERPの適合分析において、最低限の自社用の評価マスタを設定した実機を使用して、標準機能を確認しながら、業務運用を実現することができるかどうか検証する作業をプロトタイプといいます(プロトタイプのことを、CPR[Conference Room Pilot]ともいいます)。通常はモジュールごとに、また全体のサイクルを複数回実施することによって、適合分析の精度をあげようとします。

ところで、一口にプロトタイプと言ってもその実施形態によっては、適合分析の結果出てきたパッケージの適合率が実態と乖離してしまうこともあります。典型的なケースは次の2つです。

ERPよくある失敗(その2)-パッケージが想定する主要な標準プロセスの確認に終始したプロトタイプ

プロトタイプでよくある失敗の一つは、パッケージの主要機能だけを流す(うまく流れるのが当たり前の)プロトタイプです。このケースでは、ユーザーによるパッケージの理解は進み、ベンダー含めて安心感を得ることができる一方で、現行の業務運用の確認が浅く、ハイレベルな適合分析となる可能性があります。

その結果、プロトタイプはスムーズに進行してパッケージ適合率は高くなる傾向にありますが、安心していたのも束の間、アドオン開発したプログラムのユーザー受入テストやユーザートレーニングの段階で、実際の業務運用パターンごとに検証し始めると、それまで埋もれていたギャップが顕在化することになります。内容によってはパッケージのセットアップ情報の見直しや開発作業の手戻りなど、プロジェクトコスト・期間に対して大きな影響を与える可能性があります。

ERPよくある失敗(その3)-現状の個別業務に焦点をあてたプロトタイプ

もう一つのよくある失敗は、現行の業務運用の一つ一つをパッケージ機能に照らして評価するプロトタイプです。ERPパッケージに業務を合わせるのが方針だとわかっていても、ベンダーはユーザーに言われるがままにシステムに実装しようとして、複雑奇妙(?)な運用手順を提案したり、不要な機能をアドオン開発と判断したりする傾向があります。また、ユーザーとしてはERPパッケージの機能を知りたいのですが、現行の業務運用の流れとERPが想定する業務運用とが異なるなど、ERPパッケージの機能を理解するために必要以上の時間を要する可能性があります。

このケースでは現状の業務の流れを尊重するあまりに、細かいギャップも拾ってしまい、またプロトタイプの作業に拘束される時間も長くなると、ユーザーによってはしびれを切らして、「今と同じことができれば良い」というようにベンダーに丸投げすることで、危険な安心感を持ちたがることも見受けられます。

その結果、例えば、パッケージの標準機能を複雑に組み合わせた運用手順を押し付けられたユーザーから「こんなパッケージは使えない」といった不満が噴出したり、不要な機能を含む大量のアドオン要件が発生して経営陣から開発フェーズのGOサインが出なかったりする可能性があります。

それではどのようにプロトタイプ作業を進めるのが良いのでしょうか。

実は上記失敗例の中にそのヒントは隠されています。

(続きは次回エントリーで)

The following two tabs change content below.

Akiyoshi KANEKO

業務プロセスを可視化(モデル化)し、その可視化されたドキュメントを中心においてプロジェクトを推進するアプローチを提唱している。経理・財務分野を主な専門領域として、業務プロセスの改善やシステム構築、組織体制の整備に関するコンサルティングに従事。プロジェクト現場では、「お互いの仕事を理解する」「現状の課題を共有する」「考えていることを相手に伝える」「新しいしくみを共有し実行まで落とし込む」よう関係者間の橋渡し役として活動する。著書『内部統制評価にみる「重要な欠陥」の判断実務』『阻害要因探しから始める決算早期化のテクニック』
スポンサーリンク
Ads by Google
Ads by Google

シェアする

  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存

フォローする

スポンサーリンク
Ads by Google