メインコンテンツへスキップ

ビジネスユニット（business_unit）は会社と部署の間

    ServiceNow観察日記


    ServiceNow で組織を表すテーブルというと、まず会社（core_company）と部署（cmn_department）が思い浮かびます。ところが部署フォームをよく見ると「Business unit」という参照欄が並んでいて、その正体が business_unit（ビジネスユニット） というもう一つの組織テーブルです。会社ほど大きくなく、部署ほど細かくない。ちょうど会社の下・部署の上に入る「事業単位」のレイヤが、ここに用意されています。

    PDI（Zurich / OOTB）で business_unit を開き、6件のレコード・主要フィールド・会社や部署との参照関係を実測しました。business_unit が組織階層のどこに位置し、上下のテーブルとどう繋がっているのかを実画面つきで確認できます。取引先も自社も同じ1テーブルに入る（core_company） との役割分担も後半で扱います。

    この記事で分かること

    • business_unit が会社（core_company）と部署（cmn_department）の間に入る組織階層レイヤだということ

    • business_unit が継承元のない独立ルートテーブルで、PDI では6件（Legal / Sales / Marketing / HR / IT / Finance）だったこと

    • 主要フィールド name / company（会社へ）/ parent（自己参照）/ bu_head（責任者→sys_user）の役割

    • 会社 → ビジネスユニット → 部署 → ユーザー という設計上の組織ツリーと、OOTB では BU↔部署が未紐付けだったこと

    • sys_user は business_unit を直接持たず、部署（department）経由で BU につながること

    この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、件数・レコード・参照の紐付け状況が異なります。

    ビジネスユニットは会社と部署の間にある

    ServiceNow の組織は、会社・部署だけでなく、その間にビジネスユニット（business_unit）という事業単位のレイヤを挟めます。アプリナビゲーターで「Organization > Business Units」を開くと、会社内をいくつかの事業に区切った一覧が並びます。

    下の画面は、PDI（Zurich / OOTB）の business_unit（Business Unit）の一覧です。Legal・Sales・Marketing・HR・IT・Finance という6つの事業単位が登録されていました。


    画像

    business_unit が組織階層のどこに入るかを図にしました。会社の下、部署の上に位置する中間レイヤです。


    画像

    business_unit は super_class（継承元）が空の独立ルートテーブルです。Incident のように task を継承するわけではありません。CI のように cmdb を継承するわけでもありません。会社（core_company）や部署（cmn_department）と同じ、組織マスタ専用の器として独立しています。会社・BU・部署の役割分担を表にすると次のとおりです。


    画像

    business_unit はどんなテーブルか：主要フィールド

    business_unit のフィールド構成は、会社（core_company）に比べてかなりシンプルです。住所も会計コードも持たず、会社への参照・自己参照・責任者といった「組織のつながり」を表す参照が中心になっています。フィールド定義は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

    https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=business_unit^elementISNOTEMPTY


    画像

    主なフィールドは次のとおりです。


    画像

    中心になるのは name（BU名）・company（所属会社）・bu_head（責任者）・parent（自己参照階層） の4つです。company は core_company を参照し「この BU はどの会社のものか」を、bu_head は sys_user を参照し「この BU の責任者は誰か」を表します。parent は business_unit 自身への参照（自己参照）で、BU 同士の親子階層も組めるようになっています。

    下の画面は、PDI の IT ビジネスユニットのフォームです。Company に会社、Business Unit Head に責任者が入っています。


    画像

    なお business_unit は固有フィールドに sys_updated_on（更新日時）を持ちます。システムログ syslog のような append-only（追記専用）ではありません。ふつうに更新できるマスタテーブルです。

    PDI 実機の6件を見る

    PDI で business_unit を実際に数えると 6件でした。中身を表にすると次のとおりです。


    画像

    ここで実機ならではの発見が3つありました。

    • company は6件すべて ACME Corporation に設定済み。BU はきちんと会社の下にぶら下がっていました。なおこの ACME Corporation は customer=true の取引先系の1社で、primary（自社）フラグは立っていません。

    • parent と hierarchy_level は全件空。OOTB では BU 同士の階層は組まれておらず、6つの BU が会社直下にフラットに並んでいます。自己参照で階層を作れる仕組みはあるものの、初期データでは使われていません。

    • bu_head は6件すべて値が入っていますが、Marketing の責任者だけは参照先の sys_user を引くとレコードが見つからないダングリング参照でした。

    • 残り5件は実在ユーザーに解決できます。

    • Legal=Alejandra Prenatt、Sales=Aileen Mottern、HR=Abraham Lincoln

    • IT=Abel Tuter、Finance=Adela Cervantsz

    • 参照フィールドに値が入っていることと、参照先が実在することは別問題だと分かる例です。

    会社→ビジネスユニット→部署→ユーザー の組織ツリー

    business_unit は、それ単体ではなく上下のテーブルと参照で繋がって初めて意味を持ちます。BU を中心に、どの参照が出ていき、どの参照が入ってくるのかを見ます。


    画像

    BU から出ていく参照は、company（→ core_company）・bu_head（→ sys_user）・parent（→ business_unit 自身）の3つです。一方、BU に入ってくる参照の代表が、部署テーブルの cmn_department.business_unit です。下は PDI の IT 部署のフォームで、「Business unit」という参照欄が用意されているのが分かります。


    画像

    ここが実機での重要な発見です。cmn_department には business_unit を参照する欄が用意されているものの、PDI の7部署はいずれも business_unit が未設定（空）でした。つまり設計としては「会社 → ビジネスユニット → 部署 → ユーザー」という4階層を参照で繋げられます。ですが OOTB では BU と部署のリンクが張られておらず、BU は会社の下にぶら下がるところまでしか実データがない、ということです。階層を活かすかどうかは導入側の運用に委ねられています。

    もう一つ押さえたい点があります。ユーザー（sys_user） には business_unit の直接参照が無いことです。

    ユーザーは会社・部署・コストセンターは直接参照します。ビジネスユニットだけは持ちません。ユーザーから BU へたどるには、sys_user.department → cmn_department.business_unit と部署を経由する必要があります。なお business_unit を参照しているのは部署だけではありません。CI を事業単位で括れるようになっています。

    参考：CMDB の CI（cmdb_ci） も business_unit 列を持ちます

    organization-tables との役割分担

    ここまでで、business_unit が組織3テーブル（会社・部署・コストセンター）に対してどう位置づくかが見えてきました。会社・BU・部署を「階層レイヤ」として並べると次のようになります。


    画像

    • core_company（会社） … 取引先も自社も入る一番外側のマスタ。詳しくは姉妹記事を参照してください。

    • business_unit（ビジネスユニット） … 会社の中を事業で区切る中間レイヤ。company で会社に、bu_head で責任者に繋がる。

    • cmn_department（部署） … 組織図上の最小の固まり。business_unit を参照して「どの事業単位の部署か」を表せる。

    参考：組織テーブル core_company / cmn_department / cmn_cost_center の記事

    ざっくり言えば、会社は「どの法人か」、ビジネスユニットは「会社の中のどの事業か」、部署は「その事業のどの組織か」 を表します。会社と部署だけでは粗すぎる・細かすぎるという場合に、間に business_unit を1段挟んで括る、という使い方になります。ユーザー・グループ・ロール で「人の構造」を読むときも、この会社→BU→部署のレイヤを意識してください。誰がどの事業に属するのかが見通せます。

    実機で確認するときに見るべきURL

    最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

    # ビジネスユニットの一覧
