マニュアルは作った。それでも回らない。
マニュアルを作って手順を1つに決めると、品質のばらつきは小さくなります。
ただし、作業そのものの量は担当者の手元に残ります。
この記事で書くのは、標準化で止める業務と、自動化まで進める業務の分け方です。
私はコールセンターの責任者として、手順書と社内ナレッジを作る側にいました。
そのあと同じ業務を、kintoneのボタンに置き換えています。
- 標準化で減るものと、減らないもの
- 手順書の工数が、作成後も発生し続ける理由
- 標準化で止める業務と、自動化まで進める業務の分け方
業務標準化とは、やり方を1つに決めること
業務標準化とは、同じ業務のやり方を1つに決めることです。
マニュアル化は、決めたやり方を文書にする作業を指します。
2つは並べて語られますが、同じものではありません。
- 標準化
-
同じ業務のやり方を1つに決めること。決めるのは手順であって、書き方ではない。
- マニュアル化
-
決まったやり方を、他の人が読める形の文書にすること。標準化の手段の1つにあたる。
- 属人化
-
社内の特定の個人に依存している状態。社外への依存である丸投げとは、向きが逆になる。
区別しておくと、順番が見えます。
やり方が2通り残ったまま文書を作ると、書いてある手順と実際の手順が別々に動きます。
読む側は、どちらが正しいのかを判断できません。
判断できる人が社内に必要になり、その人に質問が集まります。
標準化で減るものと、減らないもの
標準化で減るのは、品質のばらつきと、教えるための時間です。
減らないのは、作業そのものの量になります。
- 品質のばらつきは小さくなる
- 教えるための時間は短くなる
- 作業そのものの量は変わらない
標準化が作るのは、誰がやっても同じ結果になる状態です。
誰もやらなくてよい状態ではありません。
手順を1つに決めても、その手順を実行するのは人のまま。
転記に30分かかっていたなら、手順書ができたあとも30分です。
マニュアルが定着しない原因として、「更新されない」「現場が読まない」といった運用の問題はよく挙げられます。
定着したあとでも作業の量そのものは残ると私は考えています。
量を減らすには、手順を人から外すという別の打ち手が必要です。
手順書の工数が、作成後も発生し続ける理由
手順書は、作った時点では終わりません。
業務のやり方が変われば、書き直す作業が発生します。
私はコールセンターの責任者として、新入社員向けのkintone導入研修と、社内のナレッジを作りました。
作ったあとも更新しています。
更新の工数は、基本的に私の時間から出ていました。
ナレッジの一部は、リーダーにも担ってもらっています。
更新の時間は、業務を回す時間と同じ場所から出ます。
忙しい時期ほど後回しになり、そのまま数か月が過ぎます。
- 手順書と実際のやり方がずれる
- 読む人が減り、口頭の質問が増える
- 質問に答えるのは、業務を知っている人になる
標準化が続かなくなるのは、作る工数ではなく持ち続ける工数のほうだと、私は考えています。
作るのは1回で済みますが、持ち続けるのは業務が変わるかぎり終わりません。
標準化で止める業務と、自動化まで進める業務
私が見ている軸は1つで、手順のなかに人の判断が入るかどうかです。
判断が入らない作業は、自動化まで進めます。
判断が入る作業は標準化で止めて、判断の基準のほうを揃えます。
| 業務の性質 | 打ち手 | 揃えるもの |
|---|---|---|
| 判断が入らない（転記・集計・決まった形での出力） | 自動化まで進める | 処理そのもの |
| 判断が入る（例外対応・優先順位づけ・交渉） | 標準化で止める | 判断の基準 |
| 発生頻度が低い（年に数回） | 標準化で止める | 手順の記録 |
標準化に意味がない、という話ではありません。
やり方が2通り残っている作業は、そもそも自動化できません。
どちらの手順で処理するかを決めないまま仕組みにすると、決めなかった判断が仕組みの中に隠れます。
あとから直すとき、なぜその動きなのかを説明できる人がいません。
全部を自動化しようとすると、年に数回の業務で工数が回収できなくなります。
自動化まで進めると決めた作業を、どの順番で手放していくか。
その手順は属人化を解消する手順の記事にまとめています。
揃えた手順を、人から仕組みへ移した現場
私が担当していたコールセンターでは、架電の結果に応じて納品用のデータを作っていました。
作り方が書かれていたのは、手順書、社内のナレッジ集、チャットの投稿の3か所。
それに加えて、口頭での説明もありました。
やり方そのものは決まっていました。
決まっていなかったのは、置き場所のほうです。
- 架電の時刻を、ボタンで自動入力する
- 入力できる内容を、ステータスに応じて制御する
- 納品用のデータを、テンプレートとして出力する
kintoneをJavaScriptでカスタマイズし、この3つを画面の中に入れました。
手順を覚えて実行する作業が、ボタンを押す作業に変わっています。
この期間、1時間あたりの架電数は21.3から24.2になりました。
4月から取り組み、6月末に集計した3か月の数字です。
同じ時期に別の施策も動いていたため、この数字を改修だけの効果として切り出すことはできません。
受託の現場では、良くなりそうな施策を同時に試すためです。
それでも、数字を押し上げた中心はこの改修だったと私は見ています。
入力していた当事者から、効果を実感する声が上がったためです。
同じことを揃えるのに、文書に書く方法と、仕組みに埋め込む方法があります。
この2つは、あとから効いてくる負担が違います。
仕組みに移した作業については、手順書の更新がいらなくなりました。
やり方を変えるときに直すのは、文書ではなく画面のほうです。
まとめ：標準化を止める線の引き方
手元の業務から、人の判断が入らないものを1つ選んでください。
転記、集計、決まった形での出力あたりが候補になります。
その1つを、手順書に書くのか、仕組みに埋め込むのか。
先に決めておくと、作った手順書を更新し続ける形になりません。
どこから手をつけるかを先に見たい場合は、9つの質問に答える診断があります。
回答すると、自社がどの段階で止まっているかが分かる仕組みです。