システムベンダーの選び方の7つのポイント|失敗しない選定基準・評価項目・RFP活用の実務

企業が新たにシステムを導入・刷新する際、どのシステムベンダーに依頼するかは、プロジェクトの成否を大きく左右します。

しかし実務では、「有名な会社だから」「価格が安かったから」「過去に付き合いがあるから」といった理由でベンダーを選び、後から苦労するケースが少なくありません。

システムベンダー選定で本当に重要なのは、単に技術力実績を見ることではありません。

自社が実現したいことを正しく理解し、現実的な進め方に落とし込み、プロジェクトの途中で発生する不確実性にも一緒に向き合える相手かどうかを見極めることです。

言い換えれば、システムベンダー選定とは「開発会社を探す作業」ではなく、「自社のIT投資を託せるパートナーを見極める意思決定」です。

本記事では、システムベンダー選定の基本的な流れ、評価項目、7つの確認ポイントに加えて、実務で見落とされがちな発注者側の準備、RFPの活用方法、提案書を比較する際の注意点まで解説します。

目次

システムベンダー選定とは?

システムベンダー選定は、企業の情報システムやソフトウェアを開発・導入するために、最適なパートナーを比較検討をして、最適な1社に委託を決定する重要なプロセスです。この選定プロセスは、導入するシステムの成功や運用効率に大きな影響を与えるため、慎重かつ計画的に行う必要があります。また、委託後に発生する保守やアップデートまで視野に入れ、体制の持続性とコミュニケーションの円滑さも確認すると、社内ノウハウ喪失や情報漏えいリスクを低減でき、結果的に長期的な視点で見た際に競争優位性を確保することができます。

システムベンダーを選定する際は、技術的な要件だけでなく、コミュニケーション能力や企業文化とのマッチングも重要なポイントとなります。

システムベンダー選定でよくある失敗

システムベンダー選定では、候補企業を比較しているようで、実際には十分に比較できていないケースがあります。

代表的なのが、提案書の見栄えやプレゼンの印象、金額の安さだけで判断してしまうケースです。

もちろん、提案書の分かりやすさや金額の妥当性は重要です。しかし、それだけでベンダーを選んでしまうと、プロジェクト開始後に次のような問題が発生しやすくなります。

提案時の担当者と実際の担当者が違う

提案段階では経験豊富な営業担当者やプリセールス担当者が前面に出ていても、受注後に実際のプロジェクトを担当するメンバーが大きく変わることがあります。

この場合、提案時にはスムーズに見えたコミュニケーションが、プロジェクト開始後に急に重くなることがあります。

確認すべきなのは、「提案が上手いか」だけではありません。

実際にプロジェクトを動かす責任者は誰か。その人に十分な経験があるか。要件定義、設計、開発、移行、運用開始までを見通せる体制があるか。

ここを確認しないまま契約すると、提案書と実行力の間に大きなギャップが生まれます。

安い見積りを選んだ結果、追加費用が増える

見積金額が安いこと自体は悪いことではありません。

問題は、なぜ安いのかが分からないまま選んでしまうことです。

要件の前提が浅い、移行作業が含まれていない、運用設計が対象外になっている、テスト範囲が限定されている、プロジェクト管理工数が不足している。

このような見積りは、初期費用だけを見ると魅力的に見えますが、実際にはプロジェクト途中で追加費用やスケジュール遅延が発生しやすくなります。

ベンダー選定では、金額そのものではなく、金額の根拠を確認することが重要です。

「できます」という回答だけで判断してしまう

RFPに対する提案では、多くのベンダーが「対応可能」「実現可能」と回答します。

しかし、実務で重要なのは「できるかどうか」ではなく、「どのような前提で、どの範囲まで、どの体制で実現するのか」です。

同じ「対応可能」でも、標準機能で対応できるのか、カスタマイズが必要なのか、業務側の運用変更が必要なのか、追加費用が発生するのかによって意味は大きく変わります。

提案書を比較する際は、表面的な回答ではなく、その裏側にある前提条件まで確認する必要があります。

発注者側の意思が曖昧なまま選定してしまう

ベンダー選定の失敗は、ベンダー側だけに原因があるとは限りません。

むしろ、発注者側の目的、優先順位、予算感、判断基準が曖昧なまま選定を進めてしまうことが、失敗の大きな要因になります。

