情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

パッケージ選定は必ずRFIを出して一発勝負を避ける

2020

3/27

パッケージの多すぎる選択肢

「在庫管理機能を持った販売管理パッケージは何社あるでしょうか?」

先月行ったセミナーの参加者にクイズを出しました。

「10社」「20社」「30社」「50社以上」と選択肢を出しましたが、全体の3分の1が正解します。

答えは「50社以上」です。

「さらにこの中で、印税管理など出版社向けに特化したものは何社あるでしょうか?」

こちらは、ほとんど正解者はいませんでした。答えは「10社以上」です。

どのような業界であっても、基幹システムのパッケージは無数にあります。探せば探すほど、たくさん出てきます。

ユーザー企業にとって、選択肢が多いことはメリットです。

問題は「数が多すぎる」ことです。

この中から、どう選んでいけば良いのでしょうか?

RFIでリスクを抑える

パッケージシステムの選定において、一番のリスクは「選定ミス」です。

これは本当に取り返しがつきません。ミスしたらどうなるのでしょうか?

業務に合わないパッケージは、現場を苦しめます。システムの都合で余計な手間が増えます。機能不足なので、エクセルなどシステム外での手作業も増えてしまいます。

システムのせいで、業務フローが複雑になり、属人化の温床になります。

また、パッケージのカスタマイズが大幅に増えます。カスタマイズ費用が一気に膨らみます。パッケージ本体の2倍~3倍は普通にかかります。

スケジュールも、通常納期が6か月とした場合、2年に伸びることもあります。

保守性も悪くなります。年間を通して、ベンダーの保守要員も必要で、システムを維持するための費用が垂れ流しで出ていきます。まるで、大規模なスクラッチ開発のようです。

つまり「選定ミス」は、会社の基幹業務が不安定になり、非効率になり、人件費とシステム費用で、大幅なコストがかかるということです。

パッケージは「選定」が全てです。

自社の業務に最もフィットすることが重要です。

では、どうやって、フィットするパッケージを探していけばいいのでしょうか?

『RFI』をうまく使うことです。

RFIとは、Request For Informationの略で、「情報提供依頼書」と訳されます。

初動調査でRFIを用いて、パッケージの基本情報を確認していきます。「自社の業務」と「パッケージの標準機能」をマッピングし、フィットするかを確認するのです。

「RFP(提案依頼書)で提案をもらえば良いのでは?」と思うかもしれません。

でも当社からすれば「RFPの一発勝負でいいんですか?」と逆に聞き返します。

選定が重要だからこそ、慎重に、確実に、候補を絞り込んでいく必要があります。その具体的なステップが、「RFIの一次選考」⇒「RFPの最終選考」となります。

RFPは通常、3社ぐらいに発行し、最終選考します。そこは問題ないのですが、

「RFPを発行した3社が正しいのか?」

に納得のいく説明ができないことが問題です。まずは、一次選考をしっかりと行うことが重要となります。

RFIは、細かく網羅的に聞くのではなく、パッケージのパンフレット情報をもらうイメージです。広く浅く情報収集するため、質問項目を少なくして、ベンダーの負担を減らし、素早く回答を得るのがポイントとなります。

このRFIで、最も重要な確認は何でしょうか?

それは、パッケージの「標準機能」の確認です。

パッケージの機能が大きく欠落していたら、そもそも話にならないからです。例えば、「印税管理」をやりたいのに、それをもっていないベンダーにRFPを投げても、お互い膨大な時間を無駄にするだけです。

まずは、RFIでざっくりと「要求機能」を列挙して、ベンダーに○×を記入してもらいます。

RFIでは、減点方式を採ります。

主要機能がなければ、減点していきます。そして、減点が少ないベンダーだけを残します。もし、自社として外せない機能が無かったら「一発アウト」にします。

つまり、RFIで「足切り」をしていくのです。

「このパッケージは可能性がないな」というベンダーを外していく作業です。

RFIは10社ほど発行し、そこからRFPの3社ほどに絞り込みます。

「RFIからのRFP」を確立する

スクラッチ開発が主流の時代は、RFPだけで問題ありませんでした。「価格」と「魅力的なシステム提案」さえ確認できれば良かったからです。1つのレースで「一発勝負」で良かったのです。

一方で、パッケージシステムは違います。何よりも先に「自社業務との適合」が重要となります。

そこを慎重に確認しないまま、RFPを3社に絞るのは「博打」と一緒です。

経営層にどう説明すればよいのでしょうか。

選定ミスの被害は計り知れません。その責任を誰がとれるというのでしょうか。

IT部門/情報システム部門の役目は、この「選定」の流れを確立し、運営することです。

貴社のIT部門は、RFIでしっかりと「ふるい」にかけていますでしょうか?

関連コラム

DXで経営戦略を仕組み化する技術

情シスコンサルティング株式会社
田村 昇平

情報システム部門(情シス)を起点に、経営戦略とDXを統合するコンサルタント。

システム開発を10年、ユーザー側のITプロジェクト支援を13年。ベンダーとユーザー、双方の立場を経て独立。これまで30社以上、100を超えるプロジェクトに携わる。

近年は、現場主導のDXが行き詰まる企業が多い現実を踏まえ、「経営主導」への転換を提唱。トップダウンでDX戦略を策定し、実行可能な形で「仕組み化」する支援を行っている。併せて、「情シスをDX推進の中核組織」へと進化させる独自メソッドも確立してきた。

膨大な現場経験での数多くの失敗や板挟みとなる葛藤。それらを乗り越えてきた知見をもとに、机上論ではない「再現性のあるDX」を追求する実務家として、経営者・CIO・情シス部長と伴走している。

主な著書に『システム発注から導入までを成功させる90の鉄則』『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』『DXで経営戦略を仕組み化する技術』がある。

著書の詳細は、こちらをご覧ください。