SAP EWMにおけるPOSC(プロセス指向棚付管理)の基本解説:仕組みから設定項目まで

EWM-POSC

前回の記事では、コンベアや中間地点を経由する物理的な移動を制御する「LOSC(レイアウト指向棚付管理)」について解説しました。今回は、それと対をなす重要な制御機能である「POSC(Process Oriented Storage Control:プロセス指向棚付管理)」を取り上げます。

LOSCが「どこを通るか(経路)」という物理的なレイアウトに焦点を当てるのに対し、POSCは「どのような順序で作業を行うか(工程)」という論理的なプロセスを管理します。荷卸し(Unloading)、検品(Counting)、デコンソリデーション(Deconsolidation)といった、最終棚に入れる前に必要な「一連の作業ステップ」をシステムで自動制御するための仕組みです。

実務においては、このPOSCによって定義された「作業工程」の間の移動を、LOSCが「経路」として補完することで、複雑な倉庫内の動きが完成します。POSCを正しく理解し設定することは、EWMにおける入荷・出荷フローのバックボーンを設計することと同義です。

この記事の内容

本記事では、POSCの基本概念から、システムが各ステップを自動的に切り替えるメカニズム、そして設定に不可欠な構成要素について、事実ベースで詳しく解説します。LOSCとの役割の違いを整理しながら、プロセス設計の要所を紐解いていきましょう。

目次

POSCを構成する3つの主要要素

POSCを理解し、システムを設定する上で欠かせないのが、以下の3つの要素です。これらが階層的に組み合わさることで、一つの業務フローが定義されます。

1. 内部プロセスステップ(Internal Process Step)

内部プロセスステップは、SAPが標準で提供している「システムが実行すべき基本動作」です。これらはSAP内部でハードコーディングされており、ユーザーが独自に新規作成することはできません。主なものとして以下が挙げられます。

  • IB01:荷卸し(Unloading)
  • IB02:デコンソリデーション(Deconsolidation / 仕分け)
  • IB03:入庫(Putaway)
  • VAS:付加価値サービス(検品やラベル貼りなど)

各内部ステップには、「タスクが完了した際に在庫のステータスをどう変えるか」「次のステップをどう探すか」といったシステムロジックが組み込まれています。

2. 外部ステップ(External Process Step)

外部ステップは、実際のビジネス要件に合わせてユーザーが自由に定義できる作業単位です。各外部ステップは、必ず前述の「内部プロセスステップ」のいずれか一つと紐付ける必要があります。

例えば、「検品(CNTS)」という外部ステップを作り、それを「内部ステップ:VAS」に紐付ける、といった具合です。この外部ステップに対して「どのワークセンター(作業場)で行うか」といった詳細な条件を定義します。

3. ストレージプロセス(Storage Process)

ストレージプロセスは、定義した外部ステップを「どの順番で実行するか」を並べた一連のシナリオです。これがPOSCの「背骨」となります。

【ストレージプロセスの定義例】

ストレージプロセス名:INB1(標準入荷プロセス)

  1. UNLD(荷卸し):内部ステップ IB01 と紐付け
  2. DECO(仕分け):内部ステップ IB02 と紐付け
  3. PUTA(入庫):内部ステップ IB03 と紐付け

POSCの前提:HU(荷役単位)管理の重要性

ここで技術的な事実として押さえておくべきなのは、POSCは基本的にHU(Handling Unit)管理を前提としているという点です。

POSCがステップを管理する際、システムは「どの荷物(HU)が、いまどの工程(ステップ)にあるか」を追跡します。バラ在庫(HU化されていない在庫)の状態では、POSCによる自動的な工程転送やタスクの連動を行うことができません。

したがって、POSCを導入する際は、入荷時に荷物をパレットやカートンとしてシステム上に登録(HU作成)し、そのHUに対してストレージプロセスを割り当てることが必須条件となります。

POSCはどのように次の工程へ進むのか

POSCを初めて学ぶと、多くの人が次のような疑問を持ちます。

