「何をつくるか」を決める前に、「何を変えるか」を決める。
システム刷新を考えると、つい「どの製品を使うか」「どのベンダーに頼むか」「どんな機能が必要か」という話から始まりがちです。
しかし、その前に決めることがあります。
今回のプロジェクトで、何を変えるのか。
何を残し、どこまでをITで変えるのか。
システム構想策定支援では、経営・業務・ITを横断して課題と選択肢を整理し、その後の要件定義やベンダー選定を進めるための「判断軸」をつくります。
こんな状況ではありませんか？
- システムを刷新したいが、何から整理すればよいか分からない
- 現場から多くの要望が出ているが、優先順位を決められない
- パッケージ、SaaS、スクラッチなど、どの方向がよいか判断できない
- 経営と現場で、システム刷新の目的や期待が揃っていない
- ベンダーに相談すると、製品や開発方式ありきの話になってしまう
- RFPを作りたいが、その前提となる方針が固まっていない
この状態で要件定義やベンダー選定へ進むと、途中で「そもそも何のためのシステムだったのか」という議論に戻ることがあります。
その前に、プロジェクトの土台をつくる。
それがシステム構想策定です。
システム構想とは、「未来のシステムを描くこと」ではありません
私たちが考えるシステム構想とは、画面や機能を決めることではありません。
事業や業務をどう変え、そのためにITをどう使うのかを決めることです。
たとえば、
- この業務をそのままシステム化するのか
- そもそも、この業務は必要なのか
- 全社で共通化するのか、個別性を残すのか
- パッケージに業務を合わせるのか、独自性を残すのか
- 今回どこまでやり、何を次に回すのか
こうした判断を重ねて、初めて「どんなシステムが必要なのか」が見えてきます。
構想がないと、「今の会社」をそのままシステム化してしまう
構想が曖昧なまま要件定義を始めると、各部門から要望が集まります。
「この機能は残してほしい」
「この帳票も必要」
「今できていることは全部できるようにしてほしい」
一つひとつの要望には理由があります。
しかし、それをすべて積み上げれば、今の業務をそのまま新しいシステムへ移すだけになりかねません。
本来、個々の要望を採用するかどうかを決める基準になるのが、システム構想です。
- 構想がないと、要件定義は「要望集」になる。
- 構想がないと、ベンダー選定は「提案比較」になる。
- 構想がないと、プロジェクト途中の判断基準がなくなる。
だからこそ、システムをつくり始める前に「何を変えるのか」を明確にします。
システム構想策定で決めること
01｜なぜ変えるのか
老朽化、業務効率化、事業変化への対応、属人化、新しいサービスへの対応など、プロジェクトを始める目的を明確にします。
02｜何を変えるのか
現在の業務やシステムを整理し、残すもの、変えるもの、なくすものを明確にします。
03｜どこまで変えるのか
全社で共通化する領域と個別性を残す領域、今回取り組む範囲と将来対応する範囲を整理します。
04｜どんな選択肢があるのか
パッケージ、SaaS、スクラッチ、既存システム活用など、特定の製品を前提とせず実現方法を比較します。
05｜何を基準に決めるのか
費用だけでなく、事業への効果、業務への影響、将来の変更容易性、運用負荷など、意思決定の基準を整理します。
支援の進め方
STEP 1 現状を知る
経営層・現場へのヒアリングや既存資料の確認を通じて、業務とシステムの現状を把握します。
↓
STEP 2 課題を整理する
現場から出てくる個別の要望をそのまま要件にせず、「なぜその問題が起きているのか」まで掘り下げます。
↓
STEP 3 目指す姿を描く
システムだけではなく、業務・組織・データを含めて「どう変えたいのか」を整理します。
↓
STEP 4 選択肢を比較する
実現方法、対象範囲、優先順位、概算規模などを比較し、意思決定できる材料を揃えます。
↓
STEP 5 次のプロジェクトへつなげる
方針を具体化し、RFP作成、ベンダー選定、要件定義へ進める状態をつくります。
ゴールは、「構想書をつくること」ではありません
私たちが目指すのは、立派な資料を納品することではありません。
発注側が、
「何を変えるのか」
「どこまでやるのか」
「何を基準に決めるのか」
を自分たちで説明し、判断できる状態をつくることです。
その結果として、
- プロジェクトの目的と対象範囲が明確になる
- 経営と現場の認識を揃えられる
- 必要な要件と不要な要件を判断できる
- システムや製品を比較する軸ができる
- 投資規模の目安を持てる
- RFP作成やベンダー選定へ進める
ようになります。
製品を売らないから、製品を決める前から支援できます
オーシャン・アンド・パートナーズは、特定の製品を販売する会社ではありません。
そのため、
「この製品をどう導入するか」ではなく、
「この会社にとって何が必要なのか」
から考えることができます。
必要なのが全面刷新とは限りません。
既存システムを残す、一部だけSaaSへ移す、業務そのものを変える、今回はシステム化しない。
そうした選択肢も含めて、発注側の立場で整理します。
構想が固まったら、次のステップへ
システム構想は、それ自体がゴールではありません。
構想をもとに、具体的な調達・実行へ進みます。
RFP作成・ベンダー選定支援
構想を具体的な提案依頼へ落とし込み、RFP作成から候補ベンダーの比較・選定まで支援します。
基幹システム再構築支援
基幹システム全体の刷新では、構想策定から要件定義、ベンダー選定、プロジェクト推進まで一貫して支援します。
よくあるご質問
はい。刷新するのか、現行を改善するのか、別の方法を取るのか。その判断からご相談いただけます。
問題ありません。現場ヒアリングから入り、個別の要望をそのまま要件にするのではなく、背景にある課題から整理します。
その段階からでも支援できます。提案された製品や方式を前提にせず、目的・対象範囲・判断基準から整理し直します。
可能です。構想策定後は自社で進めていただくことも、その後のRFP作成・ベンダー選定・要件定義・PMOまで継続して支援することもできます。
はい。ベンダを変更することが目的ではありません。既存のベンダとの関係を維持しながら、発注側の判断やプロジェクトの進め方を支援することも可能です。
プロジェクト規模、判断の難易度、関係者数、支援範囲などを確認したうえでご提案します。
「何をつくるか」を決める前に、「何を変えるか」を整理しませんか。
まだ要件が固まっていなくても構いません。
むしろ、固まっていない段階だからこそ、一緒に考えられることがあります。
現状を整理し、選択肢をつくり、発注側が判断できる状態にする。
システム構想の段階からご相談ください。
システム構想策定について相談する
システムを導入するべきか。現行システムを延命するべきか。ベンダ提案を受け入れるべきか。別の選択肢があるのか——まだ結論が出ている必要はありません。
むしろ、「問題は感じているが、何が問題なのか整理できていない」という段階こそ、私たちがお役に立てる場面です。システムを作る前に必要な判断の整理から、ご支援いたします。