うれしかったのと同時に、この状態を続けたいと思いました。担当者が替わったら、またお客様に一から聞く。そんな引き継ぎにはしたくありません。
Advangeが担当した運用集約のプロジェクトでも、複数のベンダーが持っている情報をどう引き継ぐかが気になっていました。ヘルプデスクと運用管理を新しい体制へ移す間も、お客様の業務は続きます。資料はあっても、担当者だけが知っている作業や確認先が残っていないか。その点は、機器の設定と同じように気を配る必要がありました。
手順の途中で、誰に聞くのか
ここからは、共有フォルダの権限追加を例にします。設定方法が手順書に載っていても、誰に承認をもらうかが分からなければ作業は止まります。社内IT担当者に聞いて、その人が利用部門へ確認し、返事をMSPへ伝える。これが毎回だと、担当者はずっと連絡役です。
この場合、手順書に操作画面を足しても解決しません。私が見たいのは、承認を取ったメールです。誰に何を確認したのかを読んで、引き継ぎ資料にない情報を探します。
承認先が抜けていたなら、資料に追記する。ただ、名前を書けば終わりでもありません。MSPからその人へ直接確認してよいかは、お客様と決める必要があります。権限を付ける判断をお客様に残したまま、IT担当者を経由せずに申請を回せるか。そこまで話せれば、次の依頼の進め方が変わります。
急ぎのときは、詳しい人に聞いて対応を進めることも必要です。困るのは、その回答がメールに残ったままになること。翌日には別の依頼が来るので、資料を直す時間を取らないと、そのままになりがちです。
対応が終わると、こちらも一区切りついた気になります。でも、お客様に教えていただいた内容を次の担当者が使えなければ、また説明をお願いすることになる。自分たちの引き継ぎで防げる確認は、減らしておきたいです。
SOPは、別の担当者に使ってもらう
こうした確認内容を、SOP、日常の標準作業手順に入れていきたいと考えています。権限追加なら、申請に必要な情報と承認先を操作手順と一緒に載せます。承認者が不在のときの確認先も、お客様と相談して決める。通常と違う権限の依頼は、そのまま作業せず、判断をお願いする相手へ回す形です。
書いたあとは、別の担当者に使ってもらうつもりです。自分では分かるつもりで書いていても、読む人には伝わらない箇所があるはずです。そこで出た質問を見ながら直します。まずは、同じ確認が何度も戻っている作業を一つ選ぶところからです。
気になるのは、作ったあとの更新です。承認者の名前が古いままでは、また人を探すことになります。組織変更があったときに誰が情報を知らせ、誰が手順を直すかも、運用に含めておきたいです。
Advangeでは、ネットワーク、クラウド、Microsoft 365、セキュリティ、利用者サポートなどを扱っています。複数の領域の作業を理解したうえで、担当間の受け渡しを考えられることは、運用を引き継ぐ際にも強みになります。
お客様からいただいた「楽になった」という言葉を、次の担当者にも伝えたいです。手順を渡すときに、どのやり取りがお客様の負担になっていたかも一緒に残す。その事情まで分かっていると、手順を見直すときにも判断しやすくなると思います。
執筆：崔明姬