何を実現したいのか。何を優先し、何を割り切るのか。どこまでを今回の対象範囲とするのか。将来的にどのような拡張を見込むのか。

これらが整理されていない状態では、ベンダーも適切な提案を出すことができません。

システムベンダー選定を成功させる第一歩は、良いベンダーを探すことではなく、自社の意思を整理することです。

システムベンダーに依頼するメリット・デメリット

システムベンダーに依頼することにはさまざまなメリットとデメリットがあります。これらを理解することで、企業は自社のニーズに最適な選択ができるようになります。システム開発や導入の外部委託は、リソースの効率的な活用を可能にする一方で、外部との調整が必要になるため、注意が必要です。

また、外部のシステムベンダーを選ぶことで、専門知識やノウハウを活用できるだけでなく、時間やコストを削減できる場合もあります。こうした点を踏まえて、システムベンダーの選定は慎重に行うべきです。

メリット

システムベンダーに依頼する最大のメリットは、専門的な技術力と経験を活かした高品質なシステムを導入できる点です。外部の専門家がプロジェクトを担当することで、企業内部でのリソース不足やスキル不足を補うことができます。

さらに、システムベンダーは過去の導入事例に基づいたノウハウが豊富にあり、効率的でスムーズな開発・導入が期待できます。また、システムの運用や保守も任せることができ、企業側の負担を軽減することができます。これにより、長期的な視点でのコスト削減や業務効率化が図れることもあります。

デメリット

一方で、システムベンダーに依頼する際のデメリットもあります。最も重要な点は、外部の業者に依頼することで発生するコミュニケーションコストです。プロジェクトの進行において、ベンダーとの間でスムーズな連携が取れないと、システム開発が遅延したり、予算オーバーになったりするリスクがあります。

また、ベンダー依存度が高くなることで、後々の変更や追加機能の対応に困難が生じる可能性もあります。特に、システムが複雑であるほど、ベンダーとの協力が重要となります。契約内容を十分に確認し、慎重に選定することが重要です。

ベンダーを選ぶ前に、発注者側が整理すべきこと

システムベンダーを選ぶ前に、まず発注者側が整理すべきことがあります。

それは、自社が何を実現したいのか、何を重視するのか、どのような条件であればプロジェクトを進められるのかという「判断の前提」です。

ここが曖昧なままベンダー選定を始めると、各社からの提案内容がバラバラになり、比較が難しくなります。

結果として、価格、知名度、営業担当者の印象といった分かりやすい要素に判断が引っ張られてしまいます。

目的を整理する

まず明確にすべきなのは、システム導入・刷新の目的です。

業務効率化をしたいのか、老朽化したシステムを刷新したいのか、属人化した業務を標準化したいのか、事業成長に耐えられる基盤をつくりたいのか。

目的によって、選ぶべきベンダーは変わります。

例えば、既存業務を正確に置き換えることが主目的であれば、業務理解力や移行経験が重要になります。一方で、新しい事業モデルや顧客接点をつくることが目的であれば、企画段階から伴走できる提案力や柔軟な開発体制が重要になります。

優先順位を整理する

すべての条件を満たすベンダーを探そうとすると、選定は難しくなります。

コストを抑えたいのか、スピードを重視したいのか、品質を重視したいのか、将来の拡張性を重視したいのか。

優先順位を決めておくことで、提案書を評価する際の軸が明確になります。

特に基幹システムや業務システムの刷新では、短期的な費用だけでなく、運用開始後の保守性、変更しやすさ、業務への定着まで含めて判断する必要があります。

対象範囲を整理する

ベンダー選定で見落とされやすいのが、対象範囲の整理です。

どの業務を対象にするのか。どのシステムと連携するのか。データ移行は含むのか。運用設計や教育は含むのか。既存システムの調査は誰が行うのか。

これらが曖昧なまま見積りを依頼すると、各社の前提が揃わず、金額差の理由が分からなくなります。

ベンダーの見積りに2倍、3倍の差が出る場合、その多くは単価の違いだけではありません。対象範囲、前提条件、リスクの見込み方が異なっている可能性があります。

判断基準を整理する

最後に重要なのが、誰が、どの基準で、どのように意思決定するのかを決めておくことです。

現場部門、情報システム部門、経営層では、重視するポイントが異なります。

現場は使いやすさを重視し、情報システム部門は保守性やセキュリティを重視し、経営層は投資対効果や将来性を重視します。

