エンタープライズ アーキテクチャの概要とビジネス アーキテクチャの詳細な説明

編集者リード: エンタープライズ アーキテクチャは、企業がビジネスおよび IT 戦略計画を完了するのに役立ちます。また、エンタープライズ情報計画の中核でもあり、個人のキャリアの健全かつ長期的な発展にも役立ちます。この記事の著者は、エンタープライズ アーキテクチャとビジネス アーキテクチャ設計の全体像を分析しています。興味のある方は見てみましょう。

1) 会社にとって

エンタープライズ アーキテクチャは、企業がビジネスおよび IT 戦略計画を完了するのに役立ちます。ビジネス戦略の観点からはビジョン/ミッション、目標/目的/原動力、組織構造、企業の機能と役割を定義し、ベストプラクティスに関するガイダンスを提供します。

エンタープライズ アーキテクチャは、企業のビジネス戦略と IT 戦略の間の架け橋および標準インターフェイスであり、企業の情報化計画の中核です。

2) 個人的に

CIO になるなど、職業の健全な長期的発展に貢献する最高情報責任者は、情報テクノロジーの使用を指導することで会社の目標をサポートし、テクノロジーとビジネス プロセスの両方の知識を持ち、組織のテクノロジー展開を調整することがよくあります戦略とビジネス戦略が緊密に適合する最適な候補です。

1. エンタープライズアーキテクチャのパノラマビュー

1. エンタープライズアーキテクチャのモジュール分割と主な作業内容

エンタープライズアーキテクチャは、BA(Business Architecture、ビジネスアーキテクチャ)、DA(Data Architecture、データアーキテクチャ)、AA(Applications Architecture、アプリケーションアーキテクチャ)、TA(Technology Architecture、技術アーキテクチャ)の4つで構成されます。

エンタープライズ アーキテクチャは全体的な戦略計画によって推進されます。戦略、BA、DA、AA、TA の関係を見てみましょう。

図 1-1 ストラテジーの実行シーケンス BA、DA、AA、TA

図に示すように、戦略、BA、DA、AA、TA は実際には次の 3 つのレベルに配置されます。

  • 企業戦略
  • 事業構造
  • ソリューションアーキテクチャ

これら 5 つの中心的な関係は次のように要約できます。

  • 戦略は企業の高度な設計であり、戦略的機能の構築はビジネスアーキテクトの要求です
  • ビジネスアーキテクトの仕事は「戦略はイン、ビジネスアーキテクチャはアウト」です。
  • ビジネス アーキテクチャはビジネス アーキテクトの設計ですが、データ、アプリケーション、およびテクニカル アーキテクトのニーズでもあります。

連動して、上層が下層を駆動し、下層が上層をサポートします。

                                        図 1-2 戦略、BA、DA、AA、TA の関係

2. 戦略からアーキテクチャ、実装までの実際のプロセス

上記の内容を通じて、戦略、ビジネスアーキテクチャ、ソリューションアーキテクチャの関係が分かりましたので、次に、アーキテクチャのロードマップと実装計画のリンクが実際の業務でどのように機能するかを見てみましょう。

                                                     図 1-3 戦略からアーキテクチャまでの実装プロセス

実行のキーポイントは、ポストに釘付けにすること(左側)、文書に落とし込むこと(右側)、そして組織調整、技術調達、プロジェクトの研究開発などの作業パッケージの詳細化です。主に以下のようなリンクがあります。

  • 戦略:会社の経営陣が主導し、プロセス全体を通じて企画開発部門がサポートし、出力: 「xx-xx 年の戦略計画」
  • ビジネスアーキテクチャ:情報技術部アーキテクトチームのビジネスアーキテクトが担当、成果物:「ビジネスアーキテクチャブック」
  • ソリューションアーキテクチャ:情報技術部のアーキテクトチームが担当、成果物:「テクニカルソリューションブック」
  • アーキテクチャ ロードマップ:予算がかかり、CI0 が主導して策定し、取締役会によって承認され、出力: アーキテクチャ ロードマップ
  • 実施計画: CIOが主導して策定、アウトプット:実施計画
  • プロジェクト管理・統制:研究開発プロジェクトはPMO、購買プロジェクトは部長室が担当

ここで付け加えておきたいのは、実施計画は「アーキテクチャ設計図から研究開発まで」だけではなく、「アーキテクチャ設計図からIT・非IT全般」までの計画であるということだ。

  • IT 側:ビジネス アーキテクチャの青写真をサポートするために必要な「IT 機能」とは何ですか? プロジェクトは研究開発ですか、それとも購入ですか? これに応じて、技術調達の作業パッケージと人材育成の作業パッケージを特定します。
  • IT 以外の側面:ビジネスの青写真をサポートするために必要な「組織能力」とは何ですか? 本人確認機関調整業務パッケージ、新部門業務パッケージ、人材育成業務パッケージに対応。

2. 戦略主導のビジネス アーキテクチャ設計

1. ビジネスアーキテクチャ(BA)とは何ですか?

