調達(購買)の申請ワークフローについては『オフィス用品の総務購買ワークフローも工夫が必要』を例示した。と、なれば、その後の納入検収のステップも一元的に管理しておきたい、と思うのが人情というものだ。つまり「購買申請ワークフロー」と「検収ワークフロー」を合体させたい。(もちろん「紙管理」を含めて、別システムで管理される場合はある)

ちなみに「どの『調達申請』が納品待ち状態なのか」を誰でも把握できる事の意味は大きい。すなわち、例えば「トナー切れ」を発見した時に「既に他の誰かが申請して、今は納入前?」を調べる事が出来る。



申請系ワークフロー(ビジネスプロセス)として頻出の『調達購買』は、「支出総額の抑止」が大きなテーマ。

まずは「小さな支出」の削減の積み重ねが大切だが、その為にも「購買一元化」と「交渉力強化」を推進したい(SRM: Supplier Relationship Management の王道)。
すなわち各部署からの申請は、極力「商品名」に対して必要数量(希望数)を申請してもらう形で行ってもらいたい。以下の例では、プリンタ用紙やトナーなどの消耗品から、ソフトライセンス、チラシやカタログなどの販促ツール等まで、幅広い調達業務が想定されている。



決裁者を指名して立替金申請するワークフローは『立替金申請のワークフローは、新入社員にも分かりやすく!』のエントリで例示した。

しかし≪申請した社員≫の気持ちになって考えるに、「オレの立替金申請は、ちゃんと受理されたのだろうか??」だ。そこで決裁と経理確認が済んだ時点で自動的にメールされる仕組みを組み込んでおきたい。
(フロー最下流に「メッセージ送信中間イベント(Email)」)

「立替金申請フロー」は申請系ワークフロー(ビジネスプロセス)の中でも4大アプリケーションの一つだ。
※ 立替金精算(旅費経費)、人事労務(勤怠)、調達購買、稟議

スムーズな業務処理の為には「入力フォームの注意書きの分かり易さ」が欠かせない。業務フローの「流れ方」を工夫するよりもよほど効果がある。「申請者想定は社員全員」など利用者が大人数の場合には、ナオサラだ。


「ビジネスプロセス改善事例!」だの、「実践ワークフロー改善!」だの・・・、近年BPM関連のセミナーやイベントが急増している。
そこで語られる事例の多くは「組織外部からのリクエストに対応するプロセス」に類するものだ。やはり『見積書対応』や『問い合わせ対応』などの顧客へのレスポンス改善は、売上に直結するプロセスであり、どの企業もモチベーションが高い。

さて「特定のタスク群」(プロセスモデル)の対応時間を計測したい場合、あえて単純なプロセスモデルとして独立させ、そこを通過する所用時間を計測したくな る。そんな場合、前後のタスク群(プロセスモデル)とは、メッセージ送信中間イベント等でプロセスモデル同士を接続するのが良い。


新入社員を「受け入れる際」の一連のタスクをモレ無く実施するビジネスプロセスを定義したが、「社員退職の際」の一連のタスクについてもサンプルを例示しておこう。
※参考:『新人さんが入社した時に実施すべき一連の手続き

入社手続きの場合は『人事部』が起点となってワークフローが開始されたが、退職手続きの場合は、その事実を最初に把握する(であろう)『所属部長』が起点となるべきだ。


新人社員を迎える際には「決まった手続き」がある。

カードキーを発行したり、名刺を作成したり、アカウントを発行したり。もちろん会社によっては他にも様々な手続きがあるだろう。そんな一連の手続きをヌケ・モレが無くこなす事は意外と難しい。そんな場合に「分岐機能があるワークフロー」は便利だ。


『ToDoリスト (Tasks)』と呼ばれる「自分用の仕事メモ」を活用する人は多い。
Gmailメニューにも『連絡先 (Contacts)』にあわせて『ToDoリスト (Tasks)』が標準で用意されている。もちろん『ToDoリスト (Tasks)』はGoogle Calendarにも表示される。(『ワークリスト (Worklist)』と呼ばれる場合もある)

