【IT分野での2025年問題の本質:step4】パッケージ自体よりも重要な再構築支援ベンダーの選定

システム

2020年04月07日(火)掲載

システム導入を支援してくれるベンダーの種類と定義

この一連のコラムの中で、「パッケージベンダー」や「ITベンダー」のように、「ベンダー」と言う言葉が頻繁に出てきています。誤解の無いように、企業の基幹システム導入時に重要な役割を果たす「ベンダー」について、こちらで補足説明をしておきましょう。

先ず「ベンダー」とは英語でvendorです。vendする人、つまり「売り手、提供者」のような意味合いですので、ITベンダーとは、ひろく「IT関連の売り手、提供者」となります。よって、「ITベンダー」とは、企業がITシステムの導入をする際のシステムやソリューションの提供をする人や会社であると理解していただければ良いでしょう。
しかし、敢えて私が「パッケージベンダー」や「ITベンダー」とコラムのなかで区別している理由があります。そして、この違いが今後のステップの中で重要になってきますので、こちらで詳しく解説しておきます。

・「パッケージベンダー」:企業がITシステムの導入をする際に、必要な業務パッケージのライセンス提供や、そのパッケージの導入支援をするベンダーを、代表して「パッケージベンダー」とここでは区分しています。代表的なのは、ERPパッケージを提供するようなERPベンダーです。

よって、当然このパッケージベンダーは、提供するパッケージの対応業務や機能に詳しいことが最低条件です。しかしながら、そのパッケージを企業が導入する際に、プロジェクトの進め方やマネージメントに関して、必ずしも得意でないパッケージベンダーもいるのが事実です。更に言えば、昨今の進歩が激しいERPパッケージの分野においては、必ずしもそのパッケージベンダー自身が開発したパッケージを提供しているわけでなく、海外で開発されたパッケージの販売ライセンス権を得て販売・導入支援をしているケースも多々あります。そして、このような場合には、パッケージベンダーの技術者に、スキル(能力、経験値)のばらつきがあるのが実態です。具体的に言えば、グローバルスタンダードであるERPパッケージの導入において、日本には最新機能を熟知しているパッケージ技術者が非常に少ないと言えます。

しかし、この原因は必ずしもパッケージベンダーだけにあるわけではなく、企業側にも一部責任があると考えられます。つまり、多くの日本の企業は、ベース言語が英語である海外で開発されたパッケージのほぼ全てを日本語で導入するケースが多いのです。故に、パッケージベンダーは海外のパッケージが日本語対応にポーティング(言語機能の移行)されてから日本の企業に提供することになります。よって、日本のベンダー技術者は、日本へのパッケージ提供が時期的に遅くなり、どのようしても海外の技術者よりも新機機能のキャッチアップが遅くなります。

更に、もう一つ問題があります。それは日本のIT技術者で英語の堪能な人が少ないことです。パッケージベンダーの技術者も英語が堪能でなければ、最新機能の理解や習得が遅れてしまいます。
このような理由から、基幹システムの再構築検討の際は、パッケージ自体よりも、そのパッケージを担ぐパッケージベンダーのほうが重要なのです。

・「ITベンダー」:ここでは、敢えて「ITベンダー」という表現をしていますが、これは上記のパッケージの提供をメインとした「パッケージベンダー」以外の「SIベンダー」を広く意味すると理解してください。そして、SIとはSystem Integratorを意味し、ITの導入支援をするベンダーのことを指します。よって、その「ITベンダー」がパッケージのライセンス等も提供していれば、「パッケージベンダー」も兼ねることもありますが、一番の違いは以下です。
つまり「ITベンダー」は、昨今の基幹システムパッケージが普及する前から、様々な業種・業務に対してシステム導入支援をしており、対応範囲が広いのです。これは、昔のメインフレーム(大型汎用コンピュータ)の時代からも行っていました。

例えば、著名な情報システム会社、或いは大手製造会社の情報システム部門が、一般企業のITシステムの導入支援をビジネスとして幅広く実施しているケースが多くあります。これらを称して、ここでは「ITベンダー」と呼んでいます。よって、このような会社は、その「ITベンダー」自らが開発したパッケージの提供だけでなく、他社のライセンス権を有したパッケージを販売し、提供しているケースもあります。そして、通常はライセンス提供だけでなく、システム構築や導入支援も含めて対応しているケースが多いのです。
昨今、これらの「ITベンダー」は種々雑多ありますので、どのベンダーを選択するかについても、企業の基幹システムの再構築プロジェクトが成功するか否かの大きなファクターとなります。

