立替金申請プロセスを月次起動させるタイマー設定

立替金申請を紙で回していると、他人の立替金の内容を覗き見る機会は無い。しかし、立替金申請がオンラインで全社可視化されると意外にも他人の立替金内容を見る事が多い。
そして、徐々に社内に「モラル」が生まれ、また「常識の範囲」が醸成される様になる。

立替金の申請を（極力）月に一人一枚にまとめてもらうべく、件名が「佐藤 3月分」と初期値設定された『1.立替金申請』タスクを月初にタイマー起動する。すなわち一か月間近く『1.立替金申請』で滞留させ、何度も上書き保存する習慣を付けてもらう仕掛けだ。

• 『お金の流れを社内に可視化する勇気を持とう』
• 『予定請求書登録で毎月のキャッシュアウトを予測』

を拡張する。


＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認

[立替経費申請-支出確認-月初自動起動：「1.立替金申請」画面]

予定請求書登録で毎月のキャッシュアウトを予測

『お金の流れを社内に可視化する勇気を持とう』では請求書管理について言及しなかった。

本当は、最初のタスク『1b.支払予定入力』を実施する前に、社外からの請求書のチェックフローと言う「上流工程」があるはずだ。
メッセージ開始イベントを追加し、その上流工程のデータを自動的に引き継げる仕組みにしたい。


＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認

[立替経費申請-支出確認-データ連携：「5.振込実行」画面]

「会議の可視化」が「社内の可視化」を加速させる

どうも社内会議の効率が悪い。色々と考えるに「事前準備」がイイ加減すぎる。端的に言えば、事前準備タスクの締切が守られていない・・・。早速『社内会議を効率良く運営する方法』を拡張したい。（多くの場合は、『事務局担当者のカリスマ度』の問題なのかも知れないが）

以下のワークフロー定義では、『2.議題候補』の記入をいつまでに行えば良いのか、を全参加者に認知させるべく議題候補を列挙するタスクに締切日を設定している。（ダイアグラムの見た目だけでは違いが分からない＝プロセスデータ項目に追加がある）

ちなみに、クラウド型ワークフロー製品『Questetra BPM Suite SaaS Edition』では、プロセスデータ型「掲示板」の上で、複数人がリアルタイムチャットする事もできる！（スゴイ）

＜各タスク名＞
1.開催日通知、2.議題候補、3.議題リスト作成／通知、4.事前所見表明／当日議事、5.議事録作成

[会議運営-議題候補締切: 「3.議題リスト作成／通知」画面]

社内会議を効率良く運営する方法

重要な会議ほど参加者の時給が高い。つまり重要な会議ほど効率よく行う必要がある。
正直な話、会議体の運営はメンドウなのだが、その準備や事務作業を効率化＆定型化させる意義は極めて大きい。。

以下のワークフロー定義では、タスク『5.議事録作成』後に、次の会議の『1.開催日通知』に必要データを連携させておくこともできる。審議継続事項などの再入力手間が省ける。

（ちなみに、社内の会議をワークフローに乗せると、「社内の可視化」が劇的に進む！　注：閲覧権限設定には配慮が必要）


＜各タスク名＞
1.開催日通知、2.議題候補、3.議題リスト作成／通知、4.事前所見表明／当日議事、5.議事録作成

[会議運営：「1.開催日通知」画面]

「子プロセス」を産む業務フロー定義の書き方

「BPMNの書き方」シリーズ第４弾。
ビジネスプロセスマネジメント活動を２～３か月続けていると、どうしても作りたくなる「親プロセス」と「子プロセス」と言う関係。
すなわち、プロセスモデルＡに流れるプロセスa1が…、

• プロセスモデルＢの新規プロセスb1を起動させる　（Ａ:受注プロセス⇒Ｂ:生産プロセス）
• プロセスモデルＢの新規プロセスb1とb2を起動させる　（Ａ:注文処理プロセス⇒Ｂ:配送プロセス）
• プロセスモデルＡの新規プロセスa2を起動させる　（a1:当月請求書⇒a2:翌月請求書）

