Qlikの日付処理のベストプラクティス〜第5回 SCD(IntervalMatch)を使用した組織改編への対応〜

こんにちは!Yokoです。
弊社は決算が12月でして、1月より新年度になっております。
前期は何とか良い数字を残すことができました。
弊社に目を掛けていただき、感謝致しております🙇‍♂️

さて、うちみたいな小さな会社は何てことないのですが、大企業になると組織改編なんてしょっちゅうありますよね。
そこでいつも問題になるのは前年、前々年比較です。
以前の記事で、前年比較についてご説明したのですが、組織が変わってしまうと比較するのが困難になります。
仕方ないと思って諦めてしまっている、そこのあなた!
方法はありますよ!!

というわけで、今回は
「組織改編どんとこい!SCD(Slowly Changing Dimensions)で組織改編に対応する」
というテーマで解説していきます。

目次

組織改編による集計への影響

組織が変わってしまうと、どんなことになるか…
まずは見てみましょう。
以下がデータモデルとテーブルでの集計結果です。

2024年10月に部門が分割され、さらに2025年4月に全面的に組織が変わっているようです。
前年の組織がなかったり、前年の組織が途中で分割されているなどの場合、部門単位で前年比較しようと思うと、正しく集計できないのは明らかですよね。

経験上、ビジネスシーンでのご要求は「現在の組織で集計したい」ということだと思います。
以降、現在の組織に則して比較できるようにする方法を解説していきます。

SCD (Slowly Changing Dimensions) とは

上記のような「時間とともに変化するディメンション(軸)」に対応する手法として、SCD(Slowly Changing Dimensions) という手法があります。SCDにはType0〜7までありまして、今回はType2で実装を行います。
Typeの違いはWikipediaに説明がありますので、こちらを参照して下さい。

SCD Type2は簡単に言いますと、日付の期間(From〜To)のマスタを準備して、ファクトテーブルの日付がどれに当たるかを判定する手法です。
簡単な例で説明しますと、消費税計算では
・1989年4月1日〜1997年3月31日 3%
・1997年4月1日〜2014年3月31日 5%
・2014年4月1日〜2019年9月30日 8%
・2019年10月1日〜現在 10%
という変更履歴がありますので、2018年7月1日の消費税は?
いう場合に、上記の変更履歴を元に8%と判定できます。

変更履歴を整理する

サンプルデータの組織では以下のように変更されていました。

  • 第1営業部は官庁営業部になりました(1対1)
  • 第2営業部と第3営業部は公共営業部に合併されました(多対1)
  • 第4営業部は第4営業部と第5営業部に分割されました(1対多)
  • その後、第4営業部は製造業営業部になりました(1対1)
  • 第5営業部は流通業営業部とサービス業営業部に分割されました(1対多)

現在の組織構成から見た場合、「1対1」や「多対1」は加算するだけなので、気にする必要はありませんが、1対多に分割された場合に複雑になります。
通常、企業では従業員数や売上比率で分割割合を決定しているケースが多いと思います。ここは「決め」の問題なので、どんな基準でも良いのですが、仮に以下のように分割したとします。

特に注意が必要な分割(1対多)について、比率を整理してみます。
比率を整理するに当たっては、現在の組織に対応した比率を求める必要があります。

  • 2025年4月 第5営業部は55:45で流通業営業部とサービス業営業部に分割されました
  • 2024年10月 第4営業部は40:60で第4営業部と第5営業部に分割されました
  • 第5営業部の60%は流通業営業部・サービス業営業部に後に分割されるので、流通業営業部分として(60%×55%=33%)とサービス業営業部分として(60%×45%=27%)という内訳になります。

変更履歴テーブルの作成

上記の図式を変更履歴マスタとして整理すると以下のようになります。
現在の組織の「終了日」はありませんが、便宜上「2099年3月31日」としておきます。
これがあれば、それぞれの期間の売上を現在の部門に割り当てることができるんです。

ロードスクリプトの編集

QlikでSCDを実現するには、IntervalMatchプレフィックスを使用します。
このIntervalMatchプレフィックスを使用すると、そのファクトテーブル(ここでは売上実績)の売上日に対応する部門毎の期間から部門を判定することができるんですよね。
ロードスクリプトは以下のようになります。

現在部門マスタ:
LOAD
    部門ID,
    開始日,
    終了日,
    部門ID & '|' & Date(開始日,'YYYYMMDD') as 現在部門KEY,
    分割比率,
    現在部門ID,
    現在部門名