ここで参考までに、企業の基幹システムの構築とITベンダーとの関わりについて時系列で示した図を、以下に「3-1.図1 昨今の基幹システム導入の流れと外部ベンダー等との関わり」として示します。

3-1.図1 昨今の基幹システム構築の流れと外部ベンダー等との関わり

(図1:筆者作成)

外部ベンダー等との関わりは、3-1.図1 のような関係となっています。ここでのポイントは、企業戦略をベースとし、ベンダーや支援者の必要が生じるのは、システム導入の段階だけではなく、「企業戦略・業務改革の立案」から「基幹システムの評価・監査」までを含め、情報システムのライフ・サイクルのあらゆる局面で、ベンダーやコンサルタントとの関わりが出てくるということです。そして、昨今はパッケージの活用・開発が、基幹システム構築においてベンダーの支援が必要なメインの部分となっています。今回のコラムで解説している「準備フェーズ」全てが、「システム導入(準備)」に含まれているということです。

「ステップ5」の選定プロセス開始前の注意点

既に、「ステップ3」のところで、パッケージやベンダー選定のためのRFPについて解説し、そしてベンダー選定の重要性も併せて解説しています。ここで、上記の(1)で解説した内容にも関連しますが、「ステップ5:パッケージやベンダー選定のポイント」に入る前に、少し注意していただきたいことがあります。

それは、選定対象の候補パッケージやベンダーをリストアップする際に、上記のベンダーの違いを理解した上で、幅広くベンダー候補をリストアップしていただきたいということです。特に、基幹システム再構築のように、大きい全社的なプロジェクトのRFPの場合には、RFPの前にRFI(Request for Information:情報提供依頼)というドキュメントをRFPに先立って作成してください。最初に、支援依頼候補ベンダーにこのRFIを幅広く送り、全く目的に合致しないベンダーを認識した後、本来の「ステップ5」の候補ベンダーやパッケージ選定に入るケースも多いです。

通常、RFIとRFPの2段階ステップで進める場合は、工数や期間を多く要しますので、2段階で選定を実施するか否かは、期間や再構築プロジェクトの特性、更には重要性も踏まえての判断が必要となります。仮に、RFPのみの1段階の選定になる場合でも、基幹システムの再構築であれば、最低7社~10社ほどにはRFPを送ると良いでしょう。なぜなら、RFPの内容によっては、そのベンダーの状況や体力によって、RFPの提案依頼に対して辞退を申し出るベンダーもあるからです。

ここで、RFIについて少し解説しておきます。これはRFPほどの作成のパワーはいらず、依頼するポイントのみを明確に記載します。そして、ベンダーにはこれに対して対応出来るか(特にその後のRFP回答への対応が出来るかどうか)の意思も踏まえて、そのベンダーの詳細や実績を提供依頼するものであり、回答するベンダー側も比較的簡単に回答できます。

よって、先ずは簡単にRFIを作成した上で早めに候補ベンダーに送り、その間に「ステップ3」のRFP作成準備を併行して進めるという手段もあります。そして、その場合に、RFIはパッケージベンダーやITベンダーの15社ほどに送ると良いと思います。RFIの場合は、必ず何かしらの回答が貰える筈です。そのため、もし、その時点で候補ベンダーの詳細情報を知らなくても、RFI回答によって予備知識が増え、その後のRFPを送るベンダーの絞込みやRFPの項目内容に対しても、より精度の高いRFPの作成をすることにもつながります。

次に、ベンダー選定・評価の流れの例及び重要なポイントを、次の「ステップ5:ベンダー及びパッケージ選定プロセスのポイント」で解説しましょう。

執筆者H.K氏

大阪大学工学部卒業後、電機業界の大手企業に入社し、情報システム事業部門勤務。米国への社費留学にて、コンピュータサイエンス修士号取得後、米国・東南アジア・欧州の関連会社に出向駐在を経験。日系企業の基幹システム導入支援等を多数実施。定年後はIT顧問として活動中。英語・海外関連著書30冊以上あり

関連コラム

ページTOPへ戻る