これらの視点を整理しないまま評価を行うと、選定会議の場で意見が割れ、最終判断が曖昧になります。

ベンダー選定は、単なる比較作業ではありません。

発注者側が自社の意思を明確にし、その意思に合う相手を選ぶプロセスです。

自社の意思を整理するところから始めたい方は、システム構想策定支援のページもご覧ください

システムベンダー選定の流れ

システムベンダー選定は、いくつかのステップを踏んで行います。これらのステップを順番に実行することで、最適なベンダーを選定することができます。それぞれのステップでしっかりと準備と確認を行うことが、プロジェクト成功の鍵となります。

特に、選定基準や評価項目を明確にしておくことで、後々の選定作業がスムーズに進みます。

ベンダー候補の調査

システムベンダー選定の第一歩は、ベンダー候補の調査です。まずは、自社のニーズに合ったシステム開発を手掛けている企業をリストアップします。業界やシステムの種類に特化したベンダーを選ぶことが大切です。

インターネットでの情報収集や、過去に同様のプロジェクトを成功させた企業の紹介を受けることも効果的です。

また、実際に候補となるベンダーのウェブサイトを訪れ、導入事例や対応可能なシステムの詳細を確認することも重要です。選定候補となるベンダーは、提供するサービスの範囲や対応分野を事前に調査し、絞り込む必要があります。

RFIの作成

次に、RFI(Request for Information)を作成します。RFIは、ベンダーに対してシステム開発に関する基本的な情報を提供してもらうための文書です。これには、各ベンダーの技術力や導入実績、開発手法、提供するサポート体制などの情報を含みます。

RFIを通じて、ベンダーが自社の要件にどの程度応えられるかを確認することができます。RFIの作成では、要件を明確に伝え、ベンダーの適合度を初期段階で見極めることが可能になります。

RFPとRFIの違いとは?記載する項目や作成する4つのメリットを徹底解説!

RFPの作成

RFP(Request for Proposal)は、具体的な提案をベンダーに求める文書です。RFPを作成することで、各ベンダーがどのように自社の要件に対してアプローチし、どのような解決策を提供できるのかを明確にすることができます。

提案書には、費用、スケジュール、開発方法、導入後のサポート内容など、詳細な情報が含まれるため、選定時の重要な資料となります。RFPの内容は、自社の要求に基づいてベンダーがどれだけ柔軟に対応できるかを確認するための重要な手がかりとなります。

RFPと要件定義書の違いは?RFIやRFQとの違いやRFPを作成するうえでの9つのポイントを解説

評価項目の作成

ベンダー選定を行う際には、評価項目を事前に設定しておくことが重要です。評価項目は、システムの機能性やコストだけでなく、ベンダーとの相性や将来的なサポート体制なども考慮に入れるべきです。評価項目を明確にすることで、後で比較検討を行う際にスムーズに進めることができます。

特に、システムの運用後のサポート体制や、ベンダーが提供する追加サービスなども評価項目に含めると良いでしょう。

提案書の精査

ベンダーから提出された提案書を精査します。提案書にはシステムの詳細な設計図やスケジュール、費用が示されているため、これを基にベンダーの能力や提案内容が自社のニーズに合致しているかを確認します。

特に、費用対効果や納期の具体性に注目し、実行可能性があるかを検証します。提案書に記載されている内容が、自社の目指す目標と整合性が取れているかをチェックすることが非常に重要です。

最終評価

最終評価は、ベンダー選定の最終段階で行う重要なステップです。ここでは、前述の評価項目を基に、各ベンダーの提案内容を総合的に評価します。最終的にどのベンダーが最も自社の要件を満たし、信頼できるパートナーとして適切かを決定します。

この段階では、価格だけでなく、長期的なサポートや保守体制も考慮に入れた選定が求められます。選定後のアフターフォローが重要になることも考慮に入れると良いでしょう。

システムベンダーの選び方|確認すべき7つの評価ポイント

① 自社の業務・業界への理解があるか

システムベンダーを選ぶ際は、技術力だけでなく、自社の業務や業界特性をどこまで理解できるかを確認する必要があります。

同じ販売管理システム、在庫管理システム、基幹システムであっても、業種や商流によって必要な設計は大きく異なります。

業務理解が浅いまま開発が進むと、画面や機能は完成しているように見えても、実際の現場では使いづらいシステムになることがあります。

確認すべきなのは、過去の業界実績だけではありません。

