プロセスオーナー(リーダ)は、ワークフローを運用に乗せるために、自らも汗をかくべきだ。「ワークフロー定義を済ませたらオシマイ」では、スムーズに業務が回るはずもない。

以下の例では、プロセスオーナー自身が秀逸文をFAQサイトに投稿する。カスタマーサービスのメンバは、質問回答文を書く際に参照する。運用していれば徐々にレスポンスタイムが短縮していくだろう。「今月は平均10時間以内に! 来月は平均8時間以内に!」と言ったカイゼン目標を部署全体で共有するのも良い。

(関連)
ワークフローで問い合わせへのレスポンスタイムを計測
問合内容を見て回答担当者を指名するワークフロー
問い合わせの種類に応じて回答仕事の割当先が変わるフロー



一日の問い合わせ想定数が100件を超える組織は、≪問い合わせの分類分け≫を検討すべきだ。すなわち「製品Aについての質問」なのか、あるいは「製品Bについての質問」が、上流で分かっていれば対応ルートも対応者も変わってくる(かもしれない)。

以下の定義では問い合わせ者自身に≪問い合わせの種類≫を選択してもらう事を想定している。ただし、リーダタスク『2.回答担当割当』で上書きすることも可能だ。
(『ワークフローで問い合わせへのレスポンスタイムを計測』および『問合内容を見て回答担当者を指名するワークフロー』を拡張)



業務フロー定義『ワークフローで問い合わせへのレスポンスタイムを計測』は、非常にシンプルだ。確かに、「誰が、どの問い合わせに、対応中なのか?」や、「自分がすべき対応は何件残っているのか?」などは明確になる。しかし実際に「運用」をしてみると、色々と検討事項が見えてくる。

例えば、他のマーケティング業務を兼務しているスタッフ10人で『カスタマーサービス』が構成されているなら、仕事の割り振りタスク『2.回答担当割当』は≪熾烈なカケヒキの場≫となる。そのような組織では、やはり「マネージャクラスだけが行える状態」にしておく方が望ましい。すなわち、各メンバの得意不得意や負荷状態、あるいは教育観点を踏まえて、各メンバへの仕事割り振りを行うべきだ。以下の定義では、タスク『2.回答担当割当』はカスタマーサービス部のリーダにしか割り当てられない。(滞留しない様に「リーダ」は複数人で構成したい)



なお、仕事を割り当てた以上、リーダは「相談に乗る責任」がある(ような気もする)。以下の定義では、仕事を割り振られたメンバが回答に困った時に相談に乗ってもらえるワークフローになっている。



≪問い合わせ対応フロー≫は、業務フロー改善活動(BPM)の「着手のテーマ」として定番。
つまり、多くの会社で「社外からの問合に対して平均して何時間で回答できているのか?」や「どの様な問合が多いのか?それにどんな回答をしているのか?」が把握しきれていない。これらは取締役会でもよくある質問だが、得てして「次回までに調べてきます」だ。「いつでも御覧下さい!」と言える可視化環境を構築したい。

まずは準備運動(?)として、社内からの問い合わせに回答するワークフローを構築してみよう。(最初から適用範囲を大きくすると、ロクなことはない)




『原価計算のため「作業時間」を日次報告するフロー』
『原価計算のためだけの日次報告フローはつまらない』
『どうせ日次報告するなら「報告すべき情報」を全て流そう!』

ワークフローで承認されたデータは、給与計算や原価計算などに利用される。「会計ソフト」なのか「基幹システム」なのか、会社によって様々。ただ、いずれにしても「手入力での転記」は避けたい。BPMNの表記法では、データ(プロセスデータ)の外部送信を『メッセージ送信中間イベント』で想定している。



『原価計算のため「作業時間」を日次報告するフロー』
『原価計算のためだけの日次報告フローはつまらない』
「シリーズ:製造原価計算のための日次報告」と言う感じになってきた。≪製造原価≫のための日次報告をさせるなら、ついでに≪勤怠管理≫のための報告も兼ねたくなる。

上司の現実、月に一度「部下達の出勤簿」を見せられても、そこに書かれた内容が正しいかどうか分からない。すなわち日々の報告に「出勤簿に必要な情報」を追記しておきたい。以下の日次報告ワークフローでは、「出勤欠勤の選択、出勤時刻、退社時刻」の各情報も入力する。(ダイアグラムは同型)