今回は、BPMSやワークフロー内で自分の『ToDoリスト (Tasks)』を管理する方法を提案したい。そうすると、他のワークフローのタスクと一緒に管理できるだけでなく、締切日を管理したり、途中作業のログを記録したり、参考ファイルを添付したり、更には同僚に閲覧権限を与えて見えるようにしたり…、と『ToDoリスト (Tasks)』には出来ない色々な事ができる様になる。


個別の顧客に対して、提案活動とその後の電話フォローをモレなく実施したい。もちろん専用のSFAシステムを導入して『リード管理』をしても良いのだが、コストをかけずBPMワークフローシステム内で構築したい。

以下の事例は、「セールス担当が提案書雛型に対して大きな編集をしない」を想定しつつ、その後の「提案ステップ」を着実にこなすワークフロー。


「外出の多いセールスマン」や「在宅勤務者(テレワーカ)」にとって SaaS 型の業務システムは『ワークプレイス』だ。

彼らのビジネスプロセス(ワークフロー)を整理し続け、組織全体の生産性向上を図りたい。
必ず同僚レビューを受ける形の『セールス品質を高める提案書作成フロー』では、「レビュー」と言うステップ(タスク)で停滞しがちだ。それでも誰かのレビューを受けられるようにしたい。

「営業マンが提出する提案書品質が上がらない…」 そんな悩みを持つセールスマネージャは少なくない。さて、ヒトが悪いのか?、業務プロセスが悪いのか?

単純な話、『過去のベスト提案書』をブラッシュアップし続ければ、確実に『ベスト提案書』ができあがる。セールスチーム全体で「提案書作成業務フロー」を遵守して作成すれば、相互助言が実現できるだけでなく、成果物としての提案書が様々なコメント付きでデータベース化される。(再利用性向上=組織力)


ソフトウェアや情報システムの開発では「テスト工程」がつきもの。「要件と一致しているか」を確認するだけでなく、その確認行為を記録しておくことが大切だ。

機械テストを多用する事になるのだが、最後は人間によってレポートされる必要がある。以下の例は、一つの「テスト仕様書」に対して、二人のテスタが「テスト報告書」を完成させる業務フローだ。


