ＢＡ不在の組織において、全社員のDXリテラシーを底上げさえすれば、ＤＸが実現できるのでしょうか。
ビジネスアナリシス（BA）機能が存在しない組織では、いくら全社員のDXリテラシーを底上げしても「真のDX」には到達できません。以下で、体系的にその理由と構造を整理します。

① 「DXリテラシー向上」と「DX実現」の間にある構造的ギャップ

 DXリテラシー向上が意味するものは、

社員一人ひとりが以下を理解し、ツールを活用できるようになる状態です：

• デジタル技術の基礎理解（データ・AI・クラウドなど）
• 業務のデジタル化・自動化スキル（ローコード/ノーコードなどによる）
• 現場レベルでの課題発見・改善提案能力

つまり、**「個人の理解・スキル向上」**までです。しかしDXの本質は、「組織として価値創出モデルを変革すること」ではないでしょうか、その「構造変革」を設計・推進する役割を担うのが**ビジネスアナリスト（BA）**となります。

② BAがいない組織で起きる典型的な“DXの壁”

→ 結果として、「DXの芽」は出ますがビジネス変革にまでは至りません。

③ 真のDXを実現するために必要な“BAの接続構造”

 3層構造モデル（DX成功組織の中核） を考えます。

この**中間層（BA）**が存在しないと、上層の「戦略」と下層の「実行」が乖離し、DXが“単なる改善活動の寄せ集め”に終わりそうです。いくら改善の数が多くても改革とは程遠いものです。

④ DXリテラシー教育だけでは変革が起きない理由

1. リテラシーは「理解」止まり、変革は「構造設計」から

•  社員教育は「デジタル理解」を高めますが、「業務・価値連鎖の再設計」はできません。
• BAはこの「理解」を「設計・実行」に変える変換装置です。 

2. ツール活用と価値創出の間をつなぐ存在

• 現場がAIやローコードを使えても、「それが企業価値にどう寄与するか」を測る設計者が必要。
• それがBAの役割。

3. 合意形成とトレーサビリティの中心

• DXは組織横断的。BAがいないと利害調整や要件統合が進まず、プロジェクトは分断されてしまいます。

⑤ DXリテラシーとBA内製化の「補完関係」

結論：DXリテラシーは必要条件、BA内製化は十分条件。

DXを「組織の成果」に変えるには、BAという“変革設計者”が不可欠。

⑥ 提案：DXリテラシー＋BA内製化の統合モデル（全社導入例）

いかがでしょうかビジネスアナリシス（BA）不在の組織では、いくら全社員のDXリテラシーを底上げしても「真のDX」には到達できないことが明確になったと思います。

 ①DXリテラシー向上の必要性

1. DXは一部門の業務改革ではなく、全社文化の変革

• DX（Digital Transformation）は単なるIT導入ではなく、「デジタルを活用してビジネスモデル・業務・組織文化を変革する」ことです。
• そのためには、経営層から現場までが共通の“DX言語”を理解し、同じ方向を向いて変革に参加できる状態が不可欠です。

2. 全社員がデジタルを「使う側」から「活かす側」へ

ツール操作の習熟ではなく、デジタルを使って価値を創出する視点が必要です。
具体的には：

• 「なぜこのデータを集めるのか」
• 「どんな意思決定を支援するのか」
• 「どうすれば顧客価値を最大化できるのか」
• といった“ビジネス視点のデジタル理解”が求められます。

3. BA内製化の前提条件としての「共通理解基盤」

• BAが業務変革をリードするには、現場がデータ・プロセス・KPIの概念を理解している必要があります。
• DXリテラシーの底上げは、BAとの連携をスムーズにし、全社一体での変革推進力を生みます。

②DXリテラシー向上の実現計画（全社展開モデル）

1.ステップ別ロードマップ

全社展開するためには次の様なロードマップが有効です。5つのフェーズにまとめてみました。

2.役割分担イメージ

続いて各役割毎の分担を考えます。経営層、人事/教育部門、部門リーダー、IT部門/BA、一般社員の各役割です。

3.施策の具体例

具体的な施策です。単なる教育・研修だけでなく、リテラシー向上のための体験と仕組みが重要です。そして動機付けを強化するために、人事評価にDXスキル指標を加えることを忘れてはいけません。

③ 成果モデル（BA内製化との連動）

まとめ：全社員DXリテラシー向上 × BA内製化 = 「変革自走型組織」

ビジネスアナリスト（BA）を外部委託ではなく内製化（社内育成・配置）することには、企業の変革力やDX推進力を高める大きな戦略的意義があります。そのメリット、内製化のステップ（手順）、そして成功のポイントを説明します。

 ビジネスアナリスト内製化のメリット

1. 事業戦略とIT施策の一貫性向上