ビジネス アーキテクチャについて、OMG ビジネス アーキテクチャ グループは次の定義を与えています。ビジネス アーキテクチャは、コーポレート ガバナンス構造、ビジネス機能、およびバリュー ストリームの正式な青写真です。ビジネス アーキテクチャは、企業のガバナンス構造、ビジネス機能、ビジネス プロセス、ビジネス データを明確に定義します。その中で、ビジネス機能は企業が何を行うかを定義し、ビジネスプロセスは企業がそれをどのように行うかを定義します。

具体的には次のとおりです。

  • ビジネス機能はビジネスプロセスによって実装されます
  • ビジネス プロセスは、ビジネス ステップ、ビジネス ロール、ビジネス データ、ビジネス イベント、およびビジネス ルールで構成されます。

2. ビジネスアーキテクチャの背景

ビジネスアーキテクチャの利用シーンをより深く理解するために、海外と国内のビジネスアーキテクチャの背景を学びましょうビジネスアーキテクチャは、部門横断、組織横断のビジネス要件です。単一の小さなシステムのライフサイクル。リンク。

1) クロスシステムプランニング ~世界的に台頭するビジネスアーキテクチャの背景~

外国のソフトウェア システムの長期開発、長年の実践を経て、1962 年にハーバード ビジネス ジャーナルに掲載された記事「情報システム マスター プラン」は、部門間および組織間の需要計画への序章を開きました。その後数年間、IBM などの企業は多くの実践を実施してきました。

1982 年、IBM はビジネス システム プランニング (BSP) 方法論を発表しました。これは業界に大きく永続的な影響を与える重要なイベントでした。

その後数年で、Togaf、FEAF などのビジネス アーキテクチャが急速に発展しました。

上記の歴史は、ビジネス アーキテクチャがクロスシステムから生まれ、クロスシステムの要件に注意を払っていることを示しています。開発者の観点から見ると、ビジネス アーキテクチャは部門間および組織間のビジネス要件です。

2) 情報孤立 - 中国でビジネスアーキテクチャが「発火」する機会

中国では、ビジネス アーキテクチャに関して、情報の島が話題になるという現象があります。どうしてこれなの?この国がビジネス アーキテクチャの設計に本格的に注目し始めたため、情報の島の問題点を解決することから始めました。

21世紀初頭、国内の情報化プロセスは部門情報化から企業情報化へと進展しました。エンタープライズ部門間(グループ子会社間)の相乗的連携の需要により、IT情報システム間の情報共有と相乗的連携の需要が高まり、同時に情報の孤島(財務、人事、調達、販売、 OA、CRMなど)戦争用)。

情報島の3大デメリットがあるため、中国ではこのビジネス構造が普及していますが、その主なデメリットは以下の3つです。

  1. 調整されていない - 非効率的
  2. 冗長な建設 - 企業資源の無駄遣い
  3. 開発機会の遅れ - これが最も大きな影響を及ぼし、機会を逃すと大手企業に追い抜かれ遅れをとってしまいます。

では、情報の島の問題をどのように解決すればよいのでしょうか?

一連のシステムを個別に構築する前に、ビジネス アーキテクチャを設計し、統一された青写真を定義することが重要です。データの 1 つのマップ、データ共有、プロセス統合、サービス オーケストレーションはすべて、統一されたブループリントに基づいて実行されます。

ビジネス アーキテクチャはクロスシステムです。では、ビジネス アーキテクチャとサブシステムとの関係は何ですか?

図 2-1 ビジネス アーキテクチャとサブシステムの関係

写真の大きな V と小さな V は何を意味しますか?

  • 大きな V は、ビジネス構造、段階的な実装、およびソリューションのオンラインでの受け入れを表します。
  • 2 つの小さな V は、サブシステム要件分析、プログラム開発、およびシステム テストを表します。

大きな V の部分は、計画全体のライフサイクルです。ビッグ V の要件段階では、部門横断および組織横断的な明確なビジネス要件 (多くの場合、システム横断的なもの) を調査して定義する必要があります。例えば、顧客修理サービスという業務機能では、当然のことながら、電話応対、顧客情報の確認、連絡内容の記録といった顧客サービスの一連の業務をサポートするために、コールセンターシステム、CRMシステム、作業指示システムの連携・連携が必要となります。修理レポートを作成し、メンテナンスエンジニアを訪問させます。

小さな V の部分は、特定のシステムのライフサイクルです。小さな V の要件段階では、このシステムの要件を分析して明確に定義する必要があり、これらの要件は多くの場合システム内にあります。たとえば、CRM システムは顧客プロファイル管理を担当します。

要約すると、スキーム レベルとサブシステム レベルという 2 つのライフ サイクル レベルが同時に存在します。典型的な例を挙げると、企業が ERP システムを構築したい場合はどうすればよいでしょうか。

1) プロジェクト承認段階

広範囲かつ多くの部門が関与するプログラムであるため、ビジネスアーキテクチャの設計を行う必要があります。このとき、ビジネスアーキテクトはビジネスアーキテクチャの設計を担当し、「ビジネスアーキテクチャブック」を提出します。

2) プロジェクトの第 1 フェーズ