「システムはどうやって次の工程を判断しているのか?」

例えば、以下のようなストレージプロセスが定義されているとします。

  1. UNLD(荷卸し)
  2. DECO(デコンソリデーション)
  3. PUTA(棚入れ)

入荷が発生すると、EWMはまずUNLD用の倉庫タスク(WT)を作成します。

そして作業者がそのWTを完了(荷降ろしを完了)すると、システムはHUに割り当てられているストレージプロセスを参照し、「次のステップはDECOである」と判断します。

その結果、DECO工程へ進むための新しいWTが作成されます。

つまりPOSCは、あらかじめ定義された工程順序に従って、各工程の完了をトリガーに次のWTを生成していく仕組みです。

POSCによる工程遷移のイメージ

UNLD WT完了 

次工程(DECO)を判定

DECO WT作成

DECO WT完了

次工程(PUTA)を判定

PUTA WT作成

このようにPOSCの本質は、「在庫をどこへ移動するか」を管理することではなく、「どの工程をどの順番で実行するか」を管理することにあります。

実際のプロジェクトでは、POSCの設定を確認する際に工程定義ばかりに注目しがちですが、トラブル調査では「どの工程でWTが生成されたのか」「どの工程で停止しているのか」を確認することが非常に重要です。

WTの搬送先はどのように決まるのか

ここで注意したいのは、POSCは「次の工程」を決定しますが、WTの搬送先は別のロジックによって決定される場合があるという点です。

外部ステップには「搬送先保管域タイプ(Destination Storage Type)」や「搬送先棚番(Destination Storage Bin)」を設定できます。

例えばDECO工程の外部ステップにワークセンターの保管域タイプや棚番が設定されている場合、作成されるWTはその搬送先へ向かいます。

一方で、これらの項目が空欄の場合、EWMは通常の棚入れ決定ロジックを利用します。

その際は、まずWTに割り当てられたWarehouse Process Type(WPT)が決定されます。続いて品目マスタに設定されたPutaway Control Indicator(PACI)などを参照し、適用するStorage Type Search Sequenceが選択されます。

そのSearch Sequenceに定義された候補保管域タイプが順番に評価され、最終的な搬送先保管域タイプおよび棚番が決定されます。

POSC 

次工程決定

WT作成

WPT決定

PACI参照

Storage Type Search Sequence決定

Storage Type決定

Storage Bin決定

この部分はLOSCの記事でも触れた「WTの搬送先決定ロジック」と密接に関係しています。POSCを理解する際は、「工程順序を決める機能」と「搬送先を決める機能」を分けて考えると整理しやすくなります。

ストレージプロセスはどのように決定されるのか

ここまでで、POSCは「ストレージプロセス」に定義された工程順序に従ってWTを生成していく仕組みであることを説明しました。

では、そのストレージプロセスはどこで決定されるのでしょうか。

実際のシステムでは、入荷伝票や出荷伝票が作成された時点で、EWMは対象の品目やプロセスタイプを参照し、適用すべきストレージプロセスを決定します。

つまり、POSCは単独で動作しているわけではなく、Warehouse Process Type(WPT)や品目マスタなどの設定と連携しながら実行されています。

入荷プロセスでの代表的な決定例

例えば、同じ倉庫でも品目によって必要な作業工程が異なることがあります。

  • 通常品はそのまま棚入れする
  • 混載パレットはデコンソリデーションを実施する
  • 特定品目は品質検査を実施する

このような要件を実現するために、複数のストレージプロセスを用意します。

INB1 
UNLD → PUTA

INB2
UNLD → DECO → PUTA

INB3
UNLD → QINS → PUTA

そして、どのストレージプロセスを適用するかをWarehouse Process Typeなどの設定で制御します。

その結果、同じ入荷伝票から生成された在庫であっても、対象品目や業務ルールに応じて異なる工程を通過させることが可能になります。

Warehouse Process Typeとの関係

POSCを理解する上で重要なのが、Warehouse Process Type(WPT)との関係です。