• 外部ベンダーBAは一時的なプロジェクト志向になりがちですが、内製BAは企業の戦略・文化・業務構造を理解したうえで継続的に橋渡しできます。
• → 結果：戦略意図が確実に要件へ翻訳され、プロジェクト成果が経営成果へ直結。 

2. 業務知識とデータ資産の蓄積

• BAが社内に常駐することで、業務モデル・課題・改善施策・成功失敗の知見がナレッジ化されます。
• → ベンダーに依存しない「業務アーキテクチャの資産化」が可能。 

3. DX推進のスピードと柔軟性の向上

• DXの初期段階ではPoCやアジャイル開発が多く、スピーディな要件整理と意思決定支援が求められます。
• 内製BAがいれば、現場と経営の間で即時に分析・合意形成を行え、外部調整の時間ロスを削減。

4. コスト最適化と外部委託リスク低減

• ベンダーBAは高コストなうえに契約期間で離脱しますが、内製BAは継続的スキル成長＋組織学習を実現し、長期的にはROIが高くなります。 

5. 組織変革力（Change Enablement）の内在化

• BAは「変革の媒介者（enabler）」です。内製化により、変革を外部任せにせず、自社のDNAとして定着させることが可能になります。

 内製化の手順（ステップ）

成功のためのポイント

1. 経営層の支援と位置づけの明確化

• BAは「戦略×業務×IT」を橋渡しする職能であり、単なる“要件定義担当”ではない。経営層が明確に支援することが前提。

2. 「プロセス標準化」＋「ナレッジ共有」基盤の整備

• 　APQCのPCF（Process Classification Framework）などを活用し、共通言語・標準テンプレートを整備することでBA業務の品質を均質化。

3. アジャイル開発・DXプロジェクトとの接続

• BAが単独で動くのではなく、プロダクトオーナー・PM・データ分析チームと連携するハイブリッド体制を構築。

4. AI／ツール活用による効率化

• ChatGPTなどの生成AIや、要件管理ツール（JIRA、Confluence、Enterprise Architectなど）を組み合わせ、分析・文書化の生産性を高める。

まとめ（外部委託BAと内製BAとの比較）

前回は「DXにおけるビジネスルールの重要性」を解説いたしました。

今回はビジネスルールから発展して「意思決定マネジメント」の話です。

まず、用語の定義です。意思決定とはどういうことでしょうか。当たり前のことですが。

• ビジネス上の意思決定とは、企業が目標を達成するために「ある状況における複数の可能な選択肢の中から、最適な選択肢を選ぶこと」です。

そして、ビジネス上の意思決定には大きく分けて戦略上、戦術上、業務上の3種類あります。

戦略上の意思決定

• 長期的影響をもつ、トップマネジメントの意思決定
• 例：　企業買収、市場参入、事業撤退などで1回のみ行われます。

 戦術上の意思決定

• 部門・プロジェクトレベルでの最適化判断など
• 例：　営業戦略、チャネル設計などで意思決定の回数は少ないものです。

 業務上の意思決定

• 日々の業務で反復的に発生する判断
• 例：　保険契約の引受判断、ローン審査などで毎日数多く行われます。

戦略上の意思決定が重要で、業務上の（日常的な）意思決定はたいして重要ではないと思いがちですが、数多い（1日に数万回行われる）業務上の意思決定を正しく行うことは、戦略的な（1回のみ行われる）意思決定に引けを取らずに重要です。

これから議論するのはこの「業務上の意思決定」で自動化の対象になりやすいものです。

業務上の意思決定の定義

英語の「Decision」という言葉には一般に2つの意味があります。Decisionは複数の可能な選択肢の中から、選択する行為（決定すること）を示すこともあれば、Decisionは選択される選択肢そのもの（決定事項）を示すこともあります。これから解説する「業務上の意思決定（Decision）」はこの前者の意味で用います。

• 業務上の「意思決定」はアウトプットがどのインプットからどのように決定されるかを定義するロジック（意思決定ロジックと言います）を使って、多くのインプット（可能な選択肢）からアウトプット値（選ばれた選択肢）を決める行為です。
• 意思決定ロジックは、ビジネス・ルール、アナリティカル・モデル、などの「ビジネス知識モデル」として表されます。

意思決定モデルが作成されている基本的な構造は、下図のように表記されます。

[図のクリックで拡大表示]　意思決定モデルの基本要素　（OMG　DMN1.1　より）

業務上の意思決定が求められる典型的業務例（損保業界）

• 引受け：　　この契約は引受可能か？
• 査定：　　　支払対象となるか？
• 顧客分類：　この顧客はゴールドか？リスク顧客か？
• 商品適用：　どの商品が最適か？

これらの意思決定の多くは業務担当者が行っていたので次の様な課題があります。

