会社の業務とシステムを体系的に整理する方法

ここでは、次の観点で、会社の業務とシステムを体系的に整理する方法について説明します。

• ビジネスを構成する要素
• 会社の業務とシステムを体系的に整理する手順
• 活動領域の明確化
• ジョブの定義
• アプリケーションタイプの定義
• ビジネスプロセスの定義
• マスターデータの定義
• アクティビティフローの定義
• 概念データモデルの定義
• アクションフローの定義
• システムユースケースの定義
• アプリケーションで管理するデータの明確化

ビジネスを構成する要素

記事「強いビジネスを創る」で説明したように、ビジネスを、縦軸に構成要素（目的・資産・場所・機能・活動）、横軸にレイヤ構造で分けると次の図のようになります。

このうち、今回とりあげるのは、業務機能の型であるジョブ、業務活動の型であるビジネスプロセス、アプリケーションの型であるアプリケーションタイプ（APPタイプ）、データの型であるデータタイプです。
ここでは、ジョブとビジネスプロセスを総称して「業務」、アプリケーションタイプとデータタイプを総称して「システム」と呼びます。

会社の業務とシステムを体系的に整理する手順

次の図のような手順で会社の業務とシステムを体系的に整理します。

1. 活動領域の明確化
   まず、会社の活動領域を明確にします。
2. ジョブの定義
   次に、活動領域を構成する活動を組み合わせて、企業の業務機能の型であるジョブを定義します。
   

ジョブと業務フローの関係ですが、次の図のように業務フローのレーンがジョブになります。


3. アプリケーションタイプの定義
   次に、ジョブを組み合わせて、アプリケーションの型であるアプリケーションタイプを定義します。
   
   アプリケーションタイプと業務フローの関係ですが、次の図のように業務フローのレーンとして関係するアプリケーションタイプを記述します。
   
4. ビジネスプロセスの定義
   次に、活動領域をベースにビジネスプロセスを洗い出して定義します。
   
5. マスターデータの定義
   次に、ビジネスの資産、場所を表すデータタイプとしてマスターデータを定義します。
   
6. アクティビティフローの定義
   次に、ビジネスプロセスの粗粒度の業務フローであるアクティビティフローを定義します。
7. 概念データモデルの定義
   次に、アクティビティフローのアクティビティに基づいて概念データモデルを定義します。
8. アクションフローの定義
   次に、アクティビティフローのアクティビティに対する詳細な業務フローとして、アクションフローを定義します。
9. システムユースケースの定義
   次に、アクションフローの中のアクションからアプリケーションタイプに対するメッセージをシステムユースケースとして定義します。
10. アプリケーションで管理するデータの明確化
    最後に、概念データモデルを構成するエンティティを管理するアプリケーションタイプを明確にします。

活動領域の明確化

会社の経営は次のような活動サイクルになっています。

1. まず、投資家から資本を調達する。
2. 資本を投下して資産を構築する。
3. 資産を消費して顧客に価値を提供する。
4. 顧客から受け取った対価の一部を投資家に還元して、残りを資産に再投資する。

なので、企業の活動は、次の４種類に分類することができます。

• 財務活動
  投資家から資本を調達し、利益を還元する活動。
• 資産管理活動
  資本を資産に投下し、それを維持管理する活動。
• 営業活動
  資産を消費し、顧客に価値を提供する活動。
• 経営活動
  上記の活動全体をコントロールする活動。

これを細分化して整理すると次の図のようになります。

この活動領域は、以下のように構成されています。

• 営業活動
  顧客に対して直接価値を提供する活動。
  営業活動は、さらに、
  • 商流
    取引の流れ。
  • 金流
    お金の流れ。
  • 物流
    物の流れ。

  で分類することができます。