自社の業務を理解しようとする姿勢があるか。現場の言葉をシステム要件に翻訳できるか。業務の例外処理や部門間の調整ポイントまで想像できるか。

このような観点で見極めることが重要です。

② 同種プロジェクトの実績があるか

開発実績を見る際は、単に「実績数が多いか」ではなく、自社のプロジェクトと近い条件での経験があるかを確認します。

例えば、基幹システム刷新、既存システムからの移行、複数部門をまたぐ業務改革、外部システムとの連携、長期運用を前提とした保守など、プロジェクトの性質によって必要な経験は異なります。

また、成功事例だけでなく、過去のプロジェクトでどのような問題が発生し、それにどう対応したかを確認することも有効です。

トラブルが一切ないプロジェクトはほとんどありません。

重要なのは、問題が起きたときに、原因を整理し、関係者と合意形成しながら前に進める力があるかどうかです。

③ プロジェクトを動かす体制が具体的か

ベンダー選定では、会社全体の実績だけでなく、実際に担当するプロジェクト体制を確認する必要があります。

提案書に立派な体制図が書かれていても、責任者の関与度が低かったり、実務担当者の経験が不足していたりすれば、プロジェクトは安定しません。

確認すべきポイントは、プロジェクトマネージャーの経験、業務理解を担う担当者の有無、設計・開発・テスト・移行・運用保守の役割分担、繁忙期や担当者変更時のバックアップ体制です。

特に中堅・中小企業のシステム刷新では、発注者側にも十分なIT人材がいないケースがあります。

その場合、ベンダー側に「言われたものを作る力」だけでなく、「進め方を整理し、発注者側の判断を支援する力」があるかが重要になります。

④ 見積りの金額ではなく、前提条件が明確か

見積り評価で重要なのは、金額の高い・安いだけではありません。

その金額に何が含まれていて、何が含まれていないのか。どのような前提で工数を算出しているのか。追加費用が発生する条件は何か。

ここを確認しなければ、正しい比較はできません。

特に、要件定義、データ移行、外部連携、テスト、操作説明、運用設計、プロジェクト管理、保守引き継ぎなどは、見積りの含まれ方に差が出やすい項目です。

安い見積りが悪いわけではありません。

しかし、安い理由が説明されていない見積りは、後から追加費用やスコープ調整が発生するリスクがあります。

ベンダーを選ぶ際は、金額そのものではなく、見積りの構造と前提条件を確認することが重要です。

⑤ 提案内容に実現性があるか

提案書には、魅力的な言葉や将来構想が並ぶことがあります。

しかし、実務で重要なのは、その提案が本当に実行できる内容になっているかです。

スケジュールに無理はないか。要件定義の期間は十分か。現行システム調査やデータ移行のリスクを見込んでいるか。現場部門の確認工数を考慮しているか。

このような点を確認しないまま契約すると、プロジェクト開始後に「提案時の前提が甘かった」という問題が発生します。

良い提案とは、夢のある提案ではなく、現実に進められる提案です。

実現性を見極めるためには、ベンダーに対して「どこにリスクがあると考えているか」「そのリスクにどう対応するか」を確認することが有効です。

⑥ 運用開始後まで見据えているか

システム開発は、リリースして終わりではありません。

実際には、運用開始後に問い合わせ、軽微な修正、追加要望、業務変更への対応、障害対応、データ確認などが発生します。

そのため、ベンダー選定では、開発中の体制だけでなく、運用開始後の支援体制も確認する必要があります。

保守対応の範囲、対応時間、障害時の初動、改善要望の扱い、担当者変更時の引き継ぎ、ドキュメントの整備状況などを事前に確認しておくべきです。

特に基幹システムや業務システムでは、運用開始後の改善を前提にした関係性が重要になります。

開発時点では見えていなかった課題が、実運用の中で明らかになることも多いためです。

⑦ 長期的に付き合えるパートナーか

最後に確認すべきなのは、長期的に信頼できる相手かどうかです。

システムは一度導入すると、数年から十年以上使い続けることもあります。その間に、事業環境、業務内容、組織体制、利用技術は変化します。

その変化に対して、ベンダーが継続的に相談に乗れるか。必要な改善提案をしてくれるか。特定の担当者に依存しすぎていないか。将来の技術変化にも対応できるか。

これらは、短期的な開発費用だけでは判断できません。