WPTは、WT作成時に使用されるEWMの中心的な制御オブジェクトです。

例えば以下のような情報を制御します。

  • どのストレージプロセスを利用するか
  • HU必須かどうか
  • 自動WT作成を行うか
  • 棚入れロジックとしてどのSearch Sequenceを利用するか
  • 倉庫オーダー作成時の振り分け条件

POSCだけを見ていると工程管理機能のように見えますが、実際にはWPTと組み合わせて初めて動作します。

そのため、プロジェクトでPOSCの不具合調査を行う際は、ストレージプロセス定義だけでなく、WTに割り当てられたWPTも必ず確認する必要があります。

実務ポイント

「POSCが動かない」という問い合わせの原因は、ストレージプロセス定義そのものではなく、期待したWPTが決定されていないケースが少なくありません。まずWTに割り当てられたWPTを確認し、そのWPTにどのストレージプロセスが設定されているかを追跡すると原因を特定しやすくなります。

POSCとLOSCの違いと関係性

POSCを学び始めた人が最も混乱しやすいのが、前回解説したLOSCとの違いです。

どちらも倉庫タスクの生成や搬送先に関わる機能であり、設定画面を見ても似たような項目が登場するためです。しかし、この2つは役割がまったく異なります。

一言で表現すると、POSCは「何の作業を行うか」を管理し、LOSCは「どの経路を通って移動するか」を管理します。

POSC :作業工程の管理
LOSC :搬送経路の管理

例えば、入荷した商品をデコンソリデーションした後に棚入れする業務を考えてみましょう。

POSCの観点では、システムが管理したいのは以下のような作業順序です。

荷卸し
 ↓
デコンソリデーション
 ↓
棚入れ

つまり、「どの工程をどの順番で実施するか」を定義しています。

一方で、実際の倉庫では荷卸しエリアからデコンソリエリアまで直接移動できるとは限りません。コンベアや中継地点、仕分けエリアなどを経由する場合があります。

そこで利用されるのがLOSCです。

荷卸しエリア
 ↓
中継地点
 ↓
コンベア
 ↓
デコンソリエリア

このようにLOSCは、ある保管域から別の保管域へ移動する際の物理的な経路を表現します。

POSCとLOSCは競合する機能ではない

POSCとLOSCはどちらか一方を選択する機能ではありません。実際のプロジェクトでは、両者を組み合わせて利用するケースが一般的です。

例えば、以下のような入荷プロセスを考えてみます。

荷卸し
 ↓
デコンソリデーション
 ↓
品質検査
 ↓
棚入れ

この工程順序そのものはPOSCで管理します。

しかし、デコンソリエリアから品質検査エリアまでの移動にコンベア搬送が必要であれば、その経路はLOSCで制御します。

つまり、POSCが「次は品質検査を実施する」と判断し、LOSCが「品質検査エリアまでどのルートで搬送するか」を決定するという役割分担になります。

倉庫設計では両方の視点が必要

実務では、POSCだけを設計しても現実の倉庫運用を表現できません。また、LOSCだけを設計しても作業工程を管理できません。

POSCは「業務プロセス」、LOSCは「倉庫レイアウト」を表現する機能と言い換えることもできます。

そのため、EWMの要件定義では「どのような作業工程が必要か」と「その工程間をどのように搬送するか」を分けて整理することが重要です。

POSCとLOSCを適切に組み合わせることで、システム上の業務フローと実際の倉庫内の動きを一致させることができます。

POSCが活躍する代表的な業務シナリオ

ここまでPOSCの仕組みやLOSCとの違いを解説してきました。

では、実際の倉庫業務ではどのような場面でPOSCが利用されるのでしょうか。

POSCが効果を発揮するのは、「入荷した商品をすぐに棚入れできない業務」です。棚入れ前に何らかの作業工程が存在する場合、その工程をシステム上で管理できるようになります。

デコンソリデーションを行う倉庫

最も代表的なのがデコンソリデーションです。