• 資産管理活動
  資産のライフサイクル（調達、活性化、維持、処分）を管理する活動。
  資産管理活動は、さらに、資産の種類で分類することができます。
  • 人的資産
    顧客、社員、パートナー。
  • 知的資産
    商品、知的財産。
  • 財務資産
    資産管理活動で管理するのは主に設備などの固定資産です。
    流動資産の場合、運転資本なので、債権や債務は、営業活動の債権管理活動、債務管理活動で管理し、棚卸資産は、営業活動の入出荷（物流）の在庫として管理します。
  • 情報資産
    稼ぐ力を持つ情報（データ資産）と、その情報を収集したり処理したり保管したりするための装置（情報システム）。
    機械学習でつくる学習モデルも組織ナレッジの一種と考えます。
• 財務活動
  営業活動、資産管理活動に必要な資本を調達する活動。
• 経営活動
  経営理念を実現するためにビジョンに向かって全体をコントロールする活動。

なお、資産管理活動のうち、開発活動、調達活動、活性化活動のように資産自体の価値を創る、あるいは、上げる活動は投資活動になり、それ以外の活動は維持管理活動になります。
なので、例えば、設備のライフサイクルのうち、設備の活性化と設備の運用・保守の違いですが、前者は資産価値を上げる活動で、費やしたコストは資本的支出（CAPEX：Capital expenditure）としてB/Sに計上されます。一方、 後者は資産価値を維持する活動で、費やしたコストは営業費用 (OPEX：Operating Expense)としてP/Lに計上されます。

さて、以上よりわかるように、同じように顧客にアプローチする活動でも、販売（セールス）と、顧客管理（CRM）は位置づけが異なります。
販売（セールス）は営業活動ですが、顧客管理（CRM）はマーケティングの一種で、販売（セールス）しなくても売れる仕組を創る投資（資産管理）活動なのです。
法人販売の例で説明します。

上図を見ると、①から⑤の流れで顧客価値を実現していることがわかりますが、このうち、問い合わせ対応と販売促進は顧客管理の活動、商品企画と商品開発は製品管理の活動になります。
販売は直接価値を提供する営業活動ですが、顧客にニーズを探索し、そこから顧客価値を創出し、それを商品という知的資産として実現し、その価値を顧客に展開するまでは、顧客や製品という資産を創出し管理する資産管理活動になるのです。
活動を緊急度×重要度で分類してタイムマネジメントする方法があります。

これに活動領域を適用すると、
「販売」など営業活動は、緊急で重要な第一領域の活動になりますが、
「顧客管理」や「製品管理」など資産管理活動は、緊急ではないが重要な第二領域の活動になります。
タイムマネジメントでは、緊急でも重要でもない第四領域の活動をなくし、かつ、緊急だが重要ではない第三領域の活動を削って、第二領域の活動にまわすことで、緊急で重要な第一領域の活動を減らすことを推奨します。
第一領域の活動は、事象が発生することによる治療であり、第二領域の活動は、それを予防する活動になるというのです。

活動領域でいうと、資産管理活動は、仕組をつくる投資活動であり、これをしっかりやることで、営業活動を効率的かつ効果的に行うことができるということになるのです。

活動領域の展開

さて、この活動領域をベースに、ジョブやビジネスプロセスを考えることができます。

• 一つ一つの活動領域に対応するジョブを考えることができます。
• 一つの活動領域ごとに、一つ以上のビジネスプロセスを考えることができます。
• ビジネスプロセスの中身をプロセスの視点で可視化したものが業務フローになります。
• ビジネスプロセスの中身をデータの視点で可視化したものが概念データモデルになります。
• ジョブの機能であるタスクは、業務フローを構成する要素になります。この業務フローの構成要素がアクティビティです。
• 業務フローを構成するタスクは、概念データモデルを構成するデータタイプ（データの型）を記録、活用します。
• アプリケーションの型であるアプリケーションタイプは、ジョブが活用するシステムとして、ジョブの単位に考えることができます。
• アプリケーションタイプの機能であるアプリケーションタスクは、ジョブのタスクから活用され、データタイプを記録、活用します。

次に、この活動領域とバリューチェーンの関係を見ておきましょう。

バリューチェーン

バリューチェーンとは、M・E・ポーターが競争の戦略という本で提唱した概念で、
事業活動を活動領域ごとに分類し、どの部分で付加価値が生み出されているか、競合と比較してどの部分に強み・弱みがあるかを分析し、事業戦略の有効性や改善の方向を探る手法
のことです。