BPMS製品によって異なるが、ここでは（当然ながら）『Questetra BPM Suite』における「子プロセス」を生成する方法を紹介したい。

なお、これまでの「BPMNの書き方」シリーズを復習したい方は以下。

• 『業務フロー図表記法BPMNの基本は「分岐」だ』
• 『案件によっては同時並行処理が必要になる業務フロー』
• 『業務フロー途中で「定型メール」を自動送信』

＜各タスク名＞
1.子供の名前を付ける

[BPMNサンプル-プロセス増殖：メッセージ送信中間イベント(HTTP)の設定画面]

 <各プロセスデータ>

• 文字型: 件名＜自分の名前＞
• 日付型: 自分の生年月日
• 文字型: 親の名前
• 日付型: 親の生年月日
• 文字型: 新たに産む子供の名前
• 日付型: 新たに産む子供の生年月日
• 選択型: 産む死ぬフラグ (産む/死ぬ)

役員からもセールスからも、請求書発行状況を超可視化

毎月の請求書発行。
抜け漏れなく請求書を発行したい経理チーム…。
そして、請求書の発行状況を確認したいセールスチーム。そう…『可視化』が必要だ。

請求書発行のワークフロー定義は過去にも何度か例示しているが、今回は「一枚の注文書で、請求書が複数回発行されるケース」を想定したい。

＜過去の請求書発行関連サンプル＞

• 請求書発行フローの開始を自動化したワークフロー
• 請求書発行フローは、部署横断に助け合うべきワークフロー

＜各タスク名＞
1.請求データ入力、2.請求データ確認、3-1.当月請求書内容チェック、4-1.請求書発送、5-1.入金確認

[請求書発行-注文書毎発行：「3-1.当月請求書内容チェック」画面]

他システムのデータ閲覧権限を制御する

『クラウド時代のデータ持ち出し管理フロー』で紹介した「アクセス権限の一時付与」と「付与したアクセス権限の解除」は、手動で行いたくない。
言うまでもなくデータファイルのアクセス権限設定変更は、データファイルが管理されているシステムに依存する。たとえば Google Apps を社内プラットフォームにしている場合、「Google Documents」側のAPIを活用する必要がある。（現状ではSEの力を借りざるを得ない）

* Google Documents List Data API v3.0 (Labs) - Modifying Document and Folder Sharing Permissions
* Google Documents List Data API v2.0 - Modifying Document Sharing Permissions


＜各タスク名＞
1.アクセス申請、2.一時的権限付与、3.不承認対応、4.活用報告、5.アクセス権限解除、6.アクセス権限解除確認

[データアクセス申請-外部システム権限変更：「4.活用報告」画面]

社員の日次報告データを基幹システムに自動連携

『原価計算のため「作業時間」を日次報告するフロー』
『原価計算のためだけの日次報告フローはつまらない』
『どうせ日次報告するなら「報告すべき情報」を全て流そう！』

ワークフローで承認されたデータは、給与計算や原価計算などに利用される。「会計ソフト」なのか「基幹システム」なのか、会社によって様々。ただ、いずれにしても「手入力での転記」は避けたい。BPMNの表記法では、データ(プロセスデータ)の外部送信を『メッセージ送信中間イベント』で想定している。

受注プロセスは「最上流タスク」次第で大きく変わる

会社全体を「一本の木」に喩えよう。
貴方は、「葉」だろうか、「枝」だろうか、「幹」だろうか？
あるいは「外敵からみんなを守る樹皮」かも知れない、あるいは「みんなに色々なモノを届ける管」かも知れない。いずれにせよそれぞれミンナ、役割がある。業務プロセス管理（BPM）の第一目的は「効率良くタスクをやり取りする事」だ。そこに停滞は無いか？、そこに過負荷は無いか？、誰の成果が多いのか？　可視化なくして改善なし！　（イカン、前ふりが長すぎる）

営利組織として一番大事なのはやはり『売上』だ。どの会社でも「注文が入ってからの業務フロー」だけは改善し続けなければならない。そして業務フロー自体を「競争力の源泉」にしたい。