この機会に勤務表の対応可能範囲を広げることにしました。GUI含めて大変な変更なので現状のSC2に悪影響が懸念されます。そこで、SC3として、リリースすることを目標にしますが、当面3直4交代用のGUI/Solvertとして別リリースします。
今回の変更を説明する前に、現在の基本的な概念を記しておきます。
今までシフトは、次の式で表しておりました。あるシフト変数Xは、シフトの状態を表し2値です。
個々の状態にアクセスするには、次の形態をとります。
$X_p_d_s$. または $ X[p][d][s]$
ここで、
$p \in Persons$
$d \in Days$
$s \in Shifts$
です。3次元でアクセス可能です。
最も基本的な制約は、
$\sum_{s\in Shifts}X_p_d_s=1 \ \ \ \forall p \in Persons, \forall d \in Days$
です。
今回の変更は、上式を維持したまま、Shiftの時間分割であるPhaseを追加します。Shiftは、24時間の環を表しますが、一つのShiftが8時間だとすると、さらに4時間で分けて前後という風に二つに分けます。これを称して2Phaseと呼びます。 ですから、3Shift、2Phaseであれば、一日あたりの6Phaseをもつことになります。Phaseは、オプションとしてAliasの概念が持ちます。Aliasとは別名のことで実態は別なところにあるリンクみたいなものです。早出と残業は、Aliasです。
さらに、概念の追加をします。Taskです。Taskの概念は、INRC2でも出てきました。各シフトは、各Taskを持つという概念でした。ここでは、より広く対応するために、ShiftではなくPhase毎にTaskを持つという風に拡張します。つまり、Phase時間毎にTaskを決められるという関係になります。新たにTask変数Yを定義し、個々の変数には、以下でアクセスします。
$Y_p_d_s_u_t$. または $ Y[p][d][s][u][t]$
ここで、
$p \in Persons$
$d \in Days$
$s \in Shifts$
$u \in Phases$
$t \in Tasks$
です。5次元でアクセス可能です。
最も基本的な制約は、
$\sum_{t\in Tasks}Y_p_d_s_u_t=1 \ \ \ \forall u \in Phases$
subject to active shift
$\sum_{s\in Shifts}X_p_d_s=1 \ \ \ \forall p \in Persons, \forall d \in Days$
です。
Primary Phase | Alias Phase | |||||
呼称 | 前 | 後 | 早 | 残 | ||
Day | Alias | Day | Alias | |||
勤務1 | S1E | S1L | -1 | S3L | 0 | S2E |
勤務2 | S2E | S2L | 0 | S1L | 0 | S3E |
勤務3 | S3E | S3L | 0 | S2L | 1 | S1E |
例えば、勤務1早 というフェーズの実態は、S3Lですから、前の日の勤務3後になります。
このようにして、二人の早出・残業をセットにすることで、1人分のシフトリソース不足を補償することが可能になります。スケジュールナースは、登録してある工程技能者の中から、不足している(自・他工程)リソースを自動的に補償するプログラムです。これを100人単位で配置するとなると、結構な手間になると思います。
働き方改革で年休取得も必要ですし、工程の欠員をどうするか、多能化だけでは、難しい場面もあると思います。そこを優先度つきで、個々の要望を満足させながら、複雑多岐に渡る最適化してくれるのがスケジュールナース3になります。 今までのように、一度作った勤務表で終わりではありません。条件を変えながら、難しく時間がかかる部分は機械がやってくれます。そうしていくつかの解の様子をみながら、調整して得た解こそ、本当の人間の欲しい最適化した解なのです。
変数量の計算
100人スタッフ
(5シフト(3Shift+休み+常日勤勤務))
6Phases
31+1日(前月1日)
32Tasks
=60万変数
かなり大規模ですが、なんとかできるでしょう。
今回Latexを使って数式を記述してみました。下記のYoutubeを見てGoogleBloggerを設定しました。
http://latex.codecogs.com/
0 件のコメント:
コメントを投稿