そんなの分かりきっているんだから、「初期値として入力されている状態」にしておいてくれ!!
以下のワークフロー定義は月報を報告する業務フローだ。毎月５日までに前月活動のダイジェストを上司に報告する。毎月１日の朝に『1.月報を書く』と言う仕事が自動的に全員に割り当てられる仕組みだ。
申請時には、多くのフォームに「初期値」やら「雛形」やらが入力されている。
[月報フロー-初期値]
業務フロー図が、日常業務を変える！
ダウンロード可能な「業務テンプレート」を毎週公開するブログ
そんなの分かりきっているんだから、「初期値として入力されている状態」にしておいてくれ!!
以下のワークフロー定義は月報を報告する業務フローだ。毎月５日までに前月活動のダイジェストを上司に報告する。毎月１日の朝に『1.月報を書く』と言う仕事が自動的に全員に割り当てられる仕組みだ。
申請時には、多くのフォームに「初期値」やら「雛形」やらが入力されている。
この『慶事』にともなう面倒で不安な手続きは、会社としてバックアップしたいものだ。日本の場合、社会保険関連の手続は会社を通じて行う仕組み上、社員からの「出産連絡」が必ず入る。それをトリガーに、会社として「役所手続を含めたトータルな手続き支援」を開始するのはどうか？
[出産手続フロー]
（BPMN：Business Process Model and Notation）
確かに難しい。しかし一方で『業務フローのあるべき姿』を考えられる立場にいなければ永遠に書けない。
- 日常業務で何件発生するのか、決算期には何件くらい増えるのか？
- 誰が処理すべきか、何人で処理すべきか。。。
では、どうすれば社内に BPMN を浸透させることができる？ それは、日常の単純な業務を BPMN で書く事から始めてもらうしかない。もしあなたが毎日日報を書いている／書かせているなら、日報フローがオススメだ。
[日報フロー]
日本では台風シーズン到来だ。そして気象警報が発令されると「電話連絡網」が回ってくる。（休校を知らせるための電話伝言ゲーム）
ただ最近では、「メールの普及」「個人情報への配慮」「リアルタイム性の担保」等の理由から、電話連絡網（緊急連絡網）を廃止して、メーリングリストでの情報配信に切り替える学校も多い。
『緊急メール』の配信で注意したいのは「誤解の無い文章の作成」だ。メールでの情報配信は便利なのだが、要らぬ誤解は混乱を助長する。「情報が正確に伝わっているか？」、かならず起案者以外の職員にレビューしてもらってから送信するルールにしたい。
以下のワークフローでは、(1)配信文章の起案、(2)素早いレビュー校正、(3)素早い承認、を考える。（レビューや承認は、スマートフォンが吉！）
＜各タスク名＞
1.配信文起案、2.配信文校正、3.承認、3b.事後承認
ただ最近では、「メールの普及」「個人情報への配慮」「リアルタイム性の担保」等の理由から、電話連絡網（緊急連絡網）を廃止して、メーリングリストでの情報配信に切り替える学校も多い。
『緊急メール』の配信で注意したいのは「誤解の無い文章の作成」だ。メールでの情報配信は便利なのだが、要らぬ誤解は混乱を助長する。「情報が正確に伝わっているか？」、かならず起案者以外の職員にレビューしてもらってから送信するルールにしたい。
以下のワークフローでは、(1)配信文章の起案、(2)素早いレビュー校正、(3)素早い承認、を考える。（レビューや承認は、スマートフォンが吉！）
＜各タスク名＞
1.配信文起案、2.配信文校正、3.承認、3b.事後承認
日本では今、深刻な電力不足問題を抱えている。この夏の東京地域では、ピーク時の需要に対し８割程度の電力供給しか実現できそうにない。蓄電装置の活用や空調機の停止だけでなく、「人間の移動を減らす」、「工場運転を止める」と言った大がかりな措置が必要になる可能性がある。この１か月(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.承認」画面]
毎朝毎晩の「定時タスク」を習慣化すれば、「勤務時刻」の報告だけでなく結構色々な事ができる。ニュースサイトを巡回した感想をメモするもよし、業界最新情報をTwitterでつぶやくもよし…。
毎日出勤しないアルバイトさん達にとっても、この習慣化は大切だ。ワークフロー定義『「勤務時刻をワークフローで記録」は意外とアリ』を拡張して、定時タスクを実行する日（勤務日）を事前に入力しておけるようにしよう。
つまり、シフトが決まった時に今月の出勤日を入力したり、帰り際に次回出勤日を入力したりする。（勤務時刻も予定入力しておける）
＜各タスク名＞
0.勤務予定日入力、1.勤務開始時刻記録、2.勤務開始確認、3.勤務終了時刻記録、4.勤務終了確認
毎日出勤しないアルバイトさん達にとっても、この習慣化は大切だ。ワークフロー定義『「勤務時刻をワークフローで記録」は意外とアリ』を拡張して、定時タスクを実行する日（勤務日）を事前に入力しておけるようにしよう。
つまり、シフトが決まった時に今月の出勤日を入力したり、帰り際に次回出勤日を入力したりする。（勤務時刻も予定入力しておける）
＜各タスク名＞
0.勤務予定日入力、1.勤務開始時刻記録、2.勤務開始確認、3.勤務終了時刻記録、4.勤務終了確認
[勤怠管理-つぶやき自動投稿：「0.勤務予定日入力」画面]
仕事の開始時刻と終了時刻をワークフローシステムで報告する（勤怠管理）のは意外と良い方法だ。例えば、外出時に「今から仕事タイムです」とスマートフォン報告できれば、手っ取り早い。
ちなみに、この手の業務管理データは、数日分をまとめた報告が為されがちだ。そして多くの企業で不正確なデータが蓄積されていく。そうではなく、毎朝毎晩こまめに記録する習慣をつけることが大切なのだ。オフィス出勤時も、直行直帰時も、在宅勤務時も・・・。そういう意味では、毎日ログインするワークフローシステムを活用するという発想は、ルーティンワーク化させる上でアリだ。〔偉い人にはそれが分からんのですよ〕
＜各タスク名＞
1.勤務開始時刻記録、2.オフィス外勤務確認、3.勤務終了時刻記録
ちなみに、この手の業務管理データは、数日分をまとめた報告が為されがちだ。そして多くの企業で不正確なデータが蓄積されていく。そうではなく、毎朝毎晩こまめに記録する習慣をつけることが大切なのだ。オフィス出勤時も、直行直帰時も、在宅勤務時も・・・。そういう意味では、毎日ログインするワークフローシステムを活用するという発想は、ルーティンワーク化させる上でアリだ。〔偉い人にはそれが分からんのですよ〕
＜各タスク名＞
1.勤務開始時刻記録、2.オフィス外勤務確認、3.勤務終了時刻記録
[勤怠管理-直帰対応：「1.勤務開始時刻記録」画面]
昨日の記事『シンプルな「休暇申請ワークフロー」でBPMを体感しよう』は、「Workflowサンプル記事としてシンプルすぎるのではないか？」と言う苦情が来そうだ。早々、拡張しておきたい。
ビジネスプロセス設計時の鉄則(※)だが、「ビジネスプロセスの成果物」について改めて考える。・・・そもそも「休暇申請」は何のためにするのか？
- 1. 上司やチーム内に自身の休暇を知らしめて、必要あれば仕事を代行してもらう
- 2. 出勤日数／有給休暇日数をカウントする…
そうだ！ 目的として「3. ≪有給休暇の残日数を計算≫」を足してみることにしよう！！ 一人一人の従業員にとって、残り有給休暇の残数は気になる。
ちなみに『鉄則』については、本家『ビジネスプロセスモデリングの鉄則』(全4ページ)を参照されたい。
＜各タスク名＞
1.休暇申請、2.休暇申請承認、2a.休暇申請(再入力)、3.有給休暇残数通知、4.確認
ビジネスプロセス設計時の鉄則(※)だが、「ビジネスプロセスの成果物」について改めて考える。・・・そもそも「休暇申請」は何のためにするのか？
- 1. 上司やチーム内に自身の休暇を知らしめて、必要あれば仕事を代行してもらう
- 2. 出勤日数／有給休暇日数をカウントする…
そうだ！ 目的として「3. ≪有給休暇の残日数を計算≫」を足してみることにしよう！！ 一人一人の従業員にとって、残り有給休暇の残数は気になる。
ちなみに『鉄則』については、本家『ビジネスプロセスモデリングの鉄則』(全4ページ)を参照されたい。
＜各タスク名＞
1.休暇申請、2.休暇申請承認、2a.休暇申請(再入力)、3.有給休暇残数通知、4.確認
[休暇申請-残日数メール通知：「1.休暇申請」画面]
休暇申請は『クラウド型』（SaaS型）のワークフローに限る。「風邪や病気で会社に行けない」と言う状況をスマートフォンで申請できれば、手っ取り早い。外出中の上司もスマートフォンで「了解」とクリックできる。そのまま人事部や経理部にもキッチリ伝わる仕組みだ。
「BPMって難しそうなのよね…」とお考えの貴方には、休暇申請の様な簡単なビジネスプロセスで、BPMに挑戦してみて欲しい。（BPM: Business Process Management ＝ 業務プロセス管理）
＜各タスク名＞
1.休暇申請、2.休暇申請承認、3.休暇申請確認
「BPMって難しそうなのよね…」とお考えの貴方には、休暇申請の様な簡単なビジネスプロセスで、BPMに挑戦してみて欲しい。（BPM: Business Process Management ＝ 業務プロセス管理）
＜各タスク名＞
1.休暇申請、2.休暇申請承認、3.休暇申請確認
[休暇申請-再入力：「1.休暇申請」画面]
給与計算は大事な業務。各社員の勤務時間を集計し、残業手当（時間外労働手当）、休日労働手当、深夜労働手当を計算する。
以下のワークフロー定義は、全従業員が自身専用の出勤簿ファイル（Excelファイル）に出勤内容を記入し報告する形態だ。毎月入力になるがExcelファイルは12か月分のシートが用意されているので、同じファイルへの加筆作業となる。基本的な情報（プロセスデータ）は前月データを引き継ぐ。
＜各タスク名＞
1.出勤簿入力依頼、2.出勤簿入力、3.出勤簿上司確認、4.再提出対応、5.出勤簿経理確認
以下のワークフロー定義は、全従業員が自身専用の出勤簿ファイル（Excelファイル）に出勤内容を記入し報告する形態だ。毎月入力になるがExcelファイルは12か月分のシートが用意されているので、同じファイルへの加筆作業となる。基本的な情報（プロセスデータ）は前月データを引き継ぐ。
＜各タスク名＞
1.出勤簿入力依頼、2.出勤簿入力、3.出勤簿上司確認、4.再提出対応、5.出勤簿経理確認
[出勤報告-入力依頼省略：「2.出勤簿入力」画面]
子育、介護、地震、インフルエンザ流行、通勤疲労軽減、CO2削減、フリーデスク、経費削減、地域経済活性化…。
色々な観点から「在宅勤務」は世界中で注目されている。日本でも2003年の「eJAPAN戦略II」以降、徐々にテレワーク(Telework：和製造語)を支援する会社が増え、就労人口の2割程度になりつつある。日本では、事前に仕事内容と就労時刻を決めた上で在宅で就労するパターンが多い。（参照⇒『在宅勤務の働き方を規定するワークフロー』）
今回紹介するワークフロー定義は、汎用的な作業指示フローだ。すなわち具体的な作業指示、スケジュール調整、成果物のチェック作業を可視化する。各従業員への「明確な作業指示（割り当て）」は在宅勤務の推進にも役立つ。
＜各タスク名＞
1.仕事内容の指示、2.スケジュールの回答、3.スケジュール承認、4a.追加指示、4b.成果物登録、5.完了確認
色々な観点から「在宅勤務」は世界中で注目されている。日本でも2003年の「eJAPAN戦略II」以降、徐々にテレワーク(Telework：和製造語)を支援する会社が増え、就労人口の2割程度になりつつある。日本では、事前に仕事内容と就労時刻を決めた上で在宅で就労するパターンが多い。（参照⇒『在宅勤務の働き方を規定するワークフロー』）
今回紹介するワークフロー定義は、汎用的な作業指示フローだ。すなわち具体的な作業指示、スケジュール調整、成果物のチェック作業を可視化する。各従業員への「明確な作業指示（割り当て）」は在宅勤務の推進にも役立つ。
＜各タスク名＞
1.仕事内容の指示、2.スケジュールの回答、3.スケジュール承認、4a.追加指示、4b.成果物登録、5.完了確認
[在宅勤務-部下作業提案：「3.スケジュール承認」画面]
在宅勤務（テレワーク）とクラウドコンピューティングは相性が良い。
特にワークフローシステムを『クラウド』に構築すれば、申請、決裁、報告、レビューなど、いつでも／どこでも仕事ができる。通信の高速化と端末の高性能化は、今後もより一層、自宅利用やモバイル利用を加速させるだろう。
今、日本では東日本地震に伴う電力不足で交通機関が十分に機能していない。以下で紹介するワークフロー定義『在宅勤務申請から業務報告のフロー』では、自宅で行う仕事内容を事前申告する。
＜各タスク名＞
1.仕事内容の事前申告、2.事前申告の承認、3.業務開始報告、4.業務終了報告
特にワークフローシステムを『クラウド』に構築すれば、申請、決裁、報告、レビューなど、いつでも／どこでも仕事ができる。通信の高速化と端末の高性能化は、今後もより一層、自宅利用やモバイル利用を加速させるだろう。
今、日本では東日本地震に伴う電力不足で交通機関が十分に機能していない。以下で紹介するワークフロー定義『在宅勤務申請から業務報告のフロー』では、自宅で行う仕事内容を事前申告する。
＜各タスク名＞
1.仕事内容の事前申告、2.事前申告の承認、3.業務開始報告、4.業務終了報告
[在宅勤務-終了メール：「2.事前申告の承認」画面]
『原価計算のため「作業時間」を日次報告するフロー』
『原価計算のためだけの日次報告フローはつまらない』
『どうせ日次報告するなら「報告すべき情報」を全て流そう！』
ワークフローで承認されたデータは、給与計算や原価計算などに利用される。「会計ソフト」なのか「基幹システム」なのか、会社によって様々。ただ、いずれにしても「手入力での転記」は避けたい。BPMNの表記法では、データ(プロセスデータ)の外部送信を『メッセージ送信中間イベント』で想定している。
『原価計算のためだけの日次報告フローはつまらない』
『どうせ日次報告するなら「報告すべき情報」を全て流そう！』
ワークフローで承認されたデータは、給与計算や原価計算などに利用される。「会計ソフト」なのか「基幹システム」なのか、会社によって様々。ただ、いずれにしても「手入力での転記」は避けたい。BPMNの表記法では、データ(プロセスデータ)の外部送信を『メッセージ送信中間イベント』で想定している。
『原価計算のため「作業時間」を日次報告するフロー』
『原価計算のためだけの日次報告フローはつまらない』
「シリーズ：製造原価計算のための日次報告」と言う感じになってきた。≪製造原価≫のための日次報告をさせるなら、ついでに≪勤怠管理≫のための報告も兼ねたくなる。
上司の現実、月に一度「部下達の出勤簿」を見せられても、そこに書かれた内容が正しいかどうか分からない。すなわち日々の報告に「出勤簿に必要な情報」を追記しておきたい。以下の日次報告ワークフローでは、「出勤欠勤の選択、出勤時刻、退社時刻」の各情報も入力する。（ダイアグラムは同型）
『原価計算のためだけの日次報告フローはつまらない』
「シリーズ：製造原価計算のための日次報告」と言う感じになってきた。≪製造原価≫のための日次報告をさせるなら、ついでに≪勤怠管理≫のための報告も兼ねたくなる。
上司の現実、月に一度「部下達の出勤簿」を見せられても、そこに書かれた内容が正しいかどうか分からない。すなわち日々の報告に「出勤簿に必要な情報」を追記しておきたい。以下の日次報告ワークフローでは、「出勤欠勤の選択、出勤時刻、退社時刻」の各情報も入力する。（ダイアグラムは同型）
『原価計算のため「作業時間」を日次報告するフロー』で≪作業時間≫を毎日報告するなら、ついでに≪作業内容≫も書いて、それぞれのプロマネ達にも通知される仕組みを考えたい。この手の日次ルーティーンは習慣にするまで時間がかかるが、慣れてくれば、それほどメンドウではない。むしろ一日の作業を振り返る良い機会になる。
何かを造る(創る)会社は「製造原価」の計算が付きまとう。
しかしながら「どの作業に、何時間費やしたか？」を正確に測る事は非常に難しい。特に「意匠デザイン」や「ソフトウェア開発」では、如何にスマートに各社員から報告してもらうかが大きな課題だ。（請負型ビジネスであれば≪生命線≫）
以下のワークフロー例では、毎日『作業時間の報告(タスク)』が自動で割り当てられる。BPMNでは『タイマー開始イベント』と呼ばれる。すなわち、未報告者やその未報告日は、リアルタイムに可視化される。
しかしながら「どの作業に、何時間費やしたか？」を正確に測る事は非常に難しい。特に「意匠デザイン」や「ソフトウェア開発」では、如何にスマートに各社員から報告してもらうかが大きな課題だ。（請負型ビジネスであれば≪生命線≫）
以下のワークフロー例では、毎日『作業時間の報告(タスク)』が自動で割り当てられる。BPMNでは『タイマー開始イベント』と呼ばれる。すなわち、未報告者やその未報告日は、リアルタイムに可視化される。
管理側の立場では「休暇の種類」は非常に大切だが、従業員にとって「振替休日」も「有給休暇」も大きな違いは無い。むしろ「休みの日を上司(会社)に申請」と言う点において、全く同じだ。「連休」になる様に休暇を取る場合も多い。
そんな人間達を相手に「振替休日／有給休暇／忌引休日／（休日種不明）」の申請を、それぞれ別々のフォームで受け付けると「色々な無駄」（問い合わせやミス）が発生する。そこで、以下の業務フロー例では「全ての休日申請」を一元的に受け付ける事を考えてみる。
そんな人間達を相手に「振替休日／有給休暇／忌引休日／（休日種不明）」の申請を、それぞれ別々のフォームで受け付けると「色々な無駄」（問い合わせやミス）が発生する。そこで、以下の業務フロー例では「全ての休日申請」を一元的に受け付ける事を考えてみる。
振替休日の申請を『休日出勤の最大の難関は「事前申請」だと思う』で例示したが、どうすればキッチリ「事前申請」が為されるか、をもう少し考察したい。
以下の例は、毎月「休日出勤シフト会議」を行っている会社の事例だ。すなわち、毎月25日に翌月分の振替休日申請をするように、自動的に申請プロセスが起動す（タスクが割り当てられ）る。
以下の例は、毎月「休日出勤シフト会議」を行っている会社の事例だ。すなわち、毎月25日に翌月分の振替休日申請をするように、自動的に申請プロセスが起動す（タスクが割り当てられ）る。
登録:
投稿
(
Atom
)