JP5957992B2 - 指標提供方法、指標提供装置及び指標提供プログラム - Google Patents

Description

本発明は、指標提供方法、指標提供装置及び指標提供プログラムに関する。

製品の生産者と製品を必要とする人とをつなぐ物流が注目されている。かかる物流に関する指標を提示する技術の一例としては、サプライチェーンに関する指標を管理するサプライチェーン最適化システムが挙げられる。

サプライチェーン最適化システムは、販売計画の変動に対応して、資材調達、生産や販売といった複数の業務活動における在庫品の棚卸在庫費用と、製品及び資材調達の物流費用と、販売期間損失費用との合計が最小となる物流ルートのシミュレーションを行う。かかるシミュレーションの結果として得られた棚卸在庫費用、物流費用及び販売期間損失費用は、重要業績評価指標、いわゆるＫＰＩ（Key Performance Indicator）として設定された上でサプライチェーンを管理する指標として用いられる。

特開２００９−２１７５７３号公報

しかしながら、上記の従来技術は、以下に説明するように、物流業務の評価に有用な指標を提供することができないという問題がある。

すなわち、上記のサプライチェーン最適化システムは、サプライチェーンという枠組みで棚卸在庫費用、物流費用及び販売期間損失費用の合計を調整するものに過ぎない。それゆえ、上記のサプライチェーン最適化システムでは、サプライチェーン全体のコストが下がるのであれば、物流に関するコストや品質が悪化することも厭わない。したがって、上記のサプライチェーン最適化システムによってシミュレートされた棚卸在庫費用、物流費用や販売期間損失費用が指標として提供されたとしても、物流業務の評価に役立つとは限らない。

開示の技術は、上記に鑑みてなされたものであって、物流業務の評価に有用な指標を提供できる指標提供方法、指標提供装置及び指標提供プログラムを提供することを目的とする。

本願の開示する指標提供方法は、コンピュータが、下記の処理を実行する。前記コンピュータが、物流に関する作業が製品単位で指示された作業オーダーごとに前記作業がなされた作業日および前記製品の異常の有無が対応付けられた作業情報を用いて、前記作業日が所定期間に含まれる作業オーダーを集計する処理を実行する。さらに、前記コンピュータが、前記作業情報を用いて、前記作業日が前記期間に含まれる作業オーダーのうち前記製品に異常がある作業オーダーを集計する処理を実行する。さらに、前記コンピュータが、前記製品に異常がある作業オーダーの集計値を分子に含み、かつ前記作業オーダーの総数である集計値を分母に含めて作業に関する指標を算出する処理を実行する。さらに、前記コンピュータが、前記作業に関する指標を出力する処理を実行する。

本願の開示する指標提供方法の一つの態様によれば、物流業務の評価に有用な指標を提供できるという効果を奏する。

図１は、実施例１に係る物流ＫＰＩシステムの構成を示す図である。 図２は、実施例１に係る物流ＫＰＩサーバの機能的構成を示すブロック図である。 図３は、出庫データの一例を示す図である。 図４は、入庫データの一例を示す図である。 図５は、輸送データの一例を示す図である。 図６は、流通加工データの一例を示す図である。 図７は、集計結果の一例を示す図である。 図８は、集計結果の一例を示す図である。 図９は、ダッシュボード画面の一例を示す図である。 図１０は、ドリルダウン画面の一例を示す図である。 図１１は、実施例１に係る指標提供処理の手順を示すフローチャート（１）である。 図１２は、実施例１に係る指標提供処理の手順を示すフローチャート（２）である。 図１３は、実施例１及び実施例２に係る指標提供プログラムを実行するコンピュータの一例について説明するための図である。

以下に、本願の開示する指標提供方法、指標提供装置及び指標提供プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［システム構成］
まず、本実施例に係る物流ＫＰＩシステムの構成について説明する。図１は、実施例１に係る物流ＫＰＩシステムの構成を示す図である。図１に示す物流ＫＰＩシステム１は、拠点サーバ３０Ａ〜３０Ｃから収集された物流業務に関する電子データを用いて物流業務の評価に資する指標、いわゆる物流ＫＰＩを算出した上で本社端末５０へ提供するものである。

図１に示すように、物流ＫＰＩシステム１には、物流ＫＰＩサーバ１０と、拠点サーバ３０Ａ〜３０Ｃと、本社端末５０とが収容される。なお、図１の例では、３つの拠点サーバ、１つの本社端末をそれぞれ図示したが、開示のシステムは図示の構成に限定されない。すなわち、物流ＫＰＩシステム１は、任意の数の拠点サーバおよび本社端末を収容できる。なお、以下では、拠点３Ａ〜３Ｃの各拠点を区別なく総称する場合には「拠点３」と記載するとともに、拠点サーバ３０Ａ〜３０Ｃの各装置を区別なく総称する場合には、「拠点サーバ３０」と記載する場合がある。

これら物流ＫＰＩサーバ１０、拠点サーバ３０及び本社端末５０の間は、ネットワーク７を介して相互に通信可能に接続される。かかるネットワーク７には、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。

このうち、拠点サーバ３０は、物流業務を担う業者が保有する倉庫や事業所の等の拠点３に配設される物流業務用のサーバ装置である。拠点サーバ３０の一例としては、当該拠点３における物流業務の電子データを管理するＥＲＰ（Enterprise Resource Planning）サーバなどを採用できる。なお、本実施例では、拠点３Ａ〜３Ｃが生産部門および販売部門を擁する組織の物流部門として東京、北海道、大阪などの都道府県のエリア別に設けられる場合を想定して以下の説明を行うが、拠点３は生産業者や販売業者とは独立した物流業者であってもよい。

かかる拠点サーバ３０は、物流業務に関する電子データを物流ＫＰＩサーバ１０へアップロードする。このとき、拠点サーバ３０は、物流業務に関する電子データをリアルタイムでアップロードすることとしてもよいし、また、バッチ処理でアップロードすることとしてもかまわない。これら拠点サーバ３０及び物流ＫＰＩサーバ１０の間では、物流業界においてＥＤＩ（Electronic Data Interchange）を実装する場合に標準のフォーマットとして用いられるＪＴＲＮ（Japan transport）に準拠する形式で電子データが授受される。例えば、拠点サーバ３０から物流ＫＰＩサーバ１０へアップロードされる物流業務に関する電子データの一例としては、後述する出庫報告情報、入庫報告情報、運送完了報告、流通加工報告情報、運賃支払明細情報や人員別コスト情報などが挙げられる。

物流ＫＰＩサーバ１０は、物流ＫＰＩを本社端末５０へ提供するサーバ装置である。例えば、物流ＫＰＩサーバ１０は、組織が有する物流センタや拠点３のいずれかにおいてＷｅｂサーバとして実装することとしてもよいし、また、物流ＫＰＩサービスをアウトソーシングにより提供するクラウドとして実装することもできる。

かかる物流ＫＰＩサーバ１０は、組織に所属する所属員に絞って物流ＫＰＩサービスを解放する。例えば、物流ＫＰＩサーバ１０は、本社端末５０からアカウント名やパスワードなどのログインの認証情報の入力を受け付ける。そして、物流ＫＰＩサーバ１０は、本社端末５０から受け付けたログインの認証情報を用いて、本社端末５０の利用者をログイン認証する。この結果、物流ＫＰＩサーバ１０は、ログイン認証に成功した場合には、本社端末５０の利用者が所属員であると認証し、物流ＫＰＩサービスを解放する。このとき、物流ＫＰＩサーバ１０は、組織の所属員が有する権限にしたがって物流ＫＰＩサービスの一部または全部を解放する。

本社端末５０は、拠点３Ａ〜３Ｃを統括するヘッドクオーターである本社５の所属員によって使用される端末装置である。かかる本社端末５０の一例としては、パーソナルコンピュータを始めとする固定端末の他、携帯電話機、ＰＨＳやＰＤＡなどの移動体端末も採用できる。例えば、本社端末５０は、本社５の所属員、例えば物流部門の担当者等によって利用される。