ベンダー選定では、「今回のシステムを作れる会社」ではなく、「今後の事業変化に合わせて、システムを育てていける会社」を選ぶ視点が必要です。

システムベンダーの評価の方法

システムベンダーを選定するためには、評価方法をしっかりと定めることが必要です。評価の基準を明確にすることで、比較検討がスムーズに進みます。システム導入の成功を確実にするためには、最初の段階で評価基準をしっかりと固め、計画的に選定プロセスを進めることが非常に重要です。

これにより、最終的に自社の要件に最も適したベンダーを見つけることができ、業務効率化やコスト削減、システムの品質向上が実現できます。

評価するための切り口を定める

ベンダーを評価する際は、どの要素を重視するかを決めておくことが重要です。技術的な要件やコスト面、納期、サポート体制など、評価する切り口を整理し、何を最も重視するかを明確にしましょう。例えば、システムの性能や機能性に加え、ベンダーが提供するサポート体制やシステムの拡張性、将来的なアップデートへの対応力も重視することが必要です。

評価の切り口を複数設定することで、全体的なバランスを取った比較が可能となります。また、予算の制約がある場合、コストに対する評価を重視し、最適な価格で高品質なシステムを導入できるかどうかを確認することも重要です。

具体的な評価項目を定める

評価項目は、システムの機能性や開発スケジュールだけでなく、ベンダーとのコミュニケーションのしやすさや企業文化のマッチングも考慮に入れるべきです。例えば、「対応スピード」や「問題解決能力」など、具体的な項目を定めることが効果的です。ベンダーとのやり取りのスムーズさや、どれだけ自社のニーズに柔軟に対応できるかも重要な要素となります。

さらに、システムのセキュリティ対策やリスク管理の方法、システム障害が発生した際の対応能力も評価項目に加えるべきです。また、ベンダーが過去にどのような実績を上げてきたかを参考にし、その実績を基に信頼性や安定性を評価することも重要なポイントです。

評価項目の配点を決める

各評価項目にどの程度の重要度を置くかを決めることで、比較がしやすくなります。例えば、コストが重要であればその項目に高い配点を与え、納期が重視される場合はその項目に高評価を与えるといった具合です。特に、システムの導入後のサポート体制や保守契約についても重要な項目として扱うべきです。

各項目の配点は、システムが導入される目的や自社の業務に与える影響を考慮して、合理的に設定することが求められます。評価項目の配点を明確にしておくことで、最終的にベンダー選定を行う際に、重要な要素に基づいて決定を下すことができます。また、配点を決めることで、数値的な比較がしやすくなるため、選定作業をより客観的に進めることが可能になります。

評価結果を比較しベンダーを選定する

最終的に、評価結果を総合的に比較し、最も自社のニーズに合ったベンダーを選定します。この段階で、数社を絞り込むことができるため、選定後は早めに契約を結ぶことが重要です。ベンダー間での比較においては、選定基準を再確認し、どのベンダーが自社の要件を最も満たしているかを見極める必要があります。

比較結果に基づき、価格や納期の面でも最適な選択をすることが大切です。

また、最終選定時には、ベンダーの提案内容に加えて、長期的な視点でのパートナーシップを重視することが、システム導入後の成功を左右する要因となります。評価結果を比較する際には、数値的なデータだけでなく、ベンダーとの相性や信頼性も重要な要素となります。

システムベンダー評価表の作り方

システムベンダーを比較する際は、評価表を作成しておくと判断しやすくなります。

ただし、評価表は単に点数を付けるためのものではありません。

関係者の判断基準を揃え、なぜそのベンダーを選んだのかを説明できる状態にするためのものです。

評価項目はRFPを出す前に決める

評価項目は、ベンダーから提案書が届いてから考えるのではなく、RFPを出す前に決めておくことが重要です。

提案を見た後に評価基準を変えてしまうと、印象の良い提案や価格の安い提案に判断が引っ張られやすくなります。

あらかじめ評価項目を決めておくことで、各社の提案を同じ基準で比較できます。

評価項目の例

システムベンダー評価表では、次のような項目を設定するとよいでしょう。