前提条件は主にシステム A の要件、開発、テストなどに関連します。

この時、要件分析者が突撃して「システムA要件仕様書」を担当しましたが、当然、要件分析者は上流の「ビジネスアーキテクチャ文書」の全体合意を参照する必要があります。

※これはあくまで仮説であり、実際の運用においては、ある業務機能を実現するためにシステムA、システムB、システムCの一部の機能を同時に開発する必要がある場合があり、システムA、システムB、システムCのすべての機能が同時に開発されることを意味するものではありません。プロジェクトの最初のフェーズは同じシステムに属している必要があります。

3) フェーズ II およびフェーズ III 機能

この前提は主にシステム B の要件、開発、テストなどに関係します。

このとき、要件分析者が突撃して「システムB要件仕様書」を担当しましたが、当然、要件分析者は上流の「ビジネスアーキテクチャ文書」の全体合意を参照する必要があります。

3. 実践戦略:ビジネスアーキテクチャの実際の作業内容

ビジネス アーキテクチャが成功するためには、まずアーキテクトが正しいことを行う必要があります。つまり、ビジネス アーキテクチャの実際の作業内容について十分な経験を持っていることが欠かせません。

逆に、ビジネス アーキテクト分析が存在しないということは、ビジネス アーキテクチャのブループリント計画項目が存在しないことを意味し、投資の役割からプログラム設計、実装計画、IT 作業パッケージと非 IT 作業パッケージの特定に至るすべてのフォローアップ作業に影響します。

ビジネス アーキテクチャ = ビジネス機能 + 組織構造 + ビジネス プロセス + ビジネス データ

ビジネスアーキテクチャーの実際の仕事内容は何ですか?

ビジネス アーキテクチャの前身は、1982 年に IBM がリリースした BSP などのクロスシステム プランニング手法です。したがって、ビジネス アーキテクチャは本質的にクロスシステム プランニングです。

ただし、ビジネス アーキテクチャの内容は、システム間の要件分析の範囲をはるかに超えており、システム間のビジネス アーキテクチャの青写真計画のより広い範囲をカバーしています。その理由は、ビジネス アーキテクチャが戦略から実行、つまり企業の街頭戦略、その後の IT 実装、非 IT 実装への橋渡しの役割を果たさなければならないからです。

はい、ビジネス アーキテクチャには、IT 以外の部分の青写真も含まれています。

洗練されたビジネス アーキテクチャの実際の作業モデルを見てみましょう。

                                                     図 2-2 ビジネス アーキテクチャのブループリント

大まかに言えば、ビジネス機能はビジネスの内容を定義しますか? 誰が組織構造を定義するのでしょうか? ビジネスプロセスをどのように定義するか? ビジネス データは必要なサポートを提供するため、ビジネス機能、組織構造、ビジネス プロセス、およびビジネス データがビジネス アーキテクチャの青写真の中核を構成します。

同時に、ビジネス モデルは、エンタープライズ製品、エンタープライズ コア リソース、顧客、パートナー、チャネル、コスト、利益の間の本質的な関係を明らかにします。最新のツールであるビジネス モデルも、ビジネス アーキテクチャの青写真に必要な計画項目です。

細かいところで言えば、まずビジネスチャネルはどこにあるのか。組織構造は部門、役割、機能を中心に展開しており、組織構造、ビジネスチャネル、パートナーは密接に関連しています。したがって、ビジネス アーキテクトは、組織構造を整理する際に、チャネル戦略とパートナー戦略を組み合わせて、ビジネス アーキテクチャの青写真の「第一級市民」であるビジネス チャネル計画とパートナー計画を定義する必要があります。

第二に、バリューチェーンはどこにあるのでしょうか? バリュー チェーン モデルは、企業のすべてのビジネス活動を全体的に説明するものであり、ビジネス アーキテクチャの青写真を計画する際に必ず実行する項目です。ビジネス機能は 3 つのレベルに分けられ、層ごとに分解できます。

  • トップレベルの分解 - バリューチェーンモデルの作成
  • 第 1 レベルの分解 - 機能ドメインの分解を行う
  • 2 レベルの分解 - 機能的なサブドメイン分解を実行します。

3 番目に、ビジネス プロセス = メイン プロセス + ブランチ プロセス + ビジネス ルール:

メインプロセスは汎用性が高く、変更が容易ではありません。たとえば、電車の切符を買うとき、「投票券の受け取り、支払い」というプロセスは安定しています。

ブランチプロセスは高度にパーソナライズされており、頻繁に変更されます。例えば、座席選択、窓側席、非窓側席、座席券、寝台(中段上段・下段)、小児券、大人券、学生券の分岐処理も分岐処理に入る。

ビジネス ルールは非常に詳細で細分化されているため、対応するビジネス ルールを定義しながらビジネス プロセスを定義することをお勧めします。

要約すると、ビジネス アーキテクチャの青写真の内容は明確である必要があります。包括的!直感的!詳しい!

上記でビジネス アーキテクチャの内容を学習しましたが、直感的には不十分かもしれませんが、ケースを使用して各モジュールの理解を深めます。