『原価計算のため「作業時間」を日次報告するフロー』で≪作業時間≫を毎日報告するなら、ついでに≪作業内容≫も書いて、それぞれのプロマネ達にも通知される仕組みを考えたい。この手の日次ルーティーンは習慣にするまで時間がかかるが、慣れてくれば、それほどメンドウではない。むしろ一日の作業を振り返る良い機会になる。



何かを造る(創る)会社は「製造原価」の計算が付きまとう。
しかしながら「どの作業に、何時間費やしたか?」を正確に測る事は非常に難しい。特に「意匠デザイン」や「ソフトウェア開発」では、如何にスマートに各社員から報告してもらうかが大きな課題だ。(請負型ビジネスであれば≪生命線≫)

以下のワークフロー例では、毎日『作業時間の報告(タスク)』が自動で割り当てられる。BPMNでは『タイマー開始イベント』と呼ばれる。すなわち、未報告者やその未報告日は、リアルタイムに可視化される。



ボロボロの靴をみて「使えなくなった」と言うか「まだまだ使える」と言うか、人によって違う。そして固定資産に対する見解も、その感想文は人それぞれ。
そう、固定資産の管理者を2名体制にし、同じ調査を並行して行う事も良い。それほど手間や時間のかかる仕事ではない。
『IFRS関連の業務フロー整備に着手する』および『管理者が変わっていてもスムーズに流れる固定資産調査フロー』を拡張)



『IFRS関連の業務フロー整備に着手する』では、固定資産の管理状況を調査するワークフローを例示した。ただ固定資産の数が多いケースなどでは、固定資産の管理台帳に記載された管理担当(調査担当)が変わっている場合もある。このようなケースが想定される場合、あえてタスクを分割することでスムーズなワークフローを実現する方法もある。

すなわち「2.調査報告」と言う仕事(タスク)を『2a.調査開始』と『2b.調査報告』に分割し、管理台帳に記載された管理担当者が『2a.調査開始』にて、新しい管理担当者を指名する仕組みだ。



国際財務報告基準IFRS(イファース)[アイファースとも]に関連する「ワークフロー整備」は大量に存在する。特に、国際会計基準IASの「第36号:資産の減損」あたりや「第11号:工事契約」(工事進行基準)などでは、≪社員からの情報収集≫が大切だ。

以下の業務フローは「『会社の資産』が大きく減損していないか」(減損の兆候)、を定期的に確認するワークフローだ。平たく言えば「設備、ちゃんと稼働してる?」と言う定期健診。多くの社員の協力を要する。



「≪新規≫の往訪報告って、Webサイト資料請求などの≪引合対応≫がほとんどなんだよね・・・」
そんな場合には「往訪報告フロー」に自動的にデータを引き継ぎたいものだ。(言うまでもなく)、往訪するまでに『メールや電話でアポイントを入れるタスク』があるのだが、それらの上流プロセス「引合対応プロセス」で投入されたデータを引き継ぐと言うのもアリだ。



「往訪報告のワークフロー化」や「往訪記録のデータベース化」を考えるに、往訪前にある程度の入力を済ませておきたい。(『往訪直後に「1件ずつ」の往訪報告フロー』を拡張)

もっとも、Questetra BPM Suite の様に各ステップ(タスク)の部分入力を認めるワークフロー製品であれば、同一者の連続タスクはあまり意味がない。(「進捗情報の共有」と言う観点であれば分けてもよいかも)



「往訪報告」はメールで済ませる・・・。
ま…、「何も報告しない」よりはメールで報告する方が良いのだが、非常に再利用性に乏しい。何とか「集計」に使えるレベルの記録を考えたい。例えば「営業マンAは今月何件の訪問を行ったのか?」、「営業部全体で今月何件の新規訪問があったのか?」。

すなわち、往訪直後にフォーマットに従ったに入力を行うルールにすれば、極めて有意義な往訪記録データベースができあがる。ちなみに「営業日報フロー」も悪くないが、日次の報告よりも、往訪終了時の報告の方が、抜け漏れを防ぐ観点で有効だ。



『ボツになった販促企画もキッチリと記録して行きたい!』の記事では、企画書完成時(タスク『1.企画書完成』)に指名した「マーケティング担当の同僚」に企画書を事前レビューしてもらった上で、その後のマーケティング会議に提出していた。しかし現実問題とし て「マーケティング部の会議」の直前まで資料作成に没頭するケースが後を絶たない・・・。(なぜか会議には間に合う)

と言うことで、「時間がない場合には事前レビューを省略できる」と言うフローに改めたい。すなわち『1.→2.→3.→4.→5.』の流れが理想だが、『1.→3.→4.→5.』の流れを認めるというカイゼン(?)だ。



