以下のワークフロー定義では、BPM側から情報を受信し、『体験版アカウント』を無人で発行させる。エラー発生時にのみ、人間タスクが発生する仕組みだ。（コンピュータと人間の協調作業はBPMSの醍醐味でもある）
- 類似：『体験版の受付から発行までを自動化したい』
＜各タスク名＞
1.申込情報入力、2.手動アカウント発行
[体験版アカウント発行-自動発行: 「2.手動アカウント発行」画面]
業務フロー図が、日常業務を変える！
ダウンロード可能な「業務テンプレート」を毎週公開するブログ
実際に『体験版アカウント』を発行する際、どうしても人手が必要な場合もある。しかし人間作業と言っても所詮は決まりきったコマンドをコンピュータに入力しているだけ。発行者情報を受信できれば、無人かつ自動的に『体験版アカウント』を作成する事だって出来るハズだ。
以下のワークフロー定義では、BPM側から情報を受信し、『体験版アカウント』を無人で発行させる。エラー発生時にのみ、人間タスクが発生する仕組みだ。（コンピュータと人間の協調作業はBPMSの醍醐味でもある）
＜各タスク名＞
1.申込情報入力、2.手動アカウント発行
以下のワークフロー定義では、BPM側から情報を受信し、『体験版アカウント』を無人で発行させる。エラー発生時にのみ、人間タスクが発生する仕組みだ。（コンピュータと人間の協調作業はBPMSの醍醐味でもある）
＜各タスク名＞
1.申込情報入力、2.手動アカウント発行
「無料お試し」って、どんなビジネスでも王道だ。試供品を郵送したり、体験版アカウントを発行したり…。ただ受付対応にコストをかけていられない。「無料サンプル受付対応フロー」は極力自動化したい所だ。
以下は体験版アカウントの発行プロセスの例だ。
＜各タスク名＞
1.申込情報入力、2.アカウント発行
以下は体験版アカウントの発行プロセスの例だ。
＜各タスク名＞
1.申込情報入力、2.アカウント発行
[体験版アカウント発行: 「2.アカウント発行」画面]
「アドホック」はラテン語だ。日本でも適当な訳語が見当たらず、そのまま「アドホック」と言う。ラテン語が世界中で使われると言うのは珍しい。（アドリブ、エトセトラ、くらい？）
では「アドホック」とは何か？ たぶん上手く説明できないが、「アドホックなネットワーク」や「アドホックな作業場所」などの用例で使われ、「恒久的でない」とか「その場しのぎ」と理解するのが良いだろう。
ワークフロー（業務プロセス）の世界でも、「アドホックなタスク」や「アドホックなワークフロー」と言う表現がある。平たく言えば担当者や作業順番が決まってない一連の作業だ。例えば、書類の回覧、複数人の承認などが例示されることが多く、「ワークフローシステム」で対応すべきか、「グループウェア」で対応すべきか、議論が分かれる。
第８回目となる「BPMNの書き方」のテーマは「アドホック（ad hoc）なタスクの定義方法」。
＝過去の「BPMNの書き方」＝
＜各タスク名＞
1.タスク、2.タスク
では「アドホック」とは何か？ たぶん上手く説明できないが、「アドホックなネットワーク」や「アドホックな作業場所」などの用例で使われ、「恒久的でない」とか「その場しのぎ」と理解するのが良いだろう。
ワークフロー（業務プロセス）の世界でも、「アドホックなタスク」や「アドホックなワークフロー」と言う表現がある。平たく言えば担当者や作業順番が決まってない一連の作業だ。例えば、書類の回覧、複数人の承認などが例示されることが多く、「ワークフローシステム」で対応すべきか、「グループウェア」で対応すべきか、議論が分かれる。
第８回目となる「BPMNの書き方」のテーマは「アドホック（ad hoc）なタスクの定義方法」。
＝過去の「BPMNの書き方」＝
- 『業務フロー図表記法BPMNの基本は「分岐」だ』
- 『案件によっては同時並行処理が必要になる業務フロー』
- 『業務フロー途中で「定型メール」を自動送信』
- 『「子プロセス」を産む業務フロー定義の書き方』
- 『トークンが無限増殖するループ構造』
- 『業務フロー図を我流で書くなんて、ダメダメ』（同時並行処理がある場合の中断）
- 『成果物は同じでも、プロセス開始のキッカケは様々』（複数トリガーの想定）
＜各タスク名＞
1.タスク、2.タスク
[点検業務-点検データ受信：「2.タスク」画面]
クレーム対応フローを効率良く回すカギは、ノウハウの共有だ。違う言い方をすれば『ベストプラクティス』をどの様に管理すべきか、と言う話になる。
確かに月次や週次に『全体の中でのベストプラクティス』を抽出するのも良い。しかし得てして眼前の業務によって後回しになり、ナカナカ実行できない。クレーム対応の一連業務の中で、逐次『ベストプラクティス度』を入力しておくのが良いだろう。
類似：
＜各タスク名＞
1.クレーム内容登録、2.一次対応、3.その後の対応、4.レポート、5.ベストプラクティス度
2b.【急】一次対応、3b.【急】その後の対応
確かに月次や週次に『全体の中でのベストプラクティス』を抽出するのも良い。しかし得てして眼前の業務によって後回しになり、ナカナカ実行できない。クレーム対応の一連業務の中で、逐次『ベストプラクティス度』を入力しておくのが良いだろう。
類似：
＜各タスク名＞
1.クレーム内容登録、2.一次対応、3.その後の対応、4.レポート、5.ベストプラクティス度
2b.【急】一次対応、3b.【急】その後の対応
[クレーム対応-ベストプラクティス：「5.ベストプラクティス度」画面]
クレームに対する取り組みは、「会社の規模」や「取り扱う商品サービス」によって大きく異なる。
すなわち「100円の文房具」であっても「上場企業」であればキッチリとした対応が必要かも知れない。他方、世界中に「フリーソフト」を配布している会社なら、ある程度のクレームは放置せざるを得ないかも知れない。ただ、いずれの場合であっても、クレームの収集や分析は、企業の競争力を維持する上で非常に大切な活動だと言える。
以下のワークフロー定義では、各クレームが自動的にフィルタされ、「対応優先順位」の高いモノを視覚的に認知しやすくなる。
類似：『「クレーム種」によって流れ作業の緊張感を変える』
＜各タスク名＞
1.クレーム内容登録、2.一次対応、3.その後の対応、4.レポート
2b.【急】一次対応、3b.【急】その後の対応
すなわち「100円の文房具」であっても「上場企業」であればキッチリとした対応が必要かも知れない。他方、世界中に「フリーソフト」を配布している会社なら、ある程度のクレームは放置せざるを得ないかも知れない。ただ、いずれの場合であっても、クレームの収集や分析は、企業の競争力を維持する上で非常に大切な活動だと言える。
以下のワークフロー定義では、各クレームが自動的にフィルタされ、「対応優先順位」の高いモノを視覚的に認知しやすくなる。
類似：『「クレーム種」によって流れ作業の緊張感を変える』
＜各タスク名＞
1.クレーム内容登録、2.一次対応、3.その後の対応、4.レポート
2b.【急】一次対応、3b.【急】その後の対応
[クレーム対応-優先度別：「2.一次対応」画面]
『クレーム』と一言で言っても、例えば提供商品が不十分だったケースなのか、提供商品は十分だったが顧客にとっては不満だったケースなのか、によって対応方針が大きく異なる。
また『クレームの発信者』についても、例えば以下の分類を想定する事ができる。
さて・・・、急いで対応すべきは『クレーム』は、A1だろうか、B3だろうか、C2だろうか？？？
＜各タスク名＞
1.クレーム内容登録、2.一次対応内容、3.その後の対応、4.レポート
- A. 不足（商品サービスが想定品質に達していないケース）
- B. 期待（会社想定品質に達してはいるが顧客にとっては物足りないケース）
- C. その他（商品サービス以外に関するクレーム）
- D. 言いがかり嫌がらせ等
また『クレームの発信者』についても、例えば以下の分類を想定する事ができる。
- 1. 既存顧客から離反する可能性は低い
- 2. 既存顧客から離反する可能性が高い
- 3. 新規顧客になりえる
- 4. 新規顧客になりえない
さて・・・、急いで対応すべきは『クレーム』は、A1だろうか、B3だろうか、C2だろうか？？？
＜各タスク名＞
1.クレーム内容登録、2.一次対応内容、3.その後の対応、4.レポート
[クレーム対応-個人担当：「2.一次対応内容」画面]
「自動検知が来た！」 すぐさま点検作業に着手すべきか？ （サーバ保守、自動販売機保守、社内コンピュータの保守・・・）
単純な話ではない。全ての検知に対して「無条件」に即時点検を行っていたのでは点検コストがかさむ。延いては企業のコスト構造にも関わる可能性がある。かと言って即時点検しないと言う判断は出来ない。
結論として「条件」によって即時対応するのだ。この手のワークフローでは、その条件設定のブラッシュアップこそが業務フローの最大の改善ポイントかも知れない。
類似）
＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認
単純な話ではない。全ての検知に対して「無条件」に即時点検を行っていたのでは点検コストがかさむ。延いては企業のコスト構造にも関わる可能性がある。かと言って即時点検しないと言う判断は出来ない。
結論として「条件」によって即時対応するのだ。この手のワークフローでは、その条件設定のブラッシュアップこそが業務フローの最大の改善ポイントかも知れない。
類似）
＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認
[点検業務-点検データ受信：「2.点検予定日入力」画面]
『点検そして修繕、それは流れ作業だ』の記事では、シンプルな点検作業ワークフローを示した。
しかし、そもそも点検作業を行うキッカケは何だろう？ 確かに定期点検もあるが、クレームや通報と言った何らかの外部通知によって行われるケースも少なくない。「点検データ受信」によって点検フローが自動的に開始されるように定義しておくと便利だ。
＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認
しかし、そもそも点検作業を行うキッカケは何だろう？ 確かに定期点検もあるが、クレームや通報と言った何らかの外部通知によって行われるケースも少なくない。「点検データ受信」によって点検フローが自動的に開始されるように定義しておくと便利だ。
＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認
[点検業務-点検データ受信：「2.点検予定日入力」画面]
「点検業務」って、実は典型的な「流れ作業」（ワークフロー）だ。すなわち点検だけでは終わらない。問題があれば修理し、修理された事をまた確認する。
＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認
[点検業務-再点検なし：「2.点検予定日入力」画面]
＜各タスク名＞
1.点検ポイント入力、2.点検予定日入力、3.点検実施報告、4.修繕予定日入力、5.修繕実施報告、6.確認
[点検業務-再点検なし：「2.点検予定日入力」画面]
「社員から申請されるケースもあれば、経理から確認するケースもある」
そう。世の中の業務プロセスは、毎度同じキッカケで開始されるわけではない。むしろ多くの業務プロセスで、複数のキッカケ（トリガーと言う）が想定されるべきだ。
第7回目となる「BPMNの書き方」のテーマは「複数トリガーの想定」。
＝過去の「BPMNの書き方」＝
＜各タスク名＞
1abc.タスク、2.タスク
そう。世の中の業務プロセスは、毎度同じキッカケで開始されるわけではない。むしろ多くの業務プロセスで、複数のキッカケ（トリガーと言う）が想定されるべきだ。
第7回目となる「BPMNの書き方」のテーマは「複数トリガーの想定」。
＝過去の「BPMNの書き方」＝
- 『業務フロー図表記法BPMNの基本は「分岐」だ』
- 『案件によっては同時並行処理が必要になる業務フロー』
- 『業務フロー途中で「定型メール」を自動送信』
- 『「子プロセス」を産む業務フロー定義の書き方』
- 『トークンが無限増殖するループ構造』
- 『業務フロー図を我流で書くなんて、ダメダメ』（同時並行処理がある場合の中断）
＜各タスク名＞
1abc.タスク、2.タスク
[BPMNサンプル-複数開始イベント：「1a.タスク」画面]
立替金申請を紙で回していると、他人の立替金の内容を覗き見る機会は無い。しかし、立替金申請がオンラインで全社可視化されると意外にも他人の立替金内容を見る事が多い。
そして、徐々に社内に「モラル」が生まれ、また「常識の範囲」が醸成される様になる。
立替金の申請を（極力）月に一人一枚にまとめてもらうべく、件名が「佐藤 3月分」と初期値設定された『1.立替金申請』タスクを月初にタイマー起動する。すなわち一か月間近く『1.立替金申請』で滞留させ、何度も上書き保存する習慣を付けてもらう仕掛けだ。
を拡張する。
＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認
そして、徐々に社内に「モラル」が生まれ、また「常識の範囲」が醸成される様になる。
立替金の申請を（極力）月に一人一枚にまとめてもらうべく、件名が「佐藤 3月分」と初期値設定された『1.立替金申請』タスクを月初にタイマー起動する。すなわち一か月間近く『1.立替金申請』で滞留させ、何度も上書き保存する習慣を付けてもらう仕掛けだ。
を拡張する。
＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認
[立替経費申請-支出確認-月初自動起動：「1.立替金申請」画面]
『お金の流れを社内に可視化する勇気を持とう』では請求書管理について言及しなかった。
本当は、最初のタスク『1b.支払予定入力』を実施する前に、社外からの請求書のチェックフローと言う「上流工程」があるはずだ。
メッセージ開始イベントを追加し、その上流工程のデータを自動的に引き継げる仕組みにしたい。
＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認
本当は、最初のタスク『1b.支払予定入力』を実施する前に、社外からの請求書のチェックフローと言う「上流工程」があるはずだ。
メッセージ開始イベントを追加し、その上流工程のデータを自動的に引き継げる仕組みにしたい。
＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認
[立替経費申請-支出確認-データ連携：「5.振込実行」画面]
旅費精算も、外部委託も、人件費も、ぜんぶ「支出」だ。100人以下の会社なら『会社の支出』を全て可視化してしまうのもアリだ。そうする事で、会社全体を考えた意見が発信される様になる！（かも知れない）（流石に人件費は総額表示で！）
以下のワークフロー定義は、社内で発生する支出を全て捕捉する。
＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認
以下のワークフロー定義は、社内で発生する支出を全て捕捉する。
＜各タスク名＞
1.立替金申請、2.立替金承認、3.指摘対応、4.立替金経理承認、5.振込実行
1b.支払予定入力、2b.部長承認
[立替経費申請-支出確認：「5.振込実行」画面]
押印申請フローを全ての押印に適用すると体験できるが、実は法務チェックが必要な「サインや押印」はごく一部だ。例えば、取引額だけが焦点の契約書、役所に提出する書類などは『法務タスク』を飛ばして決裁スピードを早めたい。
を拡張し、法務チェックが不要なフローを追加した。
＜各タスク名＞
1.合意文書草案、2.草案チェック、3.指摘対応、4.法務チェック、5.印刷＆サイン取得、5b.社長承認、6.提出記録
を拡張し、法務チェックが不要なフローを追加した。
＜各タスク名＞
1.合意文書草案、2.草案チェック、3.指摘対応、4.法務チェック、5.印刷＆サイン取得、5b.社長承認、6.提出記録
[押印申請-法務チェック省略：「5b.社長承認」画面]
社長にだって意思がある！(?)
『合意文書の作成過程くらいオンライン化しよう』では、社長が登場しない。やはり重要文書の合意には社長の決裁が必要だ。「業務プロセスの可視化」を推進するなら、社長自身もワークフローに参加しなければならない。
＜各タスク名＞
1.合意文書草案、2.草案チェック、3.指摘対応、4.法務チェック、5.印刷＆サイン取得、5b.社長承認、6.提出記録
『合意文書の作成過程くらいオンライン化しよう』では、社長が登場しない。やはり重要文書の合意には社長の決裁が必要だ。「業務プロセスの可視化」を推進するなら、社長自身もワークフローに参加しなければならない。
- 誰が「重要文書」と認定するか？（大きい問題）
- 社長が決裁しやすい様に、文書を社長用に印刷しておく？（小さい問題）
＜各タスク名＞
1.合意文書草案、2.草案チェック、3.指摘対応、4.法務チェック、5.印刷＆サイン取得、5b.社長承認、6.提出記録
[署名捺印申請-社長承認：「5b.社長承認」画面 ]
合意した内容は、個人間でも、会社間でも、そして国家間でも、≪紙≫にまとめられる。紙の発明ってホント凄い…（2000年前＠中国） そして21世紀の今日。「ペーパレス」などと言う言葉もあるが、合意事項は≪紙≫でまとめられている…。
もっとも、合意文書はパソコン等で作成され、末尾の署名欄だけ直筆サインを書く。契約行為を行う社長達は、（その中身をあまり見ずに）、一日に何枚もサインする仕組みだ。（ハンコで認証する日本や韓国等では、代理の人がペタペタ押す）
前半の「合意文書がパソコン等で作成される過程」をワークフローを使って可視化しよう。
＜各タスク名＞
1.合意文書草案、2.草案チェック、3.指摘対応、4.法務チェック、5.印刷＆サイン取得
もっとも、合意文書はパソコン等で作成され、末尾の署名欄だけ直筆サインを書く。契約行為を行う社長達は、（その中身をあまり見ずに）、一日に何枚もサインする仕組みだ。（ハンコで認証する日本や韓国等では、代理の人がペタペタ押す）
前半の「合意文書がパソコン等で作成される過程」をワークフローを使って可視化しよう。
＜各タスク名＞
1.合意文書草案、2.草案チェック、3.指摘対応、4.法務チェック、5.印刷＆サイン取得
[署名捺印申請：「4.法務チェック」画面 ]
 |
