クレーム管理はクラウドで

社外からのクレームに対して、何時間で対応できているか？
クレーム対応の業務プロセスを、どの様に設計すべきかは会社によって異なる。少なくとも回答品質と回答時間は反比例する。クイックレスポンス・顧客満足度向上・コンシェルジュサービスなど様々な思想があるが、その設計は決して容易ではない。BPMコンサルタントの腕の見せ所だ。

ただ明確に断言できる事として、「現状を記録する事」あるいは「現状何時間で対応できているかを把握する事」は極めて重要である。把握できなければカイゼンしようがない。以下のワークフロー定義で言えば、『Webフォーム』でクレームが入力されてから『自動回答メール』が送信されるまでの時間を把握したい。

＜各タスク名＞
1.内容確認／自身回答／担当者指名、2.回答、3.承認／微修正／差戻、4.差戻対応

[クレーム対応-回答記録：「1.内容確認／自身回答／担当者指名」画面]

新入社員の書類提出状況はオンラインで管理したい

日本では、新入社員を迎える季節。
『各管理者が並行してアカウント発行するフローや 『情報システムのログインIDを効率よく発行するフロー』で情報システムのアカウント発行プロセスを紹介した。しかし、新入社員の最初の仕事はアカウントのログインパスワードを設定するだけではない。細かい話だが、自己紹介文を書いたり、雇用契約を締結したり、宣誓書を提出したり、色々な細かいタスクがある。

類似：『新人さんが入社した時に実施すべき一連の手続き』


＜各タスク名＞
1.新入社員氏名、2.必要手続確認、3a.宣誓書作成、3b.自己紹介文、3c.雇用契約署名、4a.宣誓書確認、4b.自己紹介文確認、4c.雇用契約署名確認、5.完了確認

[新入社員受入-完了メール：「1.新入社員氏名」画面]

各管理者が並行してアカウント発行するフロー

『情報システムのログインIDを効率よく発行するフロー』でアカウント発行プロセスを定義した。
ただ、全ての情報システムのアカウントを一人の情報システム担当者で発行できる訳ではない。その様な場合を想定し、以下の拡張定義を紹介したい。


＜各タスク名＞
1.ID発行申請、2.申請の承認、3.受理の判断、4abcd.ID発行完了、5.確認

[アカウント発行申請-担当別発行-質問／回答：「3.受理の判断」画面]

情報システムのログインIDを効率よく発行するフロー

４月と言えば、日本では新人受け入れの季節。社内情報システムのアカウント発行など、色々な申請処理が立て込む。一つ一つ全ての申請を「漏れ」なくこなすには、やはりワークフローシステムが有効だ。
申請者によって申請ルートを変更できる（条件分岐機能を持つ）ワークフローシステムであれば、誰でも代理申請できるので柔軟なアカウント発行申請フローを実現できる。


＜各タスク名＞
1.ID発行申請、2.申請の承認、3.受理の判断、4.ID発行完了、5.確認

[アカウント発行申請-質問／回答：「1.ID発行申請」画面]

他システムのデータ閲覧権限を制御する

『クラウド時代のデータ持ち出し管理フロー』で紹介した「アクセス権限の一時付与」と「付与したアクセス権限の解除」は、手動で行いたくない。
言うまでもなくデータファイルのアクセス権限設定変更は、データファイルが管理されているシステムに依存する。たとえば Google Apps を社内プラットフォームにしている場合、「Google Documents」側のAPIを活用する必要がある。（現状ではSEの力を借りざるを得ない）

* Google Documents List Data API v3.0 (Labs) - Modifying Document and Folder Sharing Permissions
* Google Documents List Data API v2.0 - Modifying Document Sharing Permissions


＜各タスク名＞
1.アクセス申請、2.一時的権限付与、3.不承認対応、4.活用報告、5.アクセス権限解除、6.アクセス権限解除確認

[データアクセス申請-外部システム権限変更：「4.活用報告」画面]

クラウド時代のデータ持ち出し管理フロー

