学習目標
製品を先に選ぶのではなく、事業の目的と業務課題からシステムの役割を決める。部門ごとの便利さが、全体の成果に結び付くかを確認する。
EAの四つの観点
| 観点 | 主な問い | 受注業務の例 |
|---|---|---|
| ビジネス | 誰が何を行い、どんな価値を生むか | 受付、与信、在庫引当、出荷 |
| データ | どの情報を何の意味で共有するか | 顧客、商品、注文、在庫の定義 |
| アプリケーション | どの機能をどのシステムが担うか | 受注管理、倉庫管理、請求 |
| テクノロジー | どの技術基盤・標準で支えるか | 認証、連携方式、実行基盤 |
EAは四つの図を描いて終わるものではない。現状と目標との差、依存関係、移行順序をそろえるために使う。四層の関係はIPA DX白書2023の説明を参照し、以下の例は独自に作成している。
改善の種類を分ける
| 施策 | 変えるもの | 気を付けること |
|---|---|---|
| 現行作業の自動化 | 人の手作業を機械処理へ | 不要な承認や二重入力を温存しない |
| 業務プロセス再設計 | 手順、役割、判断の流れ | 現場への影響と統制を確認 |
| システム統合 | 重複機能・データ・連携 | 意味や責任が違うデータを無理に同一化しない |
| 外部サービス活用 | 自社で担う範囲 | 責任分界、出口戦略、データ移行性 |
As-Isは現状、To-Beは目標。現状の困りごとを解決するだけでなく、将来の業務量や事業変更も前提に入れる。ただし、根拠のない将来像のために過剰な仕組みを作らない。
判断例
営業部門の入力時間だけを半減させても、入力項目の意味が倉庫側と違えば確認電話が増え、注文から出荷までの総時間は悪化し得る。部門KPIだけでなく、受付から出荷までのリードタイム、再入力率、誤出荷率を確認する。共通の注文番号とデータ定義を整え、誰がデータの正しさに責任を持つかも定める。
目標と測定指標を結ぶ
| 段階 | 独自例 | 検証の問い |
|---|---|---|
| 目指す成果 | 顧客への納期回答を安定させる | 顧客にとって改善か |
| 成果の指標 | 約束納期の遵守率 | 母数と例外は明確か |
| 先行する活動指標 | 在庫情報の更新遅延、再確認件数 | 改善が成果につながる仮説はあるか |
| 施策 | 在庫連携、例外処理の標準化 | 効果と副作用を測れるか |
KGIを成果目標、KPIを達成過程の指標として整理する際も、名称だけで因果関係が証明されるわけではない。導入前後で対象条件が変わっていないかも見る。
モデル化の注意
業務の流れはBPMNなどで、担当や組織の境界、分岐、やり取りを整理できる。BPMNのシーケンスフローと組織間のメッセージフローを混同しない。OMG BPMN 2.0.2
間違えやすい点と確認
- 全体最適は全てを一つのシステムにまとめることと同義ではない。
- サービス連携が可能でも、データの意味や業務責任が一致するとは限らない。
- 最新技術の導入件数は、業務価値を直接測る指標ではない。
- 部門の処理時間だけが短縮したら成功か？ → 全体の待ち・手戻り・成果も確認する。
- アプリを統合する前にそろえたいものは？ → 業務上の目的、データの意味、所有責任、移行条件。
出典と適用上の注意
四層の表・As-Is/To-Be例・指標例は独自教材。技術流行を根拠とした出題頻度や的中率は示していない。