ここでは導入プロジェクトの進め方について触れます。ウォータフロー型の開発については読者の皆さんはよくご存じと思われますので、ERPらしくテンプレートを使ったプロトタイピング手法による構築方法を中心に述べていきます。
ERP導入の方法については、さまざまな方法論があります。ここでは、導入費用が多くても数千万円くらいの、ERPとしては中堅規模のプロジェクトを想定しています。しかしながら、プロトタイピング手法を採用する限り、プロジェクト規模や導入ペンダが提示する方法論が異なっても考え方は通用するはずです。
以下、プロジェクトを要件定義、システム導入、テスト本番移行 の3つのフェーズに分けて概要を述べていきます。
要件定義フェーズ
要件定義フェーズでは、CRP (Conference Room Pilot) とよばれるERPの機能検証を実施します。
CRPでは、ERPの標準機能またはテンプレートを使用して、あらかじめ用意した業務シナリオに沿って、業務を滞りなく実行できるか、ユーザが実機によって検証します。 関係者が会議室に一堂に会して システムのパイロット版を検証することから Conference Room Pilot (CRP) とよばれています。
ひとつの業務シナリオについて、検証の際の機能そのままで業務実行に支障がないと判断されれば、その業務シナリオに関する要件定義は終了します。パッケージの設定変更(コンフィグレーション)により問題なく業務を実行できると判断された場合、設定を変更して改めてユーザの確認を取ります。簡単な変更ですと、その場で設定を変更して検証することもあります。Gap があれば、その対処方法についても議論します。対処方法としては、別の使い方や別の機能で本来の目的を達成できるようにすること、アドオン・プログラムを作成することが代表的ですが、思いきって業務を簡素化するか止めてしまうことも選択肢としてあり得ます。コストに跳ね返るアドオン・プログ ラムの追加開発をなるべく抑えつつ、ユーザの理解を得てあるべき 務を見出していくことがコンサルタントの腕の見せ所です。
CRPを2回ほど実施したところで、アドオン開発の要件を文書化し、開発量を見積ることになります。CRPの回数はプロジェクトによって異なってもよいので、目安と考えてください。この段階で、一般的に、導入ペンダから要件定義後の工程についてアドオン開発を含む正式な見積が提出されます。予算に収まればよいのですが、そうならない場合も少なくありません。予算を増額しない限り、アドオン要件に優先順位を付け、優先度の低い要件を、あきらめるか、先送りするほかありません。もっとも単純な方法は、アドオン要件を優先順に並べて、予算に収まるものを作り、それ以外は、少なくともすぐには作らない、というものです。しかし、要求部門が複数にまたがる場合、部門間の調整が必要になります。この場合、すべての関係部門を統括する役員以上のクラスの決断がないとなかなか局面を打開できません。せめてプロジェクトを統括する責任者は企業トップから全権委任を受けている、という状態が望ましいでしょう。
次に、要件定義を成功させるための秘訣について考えましょう。要件定義では、業務担当者が過去の業務にこだわらず、ERP上で実現 するあるべき業務の検討に前向きに取組むことが成否を分けるカギのひとつです。しかし、導入しようとしているERPに不慣れであり、初めてERPに触れる場合もあります。そういった業務担当者は、それまで使っていたシステムと使い勝手が異なることにアレルギーを示しやすく、こうなってしまっては前向きな検討は難しくなります。ですから、CRPを実施する際の業務シナリオに沿った業務フ ローを用意しておき、細かな点はさておき、大筋では導入しようとし ているERPで業務を遂行できると感じてもらうことが大切です。ここで、標準またはテンプレートで対応できそうな業務と対応できないクリティカルな業務を切分けておくことで、実機を使ったCRPでの 抵抗感を抑え、前向きな検討がやりやすくなります。
これまでにも触れていますが、ERP導入に関して費用対効果 (ROI) をあげるためには、アドオン開発を抑えることがどうしても必要になります。特に中堅企業ではユーザ数が多くないので使い勝手をよくするための(または現行システムと同等にするための)アドオン開発コストが、使い勝手の良さによって得られる業務効率化の効果を上回り、投資は回収できないケースが目立ちます。業務担当者が ERPの使い勝手に”NO”と言っても、プロジェクト推進者はROIの観 点で妥当性を確かめる必要があります。アドオン開発は、導入ペンダ にとっては仕事が増えることを意味します (アドオンが膨らみすぎるとプロジェクト失敗のリスクが大きくなるため嫌がります)ので、導 入企業のプロジェクト推進者の責務と考えて臨むべきでしょう。しかし、実際のところ、ERPシステムが稼動を開始して数ヶ月もすれば、ERP導入に抵抗していたユーザはオペレーションに慣れてしまい、不満の声は鳴りを潜めるのが通例です。
このことが当てはまる例を2点ほど挙げてみます。
ひとつ目は、既存システムでは1画面で完了した処理が、ERP導入によって2画面にまたがってしまう例です。使用頻度や入力ミス発生の可能性と影響などによって、1画面で処理を完了できる画面の作り込みに妥当性があるか見極める必要があります。
ふたつ目は、担当者が異なる複数業務の間の連携に関することです。スクラッチ開発の現行システムでは、先行業務から後続業務への作業指示を、印刷帳票の送付やメール送信に よって行っている場合があります。要望通りならアドオン開発が必要となる場合でも、業務の仕方を工夫するとアドオンを回避することができます。後続業務の担当者は、先行業務からの連絡や指示を待つのではなく、先行業務の状態を照 機能を使って確認し、自分が担当する段階に至っている案件を選んで処理します。例えば、毎朝当日に予定されている案件の一覧を確認するところから業務を開始していくよう運用を変更するわけです。
このほか、画面に表示される用語、 例えばデータ項目名称が社内用語と異なる場合にも同様のことが言えます。ユーザは操作に慣れてくると、画面のどの位置にどんなデータを入力するか覚えてしまい、項目名称を見ることなく操作を完了するようになるようです。
アドオン開発量の増大につながりやすい、つまり導入コストに影響が大きい代表的要件に帳票があります。既存システムで出力する帳票をリストアップすると驚くほど多くなり、 実際はその大半が使われて いないといったことは珍しくありません。システムが長年運用される過程で、その時々のニーズに対応するため、担当者が知恵を絞って新たな帳票を追加していくわけです。既存システムで使っている場合でも、ほとんど同じ帳票の派性版が数多く存在する場合もあり、統一を検討したいところです。ここで考えたいのは、帳票としてERPから印刷する必要があるか、という点です。社内用の一覧帳票、例えば受注一覧を印刷するニーズは一般的ですが、多くのERPでは照会画面の条件検索(フィルタ機能)を使って一覧表示を行うことができます。また、どうしても印刷したい場合でも、Excel形式のファイルとしてデータを取出す (エクスポート) ことで代替できます。
最後に、CRPへの業務担当者のアサインについて述べます。 CRPでは、業務に精通した業務担当者が参加し、追加やアドオンの 方法などについて積極的にアイデアを出すことが、要件定義ひいてはプロジェクトの成否に大きく影響します。しかし、そのような業務 担当者は通常業務でも引っ張りだこであったり、そもそも業務を理解している担当者が少なかったりで、長時間プロジェクトに拘束されては通常業務が滞るため、プロジェクトへの参画が不十分になる事態はしばしば発生します。何とも悩ましい問題ですが、プロジェクトが始まるかなり前から調整を試みて、どうにもならないときは要件定義にかける期間を長くとることを考えるべきでしょう。プロジェクトが始まってから、予定通りに業務担当者が参加できずプロジェクトを生じるとどうしても導入ペンダの工数が膨らみ、余計にかかったコストを請求されかねません。
システム導入フェーズ
システム導入フェーズは、ERPシステムが確定した要件通りに動作するようにする、いわば作り込みの局面です。以下の3つの作業に分けて考えることができます。
(1)コンフィグレーション
パラメータやマスタデータの設定を行い、確定した要件通りに動作するようにして、機能を確認します。
(2)アドオン開発
標準およびパラメータの機能では実現できない要件を実現するための作業です。一般的なスクラッチ開発と同様に”設計” “開発 単体テスト”のタスクから成ります。
(3)結合テスト
コンフィグレーションを施したERPシステムにアドオン開発部分を結合させて、これらが一体となって要件通りの動きをするか検証します。
テスト・本番移行フェーズ
テスト・本番移行では、システム導入で構築したERPがシステムとして動作することを他システムとの連携を含め検証し、本番稼動に向けて既存システムからデータを引継ぎ、新システムへの切換えを実行します。以下に示す4つのタスクから成ります。
(1)トレーニング
ユーザ向けに、システム利用方法についてのユーザトレーニングを、システム管理者向けにはシステム管理者トレーニングを実施します。
パワーユーザ向けにトレーニングを行った後、パワーユーザが講師 となって一般ユーザ向けにトレーニングを行うこともあります。この場合、導入コストを抑え、パワーユーザの学習を加速する効果が期待できます。
また、テンプレート主導のアプローチを採用する場合には、要件定義前にユーザ向けトレーニングを実施し、CRPにおいてユーザがデモを見るのではなく、自分で使ってみるよう後押しすることもあります。
(2)総合テスト
システムが、全体として要件通りの動きをするか検証します。
(3)運用テスト
実運用とほとんど変わらない利用の仕方、すなわち実際のデータを使って、本稼動後に実施する運用手順にしたがって、問題なくシステムが動作することを、関連する他システムとの連携を含めて検証します。納品受入(検収)テストを兼ねる場合もあります。業務担当者がシステム操作に習熟するトレーニング期間としての意味合いもあります。負荷をかけた性能テストの実施、エラー処理や 復旧手順を確認する点を含め、考え方はスクラッチ開発の運用テストと同様です。
(4) 本番移行
新システムで業務運用が可能となるよう初期状態を作り、新システ ムを実業務用に稼動開始することです。具体的には、現行システム から新システムへのマスタデータ、未完了取引データ、在庫や財務残高データなどのデータを移行し、新システムに切替えます。運用開始後の混乱を回避する上で、とても重要な作業ですが、導入ベンダ選定の際にも注目されづらい傾向があり、注意が必要です。システムインテグレータの経験が浅いと、トラブルを生じがちです。また、ここは、既存システムに通じた導入企業IT部門の力量が問われるタスクでもあります。導入ペンダに任せきりにせずリーダシップを発揮する姿勢が望まれます。
コメント