メーカーや物流センターから入荷したパレットには、複数の商品が混載されていることがあります。その場合、まず商品ごとに仕分けを行い、その後に棚入れを実施します。

荷卸し
 ↓
デコンソリデーション
 ↓
棚入れ

このような工程はPOSCの典型的な利用シナリオです。

品質検査が必要な倉庫

食品、医薬品、化学品などでは、入荷後すぐに棚入れせず、品質検査エリアへ搬送するケースがあります。

検査が完了しない限り出荷可能在庫として扱えないため、工程管理が重要になります。

荷卸し
 ↓
品質検査
 ↓
棚入れ

POSCを利用することで、検査工程を経由しなければ次の工程へ進めないように制御できます。

ラベル貼付や再梱包が必要な倉庫

入荷した商品の中には、棚入れ前にラベル貼付や再梱包などの作業が必要なものもあります。

EWMではこれらをVAS(Value Added Service)として管理できます。

荷卸し
 ↓
VAS
 ↓
棚入れ

POSCを利用することで、必要な付帯作業を確実に実施した後で棚入れを行う運用を構築できます。

POSCを導入すべきか判断するポイント

逆に言えば、入荷後すぐに棚入れするだけのシンプルな倉庫であれば、POSCを利用しなくても運用できるケースがあります。

POSCが必要になるのは、「工程管理」が業務上重要な場合です。

  • 複数の作業工程を順番に実施する必要がある
  • 特定の工程を完了しなければ次へ進めたくない
  • HU単位で現在どの工程にいるかを把握したい
  • ワークセンターを経由する業務が多い

このような要件がある場合、POSCは非常に有効な選択肢となります。

まとめ

POSC(Process-Oriented Storage Control)は、EWMにおいて「どの工程をどの順番で実施するか」を管理するための機能です。

単純な棚入れだけであれば不要なケースもありますが、デコンソリデーションや品質検査、VASなど、棚入れ前に複数の作業工程が存在する倉庫では非常に重要な役割を担います。

本記事で解説したポイントを整理すると、以下のようになります。

  • POSCは工程管理のための機能である
  • 内部プロセスステップ、外部ステップ、ストレージプロセスの3層構造で構成される
  • HU管理を前提として動作する
  • 各工程の完了を契機として次のWTが生成される
  • 搬送先は外部ステップ設定や通常の棚入れ決定ロジックによって決定される
  • LOSCとは競合せず、組み合わせて利用することが多い

特に重要なのは、POSCとLOSCの役割を混同しないことです。

POSCは「何をするか」、LOSCは「どうやって移動するか」を管理します。この2つを組み合わせることで、実際の倉庫業務をシステム上で表現できるようになります。

EWMのプロジェクトでは、POSCの設定そのものよりも、「現場ではどのような工程が存在するのか」「どの工程をシステムで管理すべきなのか」を整理することが成功の鍵となります。

まずは工程を洗い出し、その上でPOSCによる制御が必要かを検討してみてください。POSCの考え方を理解すると、EWMがどのように倉庫業務をモデル化しているのかが見えてくるはずです。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

「現場の言葉」と「システムの言葉」をつなぐ。
私のキャリアは通訳から始まりました。SAP導入プロジェクトで通訳兼キーユーザーとして奔走した経験が、私の根底にあります。
その後、クライアント側でキーユーザー・プロセスオーナーとして10年、コンサルタントとして約8年。一貫して物流とSAPに向き合ってきました。単なる机上の空論ではなく、実際にオペレーションを回し、現場で頭を悩ませてきたからこそ見える「本当に使えるEWM」を大切にしています。
EWMだけでなく、WMSやWCS、物理的なマテハン設備も含めた「倉庫全体の最適化」を考えるのが得意です。このブログでは、日本語リソースが少ないEWMのTipsや、実務で培ったナレッジを惜しみなく共有していきます。
趣味は飲食(料理とお酒)と、大好きなヨーロッパやアジアへの海外旅行です。

コメント

コメントする

コメントは日本語で入力してください。(スパム対策)

目次