• 不透明性   ：        判断の根拠が属人的で説明できない
• 一貫性欠如  ：     担当者によって判断が異なる
• 複雑化 ：    　　  多様なルールが絡み合って管理が困難
• 遅延  ：　　　　情報や判断の伝達に時間がかかる（上司に判断を仰ぐなど）

上記問題を解決するためにいくつかのアプローチが取られてきました。

• ルール分離 ：          業務プロセスから判断ルールを分離し、再利用・変更しやすくする
• 可視化と説明責任：    「なぜこの判断がなされたのか？」を構造的に説明できる設計
• 自動化（BRMS連携）： 判断をシステムで実行し、迅速・正確な対応を可能にする

DX時代における業務上の意思決定の重要性

DX時代はVUCAがつきものです。外部環境の変化に応じて意思決定を柔軟に変化する必要があります。

そのために最近グローバルで注目されているのがDMN（Decisio Model and Notation：意思決定モデルと表記法）です。

DMNとは、ビジネス上の意思決定をモデル化・表現・共有・実行可能な形で記述するための表記法（Notation）であり、OMG（Object Management Group）が定義する業界標準です。

このDMNにより次のことが可能になります。

• 意思決定ロジックを明示・共有可能にできる
• 業務担当者（非技術者）にも理解・検討可能なように可視化される
• 意思決定を実行可能な形で定義して自動化まで可能
• BPMN（ビジネスプロセスモデルと表記法）と組み合わせることにより、ルールを含む業務を自動化できる

上図をDRD（意思決定要求ダイアグラム）と言います。

このDRDの構成要素（図形）は上図のとおり、4つの図形（意思決定、入力データ、ビジネス知識、知識ソース）と要求の関係を表す3種類の矢印（情報要求線、知識要求線、根拠要求線）です。わずか7つの図形と矢印で意思決定をモデル化できますから、分かりやすくIT人材やビジネスアナリストのみならず業務担当者に容易に理解してもらうことが可能です。

意思決定するためには入力情報（データ）、意思決定するための知識（主にビジネスルール）が必要です。そして意思決定のアウトプットも情報（データ）になりますから、メインの意思決定にはサブ意思決定の結果を入力することが可能です。

ビジネス知識（主にビジネスルール）としてよく使用されるのはデシジョンテーブルです。上図はカード所有者の「勤務状況」「全債務/年収」の組合せでその個人の信用格付けを意思決定するロジックです。ビジュアルに意思決定がモデル化されることが分かると思います。これなら業務担当者でも容易に理解することが可能です。
このようにして意思決定は簡単にモデル化され自動化までできます。

意思決定とプロセスの自動化による業務の自動化

業務はプロセスとルールの組み合わせという前回の冒頭のパートを思い出してください。業務を自動化するにはプロセスと意思決定を同時に自動化する必要があります。

DMNはOMG（オブジェクト・マネジメント・グループ）が標準化したものですが、この団体はITシステムへの実装方法を標準化しています。つまり図形の意味を標準化するだけではなく、そのITへの実装方法を定義していますので、システム間で互換性があります。A社のシステムで作成されたDMNモデルはB社のシステム上でも稼働できるということです。

更にビジネスプロセスモデルとして有名なBPMN（ビジネスプロセスモデルと表記法）もこのOMGが標準化したものです。同じOMGが標準化したため、BPMNとDMGのデータ構造が共通に設計されており、DMNの意思決定のアウトプットデータをBPMNが使用することが可能です。その簡単な例が次の図です。

上図の右側がDMN意思決定モデルです。左側がBPMNプロセスモデルです。DMNで融資の申請が審査され、融資の意思決定（受入、拒否）がされます。そして意思決定のアウトプットが左側のBPMNで使用されます。DMNの決定を基にビジネスプロセスが動き、「受入れ」なら融資が決定します。簡単な図ではここまでですが、実際にはこの先プロセスが自動的に動きますので融資が決定されれば振込みまで自動で進むことができるようになります。極端に言えば、条件が問題なければ融資が申請された直後に銀行口座に融資額が振込まれる、ことまで自動化されるということになります。保険で言えば、保険金を請求したら保険金が即刻が振り込まれることが可能になる、ということです。そうなったらいいですよね。

DMNモデルにより複雑な意思決定を設計することができるようになりました。その効果は計り知れません。単にビジネスルールを管理することに比べて、以下のようなメリットがあります。

• ビジネスルールを判断の文脈（意思決定）として位置付けられる
• DRDで視覚的に記述されるので、意思決定の流れが表現できる
• 再利用・保守性が意思決定構造全体として最適化ができる
• 「なぜそう判断されたのか」を明確に説明できるので、説明責任能力が極めて高い

実際のDRD（意思決定要求ダイアグラム）とビジネスプロセスモデルをご覧ください。

上図のBPMNには次の3つのGateway（分岐）があります。