「エレベータメンテナンス」や「IT資産管理」など、点検作業を≪請け負い業務≫として行っているケースでは、当然ながら点検員も修理担当者も多数所属している。人数や制度にも依存するが、「点検仕事一覧」を見て各点検員が自主的に仕事を引き取る制度であれば、以下の様なワークフロー定義になる。すなわち『2.撮影+点検報告』を各自判断でこなして行く。
『点検ワークフローは修理ワークフローとつながるハズだ』のワークフロー定義を拡張)



マーケティング企画は、「企画書」として立案され、企画会議に提出される。
マーケティング部は次々と新しい企画を立てる。そして企画書を書き上げるタイミングは、いつも夜中だ…。(そんな貴方に『SaaS型のワークフロー』はピッタリ)



クラウドの時代「受託開発ソフトウエア業」と言う分類名称は変わっていくのかも知れない。が、「請負型のビジネス」が消えてなくなることはないだろう。そして営業マンは、見積内容を上司と相談し、見積書を作成して提出し続ける。
この『営業部内でのやり取り』を、経営陣全体がリアルタイムに把握できるようにしたい。




点検業務でNGだった場合には、≪何らかの対応≫が必要だ。
そこで、昨日紹介した『「現場での写真付点検報告」を想定した点検フロー』を拡張し、『5.修理』タスクに繋げるワークフローを定義してみたい。



各自動車、工場の各装置、あるいは消防用設備や防火対象物…。企業によっては点検業務は写真に残す。WiFiや3Gと言った無線通信インフラが加速する今日、スマートフォンなどを活用して撮ったその瞬間にワークフローを回してしまいたい。場合によっては、報告直後…まだ現場近くにいる間に「再点検の要請」を出せるかもしれない。



「内部監査業務」自体の監査結果が『指摘事項』で埋まってしまわない様に、「内部監査業務プロセス」だけは自律的にカイゼンしたい。(まさにBPM)

『監査テーマをワークフローで次々とこなす』にある様に、監査業務のアウトプットを「紙」から「デジタルファイル」にするだけでも、集計や保管において随分効率良くなる。しかし、特にチェック項目が固定化されているケースで、月間10回以上実施されるような監査なら「デジタルファイルの入力項目」を「プロセスデータ」に展開してしまう事も検討してみたい。すなわち「ファイルアップロード手間の排除」や「高度な集計分析」を目指したい。ワークフロー製品次第だが、監査ヒアリング内容をiPadなどのタブレット機で直接入力し電送できるとなれば、随分とスピード感が変わる。

=品質管理簡易チェックフロー=


業務全般・製品品質・環境影響…、企業は様々な目的で『内部監査』をする。「品質マネジメントシステム」(ISO 9001)や「環境マネジメントシステム」(ISO 14001)などは、多くの方がその影響を受けた経験があろう。最近であれば、「情報セキュリティマネジメントシステム」(ISMS/ISO 27001)だろうか。

定番のチェックリストを作るのは良いのだが、その記録を「紙」で行っていたのではスピードが出ない。何より、集計コストがかかって仕方がない。きっちりと情報システムを活用しようではないか。



論文作成に手順(プロセス)なんてない!、のかも知れない。
要は気合で締切に間に合わせれば良い!、のかも知れない。

確かに、書く人間にとっては「現状把握」は容易だが、複数人を指導する人間(教授)にとっては「どの論文がどのステータスにあるのか」なんて覚えていられない。



『ワークフロー改善を検討するワークフロー』を運用していると、運用中のワークフローに関して過去どの様な要望が上がって来たのか、いつでも把握できるようになる。しかし、ただ(受け身に得た)「カイゼン要望」を記録するだけではなく、プロセス オーナーとしての「信念をもって行ったカイゼン」も記録したい。まさに「BPM活動の記録」になる。 BPM: Business Process Management (業務プロセス管理)



ワークフローを導入運用していると、「ワークフローを変更するワークフロー」と言う話が必ず出てくる。

ビジネスプロセスモデリングの鉄則から言えば、『キッカケ』を決める事が大切だ。例えば、「カイゼンしたい!」と言う(自然発生的な)社内要望があったときに随時見直しを行うのか、毎月(プロセスオーナーが能動的に)要望を集めて見直しを行うのか、によって「ワークフローを変更するワークフロー」の定義が異なる。以下の事例は、利用者である社員が発見したカイゼン点を起点にするワークフローだ。