「BPMNでワークフロー定義」の第６弾。今日は「中断」に関する書き方。（他の分担作業を停止させる業務フロー表記法）
単に「中断」と言っても色々ある。今回取り扱う「中断」は「同時並行処理がある場合の中断」だ。すなわち、複数人が同時に作業している時に、他人の作業をストップさせるケースを考える。
以下のワークフロー定義では、ＡさんとＢさんとＣさんが、一つの仕事に対して複数作業に分かれて同時に処理している折に、Ａさんの判断で全作業をストップさせる事ができる。すなわちＡさんが『2a.タスク』を完了させれば、『2b.タスク』や『2c.タスク』が消滅する。（『2b.タスク』や『2c.タスク』が既に終了している場合は変化がない）
＜各タスク名＞
1.タスク、2a.タスク、2b.タスク、2c.タスク
単に「中断」と言っても色々ある。今回取り扱う「中断」は「同時並行処理がある場合の中断」だ。すなわち、複数人が同時に作業している時に、他人の作業をストップさせるケースを考える。
以下のワークフロー定義では、ＡさんとＢさんとＣさんが、一つの仕事に対して複数作業に分かれて同時に処理している折に、Ａさんの判断で全作業をストップさせる事ができる。すなわちＡさんが『2a.タスク』を完了させれば、『2b.タスク』や『2c.タスク』が消滅する。（『2b.タスク』や『2c.タスク』が既に終了している場合は変化がない）
＜各タスク名＞
1.タスク、2a.タスク、2b.タスク、2c.タスク
[BPMNサンプル-一箇所全終了：「2a.タスク」画面]
売掛金ほどではないにせよ、「買掛金の管理」も複雑な要望が多い。
と言った要望が経理側から挙がってくるのは時間の問題だ。
早速、『買掛金プロセスを少しずつ構築する』を拡張したい。
＜各タスク名＞
0.支払見込報告、1.請求書受領、2.支払承認、3.不明点対応、4.支払
- 請求書が来るより前に支払い情報を捕捉したい
- 原材料の購入(製造原価)と一般管理上の購入(一般管理費)を分けたい
と言った要望が経理側から挙がってくるのは時間の問題だ。
早速、『買掛金プロセスを少しずつ構築する』を拡張したい。
＜各タスク名＞
0.支払見込報告、1.請求書受領、2.支払承認、3.不明点対応、4.支払
[買掛金管理-支出見込管理：「2.支払承認」画面]
業務フローを改善し続ける事は、≪企業の競争力≫を磨き続ける事に等しい。特に、金融業界、情報通信業界、物流業界などでは既に、BPMのコンセプトが定着しつつある。BPMシステム側もベンダー各社それぞれに、テンプレートの種類と量を揃えてきた。
BPM の主たる適用領域としては、マーケティングおよび販売活動における「クレーム処理」や「ローン承認」、資源管理および調達購買における「買掛金管理」や「立替金精算」や「資産管理」などが挙げられる。BPM歴の長い企業では「売掛金の管理」や「予算編成」などの難易度が高い業務プロセスにもBPMを適用する傾向にある。
以下は「買掛金」を管理する仕組みの中でも、最もシンプルなものだ。スイムレーンに「経理」が登場しないが、上司承認された請求書を一覧すれば、月末に一括して振込処理を行える。
＜各タスク名＞
1.請求書受領、2.支払承認、3.不明点対応
BPM の主たる適用領域としては、マーケティングおよび販売活動における「クレーム処理」や「ローン承認」、資源管理および調達購買における「買掛金管理」や「立替金精算」や「資産管理」などが挙げられる。BPM歴の長い企業では「売掛金の管理」や「予算編成」などの難易度が高い業務プロセスにもBPMを適用する傾向にある。
以下は「買掛金」を管理する仕組みの中でも、最もシンプルなものだ。スイムレーンに「経理」が登場しないが、上司承認された請求書を一覧すれば、月末に一括して振込処理を行える。
＜各タスク名＞
1.請求書受領、2.支払承認、3.不明点対応
[買掛金管理-上司承認：「2.支払承認」画面]
日本では今、深刻な電力不足問題を抱えている。この夏の東京地域では、ピーク時の需要に対し８割程度の電力供給しか実現できそうにない。蓄電装置の活用や空調機の停止だけでなく、「人間の移動を減らす」、「工場運転を止める」と言った大がかりな措置が必要になる可能性がある。この１か月(2011年5月)は、7月以降の在宅勤務制度導入が積極的に検討されるだろう。
なお、在宅勤務制度の制度設計を完璧に行うことは不可能に近い。申請フローや報告フローには、ＢＰＭサイクルの考えを適用し「あるべき業務フローに少しずつ近づける」と言うスタンスで臨みたい。大切なことは、在宅勤務実態はリアルタイムに可視化し、把握する事だ。（Business Process Management: 業務プロセス管理）
以下のワークフロー定義では、『在宅勤務の業務報告は円滑に！』の報告フローにおいて、「在宅キャンセル」の判断を行った事を簡単に記録できる。すなわち、在宅勤務の予定を変更した場合も正確に捕捉できる。
参考：
＜各タスク名＞
1.業務報告、1b.業務報告、2.確認、3.不明点対応
なお、在宅勤務制度の制度設計を完璧に行うことは不可能に近い。申請フローや報告フローには、ＢＰＭサイクルの考えを適用し「あるべき業務フローに少しずつ近づける」と言うスタンスで臨みたい。大切なことは、在宅勤務実態はリアルタイムに可視化し、把握する事だ。（Business Process Management: 業務プロセス管理）
以下のワークフロー定義では、『在宅勤務の業務報告は円滑に！』の報告フローにおいて、「在宅キャンセル」の判断を行った事を簡単に記録できる。すなわち、在宅勤務の予定を変更した場合も正確に捕捉できる。
参考：
＜各タスク名＞
1.業務報告、1b.業務報告、2.確認、3.不明点対応
[在宅勤務-業務報告-キャンセル：「2.確認」画面]
在宅勤務のためにファイアーウォールに「穴」を開けて社内サーバにアクセスさせるより、ある程度の業務情報を「クラウド」において社内サーバアクセスを減らすことを考えたい。ナンでもカンでも重要情報と認定してしまうと、本当に大切なものが守れなくなる。
日本の戦国時代のお城には内堀と外堀があるが、「内堀が広大な城」は侵入を防ぐコストがかかりすぎる。
以下のワークフロー定義は、『在宅勤務日の申請承認はクラウドでしょ！』を拡張し、在宅勤務日の予定を一括して申請するフローだ。在宅勤務日なんて外堀で守っておけば良い程度の情報だ。
ちなみに、一括して申請できるのは便利ながら、逐次で申請するワークフロー定義と異なり、一連の流れに乗った業務報告が出来なくなる（様な気がする）。そんな場合は、１対ｎの関係にある「申請承認フロー」と「業務報告フロー」を分離すれば良い。
＜各タスク名＞
1.事前申請、2.承認、3.非承認対応
日本の戦国時代のお城には内堀と外堀があるが、「内堀が広大な城」は侵入を防ぐコストがかかりすぎる。
以下のワークフロー定義は、『在宅勤務日の申請承認はクラウドでしょ！』を拡張し、在宅勤務日の予定を一括して申請するフローだ。在宅勤務日なんて外堀で守っておけば良い程度の情報だ。
ちなみに、一括して申請できるのは便利ながら、逐次で申請するワークフロー定義と異なり、一連の流れに乗った業務報告が出来なくなる（様な気がする）。そんな場合は、１対ｎの関係にある「申請承認フロー」と「業務報告フロー」を分離すれば良い。
＜各タスク名＞
1.事前申請、2.承認、3.非承認対応
[在宅勤務-一括申請：メッセージ送信中間イベント設定画面]
確かに「大事な業務データは、社内サーバに！」と言うセリフは正しい。
他方、「大事な業務データは、クラウド環境に！」と言うセリフも正しい。
一流のハッカーが社内に在籍しているなら、社内サーバだけを信頼する道があるかもしれない。しかしそれでも、「全ての業務で社内サーバしか使わない」と言う発想は、ほぼすべての企業において「ナンセンス」だと思う。
では、どの様な業務システムからクラウド化させるべきなのだろうか？ 以下は、「在宅勤務申請の承認フロー」をクラウドで処理する例だ。（明日以降、この基本形を拡充させていこうと思う）
類似：『在宅勤務制度を規定するワークフロー』（2011年3月23日投稿）
＜各タスク名＞
1.事前申請、2.承認、3.報告
他方、「大事な業務データは、クラウド環境に！」と言うセリフも正しい。
一流のハッカーが社内に在籍しているなら、社内サーバだけを信頼する道があるかもしれない。しかしそれでも、「全ての業務で社内サーバしか使わない」と言う発想は、ほぼすべての企業において「ナンセンス」だと思う。
- 電力供給を自前にこだわる（コンセントを使わない）
- 現金管理を自前だけでこなす（銀行に預けない）
では、どの様な業務システムからクラウド化させるべきなのだろうか？ 以下は、「在宅勤務申請の承認フロー」をクラウドで処理する例だ。（明日以降、この基本形を拡充させていこうと思う）
類似：『在宅勤務制度を規定するワークフロー』（2011年3月23日投稿）
＜各タスク名＞
1.事前申請、2.承認、3.報告
[在宅勤務-申請承認：「2.承認」画面]
単純作業であっても「ベストプラクティスの編集」は、業務品質の向上に欠かせない。検収担当者がその主観で「秀逸だ」と感じた電子化作業を、社内ポータルで表彰しよう。
以下のワークフロー定義では、検収担当者の「秀逸」判定後、リーダが「ベストプラクティス」に掲載するかどうかを決める。
＜各タスク名＞
1.画像データ入力、2.引受＆納期回答、3.文字データ、4.検収、4b.ベストプラクティス編集、5.作業台帳記録、6.経理質問対応
以下のワークフロー定義では、検収担当者の「秀逸」判定後、リーダが「ベストプラクティス」に掲載するかどうかを決める。
＜各タスク名＞
1.画像データ入力、2.引受＆納期回答、3.文字データ、4.検収、4b.ベストプラクティス編集、5.作業台帳記録、6.経理質問対応
[電子化作業-ベストプラクティス編集：「4b.ベストプラクティス編集」画面]
電子化作業の業務フローは、委託側が画像データを準備し、受託側がテキスト情報を返す形になる。
このデータエントリ作業を、請負型の在宅ワークとして展開していると、作業成果に対する賃金支払いフローも定義したくなる。
以下のワークフロー定義では、経理部門の精算支払いについても定義している。
＜各タスク名＞
1.画像データ入力、2.引受＆納期回答、3.文字データ、4.検収、5.作業台帳記録
このデータエントリ作業を、請負型の在宅ワークとして展開していると、作業成果に対する賃金支払いフローも定義したくなる。
以下のワークフロー定義では、経理部門の精算支払いについても定義している。
＜各タスク名＞
1.画像データ入力、2.引受＆納期回答、3.文字データ、4.検収、5.作業台帳記録
[電子化作業-経理精算：「5.作業台帳記録」画面]
電子化作業が大規模化してくると、『画像データを効率良くテキスト化する』で定義された「事務局」のタスクが混乱してくる。すなわち、タスク『1.画像データ入力』を行った人間が、タスク『4.検収』を実施しなければならないが、そこは分業が必要になるだろう。
以下のワークフロー定義では、あわせて画像データの作成（スキャン）を自動化する業務フローも想定している。
＜各タスク名＞
1.画像データ入力、2.引受＆納期回答、3.文字データ、4.検収
以下のワークフロー定義では、あわせて画像データの作成（スキャン）を自動化する業務フローも想定している。
＜各タスク名＞
1.画像データ入力、2.引受＆納期回答、3.文字データ、4.検収
[電子化作業-分業：「3.文字データ」画面]
登録:
投稿
(
Atom
)