バリューチェーンは、顧客に直接価値を提供する主要活動と、それを支援する支援活動から構成されます。
これを見ると、バリューチェーンの主要活動は、活動領域の営業活動の商流と物流、顧客管理活動（マーケティングの部分）から構成されていることがわかります。
そこで、活動領域の活動も分類しておきましょう。

活動の分類

上記活動領域を以下の観点で分類します。

• 主要活動
  主要活動は、顧客に直接価値を提供する活動で、
  • 事業固有の営業活動
  • 事業固有の資産管理活動

  になります。

• 支援活動
  支援活動は、全事業に共通した活動になります。
  • 事業支援活動
    主要活動を支援する活動で、以下のように分類することができます。
    • 営業支援活動
      全事業の営業活動を支援する活動で、全事業共通の資材の調達、債権・債務管理、入出荷管理が該当します。
    • 共通資産管理活動
      例えば、社員管理など、上記資産管理活動の中で、全事業共通の資産の価値を管理する活動です。
  • 企業支援活動
    主要活動、事業支援活動を支援する活動で、財務活動、経営活動が該当しす。

複数の事業を展開している企業は、事業固有の活動は何か、事業共通の活動は何か、企業共通の活動は何か識別しておく必要があります。
【関連動画】

ジョブの定義

ジョブ（職務）は、仕事の内容や役割を表す業務機能の型になります。
ジョブの機能の詳細は、職務記述書（ジョブディスクリプション）に定義します。
職務記述書（ジョブディスクリプション）は、特定の職務やポジションに関連する情報を文書化したものです。
これは組織内の異なる職種や役職に対して、その役割や責任、求められるスキルや経験などを明確にするために使用されます。
職務記述書に含まれる一般的な内容は次のようになります。

職務タイトル
職務記述書の冒頭には、その職務の正確なタイトルを明記します。
例えば、「生産管理」「販売」「カスタマーサービス」「システムエンジニア」などがあります。
• 職務の概要
  その職務の全体的な目的や役割についての概要を説明します。具体的な業務内容を簡潔に示し、組織内の位置付けや他の部門との関連性を記載します。
• 職務の責任
  その職務が担当する具体的な責任と任務を列挙します。これは、日々の業務やプロジェクトにおける具体的な職務機能を示す部分です。
• 職務の権限
  その職務に与えられた権限や決定権について説明します。特定の範囲内での判断や決定ができる権限について記載します。
• 必要なスキル・資格・経験
  その職務を遂行するために必要なスキル、資格、経験について明示します。
  例えば、特定の学位や専門的な資格、言語スキル、コンピューターソフトウェアの知識などが考えられます。
• 報告ライン
  その職務が組織内でどの職位に報告するかを示します。
  上司やマネージャーの情報を記載します。
• チームとの連携
  その職務がどのような部門やチームと連携し、協力する必要があるかを記述します。
• 仕事の場所とスケジュール：
  その職務の勤務場所（オフィス、リモートなど）と、通常の労働時間や勤務スケジュールについて記載します。
• パフォーマンス評価基準
  その職務における評価基準やKPI（Key Performance Indicators）など、業績評価に関連する項目を示します。
• 組織の文化や価値観
  組織の文化や価値観に従った行動を求める場合は、そのような情報を記載することがあります。

職務記述書は、採用や人事配置、パフォーマンス評価、キャリア開発などに役立つ重要な文書です。
明確に書かれることで、職務の理解や期待値が明確になり、組織全体の効率と従業員の満足度向上に寄与します。
さて、ジョブは、上述した活動領域を構成する活動を組み合わせて定義することができます。
例えば、活動領域の「販売」活動に対する「販売」ジョブを定義することができます。
また、「顧客管理」活動の新規顧客を獲得する機能と既存顧客を活性化、維持管理する機能を分けてマーケティングとカスタマーサービスというジョブとして定義することもできます。
ジョブは、ステークホルダーに対する価値を提供するビジネスモデルをどう設計するかによって変わってきます。
ここで、職務（ジョブ）と職位（ポジション）、部門の違いをおさえておきましょう。
職位は、部長、課長、マネージャ、リーダーなど、特定の責任や権限を与えられた組織上の地位を表します。
職務によって等級が決まり、それによって基本給が決まりますが、職位の場合、それによって役職手当が決まります。
次に、部門ですが、これは事業（市場×製品）別にジョブを分けた概念です。
会社は、部門にメンバーを配置して組織を構成します。

