システム奮闘記：その85

BPMN ビジネスプロセスモデリング表記法の入門

はじめに

　処理の流れ図といえば思いつくのが

　フローチャート

　なのだ。
　これは以前からあり、プログラムやシステムの処理の流れだけでなく
仕事の流れを描く手法として知られている。

カタカナ用語だと意味がわかりづらい。
この手の類の用語は、英語のままだと、意味がわかりやすい。

Flowは「流れ」で、Chartは「海図、図表」という意味だ。
つまり「流れ図」という意味になる。

フローチャートは「処理の流れ」という意味なので
英語では「Flow Chart」(流れ図)という言葉を当てはめている。
日本でもカタカナではなく、意訳してくれたら、わかりやすいのだが
どうもカタカナ大好きの国民性は治療しようがないと思う (--;;

　だが、フローチャートには問題がある。

　複数の処理を同時並行で記述できない!

　具体的に、どういう事なのかを見てみます。

受注から商品の発送までの流れ
うちの会社の場合を見てみた。 (AS400の部分をのぞけば、大抵、どこの会社も似たり寄ったりだろう) 受注から発送までの流れを描いている。 だが、個々の担当業務の流れを描く事はできても 他の担当者(他部署)との連携まで描く事はできない。

　複数の処理を連携が見える形で表現する事ができない問題点がある。
　だが、それを解消する方法がある。それがBPMNなのだ。

　というわけで、今回はBPMNの導入に至る話を書きます。

BPMNと出会いまでの紆余曲折の道のり


　ところで、出会いというのは、ひょんな所から起こる場合が多い。
　BPMNとの出会いも、意外な所からの出会いだった。


　紆余曲折の話なので、この部分は読み飛ばしていただいて
構いません (^^)

　2010年になって、ふと思った。

　5年前にポインタを理解できたなぁ

　学生時代にC言語と出会ったが全く理解できずに、10年がかりで理解したのだ。
　詳しくは「システム奮記:その36」のC言語のポインタ入門をご覧下さい。


　だが、それからC言語と、ご無沙汰だったので

　すっかりC言語は忘れてしまった!!

　なので、ポインタ、構造体を理解した2005年の時点に巻戻す事になった。


　そこで次の本を取り出した。
　「C for Linux 実践Linuxシステムプログラミング」(小俣 光之:秀和システム)


　RPCの話が出てきた。
　RPCといえはWindowsのセキュリティー問題で話題になる部分なのだ。
　2005年当時は・・・

　そんな危険な物を使わへんで！

　という事で、RPC関連のデーモンなどを停止させていた。
　そして全く関心だった (--;;

　でも、「使わない」のと「知らない」とは全く意味が違う上
知らないのは良くないと思い、どんな物か調べてみる事にした。
　そこからC言語の復習から脱線が始まった。


　RPCは、どういう意味なのか。
　すると次の意味があった。

　Remote Procedure Call(遠隔手続き呼び出し)

　図式化すると以下の事だった。

RPC(遠隔手続き呼び出し)の概略
RPCとはあるプログラムから他のコンピューターにある手続き(処理)を 実行可能にする技術だ。 図のようにクライアントのプログラムが サーバー(他のコンピューター)の処理を実行させる事だ。 必要に応じて、クライアントから引数を送り、 サーバーで処理終了後、返り値(実行結果)を返すのだ。 平たく言えば、自分のパソコンから、他のコンピューターのプログラムを 遠隔操作で実行させて、その結果をもらう事なのだ。

　クライアント・サーバーの基本やん!

　と思った。

　RPCについて調べていくと、MS-RPCと出くわした。
　OSF(Open Software Fundation)が規定した物をMicrosoftが拡張した

　分散コンピューティング環境

　なのだ。

　ちなみにOSFはソフトウェアのオープン化を促進する団体なのだ。
　と知ったかぶりをしてみたいのだが、「オープン化」の意味が、
イマイチわからんだけに、すぐにメッキが剥がれる・・・ (--;;



　遠隔手続き呼び出しについて、色々なサイトなどを見ていくと
他にもある事を知った。

　名前は見た事があるのだが・・・

　どんな物なのか、全くわからへん (--;;

　どんどん知らない事が出てくる。


　まずはCORBAを見てみた。
　CORBAは異機種間の相互運用性、拡張性などの優れているという。

　ところで・・・

　CORBAって何やねん!

　そこで意味を調べてみると

「Common Object Request Broker Architeture」の略だ。

Brokerという単語に注目。
カタカナで「ブローカー」といえば悪い意味合いで使われる事が多いが
正しい意味は単なる「仲介者」なので、悪い意味合いはない。

CORBAは、共通のオブジェクト(プログラムなど)を要求する時の
仲介役をする技術なのだ。
でも、これだけだと、よくわからん・・・ (--;;

　そこでTECHSCOPE:CORBA概要を見てみた。

　CORBAの屋台骨となるORB(Object Request Broker)の説明があった。
　ちなみに、ORBとは「オブジェクト間の通信を仲介者」の事だ。

　図式化すると、わかりやすい。

ORB(オブジェクト間の仲介者)の概略
クライアント側と、サーバー側の双方にORBがある。 クライアント側のオブジェクトのプログラム言語と サーバー側のオブジェクトのプログラム言語)が異なる場合がある。 ORBはプログラム言語のデータ形式を共通データ形式に変換し 異種言語間のデータのやりとりを可能にしている。 それと同時に、異種マシン間の通信のプロトコルを用意して 双方が通信可能にしている。

　つまりクライアント、サーバー双方で動いているプログラムや
通信プロトコルの違いを吸収し、双方が通信できるようにする
仲介者がORBなのだ。
　要するに・・・

　異種マシン間のやりとりを可能にさせる仲介者!

　なのだ。

　色々、調べていく間に、SOAと出会う。

　SOAって何やねん?

　調べてみると、以下の略語だという。

　Service Oriented Architecture
　(サービス指向アーキテクチャ)

　だが、略語の意味を見ても・・・

　だから何やねん!! (--;;

　なのだ。そこで調べてみた。
　するとアプリケーションをコンポーネント化(部品化)する手法だという。

　CORBAはSOAの考え方そのものやん!

　つまり、こういう事だ。

アプリケーションのコンポーネント化(部品化)
今までのアプリケーションは全ての機能を、ひとまとめにしていた。 SOAの考え方は、各機能ごとに部品にする事なのだ。 それがアプリケーションのコンポーネント化(部品化)なのだ。

　各部品にわける上、異種マシン間での通信も可能にすれば
アプリケーションの処理を、各マシンに分散処理させる事もできる。

分散処理が可能になる
異種マシン間の通信が可能になる事で、部品Aの処理はマシンA。 部品Bの処理はマシンBといった感じで分散処理が可能になる。

　分散コンピューティングやん!

　そして、この考え方は・・・

　クラウドに通じるのではないか!!


　だが、これだけだと、まだSOAの本質をとらえていない。
　コンポーネント化(部品化)と分散処理。
　それによって以下の事ができるようになるのだ。

SOAの考え方以前の業務処理システム
SOA以前の業務システム(上の例では販売管理システム)では 全ての処理が一体化している。大がかりなプログラムになっている。
SOAの考え方導入によるシステムの処理別の部品化
システムの各処理を、一体化させずに部品化を行なう。 ブロックのように組み合わせで合体、分離できるようにする。

　各処理ごとに部品化し、独立した形で稼働させる。

各処理が独立した形で稼働している
各処理を部品化し、独立した形で動かす。 各部品とは、データの入出力のやりとりにする事で、 各部品を動かしている機種を同一機種にする必要もない。 分散処理を行なって、部品化したプログラムの言語が異なっても 全く問題がなくなる。
機能追加は部品の追加と同じ感覚で行なえる
そして必要に応じて、いつでも部品の追加、削除が行なえる。 パソコンのハードディスク、メモリなどの交換で、 簡単に取り外しができたり、装着できたりする感覚と同じだ。 企業活動が動きの早さが求められている中、いかに迅速に対応できるように 必要に応じて、部品の交換、追加、削除が行なえるようにするのが有効だ。 もっと大きな視点で見ると、企業の合併や部門の統廃合があった場合 システムの統一作業の労力を省くために有効だ。 部品の取り替え、変更を行なうだけで済むような仕組みにすれば 良いためだ。

　実際に、完全に部品化したりするのは困難(不可能？)だろうが
概念としては、理想的な物だと思う。

　C言語の勉強からRPCで脱線して、SOAにたどり着いた私。
　何やら、大がかりな物に辿り着いた感じだ。

　そして次の文字が目に入った。

　SOAとBPMの親和性

　だが、思った。

　BPMって何やねん?

　BPM（Business Process Management）の略だ。
　直訳すると「業務手順の管理」だ。

　業務手順の管理。
　業務のあり方で「これが完璧」という物は存在しない。
　環境、市場、規模、人員などで最適解が変わってくる。
　そして、世の中は変化していくため、それに合わせて
業務のあり方(業務手順)の最適解が変わってくるため、
常に環境に合わせながら改善が求められる。

　この改善は、まさにPDCAサイクルが当てはまる。

BPMとPDCAサイクル
変化していく環境に合わせながら、業務のあり方の最適解を求める際、 常に改善が求められる。そのためにはPDCAサイクルの仕組みが必要だ。 BPMとは以下の事だ。 業務改善が行なえる仕組み(業務管理)が確立し、最適解を求める事。

　SOAとBPMとの親和性。

　まずは各業務処理を部品化して考える。
　業務変更の際、部品化した各処理の配置を変更したり
追加や削除を行なうようにすれば、扱いが簡単になる。

　システムの部品化と、業務の部品化を重ね合わせて考える!

　これがSOAとBPMの親和性だ。

　「業務手順の管理」(BPM)を行なうために、業務の流れを記述する
表記表が求められる。

　ここで重要なのは、技術者だけでなく、経営陣にも理解できる表記法だ。

技術者だけでなく経営陣にも理解できる表記法
業務改善を行なう際、業務の流れの図が必要になる。 特にITを活用した業務改善を行なっていく場合 技術者と経営陣の双方が理解可能な業務の流れの表記法が必要になる。

　技術者と経営陣の双方が理解できる表記法。
　それが・・・

　BPMNなのらー!!

　紆余曲折しながら、BPMNにたどり着いた。


　ちなみにBPMNは「Business Process Modeling Notation」だ。
　BPMは「Business Process Management」なので、略字だけ見ると
BPMNとBPMは似たような物だと思ってしまいそうだ (^^;;

BPMNのお勉強開始


　@ITのBPMNの説明を読んで見る事にした。
　BPMNを活用したビジネスプロセス・モデリング


　業務の流れを描くだけでなく、描き出した処理内容を
プログラムの実行言語にまで落とし込む事まで可能だという。

フローチャートとの違い

　そしてフローチャートとの違いが見えてきた。

　例としてフローチャートで受注から商品の発送までの過程を描いてみる。

受注から商品の発送までの流れ
うちの会社の場合を見てみた。 (AS400の部分をのぞけば、大抵、どこの会社も似たり寄ったりだろう) 営業事務担当者は電話やFAXなどで、お客さんからの注文を受ける。 そして受注伝票を起票し、その内容を基幹システムのAS400に入力する。 出荷可能な場合は、納品伝票を発行する。 配送担当者は、AS400に入力された受注データに基づいた 出荷依頼書を見て、在庫を確認し、出荷可能であれば AS400に出荷可能を入力し、商品の梱包を行なう。

　確かに、フローチャートの場合、各人の仕事の処理が見えるのだが

　同僚との連携が見えへん！！

　1人だけで完結している仕事なら問題ないが、会社の場合、組織なので
1連の処理を、複数人の同僚が連携して行なっている。

　これをBPMNを使って描くと以下のようになる

BPMNを使って受注から商品発送までの流れを描いてみた
営業担当者と、配送担当者との仕事の連携まで描く事ができるため 個々の担当者だけの処理だけでなく、各人の業務全体の流れまで把握できる。

　同僚との連携が見える!!

　これは凄い利点だと思う。

　業務処理を見る際、フローチャートの場合だと、個々の担当者が行なう
処理内容しか描かれていないため、同僚との連携が見えない。
　そのため問題点が出てくる。

優先順位の付け方を誤る

入社して数年間は、なかなか同僚との仕事の連携は見えない。
その上、同僚との連携がわかりやすく描いた業務マニュアルがないと
自分一人だけの処理だと思ってしまいがちになる。
急いで処理して、同僚にバトンタッチをしないといけない仕事であっても
同僚との連携が見えていないと、優先順位の付け方を誤って
後回しにしてしまう事もある。

もちろん、私自身、優先順位を誤っていたため、仕事の処理を後回しにして
怒られた事が多々ある (^^;;

仕事の重要度の認識に温度差が生まれる

ある仕事があり、その処理を単体だけで考えると重要度が見えてこない。
全体像が見えて、一連の流れの重要度を認識して、単体での処理の重要性が認識できる。

例え、最重要な仕事であっても、何の説明もなしに、一部分だけ見せられて
「この仕事をしておいて」と言われても、重要度が伝わらない。
そのため重要度を認識できない恐れが出てくる。温度差が生まれるのだ。
最重要課題で、一丸となって取り組むべき仕事であっても、
温度差の違いにより、うまく連携できない事も出てくる。

　仕事において、全ての処理を迅速に対応するのが理想なのだが
人間の能力や時間は限られている。効率良く処理していくには
優先順位を付けて、大事な事から先にやる必要があるのだ。

　
　そして、BPMNを使って業務の全体像を描き出す事の利点が見えてきた。

業務の問題点の発見に使える

　私が所属する総務部では定期的に会議を行なっている。
　各人が問題点を出し合っているのだが・・・

　各人の問題点を把握しづらい!

　ここに中小企業ならではの問題点がある。
　総務部は「何でも屋」という位置付けなのだ。
　うちの会社の総務部も中小企業の典型例で、所轄する業務範囲が広い。

　庶務、労務、経理、システム、営業事務などなど

　他にもある。
　これだけ広いと総務部員全員が各人の業務の流れを把握する事は困難だ。
　しかも、中小企業では、その分野の担当者が1人というのはザラだ。

　そのため同じ総務部員でも私のようなシステムを担当していたら
労務の処理の流れが見えないだけでなく、知らない事ばかりだ。

問題点を聞いても理解できない問題
労務担当者が「こんな問題点があります」と言っても、 私の場合、労務の知識がない上、業務の流れも知らないため 一緒になって考える事ができない問題が発生する。 3人集まれば文殊の知恵なのだが、それだけの人数もいないため 担当分野によっては、誰も助けの手をさしのべられない状況になる。

　そのため問題点を聞いても

　大変だなぁ・・・

　で終わってしまう。
　そのため、各人が問題点を出し合っても、そこから解決へ進める事もできない。


　本当に問題を解決していくには、相手の業務の流れを知る必要がある。
　そこで、BPMNを使って、各人の業務全体の流れを見やすい形に描きだし
総務部員で問題が発生している業務の流れを共有する事で、
議論をしやすくなるので、問題解決に近づける事が期待できる。

業務の流れを把握して、ようやく問題点が見え 解決に向けて考える事ができる
BPMNという手法で、業務全体の流れを描いて、総務部員全員に配布すれば 労務担当者の業務の流れを把握しやすくなり、問題点があった場合 各人が知恵を出しやすくなる利点がある。

　システムを担当する私にとっても、BPMNで描き出された業務の流れを見て
相手の業務の内容を把握しやすくなる上、どの部分の手作業をシステムを使って
自動化すれば良いのかが考えやすくなる。

BPMNを習得し、各人が描いた個々のBPMNを使って
お互いの業務内容を理解し、業務改善を行なえば理想だ。

だが、現実は甘くない。
担当者が忙しいため、業務内容を描く余裕がない事も多々ある。
そして、BPMNを活用して、業務内容を描く事ができても
専門性が高い仕事の場合、容易な表現を使っても
やはり他者には理解するのが困難な場合もある。

なので、万能薬というわけではない。

外部セミナー受講

　BPMNの導入利点が見えてきた。
　だが、独学なので知識に偏りがあったり、まだ私の知らない活用法などが
考えられるので、外部セミナーを受講して、知識の整理を考えたのだが・・・

　受講許可が得られへん (TT)

　社内でBPMNを導入した経験は全くない。
　それどころか「BPMNとは何やねん?」の世界だ。

どこの企業でもセミナー受講は、会社にとって利益がないと許可はでない。
うちの会社も同じだ。

ところで、上層部に、誰か一人でもBPMNを知っている人がいれば
話がしやすい上、セミナー受講許可が得られやすくなるが
そうでない場合、なぜ、受講する必要があるのかを説明する必要がある。
しかし、受講希望の私にしてみれば、BPMNの知識が曖昧だからこそ
受講したいのだ。そして上層部に対して上手に説明するのは困難なのだ。
もし、上層部に対して上手に説明できるだけの知識があれば
セミナー受講の必要性はなくなる。

セミナー受講のために会社の利益を説明しなければいけないが
その説明をできるだけの知識がないため、セミナーを受講しないと
キチンと説明できない矛盾が出てくる。

　許可が得られなくても、その程度で、めげる私ではない。
　という事で・・・

　有給取得なのらー!!

　で、有給取ってセミナーを受講する事にした。
　2010年2月17日、NECネクサソリューションズの
「効果的なビジネスプロセスモデリング手法について」を受講する。

　有給なので気楽に受講できる。
　とはいえ、交通費という自腹を切っているだけに、元を取ろうという気はある。


　セミナーで2つの事を学んだ。

　3階層BPMN

　3段階BPMN

　この2つについて説明していきます。

3階層BPMNについて

　新規業務を経営層、管理層、現場層の3階層に分けてBPMNを描く事なのだ。

まずは経営層がBPMNで描く
新規業務の方向性を決定するのは経営層。最高意思決定機関の取締役会だ。 決定した事について、管理職、現場に伝える意味合いを含めて どこ方向性で、どのような業務の流れにするのかを大雑把にBPMNを使って 経営層に描いてもらうのだ。 経営層で決まった事を大雑把にわかりやすく表現法(BPMN)で描く事で 管理職、現場に対して会社の決定事項を円滑に伝えられる利点があるのだ。

　次に、管理層で肉付けを行なっていく。

そして管理層がBPMNに肉付け
役員会で決定され、BPMNを使って新規業務の大雑把な流れ図を 各部門を統括する管理職が肉づけを行なう。

　だが、管理職が統括している部門の業務を、詳細まで把握しているわけではない。
　そこで最後に、現場の担当者に肉付けを行なってもらう。

最後に現場の担当者がBPMNに肉付け
最後の詰めの部分で、実務を行なっている現場の担当者に 肉付けを行なってもらう。 これにより、詳細まで描いたBPMNが完成するのだ。

　大雑把な方向性を経営層が描き、それを管理職、現場担当者が
肉付けを行なっていく方式だ。


　この方法だと良い事がある。

　経営層が何をどうしたいのかを把握しながら

　管理層、現場が肉付けを行なえる!


　新しい事を行なう際、大筋を関係者に見せる

3段階BPMNについて

　BPMNは・・・

　わかりやすさがウリ!

　なのだ。

　もし、ある業務改善を行なう際、最終目標を示すのは大事だ。
　そして、現状の業務の流れも示す必要がある。

現状と最終目標を示す事が大事!
現状と最終目標の両方のBPMNがある事によって、両者の比較ができ 何をどう改善していくのかが、わかりやすくなる。

　最終目標(理想、あるべき姿)を提示する事で、会社が、
どの方向に向かっているのかが、現場にもわかりやすい。
　経営陣だけがわかっていても、現場に伝わらなければ

　会社は社内全員、運命共同体だけに

　進むべき方向性を全員が共有が必要!

　なのだ。


　そして現状のBPMNがある事で

　最終目標との比較が容易になり

　何をどうしたいのかが、わかりやすい!


　でも、それだけだったら3段階ではなく、2段階になってしまう。
　それに、世の中、理想的な最終目標まで一足飛びできるものではない。

一足飛びで最終目標には困難
高い目標や理想を掲げるのは良い事だ。目標が設定できるからだ。 でも、いきなり、それを行なうのは無理だ。

　無理に高い目標を実現させようとすると大抵は・・・

　ホップ、ステップ、肉離れ (--;;

　になってしまう。


　そこで「現時点で可能な目標」として中間目標を設定する必要がある。

現時点で可能な目標設定
現時点で可能な目標設定を行ない、着実に業務改善を進める。 最初から、いきなり高い目標を設定して挫折しては、やる気を失うが 一歩、一歩、前に進む事で無理なく高い目標へ近づく事なのだ。 まさに「急ばが回れ」で、欲張って一足飛びするのではなく 改善、検証、改善、検証の試行錯誤しながら、最終目標に近づけていくのだ。

　そして中間目標のBPMNを作成する利点は、もう1つあるという。

中間目標のBPMNを作成する利点
中間BPMNは、単に実現すべき目標を示す物だけではない。 経営層が大筋を描き、管理層・現場が肉づけしているため 中間目標達成後は、立派な業務マニュアルに活用できる。

　中間目標が達成された時、以下の図式になる。

中間目標が達成された時
中間目標が達成された時、中間目標は現状業務になる。 そして、最終目標に向かう。 最終目標に一足飛びするのか、もう1段階、中間目標を作成して 着実に前に進むのかは、状況に応じて行なっていけば良いのだ。

　ふと、思った。
　これって・・・

　規模の大きいPDCAサイクルやん!

PDCAサイクル

　つまり現状を認識し、試行錯誤しながら、着実に中間目標を達成していき
最終目標に向けての前進しているのだ。

　聞けば当り前の事なのだが、ハッとさせられる話だった。



　セミナー終了後、確信を得た。

　BPMNは業務改善を行なう上での強力な道具!

　なのだ。
　凄く価値のあるセミナーだった。


　このセミナーで出てきた3段階BPMNや3階層BPMNについては
「UMTP JAPAN BPMN研究会」の資料に基づいているようだ。
　講師の先生が、この研究会の2009年度の関係者だからだ。
　BPMN研究会(2009年度)

　資料を見るよりも、関係者の方が、噛み砕いて説明してくださったので
理解するまでの時間が短縮できた (^^)

いざBPMNを社内に導入

　BPMNは絶対に社内に導入する
　さて、社内にBPMNを導入していこうと考えた。
　そこで導入利点を上に示すために、まとめてみる事にした。

　そして具体例を示すため、2点ほど、複数人が関わる業務処理を
BPMNの表記を使った資料を作成した。

便利な業務マニュアル

社内の業務マニュアルを図式化する事で
わかりやすくする効果と、複数の部署をまたぐ業務を
記述ができるため、連携の必要性の認識ができたり
 
今までのマニュアルですと、その人のみの作業内容や
他者との連携が断片的な事しか書かれていないため
他者との歩調合せを忘れがちになったり
他者への連絡漏れなどを起こしやすい状態です。

今、取り組むべき事への応用

BPMNを使って、現状の流れと、目指すべき方向を描けば
全体的に何をしようとしているのかが把握しやすいです。
物事に取り組んでいる際に問題点が発生しても
各人が全員が流れを把握する事で、全体的な視点での
作業工程の変更などが議論できるため、部分最適化ではなく
全体最適化で考えやすくなります。

上層部と実務担当者との意思疎通の円滑化

役員会で決定した事を、上の方で大まかに全体像を
BPMNで使って図式化すれば、実務担当者しても
上で何をやろうとしているのかが把握しやすい上
実務面で担当者が肉付けを行ったり、実務面で
問題が発生する場合も、どこで何が起こっているのかを
図で説明する事で、上も把握しやすくなりますので
意思疎通をはかりやすくなると思います。

やる気を引き出しやすくする点

何か行う際、全体像を示されずに、各担当に対して
関係部分だけ見せられて「これをしなさい」では
イマイチ、何を行うのかが見えず、言われた方は
受け身の姿勢になりがちです。
 
しかし、全体像を把握し「これを実現した時には
これだけ良い事があります。そのため、この部分については
あなたの力が必要なので、是非、やりましょう」ですと
能動的な気分になります。

工程管理表に使えます

複数人の工程を描く事ができますので、
複数人で何かに取り組む際の役割分担や作業工程を
図式化できますし、誰と誰が連携しているのかも
一目でわかりますので、意思疎通の必要性を認識したり
打ち合わせ事に進捗情報で、各人が、
どこまで作業ができているのかがわかります。

　そこで役員に報告する事にした。
　すると・・・

　好情報!!

　という反応だった。


　まずは現状の業務分析と、業務マニュアルの作成からだ。



システムの処理も描ける

　BPMNの練習として、ある業務の分析を行なう事にした。
　すると・・・

　担当者だけでなくシステム処理も並行して描ける!

　受注から商品発送までの流れを、システムの処理を描いていない物と
描いた物との比較を行なってみます。

受注から商品発送の流れ (システム処理を描かない)

　この場合、他者との連携がよく見える。
　でも、システム部分が見えていない。
　そのため裏で、どういう処理が行なわれているのか、わからない。

　だが、システム処理も並行して描くと以下のようになる。

受注から商品発送の流れ (システム処理を描く)
営業事務の担当者と、配送担当者とのやりとりを仲介したり データの処理を行なうシステム部分が、鮮明に見える。

　システムが担う裏方部分は、業務処理担当者には見えなくても
あまり問題ではないが、システム管理者としては必須だ。
　なぜなら

　障害発生時の原因究明に役立つ!

　ある処理の部分で、異常が発生した場合、システム部分が見えていれば
当たりをつけて、原因究明を行なう事ができる。


　それに加えて、裏方のシステム処理がわかる事で・・・

　全体的な視野でシステムの改善がしやすくなる!

　システムを構築した本人なら、例え、処理の流れ図を書かなくても
頭の中に入っているため、何かあっても対応しやすいが
そうでない人から見ると、業務とシステムの関連がわかりづらいため
いくら技術を知っている人であっても、処理の流れ図がないと
最初から調べていく必要があるため、把握するのに時間がかかる。

　そのため、第三者が見て「なるほど」と思えるような
人とシステムと流れ図があれば、便利になるし
問題があっても改善しやすくなる。


補遺

　BPMNは厳密に業務工程を描く事で、プログラムの実行言語に
落とし込む事ができます。
　でも、今回は、そこまで踏み込む事はしませんでした (^^;;

　機会があれば、BPMNで表記した業務処理を
実行言語に落とし込んだ例を紹介したいと思います。
　何年先になるかは、全くわかりませんが、気長に取り組みます。


最後に

　BPMNは業務の流れ図を、わかりやすく描く手法として最適です。
　複数人の工程が並行して記述できるため、他者との仕事の連携もわかり
同僚と協力しながら仕事が行ないやすくする業務マニュアルにも使えます。

　私の勤務先でも、始まったばかりなので、どこまで効果が得られるかは
未知数ですが、BPMNを上手に活用した時の効果は大きいと考えていますだけに
これからが勝負だと思っています。


　BPMNの記述法は岩田研究所の資料に詳しく書かれています。
　岩田研究所:BPMN