「そもそも≪クラウド≫にあるデータは、≪持ち出し≫の対象か？」
クラウドコンピューティングの普及は時間の問題だ。本社、工場、コールセンター…と、ロケーションが限定されていた時代は、少々場所が離散していてもＶＰＮ技術等を使って「封じ込めて」いた。しかし、在宅勤務だ、クラウドコンピューティングだ、とさわがれる昨今「データの持ち出し議論」はゼロベースで考え直さなければなるまい。

あくまでも一意見ではあるが、≪業務効率≫（既存業務の継続性、テレワークの活用、グローバルビジネスの想定）あるいは≪巨大災害の想定≫等を勘案するに、以下の『４方針』を基軸にせざるを得ないのではなかろうか。
[1.一元化] データは≪クラウド≫にて極力一元的に管理する
[2.制御] 各データの権限者を最少人数に留め厳格な制御を行う
[3.証跡] 各データへの参照更新について全てロギングを行う
[4.教育] ローカルディスクやメディアへのデータ複製を一切禁じる（最終的には人的教育）

ここでは特に重要な機密データについて「一時的な参照権限を付与」する申請フローを紹介したい。


＜各タスク名＞
1.アクセス申請、2.一時的権限付与、3.不承認対応、4.活用報告、5.アクセス権限解除

[データアクセス申請-解除確認：「2.一時的権限付与」画面]

やむを得ず「持ち出す」時の承認フロー

情報セキュリティ管理の観点で、データやPCの「持ち出し」は制御活動の基本になる。
在宅勤務時や外出作業時にやむを得ずデータやPCを持ち出す場合には、「事前の申請」と「適切な事後処理」が重要だ。以下は、紙で行っていた「持ち出し許可申請」をオンラインワークフローで行うことを想定したワークフロー定義だ。どのPCが、どのUSBメモリが、いつ、何の用途で、誰によって持ち出されたのか、いつでも確認することが可能になる。

※「持ち出し議論」と「クラウド」の関係については、明日の記事で言及したい。


＜各タスク名＞
1.持出申請、2.持出承認、3.不承認対応、4.活用報告

[持出許可申請-事後処理確認：「2.持出承認」画面]

今こそ検討したい『在宅勤務』ワークフロー

子育、介護、地震、インフルエンザ流行、通勤疲労軽減、CO2削減、フリーデスク、経費削減、地域経済活性化…。
色々な観点から「在宅勤務」は世界中で注目されている。日本でも2003年の「eJAPAN戦略II」以降、徐々にテレワーク(Telework：和製造語)を支援する会社が増え、就労人口の2割程度になりつつある。日本では、事前に仕事内容と就労時刻を決めた上で在宅で就労するパターンが多い。（参照⇒『在宅勤務の働き方を規定するワークフロー』）

今回紹介するワークフロー定義は、汎用的な作業指示フローだ。すなわち具体的な作業指示、スケジュール調整、成果物のチェック作業を可視化する。各従業員への「明確な作業指示（割り当て）」は在宅勤務の推進にも役立つ。


＜各タスク名＞
1.仕事内容の指示、2.スケジュールの回答、3.スケジュール承認、4a.追加指示、4b.成果物登録、5.完了確認

[在宅勤務-部下作業提案：「3.スケジュール承認」画面]

在宅勤務制度を規定するワークフロー

在宅勤務（テレワーク）とクラウドコンピューティングは相性が良い。
特にワークフローシステムを『クラウド』に構築すれば、申請、決裁、報告、レビューなど、いつでも／どこでも仕事ができる。通信の高速化と端末の高性能化は、今後もより一層、自宅利用やモバイル利用を加速させるだろう。

今、日本では東日本地震に伴う電力不足で交通機関が十分に機能していない。以下で紹介するワークフロー定義『在宅勤務申請から業務報告のフロー』では、自宅で行う仕事内容を事前申告する。


＜各タスク名＞
1.仕事内容の事前申告、2.事前申告の承認、3.業務開始報告、4.業務終了報告

