PMの目から見たサービスデスクのデジタル変革

私の実践からのいくつかの話-サービスデスク（SD）の方向の問題と、スクラム自動化プロジェクトを開始することによるそれらの解決策について。

過去への遠足

私はICLサービスで4年以上働いており、大規模なプロジェクトの技術サポートスペシャリストとしてスタートしました。現在、私はITSMグループをService Deskの方向に導きます。 私の能力は、ITSMシステムの展開と構成、ITプロセス管理（インシデント、変更、問題管理）に集中しています。実際、私は誇張せずに言うことができます：SDの分野で最も熟練した人々は私のグループで働いています。



就職してから約6ヶ月間働いてから発見した大企業の特徴は次のとおりです。人々がベストプラクティスを共有することはめったにありません。彼らが貪欲だったからではなく、単に彼らが非常に怠惰すぎて同僚に利点が何であるかを説明できなかったからです。結局のところ、よくあることですが、ほとんどの場合、ここの全員は長年の関係を持つ技術者でした。



そして、私が来ました-そして、1つは作業の一部を自動的に実行できる豪華なスクリプトを持っており、もう1つはクラウドアプリケーションでシフトのスケジュールを保持し、シフトを混乱させることはありません（そして、私たちがまだExcelを使用していた密集した時代に）、3番目は簡単なものを書きましたITSMシステムのタブを切り替えてアプリケーションをチェックするときにそれらを開く時間を無駄にしないように、アプリケーションのすべてのフィールドを1つの画面に表示するWebアプリケーション。



しかし、これらの開発は個別のままであり、同様のプロジェクトでの実装は言うまでもなく、プロジェクトチーム全体と共有されませんでした。私のリーダーが言ったように、私たちは常に自分たちで自転車を再発明してきました-そして私はその場合に正しかったです。もちろん、人的要因もありました。たとえば、経験豊富な人がいて、「若者」のベストプラクティスを使用できませんでした。そして、特別な古典-「 しかし、彼とは個人的な対立があるので、私は彼が使用するツールを使用しません。」



それは私にとって成功し、一般的に私たちの部門全体にとって、プロセスへの新しいアプローチが導入され、テストされました。大量のドキュメント、ユーザーやサポートグループからの遠吠え-すべてが通常どおりです。私は見た改善をなんとかやり遂げることができましたが、最も重要なことは、ほとんどすべての人が一緒にサービスに取り組むことに成功したことです。結局のところ、問題に対して団結したチームが何ができるか知っていますか？問題はチャンスがありません。顧客は新しい指標、つまりアプリケーションに記入する際のエラーの割合を導入しました。当初、チームあたり約10％でした。つまり、約200のアプリケーションに、マイナーエラーと重大エラーの両方がありました。



ラインマネージャーとプロジェクトマネージャーは次のように述べています。「エラー率をこれ以上減らすこと はできません。人は人であり、常に間違っています。"。主要なスペシャリストが作成したWebアプリケーションを複製し、コントロールポイントを設定し、これらのインジケーターに関する情報を定期的に取得して、特定のケースを解決しました。ITSMシステム自体がActive Directoryの必要なフィールドを置き換える場合、何を探すべきか。結果はすぐに現れました。6か月で、1か月あたりのエラーの割合がチームあたり0〜0.6％という非常に低いレベルになりました。



そして、私のキャリアのこの時点で、私は2つのことに気づきました。

1. 私はクールなチームで働きたいと思っています、そしてその全体の仕事の結果は最も独創的な従業員でさえできることよりはるかに良いです。この決定は間違いなく後で私を経営に導くでしょう。
2. 才能あふれるクールな人たちの業績を、以前よりも優れ、信頼性が高く、高速な単一のシステムにまとめたいと思います。

プロジェクト開始

2019年、私はデジタルSDプロジェクトを主導するように提案されました。その中で、機械学習、さまざまな音声およびテキストボット、オムニチャネルプラットフォーム、自動分類、自動解決アプリケーションなどの最新テクノロジーを利用して、サービスの競争力を高める必要がありました。言い換えれば、サービスを提供するための人件費を増やすことなく、クライアントの経験を新しいレベルに引き上げるすべてのもの。

