論文
DBSJ Letters Vol.6, No.4――――――――――――――――――――――――――――――――――――

業務データからプロセスインスタ
ンスを生成する一手法とその評価
A Generation Method of Business ProcessInstance using Business Transaction Dataand its Evaluation

相馬 仁志♠
篠崎 衛♦

村澤 靖♦
茂木 強♦

Hitoshi SOMA
Mamoru SHINOZAKI

Yasushi MURASAWA
Tsuyoshi MOTEGI

近年，ビジネスプロセスの視点から PDCA サイクルによる継続的な業務改善を実施する上で，業務の実施状況や改善効果を監視する BAM が注目されている．本稿では，業務システムにて出力された業務データを基に，実際に実行された個々の業務フローであるプロセスインスタンスの生成に必要なプロセスキーを発見するための手法について報告する．これにより，ビジネスプロセスを可視化することができ，ビジネスプロセスの視点から業務分析や評価が可能となる．提案手法を
実システムの業務データへ適用し，本手法にてプロセスインスタンスを生成するための適切なプロセスキーを導出できることを確認した．
Recently, BAM technology that monitors businessactivities and business performances is being watched inexecuting a continuous business improvement by thePDCA cycle. In this paper, we propose a method to findout a process key necessary for generating the businessprocess instance that is the business flow actually
executed from the business data. As a result, it is able tovisualize the business process and analyze, evaluate on
the performance of business operations.
Actually, we applied the proposed method to somebusiness data of the real system, and confirmed theoptimum process key was able to be found out.

客名などが，出荷指示タスクでは，出荷指示日や出荷先，出荷番号などがある．これらの各タスクで出力された大量の業
務データを基に，プロセスインスタンスを生成する（個々の業務がどのような流れで実施されたかを再現する）ためのキーを見つける手法について示す．これは，業務プロセス管理手法である BPM（Business Process Management）[1][2]のPDCA サイクルにおける監視と分析・評価で利用される．具
体的には業務の実施状況や実績（パフォーマンス）を監視する BAM（Business Activity Monitoring）[3]-[5]において，実際に処理された業務プロセスを可視化する場合などに用いることができる．

図 1 対象とする業務と業務システムの例
Fig.1 Example: Target business process and system

2. 背景と課題
プロセスインスタンスは，業務システム上で個々の業務を実施した結果であるので，そのシステムの機能を用いてプロセスインスタンスを表示したり，業務システム固有のログファイルから導き出したりすることができる．しかし，これらの機能やログファイルなどの情報は，業務システムの仕組みや仕様に依存する．
ここでは業務システムに依存せずに，業務を実施した結果から入手できる業務データを使って，実際に実行されたプロセスインスタンスを生成（再現）する．
プロセスインスタンス 1

タスク
受注

受注番号:1345
製品名:AAA
型番:X11
数量:10

出荷
指示

受注番号:1345
数量:10
指示日:10/01
出荷番号:20

受注番号:6354
数量:7
指示日:11/23
出荷番号:27

受注番号:6354
数量:3
指示日:11/30
出荷番号:28

受注番号:1345
出荷番号:20
数量:10
出荷日:10/03

受注番号:6354
出荷番号:27
数量:7
出荷日:11/26

受注番号:6354
出荷番号:28
数量:3
出荷日:12/03

1. はじめに
ワークフローシステムなどのようにコンピュータ等を用いて複数の処理を順番に実施するような業務において，そこで出力されたあるまとまった業務データを使って，実際に実行された個々の業務フローを生成するためのキーを見つける手法について報告する．ここでは対象とする業務の処理手順をビジネスプロセス，それぞれの処理をタスク，実際に実行された個々の業務フローをプロセスインスタンスと呼ぶこととする．例えば，図 1 に示すような受注出荷業務では，受注→出荷指示→出荷確認のようにいくつかのタスクから業務が成り立っており，それぞれのタスクで出力された業務データとして，受注タスクでは，受注番号や製品名，型番，数量，顧♠正会員 三菱電機(株)情報技術総合研究所
Soma.Hitoshi@ce.MitsubishiElectric.co.jp♦
三菱電機(株)情報技術総合研究所{Murasawa.Yasushi@db, Shinozaki.Mamoru@ds,Motegi.Tsuyoshi@ah}.MitsubishiElectric.co.jp

1プロセスインスタンス 2

出荷確認

受注番号:6354
製品名:BBB
型番:Y32数量:10