[在宅勤務-終了メール：「2.事前申告の承認」画面]

問合対応中に「社内助言」を求めるワークフロー

「仕事の情報をスマートに流す」ワークフローシステム（BPMシステム）にとって非常に重要な使命だ。

ただ、例えば社外からの問い合わせに回答するワークフローにおいて、自分だけでは応えられないケースは少なくない。すなわち更に他部署に聞かなければならない時がある。

問い合わせの発生件数を把握する、迅速に応える、そんな目的で導入した『検出文字列で「問い合わせ対応」のフローを変える』を更に拡張する。

＜各タスク名＞
0.受電等の問合入力、1a.緊急問合対応、1b.パスワード問合対応、1c.申請問合対応、1x.一般問合対応、2b.パスワード問合対応、2c.申請問合対応、2x.一般問合対応、3.社内助言、4.回答

[問合回答-社内助言：「1b.パスワード問合対応」画面]

問合回答のベストプラクティスを検索しやすくする

ルーティンワークは強い。
ワークフロー定義に従って「外部からの問い合わせ」を粛々と処理し続けていると、自ずと納期(Delivery)も品質(Quality)も改善してくる。キーワードはベストプラクティス管理だ。

以下のワークフロー定義では、回答文と言う成果物について、チームリーダが評価する。再利用時や教育研修時に参照しやすくなる。

＜各タスク名＞
0.受電等の問合入力、1a.緊急問合対応、1b.パスワード問合対応、1c.申請問合対応、1x.一般問合対応、2b.パスワード問合対応、2c.申請問合対応、2x.一般問合対応、3.評価

[問合回答-ML共有：「成果物共有」メール設定画面]

検出文字列で「問い合わせ対応」のフローを変える

「問い合わせ対応業務」は、件数増加時にはパンクする。そういうモノだ。ん？…そういうモノなのか？

≪問い合わせ件数≫が増加した時も、実は≪問い合わせ種類数≫を数えれば、それほど変わらない。問い合わせの種類を自動的に分類できれば、そのレスポンスタイムを大幅に短縮できる可能性が高い。

以下のワークフロー定義では、Webフォームやメールから来る問い合わせに『特定の文字列』が入力されていればフローが変わるビジネスルールを例示している。

＜各タスク名＞
0.受電等の問合入力、1a.緊急問合対応、1b.パスワード問合対応、1c.申請問合対応、1x.一般問合対応、2b.パスワード問合対応、2c.申請問合対応、2x.一般問合対応

＜関連ワークフロー定義＞

• 『問い合わせの種類に応じて回答仕事の割当先が変わるフロー』

[問合回答-自動分類：「1b.パスワード問合対応」画面]

トラブル発生時の社内情報を整理し発表するフロー

「情報を集約し、効率よく共有／発信する」は組織にとって非常に重要な機能だ。
情報を統括するチームが、仮に「上がってきた情報を全てソノママ出している」ようであれば、そんなチームに存在価値はない。むしろ存在しない方が良い。つまり「収集する・発信する」に加え、「フィルタする・補完する・整理する」と言った各機能が期待されるのだ。

さりとて、トラブル発生で社内から大量の情報が押し寄せた時に、広報窓口が十分な情報発信機能を維持し続ける事は容易ではない。

<各タスク名>
0.共有すべきかも知れない情報の登録、1a.一次確認(緊急)、1b.一次確認(通常)、2a.記事化(緊急/新規)、2a+.記事化(緊急/既存)、2b.記事化(通常/新規)、2b+.記事化(通常/既存)

[社内情報発信-IR関連情報：「1a.一次確認(緊急)」画面]

警報機器等からの自動通知に始まるワークフロー

『イザという時のための行動手順をワークフロー化』で紹介した≪被害確認から緊急事態宣言までのフロー≫ は、検知・確認を経て緊急事態判断に至るという「緊急体制整備」のための基本的な流れを紹介した。しかし、警報センサーや何らかの情報システムで検知や確認がほぼ自動化されているなら、もっと早い段階で『緊急事態判断』ができるはずだ。

