基幹システムを「入れ替える」のではなく、事業を支える仕組みをつくり直す。
基幹システムの再構築は、古くなったシステムを新しくするだけのプロジェクトではありません。
業務をどう変えるのか。
何を共通化し、何を残すのか。
どこまでをシステムで実現するのか。
誰に任せ、どうプロジェクトを進めるのか。
多くの判断が連続する、長期のプロジェクトです。
オーシャン・アンド・パートナーズは、構想策定からRFP、ベンダー選定、要件定義、開発・移行まで、発注側の立場で一貫して支援します。
こんな状況ではありませんか？
- 長年の改修で、システムの全体像が分からなくなっている
- 業務が変わっているのに、システムが追いついていない
- 現行ベンダーへの依存が強く、他の選択肢を判断できない
- パッケージ、SaaS、スクラッチなど、どの方向がよいか決められない
- 現場から要望が大量に出て、再構築の範囲が膨らんでいる
- 数千万円、数億円という投資をどう判断すればよいか分からない
- 社内だけでは、長期のプロジェクトを推進する体制をつくれない
基幹システムは動いている限り、刷新を先送りすることもできます。
しかし、その間にも事業や業務は変わります。
問題は「古いこと」そのものではなく、会社が変わりたいときに、システムが変化を妨げることです。
「今のシステム」を新しくするだけでは、再構築にならない
基幹システム刷新では、現在の機能を洗い出して、新しいシステムへ置き換える方法が取られがちです。
しかし、10年前、20年前につくられた仕組みには、その当時の業務や組織、商品、顧客、商習慣が組み込まれています。
そのまま新しい技術で作り直せば、
古い会社の仕組みを、新しいシステムで再現する
ことになりかねません。
再構築を機会に考えるべきなのは、
- 今後も残す業務は何か
- なくせる業務は何か
- 全社で共通化できるものは何か
- 事業ごとに残すべき違いは何か
- 将来変わることを前提に、どこを柔軟にしておくか
という、会社の仕組みそのものです。
システムを入れ替えるのではなく、事業を支える構造をつくり直す。
私たちは、そこから基幹システム再構築を考えます。
基幹システム再構築で決めること
01｜何のために再構築するのか
老朽化対応だけでなく、今後の事業、業務、組織の変化まで含めて再構築の目的を整理します。
02｜何を変え、何を残すのか
現在の業務やシステムを前提とせず、残すもの、変えるもの、なくすものを整理します。
03｜どんな構造にするのか
一つの巨大なシステムに集約するのか、コアを共通化して周辺を分けるのか、SaaSなどを組み合わせるのか。将来の変化も踏まえて全体像を設計します。
04｜誰とつくるのか
RFPを作成し、複数の選択肢からベンダーや製品を比較します。価格だけでなく、技術、体制、実現性、将来性などから判断します。
05｜どうやって実現するのか
要件定義、開発、テスト、移行まで、発注側としてプロジェクトを管理します。
構想から稼働まで、一つのプロジェクトとして支援します
基幹システム再構築では、フェーズごとに判断が分断されることが大きなリスクになります。
構想で決めたことがRFPに反映されない。
RFPで重視したことが要件定義で変わる。
要件定義で決めたことが開発途中で膨らむ。
こうしたズレを防ぐため、構想から実装まで一つの軸でつなぎます。
STEP 1｜現状・課題を整理する
現在の業務、システム、データ、運用、契約などを把握し、「なぜ再構築するのか」を整理します。
↓
STEP 2｜構想をつくる
目指す業務とシステムの姿、対象範囲、優先順位、実現方法、投資規模などを整理します。
↓
STEP 3｜要求・RFPを整理する
構想を具体的な要求へ落とし込み、ベンダーへ提案を求めるためのRFPを作成します。
↓
STEP 4｜ベンダー・製品を選ぶ
提案内容、費用、技術、体制、リスクなどを比較し、発注側が選定できる材料を揃えます。
↓
STEP 5｜要件定義・開発を進める
発注側として要件を整理し、優先順位や変更を判断しながらベンダーとプロジェクトを進めます。
↓
STEP 6｜移行・稼働につなげる
データ移行、受入テスト、業務切替などを整理し、新しい仕組みを実際の業務へつなげます。
プロジェクトが始まってからでも支援できます
すべてのプロジェクトが、最初から私たちと始まるわけではありません。
たとえば、
ベンダーから提案が出てきたが、妥当なのか判断できない。
要件定義を始めたものの、要望が増え続けて前に進まない。
開発が始まったが、予算・仕様・スケジュールに違和感がある。
こうした途中段階からでも支援できます。
現状を確認し、
何が決まっていて、何が決まっていないのか。
どこから整理し直す必要があるのか。
を明らかにしたうえで、必要なところからプロジェクトに入ります。
発注側にも、プロジェクトを動かす専門家が必要です
システム開発会社は、システムをつくる専門家です。
しかし基幹システム再構築では、発注側にも専門的な仕事があります。
- 経営と現場の意見を整理する
- 要求の優先順位を決める
- ベンダーの提案を評価する
- 見積や変更内容の妥当性を判断する
- 複数の選択肢から意思決定する
- プロジェクトが目的から外れていないか確認する
これらをすべてベンダーへ任せてしまうと、「何をつくるか」だけでなく「何をつくるべきか」まで、つくる側に委ねることになります。
私たちは、ベンダーの代わりではありません。
ベンダーと一緒にプロジェクトを進める、発注側のチームに入ります。
必要なフェーズから支援できます
すべてを一括してご依頼いただく必要はありません。
| フェーズ | 主な支援内容 |
|---|---|
| 構想 | 現状分析・業務整理・システム構想・IT投資判断 |
| 調達 | 要求整理・RFP作成・ベンダー／製品選定 |
| 実行 | 要件定義・発注側PMO・ベンダーコントロール |
| 移行 | 移行計画・受入支援・業務切替 |
| 稼働後 | 課題整理・改善・ベンダー管理 |
「まだ刷新するか決めていない」という段階から、「すでに開発が始まっている」という段階まで、状況に応じて支援範囲を設計します。
支援事例
製造業
老朽化した基幹システムの刷新に向け、構想整理からベンダー選定まで支援。複数の提案を比較し、経営判断に必要な材料を整理しました。
金融関連団体
業務システム刷新において、要件整理から開発管理まで支援。業務部門・システム部門・ベンダー間の認識を整理しながらプロジェクトを推進しました。
小売・サービス業
複数ベンダーが関与するプロジェクトに発注側PMOとして参画。課題と優先順位を整理し、停滞していたプロジェクトの立て直しを支援しました。
よくあるご質問
問題ありません。現行システムを延命するのか、一部を入れ替えるのか、全面再構築するのか。その判断から支援できます。
問題ありません。ベンダー変更を目的とはせず、継続を含めた選択肢を比較できる状態をつくります。
最初からどちらかを前提にはしません。業務特性、独自性、将来の変化、費用、運用体制などから選択肢を比較します。
プロジェクトの内容に応じて、開発まで含めた支援も可能です。発注側支援を基本としながら、特に難易度の高い領域や技術的なハードルが高い部分では、私たち自身が実装に入るケースもあります。
可能です。要件定義、ベンダー選定、開発、プロジェクト立て直しなど、現在の状況を確認して必要なフェーズから支援します。
基幹システムを変えることは、会社の仕組みを変えること。
基幹システム再構築では、技術だけでなく、業務、組織、投資、ベンダー、移行など、多くの判断が必要になります。
まだ方向性が決まっていなくても構いません。
すでにプロジェクトが動いていても構いません。
構想から実装まで、発注側に立ってプロジェクトを動かす。
基幹システム再構築のどの段階からでもご相談ください。