評価観点確認する内容
業務理解自社業務、業界特性、現場課題を理解しているか
提案内容課題に対する解決策が具体的か、実現性があるか
技術力必要な技術、開発手法、連携、セキュリティに対応できるか
プロジェクト体制PM、業務担当、開発担当、保守担当の役割が明確か
実績同種プロジェクト、同規模案件、移行経験があるか
見積り金額の根拠、前提条件、対象範囲が明確か
スケジュール無理のない計画か、発注者側の確認工数も考慮されているか
運用保守リリース後の問い合わせ、障害対応、改善対応の範囲が明確か
リスク対応想定リスクと対応策が提案されているか
相性・信頼性長期的に相談できる相手か、率直な対話ができるか

配点はプロジェクトの目的に合わせる

すべての項目を同じ点数で評価する必要はありません。

例えば、短期間でのシステム導入が重要な場合は、スケジュールや体制の配点を高くします。

基幹システム刷新のように長期運用が前提となる場合は、業務理解、移行経験、保守体制、将来性の配点を高くするべきです。

一方で、PoCや小規模な試行開発であれば、スピード感や柔軟性を重視してもよいでしょう。

重要なのは、自社の目的に合った評価軸を設定することです。

点数だけで決めない

評価表は有効ですが、点数だけで機械的に決めるべきではありません。

なぜなら、システムベンダー選定には、数値化しにくい要素も含まれるからです。

例えば、こちらの課題を深く理解しようとする姿勢、リスクを正直に伝える誠実さ、経営層や現場部門との対話力、プロジェクトが難航したときの粘り強さなどは、単純な点数だけでは評価しきれません。

評価表は、最終判断の代わりではなく、判断を支えるための道具です。

最終的には、点数、提案内容、面談での印象、リスク、社内の優先順位を総合して判断する必要があります。

ベンダー選定を成功させるにはRFPが重要

システムベンダー選定では、RFPの質が提案の質を左右します。

RFPとは、ベンダーに対して提案を依頼するための文書です。システム導入の背景、目的、対象範囲、課題、要件、予算感、スケジュール、評価基準などを整理し、各ベンダーに共通の前提を提示します。

RFPが曖昧なままでは、ベンダーごとに解釈が分かれ、提案内容や見積りの前提がバラバラになります。

その結果、どのベンダーが本当に適しているのかを比較できなくなります。

RFPはベンダーを縛るためのものではない

RFPというと、細かい要件をすべて書き出し、ベンダーにその通りに見積もらせる文書だと思われがちです。

しかし、実務上のRFPで重要なのは、ベンダーを縛ることではありません。

発注者側の目的、制約条件、判断基準を明確にし、ベンダーが適切な提案を出せる状態をつくることです。

つまりRFPは、ベンダーを競わせるためだけの文書ではなく、各社の提案を同じ土俵で比較するための文書です。

RFPに書くべき主な項目

システムベンダー選定のためのRFPには、少なくとも次の項目を整理しておくとよいでしょう。

項目内容
プロジェクトの背景なぜシステム導入・刷新を行うのか
目的・ゴール何を実現したいのか、何を成功とするのか
対象範囲対象業務、対象システム、対象部門
現状課題現在発生している業務・システム上の問題
要件機能要件、非機能要件、連携要件、移行要件
予算感想定予算、費用上限、費用に対する考え方
スケジュール提案期限、選定時期、導入希望時期
提案依頼事項ベンダーに回答してほしい内容
評価基準何を重視して選定するのか
契約・保守条件契約形態、保守範囲、運用開始後の支援

RFPを作成することで、発注者側の考えが整理されます。

また、ベンダー側も提案すべき内容を理解しやすくなり、結果として比較可能な提案を受け取りやすくなります。

システムベンダー選定に不安がある場合はご相談ください

システムベンダー選定では、価格、実績、提案内容、体制、将来性など、複数の要素を総合的に判断する必要があります。

しかし実際には、提案書を読んでも各社の違いが分かりにくい、見積り金額の差の理由が判断できない、どのベンダーを選ぶべきか社内で意見が分かれる、といった悩みが起こりがちです。

オーシャン・アンド・パートナーズでは、発注者側の立場から、RFP作成、ベンダー選定、提案比較、評価基準の整理を支援しています。

特定のベンダーを推すのではなく、貴社が納得して意思決定できる状態をつくることを重視しています。

システム導入・基幹システム刷新・RFP作成・ベンダー選定でお悩みの場合は、お気軽にご相談ください。

RFP作成・ベンダー選定支援について詳しく見る

この記事を書いた人について

谷尾 薫
谷尾 薫
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア(全省庁統一資格Aランク)代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

関連記事

資料ダウンロード