ここでは、架空の会社、左川産業株式会社を例に、デザイン思考経営をベースとしたDXをどう進めるのか、DX成熟度ごとのフェーズに分けて説明します。
なお、ここでは、DXを、
企業を
データやデジタル技術を活用することで
環境の変化に応じて迅速に事業を変革・創出し
顧客を中心としたステークホルダーに価値を提供し続ける
体質にすること
と定義しています。
【左川産業株式会社の概要】
左川産業は、製造業者向けに産業機械を製造、販売する会社です。
仕入先から部品を購買し、産業機械を製造して顧客に販売します。
現在、産業機械の保守は、全国にある保守サービス会社が代行しています。
DXのコンセプト
これは、DX1からDX5で何を実現するのか、企業情報基盤、マネジメント基盤、データドリブン経営に分けてまとめた表です。
これをDXマトリクスと呼びます。
ここでは、具体的な説明をする前に、まず、DXをなぜ次の順で進めるのか、それぞれの段階で何をするのか、そのコンセプトについて説明します。
まず、この順番の考え方ですが、大きく5つあります。
- DX成熟度
一つは、先程述べたDX成熟度です。
DX成熟度は次のようにレベルアップします。- まずやってみる
- 最低２回繰り返す
- プロセスとプロダクトを標準化する
- プロセスとプロダクトを管理する
- プロセスとプロダクトを継続的に改善する
- デザイン思考経営におけるDXのアプローチ
次に、「デザイン思考経営におけるDXのアプローチ」で示している- トップダウン
- アジャイル
- スモールスタート
です。
- DXまでの３つの段階
次に、経済産業省が「DXレポート２」で示しているDXまでの３つの段階です。
なので、DX成熟度、および、DXアプローチのスモールスタートを考慮して、デジタイゼーション→デジタライゼーション→デジタルフォーメーションという順で進めます。 - DXで取り組むべき３つの分野
次に、経済産業省が「DX調査2020」で示しているDXで取り組むべき３つの分野です。
DX4の革新的な生産性向上とDX5の創造と変革は、この３つの分野を表しています。 - DXによって企業が目指すべき姿・DX戦略マップ
最後が、「DX（体質変換）によって企業が目指すべき姿」、および、DX戦略マップです。- 仮説検証の仕組
- 変化に強い構造
- 価値創造の企業文化
デジタイゼーションとデジタライゼーションの後、すぐに、デジタルトランスフォーメーションに進むのではなく、まず、企業全体の企業情報基盤（プロダクト）とマネジメント基盤（プロセス）を標準化し、DX成熟度をレベル３にし、マネジメントが統制できるレベルにします。
次に、本各的に、デジタルフォーメーションを進めるのですが、まず、企業の業務とシステムを変化に強い構造にするとともに、価値創造の企業文化を醸成し、革新的に生産性を上げた上で、データドリブン経営による仮説検証の仕組によって事業創出と事業変革を実現します。
DX1：デジタイゼーション
まず、紙のデータをデジタルデータ化するデジタイゼーションを実現します。
ただし、DXアプローチのトップダウンアプローチに従って、最初に、企業全体の仕組（エンタープライズアーキテクチャ）を事業、業務、システム、戦略の観点で広く浅く明確にして全体最適化を目指します。
その上で、戦略上、どのビジネスプロセスを優先的にデジタイゼーションするか決めるようにします。
なぜ、一度にデジタライゼーションしないかというと、まず、やってみて小さな成功体験を積み重ねるというスモールスタートで進めるためです。
デジタイゼーションは、業務改善になります。
ここでは、生成AIを活用した業務改善について学習します。
それから、この段階で、ビジョンとしてDXアクションプランを策定するとともに、どのアプリケーションにマイクロサービスを適用し、どのアプリケーションに業務パッケージを適用するかというアプリケーション戦略を立案します。
DX2：デジタライゼーション
次に、データドリブン経営と、制約理論（TOC）の現場レベルのステップ2と3、つまり、制約の改善、制約への適合を実践することで、戦略上重要なビジネスプロセスを２つ以上デジタライゼーションします。
現場レベルの制約理論（TOC)は、業務改革になります。
デジタライゼーションでは、制約理論（TOC)を適用した業務改革について学習します。
これによって、２回以上デジタル化を繰り返すことになるので、DX成熟度レベルがレベル２、繰り返し可能な状態になります。
DX3：スタンダーダイゼーション（標準化）
DX2までで、デジタイゼーション、デジタライゼーションが実現できたので、本格的に、デジタルトランスフォーメーションを進めることができますが、その前に、企業全体の企業情報物理基盤（プロダクト）とマネジメント基盤（プロセス）を標準化し、DX成熟度をレベル３にし、マネジメントが統制できるレベルにします。
なお、企業全体の企業情報物理基盤（プロダクト）の標準化とは、IT基盤、コミュニケーション基盤、アプリケーション基盤、データ管理基盤、BPM基盤のプロダクトを企業全体で統一的に整備することです。
アプリケーション基盤を構築する一環として、ストラングラーアプリケーションパターンを適用して基幹システムをマイクロサービス化します。
DX4：革新的な生産性向上
ここから、本各的に、デジタルフォーメーションを進めるのですが、まず、標準化された企業情報基盤を適用し企業の業務とシステムを変化に強い構造にするとともに、標準化されたマネジメント基盤の下、データドリブン経営と現場レベルの制約理論（TOC）を実践しながら価値創造の企業文化を醸成し、革新的に生産性が上がる状態にします。
この段階で、企業情報物理基盤が確立され、マネジメント基盤の統制されたマネジメントが実行できるので、DX成熟度がレベル４，管理された状態になります。
DX5：創造と変革
DX5では、まず、マネジメント基盤の統制されたマネジメントの下、データドリブン経営と現場レベルの制約理論（TOC）を実践し、マネジメント基盤を継続的に改善できる状態にし、DX成熟度をレベル5にします。
この段階で、仮説検証の仕組が確立するので、制約理論（TOC）の経営レベルのステップ４、「制約の克服」を適用して事業創出と事業変革を実現します。
DX5では、仮説検証の仕組、変化に強い構造、価値創造の企業文化が実現され、企業が継続的に学習し、環境の変化に適応して進化する組織になることを目指します。
さて、説明の観点ですが、ここでは、各DXフェーズで実施する内容を、DX成熟度と、DX戦略マップの
- 企業情報論理基盤
- 企業情報物理基盤
- マネジメント基盤
- データドリブン経営
DX1：デジタイゼーション
まず、トップダウンアプローチに従って、最初に、企業全体の仕組（エンタープライズアーキテクチャ）を事業、業務、システム、戦略の観点で広く浅く明確にして全体最適化を目指します。
また、DXアクションプランとアプリケーション戦略も策定します。
その上で、ビジネスプロセスを一つ選定し、生成AIを活用した業務改善をデジタイゼーションとして実施します。
DX成熟度
DX成熟度レベル 1: 場当たり的な状態 (Initial)
まずやってみる
企業情報基盤、および、マネジメントはアドホックであり、企業情報基盤、および、マネジメントプロセスの手順は正式に文書化されていません。
企業情報基盤、および、マネジメントの品質が低く、それらはプロジェクトに依存します。
企業情報論理基盤
企業情報論理基盤は、経営理念、事業パーパス、ビジョン、戦略マップ、EA（エンタープライズアーキテクチャ）から構成されます。
ここでは、
を明確化します。
事業ドメイン、企業の本質、ビジネスモデルはEAの要素です。
なお、EAのうちTA（テクニカルアーキテクチャ）は、企業情報物理基盤で設計します。
経営理念
左川産業の経営理念は次のようになります。
カスタマーサクセス（顧客の成功）を中心に考える。
事業ドメイン
左川産業の事業ドメインは、
製造業者向け産業機械の製造と販売
になります。
左川産業は、製造業者向けに産業機械を製造、販売する会社です。
仕入先から部品を購買し、産業機械を製造して顧客に販売します。
現在、産業機械の保守は、全国にある保守サービス会社が代行しています。
事業パーパス
左川産業の事業パーパスは
製造業者に、安定操業、省エネ操業を実現する産業機械を提供すること
です。
企業の本質
ここでは、トップダウンアプローチに従って、EAのうち、企業の骨格となる
事業の本質
ここでは、次の観点で事業の本質を記述します。
顧客価値
顧客価値と製品価値は、「誰（顧客価値）に何の価値（製品価値）を提供するか」というビジネスの原点になります。
ここでは、次の順で顧客価値を定義します。
「満たすべき顧客の欲求（ニーズ）は何か」定義します。
顧客の欲求（ニーズ）をマズローの欲求5段階説の段階で考えることもできます。
左川産業の場合、次のような製造業者の欲求になります。
- 機械を止めずに安定して製品を製造したい
- できるだけ少ないエネルギーを使って低コストで製品を製造したい
顧客の欲求（ニーズ）を満たす性質を考えます。
左川産業の場合、次のような製造業者の価値になります。
- 安定操業
機械を止めずに安定して製品を製造できること。 - 省エネ操業
できるだけ少ないエネルギーを使って低コストで製品を製造できること。
製品価値
ここでは、顧客価値に適合する製品の性質 （効用）を定義します。
左川産業の場合、次のような製品価値になります。
- 信頼性の高い製品
故障が少なく信頼できる産業機械。
止まらない、壊れない。 - 高性能な製品
より少ないエネルギーでパフォーマンスを出す高性能な産業機械。
【参考動画】
顧客と製品の設計
メンバー価値
ここでは、会社がメンバーに求める価値観を定義します。
左川産業の場合、経営理念「カスタマーサクセス（顧客の成功）を中心に考える」を鑑みて、
カスタマーサクセス（顧客の成功）を中心に考えることが重要であるという価値観
を求めます。
パートナー価値
ここでは、会社がパートナーに求める価値観を定義します。
左川産業の主なパートナーは、現状、保守サービス会社と、部品の仕入先になります。
左川産業の場合、経営理念「カスタマーサクセス（顧客の成功）を中心に考える」を鑑みて、保守サービス会社と仕入先に対して
カスタマーサクセス（顧客の成功）を中心に考えることが重要であるという価値観
を求めます。
財務資産
ここでは、事業を行う上で重要な財務資産があれば定義します。
左川産業の場合、信頼性が高く性能が高い産業機械を製造するための
製造設備
が重要になります。
場所
ここでは、事業を行う上で重要な場所があれば定義します。
左川産業の場合、合、信頼性が高く性能が高い産業機械を製造し販売するための次の場所になります。
製造場所（工場など）、物流場所（倉庫など）、販売場所（支店など）
業務の本質
ここでは、次の観点で業務の本質を記述します。
活動領域
ここでは、会社の活動領域を定義します。
左川産業の場合、次のようになります。
※
ここでは、「商品」と「製品」を同義とします。
なので、商品管理と製品管理は同義です。
さて、この活動領域ですが、事業ドメイン固有の活動領域と、事業ドメイン共有の活動領域に分けることができます。
これは、不動産会社を事業ドメイン固有の活動領域と、事業ドメイン共有の活動領域に分けた例です。
例えば、戸建て住宅開発販売事業には、販売、顧客管理、事業管理、用地管理、建物管理という主要活動があります。
また、事業共通の事業支援活動には、支払、請求、社員管理、パートナー管理、情報管理があり、企業共通の企業支援活動には、財務管理、経営管理があります。
ビジネスプロセス
ここでは、活動領域別のビジネスプロセスを洗い出します。
左川産業の場合、次のようになります。
ビジネスプロセス一覧
バリューチェーン
ここでは、洗い出したビジネスプロセスをバリューチェーンの主要活動を構成する次の活動と支援活動に分類します。
- 価値を創る活動（イノベーションプロセス）
- 価値を伝える活動（コミュニケーションプロセス）
- 価値を届ける活動（オペレーションプロセス）
左川産業のバリューチェーン（概要レベル）は、次のようになります。
バリューチェーンの詳細は、上記ビジネスプロセス一覧を参照してください。
ジョブ
ここでは、会社の職務（ジョブ）を定義します。
ジョブは、ビジネスを行う機能であり、ビジネスプロセスの業務フローを実行する主体になります。
ジョブを設計するときは、活動領域を利用します。
ジョブは、活動領域をベースに、
- 内部統制を働かせるためにどう職務を分掌するか
- 戦略マップの戦略目標をどう実現するか
などの観点で設計します。
左川産業のジョブは次のようになります。
※
ここでは、「商品」と「製品」を同義とします。
なので、商品管理者と製品管理者は同義です。
- 内部統制を働かせるための職務分掌
【購買管理者、入荷管理者、支払管理者の分掌】
もし、購買管理者が部品の発注、入荷、代金の支払をすべて行うと、どのようなリスクが発生するでしょか。
不正などにより購買管理者が発注した部品が棚卸資産として計上されない可能性があります。
また、購買管理者に会計に知識がない場合、代金が入金されても買掛金が消し込みされない可能性があります。
これは、棚卸資産や買掛金の実在性に対するリスクになります。
なので、財務報告の信頼性リスクを統制するために、購買管理者、入荷管理者、支払管理者の職務を分掌（ぶんしょう）し、部品の発注、入荷、代金の支払の責務を分けることにします。
【販売管理者、出荷管理者、請求管理者の分掌】
もし、販売管理者が製品の受注、出荷、代金の請求をすべて行うと、どのようなリスクが発生するでしょか。
不正などにより販売管理者が受注した製品が棚卸資産として計上されない可能性があります。
また、販売管理者に会計に知識がない場合、代金が回収されても売掛金が消し込みされない可能性があります。
これは、棚卸資産や売掛金の実在性に対するリスクになります。
なので、財務報告の信頼性リスクを統制するために、販売管理者、出荷管理者、請求管理者の職務を分掌し、製品の受注、出荷、代金の請求の責務を分けることにします。
【在庫管理者と会計管理者の分掌】
物財を扱う在庫管理者が帳簿を扱うと、不正などにより正しく棚卸資産が計上されない可能性があります。
これは、棚卸資産の実在性に対するリスクになります。
なので、財務報告の信頼性リスクを統制するために、物財を扱う在庫管理者と帳簿を扱う会計管理者を分掌し、正しく棚卸資産が計上されるようにします。
- 戦略マップの戦略目標をどう実現するか
これは、戦略マップを設計した後で行います。
【生産管理者と製造担当者の分掌】
例えば、戦略目標に「製品/部品の安定供給および適正在庫」がある場合、それを実現するためには、在庫のムラを防ぐために、需要予測の精度上げるとともに、需要予測の結果と生産能力を考慮して生産計画を策定し適正数部品を仕込むことが重要です。
そこで、製造と生産管理の職務を分掌し生産計画の専門性を強化するようにします。
【製造担当者と品質担当者の分掌】
戦略目標に「製品品質の維持向上」がある場合、それを実現するために、製造と品質管理の職務を分掌し品質管理の専門性を強化します。
左川産業のジョブ一覧は次のようになります。
ジョブ一覧
【参考動画】
ジョブとビジネスプロセスの設計
システムの本質
ここでは、トランザクション処理アプリケーション、分析アプリケーションのアプリケーションポートフォリオと、そこで管理すべきデータを設計します。
左川産業のアプリケーションタイプと、それが管理するデータタイプは次のようになります。
アプリケーション一覧
トランザクション処理アプリケーション（SoR）
トランザクション処理アプリケーションのアプリケーションタイプはジョブに対応させます。
ジョブは、内部統制による職務分掌や、同じスキルセット、ドメイン知識を持つ機能単位として考えられているので、ジョブ単位にトランザクション処理アプリケーションを分割することで、業務機能とアプリケーションを対応させることができます。
これは、結果的に、ソフトウェア設計原則の単一責任の原則「変更する理由が同じものは集める、変更する理由が違うものは分ける」に則ることになります。
ジョブをベースにして左川産業のトランザクション処理アプリケーションのアプリケーションタイプの構成は次のように設計することができます。
ここでは、戦略目標「製品品質の維持向上」を実現するために、顧客に導入した納入機（製品個体）の状態を監視し予防保全を実現するため納入機管理システムを導入しています。
また、得意先元帳や仕入先元帳に対応するシステムを導入し債権債務を細かく管理するため会計管理システムから売上管理システムと仕入管理システムを独立させています。
アプリケーションポートフォリオを一覧化すると次のようになります。
分析アプリケーション（SoI）
次に、分析アプリケーションのアプリケーションタイプの構成ですが、これは、ソフトウェア設計原則の単一責任の原則に従うよう、分析の目的別に分類します。
例えば、売上分析をしたい場合は、売上分析システムになります。
BSCのKPIが定義されている場合、KPIごとに分析システムを設定することができます。
その場合、BSCの設計後、分析アプリケーションを設計します。
左川産業の分析アプリケーションは次のようになります。
トランザクション処理アプリケーション（SoR）で管理すべきデータ
トランザクション処理アプリケーション（SoR）で管理すべきトランザクションデータとマスターデータを洗い出します。
詳細は、上記アプリケーション一覧を参照してください。
分析アプリケーション（SoI）で管理すべきデータ
分析アプリケーション（SoI）で管理すべきデータをBSCのKPIを中心に洗い出します。
詳細は、上記アプリケーション一覧を参照してください。
戦略マップ
上記事業の本質、業務の本質、システムの本質で明確になった会社の構成要素を参照して、次の観点で戦略マップとBSC（バランススコアカード）を設計します。
戦略マップは、事業戦略の型となるもので、事業が続く限り変わりません。
左川産業の戦略マップは次のようになります。
また、左川産業のBSCは次のようになります。
財務の視点
企業価値の最大化という目標を設定します。
BSCを構成するKPIとして、投下資本利益率（ROIC）など企業価値を測る指標を設定します。
収益の増大という目標を設定します。
BSCを構成するKPIとして、収益を測る指標を設定します。
生産性の向上という目標を設定します。
BSCを構成するKPIとして、生産性を測る指標を設定します。
顧客の視点
事業の本質の顧客価値と製品価値、および、顧客との関係に関する目標を設定します。これらは、財務の視点の収益の増大の原因になります。
BSCを構成するKPIとして、顧客価値、製品価値、顧客との関係に関する目標を測る指標を設定します。
左川産業の場合、信頼性の製品と高性能な製品を製品価値として提供することで、顧客価値である安定操業と省エネ操業を実現し、顧客に信頼されるビジネスパートナーになることを目指しています。
内部プロセスの視点
バリューチェーンの主要活動である「価値を創る活動」、「価値を伝える活動」、「価値を届ける活動」を構成するビジネスプロセスの戦略目標を次の観点で設定し、BSCを構成するKPIとして、各戦略目標を測る指標を設定します。
- 製品価値を実現するための目標
- 生産性を上げるための目標
まず、「価値を届ける活動」ですが、左川産業の場合、製品/部品の在庫を最適化することによって生産性を上げるとともに、製品/部品を顧客に安定的に供給し、顧客の安定操業を実現します。
また、製品品質を維持・向上すること、および、保守サービスの品質を維持・向上することで、信頼性の高い製品価値を実現します。
次に、「価値を伝える活動」ですが、左川産業の場合、製品性能を効果的にプロモーションすることで、顧客に高性能な製品価値を正しく伝えます。
最後に、「価値を創る活動」ですが、左川産業の場合、高性能製品を迅速かつ継続的に創出することで、顧客に絶え間なく高性能な製品価値を提供し競争優位性を確立します。
学習と成長の視点
ここでは、内部プロセスの視点の各戦略目標実現に関連するジョブ、アプリケーションタイプを選択します。
選択したジョブに関する目標を人的資本の目標として設定します。
選択したアプリケーションタイプに関する目標を情報資本の目標として設定します。
アプリケーションタイプで管理されるデータタイプが戦略的データになります。
経営理念を浸透させる目標を組織資本の目標として設定します。
そして、BSCを構成するKPIとして、学習と成長の視点の各目標を測る指標を設定します。
左川産業の場合、製品/部品の在庫を最適化するために、SCMをシステム化することで継続的に改善するようにします。
また、保守サービス技術を蓄積し、それを活用することで高い保守サービスの品質を実現します。
さらに、顧客に導入した納入機の市場品質を監視、分析することで予防保全を実現し、保守サービスの品質を向上します。
また、品質管理技術を蓄積し、それを活用することで製品品質を維持、向上します。
次に、SFAおよびCRMをシステム化し、継続的に改善することで、顧客に対して製品性能を効果的にプロモーションすることができるようにします。
最後に、PLMをシステム化することで継続的に改善するとともに、製品開発者を獲得し育成することで高性能な製品を実現します。
※
製品開発者は製品管理者（商品管理者）の一種です。
ビジネスモデル
ここでは、事業のビジネスモデルをビジネスモデルキャンバスで表します。
戦略マップは、事業が続く限り変わりませんが、ビジネスモデルは、事業変革の都度、変化します。
ビジネスモデルキャンバスは、スイスの起業家、アレックス・オスターワルダーとイヴ・ピニュールによって開発されたもので、ビジネスモデルを次の9つの要素に分解し、それぞれの要素を可視化することで、ビジネスの全体像を把握し、戦略立案や改善に役立てるフレームワークです。
- 顧客セグメント (Customer Segments)
誰に価値を提供するのか、ターゲット顧客を明確にします。
ここでは、顧客価値を設定します。 - 価値提案 (Value Propositions)
顧客にどのような価値を提供するのか、具体的な価値を記述します。
ここでは、製品価値を設定します。 - チャネル (Channels)
顧客にどのように価値を届けるのか、販売経路やコミュニケーション手段を検討します。
ここでは、販売に関するパートナーを設定します。 - 顧客関係 (Customer Relationships)
顧客とどのような関係を築くのか、顧客との関係性を明確にします。 - 収益の流れ (Revenue Streams)
どのように収益を上げるのか、収益源を明確にします。 - 主要リソース (Key Resources)
ビジネスに必要な資源を明確にします。
ここでは、戦略マップの人的資本、情報資本、財務資産を設定します。 - 主要活動 (Key Activities)
価値を創造するために必要な活動を明確にします。
ここでは、バリューチェーンを構成するビジネスプロセスを設定します。 - 主要パートナー (Key Partners)
誰と協力してビジネスを行うのか、パートナーを明確にします。
ここでは、購買、その他に関するパートナーを設定します。 - コスト構造 (Cost Structure)
ビジネスを行う上で発生するコストを明確にします
左川産業の現在のビジネスモデルキャンバスは次のようになります。
全体概念データモデル・データフロー
全体概念マスターデータモデル
ここでは、マスターデータの全体概念データモデルを設計します。
法人顧客マスターデータの全体概念データモデル
次の図は、左川産業の法人顧客の概念データモデルの例です。
この概念データモデルを見ると、このビジネスでは、次のような観点で法人顧客を管理することがわかります。
- 法人番号を持つ法人をベースに法人顧客を管理する。
国税庁が管理する13桁の法人番号や、全世界の企業を一意に識別できる9桁のDUNSナンバーを法人番号の候補として考えることができます。 - 法人は、関連会社の関係もわかるようにする。
- 法人顧客ごとに複数の顧客担当者を定義できるようにする。
- 法人顧客ごとに複数、支払手段を設定できるようにする。
- 同じ法人顧客でも、契約先、出荷先、請求先など役割の違いが識別できるようにする。
- すでに取引がある顧客かまだ取引がない潜在的な顧客かなど顧客のステータスが識別できるようにする。
- 例えば、業種、規模、地域など様々な切り口で法人顧客を分類できるようにする。
このように、全体概念マスターデータモデルでは、ビジネスアーキテクチャで設計された資産をどのように管理すべきかをデータモデルとして記述します。
法人顧客マスターデータの全体概念データフロー
顧客マスターデータは、バリューチェーンのビジネスプロセスでいうと「顧客の獲得」プロセス、「顧客の活性化」プロセス、「顧客の維持」プロセス、「顧客の処分」プロセスで生成、更新、削除されます。
次の図は、法人顧客マスターデータが更新されるときの全体概念データフローの例です。
これを見ると、マスターデータ管理の方針として、顧客マスターは、データの構造を一般化して多くのシステムに適用にする必要がないため、顧客マスターの主管システムである顧客管理システムをトランザクションハブにしていることがわかります。
また、データ統合の方針として、顧客マスターデータの統合は、リアルタイム性を求められないため、顧客マスターデータの更新の都度、非同期メッセージングによるイベント駆動で統合していることがわかります。
この全体概念データフローは、トランザクションハブである顧客管理システムの顧客データが更新される都度、顧客データを必要とするシステムにTopicを介して配布（ブロードキャスト）するというイベント駆動統合の仕組を表しています。
顧客データを必要とするシステムは、顧客管理システムから送られていくる最新の顧客データで、自身の持つ顧客データを更新します。
製品マスターデータの全体概念データモデル
次に、左川産業の製品の概念データモデルの例を示します。
これを見ると、このビジネスでは、次のような観点で製品を管理することがわかります。
- 製品は、その種類の最小単位である品目として管理する。
- 品目は、「PN（Parts Number）」という品目情報と、「PS（Part Structure）」というPNの親子関係を管理するBOM（Bills of materials：部品表）の構造を持つ。
- 品目の種類には、設計品目、製造品目、販売品目、購買品目、サービス品目がある。
- 各品目は、種類ごとに、複数の単価を持つことができる。
- 各品目は、種類ごとに、仕様、サイズ、色など様々な分類基準で分類することができる。
「マーケティングマネジメント―持続的成長の開発と戦略展開」という書籍で、フィリップ・コトラーは、製品の階層構造を次のように説明しています。
- ニーズ・ファミリー
製品ファミリーのもととなる中核ニーズ。
生命保険の例
安全。 - 製品ファミリー
中核ニーズを満足させる全ての製品クラス。
生命保険の例
貯蓄と所得。 - 製品クラス
製品ファミリーの中で機能的一貫性を持っているとみなされる製品グループ。
生命保険の例
金融手段。 - 製品ライン
製品クラスの中で、機能、顧客、販路、価格水準などを同じくすることで密接に関連づけられている製品グループ。
生命保険の例
生命保険。 - 製品タイプ
製品ラインの中で、形態や様式が同じもの。
生命保険の例
長期契約の生命保険。 - ブランド
製品ラインの中の一つあるいは複数のアイテムにつけられた名前であり、アイテムの特性や出所を明らかにするもの。
生命保険の例
プルーデンシャル。 - 品目（アイテム）
製品ラインやブランドの中で、サイズ、価格、外見、その他の特性で区別される単位。
生命保険の例
プルーデンシャル更新可能長期保険。
上図の概念データモデルでは、この分類の品目を管理し、その上位概念としてのニーズ・ファミリーからブランドまでを品目分類基準とその値で定義できるようにしていることがわかります。
次に、設計品目、製造品目、販売品目、購買品目、サービス品目の関係を次のように設計します。
この概念データモデルは、設計→製造→サービスのエンジニアリングチェーンと、購買→製造→販売というサプライチェーンの流れから構成されています。
それから、各関連の多重度によって、ビジネス上、次の要件を満たす必要があることがわかります。
- 製造品目から販売品目への関連
同じ製造品目であっても販売独自の視点で販売単価の異なる販売品目を設ける可能性がある。 - 販売品目から製造品目への関連
複数の製造品目をまとめて一つの販売品目にする可能性がある。 - 製造品目から購買品目への関連
同じ製造品目（この場合部品です）であっても購買独自の視点で購買単価の異なる購買品目を設ける可能性がある。 - 購買品目から製造品目への関連
購買独自の購買品目がある可能性がある（製造品目が0になる場合がある）。 - 製造品目から設計品目への関連
「工程」など製造独自の製造品目がある（設計品目が0になる場合がある）。 - 設計品目から製造品目への関連
一つの設計品目に対して異なるバージョンの製造品目がある可能性がある。 - 製造品目からサービス品目への関連
一つの製造品目に対して異なるバージョンのサービス品目がある可能性がある。 - サービス品目から製造品目への関連
「役務」などサービス独自のサービス品目がある（製造品目が0になる場合がある）。
複数の製造品目をまとめて一つのサービス品目にする可能性がある。
このようなビジネス上のデータ要件は、ビジネスメタデータとして定義します。
そして、システム開発や業務パッケージ導入の要件定義の際、それが満たすべきデータ要件として定義します。
製品マスターデータの全体概念データフロー
製品マスターデータは、バリューチェーンのビジネスプロセスでいうと「製品の開発」プロセス、「製品の改良」プロセス、「製品の改修」プロセス、「製品の廃止」プロセスで生成、更新、削除されます。
次の図は、「製品の開発」プロセスのアクティビティフローの例です。
流れは次のようになります。
- 製品管理者が製品を設計すると、
- 生産管理者がそれを受けて量産化の準備をする。
- 量産化の準備ができると、販売管理者、購買管理者、保守サービス管理者が、それぞれ、販売、購買、サービスの企画をする。
- 販売、購買、サービスの企画ができると、顧客管理者が市場に向けて製品のプロモーションを行う。
製品開発の流れを受けて、各システム（アプリケーションタイプ）間のデータフローは次のようになります。
これを見ると、マスターデータ管理の方針として、品目マスターは、データの構造を一般化して多くのシステムに適用にする必要がないため品目マスターの主管システムをトランザクションハブにしていることがわかります。
また、データ統合の方針として、品目マスターデータの統合は、リアルタイム性を求められないため、品目マスターデータの更新の都度、非同期メッセージングによるイベント駆動で統合していることがわかります。
データ統合の流れは次のようになります。
- 製品管理者の製品設計を受けて製品管理システムが、設計品目データを、Queueを介して生産管理システムに送る。
- 生産管理者の生産準備の過程で、設計品目データから製造品目データが生成され、それがTopicを介して販売管理システム、購買管理システム、サービス管理システムに送られ、各システムで販売品目、購買品目、サービス品目が生成される。
- また、生産準備を受けて、製造品目データがQueueを介して在庫管理システムに送られることで、製造品目に対応した在庫データが生成される。
- 販売、購買、サービスの企画ができると、販売管理システムの販売品目がQueueを介して顧客管理システムに送られ、製品のプロモーションに活用される。
- なお、顧客の問い合わせやクレームによって蓄積された製品の改善要求データは、製品管理システムに送られ、製品の改良に活用される。
全体概念トランザクションデータモデルとデータフロー
ここでは、トランザクションデータの全体概念データモデルと全体概念データフローを設計します。
トランザクションデータの全体概念データモデル
次に、左川産業の全体概念トランザクションデータモデルを設計します。
ビジネスアーキテクチャとしてバリューチェーンが設計されると、全体概念トランザクションデータモデルを設計することができます。
特に、戦略マップの内部プロセスの視点を構成する
- 価値を創る活動、
- 価値を伝える活動、
- 価値を届ける活動
の活動領域は、顧客価値を創出する戦略的な活動になります。
マスターデータが資産や場所など業務活動に関連する共通概念を表すのに対して、トランザクションデータは、業務活動によって発生した事実を表します。
全体概念トランザクションデータモデルは、バリューチェーンを構成する業務活動間の関係、つまり、価値の連鎖を設計します。
具体例で説明します。
これは、左川産業のバリューチェーンの一部です。
このうち、価値を届ける活動のバリューチェーンに対する全体概念トランザクションデータモデルを次のように設計します。
※本図は、代表的なエンティティのみ記載したものです。
全体概念トランザクションデータモデルの枠組みは、バリューチェーンに対応するアプリケーションタイプです。
なので、全体概念トランザクションデータモデルを設計するためには、アプリケーションタイプの構成であるアプリケーションポートフォリオが設計されている必要があります。
さて、全体概念トランザクションデータモデルを構成するエンティティの粒度ですが、これは、次のガイドラインに基づいて考えます。
- ドメイン駆動設計のドメインオブジェクトのうエンティティを対象とし値オブジェクトは対象にしない
例えば、下図の法人顧客の概念データモデルで考えると、顧客分類基準、顧客ステータス、顧客役割、取引条件は値オブジェクトに該当するので省きます。
- ドメイン駆動設計の集約のルートにする
例えば、受注と受注明細が強い所有関係になっている場合、受注明細は受注に集約されるものとし、受注エンティティを全体概念トランザクションデータモデルのエンティティにします。
また、上図の法人顧客の概念データモデルでいうと、銀行口座や顧客担当者は、法人顧客に集約されると考えることができます。
結果的に、法人顧客の概念データモデルで全体概念トランザクションデータモデルの対象となるエンティティは、法人顧客のみになります。
さて、全体概念トランザクションデータモデルで重要なのはトランザクションデータ（活動）間の関連（連鎖）です。
特に、ビジネス上のデータ要件のうち、
- データのトレーサビリティ、
- データ関連の制約
を、この段階で明確にしておきます。
これらのデータ要件は、ビジネスを遂行するための必要条件になるからです。
例えば、上図の全体概念トランザクションデータモデルの、受注と出荷の関係を見ると、次のデータ要件が発生することがわかります。
- データのトレーサビリティ
出荷の元となる受注データがトレースできなければならない。
これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要です。 - データ関連の制約
複数の受注の製品をまとめて出荷（一括納品）できなければならない。
一つの受注の製品を分割して出荷（分納）できなければならない。
もう一つ例を上げると、販売管理システムの受注データと、在庫管理システムの引当データの関連から、「受注したタイミングで在庫の引当をしなければならない」というデータ関連の制約を定義することができます。
これらのデータ要件は業務パッケージの導入やシステム開発のときの仕様になります。
このように、全体概念トランザクションデータモデルを設計することによって、バリューチェーンが備えるべきビジネス上のデータ要件を全体的に洗い出すことができます。
トランザクションデータの全体概念データフロー
トランザクションデータの全体概念データフローは、全体概念トランザクションデータモデルに対する概念データフローです。
下図は、上記、左川産業の全体概念トランザクションデータモデルです。
このデータモデルのトランザクションデータ間のトレーサビリティから、次のようなトランザクションデータの全体概念データフローを設計することができます。
例えば、上の全体概念トランザクションデータモデルを見ると、受注データと出荷データの間に「出荷の元となる受注データがトレースできなければならない」というトレーサビリティがあることがわかります。
これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要です。
なので、何らかの方法で、販売管理システムの受注データを、出荷管理システムに渡す必要があります。
上図のトランザクションデータの全体概念データフローでは、販売管理システムと出荷管理システム間で受注データのフローを記述しています。
このトランザクションデータの全体概念データフローは、業務概念データフローを設計するときの見取り図になります。
全体概念分析データモデルとデータフロー
ここでは、分析データの全体概念データモデルと全体概念データフローを設計します。
分析アプリケーション（SoI）で管理すべきデータ
ここでは、分析アプリケーション（SoI）で管理すべきデータをBSCのKPIを中心に洗い出します。
詳細は、上記アプリケーション一覧を参照してください。
次に、分析データの全体概念データモデル、および、全体概念データフローを設計します。
ここでは、左川産業の例を示します。
-
LTVデータの全体概念データモデル
ここでは、LTV分析システムにおけるLTVのデータアーキテクチャの例について説明します。
まず、LTV分析システムではLTV（顧客生涯価値）を次のように管理すると考えます。- 既存顧客のLTV=（取引期間における顧客の粗利益）−（取引期間における顧客維持コスト）と考える。
さらに、次のようにLTVを分解する。
LTV=顧客単価×粗利率×購買頻度×存続期間－顧客維持コスト
顧客単価：顧客一人当たりの平均単価/期間
粗利率：製品の粗利率/期間
購買頻度：顧客一人当たりの購買回数/期間 - 製品カテゴリの定義
販売品目（完成品、部品、サービス）を製品カテゴリ（ハイエンド製品など）で分類する。 - 顧客セグメントの作成
例えば、ハイエンド製品を購入した顧客を顧客セグメント・ハイエンドとして分類する。 - 期間（年、四半期など）ごとの顧客維持コストを記録する。
- 売上計上の都度、売上データをLTV分析システムに蓄積する。
- LTV分析システムでは、売上明細から継続的に期間（年、四半期など）ごとのLTVを測定する。
まず、販売品目（完成品、部品、サービス）を製品カテゴリ（ハイエンド製品など）で分類します。
次に、例えば、ハイエンド製品を購入した顧客を顧客セグメント・ハイエンドとして分類します。
このモデルでは、期間（年、四半期など）ごとの顧客維持コストを顧客ごとに記録できるようにしています。
さて、次のように売上データから製品一個あたり粗利益を計算することができます。
なので、コマンド・クエリ分離パターン（CQRS）を適用して、「製品の出荷登録」アクションのタイミングで売上管理システムから売上データをLTV分析システムに渡します。
LTV分析システムのDWHには、その都度、売上データが蓄積されます。
売上管理システムからLTV分析システムに渡される売上データのカノニカルモデルは次のようになります。
※
カノニカルモデル
システム間を異動するメッセージのデータモデル。
LTV分析システムでは、定期的にバッチで売上データからLTVデータを統合します。
その際、バッチ処理の一環として、顧客管理システムから最新の顧客セグメント別顧客データを取得するとともに、販売管理システムから最新の製品カテゴリ別販売品目データを取得します。
結果的に、LTV分析システムでは、次のようなLTVデータが生成されます。
売上データの全体概念データフロー
次の図は、LTV分析システムに売上データが蓄積される分析データの全体概念データフローを表しています。
これを見ると「製品の出荷登録」アクションのタイミングで売上管理システムから売上データをLTV分析システムに渡していることがわかります。
LTV分析システムのDWHには、その都度、売上データが蓄積されます。ビジネスプロセス別KPIの設計
さて、上述した分析アプリケーションで管理するデータで、LTVを次のように分解して管理するという説明をしました。
LTV=顧客単価×粗利率×購買頻度×存続期間－顧客維持コスト
顧客単価：顧客一人当たりの平均単価/期間
粗利率：製品の粗利率/期間
購買頻度：顧客一人当たりの購買回数/期間
これを、ビジネスプロセスごとのKPIとして考えると、次のようになります。- 顧客単価
クロスセルやアップセルで上げることができるので、これは「製品の販売」プロセスのKPIとして考えます。 - 粗利率
製品の機能改善によって上げることができるので、これは「製品の改良」プロセスのKPIとして考えます。 - 購買頻度
プロモーションなど顧客の購買意欲を上げる活動で上げることができるので、これは「顧客の活性化」プロセスのKPIとして考えます。 - 顧客維持コスト
上記のビジネスプロセスで費やされたコストを顧客維持コストとして考えます。
顧客維持コストは活動基準原価計算で測定することができます。
次の表は、ビジネスプロセス別KPI一覧です。
ビジネスプロセス別KPI一覧
ここでは、LTVのケースを例にしていますが、BSCのすべてのKPIについて、それを分解してビジネスプロセス単位に割り当てることができます。
これによって、データドリブン経営の問題の特定で検証すべきKPIが明確になります。
ビジョン
ビジョンとして次を策定します。
DXアクションプラン
いつまでにDX2からDX5までを進めるか、上記DXマトリクスをベースうにアクションプランを策定します。
アプリケーション戦略
ここでは、あるべきアプリケーションカテゴリ（論理レベルのアプリケーション）の構成についての戦略を策定します。
次の図は、企業のアプリケーションを、業務活動の特殊性と規模で分類したものです。
これを見ると、業務活動の規模が大きくて特殊なアプリケーションはスクラッチ開発がよく、業務活動の規模が大きくて汎用的なアプリケーションは業務パッケージを適用したほうがよいとなっています。
なぜならば、業務活動の規模が大きくて特殊なアプリケーションは、ビジネスのノウハウが機能として蓄積されていく部分なので変更可能性が高く、自分たちが自由に変更しづらい汎用的な業務パッケージが足かせになる可能性が高いからです。
マイケル・ポーターのバリューチェーンは主要活動と支援活動から構成されていますが、価値を創り、伝え、届ける主要活動の部分は、ビジネスの根幹となる部分であり特殊性が高く、支援活動は汎用性が高いと考えることができます。
特に、会計や給与計算などは、会社によって機能が変わるわけではなく法改正による機能変更をいちいち自社で行う必要はないので、それこそ既成の業務パッケージを適用するほうがよいと考えます。
そして、この業務活動の規模が大きくて特殊性が高いアプリケーションこそマイクロサービスを適用すべきだと考えます。
なぜならば、ビジネスの根幹となる業務を支援するアプリケーションは高い保守性や可用性が求められるからです。
マイクロサービスを適用することで、システムがモジュール化され、比較的柔軟に機能を追加、変更することができます。
また、マイクロサービスは、分散システムを形成するので障害耐性が強く可用性を高くします。
次の図は、左川産業のアプリケーションポートフォリオで業務パッケージを適用する部分とマイクロサービスを適用する部分を分けた図です。
これを見ると、左川産業では、会計や人事など規模が大きく汎用的なアプリケーションには業務パッケージを適用し、大規模で特殊性の高いSCMやCRM、PLMにはマイクロサービスを適用していることがわかります。
これは、企業が、アプリケーション戦略としてマイクロサービスアーキテクチャを適用した例になります。
DXを進めるときは、アプリケーション戦略に基づいて、現行の基幹システムの構成をあるべき基幹システムの構成にトランスフォームするようにします。
そのためには、現行の基幹システムを、そこで管理しているデータも含めて洗い出し、論理的機能、および、将来のマイクロサービスとマッピングさせる必要があります。
以下のアプリケーション一覧の「現行アプリ」シートを参照してください。
アプリケーション一覧
※
SCM
サプライチェーン管理（SCM：Supply Chain Management、以下、SCM）とは、製品やサービスを提供するために必要な資材や部品などを供給するネットワーク全体を統合的に管理するソリューションです。
SFA
営業支援システム（SFA：Sales Force Automation、以下、SFA）とは、営業担当者が行う業務（訪問、電話、メール、提案など）を記録・分析・管理することで、営業活動を効率化・可視化・自動化するためのITシステムです。
CRM
顧客関係管理（CRM：Customer Relationship Management、CRM）とは、顧客との関係を強化し、顧客とのコミュニケーションや相互作用を最適化するための戦略的なアプローチや技術の総称です。
PLM
製品ライフサイクル管理（PLM：Product Lifecycle Management、以下、PLM）とは、製品開発力や企業競争力を強化するために、製品ライフサイクル全体（製品企画・設計、調達、製造、販売、物流、保守サービス）に渡って発生する様々な技術情報を集約してエンジニアリングチェーンを繋いで管理するソリューションです。
ERP
エンタープライズ・リソース・プランニング（ERP: Enterprise Resource Planning）とは、企業全体を経営資源（人、物、金、情報）の有効活用の観点から統合的に管理し、経営の効率化を図るための手法です。
それから、アプリケーション戦略では、シングルサインオンを導入するかどうかなど、アプリケーションカテゴリ全体に関係する方針も決めます。
マイクロサービスの構成を考えるときは、ビジネスの活動領域を担うサービスだけでなく、ロギングサービスや認証・認可サービスなど業務機能に共通の機能をマイクロサービス化することも考えます。
マイクロサービスは、購買管理サービス、生産管理サービス、販売管理サービスなど業務視点で分けて考えるとともに、認証サービス、ロギングサービス、構成管理サービスなど業務横断的なシステム視点でも分けて考えます。
例えば、シングルサインオンを導入する場合、それを実現する認証サーバーをマイクロサービス（認証サービス）として実現することができます。
シングルサインオン（Single Sign-On：SSO）とは、認証と認可を分けることで、最初のアプリケーションを利用する時に、一度だけログインすれば、以降は全てのアプリケーションやサービスを再ログインなしに利用できるようにする仕組のことです。
上図は、シングルサインの仕組を表したものです。
流れを説明すると次のようになります。- ユーザーがUIのサインイン画面でIDとパスワードを入力します。
- UIはSSOゲートウェイにIDとパスワードを渡します。
- SSOゲートウェイは認証サービスにIDとパスワードを渡します。
- 認証サービスはユーザーのIDとパスワードを検証し、成功すると認証トークン（例えばJWT：JSON Web Token）を生成してSSOゲートウェイに返します。
- SSOゲートウェイは認証トークンをUIに渡します。
- UIは認証トークンを付加してバックエンドのアプリケーションやマイクロサービスにリクエストを送信します。
- アプリケーションやマイクロサービスは、認証トークンを検証し、ユーザーのリクエストに応じた処理を行います。
認証サービスとは、ユーザーの認証を行うマイクロサービスです。
認証サービスが認証した結果を認証トークンとして第三者に渡すことで、認証と認可を分離することができます。
認証トークンを受け取ったシステムは、それに応じたデータへのアクセスが認可されます。
それから、認証サービスは、多要素認証することもできます。
多要素認証とは、IDとパスワードに加え、第二の認証要素（例えば、スマートフォンの認証アプリ、SMSコード、生体認証など）を要求する認証方法です。
なお、上図のSSOゲートウェイとは、シングルサインオンゲートウェイのことで、アプリケーションやマイクロサービスと認証サービスとのやりとりを中継する機能です。
さて、どの部分に業務パッケージを適用し、どの部分にマイクロサービスを適用するか決まったら、どいう手順でマイクロサービス化していくかアクションプランを立案します。
その場合、多くのマイクロサービスに共通したマスターデータを管理する顧客管理システムや商品管理システムは共通部品になるので、先にマイクロサービス化すると比較的リスクとコストを抑えて進めることができます。
デジタイゼーション対象のEA
次を設計します。
- デジタイゼーション対象のビジネスプロセスのアクティビティフロー
- デジタイゼーション対象のアクティビティのアクションフロー
- デジタイゼーション対象のビジネスプロセスの概念データモデル
- デジタイゼーション対象のビジネスプロセスのアプリケーション連携モデル
デジタイゼーション対象のビジネスプロセスのアクティビティフロー
デジタイゼーション対象のビジネスプロセスのアクティビティフローを分析します。
今回は、バリューチェーンの中の「製品の販売」プロセスを対象とします。
「製品の販売」プロセスのアクティビティフローは、次のようになります。
デジタイゼーション対象のビジネスプロセスのアクションフロー
デジタイゼーション対象のアクティビティのアクションフローを分析します。
「製品の販売」プロセスのアクティビティフローのアクションのうち「販売の見積」アクティビティがFAXで紙のデータを扱っているので、これを対象にします。
「販売の見積」アクティビティのアクションフローは次のようになります。
顧客の見積依頼書をFAXで受取り、見積もり後、その内容をExcelに登録しています。
デジタイゼーション対象のビジネスプロセスの概念データモデル
デジタイゼーション対象のビジネスプロセスの業務概念データモデルを設計します。
「販売見積」の概念データモデルは次のようになります。
デジタイゼーション対象のビジネスプロセスのアプリケーション連携モデル
デジタイゼーション対象のアクションのアプリケーション連携モデルを設計します。
「販売見積の登録」アクションのアプリケーション連携モデルは次のようになります。
アプリケーション戦略としてマイクロサービスアーキテクチャを適用しているので、フロントエンドアプリケーションがBFFを介してマイクロサービスに処理を依頼する流れになっていることがわかります。
ここでは、デジタイゼーションを実現するため、FAXで受け取った顧客の見積依頼書の写真をとって販売管理システムにアップロードすると、販売管理システムが自動的に見積を行い、結果を販売管理サービスに登録し、顧客に自動的に販売見積回答書を添付したメールを送るというシステムを開発します。
企業情報物理基盤
DX1では、現在の企業情報物理基盤の状況を把握します。
例えば、次のようなITポートフォリオを作成して企業情報物理基盤の状況を明確にします。
企業情報物理基盤の設計は、EAのうちTA（テクニカルアーキテクチャ）になります。
マネジメント基盤
ここでは、マネジメント基盤に関して次の観点で説明します。
ビジネスプロセスマネジメント
DXを進める上で、ビジジネスアーキテクトがアサインされています。
ビジネスアーキテクトは、上記事業の本質と業務の本質を定義します。
また、ビジネスアーキテクトは、データドリブン経営の業務改善（デジタイゼーション）を実施します。
アプリケーションマネジメント
DXを進める上で、アプリケーションアーキテクトとアプリケーションエンジニアがアサインされています。
アプリケーションアーキテクトは、現行アプリケーションを調査するとともに、上記システムの本質のうちアプリケーションポートフォリオを設計します。
また、上記アプリケーション戦略を策定するとともに、アプリケーション連携モデルも設計します。
アプリケーションエンジニアは、業務改善（デジタイゼーション）のマイクロサービスやフロントエンドシステムを開発します。
データマネジメント
DXを進める上で、データアーキテクトとデータスチュワードがアサインされています。
データアーキテクトは、現行アプリケーションで管理されるデータを調査するとともに、上記システムの本質のうち概念データモデルと概念データフローを設計します。
また、データアーキテクトは、業務改善（デジタイゼーション）のデータ要件、および、データモデルを検証します。
データスチュワードは、概念データモデルのデータ要件をビジネスメタデータとして定義します。
ITマネジメント
DXを進める上で、ITアーキテクトがアサインされています。
ITアーキテクトは、上記現在の企業情報物理基盤の状況を把握します。
データドリブン経営
DX成熟度レベル1の「まずやってみる」ということで、ここでは、生成AIを活用して紙のデータをデジタルデータ化（デジタイゼーション）する業務改善を行います。
デジタイゼーション対象の業務の責任者と担当者がアサインされているものとします。
業務改善は次のような手順で行います。- 付加価値分析
アクションフローを構成するアクションを次の観点で分析します。- 本当に価値を生み出すアクションは何か
- 価値を生み出していないアクションは何か
- 価値を生み出すアクションをもっと効果的かつ効率的に行うにはどうすべきか
- 価値を生み出していないアクションはどうするか、削除、あるいは、削減するか、フローを変えるか、代替する手段はないか
- アクションの改善
価値を生み出すアクションをもっと効果的かつ効率的に行う方法を次の観点で考えます。RPAとAIの違いをを適用業務、入力データ、処理方法、出力結果で分けてまとめると次のようになります。
- アクションフローの自動化
個々のアクションの改善を受けて次を検討します。- ワークフローシステムを導入して、承認や確認アクションも含めてアクションフローを自動化する
- BAMを導入してアクションフローをモニタリングして継続的改善ができるようにする
RPA、生成AIの導入が適した業務の例は次のようになります。
- RPAが適している定型業務の例
- Webスクレイピング（株価取得、価格リサーチ）
※スクレイピングとはWebサイトやデータベースから特定の情報を抽出してデータを整形する手法。 - Excelデータ入力、転記、集計
- メールの自動送信（定型文）
- システム間データ連携（ERP、CRM、Salesforceなど）
- ファイル管理（リネーム、移動、アーカイブ）
- Webスクレイピング（株価取得、価格リサーチ）
- 生成AIが適している非定型業務の例
- 文書の要約や自動作成
例: メールやレポートを自動作成 - 問い合わせ対応（チャットボット）
例: 顧客の問い合わせを理解し、適切な回答を生成 - データ分析と洞察の生成
例: 売上データをもとに、異常値を検出してレポート作成 - 画像・音声処理
例: AIが請求書の画像からデータを抽出し、Excelに入力
- 文書の要約や自動作成
- RPAと生成AIの組み合わせが有効なケース
それでは、左川産業のデジタイゼーションの例を次の手順で示します。
付加価値分析
「販売の見積」アクティビティの現在のアクションフローは次のようになります。
顧客の見積依頼書をFAXで受取り、見積もり後、その内容をExcelに登録しています。
付加価値分析を行うと次のようになります。- 本当に価値を生み出すアクションは何か
「販売の見積」アクティビティのうち、本当に価値を生み出すアクションは「販売見積」です。 - 価値を生み出していないアクションは何か
「販売の見積」アクティビティのうち、本当に価値を生み出していないアクションは「販売見積の登録」と「販売見積の報告」になります。 - 価値を生み出すアクションをもっと効果的かつ効率的に行うにはどうすべきか
FAXで受け取った顧客の見積依頼書の写真をとって販売管理システムにアップロードすると、販売管理システムが自動的に見積を行うようにして、見積効率と見積精度を上げるようにします。 - 価値を生み出していないアクションはどうするか、削除、あるいは、削減するか、フローを変えるか、代替する手段はないか
「販売見積」のタイミングで自動的に登録されるようにします。
システムが、顧客に販売見積回答書を添付したメールを送るようにします。
アクションの改善
技術も含めて次のような企画を立てました。
機能 技術 説明 📸 画像アップロード スマホ／Webフォーム（BubbleやReact＋Spring Bootなど） 顧客担当者が写真をアップロード 🔎 文字認識（OCR） Google Cloud Vision API / Amazon Textract FAX画像からテキスト抽出 🧠 内容理解 生成AI（OpenAI GPT-4o） + プロンプト設計 「商品名」「数量」「納期」などの項目を自動抽出（構造化） 🔄 自動見積作成 販売管理システム＋ルールエンジン or 見積ロジック 抽出された内容に基づいて見積を計算 📋 PDF見積書生成 PDFMonkey, Documint など 販売見積回答書をテンプレートで生成 📨 自動メール送信 SendGrid / Gmail API / Outlook API 顧客にメールでPDFを添付して送信（RPAやワークフローで自動実行） アクションフローの自動化
上記、アクションのイベントの流れをZapierなどのワークフローシステムで自動化するとともに、最後にBAMにログの記録と通知をさせるようにしました。
機能 技術 説明 ⚙️ ワークフロー自動化 RPA（UiPath / Power Automate / Zapier） 全体の処理フローを自動化・監視・例外対応 📊 ログ・監査対応 BPM/監視ダッシュボード 各処理のログとエラー検知（BAM） 以上より、次のようなユースケースとイベントフローを設計することができます。
販売管理システムのユースケース
「販売見積の登録」ユースケースのイベントフロー- 顧客管理者が販売見積依頼書をスマホで撮影し、画像を販売管理システムにアップロードする
- 販売管理システムはOCR（Google Cloud Vision）でFAX画像からテキストを抽出する
- 販売管理システムは顧客管理サービスから顧客データを取得する
- 販売管理システムは生成AI（OpenAI GPT-4o）で見積依頼情報を構造化（商品名・数量・納期など）する
- 販売管理システムは販売管理サービスに構造化データを送信し、見積計算を依頼する
- 販売管理システムはPDF生成ツール（PDFMonkey）を使って、見積結果から販売見積回答書PDFを生成する
- 販売管理システムは電子メールシステム（Gmail）を使って、販売見積回答書を顧客にメール送信する
- 販売管理システムはBAM（Celonis）を使って、ログを記録し販売管理者に通知する
DX2：デジタライゼーション
ここでは、戦略上重要なビジネスプロセスを２つ以上を対象に、現場レベルの制約理論（TOC）を適用した業務改革（デジタライゼーション）を実施します。
DX成熟度
レベル 2: 繰り返し可能な状態 (Repeatable)
最低２回繰り返す
基本的な企業情報基盤、および、マネジメントプロセスが確立され、繰り返し可能な手順があります。
しかし、それらは依然としてプロジェクトごとに異なり、標準化が進んでいません。企業情報論理基盤
企業情報物理基盤
マネジメント基盤
ここでは、マネジメント基盤に関して次の観点で説明します。
ビジネスプロセスマネジメント
ビジネスアーキテクトは、データドリブン経営の業務改革（デジタライゼーション）を実施します。
アプリケーションマネジメント
アプリケーションアーキテクトは、業務改革（デジタライゼーション）のアプリケーションアーキテクチャを設計します。
アプリケーションエンジニアは、業務改革（デジタライゼーション）のアプリケーションを開発します。
データマネジメント
データアーキテクトは、業務改革（デジタライゼーション）のデータ要件、および、データモデルを検証します。
ITマネジメント
ITアーキテクトは、業務改革（デジタライゼーション）のIT基盤を構築します。
データドリブン経営
ここでは、データドリブン経営と、制約理論（TOC）の現場レベルのステップ2と3、つまり、制約の改善、制約への適合を実践することで、戦略上重要なビジネスプロセスを２つ以上デジタライゼーションします。
なお、データドリブン経営を実践し、デジタライゼーション対象の業務の責任者と担当者がアサインされているものとします。
次の図は、データドリブン経営と、業務改革、事業変革の活動の関係を表したものです。
解決策を考えるとき、まず、TOCを適用して課題を解決するための制約を特定し、TOCのステップ２から４で解決策を考案します。
TOCのステップ２から４、それぞれの解決策に対して実験を行い検証します。
業務改革・改善では、検証された解決策を反映した業務フローを設計します。
今回は、現場レベルのTOCなのでステップ2と3で解決策を考案します。
次の手順で具体例を説明します。問題の特定
ここでは、戦略目標「製品/部品の安定供給」、KPI「製品/部品納期遵守率」を対象にして問題を特定します。
問題の特定は、制約理論（TOC）の制約の特定に位置づけることができます。
ちなみに、TOCのスループットは、戦略目標「収益の増大」の売上高から完全変動費を引いて求めます。
業務改革の問題を特定するときは、顧客にとっての問題と内部プロセスの問題に分けて特定します。
内部プロセスの問題を特定するにあたって、戦略目標「製品/部品の安定供給」に関連すると考えらるビジネスプロセスを特定します。
次の図は、戦略目標「製品/部品の安定供給」に関連すると考えらるビジネスプロセスになります。
次に、顧客にとっての問題と内部プロセスの問題を次のように特定します。-
顧客にとっての問題は何か？
- 供給遅れによる稼働率の低下
- 生産計画の未達
- 機会損失
-
内部プロセスの問題は何か？
- 販売計画の問題
需要予測の精度が低い - 購買計画の問題
購買予測（仕入先へのフォーキャスト）の精度が低い - 部品購買の問題
サプライヤーの納期遅延 - 製品製造の問題
- 設備の能力制約（制約工程のキャパシティ不足）
- 人的リソースの制約（熟練労働者の不足、シフト管理の問題）
- 品質管理の問題（不良品発生率が高く、リワークや廃棄が発生）
- 製品販売の問題
顧客への納期遅延（在庫不足や生産遅れが原因） - 保守サービス（部品販売）の問題
- 保守部品の在庫不足
- 技術者不足による対応遅れ
- サービス対応エリアの制約（拠点数が少なく、カバー範囲が狭い）
- 顧客対応プロセスの遅れ（問い合わせから対応完了までの時間が長い）
- 販売計画の問題
原因の推定
次に、問題を発生させる根本原因は何か推定します。
そこで、上記で特定された問題の因果関係を分析して根本原因を明らかにします。
次の図は、問題の因果関係を分析して根本原因を推定したものです。
オレンジ色の問題が根本的な原因になります。
次に、下図のように、各原因がどのビジネスプロセスに関連するか明確にします。
課題の設定
ここでは、次のように、原因を取り除くという観点で課題（Issue）を設定します。
- 需要予測の精度向上
- 設備の能力（制約工程のキャパシティ不足）向上
- 人的リソースの制約（熟練労働者の不足、シフト管理の問題）解消
- 品質管理の問題（不良品発生率が高く、リワークや廃棄が発生）解決
- 保守部品の在庫の適正化
- 技術者の不足の解消
- サービス対応エリアの（拠点数が少なく、カバー範囲が狭い）見直し
- 顧客対応プロセスの（問い合わせから対応完了までの時間が長い）改善
その上で、下図のように各課題がどのビジネスプロセスに関連するか明確にします。
制約の改善
ここでは、制約理論（TOC）のステップ２「制約の改善」を適用して課題に対する解決策を次のように考えます。
- 需要予測の精度向上
AI/MLの時系列モデル（例：XGBoost、LSTM）を導入して需要を予測する。
XGBoost（eXtreme Gradient Boosting）は、勾配ブースティング決定木という機械学習アルゴリズムのことです。
LSTM（Long Short-Term Memory）は、時系列データにおける長期的な依存関係を捉えるのが得意な深層学習アルゴリズムのことです。 - 設備の能力（制約工程のキャパシティ不足）向上
段取り時間短縮、夜間稼働などで稼働率を向上させる。 - 人的リソースの制約（熟練労働者の不足、シフト管理の問題）解消
制約工程に熟練者を集中配置する。 - 品質管理の問題（不良品発生率が高く、リワークや廃棄が発生）解決
上位3要因を集中的に改善する。
不具合に対する優先順位を評価する方法にFMEAがあります。
FMEAとは、Failure Mode and Effects Analysis（故障モード影響解析）の略で、製品やプロセスにおいて起こり得る不具合（故障モード）をあらかじめ洗い出し、それが起きた場合の影響（Effects）、発生する確率（Occurrence）、および検出のしやすさ（Detection）を評価し、優先的に対策すべきリスクを特定する手法です。 - 保守部品の在庫の適正化
需要実績から安全在庫を見直す。 - 技術者の不足の解消
技術者の業務負荷バランスを最適化する。 - サービス対応エリアの（拠点数が少なく、カバー範囲が狭い）見直し
拠点の稼働率を見直し、統廃合を検討する。 - 顧客対応プロセスの（問い合わせから対応完了までの時間が長い）改善
FAQを整備するとともに初動自動応答を導入する。
制約への適合
ここでは、制約理論（TOC）のステップ３「制約への適合」を適用して課題に対する解決策を次のように考えます。
- 需要予測の精度向上
販売計画、生産計画、購買計画、および、仕入先への購買予測の連動を強化する。 - 設備の能力（制約工程のキャパシティ不足）向上
他工程を制約工程を中心にスケジューリングする。 - 人的リソースの制約（熟練労働者の不足、シフト管理の問題）解消
教育リソースを制約工程に集中させる。 - 品質管理の問題（不良品発生率が高く、リワークや廃棄が発生）解決
不良削減に合わせて検査工程を見直す。 - 保守部品の在庫の適正化
調達リードタイムを在庫計画に反映させる。 - 技術者の不足の解消
人材配置を見直し、非制約業務を外注する。 - サービス対応エリアの（拠点数が少なく、カバー範囲が狭い）見直し
物流・移動時間をエリアの再設計に反映させる。 - 顧客対応プロセスの（問い合わせから対応完了までの時間が長い）改善
業務フローの全体の時間を短縮し業務を最適化する。
実験計画の策定
ここでは、制約理論（TOC）の制約の改善、および、制約への適合の妥当性を検証するため、ランダム化比較実験の実験計画を次のように考えます。
- 需要予測の精度向上
主要製品に対するモデルを比較する（3ヶ月）。
評価指標
納期遵守率。 - 設備の能力（制約工程のキャパシティ不足）向上
1ライン限定で稼働改善施策を実施する。
評価指標
制約工程の稼働率、通過数。 - 人的リソースの制約（熟練労働者の不足、シフト管理の問題）解消
制約工程への熟練者集中を実験的に実施する。
評価指標
作業ミス率、スループット。 - 品質管理の問題（不良品発生率が高く、リワークや廃棄が発生）解決
一部製品ラインで要因別対策を実施する。
評価指標
不良率、リワーク件数。 - 保守部品の在庫の適正化
過去3ヶ月分の実績で最適在庫算出する。
評価指標
欠品率、在庫回転率。 - 技術者の不足の解消
繁忙地域への集中配置を試行する。
評価指標
対応完了時間、一次解決率。 - サービス対応エリアの（拠点数が少なく、カバー範囲が狭い）見直し
一部エリアで拠点増設をパイロット的に実施する。
評価指標
カバー率、対応時間。 - 顧客対応プロセスの（問い合わせから対応完了までの時間が長い）改善
一部署でAI自動応答および業務可視化を実施する。
評価指標
対応時間、満足度、再問合せ率。
解決策の検証
ここでは、制約理論（TOC）の制約の改善、および、制約への適合の妥当性を検証するためランダム化比較実験を行います。
業務の改革・改善
ここでは、需要予測の精度向上という課題に対する次の解決策を業務に組み込む例について説明します。
- AI/MLの時系列モデル（例：XGBoost、LSTM）を導入して需要を予測する
- 販売計画、生産計画、購買計画、および、仕入先への購買予測の連動を強化する
まず、業務改革について説明します。
現在のバリューチェーンを見ると、販売計画、生産計画、購買計画が独立して策定されることがわかります。
今回、需要予測の精度を上げるために、AI/MLを活用した需要予測に、販売計画、生産計画、購買計画、および、仕入先への購買予測を連動させます。
そこで、次のように、「販売計画の策定」プロセス、「生産計画の策定」プロセス、「購買計画の策定」プロセスを「受給計画の策定」プロセスに統合します。
そして、販売計画から仕入先への購買予測までのアクティビティフローを次のように設計します。
次に業務改善です。
現在、「需要の予測」アクティビティは、次のアクションフローのように、受注データを手動で取得後、手動で需要予測を行っています。
今回、需要予測を効率化するために、販売管理システムに受注データが登録されたタイミングで、販売管理サービスから、イベント駆動で受注明細データが需要予測サービスに送られ、定期的に需要予測モデルが見直される仕組にします。
次の図は、この仕組を表したアプリケーション連携モデルです。
販売管理サービスから受け取る受注データのカノニカルモデルは次のようになります。
販売品目に関係する品目分類基準と品目分類基準値も、このタイミングで受け取ります。
そして、需要予測サービスで管理する受注履歴の業務概念データモデルは次のようになります。
このモデルは、分析の切り口が分類基準と分類基準値のパワータイプになっています（例えば、日付分類基準が四半期であれば、日付分類基準値は、Q1、Q2、Q3、Q4になります）。
分析軸をパワータイプにすることで分析軸を柔軟に追加することができます。
※パワータイプとはサブクラスをインスタンスに持つクラスのことです。
需要予測サービスは、受注データを受け取ったタイミングで顧客管理サービスから顧客データを受取り、受注履歴データを作ります。
その際、受注日から、日付分類基準に応じた日付分類基準値を作成します。
その際、受取る顧客データのカノニカルモデルは次のようになります。
顧客に関係する顧客分類基準と顧客分類基準値も、このタイミングで受け取ります。
以上の設計の結果、上記「需要の予測」アクションフローの「需要予測」アクション以外の部分が不要になります。
DX3：スタンダーダイゼーション（標準化）
ここでは、企業全体の企業情報物理基盤（プロダクト）とマネジメント基盤（プロセス）を標準化し、DX成熟度をレベル３にし、マネジメントが統制できるレベルにします。
DX成熟度
レベル 3: 定義された状態 (Defined)
プロセスとプロダクトを標準化する
企業情報基盤、および、マネジメントプロセスが組織全体で定義され、標準化されています。
しかし、それらの定義が一貫しておらず、完全な実施には至っていません。企業情報論理基盤
全社の業務フローを設計します。
全社の業務概念データフローを設計します。
全社の業務概念データモデルを設計します。
全社のアプリケーションカテゴリを定義します。
会社全体のアプリケーション連携モデルを設計します。
企業情報物理基盤
ITアーキテクトは、DX1で明確にした企業情報物理基盤で不足している部分をすべて整備します。
その際、DX1で策定したアプリケーション戦略に従って、ストラングラーアプリケーションパターンで既存の基幹システムをマイクロサービス化します。
マイクロサービスは、アプリケーション基盤の一要素になります。
マネジメント基盤
マネジメント基盤の標準化
ここでは、マネジメント基盤に関して次の観点で説明します。ビジネスプロセスマネジメント
ビジネスアーキテクトは、全社の業務フローを設計するとともに、ビジネスプロセスマネジメント導入プロセスの設計フェーズで作成するビジネスプロセスマネジメントモデルの内容、ビジネスアーキテクチャ、ビジネスプロセスマネジメント組織（ジョブ）、ビジネスプロセスマネジメントプロセスをすべて設計します。
ビジネスプロセスマネジメントモデルの内容を設計することで、ビジネスプロセスマネジメントのポリシー、スタンダード、プロシージャが定義され、DX4以降、ビジネスプロセスマネジメントを統制することができるようになります。- ポリシー
ビジネスプロセスマネジメントの基本的な考え方・方針。何を実現すべきかを定義します。
例- 目的
全社的な業務の標準化、戦略との整合、部門横断的な連携の強化。 - 内容
本組織は、全社的な業務プロセスの可視化・最適化・継続的改善を通じて、業務の品質・効率・柔軟性を高めることを基本方針とする。BPM活動は経営戦略と整合させ、KGI/KPIを通じて評価・改善を実施する。
- 目的
- スタンダード
ポリシーを満たすための共通基準や仕様（技術的・運用的）を定めたものを定義します。
例- プロセス記述標準
UMLアクティビティ図を用いてプロセスをモデリングすること。すべての業務プロセスは「開始」「終了」を含めて記述。
プロセス階層標準
業務プロセスは３階層で整理する。
・レベル1：ビジネスプロセス
・レベル2：アクティビティフロー
・レベル3：アクションフロー - KGI/KPI標準
各ビジネスプロセスにはKGI（例：LTVなど顧客の視点のKPI）とKPI（例：納期遵守率など内部プロセスの視点のKPI）を設定すること。 -
改善サイクル標準
データドリブン経営のマネジメントサイクル（PDCA）によってプロセス改善を行うこと。
また、ビジネスプロセスマネジメントのガバナンスサイクルによってビジネスプロセスマネジメントプロセスを改善する。
- プロセス記述標準
- プロシージャ
スタンダードに基づいて具体的な手順を説明したもの。「誰が」「いつ」「どのように」行うかを定義します。
各ビジネスプロセスの業務フローとビジネスプロセスマネジメントプロセスの業務フローで記述する。
次に、ビジネスアーキテクトは、ビジネスプロセスマネジメント組織を設計後、ビジネスプロセスマネジメント組織構築計画を策定します。
なお、BPM基盤は、企業情報物理基盤で構築します。
アプリケーションマネジメント
アプリケーションアーキテクトは、全社のアプリケーションカテゴリを定義し、会社全体のアプリケーション連携モデルを設計するとともに、アプリケーションマネジメント導入プロセスの設計フェーズで作成するアプリケーションマネジメントモデルの内容、アプリケーションアーキテクチャ、アプリケーションマネジメント組織（ジョブ）、アプリケーションマネジメントプロセスをすべて設計します。
アプリケーションマネジメントモデルの内容を設計することで、アプリケーションマネジメントのポリシー、スタンダード、プロシージャが定義され、DX4以降、アプリケーションマネジメントを統制することができるようになります。- ポリシー
アプリケーションマネジメントの基本的な考え方・方針。何を実現すべきかを定義します。
例- 目的
アプリケーションの品質・安定性・セキュリティの確保と、ビジネスとの整合性の継続的確保。 - 内容
当社は、ビジネス要件に適合し、セキュアかつ高可用性を維持するアプリケーションを計画的に導入・運用・改善する。すべてのアプリケーションはライフサイクルに基づき管理され、ユーザ満足度・運用効率・セキュリティを重視する。
- 目的
- スタンダード
ポリシーを満たすための共通基準や仕様（技術的・運用的）を定めたものを定義します。
例- アプリケーションライフサイクル標準
アプリケーションを「企画 → 開発／導入 → 運用 → 保守／改善 → 廃止」の各フェーズで管理する。各フェーズにGate Reviewを設ける。 - バージョン管理標準
ソースコードおよび構成情報はGitなどのバージョン管理システムで一元管理し、main／develop／featureブランチを運用。 - セキュリティ標準
すべてのアプリケーションは年1回以上の脆弱性スキャンを受け、パッチは重大度に応じて規定期間内に適用。 - SLA／SLO標準
ミッションクリティカルなアプリは月間稼働率99.9%以上、障害一次応答時間は2時間以内とする。 - ログ／監査標準
重要業務アプリは操作ログとエラーログを収集・保存し、90日以上保管する。
- アプリケーションライフサイクル標準
- プロシージャ
スタンダードに基づいて具体的な手順を説明したもの。「誰が」「いつ」「どのように」行うかを定義します。
アプリケーションマネジメントプロセスの業務フローで記述する。
アプリケーションマネジメントのガバナンスサイクルによってビジネスプロセスマネジメントプロセスを改善する。
次に、アプリケーションアーキテクトは、アプリケーションマネジメント組織を設計後、アプリケーションマネジメント組織構築計画を策定します。
なお、アプリケーション基盤は、企業情報物理基盤で構築します。
データマネジメント
データアーキテクトは、全社の業務概念データモデルを設計するとともに、データマネジメント導入プロセスの設計フェーズで作成するデータマネジメントモデルの内容、データアーキテクチャ、データマネジメント組織（ジョブ）、データマネジメントプロセスをすべて設計します。
データマネジメントモデルの内容を設計することで、データマネジメントのポリシー、スタンダード、プロシージャが定義され、DX4以降、データマネジメントを統制することができるようになります。
それから、データセキュリティに関しては、独立してデータセキュリティのポリシー、スタンダード、プロシージャを定義することもできます。- ポリシー
データマネジメントの基本的な考え方・方針。何を実現すべきかを定義します。
例- 目的
・データ品質の確保
・部門間でのデータ整合性の維持
・法令遵守（例：個人情報保護）
・データ活用による付加価値創出 - 内容
当社は、データを経営資源と位置づけ、正確性・一貫性・安全性・可用性を維持しながら、業務および意思決定における信頼できる基盤として活用する。データの品質向上、ガバナンス、セキュリティを全社的に推進する。
- 目的
- スタンダード
ポリシーを満たすための共通基準や仕様（技術的・運用的）を定めたものを定義します。
例- データ分類標準
データは以下のように分類する。
・機密データ（Confidential）
・業務データ（Internal Use）
・公開データ（Public） - データ品質標準
データは以下の品質特性を維持すること。- 正確性
データが現実の実体を正しく表している程度を表す。 - 完全性
必要なデータが全て存在しているかどうか、その程度を表す。 - 一貫性
データが、特定のデータベースなどデータセット内で一貫して（正しいルールに貫かれて）表現されているか、あるいは、データセット間で一貫して関連付けられ、一貫して表現されているか、その程度を表す。
一貫性は、１レコード内にある属性値と別の属性値との間（レコードレベルの一貫性）、あるレコードの属性値と別のレコードの属性値の間（クロスレコードの一貫性）、あるレコードの属性値と異なる時点における同じレコードの属性値との間（経時的一貫性）において定義される。
参照キーを介したデータセット間の一貫性（例えば参照先のデータだけがないという欠落がない）を参照整合性という。 - 一意性
同じ実体を表すデータが同じデータセット内に複数存在していないか、その程度を表す。 - 適時性
データが適切な時点のものであるか、その程度を表す。
データが発生して利用可能になるまで遅延する場合、遅延の程度によってデータの可用性を定義することによって、データの適時性を判断することができる。 - 有効性
データが定義域に準拠しているか、その程度表す。
データの定義域とはデータドメインといい、データの型、形式、範囲、ルールなどで定義された、データがとり得る全体を表す。
- 正確性
- データ所有者標準
各主要データセットには「データオーナー」「データスチュワード」を必ず割り当て、責任範囲を明確化する。 - メタデータ管理標準
業務概念データモデルに対して、次の内容のビジネスメタデータを定義する。
ビジネスメタデータの例（Excel）のダウンロード
また、物理データモデルに対するテクニカルメタデータ、および、オペレーショナルメタデータを定義する。 - 個人情報管理標準
個人情報は暗号化、アクセス制御、ログ記録、匿名加工などのセキュリティ対策を講じ、法令（例：GDPR, 個人情報保護法）に準拠する。
- データマネジメントジョブ標準
本標準は、データマネジメントにおける主要ジョブの役割・責任・権限を定義し、組織全体で統一された基準のもとでデータガバナンスを実現することを目的とする。- データスチュワード（Data Steward）
- 役割
データの品質・定義・利用ルールを維持管理し、ビジネス部門とIT部門の橋渡しを行う。 - 主な責任
- 担当データ領域のデータ定義（ビジネス定義）の策定・維持
- データ品質モニタリングと改善活動の推進
- データ利用申請の承認および利用状況の監査
- データ関連の問い合わせ対応と教育
- 権限
- 担当データ領域の定義変更の提案権
- データ利用の承認／拒否権
- 任命要件
- 担当領域に関する業務知識3年以上
- データマネジメント研修の修了
- データアーキテクト（Data Architect）
- 役割
データの構造設計、統合アーキテクチャ、メタデータ設計を担い、全社的なデータ利用を最適化する。 - 主な責任
- 全社データモデル（概念／論理／物理）の設計と維持
- データ統合およびインターフェース仕様の設計
- メタデータ管理・リファレンスデータ管理の基準策定
- データベース設計レビューおよび性能最適化
- 権限
- データ設計基準の策定権
- データ統合方式の承認権
- 任命要件
- データベース設計経験5年以上
- データアーキテクチャまたは情報システム設計の実務経験
- 役割
- データサイエンティスト（Data Scientist）
- 役割
データ分析や機械学習モデルの開発を通じ、ビジネス価値の最大化を図る。 - 主な責任
- 分析要件の定義と分析計画の策定
- データの前処理、特徴量設計、モデル構築
- 分析結果の可視化と経営層・業務部門への提案
- モデル精度のモニタリングと改善
- 権限
- 分析目的に必要なデータ利用申請の提出権
- 分析結果に基づく改善提案権
- 任命要件
- 統計学・機械学習・データ分析の実務経験3年以上
- Python、Rなどの分析ツール利用経験
- 役割
- 役割
- プロシージャ
スタンダードに基づいて具体的な手順を説明したもの。「誰が」「いつ」「どのように」行うかを定義します。
データマネジメントプロセスの業務フローとして記述します。
データマネジメントのガバナンスサイクルによってデータマネジメントプロセスを改善します。
詳細は、以下のデータマネジメントタスク一覧を参照してください。
データマネジメントタスク一覧
次に、データアーキテクトは、データマネジメント組織を設計後、データマネジメント組織構築計画を策定します。
なお、データ管理基盤は、企業情報物理基盤で構築します。
ITマネジメント
ITアーキテクトは、ITマネジメント導入プロセスの設計フェーズで作成するITマネジメントモデルの内容、ITアーキテクチャ、ITマネジメント組織（ジョブ）、ITマネジメントプロセスをすべて設計します。
ITマネジメントモデルの内容を設計することで、ITマネジメントのポリシー、スタンダード、プロシージャが定義され、DX4以降、ITマネジメントを統制することができるようになります。- ポリシー
ITマネジメントの基本的な考え方・方針。何を実現すべきかを定義します。
例- 目的
・ITリソースの最適活用
・セキュリティと安定性の確保
・業務部門との連携強化
・コンプライアンスの遵守 - 内容
当社は、ITを経営の競争力強化と業務効率向上の基盤と位置づけ、IT資源を計画的かつ安全に管理・活用する。IT投資は戦略と整合し、リスク・コスト・効果の観点から適切に評価・管理されなければならない。
- 目的
- スタンダード
ポリシーを満たすための共通基準や仕様（技術的・運用的）を定めたものを定義します。
例- IT資産管理標準
すべてのIT資産は、購入から廃棄まで資産管理台帳に登録し、棚卸を年1回以上実施。資産タグを必ず貼付。 - ソフトウェアライセンス管理標準
商用ソフトは正規ライセンスを取得して使用すること。未許可のインストールは禁止。ライセンス数の超過使用は禁止。 - システム変更管理標準
本番環境に影響を与える変更は、必ず「変更管理申請書」を提出し、レビューと承認を経ること。 - バックアップ標準
業務システムのデータは毎日1回以上バックアップを取得し、暗号化して別拠点に保管。復旧テストは年2回以上実施。 - ITサービスレベル標準（SLA）
重要システムのサービスレベル：
・可用性99.9%
・初動対応2時間以内
・障害復旧4時間以内
- IT資産管理標準
- プロシージャ
スタンダードに基づいて具体的な手順を説明したもの。「誰が」「いつ」「どのように」行うかを定義します。
ITマネジメントプロセスの業務フローで記述する。
ITマネジメントのガバナンスサイクルによってITマネジメントプロセスを改善する。
次に、ITアーキテクトは、ITマネジメント組織を設計後、ITマネジメント組織構築計画を策定します。
なお、IT基盤は、企業情報物理基盤で構築します。
データドリブン経営
DX2と同様、ビジネスプロセスを選定して、標準化されたマネジメント基盤の下、業務改革を行うことで、標準化されたマネジメント基盤を検証します。
DX4：革新的な生産性向上
ここでは、標準化された企業情報基盤を適用し、企業の業務とシステムを変化に強い構造にするとともに、標準化されたマネジメント基盤の下、データドリブン経営と現場レベルの制約理論（TOC）を実践しながら価値創造の企業文化
- データスチュワード（Data Steward）
- DX成熟度
- 企業情報論理基盤
- 企業情報物理基盤
- マネジメント基盤
- データドリブン経営
DX成熟度
レベル 4: 管理された状態 (Managed)
プロセスとプロダクトを管理する
企業情報基盤、および、マネジメントプロセスが実行、監視され、測定されており、それらの効率化が図られています。
継続的な改善が必要ですが、それらの監視と測定は定着しています。企業情報論理基盤
標準化された企業情報論理基盤を適用し企業の業務とシステムを変化に強い構造にします。
企業情報物理基盤
標準化された企業情報物理基盤を適用し企業の業務とシステムを変化に強い構造にします。
マネジメント基盤
ビジネスプロセスマネジメント
スタンダーダイゼーション（標準化）で、ビジネスプロセスマネジメントのポリシー、スタンダード、プロシージャ、および、ビジネスプロセスマネジメント組織が設計されるので、この段階で、ビジネスプロセスマネジメントを実行する組織と、ビジネスプロセスマネジメントが適切に遂行されているか監督する組織を構築します。
そして、実行側のビジネスプロセスマネジメント組織にアサインされたビジネスアーキテクトは、ビジネスプロセスマネジメント計画を策定し、ビジネスプロセスマネジメントを遂行します。
監督側のビジネス組織のビジネスアーキテクトは、標準化されたビジネスプロセスマネジメントモデルに従ってビジネスプロセスマネジメントを統制します。
アプリケーションマネジメント
スタンダーダイゼーション（標準化）で、アプリケーションマネジメントのポリシー、スタンダード、プロシージャ、および、アプリケーションマネジメント組織が設計されるので、この段階で、アプリケーションマネジメントを実行する組織と、アプリケーションマネジメントが適切に遂行されているか監督する組織を構築します。
そして、実行側のアプリケーションマネジメント組織にアサインされたアプリケーションアーキテクトは、アプリケーションマネジメント計画を策定し、アプリケーションマネジメントを遂行します。
監督側のビジネス組織のアプリケーションアーキテクトは、標準化されたアプリケーションマネジメントモデルに従ってアプリケーションマネジメントを統制します。
データマネジメント
スタンダーダイゼーション（標準化）で、ビジネスプロセスマネジメントのポリシー、スタンダード、プロシージャ、および、データマネジメント組織が設計されるので、この段階で、データマネジメントを実行する組織と、データマネジメントが適切に遂行されているか監督する組織を構築します。
そして、実行側のデータマネジメント組織にアサインされたデータスチュワードは、データマネジメント計画を策定し、データマネジメントを遂行します。
監督側のビジネス組織のデータスチュワードは、標準化されたデータマネジメントモデルに従ってデータマネジメントを統制します。
ITマネジメント
スタンダーダイゼーション（標準化）で、ITマネジメントのポリシー、スタンダード、プロシージャ、および、ITマネジメント組織が設計されるので、この段階で、ITマネジメントを実行する組織と、ITマネジメントが適切に遂行されているか監督する組織を構築します。
そして、実行側のITマネジメント組織にアサインされたITアーキテクトは、ITマネジメント計画を策定し、ITマネジメントを遂行します。
監督側のビジネス組織のITアーキテクトは、標準化されたITマネジメントモデルに従ってITマネジメントを統制します。
データドリブン経営
標準化されたマネジメント基盤の下、データドリブン経営と現場レベルの制約理論（TOC）を実践しながら価値創造の企業文化を醸成します。
DX5：創造と変革
ここでは、まず、マネジメント基盤の統制されたマネジメントの下、データドリブン経営と現場レベルの制約理論（TOC）を実践し、マネジメント基盤を継続的に改善できる状態にし、DX成熟度をレベル5にします。
この段階で、仮説検証の仕組が確立するので、制約理論（TOC）の経営レベルのステップ４、「制約の克服」を適用して事業創出と事業変革を実現します。DX成熟度
レベル 5: 最適化された状態 (Optimized)
プロセスとプロダクトを継続的に改善する
企業情報基盤、および、マネジメントプロセスが最適化され、継続的に改善されています。最新の技術やベストプラクティスが取り入れられています。
イノベーションと最適化が組織の文化として根付いています。企業情報論理基盤
ビジネスアーキテクトは、事業変革に対応した業務フローを設計します。
また、ビジネスアーキテクトは、ビジネスモデルキャンバスを見直します。
データアーキテクトは、事業変革に対応した業務概念データモデルを検証します。
アプリケーションアーキテクトは、事業変革に対応したアプリケーション連携モデルを設計します。
企業情報物理基盤
マネジメント基盤
ここでは、マネジメント基盤に関して次の観点で説明します。
ビジネスプロセスマネジメント
監督側のビジネスアーキテクトは、事業変革に対応した業務フローを設計します。
そして、現場レベルの業務改革の下、実行側のビジネスアーキテクトは、ビジネスプロセスマネジメント計画を策定、実行し、監督側のビジネスアーキテクトが継続的にビジネスプロセスマネジメントモデルを改善します。
アプリケーションマネジメント
監督側のアプリケーションアーキテクトは、現場レベルの業務改革に対応したアプリケーション連携モデルを検証し継続的に改善します。
実行側のアプリケーションアーキテクトは、事業変革に対応したアプリケーション連携モデルを設計します。
そして、現場レベルの業務改革の下、実行側のアプリケーションアーキテクトは、アプリケーションマネジメント計画を策定、実行し、監督側のアプリケーションアーキテクトが継続的にアプリケーションマネジメントモデルを改善します。
データマネジメント
データアーキテクトは、事業変革に対応した業務概念データモデルを検証します。
そして、現場レベルの業務改革の下、実行側のデータスチュワードは、データマネジメント計画を策定、実行し、監督側のデータスチュワードが継続的にデータマネジメントモデルを改善します。
ITマネジメント
監督側のITアーキテクトは、事業変革対象のIT基盤を検証します。
そして、現場レベルの業務改革の下、実行側のITアーキテクトは、ITマネジメント計画を策定、実行し、監督側のITアーキテクトが継続的にITマネジメントモデルを改善します。
データドリブン経営
ここでは、制約理論（TOC）の経営レベルのステップ４、「制約の克服」を適用した事業変革の例をしめします。
問題の特定
事業変革のトリガーは、BSCのKPI、売上高のトレンドが低迷してきたことです。
これは、事業が成熟期に入っていることを意味し、事業変革する必要があることを示しています。
原因の推定
そこで、外部環境も含めて、システム思考で、売上高のトレンドが低迷してきた根本的原因を推定します。
次の図は、因果ループで、 産業機械産業を取り巻く経営環境の動向を予測した図です。
スマートファクトリ化、省エネ製品の台頭などの技術革新より産業機械の需要が増え、それによって技術革新に拍車がかかります。
また、新興国市場が成長することで、産業機械の市場が拡大し、されに産業機械の需要が増加します。
しかし、長期的に考えると、技術革新は、機械の寿命を延ばすとともに、新興国市場もやがて飽和し、産業機械の需要が低下していきます。
なので、根本的な原因として以下を推定することができます。- 機械の長寿命化による需要の低下
- 市場の飽和による需要の低下
課題の設定
事業変革の場合、どのような事業に変革するのかを課題として設定します。
左川産業では、
機械販売モデル」から「サブスクリプション型メンテナンスモデル」 にシフトすることで、新たな収益源を確保する
ことを事業変革の課題として設定しました。
解決策の考案
左川産業は、課題を解決するため、製造業者向けの産業機械を製造、販売する機械販売モデルから、部品の販売も含めた保守サービスをサブスクリプション形式で提供するサブスクリプション型メンテナンスモデルに移行することにしました。
これを「圧縮空気をサービスとして提供」する「Air as a Service」モデルと呼びます。
次の図は、新しいビジネスモデルのイメージを示したものです。
このビジネスモデルのポイントは次のようになります。- 製品＋保守サービスのセット販売
- 保守サービスは年間契約で月額制のサブスクリプション
- 市場品質分析システム（IoT）による予知保全
- 保守サービスの内製化
実験計画の策定
上記ビジネスモデルのポイントの妥当性を検証するため次のようなランダム化比較実験の実験計画を策定しました。
製品＋保守サービスのセット販売の妥当性検証
- 仮説
セット販売のほうが、単品販売よりも顧客の継続率・売上総利益が向上する。 - 実験設計
- 被験者（単位）
新規顧客（または既存顧客の新案件） - 割付方法
無作為に2群に分ける
A群：製品＋保守のセット販売
B群：製品単体販売（従来型） - 期間
6か月〜1年程度（購買からリピート・保守利用を観察） - 評価指標
顧客継続率
月次売上総利益（粗利）
顧客満足度（CSアンケート）
- 被験者（単位）
保守サービスの月額サブスクリプション契約の妥当性検証
- 仮説
従量課金よりも月額制サブスクのほうが収益が安定し、LTV（顧客生涯価値）が向上する。 - 実験設計
- 被験者（単位）
既存顧客または新規導入企業 - 割付方法
無作為に2群に分ける
A群：月額定額制（サブスクリプション）
B群：従量制課金（都度対応型） - 期間
12か月 - 評価指標
平均月間売上
LTV（顧客単価×継続期間）
解約率（チャーンレート）
- 被験者（単位）
IoTによる予知保全導入の妥当性検証
- 仮説
IoTによる予知保全導入により、故障率と修理コストが低下する。 - 実験設計
- 被験者（単位）
同型機器を導入している工場・現場（例：同じ製品ラインを持つ顧客） - 割付方法
無作為に2群に分ける
A群：IoT予知保全センサーあり
B群：センサーなし（従来の保守型） - 期間
最低6か月～1年 - 評価指標
故障件数
修理コスト
保守回数と平均対応時間（MTTR）
- 被験者（単位）
保守サービスの内製化の妥当性検証
- 仮説
保守業務の内製化により、顧客対応のスピード・品質が向上し、顧客満足度と再契約率が高くなる。 - 実験設計
- 被験者（単位）
既存保守顧客のうち保守対応を要する案件 - 割付方法
無作為に2群に分ける
A群：左川産業内製チームが保守対応
B群：外注業者が保守対応 - 期間
3か月〜6か月 - 評価指標
保守依頼から対応完了までの時間（リードタイム）
顧客満足度（NPS, CSアンケート）
再契約率
- 被験者（単位）
それから、共通の実験上の注意点は次のようになります。
- ランダム化
公平性を保つため、割り付けにはランダム化ツール（ExcelのRAND関数やR/Python）を使う。
可能であれば層別ランダム化（地域・業種別など）を行う。 - バイアス対策
実験参加者や営業側に割り付けを知らせない シングルブラインドが理想。
難しい場合は、検証者が評価時にバイアスを排除する仕組みを設ける。 - 統計的検定
指標の差についてt検定やカイ2乗検定などで有意性を確認。
効果量（Cohen’s d等）も併せて評価。
解決策の検証
ここでは、上記ランダム化比較実験を実施しビジイネスモデルのポイントを検証します。
業務の改革・改善
検証した結果、問題ない場合、ビジネスモデルを移行するアクションプランを策定し遂行します。
それから、ビジネスモデルキャンバスを次のように更新します。
現行ビジネスモデルと違う点はつぎのようになります。- 保守サービスの内製化によって、チャネルの保守サービス会社がなくなっている点
- 月額制のサブスクリプションにしたことによって、収益が保守サービス料金（月額）になっている点
- 市場品質分析システム（IoT）の導入によって、キーリソースに市場品質分析が追加されている点
AIを前提としたビジネスプロセスの再設計
次に、AIを前提として、下図のオペレーション（赤い枠の部分）を一気通貫で自動化することで戦略目標「製品/部品の安定供給」が実現できるようにビジネスプロセスを再設計します。
次の図は、市場品質分析システム（IoT）の導入によって戦略目標「製品/部品の安定供給」が実現されることを示したアプリケーション連携モデルです。
このモデルは、各マイクロサービスにはAIエージェントが組み込まれているAIを前提とした（AIネイティブの）モデルで、次のようにオペレーションを自動化します。- 市場品質分析サービスは、空気圧縮機の「稼働データ（温度・振動・圧力など）」と「状態情報」を受取り、その内容を解析し、故障兆候・異常がある場合、顧客のその旨を通知して保守サービスを促します。
- 市場品質分析サービスは、IoTセンサーなどから取得した空気圧縮機の稼働データ（温度、振動、電力、負荷、使用頻度など）をAIで分析し、製品（空気圧縮機）自体が動作を最適に調整するようフィードバックします（空気圧縮機の自己最適化）。
例- IoTセンサー → 市場品質分析サービス
圧縮機の状態（温度・圧力・稼働率・電力など）を常時送信 - 市場品質分析サービス（AI）
受信したデータをもとに、異常兆候を検知（予知保全）
個別環境における最適運転条件をリアルタイムで推定
同一型番でも、顧客の使い方に応じて個別最適化された制御ロジックを算出 - 圧縮機へのフィードバック（自己最適化）
AIが算出した最適化パラメータを圧縮機へ送信（例：クラウド経由またはエッジ経由）
圧縮機が以下を自律的に調整
モーター回転数（インバータ制御）
負荷制御アルゴリズム（ON/OFF間隔のチューニング）
熱効率のための冷却タイミング
自動スリープ・ウェイク機能の最適タイミング
エネルギー効率と寿命のバランス取り（たとえばピーク時は寿命より効率優先）
- IoTセンサー → 市場品質分析サービス
- 顧客からの製品の発注を受けた販売管理サービスは、在庫管理サービスに部品の引当を依頼し、在庫がない場合、購買管理サービスに部品の購買を依頼します。
- 部品が入荷されたら購買管理サービスは、在庫管理サービスに部品の入庫依頼をし、支払管理サービスに代金の支払を依頼します。
- 部品が入庫されたら、在庫管理サービスは、生産管理サービスに製品の製造依頼します。
- 工場は、スマートファクトリ化されており、製品の製造工程はすべてロボットが自動的に実行します。
- 製品ができたら生産管理サービスは、品質管理サービスに製品の検査依頼をします。
- 製品の検査依頼を受けた品質管理サービスは、品質管理者に製品の品質検査を促します。
- 製品の品質検査が終了すると、品質管理サービスは、出荷管理サービスに製品の出荷を依頼します。
- 出荷依頼を受けた出荷管理サービスは、出荷担当者に製品の出荷を依頼します。
- 出荷担当者は、ドローンや自動運転車で製品を出荷します。
- 顧客に製品が納品されると、顧客は出荷管理サービスに製品を受け取ったことを通知します。
- 出荷管理サービスは、それを受けて、請求管理サービスに代金の請求を依頼するとともに、顧客管理サービスに、戦略目標「製品/部品の安定供給」のKPI「製品納期遵守率」の更新を促します。
- 顧客管理サービスの「納期遵守率」はリアルタイムでホームページ上に表示されます。
- データ分類標準
- 既存顧客のLTV=（取引期間における顧客の粗利益）−（取引期間における顧客維持コスト）と考える。
