ストーリーは、チャットボットのHRシステムにアクセスする必要があるという事実から始まりました。 後者は、「ピクニックを修正できる人を見つける」など、要求に応じて従業員の連絡先を検索できるようにします。 企業インフラストラクチャでは、次のようになります。自動化部門に行き、HRMSからのデータが必要だと言います。 そして、自然な答えが得られます。
-TKを作成して、6か月後にAPIと統合サーバーを提供します。
-みんな、どうして？ 早くする必要があります！
-TKと頭に手紙を書いて、私たちは3か月を緊急に満たすことができます。
そして、3日間でした。 したがって、私たちは別の方法で行った。彼らは人事担当者にボットの従業員リストに私たちを入れ、システムへのアクセスを許可するように頼んだ。 それから彼はすでに男ができることを彼の代わりにやった。
その結果、プログラマーが権力を握ると、議会全体を単純なbashスクリプトに置き換えることができるという古いジョークは、そのようなジョークではありませんでした。 もちろん、私たちのロボットは、今後数年間、アーキテクチャの点で最適ではありませんが、機能します。 彼らが何をするのか、そしてそのような用語はどこから来たのかについて、私は今あなたに話します。
そのため、主なアイデアは非常に単純です。ユーザーのアクションをシミュレートするロボットを使用できます。 たとえば、人事システムにアクセスする必要がある場合、統合サーバーを構築してAPIを取得する必要はありません。 必要なボタンを押して回答を解析するようにロボットに教える必要があります。 幸いなことに、ほとんどすべての最新のインターフェイスは非常にロボットに優しいです。MSソフトウェアには、代替アクセス、ホットキー、または認識可能なアイコンのコントロールのタグがあります。 正しい順序で正しいボタンを押すようにロボットに教えるだけです。 Wordのマクロのようなプロセスを自動化するか、Photoshopでアクションを記録するのに約1時間かかり、残りの90％はテストと例外処理です。
ユーザーがインターフェースのボタンをクリックします。 その後、データが収集され、ロボットが起動します。 たとえば、チャットボットはスクリーンショットを取得できないため、個別のインターフェイス（フロントエンド）としてのボタンが必要です。 しかし、彼はボタンについて話すことができます。ユーザーはすべての質問をメインインターフェイスとしてチャットボットに向けることができるという事実に慣れているからです。 Chatbotはロボットも起動します。
一般に、ユーザーはいずれかのインターフェイスを介してタスクを設定します。 たとえば、チャットボットを介して従業員のデータベースにリクエストを送信します。 インターフェースは処理ロボットに一貫したデータを転送します。つまり、指定されたパラメーターでスクリプトを実行します。 ハンドラーはユーザーをエミュレートし、お尻で何かをしてから、結果をインターフェイスに送信します。
それは：
-ロボットを起動するためのインターフェイスがあります。これらは、チャットボット、ボタン、スクリプト、イベント、タイマー、または他のロボットのアクションです。
-ロボットのアクションがあります。これはデータの取得と変換です。
-そして、ユーザーに結果の結論があります。これはチャットボットの応答インターフェイスにアップロードし直され、結果はメールでファイルに保存されるなどです。
ロボットがシステムにログインしてパスを作成する方法の例を次に示します。
私は熱意を冷やすために急いで
はい、非常に高速です。 はい、これは組み込みのAPIまたは統合サーバーによる完全自動化と比較して非常に安価です。 しかし、いくつかの欠点があります。
- ロボットはシステムのユーザーをエミュレートします。 これは、このシステムに別のワークステーションが必要であることを意味します。 つまり、ユーザーまたはマシンのライセンスを取得する場合、追加のライセンスが必要です。
- ロボットは人間よりもはるかに速く動作しますが、ヒューマンインターフェイスを使用します。 つまり、8時間で人が行うこと、4分で条件付きで行うことです。 ただし、これは、API統合の場合のように2秒ではありません。ロボットは、インターフェイスの読み込みと完全なレンダリングを待機しています。 これは、ロボットサーバーがバルク要求でビジーになる可能性があることを意味します。 複数のマシンが必要です=オーケストラが表示され、同時に複数のストリームを使用するにはより多くのライセンスが必要です。
- ユーザーのアクションをエミュレートするロボットは、大規模なシステムの更新に敏感です。 インターフェイスが大幅に変更された場合、ボットの再構成が必要です（これには3〜10営業時間がかかります）。
- ロボットは自分自身の代わりに行動することはできません（自分自身でログインします）。毎回特定のユーザーの代わりに行動します。
後者については、個別に説明する価値があります。 たとえば、人事システムに遭遇したとき、特定の問題が発生しました。 人事担当者と同じ権限を持つボットのアカウントをシステムに入れる必要がありました。これにより、HRSM、Outlookをメールおよび連絡先、カレンダーとともに使用できるようになりました。 ロボットが尻で動作するという事実に至ったとき、それはすべての人をイデオロギー的なショックとst迷に陥れました。
ルールは単純です。各従業員の権利は人事管理システムで指定されています。 そこからアクセスします。 人間であるため、HRMSでロボットを起動することはできません。 また、アカウントと連絡先のデータはそこにのみあります。 従業員が働くためには、彼は人でなければなりません。 その結果、アルファの場合、開発者アカウントを取得し、彼に代わってロボットを起動しました。 これは、ロボットのすべての側面をその上に記録したことを自動的に意味します。 ベータ版では、より興味深いライフハックを思いつきました。（このロボットで構成される）カウンターパーティを取得し、システムの責任を負う開発者と一緒に立ち上げました。 それにもかかわらず、ロボットが何か間違ったことをした場合、どうにかして彼を法廷に導き、答えさせなければなりません。 そして、私は怠慢と相手方の適切な検証の欠如をはんだ付けします。
そしてもう1つの欠点：はい、ロボットが間違っている可能性があります。 私たちのポリシーは、見ている人がいなければ取り返しのつかない行動ではありません。 つまり、ロボットは出張のためにすべての文書を準備し、自分で注文することができますが、後者は許可していません。 彼はすべてのドキュメントをネットワークボールに入れて出張部門の従業員に渡し、すでに会社のお金を使っています。 まれなバグのために、2,000人の従業員のオフィス全体を出張でアナディルに送りたいとは思わないからです。
したがって、ロボット工学の最初の法則があります：ロボットは人に代わってすべてを行います。
次に起こったこと
ボット用のアプリケーションをさらに多数用意しました：チャットボットでのレポート、1Cに追加するためのTelegramへのプライマリドキュメントのダウンロード、ドキュメントの記入に関するダイアログ、旅行レポート、レポート用のドキュメントの一括作成、すべての参加者への送信。 などなど。
これのほとんどすべてが2日間で行えることが判明しました。 上記の制限付き。
ロジックは次のとおりです。すべてが機能する場合、ロボットが時間をどれだけ節約するか、誰かがそれを使用するかどうかを評価できます。 すべてを「気持ちよく、実際に、アレンジで」行う必要があり、顧客が多くの時間を費やしている場合、もちろん、タスクを自動化部門に転送することができます。 ユーザーインターフェイスは同じであるため、彼は移行に気づきさえしません。 バッジや証明書の印刷などのタスクを迅速に自動化する必要がある場合（イベントの方向から私たちの女の子のために2泊かかりました）、ロボットは動作します、それだけです。
進化はこれです：
1.プロトタイプまたはそれほど責任のないタスク
2.操作の段階
3.責任あるサービス
そして、危険な神話が生まれました。 私たちのトップがそれがどのように機能するかを見たとき、彼らは「労務費ゼロ」という言葉でプロセスについて言いました。 したがって、これはゼロではありません。 はい、ラピッドプロトタイピングの場合、すべてを2日で完了できます。 通常のデバッグの場合、2週間。 ただし、動作するものはすべて、ユーザーエミュレーションではなく、API駆動型または体系的なものに置き換える必要があります。
別のロボットが誰かに代わって行動します。 私たちの場合、それはチャットボットで許可されたユーザーに代わって動作します。 私たちは外に出さない-したがって、ロボットは誰かに注文することはできません。 インターフェースからミドルランドまでのすべてのレベルで保護されているハードチェック。 フォームに入力されたデータの正確性は、ボット自体によってチェックされます。 インターフェースボット（チャットボット）はデータ入力のロジックをチェックし（旅行は今日の日付より早くなることはできません）、実行中のボット（ユーザーエミュレーター）は着信データの整合性をチェックします。
最初のアプリケーションはトレーニング部門でした。 彼らにとってそれは本当の魔法でした。 女の子は参加者のリスト（および場合によっては200人）をBPMシステムにアップロードし、ロボットは5〜6分で次のことを行います。
- 注文はまったく通ります。
- テンプレートに応じたバッジの種類と証明書の準備。
- 有名なサプライヤーからのケータリング（食べ物、コーヒーブレイク）をすべてカウントします。 現在の実装では-1つ、技術的には1つであるため（ボットの前に選択が行われます）。
- 配布資料を作成し、タイピングまたは秘書に送信します。 たとえば、セキュリティ、トレーニングルームエンジニア、サウンドエンジニアなど、それを必要とするすべての人に警告します。
- 会議を開催し、すべての参加者への招待状、会場への地図、責任者の連絡先、イベントのプログラムを送信します。
- みんなに1日思い出させる。
各タスクは個別のマイクロサービスです。 もちろん、これらすべてを維持することは困難ですが、開発するにつれて、これらのマイクロサービスはターミナルサーバーでユーザーをエミュレートするのではなく、より高度な自動化を行います。 これにより、ロボットをアンロードできます。それ以外の場合は、スレッドが4つしかないため発生します。
その結果、この部品は操作性に優れていることが証明されました。 テクノロジースタックは次のとおりです。
最も難しい部分は、フローを分散するロボットオーケストレーターです。 私たちは、約2,000人の大規模なオフィスを持っています。 オーケストラは、ロボットの制御、タスクの割り当て、ロボットのタスクスケジュールの設定、作業の監視、ジョブキューの管理、ロボット間のタスクの分割などに必要です。技術的な観点からは、別のエンティティが必要です。さまざまなボットの仕事に。 テスト中、ロボットの忙しさのために多くの否定性がありました-それはシングルタスクです。 1つのロボットが対応せず、タスクの実行時間がかなり重要な場合、2番目のロボットを（追加ライセンスのために）支援する必要があります。 タスクの実行時間が重要でない場合、タスクはキューに入れられ（オーケストラを使用）、ロボットが解放されると、キューに入れられたタスクが完了します。
その結果、開発者たちはすでに指を向けており、まさにスタッフを大幅に削減できる人々だと言っています。 私たちは彼らが私たちを打ち負かすことを少し恐れていますが、私たちは誇りに思っています。 そして、政府についての冗談をみんなに伝えます。
参照資料
- オフィスでボットとチャットできるもの
- IVRでできること
- 私のメールはdigital@croc.ruです