例えば、下図の場合、社員の山田太郎さんの職務は生産管理者で、職位はマネージャ、所属する部門はA事業部・生産管理部になります。

ジョブは業務機能の型として設計しますが、市場セグメント×製品カテゴリを明確にした事業戦略を策定する段階で、組織戦略に従ってA事業部・営業第一部などの部門に展開されます。

アプリケーションタイプの定義

アプリケーションタイプは、アプリケーションの型を表す概念です。
アプリケーションは、人の仕事を支援する手段なので、ジョブの組み合わせでアプリケーションタイプを定義することができます。
また、会社が複数の事業を扱っている場合、A事業販売システムとB事業販売システムというように、各事業ごとにアプリケーションタイプを分けることもあります。
次の図は、情報資本ポートフォリオのアプリケーションの部分です。

ここでは、アプリケーションタイプを次のように分類しています。

• トランザクション処理アプリケーション
  企業の基本的な定型業務を自動化するアプリケーション。
• 変革アプリケーション
  企業の現行のビジネスを変革するアプリケーション。
• 分析アプリケーション
  分析、解釈、情報と知識の共有を促進するアプリケーション。

このうち、トランザクション処理アプリケーションを、企業情報基盤のアプリケーション基盤のERP、分析アプリケーションと変革アプリケーションを戦略的アプリケーションと位置づけています。
アプリケーションタイプは、アプリケーションの型ですが、事業戦略を策定する段階でIT戦略に従ってアプリケーションカテゴリに展開されます。
アプリケーションカテゴリは、アプリケーションタイプをどう実現するのかを表すもので、パッケージで実現するのか、スクラッチ開発するのか定義します。

ビジネスプロセスの定義

ここでは、ビジネスプロセスを
それを構成する活動が資産を消費することで、ステークホルダーに価値を生み出し、結果的に資産の状態を変化（増減）させる組織横断的な単位
と定義します。
※ステークホルダー（ビジネスの利害関係者）には、顧客だけでなく社員や株主、パートナーなどがあります。

ビジネスプロセスは活動から構成されるので、ビジネスプロセスの単位で業務フローを作成します。
さて、企業全体のビジネスプロセスを明確にしたい場合は、バリューチェーンを構成する各活動領域ごとに、どのようなビジネスプロセスがあるか定義します。
上述したように、バリューチェーンは、事業ごとの主要活動と、事業、あるいは、企業全体で共通の支援活動に分けることができます。
なので、次のように、主要活動のビジネスプロセスは、支援活動のビジネスプロセスを共有するかたちになります。

営業活動のビジネスプロセスは、ビジネスの仕組を考えることで比較的容易に洗い出すことができます。
次の図は、営業活動の商流、物流、金流の仕組を表しています。

この場合、以下の、活動を表す部分がビジネスプロセスの単位になります。

• 製品の販売
• 部品の調達
• 製品の製造
• 出荷の指示
• 部品の納入
• 代金の請求
• 代金の支払

上図は、予め製品を製造して在庫を持つ見込み生産の仕組ですが、注文を受けてから製造する受注生産の場合は次のようになります。

「製品の製造」プロセスがなくなり、製造してから販売する「製品の製造販売」プロセスになっていることがわかります。
また、製造業ではなくサービス業の場合は次のようになると思います。

物を販売する「製品の製造販売」プロセスではなく、「サービスの販売」プロセスになり、「サービスの提供」プロセスも必要になります。
このように、ビジネスモデルによってビジネスの仕組は変わってきます。

