“実践”システム障害対応:8週間目:関係者と対応方法合意

12週にわたり「”実践”システム障害対応」と題して、システム障害対応の改善のプロセスを約3か月で実行できるように、各週ごとに何を実践すればよいか?を考えていきたいと思います。

7週目までにシステム障害時の「アクション候補」「判断情報・判断基準」「システム障害フロー・システム障害レベル」について考えてきました。

今まで決めてきた内容は、過去の記事をご参照ください。

8週目は、システム保守で考えてきた7週目までの内容を元に、「関係者と対応方法合意」ついて考えていきましょう。

関係者とのミーティング

アクション候補、判断情報、判断基準の仮設、システム障害フロー、システム障害レベルが決定しました。これをもって、関係者と合意をしに行きましょう!

「対顧客」とのミーティング

ここまで検討や整理などお疲れ様でした。
ここで満足せずに検討や整理した内容が、本当に顧客側にとって「メリットがあるか?」「システム障害時にお互いの動きとして意識があうか?」を確認する事が大事です。

そしてミーティングの実施タイミングとしては、平時の時こそ実施しておくべきだと考えます。
主には顧客になるかもしれませんが、大勢顧客がいるならば重要顧客(売り上げ上位or障害へ感度の高いお客様)と実施することをお勧めします。

ミィーティング前の心構えと意識する点

どんな業務、どんなビジネスシーンにおいても合意形成の交渉は常に連続してあり、避けて通ることはできません。
このミーティングは、改善提案して合意形成を図るのですが、コンサルティング営業のような心構えになる方も少なからずいるかと思います。

少々話がそれますが、営業の業務は、お客様から「NOと言われる所から始まる」ともいいます。
今回のミーティングの中で、もし拒絶のようなシーンがあれば、辛い体験をするかもしれません。
ですが、それに対して心が打ち負けないために大事な事は「使命感」だと考えています。

今まで顧客が困るシステム障害のシーンからアクション候補を考え、それを少しでも影響極小化にするために考えたプランです。
自分やチームで考えた内容である事が前提ですが、「自分達は相手をどう良くしてあげられるか、相手にメリットがある」という気持ちの使命感が大事かもしれません。
どんな業務でもそうですが、会社や上司から言われて仕方なく進めているとか、建前でミーティングに臨むのであれば、おそらく上手くいきません。

また、相手の立場や状況を無視して進める事はできません。
顧客はシステム障害があった事など忘れて業務を実施しています。
今まで一度もシステム障害を経験していない方は仕方ないですが、普段は過去発生したシステム障害の事を忘れている方がほとんどです。
その理由は以下です。(参考「システム障害対応の改善は何故進まないのか?(第二部)」)

①企業として稼ぐことを優先するから(自分の主業務が大事だから)
②時間がないから(自分の主業務が繁忙期で忙しい等)
③どれだけ大切な事か理解していない(システム障害に対して課題感がない等)

①と②の理由であれば、実際に顧客がシステム障害発生してしまった前後など良いタイミングを待ちましょう。無理やり進めても顧客と良い関係性を保てません。

また②の理由と③の理由は、「避難訓練に参加しない」という理由に近いかと思います。

  • システム障害発生時の避難訓練の計画であるため…大事だとわかっているけど…今は忙しい
  • もっと急いでやる事があるから断ろう
  • 自分の実績や稼ぎと関係ないならやりたくない
  • めんどくさいから忙しさを理由にしてしまおう

等です。

もっと考えると②時間がないという理由は③の大切な事と理解していない(又は課題感がない)につながっているためと考えています。

システム障害対応の改善をした結果、エンドユーザーがどのくらい困らなくなるのかを理解していただく事が大事だと思います。
誰のためにどんな効果があるのか、それをどれだけ大切にするか理解しないまま、忙しい日々の流れの中で忘れてしまうのかもしれません。

いざミーティングで会話した後に「そうはいっても、実際システム障害が発生した時に都度状況をみないと判断できない」「今はわからない」とおっしゃる顧客もいるかと思います。
それもごもっともです。決めた計画通り推移する事は100%ないと思っています。
しかしシステム障害があった時に、考えたケースと違うものであったとしても、部分的にでも役立つ事は間違いないと思います。

ミーティング前に意識することや流れなどを以下に記載しておきます。

※今後実際のミーティング内容のケースのご紹介とあわせて、上記内容をブラッシュアップできればと思います。

「対ベンダ・連携システム」とのミーティング

システム構成で、システムベンダ・他に連携システムがある場合、そのチームの方々とも考え方を合わせておくとシステム障害対応時に変な意識ズレが発生しないかと思います。
ベンダが紋切り型で対応してくれない場合は、できる範囲/できない範囲を明確にしておくだけでもいいかもしれません。
もしかしたら保守契約内容などを見直す必要があるかもしれませんが、何かボトルネックが発見できるかもしれません。
システム障害当日にお互い辛い状況になる前に、事前に会話しておきましょう。

議事録の作成と確認依頼

無事ミーティングを行って意識合わせをしたら、従来よりもよりしっかり読みやすい議事録を書いて、先方にもぜひ確実に確認してもらいましょう。
普段も議事録を書かれていると思いますが、この議事録は「システム障害発生時に報告とともにこの議事録を送付」することを想定しています。

ミーティングによって意識合わせが無事できてより良い合意ができたとしても、次の障害が起きるのが何時になるかはわかりません。
その時には合意内容を忘れているかもしれませんし、担当が変わっているかもしれません。
そのため、「xx月xx日のこの時伺った内容をもとに報告します!アクションとしてはこのようなことをされると良いという話になっていました!」と送ってあげることで、お客様の満足度が格段に上がります。

こういう緊急時に送付するものなので、普段の議事録と若干書き方を工夫して「緊急時でも読みやすい」文章にしといておくと良いでしょう。
システム障害時は緊急で改めて関係者と確認していく時間がないので、ぜひやっていきましょう!

次回から3か月目の「システム障害発生時の訓練と振り返り」に入っていきます。
ここまで、ご覧いただきありがとうございました!
何か感じる事がございましたら、ご遠慮なくコメントいただけますと幸いです。

野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。

The following two tabs change content below.

野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。
是非フォローお願いしますm(_ _)m
NO IMAGE