PR

 業務要件を整理して機能要件に落とし込む一連のステップは,パッケージ導入ならではの醍醐味があり,コンサルタントにとっては腕の見せどころである。しかし,顧客とコンサルタントの意見が衝突して,双方が気まずい思いをすることが少なくない。

 その原因の一つは,パッケージの標準プロセス/機能を押付ける一方的な姿勢,あるいは反対に顧客の要求を丸飲みする受身的姿勢で,コンサルタントが機能要件の定義を進めてしまうことにある。そのような進め方をすると,どんな結果を招くのだろうか。

 まず,実現方法の決定が迷走した結果,プロジェクトが止まる。「運用可能な新業務プロセスを定義できない」「適合率が著しく低くなった結果,プロジェクト・オーナーがパッケージ導入のメリットを出せないならば必要ないと判断する」といったことが想定される。だが,この種のチェック機能が働くのはまだ良い方である。

 もっと面倒なケースでは,意思決定の根拠や前提条件をあいまいにして進めた結果,本番運用が困難になる。「業務遂行に重大な支障が出て,顧客の顧客(取引先・最終消費者・投資家)に迷惑をかける」「大量のアドオン・プログラムがネックになって,組織改正やパッケージのバージョンアップ時などに,膨大な工数(=費用)がかかる」ことが想定される。

 このような好ましくない事象を防ぐために必要な施策を,(1)顧客のギャップ判定と,(2)アドオン判定基準の二つの観点から紹介する。

顧客のギャップ判定をそのまま受け入れてはいけない

  現場担当者から出る「業務が回らない」という反応を無条件に受け入れていると,目標達成,稼働時期順守,予算順守のいずれかが破たんする危険性が高い。そうなる前に行うべき対策を三つ挙げる。

 第1の対策は,理由を突き詰めて分類し,個別に対応策を練ること。顧客がパッケージ機能を否定する理由はいろいろある。主なパターンとその対応策の例を紹介する。

【機能が無い】
 その機能がなぜ必要なのか,今後も必要なのか,という視点で,要件のもとになるルールを確認し,目標に沿った新業務プロセスと照合して,ルールの変更可否(変えるべき,変えてもよい)を判断する。

【手作業では対応できない】
 作業量という数値化可能な事実に勝る判断材料はない。そこで対象データ(処理)の発生頻度を調査する。過去の発生件数の把握も必要だが,新業務プロセスにおける発生頻度を想定して,本当に手作業で対応できないのかを判断する。

【利用者が使いこなせない】
 現場にどれだけの業務変更を求めるか,というプロジェクト方針によるが,不特定多数が使用する稟議・旅費/経費精算・勤怠入力などの共通機能と,特定の担当者が使用する受発注・入庫・請求・入金・支払等の個別機能を区別し,利用者のレベルに合わせて優先順位を考える。いわゆる慣れの問題については,教育による担当者のレベル引き上げや,効率化を目的としたシェアードサービスセンター化と連動した操作知識を持つ人材集中・少数精鋭化などで,ある程度克服可能である。

【手作業では内部統制上問題がある】
 いきなり実現手段を検討する前に,内部統制の定義を今一度確認する。例えば「統制強度と監査件数に関係があること」「承認履歴自体は,パッケージ本体で持っていなくとも,外部の文書管理ツールなど適切な環境の下で,財務数値にかかわるインプットを承認した履歴が取れれば有効であること」など,正確な要件と照合して,パッケージの内外にこだわらず個別に対応策を検討する。

 第2の対策は,標準機能を駆使したギャップの解決案を提示すること。ルールや体制変更の前提条件を明確にした上で,標準機能または手作業で構成した実現方法案を作成する。その際,アドオンの必要性は,標準機能の活用を考え尽くした結果として判断すべきである。この作業を行わないと,例えば単なる処理の自動化が求められているのか,全く存在しない機能が求められているのかが整理できない。

 現状の処理時期や担当者を当てはめてみると,ギャップの理由が見えてくる。そこから体制や業務手順面の解決策が導き出される場合が多い。これはアドオン判定で開発が認められなかった場合の代替案としても必要である。

 第3の対策は,ルールの変更可否判断をエスカレーションすること。検討チーム内,現場担当者レベルでは,ルールの変更可否を判断できないことも多い。BPR(業務変更)ポイントとして,変更した場合の業務への影響,変更しなかったためにアドオン開発して対応した場合の工数・本番運用開始後の追加作業を追記し,しかるべき権限を持った組織へ意思決定依頼をエスカレーションする。