ベンダーが〇を多く付けていても、自社の業務にフィットするわけではない！ERP選定における試用の重要性
本記事はEnterpriseZine「失敗しないERP選定＜試用編＞」転載記事です。（2016/12/22 7:00掲載）
連載の第1回目となる前回は、ERPにおけるクラウド環境の進展と、それに伴いサービス利用開始前の試用が容易になったため、ぜひ試用をしましょうと申し上げました。では、なぜ試用が必要なのでしょうか。もちろん、「使ってみた方がいいに決まっている、言われなくてもわかっているよ」と思われるでしょうが、営業担当として多くのERP選定に携わってきた筆者が考える、試用の重要性についてご説明していきます。
目次
ERP機能の”FIT&GAP”をどのように精査するか？
単純なシステムであればまだしも、ERPのような複数の業務範囲にわたるシステムが、自社の望む機能を過不足なく持っているということなどありえません。（不足はもちろんですが、過剰な機能というのも持て余し、邪魔になるものです）
ユーザーは選定において、自社の業務を洗い出し、そのために必要な機能を書き出します。その内容と、複数のERPの機能の合う部分(FIT)、合わない部分(GAP)を精査する必要があります。
できない部分があるのであれば、それをどのように解決するか考えなくてはいけません。例えば、カスタマイズをするのか、入力方法等を工夫する、該当部分だけはシステム外で管理する、といった運用回避策を考えるのか、あるいはできないことに目をつぶり、その機能は不要とするか。パッケージ製品は、できることがあらかじめ決まっていますので、「FIT&GAPをする」=「選定をする」事そのものと言えるでしょう。
クラウドの普及により、今までは少なくとも中堅規模以上の会社でしか費用的に導入が難しかったERPが、中小規模の企業にも手が届く価格帯になってきましたが、そういった企業はシステム企画部門等、システムの専門家を抱えていない場合が多く、システム導入に際しFIT&GAPをどのようにしていけばよいかわからない担当者の方も多いと感じます。
基本はユーザーが「要件一覧表」を作り、ベンダーがOXをつける
一番基本的な機能要件のFIT&GAPは、下記のような表をユーザーが作り、ERPベンダー側で○×をつけるというものです。
▲図1：要件一覧表のサンプル
ちなみに、口頭とデモでのみ製品を決定するお客様も少なからずいらっしゃいますが、
最低でもこういった表はお作りいただきたいというのが営業担当としてのお願いです
システムの選定を行う際には、機能だけでなく複数の要素が総合的に判断されることになります。
- 費用
- 希望納期への対応
- 営業担当含むベンダー対応・信頼性
- 導入実績・同業他社事例
- 非機能面の要求水準（セキュリティ、稼働時間、保守体制等の要件）
- 機能面のフィット率
上記の中で優先順位がかなり高いはずの「機能面のフィット率」を、1、2回のベンダー操作によるデモンストレーションと、上記○×のみで判断してしまう場合があります。しかしそれは非常に危険です。なぜ危険なのか、毎週のようにお客様から頂いたご要望に日々○×をつけている営業担当の目線でお伝えします。
○が多ければ自社にフィットしているのか？
例えば「入金消込」の機能の場合、最も簡潔な要件で書くと
入金の消込ができること
という表記になります。これであれば、債権債務の機能を持っているパッケージであれば大抵が○表記になるでしょう。もちろん、この「入金の消込ができること」だけでは大雑把すぎて本当に要件を満たしているかわかりませんが、実際お客様から受領する要件一覧表には、この粒度で記載してあるものも少なくありません。 もっと詳細に要件を伝えるために、入金カテゴリの小項目に下記のように追記していきます。
- 入金の方法としては、振込、現金、手形、口座振替に対応できること
- 1請求に対して、複数回の入金処理ができること（1対N）
- 複数回の請求に対して、1回の入金で消込ができること（N対1）
etc… 細かく書いていってはキリがないですが、これで少し詳しくなりました。
では、これらの項目に最も○が多い製品が、自社の要件を多く満たしており、FITしているといえるか？というと、本当にそうでしょうか。
図2：点数表
業務は単独の機能の集合体ではない！
もちろん、○は多ければ多いほど良いのですが、実際には業務は単独の機能の集合体ではなく流れ、つまり言葉通り「業務フロー」になっているので、個別の機能についていくら掘り下げて細かく記載し、○×をつけてもらっても、それが自社の業務にマッチしているかどうかというと、必ずしもそうではないのです。
上記要件を例に取れば、「入金」というのは1つの契約・販売プロセスにおいて終盤に発生する業務ですが、「複数請求に対して1回の入金で消込ができること」という場合は、導入範囲にもよりますが
- どのような受注・契約形式になっているのか？
- 売上は請求額と同一なのか？
- 営業段階での案件管理ではどのように見込みを管理するのか？
といった事も付随して考えなくてはいけません。○×ではそのような全体の流れを把握することは出来ません。
ベンダー側は○を多く付けたがる
これは、「ベンダー側の営業というのは受注第一に考えて嘘をついている、機能を盛っている」という意味ではありません。ベンダー担当者は、前述のように、○=お客様の要件を必ずしも満たしているわけではない、ことを理解しています。しかし一方で○×の数だけで機械的に点数化される可能性がある事も知っています。
従いまして、「確かにこの1文だけで見ると○だけど、他の要件を読む限り、書かれてないけどおそらくこういう内容も含むのだろうなぁ」といった思いをめぐらせながら○を付けている場合もあるのです。
私が○×をつける際は、曖昧な表現や、自分の知らない用語、要件表全体の矛盾などがある場合、極力お客様に質問をして理解するように努めたり、「※但しこの場合はできません」と言った風に注釈を細かく記載するようにしたりしていますが、結局のところユーザーがベンダーに自社の業務を全て伝えるのは不可能です。最初は対応範囲を確認する意味合いで、ベンダーに○×をつけてもらうのが良いでしょうが、最終的な検証はユーザー側で行う必要があります。
「この機能は当然あるだろう」という思い込みは禁物
具体例を挙げるのが難しいですが、「当たり前にできるだろう」とか「書かなくてもわかるだろう」という事は極力無くしていかなければいけません。
私も上記のようなことを言われ、お客様にお叱りを受けたことはありますが、たとえあって然るべき機能でも、無いものは無いのがシステムですし、どうしても、自社の業務に染まってしまうと、それが世の中全体の標準的な考え方であると錯覚してしまいますが、そうでは無いことが往々にしてあるものです。 そういった、言わずもがなと思っている仕様は、自分で使ってみて、「なんか変だと思ったらこの機能がないのか」と気付くものだと思います。
私もよく実施しますが、お客様と対面でシステムを見ながら要件を一個一個確認していくというのは、いい方法です。その場で疑問点を質問できますし、ユーザー業務とパッケージ機能の相互理解が深まります。
しかしながら、その場合もシステムの操作はあくまでもベンダー側の担当者がしているはずであり、操作に慣れた担当者のデモを見せられると、簡単に出来るような気になってしまうものです。
****
ユーザーが自らシステムを操作して、FIT&GAP結果を検証する必要性はご理解いただけたかと思います。しかし、選定におけるどの時期にどれくらいの期間、人数で、どのように検証を進めていけばよいかということも考えていかなくてはいけません。次回は、具体的な試用の進め方についてご説明いたします。
筆者プロフィール
- ビーブレイクシステムズ
- 新しい「働き方」やそれを支えるITツールにアンテナを張っています。面白い働き方を実践している人はぜひ教えてください！