なお、ここでは、本社５の所属員に本社端末５０を通じて物流ＫＰＩサービスを提供する場合を想定するが、各拠点３の所属員、例えば拠点３の管理者やそれに準ずる関係者が使用する拠点端末を通じて物流ＫＰＩサービスを提供することとしてもかまわない。この場合には、拠点３の管理者や関係者に各々の拠点３に関係する物流ＫＰＩに絞って閲覧させることもできる。

［物流ＫＰＩ］
続いて、本実施例に係る物流ＫＰＩサーバ１０が提供する物流ＫＰＩについて説明する。本実施例に係る物流ＫＰＩサーバ１０は、物流コストや物流品質などのあらゆる物流ＫＰＩを算出することができるが、とりわけ物流における作業品質を評価するのに有用な物流ＫＰＩの算出に優れている。

すなわち、物流における作業品質は、事故が起こった製品の金額や個数からだけで把握するのは困難である。なぜなら、事故が起こった製品の金額が大きかったからといって作業品質が悪いとは必ずしも言えず、また、事故が起こった製品の個数が多かったからといって作業品質が悪いとは必ずしも言えないからである。

例えば、単価が他の製品よりも高い製品に事故を起こしてしまった場合でも、単価が他の製品よりも低い製品に事故を起こしてしまった場合でも、１つの製品に事故が起こったことに変わりはない。それにもかかわらず、金額だけで評価を行った場合には、単価が高い製品に事故を起こしてしまった場合の方が事故の金額が高くなるので、実情以上に作業品質の評価をおとしめることになる。また、製品がダンボールやパレットなどで梱包された荷姿で取り扱われている時に事故があった場合には、いくつ製品が梱包されていようとも１つのダンボールやパレットに事故があったことに変わりはない。それにもかかわらず、個数だけで評価を行った場合には、多くの製品が梱包されていたダンボールやパレットに事故があった場合の方が製品の個数が多くなるので、実情以上に作業品質の評価をおとしめることになる。

そこで、本実施例に係る物流ＫＰＩサーバ１０は、物流部門の担当者による原因究明の作業を支援するために、製品に事故が起こった事故明細数を分子に含み、かつ総明細数を分母に含めて算出された「事故率」を物流ＫＰＩとして提供する。なお、ここで言う「明細」とは、入荷伝票、輸送伝票や流通加工伝票などの各種の伝票において入庫、輸送や流通加工等に関する作業がなされる場合の最小単位、例えば品目別に指示される作業オーダーを指す。

このような「事故率」を物流ＫＰＩとして提供することによって、全作業オーダーのうち事故が起こった作業オーダーがどの程度の割合であるかを物流部門等の担当者に把握させることができる。このため、物流部門等の担当者は、製品の価値や多寡などの作業とは無関係な重みが取り除かれた状態で事故の発生率を評価できる。したがって、物流における作業品質の評価に寄与することが可能になる。

［物流ＫＰＩサーバ１０］
次に、本実施例に係る物流ＫＰＩサーバ１０の機能的構成について説明する。図２は、実施例１に係る物流ＫＰＩサーバ１０の機能的構成を示すブロック図である。図２に示すように、物流ＫＰＩサーバ１０は、通信Ｉ／Ｆ（interface）部１１と、記憶部１３と、制御部１５とを有する。なお、物流ＫＰＩサーバ１０は、図２に示した機能部以外にも既知のサーバ装置が有する各種の機能部、例えば各種の入力デバイスや音声出力デバイスなどの機能部を有することとしてもかまわない。

通信Ｉ／Ｆ部１１は、他の装置、例えば拠点サーバ３０Ａ〜３０Ｃや本社端末５０との間で通信制御を行うインタフェースである。かかる通信Ｉ／Ｆ部１１の一態様としては、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。例えば、通信Ｉ／Ｆ部１１は、拠点サーバ３０から物流業務に関する電子データを受信したり、また、物流ＫＰＩサーバ１０が算出した物流ＫＰＩを本社端末５０へ送信したりする。

記憶部１３は、制御部１５で実行されるＯＳ（Operating System）、拠点サーバ３０との間で物流業務に関する電子データの交換を行う基盤ソフトや物流ＫＰＩを提供する指標提供プログラムなどの各種プログラムを記憶する記憶デバイスである。記憶部１３の一態様としては、フラッシュメモリなどの半導体メモリ素子、ハードディスク、光ディスクなどの記憶装置が挙げられる。なお、記憶部１３は、上記の種類の記憶装置に限定されるものではなく、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)であってもよい。

記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、出庫データ１３ａと、入庫データ１３ｂと、輸送データ１３ｃと、流通加工データ１３ｄとを記憶する。なお、上記の出庫データ１３ａ、入庫データ１３ｂ、輸送データ１３ｃ及び流通加工データ１３ｄ以外にも、他の物流業務に関する電子データ、例えば運賃支払明細情報や人員別コストに関するデータなども併せて記憶することもできる。

このうち、出庫データ１３ａは、出庫に関する各種のデータである。ここで言う「出庫」とは、拠点３の倉庫から製品を出す行為全般を指し、例えば、販売店への製品の納入を目的とする通常の出庫、製品を倉庫に保管したままで製品の名義を販売店へ変更する名変出庫や製品の製造元への返品を目的とするメーカ返品などが含まれる。

一例として、出庫データ１３ａは、拠点サーバ３０からアップロードされる物流業務に関する電子データのうち出庫報告情報が後述の基盤ソフト実行部１６によって登録される。他の一例として、出庫データ１３ａは、物流ＫＰＩとして事故率を算出するにあたって出荷伝票の明細を集計するために、後述の集計部１７ｂによって参照される。

かかる出庫データ１３ａの一態様としては、出荷依頼番号、明細番号、組織コード、出荷日、出荷依頼種別コード、受注者品名コード、個数および販売単価などの項目が対応付けられたデータを採用できる。

上記の項目のうち「出荷依頼番号」は、各々の出荷伝票を識別する番号を指す。出荷伝票には、複数品目の製品に関する出荷作業が含まれる場合がある。かかる出荷作業を製品の品目別に区別するために、出荷伝票には、出荷依頼番号の枝番として機能する「明細番号」が付与される。このように、出庫データ１３ａの１レコードは、出庫に関する作業がなされる場合の最小単位、例えば品目別に指示される作業オーダーごとに設けられる。なお、製品の品目ごとに出荷伝票が発行される場合には、必ずしも明細番号の項目を設ける必要はない。

また、「組織コード」は、出荷作業が行われる倉庫の管轄である拠点３を識別するコードを指す。また、「出荷日」は、出荷作業が行われる日付を指す。また、「出荷依頼種別コード」は、出荷伝票の依頼種別を識別するコードを指す。例えば、出荷依頼種別コードが「01」である場合には出庫を表し、出荷依頼種別コードが「02」である場合には名変出庫を表し、また、出荷依頼種別コードが「03」である場合にはメーカ返品を表す。また、「受注者品名コード」は、製品の納入先である販売店で商品を識別するために使用されるコードを指す。また、「個数」は、出庫される製品の数を指す。なお、製品がバラ、箱詰めやパレットなどのように複数の荷姿で取り扱われる場合には、荷姿を示す荷姿単位コードやその荷姿に梱包される製品の数を示す入り数などの項目をさらに設けることもできる。また、「販売単価」は、製品が販売される場合の単価を指し、上代とも呼ばれる。

図３は、出庫データ１３ａの一例を示す図である。図３の例では、２０１２年１月４日に拠点サーバ３０Ａからアップロードされた出庫データの一部を例示している。図３に示す各レコードのうち上から１番目および２番目のレコードは、出荷依頼種別コードが「01」であるので、これらはともに製品が納品先へ出荷される通常の出荷伝票であることがわかる。これら上から１番目と２番目のレコードは、両者ともに出荷依頼番号が「S001」であるので、同一の出荷伝票に関する出庫データであることを表す。このうち、明細番号が「1」である上から１番目のレコードは、販売単価が２００円である受注者品名コード「P001」の製品が納品先へ１０個出庫されたことを示す。一方、明細番号が「2」である上から２番目のレコードは、販売単価が１００円である受注者品名コード「P003」の製品が納品先へ５個出庫されたことを示す。