関連ワークフロー）

• 『イザという時のための行動手順をワークフロー化』
• 『緊急時にチームワークを発揮するためのワークフロー定義』

<タスク名>
1.被害確認指示(＋緊急事態宣言)、2.緊急事態宣言、3.ライブ指示、3abc.着手、4abc.報告、5.報告完了確認、6.関係者招集

[緊急時行動-情報自動送信：「1.被害確認指示(＋緊急事態宣言)」画面]

イザという時のための行動手順をワークフロー化

東日本大震災(※)以降、毎日の様に大きな地震が起きている。地震・津波・原発事故などによって、日本経済は大混乱している。この１年の間、あるいはこの半年にも、回復基調に転じると信じたい。
※『平成23年東北地方太平洋沖地震』（The 2011 off the Pacific coast of Tohoku Earthquake）

今日紹介するワークフロー定義≪被害確認から緊急事態宣言までのフロー≫は、「コンティンジェンシープラン」（緊急時行動手順）と呼ばれる。緊急時の作業手順をあらかじめ想定しておき、いざという時にその手順に従い粛々と行動するためのものだ。言うまでも無いが、半年に一度程度は「訓練」をし、また必要あれば「改善」すべきだ。
ここでは『地震』等の天災に限らず『サイバー攻撃』や『風評被害』まで様々な被害を想定している。緊急事態を察知(検知)した被害確認責任者が、即座に【状況把握】を開始し、状況に応じて【関係者招集】を行う。
何時何分に確認作業が開始されたのか、何時何分に誰がどの様な判断をしたのか、全てが自動的に記録されるため、後々も参照できる。

<タスク名>
1.被害確認指示、2.開始確認、3.ライブ指示、3a.着手、4a.報告、5.報告完了確認、6.関係者招集判断、7.緊急事態宣言

[緊急時行動：「1.被害確認指示」画面]

毎朝９時に被害情報を集約する情報報告フロー

例えば、各支店の被害状況について≪効率良い情報集約≫を実現したい。そして集約された一次情報を元に、その後の対策を打ちたい。

原則論として、情報の一元化は『Google スプレッドシート（あるいはフォーム）に各自が書き込む』等の「多発信スタイル」が良い。すなわち多数が一つのリソース（ファイル）に書き込む形態によって、通信コストを軽減できる。（「どの様な入力項目を準備するか？」こそが、その効率を左右する）

以下のワークフロー定義では、毎朝9時に被害状況の報告を全社員に割り当てる。各支店の被害状況を定時に全把握できるだけでなく、全社員の安否確認にもつながる。

<タスク名>
1.状況報告、2.状況確認／再報告指示、3.再報告対応

[定時状況報告-自動起動：「1.状況報告」画面]

緊急業務指示をワークフローで流し、その進捗を可視化する

東日本大地震…。「地震」と「地震に伴う津波」により死者数は≪万単位≫に及ぶと報道されている。日本中で力を合わせて、復興していきたい。

さて、今日のワークフロー定義は『ワークフローを使った業務指示と進捗確認』を紹介したい。個別メールでの業務指示も悪くないが、≪全社で発生している全タスク≫を俯瞰しやすいBPMSは、誰が何件の仕事を抱えているのか／着手しているのか、を可視化する上で有効と言える。

[業務指示：「1.作業登録／指示」画面]

セールスステータスを管理するワークフロー

「無料サンプル」に始まるワークフローをどこまで引っ張るんだ・・・。しかし、ビジネスにおいて≪引合（リード）をどのように処理するか≫は本当に奥が深い話。

• 『試供品の受付対応システムを「ワークフロー」で構築する』
• 『試供品申込時の「通信欄」に素早く対処する』
• 『「メールアドレスを持たない方」のワークフロー分岐』
• 『試供品を届けてから10日後に電話するワークフロー』