1) ビジネスアーキテクチャ設計図の 5 つの要素

ビジネス アーキテクチャの青写真の 5 つの要素を利用して、中国鉄道 12306 プラットフォームのビジネス アーキテクチャを垣間見ることができます。

  • 対象業務機能:オンラインチケット購入、オンライン決済、オンライン払い戻し等
  • 目標組織体制:当初の組織体制をベースに、新たなIT運用保守センターを構築
  • ターゲット ビジネス プロセス: 最初にログインし、次にチケットを取得し、次に支払いを行い、支払いが超過した場合はチケット ソースを解放します。
  • 対象となるビジネス モデル: オンライン チケット購入、トラブルと労力の節約 (これは単なる価値提案です)
  • 対象となるビジネスデータ:ユーザーアカウント、列車時刻表、座席データ、注文、支払い記録など。

2) ビジネスチャネル、パートナー、バリューチェーン

次の図は、証券会社の業務機能とそれに対応するビジネスチャネルを分析したものです。

図 2-3 バリューチェーン別事業分析

バリューチェーンにはコアビジネス層とサポート層があり、ここでのコアビジネス層はバリューチェーンにおけるビジネス機能やサービスを最上位に分解したものに属します。

仲介業務には、顧客開拓、トレーディング機能、顧客サービスが含まれており、業務機能は最上位分解、第一階層分解、第二階層分解の3階層に分かれており、この3つが業務機能の最上位分解となります。

この図から、証券会社には仲介業務、自己運営業務、資産運用業務、企業金融業務の4つの事業が柱であることが分かります。

関連する従来のチャネルは主に事業部門のカウンターであり、関連する電子チャネルは総合サービスポータル、クライアント端末、モバイルAPPなどであり、企業の従業員は総合管理ポータルを通じて日常業務と調整を完了できます。

4. 実践的な戦略: 戦略主導のビジネス アーキテクチャのステップ

計画を立てる際には、まず現状を把握し、次に期待値を与え、目標と期待値とのギャップを分析するためにGAP分析手法を使用することがよくあります。誰かが初心者にこれを言ったとしても、それだけでは十分ではないかもしれません。少なくとも次の質問に答える必要があります。

  • ビジネスアーキテクトは正確に何を分析する必要があるのでしょうか? 戦略的推進とは何でしょうか? ——政策文書を指定していただけますか?戦略的アプローチ? 市場調査?友達とベンチマーク?
  • 戦略から設計図まで、その中間のロジックは何でしょうか? ——小さな目標に分解することはできますか?ちょっとした戦略立案?
  • まず何をすべきでしょうか?——小規模な請求書発行システムであっても、まずビジネスリサーチが必要ですよね。

1) 着陸: 設計ステップ

著者が共有する戦略主導型ビジネスアーキテクチャ(BA)設計の3ステップ手法を見てみましょう。

図 2-4 ビジネス アーキテクチャの設計ステップ

図の 3 つの主要なステップは明確であり、現実に非常に近いものです。

利点 1: 明確な戦略主導の出発点。この手法では、3 種類の戦略推進要因 (Drvier) が明らかにされています。実際には、追跡調査、計画、実行のきっかけとなるのは 3 つのうちの 1 つであるためです。

利点 2: 最初のステップの研究リンクを含む、明確な研究リンク。

利点 3: 戦略からブループリントへの移行ロジックを強調する 2 番目の大きなステップでは、ビジネス アーキテクチャの目標/戦略をしっかりと計画することによってのみ、ブループリントが戦略を完全にサポートできるようになります。このステップは、高レベルのビジネス アーキテクチャ設計に属します。

利点 4: ターゲットの青写真と 3 番目の大きなステップであるギャップ分析にも同様に注意を払います。

BAターゲットブループリントを設計するステップは、ギャップリンクが必要なリンクである低レベルのビジネスアーキテクチャ設計に属し、ビジネスアーキテクチャの増分を特定し、対応する実装措置を与える必要があります。

ギャップ分析の価値は、継続的なアーキテクチャ ガバナンスに必要であることであり、BA 計画での適用に加えて、AA、DA、および TA 設計にも適用されます。

2) 要点: ドライバーをクリアし、研究をしっかり行う

ビジネス アーキテクチャの設計で最初に行うべきことは、戦略的推進要因が何であるかを 100% 明確にすることです。

ビジネス アーキテクチャの設計でよく行う必要がある 2 番目のことは、リサーチです。研究を通じて、企業のマクロ環境と業界動向を幅広く理解し、戦略の原因と結果、戦略の内部と外部を深く理解し、企業の競争環境と友人の動向を理解することができます。そしてビジネスを水平方向に。

一見すると研究範囲が非常に広く、混乱してしまいます。よく見るとルールがあり、経営者インタビュー、戦略の裏話、参考になる事例の3本がメインです。

図 2-5 ビジネス アーキテクチャ設計で調査する必要があるコンテンツ カテゴリ

3) 重要なポイント: 戦略から青写真までの内部ロジック