また、図３に示す３番目のレコードは、出荷依頼種別コードが「03」であるので、製造元へ返品されるメーカ返品の出荷伝票であることがわかる。かかる上から３番目のレコードは、販売単価が５０円である受注者品名コード「P002」の製品が製造元へ３つ返品されたことを示す。また、図３に示す４番目のレコードは、出荷依頼種別コードが「02」であるので、名変出庫の出荷伝票であることがわかる。かかる上から４番目のレコードは、販売単価が２００円である受注者品名コード「P001」の製品５つが販売店の名義へ変更されたことを示す。

入庫データ１３ｂは、入庫に関する各種のデータである。ここで言う「入庫」とは、拠点３の倉庫へ製品を入れる行為全般を指す。例えば、入庫は、製造元からの製品の搬入を目的とする通常の入庫、製品を倉庫に保管したままで製品の名義を販売店へ変更する名変入庫や流通加工が行われた製品を入庫する流通加工入庫などを含む。

一例として、入庫データ１３ｂは、拠点サーバ３０からアップロードされる物流業務に関する電子データのうち入庫報告情報が後述の基盤ソフト実行部１６によって登録される。他の一例として、入庫データ１３ｂは、物流ＫＰＩとして事故率を算出するにあたって入荷伝票の明細、入荷伝票の明細のうち事故が起こった事故明細を集計するために、後述の集計部１７ｂによって参照される。

かかる入庫データ１３ｂの一態様としては、入庫予定番号、明細番号、組織コード、入庫日、入庫予定種別コード、良品不良品コード、受注者品名コード、個数や商品事故コードなどの項目が対応付けられたデータを採用できる。

上記の項目のうち「入庫予定番号」は、各々の入荷伝票を識別する番号を指す。入荷伝票には、複数品目の製品に関する入荷作業が含まれる場合がある。かかる入荷作業を製品の品目別に区別するために、入荷伝票には、入庫予定番号の枝番として機能する「明細番号」が付与される。このように、入庫データ１３ｂの１レコードは、入庫に関する作業がなされる場合の最小単位、例えば品目別に指示される作業オーダーごとに設けられる。なお、製品の品目ごとに入荷伝票が発行される場合には、必ずしも明細番号の項目を設ける必要はない。

また、「入庫日」は、入荷作業が行われる日付を指す。また、「入庫予定種別コード」は、入荷伝票の依頼種別を識別するコードを指す。例えば、入庫予定種別コードが「01」である場合には入庫を表し、入荷予定種別コードが「02」である場合には名変入庫を表し、また、入荷予定種別コードが「06」である場合には流通加工入庫を表す。また、「良品不良品コード」は、入庫される製品が良品または不良品であるかを識別するコードを指す。例えば、良品不良品コードが「01」である場合には良品を表し、また、良品不良品コードが「03」である場合には事故品を表す。

また、「商品事故コード」は、入庫時または流通加工時に製品に起こった事故種類を表すコードを指す。例えば、商品事故コードが「WETTO（WET）」である場合には、事故種類が濡れであることを表し、また、商品事故コードが「BROKN」である場合には、事故種類が破損であることを表す。また、商品事故コードが「CVTRN（COVER TORN）」である場合には、事故種類が外装破れや袋切れであることを表し、また、商品事故コードが「STAIN（STAINED）」である場合には、事故種類が色付き又は汚れであることを示す。また、商品事故コードが「STALE」は、事故種類が鮮度落ちであることを表し、また、商品事故コードが「BAOFF（BANDS OFF）」である場合には、事故種類がバンドル切れであることを表す。かかるバンドルは、製品に付す付属製品であり、例えば、おまけ等の景品が挙げられる。なお、商品事故コードは、ＪＴＲＮには用意されていない独自にカスタマイズされた項目であるが、上記で例示したコードは、輸送に関する事故明細と集計を行うために、後述する運送完了報告に用いられる運送異常原因種別コード「11」〜「15」にリンクさせている。

図４は、入庫データ１３ｂの一例を示す図である。図４の例では、２０１２年１月４日に拠点サーバ３０Ａからアップロードされた入庫データの一部を例示している。図４に示す各レコードのうち上から１番目、２番目及び３番目のレコードは、入庫予定種別コードが「01」であるので、これらはともに製造元から入荷される通常の入荷伝票であることがわかる。さらに、上から１番目のレコードは、良品不良品コードが「01」であるので、受注者品名コード「P001」の製品は良品であることがわかる。

また、上から２番目と３番目のレコードは、両者ともに入庫予定番号が「G002」であるので、同一の入荷伝票に関する入庫データであり、さらに、良品不良品コード「03」が付与されているので、事故品であることがわかる。このうち、上から２番目のレコードは、商品事故コード「WETTO」から受注者品名コード「P002」の製品が濡れていることがわかる。一方、上から３番目のレコードは、商品事故コード「BROKN」から受注者品名コード「P003」の製品が破損していることがわかる。

また、上から４番目のレコードは、入庫予定種別コードが「06」であるので、流通加工が行われた製品の入荷伝票であることがわかる。さらに、上から４番目のレコードは、良品不良品コード「03」が付与されているので、事故品であることがわかる。加えて、上から４番目のレコードは、商品事故コード「BAOFF」から受注者品名コード「P001」の製品にバンドルが付属されていないことがわかる。

輸送データ１３ｃは、輸送に関する各種のデータである。一例として、輸送データ１３ｃは、拠点サーバ３０からアップロードされる物流業務に関する電子データのうち運送完了報告情報が後述の基盤ソフト実行部１６によって登録される。他の一例として、輸送データ１３ｃは、物流ＫＰＩとして事故率を算出するにあたって運送伝票の明細、運送伝票の明細のうち事故が起こった事故明細を集計するために、後述の集計部１７ｂによって参照される。

かかる輸送データ１３ｃの一態様としては、運送依頼番号、明細番号、組織コード、運送完了日、運送異常原因種別コード、受注者品名コード、個数や輸送コストなどの項目が対応付けられたデータを採用できる。

上記の項目のうち「運送依頼番号」は、各々の運送伝票を識別する番号を指す。運送伝票には、複数品目の製品に関する運送作業が含まれる場合がある。かかる運送作業を製品の品目別に区別するために、運送伝票には、運送依頼番号の枝番として機能する「明細番号」が付与される。このように、輸送データ１３ｃの１レコードは、輸送に関する作業がなされる場合の最小単位、例えば品目別に指示される作業オーダーごとに設けられる。なお、製品の品目ごとに運送伝票が発行される場合には、必ずしも明細番号の項目を設ける必要はない。

また、「運送完了日」は、運送作業が完了した日付を指す。また、「輸送コスト」は、製品の輸送に要するコストを指す。かかる輸送コストの一例としては、車両、船や航空機のランニングコスト、例えば燃料費や有料道路の料金などが加味された金額が搭載量で按分されたものが挙げられる。

また、「運送異常原因種別コード」は、運送中に製品に異常が起こった場合の原因の種別を示すコードである。例えば、運送異常原因種別コードが「11」である場合には、製品が濡れることにより品質が損なわれる濡損であることを示す。また、運送異常原因種別コードが「12」である場合には、製品の内容品が破損する内容品破損であることを示す。また、運送異常原因種別コードが「13」である場合には、製品の外装が破損する外装破損であることを示す。また、運送異常原因種別コードが「14」である場合には、製品が汚れることにより品質が損なわれる汚損であることを示す。また、運送異常原因種別コードが「15」である場合には、製品が腐敗する腐敗であることを示す。

これら運送異常原因種別コード「11」〜「15」は、その内容の意味するところが商品事故コードにおける「WETTO」と同様である。このため、運送異常原因種別コード「11」〜「15」及び商品事故コード「WETTO」、「BROKN」、「CVTRN」、「STAIN」及び「STALE」は同義のコードとして対応付けることができる。

