パッケージ導入プロジェクトの後半、すなわち構築フェーズでは、プロジェクトのコストが予算オーバーするとか、期間内に開発が終わらず稼働が延期されるとか、業務要件の理解違いなどから機能的な欠陥が指摘されるなどといった状況になることがあります。プロジェクトマネジメントでは、このような状況にならないように進捗や課題の管理をしていきますが、構築フェーズにおけるアドオン開発がらみの課題の多くは、元をたどると、プロジェクトの前半で実施するプロトタイプ作業を通じた適合分析のやり方に原因があったということが多いのも事実です。
「ERPパッケージ適合分析におけるおススメのアプローチ」、2回目の今日は、前回、適合分析における「よくある失敗例」を踏まえて、プロトタイプ作業におけるおススメのアプローチをまとめています。
ERP開発が始まるまでに明確にすべきアウトプット
最初に前回も記載した適合分析における3つのアウトプットを再度確認をします。
- ERPパッケージを使用した新しい業務プロセスの設計
- ERPパッケージの標準機能を適用する領域と不足している機能をアドオン開発して適用する領域の切り分け
- ERPパッケージの基本セットアップ（マスタとコードの設計方針、主要なキー項目など）の定義
2について、アドオン開発がどの程度であれば適正かというよりも、問題となるのは、パッケージの適合率が実態と乖離してしまうことだと説明しました。この乖離がのちの構築フェーズで課題として顕在化してきます。
以下では、プロトタイプの評価作業を通じてこれを回避するアプローチとして、プロトタイプの準備に関するものを2つ、プロタイプの評価実施に関するものを1つ紹介します。
ERPおススメのアプローチ（その１）－実現しなければいけない業務機能をリストアップし、業務要件を定義する
私は、プロトタイプ作業の準備として、業務機能チャートという業務全体を体系的・網羅的にリストアップした一覧表をよく作成します。業務プロセスのモデリング技術には動的なものと、静的なものがありますが、業務機能チャートは静的なモデリング技法の一つになります。
なぜ静的なモデリング技法を使用するかといいますと、このプロトタイプ作業を通じた適合性評価では「流れ」ではなく、あくまでも「機能」に着目をするからです。そこでは、業務全体の目的は何か、業務遂行の結果アウトプットされるデータ・資料は何か、業務遂行にあたって適用されている業務ルールは何か、という観点を重視します。
例えば、現行の伝票登録の処理が、「登録時に一旦仮伝票として登録され、それを承認登録することによって転記される」のに対して、導入するERPパッケージの伝票登録処理は、「登録時に即時転記される」だったとします。このときに承認機能や転記タイミングをギャップとして把握するかが問題となります。前回のエントリーで失敗例として挙げた『現状の個別業務に焦点をあてたプロトタイプ』のアプローチでは、順序が違う、承認処理を利用しているという理由でギャップとして扱います。
しかし、上記の機能に着目した考えで、
- 承認時にどのような点を確認して承認をしているのか
- なぜそのタイミングで承認しているのか
- すべての伝票に承認が必要か
- 転記後の承認ではいけないのか
- システム外の承認ではいけないのか
ということを確認したうえで業務要件として定義します。
つまり、「承認」という機能の目的をいくつかの観点で質問し、その要否や目的に適合した本来のあるべき／したい行為を確認をしています。実際のプロトタイプの評価作業では実機を見ながら、後述する業務シナリオに沿った流れの中で「今のシステムは処理が必須だからしているが、今後システム上の承認処理は不要でも良い（事後に別の方法で承認する）」とか、「支払につながる伝票については今と同じように転記前に承認処理を入れたい」など検討することになります。今を前提にしないで、業務の目的を意識してもらうのがポイントです。
実はこの”目的指向”の考え方が、ERPパッケージに業務を合わせるといったときに一番大事な考え方になると思っています。これによって、単に現行の業務プロセスの焼き直しではなく、また無理にパッケージに実装しようとして複雑奇妙（？）な運用手順になることを回避し、さらには多くの不要なアドオン開発を抑制することができます。
ERPおススメのアプローチ（その２）－キーとなるユーザーが、ERPパッケージの操作トレーニングを受講しておく
プロトタイプは、最低限の自社用の評価マスタを設定した実機を使用して、標準機能を確認しながら、業務運用を実現することができるかどうか検証する作業です。したがって、ユーザーがパッケージの標準的な操作や想定している運用をあらかじめ理解しておくことは、自社の業務運用の検証に意識を集中することができ、プロトタイプ作業の品質向上につながります。すなわち、パッケージ適合率が現実的なものになるのです。
ERPで運用する標準的な業務の流れも頭に入っているので、仮に現行の業務の順序が変わったり、（付加価値のない業務が）廃止されることになっても、意外に受け入れやすくなるものです。
前回のエントリーで失敗例として挙げた『実機を使用しない／一般的なデモ環境しか利用しない適合分析』はもとより、他の2つの失敗例のように、いきなりプロトタイプ作業に入るアプローチをおススメしない理由がここにあります。
ベンダーが定期的な研修を提供していることも多く、また、製品購入ユーザーであればプロジェクト内でもタスクとして組み込むことを相談できると思います。新しいERPパッケージの利用ユーザー数が多いと、新システムのトレーニングや新業務への切替などを計画的に進める必要がありますが、いざというときに現場で頼りになるのがプロジェクトを通じて育ったパワーユーザーです。
ERPおススメのアプローチ（その３）－プロトタイプシナリオを用意する
業務機能の一覧を作成し、導入するERPの操作もおよそ覚えたあとは、いよいよプロトタイプの評価作業になります。おススメのアプローチの3つ目は、プロトタイプの推進にあたって、目標となる業務プロセスを想定し、プロトタイプを評価するための業務シナリオを用意することです。
お芝居や演劇の稽古では「ランスルー」と呼ぶ”通し稽古”がありますが、まさにランスルーと同じように、プロトタイプを使って本番の業務運用を一通り流してみることをします。
それってユーザー受入テストと同じでは？と思われるかもしれませんが、そうなんです。ユーザー受入テストと同じつもりでプロトタイプの評価作業を実施するのです。細かいことを言えば、ユーザー受入テストではアドオン開発した機能を含めて、論理的なデータの流れや整合性を重視しますが、ここでは新しい業務が最初から最後まできちんと流れるかどうか「テストと同じつもりでプロトタイプを評価」して欲しいということを言っています。
業務プロセスというのは人が遂行するのであって、ERPはその遂行手段に過ぎないのですから、想定される目標の業務プロセスの流れに沿ってプロトタイプの評価を実施します。手作業で遂行される業務やアドオン機能でしか対応できない箇所も、それらをどのように実施するか想定して、最終的に欲しいアウトプットは作成できるか、業務の目的を達成できるかを検証します。その結果、プロトタイプの評価作業が終わった段階において、ユーザーがERPが導入された後の新しい業務運用を明確にイメージすることができるのです。
まとめ
上記で洗い出した課題について、解決策を検討するアプローチをとると、冒頭に再確認をした「開発が始まるまでに明確にすべきアウトプット」を得ることができます。
ところで、前回エントリーに関して、FacebookでERPパッケージを既成服に見立てて、「細身の服を着るために、激烈ダイエットをする自分に思えてきました・・・既製服に自分を合わせるしかないかなぁ」というコメントをいただきました。
たしかに細身の服を着れたときの自分を思い描いて懸命にダイエットに取り組むことも考えられますが、それで健康まで損なっては元も子もありません。ですので、専門トレーナーのアドバイスを受けながら健康的にダイエットをする一方で、元の服のデザイン性を残しつつ体型に合うように服をリフォームできる仕立屋に修理を依頼をするのが良いと思います。
それゆえ、ERP導入のプロトタイプを通じた適合分析において、業務分析スキルと各種ERPパッケージの導入経験を持つコンサルタントが参画し、ユーザーとベンダーの橋渡しをする意義があると考えています。
