在庫管理システムの設計と実装 ―引当済み在庫ではなぜ不十分かー
6
0
0
全文
(2) Vol.2010-IS-112 No.4 2010/6/5. 情報処理学会研究報告 IPSJ SIG Technical Report. 在庫の集計処理を行いたい場合，それぞれの夜間バッチの終了を待たなければならず， 場合によっては全社の在庫集計に１週間ほどものタイムラグが生じるケースさえある。 自社拠点間の在庫融通の入出荷を扱うために，在庫の集計時に，重複をのぞく処理が 必要であり，在庫の集計に時間がかかる原因となっている。. この方法については，実装が容易，計算機資源を多く必要としないというメリットが あり。単一の在庫拠点での入出荷を扱うには十分な方法である。これは，ある時点の 在庫の量を基礎データとしてシステムを作成するので，ストックベースのシステムと 呼ぶ。 2.2. 最後の問題は，在庫データの修正処理の問題である。過去の入荷，出荷データに誤 りがあった場合，在庫量の修正をさかのぼって修正する場合の処理は，過去の在庫推 移データをすべて処理する必要があるため，実装が困難となる。. 引き当て済み在庫の実装. 前述のような実装方法で，在庫管理を実装した場合，次の課題となるのは，在庫の 予約に対応する方法である。ストックベースでは，このような場合，引当済み在庫を 記録することによって対応する。 すなわち， 実在庫量 とする。. －. 引当済み在庫量. ＝. 3. フローベースの在庫管理システム. 有効在庫量. 現状のストックベースの課題を踏まえ，次の設計要件を検討する。 時間を考慮した引当が可能であること。未来の在庫推移が見えたうえで、適切に 出荷の可否が判断できること。 更新に大きなロックを必要としないこと。分散処理が可能であること。 過去のデータを修正するための，適切な方法が提供されていること。 拠点間や、品目グループ間の集計が容易であること。. 1. 有効在庫の限り，新たな出荷や出荷予約を行って良いという判断をすることとなる。 このような実装は，現在も多くの企業で使われている。. 2. 3. 4.. 最近の多品種化，短納期化の流れに伴い，おおきく３つの問題が顕在化することと なった。. 昨今の計算機資源の向上を踏まえ，計算量やメモリ，ネットワークなどについては， ストックベースと比較して多く利用しても問題ない。. 一つめは，しばらく先に引当対象の出荷があるために，現在在庫があり，かつ先の 出荷までには，追加の調達が可能なケースに対する対応である。この場合，現在手許 の在庫を出荷し，あらたな調達発注をして，引当対象の出荷を割り当てると，双方の 出荷を満たすことができる。ストックベースのシステム実装は，本来はマイナスの有 効在庫を認めていない。そとため実際には、多くの場合は出荷担当者が，出荷予定と 入荷予定を見ながら出荷可否を判断し，システムの在庫のデータと，実際の在庫が乖 離していくケースが多く発生している。システムに登録しない在庫をもって、飛び込 み注文に対応しているケースも多い。本来は出荷可否の判断を行うために作成された， 引当済在庫，有効在庫というしくみがうまく動かないケースが増えているのである。. 3.1. フローベースシステムの概念. 概念レベルの設計は，ファウラーによりまとめられたアナリシスパターンに含まれ る勘定パターンを利用する 1)。 勘定パターンにおいては，在庫の残高は記録せず（後述の計算量削減による高速化 のために，時点の在庫量を記録することはある），入出庫による増減量から，在庫量を 導出する。増減量にあたる流量を中心としてデータを保持することから，ストックベ ースと対照して，フローベースと呼ぶ。. 二つめの問題は，複数拠点での在庫の集計である。他品種化に伴い，同一の品目を 複数の作業場所で扱うケースが多くある。このような場合，作業場所に対して同一の 在庫テーブルを共有してしまうと，それぞれの拠点での在庫入力の際に同期処理が必 要であり，ロックの問題などから性能が低下する。そのため，在庫の計算処理は，夜 間バッチによる集計とするという処理を行っている場合が多い。この場合，拠点間の. もともとは，会計の複式簿記をモデル化したもので，借方，貸方をあわせて 表記することで，推移を適切に管理でき，かつデータは追記のみで更新の必要はない。. 2. ⓒ2010 Information Processing Society of Japan.
(3) Vol.2010-IS-112 No.4 2010/6/5. 情報処理学会研究報告 IPSJ SIG Technical Report. これで設計要件２は満たす。また，いわゆる赤黒伝票による相殺処理と後述のデュア ルデート処理により，設計要件３も満たすことができるし、要約勘定による集計で、 設計要件４を満たす。. 期末在庫量. 会計用の勘定パターンでは，未来の予定を管理することはできないので，ここでは， 児玉の発表した在庫管理のための勘定パターンモデルを利用する 2)。. 工場倉庫累積入荷. 図３. 期首在庫量 数量. 在庫量. 在庫滞留時間. 設計レベルの勘定パターンクラス図. 今回は，取引によって品目が変わることはない在庫の把握のみを対象とするため， 取引に紐づく出荷側と入荷側の数量は常に一致する。すなわち，取引に紐づく移動量 の合計は，常に０となる。製造などによって消費される品目と製造される品目が異な る取引を扱う際には，部品表を参照して，消費数と生産数が対応することを確認する ように拡張する必要がある。. 工場累積入荷出荷. 時間. つぎに設計におけるいくつかの考慮点について記述する。 図２. 在庫流動表 3.2.1 予定と実績の対応関係. 勘定パターンによる実装により，図２に示すような流動分析を未来についても行うこ とができる。結果として，引当済み在庫ではなく，未来における在庫量推移がマイナ スにならないように，出荷の可否判断をし、必要な入荷量を把握できる。 3.2. 入荷や出荷が予定に対して分割される場合，または複数の入出荷予定をまとめて処 理する可能性がある場合は，予定と実績の対応が多対多となる。この場合は，その間 の関係をしめす関連クラスの導入が必要となる。. フローベースの設計 3.2.2 集計時の予定日時を過ぎた予定の扱い. 設計レベルのクラスを図３に示す。 勘定パターンにおいては，在庫量は時間に依存するものとして，そのたびに再計算 される。そのため，実行日時を過ぎた予定をどう扱うかが問題となる。設計のパター ンとしては， 予定を過ぎたものもそのまま扱う。過去の予定もそのとおりに実行されたとみな 3. ⓒ2010 Information Processing Society of Japan.
(4) Vol.2010-IS-112 No.4 2010/6/5. 情報処理学会研究報告 IPSJ SIG Technical Report. タをすべて集計するのではなく，有効な時点在庫のデータを初期在庫量データとして 用い，入出荷量を累計して，在庫量を計算する。. す。 予定を過ぎたものは，実行日時を現在日時もしくは現在日時のしばらく後とみな す。 予定を過ぎたものは，キャンセルされたものとみなす。 などがある。 -. 時点在庫は，取引と同じく，実行日と計上日をもつ。時点在庫の実行日以前の実行 日を持つ取引の計上日が，時点在庫の計上日より新しかった場合は，時点在庫は無効 となる。. 実際の設計では，最初の方法を採用し，実行されない予定については，明示的にキ ャンセルしたという実績を登録する場合が多い。集計方法の実装によって，使い分け ることも可能である。. 時点在庫は，キャッシュデータであるので，システムの都合により任意の時点で設 定してよい。ただし，在庫量データの正確性の確認という意味から，棚卸時に登録す るのがよい。その場合は，それ以前の時点在庫を基点として求めた在庫量と，新たに 登録する時点在庫の在庫量が一致するように，棚卸調整の取引を登録しておく。. 3.2.3 実行日時と計上日時の使い分け. 業務上の都合などにより，入荷出荷のデータを，タイムリーに登録できない場合が ある。また，入力漏れや入力ミスなどで，後になってから入出荷のデータが修正登録 される場合がある。このような場合に対応するため，取引には，実行日時と計上日時 の２つの時点のデータを登録しておく。. 4. フローベースの実装 ここでは，Java による実装例について説明する。実装内容は，中小企業庁の平成 20 年度中小企業 IT 経営革新支援事業の「RFID を利用した自動車部品共通 EDI システ ムの開発」で利用されている，設計・実装モデルを一部改変したものである。. 通常の在庫量計算の場合は，実行日時のみを参照して在庫量を計算する。必要に応 じて，在庫計算時に計上日時を指定し，その場合は指定された日時以降の取引データ は計算しないようにすることで，システムが認知していた入出荷の状況を，任意の時 点にさかのぼって参照することができる。. 実行および検証が可能なソースコード一式は，別途株式会社情報システム総研のホ ームページ上で公開の予定である。 4.1. 利用技術. 3.2.4 調整場所. Java 2 Standard Edition/Enterprise Edition 6.0 に準拠した Web アプリケーション AP サーバ: Apache Tomcat 6 DB サーバ: PostgreSQL 8 O/R マッパー: Hibernate 他に，システム連携コンポーネントとして，Mule ESB / Apache CXF などを利用. 勘定パターンの制約により，取引における移動量は常に合計を０にする必要がある。 そのため，在庫調整(棚卸しによる数値差異)の場合の移動元，移動先として利用する ため調整場所を用意する。調整場所においては，在庫量が負になってもエラーとする ことはない。調整場所の在庫量を集計することで，棚卸しなどの差異の集計が可能と なる。同様な理由で，入荷元，出荷先も同様に場所として登録しておく。. 4.2. 実装例. 3.2.5 時点在庫. 実装上、留意が必要なのは、取引の登録と、在庫量および在庫推移の計算である。 ストックベースと異なり，フローベースでは，在庫量を参照した時点で，入荷量と 出荷量から在庫量を計算する。必要な計算量は，当然ながら入出荷のデータ件数と比 例することとなる。システム導入時からすべての入出荷データを集計するのは現実的 ではないので，時点在庫という在庫量データのキャッシュを導入する。入出荷のデー. 取引の登録は、取引に紐づく移動量の合計が０となるように、バリデーションを行 ってから記録する必要がある。また、基本的に取引と移動量は、追記のみ行い、更新. 4. ⓒ2010 Information Processing Society of Japan.
(5) Vol.2010-IS-112 No.4 2010/6/5. 情報処理学会研究報告 IPSJ SIG Technical Report. は行わないよう実装する。この実装により、意図しないデータ変更を防ぐことができ る。. e.addExtractValue(new ExtractValue("quantity", Entry.class, null, "quantity"));. List<Map<String, Long>> mapList = BasicService.getService().findByExtractor(e);. 以下に，実装コードのうち，フローベースの根幹となる在庫計算部分を示す。 基本的には、登録された時点在庫のうち、指定された時点より過去のうち最新のもの を探し、そこから入荷出荷量を集計して、在庫量を求める。. // 移動量を合計する。. public Long getBalance(Account account, Date date) {. }. for(Map<String, Long> map : mapList) { ret += map.get("quantity");. // 引数として対象のアカウント，時点日付をとる。 // 合計値を返す。 Extractor pointext = new Extractor(PointInventory.class);. return ret;. Extractor e = new Extractor(Entry.class);. }. long ret = 0L;. 4.3. 性能について. ストックベースの実装と比較すると，フローベースの実装は、在庫量は DB から取 得するのではなく， 入出荷の移動データを集計する必要がありレスポンスは悪化する。. // 指定された時点以前の最新の時点在庫を取得する条件を設定 pointext.add(Condition.eq(PointInventory.ACCOUNT, account)); pointext.add(Condition.le(PointInventory.POINT, date));. 勘定パターンモデルの性質をうまく利用することにより，品目，場所，時間で分割 処理して，並行処理することが可能であり，スケールアウトによって性能向上がはか れる。これは、最近のマルチコア化やクラウド環境などの技術利用に際して大きなメ リットである。大量のメモリを活用した、DB のキャッシュ機構により大幅な性能の 向上が可能である。. pointext.addOrder(Order.desc(PointInventory.POINT)); pointext.setLimit(1); // 時点在庫を DB から取得 FindResult<PointInventory>. pointInvs = BasicService.getService().findByExtractorWithCount(pointext);. if (pointInvs.count > 0) {. 稼働環境である EDI システムにおいては，Xeon 2GHz ２コア，メモリ２GB の環 境 （仮想化環境において），取引件数が１万件程度以下の在庫量計算は数秒で完了する。. PointInventrory pinv = pointInvs.get(0); ret = pinv.getAmount(); // 時点在庫が存在した場合は，時点在庫の時点以降の取引のみを取得する条件. また別途環境の在庫集計システムにおいては，Xeon 3GHz ４コア x 2，メモリ 16GB の環境では，２０万件程度の取引，４０拠点ほどの在庫推移表の取得が，３０秒程度 での出力が可能である。. e.add(Condition.gt(Entry.TRANSACTION+"."+Transaction.PROCESS_DATE, pinv.getPoint()); } // 時点在庫の時点と指定された時点の間の取引の移動量を取得する条件を設定. 4.4. 稼働状況. e.add(Condition.eq(Entry.ACCOUNT, this));. EDI システムでは，数十社の受発注および在庫管理システムとして，昨年の２月 ごろから実稼働している。今後の利用者数の増大には、クラウド環境でのシステム利 用を進めていく予定である。. // DB から移動量を取得する。 e.add(Condition.le(Entry.TRANSACTION + "." + Transaction.PROCESS_DATE, date));. 5. ⓒ2010 Information Processing Society of Japan.
(6) Vol.2010-IS-112 No.4 2010/6/5. 情報処理学会研究報告 IPSJ SIG Technical Report. 5. おわりに 企業情報システムの中でも基幹システムの一部と考えられる在庫管理システム，改 良を重ねながら長期間にわたって使われてきている。特に製造業や物流業においては、 停止するのがほぼ不可能なシステムであり、なかなか設計変更をしようとしても難し いという現状がある。 最初に説明したようなストックベースの課題については、さまざまな方法により、 ストックベースのシステムは維持された状態で課題の回避がなされてきている。ただ、 そのような回避は、中心となるデータを分散させ、さらなるアプリケーションのサイ ロ化を招いている現状もある。 このような設計手法が、日本のサプライチェーンにかかわるシステムの改善に役に 立てば幸いである。 サプライチェーンにおいて共通の課題となっている、ロット管理、個品管理の問題、 トレーサビリティや納期保証の仕組みなどについても、フローベースの拡張として別 途発表したいと考えている。. 6. 謝辞 株式会社小島プレス工業の兼子氏、株式会社ラフダイアモンドの山根氏、株式会社 グローバルワイズの山下氏、株式会社情報システム総研の児玉氏には、本発表につい て多大な支援をいただいた。この場を借りて、感謝したい。. 参考文献 1)Fowler, M. 著, 児玉公信ほか訳: アナリシスパターン, アジソンウエスレイジャパン (1998) 2)児玉公信: UML モデリングの本質，日経 BP 社 (2004) 3)渡辺一衛: 納期管理の基本マスターコース- PHP 通信ゼミナール教材、PHP 研究会. 6. ⓒ2010 Information Processing Society of Japan.
(7)
関連したドキュメント
So far, most spectral and analytic properties mirror of M Z 0 those of periodic Schr¨odinger operators, but there are two important differences: (i) M 0 is not bounded from below
Some new oscillation and nonoscillation criteria are given for linear delay or advanced differential equations with variable coef- ficients and not (necessarily) constant delays
discrete ill-posed problems, Krylov projection methods, Tikhonov regularization, Lanczos bidiago- nalization, nonsymmetric Lanczos process, Arnoldi algorithm, discrepancy
While conducting an experiment regarding fetal move- ments as a result of Pulsed Wave Doppler (PWD) ultrasound, [8] we encountered the severe artifacts in the acquired image2.
Wro ´nski’s construction replaced by phase semantic completion. ASubL3, Crakow 06/11/06
Hence, for these classes of orthogonal polynomials analogous results to those reported above hold, namely an additional three-term recursion relation involving shifts in the
Amount of Remuneration, etc. The Company does not pay to Directors who concurrently serve as Executive Officer the remuneration paid to Directors. Therefore, “Number of Persons”
[Principle 4.1 Roles and Responsibilities of the Board of Directors 1] Supplementary Principle 4.1.1 As a “Company with Nominating Committee, etc.,” the Company’s Board of
