繰り返しますが、IT以外のサービスアプローチを使用するという考え方に焦点が当てられています。 以前に分析された：
- なぜ、誰がそれを必要としますか。
- 物事を整理するときです。
- それを行う方法。
今日は、会社のプロセスにサービスアプローチを導入しながら、実際に経験する時間がある段階に焦点を当てます。
前回の記事で、 ITレシピを「コール管理の虹」というスキームの形式で紹介しました（広告、トレーニング、レポートの各段階の機能の強調表示を含む）。
残りを見ていきます。
- 内部顧客を検索します。
- プロセスモデリング。
- ツールの選択。
- 適切な雰囲気を作成します。
内部顧客を探しています
「内部顧客検索」とは何ですか？ 私の意見では、これは重要な段階です。
私は薬との並行性が好きです。深刻な健康上の問題だけが検査のために医者に行くようにします。 予防検査は無視します。 sayingにもあるように、「雷が鳴るまで...」。
同様の状況は、多くのビジネスプロセスの「健康」にも当てはまります。 ユニットの長が問題に気付いていても、彼はいつもそれについて話すとは限りません。 さらに、誰かに助けを求めてください。 より頻繁に黙って、自分で「治療」します。
企業が内部または外部監査、リーン製造の実施、またはその他の手段を使用して調査を実施しようとしても、すべての問題が明らかになるわけではありません。 そして、それらは多くの場合、まったく狙われていません。
ここで、ITマネージャーまたはITマネージャーが重要な役割を果たします。 情報システムの知識を持ち、サービスアプローチの本質を明確に理解している彼は、ITSMメソッドを使用して解決しようとするビジネス上の問題を完全に理解しています。 もちろん、彼がしたい場合。
さらに、徹底的な対策を講じることなく、段階的に解決できます。 彼は誰に助けを求めるべきかを他の人よりもよく知っています。 私は強調します-訴えることであり、何らかの決定を課すことではありません。 すぐに、またはさらに悪いことに、次のような情報で人を公に隔離することはできません。 「しかし、あなたはそのような問題を抱えていることを知っています。 解決を手伝ってほしいですか？」 その効果は完全に反対です。
どうする？ そのような会話をどこでしようとするのですか？
主な問題は「喫煙室」によって解決されると人々は言います。 しかし、これは同じ画像です。 これに都合の良い場所で会話を開始する方が良いことを理解することが重要です。 バス停にあるエレベーター、食堂への行列などです。 場所では、これらの「喫煙室」がより見える。 主なことは、恐れずにアプローチし、会話を開始し、軌道に乗せることです。 実際、何がどこで痛いのかを調べてください。
ケーススタディ。 主任会計士との会話。 「同僚、私はあなたの部門が和解の行為の準備のための多くのアプリケーションを受け取ることを知っています。 そのような量に時間通りにどう対処するのですか？」
私たちは、問題が絶対に無害であることについて尋ねました。 質問がされました-今、私たちは答えを待っています。
「はい。 多くのアプリケーションがあります。 すべての人は忙しいが、まだ時間がない。」
ここがその瞬間です。 「治療」を提供する時が来ました。
「私は、サービスデスクを通して和解行為の申請を提出することを提案しますか？」
次は技術的な問題です。
この内部顧客検索アルゴリズムを「ファイブP」メソッドと呼びます。
- さあ
- 話をする。
- 聞く。
- 提案（試してみてください）。
- 販売（実装）。
アプローチする方法、私たちはすでに知っています。 それは拳の戦いのように見えないように話してください。 会話の技術を学ぶ必要があります。 「眠い顔」で聞いている場合、結果は同じになります。 リスナーの注意を引きます。 はい、簡単ではありません。 あなたが確信しているものだけを提供できます。
実装を長期間延長しないでください。 ツールがすでに存在する場合、機能をできるだけ早く実行する必要があります。
モデリングプロセス
適切に編成されていれば、この段階は変更を加えるためのほぼ準備完了の技術的タスクです。
顧客が見つかり、問題が特定されました。 今では、迅速かつ顧客の注意をそらすことなく、技術仕様のプロトタイプを入手することが重要です。 この段階では、プロセスの主要参加者全員と連絡を取ります。
モデリングの前の最初のステップは、適切なプロセスに慣れることです。 以前、私は大規模な小売店を自分で訪問した方法の経験を共有し、ITに申請するプロセスを研究しました。 その後、彼は、エグゼキュータによるアプリケーションの処理プロセスを分析しました。 その後になって、紙の上でモデルを作成するときが来ました。
図面から始めます。 あなたが描く、顧客のルール。 プロセスの各参加者が理解できる図に言葉を入れてください。
ケーススタディ。 サービスデスクに基づいて、設備の自動化の修理およびメンテナンスの要求を自動化するプロジェクトはスマートです。 地理的に分散したオブジェクト。 パフォーマーとしてのプロセスの参加者は300人以上です。 最初に、労働者の日を調査しました。アプリケーションを受け取る方法、実装について報告する方法、コンピューターを使用するか、電話で「現場」ですべてを決定するかです。 その後、段階的に施設の主要な従業員を集め、ホワイトボード上のプロセス図を簡単に引き出しました。 議論の過程で、図は図の形を取りました。 すべてのコメントと提案が考慮されました。 問題のある問題は、管理上の決定のために別々に記録されました。 これらの図に基づいて、プロセスを説明したアプリケーションライフサイクル図を作成し、顧客と合意しました。
このような実装により、パフォーマーはイノベーションの本質を理解するのがはるかに簡単になります。 一緒に作成された図面により、システム内のプロセスの各ステップをすぐに呼び出すことができました。
プロセスをモデル化するときは、同僚に図をロードせず、簡単な図面を提供します。 これらの図のすべての質問を処理します。 そして、顧客がすべてを理解したら、彼の言葉をスキームにシフトし、その説明を準備します。
サービスデスククラスの最新のシステムでは、プロセスの図と説明があるため、新しい機能を作成するのは非常に簡単で迅速です。
ツールを選択してください
これは技術的な選択基準ではなく、さまざまなプログラムのパフォーマンス特性の比較に関するものではありません。 むしろ、問題の機能的および心理的側面に重点が置かれています。
子供向けのおもちゃのようなものです。 おもちゃが気に入らない場合、子供はそれで遊ぶことはありません。 システムまたはツールが不快な場合、ルートを取得しません。
年齢によって玩具は異なります。かつては柔らかくふわふわで、一度は大きくて鉄です。 「子供の年齢」-組織の成熟度を考慮します。 なぜ最も単純なタスクを解決するために強力なサービスデスクを使用するのですか？ またはその逆。 通常の郵便物の大規模な保管場所に郵便物管理プロセスを構築することは便利ですか？
次に、機能的な目的について説明します。 このツールで何が行われるかを明確に理解する必要があります。 どのように提供されますか？ メルセデスが本当に必要なのか、それともそこに着くのか？ メルセデスの場合、メンテナンスと維持のためのリソースはありますか？
ケーススタディ。
「なぜサービスデスクが必要なのですか？」
「プログラマーを管理する。」
時間をかけてください。 すべての引数を考慮してください。 単純なクラウドソリューションで十分な場合もあれば、本格的な請負業者が関与するプロジェクト全体が必要な場合もあります。
チームの雰囲気を作る
彼らはあなたがあなたがしていることを愛しているなら、あなたは仕事に行かないようなものだと言う。
あなたのビジネスを信じていない場合、どうすれば他の人を魅了できますか？ プロジェクトリーダーは重要です。 これは、タスクを明確に理解し、それらを他の人に伝える意欲を持つアイデアの生成元です。 適切な雰囲気を作り出すのは彼です。
この点で幸運でした。 私は自分の仕事が好きです。 そして、私はパフォーマーのチームにどのような変化をもたらすのかを明確に理解しています。 これをチームに正しく伝えることが残っています。 ステージを設定することが重要ですが、無理をしないでください。 害はありません。
ケーススタディ。 石油およびガス会社向けのITインシデント管理実装プロジェクト。 出演者の中には、通信エンジニア、5分もなしの年金受給者がいます。 彼はすぐに、「1か所でサービスデスク」を見たと言いました...その時、その週の終わりに、会社のすべてのITスペシャリストは、Excelで勤務日の「ミラー」を記入しました。 彼らのKPIとボーナスはそれに依存していました。 すでにテスト運用中に、レポートをサービスデスクのデータに置き換えることをお勧めしました。 その結果、通信エンジニアはそこで空いていました。 彼の申請書は「過去のレジ」を解決したので、「kalym」と呼びました。 そして、彼にとっては賞品は用意されていません。 もちろん、それは冗談でした。 しかし、目標は達成されました。 翌日、彼はすでにユーザーにシステムでアプリケーションを作成する必要がある理由を説明していました。
志を同じくする人々の検索が必要です。 常にそのようなものがあります。 そして、最も「頑固な」者が議論に関与しなければなりません。 熱心な懐疑論者が最初のアシスタントになる場合がよくあります。
別のポイントは、恐怖を払拭することです。 原則として、人々はそう考えます： 「彼らは私たちを数え、それから彼らは私たちの多くがいると言い、そしておそらく彼らは誰かを解雇するでしょう。」
恐れがあれば、それを払拭しなければなりません。 ツールの使用がチームメンバーと顧客に与えるものを説明します。 適切な雰囲気は、実装を成功させるためのもう1つの鍵です。
まとめると
記事の第2部を一般的なフレーズではなく、実際のストーリーで完成させたいと思います。
ユニットのヘッドからの電話： 「ドミトリー、彼らはあなたのサービスデスクがほとんどすべての問題を解決できると言います。 あなたの助けが本当に必要です。」
私： 「誰が話しているの？」
回答： 「人々は話している。」
もちろん楽しいですが、経験から次のことが示唆されています。 すべてをご覧ください。 突然、それはそのプログラムに関するものではありません。
「どうすれば手伝うことができますか？」
回答： 「特定の種類の通話を管理するプロセスを自動化する必要があります。」
このトピックは複数回取り上げられています。 実装プロセスは簡単です。 タスクを明確にし、現在の負荷を確認してから10分後に、5日後にテストできると言います。 受信機に沈黙があります。
私： 「こんにちは、ここにいますか？」
回答： 「冗談ですか？ とても速いですか？」
私： 「それは起こります。 同様のプロセスがすでに存在します。」
1週間後、運用を開始しました。 感謝していました。 「奇跡」についての新しい情報が人々にやってきました。
それが私たちの仕事です。 面白い。 喜んで。 顧客に小さな喜びを提供し、サービスアプローチを導入する実践においてますます多くの経験を蓄積します。 これらのケースを次の記事で共有します。