請求書発行の遅延やモレを防止すべく、経理部門がToDoタスクを追加しておくワークフローは昨日紹介した。(『請求書発行フローは、部署横断に助け合うべきワークフロー』
このワークフロー例は「人間系タスク」の集合としての「請求書発行プロセス」になっている。

システム連携による「機械的な業務処理」を目指す事で、更に請求書発行の遅延やモレを防ぐ事ができる。すなわち『0.請求書発行指示』を「自動化」する事を考えたい。


請求書の「発行遅延」は、かなりイケてない。
請求書の「発行モレ」は、究極にイケてない。
組織にあわせた請求書発行プロセスを模索し続け、「遅延」や「モレ」を撲滅したい。

そもそも「請求書発行プロセス」は、どの部署から開始されるべきか、会社によって異なる。すなわち『顧客に対峙しているセールス部門』、『完成納入を把握し ている業務部門(製造部門)』、『受注を把握している経理部門』のいずれも考えられる。以下の例は、業務部門(製造部門)自身が(完成納入後に)請求書発行を開始するワークフローサンプルだ。


どれだけ周到な準備やテストをしていても、Webサイトを新規公開する瞬間は緊張が走る。
現実問題として「テスト運用環境」と「本番運用環境」を100%完全に同じ条件にする事は不可能であり、公開してみて初めて発覚する『不具合』もある。
大切なことは『不具合』の発生時に、着手優先順位を付け、しかるべき手順で、冷静に対応する事だ。


受託事業において『検収報告書の獲得』は最優先事項だ。Webサイト制作にせよ、システム制作にせよ、『検収報告書』をもらう為に頑張ると言っても過言ではない。

プロジェクト全体では、『企業間プロジェクトにおける仕様書確定プロセス』で紹介したように、最終的に『検収完了』のステータスに持っていく必要がある。しかし多くのケースで、すんなり『検収完了』になる事はない。
すなわち納品物に対して「修正要望」が出てくる。それが2〜3箇所なのか、10箇所なのか、50箇所なのか…。いずれにせよ一つ一つの「修正要望」をキッチリと把握し、消し込んでいく必要がある。


ワークフローは『企業内に閉じたもの』と思いがち。ただ、「頻繁に発生する定型の業務」は企業内に限った事ではない。

例えば「仕様書」の『企業間やり取り』をメールで行うと、やり取りしている当事者同士ですら、結局どれが「最終的に確定した仕様書」なのか分からなくなる。このようなケースでは、『企業間やり取り』を可視化し、その進捗を委託側・受託側それぞれの多数関係者がいつでも確認できる様にしたい。
(そもそもメールやり取りは、会社記録に残らない可能性があるので避けたい)

以下の業務フローは、両社権限者の仕様書策定活動(と仕様書修正活動)をオープンに進捗させるためのフレームと言える。
(「SaaSワークフロー」であればプロジェクト期間中だけの利用も出来て便利)


企業セミナーや出展イベントを行う場合、事前申込者に対して、1か月前/1週間前/直前…と案内メールを送る。『Pushメール』とも呼ばれる。
≪口コミ集客≫ 「ちゃんと来てね」、「友達にも紹介してね」、「ナンなら連れてきてね」…。
≪事前再告知≫ 「こんなコトするよ」、「あんなコトもするよ」、「こんなURLも見といて」…。

その回数や文面は各企業の『ノウハウ』だ。取扱商品やサービスによっても全く異なるだろう。過去にも『リマインダメールをモレなく送信するワークフロー』や『「イレギュラーな事態」の発生件数を計測しよう』で「マンションの見学会」や「自動車ディーラーの試乗会」の例を紹介した。


「GoogleDocs の SpreadSheet Form」 と Workflow の連動ニーズは極めて多い。『顧客情報の管理』から『社内宴会の出欠管理』まで、様々なデータ収集フォームを簡単に作成できるからだ。

例えば「100人を相手にしたコミュニケーション」を考える。最初の質問は同報メールで全員に投げかけるにしても、その回答についてはWebフォームに投入してもらう方が良い。
宴会の幹事をやった気分になって頂けば良い。全員からバラバラと返事が来ても困る…。


残業/休日出勤の申請ってメンドウ。申請書のほとんどが『事後申請』のアリサマ。と言うか督促しないと出てこない人、多数。これでは月次の給与計算に手間 がかかって仕方が無い。本来的には『事前申請』のインセンティブを与えたい所だが、せめて督促せずとも『事後申請』が出てくるような環境にしたい。

さて。上司が怒る・・・。経理がクレームを言う・・・。他人に申請してもらう・・・。うーむ、いずれも現実味が無い。


社内情報システムのアカウント発行は丁寧に行いたい。何より綺麗に記録に残したい。
そんな時にも、ワークフローの出番だ。

データ項目設計は悩ましい所だが、「グループウェア、ERP、CRM」の3システムを運用しているケースであれば「G-ID(text)、G-仮パスワード(text)、E-ID(text)、E-仮パスワード(text)、C-ID(text)、C-仮パスワード(text)」の6項目で管理しよう。複数の申請を同時に受け付ける事もできる。


「あ、その原稿なら、オレ、書いておくよ」 そして、あの原稿は今…?
「書く」と一度口に出したなら、原稿タイトルだけでも宣言しておいてもらいたいものだ。(タスク『1.原稿概要』で宣言)

レビューを依頼するパターンであれば、タスク『2.原稿完成』でレビューを依頼する人を指名する。


リマインダメールをモレなく送信するワークフロー」。
なるほど、「見学会」や「試乗会」への申込者様が、忘れずに参加して頂ける様に『前日などにメールを再送する』のは良いサービスだ。

ただ、どこの世の中でも「例外」と言うモノが存在する。どうしてもイベントに来れなくなったお客様、何かノッピキならない事情で御礼メールすら送れなくなったお客様…。


「『業務フロー定義』は改善し続けなければならない」 (それは分かる)
「でも、ナカナカ変えられない」 (ガンバレ)

荷が重い、気が重い、メンドウ、今のままでも何とかなる…。そう言う仕事は「締切」を決める事が大切。アパレル業界も、ケータイ業界も、(ソフトウェア業界も?)、「2011年モデルは何か?」を決める前に、「2011年モデルの発売日」が先に決まっているから仕事が完了するのだ。
ワークフロー定義(プロセスモデル)も、定義名やカテゴリ名で「2011年第1四半期モデル」と決めておけば、1月1日までにキット完成する。(!?)
 (ルーティーンは強し)


携帯電話、ハンディーターミナル、複合機、センサー、各種事務機器…。
営業事務さんは「ウチは図書館ぢゃないんだ!」、と叫ぶものの「実機貸出」の状況って、営業のみんなが知りたい情報。

実機の個体数が少ないケースなら、「カレンダーの設備予約」で管理している会社も多いが、その場合、≪返却された事を確認するスベ≫がない。


展示会、学会、セミナー。
「イベント参加レポート」なんてメンドウなだけ。何かに役立っている気がしない。メーリングリストで共有しても、みんな忘れるし。

ただ…もし、過去に同じイベントに参加した人のレポートを「気軽に参照」できるのなら、イベント参加前に閲覧するだろう。「どうやって行ったのか(交通手段)」、「行く意味があったのか」など、ちょっとした情報でも有り難い。組織として簡単なメモでも良いので「イベント参加レポート」を蓄積して行く事に大きな意義がある。


マンションや車の販売店は、あの手この手の「キャンペーン企画」を考えている。
「見学会」や「試乗会」なんて良くある話。その申込を如何に効率よく受け付け、イベント当日にちゃんと来させる事ができるか? 事務作業のミスやモレをゼロに!
すなわち、メール送信先を間違える事だけは避けたい。ただ、一人ひとりの参加者に対して、キッチリとメール文章を書きたい。


いまどき「新卒採用のインターネット活用」なんて当たり前。「自己PR」や「入社したら何がしたいか?」等、お決まりの質問もWebフォーム入力だし、「資格」の欄はチェックボックス式ですよ、お父さん!・・・(誰?)

とは言っても「採用までのプロセス」は本当に多種多様。100社あれば100通り。採用人数や業種によっても全く異なる。以下は「エントリ数想定:500 人」「採用予定:20人」の採用プロセス例だが、この会社では「書類選考合格者100人のエントリーデータ」を面接前に各部門長に全て評価してもらい、そこでの高評価者がグループ面接(一次面接)で集中しない様にグループ分けを行っている。(400人に書類選考での不合格通知!)


『ファイル管理』を中心機能とするシステムにも、簡易なドキュメントワークフロー機能が付いている場合がある。気楽にレビューしてもらえるのは便利。それ に慣れていると、「流れ定義」にこだわるBPMS(業務プロセス管理システム)でファイル回覧するのは、ちょっとメンドウに感じる事も。

しかし、 もし既に回覧文化が組織にあるなら、汎用的な回覧プロセスを定義しておく事をオススメしたい。一週間もすれば「どの様な類のドキュメントが社内を回覧して いるのか?」が見えて来る。すなわち「管理すべき業務プロセス」が見えてくるのだ。(最初は「滞留の可視化」や「所要時間の計測」と言ったムツカシイ事は 意識しない)

イマドキのワークフローシステムやBPMSであれば、ループ設定や分岐設定が簡単にできるし、ファイル添付やチャットも可能だ。



『1名様に世界一周旅行をプレゼント』の抽選なら、風車型の抽選マシーンを回して、大勢の面前でワイワイ楽しい抽選会を実施する。でも『100名様にiPadをプレゼント』となれば、そうも行かない。

まずは「厳正なる抽選」である事を、誰にでも説明できる様にしておきたい。例えば「コンピュータで自動抽選」と説明したところで、やはり「転記ミスはないの?」「2~3人で密室処理してたりしない?」など、小市民は何かと質問したくなる。
出来る事なら「社内不正の発生確率が低い」あるいは「ミスや手戻りが発生しない」、そんな業務手順を考えたい。


「≪一人で完結する業務プロセス≫もタスク種に分割して管理したい」なんて言う人は極めてまれだ。そんなのメーラの「スターマーク(★印)」で代用すればよい。
あえて言えば、スターマーク(★印)の on/off だけでは管理しきれない「3ステップや4ステップから構成される業務プロセス」であれば、まぁ、ワークフローシステムで管理しても良いとは思う…。今回紹介する事例は「お悩み相談室」を一人で運営している方の業務プロセス。

最初に入力されるデータは『氏名・メールアドレス(必須)・電話番号・質問文』で、最終的に『回答文』がメール送信される。気になる案件はメール送信後、電話などでフォローする。実際は、Webフォームから入力された情報を見て、スグに回答して終了するケース(「1.問合内容確認(回答文を書く)」→「通常終了」)もあれば、一旦、優先度や締切日を設定し後日回答するケース(「1.問合内容確認」→「2.回答文入力」→「3.フォロー」→「フォロー終了」)もある。


「『翻訳フローは役割が明確だから定義しやすいね』良く分かりました。でも、ウチでは3カ国語に翻訳してるんです…」(アイ、スイマセン)
まず、多言語への翻訳は、同時(パラレル)に行うべきか、順番(シーケンシャル)に行うべきか、が悩ましい。「英語⇒日本語、英語⇒スペイン語、英語⇒中国語」の3業務であれば、同時に走らせるのだろう。すなわち、およそ用語に「揺らぎ」は出ない。


「翻訳フロー」って、ちょっと地味だがワークフロー化すると効果テキメン。
普通の業務フローと違って『役割』が明確で、設計も改善もしやすい。在宅勤務スタッフや外部委託先スタッフのタスクも把握しやすい。
業務フロー設計において「役割分担がダイジだ」とは、Questetraの著作物『ビジネスプロセスモデリングの鉄則』の第3話にも書いてある!

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

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

「BPMって、何から着手すべき?」
超FAQながら、ナカナカ難しい。「そりゃ会社によって違うよ」「貴方の会社のボトルネックから!」な~んて答えたくなるが、それぢゃー質問している人の期待を裏切る事になる。

あえて断言すれば、『A:組織外部からの何らかの問い合わせに返答するフロー』と『B:注文入力に始まる製品サービスを提供する手続き』だ。今日はA系の「資料請求対応」の事例を紹介したい。

スーパーコンピュータ、誰でも使えるわけではない。限られた利用者が「適切な申請」を経て「一定期間」だけ使う。ただ「アカウント作ったので、勝手に利用しておいてください」と言うわけにもいかない。それぞれの『利用者』につき『サポート担当』が付いて、様々な支援を行う。

以下のワークフローは、ある意味で「セールス」でもある『サポート担当』の業務を整理したものだ。すなわち、利用者の利用日程等を出来るだけ早く確認し、利用申請に迅速に対応する。「見積書~発注」の流れにも近い。

「クレームなんて、来ないよ」(言ってみたい)
「クレーム?、沢山きますよ」(自慢するな)

しかしクレームは『製品やサービスの改善チャンス』だ。きっちりと記録し『個々の原因分析』や『全体の俯瞰した分析』につなげたい。いまどきであればWebフォームを用意して、いつでも、誰からでも、受け付けられる仕組みを用意し、かつクイックレスポンスを目指したい。
Webフォームは Google Docs Form で構築し、自動起票されたクレームをワークフローで対処しよう。


記事、論文、ニュース配信…。
何度も何度も書き直しが発生するライター稼業。ナンギな商売だ。二カ国語発表、しかも原文も訳文もダブルチェック体制ともなると、かなりナンギ。


『事後承認』って何とも複雑な言葉。もし『承認』されなかったらドウするの?
もし権限が移譲されているなら『事後承認』なんて言葉はイラナイ。あれ…? そもそも権限が移譲されていないのに、ナンデ承認する意味があるの?(愚痴ってみる)
ほとんど用無しの『事前の承認』はコンナ感じか。(現実には良くあるワークフロー)



キャンペーン企画がまとまって来た。斬新なアイデアが満載。マーケティングチーム、渾身の自信企画だ。
「あ、この稟議書って、セールスチームの合意も必要でしょ・・・」

意外な話だが『承認部署の柔軟な追加や変更』を許容する業務フロー定義は難しい。


組織として良いアイデアをコンスタントに生み出すには、どうしたら良いのだろうか?

そもそも「思い浮かんだアイデア」の大多数は大したこと無い。アイデア達の多くは、進化論的に淘汰されるべきだ。(ジェノサイド!)

こんな時には、あえて「プロセスを滞留させる事」を前提にしたワークフローも考えられる。つまり『アイデアの概要』を沢山書きためておき(ネタ帳?)、多数のアイデア概要の内で、「もっとも良いアイデア/タイムリーなアイデア」を詳細化して行くワークフローだ。


「Blog や Twitter で情報発信したい。でも、原稿のチェックは、しっかり行いたいな」 そんな会社さんは非常に多い。
最近「ワークフローシステム(※)で承認された原稿」を Blog や Twitter へ自動投稿する仕組みが、ちょっとしたブームだ。

つまり「Blog や Twitter のメールで投稿できる仕組み」と「プロセスのデータを『メール送出』できるワークフローシステム」(※)を連携させるわけだ。(メール送信部分が、システム連携のツボ)

※ 『メッセージ送信中間イベント』(BPMN用語)が実装されているワークフローシステム: Questetra BPM Suite 等



「プリンタのトナーが切れた…、けど、見なかった事にしよう」
貴方もこれまでに4回位(?)は見なかった事にしたハズだ。(決めつけ)。それでも、心ある誰かが予備トナーと交換し総務に報告してくれる。(助け合い??)

総務としては、効率良く情報を集めて、効率良く外部発注したい。トナーに限らず、蛍光灯/ホワイトボードのペン/伝票といった共用のモノから、名刺や作業服といった個人が占有してしまうモノまで、ホントに多種多様な発注をしているのだ。
目立たない作業だが、結構タイヘンなのだ。



『休暇申請フロー』は意外と奥が深い。
それが単なる有給休暇なのか、バケーションなのか、長期療養の休暇なのか、育児休暇なのか…、入力項目や回付ルートが違う。忌引休暇であれば、会社として何らかのアクションが必要かもしれない。ま、いずれにせよ、まずは「無駄なやり取り」を減らすために、

  • 申請フォームには『出来るだけ親切な注意書き』を明記しておくこと
  • 『汎用的な申請フォーム』にしておくこと

に注力したい。


「人間は受け身な存在である」(哲学?!)
『組織の外から仕事が飛んでくる仕組み』があれば、その対処の組織内プロセスは日々改善される。あえて難解に言えば(??)、『外部システムからのプロセス起動』こそが『組織の外部環境適合進化』を促進するのだ。(社外、部外、チーム外、隣人…)

これは Google Docs の Spreadsheet Form に入力された問い合わせ(仕事)が、自動的に流れるワークフローだ。途中の分岐は、どうしても経理部門に聞かなければ分からない事を聞くための分岐になっている。

『タスクのパスワーク、司令塔が居ればミンナが楽になる?』の第2定義は「指示度が高い業務フロー」だ。「リーダーシップ理論」(SL理論)に照らし合わせるまでもなく、組織の成熟に支障をきたしかねない。最悪ケースでは、問い合わせ回答を量産しつつも、同時に『指示待ち族』を量産しかねない。(ちょっと心配性)

「見えている仕事」が10個なら10個しか処理しないが、もし20個来たら20個やってしまう。そんなもんだ。

ところで、割り当てられたらやるけど、自分から積極的に引き受けるのは気が引ける・・・なんて考える人が増えた場合、例えば『日々進化する問い合わせ回答ワークフロー』の「未回答状態の問い合わせ」は増加の一途をたどる。