[試供品受付対応-セールスアプローチ：「6.一時アプローチ報告」画面]

試供品を届けてから10日後に電話するワークフロー

お決まりのパターンで恐縮ながら、「無料サンプル」を届けるワークフローを、「無料サンプル」が届けてしばらく後に電話なりメールなりでアプローチするワークフロー、に拡張したい。

• 『試供品の受付対応システムを「ワークフロー」で構築する』
• 『試供品申込時の「通信欄」に素早く対処する』
• 『「メールアドレスを持たない方」のワークフロー分岐』

[試供品受付対応-引合対応：「5.セールス指示」画面]

「メールアドレスを持たない方」のワークフロー分岐

「無料サンプル」は電話でも受け付けてるんだ。。。と言う場合、『メールアドレス』を≪必須項目≫からはずしたくなる。しかし一方で、オペレーション上の≪抜け漏れ≫を防ぐために『メールアドレス』は必須項目にしておきたい、とも思う。

良くある結論としては、「運用上のルール」で
・明らかに不正なメールアドレスを入力している方、
・メールアドレスの無い方、
と同様に≪ダミーのメールアドレスを入力させる≫と言うやり方だ。それはそれで良い。ただ実際にメール送信されてしまうのは、何とも不毛だ。以下のワークフロー定義を拡張したい。

• 『試供品の受付対応システムを「ワークフロー」で構築する』
• 『試供品申込時の「通信欄」に素早く対処する』

[試供品受付対応-返信作業通知：「登録御礼メール」設定画面]

試供品申込時の「通信欄」に素早く対処する

『試供品の受付対応システムを「ワークフロー」で構築する』のワークフロー定義は、ほぼ無人の業務フローだ。
ただ『通信欄』に記入があった場合には、別途≪人間による素早い対応≫を行いたい。（人間作業とコンピュータ作業の同時並行処理）

[試供品受付対応-通信欄対応：「3.宛名シール貼/郵送中止判断」画面]

試供品の受付対応システムを「ワークフロー」で構築する

特に化粧品や健康食品など、「無料サンプル」をマーケティングに活用する例は多い。
≪無料サンプル受付配送システム≫をシステム会社に依頼してオーダーメイドで開発するのも悪くないが、イマドキの『ワークフロー製品』を使えば、自前で開発できてしまうかも。そうすれば仕様変更時にも即時対応できる。

以下のワークフロー定義は、『個人情報は情報システム部門のデータベースでキッチリ管理している』、と言う会社の例。正常入力の場合、「登録御礼メール」までのプロセスは「無人」だ。

[試供品受付対応-郵送：「1.登録確認」画面]

チームでレビュー？部署全体でレビュー？

ドキュメントをレビューしてもらうことは大切だ。ただ、レビューしてもらう範囲を指定できる方が使いやすい。『ワークフローでドキュメントレビュー』を拡張する。

[ドキュメントレビュー-チーム指定：「1. レビュー依頼」画面]

ワークフローでドキュメントレビュー

ドキュメントをレビューしてもらうことは大切だ。各プロセス内でチャット機能が使えるQuestetra BPM Suiteなら、以下の様なワークフロー定義で、手が空いている人から感想をもらうことができる。レビュー依頼者がタスク『2x感想対応／終了判断』で「終了フラグ」を立てるまでは、仲間たちから感想をもらうことが出来る。

[ドキュメントレビュー-チームコメント：「1.レビュー依頼」画面]

社内の技術教育は「カリスマ」を中心に回る

プログラミングのスキルは所属する組織のスキルレベルに大きく影響を受ける。勉強会を行うにしても「カリスマ」の存在有無で、その教育効果は大きく異なるだろう。

以下は、「カリスマ」がコードレビューされた結果を最終的に評価コメントする。組織にとっては、過去の勉強会資料が貴重な財産になっていく。
（『「コードレビュー」もワークフローで記録せよ』を発展）

[プログラムコードレビュー-リーダ評価：「6.評価」画面]