• 信用調査戦略を判定する（信用調査、スルー、謝絶）
• 判定ルーティング（受諾、参照、謝絶）
• 申込みを見直す裁定（受諾、謝絶）

その分岐条件は意思決定（DMN）の結果により分岐先が決まります。

最初のStrategy（信用調査戦略）判定に関するDRDは次のとおりです。

3つの意思決定（判定）要求ダイアグラムを合体したものが次の意思決定要求グラフです。

そして、4つの入力データです。

• Requested product（要求された金融商品）
• Applicant data（申込み者データ）
• Bureau data（信用調査会社データ）
• Supporting documents（サポート書類）

実例は下記リンク先のOMG標準　DMN1.1日本語版を参照ください。

DMN1.1 日本語版

金融サービスのみならず、意思決定の自動化はDX環境において極めて重要になります。例えばIoTではデバイスからの多くの入力データの組合わせにより自動判定が必須です。温度変化に応じてドアなどの自動開閉。ジェットエンジンの使用時間・飛行時間により月間使用量の自動算出・自動請求．．．枚挙にいとまがありません。

日本では保険支払いの膨大な過去データをAIに覚えこませて、保険サービスの意思決定を自動化する試みが見受けられます。しかし、グローバルではEUのGDPR（一般データ保護規則）に代表されるように、自動化された意思決定に対し個人が説明を求める権利を認めています。ですから残念ながら説明能力が不十分なAIでは対応できないようです。いずれ日本でも個人情報保護の強化が必要になるかもしれません。

ビジネスルール管理とDMN（意思決定モデル）との違いは以下のとおりです。

DMN（意思決定モデル）は、「ビジネスルール管理」を超えて、「意思決定の全体像」をモデルとして扱える点が決定的に異なります。

ビジネスを意思決定の立場から考えようというアプローチがあります。

参考文献：意思決定マネジメントのマニフェスト（日本語版V1.5）

参考：意思決定の法律（政策）への適用の試み

BBC2020カンファレンスでのプレゼンの一部を紹介します。

グローバルではDecisionを法律（政策）にまで適用しようとする試みがあります。まだ完成されたわけではありませんが、そのチャレンジ精神には頭が下がる思いがします。

Newzealand政府の政策の自動実行への試みです。
発表者はGladys Lam（Business Rules Solutions, LLC） 氏

目指すところは政策（自動実行）の対話形式での開発です。

必要なことは法律（Governing Rules）をビジネスルールに変換し自動化ルールにまで落とし込むことです。
法律をビジネスルールに変換し、さらにそれを自動化ルールに変換するのです。

そのためには多くのステークホルダーの協力が欠かせません。
特に　法律作成者、ビジネスアナリスト、そしてソフトウェア開発者です。

RuleSpeakはビジネスアナリストによる、ルールの表記法です。
これをは政策（法律）をコンピュータ言語に変換する通訳の役割を果たします。

詳細はNewzealand政府発行のWebページをご覧ください。

https://www.digital.govt.nz/dmsdocument/95-better-rules-for-government-discovery-report/html

ブラウザがGoogle Chromeなら同時翻訳で日本語で読めますので、概要は理解できると思います。

従来からDXにおける業務プロセスの重要性について述べてきました。

• DXにおける業務プロセス変革（1）
• DXにおける業務プロセス変革（2）
• DXにおける業務プロセス変革（3）

今回は更に発展してDXにおけるビジネスルールの重要性について考えてみます。

業務とビジネスルールの関係

業務プロセスは、仕事の流れ（フロー）、ルール、情報（データ）の組合せからできていますが、業務からビジネスルールを切り離して管理する方法が注目されています。ビジネスルールの多くがプロセスの中に含まれているのです。

（図クリックで拡大表示）

上図は単純な承認ルールの例ですが、世の中の景気の変動により承認ルールを変えたくなりますよね。ルールの変更をシステムが対応するためには、その都度システムを止め、コードを変更し、テストし、動作チェックをする．．．時間がかかりますね。

VUCAの時代と言われているように外部環境の変化は最近よくあります。その都度システムのコードを修正するには多くの作業が必要です。外部環境の変化に対応しずらい（対応するのに時間がかかる）のは大きな問題です。最近の研究で明らかになってきたことは、頻繁に起こる外部環境の変化にはビジネスルールの変化で対応できることが意外と多いということです。

（図クリックで拡大表示）

上図のように、業務プロセスの中からビジネスルールだけを取り出し、別に管理するやり方をBRM（ビジネスルール管理）と言い、それを支援するのがBRMS（ビジネスルール管理システム）です。

従来から特定な業界（保険業界や通信業界など）ではBRMSが多く使用されてきました。考えてみると保険の約款はビジネスルールの塊です。ビジネスルールをしっかり管理する必要があります。また、携帯電話（スマホ）の料金プランもビジネスルールです。学割、家族割など、毎月のように新しいプランが提案されますが、請求プロセスなどは殆ど変わりません。ビジネスルールを変えているだけです。

