Comments
Description
Transcript
配送不具合の解析のための履歴情報収集法に関する
配送不具合の解析のための履歴情報収集法に関する基礎検討 On Tracing Work Flows to Cope well with Possible Wrong Delivery 池 鋒（流通経済大学大学院） 増田 悦夫（流通経済大学） Feng CHI, Etsuo MASUDA (Ryutsu Keizai University) 要旨 競争が熾烈化する今後の配送サービスには一層の品質向上が求められる。本論文では、商品などが配送先に届けら れた際に納入数量や日時などの不具合が発生した場合、どの業務のミスによるものかを容易に検出できるようにする ための履歴情報収集法の検討を行い有効な一案を提案した。即ち、各業務の履歴情報はネットワーク上に収集し、各 個体の IC タグからそれらへリンクを張る方式が有効なこと、更にピッキング前に個体が確定しない問題への対応と して、第三の場所に仮想的な個体を定義しそこへ一時的に設定を行う方式が望ましいことなどを示した。 Abstract To cope well with possible wrong delivery problem is an important issue in the future parcel services. We have studied methods of maintaining the data of each work carried out for the delivery. We firstly clarify the data to be maintained and have proposed that the data should be maintained on the network connected by RFID tag attached to each article. We have also proposed how the data of the works prior to picking should be maintained. 1.まえがき は、ミスの発生箇所、原因を早期に突き止め再 コンビニエンスストア（以下コンビニと呼 発を防ぐことにより、徐々にミスの件数を零化 ぶ）の進展(1)やネット通販などの進展に伴い多 させていく必要がある。 頻度・小口配送の需要が増加している。また、 本論文では、質の高いサービスを実現する上 2007 年に予定されている郵政事業の民営化は での課題として、特にミスの少ない配送の実現 郵便事業のコンビニ化を促し小口配送分野で を取り上げ、最近活発に検討され注目を集めて の競争は熾烈化するものと予想される。競争が いる IC タグ例えば（5）（6）の適用も視野に入れ、対 熾烈化する今後の配送分野においては、業務の 策のひとつと考えられる業務履歴の活用法を 一層の効率化は言うまでもなく、荷主に対する 明らかにすることを狙いとしている。より具体 （2） 。業者 的には、今後、進展と熾烈な競争が予想される にとっては、預かり荷物の可視化、即ち、荷主 小口配送分野において、配送上の不具合が、ど より預かった荷物が、今、どこで、どのような の業務のミスによって引き起こされたものか 状態になっているのか、などを常に把握できる が容易に解明できるような履歴情報の収集法 ようになっていること、更にはミスの少ない配 を明らかにすることを狙いとしている。 質の高いサービスの提供が求められる 送が重要な課題となる。荷物を可視化するに当 従来の配送においてはミスによる不具合が たっては GPS、バーコード、Web などの技術を 無視し得ない状況にあることが報告されてお 用いて物流センタ内や配送途中での荷物の状 り（7）、また、対策面ではバーコードを用いて作 態をきめ細かく管理する（3）（4）必要がある。一 業履歴をネットワークに残すシステム（8）や IC 方、ミスの少ない配送の実現に当たっては、万 タグの活用による情報共有がトラブルの解析 一発生してしまった配送上の不具合について に有用であること（9）が示されている。また、 1 文献（6）にはトレーサビリティを確保するた れた数量と食い違う（数量不具合）、注文され めの履歴情報の利用法が示されている。しかし た届け日時と食い違う（日時不具合）、品質が ながら、配送上の不具合や情報の収集方法の得 納品可能なレベルにない（品質不具合）、届け 失を比較したものは見当たらない状況である。 先が発注主と異なる（届け先不具合）などであ 本論文では、商品などが配送先に届けられた る｡図 2 には、これらの不具合を引き起こすミ 際に数量の不一致や時刻の遅れなどの何らか スの具体例を業務と対応づけて示している。 の不具合が発生した場合、それが業務のどこの 着目する一連の業務 ミスで作りこまれたものかをいち早く検出で 発注 共同受発注 本部 製造業者 （メーカ） きるようにするための業務履歴の収集法につ ②出荷指示 いて検討を行った。 在庫引当 倉庫 2.代表的な業務形態と配送不具合の種類 入荷 2.1 代表的な業務形態 ③ 顧客 （小売業店舗） ①注文 共同物流センタ 出荷指示 納品 ④ ﾋﾟｯｷﾝｸﾞ 梱包 ⑤ ⑧ 店舗別 ⑥ 積載 仕分け ⑦ 小口配送の代表的な形態を図 1 に示す。製造 配送 ：物の流れ ○数字：業務の流れ メーカと複数の顧客との間には物流センタが 図 1 代表的な業務形態 存在し、当該センタを介して荷物の配送が行わ れる。顧客からの注文に対して物流センタから 顧客へ届けられるまでの一連の業務は一般に 3.履歴情報収集上の課題 は図 1 の丸数字で示したように流れる。なお、 履歴情報を収集するに当たり、以下のような 物流センタの在庫を補充するためには、センタ 課題について検討が必要である。 と製造業者（メーカ）との間での業務が行われ （1）課題 1：解析に必要な履歴情報種別 る。本論文での以下の検討では、物流センタ− 本論文では、不具合にいたるミスをどの業務 顧客間で行われる業務、即ち、図 1 において枠 （あるいはその実施者）で犯したかを特定する で囲んだ範囲を対象とする。メーカとセンタと ことが目的であり、この目的を達成するために の間の業務も同様であることから、検討結果は どのような種別の情報を収集すればよいかを 流用可能と考えられる。 明確にする必要がある。 物流センタと各顧客との間で行われる業務 （2）課題 2：履歴情報の収集単位 において作業の遅延や商品の紛失など何らか 履歴情報を残すに当たり、その単位として、 のミスが発生すると顧客への納品の際に不具 「業務」とする場合と取り扱われる商品即ち 合となって現れる。なお、業務毎に結果の検査 「個体」とする場合の案が考えられ、収集シス を行い不具合を未然に防止するという形態も テムを実現するに当たり、いずれが望ましいか 考えられるが、業務のスムーズな流れ、検査の を明確にしておく必要がある。 稼働増の回避などのメリットを考慮し、本論文 （3）課題 3：履歴情報を残す場所 では、納品時に不具合が確定するという形態を 更に、履歴情報を残す場所としては、ネット 前提とする。 ワーク上の他に、最近の IC タグ技術の進展を 2.2 不具合の種類 考慮すると、各商品につけられたタグ上も考え 本論文では、注文内容通りに顧客に納品され られる。システムの構築や運用の面からどのよ なかった場合を「不具合」と定義する。顧客に うに残すのが良いかを明確にする必要がある。 納品された際に発覚する不具合としては、図 2 （4）課題 4：ピッキングに先行する業務履歴の に示すような４種が考えられる。即ち、注文さ 残し方 2 不具合を招く原因 不具合を招く原因 業務種別 業務種別 不具合の種類 不具合の種類 手書きの注文数量の読み誤り 手書きの注文数量の読み誤り オンラインシステムの故障 オンラインシステムの故障 帳簿と実物の食い違い 帳簿と実物の食い違い 数量・品名の誤り及び未着 数量・品名の誤り及び未着 受注 受注 在庫引当 在庫引当 出荷指示 出荷指示 ピッキング・ ピッキング・ 梱包 梱包 （1）数量 （1）数量 不具合 不具合 パレットの品名表示外れ パレットの品名表示外れ 品物間違い、数量間違い 品物間違い、数量間違い 色の間違い 色の間違い 傷・汚れ 傷・汚れ 入り数の間違いなど 入り数の間違いなど 仕分け 仕分け （2）日時 （2）日時 不具合 不具合 店別の品物間違い 店別の品物間違い 数量間違い 数量間違い 違う店の品物を積んだ 違う店の品物を積んだ 積む品物の数量が間違った 積む品物の数量が間違った 無作為な積み込みによる品物 無作為な積み込みによる品物 の破損 の破損 積載 積載 （3）品質 （3）品質 不具合 不具合 配送 配送 道を間違えた（新人） 道を間違えた（新人） 突発事故・渋滞に巻き込まれ 突発事故・渋滞に巻き込まれ 商品の傷み 商品の傷み 納品 納品 違う店の品物を下ろした 違う店の品物を下ろした おろした品物の数量が間違った おろした品物の数量が間違った 不注意による品物の破損 不注意による品物の破損 （4）届け先 （4）届け先 不具合 不具合 図 2 不具合の種類とその要因の例 図 1 の枠内に含まれる業務のうち、ピッキン 業務の実施日付や時間帯（開始時刻、終了時刻） グや仕分けに先行して行われる業務は、業務の が影響するため、上記３種の他に、日付、実施 対象となる個体が特定されていない。このよう 時間帯も◎となる。また、品質不具合について な業務において履歴情報をどのように残せば は、業務の実施環境（温湿度、震動、塵など） よいかを明確にする必要がある。 に影響されて引き起こされるため、上記３種に 加え処理環境も◎となる。最後に、届け先不具 4.各課題の検討 合は数量不具合となって顕在化するため数量 4.1 解析に必要な履歴情報 不具合に包含されると考えられ、必要性レベル ミスを起こした業務を履歴情報から特定す は数量不具合と同一である。 るために、どんな情報が必要かを検討し整理を 以上より、不具合の解析に必須の情報として 行った。表 1 は、履歴情報の内容と各不具合の は表 1 に示す 7 種となり、これらを残すことに 解析における必要性レベルを示したものであ より発生した各配送不具合は 4.5 節に示すよう る。◎は不具合の解析に必須であることを示し、 な方法によって解析できると考えられる。 △は参考または不要であることを示している。 4.2 履歴情報の収集単位 解析の目的がある個体の配送不具合につい てその原因となった業 表 1 履歴情報と解析における必要性レベル 務や実施者を特定する 不具合の種類 ことであるので、業務 内 容 種別、実施者、処理さ れた個体の３種は全不 具合について◎となる。 数量不具合について は、さらに仕分けミス 3 章で指摘したように、履歴情報の収集単位 履 歴 情 報 の 内 容 数量不具合 日時不具合 品質不具合 届け先不具合 納入数量の食 納入日時の食 納入品質の食い 納入先の食い い違い（数量 い違い（遅配な 違い（腐敗、破損、 違い（誤配な 過不足） ど） 汚れなど） ど） 業務種別 ◎ ◎ ◎ ◎ 日付 △ ◎ △ △ 実施時間帯（開始時刻、 終了時刻） △ ◎ △ △ 実施者 ◎ ◎ ◎ ◎ でも起こり得るため納 処理された個体 ◎ ◎ ◎ ◎ 品先情報も◎となる。 処理環境 （温湿度,震動,塵など） △ △ ◎ △ 日時不具合については、 納品先情報 ◎ △ △ ◎ 不具合解析における必要性レベル ◎：必須 3 △：参考または不要 として２案が考えられる。 ｋまでｋ種の業務があるとして、業務ｉ（１≦ 案 A）各業務を単位に情報収集 ｉ≦ｋ）について同一の時間帯、実施者、環境、 業務毎に、いつ（実施時間帯）、誰によって 納品先について処理される個体の最大数量を （実施者） 、どんな環境で（実施環境） 、どの個 ｎi で示している。また、ひとつの個体について、 体が（個体情報）処理されたか、などの履歴情 全業務の履歴情報との対応関係を図 4 に示す。 報を収集し、それらを業務をインデクスとして 図 3 において、例えば、個体 1 は、業務 1、 ・・・、 管理する方式である。 業務 k の k 個の履歴情報を別々に指しているが、 案 B）各個体を単位に情報収集 実際には１箇所から指しており、この部分を取 個体毎に、いつ（実施時間帯）、どんな業務 り出して示したものが図 4 で j＝1 とした場合に において（業務種別）、どんな環境で（実施環 当たる。即ち、各個体には履歴情報の先頭番地 境）、誰によって（実施者）処理されたか、な を指し示す k 本のリンクが必要となる。 以下では、各個体を単位に履歴情報を収集す どの履歴情報を収集し、個体をインデクスとし る方式（案 B）をベースとして検討を進める。 て管理する方式である。 また、「個体」という用語を個々の商品の意味 両案を比較した場合、履歴情報の保持に必要 となる最小限の記憶容量は同等と考えられる。 で用いるものとする。 それは、k 種の業務で個体を N 個ずつ処理した 4.3 履歴情報を残す場所 場合、案 A では k 個の業務で N 個ずつ合計で （1）方式案 kN 個の履歴情報が、一方案 B では N 個の個体 履歴情報を残す場所としては、IC タグの利用 で k 個ずつ合計 Nk 個の履歴情報がそれぞれ必 報がそれぞれ必 も考慮すると 3 案を考えることができる （図 5） 。 要で、かつ各履歴情報のサイズが 同等（案 A：個体、日付、時間帯、 実施者、環境、納品先の 6 種分、 るからである。どちらを単位とし n1 ・・・ 環境 時間帯 納品先実施者 n1+1 n1個 ｋ個 時間帯業務１ 実施者日付 nk 個 業務ｋ 日付 時間帯業務ｋ 実施者日付 nk nk+1 環境 2n1 nk個 ・ ・ ・ 環境 時間帯 納品先実施者 環境 2nk 納品先 ・ ・ ・ にすることが可能である。 日付 ・ ・ ・ る限り、用意する記録領域は同等 n1個 履歴情報 リンク １ 業務１ ・ ・ ・ て収集しても、情報量が同じであ １ 個体 履歴情報 リンク ・ ・ ・ 者、環境、納品先の 6 種分）であ 個体 ・ ・ ・ 案 B：業務、日付、時間帯、実施 業務ｋ 業務１ 納品先 しかしながら、不具合が顕在化 した後のミスを犯した業務の解 ｎi個：業務ｉにおいて、同一の時間帯、実施者、環境、納品先について処理される 最大数量 析を考えた場合、案 B が望ましい 図 3 個体ベースの情報収集イメージ と考えられる。即ち、不具合は、 納品時に届いた個体について、数量が食い違う、 ｊ 遅れて届いた、品質が正常でない、などとして 履歴情報 個体 リンク 業務１ リンク 顕在化するため、そこからの解析は、その個体 を基準にして過去の業務を遡れるように保持 されている方が、探索が容易で効率的と考えら れる。 業務ｋ 日付 日付 時間帯 ｋ個 時間帯 実施者 ・・・ 実施者 環境 環境 仕分先 仕分先 案 B の場合の各業務における個体と履歴情報 との対応関係のイメージを図 3 に示す。１から 図 4 個体と履歴情報との対応関係 4 案Ba）商品分散方式 履歴情報書き込み 案 Ba）商品分散方式：商品の IC タグ上に残す。 業務Ｎ （NW）上に個体＋履歴情報を集中して残す。 業務Ｂ 業務Ａ 案 Bb）ネットワーク集中方式：ネットワーク ・・・ 案 Bc）両者併用方式：IC タグとネットワーク 案Bb）ＮＷ集中方式 の両者に分散させて残す。具体的には、履歴情 ネットワーク（ＮＷ） 報をネットワーク上に収集し、各履歴情報への リンクを IC タグ上に残す方式が考えられる。 ＤＢ （2）比較 個体情報＋履歴 情報の書き込み となる。案 Bb についても、バーコードでは記 憶容量制約から一般的に個体識別が困難と考 えられるため、同様に IC タグをつけることが ・・・ 業務Ｎ 業 務Ａ 業務Ｂ 案 Ba は各商品に IC タグをつけることが前提 案Bc）商品とＮＷの両方に残す方式 必要となる。案 Bc も同様に IC タグ付加が前提 ネットワーク（ＮＷ） である。 ①方式案の特徴比較 案 Ba は、NW 上の記憶手段を必要とせず、 NW との情報やり取りが不要な上、NW の混雑 ・・・ 業務Ｎ れているため、一度に大量の履歴情報が紛失す 業務Ｂ 業務Ａ も心配する必要がない。情報は各商品に分散さ リンク情報 書き込み ＤＢ 履歴情報 書き込み るような事態も起こらず信頼度上も望ましい。 ＤＢ：デ−タベース これに対し、案 Bb は案 Ba の逆であり、全部の 図 5 履歴情報を残す場所の方式案 個体に関する履歴情報を NW 上に保持する必要 があり、多数の個体についての記憶領域が必要 ③NW 上に必要となる記憶領域の比較 となる。しかし、すべての情報を容易に一覧す 次に、情報の保持に必要な記憶領域について ることができ、原因の解析に要する時間が少な 検討する。ここでは、図 3 に示す履歴情報の各 くて済むというメリットも考えられる。案 Bc エントリと個体から履歴情報へのリンクに必 は上記両案の中間的な特徴を有し、両方のメリ 要な各エントリが NW 上にどの程度必要となる ットを引き出し両者の欠点を緩和しつつ、それ かについて簡単なモデルを用いて評価を行う。 らのメリットも併せ持つことが期待できる。 ある商品の受注個数をＱとする時、その商品 ②不具合原因の解析への対応 の納品までの間に NW 上に保持される必要があ 履歴情報を用いて不具合の原因となるミス るエントリ数（即ち、履歴情報の各項目数＋個 を特定する際、案 Ba は IC タグに書き込まれた 体からのリンク数）は表 2 のようになる。前述 情報のみを利用することになる。不具合の中に したように、k は受注から納品までに経由する は、配送途中での紛失もあり得、どこで紛失が 業務の数、ni（１≦ｉ≦k）は業務ｉについて同 起こったかを解析しなければならない｡その場 一の時間帯、実施者、環境、納品先について処 合、紛失した個体の履歴情報は手元に存在しな 理される個体の最大数量である。ひとつの履歴 いため、解析不能となる。できるだけ多くの不 情報のエントリ数は、図 3 の内容を考慮し 6 エ 具合へ対応できるためには、個体と分離した場 ントリとした。以上より、案 Ba における IC タ 所に履歴情報を残す方が良いと考えられ、この グ上の所要エントリ数は、業務毎に 6 エントリ 点から案 Bb、案 Bc が推奨される。 必要（図 4 参照）なため 6k となる。案 Bb では、 5 表 2 所要エントリ数の評価式 受注数量Ｑ全体についてのエント リが NW のサーバ上に必要となる。 図 3 より、各業務において各履歴情 報（6 エントリ）が ni 個の個体で共 案種別 履歴情報の 所在 案Ba ＩＣタグ上 案Bb ＮＷ上 履歴情報の保持に必要なエントリ数 ＩＣタグ ＮＷのサーバ上 ６ｋ ０ 有されるため個体当たりのエント リ数は、6/ni＋1（1 は個体から履歴 情報へのリンク分）となる。従って、 注文数量Ｑ、業務数 k についての合 k 6 ∑ n 計は、 Ｑ i =1 i 6 k 案Bc ０ ＩＣタグ上＋ ＮＷ上 ∑ n Ｑ i =1 6 Ｑ n i =1 i k ｋ（リンク数） i + 1 ∑ Ｑ：ある商品の受注個数 + 1 となる。一方、 案 Bc では、履歴情報が NW 上に保存され履 歴情報へのリンクが IC タグ上に保持される ため、IC タグの所要エントリ数が各業務の履 歴情報へのリンク数 k となり、NW のサーバ 上の所要エントリ数が履歴情報分の 6 となる。表 2 において、k＝8、ｎi i i =1 k ∑ n Ｑ ＝20 および 1（for any i、1≦i≦k)とし、受注 個数を 100 個から 1000 個まで振らした場合 の評価例を図 6 に示す。なお、案 Ba は NW 上のエントリ数＝0 のため図示していない。 案 Bb と案 Bc との差は、各個体から各履歴情 報へのリンクの保持に相当する分である。案 Bc では、リンクを IC タグ側に保持すること 図 6 NW 上の所要エントリ数 によって、NW 上の記憶領域を削減できる。 いてはメーカからの入荷に関する情報や保管 受注数量Ｑに対しｎi が小さいほど所要エント 場所の情報などが管理されているが、顧客から リ数が大きくなっているが、これは表 2 の式か の受注、在庫引当、出荷指示などの業務は、一 らも分かるように、ni が小さいと各業務 i につ 般には、品目や数量などに基づいて行われ、ど いて管理すべき履歴情報（図 3 の太枠で囲まれ の個体がどの注文に対して出荷されるかは、ピ た 6 エントリから成る情報ブロック）の数が大 ッキング、仕分けが終了しないと決まらない きくなるためである。なお、図 6 は k＝8（固定） 。そこで、ピッキングに先行して行われ （図 7） の場合を示しているが、表 2 の式からも分かる る在庫引当、出荷指示などの業務では、節 4.2 ように所要エントリ数は業務数 k の値に正比例 で述べた個体を単位とする履歴情報の収集法 して増加していく。 （案 B)を明らかにする必要がある。方式案とし 以上の検討より、履歴情報を残す場所として ては以下の２案が考えられる。 は、個体紛失の不具合へも対応でき、NW 上の 案 Bc1）ピッキング候補の全個体に履歴情報へ 記憶領域が案 Bb より削減できる案 Bc が望まし のリンクを重複設定：ピッキングによって取り いと言える。 出される可能性のあるすべての個体について 4.4 ピッキングに先行する業務の履歴収集法 同一履歴情報へのリンクを重複して設定し、ピ 物流センタ内に保管されている各個体につ 6 この段階の業務は、倉庫内の商品（即ち、メーカからの入荷 に関する情報やロケーションなどが管理されている）の状況 を見て行われ、顧客や注文番号との対応は、とれていない。 ッキングによって 個体が確定した時、 ここで出荷される 個体が決まる ここで納入 先が決まる ピッキングされた 個体のリンクのみ を残し、その他の 個体のリンクをす べて削除する。 案 Bc2）仮想的な個 受注 在庫引当 顧客Ａの注文（５個） × × 出荷指示 × ピッキング 仕分け ５個 顧客Ｂの注文（３個） 顧客Ｃの注文（４個） 体を定義しそこへ × × × × × ◆ ◆ １２個 ３個 × ４個 履歴情報へのリン 図 7 ピッキングに先行する業務と個体との対応 クを設定：仮想的 るがリンク情報の削除の処理に比較し処理量 な個体を第三の場所（例えば、物流センタ内の は少なく無効処理も存在しない。しかも、物流 システム上）に定義し、そこに履歴情報へのリ センタのシステムを利用することにより、容易 ンクを設定する。ピッキングによって個体が確 に実現できるものと考えられる。従って、案 Bc2 定後、仮想的な個体から確定した個体へリンク が望ましい。 情報をコピーする。 4.5 原因箇所の解析例 案 Bc1 ではリンク情報の削除が無効処理とな 本節では、納品時に顕在化した配送不具合が る。この無効処理は、物流センタが収容する顧 どの業務によって引き起こされたかの解析例 客数、顧客の注文数、在庫数などの増加に伴っ を示す。図 8 は、ある特定な注文（即ち、顧客 て増えていく。それに対し、案 Bc2 では、ピッ #i からの受注#j）について５つの業務で対応す キングで個体確定後のコピー処理が必要とな る場合の例を示したものである。図 8 の（1） は数量不具合 顧客#iからの受注#j 顧客#iからの受注#j 合計 ・・・ｎ 業務１ 業務１ ・・・ｎ ・・ 業務３ ・・ ･･･ ・・・ 数量 不具合 個体 （ａ）数量不足の例：ｎ個の注文に対しｎ−１個納品 ・・・ｎ＋１ ・・・ｎ＋１ 業務４ ・・・ｎ−１ ･･･ ・・・ｎ 業務３ ・・・ｎ−１ 業務５ 合計 ・・・ｎ ・・ ・・ 業務２ ・・・ｎ−１ 業務４ 個体 の解析例であ NW上のﾒﾓﾘ（一部） NW上のﾒﾓﾘ（一部） 業務２ ･･･ 個体 ･･･ ･･･ 数量 不具合 NW上のﾒﾓﾘ（一部） 業務（業務２）が被疑となる。 【日時不具合】 遅配などの場合、履歴情報を最近から過去へ遡り、実施時間帯が標 準値（注：与えられるものと仮定）を逸脱している業務（業務３）が被疑となる。 【品質不具合】 腐敗などの場合、履歴情報を最近から過去へ遡り、業務環境が許容 業務４ 業務５ 個体 値（注：与えられるものと仮定）を逸脱している業務（業務３）が被疑となる。 【届け先不具合】 誤店舗への配送などの場合、履歴情報を最近から過去へ遡り、納 日時等 不具合 合では、ある 納品された各 個体の履歴情 【数量不具合】 ある受注について、業務毎の履歴情報の合計を調べ、変化した所の 業務３ る。数量不具 注文について、 被疑の業務 業務２ （b）が数量過 （ｂ）数量過多の例：ｎ個の注文に対しｎ＋１個納品 顧客#iからの受注#j 業務１ 量不足の場合、 多の場合であ ･･･ 個体 り、（a）が数 ・・・ｎ＋１ 業務５ （１）数量不具合 ･･･ 時間 品先情報を変化させた業務（業務３）が被疑となる。 報（NW 上） を調べ業務毎 の合計を求め る。合計値が 変化した所の 直前の業務 （２）日時不具合、品質不具合、届け先不具合 （業務 2）が被 図 8 配送不具合の解析例 7 疑となる。例えば、仕分先を間違えた場合や配 第三の場所（例えば、物流センタに設置のシス 送途中に紛失した場合などがこれで検出でき テム上）に定義し、そこに履歴情報へのリンク る｡また、図 8 の（2）は残りの日時不具合、品 を設定し、ピッキングで個体が確定した後に、 質不具合、届け先不具合の解析例である。これ 仮想的な個体から確定した個体へリンク情報 ら３種の不具合の解析法は、不具合状態で届け をコピーする方式が望ましいことを示した。 られた個体それ自身の履歴情報を調べて行う 今回提案した方式は、履歴情報へのリンクを という点で解析の仕方は基本的に同様である。 IC タグ上に保持する方式であり、商品が納入さ 例えば、遅配（日時不具合）、腐敗・破損（品 れた後には利用できなくなってしまう。履歴情 質不具合）状態での納品といった不具合は、対 報をその他の用途にも利用する場合には、納品 応する履歴情報を最近から過去へ遡り、標準的 時に IC タグ上の情報を NW 上へコピーするな な値（注：これらの値は given であるものとす どの対策が必要となる。 る）を逸脱していないかを調べ、逸脱している 今回は、業務ミスへの迅速な対応という目的 業務（業務 3）が被疑となる。誤配（届け先不 を達成するために必要な履歴情報種別、収集法 具合）については、誤った納品先情報に変化さ などを示したが、この他に、食料品などについ せた最初の業務が被疑となる。 て店舗で商品を購入する消費者へ安心を与え なお、品質不具合については、被疑の業務を るためのトレーサビリティとしての用途、さら 特定するために、温湿度、震動、加速度などの には業務の改善用という目的で収集する場合 環境条件と個体の不具合発生との因果関係を も考えられる。用途間で情報の重複も想定され 考慮した上で情報収集法、標準値の設定法を明 るため各用途を同時に満たす情報収集法につ 確にする必要がある。ひとつの方法として、環 いても今後明らかにする必要がある。 境条件は連続的に変化することから、それらを 常時監視するセンサを取り付けておき、当該業 参考文献・サイト 務において閾値を超えたか否かの情報を履歴 （1）http://www.meti.go.jp/report/tsuhaku2004/2004honbun/ として残すなどの方法が考えられるが、システ figindex.html（通商白書 2004、経済産業省）． ム実現上の今後の課題である。 （2）増田悦夫：物流と情報通信技術の関わり、日本物流学 会誌、No. 12、pp.151-158、2004． 5.むすび （3）http://www.trabox.ne.jp/tragps/（Tr@GPS、トラボックスネ 以上、本論文では、競争が熾烈化する今後の ット）． 配送におけるサービス品質向上策の一環とし （4 ）宮前直幸：物流可視化に向けた位置情報の標準化、 て、商品などが配送先に届けられた際に数量の NRI Consulting NEWS、Ｎｏ.14、2003 年 9 月． 不一致や時刻の遅れなどの不具合が発生した （5）商品トレーサビリティを巡る同床異夢 IC タグ狂想曲、 場合、それが業務のどこのミスで作りこまれた LOGI-BIZ、No.29、pp.7-33、2003 年 8 月． ものかをいち早く検出できるようにするため （6）RFID テクノロジ：無線 IC タグのすべて、日経ＢＰ社、 の業務履歴の収集法について検討を行った。 2004 年 3 月 17 日． その結果、履歴情報を収集する方法として、 （7）特集１ 配送ミス,代金未回収,ウイルス感染……、日経 各業務の履歴情報をネットワーク上に収集し、 ネットビジネス、Ｎｏ.090、p.38、2002 年 2 月 10 日． 個々の履歴情報に対するリンクを各個体に付 （8）http://www.digi-tek.com/support/doc/delivery_hp.pdf 加された IC タグに設定する方式が有効なこと （配送業務支援システム、ディジ・テック社）． を示した。また、ピッキングに先行して行われ （9）井上能行：IC タグのすべて、日本実業出版社、 る業務の履歴収集法としては、仮想的な個体を pp.46-48、2004 年 7 月 1 日． 8