図５は、輸送データ１３ｃの一例を示す図である。図５の例では、２０１２年１月４日に拠点サーバ３０Ａからアップロードされた輸送データの一部を例示している。図５に示す各レコードのうち上から１番目及び２番目のレコードは、運送異常原因種別コードに値が登録されていないので、これらはともに販売店へ無事に運送された運送伝票であることがわかる。一方、上から３番目及び４番目のレコードは、運送依頼番号が共通するとともに運送異常原因種別コードに値が登録されているので、同一の運送伝票であるとともに製品に事故が起こったことがわかる。このうち、上から３番目のレコードは、製品に起こった異常の原因が「濡損」であり、一方、上から４番目のレコードは、製品に起こった事故の原因が「汚損」であることがわかる。

流通加工データ１３ｄは、流通加工に関する各種のデータである。ここで言う「流通加工」とは、流通段階で行われる加工工程を指す。かかる流通加工の一例としては、製品の梱包、包装、封入の他、おまけ等の景品を製品に付したり、組み立てを行ったりする作業が挙げられる。

一例として、流通加工データ１３ｄは、拠点サーバ３０からアップロードされる物流業務に関する電子データのうち流通加工報告情報が後述の基盤ソフト実行部１６によって登録される。他の一例として、流通加工データ１３ｄは、物流ＫＰＩとして事故率を算出するにあたって流通加工伝票の明細を集計するために、後述の集計部１７ｂによって参照される。

かかる流通加工データ１３ｄの一態様としては、流通加工依頼番号、明細番号、組織コード、入庫日、受注者品名コード及び個数などの項目が挙げられる。ここで言う「流通加工依頼番号」とは、各々の流通加工伝票を識別する番号を指す。流通加工伝票には、複数品目の製品に関する流通加工作業が含まれる場合がある。かかる流通加工作業を製品の品目別に区別するために、流通加工伝票には、流通加工依頼番号の枝番として機能する「明細番号」が付与される。このように、流通加工データ１３ｄの１レコードは、流通加工に関する作業がなされる場合の最小単位、例えば品目別に指示される作業オーダーごとに設けられる。なお、製品の品目ごとに流通加工伝票が発行される場合には、必ずしも明細番号の項目を設ける必要はない。

図６は、流通加工データ１３ｄの一例を示す図である。図６の例では、２０１２年１月４日に拠点サーバ３０Ａからアップロードされた流通加工データの一部を例示している。図６に示す各レコードのうち、上から１番目のレコードは、受注者品名コード「P001」の製品が１０個流通加工されたことを示す。さらに、上から２番目のレコードは、受注者品名コード「P004」の製品が１０個流通加工されたことを示す。また、上から３番目及び４番目のレコードは、流通加工依頼番号が共通するので、同一の流通加工伝票であることがわかる。このうち、上から３番目のレコードは、受注者品名コード「P003」の製品が１５個流通加工されたことを示し、一方、上から４番目のレコードは、受注者品名コード「P002」の製品が５個流通加工されたことを示す。

なお、図２の例では、入庫データ１３ｂ、輸送データ１３ｃ及び流通加工データ１３ｄをそれぞれ個別のデータとして分散させる場合を例示したが、これらは統合して作業情報として記憶部１３に記憶することもできる。例えば、入庫データ１３ｂに含まれる入庫予定番号および明細番号、輸送データ１３ｃに含まれる運送依頼番号及び明細番号、さらには、流通加工データ１３ｄに含まれる流通加工依頼番号及び明細番号は、いずれも入庫作業、輸送作業や流通加工作業等の作業が製品単位で指示された作業オーダーである。そして、入庫データ１３ｂの入庫日、輸送データ１３ｃの運送完了日、流通加工データ１３ｄの入庫日は、いずれも作業がなされた作業日である。また、入庫データ１３ｂに含まれる入庫予定種別コードが入庫「01」である良品不良品コード、さらには、入庫予定種別コードが流通加工入庫「06」である良品不良品コードが良品「01」またはそれ以外であるかが製品の異常の有無を表し、輸送データ１３ｃに含まれる運送異常原因種別コードの有無が製品の異常の有無を表す。これらのことから、開示の装置は、作業オーダーごとに作業日および製品の異常の有無が対応付けられたレコードを作業情報として記憶することによって指標の算出に用いるデータを統合管理することもできる。

制御部１５は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１５は、図２に示すように、基盤ソフト実行部１６と、指標提供部１７とを有する。

このうち、基盤ソフト実行部１６は、拠点サーバ３０との間で物流業務に関する電子データの交換を行う基盤ソフトウェアを実行する処理部である。一態様としては、基盤ソフト実行部１６は、拠点サーバ３０から出庫報告情報がアップロードされた場合には、当該出庫報告情報を出庫データ１３ａとして記憶部１３へ登録する。他の一態様としては、基盤ソフト実行部１６は、拠点サーバ３０から入庫報告情報がアップロードされた場合には、当該入庫報告情報を入庫データ１３ｂとして記憶部１３へ登録する。更なる一態様としては、基盤ソフト実行部１６は、拠点サーバ３０から運送完了報告情報がアップロードされた場合には、当該運送完了報告情報を輸送データ１３ｃとして記憶部１３へ登録する。他の一態様としては、基盤ソフト実行部１６は、拠点サーバ３０から流通加工報告情報がアップロードされた場合には、当該流通加工報告情報を流通加工データ１３ｄとして記憶部１３へ登録する。なお、基盤ソフト実行部１６は、上記の他にも、運賃支払明細情報や人員別コスト情報を記憶部１３へ登録する。

これら出庫報告情報、入庫報告情報、運送完了報告情報、流通加工報告情報、運賃支払明細情報及び人員別コスト情報のアップロードの契機は、基盤ソフト実行部１６が任意のタイミングに設定できる。一例として、基盤ソフト実行部１６は、拠点サーバ３０に出庫報告情報、入庫報告情報、運送完了報告情報、流通加工報告情報及び人員別コスト情報を日次のバッチ処理でアップロードさせる。その一方で、基盤ソフト実行部１６は、運賃支払明細情報を月次のバッチ処理でアップロードさせることができる。他の一例として、基盤ソフト実行部１６は、拠点サーバ３０で入庫報告情報、運送完了報告情報、流通加工報告情報、運賃支払明細情報及び人員別コスト情報が更新される度にリアルタイムでアップロードさせることもできる。

指標提供部１７は、物流ＫＰＩを本社端末５０等へ提供する指標提供プログラムを実行する処理部である。指標提供部１７は、図２に示すように、アクセス制御部１７ａと、集計部１７ｂと、算出部１７ｃと、出力部１７ｄとを有する。

このうち、アクセス制御部１７ａは、本社端末５０等からのアクセスを制御する処理部である。一態様としては、アクセス制御部１７ａは、本社端末５０からアカウント名及びパスワードを含むログイン要求を受け付けた場合に、アカウント名及びパスワードが予め登録された正当なものであるか否かを判定する。これによって、アクセス制御部１７ａは、本社端末５０の利用者が組織の所属員であるか否かをログイン認証する。そして、アクセス制御部１７ａは、本社端末５０の利用者が所属員であると認証した場合、すなわちログイン認証に成功した場合に、物流ＫＰＩサービスを解放する。このとき、物流ＫＰＩサーバ１０は、組織の所属員が有する権限にしたがって物流ＫＰＩサービスの一部または全部を解放する。なお、ログイン認証に失敗した場合には、リトライを促すことによってアカウント名及びパスワードを再度入力させたり、また、ログイン認証に失敗した本社端末５０による物流ＫＰＩサーバ１０へのアクセスを禁止したりする。

集計部１７ｂは、所定期間内における各種伝票の明細を集計するとともに、所定期間内における各種伝票の事故明細を集計する処理部である。

すなわち、集計部１７ｂは、集計時にキーとして用いる項目の切り口、例えば期間、組織や製品の粒度が設定された切り口設定にしたがって集計を実行する。ここで、以下では、期間、組織および製品の切り口が「月次」、「拠点３Ａ」及び「全製品」に設定されている状況下で集計が実行される場合を想定するが、切り口設定は本社端末５０の使用者が有する権限の範囲で任意に設定できる。例えば、期間の切り口を「日次」や「半期」へ変更したり、組織の切り口を「全拠点」や「拠点別」へ変更したり、製品の切り口を「品目」や「品種」へ変更したりすることができる。なお、切り口設定は、過去の切り口の選択履歴から自動的に設定することもできる。