戦略から青写真に至る内部ロジックは、次の 4 つの概念によってサポートされるスケルトンです。

  1. ドライバー: 戦略的ドライバー
  2. 目標: ビジネス アーキテクチャの目標
  3. 戦略: ビジネス アーキテクチャ戦略
  4. ブループリント: ビジネス アーキテクチャ ブループリント

これは大企業であり、戦略からブループリント構築ロジックまでデジタル調達変革をどのように推進するかについては、次の点を理解するのに役立つと思います。

図 2-6 戦略からブループリントまでの内部ロジック

  1. 図の上から下へ、Driver(ドライバー)、Goal(目標)、Strategy(戦略)、Blueprint(ブループリント)の 4 層構造になっています。
  2. ドライバー層: 1 つの戦略的ドライバー、企業のデジタルへの変革
  3. 目標レイヤー: 3 つのビジネス アーキテクチャの目標。デジタル トランスフォーメーションの具体的な目標の分解として理解できます。
  4. 戦略層: 10 のビジネス アーキテクチャ戦略。改善が必要な 3 つの目標として理解されます。最も重要な点は、組織ビジネス構造の改善、ビジネス機能の向上など、ビジネス アーキテクチャの青写真の 5 つの要素を中心に 10 の戦略が完全に展開されていることです。
  5. ブループリント層: ビジネス アーキテクチャ ブループリントの 5 つの要素に従ってブループリントを定義します。これはビジネス アーキテクトの主な作業です。

要約すると、戦略からブループリントへの内部論理の主線は、「ドライバーの決定 - ターゲットの分解 - 戦略設計 - ブループリントの定義」です。ロジックは明確で、イノベーションには十分な根拠があります。

ビジネス アーキテクトが戦略的意図を真に洞察し、戦略的動機を正確に理解した場合にのみ、その後のビジネス アーキテクチャ設計作業は追跡可能になります。作業負荷がどんなに重くても、それはひどいことではありません。

4) ツール:GAP分析

  • 内容 1: ベースラインのビジネス アーキテクチャとターゲット ビジネス アーキテクチャの概要をリストします。
  • 内容 2: 比較分析、GAP の特定 - ビジネス能力ギャップ、IT 能力ギャップ

5. 実践事例

1) デジタル変革 – 推進要因を特定し、適切な調査を行う

①進む:ドライバーを決める

このプロジェクトは、鉄道デジタル サービス変革プロジェクトであると想定されます。

ビジネス アーキテクト (Zhang San) は、ビジネス アーキテクチャの推進力がビジネス全体の出発点であり、特定して徹底的に理解する必要があることを知っています。

Zhang San 氏は、デジタル変革プロジェクトの原動力は、会社が策定したばかりの「企業戦略計画」であることを知りました。

「全社戦略計画」では、デジタルサービス変革の背景を説明しています。近年、インターネット技術の発展により、あらゆる階層のサービスレベルが向上し、人々の衣・食・住・交通・医療・学習・生活が大幅に容易になりました。遊びなど 企業の観点から見ると、インターネットやビッグデータなどのテクノロジーの助けを借りて、デジタルトランスフォーメーションを積極的に推進し、顧客中心のサービスモデルを採用することで、顧客満足度と企業競争力を向上させることができます。

「全社戦略計画」におけるデジタル変革戦略の核心表現は、人間本位・顧客本位のサービスコンセプトの確立、サービス手法の革新、サービス水準の向上、デジタルサービス変革の推進、サービスレベルの向上である。

②昇進:研究のための経営者面接をしっかり行う

経営陣へのインタビューは、ビジネスアーキテクトが業界を理解するためのものではなく、経営陣の懸念や主な見解を理解するために行われます。

面接を通じて、ビジネス アーキテクトは次のことを理解する必要があります。

  • 現在の状況: 経営陣は現在の主な欠陥をどこに見ていますか? たとえば、チケットを予約するのが不便です
  • 目標: 経営陣は変化によって何を達成したいと考えていますか? たとえば、経営者はオンラインの総合サービス ポータルを設立したいと考えています。
  • アクション: 経営陣はどのようなアクションが可能だと考えていますか? インターネットの利用など
  • ポリシー: 経営陣はどのような関連ポリシーに細心の注意を払っていますか?
  • ベンチマーク: 経営陣が特に注目するベンチマーク企業はどこですか? 例: 外国企業によるチケット販売の慣行
  • その他:企業イメージの向上など、経営上の懸念事項

③宣伝:研究を進める上で参考になる事例紹介

研究には参考となるベストプラクティスやベストケースの調査も必須です。

その理由は、業界の各段階におけるベストプラクティスやベストケースは、その時点での業界の実際のレベルを反映しているためです。したがって、ビジネス アーキテクトが業界の現在のベスト プラクティス事例を収集して分割すると、担当するアーキテクチャ設計における設計の方向性をより適切に把握し、設計基準を策定することができます。

2) デジタル サービスの変革 - BA の目標と戦略を決定する

