中央のCarPriceハブは、誰かが到着するのを待って車を捨てるだけの警備された領域ではありません。 倉庫に到着したすべての車は技術検査を受け、書類を準備して整理します-バッテリーの充電、燃料の追加、液体の洗浄など。 そして、販売の前に、彼らはディーラーのために追加の試験を組織します。
ディーラーは予想外に到着します-フローは非常に不安定でした。 倉庫の従業員は、自分で何をすべきか分からずに、車から車へと舌を突き出して走ったか、または「bamboo製竹」を使い果たしました。 あるディーラーはすぐに1ダースの車を取りました-早朝から深夜まで丸一日かかりました。
予約システム
作業を効率化するために、レコーディングサービス（予約、別名電子キュー）のためのシンプルなユニバーサルサービスを作成しました。 その中で、車の受け取りは、検査と発行という2つのステップに分けられます。 第1には、検査の準備と、倉庫管理者の立ち会いのもとでのディーラーによる車自体の検査が含まれます。 その後、ディーラーは車の代金を支払い、発行ステップに進みます。発行ステップでは、文書に署名し、キーを転送します。 検査と発行は異なる日に行うことができ、一部のディーラーは検査なしで発行のためにすぐに記録され、一部のディーラーは1台の車を数回検査します。
録音サービスは最初は複雑なシステムではなく、シンプルで理解しやすいタスクを解決しました。倉庫の従業員の勤務スケジュールを考慮して、サービス（ステージ）のタイプと期間に応じて空きスロットを計算しました。
ディーラーはあなたの個人アカウントにログインし、最終倉庫からオークションで勝った車の1つ、サービスの種類（検査または配送）を選択し、空きスロットに記録します。
これは、デスクトップとモバイルアプリケーションの両方から実行できます。 何らかの理由でディーラーが自分で登録できない場合、個人のマネージャーまたは倉庫の従業員が記録することができます。
このようなスキームは多くの企業でうまく機能しており、サービスを統合するとすぐにすべての問題が消えることを期待していました。
問題は消えません
しばらくして、システムが実際には機能しないことを理解しています。 その理由は、ほとんどのディーラーは非常に時間厳守ではないということです。彼らは約束なしに、約束された時間よりもずっと遅くまたは早く、時には別の日にさえ到着します。 同時に、それらは発行のために記録され、検査のために来ます。 彼らは1台の車の検査を示し、さらに5台の車を見せることを要求しました。 一部のディーラーは、特定の倉庫管理者とのみ協力したいと考えています。 しかし、多くのディーラーは非常に感情的であり、矛盾に耐えることができません。 このような予測不可能性により、倉庫のスタッフは、どの群衆の激怒ディーラーを雇う必要があるのか、どの車を検査の準備をするのかを理解していません。 私たちは、新しいソリューションを導入することを考え、考え、決定しました。
電子キュー
アイデアは有望でした。 マネージャーは、誰を雇うかを考える必要はありません。「次へ」ボタンをクリックしてから進みます。 ディーラーは、倉庫の混雑を理解し、キュー内での自分の位置を確認し、どれだけ待つべきかを知っています。 サービス時間の監視結果に基づいて、スロットを動的に調整し、SLA違反の場合は管理者に通知できます。 また、検査/発行のために、倉庫のターミナルから直接登録できます。
バックエンドでは、オペレーター間のタスクの分散を含む、アプリケーションのロジック全体を実装する必要があります。 フロントコンポーネント：
- 電話番号による承認、サービスの記録、利用可能な車の表示、有料サービスの接続、記録クーポンの発行を行う端末
- 作業中のキューと現在のクーポンを視覚化したダッシュボード
- オペレーターコンソール（倉庫マネージャー）
技術的な観点から、ディーラーは、自分の個人アカウントで車の検査を予約することで、記録可能な車のリスト、空き日と時間の受信に応じて、バックアップ予約サービスに要求します。 メインのケースに加えて、システムは他の「重要な」ケースを処理する必要がありました。
- ディーラーがサインアップ、到着/未到着
- ディーラーはサインアップし、時間通りに到着し、30分でスロットに入れました
- ディーラーがサインアップし、15分、40分、100分後に到着しました。
- ディーラーはVIP発行のために登録/到着しました
- ディーラーは30分でスロットにサインアップしました-実際には10分/ 2時間でした
- ディーラーは検査にサインアップし、到着し、検査し、支払いに行き、40分後に車を取りに戻りました
追加の要件がいくつかありました。
- 倉庫の従業員のスケジュールを柔軟に調整し、誰でも提供できるサービスを表示します。 従業員の勤務スケジュールが重複しているという条件のもとで、これらすべては、9から18と13から22の2つのシフトがあります。
- 新しい倉庫のシステムへの迅速な接続
- 他のサービスとの統合-現在の予約、ディーラーの承認など。
- 簡単な垂直および水平スケーリング
- リアルタイムインターフェース
要件は超越的なものとは思えなかったので、私はそれに没頭してバンプを埋めたくありませんでした。 電子ラインナップは既に十分に開発されたトピックであると考え、所定のビジネスケースにアプローチする方法を知っている既製のボックスソリューションを備えた請負業者を見つけることにしました。
私たちは自分自身を開発します
請負業者を探しても何も得られませんでした。 ほとんどのターンキーソリューションには、非常に原始的なアルゴリズムがあります。 クーポンは1つの一般的なキューに追加されるか、分類され、オペレーターはキューからクーポンを交互に引き出します。 それだけです 柔軟な構成はなく、オペレーター間でクーポンを配布するロジックもありません。また、システムは通常Windowsでのみ機能します。 内部サービスとの簡単な統合については説明しません。 同時に、全員の値札は宇宙的です。 それにもかかわらず、私たちは1人の請負業者と仕事を始めましたが、彼には必要な機能の10パーセントがあり、他のすべては長い間カットされなければなりませんでした。 そこで私たちは解散し、自分で電子キューを書くことにしました。
この時点で、すべてのニュアンスに関するニーズをすでに明確に理解し、すぐに実装を開始しました。 バックエンドは、Laravel、PHP 7、RabbitMQ、Percona、Websocket、およびDockerのすべてを使用して、以前に作成された予約サービスに基づいて作成されました。 フロント全体がWebソケットに実装されたため、リアルタイムのインターフェースを作成できました。
端末は、iPadが隠れている金属ケースから組み立てられました。 ケースはタブレットを盗難から保護し、正しい位置に固定します。
タブレットでガイドアクセスが有効になり、コントロールのないフルスクリーンブラウザーで、Vue.js（SPA）上のサードパーティアプリケーションが起動します。 まず、ディーラーはSMS（JWT）を介して端末で認証されます。 承認後、彼は検査/発行のために自分の記録を見て、それらのクーポンを受け取ることができます。 ディーラーは、個人の財布に鍵を掛けてVIPサービスにアクセスできます。
検査と配送の各レコードは特定の倉庫管理者に事前にリンクされており、可能であれば、同じディーラーの他のレコードと自動的にグループ化されます。 マネージャーを拘束する場合、従業員のスケジュールと作業負荷、ディーラーでのその他の計画された記録の可用性、およびその他の要因が考慮されます。
ディーラーのアカウントで予約をすると、お金はブロックされ、クーポンを受け取ると返還されます。 クーポンが期限内に受け取られなかった記録は自動的にキャンセルされ、虚偽のエントリのお金はディーラーの口座から引き落とされます。 受け取ったクーポンから、記録時間とディーラーの期待、記録のタイプなどを考慮して、作業マネージャー間で分配されるキューが形成されます。
VIPには別のキューがあります。ディーラーは「今」のクーポンを受け取り、同じVIPからのキューがない場合はすぐにマネージャーとのミーティングに行くことができます。 このサービスは、有料ではあるが、予約なしで到着した、または遅れて待ちたくないディーラーの間で大きな需要があります。
システムの別のコンポーネント-ダッシュボード-どのチケットがどのオペレーターによって提供されているかを示します。 さらに、彼は現在のキューを表示し、ディーラーに声でオペレーターに進むように勧めます。 実際、これはネットトップが接続された通常のテレビで、フルスクリーンブラウザーが起動され、特定のウェアハウスのパラメーターでVue.js（SPA）アプリケーションが開かれます。
オペレーターは仕事用のリモートコントロール、つまり職場のラップトップを持っています。
オペレーターのインターフェースはラップトップで開いており、承認後、レコードの作成、変更、キャンセル、サービスの結果の記録、顧客の転送、顧客との作業の延期が可能です。 特定の権限がある場合、このインターフェイスを使用して、マネージャーとその可能なサービスの勤務スケジュールを構成できます。
各ウェアハウスの個別のインターフェースを使用して、SLAを詳細に構成できます。 これにより、電子キューを任意の数の新しい倉庫に簡単に拡張できます。
SLAにはさまざまな設定があり、多くの指標に従って倉庫の作業を監視します。
新しい電子キューシステムは、さまざまな困難なケースの解決に役立ちます。 以下に例を示します。
- ディーラーは数台の車にサインアップしましたが、非常に遅れ、その半分が期限切れになりました。 記録は部分的に期限切れであることが判明したため、ディーラーはまだ端末でそれを見て、チケットを受け取ることができます。 オペレーターのコンソールのマネージャーは、一部のサービスの有効期限が切れていること、クーポンなしでクーポンを使用して作業を完了すること、またはアクティブなサービスの一部を削除して期限切れのサービスを追加できることを確認します。
- ディーラーは車の検査と発行に来ましたが、車には欠陥がありました。 今、ディーラーは引き渡しを必要としませんが、払い戻しの請求の形成。 オペレーターのコンソールで、マネージャーは1つのボタンでこれを行うことができます-サービスの種類を発行から請求に変更します。
- ディーラーは1台の車を検査するために来ましたが、別の車を検査したいと考えています。 オペレーターコンソールのマネージャーは、チケットの検査のためにマシンを交換できます。
Telegramを介したSLAの監視
上記のSLA設定のスクリーンショットを注意深く見ると、メッセンジャーに関連する行がそこにあります。 以前は、倉庫の従業員は仕事ではなく1時間タバコを吸っていたため、同僚は緊急モードに切り替える必要がありました。 今、従業員が仕事に行き、長い間ディーラーを雇わない場合、経営者はこの種の通知を受け取ります：
または、ディーラーに関するこれらの警告は次のとおりです。
ディーラーと一緒に働くマネージャーに加えて、倉庫には定期検査時間に備えて車を準備している技術者がいます：彼らは雪の吹きだまりから掘り出し、燃料を注ぎ、洗浄し、バッテリーを充電し、エンジンを暖め、閉鎖された駐車場から車を運転しています。 別のチャネルを使用すると、エンジンを起動する機能について学習し、トレーニングを迅速に完了できます。 興味深い投稿を次に示します。
ただし、このオプションはおそらく最も独創的なものです。
まとめ
新しい電子回線の助けを借りて、倉庫内の混乱を克服し、ディーラーの生活を簡素化し、多くの追加サービスを提供しました。 ビジネス指標をリストすると、ディーラーの待ち時間が3倍に減少し、否定的なフィードバックの数が4倍になり、同じ従業員数の倉庫が1日あたり3000台ではなく3000台の車を通過できるようになりました。 おそらくシステム上で計画中に、クーポンを紙に印刷するプリンターを設置することを除いて。
現在、モスクワのオフィスでQAスペシャリストおよびバックエンド開発者を探しています。 フィードバックをお待ちしています！