一態様としては、集計部１７ｂは、本社端末５０のログイン認証が成功すると、記憶部１３に記憶された入庫データ１３ｂのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる入庫日を持つ入庫データ１３ｂを読み出す。このとき、集計部１７ｂは、組織の切り口が「拠点３Ａ」に設定されているので、拠点３Ａに対応する拠点サーバ３０Ａ以外の組織コードの値を持つ入庫データ１３ｂは読み出さない。さらに、集計部１７ｂは、製品の切り口が「全製品」に設定されているので、受注者品名コードがどのような値であっても出荷日および組織コードが切り口設定の条件を満たす入庫データ１３ｂを全て読み出す。

続いて、集計部１７ｂは、先に読み出した入庫データ１３ｂの中からレコードを１つ選択する。このとき、集計部１７ｂは、前回までにインクリメントされていた総明細数の値を１つインクリメントする。その上で、集計部１７ｂは、今回に選択した入庫データ１３ｂのレコードに含まれる良品不良品コードが良品以外のコードであるか否かを判定する。そして、集計部１７ｂは、良品不良品コードが良品以外のコードである場合には、入庫予定種別コードが流通加工入庫であるか否かをさらに判定する。なお、集計部１７ｂは、良品不良品コードが良品を示すコードである場合には、入庫または流通加工の事故明細数のインクリメントは実行しない。

このとき、集計部１７ｂは、入庫予定種別コードが流通加工入庫ではない場合には、次のような処理を実行する。すなわち、集計部１７ｂは、前回までに商品事故コード別にインクリメントされていた入庫の事故明細数の集計値のうち今回選択したレコードの商品事故コードと同一の商品事故コードを持つ集計値をインクリメントする。一方、集計部１７ｂは、入庫予定種別コードが流通加工入庫である場合には、次のような処理を実行する。すなわち、集計部１７ｂは、前回までに商品事故コード別にインクリメントされていた流通加工の事故明細数の集計値のうち今回選択したレコードの商品事故コードと同一の商品事故コードを持つ集計値をインクリメントする。つまり、集計部１７ｂは、商品事故コード「WETTO」、「BROKN」、「CVTRN」、「STAIN」及び「STALE」のうち今回選択したレコードの商品事故コードが該当するものの集計値をインクリメントする。

このように、集計部１７ｂは、先に読み出した入庫データ１３ｂの全てのレコードについて集計を実行するまで、総明細数をインクリメントする処理または総明細数と入庫の事故明細数または流通加工の事故明細数とをインクリメントする処理を繰り返し実行する。

その後、集計部１７ｂは、記憶部１３に記憶された輸送データ１３ｃのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる運送完了日を持つ輸送データ１３ｃを読み出す。この読み出しについても、集計部１７ｂは、拠点３Ａに対応する拠点サーバ３０Ａ以外の組織コードの値を持つ輸送データ１３ｃは読み出さず、運送完了日および組織コードさえ切り口設定の条件を満たせば輸送データ１３ｃを読み出す。

そして、集計部１７ｂは、先に読み出した輸送データ１３ｃの中からレコードを１つ選択する。このとき、集計部１７ｂは、前回までにインクリメントされていた総明細数の値を１つインクリメントする。その上で、集計部１７ｂは、今回に選択した輸送データ１３ｃのレコードに含まれる運送異常原因種別コードの属性値の有無を判定する。なお、運送異常原因種別コードに属性値が存在しない場合には、輸送の事故明細数のインクリメントは実行しない。

このとき、集計部１７ｂは、運送異常原因種別コードに属性値が存在する場合には、次のような処理を実行する。すなわち、集計部１７ｂは、前回までに商品事故コード別にインクリメントされていた輸送の事故明細数の集計値のうち今回選択したレコードの運送異常原因種別コードに対応する商品事故コードを持つ集計値をインクリメントする。つまり、輸送データ１３ｃには、ＪＴＲＮにはない商品事故コードが使用されておらず、このままでは入庫および流通加工の事故明細との間で集計ができない。よって、集計部１７ｂは、運送異常原因種別コード「11」〜「15」と商品事故コード「WETTO」、「BROKN」、「CVTRN」、「STAIN」及び「STALE」との対応関係を用いて、輸送の事故明細数の集計値をインクリメントする。

例えば、集計部１７ｂは、今回選択したレコードの運送異常原因種別コードが「11」である場合には、商品事故コードが「WETTO」である輸送の事故明細数の集計値をインクリメントする。また、集計部１７ｂは、今回選択したレコードの運送異常原因種別コードが「12」である場合には、商品事故コードが「BROKN」である輸送の事故明細数の集計値をインクリメントする。また、集計部１７ｂは、今回選択したレコードの運送異常原因種別コードが「13」である場合には、商品事故コードが「CVTRN」である輸送の事故明細数の集計値をインクリメントする。また、集計部１７ｂは、今回選択したレコードの運送異常原因種別コードが「14」である場合には、商品事故コードが「STAIN」である輸送の事故明細数の集計値をインクリメントする。また、集計部１７ｂは、今回選択したレコードの運送異常原因種別コードが「15」である場合には、商品事故コードが「STALE」である輸送の事故明細数の集計値をインクリメントする。

このように、集計部１７ｂは、先に読み出した輸送データ１３ｃの全てのレコードについて集計を実行するまで、総明細数をインクリメントする処理、あるいは総明細数と輸送の事故明細数とをインクリメントする処理を繰り返し実行する。

その後、集計部１７ｂは、記憶部１３に記憶された流通加工データ１３ｄのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる入庫日を持つ流通加工データ１３ｄを読み出す。この読み出しについても、集計部１７ｂは、拠点３Ａに対応する拠点サーバ３０Ａ以外の組織コードの値を持つ流通加工データ１３ｄは読み出さず、入庫日および組織コードさえ切り口設定の条件を満たせば流通加工データ１３ｄを読み出す。そして、集計部１７ｂは、先に読み出した流通加工データ１３ｄのレコード数をそれまでにインクリメントされていた総明細数の集計値へ加算する。

さらに、集計部１７ｂは、記憶部１３に記憶された出庫データ１３ａのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる出荷日を持つ出庫データ１３ａを読み出す。この読み出しについても、集計部１７ｂは、拠点３Ａに対応する拠点サーバ３０Ａ以外の組織コードの値を持つ出庫データ１３ａは読み出さず、出荷日および組織コードさえ切り口設定の条件を満たせば出庫データ１３ａを読み出す。そして、集計部１７ｂは、先に読み出した出庫データ１３ａのレコード数をそれまでにインクリメントされていた総明細数の集計値へ加算する。

算出部１７ｃは、物流ＫＰＩを算出する処理部である。一態様としては、算出部１７ｃは、集計部１７ｂによる集計結果を用いて、事故率を算出する。これを説明すると、算出部１７ｃは、総明細数の集計値に対する入庫の事故明細数の集計値の割合、すなわち「入庫の事故明細数の集計値／総明細数の集計値」を商品事故コード別に計算することによって入庫の事故率を商品事故コード別に算出する。このとき、集計部１７ｃは、総明細数の集計値に対する入庫の事故明細数の集計値の割合を求めることとしたが、入庫の総明細数の集計値に対する入庫の事故明細数の集計値の割合を求めることとしてもかまわない。また、輸送および流通加工についても、算出部１７ｃは、上記の入庫における事故率の計算と同様にして、輸送の事故率および流通加工の事故率を商品事故コード別に算出する。

そして、算出部１７ｃは、先に商品事故コード別に算出された入庫の事故率を合算することによって入庫トータルの事故率を算出する。さらに、算出部１７ｃは、先に商品事故コード別に算出された輸送の事故率を合算することによって輸送トータルの事故率を算出する。さらに、算出部１７ｃは、先に商品事故コード別に算出された流通加工の事故率を合算することによって流通加工トータルの事故率を算出する。その上で、算出部１７ｃは、入庫トータルの事故率、輸送トータルの事故率および流通加工トータルの事故率を合算することによってトータルの事故率を算出する。