このようにビジネスルールの変更のみで、魅力的な料金プランを提示することにより、スマホユーザーにキャリアの変更を促すことができ、キャリア会社の売上げに直接影響し企業利益に貢献することが可能になります。

つまりビジネスルールの変更⇒　顧客行動に直接影響し、売上・利益の向上に寄与

これが最重要です。

DXブームの一環で、プロセス（フロー）改善も重要で、BPM（ビジネスプロセス管理）や、それを支援するBPMS（ビジネスプロセス管理システム）も注目されています。しかし、プロセス改善は仕事の効率向上によるコスト改善に効果がありますが、売上の向上はあまり期待できないかもしれません。

スマホ料金プランのように、ルールの変更は魅力的なプラン（家族割など）を提示でき、顧客の行動に直接影響を与えることが期待できますから、効率より企業の売上げや利益への直接的な貢献が期待できます。

また、電気・ガス料金の自由化で従来別々の契約だったものを、ガス会社（電気会社）が電気料金（ガス料金）と合算して一括サービスを提供できるようになりました。電気・ガスを別々に契約することに比べ、一括サービスで魅力的な料金サービスを提供しています。提供会社の売上げ・利益の貢献のみならず、消費者の満足度向上にも大きく貢献しています。これもビジネスルールの果たす役割が極めて大きいものです。

ビジネスプロセス管理とビジネスルール管理の効果の違い：

• 　ビジネスプロセス管理：　業務効率の向上がメインで、コスト削減に寄与
• 　ビジネスルール管理：　　顧客行動に直接影響し、売上・利益の向上に寄与

ビジネスプロセスからビジネスルールを分離して管理することは、業務の柔軟性・一貫性・保守性を高めるという観点から、さまざまなメリットがあります。次の表はその代表的なものです。

特に変化の多い業界（例：保険・金融、通信、公共料金など）では、その利点がより顕著です。

DXにおけるビジネスルールの重要性

ビジネスルールは最近のDX環境において、変化の多い業界のみならず大きな意味があります。それはDXで重要なのは業務をデジタル化（もしくはデジタライズ）したのちに外部変化への対応能力を高めておくこと必要があるかからです。外部環境が変化するたびにデジタルシステムを作り直すのではなく、ビジネスルールのみを修正することで変化に柔軟に対応可能なデジタルシステムにしておくことがDX時代には不可欠になります。

そもそもDXとは「デジタルを活用して、企業が競争優位を獲得・維持するために、ビジネスモデル・業務プロセス・組織文化を継続的に変革していくこと」です。この変革の過程で、頻繁に変わる意思決定や業務判断が必要になります。

→ その中心にあるのが「ビジネスルール」と言えます。

DXにおけるビジネスルール管理の重要性（要点）は次のとおりです。

日本ではDXブームと言われていますが、AI、IoTなどデジタル技術に重点が置かれていてX（トランスフォーメーション）がなおざりにされているのは残念です。まして、ビジネスルールの重要性にまで気がついていないようなのが気がかりです。

DX時代のデジタルビジネスは、ある意味「コードよりもルールで動かす」ことが重要ではないでしょうか。ビジネスルールが外部化・再利用・可視化されることで、DXに必要な変革スピード・一貫性・説明力が確保されます。

ビジネスアナリストがビジネスルールの設計と管理に深く関与することで、ITと業務の橋渡しが実現します

次回はDXにおける意思決定マネジメントです。

ちょうど原稿を執筆中に、2月のRoger Burltonセミナーに参加されていた谷島氏が日経コンピューター誌の最新号で解説記事を書かれているので、そちらも参考にしてください。

• 日経コンピューター誌2025年5月1日号

先週は「ビジネス設計」フェーズの中の「ビジネス情報（ビジネスコンセプトモデル）」と「ビジネスプロセス」の関係を解説したところです。
今回は「ビジネスプロセス」と「ビジネス実行能力（ビジネスケイパビリティ）」の関係を解説します。

価値ストリームとケイパビリティの関係

Roger Burlton氏によれば、価値指向のプロセスアーキテクチャの最上位プロセス（PCFではプロセスカテゴリーと言います）は価値ストリームと等価ということです。

ここで最も重要なのはビジネスプロセスを価値志向でまとめることです。多くの組織内プロセスは個別の組織の作業を中心にまとめてあるのではないでしょうか。ですからそれを価値志向でプロセスで記述する必要がありそうです。

消費者向け銀行サービスの例です。価値志向のプロセス（レベル1と2）

• 消費者向け商品・サービスを作成する
  －商品・サービスのコンセプトを開発する
  －商品・サービスを作成する
  －商品・サービスを最適化する
