(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023109453
(43)【公開日】2023-08-08
(54)【発明の名称】倉庫作業管理システム、倉庫作業管理方法及びプログラム
(51)【国際特許分類】
G06Q 10/0631 20230101AFI20230801BHJP
G06Q 10/087 20230101ALI20230801BHJP
【FI】
G06Q10/06 302
G06Q10/08 330
【審査請求】未請求
【請求項の数】8
【出願形態】OL
(21)【出願番号】P 2022010975
(22)【出願日】2022-01-27
(71)【出願人】
【識別番号】000153546
【氏名又は名称】ロジスティード株式会社
(74)【代理人】
【識別番号】100177220
【弁理士】
【氏名又は名称】小木 智彦
(72)【発明者】
【氏名】中安 良二
(72)【発明者】
【氏名】舘内 直
(72)【発明者】
【氏名】藤原 考輝
(72)【発明者】
【氏名】小牟田 治
(72)【発明者】
【氏名】石山 圭
(72)【発明者】
【氏名】糸谷 昌博
(72)【発明者】
【氏名】森尾 直弥
(72)【発明者】
【氏名】山本 洋平
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049AA06
5L049AA16
(57)【要約】
【課題】倉庫作業中のトラブルによる進捗の遅れを素早く修正することを可能にする。
【解決手段】倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理する倉庫作業管理システムは、倉庫全体の各作業工程の完了情報を取得し、取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出し、算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知し、前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成し、作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理する倉庫作業管理システムであって、
倉庫全体の各作業工程の完了情報を取得する取得部と、
取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出する算出部と、
算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知するアラート通知部と、
前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成する作成部と、
作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出するシミュレータと、
を備える倉庫作業管理システム。
【請求項2】
前記作成部は、複数の前記リカバリプランを作成し、
前記シミュレータは、前記複数のリカバリプランをシミュレートし、各リカバリプランに基づく当日分の作業全体の利益を其々算出する、
請求項1に記載の倉庫作業管理システム。
【請求項3】
シミュレートした前記複数のリカバリプランを同時に出力する出力部と、
出力した前記複数のリカバリプランに対する選択を受け付ける選択受付部と、
選択を受け付けた前記リカバリプランを、選択時以降の当日分の前記作業計画に決定する決定部と、
を更に備える請求項2に記載の倉庫作業管理システム。
【請求項4】
前記出力部は、シミュレートした前記複数のリカバリプランを、当日分の作業全体の利益が大きい順に出力する、
請求項3に記載の倉庫作業管理システム。
【請求項5】
前記出力部は、シミュレートした前記複数のリカバリプランを、当日分の作業全体の作業効率が最適な順に出力する、
請求項3に記載の倉庫作業管理システム。
【請求項6】
選択を受け付けた前記リカバリプランが、当日分の作業終了時刻が通常設定されている作業終了時刻よりも早く終わるリカバリプランである場合、翌日以降の作業内容を前倒しで作業できる旨を通知する前倒し可能通知部と、
を更に備える請求項3に記載の倉庫作業管理システム。
【請求項7】
倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理するコンピュータが実行する倉庫作業管理方法であって、
倉庫全体の各作業工程の完了情報を取得するステップと、
取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出するステップと、
算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知するステップと、
前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成するステップと、
作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出するステップと、
を備える倉庫作業管理方法。
【請求項8】
倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理するコンピュータに、
倉庫全体の各作業工程の完了情報を取得するステップ、
取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出するステップ、
算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知するステップ、
前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成するステップ、
作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出するステップ、
を実行させるためのコンピュータ読み取り可能なプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、倉庫作業のリアルタイム最適化に有効な技術に関する。
【背景技術】
【0002】
従来、倉庫作業を最適化するためのシステムが提案されている。例えば、特許文献1では、複数の出荷オーダに応じた作業を、リソースの割り当ても含め全体の作業計画を立案し、最適化することが可能な作業計画システムが開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、倉庫作業の作業計画を立てていても、当日、体調不良等により、出勤できない倉庫作業者が現れ、倉庫作業の作業人員の変更が生じたり、緊急対応が必要な出荷オーダが発生し、作業量の変更等が生じたりして、予定していた倉庫の作業計画が当日になって崩れることがある。
この場合、当初の作業計画の変更を行って出荷オーダに対応することが要求されるが、そのような場合でも、当日の倉庫作業における利益が、当初の作業計画と大きく乖離しないことが望ましい。
そこで、本発明者らは、倉庫稼働中に、リアルタイムに倉庫作業の進捗具合を把握して、どのように作業計画を変更すれば、当日の倉庫作業における利益が最大になるかをシミュレートして提供する仕組みに着目した。
【0005】
本発明は、倉庫作業中のトラブルによる進捗の遅れを素早く修正することを可能にする倉庫作業管理システム、倉庫作業管理方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明は、倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理する倉庫作業管理システムであって、
倉庫全体の各作業工程の完了情報を取得する取得部と、
取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出する算出部と、
算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知するアラート通知部と、
前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成する作成部と、
作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出するシミュレータと、
を備える倉庫作業管理システムを提供する。
【0007】
本発明によれば、倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理する倉庫作業管理システムは、倉庫全体の各作業工程の完了情報を取得し、取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出し、算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知し、前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成し、作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出する。
【0008】
本発明は、システムのカテゴリであるが、方法及びプログラムであっても同様の作用、効果を奏する。
【発明の効果】
【0009】
本発明によれば、倉庫作業中のトラブルによる進捗の遅れを素早く修正することを可能にする。
【図面の簡単な説明】
【0010】
【
図1】倉庫作業管理システム1の概要を説明する図である。
【
図2】倉庫作業管理システム1の機能構成を示す図である。
【
図3】倉庫作業管理システム1が実行する出荷オーダ取得処理のフローチャートを示す図である。
【
図4】倉庫作業管理システム1が実行する作業計画取得処理のフローチャートを示す図である。
【
図5】倉庫作業管理システム1が実行する不足人員通知処理のフローチャートを示す図である。
【
図6】倉庫作業管理システム1が実行するアラート通知処理のフローチャートを示す図である。
【
図7】算出結果60の一例を模式的に示した図である。
【
図8】管理者端末40に通知するアラート70の一例を模式的に示した図である。
【
図9】倉庫作業管理システム1が実行するリカバリプラン作成処理のフローチャートを示す図である。
【
図10】管理者端末40が表示する変更入力用UI80の一例を模式的に示した図である。
【
図11】管理者端末40が表示する変更入力用UI86の一例を模式的に示した図である。
【
図12】倉庫作業管理システム1が実行する作業計画決定処理のフローチャートを示す図である。
【
図13】シミュレート結果の一例を模式的に示した図である。
【
図14】並び替えを行ったシミュレート結果の一例を模式的に示した図である。
【
図15】並び替えを行ったシミュレート結果の一例を模式的に示した図である。
【
図16】管理者端末40に出力するシミュレート結果90の一例を模式的に示した図である。
【
図17】管理者端末40に出力するシミュレート結果90の一例を模式的に示した図である。
【
図18】管理者端末40に出力するシミュレート結果90の一例を模式的に示した図である。
【
図19】管理者端末40に出力するシミュレート結果90の一例を模式的に示した図である。
【
図20】倉庫作業管理システム1が実行する前倒し作業可能通知処理のフローチャートを示す図である。
【発明を実施するための形態】
【0011】
以下、添付図面を参照して、本発明を実施するための形態(以下、実施形態)について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。
【0012】
[基本概念/基本構成]
図1は、倉庫作業管理システム1の概要を説明するための図である。倉庫作業管理システム1は、少なくともコンピュータ10を備える倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理するシステムである。
本実施形態では、倉庫作業管理システム1は、コンピュータ10と、出荷オーダを管理するWMS(Warehouse Management System)20、作業計画を管理するRCS(Resource Control System)30、倉庫作業者や作業内容を管理する管理者が所持する管理者端末40、倉庫作業者毎の出勤、労働時間、遅刻、早退、休憩、欠勤等の就業状況をシフトデータ等により管理する勤怠管理システムであるシフト管理システム50と、データ通信可能に接続されるシステムである。
【0013】
本実施形態は、前提として、予め当日分の作業計画が作成又は保存されており、この作業計画を用いるものである。なお、作業計画は、RCS30により自動で作成され、コンピュータ10に自動で出力されるのが望ましいが、その態様に限定されるものではない。また、倉庫作業における工程として、入荷、入庫、ピッキング、流通加工、梱包、出荷を想定しているが、工程に関してもこれらに限定されるものではない。また、本明細書において、利益とは、単純な粗利だけでなく、売上、支出、収支、利益率を含むものである。
【0014】
倉庫作業管理システム1が、作業人員及び/又は作業内容の変更に基づく当日分の作業全体の利益を算出する場合についての処理ステップの概要について、
図1に基づいて説明する。
【0015】
コンピュータ10は、当日分の出荷オーダ及び作業計画を取得する(ステップS0)。
出荷オーダは、例えば、商品ID、出荷量、締切日時が含まれるデータである。作業計画は、例えば、倉庫作業における各工程の倉庫作業者の作業人員数及び作業内容(例えば、作業時間、作業量)である。
WMS20は、管理者から管理者端末40を介して、出荷オーダの入力を受け付ける。WMS20は、受け付けた出荷オーダの内、当日分の出荷オーダを、コンピュータ10に送信する。なお、WMS20は、出荷オーダを、顧客が管理する顧客システムから取得した出荷オーダを、コンピュータ10に送信する構成も可能である。
RCS30は、作成、又は保存済の作業計画の内、当日分の作業計画を、コンピュータ10に送信する。
コンピュータ10は、WMS20又はRCS30から、これらの出荷オーダ及び作業計画を受信することにより、当日分の出荷オーダ及び作業計画を取得する。
【0016】
コンピュータ10は、倉庫全体の各作業工程の完了情報を取得する(ステップS1)。
コンピュータ10は、リアルタイムにおける倉庫全体の各作業工程の内、完了したものについて、完了情報を取得する。
RCS30は、倉庫全体の各作業工程の完了情報を、コンピュータ10に送信する。
コンピュータ10は、この完了情報を受信することにより、完了情報を取得する。
【0017】
コンピュータ10は、取得した完了情報と、予め作成された作業計画上の作業工程とを比較し、作業工程の進捗具合を算出する(ステップS2)。
進捗具合は、例えば、作業計画における影響度(作業計画に対する進捗率、完了した作業量及び作業計画上の必要な作業量)、進捗具合による利益の差(収支影響)、進捗具合をリカバリするために必要な工数(必要人時)である。
コンピュータ10は、取得した完了情報と、取得した当日の作業計画における作業工程とを比較し、リアルタイムにおける倉庫全体の作業工程の進捗具合を算出する。
【0018】
コンピュータ10は、算出結果に基づいて、作業工程の進捗具合が閾値以下の場合、アラートを通知する(ステップS3)。
コンピュータ10は、作業工程の進捗具合が閾値以下の作業工程が発生した場所を表示したフロアマップ、進捗具合及び受注オーダ等をまとめたものをアラートとして作成する。コンピュータ10は、作成したアラートを、管理者端末40に送信する。
管理者端末40は、このアラートを受信し、自身の表示部に表示する。
コンピュータ10は、作成したアラートを、管理者端末40に表示させることにより、算出結果に基づいて、作業工程の進捗具合が閾値以下の場合、管理者に、アラートを通知する。更に好ましくは、コンピュータ10は、進捗具合に対しての補填等せずに作業を行った場合のプランをシミュレートし、当日分の作業全体の利益予想を算出するとともに、作業超過時間を管理者端末40に通知するのが好ましい。ここで、出荷オーダに記載の時間を超過する結果となる場合には、計画が困難であるとしてエラーを表示しても良い。
管理者は、表示されたアラートを閲覧することにより、進捗に遅れが発生していることを把握する。
【0019】
コンピュータ10は、アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成する(ステップS4)。
コンピュータ10は、アラートを通知する度、予め作成された作業計画について、作業人員及び/又は作業内容の変更を、管理者端末40を介して受け付ける。
管理者は、管理者端末40に通知されたアラートを確認し、作業人員の配置変更及び/又は作業内容の変更の入力の要否等を判断する。管理者端末40は、作業人員の配置変更及び/又は作業内容の変更の入力を受け付けることができ、管理者は、作業内容の変更が必要と判断した場合にはその変更内容を入力する。
変更内容は、具体的には以下のようなものである。
例えば、進捗に遅れが発生している作業内容を他の作業人員に配置変更するプラン、一日を午前と午後で二分割し、午前中は進捗に遅れが発生している点を除いて当初割り当てられた作業内容の配置を維持するが、午後に進捗に遅れが発生している作業内容を別途補填して配置変更するプラン、当初複数人に割り当てられた作業内容の内、人数が減っても問題が無い又は問題が少ない作業内容を抽出し、そこから作業人員を進捗に遅れが発生している作業内容に割り当てて配置変更するプラン、又は翌日以降に行っても問題ない作業内容を抽出してその分を翌日以降に変更し、現在の作業人員により行える作業内容に集約して作業内容を再作成して配置変更するプラン、等である。管理者端末40は、このような変更プランを1案ずつ入力して受付けても良いし、複数プランを入力できるものでも良く、優先順位とともに複数プランを入力可能なものであっても構わない。
管理者端末40は、上述のような趣旨で受け付けた変更内容をコンピュータ10に送信する。
コンピュータ10は、この変更内容を受信することにより、取得した作業計画について、作業人員及び/又は作業内容の変更を受け付ける。
コンピュータ10は、受け付けた変更内容に基づいて、作業計画に対するリカバリプランを作成する
コンピュータ10は、この変更内容に基づいて、当初の当日分の作業計画に対して、進捗に遅れが発生している作業工程を補う作業計画をリカバリプランとして作成する。このリカバリプランは、上述した変更内容を、選択時以降の当日分の作業計画に反映したものである。
【0020】
コンピュータ10は、作成したリカバリプランをシミュレートし、リカバリプランに基づく当日分の作業全体の利益を算出する(ステップS5)。
コンピュータ10は、作成したリカバリプランをシミュレートし、リカバリプランにおける売上及び経費を算出する。コンピュータ10は、算出した売上から経費を減算し、収支を算出する。コンピュータ10は、これらの計算を行うことにより、利益を算出する。更に、コンピュータ10は、リカバリプランにおける作業効率(総所要時間、カットタイム余裕時間、余裕率、超過人時)を算出する。
総所要時間は、シミュレーション結果のかかった時間(実際に、このリカバリプランにより倉庫作業を行った場合にかかる時間)であり、作業開始時刻から、作業終了時刻までに必要な時間である。カットタイムは、出荷する荷物毎に設定される締切時間である。カットタイム余裕時間は、カットタイムから総所要時間を減算した時間(作業終了時刻から、カットタイムの時刻までの間の時間)である。余裕率は、このカットタイムに対するカットタイム余裕時間の割合である。超過人時は、カットタイム余裕時間がマイナスの場合に必要な単位時間当たりの人数である。
【0021】
コンピュータ10は、このようにして得られたリカバリプランに基づいて、選択時以降の当日の作業計画を決定することになる。倉庫作業者は、決定された作業計画に従って、実際の倉庫作業を行う。
なお、ここでは、コンピュータ10が取得した作業計画に対し作業人員が変更を受け付けた場合の例で説明したが、作業量が変更となった場合においても同様である。コンピュータ10は、作業量の変更を管理者端末40に通知し、予定作業時間内に作業完了できるかどうか、更に好ましくは利益を算出して当初プランとの乖離(利益損失)を管理者端末40に通知する。
【0022】
このような倉庫作業管理システム1によれば、倉庫作業中のトラブルによる進捗の遅れを素早く修正することが可能となる。また、前日に予測した人員計画及び作業計画と、当日の出荷オーダとが異なる場合、予測した人員計画及び作業計画を、どのように変更すれば、出荷オーダに間に合うかをレコメンドしたり、その際の収支シミュレーションを行ったりすることも可能となる。
【0023】
[機能構成]
図2に基づいて、倉庫作業管理システム1の機能構成について説明する。
倉庫作業管理システム1は、少なくともコンピュータ10を備え、コンピュータ10が、出荷オーダを管理するWMS20、作業計画を管理するRCS30、倉庫作業者や作業内容を管理する管理者が所持する管理者端末40、倉庫作業者毎の就業状況をシフトデータ等により管理する勤怠管理システムであるシフト管理システム50と、公衆回線網やイントラネット等のネットワーク9を介して、データ通信可能に接続される。
倉庫作業管理システム1は、コンピュータ10に加えて、WMS20、RCS30、管理者端末40、シフト管理システム50、その他の端末や装置類等が含まれていても良い。この場合、倉庫作業管理システム1は、後述する処理を、含まれる端末や装置やシステム等の何れか又は複数の組み合わせにより実行する。
【0024】
コンピュータ10は、サーバ機能を有するコンピュータやパーソナルコンピュータ等であり、倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理するものである。
コンピュータ10は、例えば、1台のコンピュータで実現されてもよいし、クラウドコンピュータのように、複数のコンピュータで実現されてもよい。本明細書におけるクラウドコンピュータとは、ある特定の機能を果たす際に、任意のコンピュータをスケーラブルに用いるものや、あるシステムを実現するために複数の機能モジュールを含み、その機能を自由に組み合わせて用いるものの何れであってもよい。
【0025】
コンピュータ10は、制御部として、CPU(Central Processing Unit)、GPU(Graphics Processing Unit)、RAM(Random Access Memory)、ROM(Read Only Memory)等を備え、通信部として、他の端末や装置等と通信可能にするためのデバイス、作業工程の完了情報を取得する取得部11、作業工程の進捗具合に応じてアラートを通知するアラート通知部12等を備える。
また、コンピュータ10は、記憶部として、ハードディスクや半導体メモリ、記憶媒体、メモリカード等によるデータのストレージ部を備える。
また、コンピュータ10は、処理部として、各種処理を実行する各種デバイス、作業工程の進捗具合を算出する算出部13、作業人員及び/又は作業内容を変更したリカバリプランを作成する作成部14、リカバリプランのシミュレート及び利益を算出するシミュレータ15等を備える。
【0026】
コンピュータ10において、制御部が所定のプログラムを読み込むことにより、通信部と協働して、出荷オーダ取得モジュール、作業計画取得モジュール、シフトデータ取得モジュール、不足人員通知モジュール、完了情報取得モジュール、アラート通知モジュール、変更受付モジュール、リカバリプラン出力モジュール、選択受付モジュール、前倒し可能通知モジュールを実現する。
また、コンピュータ10において、制御部が所定のプログラムを読み込むことにより、記憶部と協働して、出荷オーダ記憶モジュール、作業計画記憶モジュール、リカバリプラン記憶モジュールを実現する。
また、コンピュータ10において、制御部が所定のプログラムを読み込むことにより、処理部と協働して、不足人員検出モジュール、不足人員判断モジュール、不足人員割当作業特定モジュール、進捗具合算出モジュール、進捗具合判断モジュール、アラート作成モジュール、リカバリプラン作成モジュール、シミュレートモジュール、利益算出モジュール、作業効率算出モジュール、シミュレート結果作成モジュール、並べ替えモジュール、作業計画決定モジュール、早期終了判断モジュールを実現する。
【0027】
WMS20は、汎用的な倉庫の入出庫等を管理するシステムであれば良く、その詳細な説明は省略する。
RCS30は、汎用的な倉庫設備を管理するシステムであれば良く、その詳細は省略する。
管理者端末40は、管理者が所持する携帯電話、スマートフォン、タブレット端末等の携帯端末やパーソナルコンピュータ等の端末であり、端末制御部として、CPU、GPU、RAM、ROM等を備え、通信部として、コンピュータ10と通信可能にするためのデバイス等を備え、入出力部として、画面やデータ等の入出力を実行する各種デバイス等を備える。
シフト管理システム50は、汎用的な倉庫作業者の就業状況等を管理するシステムであれば良く、その詳細は省略する。
【0028】
以下、倉庫作業管理システム1が実行する各処理について、上述した各モジュールが実行する処理と併せて説明する。
本実施形態では、倉庫作業における工程として、入荷、入庫、ピッキング、流通加工、梱包、出荷等を想定しており、利益とは、単純な粗利だけでなく、売上、支出、収支、利益率を含むものである。
【0029】
[コンピュータ10が実行する出荷オーダ取得処理]
図3に基づいて、コンピュータ10が実行する出荷オーダ取得処理について説明する。同図は、コンピュータ10が実行する出荷オーダ取得処理のフローチャートを示す図である。出荷オーダ取得処理とは、上述した出荷オーダ及び作業計画を取得する処理(ステップS0)のうち、出荷オーダの取得処理に係るフローの詳細である。
【0030】
出荷オーダ取得モジュールは、当日分の出荷オーダを取得する(ステップS10)。
出荷オーダは、上述した通り、商品ID、出荷量、締切日時等が含まれるデータである。
管理者端末40は、管理者から、出荷オーダの入力を受け付け、受け付けた出荷オーダを、WMS20に送信する。
WMS20は、この出荷オーダを受信し、自身の記憶部等に記憶する。WMS20は、記憶した出荷オーダの内、当日分の出荷オーダを抽出してコンピュータ10に送信する。なお、WMS20は、出荷オーダを、顧客が管理する顧客システムから取得した出荷オーダを、コンピュータ10に送信する構成も可能である。
出荷オーダ取得モジュールは、この出荷オーダを受信することにより、当日分の出荷オーダを取得する。
【0031】
出荷オーダ記憶モジュールは、取得した出荷オーダを記憶する(ステップS11)。
出荷オーダ記憶モジュールは、取得した出荷オーダと、この出荷オーダの識別子(名称、ID、管理番号、整理番号等)とを紐付けて記憶する。
【0032】
以上が、出荷オーダ取得処理である。
出荷オーダ取得処理は、出荷オーダの更新毎、所定時間毎、出荷オーダの完了毎等において、随時行われる処理である。コンピュータ10は、上述した出荷オーダ取得処理により取得した出荷オーダを用いて、後述する処理を実行する。
なお、コンピュータ10は、出荷オーダ取得処理において、出荷オーダを記憶せずに、後述する処理を実行する構成も可能であり、この場合、後述する処理において、取得した出荷オーダをそのまま用いればよい。
【0033】
[コンピュータ10が実行する作業計画取得処理]
図4に基づいて、コンピュータ10が実行する作業計画取得処理について説明する。同図は、コンピュータ10が実行する作業計画取得処理のフローチャートを示す図である。作業計画取得処理とは、上述した出荷オーダ及び作業計画を取得する処理(ステップS0)のうち、作業計画の取得処理に係るフローの詳細である。
【0034】
作業計画取得モジュールは、当日分の作業計画を取得する(ステップS20)。
作業計画は、上述した通り、倉庫作業における各工程の倉庫作業者の作業人員数及び作業内容(例えば、作業時間、作業量)、作業工程等である。
RCS30は、予め作成した作業計画の内、当日分の作業計画を抽出してコンピュータ10に送信する。
作業計画取得モジュールは、この作業計画を受信することにより、当日分の作業計画を取得する。なお、作業計画の取得元は、RCS30に限定されるものではない。
【0035】
作業計画記憶モジュールは、取得した作業計画を記憶する(ステップS21)。
作業計画記憶モジュールは、取得した作業計画と、この作業計画の識別子(名称、ID、管理番号、整理番号等)とを紐付けて記憶する。
【0036】
以上が、作業計画取得処理である。
作業計画取得処理は、作業計画の更新毎、所定時間毎、作業開始時刻の所定時間前、作業終了時刻後等において、随時行われる処理である。コンピュータ10は、上述した作業計画取得処理により取得した作業計画を用いて、後述する処理を実行する。
なお、コンピュータ10は、作業計画取得処理において、作業計画を記憶せずに、後述する処理を実行する構成も可能であり、この場合、後述する処理において、取得した作業計画をそのまま用いればよい。
【0037】
[コンピュータ10が実行する不足人員通知処理]
図5に基づいて、コンピュータ10が実行する不足人員通知処理について説明する。同図は、コンピュータ10が実行する不足人員通知処理のフローチャートを示す図である。
【0038】
シフトデータ取得モジュールは、当日分のシフトデータを取得する(ステップS30)。
シフト管理システム50は、当日分のシフトデータを抽出してコンピュータ10に送信する。
シフトデータ取得モジュールは、このシフトデータを受信することにより、当日分のシフトデータを取得する。
【0039】
不足人員検出モジュールは、取得した当日分のシフトデータにおける不足人員を検出する(ステップS31)。
不足人員検出モジュールは、取得した当日分のシフトデータを解析し、当日分の倉庫作業者の内、欠勤、遅刻、早退等の変更があった者については自身に割り当てられた当日分の倉庫作業の一部又は全部を行えない倉庫作業者を不足人員として検出し、それ以外の出勤の倉庫作業者については予定した作業を行えるとして、作業人員として検出する。
【0040】
不足人員判断モジュールは、検出結果において、不足人員が存在するか否か判断する(ステップS32)。
不足人員判断モジュールは、不足人員が存在しないと判断した場合(ステップS32 NO)、コンピュータ10は、不足人員通知処理を終了する。
【0041】
一方、不足人員検出モジュールは、検出結果において、不足人員が存在すると判断した場合(ステップS32 YES)、不足人員割当作業特定モジュールは、検出した不足人員に割り当てられた作業内容を特定する(ステップS33)。
不足人員割当作業特定モジュールは、上述した作業計画取得処理により取得した作業計画を参照し、検出した不足人員に割り当てられた作業内容を特定する。なお、不足人員割当作業特定モジュールは、取得したシフトデータを参照し、検出した不足人員に割り当てられた作業内容を特定しても良い。
【0042】
不足人員通知モジュールは、不足人員を通知する(ステップS34)。
不足人員通知モジュールは、不足人員数、不足人員に割り当てられた当日分の作業内容及び期間を管理者端末40に送信する。期間は、不足人員が欠勤である場合、一日であり、遅刻や早退であれば、午前や午後や所定の時間帯等である。
管理者端末40は、この不足人員数、不足人員に割り当てられた当日分の作業内容及び期間を受信し、自身の表示部に表示する。
不足人員通知モジュールは、管理者端末40に、不足人員数、不足人員に割り当てられた当日分の作業内容及び期間を表示させることにより、不足人員を通知する。
【0043】
以上が、不足人員通知処理である。
【0044】
[コンピュータ10が実行するアラート通知処理]
図6に基づいて、コンピュータ10が実行するアラート通知処理について説明する。同図は、コンピュータ10が実行するアラート通知処理のフローチャートを示す図である。アラート通知処理は、上述した作業工程の完了情報の取得処理(ステップS1)、作業工程の進捗具合の算出処理(ステップS2)、作業工程の進捗具合に応じてアラートを通知するアラート通知処理(ステップS3)の詳細であり、上述した作業計画取得処理と同時又は後に行われる処理である。
【0045】
完了情報取得モジュールは、倉庫全体の各作業工程の完了情報を取得する(ステップS40)。
完了情報は、完了した作業工程の内容、完了した時間、作業時間等が含まれるものである。
完了情報取得モジュールは、アラート通知処理の実行した時点、すなわち、リアルタイムにおける倉庫全体の各作業工程の内、完了したものについて、其々、完了情報を取得する。
RCS30は、この完了情報を、コンピュータ10に送信する。
完了情報取得モジュールは、この完了情報を受信することにより、倉庫全体の各作業工程の完了情報を取得する。
完了情報取得モジュールが取得する完了情報は、取得時点において、既に作業が行われた各工程及び現在作業中の工程の作業工程の完了情報であっても良いし、取得時点において、現在作業中の工程のみの作業工程の完了情報であっても良い。
【0046】
進捗具合算出モジュールは、取得した完了情報と、予め作成された作業計画上の作業工程とを比較し、作業工程の進捗具合を算出する(ステップS41)。
進捗具合は、上述した通り、作業計画における影響度(作業計画に対する進捗率、完了した作業量及び作業計画上の必要な作業量)、進捗具合による利益の差(収支影響)、進捗具合をリカバリするために必要な工数(必要人時)等である。
進捗具合算出モジュールは、進捗具合として、計画対作業進捗率、作業量、完了見込み時間、余裕率、超過人時、粗利率を其々算出する(
図7参照)。
進捗具合算出モジュールは、完了情報と、上述した作業計画取得処理により取得した当日分の作業計画とに基づいて、作業工程の進捗具合を算出する。進捗具合算出モジュールは、完了情報における工程において完了した作業工程と、当時分の作業計画のこの工程における作業工程とを、比較し、この工程における進捗具合を算出する。
進捗具合算出モジュールは、取得時点において、既に作業が行われた各工程及び現在作業中の工程の作業工程の完了情報と、予め作成された作業計画上の作業工程とを比較しても良いし、取得時点において、現在作業中の工程の作業工程の完了情報と、予め作成された作業計画上の作業工程とを比較しても良い。
【0047】
図7に基づいて、進捗具合算出モジュールが算出する作業工程の進捗具合について説明する。同図は、進捗具合算出モジュールが、算出した算出結果の一例を模式的に示した図である。同図において、進捗具合算出モジュールが、ピッキングにおける進捗具合を算出した算出結果の例を示している。
進捗具合算出モジュールは、算出結果60として、算出した進捗具合の各数字や内容を、テーブルとしてまとめた進捗テーブル61及び算出した進捗具合の各数字や内容を、グラフとしてまとめた進捗グラフ62が示されている。
進捗テーブル61において、作業計画における影響度として、計画対作業進捗率 73%、作業量 560/768、完了見込み時間 20:47(+3:47)、余裕率 -32.1%が示され、進捗具合による利益の差として、粗利率 -8.1%が示され、進捗具合をリカバリするために必要な工数として、超過人時 11人時が示されている。
進捗グラフ62は、これらの内容をグラフとしてまとめたものである。
【0048】
このような進捗具合の遅れの発生理由としては、上述した不足人員通知処理において、検出した不足人員によるものや、想定外のトラブルの発生等によるものが挙げられる。
【0049】
図6に戻り、アラート通知処理の続きを説明する。
進捗具合判断モジュールは、算出結果に基づいて、作業工程の進捗具合が閾値以下であるかどうかを判断する(ステップS42)。
閾値は、予め設定されるものであり、例えば、進捗率、残作業量、開始時間、完了見込み時間に、設定される割合や数字である。
進捗具合判断モジュールは、これらの全部又は一部において、設定された閾値以下であるかどうかを判断する。
進捗具合判断モジュールは、算出した進捗具合が、閾値よりも大きいと判断した場合(ステップS42 NO)、コンピュータ10は、アラート通知処理を終了する。
【0050】
一方、進捗具合判断モジュールは、算出した進捗具合が、閾値以下であると判断した場合(ステップS42 YES)、アラート作成モジュールは、アラートを作成する(ステップS43)。
アラート作成モジュールは、算出した進捗具合が閾値以下の作業工程が発生した場所を表示したフロアマップ、進捗具合及び受注オーダ等をまとめたものをアラートとして作成する(
図8参照)。アラート作成モジュールは、フロアマップにおいて、この場所を、例えば、強調表示、囲み線、塗りつぶし、アイコンの付与等により表示する。また、アラート作成モジュールは、進捗具合及び受注オーダを視覚化したテーブル等を作成する。また、アラート作成モジュールは、これらに加えて、作業全体の進捗、作業全体における処理能力、人員配置等をグラフ等により視覚化したものを作成する。
【0051】
図8に基づいて、アラート作成モジュールが作成するアラートについて説明する。同図は、アラート作成モジュールが作成するアラートの一例を模式的に示した図である。
アラート70において、フロアマップ71、進捗具合72、受注オーダ73が示されている。
フロアマップ71において、進捗に遅れ(進捗具合が閾値以下)が発生した作業工程の場所が、囲み線74により示されている。
また、フロアマップ71の近傍に、算出した進捗具合及び遅れが発生した工程をテーブルとして視覚化した進捗具合72、取得した受注オーダをテーブルとして視覚化した受注オーダ73が示されている。
なお、これらの配置や表示態様(進捗に遅れが発生した場所の表示態様、フロアマップの表示態様、進捗具合の表示態様、受注オーダの表示態様)については、適宜変更可能である。
また、アラート70は、これらの一部、例えば、進捗具合のみ、フロアマップ及び進捗具合のみを含むものであっても良い。また、アラート70は、これらに加えて、作業全体の進捗、作業全体における処理能力、人員配置等をグラフ等により視覚化したものが含まれていても良い。
【0052】
図6に戻り、アラート通知処理の続きを説明する。
アラート通知モジュールは、作成したアラートを通知する(ステップS44)。
アラート通知モジュールは、作成したアラートを、管理者端末40に送信する。
管理者端末40は、このアラートを受信し、自身の表示部に表示する。管理者端末40は、上述した
図8で示したアラート70を、自身の表示部に表示する。
アラート通知モジュールは、作成したアラートを、管理者端末40に表示させることにより、作成したアラートを通知する。
管理者端末40は、表示したアラートに対する入力を受け付けることにより、上述した
図7で示した算出結果60を表示する画面に遷移する。
管理者は、このアラート70を閲覧することにより、進捗に遅れが発生していること、遅れが発生している場所、進捗具合等を把握する。
【0053】
以上が、アラート通知処理である。
【0054】
[コンピュータ10が実行するリカバリプラン作成処理]
図9に基づいて、コンピュータ10が実行するリカバリプラン作成処理について説明する。同図は、コンピュータ10が実行するリカバリプラン作成処理のフローチャートを示す図である。リカバリプラン作成処理は、上述したリカバリプランの作成処理(ステップS4)の詳細であり、上述したアラート通知処理が実行され、アラートを通知する度に行われる処理である。
【0055】
変更受付モジュールは、作業人員及び/又は作業内容の変更を受け付ける(ステップS50)。
管理者端末40は、アラートを閲覧した管理者から、作業人員及び/又は作業内容の変更の入力を受け付ける。管理者端末40は、上述したアラート通知処理により通知されたアラートにおける進捗具合の内容に基づいて、この進捗具合の遅れを修正するための作業人員の配置変更及び/又は作業内容の変更の入力を受け付ける。
また、作業内容の変更が必要となる場合として、アラートの発生に限らず、前日までに立案した作業人員の人員計画及び作業計画と、実際の出荷オーダとの間にズレが発生している場合が挙げられる。
このような作業計画の変更が必要となる例として、前日に翌日の出荷オーダを予測した状態で、立案した人員計画及び作業計画に対して、当日における実際の出荷オーダが異なっている場合が挙げられる。具体的には、予測よりも出荷オーダがかなり多かった場合、予定していた翌日出荷分の作業内容を中止し、当日出荷分の作業内容に変更する、又は、作業人員の調整(例えば、作業人員の残業)が必要となる。また、予測よりも手動で作業しなければならない出荷オーダが多かった場合、自動作業の作業人員を減らし、手動作業の人員を増やすといったことが必要となる。また、予測よりもカットタイムが早い出荷オーダが多かった場合、作業が早めに終わるように、カットタイムが遅い出荷オーダから、このカットタイムが早い出荷オーダに作業人員を集中させることが必要となる。これらを解消するための作業人員の配置変更及び/又は作業内容の変更の入力も併せて受け付ける。
入力を受け付ける変更内容は、例えば、以下のようなものである。
すなわち、進捗に遅れが発生している作業内容を他の作業人員に配置変更する内容、一日を午前と午後で二分割し、午前中は進捗に遅れが発生している点を除いて当初割り当てられた作業内容の配置を維持するが、午後に進捗に遅れが発生している作業内容を別途補填して配置変更する内容、当初複数人に割り当てられた作業内容の内、人数が減っても問題が無い又は問題が少ない作業内容を抽出し、そこから作業人員を進捗に遅れが発生している作業内容に割り当てて配置変更する内容、又は翌日以降に行っても問題ない作業内容を抽出してその分を翌日以降に変更し、現在の作業人員により行える作業内容に集約して作業内容を再作成して配置変更する内容等である。また、これらの他に、予測よりも出荷オーダがかなり多かった場合、翌日出荷分の作業内容を中止し、当日出荷分の作業内容に変更する内容、自動作業の作業人員を減らし、手動作業の作業人員を増やす内容、予測よりも手動で作業しなければならない出荷オーダが多かった場合、自動作業の作業人員を減らし、手動作業の人員を増やす内容、予測よりもカットタイムが早い出荷オーダが多かった場合、作業が早めに終わるように、カットタイムが遅い出荷オーダから、この出荷オーダに作業人員を集中して増やす内容等である。
管理者端末40は、このような変更プランを、1案ずつ入力を受付けるものでも良いし、複数プランを入力できるものでも良く、優先順位とともに複数プランを入力できるものであっても構わない。
【0056】
変更受付モジュールが受け付ける変更内容について説明する。
管理者端末40は、ピッキングにおいて、アラートが通知された場合、梱包の作業人員の内の所定の人数(例えば、1名)を、ピッキングに変更する入力を受け付ける(
図10参照)。また、管理者端末40は、流通加工及び梱包の作業人員の内、所定の人数(例えば、各1名)を、午後からピッキングに変更する入力を受け付ける(
図10参照)。また、管理者端末40は、翌日以降出荷分の作業量を減少させる入力を受け付ける(
図11参照)。管理者端末40は、コンピュータ10が各工程の何れか又は複数の組み合わせにおいて、アラートを通知した時も、同様に、アラートを通知していない工程から作業人員の配置変更、作業内容の変更を受け付ける。
【0057】
図10に基づいて、管理者端末40が作業人員の変更の入力を受け付ける際のUI(User Interface)について説明する。同図は、管理者端末40が作業人員の変更の入力を受け付ける際に表示する変更入力用UIの一例を模式的に示した図である。
管理者端末40は、変更入力用UI80を自身の表示部に表示し、管理者からの入力を受け付ける。
管理者端末40は、作業員入力欄81において、作業人員の割り当て元となる作業員の識別子の入力を受け付ける。ここで、管理者端末40は、アイコン84に対する入力を受け付け、プルダウンメニューにより、作業員の選択入力を受け付ける。
管理者端末40は、プロセス入力欄82において、作業人員の割当先となる工程(プロセス)の入力を受け付ける。ここで、管理者端末40は、アイコン84に対する入力を受け付け、プルダウンメニューにより、工程の選択入力を受け付ける。
管理者端末40は、時間入力欄83において、作業人員の割当期間の入力を受け付ける。ここで、管理者端末40は、アイコン84に対する入力を受け付け、プルダウンメニューにより、期間の開始時時間及び終了時間の選択入力を受け付ける。
なお、この変更入力用UIは、あくまでも一例に過ぎず表示内容、表示順、入力内容等は、
図10で示すUIに限定されるものではない。例えば、アイコン84によるプルダウンメニューでなくとも良いし、それ以外の表示内容、表示順、入力内容等も可能である。
【0058】
図11に基づいて、管理者端末40が作業内容の変更の入力を受け付ける際のUIについて説明する。同図は、管理者端末40が作業内容の変更の入力を受け付ける際に表示する変更入力用UIの一例を模式的に示した図である。
管理者端末40は、変更入力用UI86を自身の表示部に表示し、管理者からの入力を受け付ける。この変更入力用UI86は、作成した出荷オーダに基づいたものである。
管理者端末40は、翌日以降の出荷オーダの内、作業量を減少させる出荷オーダに対して、入力を受け付ける。具体的には、変更入力用UI86に表示中の出荷オーダの内、管理者が所望した出荷オーダに対する選択入力等を受け付けることにより、減少させる出荷オーダの入力を受け付ける。管理者端末40は、変更入力用UI86において、入力を受け付けた出荷オーダの日付欄87におけるボックスに、チェックマークを付与することにより、入力を受け付けたことを明示する。
なお、この変更入力用UIは、あくまでも一例に過ぎず表示内容、表示順、入力内容等は、
図11で示すUIに限定されるものではない。例えば、チェックマークを付与しなくとも良いし、それ以外の表示内容、表示順、入力内容等も可能である。
【0059】
図9に戻り、リカバリプラン作成処理におけるステップS50の処理の続きを説明する。
管理者端末40は、入力を受け付けた変更内容を、コンピュータ10に送信する。
変更受付モジュールは、この変更内容を受信することにより、作業人員及び/又は作業内容の変更を受け付ける。
なお、変更受付モジュールは、管理者端末40から、一の変更内容のみを受け付けた場合には、この一の変更内容のみ、後述する処理を行う。変更受付モジュールが複数の変更内容を受け付けた場合、変更内容毎に、後述する処理を実行する。また、優先順位とともに変更内容を受け付けた場合は、その順位に従って処理を実行する。
また、変更受付モジュールは、管理者端末40により、変更内容を受け付けている構成として説明しているが、変更受付モジュールが、直接、変更内容を受け付ける構成であっても良い。例えば、作業内容と作業人員との相関関係を学習し、学習結果に基づいて、アラートを通知した場合の作業人員及び/又は作業内容の変更を受け付けても良い。また、変更受付モジュールは、アラートを通知した場合、予め設定された作業人員及び/又は作業内容に基づいて、作業人員及び/又は作業内容の変更を受け付けても良い。
【0060】
リカバリプラン作成モジュールは、受け付けた変更内容に基づいて、作業計画に対するリカバリプランを作成する(ステップS51)。
リカバリプラン作成モジュールは、受け付けた変更内容を、選択時以降の当日分の作業計画に反映させたリカバリプランを作成する。すなわち、リカバリプラン作成モジュールが作成するリカバリプランは、選択時以降の当日分の作業計画に、変更を受け付けた作業人員及び/又は作業内容を反映させたものである。
リカバリプラン作成モジュールは、受け付けた変更内容が、一つのみである場合、この一の変更内容に基づいた一のリカバリプランを作成し、複数の変更内容を受け付けた場合、其々の変更内容に基づいた複数のリカバリプランを作成する。
以下の説明において、リカバリプラン作成モジュールは、流通加工の作業人員を1名、ピッキングに変更したものをリカバリプラン1として作成し、流通加工の作業人員を1名及び梱包の作業人員を1名、午後から、ピッキングに変更したものをリカバリプラン2として作成し、翌日以降出荷分の作業量を削減したものをリカバリプラン3として作成したものとして説明する。
なお、リカバリプランは、上述した個数に限らず、それ以上の個数でもそれ以下の個数でも良く、受け付けた作業人員及び/又は作業内容の個数に応じて、適宜作成されるものである。
また、リカバリプラン作成モジュールが、リカバリプランを作成する構成として説明しているが、管理者が作成したリカバリプランを取得する構成であっても良い。例えば、管理者端末40は、管理者が作成したリカバリプランの入力を受け付ける、又は、管理者端末40は、入力を受け付けた変更内容に基づいてリカバリプランを作成する等を行い、このリカバリプランをコンピュータ10に送信する。コンピュータ10は、このリカバリプランを受信することにより、リカバリプランを作成するものとみなす構成も可能である。
【0061】
リカバリプラン記憶モジュールは、作成したリカバリプランを記憶する(ステップS52)。
リカバリプラン記憶モジュールは、作成したリカバリプランと、このリカバリプランの識別子(名称、ID、管理番号、整理番号等)とを紐付けて記憶する。リカバリプラン記憶モジュールは、リカバリプラン1、リカバリプラン2、リカバリプラン3を記憶する。
【0062】
以上が、リカバリプラン作成処理である。
コンピュータ10は、リカバリプラン作成処理により作成したリカバリプランを用いて、後述する処理を実行する。
なお、コンピュータ10は、リカバリプラン作成処理において、リカバリプランを記憶せずに、後述する処理を実行する構成も可能であり、この場合、後述する処理において、作成したリカバリプランをそのまま用いればよい。
【0063】
[コンピュータ10が実行する作業計画決定処理]
図12に基づいて、コンピュータ10が実行する作業計画決定処理について説明する。同図は、コンピュータ10が実行する作業計画決定処理のフローチャートを示す図である。作業計画決定処理は、当日分の作業全体の利益の算出処理(ステップS5)の詳細であり、上述したリカバリプラン作成処理の後に行われる処理である。
【0064】
シミュレートモジュールは、作成したリカバリプランのシミュレートを実行する(ステップS60)。
シミュレートモジュールは、上述したリカバリプラン作成処理により作成したリカバリプランのシミュレートを実行する。シミュレートモジュールが実行するシミュレートの内容は、作成したリカバリプランにおける作業人員が行う各工程を模擬的に再現するものであれば良い。シミュレートモジュールは、リカバリプラン1、リカバリプラン2及びリカバリプラン3を同時にシミュレートする。
シミュレートモジュールは、一のリカバリプランのみを作成していた場合、この一のリカバリプランをシミュレートし、複数のリカバリプランを作成していた場合、複数のリカバリプランを同時にシミュレートする。
【0065】
利益算出モジュールは、リカバリプランに基づく当日分の作業全体の利益を算出する(ステップS61)。
利益算出モジュールは、リカバリプランにおける各工程において、売上、支出、収支を算出する。ここで、支出は、経費と同義であり、収支は、利益と同義であり、売上から、支出を減算したものが、収支となる。ここでの各工程における売上は、荷主から支払われる配送費を各工程に割り振ったものや予め各工程に割り振られたものである。また、支出は、各工程に割り当てられた作業人員の人件費である。
利益算出モジュールは、入荷、入庫、ピッキング、流通加工、梱包、出荷の各工程について、売上、支出、収支を、其々算出する。利益算出モジュールは、この各工程における売上の和、支出の和、収支の和を、其々算出する。利益算出モジュールは、収支の和を、売上の和で除算し、算出した値を100分率で表したものを利益率として算出する。利益算出モジュールは、これらの計算結果に基づいて、収支総合として、リカバリプランに基づく当日分の作業全体の、売上、支出、収支、利益率を、其々算出する。
利益算出モジュールは、リカバリプラン1に基づく当日分の作業全体における売上を420,000円、支出を383,040円、収支を36,960円、利益率を8.8%と算出し、リカバリプラン2に基づく当日分の作業全体における売上を450,000円、支出を390,600円、収支を59,400円、利益率を13.2%と算出し、リカバリプラン3に基づく当日分の作業全体における売上を434,786円、支出を382,354円、収支を52,432円、利益率を12.1%と算出したものとして、以下の処理を説明する。
なお、各項目における数字は、出荷オーダや作業計画や受け付けた作業人員及び/又は作業内容等に伴って適宜算出されるものである。
【0066】
作業効率算出モジュールは、リカバリプランに基づく当日分の作業全体の作業効率を算出する(ステップS62)。
作業効率は、総所要時間、カットタイム余裕時間、余裕率、超過人時である。
作業効率算出モジュールは、入荷、入庫、ピッキング、流通加工、梱包、出荷の各工程について、作業量を算出する。作業効率算出モジュールは、シミュレーション結果のかかった時間(実際に、このリカバリプランにより倉庫作業を行った場合にかかる時間)に基づいて、総所要時間を算出する。カットタイムは、出荷する荷物毎に設定される締切時間であり、作業開始時刻から、作業終了時刻までに必要な時間である。作業効率算出モジュールは、カットタイムから総所要時間を減算した時間に基づいて、カットタイム余裕時間を算出する。また、作業効率算出モジュールは、カットタイムに対するカットタイム余裕時間の割合を、余裕率として算出する。カットタイム余裕時間がプラスの値である場合、作業時間に余裕が有ることを意味し、カットタイム余裕時間がマイナスの値である場合、作業時間が足りていないことを意味する。作業効率算出モジュールは、超過人時を、カットタイム余裕時間がマイナスの場合に必要な単位時間当たりの人数として算出する。
本実施形態において、作業効率算出モジュールは、リカバリプラン1に基づく当日分の作業全体における総所要時間を12h7m(12時間7分)、カットタイム余裕時間を-4:07(マイナス4時間7分)、余裕率を-17.5%、超過人時を13人時と算出し、リカバリプラン2に基づく当日分の作業全体における総所要時間を9h14m(9時間14分)、カットタイム余裕時間を-1:14(マイナス1時間14分)、余裕率を-13.4%、超過人時を6人時と算出し、リカバリプラン3に基づく当日分の作業全体における総所要時間を7h57m(7時間57分)、カットタイム余裕時間を0:03(0時間3分)、余裕率を0.6%、超過人時を0人時と算出したものとして、以下の処理を説明する。
なお、各項目における数字は、出荷オーダや作業計画や受け付けた作業人員及び/又は作業内容等に伴って適宜算出されるものである。
【0067】
シミュレート結果作成モジュールは、シミュレート結果を作成する(ステップS63)。
シミュレート結果作成モジュールは、上述したステップS61及びS62の処理により算出したリカバリプラン毎の利益及び作業効率を、リカバリプラン毎にまとめたシミュレート結果を作成する。シミュレート結果作成モジュールは、各リカバリプランの識別子と、このリカバリプランにおける作業人員及び/又は作業内容の変更内容と、このリカバリプランにおける算出した当日分の売上、支出、収支及び利益率(各工程における売上、支出及び収支を含む)と、このリカバリプランにおける算出した当日分の総所要時間、カットタイム余裕時間、余裕率、超過人時と、総合進捗(各工程における作業量、作業完了率等)、処理能力、人員配置等の各リカバリプランのシミュレート内容をグラフや表等により視覚化したものをまとめたシミュレート内容と、をまとめたものをシミュレート結果として作成する(
図13参照)。
図13において、シミュレート結果作成モジュールは、各リカバリプランの名称と、変更内容と、このリカバリプランにおける当日分の作業全体における作業効率及び利益率と、その他の内容に紐付けられた詳細アイコン88と、をまとめたものをシミュレート結果として作成している。
なお、シミュレート結果作成モジュールが作成するシミュレート結果は、
図13で示したものに限らず、それ以外の内容が含まれていても良いし、これらの内の何れか又は複数の組み合わせが含まれていても良い。また、詳細アイコン88として表示するのではなく、その他の内容そのものを表示する構成であっても良い。
【0068】
図12に戻り、作業計画決定処理の続きを説明する。
並び替えモジュールは、作成したシミュレート結果におけるリカバリプランを、所定の順序に並び替える(ステップS64)。
所定の順序は、利益及び/又は作業効率に基づいた順序であり、具体的には、利益の場合、当日分の作業全体の利益が大きい(利益率が大きい)順序である。また、作業効率の場合、作業効率が最適となる順序であり、最適な総所要時間順序、最適なカットタイム余裕時間順序、最適な超過人時順序、最適な余裕率順序の何れか又は複数の組み合わせである。また、管理者による優先順位とともに複数の変更内容が受け付けられた場合は、その優先順位に従って並び替える。
並び替えモジュールが実行する並び替えの例について説明する。
並び替えモジュールは、各リカバリプランにおいて算出した利益に基づいて、当日分の作業全体の利益が大きい順序に、作成したシミュレート結果におけるリカバリプランの順序の並び替えを実行する(
図14参照)。
図14において、並び替えモジュールは、
図13で示したシミュレート結果におけるリカバリプランの順序を、リカバリプラン2、リカバリプラン3、リカバリプラン1の利益率が大きい順序に並び替えを行っている。
また、並び替えモジュールは、各リカバリプランにおいて算出したカットタイム余裕時間に基づいて、最適なカットタイム余裕時間の順序に、作成したシミュレート結果におけるリカバリプランの順序の並び替えを実行する(
図15参照)。
図15において、並び替えモジュールは、
図13で示したシミュレート結果におけるリカバリプランの順序を、リカバリプラン3、リカバリプラン2、リカバリプラン1のカットタイム余裕時間が最適な順序に並び替えを行っている。
並び替えモジュールは、他の作業効率の内容も同様に、各リカバリプランにおいて算出した作業効率の内容に基づいて、最適な作業効率の内容の順序に、作成したシミュレート結果におけるリカバリプランの順序の並び替えを実行可能である。
なお、並び替えモジュールは、一の内容のみに基づいて、作成したシミュレート結果におけるリカバリプランの順序の並び替えを実行するだけでなく、複数の内容の組み合わせに基づいて、このリカバリプランの順序の並び替えを実行する構成も可能である。例えば、並び替えモジュールは、利益が大きい順序、且つ、最適なカットタイム余裕時間順序により、このリカバリプランの順序の並び変えを実行する構成も可能である。このような複数の内容により、リカバリプランの順序の並び変えを実行する場合、内容毎に、優先順位や閾値等を設定しておき、優先順位や閾値等に基づいて、並び替えを実行する等を行えばよい。
【0069】
図12に戻り、作業計画決定処理の続きを説明する。
リカバリプラン出力モジュールは、シミュレートしたリカバリプランを出力する(ステップS65)。
リカバリプラン出力モジュールは、上述した所定の順序(当日分の作業全体の利益が大きい順序、当日分の作業全体の作業効率が最適な順序等)に並び替えを行ったシミュレート結果を、管理者端末40に送信する。本実施形態では、リカバリプラン出力モジュールが、
図15で示したカットタイム余裕時間順に並び替えを行ったものを、管理者端末40に送信するものとして説明する。
管理者端末40は、このシミュレート結果を受信し、自身の表示部等に表示する(
図16参照)。
リカバリプラン出力モジュールは、このシミュレート結果を管理者端末40に表示させることにより、シミュレートしたリカバリプランを出力する。
【0070】
図16に基づいて、管理者端末40が表示するシミュレート結果について説明する。同図は、管理者端末40が表示するシミュレート結果の一例を模式的に示した図である。
管理者端末40は、受信したシミュレート結果に基づいて、シミュレート結果90を、自身の表示部に表示する。管理者端末40は、詳細アイコン91に対するタップ操作等の入力を受け付け、詳細アイコン91に紐付けられた内容である、総合進捗、処理能力、人員配置等のグラフ、全体の進捗や各工程の進捗、全体の収支や各工程の収支等のシミュレート内容を示す画面に遷移する(
図17及び
図18参照)。
図17は、シミュレート内容を示す画面の一例を模式的に示した図である。同図において、管理者端末40は、シミュレート結果90として、リカバリプランの識別子と、このリカバリプランにおける作業人員及び/又は作業内容の変更内容と、このリカバリプランにおける算出した当日分の利益率と、このリカバリプランにおける算出した当日分の総所要時間、カットタイム余裕時間、余裕率、超過人時と、総合進捗(各工程における作業量、作業完了率等)、処理能力、人員配置等の各リカバリプランのシミュレート内容をグラフや表等により視覚化したものを表示する。また、管理者端末40は、所定の入力を受け付けることにより、シミュレート結果90に表示する内容を
図18で示す内容に変更する。また、管理者端末40は、所定の入力を受け付けることにより、シミュレート結果90に表示する内容を
図16で示す内容に変更する。
図18は、シミュレート内容を示す画面の一例を模式的に示した図である。同図において、管理者端末40は、シミュレート結果90として、リカバリプランの識別子と、このリカバリプランにおける作業人員及び/又は作業内容の変更内容と、このリカバリプランにおける算出した当日分の売上、支出、収支及び利益率(各工程における売上、支出及び収支を含む)と、このリカバリプランにおける算出した当日分の総所要時間、カットタイム余裕時間、余裕率、超過人時と、総合進捗、処理能力、人員配置等の各リカバリプランのシミュレート内容をグラフや表等により視覚化したものをまとめたものを表示する。また、管理者端末40は、所定の入力を受け付けることにより、シミュレート結果90に表示する内容を
図17で示す内容に変更する。また、管理者端末40は、所定の入力を受け付けることにより、シミュレート結果90に表示する内容を
図16で示す内容に変更する。
【0071】
なお、上述した説明において、コンピュータ10は、シミュレートした全てのリカバリプランを出力する構成としているが、当日中に、その日の倉庫全体の作業工程が完了するリカバリプランを出力する構成であっても良い。具体的には、リカバリプラン出力モジュールは、シミュレートしたリカバリプランの内、算出されたカットタイム余裕時間が、0分以上の時間のリカバリプランのみを、シミュレート結果から抽出し、抽出したリカバリプランのみのシミュレート結果を、管理者端末40に出力すれば良い。本実施形態の場合では、リカバリプラン出力モジュールは、シミュレート結果からリカバリプラン3のみを抽出し、このリカバリプラン3のみのシミュレート結果を、管理者端末40に出力する(
図19参照)。
【0072】
図12に戻り、作業計画決定処理の続きを説明する。
選択受付モジュールは、出力したリカバリプランに対する選択を受け付ける(ステップS66)。
管理者端末40は、自身に表示したシミュレート結果の内、管理者が所望したリカバリプランに対する選択入力を受け付け、受け付けたリカバリプランを、コンピュータ10に送信する。管理者端末40は、
図16で示したシミュレート結果90における、リカバリプランに対する選択入力を受け付け、受け付けたリカバリプランを、コンピュータ10に送信する。
選択受付モジュールは、このリカバリプランを受信することにより、出力したリカバリプランに対する選択を受け付ける。
【0073】
作業計画決定モジュールは、受け付けたリカバリプランを、選択時以降の当日分の作業計画に決定する(ステップS67)。
作業計画決定モジュールは、上述した作業計画取得処理において取得した当初の当日分の作業計画を、受け付けたリカバリプランにおける、作業人員及び作業内容に変更し、選択時以降の当日分の作業計画に決定する。
【0074】
以上が、作業計画決定処理である。
コンピュータ10は、決定した作業計画を、倉庫作業者や管理者に通知等することにより、倉庫作業者や管理者に新たな作業計画を周知させても良いし、決定した作業計画に基づいて、倉庫作業に関連する機器類の動作の調整等に関連する処理を実行しても良い。
【0075】
[コンピュータ10が実行する前倒し作業可能通知処理]
図20に基づいて、コンピュータ10が実行する前倒し作業可能通知処理について説明する。同図は、コンピュータ10が実行する前倒し作業可能通知処理のフローチャートを示す図である。前倒し作業可能通知処理は、上述した作業計画決定処理に関連する処理であり、上述したステップS66の処理の後に行われる処理である。
【0076】
早期終了判断モジュールは、選択を受け付けたリカバリプランが、当日分の作業終了時刻が通常設定されている作業終了時刻よりも早く終わるリカバリプランであるか否かを判断する(ステップS70)。
通常設定されている作業終了時刻は、当初の作業計画における作業終了時刻や、予め設定された作業終了時刻である。
早期終了判断モジュールは、選択を受け付けたリカバリプランにおけるカットタイム余裕時間が、プラスの時間であるか否かを判断する。このとき、早期終了判断モジュールは、カットタイム余裕時間がプラスであれば、その時間の長短を考慮しなくともよいが、望ましくは、翌日以降の出荷オーダ及び作業計画における、所定の作業内容が実行可能な時間分のプラスであるか否かを判断する。
早期終了判断モジュールは、選択を受け付けたリカバリプランが、当日分の作業終了時刻が通常設定されている作業終了時刻よりも早く終わるリカバリプランではないと判断した場合(ステップS70 NO)、コンピュータ10は、前倒し作業可能通知処理を終了する。
【0077】
一方、早期終了判断モジュールは、選択を受け付けたリカバリプランが、当日分の作業終了時刻が通常設定されている作業終了時刻よりも早く終わるリカバリプランであると判断した場合(ステップS70 YES)、前倒し可能通知モジュールは、翌日以降の作業内容を前倒しで作業できる旨を通知する(ステップS71)。
前倒し可能通知モジュールは、翌日以降の作業内容を前倒しで作業できる旨の通知を作成し、この通知を、管理者端末40に送信する。
管理者端末40は、この通知を受信し、自身の表示部に表示する。
前倒し可能通知モジュールは、この通知を、管理者端末40に表示させることにより、翌日以降の作業内容を前倒しで作業できる旨を通知する
管理者は、この通知を閲覧することにより、翌日以降の作業内容を前倒しで作業できることを把握することが可能となる。この結果、管理者に、選択時以降の当日分の作業計画の更なる変更を促すことにもつながる。
【0078】
なお、上述した説明において、コンピュータ10は、選択を受け付けたリカバリプランに対して、作業終了時刻よりも早く終わるか否かを判断しているが、選択を受け付けたリカバリプランに限らず、シミュレートした全てのリカバリプランに対して、作業終了時刻よりも早く終わるか否かを判断する構成であっても良い。この場合、早期終了判断モジュールは、シミュレートし、算出したリカバリプラン毎のカットタイム余裕時間が、プラスであるか否かを判断する。前倒し可能通知モジュールは、プラスであるリカバリプランの識別子等を、翌日以降の作業内容を前倒しで作業できる旨の通知に含めて、管理者端末40に出力する等の構成が可能である。
【0079】
以上が、前倒し作業可能通知処理である。
【0080】
上述した各処理は、別個の処理として記載しているが、コンピュータ10は、上述した各処理の一部又は全部を組み合わせて実行する構成も可能である。また、コンピュータ10は、各処理において、説明したタイミング以外のタイミングであっても、その処理を実行する構成も可能である。
【0081】
上述した手段、機能は、コンピュータ(CPU、情報処理装置、各種端末を含む)が、所定のプログラムを読み込んで、実行することによって実現される。プログラムは、例えば、コンピュータからネットワーク経由で提供される(SaaS:ソフトウェア・アズ・ア・サービス)形態やクラウドサービスで提供されてよい。また、プログラムは、コンピュータ読取可能な記録媒体に記録された形態で提供されてよい。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記録装置又は外部記録装置に転送し記録して実行する。また、そのプログラムを、記録装置(記録媒体)に予め記録しておき、その記録装置から通信回線を介してコンピュータに提供するようにしてもよい。
【0082】
以上、本発明の実施形態について説明したが、本発明は上述したこれらの実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。
【0083】
(1)倉庫業務の各工程(例えば、入荷、入庫、ピッキング、流通加工、梱包、出荷)における作業人員と出荷オーダとに基づく作業量を管理する倉庫作業管理システムであって、
倉庫全体の各作業工程の完了情報を取得する取得部(例えば、取得部11、完了情報取得モジュール)と、
取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出する算出部(例えば、算出部13、進捗具合算出モジュール)と、
算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知するアラート通知部(例えば、アラート通知部12、アラート通知モジュール)と、
前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成する作成部(例えば、作成部14、リカバリプラン作成モジュール)と、
作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出するシミュレータ(例えば、シミュレータ15、シミュレートモジュール、利益算出モジュール)と、
を備える倉庫作業管理システム。
【0084】
(1)の発明によれば、倉庫作業中のトラブルによる進捗の遅れを素早く修正することが可能となる。また、前日に予測した人員計画及び作業計画と、現在の出荷オーダとが異なる場合、予測した人員計画及び作業計画を、どのように変更すれば、出荷オーダに間に合うかをレコメンドしたり、その際の収支シミュレーションを行ったりすることが可能となる。
【0085】
(2)前記作成部は、複数の前記リカバリプランを作成し、
前記シミュレータは、前記複数のリカバリプランをシミュレートし、各リカバリプランに基づく当日分の作業全体の利益を其々算出する、
(1)に記載の倉庫作業管理システム。
【0086】
(2)の発明によれば、複数のリカバリプランをシミュレートし、各リカバリプランに基づく当日分の作業全体の利益を把握することが可能になる。
【0087】
(3)シミュレートした前記複数のリカバリプランを同時に出力する出力部(例えば、リカバリプラン出力モジュール)と、
出力した前記複数のリカバリプランに対する選択を受け付ける選択受付部(例えば、選択受付モジュール)と、
選択を受け付けた前記リカバリプランを、選択時以降の当日分の前記作業計画に決定する決定部(例えば、作業計画決定モジュール)と、
を更に備える(2)に記載の倉庫作業管理システム。
【0088】
(3)の発明によれば、作成したリカバリプランの内、管理者等が決定したリカバリプランを、作業計画とすることが可能となる。
【0089】
(4)前記出力部は、シミュレートした前記複数のリカバリプランを、当日分の作業全体の利益が大きい順に出力する、
(3)に記載の倉庫作業管理システム。
【0090】
(4)の発明によれば、管理者等が、利益の確保に有効なリカバリプランを把握することが容易となる。
【0091】
(5)前記出力部は、シミュレートした前記複数のリカバリプランを、当日分の作業全体の作業効率が最適な順に出力する、
(3)に記載の倉庫作業管理システム。
【0092】
(5)の発明によれば、管理者等が、作業効率の点で有効なリカバリプランを把握することが容易となる。作業効率が良好なリカバリプランによれば、作業の遅れや進捗上の乖離を防止できる。
【0093】
(6)選択を受け付けた前記リカバリプランが、当日分の作業終了時刻が通常設定されている作業終了時刻よりも早く終わるリカバリプランである場合、翌日以降の作業内容を前倒しで作業できる旨を通知する前倒し可能通知部(例えば、前倒し可能通知モジュール)と、
を更に備える(3)に記載の倉庫作業管理システム。
【0094】
(6)の発明によれば、翌日以降の作業内容を前倒しで作業することが可能になる。
【0095】
(7)倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理するコンピュータが実行する倉庫作業管理方法であって、
倉庫全体の各作業工程の完了情報を取得するステップ(例えば、ステップS40)と、
取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出するステップ(例えば、ステップS41)と、
算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知するステップ(例えば、ステップS44)と、
前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成するステップ(例えば、ステップS51)と、
作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出するステップ(例えば、ステップS60、ステップS61)と、
を備える倉庫作業管理方法。
【0096】
(8)倉庫業務の各工程における作業人員と出荷オーダとに基づく作業量を管理するコンピュータに、
倉庫全体の各作業工程の完了情報を取得するステップ(例えば、ステップS40)、
取得した前記完了情報と、予め作成された作業計画上の作業工程とを比較し、前記作業工程の進捗具合を算出するステップ(例えば、ステップS41)、
算出結果に基づいて、前記作業工程の進捗具合が閾値以下の場合、アラートを通知するステップ(例えば、ステップS44)、
前記アラートを通知する度、作業人員及び/又は作業内容を変更したリカバリプランを作成するステップ(例えば、ステップS51)、
作成した前記リカバリプランをシミュレートし、前記リカバリプランに基づく当日分の作業全体の利益を算出するステップ(例えば、ステップS60、ステップS61)、
を実行させるためのコンピュータ読み取り可能なプログラム。
【符号の説明】
【0097】
1 倉庫作業管理システム
9 ネットワーク
10 コンピュータ
20 WMS
30 RCS
40 管理者端末
50 シフト管理システム
60 算出結果
61 進捗テーブル
62 進捗グラフ
70 アラート
71 フロアマット
72 進捗具合
73 受注オーダ
74 囲み線
80 変更入力用UI
81 作業員入力欄
82 プロセス入力欄
83 時間入力欄
84 アイコン
86 変更入力用UI
87 日付欄
88 詳細アイコン
90 シミュレート結果
91 詳細アイコン