これら商品事故コード別の入庫の事故率、商品事故コード別の輸送の事故率、商品事故コード別の流通加工の事故率、入庫トータルの事故率、輸送トータルの事故率、流通加工トータルの事故率およびトータルの事故率は、図示しない内部メモリに保存される。

上記の事故率の他、算出部１７ｃは、記憶部１３に記憶された輸送データ１３ｃを始めとするデータを用いて、輸送コストを算出する。これを説明すると、算出部１７ｃは、運送完了日が月の初日からログイン日までの期間に含まれる輸送データ１３ｃを記憶部１３から読み出す。この読み出しについても、算出部１７ｃは、拠点３Ａに対応する拠点サーバ３０Ａ以外の組織コードの値を持つ輸送データ１３ｃは読み出さず、運送完了日および組織コードさえ切り口設定の条件を満たせば輸送データ１３ｃを読み出す。その後、算出部１７ｃは、先に読み出した輸送データ１３ｃに含まれる輸送コストを集計することによって輸送コストを算出する。

このとき、算出部１７ｃは、人員のコストや運賃の支払い明細書から得られる情報を用いて、より厳密な輸送コストを算出することもできる。一例としては、算出部１７ｃは、記憶部１３に記憶された図示しない運賃支払明細情報のうちログイン日を含む運賃請求年月の運賃支払明細情報のレコードを読み出す。このとき、算出部１７ｃは、ログインに成功した日付を含む運賃請求年月を持つ運賃支払明細情報がなければ、当該運賃請求年月の前月の運賃支払明細情報を読み出す。その上で、算出部１７ｃは、運賃支払明細情報に含まれる最新の燃料の料金や有料道路の料金を用いて、記憶部１３から読み出された時点の輸送データ１３ｃに含まれる輸送コストを補正することもできる。さらに、算出部１７ｃは、記憶部１３に記憶された図示しない人員別コスト情報のうち作業日が月の初日からログイン日までの期間に含まれる人員別コスト情報のレコードを読み出す。そして、算出部１７ｃは、先に読み出した人員別コスト情報の各レコードに含まれる作業開始時間から作業終了時間までの時間あたりの人員コストを集計した上で補正後の輸送コストに足し合わせることもできる。

出力部１７ｄは、算出部１７ｃによる算出結果を本社端末５０等へ出力する処理部である。一態様としては、出力部１７ｄは、切り口設定に定められた組織の粒度に関する輸送コスト、トータルの事故率、入庫トータルの事故率、輸送トータルの事故率及び流通加工トータルの事故率を含むダッシュボード画面を生成した上で本社端末５０へ出力する。その後、出力部１７ｄは、ダッシュボード画面を出力後に本社端末５０から入庫、輸送または流通加工のいずれかの事故率を切り口とするドリルダウンを受け付けた場合に、次のような処理を実行する。すなわち、出力部１７ｄは、図示しない内部メモリに記憶された商品事故コード別の入庫、輸送または流通加工の事故率と事故明細数を含むドリルダウン画面を生成した上で本社端末５０へ出力する。

なお、制御部１５には、各種の集積回路や電子回路を採用できる。また、制御部１５が有する機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。

［具体例］
ここで、図７〜図１０を用いて、指標提供方法の具体例について説明する。図７及び図８は、集計結果の一例を示す図である。図９は、ダッシュボード画面の一例を示す図である。図１０は、ドリルダウン画面の一例を示す図である。図７及び図８の例では、ダッシュボード画面における期間、組織および製品の切り口が「月次」、「拠点３Ａ」及び「全製品」に設定されている状況下で集計が実行されたものとする。図９及び図１０に示す「東京支店」は、拠点３Ａの組織名であるものとする。なお、ここでは、事故率を百分率（％）で表す場合を説明するが、除算値そのもので表すこととしてもよいし、分数や比で表すこととしてもかまわない。また、ここでは、小数点第二位以下を四捨五入して事故率を求めるものとする。

例えば、商品事故コード別の入庫の事故明細数の集計値、入庫トータルの事故明細数の集計値、輸送トータルの事故明細数の集計値、流通加工トータルの事故明細数の集計値および総明細数の集計値として図７及び図８に示す集計結果が得られたと仮定する。この場合には、算出部１７ｃによって商品事故コード別に「入庫の事故明細数の集計値／総明細数の集計値」が計算される。図８に示す例で言えば、製品の事故種類が「濡れ」である入庫の事故明細数の集計値「5」を総明細数の集計値「600」で除算した上で百分率に換算する。これによって事故種類が「濡れ」である入庫の事故率「0.8％」が算出される。さらに、事故種類が「破損」である入庫の事故明細数の集計値「18」を総明細数の集計値「600」で除算した上で百分率に換算する。これによって事故種類が「破損」である入庫の事故率「3.0％」が算出される。同様にして、事故種類が「外装破れ」である入庫の事故率「0.5％」が算出され、事故種類が「汚れ」である入庫の事故率「0.7％」が算出され、さらに、事故種類が「鮮度落ち」である入庫の事故率「0.0％」が算出される。

そして、濡れ、破損、外装破れ、汚れ及び鮮度落ちの事故種類別に算出された入庫の事故率を合算することによって入庫トータルの事故率「5.0％」を算出する。また、輸送および流通加工についても、上記の入庫における事故率の計算と同様にして、輸送の事故率および流通加工の事故率が商品事故コード別に算出された上で輸送トータルの事故率「10.0％」および流通加工トータルの事故率「2.5％」が算出される。その上で、入庫トータルの事故率「5.0％」、輸送トータルの事故率「10.0％」および流通加工トータルの事故率「2.5％」を合算することによってトータルの事故率「17.5％」が算出される。

このように事故率が算出された上で、出力部１７ｄによって輸送コスト、トータルの事故率、入庫トータルの事故率、輸送トータルの事故率及び流通加工トータルの事故率を含む図９に示すダッシュボード画面２００が生成された上で本社端末５０等へ表示される。図９に示すように、ダッシュボード画面２００には、拠点３Ａに対応する東京支店の輸送コスト「70000」、入庫トータルの事故率「5.0％」、輸送トータルの事故率「10.0％」、流通加工トータルの事故率「2.5％」及びトータルの事故率「17.5％」が表示される。

図９に示すダッシュボード画面２００によれば、トータルの事故率が１０％を超えている。これを閲覧する物流部門の担当者は、事故に遭った製品の金額や個数の多寡が小さい場合であっても物流品質が悪いことを把握できる。また、事故率が輸送コストと合わせて表示されるので、輸送コストの多寡が妥当なものであるかを併せて判断することもできる。さらに、入庫、流通加工および輸送の局面ごとに事故率が表示される。図９の例では、入庫トータルの事故率や流通加工トータルの事故率よりも輸送トータルの事故率が２倍以上悪いことがわかる。このため、物流部門の担当者は、物流品質のボトルネックが輸送品質にあること、さらには、輸送コストが高くなっている一因に事故が起こって販売店に納品できない製品が無駄に輸送されているからであることもわかる。なお、物流部門の担当者は、切り口が事故率に設定された状態でドリルダウンボタン２００Ａを押下することによって事故種類別の事故率を閲覧することができる。

なお、図９の例では、組織の切り口が拠点３Ａに対応する「東京支店」に設定されている場合を例示したが、組織の切り口設定が「拠点別」に設定し直された上で検索ボタン２００Ｂが押下された場合には、次のような表示を行うこともできる。すなわち、拠点３Ｂに対応する北海道支店及び拠点３Ｃに対応する大阪支店の保管コストおよび廃棄損を含むダッシュボード画面を本社端末５０に表示させることもできる。この場合には、東京支店、北海度支店及び大阪支店の間で保管コストを相対的に比較できるように、各々の支店の輸送コストを売上高や製品の重量で除算することによって算出された売上高または重量の単位あたりの輸送コストを表示させることもできる。

