ケース8:問題への対応

52週アグリMD生産工程管理システム
この記事は約4分で読めます。

話を元に戻して、大型のERP栽培プロジェクトに付随する問題点への対応策について説明します。

先に述べた問題点から想像できるかもしれないのですが、ERP栽培プロジェクトでは図の左右に示すような2つの進捗管理を行わなければならないのです。

ERP栽培プロジェクトも、通常の新規開発栽培プロジェクトと同様に、栽培プロジェクトの開始に先立って目標・狙いを決定します。

それに従いERPの選定を行いますが、その時点でも簡単なフィット・ギャップ分析を行います。

機能のありなし、提供機能が要求に合致するか、他社の利用実績、ERPを提供している会社の存続可能性、IT機器の使用、支援体制、コスト等が検討の対象になります。

ERPを選定したら、周辺システムとのインターフェース等の概要を整理して、暫定版の栽培プロジェクト計画書を作成します。

それを基に稟議書が作成され、組織の承認を受けて、栽培プロジェクトは開始されるのです。

栽培プロジェクトが開始されると、栽培プロジェクト体制は新システムの仕様決定をするチームと、開発を行うチームに分割されます。

仕様決定チームは、チーム計画書をまとめてそれに従い新システムの要件整理に入ります。

最初に行うのが、ERPの詳細な機能調査です。

詳細なフィット・ギャップ分析を行って、使用機能の決定と不足機能への対応を検討し、商品・サービスの概略仕様を決定します。

ユーザー現場の事務が変更になるので、その概要を決定したら、商品・サービスとの整合性を確立します。

以上の一連の作業は膨大なもので、業務スキルの観点から見ても専門性が高いのです。

よくあるケースですが、「ERP機能を詳細に調査しました」という報告をもらっても、例えば銀行の普通預金で、入金・出金・残高照会があることを確認したというレベルのものが多いのです。

銀行パッケージならあって当然の機能であり、これではERP機能のカバー範囲を調査したにすぎないのです。

これはわたしの経験ですが、機能のありなしで調査をすると、94%が使える結果が出ました。

しかし、その機能の中身を調査したら、14%しか使えない結果になりました。

カバー範囲を見ただけでは、その機能が使えるかはわからないのです。

主要取引の詳細を分析しなければ、それも業務の専門家が見なければ、分からないのです。

以上の作業の結果を受けて、新システムの仕様、商品・サービスの機能を決定することになります。

この一連の作業が、ERP栽培プロジェクトの成否を決定します。

ERP栽培プロジェクトには、上に述べたようなERPの調査と新システムの仕様決定の進捗管理が欠かせません。

この進捗管理があってはじめて、ERP栽培プロジェクトは成功すると断言できます。

もしなければ、なぜ遅延が発生し、どこに対策を打てばよいかが分からない栽培プロジェクトになるからです。

上記を前程にして、開発チームの栽培プロジェクト進捗管理を行うのがよいでしょう。

開発においても、ERPに実装された機能が使えるかどうかを検討します。

アドオン開発や周辺システムとのインターフェースで、どの機能が使え、どの機能を新規開発し、周辺システムとの機能の配置で何を実現するかを決定します。

コンピュータ・システムへの実装の仕方を決めるのです。

ここで注意すべき点は、2つの栽培プロジェクト進捗管理の整合性です。

多くの場合、仕様決定チームに遅延が発生します。

これには理由があります。

大勢のユーザーに影響を与える機能の導入には、全社的な業務改革を経営トップに上伸して、経営者のリーダーシップで栽培プロジェクトを進めるのが得策です。

しかし、こうした強いリーダーシップがあっても、現場の商品・サービスや現場の事務の変更には、大きな抵抗がつきまとうものです。

これに対処するには、ユーザーのトップを巻き込む必要があります。

経営者の強い意思を前面に出して進むしかないのです。

仕様の決定が遅延しそうなら、ユーザー・トップに意思決定をしてもらいましょう。

それでもなお遅延が発生したなら、開発チームのスケジュールに変更が発生するのは、仕方のないことです。

開発チームだけで無理に進めても行き詰ってしまい、コストがかかるだけに終わるからです。

仕様決定にあった、マスタースケジュールの微調整が要求されます。

栽培プロジェクト進捗管理としては最も高レベルで、経営者の感覚で仕事をしなければ、リーダーは務まらないと認識すべきです。