私の名前はダリア、製品アナリストです。 私の会社の主力製品はサービス デスクです。これは、さまざまなオブジェクトの修理作業やメンテナンスなどのビジネス プロセスを自動化するクラウド プラットフォームです。 私の仕事の XNUMX つは、クライアントのビジネスに当社のプラットフォームを導入するプロセスに参加することであり、その一方で、特定の企業の詳細を可能な限り深く掘り下げる必要があります。
私たちのクライアントの XNUMX つである Brant サービス会社が、どのようにして労働集約的なビジネス プロセスを自動化することに成功したかについてお話したいと思います。 同社は、クライアントの数、そしてそれに応じてサービスへのリクエストが急速に増加し始めたときに、当社のプラットフォームに注目しました。 ビジネスは活発に発展しています。それは素晴らしいことですが、何が問題なのでしょうか? 実際、同様の日常的なプロセスの数は急激に増加しており、この危険性を過小評価することはできません。 さらに、アプリケーションが少なかったときに機能していた同じツールを使用できないことは明らかです。
おなじみ？
ということで、救いの物語。
すなわち サービス会社 複数の関係者間での迅速なコミュニケーションが必要なため、当社のプラットフォームの機能を可能な限り最大限に活用してください。 これらの側面は何ですか?
- お客様何かが壊れている人
- サービスマネージャ、申請を受け入れ、執行者を任命し、その実施を制御する者
- リードエンジニア、実行される作業の品質を確実に管理し、複雑なリクエストを完了する際に技術サポートを提供します。
- サービススペシャリスト、 誰が核心を突いて問題を解決してくれるのか
会社概要「ブラント」
- 提供されるサービス：機器の修理および保証サービス、建設および設置作業。 クリーニング;
- モスクワとモスクワ地方には 1000 を超えるサービス施設があります。
- 60名以上のサービススペシャリストが常駐しています。
- 同社は毎月 4500 件を超える申請を処理しています。
- この文章ではブラントの顧客を特定するために仮名を使用しています。 これらは次のとおりです。食料品店の連邦チェーンです。これを「ポリアンカ」と呼びましょう。 XNUMX つの薬局チェーン – 「ドクター A」と「ドクター B」。 通信事業者「Op Mobile」のサービスセンター。 いくつかの生産施設も同様です。
各大手チェーンは、すべてのアプリケーション サポート作業を自社の会計プログラムで実行することを主張しました。 インタラクションの自動化は顧客とサービス会社の両方にとって効果的であり、総合サービスの分野では正当化されます。 ただし、顧客が XNUMX 人以上いる場合、サービス会社が複数のプログラムを同時に行うと困難が生じます。
サービスデスク導入前の様子
Polyanka ネットワークは 1C: MRO プログラムを使用します。 「ドクター A」 - イントラサービス システムを通じて申請を提出します。 「Doctor B」と「Op Mobile」 - 独自のサービスデスクを通じて。 オフラインの顧客は、電子メール、電話、さらには WhatsApp や Viber を通じてリクエストを送信します。
受け取ったすべての申請書は Excel ファイルにまとめられました。 一度にアプリケーションの数は 4 を超える可能性があり、これらはアクティブなアプリケーションのみですが、完了したアプリケーションの履歴を保存することも必要です。
概要ファイルがいつでも消滅する恐れがあるため、アプリケーション データベースを失わないように常にコピーを作成する必要がありました。 すべてのソースからアプリケーションを収集して Excel ファイルに転送するには、容認できないほど長い時間がかかりました。 さらに、SMS メッセージ、電子メール、Viber、WhatsApp を介して出演者にアプリケーションを手動で送信する必要もありました。
この場合、サービススペシャリストに送信されるリクエストには、その実装に必要な最大限の情報が含まれている必要があります。 申請完了後は、実施に関する情報収集や写真レポートの収集が必要でした。 そしてそれを別の場所に保管します。
このようなマルチチャンネルの受信、録画、アプリケーションの配信がどれほど困難だったかは想像できます。 同社がサービスを提供する新しい顧客を獲得し、より多くのスペシャリストを雇用していることを考えると、プロセスの自動化と透明性の向上が切実に必要とされていました。 ただし、クライアントにとって都合の良い方法でアプリケーションを操作することを拒否することは、契約条件によって規定されているため、拒否することはできません。
これは、以下を可能にする別のシステムが必要であることを意味します。
- すべての顧客システムからタスクを XNUMX か所に収集します。
- さまざまな形式で受け取ったアプリケーションを標準化する。
- 必要なすべての情報を添えてサービススペシャリストにリクエストを送信します。
- アプリケーションの実行に関するレポートを受け取る。
- 完了した注文の履歴を保存します。
そして同時に、それは出演者、つまりコミュニケーション手段として電話しか持っていない現場従業員にとっても便利でなければなりません。
サービスデスク導入後の様子
ソフトウェア製品の市場を調査した後、Brant は当社のシステムである HubEx プラットフォームを選択しました。
ステップ 1: Excel インポートを使用して、サービス対象のすべてのオブジェクトのデータがプラットフォームに転送されました (開始時点では 900 個以上ありました)。これで、各オブジェクトに関する必要な情報がすべてオブジェクトの Web パスポートに保存されます。地図上の地理位置情報、技術文書、連絡先、サービス履歴。 申請を迅速に完了するために必要なすべてのもの。
ステップ 2: - 共通システムへのアプリケーションのロードは迅速に完了しました。 HubEx システムへのインポートは XNUMX 回のクリックで実行され、各オブジェクトのすべてのリクエストが XNUMX か所に収集されるようになりました。 顧客のシステムからアプリケーションを収集する別の方法は、アプリケーションを電子メールで直接受信するメカニズムをセットアップすることです。 このオプションはプラットフォームでも利用できます。
結果: Brant ディスパッチャは、すべてのリクエストを XNUMX つのプログラムで確認し、現場従業員に配布します。
各従業員は、新しく割り当てられたリクエストについて通知するモバイル アプリケーションを備えた携帯電話をポケットに入れています。 そして、アプリケーション自体で、スペシャリストは自分のアプリケーションの現在のリストを確認します。
重要な点: アプリケーションに関するすべてのコミュニケーションは、電話での会話やインスタント メッセンジャーを通じてではなく、厳密にアプリケーション自体内で行われます。
これにより、リクエストの履歴を保存し、それぞれの通信を明確にセグメント化し、重要なものが失われないようにすることができます。 請負業者は、作業に関する追加情報を要求したり、遅延を報告したり、または以前にこのオブジェクトにサービスを提供したことのある別の専門家など、必要な参加者を議論に招待したりすることができます。
これで、アプリケーションを別の専門家に転送するときに、新しい従業員は以前のアクションに関する必要な情報をすべて利用できるようになります。
したがって、サービス デスクの導入により、Brant はすべてのプロジェクトを XNUMX つのシステムに統合できるようになりました。 さらに、会社を沈没させる恐れのある日常的なプロセスが大幅に削減されました。サービス オブジェクトの数が増加したという事実にもかかわらず、同様のタスクの数の増加をカバーするためだけに新しい従業員で人員を増やす必要はありませんでした。
出所： habr.com