図９に示すドリルダウンボタン２００Ａが押下された場合には、商品事故コード別の入庫の事故率及び入庫の事故明細数を含む図１０に示すドリルダウン画面２１０を生成した上で本社端末５０等へ表示される。図１０に示すように、ドリルダウン画面２１０には、拠点３Ａに対応する東京支店について、事故種類が「濡れ」である入庫の事故率「0.8％」、事故種類が「破損」である入庫の事故率「3.0％」が表示される。さらに、ドリルダウン画面２１０には、事故種類が「外装破れ」である入庫の事故率「0.5％」、事故種類が「汚れ」である入庫の事故率「0.7％」、さらに、事故種類が「鮮度落ち」である入庫の事故率「0.0％」が表示される。さらに、ドリルダウン画面２１０には、事故種類「濡れ」、「破損」、「外装破れ」、「汚れ」及び「鮮度落ち」の事故明細数も各々表示される。

図１０に示すドリルダウン画面２１０によれば、他の事故種類の入庫の事故率よりも事故種類「破損」の事故率が３倍以上高い。これを閲覧した物流部門の担当者は、入庫に関する作業で発生する事故のうち落下や衝突などによる製品の破損が入庫に関する作業品質のボトルネックになっていることがわかる。かかる事故種類別の事故率を物流ＫＰＩとして提供することによって、落下や衝突などによる製品の破損に重点を置いた事故防止のマニュアルや注意喚起を拠点３Ａの人員に行うことができるので、拠点３Ａの入庫に関する作業品質の改善に資することが可能になる。なお、物流部門の担当者は、ドリルアップボタン２１０Ａを押下することによってダッシュボード画面２００へ戻ることができる。

なお、図９及び図１０の例では、期間の切り口がログイン日である「1月」に設定されている場合を例示したが、期間の切り口設定が「半期」に設定し直された上で検索ボタン２００Ｂまたは２１０Ｂが押下された場合には、次のような表示を行うこともできる。例えば、期間の切り口設定が「半期」に設定し直された場合には、ログイン日を含む上半期または下半期の６ヶ月分の物流ＫＰＩを表示させることもできる。また、図９及び図１０の例では、輸送コストや事故率の実績値を表示させる場合を例示したが、輸送コストや事故率の目標値が設定されている場合には、目標値を合わせて表示したり、実績値を目標値で除算した割合を示す達成率を表示させたりすることもできる。

［処理の流れ］
次に、本実施例に係る物流ＫＰＩサーバの処理の流れについて説明する。図１１及び図１２は、実施例１に係る指標提供処理の手順を示すフローチャートである。この指標提供処理は、本社端末５０のログイン認証が成功した場合に処理が起動される。

図１１に示すように、集計部１７ｂは、記憶部１３に記憶された入庫データ１３ｂのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる入庫日を持つ入庫データ１３ｂを読み出す（ステップＳ１０１）。

続いて、集計部１７ｂは、ステップＳ１０１で読み出した入庫データ１３ｂの中からレコードを１つ選択する（ステップＳ１０２）。そして、集計部１７ｂは、前回までにインクリメントされていた総明細数の値を１つインクリメントする（ステップＳ１０３）。

その上で、集計部１７ｂは、ステップＳ１０２で選択した入庫データ１３ｂのレコードに含まれる良品不良品コードが良品以外のコードであるか否かを判定する（ステップＳ１０４）。

そして、良品不良品コードが良品以外のコードである場合（ステップＳ１０４肯定）には、集計部１７ｂは、入庫予定種別コードが流通加工入庫であるか否かをさらに判定する（ステップＳ１０５）。なお、良品不良品コードが良品を示すコードである場合（ステップＳ１０４否定）には、入庫または流通加工の事故明細数のインクリメントは実行せずにステップＳ１０８の処理へ移行する。

このとき、入庫予定種別コードが流通加工入庫ではない場合（ステップＳ１０５否定）には、次のような処理を実行する。すなわち、集計部１７ｂは、前回までに商品事故コード別にインクリメントされていた入庫の事故明細数の集計値のうち今回選択したレコードの商品事故コードと同一の商品事故コードを持つ集計値をインクリメントする（ステップＳ１０６）。

一方、入庫予定種別コードが流通加工入庫である場合（ステップＳ１０５肯定）には、集計部１７ｂは、次のような処理を実行する。すなわち、集計部１７ｂは、前回までに商品事故コード別にインクリメントされていた流通加工の事故明細数の集計値のうち今回選択したレコードの商品事故コードと同一の商品事故コードを持つ集計値をインクリメントする（ステップＳ１０７）。

その後、上記のステップＳ１０１で読み出した入庫データ１３ｂの全てのレコードについて集計を実行するまで（ステップＳ１０８否定）、上記のステップＳ１０２〜ステップＳ１０７までの処理を繰り返し実行する。

そして、入庫データ１３ｂの全てのレコードについて集計を実行すると（ステップＳ１０８肯定）、集計部１７ｂは、次のような処理を実行する。すなわち、集計部１７ｂは、記憶部１３に記憶された輸送データ１３ｃのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる運送完了日を持つ輸送データ１３ｃを読み出す（ステップＳ１０９）。

続いて、集計部１７ｂは、ステップＳ１０９で読み出した輸送データ１３ｃの中からレコードを１つ選択する（ステップＳ１１０）。そして、集計部１７ｂは、前回までにインクリメントされていた総明細数の値を１つインクリメントする（ステップＳ１１１）。

その上で、集計部１７ｂは、今回に選択した輸送データ１３ｃのレコードに含まれる運送異常原因種別コードの属性値の有無を判定する（ステップＳ１１２）。なお、運送異常原因種別コードに属性値が存在しない場合（ステップＳ１１２否定）には、輸送の事故明細数のインクリメントは実行せずにステップＳ１１４の処理に移行する。

このとき、運送異常原因種別コードに属性値が存在する場合（ステップＳ１１２肯定）には、集計部１７ｂは、次のような処理を実行する。すなわち、集計部１７ｂは、前回までに商品事故コード別にインクリメントされていた輸送の事故明細数の集計値のうち今回選択したレコードの運送異常原因種別コードに対応する商品事故コードを持つ集計値をインクリメントする（ステップＳ１１３）。

その後、ステップＳ１０９で読み出した輸送データ１３ｃの全てのレコードについて集計を実行するまで（ステップＳ１１４否定）、上記のステップＳ１１０〜ステップＳ１１３までの処理を繰り返し実行する。

そして、輸送データ１３ｃの全てのレコードについて集計を実行すると（ステップＳ１１４肯定）、集計部１７ｂは、次のような処理を実行する。すなわち、図１２に示すように、集計部１７ｂは、記憶部１３に記憶された流通加工データ１３ｄのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる入庫日を持つ流通加工データ１３ｄを読み出す（ステップＳ１１５）。

続いて、集計部１７ｂは、ステップＳ１１５で読み出した流通加工データ１３ｄのレコード数をそれまでにインクリメントされていた総明細数の集計値へ加算する（ステップＳ１１６）。

そして、集計部１７ｂは、記憶部１３に記憶された出庫データ１３ａのうち、所定期間、例えば月の初日からログインに成功したログイン日までの期間に含まれる出荷日を持つ出庫データ１３ａを読み出す（ステップＳ１１７）。続いて、集計部１７ｂは、ステップＳ１１７で読み出した出庫データ１３ａのレコード数をそれまでにインクリメントされていた総明細数の集計値へ加算する（ステップＳ１１８）。

その後、算出部１７ｃは、集計部１７ｂによる集計結果を用いて、下記の事故率を算出する（ステップＳ１１９）。例えば、商品事故コード別の入庫の事故率、商品事故コード別の輸送の事故率、商品事故コード別の流通加工の事故率、入庫トータルの事故率、輸送トータルの事故率、流通加工トータルの事故率およびトータルの事故率が算出される。さらに、算出部１７ｃは、記憶部１３に記憶された輸送データ１３ｃを始めとするデータを用いて、輸送コストを算出する（ステップＳ１２０）。

そして、出力部１７ｄは、切り口設定に定められた組織の粒度に係る輸送コスト、トータルの事故率、入庫トータルの事故率、輸送トータルの事故率及び流通加工トータルの事故率を含むダッシュボード画面を生成して本社端末５０へ出力する（ステップＳ１２１）。