FROM [$(vDataPath)/部門別売上.xlsx]
(ooxml, embedded labels, table is 部門SCD);

売上実績:
LOAD
    部門ID,
    Date(売上日) as 売上日,
    売上金額
FROM [$(vDataPath)/部門別売上.xlsx]
(ooxml, embedded labels, table is 売上実績);

Bridge:
IntervalMatch(売上日,部門ID) 
LOAD 
	Distinct
	開始日,
    終了日,
	部門ID
RESIDENT 現在部門マスタ;

Left Join(売上実績)
Load
	部門ID,
    売上日,
	部門ID & '|' & Date(開始日,'YYYYMMDD') as 現在部門KEY
Resident Bridge;

Drop Table Bridge;
Drop Field 部門ID From 現在部門マスタ;

解説しますね。

■ 現在部門マスタ
上で作成した変更履歴テーブル読み込む際に、部門IDと開始日を組み合わせて、現在部門KEYを作成しておきます。
組織では、ある部門において開始日が同じで複数の終了日を持つことはありえないので、この組み合わせでユニークになる想定です。

■ Bridge
ある部門のある売上日のデータが、どの期間に属するかを判定するためにIntervalMatchで処理します。
IntervalMatchで設定した売上日は、Load文の開始日,終了日のどの期間に当たるかを判定します。ここでは部門IDも関係してくるため、部門IDをKEYとして追加する必要があります。
IntervalMatch(売上日, 部門ID)
Load Distinct 開始日, 終了日, 部門ID …
として対応づけておきます。
このBridgeテーブルでは部門IDと売上日のパターンが、どの部門の開始日、終了日なのかをユニークな組み合わせとして作成してくれます。
作成されるテーブルの値はこんな感じになります。

カラム
部門ID5
売上日2024/11/01
開始日2024/10/01
終了日2025/03/31

ここで、部門IDと開始日がわかれば、現在部門に割り当てることができるので、Bridgeテーブルから部門IDと売上日、さらに部門IDと開始日で生成した現在部門KEYを売上実績テーブルにLeft Joinしてやれば、現在部門マスタに紐づけることができます。
最後に、Bridgeテーブルを削除し、現在部門マスタから部門IDを削除すれば完成です。
完成したデータモデルは以下のようになります。

ビジュアライゼーションの作成

ビジュアライゼーションにはどう実装していくかを説明していきます。
年度選択もフィルターパネル(売上日.fiscal.Year)を設置し、その下に現在の部門に対する当年と前年の売上金額を表示するピボットテーブルを作成します。
ストレートテーブルの設定は以下のとおりです。
(細かいところは、Qlikの日付処理のベストプラクティス〜第3回 前年比較の表現〜を参考にして下さい)

軸 > 行現在部門ID
軸 > 行現在部門名
軸 > 列年月(売上日.fiscal.Month)
メジャー > 当年Sum({$<売上日={“>=$(vMinDate)<=$(vMaxDate)”}>} [売上金額] * [分割比率])
メジャー > 前年Sum({$<売上日={“>=$(vLast_MinDate)<=$(vLast_MaxDate)”},[売上日.fiscal.Year]>} [売上金額] * [分割比率])

以上の設定で、フィルターパネルで”2025″を選択すると以下のような表示になります。

現在の部門に対応して、当年と前年が正しく表示されるようになりました。
2024年を選択しても、現在の部門に対応して集計されます。

まとめ

組織改編に対応して、現在の組織ベースで集計は、IntervalMatchを使用したSCDで簡単に実現できます。
ポイントは以下の通りです。

  • 開始日、終了日を設定した変更履歴データを作成
  • 開始日、終了日を使用して、IntervalMatchで、ファクトテーブルに現在の組織に割り当てるKEYを作成
  • 分割比率を計算式に入れることで、事業分割にも対応

思った以上に簡単ですよね。
他にもっといい方法があるのかもしれませんが、僕のアイディアは以上のとおりです。

ではまた!

関連記事はこちら
Qlikの日付処理のベストプラクティス〜第1回 Auto Calendar〜
Qlikの日付処理のベストプラクティス〜第2回 カレンダーの切り替え〜
Qlikの日付処理のベストプラクティス〜第3回 前年比較の表現〜
Qlikの日付処理のベストプラクティス〜第4回 日付ピッカー(Date Picker)の最適設定〜

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次