• 消費者向けサービスを提供する
  －新規顧客獲得する
  －消費者ビジネスを取引する
  －リスクを軽減する
  －顧客関係を評価する

ケイパビリティマップはプロセスレベル3と関係します。

プロセスとケイパビリティの関係を図示したものが次の図です。

（図のクリックで拡大表示）

上図によれば、アカウント管理（ケイパビリティ）により、次のプロセスが実行されます。

• 信用度の決定（Make Credit decision）
• 消費者チャージを計算する
• 消費者アカウントを閉じる
• 消費者アカウントのステータスを報告する
• 消費者クレームを解決する

また、CRM（ケイパビリティ）により、次のプロセスが実行されます。

• サービスを合意する
• 消費者ビジネスを取引する
• リスクを低減する

逆に「サービスを合意する」プロセス（レベル3）は次のケイパビリティによって実行されます。

• リスク軽減（レベル3）
• CRM（レベル4）

プロセスとケイパビリティの間の多対多の関係を一般化すると次の図のようになります。

（図のクリックで拡大表示）

要は、価値志向でプロセスを記述しておけば、ケイパビリティにマッピングすることができ、そして両者は多対多の関係で相互にリンクされるということです。
ですから、プロセス表記（階層構造）に慣れているビジネスアナリストは不慣れなケイパビリティにとらわれることなく、プロセスの階層構造を活用すればビジネス・アーキテクチャとして十分使えるということになります。ただし留意するべきことはプロセスを価値志向でまとめておくということです。そうすると次の様な関係になります。

プロセスアーキテクチャ　⇒　ビジネスアーキテクチャ

• レベル0プロセス　　⇒　バリューチェーン
• レベル1プロセス　　⇒　バリューストリーム（価値ストリーム）
• レベル2プロセス　　⇒　バリューセグメント（価値セグメント）
• レベル3プロセス　　⇒　多対多の関係でケイパビリティにリンク

プロセスアーキテクチャでビジネス・アーキテクチャ（価値ストリームとケイパビリティ）を記述していることになります。

Roger Burltonのビジネスアーキテクチャ方法論（フレームワーク）について解説しています。
BIZBOK（知識体系）とは異なり、戦略（目的）から自然の流れでプロセスアーキテクチャを基に

バリューチェーン→バリューストリーム（価値ストリーム）→バリューセグメント（価値セグメント）→　ケイパビリティへとつながるので分かりやすいのではないでしょうか。

参考：Business Architecture Essentials: ‘Aligning your Capabilities, Processes and Business Information: Connecting the Dots’

• ビジネスコンセプトモデル
• ビジネスプロセスモデル
• ビジネスケイパビリティ
• ビジネス・パフォーマンス

今回は、ビジネスコンセプトモデルとビジネスプロセスモデルの関係について解説します。

ビジネスコンセプトモデルとビジネスプロセスモデルの関係

1. ビジネスコンセプトモデルとは？

ビジネスコンセプトモデル（Business Concept Model, BCM）は、ビジネスの主要な概念（エンティティ）とその関係性を表すモデル です。企業のビジネス領域を整理し、共通の言語を定義するために使われます。

例:

小売業のビジネスコンセプトモデルでは、以下のような概念と関係が定義されます。

• 顧客 は 注文 を行う
• 注文 は 商品 を含む
• 商品 は 在庫 により管理される

2. ビジネスプロセスモデルとは？

ビジネスプロセスモデル（Business Process Model, BPM）は、ビジネスの業務手順やフローを可視化したモデル です。業務の手順、役割、ルール、イベントの流れを明確にし、効率化や最適化を支援します。

例:

「オンライン注文プロセス」のビジネスプロセスモデルでは、以下のような流れが定義されます。

• 顧客 が 注文を行う
• システム が 在庫を確認 する
• 注文処理部門 が 注文を承認 する
• 倉庫 が 商品をピッキング する
• 配送 を手配する

 3. 両者の関係

ビジネスコンセプトモデルは、ビジネスプロセスモデルの基盤となります

ビジネスプロセスの中でやり取りされる情報やエンティティ（注文・商品・顧客など）は、コンセプトモデルに基づいて定義されます。
例えば、「注文を行う」というプロセスは、ビジネスコンセプトモデルの「注文」と「顧客」という概念を扱います。

ビジネスプロセスモデルは、コンセプトモデルの動的な側面を示します

コンセプトモデルが「静的なビジネス構造」を表すのに対し、プロセスモデルは「その構造がどのように動作するか」を示します。
例えば、「注文」は単なる概念ですが、プロセスモデルでは「注文を行う」「注文を承認する」「注文（商品）を出荷する」といった具体的なフローが描かれます。

一貫性が求められる