図 2 プロセスインスタンスの例
Fig. 2 Example: Process Instance
一般に BAM のようなビジネスプロセスを監視するツール[6]では，個々のプロセスインスタンスを識別するためのキーを，ツールの使用者が明示的に設定する必要がある．ここで，このキーをプロセスキーと呼ぶこととする．図 2 では，受注番号をプロセスキーとして，一つのプロセスインスタンスに

日本データベース学会 Letters Vol.6, No.4

論文
DBSJ Letters Vol.6, No.4――――――――――――――――――――――――――――――――――――
属するタスクを識別することができる．これによりビジネスプロセスの視点から業務の分析や評価を行うことができるようになる．例えば，受注番号 6354 のプロセスインスタンスを見ると，1 つの受注に対して分割して出荷されていることがわかる．個々のプロセスインスタンスを明確にすることによりビジネスプロセス視点での分析を行うことが可能となる．
しかし，業務データのデータ項目がたくさんあったり，データ項目の意味が曖昧であったりする場合は，どのデータ項目をプロセスキーとして設定すべきかわからないことがある．
例えば，（一般にそうであるが）業務分析を実施する部門とシステムを構築する部門が異なる場合である．
本稿では，データ項目の意味が不明な場合でも，次に示す前提条件の下で（一般的に入手可能であると想定できる情報を使って），適切なプロセスキーを見つける手法について示す．
① ビジネスプロセスのタスク間のつながりが明確である② データがどのタスクで出力されたものか分かっている③ 各データがどのデータ項目であるか識別できる
図 2 の例で，上記条件は次のとおりである．①は，「対象とするビジネスプロセスは，［受注］［出荷指示］［出荷確認］のタスクからなり，この順番に処理される．」，②は，「表 1のデータが受注タスク，表 2 のデータが出荷指示タスクのデータであるということが分かっている．」，③は，「データ 1345がデータ項目 x01 であり，AAA が x02 であることが識別できる．」ということである．
表 1 受注データの例
Table 1 Example: Data of Sales Order Task
x01
1345
1564
4090
6354

x02
AAA
AAAAAA
BBB

x03
X11
X25
X11Y32x04
10202010x05
20070902
20070903
20070922
20070922

…

…

…

…

…

…
…
…
…
…
…

表 2 出荷指示データの例
Table 2 Example: Data of Shipping Instruction Task
y01
1345
1564
4090
6354
6354

202123
27
28

y02

y03
AAAAAAAAA
BBB
BBB

102020
7
3

y04

y05
ST-A
ST-A
ST-A
ST-A
ST-A

…

…

…

…

…

…
…
…
…
…
…
…

3. 提案手法
本稿の目的は，複数のタスクからなるビジネスプロセスと，各タスクの業務データから，プロセスインスタンスを生成することである．各タスクを結びつけるプロセスキーを見つけ，その値が同じものを同一のプロセスインスタンスと見なす．
したがって，2 つのタスクを結び付けるプロセスキーを見つけることにより，全体のプロセスインスタンスを生成することができる．例えば，図 2 の場合，受注タスクと出荷指示タスクは，受注番号をプロセスキーとして，出荷指示タスクと出荷確認タスクは，（受注番号はもちろん）出荷番号をプロセスキーとすることでも，プロセスインスタンスを生成することが可能である．よって，ここでは，隣接する 2 つのタスク間を結びつけるプロセスキーを求める．

3.1 手法の概要
本手法は，我々のこれまでのアプリケーション開発やシステム構築の経験，特に製造業を対象とした ERP システムの開2

発・構築にて扱った業務とデータの関係や特徴に基づいて考案したものである．
一般に製造業では，受注や調達，生産，出荷，会計など複数の業務が関連して全体業務が成り立っている．データの観点から，これらを関連付けるものとして，受注伝票番号や出荷明細番号など一連の業務データを識別するためのデータ項目が存在する．このデータ項目の値が同一のものが一つのプロセスインスタンスとなる．逆に言えば，あるデータ項目において，データの値が異なるものが多いほど，そのデータ項目はプロセスインスタンスを識別するキー，すなわち，プロセスキーである可能が高い．
また，対象とする業務によってはプロセスインスタンスにおける，あるタスクの個数が，その業務の特性によって決まってくる場合がある．例えば，ある出荷業務では，一つの出荷指示タスクに対して，複数の出荷確認タスクは存在せず，必ず一つだけ存在する場合などである．
本稿では，前章の前提条件に加えて，次の条件の下で，プロセスキーを発見する手法を示す．
A) 単一のデータ項目でプロセスキーとなるB) プロセスインスタンスにて，個々のタスクのインスタンスが複数存在するか業務の特性上明確となっている