正直なところ、AIに関する誇大宣伝全体を振り返った後、最初はこのタスクに非常に懐疑的でした。そして、方向は正しく、目標は良いようですが、ここで何かが間違っていました。







そして、キャッチは、開発する必要があるものを正確に誰も知らなかったということでした。たくさんの方向性があります、何をつかむべきですか？通常、記事や本のそのような瞬間に、彼らは自信を持って次のように書いています。「それでも、私たちはどこにどのように移動するかを知っていました。」だから、これは私たちのことではありません。私は製品の所有者と一緒に立ち、製品を設計するときに答える必要のある質問のリストを作成しました。

1. ユーザーと顧客にどのような便利な機能を提供しますか？
2. これは現在のサービスにどのように統合されますか？
3. これが機能し、有益であるためには、現在のワークフローをどのように変更する必要がありますか？
4. これはどのように、どのテクノロジーで行う必要がありますか？
5. 経済的なソリューションモデルをどのように構築する必要がありますか？

しかし、私たちは非常に慎重にそれを行いました。プロジェクトマネージャー、ラインマネージャー、技術専門家の中からSDから専門家のグループを集め、ユーザーストーリーを書き留め、バリューマップを作成しました。







これはその一部です 。並行して、開発者と一緒にトップレベルアーキテクチャについて説明し、プロジェクトの開始点を取得しました。 ..。

SCRUMの仕事

だから私たちの紹介：プロダクトオーナー、PM、スクラムマスター、そして開発チーム。2週間続く作業スプリント。タスクは、次のような方法で製品リリースプロセスを整理することです...







しかし、真剣に、すべての利害関係者の要件を考慮し、苦痛に対処し、本当に何をする必要があるか、後で何ができるか、何をしないかを理解する必要がありました。



3つの大きな活動領域がありました。

1. 進行中のサービスプロジェクトにおける自動化のための製品。これには、サービスを提供するための人件費の削減、顧客満足度の向上、および付加価値の提供に役立つすべてのものが含まれます。
2. 新規顧客向けの製品。開始時にすごい効果を生み出し、クライアントを「フック」するもの。
3. 組織の内部タスクを自動化するための製品。人事、マーケティング、IT、管理サービスなどのタスク。

プロジェクトマネージャーは痛みについて話し、サポートサービスのリーダーは願いについて話しているので、私たちは3番目のスプリントによってのみ通常の作業を確立することができました。







記事を拡張することはせず、Agile自体がいかにクールであり、それがどのように役立つかを説明します。しかし、このモードで約30スプリント作業した後、私が実際に言えることは次のとおりです。

• スクラムは実用的なアプローチです。あなたは資源と方法論を投入し、そしてあなたは物資を手に入れます。
• – . , , , . , , , , « », – .
• . , , . , , – . PM – , , , – , – .

私はこの種の経験が少ないので、この大きくて重い負担はプロダクトオーナーに大きな負担をかけました：利害関係者の期待を現実と比較し、私のチームの能力を明確に理解し、目をきれいにし、市場の状況を理解し、リソースを有用な機能に向けるバランス、実験および「必要な悪」-ソリューションのセキュリティ、サービスアーキテクチャの編成、環境、ドキュメント。

• PM . , . -. Devops , , : , /. , , Agile - , : , , .
• - – . , -. , . , PM -, . , . , , !

ゼロから開発を始めたわけではありません。何らかの形で使用できる会社で多くの開発がありました-2つの自動分類器だけがありました。

最初のプロジェクトで開発を収集したことがあるので、さまざまなプロジェクトや部門からこれらすべてを収集したときに、déjàvuを感じました。



私たちはいくつかのオープンソースライブラリとの対話システムの開発を開始しました-そしてそれらの1つはDeepPavlovでした。私たちはそれについてあまり経験がなく、私たちの仕事では認識の質は平凡であることがわかりました。すぐにRasaに切り替えましたが、状況ははるかに良くなりました。特定のデータでモデルをトレーニングした後、対話をしっかりと自信を持って認識できるようになりました。



