「ビジョナリーカンパニー」という本に書かれている経営原則の一つに、「時を告げるのではなく、時計をつくる」というものがあります。
その本の中で、著者ジム・コリンズは、ビジョナリーカンパニー、つまり、私達が暮らす社会に消えることのない足跡を残した卓越した会社では、往往にして、カリスマ性のある偉大な指導者が時代に合った経営戦略を立てて社員を先導する（時を告げる）のではなく、謙虚で控え目な経営者が、時代に応じて自ら変化、改善する組織（仕組）を構築している（時計をつくる）、その作業は、まるで建築家（アーキテクト）の仕事のようだと言っています。
建物の建築様式のことをアーキテクチャといいますが、この本を読むと、ビジネスにもアーキテクチャ、つまり、ビジネスアーキテクチャがあり、それを設計、構築することは、経営者にとって大変重要な仕事であるということがわかります。
下図は、ビジネスを、縦軸を構成要素（目的・資産・場所・機能・活動）、横軸をレイヤ構造にして分けた図です。
これをビジネスストラクチャマトリクスと呼びます。
ここでは、ビジネスを分析（分解×分類）し、ビジネスプロセス単位で統合するする方法について次の順で解説します。
ビジネスの分解
ビジネスストラクチャマトリクスは、ビジネスを、５W１H、目的・資産・場所・機能・活動に関する構成要素で分解しています。
ここでは、資産を、価値を生み出すもの、ビジネスでいうと利益獲得能力（稼ぐ力）を持つ人、もの、金、情報、つまり、人的資産、知的資産、財務資産、情報資産としてとらえており、顧客、製品、メンバー、パートナー、アプリケーション、データ、IT基盤、財務資産に分解しています。
そして場所、機能、機能をいつどういう順番で実行するのかを示すのが活動になります。
なぜ、誰に、何の価値を、誰が何を使って、どこで、いつどのように提供するのかというように、事業パーパスを起点にビジネスを組み立てることによってパーパスベース経営を実現することができます。
ビジネスの分類
記事変化に強いシステムを創るで、ビジネスや情報システムを抽象レベルによってレイヤ化し、変化しにくい本質の部分と、変化しやすい現象の部分を分けることで、環境が変化した場合、変化する部分だけ置き換えることができるようになり、環境の変化に柔軟に適応できるようになると説明しました。
ビジネスの場合、レイヤ構造の概念レベル、論理レベル、物理レベルを、型（タイプ）、種類（カテゴリ）、実例（インスタンス）というように階層化します。
概念レベルの型（タイプ）が最も本質的な概念で、論理レベルの種類（カテゴリ）は、その部分集合になります。
述語論理でいう集合の条件で分類（カテゴライズ）するわけです。
ビジネスであればビジネスの型は、ビジネスを分類する（戦略の）ためのビジネス要件（顧客の価値観や製品が提供すべき価値、データの品質要件やセキュリティ要件など）を規定することになります。
そして、実例（インスタンス）は、集合に所属する実体、つまり、集合に属する要素を表します。
なので、型（タイプ）は、分類基準や評価指標などの属性や機能（集合の条件）を持ち、実例（インスタンス）は、その値を持ちます。
型（タイプ）の違いは、それが持っている分類基準などの属性や機能の違いであり、種類（カテゴリ）の違いは型の分類基準の値の違いになります。
例えば、顧客の場合、型を法人顧客にすると、種類は、それを業種、企業規模、エリアで分類した市場セグメントになり、実例は、その市場セグメントに属する個別の会社になります。この場合、論理レベルでは、業種が製造業で、企業規模が大規模、エリアが関東地方（集合の条件）に属する法人顧客という部分集合をつくっています。
また、製品の場合、型を衣類にすると、種類は、それを色、サイズ、デザインで分類した製品アイテムになり、実例は、そのアイテムに属する個別の製品になります。この場合、論理レベルでは、色が青で、サイズがM、あるデザイン（集合の条件）に属する衣類という部分集合をつくっています。
ここでは、概念である型を考える活動を設計、型を論理的に分類する活動を戦略、戦略に従って実例を構築、あるいは、取得し、それを運用する活動を実現（構築、運用）と呼びます。
上記例でいうと、論理レベルで、業種が製造業で、企業規模が大規模、エリアが関東地方という集合を考えることは、資源を集中すべきセグメントを考えること、つまり「戦略」を考えることになるからです。
マーケティング戦略の変更により市場セグメントは変わり、顧客層も変化しますが、法人顧客がビジネスに求める本質的な価値観は不変です。
この図は、設計、戦略、実現（構築・運用）の関係を表しています。
設計することでできるビジネスの型がビジネスモデル、
ビジネスモデルを分類することで特定の種類に限定されたものが事業戦略
事業戦略に基づいて構築されたものがビジネスシステム
になります。
ビジネスシステムは、資産や場所の実例を構築、取得し、機能や活動を実現したものです。
UMLで表すと、ビジネスモデルと事業戦略の間が汎化関係になっており、事業戦略とビジネスシステムの間が多対多の関連になっています。
ビジネスシステム（クラス）のオブジェクトである、ビジネスの構成要素の実例は、事業戦略（クラス）のオブジェクトである、ビジネスモデルの種類に対応します。
ある事業戦略のオブジェクトには、複数のビジネスシステムのオブジェクトが対応し、あるビジネスシステムのオブジェクトは、複数の事業戦略のオブジェクトに対応します。
なので、種類は、型のサブクラスであり、実例のメタクラスになり、実例から種類の思考過程は抽象化、種類から型への思考過程は一般化ということになります。
また、ビジネスモデルの存在意義がパーパスで、事業戦略が目指すべきところがビジョンになり、ビジネスシステムはビジョンの一里塚であるゴールを達成するために運用されます。
ビジネスモデルを包含するビジネスの単位が事業ドメインで、事業ドメインを事業戦略によって分類した単位が事業単位（Business Unit：BU）、事業単位の実例がプロジェクト、あるいは、プログラムになります。
事業ドメインは、顧客タイプ×製品タイプ（誰に何の価値を提供するか）で決まり、事業単位は、顧客カテゴリ×製品カテゴリ（誰に何の価値を提供するか）で決まります。
プロジェクトは、ビジネスシステムを構築する場合など、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務です。
一方、プログラムは、会計期間ごとに繰り返される通常業務や、継続的な運用管理、あるいは改善活動です。
事業ドメインには、事業戦略の型である戦略マップを定義します。
事業単位には、戦略マップに対するバランススコアカード（BSC）の目標と実績を設定します。
プロジェクトやプログラムには、そこで測りたい、BSCの重要業績評価指標（KPI）の目標と実績を設定します。
ビジネスの分析（分解×分類）
部門やアクションプランなど戦略レベルのから、もっとも本質的なビジネスの型（ビジネスモデル）を考えることによって、ビジネスをメタ認知することができます。
戦略を変えることで、アクションプランや組織は変わりますが、本質的なビジネスモデルは不変です。
また、戦略は同じでも、戦術の見直しによって、それを実現している個々の実体を変えることは頻繁にあると思います。
このように、不変的な部分と変動する部分を分けて可視化することによって、環境の変化によって変えるべき部分が明確になり、より柔軟に適応することができるようになります。
それでは、各構成要素を型から種類、実例に展開していきましょう。
顧客
顧客は、顧客タイプ、顧客カテゴリ、顧客に展開されます。
顧客タイプ
顧客タイプは、顧客の本質的な型で、顧客の価値観（心身の欲求を満たす性質）を定義したものになります。
顧客の価値観が顧客価値です。
また、顧客タイプには、顧客タイプを分類するときの分類基準（業種、規模、エリアなど）および分類基準値と、顧客価値を測るための評価指標を測定方法と評価基準を含めて定義します。
顧客価値を測るための評価指標は、BSCにおける顧客の視点のKPIになります。
顧客カテゴリ
顧客タイプに定義された分類基準の分類基準値（業種の値、規模の値、エリアの値など）によって分類されたものが顧客カテゴリになります。
顧客カテゴリは、事業戦略の一つマーケティング戦略によって策定される市場セグメントを表します。
顧客
顧客カテゴリに属する個々の顧客の実例です。
顧客は、顧客番号などの識別子で識別されます。
製品
製品は、製品タイプ、製品カテゴリ、製品に展開されます。
製品タイプ
製品タイプは、製品の本質的な型で、顧客の価値観に対する価値提案（顧客にどのような価値を提供するか）を定義したものになります。
顧客の価値観を満たす価値が製品価値です。
また、製品タイプには、製品タイプを分類するときの分類基準（色、サイズ、デザインなど）および分類基準値と、製品価値を測るための評価指標を測定方法と評価基準を含めて定義します。
製品価値を測るための評価指標は、BSCのKPIになります。
製品カテゴリ
製品タイプに定義された分類基準の分類基準値（色の値、サイズの値、デザインの値など）によって分類されたものが製品カテゴリになります。
製品カテゴリは、事業戦略の一つマーケティング戦略（製品のポジショニング）によって策定される製品のポジションを表します。
製品
製品カテゴリに属する個々の製品の実例です。
製品は、製造番号（シリアル番号）などの識別子で識別されます。
メンバー
ビジネスの構成員であるメンバーは、メンバータイプ、メンバーカテゴリ、メンバーに展開されます。
メンバータイプ
メンバータイプは、メンバーの本質的な型で、メンバーのモチベーションを上げる価値観を定義したものになります。
メンバーの価値観がメンバー価値です。
メンバー価値は、企業が望むメンバーの価値観です。
また、メンバータイプには、メンバータイプを分類するときの分類基準（雇用形態、職務、職能、職位など）および分類基準値と、メンバー価値を測るための評価指標を測定方法と評価基準を含めて定義します。
メンバー価値を測るための評価指標は、メンバーのエンゲージメントを表すBSCのKPIになります。
メンバーカテゴリ
メンバータイプに定義された分類基準の分類基準値（雇用形態の値、職務の値、職能の値、職位の値など）によって分類されたものがメンバーカテゴリになります。
メンバーカテゴリは、事業戦略の一つ人事戦略によって策定される等級などメンバーのセグメントを表します。
メンバー
メンバーカテゴリに属する個々のメンバーの実例です。
メンバーは、社員番号などの識別子で識別されます。
パートナー
協業他社であるパートナーは、パートナータイプ、パートナーカテゴリ、パートナーに展開されます。
パートナータイプ
パートナータイプは、パートナーの本質的な型で、パートナーのモチベーションを上げる価値観を定義したものになります。
パートナーの価値観がパートナー価値です。
パートナー価値は、企業が望むパートナーの価値観です。
また、パートナータイプには、パートナータイプを分類するときの分類基準（取引先区分、評価ポイントなど）および分類基準値と、パートナー価値を測るための評価指標を測定方法と評価基準を含めて定義します。
パートナー価値を測るための評価指標は、BSCのKPIになります。
パートナーカテゴリ
パートナータイプに定義された分類基準の分類基準値（取引先区分の値、評価ポイントの値など）によって分類されたものがパートナーカテゴリになります。
パートナーカテゴリは、事業戦略の一つマーケティング戦略（チャネル戦略）によって策定されるチャネルにも対応します。
パートナー
パートナーカテゴリに属する個々のパートナーの実例です。
パートナーは、取引先番号などの識別子で識別されます。
アプリケーション
アプリケーションは、アプリケーションタイプ、アプリケーションカテゴリ、アプリケーションに展開されます。
アプリケーションタイプ
アプリケーションタイプは、概念レベルのアプリケーションで、アプリケーションタイプを分類するときの分類基準および分類基準値を定義します。
アプリケーションタイプには、アプリケーションタスクを定義します。
また、アプリケーションタイプには、機能適合性や保守性などアプリケーションの品質を測るアプリケーション指標を測定方法と評価基準を含めて定義します。
アプリケーション指標は、BSCのKPIになります。
アプリケーションタスクは、アプリケーションの機能要件を表し、アプリケーション評価指標は、アプリケーションの非機能要件を表します。
なので、アプリケーションタスクには、それを実施する際のガイドライン（行動指針）としてアプリケーション評価指標の基準値や標準的なやり方（ユースケースシナリオなど）を設定します。
アプリケーションタイプは、業務の機能であるジョブを支援するツールと考え、ジョブに対応して定義します。
なので、各アプリケーションタイプは、業務で実現すべき最小の機能を備えた単位であり、それを実装することでマイクロサービスになります。
次の図は、企業のアプリケーションタイプを一覧化した例です。
個々アプリケーションで管理すべきデータタイプも定義されています。
アプリケーションカテゴリ
アプリケーションカテゴリは、論理レベルのアプリケーションで、アプリケーションタイプを製品単位に分類したものです。
また、アプリケーションカテゴリは、例えば、トランザクション処理アプリケーション、分析アプリケーション、変革アプリケーションのようにアプリケーションタイプで定義した分類基準の分類基準値で分類することができます。
アプリケーションカテゴリには、アプリケーション機能を定義します。
次の図は、上図のアプリケーションタイプを製品単位に分類したをアプリケーションカテゴリを表した例です。
アプリケーション
アプリケーションは、アプリケーションカテゴリに属する物理レベルのアプリケーションです。
物理レベルのアプリケーションとは、アプリケーションの実行ファイルです。
データ
データは、データタイプ、データカテゴリ、データに展開されます。
データタイプ
データタイプは、概念レベルのデータで、データタイプを分類するときの分類基準および分類基準値を定義します。
データタイプには、データの属性を定義します。
また、データタイプには、データの品質やセキュリティを測るデータ評価指標を測定方法と評価基準を含めて定義します。
データ評価指標は、BSCのKPIになります。
データタイプを構造化すると概念データモデルになります。
次の図は、UMLのクラス図で記述した概念データモデルの例です。
データカテゴリ
データカテゴリは、データタイプをデータモデリングスキーム（データの表現形式）によって分類した論理レベルのデータです。
データカテゴリには、データ項目を定義します。
また、データカテゴリは、例えば、構造化データ、半構造化データ、非構造化データのようにデータタイプで定義した分類基準の分類基準値で分類することができます。
データカテゴリを構造化すると論理データモデルになります。
次の図は、ER図で記述したリレーショナルスキームの論理データモデルの例です。
データ
データは、物理レベルのデータで、リレーショナルデータベースであればテーブル、および、テーブルのデータセットになります。
IT
ITは、ITタイプ、ITカテゴリ、ITに展開されます。
ITタイプ
ITタイプは、概念レベルのITで、ITタイプを分類するときの分類基準および分類基準値を定義します。
ITタイプには、ITの可用性やキャパシティなどITの品質を測るIT評価指標を測定方法と評価基準を含めて定義します。
IT評価指標は、BSCのKPIになります。
ITカテゴリ
ITカテゴリは、論理レベルのITで、ITタイプを製品単位に分類したものになります。
また、ITカテゴリは、IT基盤、コミュニケーション基盤、アプリケーション基盤、データ管理基盤、BPM基盤のようにITタイプで定義した分類基準の分類基準値で分類することができます。
IT
ITは、ITカテゴリに属する物理レベルのITです。
物理レベルのITは、製造番号（シリアル番号）で識別されます。
財務資産
財務資産は、設備や建物で、財務資産タイプ、財務資産カテゴリ、財務資産に展開されます。
財務資産タイプ
財務資産タイプは、概念レベルの財務資産で、財務資産タイプを分類するときの分類基準および分類基準値を定義します。
財務資産タイプには、財務資産の品質を測る財務資産評価指標を測定方法と評価基準を含めて定義します。
財務資産評価指標は、BSCのKPIになります。
財務資産カテゴリ
財務資産カテゴリは、論理レベルの財務資産で、財務資産タイプを製品単位に分類したものになります。
また、財務資産カテゴリは、財務資産タイプで定義した分類基準の分類基準値で分類することができます。
財務資産
財務資産は、財務資産カテゴリに属する物理レベルの財務資産です。
物理レベルの財務資産は、製造番号（シリアル番号）で識別されます。
場所
場所は、場所タイプ、場所カテゴリ、拠点に展開されます。
場所タイプ
場所タイプは、場所の本質的な型で、場所タイプを分類するときの分類基準および分類基準値を定義します。
場所カテゴリ
場所タイプに定義された分類基準の分類基準値によって分類されたものが場所カテゴリになります。
拠点
場所カテゴリに属する、位置情報を持つ個々の物理的な地点です。
機能
ビジネスの機能は、ジョブ、部門、プロジェクトあるいはプログラムに展開されます。
ジョブ
ジョブ（職務）は、事業ドメインに定義される、仕事の内容や役割を表す業務機能の型になります。
ジョブには、課業であるタスクを定義します。
また、ジョブには、業績、能力（スキル）、特性（コンピテンシー）を測る職務指標を測定方法と評価基準を含めて定義します。
例えば、ジョブが「販売管理者」であれば、「新規顧客獲得数」「新規顧客アプローチ数」「契約率」など業績を測る職務指標を考えることができます。
職務指標は、BSCのKPIになります。
また、タスクには、それを実施する際のガイドライン（行動指針）として職務評価指標の基準値や標準的なやり方を設定します。
例えば、「販売契約の締結」タスクのガイドラインに「契約率90%」などの基準を設定します。
部門
ジョブを市場×製品、つまり、事業単位別に分類したものが部門になります。
部門には、タスクを分類したアクションを定義します。
部門には、メンバーを割り当てます。
また、部門はジョブの評価指標に対する目標と実績を管理します。
ワーカー
ワーカーは、部門の実例で、部門に割り当てられたメンバーをプロジェクト、ありは、プログラムに割当てることで生成されます。
ワーカーには、アクションの実例であるワークを定義します。
ワーカーはジョブの評価指標に対するメンバーの目標と実績を管理します。
活動
ビジネスの活動は、ビジネスプロセス、アクションプラン、ワークフローに展開されます。
ビジネスプロセス
ビジネスプロセスは、それを構成する活動が資産を消費することで、ステークホルダーに価値を生み出し、結果的に資産の状態を変化（増減）させる組織横断的な単位です。
ビジネスプロセスは、事業ドメインに定義され、ジョブのタスクの順番によって構成されます。
ビジネスプロセスは、バリューチェーンを構成する活動領域に分類されます。
ビジネスプロセスには、「部品発注リードタイム」などの業務評価指標を定義します。
アクションプラン
ビジネスプロセスを戦略別に展開したものがアクションプランです。
アクションプランは、部門のアクションの順番によって構成されます。
アクションプランは、BSCのKPI目標を実現するための実行計画で、KPI目標が達成されるべき期日が設定されます。
アクションプランを構成する各アクションの開始日、終了日を設定したものがスケジュールです。
アクションプランは、マネジメントサイクル（Plan-Do-Check-Actサイクル）を通して実行されます。
ワークフロー
プロジェクトやプログラムにおいて、アクションプランが実行される単位がワークフローです。
ワークフローは、アクションの実例であるワークの順番によって構成されます。
ビジネスの統合
これまで、ビジネスを分解×分類という視点で要素単位に分けてきました。
ここでは、ビジネスを構成する要素を統合するときの考え方と方法について次の観点で説明します。
ビジネスプロセス統合
次の図は、戦略マップを簡略化した図です。
戦略マップは、学習と成長の視点の人、情報、組織という無形資産が、内部プロセスの視点の、価値を生み出す活動、バリューチェーンをを実行することで、顧客価値を提供し、収益を上げるとともに、生産性を高め、最終的に企業価値を創出する、その企業価値を、人、情報、組織という無形資産に投資、フィードバックすることで、それらが学習し成長し、ますます価値を生み出すという価値創出のプロセスです。
戦略マップの人的資本は、ビジネスを構成する要素のジョブを表し、情報資本は、アプリケーションタイプ、データタイプ、ITタイプを表し、組織資本はメンバータイプやパートナータイプを表します。
なので、戦略マップでは、ビジネスを構成する要素である資産（価値産出能力）を、内部プロセスの視点のビジネスプロセスに結びつけることで企業価値が創出されると考えています。
マイケル・ポーターは、著書「競争の戦略」の中で、
戦略の本質は、活動の中にある。活動を他社とは異なるように遂行するのか、あるいは、ライバルとは異なる活動を遂行するのかの選択である。
と記述し、活動を競争優位を得るための基本的な単位としています。
ここでは、ビジネスを構成する資産（価値産出能力）をビジネスプロセス単位に統合することで企業価値を生み出すことができると考え、その方法について説明したいと思います。
ビジネスのモジュール化
ビジネスプロセスは、それを構成する活動が資産を消費することで、ステークホルダーに価値を生み出し、結果的に資産の状態を変化（増減）させる組織横断的な単位です。
ここでいいう組織は、業務機能の単位であるジョブを表します。
「強いシステムを創る」という記事で、システムをモジュール化するによって、その生産性と保守性が高まり、変化に強いシステムを創ることができると説明しました。
モジュール化とは、ビジネスや情報システムの構成要素を、インターフェース（仕様）と実装（実現）部分に分離し、相手の要素にはインターフェースだけを公開し、実装（実現）部分はブラックボックにすることです。
これによって、相手の要素にはインターフェースだけにアクセスできるようになり、実装（実現）部分を変更しても影響を受けることはありません。
なので、実装部分が自由に交換でき、保守性が向上するとともに、モジュールを再利用することによって生産性が向上します。
ビジネスの場合、インターフェース（仕様）になるのが機能であるジョブ、それを実現するのがメンバーやアプリなどの資産になります。
ビジネスプロセスは、インターフェース（仕様）であるジョブのタスクが、それを実現する資産の価値を消費することで、ステークホルダーに対する価値を創出します。
そこで、まず、ビジネスプロセスをジョブがどう実行するか明確にし（仕様の明確化）、それから、そのジョブを何の資産が実現するのか明確にする（実現の明確化）、つまり仕様と実現を分離して考えることで、ビジネスの生産性や保守性を向上させ、ビジネスを、環境の変化により柔軟に適応できる「変化に強い構造」にすることを考えます。
具体的な例で見ていきましょう。
電力、ガス、水道などを提供する公益事業を行うユーティリティ業界の例を考えます。
バリューチェーンを「価値を創る活動」「価値を伝える活動」「価値を届ける活動」に分けた場合、ユーティリティ業界の場合、「価値を創る活動」のビジネスプロセスとして「新しい設備の開発」、「価値を伝える活動」のビジネスプロセスとして「マーケティング」や「顧客関係管理」、「価値を届ける活動」のビジネスプロセスとして「設備の構築」「設備の保全」「設備の除却」を考えることができます。
このうち「設備の保全」プロセスの一種に「定期点検」があります。
下図は、「定期点検」の業務フローをUMLのアクティビティ図で記述した例です。
この業務フローのパーティションはジョブ、各アクティビティ（活動）はジョブのタスクを表しています。
この「定期点検」プロセスを、UMLのクラス図を使って、ビジネスを構成する要素同士の相互関係で記述すると次の図のようになります。
このビジネス構造は、業務機能の仕様であるジョブの関係を表しているので環境変化によらない不変的は構造を表しています。
例えば、現行、点検担当者というジョブを、人的資産であるメンバーが実現している場合、次の図のように表すことができます。
なお、設備管理者と点検担当者は、アプリケーションをインターフェースにしてやりとりしているとします。
次に、この会社では、「設備保全の効率化」という戦略目標を設定したとします。
そこで、これまで人がやっていた定期点検作業を機械がすることで、作業の精度と効率をアップするビジネス構造にしたいと考え、次のようなモデルを設計しました。
これまで人間がやっていたい定期点検はドローンが行い、点検の報告は生成AIが行うという仕組です。
これを見ると、業務機能の仕様であるジョブを実現する資産が人的資産から財務資産（ドローン）や情報資産（生成AI）に変わっていることがわかります。
このとき点検担当者に作業を依頼する設備管理者は、アプリケーションをインターフェースにしているので、相手が人であろうが機械であろうが意識する必要はありません。
つまり、ビジネスをモジュール化することで、柔軟に手段を変えて、「設備保全の効率化」という戦略目標を実現しているわけです。
このように、ビジネスを構成する資産（価値産出能力）をビジネスプロセス単位に統合するとき、仕様と実現を分離して考える、つまり構成要素をモジュール化して考えることで、ビジネスを、環境の変化により柔軟に適応できる「変化に強い構造」にすることができます。
ビジネスプロセス統合のアプローチ
それでは、最後に、ビジネスを構成する資産（価値産出能力）をビジネスプロセス単位に統合する手順について見ていきましょう。
次の順で勧めます。
ビジネスプロセスの洗い出し
まず、企業のビジネスプロセスを洗い出します。
下図は、企業のビジネスプロセスを洗い出した例です。
この中で、戦略マップの内部プロセスの視点にある戦略的なビジネスプロセスを優先的に考えます。
業務フローの可視化
次に、各ビジネスプロセス単位にジョブのタスクの順番を記述した業務フローを作成します。
ジョブのタスクの順番によって業務フローを記述することでビジネスプロセスの仕様（何をするのか）を定義することができます。
下図は、上記ビジネスプロセスの「製品の出荷」プロセスの業務フローを表した例です。
資産のビジネスプロセス統合
最後に、業務フローの各ジョブのタスクをどの資産が実現するか、つまり、ビジネスプロセスの実現方法（どのようにするのか）を考えることで、ビジネスを構成する資産をビジネスプロセス単位に統合します。
例えば、「製品の出荷」プロセスの「製品の出荷」と「製品の出庫」の部分を考えると、次のようなジョブの構成になります。
これらのジョブを、メンバーとアプリケーションで実現すると次のようになります。
出荷担当者が出荷管理システムに対して出荷指示をすると、出荷管理システムから出荷指示データが在庫管理システムに送られることで在庫管理者が在庫管理システムから出庫指示を受けて、製品を出庫するという流れです。
また、下図のように、出荷予定日になると、出荷管理システムから自動的に出荷指示データが在庫管理システムに送られるようにすることで、出荷指示の精度と効率を上げる仕組にすることもできます。
ビジネスを仕組化できると、出荷管理システムと在庫管理システムの連携方式をどう考えるか、出荷管理システムと在庫管理システムのデータ構造をどう考えるかなどアプリケーションアーキテクチャやデータアーキテクチャを検討することができます。
下図は、出荷管理システムと在庫管理システムの連携をAPIを介した同期通信で行うリアルタイム連携の例と、メッセージングによる非同期通信で行うイベント駆動連携の例です。
ちなみに、トランザクション整合性を保持する必要があるなどデータ連携の即時性が求められない場合、イベント駆動による非同期通信によって連携するほうが、ソースシステムがターゲットシステムの状態を意識しないで処理を進めることができるので、システム間を疎結合にすることができます。
次に、下図は出荷管理システムの概念データモデルを表した図です。
このビジネスでは、受注明細の製品を複数回に分けて出荷する分納も、複数の受注明細の製品を一回で納入する一括納入も行っているということがわかります。
このように、システム開発を、個々のシステムにフォーカスして局所的に進めるのではなく、ビジネスの仕組をどう実現するかというビジネス全体の観点、つまり、エンタープライズアーキテクチャの観点で進めることで、事業戦略を実現し企業価値を高めるシステムを開発することができます。
関連動画
ビジネスの仕組化①
ビジネスの仕組化②
以上、今回は、ビジネスの仕組化について解説しました。
[…] 設計フェーズは、ビジネスストラクチャマトリクスの「ビジネスモデ&# […]
[…] ;クチャマトリクスビジネスストラクチャマトリクスでいうと次の図の& […]