3.2 アルゴリズム
本手法のアルゴリズムを示す．
Step1:
ビジネスプロセス上で隣接する 2 つのタスクに着目し，上記 B)の条件より，それぞれのタスクのインスタンスが複数存在する可能性があるかどうか表現する．すなわち，タスク T1，T2 の順番で処理される 2 つのタスクにおいて，ビジネスプロセスのパターンとして，BP(T1,T2) = {1:1 | 1:N | N:1 | N:N}とする．1:N は，タスク T1 の 1 つのインスタンスに対して，タスク T2 の 1 つ以上のインスタンスが存在する可能性があることを示す．
Step2:
それぞれのタスクのデータからデータ項目ごとにデータ値が異なるものの個数を求め，その値の大きい順にデータ項目名を並べる．すなわち，タスク T1 の業務データに対して，データ項目ごとの列ベクトル Ai（i = 1 .. n）から構成されるレコード数 m，カラム数 n の行列を A = [Ａ1 A2 .. An]とし，u(Ai)を列ベクトル Ai におけるデータ値が異なる要素の個数とすると，S(A) = [x1 .. xn]
xi: u(Ai)を降順に並べたときの対応するデータ項目名を求める．タスク T2 についても，業務データをレコード数 p，カラム数 q の行列 B とし，S(B) = [y1 .. yq]を求める．
Step3:
S(A)と S(B)のそれぞれの要素の総当りでデータ値が一つでも同じであるものを抽出し，S(A)と S(B)のそれぞれのデータ項目名の組み合わせをプロセスキーPK の候補とする．このとき，S の要素であるデータ項目名の順番が先のものほど，PK である可能性が高い．すなわち，抽出された個数を r とし，PKi = (xi, yi)，i = 1 .. r，xi, yi :データ項目名を求める．ここで，PKi,1 = xi, PKi,2 = yi とする．
Step4:
プロセスキーの候補ごとに，プロセスインスタンスの生成を試みる．タスク T1 における PKi,1 の各データ値とタスク
T2 における PKi,2 の各データ値が等しいものを同一のプロセスインスタンスと見なす．すなわち，プロセスキー候補 PKiより生成されたプロセスインスタンスのデータの個数 NPi は，

日本データベース学会 Letters Vol.6, No.4

論文
DBSJ Letters Vol.6, No.4――――――――――――――――――――――――――――――――――――
PKi の同一のデータ値を共有する T1，T2 それぞれのデータ数をα，βとし，PKi,1 のデータ値を di,j とすると，NPi(di,j) = (αj, βj)，j = 1..mとなる．
ここで，できるだけ多くの j について，αj:βj が Step1 のBP(T1,T2)となっている場合，PKi がプロセスキーとなる．すなわち，表 3 を満たす j の数が多いものがプロセスキーとなる．
表 3 プロセスキーの条件
Table 3 Condition for Process Key
1:1=1=1

αj
βj

1:N
=1>0

N:1>0
1

N:N>0>0以上の手順によりプロセスキーを見つけることができる．

3.3 具体例
表 1 と表 2 の太枠部分を例にとり，提案手法を説明する．
この例では受注タスクのインスタンス 1 つに対して，複数の出荷指示タスクのインスタンスが存在する．
Step1:
BP(受注, 出荷指示) = 1:N となる．
Step2:
受注では，u(A1) = 4, u(A2) = 2, u(A3) = 3, u(A4) = 2, u(A5) =3，出荷指示では，u(B1) = 4, u(B2) = 5, u(B3) = 2, u(B4) = 4,u(B5) = 1 となり，これより，S(A) = [x01 x03 x05 x02 x04]
S(B) = [y02 y01 y04 y03 y05] となる．
Step3:
S(A)と S(B)を縦横とする表を作成し，データが一つでも同じものを○，異なるものを×とすると，表 4 のようになる．
表 4 プロセスキーの候補の例
Table 4 Example: Process Key Rank
y02
y01
y04
y03
y05

x01
×
○×××x03
×××××x05
×××××x02
×××
○×x04
○×○××

