シミュレーション最適化：友人の会社のサポートデスクをモデル化し最適化の手助けをする
友人の会社のサポートデスクをモデル化して最適化をサポートするシミュレーション最適化
サポートデスクのスタッフ配置を効率化するためのシミュレーション最適化モデルの作成についてのストーリー。
紹介
それは非常にシンプルな依頼から始まりました。サポートセンターの運営を手伝っている友人が、いくつかの問題に直面していました。いつでも、サポートデスクのエージェントは効率的に最適化されず、スタッフが余分に配置されたり、不足していたりしました。彼は、電話やチャットメッセージ、メールがいつ着信し、電話を待った時間や会話の長さなどをかなり正確なデータで把握していました。私の運用リサーチ（OR）のバックグラウンドを知っている友人は、この問題を私に話しました。私は興奮しました – 私のキャリアでは、私は定期的にOR原則を使用することはありません。これは私が5年間を捧げて学び続けたものに初めて触れる機会でした。
ORプログラムの中核はキュー理論であり、これは文字通りのm / m / cキューの典型的なケースでした。一定の確率的なレートで着信電話があり、複数のエージェントが着信電話を処理し、すべての電話は一定の確率的なレートで処理されるべきで、確率的なレートは指数分布に従うべきです。そこで、Jupyterノートブックを起動し、着信電話と処理時間に指数分布を適合させるためにscipyを使用しました。実際に、私たちは指数分布にかなり近いパラメーターを持っていることがわかりました。
もし友人が単にサポートデスクに何人のエージェントが必要かを知りたいだけなら、それを正確に教えるための公式（主にErlang-Cと呼ばれるもの）があります。[1] ただし、現実のシナリオと同様に、このフォーミュラは、この特定のサポートセンターに影響を与える多くのパラメーターを導入するとすぐに崩壊しました。変動する終日の着信電話需要、エージェントの効率、休憩時間、シフト勤務が必要なエージェントなど、多くの要素がありました。したがって、もう1つのORの中核である「シミュレーション」に取り組むことになりました。
シミュレーション
シミュレーションは、特定の公式に制約されることなく作業できるため有用です。確率論的な入力の性質を利用して、システムが信頼できる平均に収束することを知りながら、シミュレーションの一部を調整し、出力を実世界のトレーニングデータに一致させることで、システムやデータのほとんどの異常を補正することができます。
それでは、作業を始めました。数日後、Pythonで実際のデータ入力を使用してサポートデスクのシミュレーションを構築しました。私のシミュレーションの核となる部分は、一日中の着信電話とエージェントの対応時間の可変性を考慮し、さらにキューの長さやパラメーターの変更時にエージェントが作業することなどを考慮に入れていました。何を測定するかを決める時が来ましたが、オプションは数多くありました。最初はエージェントの利用率や平均的なキューの長さを測定しましたが、サポートセンターの主な指標の1つである接続時間のサービスレベル契約（SLA）に重点を置きました。[2] SLAは、キューでの待ち時間の目標測定としての合意に基づくものです。SLAは、平均だけでなく、一日中の時間帯別の時系列データとして監視することが重要です。サポートセンターは、いつ誰かが電話しても、短くて予測可能な時間内に電話に応答することを目指します。
幸いにも、これはかなり簡単でした。シミュレーションラン中に測定を行うたびに、列の先頭の人がどのくらい待っているかを確認していました。列の先頭の人が一番長く待っていることを知れば、最大のSLAが維持されていることがわかります。彼のデータで私たちはトレーニングと検証のセットを作り、さらに微調整をしました。友人にはエージェントの数や着信呼び出しのパラメータを変更し、SLAにどのような影響があるかを見ることができるツールがありました。このプロジェクトのこの部分も、時間がかかりました。
最適化
あるロードトリップの間、私たちはこのツールが興味深いが必ずしも役に立たないということを話し合いました。友人は数値を入力して何が起こるかを見ることができましたが、それはスタッフの決定を容易にするのに役立たず、基本的には教育的なトライアンドエラーでした。より役立つのは、終日の目標SLAを設定し、可変の着信呼び出しパラメータとエージェントの処理時間に対応する最適なエージェントのスケジュールをシステムが提供することです。これはORの3つ目の偉大な柱である「最適化」です。
問題は、最適化には最適化するための数式が必要であり、私たちはシミュレーションを持っているということでした。しかし、私は気づいたのですが、シミュレーションを最適化問題の目的関数として使用できない理由はありません。それは入力のセットを取り、シミュレーションの十分な実行で確信の持てる出力を提供します。幸いなことに、30年前の研究者たちは同じ考えを持っており、それ以来、シミュレーション最適化の分野を研究してきました。これらの優れた人々が私のためにすべての難しい作業を行ってくれました。[3, 4]
したがって、再び私は取り組みました。シミュレーション最適化の核心は、入力のセットを作成し、シミュレーション上で実行し、次にどの入力を選択するかを賢明な方法で選択することで、目的を達成するまで続けることです。私の最適化問題は次のようなものでした：
私の目標はスケジュールを作成することです。スケジュールはシフトから構成されます。シフトは、エージェントが働くことができるシミュレーションの「日」中の設定された時間です（例えば、9時〜17時、10時〜16時）。スケジュールは、すべてのシフトの集合であり、各シフトで働くエージェントの数も含まれます。良いスケジュールは、SLAを目標のまわりでうまく保ち、労働者の総労働時間（労働者の数*シフトの長さ）を最小限に抑えるものです。特定のシフトには、働くことができる人数の上限があり（例えば、半日の午前シフトには10人しか働けません）、各シフトには特定の休憩スケジュールがあります。SLAは、ターゲットを上回る厳しい天井を超えてはいけません（例えば、私たちの目標は3分のSLAですが、誰も10分以上待つべきではありません）。
これらの制約を考慮したフレームワークを構築し、最適化の準備が整いました。シミュレーション最適化の研究で話されるいくつかの問題は、そのシミュレーションがブラックボックスであるために困難です。つまり、シミュレーションの答え以外には有用な信号が得られません。幸いなことに、このシミュレーションは異なります。私たちはシミュレーション「日」全体で待ち時間を測定しているため、特定のシフトが他のシフトと比較してどのように機能するかを見ることができます。
例えば、朝のシフトには遅いシフトよりも多くのエージェントが配置されていますが、遅いシフトの方が着信呼び出しが多い場合、遅いシフトのほうが目標から逸脱しやすいということがわかるでしょう。次の試みでは、遅いシフトの人数を増やすべきです。
これは単純な問題ではありません。複雑な重なり合うシフトやその他のパラメータがあるため、相互依存関係が存在しますが、どのスケジュールをシミュレーションに組み込んでも何が起こるかを確認することができます。
シミュレーションから得られるこれらの信号は、私を明確な戦略「勾配」へと導きました。
基の探索は、ボールが山を転がって下に向かうことを理解することと同様です。毎回、ボールを下の状態にするように努めて、ボトムに到達するまでステップを踏みます。これは均一な山ではないので複雑です。山のどの場所を選んでも山に逆戻りしてしまう偽の底が存在しますが、真の底に到達するには異なる場所から転がす必要があります。実際には、真の底に到達したかどうかはわかりませんが、かなり近いことを知るために十分なテストを行うための賢い方法が存在します。私たちの場合、ボールはスケジュールであり、山の底はすべての着信呼び出しが目標のSLAに正確に待機する完璧な直線です。
では、最も自然なグラデーションステップは何でしょうか？ 最悪のスケジュール（平均的には目標から最も離れているもの）を選び、平均が目標を上回っている場合はエージェントをシフトに追加し、平均が目標を下回っている場合はエージェントを削減します。すべてのシフト変更がスケジュールを悪化させる場合でも、SLAが目標に十分近くない場合は、以前に良いスケジュールに戻ってそこからやり直します。次のスケジュールを選択する方法には他の方法も試しましたが、これが最も一貫性のある結果でした。いつ終了するかを知る方法は？ 平均的にターゲットから30秒以上離れていない場合（例えば）、それが解決済みとみなします。多くの手順が実行されすぎた場合には停止し、シミュレートされたスケジュールの中で最良のものを選択します。
理想的な世界では、私たちは最適なものを見つけるまでこのプログラムをずっと実行したいと思うかもしれませんが、このプログラムを5分以内にスケジュールを選択するようにする必要がありました。最も興味深い部分は、最速で良い解決策を得ることができる最適化アルゴリズムのテストでした。
最良の結果を出すソリューションはシミュレーションを実行する回数を制御できるという点ですが、そのトレードオフとしてシミュレーションを実行する回数が少ないほど、その結果に対する信頼性が低くなります。以下に機能すると分かった方法を示します：
最適化アルゴリズムを実行し始めるときは、最初はより少ないシミュレーションから始め、目的に近づくにつれて回数を増やしていきます。これは、最初は多くのシフト変更がスケジュールを目的の方向に移動させるため、選択した方向に対して信頼性が高くなる必要がないからです。より良い解決策が近づくにつれて、スケジュールがどこに行くかがより重要になります。さらに、同じヌルポイントから始まる複数の階層実行を組み合わせることで、より広範な解の探索が保証されます。
このアプローチの素晴らしいところは、アルゴリズムの実行時間を制御できることです。実行時間を確認し、必要に応じて反復回数を調整することができます。また、どれくらいの回数から開始するかも選択できます。このアルゴリズムを実行する各マシンは少し異なる動作をするため、一貫したアルゴリズムの実行時間は、このプロジェクトが現実の世界で有用であることを確保するために極めて重要です。
#scheduleは{(開始時刻、終了時刻)：エージェント数です}{'Schedule': {(0, 540): 5, (30, 570): 2, (60, 600): 1, (90, 630): 1, (120, 660): 4, (150, 690): 1, (180, 720): 0, (210, 750): 1, (240, 780): 18, (0, 660): 0, (30, 690): 0, (60, 720): 0, (90, 750): 0, (120, 780): 3}'Average Wait': 0.5738814985851588'Worker Units': 660.0'Worst Shift Time In Queue, Relative to Target': 0.5965600329117189}結論
今や友人は入力と制約に基づいてスケジュールを作成できるプログラムを手に入れました。現実の世界での実際のパフォーマンスはまだ見ていませんが、スケジュールとシミュレーションの正確性について十分なデータを集めるために待つ必要があります。病気や休暇などの現実世界の要素は考慮していませんが、シミュレーションの素晴らしいところは、考慮しなかった要素を後から追加できることです。プロジェクト全体を大幅に見直す必要はありません。必要な場所に変更を追加するだけです。
このプロジェクトの最も重要な部分の一つは、すべてが独立して動作し、非常にモジュラーであることです。どんな不規則性もシミュレーションに組み込むことができます。多くの宿題プロジェクトは、解決策の堅さのために教室から抜け出せないのです。このプロジェクトは、柔軟性と再構築の能力から、私の考えでは特に有用です。現実世界は変化しますし、テクノロジーソリューションは適応して重要性を維持できるべきです。
最終的な考え
このプロジェクトに関しては、この友人であるジェレミー・ハーパーに本当に感謝しています。
このプロジェクトはこの分野に興味を持たせ、別の問題で再び試してみたいと思っています。モデリング、シミュレーション、最適化が必要な実世界の問題があれば、ぜひ教えていただき、この領域でのさらなるプロジェクトで協力できればと思います。 LinkedIn。
参考文献
1. Rahul Awati、Earlang C、techtarget.com
2. Naveen Mahadevan、サービスレベル契約（2022）、sprinklr.com
3. N. Jian、S. Henderson、シミュレーション最適化入門（2015）、Winter Simulation Conference
4. Y. Carlson、A. Maria、シミュレーション最適化：方法と応用（1997）、Winter Simulation Conference
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