両者が整合性を持たないと、プロセスの中で定義されている「注文」と、コンセプトモデルの「注文」が異なる意味を持ってしまう可能性がある。そのため、 ビジネスアナリストは、コンセプトモデルとプロセスモデルを統合的に設計・管理することが重要 となるます。

4. 具体的な活用例

例えば、ECサイトの注文管理システムを設計する場合：

ビジネスコンセプトモデルを作成

「顧客」「注文」「商品」「在庫」「配送」などの関係性を整理します

ビジネスプロセスモデルを作成

「注文受付 → 在庫確認 → 決済処理 → 出荷準備 → 配送」 の流れを定義します

プロセスとコンセプトの整合性を確認

• 「注文」はどの段階で確定するか？
• 「在庫確認」のルールは？
• 「配送情報」はいつ確定するか？

まとめ

• ビジネスコンセプトモデル は、ビジネスの主要な概念と関係を整理します（構造的視点）。
• ビジネスプロセスモデル は、それらの概念がどのように業務の中で動くかを示します（動的視点）。
• 両者を統合的に考えることで、プロセスの設計が一貫性を持ち、業務の最適化がしやすくなります。

2月末に、Roger Burlton氏のビジネス・アーキテクチャ方法論のチュートリアルに参加しましたので、その概略を紹介します。

以前にビジネス・アーキテクチャ・ギルド（Business Architecture Guild）のビジネス・アーキテクチャ（BIZBOK）の解説を行いました。
http://kbmanagement.biz/?p=5979

この知識体系（BIZBOK）は独自の手法のため慣れていない読者（筆者も含めて）にはかなり分かりにくいモノではなかったでしょうか。今回紹介するRoger Burltonのビジネス・アーキテクチャは方法論/フレームワークで、4つの主要フェーズとそれぞれの中の4つのセクション（合計16セクション）が明確にあり、そのフェーズ中でバリューストリーム、ケイパビリティ、プロセスが定義されているので、感覚的にも分かりやすいものとなっています。

知識体系と方法論の違いを知ることは大切です。

4つの主要フェーズです。

1. ビジネスを定義する（Define the Business）
2. ビジネスを設計する（Design the Business）
3. ビジネスを構築する（Build the Business）
4. ビジネスを運営する（Operate the Business）

1．「ビジネスを定義する」フェーズでは次の4つのセクションがあります。

• ビジネスモデル
• ビジネスのエコシステム
• 戦略的目標（Strategic Objectives）
• 戦略的要求事項

「ビジネスのエコシステム」ではビジネスのマクロおよび外部環境を整理します。

Social, Tchnological,　Economic,Environmental, Poliitical ,Legalの頭文字をとったSTEEPL分析です。

また、外部の重要なステークホルダーも分析します。例えば、顧客、サプライヤ、株主、従業員、労働組合、規制者、コミュニティ、競合

2．「ビジネスを設計する」フェーズは次の4つのセクションです。

• ビジネスコンセプトモデル
• ビジネスプロセス
• ビジネスケイパビリティ
• ビジネス・パフォーマンス

まず、「ビジネスコンセプトモデル」はビジネスで扱うオブジェクト（概念データ）とその間の関係図です。重要な概念（概念的データモデルの元）を作成します。その情報モデルからビジネスプロセス、ビジネスルール、ビジネス・ケイパビリティ、パフォーマンスなどの元となります。

このへんが知識体系（BIZBOK）と大きく異なる点で、BIZBOKではいきなりケイパビリティモデルとは．．．となり分かりずらいのですが、この方法論（フレームワーク）では、コンセプトモデルからプロセスを導きそしてケイパビリティへブレークダウンしていきますので、納得感が得られやすいのではないでしょうか。特にプロセスに親しみのあるビジネスアナリストにとっては容易に理解が進むところです。

業務プロセス変革も最終回です。

今までは業界共通のPCFを紹介してきましたが、特定業界用のPCFがいくつか用意されています。

今回は特定業界のPCFとして「損害保険業界」用のPCFを紹介します。

13のすべてのカテゴリーが用意されているわけではなく、オペレーティングプロセスの一部だけが特定業界用として作成されていますい。バックオフィス系のカテゴリー（例えば、人事や経理関係）は業界共通PCFと共通です。

オペレーティングプロセスの「5.0サービスを提供する」カテゴリーが重要です。

[画像クリックで拡大表示]

特有なのはプロセスグループ「顧客に保険サービスを提供する」（レベル2）です

その下には3つのプロセス（レベル3）がありますが、ご覧のとおりまさに保険業務そのもののプロセスです。

• 5.1.1 保険契約を管理・運営する
• 5.1.2 保険金請求を管理・運営する
• 5.1.3 保険契約および保険金請求情報の記録を管理する

[画像クリックで拡大表示]

レベル3「5.1.1 保険契約を管理・運営する」プロセスの下には以下の7つのアクティビティがあります。