ビジネス アーキテクチャの目標と戦略には、次の 2 つの側面が含まれます。

  • 内容 1: ビジネス機能の欠点を説明し、ビジネス アーキテクチャの目標を決定する
  • 内容 2: 組織構造、ビジネスプロセス、ビジネス機能、ビジネスモデル、チャネルイノベーションなどの観点から具体的な戦略を説明します。そして、外国規格、ベンチマーク分析、ユーザー調査、ユーザー像、データ統計、技術トレンド、機会ノードなどの根拠を説明します。

① 進化:ギャップ分析

基本的なビジネスアーキテクチャ:

図 2-7 ベースライン アーキテクチャ

目指すビジネスアーキテクチャ:

図 2-8 ベースライン アーキテクチャ

上記のケースでは、GAP 分析を通じてビジネス能力のギャップと IT 能力の欠点を特定し、それによってビジネス アーキテクチャの目標と戦略を特定しました。これはボトムアップのアプローチです。

ビジネスモデルモジュール対応する戦略を示します。

例: 上図のバリューチェーン分析から、新しいビジネスニーズは、電子商取引ビジネスと旅行代理店を通じて実現できる付加価値サービスであることがわかります。私たちの目標は収益を増やすことであり、それを上乗せすることもできますが、下向きに考えると、電子商取引事業や旅行代理店に加えて、サービスポータルのチャネルを通じてユーザーにリーチする保険代理店になることもできます。

②プロモーション:目標と戦略の策定

ビジネス アーキテクチャの目標と戦略をしっかりと計画することによってのみ、その後のビジネス アーキテクチャのブループリント定義が戦略を完全にサポートすることを保証できます。

ビジネス目標と戦略的リンクの決定は、ビジネス アーキテクチャ設計の高レベルの部分です。後続のビジネス アーキテクチャ ブループリント定義は、ビジネス アーキテクチャ設計の低レベルの部分です。前者は後者の開発方向を導き、「ビジネスアーキテクチャの目標と戦略の決定」のつながりの重要性を示しています。

このステップでは、次の 3 つのアプローチがあります。

  1. トップダウン: ドライバーをサブ目標に分解し、サブ目標をビジネス アーキテクチャ戦略にマッピングする
  2. ボトムアップ: ギャップ分析を通じて弱い取締役会を見つけ、ビジネス アーキテクチャの目標と戦略を特定します。
  3. 上記 2 つの方法を組み合わせて、相互に検証するサイクルを展開します。

鉄道システムのデジタル変革とサービスレベルの向上が原動力ですが、この究極の目標をどのように達成できるのでしょうか?

答えは次のとおりです。

  • 利便性:オンラインチケット予約サービス、コールセンターサービスの提供など
  • 効率化:改札機や改札機を活用し、検知効率と精度を向上させ、人件費も削減
  • 収益の追加: サービス ポータルの提供

図 2-9 目標と戦略の決定

3) デジタル サービス変革 - BA ブループリント (組織構造) を定義する

図 2-10 組織ビューの内容

組織構造ビューには、組織構造、ビジネス チャネル、パートナーの 3 つのモジュールが含まれています。

組織構造と改善では主に部門設定、職務設定、職務責任などについて説明し、パートナーと改善では主にサプライチェーンの上流および下流パートナーとの関係強化について説明します。以下に示すように、ビジネス チャネルのイノベーションもビジネス アーキテクチャ設計における一般的な戦略です。

組織構造:GAP分析の手法を用いて現状の組織構造と目標とする組織構造を描き、その変化点を示したのが下図です。

図 2-11 組織構造の GAP 分析

ビジネスアーキテクトの初心者は、組織構造には何も設計する必要がないと考えがちですが、実際には、組織構造を一度変更する必要があると、必ず大きな影響が生じます。

上の写真を見ると、以前は自社でIT開発を行っていた同社が、今後は開発をしながらITの運用保守も自社で行う予定であることがわかります。これに応じて、IT 運用および保守センターが企業の組織構造に追加されました。

ビジネスアーキテクトは、組織構造の変更の可能性を早い段階で特定する必要があります。新しい部門、部門の強化、人事機能の強化のいずれであっても、それらはすべて TOGAF の機能増分に属し、後続の非 IT 作業パッケージによって実現する必要があるためです。

それだけではなく、組織構造の変化は、運営・管理、管理・監督、業績評価に至るまで、企業全体のガバナンス構造にも影響を与えます。

つまり、ビジネス アーキテクトはクロスシステム ソフトウェア要件アナリストとして格下げされることがよくありますが、ビジネス アーキテクチャの青写真計画のタスクを実際に引き受けるビジネス アーキテクトは、多くの「非 IT」計画を実行できなければなりません。

4) デジタル サービス変革 - BA ブループリント (ビジネス チャネル) を定義する

百度百科ではチャネルについて「ある目的を達成するための手段の比喩」と説明されており、ビジネスチャネルはユーザーがビジネス目標を達成するための手段である。下図に示すように、車掌は乗車券引換端末のチャネルを通じて利用者の運賃引換手続きをお手伝いし、旅客運送会社は大型画面を通じて乗客に列車番号情報を通知します。

ビジネスチャネルのイノベーションの例:

