以下のワークフロー定義では、一つの原稿が、複数言語に翻訳される。
類似：『「翻訳フロー」で学ぶ業務フロー図の書き方』
＜各タスク名＞
1.原稿登録、2.原稿チェック、3a-d.引受＆納期、4a-d.質問／完了、5a-d.質問対応、6.翻訳確認
[翻訳-複数言語-並行：「4a.質問／完了」画面]
業務フロー図が、日常業務を変える！
ダウンロード可能な「業務テンプレート」を毎週公開するブログ
「データ入力」や「デザイン系」と並び「翻訳」は、在宅ワークとしてかなりポピュラーな業務だ。自分の時間に、自分のペースで、仕事を進められるのは有り難い。契約形態が雇用契約であれ請負契約であれ、もっとも大切なことは「進捗の可視化」だ。
以下のワークフロー定義では、一つの原稿が、複数言語に翻訳される。
類似：『「翻訳フロー」で学ぶ業務フロー図の書き方』
＜各タスク名＞
1.原稿登録、2.原稿チェック、3a-d.引受＆納期、4a-d.質問／完了、5a-d.質問対応、6.翻訳確認
以下のワークフロー定義では、一つの原稿が、複数言語に翻訳される。
類似：『「翻訳フロー」で学ぶ業務フロー図の書き方』
＜各タスク名＞
1.原稿登録、2.原稿チェック、3a-d.引受＆納期、4a-d.質問／完了、5a-d.質問対応、6.翻訳確認
- 日本では物品調達やアルバイト採用などを行う度に「手紙の様なもの」を書いて上司にお伺いを立てる。その書類を『稟議書』と呼ぶ。
- 日本ではこの時期、祝日が多い。谷間の出勤日に有給休暇を入れて10連休と言う人も少なくない。4月29日から5月初旬を『ゴールデンウィーク』と呼ぶ。
- そして、この時期の日本では商談が進まない・・・。
＃どうでも良い話だが、元々が映画業界の宣伝用語であったため公共放送などでは「ゴールデンウィーク」と言う言葉を一切使わない。しかし日本国民は全員、この時期の事を「ゴールデンウィーク」と呼ぶ。
＜各タスク名＞
1.稟議申請、2.上司承認、3.決裁／承認、4.決裁／承認、5.決裁／承認
[稟議-金額別決裁：「2.上司承認」画面]
＜各プロセスデータ名＞
- 件名
# 承認決裁ルート（★決裁者）：
# 100万円未満 ⇒ 上司 ⇒ ★役員
# 100万円以上 ⇒ 上司 ⇒ 役員 ⇒ ★社長
# 500万円以上 ⇒ 上司 ⇒ 役員 ⇒ 社長 ⇒ ★取締役会
- 文字型: 起案者所属部署名
- ユーザ型: 起案者
- ユーザ型: 上司氏名
- ユーザ型: 管掌役員
- 日付型: 起案日
- 文字型: 稟議ID
- 文字型(複数5行): 起案に対する説明
- 文字型(複数5行): 支払先選定に対する説明
- 日付型: 時期
- 文字型: 時期補足
- 数値型: 金額
- 文字型: 支払先
- ファイル型: 添付ファイル
- 選択型: 予算内 (予算内 / 予算外)
- 選択型: 予算元 (販管費 / プロジェクト経費)
- 選択型: 取下げフラグ ((再)申請する / 取り下げる)
- 選択型: 上司承認フラグ(OK / NG)
- 選択型: 管掌役員承認フラグ(OK / NG)
- 選択型: 社長承認フラグ(OK / NG)
- 選択型: 取締役会承認フラグ(OK / NG)
- 掲示板型: 社内通信
「翻訳」と言う仕事はテレワーク(在宅勤務)に適している。作業者に渡されるインプットと、作業者から生み出されるアウトプットが分かりやすく、アウトプット量の計測も比較的容易だ。
実際「翻訳フロー」は、BPM活動の初期テーマとして取り扱われることが多い。まずはシンプルなワークフロー定義で業務を回し、少しずつ「あるべきワークフロー」に近づけていこう。
＜各タスク名＞
1.原稿登録、2.原稿チェック、3.引受＆納期、4.質問／完了、5.質問対応、6.翻訳確認
＜各プロセスデータ名＞
実際「翻訳フロー」は、BPM活動の初期テーマとして取り扱われることが多い。まずはシンプルなワークフロー定義で業務を回し、少しずつ「あるべきワークフロー」に近づけていこう。
＜各タスク名＞
1.原稿登録、2.原稿チェック、3.引受＆納期、4.質問／完了、5.質問対応、6.翻訳確認
[翻訳-質問対応-タスク分岐：「4.質問／完了」画面]
＜各プロセスデータ名＞
- 件名＜原文タイトル＞
- 文字型: 原文タイトル
- ファイル型: 原文ファイル
- 文字型(複数5行): 原文
- 選択型: 重要度(A / B / C)
- 日付型: 希望納期
- 日付型: 予定納期
- 文字型: 翻訳タイトル
- ファイル型: 翻訳ファイル
- 文字型(複数5行): 翻訳文
- 選択型: 作業ステータス(質問する / 完了報告)
- 選択型: 検収ステータス(OK / 差し戻し)
- 掲示板型: 社内通信
優良顧客に対しては、一人ひとり丁寧なメールを書きたい。でも・・・、いつ誰がどんなメールを送ったんだか？
そんなお悩みを抱える、自動車ディーラーさん、美容室理髪店さん、歯医者さんは、クラウド型ワークフロー製品を試してみてはどうか。効率よく『顧客ステータス』を管理できる様になるかも知れない。
＜各タスク名＞
0.新規顧客登録、1.次回来店勧誘文、2.来店日記録、3.勧誘文
＜プロセスデータ＞
そんなお悩みを抱える、自動車ディーラーさん、美容室理髪店さん、歯医者さんは、クラウド型ワークフロー製品を試してみてはどうか。効率よく『顧客ステータス』を管理できる様になるかも知れない。
＜各タスク名＞
0.新規顧客登録、1.次回来店勧誘文、2.来店日記録、3.勧誘文
[来店勧誘-御礼メール送信：「2.来店日記録」画面]
＜プロセスデータ＞
- 件名＜氏名＞
- 文字型: ふりがな
- 日付型: 生年月日
- 文字型: 電話番号
- 文字型: 電話番号(副)
- 選択型: 性別(男性 / 女性 / 不明)
- 文字型: メールアドレス
- 文字型(複数2行): 住所
- 選択型: 優良顧客ランク(S / A / B / C / D)
- ユーザ型: 担当営業
- 日付型: 最新来店日
- 日付型: 次回来店誘導日
- 文字型(複数5行): 前回(初回)の来店御礼メール [タスク0、メッセージ開始イベント]
- 文字型(複数5行): 今回の来店誘導メール [タスク1、3]
- 文字型(複数5行): 今回の来店御礼メール [タスク2]
- 選択型: 制御(来店御礼メール送信＋次回誘導タスク予約 / 次回誘導タスク予約のみ / 優良顧客から削除) [タスク2]
- 掲示板型: 社内通信
新卒採用フローの現場は、意外とローテクだ。
特に不採用の通知は、就職を希望する学生の立場に立った丁寧な対応が必要になるため、どうしても手間がかかってしまう。さりとて一方では、受験者に対して≪迅速な連絡≫も実現したい。
社内の業務フロー（ワークフロー）をブラッシュアップし続ける必要がある。（不採用通知の例文も、各社でブラッシュアップを！）
類似：『数百人のエントリーシートを管理する』
＜各タスク名＞
0.郵送分の入力、1.書類合否判断、1a通知文、1b通知文、2.一次合否判断、2a通知文、2b通知文、3.二次合否判断、3a通知文、3b通知文、4.最終合否判断、4a通知文、4b通知文
<プロセスデータ名>
特に不採用の通知は、就職を希望する学生の立場に立った丁寧な対応が必要になるため、どうしても手間がかかってしまう。さりとて一方では、受験者に対して≪迅速な連絡≫も実現したい。
社内の業務フロー（ワークフロー）をブラッシュアップし続ける必要がある。（不採用通知の例文も、各社でブラッシュアップを！）
類似：『数百人のエントリーシートを管理する』
＜各タスク名＞
0.郵送分の入力、1.書類合否判断、1a通知文、1b通知文、2.一次合否判断、2a通知文、2b通知文、3.二次合否判断、3a通知文、3b通知文、4.最終合否判断、4a通知文、4b通知文
[人事採用-結果通知メール：「4b通知文」画面]
<プロセスデータ名>
- 件名(応募者氏名)
- 文字型: 応募者ふりがな
- 日付型: 生年月日
- 文字型: 電話番号
- 文字型: メールアドレス、
- 文字型（複数行-2行）: 住所
- 文字型（複数行-4行）: 学歴
- 文字型（複数行-4行）: 志望動機
- 文字型（複数行-4行）: 会社でやってみたい事
- ファイル型: 参考ファイル
- 選択型: 書類合否
- 選択型: 一次面接合否
- 選択型: 二次面接合否
- 選択型: 最終面接合否
- 掲示板型: 人事メモ
- 文字型（複数行-2行）: 書類結果通知文
- 文字型（複数行-2行）: 一次結果通知文
- 文字型（複数行-2行）: 二次結果通知文
- 文字型（複数行-2行）: 最終結果通知文
社内当番制のBlog発信。一般従業員が「執筆」する。多くは語るまい！！？
Blogへの投稿は『メッセージ送信中間イベント(メール)』によって自動投稿される。
＜各タスク名＞
1.指名、2.原稿執筆、3.依頼/投稿、4a.翻訳、4b.修正対応
Blogへの投稿は『メッセージ送信中間イベント(メール)』によって自動投稿される。
＜各タスク名＞
1.指名、2.原稿執筆、3.依頼/投稿、4a.翻訳、4b.修正対応
[Blog投稿：「2.原稿執筆」画面]
「BPMNの書き方」シリーズ第４弾。
ビジネスプロセスマネジメント活動を２～３か月続けていると、どうしても作りたくなる「親プロセス」と「子プロセス」と言う関係。
すなわち、プロセスモデルＡに流れるプロセスa1が…、
BPMS製品によって異なるが、ここでは（当然ながら）『Questetra BPM Suite』における「子プロセス」を生成する方法を紹介したい。
なお、これまでの「BPMNの書き方」シリーズを復習したい方は以下。
＜各タスク名＞
1.子供の名前を付ける
<各プロセスデータ>
ビジネスプロセスマネジメント活動を２～３か月続けていると、どうしても作りたくなる「親プロセス」と「子プロセス」と言う関係。
すなわち、プロセスモデルＡに流れるプロセスa1が…、
- プロセスモデルＢの新規プロセスb1を起動させる （Ａ:受注プロセス⇒Ｂ:生産プロセス）
- プロセスモデルＢの新規プロセスb1とb2を起動させる （Ａ:注文処理プロセス⇒Ｂ:配送プロセス）
- プロセスモデルＡの新規プロセスa2を起動させる （a1:当月請求書⇒a2:翌月請求書）
BPMS製品によって異なるが、ここでは（当然ながら）『Questetra BPM Suite』における「子プロセス」を生成する方法を紹介したい。
なお、これまでの「BPMNの書き方」シリーズを復習したい方は以下。
＜各タスク名＞
1.子供の名前を付ける
[BPMNサンプル-プロセス増殖：メッセージ送信中間イベント(HTTP)の設定画面]
<各プロセスデータ>
- 文字型: 件名＜自分の名前＞
- 日付型: 自分の生年月日
- 文字型: 親の名前
- 日付型: 親の生年月日
- 文字型: 新たに産む子供の名前
- 日付型: 新たに産む子供の生年月日
- 選択型: 産む死ぬフラグ (産む/死ぬ)
「さーて、来年のエントリーシートはどうやって集めるかね」
日本では、2012年4月入社の願書(エントリーシート)を締め切る季節だ。企業側は、これから面接や試験と言った選抜工程に移る。（そう、日本は早いのだ…）
＜各タスク名＞
0.郵送分の入力、1.書類合否、2.一次面接合否、3.二次面接合否、4.最終面接合否
<プロセスデータ名>
件名(応募者氏名)
▼エントリ内容▼
日本では、2012年4月入社の願書(エントリーシート)を締め切る季節だ。企業側は、これから面接や試験と言った選抜工程に移る。（そう、日本は早いのだ…）
＜各タスク名＞
0.郵送分の入力、1.書類合否、2.一次面接合否、3.二次面接合否、4.最終面接合否
[人事採用-新卒エントリ：「1.書類合否」画面]
<プロセスデータ名>
件名(応募者氏名)
▼エントリ内容▼
- 文字型: 応募者ふりがな
- 日付型: 生年月日
- 文字型: 電話番号
- 文字型: メールアドレス
- 文字型（複数行-2行）: 住所
- 文字型（複数行-4行）: 学歴
- 文字型（複数行-4行）: 応募者ふりがな
- 文字型（複数行-4行）: 志望動機
- 文字型（複数行-4行）: 会社でやってみたい事
- ファイル型: 参考ファイル
- 選択型: 書類合否
- 選択型: 一次面接合否
- 文字型（複数行-2行）: 一次結果挿入追伸文
- 選択型: 二次面接合否
- 文字型（複数行-2行）: 二次結果挿入追伸文
- 選択型: 最終面接合否
- 文字型（複数行-2行）: 最終結果挿入追伸文
- 掲示板型: 人事メモ
ビジネスプロセス管理は、フローを定義し、その上を流れるトークンを管理する。
「線路」を引いて、「電車」を走らせると言えば、分かりやすいかも？
まれに、自分で引いた線路の上を走っている電車を、人の引いた線路の上に走らせたくなる場合がある。（は？）。具体的に言えば、Ａエリア担当営業が得た引合を、Ｂエリアの担当営業に引き渡す、と言った例だ。
『営業支援システム(SFA)をBPM上に構築する』の『引合～商談～受注のフロー』を拡張し、案件を営業所間で自由に引き渡せるよ うにしたい。まずは、各営業所（ＡＢＣとする）それぞれが、以下のワークフロー定義を個別導入する。（もちろんフローの詳細は自治的に変更しても構わない）
＜各タスク名＞
1.リード手入力、2.1stコンタクト、3.初期提案活動、4.決裁者への提案活動、5.最終商談
＜各プロセスデータ名＞
件名(ユーザ企業名)
▼顧客情報▼
「線路」を引いて、「電車」を走らせると言えば、分かりやすいかも？
まれに、自分で引いた線路の上を走っている電車を、人の引いた線路の上に走らせたくなる場合がある。（は？）。具体的に言えば、Ａエリア担当営業が得た引合を、Ｂエリアの担当営業に引き渡す、と言った例だ。
『営業支援システム(SFA)をBPM上に構築する』の『引合～商談～受注のフロー』を拡張し、案件を営業所間で自由に引き渡せるよ うにしたい。まずは、各営業所（ＡＢＣとする）それぞれが、以下のワークフロー定義を個別導入する。（もちろんフローの詳細は自治的に変更しても構わない）
＜各タスク名＞
1.リード手入力、2.1stコンタクト、3.初期提案活動、4.決裁者への提案活動、5.最終商談
[顧客管理-引合-商談-受注-営業所連携：「Ｂ営業所へ」の設定画面]
＜各プロセスデータ名＞
件名(ユーザ企業名)
▼顧客情報▼
- テキスト型：利用企業名
- テキスト型：決裁者部署名
- テキスト型：決裁者氏名
- テキスト型：決裁者電話番号
- テキスト型：決裁者メール
- テキスト型：決裁者郵便番号
- テキスト型：決裁者URL
- テキスト型（複数行）：決裁者住所
- テキスト型：窓口担当者部署名
- テキスト型：窓口担当者氏名
- テキスト型：窓口担当者電話番号
- テキスト型：窓口担当者メール
- テキスト型（複数行）：その他関与者情報等
- 選択型：パートナ経由フラグ(直販 / パートナ経由)
- テキスト型：請求先企業名
- テキスト型：請求先部署名
- テキスト型：請求先氏名
- テキスト型：請求先電話番号
- テキスト型：請求先メール
- テキスト型：請求先郵便番号
- テキスト型：請求先URL
- テキスト型（複数行）：請求先住所
- 選択型：ノイズフラグ(提案活動へ / ノイズ)タスク2のみ
- 選択型：初期提案フラグ(初期ループ / 初期ループ(仮見積報告) / 決裁者提案へ / 提案終了へ)タスク3のみ
- 選択型：決裁者提案フラグ(決裁者提案ループ / 決裁者提案ループ(見積書作成依頼) / 最終商談へ / 提案終了へ)タスク4のみ
- 選択型：最終商談フラグ(最終商談ループ / 最終商談ループ(見積書作成依頼) / 成約報告 / 失注報告)タスク5のみ
- ユーザ型：担当営業
- 掲示板型：コンタクト記録
- テキスト型（複数行）：仮見積
- 選択型：注文種類(SaaS BPM / SaaS CRM / Other)
- ファイル型：見積書注文書データ
- 数値型：ユーザライセンス数
- 数値型：値引率
- 日付型：注文書受領日
- 日付型：初回請求金額 ≪税込金額≫
- 日付型：初回請求書発行日
- 日付型：初回入金日
- テキスト型（複数行）：注文概要注意
セールスの日々の活動を「広い意味で顧客情報をメンテナンスし続ける活動」と考えると、SFA(営業支援システム)は理解しやすい。つまりセールスは、新規引合対応や既存顧客対応の中で、顧客の属性に限らずニーズやウォンツについても情報収集を行い続けている。
参考記事：『営業支援システム(SFA)をBPM上に構築する』の『引合〜商談〜受注のフロー』
そしてセールスがメンテナンスし続けている情報を利用して、見積書作成プロセス、提案書作成プロセス、契約書締結プロセスなどを呼び出すと、情報入力の手間を省けてとても便利だ。
親プロセスの管理情報の一部を複製して、子プロセスを起動すれば、正確な情報の受け渡しが実現できるので、誤植や手戻りの発生を減らすことが出来る。利用するかどうかわからない、電話番号やメールアドレスを「子プロセス」に渡しておくのも良い。 以下のワークフロー定義は、「子プロセス」としての契約書チェックフローだ。
類似記事：『見積書がキチンと郵送されているか可視化する』
＜各タスク名＞
1.契約書案入力、2.契約書案承認、3.契約書内容交渉、4.署名押印
＜各プロセスデータ名＞
参考記事：『営業支援システム(SFA)をBPM上に構築する』の『引合〜商談〜受注のフロー』
そしてセールスがメンテナンスし続けている情報を利用して、見積書作成プロセス、提案書作成プロセス、契約書締結プロセスなどを呼び出すと、情報入力の手間を省けてとても便利だ。
親プロセスの管理情報の一部を複製して、子プロセスを起動すれば、正確な情報の受け渡しが実現できるので、誤植や手戻りの発生を減らすことが出来る。利用するかどうかわからない、電話番号やメールアドレスを「子プロセス」に渡しておくのも良い。 以下のワークフロー定義は、「子プロセス」としての契約書チェックフローだ。
類似記事：『見積書がキチンと郵送されているか可視化する』
＜各タスク名＞
1.契約書案入力、2.契約書案承認、3.契約書内容交渉、4.署名押印
[契約書チェック-上司承認：「1.契約書案入力」画面]
＜各プロセスデータ名＞
- 件名(ユーザ企業名)
- テキスト型：部署名
- テキスト型：氏名
- テキスト型：郵便番号
- テキスト型：URL
- テキスト型：電話番号
- テキスト型：メールアドレス
- テキスト型（複数行）：住所
- 選択型：契約書種類 (NDA / 委託契約 / Other)
- 選択型：契約書起案 (先方 / 当方)
- ユーザ型：担当営業
- ファイル型：契約書Word等
- ファイル型：対案契約書Word タスク2のみ
- 選択型：合意フラグ (合意 / 修正 / 取消) タスク3のみ
- 日付型：署名完了日 タスク4のみ
- ファイル型：契約書スキャン画像 タスク4のみ
- 掲示板型：社内通信
セールスチームは「顧客情報をメンテナンスし続けている」と言っても過言ではない。どんな≪課題≫が存在するのか、どんな≪商品≫が欲しいのか、どんな≪解決≫を夢見ているのか…。
セールスチームが『プロセスデータ』を用いて顧客情報をメンテナンスし続ける活動は、『営業支援システム(SFA)をBPM上に構築する』に提案した。今日は、それらのデータを利用した「子プロセス」的な業務フローとして『見積書作成～見積書郵送プロセス』を提案したい。
＜各タスク名＞
1.見積書データ、2.印刷＆署名依頼、3.助言、4.見積書受領、5.郵送
セールスチームが『プロセスデータ』を用いて顧客情報をメンテナンスし続ける活動は、『営業支援システム(SFA)をBPM上に構築する』に提案した。今日は、それらのデータを利用した「子プロセス」的な業務フローとして『見積書作成～見積書郵送プロセス』を提案したい。
＜各タスク名＞
1.見積書データ、2.印刷＆署名依頼、3.助言、4.見積書受領、5.郵送
[見積書作成-完成通知メール：「1.見積書データ」画面]
「小さく始める」と言うフレーズはBPM活動の基本だが、その裏側には「大きく育てる」と言う意味もある。すなわち、ビジネスオブジェクトの「あるべき データ項目」と「あるべき流れ方」が見えてくれば、上流や下流のビジネスプロセスも捕捉できるように、BPM適用領域を拡大したい。
以下のビジネ スモデル(ワークフロー定義)は、マーケティング活動とセールス活動を包括する「引合～商談～受注」のプロセスだ。すなわち社内の案件ステータスを可視化 する。途中ぐるぐるとループさせることで、顧客プロフィールを徐々に詳細化させていく。『営業支援システム』(SFA)そのものと言っても良い。
<各タスク名>
1.リード手入力, 2.1stコンタクト, 3.初期提案活動, 4.決裁者への提案活動, 5.最終商談
以下のビジネ スモデル(ワークフロー定義)は、マーケティング活動とセールス活動を包括する「引合～商談～受注」のプロセスだ。すなわち社内の案件ステータスを可視化 する。途中ぐるぐるとループさせることで、顧客プロフィールを徐々に詳細化させていく。『営業支援システム』(SFA)そのものと言っても良い。
<各タスク名>
1.リード手入力, 2.1stコンタクト, 3.初期提案活動, 4.決裁者への提案活動, 5.最終商談
[顧客管理-引合-商談-受注 : 「1.リード手入力」画面]
プロセスモデルを定義するには、流れ・組織・データの基本３要素を押さえる必要がある。
確かに「流れ」を考える作業も頭を使うのだが、「データ」を設計するのもまた違う場所の脳を使うので大変だ。
特に財務会計に影響を与えるようなワークフロー定義であれば、項目が多くて嫌になってくる。
『セールスは実際に郵送される請求書をチェックすべきか？』のデータ項目(プロセスデータ)について真面目に列挙しておく。しかし、 御社で導入する場合は、以下のリスト以外に必要なデータ項目にが無いか、しっかり瞑想する時間をとってから着手した方が良い。
＜各タスク名＞
1.受注/請求情報入力、2.請求情報確認、3.請求書作成、4.請求書レビュー、5.請求書発送、6.入金確認
確かに「流れ」を考える作業も頭を使うのだが、「データ」を設計するのもまた違う場所の脳を使うので大変だ。
特に財務会計に影響を与えるようなワークフロー定義であれば、項目が多くて嫌になってくる。
『セールスは実際に郵送される請求書をチェックすべきか？』のデータ項目(プロセスデータ)について真面目に列挙しておく。しかし、 御社で導入する場合は、以下のリスト以外に必要なデータ項目にが無いか、しっかり瞑想する時間をとってから着手した方が良い。
＜各タスク名＞
1.受注/請求情報入力、2.請求情報確認、3.請求書作成、4.請求書レビュー、5.請求書発送、6.入金確認
[請求書発行-次月請求書対応：「1.受注/請求情報入力」画面]
「分岐」は学んだ。「タスク」は分かる。ぢゃ、次のステップは「イベント」だ。
「イベント」とは、「タスク」(仕事)や「分岐」(ビジネスルール)では表せない出来事全般を表現する。そんな表現をすると学習意欲がそいでしまうが、
ちなみにBPMN2.0で規定されたイベントは全部で60以上あるが、ほとんどBPMシステムはそのゴク一部しか利用できない。「あらゆるイベント記号を駆使したい」などと言う人もあるが、そんなことをしたら業務フロー図を読める人が激減してしまう。「多くの人が直観的に理解できる事」がBPMNの良いところであり、日常的に利用するイベントは上記の６つ程度で良い。（キリっ）
＜各タスク名＞
1.タスク
「イベント」とは、「タスク」(仕事)や「分岐」(ビジネスルール)では表せない出来事全般を表現する。そんな表現をすると学習意欲がそいでしまうが、
- 人間が始めるよ（ノーマル開始イベント）
- 時計さんが始めるよ（タイマー開始イベント）
- お便りが来たら始めるよ（メッセージ開始イベント）
- お便りを出すよ（メッセージ送信中間イベント）
- ここで終了だよ（ノーマル終了イベント）
- 他の同時処理作業も含めて終了だよ（全終了イベント）
ちなみにBPMN2.0で規定されたイベントは全部で60以上あるが、ほとんどBPMシステムはそのゴク一部しか利用できない。「あらゆるイベント記号を駆使したい」などと言う人もあるが、そんなことをしたら業務フロー図を読める人が激減してしまう。「多くの人が直観的に理解できる事」がBPMNの良いところであり、日常的に利用するイベントは上記の６つ程度で良い。（キリっ）
＜各タスク名＞
1.タスク
[BPMNサンプル-メッセージ送信中間イベント（メール）-ループ：「1.タスク」画面]
Webフォームに入力された方の多くから入金がある場合、さて…どの様にして効率よく「入金チェック」を行うか？
特に需要が大きいのは「イベントの参加申込」だ。一人で行うにしても、複数人で行うにしても、『Webフォーム入力データ』と『銀行やクレジット経由の入金ログ』を照合する作業は大変だ。
以下のワークフロー定義では、Webフォーム入力情報を自動的に取り込み、その後『1.入金確認』タスクで消し込みを行う。「いつ誰が消し込んだか」の情報も自動的に残る上に、消し込み後の「入金御礼メール」も自動的に送信される。
＜各タスク名＞
1.入金確認(一週間)、2.督促判断
特に需要が大きいのは「イベントの参加申込」だ。一人で行うにしても、複数人で行うにしても、『Webフォーム入力データ』と『銀行やクレジット経由の入金ログ』を照合する作業は大変だ。
以下のワークフロー定義では、Webフォーム入力情報を自動的に取り込み、その後『1.入金確認』タスクで消し込みを行う。「いつ誰が消し込んだか」の情報も自動的に残る上に、消し込み後の「入金御礼メール」も自動的に送信される。
＜各タスク名＞
1.入金確認(一週間)、2.督促判断
[入金消込-タスク分担：「2.督促判断」画面]
毎朝毎晩の「定時タスク」を習慣化すれば、「勤務時刻」の報告だけでなく結構色々な事ができる。ニュースサイトを巡回した感想をメモするもよし、業界最新情報をTwitterでつぶやくもよし…。
毎日出勤しないアルバイトさん達にとっても、この習慣化は大切だ。ワークフロー定義『「勤務時刻をワークフローで記録」は意外とアリ』を拡張して、定時タスクを実行する日（勤務日）を事前に入力しておけるようにしよう。
つまり、シフトが決まった時に今月の出勤日を入力したり、帰り際に次回出勤日を入力したりする。（勤務時刻も予定入力しておける）
＜各タスク名＞
0.勤務予定日入力、1.勤務開始時刻記録、2.勤務開始確認、3.勤務終了時刻記録、4.勤務終了確認
毎日出勤しないアルバイトさん達にとっても、この習慣化は大切だ。ワークフロー定義『「勤務時刻をワークフローで記録」は意外とアリ』を拡張して、定時タスクを実行する日（勤務日）を事前に入力しておけるようにしよう。
つまり、シフトが決まった時に今月の出勤日を入力したり、帰り際に次回出勤日を入力したりする。（勤務時刻も予定入力しておける）
＜各タスク名＞
0.勤務予定日入力、1.勤務開始時刻記録、2.勤務開始確認、3.勤務終了時刻記録、4.勤務終了確認
[勤怠管理-つぶやき自動投稿：「0.勤務予定日入力」画面]
昨日は Questetra のプレスリリースの日だった。〔内容が気になる人はコチラ〕
基本的な情報の伝達経路は「情報発信者⇒マスメディア⇒一般大衆」なのだが、最近のプレスリリースでは「情報発信者⇒配信代行サービス⇒マスメディア⇒一般大衆」の流れが目立つ。すなわち、メディアの数が多くなった、プレスリリース文を一般大衆が直接読むケースがある、SEO対策にもなる、そもそもメディアが配信代行会社に依存しつつある、などが背景にあるようだ。
＜各タスク名＞
1.プレス配信文登録、2.配信会社通知、3.最終原稿確認、4.自社サイト登録
基本的な情報の伝達経路は「情報発信者⇒マスメディア⇒一般大衆」なのだが、最近のプレスリリースでは「情報発信者⇒配信代行サービス⇒マスメディア⇒一般大衆」の流れが目立つ。すなわち、メディアの数が多くなった、プレスリリース文を一般大衆が直接読むケースがある、SEO対策にもなる、そもそもメディアが配信代行会社に依存しつつある、などが背景にあるようだ。
＜各タスク名＞
1.プレス配信文登録、2.配信会社通知、3.最終原稿確認、4.自社サイト登録
[プレス配信-効果測定：「1.プレス配信文登録」画面]
仕事の開始時刻と終了時刻をワークフローシステムで報告する（勤怠管理）のは意外と良い方法だ。例えば、外出時に「今から仕事タイムです」とスマートフォン報告できれば、手っ取り早い。
ちなみに、この手の業務管理データは、数日分をまとめた報告が為されがちだ。そして多くの企業で不正確なデータが蓄積されていく。そうではなく、毎朝毎晩こまめに記録する習慣をつけることが大切なのだ。オフィス出勤時も、直行直帰時も、在宅勤務時も・・・。そういう意味では、毎日ログインするワークフローシステムを活用するという発想は、ルーティンワーク化させる上でアリだ。〔偉い人にはそれが分からんのですよ〕
＜各タスク名＞
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.休暇申請」画面]
先週の「BPMNの書き方」では『業務フロー図表記法BPMNの基本は「分岐」だ』と言うタイトルで、「×印」と「＋印」のある分岐について説明した。今日は「○印」のある分岐について説明しよう。
＜各タスク名＞
1.タスク、2abc.タスク、3.タスク
- ×印： XOR分岐 ⇒ どれか一つ
- ＋印： AND分岐 ⇒ 全部
- ○印： OR分岐 ⇒ いくつか
＜各タスク名＞
1.タスク、2abc.タスク、3.タスク
[BPMNサンプル-OR分岐：「1.タスク」画面]
ドキュメントレビューは『はじめての業務フロー設計』に最適だ。
特に『汎用的なレビュープロセス』は、設計者にとっても社員にとっても、BPMやワークフローに慣れるために都合良い。何より気楽に使える。
ちなみにしばらく運用すると、ドキュメントの蓄積がそれはそれでノウハウの集積になる。そして不思議なもので『整備が必要なプロセス』が見えてくる。
＜参考＞
＜各タスク名＞
1.ドキュメント登録、2a.部内レビュー、2b.全社レビュー、3.完了確認
特に『汎用的なレビュープロセス』は、設計者にとっても社員にとっても、BPMやワークフローに慣れるために都合良い。何より気楽に使える。
ちなみにしばらく運用すると、ドキュメントの蓄積がそれはそれでノウハウの集積になる。そして不思議なもので『整備が必要なプロセス』が見えてくる。
＜参考＞
＜各タスク名＞
1.ドキュメント登録、2a.部内レビュー、2b.全社レビュー、3.完了確認
[ドキュメントレビュー-レビュワ移行：メールプロパティ設定画面]
給与計算は大事な業務。各社員の勤務時間を集計し、残業手当（時間外労働手当）、休日労働手当、深夜労働手当を計算する。
以下のワークフロー定義は、全従業員が自身専用の出勤簿ファイル（Excelファイル）に出勤内容を記入し報告する形態だ。毎月入力になるがExcelファイルは12か月分のシートが用意されているので、同じファイルへの加筆作業となる。基本的な情報（プロセスデータ）は前月データを引き継ぐ。
＜各タスク名＞
1.出勤簿入力依頼、2.出勤簿入力、3.出勤簿上司確認、4.再提出対応、5.出勤簿経理確認
以下のワークフロー定義は、全従業員が自身専用の出勤簿ファイル（Excelファイル）に出勤内容を記入し報告する形態だ。毎月入力になるがExcelファイルは12か月分のシートが用意されているので、同じファイルへの加筆作業となる。基本的な情報（プロセスデータ）は前月データを引き継ぐ。
＜各タスク名＞
1.出勤簿入力依頼、2.出勤簿入力、3.出勤簿上司確認、4.再提出対応、5.出勤簿経理確認
[出勤報告-入力依頼省略：「2.出勤簿入力」画面]
契約書は、9割が雛形通りなのか、雛形通りは1割しか無いのか。
締結数は、年間10本なのか、年間100本なのか。
法務担当者は、社内に居るのか、全て弁護士に依存しているのか。
日本の場合だと、押印する人は誰か、も大きな問題だ。
契約書のチェックフローと言っても、会社によってゼンゼン違う。すなわち「あるべき姿」はそれぞれの会社がそれぞれ考えるしかない。
以下の法務チェックフローは、法務担当者がある程度知識を持っていながらも、必要あれば顧問弁護士に問い合わせするというフローだ。顧問弁護士もワークフローシステムにログインする。
この様なフローを整備すれば、いつ誰がどの様な判断を行ったのかを全て自動的に記録していくことができる。契約書案の蓄積も、間違いなく業務効率向上につながる。内部統制視点でも強くお勧めしたい。
＜各タスク名＞
1.契約書案投入、2.承認、3.判断＆コメント、4.確認対応、5.完了確認
締結数は、年間10本なのか、年間100本なのか。
法務担当者は、社内に居るのか、全て弁護士に依存しているのか。
日本の場合だと、押印する人は誰か、も大きな問題だ。
契約書のチェックフローと言っても、会社によってゼンゼン違う。すなわち「あるべき姿」はそれぞれの会社がそれぞれ考えるしかない。
以下の法務チェックフローは、法務担当者がある程度知識を持っていながらも、必要あれば顧問弁護士に問い合わせするというフローだ。顧問弁護士もワークフローシステムにログインする。
この様なフローを整備すれば、いつ誰がどの様な判断を行ったのかを全て自動的に記録していくことができる。契約書案の蓄積も、間違いなく業務効率向上につながる。内部統制視点でも強くお勧めしたい。
＜各タスク名＞
1.契約書案投入、2.承認、3.判断＆コメント、4.確認対応、5.完了確認
[契約書チェック-同時依頼：「2.承認」画面]
日本では地震被害による電力不足が深刻だ。首都圏では照明空調のみならず電車通勤網も正常に機能していない。
これまで在宅勤務と言えば「介護や育児と言った福利厚生上の制度」と考えられる傾向が強かったが、これからは「社員一人ひとりの生産性向上のための制度」ととらえる必要があろう。1.データ入力、2.翻訳、3.デザイン制作、4.プログラム制作、5.製図設計、6.販売促進…。現状でも様々な職種で在宅勤務が有効だが、今後はより多くの職種で在宅勤務が検討される。
在宅勤務制度の導入ポイントは『労働時間』だけでなく、むしろ『アウトプット』をきちんと記録できるツールの存在だ。以下は、在宅勤務で生産するアウトプットを「事前」に決定しておく事を是としながらも、副産物的に生み出したアウトプットも記録できるワークフロー定義だ。自らのアウトプットをきちんと記録する事で、人事考課における基礎データにもなる。
＜参考＞
＜各タスク名＞
0.仕事内容の提案、1.仕事内容の指示、2.スケジュールの回答、3.スケジュール承認、4.成果物登録、5.完了確認
これまで在宅勤務と言えば「介護や育児と言った福利厚生上の制度」と考えられる傾向が強かったが、これからは「社員一人ひとりの生産性向上のための制度」ととらえる必要があろう。1.データ入力、2.翻訳、3.デザイン制作、4.プログラム制作、5.製図設計、6.販売促進…。現状でも様々な職種で在宅勤務が有効だが、今後はより多くの職種で在宅勤務が検討される。
在宅勤務制度の導入ポイントは『労働時間』だけでなく、むしろ『アウトプット』をきちんと記録できるツールの存在だ。以下は、在宅勤務で生産するアウトプットを「事前」に決定しておく事を是としながらも、副産物的に生み出したアウトプットも記録できるワークフロー定義だ。自らのアウトプットをきちんと記録する事で、人事考課における基礎データにもなる。
＜参考＞
＜各タスク名＞
0.仕事内容の提案、1.仕事内容の指示、2.スケジュールの回答、3.スケジュール承認、4.成果物登録、5.完了確認
[在宅勤務-スケジュール回答省略]：「4.成果物登録」画面]
登録:
投稿
(
Atom
)