ダイアログ自体のレイアウトは手動で行われました。その時点で、SDにこのタスクを引き受けた人がいました。私たちの主要なPython開発者はすぐにマークアッププログラムを作成し、モデルに数万の会話を提供しました。フラグメントはかなり短く、それぞれ3秒で取得されました。これにより、結果がより良くなりました。



当初、WindowsとLinuxに2つの仮想マシンがありましたが、一部のサービスはWindowsでしか機能しませんでした。しかし、最初の開発をパイロットに入れ始めたとき、1つのプロジェクトに2つの仮想マシンが高すぎることにすぐに気付きました。それをやり直す必要があります。現在、Ubuntuで1台の仮想マシンを本番環境に使用しています。もちろん、それらはすべて分離されており、各プロジェクトには独自の領域があります。



また、2つの仮想マシンのセットアップ、すべてのサービスの起動とデバッグ、ポートのオープン、およびその他の設定には、まったく無作法な時間がかかることにすぐに気付きました。次に、DockerをベースにしたCI / CDソリューションを、メインコードとML部分の両方で作成しました。



9〜10回目のスプリントのどこかで、多くのお客様から独自の音声認識システムを作成してほしいという要望に直面しました。ほとんどのお客様は、機密情報を「クラウド」からサードパーティに転送する準備がまったくできていませんでした。そのため、このようなシステムを作成しました。たとえば、州に密接に関連する企業の場合など、アーキテクチャ全体をセキュリティ境界内に配置することが重要な場合に提供できます。または、機密データがサードパーティに送信されないことを確認して、インフラストラクチャに配置します。

コンポーネント監視システムを導入し、ヘルスチェックを設定し、システムをTelegramのチャットチャネルと統合しました。



そして最後に、自分のチャットボットを設計するときに誰かに役立つかもしれないもう1つの微妙な点について説明します。当初、すべてのコードは非常にモノリシックであり、変更を加えるのは面倒でした。チャットボットは、ベースボットとカスタマイズの2つの大きな部分に分かれています。ロジックを書き直す必要がありましたが、この分離のおかげで、ボットの基本コンポーネントと共通コンポーネントをすばやく展開し、特定のプロジェクトごとにカスタムされたものだけを編集できました。

プロジェクトの結果

私たちは、私たちの歴史のニッチな性質を明確に理解しました。私たちは、12年にわたって開発された箱入り製品と競争することができず、その必要はありません。私たちのニッチは、プレセールから契約満了まで、サービスプロジェクトのあらゆる段階で自動化ツールを提供することです。言い換えれば、当初はGoogleを作るという目標はありませんでしたが、目標はService Deskの販売を支援し、サービスを提供するコストを削減し、顧客とそのビジネスに追加の機会を与えるデザイナーを作ることでした。



また、私自身にとって興味深い点も指摘しました。市場に出回っている箱入りのソリューションが、顧客の苦痛を完全にカバーし、同時に価格を調整できることはめったにありません。顧客が後で使用しない機能に対して過大な支払いをするか、または改善の一部は、専門家または選択したベンダーの専門家がそれを採用した場合に行う必要があります。



そして、ここでは、純粋に独自の自動化ソリューションを提供することに加えて、すでに市場に出ている開発およびサードパーティソリューションから顧客向けのシステムを構築し、顧客の機能に適合させ、そのようなシステムをサービスとして維持するための、興味深く、かなり難しい統合タスクがあります。興味があれば、次の記事でこの作業の結果について話すかもしれません。



私たちのツールと開発のほとんどはすでに現在のサービスに実装されており、いくつかを試験運用しており、BAUでいくつかを改良する予定です。チャットボットは依然として最悪の事態を感じていますが、今日ではプロジェクトにとって最も役に立たないものです。おそらく、期待が非常に高くなっているためです。誰もが、人間の会話を認識し、すべてのユーザーの質問に冷静に答え、中断を処理でき、すべてのシステムに統合され、人間の介入なしに自分自身を学習し、時間の経過とともにますます多くの意図を認識することができるスマートボットを望んでいます。