https://<YourInstance>/business_unit_list.do

# 会社でグループ化（どの会社に何件の BU があるか）
https://<YourInstance>/business_unit_list.do?sysparm_query=GROUPBYcompany

# business_unit のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=business_unit^elementISNOTEMPTY

# 部署の一覧（Business unit 欄を持つ）
https://<YourInstance>/cmn_department_list.do

    まとめ

    • business_unit は会社（core_company）と部署（cmn_department）の間に入る組織階層レイヤ。継承元のない独立ルートテーブルで、PDI では 6件（Legal / Sales / Marketing / HR / IT / Finance）。

    • 主要フィールドは name / company（会社へ）/ bu_head（責任者→sys_user）/ parent（自己参照階層）。住所や会計コードは持たないシンプルなマスタ。

    • PDI の6件は company が全件 ACME Corporation で、parent / hierarchy_level は全件空（階層は未使用）。bu_head のうち Marketing はダングリング参照だった。

    • 設計上は会社 → BU → 部署 → ユーザーの4階層を参照で繋げられるが、OOTB では cmn_department.business_unit が全件空で BU↔部署が未紐付け。

    • sys_user は business_unit を直接持たない。ユーザーから BU へは部署（department）経由でたどる。CI（cmdb_ci）も business_unit 列を持つ。

    ビジネスユニットが分かると、組織テーブル（会社・部署・コストセンター）とユーザー（sys_user）の間に「事業単位」という横串が1本通ります。ServiceNow の組織構造がより立体的に見えてきます。

    参考：組織テーブル（会社・部署・コストセンター） ／ ユーザー（sys_user）

    関連記事

     
     

    ServiceNow観察日記

     
     
    ServiceNowのPDI（Personal Developer Instance）を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