図 2-12 ビジネスチャネル設計のケーススタディ

ウェブサイト、モバイルアプリ、運賃補充端末、大型スクリーンにより、チケット購入、運賃補充、列車番号閲覧のオンラインとオフラインの連携が実現され、ユーザーエクスペリエンスと企業の内部効率が向上します。

上の図からわかるように、ビジネス チャネルは完全に独立したビジネス アーキテクチャの青写真計画項目ではなく、ビジネス プロセス、ビジネス機能、組織構造と共鳴しています。したがって、ビジネスチャネルを計画する際には、これらも考慮する必要があります。

チャネル連携に関して、一部の同業者は次のようにまとめています。

  • 低レベル: 孤立した情報、多数のサイロ、顧客は携帯電話でチケットを購入したが、PC ではチケットを見つけることができなかった
  • 一般レベル: 情報共有、複数のフロントエンドが統一されたバックグラウンド システムを共有
  • 高レベル: チャネルの連携、プロセスの統合、複数のポジション、複数のフロントエンド、および複数のアプリケーション間のスムーズなプロセス連携

5) デジタル サービス変革 - BA ブループリント (ビジネス機能) を定義する

図 2-13 ビジネス機能ビュー

企業は、顧客に価値を創造する一連の活動と機能から構成されており、私たちのビジネス機能は、顧客に価値を創造できる活動と機能から派生します。

企業のバリュー チェーンは、設計、生産、マーケティング、輸送など、顧客に価値を生み出す一連の活動、機能、ビジネス プロセス間のつながりを示します。バリュー チェーンには 2 つの主要なコンポーネントがあります。

  • コアビジネス: 主要な顧客価値の創造
  • 支援活動:本業に対するサポートサービスの提供

引き続き運送会社のデジタル サービスの事例を見ていきます。ビジネス アーキテクトは、運送会社のデジタル サービスを変革するという課題に直面し、入念な調査を行った結果、次の図のようなバリュー チェーン部門の構造を導き出しました。

図 2-14 バリューチェーンを利用したビジネス機能の分析

学生の中には、なぜ基幹業務モジュールに旅客運送と貨物運送という 2 つの異なる業種があるのか​​と疑問に思う人もいるかもしれません。実際の業務では、旅客輸送と貨物輸送のいずれかのモジュールを担当するだけかもしれません。

当社のビジネスアーキテクチャの背景も前述しましたが、中国では情報の孤島を解決するためにビジネスアーキテクチャが開発され、ビジネスアーキテクトは個別のシステムを整理するのではなく、全体的な計画を立てる必要があります。

上記のバリューチェーンを整理しましたが、次は機能ドメインを分解する必要があります。次の図は、第 1 レベルの機能ドメインの分解図です。

図 2-15 第 1 レベルの機能ドメイン分割

次に、ビジネス能力ギャップ分析を行うと、4 つの新しい第 1 レベル機能ドメインと 13 の強化された第 1 レベル機能ドメインがあることがわかります。

バリューチェーン分析を第 1 レベルの機能ドメインの分割に変換することで、次のようなメリットが得られます。

① バリューチェーン分析モデルは、その後の機能領域分割の基礎となった 経営支援+コア事業という事業機能領域分割の枠組みは非常に使いやすく、業界に広く認知されており、当然ながら社内でも受け入れられやすいコミュニケーションプロセス。

②「乗車前、乗車中、降車後」と同様のタイムライン思考は、ビジネスアーキテクトに必要な分析スキルであり、甲の事業分野の専門家がよく使う分析習慣でもある。

ビジネス アーキテクチャの設計では、ターゲット アーキテクチャを定義するだけでなく、GAP 分析手法を使用して、その後の実装に備えて強化する必要があるアーキテクチャ機能を特定する必要があります。具体的には、ビジネス機能の変更と増分、組織構造の変更と増分、ビジネス プロセスの変更と増分、ビジネス データの変更と増分が含まれます。

6) デジタル サービス変革 - BA ブループリント (ビジネス モデル) を定義する

ビジネス モデルは、エンタープライズ製品、エンタープライズ コア リソース、顧客、パートナー、チャネル、コスト、利益の間の重要な関係を明らかにします。簡単に言えば、同じことができる企業もあれば、できない企業もあるのはこのためです。

ビジネスモデルを策定する際、全体のビジネスモデルは一つであるというわけではなく、例えば上記の鉄道運送会社の場合、利便性、収益向上、収益向上の3つの目標を掲げ、目的に応じてビジネスモデルを策定することができます。効率化の3つのビジネスモデルを設計できます。

鉄道企業のデジタル サービス変革に関する限り、人々が容易に利用できるように、いつでもインターネット、電話、モバイル アプリを通じて企業サービスを利用できるようにする必要があります。

図 2-16 利便性を目的とした場合のビジネスモデル

鉄道事業者のデジタルサービス変革に関する限り、効率を高めるために、ハードウェア機器とインテリジェント制御システムを使用して、キャンセル、チケットチェック、その他のリンクのデジタル変革を促進し、効率を向上させることができます。

