5-5 システム戦略
システム戦略
システム戦略は、経営戦略や業務目標を実現するために、情報システムとデータをどのように活用するかを決める方針です。新しいツールを導入すること自体が目的ではなく、顧客価値、業務効率、意思決定、リスク管理などの成果へ結び付ける必要があります。
この節の目標は、現状業務を分析し、全体最適の視点から将来像、システム化対象、データ活用、評価指標を設計できるようになることです。
1. 経営戦略からシステム戦略へつなげる
| 層 | 決める内容 | 例 |
|---|---|---|
| 経営戦略 | どの市場で、どの価値を提供するか | 地域顧客へ当日配送を提供する |
| 事業・業務戦略 | どの業務を、どの方法で実現するか | 店舗在庫と配送を一体管理する |
| システム戦略 | どの情報と機能で業務を支えるか | 在庫、注文、配送状況を統合する |
| システム企画 | 対象範囲、費用、体制、調達方法を具体化する | SaaS比較、RFP、投資評価を行う |
経営目標と関係しないシステム投資は、機能が多くても優先度が高いとは限りません。目標、業務、データ、機能、KPIのつながりを確認します。
2. AS-ISとTO-BEで業務を整理する
- AS-IS：現在の業務、情報、問題点を可視化した状態。
- TO-BE：目標達成後の望ましい業務と情報の状態。
- ギャップ：AS-ISとTO-BEの差。改善施策やシステム要件の根拠になる。
完全ケース：営業報告の全体最適
ある会社では、営業担当者が案件情報を個人の表計算ファイルで管理しています。管理職は週末に各担当者のファイルを集めて集計し、在庫部門には電話で需要を伝えています。
AS-ISの問題は次のとおりです。
- 同じ顧客名が異なる表記で登録される。
- 最新の商談状況が管理職へ届くまで時間がかかる。
- 営業予測と在庫計画が連動しない。
- 退職者のノウハウが残りにくい。
TO-BEでは、顧客・案件情報を共通のCRMへ登録し、受注見込みを在庫計画へ連携します。営業担当は外出先から更新し、管理職はBI画面で進捗を確認します。
ここで重要なのは、表計算ファイルをそのままWeb化することではありません。顧客コード、案件段階、更新責任、閲覧権限、在庫部門との連携方法を統一します。
3. 業務と情報をモデル化する
| 表現方法 | 着目点 | 適した用途 |
|---|---|---|
| 業務フロー | 人や部門の作業と順序 | 申請、承認、引渡しの流れを確認する |
| DFD | データの流れ、処理、保存先 | 入力データがどこで処理・保存されるか整理する |
| ER図 | データ同士の関係 | 顧客、注文、商品の関係を設計する |
| UML | システムの構造や振る舞い | 利用者と機能、処理の流れ、クラス関係を示す |
図の見た目ではなく、何を明らかにしたいかで選びます。担当部門と作業順序なら業務フロー、データの移動ならDFD、データ項目の関係ならER図です。
4. エンタープライズアーキテクチャで全体最適を考える
EAは、企業全体を複数の視点から整理し、現状から目標状態へ計画的に移行する考え方です。
| 視点 | 整理する内容 | 例 |
|---|---|---|
| ビジネスアーキテクチャ | 経営目標、組織、業務プロセス | 受注から配送までの業務 |
| データアーキテクチャ | データの定義、関係、所有者 | 顧客コード、商品コード、マスタ管理 |
| アプリケーションアーキテクチャ | 業務を支えるアプリケーション | CRM、在庫、会計、EC |
| テクノロジアーキテクチャ | サーバ、クラウド、ネットワーク、端末 | クラウド基盤、認証、接続方式 |
部門ごとに顧客コードや商品コードが異なると、システムを接続しても全体の分析が難しくなります。全体最適には、共通データと責任分担の設計が必要です。
5. ソリューションを課題で選ぶ
| ソリューション | 解決する代表的な課題 | 注意点 |
|---|---|---|
| ERP | 部門ごとに分散した会計・販売・在庫データ | 業務とコード体系の標準化が必要 |
| CRM / SFA | 顧客・案件情報が担当者に分散している | 入力ルールと利用目的を明確にする |
| SCM | 需要、調達、生産、在庫、物流が連動しない | 取引先を含む情報共有が必要 |
| ワークフロー | 紙の申請、承認状況が見えない | 不要な承認段階も見直す |
| グループウェア | 予定、文書、連絡が分散している | 情報分類と運用ルールを決める |
| BI | データはあるが意思決定に使えない | 元データの品質と指標定義が重要 |
| RPA | 定型的な画面操作を繰り返している | 例外処理や画面変更への対応が必要 |
RPAは非効率な業務をそのまま自動化する可能性があります。まず業務の必要性と流れを見直し、その後で自動化対象を選びます。
6. DXとデータ活用を目的で捉える
DXは、デジタル技術やデータを使って、業務だけでなく製品、サービス、顧客体験、組織文化、事業モデルを変革する取組です。紙をPDFへ置き換えるだけでは、必ずしも事業変革にはなりません。
例えば、設備メーカーがセンサから稼働データを収集し、故障前に保守を提案するサービスへ転換すれば、売切り型から継続サービス型へ事業モデルが変わります。
データ活用の判断手順は次のとおりです。
- 解決する業務・顧客課題を明確にする。
- 必要なデータと取得方法を決める。
- 品質、権利、個人情報、セキュリティを確認する。
- 分析やAIの出力を業務判断へ組み込む。
- KPIで効果と副作用を測定する。
- 現場の運用と責任分担を継続的に改善する。
7. システム戦略の評価指標
| 目的 | 指標の例 |
|---|---|
| 売上・顧客価値 | 売上、購入率、継続率、顧客満足度 |
| 業務効率 | 処理時間、入力件数、手戻り率、自動化率 |
| 品質 | 誤入力率、不良率、問い合わせ解決率 |
| システム運用 | 稼働率、応答時間、障害件数、復旧時間 |
| リスク | 権限違反、情報漏えい、未承認変更、監査指摘 |
導入件数やログイン数だけでは、経営成果を説明できない場合があります。利用指標と成果指標を分けて設定します。
8. よくある誤りと理由
- 最新技術の導入を目的にする：経営課題と成果指標が先です。
- 現行業務をそのままシステム化する：不要な作業や承認も残ります。
- 部門ごとに最適化する：企業全体でデータと業務が分断される可能性があります。
- RPAを全ての自動化に使う：定型性、例外、変更頻度を確認します。
- DXを単なるデジタル化と考える：顧客価値や事業・組織の変革まで含めて考えます。
- データを集めれば価値が生まれると考える：目的、品質、分析、業務利用が必要です。
9. セルフチェック
- 経営目標とシステム施策のつながりを説明できるか。
- AS-IS、TO-BE、ギャップを区別したか。
- 問題が業務、データ、アプリケーション、技術のどこにあるか。
- 部門最適ではなく全体最適になっているか。
- 導入指標だけでなく業務・経営成果を測るKPIがあるか。
理解を確認したら、第5章の練習問題と第5章の知識カードで業務課題と施策を対応させてください。具体的な投資・調達計画は、システム企画で学びます。
公式範囲との対応
本節は、IPA「ITパスポート試験シラバス Ver.6.5」の情報システム戦略、業務プロセス、ソリューションビジネス、システム活用促進・評価に対応し、AS-IS・TO-BE、BPR、EA、業務モデリング、ERP、CRM、SCM、RPA、DX、データ活用を扱います。