社内業務の改善・整理はまず「柔軟な対応」をやめる

クライアントの社内業務をシステム化する仕事をしているのですが、システム導入の前段として業務改善・整理を行っていると、「～の場合に柔軟に対応できなくなってしまう」などと言われることがあります。社内業務のシステム化においては、そもそも「柔軟な対応」をやめるべきというのが理解されていないようでした。その場で上手な説明ができなかったので、その理由を整理します。

柔軟な対応の実態

まず、「柔軟な対応」とは何でしょう。具体的にあった事例を挙げます。以前、あるシステムへのアカウント登録業務を整理する機会がありました。形式上は下記のような業務フローになっていました。

こちらの業務をシステム化すると、下記の様になります。メールではなく、申請フォームからの申請にしました。そして、現在メールで申請を行っている人たちには申請書から申請するように伝えて頂くよう依頼しました。

これに対し、システム管理者から次のような質問が出ました。

・引き続きメールで申請してくる人がいると思う。また、実は現在メールではなくチャットや電話で申請してくる人もいる。毎回我々の方でシステムに転記するのは面倒なので何かやり方を考えてほしい。
・2営業日を待てないので緊急で対応してほしいという依頼がチャットで来る場合もあり、システム上での申請だと緊急依頼に気づけない可能性があるので、システムからチャットを飛ばすなど何かやり方を考えてほしい。

つまり、現行の運用では下記の様な「柔軟な対応」を行っていたということがわかりました。
・既定の方法（メール）以外の方法での依頼にも対応していた
・チャットでの緊急対応を受け付けていた

このような業務フローにはない「柔軟な対応」があると、上記のようにシステム化するときに問題となります。システムを作る側からすると、
申請フォームから来たものだけを対応してください。以上！
なのですが、これを伝えると、たいてい運用者からは「それだと柔軟な対応ができなくなる」という反応が返ってきます。このような場合の説明を考えました。

（なお、実際にはこのような業務はアカウント作成までを自動化することも多いですが、この記事ではそこは焦点ではないため手動作成のまま申請プロセスのシステム化のみを行うことにします）

柔軟な対応をやめるべき理由

下記の理由で、業務を改善・整理する際には柔軟な対応はやめるべきです。

① 社内業務はそれ自体がコストであり、柔軟な対応はそのコストを増大させる
カスタマーサポートなど対コンシューマ向けのサービスにおいては「柔軟な対応」は良しとされることも多いでしょう。サービス品質の向上に繋がり、企業の利益に貢献する可能性があるからです。しかし、上記のシステムアカウントの作成などの社内業務（サービス）においては、サービスを受ける側も対応する側も従業員であり、その対応を行っている時間は顧客に対して価値を提供していない単なるコストです。「柔軟な対応」はこのコストを増大させます。

② 業務が属人化する
「柔軟な対応」の多くは業務フローやマニュアルに書かれていません。そのため、担当者が独断で良かれと思い「柔軟な対応」をしていると、後任者に引き継いだ際にユーザから当然のようにそれを求められますが、その後任者はそんな対応をしていることは知らないのですぐに同じ業務を行うことができません。

③ システムが複雑化し開発・維持コストが増大する
これはシステム化を前提としたときの問題ですが、「柔軟な対応」を含む複雑な業務をシステム化しようとすると当然システムも複雑化します。その結果、開発・維持コストが増大します。このコストが大きいと、社内業務の変更にシステムがついてこれず、結果としてメール運用に逆戻りする、といったことが起こります。

ユーザを教育する

「柔軟な対応」をやめるためには、ユーザの教育が必須です。上記の例だと、メールや電話、チャットできた場合はシステムでの申請をするように誘導し、緊急対応も受け付けないようにします。このようにして、黙ってシステムから申請して待つしかない、とユーザを教育するのです。始めは問合せが多発したり、ユーザから苦情が出るかもしれませんが、会社全体の利益のためにやっているので堂々としていればよいのです。いずれユーザが「申請フォームから申請しないとダメなんだな」と理解すれば、それ以降は黙って申請フォームから申請してきます。

例外を作る場合は、険しい条件を設ける

しかし、どうしても例外対応が必要な場合があります。その場合は、例外対応に厳しい条件を設けます。例えば、緊急で対応してほしい場合は、緊急の理由とマネージャの承認メールを添えて依頼すること。などとしておきます。「緊急の依頼が多い場合は担当マネージャに改善を要求します。」などと注意書きしておくとなおよいです。

単に「緊急の場合はチャットをしてください」などとしてしまうと、ユーザにとってはそちらの方が楽なので、事前にわかっていた場合でもギリギリになって緊急のふりをしてチャットしてくるようになります。全体最適になる行動が同時に個別最適になるように制御するのです。