図 2-17 効率化を目的とした場合のビジネスモデル

ビジネス キャンバスは、9 つ​​の小さなグリッドの助けを借りて、簡潔で効率的な体系的な思考環境を構築します。これは注目に値する発明です。

上記の例からわかるように、このビジネス モデルには次の利点があります。

  • 効果的なデザインに役立ち、サービスの革新、プロセスの革新、国境を越えた協力などの優れたアイデアを刺激することができます。
  • これは効果的なレポート作成に役立ち、ビジネス モデルは「なぜこれを行うのか?」という内部ロジックを強調します。

私の意見では、このビジネス モデルは BRD と MRD の内容を組み合わせたものです。

  • BRD: ビジネス要件文書。誰が (顧客セグメンテーション)、どの問題を解決するか (価値提案)、何を行う必要があるか (主要な活動)、どのリソースを費やすか (主要リソース)、およびコスト パフォーマンス (コスト/収益) に焦点を当てます。
  • MRD: 消費者がどのように到達するか(チャネルアクセス)、およびパートナーを獲得する方法に焦点を当てた市場需要文書

7) デジタル サービス変革 - BA ブループリント (ビジネス プロセス) を定義する

ビジネス プロセス ビューはアプリケーション アーキテクチャの入力であり、ビジネス アーキテクチャの中で最も実用的かつ最大の章でもあります。

記事の中で著者はビジネスプロセスの連携方法について論じており、結論としては、単純なビジネスプロセスはフローチャートの形で描くことができ、分岐が多く複雑なビジネスプロセスについてはテキスト記述を使用することを強く推奨するということです。

ビジネスプロセス定義仕様:

  • 第1部:業務機能の概要 業務機能はメインプロセスと分岐プロセスによって実現される ポイントは「1本体+N分岐」のプロセス分解
  • 2 番目の部分: メイン プロセス。主要なポイントは「段階的 + ステップバイステップ」であり、各ステップにビジネス ルールまたはデータ モデル ルールが適用されます。
  • 3 番目の部分: 分岐処理。要点は「メイン処理でのフォーク位置を示す」ことであり、各ステップのビジネスまたはデータ モデルのルールを添付します。
  • 4 番目の部分: 主要な UI プロトタイプ/UI プロセス、この部分はオプションです

図 2-18 業務機能の概要

図 2-19 メインプロセス

図 2-20 分岐処理

図 2 – 21 主要な UI プロトタイプ: UI フロー

この部分は非常に重要で、上で述べたように、ビジネス プロセス ビューはアプリケーション アーキテクチャの入力であるため、この部分をもう一度まとめてみましょう。

分岐プロセスとビジネス シナリオの間には完全な対応関係があることがわかりました。分岐プロセスの特定はシーンベースの思考です。逆に、メインプロセスとブランチプロセスを区別しないと、このような単純なブランチプロセスの変更よりも、その後のビジネス要件の変更が広範囲に影響を与えることになり、あまりにも専門的ではありません。

ビジネス機能やビジネスシナリオは数多くありますが、ビジネスプロセスの定義は何でしょうか? ビジネス プロセスは、複数のビジネス シナリオを含むビジネス機能を定義します。たとえば、チケットの購入には、複数人分のチケットの購入、子供用のチケットの購入などが含まれます。

ビジネス ルールは非常に多くありますが、ビジネス ルールの断片化を避けるにはどうすればよいでしょうか? ビジネス ルールは、メイン プロセス ステップまたはブランチ プロセス ステップとなるビジネス ステップを中心に定義されます。

業務フローチャートを使用するかどうかについては、業務プロセスが中核になればなるほど分岐や業務ルールが多くなりますが、現時点では、より網羅的な情報を提供するためにテキスト仕様を使用することをお勧めします。単純なビジネス プロセスの場合は、フローチャートに従うことができます。

3. まとめ

この記事では、エンタープライズ アーキテクチャの概要を説明し、ビジネス アーキテクチャの背景と実践的な戦略を詳細に説明し、実際の事例を通じてビジネス アーキテクチャについての理解を深めます。

この記事に含まれる概念間の関係を確認してみましょう。

  • エンタープライズ アーキテクチャ = ビジネス アーキテクチャ + アプリケーション アーキテクチャ + データ アーキテクチャ + 技術アーキテクチャ
  • ビジネスアーキテクチャ = 組織構造 + ビジネス機能 + ビジネスプロセス + ビジネスデータ + ビジネスモデル
  • ビジネス機能 = トップレベルのバリューチェーン + 第 1 レベルの機能ドメイン分解 + 第 2 レベルの機能サブドメイン分解
  • ビジネスモデル = ビジネスモデルキャンバス分析
  • ビジネスデータ = データドメイン + データモデル + データルール

戦略主導のビジネス設計の実践的なステップの本質は、戦略からビジネス アーキテクチャの設計図までのスパンが大きすぎて論理チェーンを接続できないため、次の 2 つのステップに分割されることです。

  • 戦略から戦略へ
  • 戦略から青写真へ

おすすめ

転載: blog.csdn.net/u012921921/article/details/127779843