IT関係の条件は通常、ベンダーによって決定されますが、私たちのITシステムは私たちのビジネスにとって重要なものです。今こそ、この関係に革命を起こす時です。「カスタマー・マニフェスト」は、その方法を示しています。
私たちは、テクノロジーベンダーに組織を支配する力を与えてしまいました。ミッションクリティカルなシステムがダウンするとどうなるかというと、ビジネスは心臓発作を起こします。ERPシステムがダウンすると、生産ラインが停止してしまいます。課金システムが故障して、顧客に請求できない。データベースがクラッシュして、誰が顧客なのかさえわからなくなってしまいます。
このような力関係の不均衡は、ベンダーと顧客の関係全体に存在します。プロジェクトでは、新しいシステムがいつ稼働するかをベンダーから教えてもらうのを待っています。人材においては、当社のビジネスに適しているかどうかではなく、技術者のスキルを重視して採用しています。お金の面では、スクルージがうらやむような価格設定に縛られています。
私たちはベンダーの犠牲になっています。そして、ITへの依存度が高まるにつれ、この状況はさらに悪化するでしょう。
私たちには何ができるのか？ほとんどのITベンダーとの関係は、販売後、つまりベンダーが販売したシステムをサポートすることで初めて成立するということを認識することから始めましょう。しかし、サポート関係の条件を決めるのは誰でしょうか？多くの場合、それはベンダーです。
ここでは、サービスレベルアグリーメントや契約の話をしているのではありません - これらは非常に重要ですが。ここでのキーワードは「関係」です。期待される行動を設定し、それ以下のものは認めないということです。ベンダーにはプロフェッショナルであることを期待し、その意味を説明することです。
ミッションクリティカルなサポート関係には、7つのルールが存在する。私たちは、お客様とベンダーの双方からサポート関係をつぶさに観察し、このルールを特定しました。お客様がエスカレーションを起こすのは、ベンダーがこれらのルールの1つ以上に違反しているからである。
ミッションクリティカルなお客様は、テクノロジーベンダーに次のことを期待するのが当然です。
- お客様のサポート
- 一貫して提供する
- お客様のご案内
- 積極的なトラブルシューティング
- 速く
- それを証明する
- 先行する
この7つのルールは、顧客マニフェストを構成しています。これは、顧客が関係をコントロールし、パワーバランスを取り戻すための青写真です。どのように？
1.お客様をサポートする。
ミッション・クリティカルな世界では、ベンダーはシステムだけではなく、お客様のビジネスをサポートします。システムが停止した場合、ベンダーには必要なことは何でもやってもらう必要があります。システムを復旧させるだけでなく、ビジネスを再開させるためのサポートも必要です。
例えば、ある流通企業の倉庫サーバーが断続的にクラッシュしていました。クラッシュするたびに、何万ポンドものビジネス損失が発生していました。ハードウェアベンダーは、問題がハードウェアにもアプリケーションにもないことを証明しました。それにもかかわらず、ベンダーはこの問題について顧客をサポートし続け、問題の真の原因である「妨害行為」を証明することに貢献したのです。
ベンダーにあなたのビジネスをサポートしてもらいましょう。ベンダーに聞くべき良い質問
- インシデントをサポートする際、どの時点でプラグを抜くのか？（これでいいのか？）
- インシデントが複数のテクノロジーにまたがっている場合、最終的にどのベンダーが責任を負うことになっても、彼らがインシデントを管理してくれるのか？
- あなたと一緒に大規模なインシデントを管理するための練習やリハーサルを行い、その結果、自分たちのプロセスを変えることができるか？
それは彼らのシステムかもしれないが、あなたのビジネスだ。彼らに思い出させる。
2.一貫して提供する
もし私が心臓発作を起こした場合、ジョーンズ医師ではなくスミス医師に治療を受けたかどうかで、私の生存が左右されるべきではありません。私は、すべての医師が一貫して適切な治療をしてくれることを期待しています。私たちの組織が心臓発作に襲われたとき、私たちはベンダーにそれ以下のことを期待すべきでしょうか？特に、誰が対応してもビジネスを再開できるような、具体的で明確かつ効果的なプロセスを持っているでしょうか。
例えば、あるシステムサプライヤーでは、ミッションクリティカルなお客様にクラッシュが発生した場合、「War Room」を設置しています。この部屋にいる人たちはそれぞれ特定の役割を持ち、その役割の中で組織的に作業を行い、問題を診断してサービスを復旧させます。誰がどのような役割を担っているかにかかわらず、War Roomは同じように数字で動いています。
基準を上げる。求める。
- インシデント管理について、ベンダーはどのような基準を持っていますか？
- 彼らは、あなたが期待する基準を知っていますか？
- サポートの成功が1人や2人の個人だけに依存しないようにするために、どのようなプロセスをとっているのでしょうか？
それはあなたのビジネスです。あなたが基準を決めるべきです。
3.お客様をご案内する
テレビでは、警察が取り調べで容疑者の不安を高めようとするとき、質問をして答えをもらい、何も言わずに部屋を出ていく。沈黙が続くと、容疑者はいろいろなことを心配しますが、主に「What else?次は何だ？"と。警察が戻ってきたとき、容疑者は心配で壁を登り、自白しようと必死になっている。
驚くべきことに、多くのベンダーが同じような「質問と沈黙」のルーチンを採用しています。深刻な事故について質問した後、「問題に取り組む」ためにオフラインになってしまうのです。なぜ質問されたのか、その答えで何をしているのか、次に何をするのか、わからないのです。エスカレートするのも無理はありません。
しかし、ベンダーの中には、顧客を上手に誘導するところもある。あるソフトウェア・ベンダーは、ミッション・クリティカルなクラッシュの診断を構成するために、一貫したトラブルシューティング・プロセスを使用しており、それをお客様と共有しています。つまり、顧客とのコンタクトのたびに、どのような情報が必要なのか、なぜそれが必要なのか、その情報を使って何をするのか、そして次にどこに行くのかを説明しているのだ。
不安を減らす。大規模なインシデントの際にベンダーが案内する方法を改善する。聞いてみましょう。
- 問題を診断する際、彼らはどのような質問をするように訓練されていますか？
- 事故の際に、どのような情報が必要なのか、なぜそれが必要なのか、その情報を使って何をするのか、次に何をするのかを、彼らはどのように説明するのか。
- 彼らの診断ロードマップはどのようなもので、それを共有できるのか？
あなたは、彼らの診断におけるすべてのステップを透明にしたいと思っています。サプライズはありません。
4.積極的なトラブルシューティング
ミッションクリティカルな問題の多くは、ベンダーの知識が尽きたためにエスカレーションされます。ベンダーは、我々のような問題を見たことがないかもしれないし、問題が非常に複雑かもしれない。通常、ベンダーはこのような問題に対して、1つの修正プログラムが定着することを期待して、一連の修正プログラムを投入します。しかし、ほとんどの修正は失敗に終わります。さらに悪いことに、元々の問題よりも大きな問題を引き起こしてしまうこともある。
ミッションクリティカルな問題を一貫してトラブルシューティングすることが可能です。ある金融サービス会社では、終業時の照合作業中にシステムが断続的にクラッシュしていました。このクラッシュのせいで、翌日に合法的な取引ができるように、毎晩何百人もの派遣社員を雇って手作業で作業を行わなければなりませんでした。これは、二度と繰り返したくない大仕事でした。この問題は複雑だったため、ベンダーは診断プロトコルを使用し、顧客と共有しました。このプロトコルにより、不必要なシステム変更を最小限に抑え、効率的に問題を解決することができました。
お客様を導く。ベンダーが問題を解決するのを助ける。頼んでください。
- 失敗した修正案を次々と出してしまうような、ばらまき型のアプローチを取らないようにするにはどうすればいいのでしょうか。
- 大規模なインシデントが発生した場合、彼らはどのような標準的な情報を必要とするのでしょうか？
- 問題となる情報を入手した場合、その情報を構造化されたフォーマットですぐにあなたと共有することができますか？(誤った情報を修正し、迅速な成功の可能性を高めることができるかもしれません）。
すべてのインシデントは、同じような質問を一貫した方法で使って管理されていますか？いいえ。まだまだですね。
5.速いこと。
救急隊員は、時間に追われながら人命を救助していますが、それを間違えることは許されません。この2つの相反するプレッシャーから、彼らはほとんどの一般的な状況で一貫したプロセスを使用し、それに厳密に従っています。即興で対応するには、時間があまりにも限られており、リスクがあまりにも高いのです。彼らのプロセスに従うことが、仕事を終わらせる一番の近道なのです。
ベンダーにも同様の規律が必要です。致命的な問題の場合、ベンダーが間違えることは許されません。
例えば、あるハードウェアベンダーでは、ミッションクリティカルなお客様の問題が2時間以上前に発生した場合、最上級のエンジニアにエスカレーションすることを義務付けています。これらのエンジニアがすぐに対応できるように、また、古い問題の確認に費やす時間を最小限に抑えるために、この会社では、彼らに渡す問題情報の標準セットを義務付けています。この措置により、お客様の問題解決までの時間が平均52%改善されました。
ベンダーを迅速な軌道に乗せる聞いてみてください。
- 大規模なインシデントが発生した場合、どのような自動プロセスが働くのでしょうか？(消防隊やF1のピットクルーを思い浮かべてみてください）。
- これらをどのくらいの頻度で練習するのでしょうか？
- これらのプロセスを高速化するために、どのくらいの頻度で見直しているのだろうか。
- より早く問題を解決してもらうためには、どのような方法があるのでしょうか。
ミッションクリティカルなインシデントの平均時間を追跡する。短縮されていなければ、これらの質問に答えていないことになります。
6.証明してください。
オスカー・ワイルドの言葉を借りれば、「一度の事故は不幸かもしれないが、二度の事故は不注意である」ということです。私たちのビジネスがダメージを受けたのであれば、ベンダーはなぜそれが起こったのか、そしてなぜそれが二度と起こらないのかを証明してくれるはずです。多くのベンダーは、目の前の問題が解決するとアクセルを緩めてしまいます。
しかし、一部のベンダーはそれを正しく実行しています。あるシステム・サプライヤーは、重大なインシデントが発生した後、その根本原因が何であったかだけでなく、それがどのようにして証明されたか、そして二度と起こらないようにするために何をしているかを記した標準的な分析レポートを顧客に渡しています。
ベンダーに立証責任を与えてください。彼らに聞いてみてください。
- 根本的な原因を見つけたことをどうやって確認するのか。
- 根本的な原因をどのように推測しているのか？
- 他にどのような原因が考えられるだろうか。
あなたの問題のうち、時間の経過とともに繰り返される問題の数を記録してください。もしこの数が減っていなければ、その根本原因は根本原因ではないということです。
7.先手を打つ。
多くの問題は防ぐことができます。何か違うことをする必要があるかもしれませんし、他の人の問題から学ぶことができるかもしれません。私たちは、問題を解決するためにベンダーの支援を必要とする以上に、問題を回避するためにベンダーの支援を必要としています。そのため、ベンダーサポート組織が積極的な支援をほとんど行わない傾向にあるのは残念なことです。
しかし、例外もあります。例えば、あるサーバー会社では、顧客の問題を未然に防ぐことを唯一の仕事とする技術スペシャリストの幹部を作りました。その結果、お客様の問題は減り、エスカレーションも減りました。
予防は治療に勝る。聞いてみてください。
- 彼らのサポート活動のうち、インシデントへの対応ではなく、問題の予防に充てられている割合はどのくらいですか？(この割合はあなたにとって受け入れられるものですか？)
- 彼らが変更を提案するとき、その変更が引き起こすかもしれない問題を防ぐために、どのような提案をするのでしょうか。
- 彼らが問題を解決したとき、その解決が必要なのはこのシステムだけだということをどうやって知ることができるでしょうか？
ベンダーのサポートは、往々にしてリアクティブなものです。彼らは先のことを考える必要があります。そのためのサポートを惜しんではいけません。
カスタマーサポートの7つのルール」は、サポートに関するすべての問題を解決するものではなく、また、簡単に実現できるものでもありません。しかし、ベンダーと協力してパフォーマンスを向上させなければ、ダウンタイムやビジネスへの影響など、あるがままの状態を受け入れるしかありません。
多くのベンダーは、これらの信条のうちのいくつかに対しては成功します。しかし、7つの項目すべてに成功しているベンダーはほとんどありません。これでは十分ではありません。私たちは、テクノロジー・ベンダーにビジネスの命を預けています。彼らのサポートルールを受け入れてきました。しかし、もう終わりです。私たちのビジネスは、そんなことをしている場合ではありません。ルールを変える時が来たのです。