その後、本社端末５０からダッシュボード画面を出力後に本社端末５０から入庫、輸送または流通加工のいずれかの事故率を切り口とするドリルダウンを受け付けた場合（ステップＳ１２２肯定）には、出力部１７ｄは、次のような処理を実行する。すなわち、出力部１７ｄは、図示しない内部メモリに記憶された廃棄理由別の売上高ベース廃棄損、廃棄理由別の在庫金額ベース廃棄損及び廃棄理由別の廃棄コストを含むドリルダウン画面を生成した上で本社端末５０へ出力する（ステップＳ１２３）。

また、ドリルダウン画面でドリルアップを受け付けた場合（ステップＳ１２４肯定）には、出力部１７ｄは、ダッシュボード画面を改めて本社端末５０へ出力する（ステップＳ１２１）。

その後、ステップＳ１２１〜ステップＳ１２４の処理は、ダッシュボード画面もしくはドリルダウン画面の表示を終了する操作が行われるまで繰り返し実行される。

なお、図１１に示すフローチャートのステップＳ１０１〜Ｓ１０８と、ステップＳ１０９〜Ｓ１１４と、ステップＳ１１５〜Ｓ１１６と、ステップＳ１１７〜Ｓ１１８の処理は、必ずしも同一のフローで実行される必要はない。また、各々の処理は、順序の後先も自由に選択して実行することができる。

［実施例１の効果］
上述してきたように、本実施例に係る物流ＫＰＩサーバ１０は、製品に事故が起こった作業オーダーを分子に含み、かつ作業オーダーの総数を分母に含めて事故率を算出した上で事故率を物流ＫＰＩとして出力する。このため、本実施例に係る物流ＫＰＩサーバ１０では、全作業オーダーのうち事故が起こった作業オーダーがどの程度の割合であるかを物流部門等の担当者に把握させることができる。それゆえ、本実施例に係る物流ＫＰＩサーバ１０では、物流部門等の担当者に製品の価値や多寡などの作業とは無関係な重みが取り除かれた状態で事故の発生率を評価させることができる。したがって、本実施例に係る物流ＫＰＩサーバ１０によれば、物流における作業品質の評価に有用な指標を提供することが可能である。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、基盤ソフト実行部１６または指標提供部１７を物流ＫＰＩサーバ１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、指標提供部１７が有する機能部の一部を物流ＫＰＩサーバ１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、出庫データ１３ａ、入庫データ１３ｂ、輸送データ１３ｃまたは流通加工データ１３ｄの全部または一部をデータベースサーバとして別の装置が記憶する構成を採用することもできる。この場合には、データベースサーバとネットワーク接続されて協働することで、上記の物流ＫＰＩサーバ１０の機能を実現するようにしてもかまわない。

［指標提供プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１３を用いて、上記の実施例と同様の機能を有する指標提供プログラムを実行するコンピュータの一例について説明する。

図１３は、実施例１及び実施例２に係る指標提供プログラムを実行するコンピュータの一例について説明するための図である。図１３に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１３に示すように、上記の実施例１で示した指標提供部１７と同様の機能を発揮する指標提供プログラム１７０ａが予め記憶される。この指標提供プログラム１７０ａについては、図２に示した各々の指標提供部１７の各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７０に格納されれば良い。

そして、ＣＰＵ１５０が、指標提供プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図１３に示すように、指標提供プログラム１７０ａは、指標提供プロセス１８０ａとして機能する。この指標提供プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、指標提供プロセス１８０ａは、図２に示した指標提供部１７にて実行される処理、例えば図１１〜図１２に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。

なお、上記の指標提供プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。

１ 物流ＫＰＩシステム
３Ａ，３Ｂ，３Ｃ 拠点
５ 本社
７ ネットワーク
１０ 物流ＫＰＩサーバ
１１ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ 出庫データ
１３ｂ 入庫データ
１３ｃ 輸送データ
１３ｄ 流通加工データ
１５ 制御部
１６ 基盤ソフト実行部
１７ 指標提供部
１７ａ アクセス制御部
１７ｂ 集計部
１７ｃ 算出部
１７ｄ 出力部
３０Ａ，３０Ｂ，３０Ｃ 拠点サーバ
５０ 本社端末

Claims (7)

1. コンピュータが、
   物流に関する作業の内容を示す作業オーダー毎に、作業がなされた作業日および作業の対象となった製品の異常の有無が対応付けられた作業情報を用いて、作業日が所定期間に含まれる作業オーダー数を集計し、
   前記作業情報を用いて、作業日が前記所定期間に含まれる作業オーダーのうち作業の対象となった製品に異常がある作業オーダー数を集計し、
   製品に異常がある作業オーダー数の集計値を分子に含み、かつ作業日が前記所定期間に含まれる作業オーダー数の集計値を分母に含めて作業に関する指標を算出し、
   前記作業に関する指標を出力する
   処理を実行することを特徴とする指標提供方法。
2. 前記作業情報は、入庫に関する作業オーダー、輸送に関する作業オーダー及び流通加工に関する作業オーダーを含み、
   前記製品に異常がある作業オーダー数を集計する処理は、
   入庫、輸送および流通加工の場面別に製品に異常がある作業オーダー数を集計し、
   前記作業に関する指標を算出するは、
   入庫、輸送および流通加工の場面別に作業に関する指標を算出し、
   前記作業に関する指標を出力するは、
   入庫、輸送および流通加工の場面別に算出された作業に関する指標を出力することを特徴とする請求項１に記載の指標提供方法。
3. 前記作業情報は、前記作業オーダーごとに前記製品の異常種類がさらに対応付けられたものであって、
   前記製品に異常がある作業オーダーを集計する処理は、
   異常種類別に製品に異常がある作業オーダー数を集計し、
   前記作業に関する指標を算出する処理は、
   異常種類別に作業に関する指標を算出し、
   前記作業に関する指標を出力する処理は、
   異常種類別に算出された作業に関する指標を出力することを特徴とする請求項１または２に記載の指標提供方法。
4. 前記作業に関する指標を出力する処理は、
   製品の輸送コストとともに前記作業に関する指標を出力することを特徴とする請求項１、２または３に記載の指標提供方法。
5. 物流に関する作業の内容を示す作業オーダー毎に、作業がなされた作業日および作業の対象となった製品の異常の有無が対応付けられた作業情報を記憶する記憶部と、
   前記記憶部に記憶された作業情報を用いて、作業日が所定期間に含まれる作業オーダー数を集計するとともに、作業日が前記所定期間に含まれる作業オーダーのうち作業の対象となった製品に異常がある作業オーダー数を集計する集計部と、
   製品に異常がある作業オーダー数の集計値を分子に含み、かつ作業日が前記所定期間に含まれる作業オーダー数の集計値を分母に含めて作業に関する指標を算出する算出部と、
   前記作業に関する指標を出力する出力部と
   を有することを特徴とする指標提供装置。
6. コンピュータに、
   物流に関する作業の内容を示す作業オーダー毎に、作業がなされた作業日および作業の対象となった製品の異常の有無が対応付けられた作業情報を用いて、作業日が所定期間に含まれる作業オーダー数を集計し、
   前記作業情報を用いて、作業日が前記所定期間に含まれる作業オーダーのうち作業の対象となった製品に異常がある作業オーダー数を集計し、
   製品に異常がある作業オーダー数の集計値を分子に含み、かつ作業日が前記所定期間に含まれる作業オーダー数の集計値を分母に含めて作業に関する指標を算出し、
   前記作業に関する指標を出力する
   を実行させることを特徴とする指標提供プログラム。
7. 物流に関する作業の内容を示す作業オーダー毎に、作業の対象となった製品の異常の有無、作業オーダーの種類、製品の異常の種類が対応付け記憶された作業情報を参照し、前記作業オーダーの種類毎に製品に異常がある作業オーダーの割合と前記作業オーダーの種類それぞれについて製品の異常の種類毎に製品に異常がある作業オーダーの割合を算出し、
   前記作業オーダーの種類毎の製品に異常がある作業オーダーの割合が表示されている状態で、いずれかの作業オーダーの選択がなされると、選択された前記いずれかの作業オーダーについて前記製品の異常の種類毎に製品に異常がある作業オーダーの割合を出力する、
   処理をコンピュータが実行することを特徴とする指標提供方法。

Images