しかし、このトピックに精通している開発者なら誰でも、このタスクがいかに難しいかを理解しています。結局のところ、機能を増やし、ボットが認識できる意図の数を増やしても、既存の意図の認識を悪化させる可能性があります。しかし、これは逸脱でした-一般的に、私たちはそれにもかかわらず、プロジェクトの主要なタスクに対処したように見えます。

出口で何が起こったのか

1. インテリジェントな音声アシスタントおよびそのためのスクリプトデザイナー。設定に応じて、着信コールフローを自動化し、ユーザーの音声、音声からテキストを認識して、メール、チャット、ITSMシステムに送信する必要をなくします。既製のコネクタ、または私たちが作成したコネクタのいずれかを使用して、さまざまなシステムと統合できます。



2. 音声アシスタントのエンジンを搭載したダイヤラー。指定された番号のプールを呼び出す必要性を閉じ、シナリオに応じてユーザーの応答を収集します。定期的な電話が可能です。繰り返しの質問の回数を設定して、何回、何時に電話をかけ直すかを明確にします。発信された通話に関するデータを、通話結果および通話記録とともに保存します。現在では、大規模なファストフードレストランチェーンで解決されたアプリケーションの品質に関する情報を収集する計画で、大規模なポジションのインタビューを整理する際に、HR部門で、大規模な国際食品小売業者向けに実装されたプロジェクトのパッチ適用についてエンジニアに思い出させるために使用されます。







3.アプリケーションを作成し、パスワードをリセットするための チャットボットとそのスクリプトデザイナー。リクエストを登録するための主要な情報を要求し、ITSMシステムにリクエストを登録し、リクエスト番号を返す方法を知っています。記事が公開されるまでに、開いているアプリケーションのリストを表示し、それらに情報を追加したり閉じたりすることができるようになります。 apiアクセスの有無にかかわらず、さまざまなITSMシステムに接続できます。











4. 品質管理のためのツール。彼はこれまでのところ少し知っています。彼は通話を追跡し、オペレーターが挨拶したかどうかを認識し、競合を生成する単語を識別し、対話で交尾し、品質管理者のための本格的なインターフェースを備えています。彼らは自分たちでそれをしました、しかしそれはCCで役に立ちます。







5. 自動分類子。彼はITSMシステムでアプリケーションを解析し、それらに入力して、必要なソリューショングループに送信することができます。エンジニアの可用性、作業負荷、専門性を考慮に入れる場合があります。たとえば、すべてのEDSアプリケーションをメインスペシャリストのVasilyまたはAndreyに送信するようにロジックを設定できます。Vasilyが勤務していない場合、アプリケーションはAndreyに送信され、その逆も同様です。両方でない場合、チケットは一般的な基幹業務アプリケーションのサポートに追加されます。 Vasilyに2つのアプリケーションがあり、Andreyに1つのアプリケーションがある場合、新しいアプリケーションがAndreyに送信されます。自信を持ってモデルを再トレーニングし、精度を高めることができます。 システムの欠点はそのポイントです。モデルから100％の精度を期待したり、アプリケーションのボリューム全体で作業したりしないでください。テストサンプルでは、​​ユーザーがテンプレートの操作に慣れている非常に一貫性のあるデータを使用して、50％のアプリケーションで90％の精度を実現しました。 2つ目の欠点は、注文量です。 1か月あたりのアプリケーション数が1000未満の場合、モデルをトレーニングすることは意味がありません。



6. アプリケーションを自動解決するためのツール。これは、テクニカルサポートエージェントの標準アクションを自動化するスクリプトを備えたGUIのツールのセットです。システムからのログの収集、シャドウモードを含むスクリーンショットの取得、ポリシーの更新、および各プロジェクトに固有のその他のことです。2番目のツールは、承認が必要なアプリケーションの自動化です。ツール自体は、承認/拒否へのリンクを含む承認者へのレターを生成し、その結果に基づいて、アクセスを許可するコマンドを提供するか、拒否を含むレターを生成します。

さよならの代わりに

冬が来て、プロジェクトは今年の終わりに終了します 。Cyber​​punk2077が欲しいのですが、これだけではありません。つまり、まだ多くの組織的な作業が必要です。



あなたの興味とあなたの時間をありがとう、病気にならないでください！