さて、ビジネスプロセスを定義するときに重要なのは、価値を提供するステークホルダーを明確にするということです。
価値を提供する相手を考えることで、

• 本当に価値を生み出す活動は何か
• 価値を生み出していない活動は何か
• 価値を生み出す活動をもっと効果的に行うにはどうすべきか
• 価値を生み出していない活動はどうするか、削除、あるいは、削減するか、フローを変えるか、代替する手段はないか

など業務フローを構成する各活動を分析し、業務を改善することができるようになります。

マスターデータの定義

ビジネスの資産や場所を表すデータタイプとしてマスターデータを定義します。

アクティビティフローの定義

業務フローには、ビジネスプロセスの本質的な流れを示す「アクティビティフロー」と、それを構成するアクティビティをさらに詳細化した「アクションフロー」があります。

アクティビティフローを構成する「アクティビティ」は、「受注」、「出荷」など、ビジネスプロセスを構成する本質的な活動を表し、アクションフローを構成する「アクション」は、「〜の記録」、「〜の報告」、「〜の承認」、「〜の確認」など、これ以上分けることができない動作の単位になります。
下図は、BPMNという表記法で記述した「製品の販売」プロセスのアクティビティフローの例です。

この場合、「製品の提案」、「製品の見積」、「製品の受注」、「在庫の引当」という「製品の販売」プロセスを構成する本質的な活動（アクティビティ）の流れを記述しています。
BPMNでは、「レーン」で業務フローの活動の主体であるジョブを表し、アクティビティは、さらに詳細の下位フローを含む「サブプロセス」で表現します。
ビジネスプロセスの業務フローは、不変的な活動の型なので、活動の主体は、業務機能の型であるジョブになります。
業務フローのレーンを部門にすると、組織戦略の変更で部門が変わる都度、業務フローを書き換える必用があります。
部門は、戦略レベルのアクションフローの活動主体です。

なので、組織戦略の変更で部門が変わる都度、ジョブに対する部門の対応付けを見直すようにします。

概念データモデルの定義

アクティビティフローのアクティビティに基づいて概念データモデルを定義します。
下図は、「製品の販売」プロセスのアクティビティフローに対する概念データモデルの例です。

「製品の提案」、「製品の見積」、「製品の受注」、「在庫の引当」というアクティビティの結果、記録すべき事実としてのトランザクションデータとして「提案」、「見積」、「受注」と、それらの明細、および、「引当」エンティティが因果関係として関連付けられていることがわかります。
なお、「社員」、「拠点」、「顧客」、「製品」、「製品在庫」はマスターデータです。
※製品在庫は棚卸資産という財務資産のマスターデータです。

アクションフローの定義

次に、下図は、上記「製品の受注」アクティビティの詳細を記述したアクションフローの例です。

アクティビティフローのレーンは、「販売」、「出荷」という上位レベルのジョブになっていますが、アクションフローのレーンは、「販売実務」、「出荷実務」というようにジョブが下位レベルになっていることがわかります。
また、それにともなって、これ以上分解しても意味がない動作（アクション）の流れになっていることがわかります。
BPMNでは、アクションを、これ以上下位に詳細フローを含まない「タスク」で表現します。
記事「強いビジネスを創る」で説明したように、ビジネスの場合、モジュールの仕様部分がジョブ（職務）、それを実現するのがメンバー、アプリケーション、製品などの資産になります。

ジョブのアクションをアプリケーションが実行する場合、上図のようにアプリケーションタイプのレーンを設けて、アプリケーションが実行するアクションを記述するようにします。

システムユースケースの定義

アクションフローの中のアプリケーションタイプのレーンのアクションをシステムユースケースとして定義します。

上図の場合、販売管理システムの「受注の登録」アクションと、出荷管理システムの「在庫の引当」と「在庫の照会」アクションを下図のようにシステムユースケースとして定義します。

アプリケーションで管理するデータの明確化

概念データモデルとシステムユースケースの関係から、下図のように、アプリケーションタイプで管理するデータタイプを明確にします。

これは、アプリケーション開発の要件定義のときに作成するドメインモデルの元になります。