• 5.1.1.1 取引の受領とチャネルの管理
• 5.1.1.2 新規契約の引受け
• 5.1.1.3 特約条項の処理
• 5.1.1.4 保険契約の解約
• 5.1.1.5 保険契約の復活
• 5.1.1.6 契約の更新
• 5.1.1.7 契約条項の発行

同様に、レベル3「5.1.2 保険金請求を管理・運営する」プロセスの下には７つのアクティビティが、「5.1.3 保険契約および保険金請求情報の記録を管理する」プロセスの下には3つのアクティビティがあります。

例えば、アクティビテイ「5.1.1.2 新規契約の引受け」の下にはさらに次の9つのタスクがあります。

[画像クリックで拡大表示]

• 5.1.1.2.1　契約者ポートフォリオの審査
• 5.1.1.2.2　引受開始および必要データの収集
• 5.1.1.2.3　必要データの評価
• 5.1.1.2.4　不足情報の請求
• 5.1.1.2.5　新契約の料率を設定する
• 5.1.1.2.6　保険料を発行する
• 5.1.1.2.7　再保険の要件を評価する
• 5.1.1.2.8　新契約を認可する
• 5.1.1.2.9　顧客に通知する

このようにプロセス、アクティビテイ、タスクがしっかり定義されていて、その数は以下の通りです。

• レベル3プロセス：　　　　3個
• レベル4アクティビテイ：　17個
• レベル5タスク：　　　　　71個

ここまで参照モデルが用意されているのには驚きますね。どの保険会社でも上記タスクは存在するはずです。 重要なことはこの階層構造がタスク（レベル5）まで標準化されていることです。

これだけの参照モデルがあると、保険業務のヌケや漏れを防ぐことができますし、組織全体の業務の可視化、標準化が容易に可能になりますね。

それのみならず、事業再編が頻繁な保険業界ではこのような業務参照モデルが果たす役割は大きいものがあります。同じ参照モデルを使用していれば、業務プロセスの統合は短期間で済みます。バックオフィス系の業務のみならず、オペレーティングプロセスでさえ、顧客対応を変更することなく、もとは異なる2つの保険会社が新しいサービスへとスムーズに移行することも難しくありません。
さらに、日本の損保企業が海外市場に進出する際、現地法人の業務と比較・統合しやすくなるため、国際展開の推進にも役立ちそうです。

ただし、PCFはグローバル基準で作成されているため、日本の損保業界の独自の規制（例：金融庁の監督指針、保険業法、顧客対応義務など）などは考慮されていないことに注意する必要があります。

3回連続でAPQC（American Productivity and Quality Center）のPCF（Process Classification Framework）を解説いたしました。

ご意見、感想をいただければ幸いです。

 実際の具体例（プロセス可視化の第一ステップ）

 例：グローバルに展開する販売プロセスの一元化。

PCFを使用して組織の全プロセスを洗い出し、全体像をマッピングすることができます。

たとえば、顧客サービスの管理プロセスをPCFの「6.0顧客サービスを管理する」カテゴリーに基づいて整理します。

グローバルの各部門が異なる顧客管理手法（CRM）で運用している場合、PCFを基準にプロセス定義を統一できます。

使用するのは前述の「6.0顧客サービスを管理する」カテゴリーです。

［画像クリックで拡大表示］

「6.3販売後に製品サービスを提供する」プロセスグループの下には次の4つのプロセスがあります。

• 6.3.1　製品を登録する
• 6.3.2　保証請求を処理する
• 6.3.3　サプライヤー責任の費用回収を管理する
• 6.3.4　製品サービスを提供する

さらに「6.3.4製品サービスを提供する」プロセスの下には次の4つのアクティビティがあります。

• 6.3.4.1　個々の顧客の特定のサービス要件を確認する
• 6.3.4.2　サービス要件を満たすためのリソースを特定してスケジュールする
• 6.3.4.3　サービスオーダーフルフィルメントを管理する
• 6.3.4.4　サービス品質を確保する

 「6.3.4.4　サービス品質を確保する」アクティビティの下には更に次の4つのタスクがあります。

• 6.3.4.4.1　フィードバックのために完了したサービス注文を特定する
• 6.3.4.4.2　不完全なサービス注文とサービス障害を特定する
• 6.3.4.4.3　提供されたサービスに関する顧客のフィードバックを求める
• 6.3.4.4.4　提供されたサービスに関する顧客のフィードバックを処理する

このようにアクティビティ（レベル4）からタスク（レベル5）レベルまで標準化することが可能です。

国ごとにばらばらに顧客サービスを管理していると国ごとに異なるCRMを導入してコストが膨大になりますが、上記のように顧客サービスのプロセスを標準化しておけばグローバルに共通のCRMを導入することができ、コストメリットが大きくなります。