調達(購買)の申請ワークフローについては『オフィス用品の総務購買ワークフローも工夫が必要』を例示した。と、なれば、その後の納入検収のステップも一元的に管理しておきたい、と思うのが人情というものだ。つまり「購買申請ワークフロー」と「検収ワークフロー」を合体させたい。(もちろん「紙管理」を含めて、別システムで管理される場合はある)
ちなみに「どの『調達申請』が納品待ち状態なのか」を誰でも把握できる事の意味は大きい。すなわち、例えば「トナー切れ」を発見した時に「既に他の誰かが申請して、今は納入前?」を調べる事が出来る。
申請系ワークフロー(ビジネスプロセス)として頻出の『調達購買』は、「支出総額の抑止」が大きなテーマ。
まずは「小さな支出」の削減の積み重ねが大切だが、その為にも「購買一元化」と「交渉力強化」を推進したい(SRM: Supplier Relationship Management の王道)。
すなわち各部署からの申請は、極力「商品名」に対して必要数量(希望数)を申請してもらう形で行ってもらいたい。以下の例では、プリンタ用紙やトナーなどの消耗品から、ソフトライセンス、チラシやカタログなどの販促ツール等まで、幅広い調達業務が想定されている。
まずは「小さな支出」の削減の積み重ねが大切だが、その為にも「購買一元化」と「交渉力強化」を推進したい(SRM: Supplier Relationship Management の王道)。
すなわち各部署からの申請は、極力「商品名」に対して必要数量(希望数)を申請してもらう形で行ってもらいたい。以下の例では、プリンタ用紙やトナーなどの消耗品から、ソフトライセンス、チラシやカタログなどの販促ツール等まで、幅広い調達業務が想定されている。
決裁者を指名して立替金申請するワークフローは『立替金申請のワークフローは、新入社員にも分かりやすく!』のエントリで例示した。
しかし≪申請した社員≫の気持ちになって考えるに、「オレの立替金申請は、ちゃんと受理されたのだろうか??」だ。そこで決裁と経理確認が済んだ時点で自動的にメールされる仕組みを組み込んでおきたい。
(フロー最下流に「メッセージ送信中間イベント(Email)」)
しかし≪申請した社員≫の気持ちになって考えるに、「オレの立替金申請は、ちゃんと受理されたのだろうか??」だ。そこで決裁と経理確認が済んだ時点で自動的にメールされる仕組みを組み込んでおきたい。
(フロー最下流に「メッセージ送信中間イベント(Email)」)
「立替金申請フロー」は申請系ワークフロー(ビジネスプロセス)の中でも4大アプリケーションの一つだ。
※ 立替金精算(旅費経費)、人事労務(勤怠)、調達購買、稟議
スムーズな業務処理の為には「入力フォームの注意書きの分かり易さ」が欠かせない。業務フローの「流れ方」を工夫するよりもよほど効果がある。「申請者想定は社員全員」など利用者が大人数の場合には、ナオサラだ。
※ 立替金精算(旅費経費)、人事労務(勤怠)、調達購買、稟議
スムーズな業務処理の為には「入力フォームの注意書きの分かり易さ」が欠かせない。業務フローの「流れ方」を工夫するよりもよほど効果がある。「申請者想定は社員全員」など利用者が大人数の場合には、ナオサラだ。
「ビジネスプロセス改善事例!」だの、「実践ワークフロー改善!」だの・・・、近年BPM関連のセミナーやイベントが急増している。
そこで語られる事例の多くは「組織外部からのリクエストに対応するプロセス」に類するものだ。やはり『見積書対応』や『問い合わせ対応』などの顧客へのレスポンス改善は、売上に直結するプロセスであり、どの企業もモチベーションが高い。
さて「特定のタスク群」(プロセスモデル)の対応時間を計測したい場合、あえて単純なプロセスモデルとして独立させ、そこを通過する所用時間を計測したくな る。そんな場合、前後のタスク群(プロセスモデル)とは、メッセージ送信中間イベント等でプロセスモデル同士を接続するのが良い。
そこで語られる事例の多くは「組織外部からのリクエストに対応するプロセス」に類するものだ。やはり『見積書対応』や『問い合わせ対応』などの顧客へのレスポンス改善は、売上に直結するプロセスであり、どの企業もモチベーションが高い。
さて「特定のタスク群」(プロセスモデル)の対応時間を計測したい場合、あえて単純なプロセスモデルとして独立させ、そこを通過する所用時間を計測したくな る。そんな場合、前後のタスク群(プロセスモデル)とは、メッセージ送信中間イベント等でプロセスモデル同士を接続するのが良い。
新入社員を「受け入れる際」の一連のタスクをモレ無く実施するビジネスプロセスを定義したが、「社員退職の際」の一連のタスクについてもサンプルを例示しておこう。
※参考:『新人さんが入社した時に実施すべき一連の手続き』
入社手続きの場合は『人事部』が起点となってワークフローが開始されたが、退職手続きの場合は、その事実を最初に把握する(であろう)『所属部長』が起点となるべきだ。
※参考:『新人さんが入社した時に実施すべき一連の手続き』
入社手続きの場合は『人事部』が起点となってワークフローが開始されたが、退職手続きの場合は、その事実を最初に把握する(であろう)『所属部長』が起点となるべきだ。
新人社員を迎える際には「決まった手続き」がある。
カードキーを発行したり、名刺を作成したり、アカウントを発行したり。もちろん会社によっては他にも様々な手続きがあるだろう。そんな一連の手続きをヌケ・モレが無くこなす事は意外と難しい。そんな場合に「分岐機能があるワークフロー」は便利だ。
カードキーを発行したり、名刺を作成したり、アカウントを発行したり。もちろん会社によっては他にも様々な手続きがあるだろう。そんな一連の手続きをヌケ・モレが無くこなす事は意外と難しい。そんな場合に「分岐機能があるワークフロー」は便利だ。
『ToDoリスト (Tasks)』と呼ばれる「自分用の仕事メモ」を活用する人は多い。
Gmailメニューにも『連絡先 (Contacts)』にあわせて『ToDoリスト (Tasks)』が標準で用意されている。もちろん『ToDoリスト (Tasks)』はGoogle Calendarにも表示される。(『ワークリスト (Worklist)』と呼ばれる場合もある)
今回は、BPMSやワークフロー内で自分の『ToDoリスト (Tasks)』を管理する方法を提案したい。そうすると、他のワークフローのタスクと一緒に管理できるだけでなく、締切日を管理したり、途中作業のログを記録したり、参考ファイルを添付したり、更には同僚に閲覧権限を与えて見えるようにしたり…、と『ToDoリスト (Tasks)』には出来ない色々な事ができる様になる。
Gmailメニューにも『連絡先 (Contacts)』にあわせて『ToDoリスト (Tasks)』が標準で用意されている。もちろん『ToDoリスト (Tasks)』はGoogle Calendarにも表示される。(『ワークリスト (Worklist)』と呼ばれる場合もある)
今回は、BPMSやワークフロー内で自分の『ToDoリスト (Tasks)』を管理する方法を提案したい。そうすると、他のワークフローのタスクと一緒に管理できるだけでなく、締切日を管理したり、途中作業のログを記録したり、参考ファイルを添付したり、更には同僚に閲覧権限を与えて見えるようにしたり…、と『ToDoリスト (Tasks)』には出来ない色々な事ができる様になる。
個別の顧客に対して、提案活動とその後の電話フォローをモレなく実施したい。もちろん専用のSFAシステムを導入して『リード管理』をしても良いのだが、コストをかけずBPMワークフローシステム内で構築したい。
以下の事例は、「セールス担当が提案書雛型に対して大きな編集をしない」を想定しつつ、その後の「提案ステップ」を着実にこなすワークフロー。
以下の事例は、「セールス担当が提案書雛型に対して大きな編集をしない」を想定しつつ、その後の「提案ステップ」を着実にこなすワークフロー。
「外出の多いセールスマン」や「在宅勤務者(テレワーカ)」にとって SaaS 型の業務システムは『ワークプレイス』だ。
彼らのビジネスプロセス(ワークフロー)を整理し続け、組織全体の生産性向上を図りたい。
必ず同僚レビューを受ける形の『セールス品質を高める提案書作成フロー』では、「レビュー」と言うステップ(タスク)で停滞しがちだ。それでも誰かのレビューを受けられるようにしたい。
彼らのビジネスプロセス(ワークフロー)を整理し続け、組織全体の生産性向上を図りたい。
必ず同僚レビューを受ける形の『セールス品質を高める提案書作成フロー』では、「レビュー」と言うステップ(タスク)で停滞しがちだ。それでも誰かのレビューを受けられるようにしたい。
「営業マンが提出する提案書品質が上がらない…」 そんな悩みを持つセールスマネージャは少なくない。さて、ヒトが悪いのか?、業務プロセスが悪いのか?
単純な話、『過去のベスト提案書』をブラッシュアップし続ければ、確実に『ベスト提案書』ができあがる。セールスチーム全体で「提案書作成業務フロー」を遵守して作成すれば、相互助言が実現できるだけでなく、成果物としての提案書が様々なコメント付きでデータベース化される。(再利用性向上=組織力)
単純な話、『過去のベスト提案書』をブラッシュアップし続ければ、確実に『ベスト提案書』ができあがる。セールスチーム全体で「提案書作成業務フロー」を遵守して作成すれば、相互助言が実現できるだけでなく、成果物としての提案書が様々なコメント付きでデータベース化される。(再利用性向上=組織力)
ソフトウェアや情報システムの開発では「テスト工程」がつきもの。「要件と一致しているか」を確認するだけでなく、その確認行為を記録しておくことが大切だ。
機械テストを多用する事になるのだが、最後は人間によってレポートされる必要がある。以下の例は、一つの「テスト仕様書」に対して、二人のテスタが「テスト報告書」を完成させる業務フローだ。
機械テストを多用する事になるのだが、最後は人間によってレポートされる必要がある。以下の例は、一つの「テスト仕様書」に対して、二人のテスタが「テスト報告書」を完成させる業務フローだ。
請求書発行の遅延やモレを防止すべく、経理部門がToDoタスクを追加しておくワークフローは昨日紹介した。(『請求書発行フローは、部署横断に助け合うべきワークフロー』)
このワークフロー例は「人間系タスク」の集合としての「請求書発行プロセス」になっている。
システム連携による「機械的な業務処理」を目指す事で、更に請求書発行の遅延やモレを防ぐ事ができる。すなわち『0.請求書発行指示』を「自動化」する事を考えたい。
このワークフロー例は「人間系タスク」の集合としての「請求書発行プロセス」になっている。
システム連携による「機械的な業務処理」を目指す事で、更に請求書発行の遅延やモレを防ぐ事ができる。すなわち『0.請求書発行指示』を「自動化」する事を考えたい。
請求書の「発行遅延」は、かなりイケてない。
請求書の「発行モレ」は、究極にイケてない。
組織にあわせた請求書発行プロセスを模索し続け、「遅延」や「モレ」を撲滅したい。
そもそも「請求書発行プロセス」は、どの部署から開始されるべきか、会社によって異なる。すなわち『顧客に対峙しているセールス部門』、『完成納入を把握し ている業務部門(製造部門)』、『受注を把握している経理部門』のいずれも考えられる。以下の例は、業務部門(製造部門)自身が(完成納入後に)請求書発行を開始するワークフローサンプルだ。
請求書の「発行モレ」は、究極にイケてない。
組織にあわせた請求書発行プロセスを模索し続け、「遅延」や「モレ」を撲滅したい。
そもそも「請求書発行プロセス」は、どの部署から開始されるべきか、会社によって異なる。すなわち『顧客に対峙しているセールス部門』、『完成納入を把握し ている業務部門(製造部門)』、『受注を把握している経理部門』のいずれも考えられる。以下の例は、業務部門(製造部門)自身が(完成納入後に)請求書発行を開始するワークフローサンプルだ。
どれだけ周到な準備やテストをしていても、Webサイトを新規公開する瞬間は緊張が走る。
現実問題として「テスト運用環境」と「本番運用環境」を100%完全に同じ条件にする事は不可能であり、公開してみて初めて発覚する『不具合』もある。
大切なことは『不具合』の発生時に、着手優先順位を付け、しかるべき手順で、冷静に対応する事だ。
現実問題として「テスト運用環境」と「本番運用環境」を100%完全に同じ条件にする事は不可能であり、公開してみて初めて発覚する『不具合』もある。
大切なことは『不具合』の発生時に、着手優先順位を付け、しかるべき手順で、冷静に対応する事だ。
受託事業において『検収報告書の獲得』は最優先事項だ。Webサイト制作にせよ、システム制作にせよ、『検収報告書』をもらう為に頑張ると言っても過言ではない。
プロジェクト全体では、『企業間プロジェクトにおける仕様書確定プロセス』で紹介したように、最終的に『検収完了』のステータスに持っていく必要がある。しかし多くのケースで、すんなり『検収完了』になる事はない。
すなわち納品物に対して「修正要望」が出てくる。それが2〜3箇所なのか、10箇所なのか、50箇所なのか…。いずれにせよ一つ一つの「修正要望」をキッチリと把握し、消し込んでいく必要がある。
プロジェクト全体では、『企業間プロジェクトにおける仕様書確定プロセス』で紹介したように、最終的に『検収完了』のステータスに持っていく必要がある。しかし多くのケースで、すんなり『検収完了』になる事はない。
すなわち納品物に対して「修正要望」が出てくる。それが2〜3箇所なのか、10箇所なのか、50箇所なのか…。いずれにせよ一つ一つの「修正要望」をキッチリと把握し、消し込んでいく必要がある。
ワークフローは『企業内に閉じたもの』と思いがち。ただ、「頻繁に発生する定型の業務」は企業内に限った事ではない。
例えば「仕様書」の『企業間やり取り』をメールで行うと、やり取りしている当事者同士ですら、結局どれが「最終的に確定した仕様書」なのか分からなくなる。このようなケースでは、『企業間やり取り』を可視化し、その進捗を委託側・受託側それぞれの多数関係者がいつでも確認できる様にしたい。
(そもそもメールやり取りは、会社記録に残らない可能性があるので避けたい)
以下の業務フローは、両社権限者の仕様書策定活動(と仕様書修正活動)をオープンに進捗させるためのフレームと言える。
(「SaaSワークフロー」であればプロジェクト期間中だけの利用も出来て便利)
例えば「仕様書」の『企業間やり取り』をメールで行うと、やり取りしている当事者同士ですら、結局どれが「最終的に確定した仕様書」なのか分からなくなる。このようなケースでは、『企業間やり取り』を可視化し、その進捗を委託側・受託側それぞれの多数関係者がいつでも確認できる様にしたい。
(そもそもメールやり取りは、会社記録に残らない可能性があるので避けたい)
以下の業務フローは、両社権限者の仕様書策定活動(と仕様書修正活動)をオープンに進捗させるためのフレームと言える。
(「SaaSワークフロー」であればプロジェクト期間中だけの利用も出来て便利)
企業セミナーや出展イベントを行う場合、事前申込者に対して、1か月前/1週間前/直前…と案内メールを送る。『Pushメール』とも呼ばれる。
≪口コミ集客≫ 「ちゃんと来てね」、「友達にも紹介してね」、「ナンなら連れてきてね」…。
≪事前再告知≫ 「こんなコトするよ」、「あんなコトもするよ」、「こんなURLも見といて」…。
その回数や文面は各企業の『ノウハウ』だ。取扱商品やサービスによっても全く異なるだろう。過去にも『リマインダメールをモレなく送信するワークフロー』や『「イレギュラーな事態」の発生件数を計測しよう』で「マンションの見学会」や「自動車ディーラーの試乗会」の例を紹介した。
≪口コミ集客≫ 「ちゃんと来てね」、「友達にも紹介してね」、「ナンなら連れてきてね」…。
≪事前再告知≫ 「こんなコトするよ」、「あんなコトもするよ」、「こんなURLも見といて」…。
その回数や文面は各企業の『ノウハウ』だ。取扱商品やサービスによっても全く異なるだろう。過去にも『リマインダメールをモレなく送信するワークフロー』や『「イレギュラーな事態」の発生件数を計測しよう』で「マンションの見学会」や「自動車ディーラーの試乗会」の例を紹介した。
「GoogleDocs の SpreadSheet Form」 と Workflow の連動ニーズは極めて多い。『顧客情報の管理』から『社内宴会の出欠管理』まで、様々なデータ収集フォームを簡単に作成できるからだ。
例えば「100人を相手にしたコミュニケーション」を考える。最初の質問は同報メールで全員に投げかけるにしても、その回答についてはWebフォームに投入してもらう方が良い。
宴会の幹事をやった気分になって頂けば良い。全員からバラバラと返事が来ても困る…。
例えば「100人を相手にしたコミュニケーション」を考える。最初の質問は同報メールで全員に投げかけるにしても、その回答についてはWebフォームに投入してもらう方が良い。
宴会の幹事をやった気分になって頂けば良い。全員からバラバラと返事が来ても困る…。
残業/休日出勤の申請ってメンドウ。申請書のほとんどが『事後申請』のアリサマ。と言うか督促しないと出てこない人、多数。これでは月次の給与計算に手間 がかかって仕方が無い。本来的には『事前申請』のインセンティブを与えたい所だが、せめて督促せずとも『事後申請』が出てくるような環境にしたい。
さて。上司が怒る・・・。経理がクレームを言う・・・。他人に申請してもらう・・・。うーむ、いずれも現実味が無い。
さて。上司が怒る・・・。経理がクレームを言う・・・。他人に申請してもらう・・・。うーむ、いずれも現実味が無い。
社内情報システムのアカウント発行は丁寧に行いたい。何より綺麗に記録に残したい。
そんな時にも、ワークフローの出番だ。
データ項目設計は悩ましい所だが、「グループウェア、ERP、CRM」の3システムを運用しているケースであれば「G-ID(text)、G-仮パスワード(text)、E-ID(text)、E-仮パスワード(text)、C-ID(text)、C-仮パスワード(text)」の6項目で管理しよう。複数の申請を同時に受け付ける事もできる。
そんな時にも、ワークフローの出番だ。
データ項目設計は悩ましい所だが、「グループウェア、ERP、CRM」の3システムを運用しているケースであれば「G-ID(text)、G-仮パスワード(text)、E-ID(text)、E-仮パスワード(text)、C-ID(text)、C-仮パスワード(text)」の6項目で管理しよう。複数の申請を同時に受け付ける事もできる。
「あ、その原稿なら、オレ、書いておくよ」 そして、あの原稿は今…?
「書く」と一度口に出したなら、原稿タイトルだけでも宣言しておいてもらいたいものだ。(タスク『1.原稿概要』で宣言)
レビューを依頼するパターンであれば、タスク『2.原稿完成』でレビューを依頼する人を指名する。
「書く」と一度口に出したなら、原稿タイトルだけでも宣言しておいてもらいたいものだ。(タスク『1.原稿概要』で宣言)
レビューを依頼するパターンであれば、タスク『2.原稿完成』でレビューを依頼する人を指名する。
「リマインダメールをモレなく送信するワークフロー」。
なるほど、「見学会」や「試乗会」への申込者様が、忘れずに参加して頂ける様に『前日などにメールを再送する』のは良いサービスだ。
ただ、どこの世の中でも「例外」と言うモノが存在する。どうしてもイベントに来れなくなったお客様、何かノッピキならない事情で御礼メールすら送れなくなったお客様…。
なるほど、「見学会」や「試乗会」への申込者様が、忘れずに参加して頂ける様に『前日などにメールを再送する』のは良いサービスだ。
ただ、どこの世の中でも「例外」と言うモノが存在する。どうしてもイベントに来れなくなったお客様、何かノッピキならない事情で御礼メールすら送れなくなったお客様…。
「『業務フロー定義』は改善し続けなければならない」 (それは分かる)
「でも、ナカナカ変えられない」 (ガンバレ)
荷が重い、気が重い、メンドウ、今のままでも何とかなる…。そう言う仕事は「締切」を決める事が大切。アパレル業界も、ケータイ業界も、(ソフトウェア業界も?)、「2011年モデルは何か?」を決める前に、「2011年モデルの発売日」が先に決まっているから仕事が完了するのだ。
ワークフロー定義(プロセスモデル)も、定義名やカテゴリ名で「2011年第1四半期モデル」と決めておけば、1月1日までにキット完成する。(!?)
(ルーティーンは強し)
「でも、ナカナカ変えられない」 (ガンバレ)
荷が重い、気が重い、メンドウ、今のままでも何とかなる…。そう言う仕事は「締切」を決める事が大切。アパレル業界も、ケータイ業界も、(ソフトウェア業界も?)、「2011年モデルは何か?」を決める前に、「2011年モデルの発売日」が先に決まっているから仕事が完了するのだ。
ワークフロー定義(プロセスモデル)も、定義名やカテゴリ名で「2011年第1四半期モデル」と決めておけば、1月1日までにキット完成する。(!?)
(ルーティーンは強し)
携帯電話、ハンディーターミナル、複合機、センサー、各種事務機器…。
営業事務さんは「ウチは図書館ぢゃないんだ!」、と叫ぶものの「実機貸出」の状況って、営業のみんなが知りたい情報。
実機の個体数が少ないケースなら、「カレンダーの設備予約」で管理している会社も多いが、その場合、≪返却された事を確認するスベ≫がない。
営業事務さんは「ウチは図書館ぢゃないんだ!」、と叫ぶものの「実機貸出」の状況って、営業のみんなが知りたい情報。
実機の個体数が少ないケースなら、「カレンダーの設備予約」で管理している会社も多いが、その場合、≪返却された事を確認するスベ≫がない。
展示会、学会、セミナー。
「イベント参加レポート」なんてメンドウなだけ。何かに役立っている気がしない。メーリングリストで共有しても、みんな忘れるし。
ただ…もし、過去に同じイベントに参加した人のレポートを「気軽に参照」できるのなら、イベント参加前に閲覧するだろう。「どうやって行ったのか(交通手段)」、「行く意味があったのか」など、ちょっとした情報でも有り難い。組織として簡単なメモでも良いので「イベント参加レポート」を蓄積して行く事に大きな意義がある。
「イベント参加レポート」なんてメンドウなだけ。何かに役立っている気がしない。メーリングリストで共有しても、みんな忘れるし。
ただ…もし、過去に同じイベントに参加した人のレポートを「気軽に参照」できるのなら、イベント参加前に閲覧するだろう。「どうやって行ったのか(交通手段)」、「行く意味があったのか」など、ちょっとした情報でも有り難い。組織として簡単なメモでも良いので「イベント参加レポート」を蓄積して行く事に大きな意義がある。
マンションや車の販売店は、あの手この手の「キャンペーン企画」を考えている。
「見学会」や「試乗会」なんて良くある話。その申込を如何に効率よく受け付け、イベント当日にちゃんと来させる事ができるか? 事務作業のミスやモレをゼロに!
すなわち、メール送信先を間違える事だけは避けたい。ただ、一人ひとりの参加者に対して、キッチリとメール文章を書きたい。
「見学会」や「試乗会」なんて良くある話。その申込を如何に効率よく受け付け、イベント当日にちゃんと来させる事ができるか? 事務作業のミスやモレをゼロに!
すなわち、メール送信先を間違える事だけは避けたい。ただ、一人ひとりの参加者に対して、キッチリとメール文章を書きたい。
いまどき「新卒採用のインターネット活用」なんて当たり前。「自己PR」や「入社したら何がしたいか?」等、お決まりの質問もWebフォーム入力だし、「資格」の欄はチェックボックス式ですよ、お父さん!・・・(誰?)
とは言っても「採用までのプロセス」は本当に多種多様。100社あれば100通り。採用人数や業種によっても全く異なる。以下は「エントリ数想定:500 人」「採用予定:20人」の採用プロセス例だが、この会社では「書類選考合格者100人のエントリーデータ」を面接前に各部門長に全て評価してもらい、そこでの高評価者がグループ面接(一次面接)で集中しない様にグループ分けを行っている。(400人に書類選考での不合格通知!)
とは言っても「採用までのプロセス」は本当に多種多様。100社あれば100通り。採用人数や業種によっても全く異なる。以下は「エントリ数想定:500 人」「採用予定:20人」の採用プロセス例だが、この会社では「書類選考合格者100人のエントリーデータ」を面接前に各部門長に全て評価してもらい、そこでの高評価者がグループ面接(一次面接)で集中しない様にグループ分けを行っている。(400人に書類選考での不合格通知!)
『ファイル管理』を中心機能とするシステムにも、簡易なドキュメントワークフロー機能が付いている場合がある。気楽にレビューしてもらえるのは便利。それ に慣れていると、「流れ定義」にこだわるBPMS(業務プロセス管理システム)でファイル回覧するのは、ちょっとメンドウに感じる事も。
しかし、 もし既に回覧文化が組織にあるなら、汎用的な回覧プロセスを定義しておく事をオススメしたい。一週間もすれば「どの様な類のドキュメントが社内を回覧して いるのか?」が見えて来る。すなわち「管理すべき業務プロセス」が見えてくるのだ。(最初は「滞留の可視化」や「所要時間の計測」と言ったムツカシイ事は 意識しない)
イマドキのワークフローシステムやBPMSであれば、ループ設定や分岐設定が簡単にできるし、ファイル添付やチャットも可能だ。
しかし、 もし既に回覧文化が組織にあるなら、汎用的な回覧プロセスを定義しておく事をオススメしたい。一週間もすれば「どの様な類のドキュメントが社内を回覧して いるのか?」が見えて来る。すなわち「管理すべき業務プロセス」が見えてくるのだ。(最初は「滞留の可視化」や「所要時間の計測」と言ったムツカシイ事は 意識しない)
イマドキのワークフローシステムやBPMSであれば、ループ設定や分岐設定が簡単にできるし、ファイル添付やチャットも可能だ。
『1名様に世界一周旅行をプレゼント』の抽選なら、風車型の抽選マシーンを回して、大勢の面前でワイワイ楽しい抽選会を実施する。でも『100名様にiPadをプレゼント』となれば、そうも行かない。
まずは「厳正なる抽選」である事を、誰にでも説明できる様にしておきたい。例えば「コンピュータで自動抽選」と説明したところで、やはり「転記ミスはないの?」「2~3人で密室処理してたりしない?」など、小市民は何かと質問したくなる。
出来る事なら「社内不正の発生確率が低い」あるいは「ミスや手戻りが発生しない」、そんな業務手順を考えたい。
まずは「厳正なる抽選」である事を、誰にでも説明できる様にしておきたい。例えば「コンピュータで自動抽選」と説明したところで、やはり「転記ミスはないの?」「2~3人で密室処理してたりしない?」など、小市民は何かと質問したくなる。
出来る事なら「社内不正の発生確率が低い」あるいは「ミスや手戻りが発生しない」、そんな業務手順を考えたい。
「≪一人で完結する業務プロセス≫もタスク種に分割して管理したい」なんて言う人は極めてまれだ。そんなのメーラの「スターマーク(★印)」で代用すればよい。
あえて言えば、スターマーク(★印)の on/off だけでは管理しきれない「3ステップや4ステップから構成される業務プロセス」であれば、まぁ、ワークフローシステムで管理しても良いとは思う…。今回紹介する事例は「お悩み相談室」を一人で運営している方の業務プロセス。
最初に入力されるデータは『氏名・メールアドレス(必須)・電話番号・質問文』で、最終的に『回答文』がメール送信される。気になる案件はメール送信後、電話などでフォローする。実際は、Webフォームから入力された情報を見て、スグに回答して終了するケース(「1.問合内容確認(回答文を書く)」→「通常終了」)もあれば、一旦、優先度や締切日を設定し後日回答するケース(「1.問合内容確認」→「2.回答文入力」→「3.フォロー」→「フォロー終了」)もある。
あえて言えば、スターマーク(★印)の on/off だけでは管理しきれない「3ステップや4ステップから構成される業務プロセス」であれば、まぁ、ワークフローシステムで管理しても良いとは思う…。今回紹介する事例は「お悩み相談室」を一人で運営している方の業務プロセス。
最初に入力されるデータは『氏名・メールアドレス(必須)・電話番号・質問文』で、最終的に『回答文』がメール送信される。気になる案件はメール送信後、電話などでフォローする。実際は、Webフォームから入力された情報を見て、スグに回答して終了するケース(「1.問合内容確認(回答文を書く)」→「通常終了」)もあれば、一旦、優先度や締切日を設定し後日回答するケース(「1.問合内容確認」→「2.回答文入力」→「3.フォロー」→「フォロー終了」)もある。
登録:
投稿
(
Atom
)