表 4 の○のついたデータ項目名を抽出する．このとき表の左上にあるほど，プロセスキーとしての可能性が高く，
PK1 = (x01, y01），PK2 = (x04, y02)，PK3 = (x04, y04），
PK4 = (x02, y03）となる．
Step4:
BP(受注, 出荷指示) = 1:N に合う NP の個数は，NP1 は，NP1(1345) = (1,1)，NP1(1564) = (1,1)，NP1(4090)= (1,1)，NP1(6354) = (1,2) で，4 個，NP2 は，NP2(20) = (2,1)，NP2(10) = (2,0)で，0 個
NP3 は，NP3(10) = (2,1)，NP3(20) = (2,2)で，0 個
NP4 は，NP4(AAA) = (3,3)，NP4(BBB) = (1,1)で，1 個となる．この結果から候補 1 の PK1，すなわち，受注データの x01 と出荷指示データの y01 がプロセスキーとなる．

4. 適用と評価
本章では，提案手法を異なる 2 つの業務システムのデータに適用したときの結果について報告する．

4.1 評価データ
4.1.1 発注業務データ
組織において物品等を購入する場合に，購入申請を行い，承認されると業者への発注を行う発注業務を対象として，そ3こで出力されたデータを用いて評価を行う．この業務では，一つの申請で複数の発注が存在することがある．
このデータの大きさを表 5 に示す．申請データの項目の一
例は，整理番号，区分，用途目的，金額，提出日時，処理者，状態など，発注データは，買券番号，見積番号，登録日，発注日などであるが，ここでは，これらの項目名は不明とする．
表 5 適用データ 1 の大きさ
Table 5 Size of Test data 1
申請データ
発注データ

カラム数
136

レコード数
25374745

4.1.2 受注出荷業務データ
顧客からの受注にしたがって，製品を生産あるいは調達し，注文した顧客へ製品を出荷する受注出荷業務を対象として，そこで出力されたデータを用いる．これまでの説明で，例として用いてきた業務に相当する．
このデータの大きさを表 6 に示す．受注データの項目名の一例を挙げると，受注番号，受注明細番号，製品名，型番，数量，営業所，生産工場，顧客番号，受注登録日，納期などであるが，ここでは，これらの項目名は不明とする．
表 6 評価データ 2 の大きさ
Table 6 Size of Test data 2
受注データ
出荷指示データ
出荷確認データ

カラム数393311

レコード数
778513670

4.2 評価実験
本手法を Java で実装し，プロセスキーを求めた．

4.2.1 評価データ 1 を用いた適用結果
申請データ，発注データのデータ項目名をそれぞれ xnn,ynn （nn は 01，02 などの数字）とする．
業務の特性から，BP(申請, 発注) = 1:N となる．
Step3 を実施した結果，図 3 のようになり，PK1 = (x02,y01), PK2 = (x12, y06), PK3 = (x07, y06) の 3 個が抽出された．

図 3 申請と発注の組合せによるプロセスキーの候補
Fig. 3 Process Key Rank using Test data 1
次に Step4 にて，1:N に適合する個数は次のようになった．
NP1(038518) =(1,1), NP1(038457) = (1,2), … で， 2186 個
NP2(2007-06-29 00:00:00) =(1,32) で，1 個
NP3(2007-06-29 00:00:00) =(1,32) で，1 個
結果的に，申請データの x02 と発注データの y01 をプロセスキーとして求めることができた．実際，これらのデータ項
目は，x02 が整理番号，y01 も同一の整理番号であり，申請データと発注データを関連づけるキーとして働いているものであり，相応しいプロセスキーを見つけることができた．

4.2.2 評価データ 2 を用いた適用結果
受注データ，出荷指示データ，出荷確認データのデータ項
目名を先ほど同様，それぞれ xnn, ynn, znn とする．
まず，受注データと出荷指示データに対して，本手法を適用する．業務の特性から，BP(受注, 出荷指示)＝1:N である．
Step3 の結果は図 4 の通りであり，PK は 48 個抽出された．
PK1 = (x23, y03), PK2 = (x38, y08), PK3 = (x08, y03), …

日本データベース学会 Letters Vol.6, No.4

論文
DBSJ Letters Vol.6, No.4――――――――――――――――――――――――――――――――――――
4.3 評価結果
評価データ 1 および評価データ 2 について，本手法にてプロセスキーを見つけることができ，有効性が示された．

5. おわりに図 4 受注と出荷指示の組合せによるプロセスキーの候補
Fig. 4 Process Key Rank using Test data 2-1
Step4 を実施し，PK1 ～ PK10 について，1:N となるプロセスインスタンスの個数を計算した結果が図 5 である．これより，2 番目の候補の PK2 = (x38, y08) が求められた．実際，
x38 は販売伝票番号，y08 は販売伝票番号を表す参照伝票番号であり，プロセスキーとして相応しいものであった．
160140120100806040200PK1PK2PK3PK4PK5PK6PK7PK8PK9PK10

図 5 受注と出荷指示が 1:N であるインスタンスの個数Fig. 5 Count of process instance on 1:N pattern
次に，出荷指示データと出荷確認データに対して適用した．
BP(出荷指示,出荷確認)＝1:1 であり，PK は 17 個抽出された．
PK1 = (y07, z11), PK2 = (y03, z08), PK3 = (y08, z03), …
Step4 を実施し，PK1～PK10 について，1:1 となる個数を計算した結果が図 6 である．これより，1 番目の候補の PK1= (y07, z11) が条件に当てはまった．実際，データ項目 y07と z11 は出荷伝票番号であり，プロセスキーとして相応しいものであった．なお，3 番目の PK3 の y08 は参照伝票番号であり，z03 も参照伝票番号であった．

[文献][1] Lee YeongSeok, Bae JungHyun, Shin Seokkoo.
Development of Quality Evaluation Metrics for BPM(Business Process Management) System. ICIS`05. 2005.
[2] M.Weske, W.M.P. van der Aalst, H.M.W. Verbeek.
Advances in business process management. Data &Knowledge Engineering 50. 2004.
[3] David W. McCoy. Business Activity Monitoring: Calm
Before the Storm. Ｇartner,Inc. 2002.
[4] Matteo Golfarelli, Stefano Rizzi, Iuris Cella: Beyond
data warehousing: what's next in business intelligence?
Proceedings of the 7th ACM international workshop on
Data warehousing and OLAP. 2004.
[5] 細川武彦,上野浩一郎,馬場昭宏,砂田英之,北山泰英,相浦利治,茂木強:"ビジネスプロセスモデルを活用した BAM シス
テム構築の提案",情報処理学会研究報告, DSM. 2006.
[6] IDS Scheer. ARIS Process Performance Manager (ARISPPM): Measure, Analyze and Optimize Your Business
Process Performance. IDS Scheer, Saarbruecken,Gemany, http://www.ids-scheer.com, 2002.

相馬 仁志

Hitoshi SOMA

三菱電機株式会社 情報技術総合研究所勤務．1990 北海道大学大学院工学研究科修士課程修了．上流工程業務分析技術，ビジネスプロセス管理技術の研究・開発に従事．日本データベース学会正会員．情報処理学会正会員．

村澤 靖

400

Yasushi MURASAWA

三菱電機株式会社 情報技術総合研究所勤務．1986 千葉大学
理学部卒業．IT サービス管理技術，運用管理技術の研究・開発に従事．情報処理学会正会員．

350300250

篠崎 衛

200

三菱電機株式会社 情報技術総合研究所勤務．1984 早稲田大
学理工学部卒業．言語処理系開発技術，システム性能評価技
術，ソフトウェアエンジニアリング応用技術，業務・システ
ム分析技術，ビジネスプロセス管理技術の研究・開発に従事．

150
10050

茂木 強0PK1PK2PK3PK4PK5PK6PK7PK8PK9PK10

図 6 出荷指示と出荷確認が 1:1 であるの個数Fig. 6 Count of process instance on 1:1 pattern

4

業務システムで出力された業務データを基に，実際のプロセスインスタンスを生成（再現）する手法について報告した．
本手法は，BPM/BAM の観点で業務監視，業務分析を行う最初の一歩として，個々のプロセスインスタンスの可視化を念頭においたものである．業務分析をより深く進める段階では不明としたデータ項目などの意味を明確にしていく．
今後の課題としては，プロセスキーが複数のデータ項目やデータ項目の一部分からなる場合への対応がある．また，ビジネスプロセスとしてタスクが直列に並ぶ最も単純な場合で評価したが，分岐，結合，並列などが存在する一般的なビジネスプロセスに対しても適用可能であると考えており，今後，適用による評価を行っていく．

Mamoru SHINOZAKI

Tsuyoshi MOTEGI

三菱電機株式会社 情報技術総合研究所勤務．1980 京都大学
理学部卒業．1994 スタンフォード大学大学院計算機学科修了．コンパイラおよび計算機システムアーキテクチャに関する研究・開発に従事．

日本データベース学会 Letters Vol.6, No.4