レストランの在庫管理機能付きPOS：本当の「連携」が意味するもの

仕様書にある「在庫連携」が通常意味すること

ほとんどのPOS（販売時点情報管理）システムは、在庫管理機能があると謳っています。機能リスト上では、それは単純明快に見えます。売上が計上されると、システムがその商品を総在庫数から差し引く。コーラのボトルが1本売れれば、コーラのボトルの在庫数が1つ減る。これは単純な在庫追跡であり、飲み物やスナック菓子のような包装済み商品には完璧に機能します。

問題は、レストランが主に販売するのは包装済み商品ではなく、料理であるということです。POSで「クラシックバーガー」を会計処理しても、その1回の販売で牛ひき肉150グラム、ブリオッシュバンズ1個、チェダーチーズ20グラム、自家製ソース10mlが消費されたことを自動的に認識するわけではありません。この単純な引き算モデルは、すぐに破綻します。

ほとんどの基本的なシステムが提供しているのは、商品単位の追跡であり、材料単位の追跡ではありません。システムは「クラシックバーガー」が何個売れたかは教えてくれますが、牛ひき肉がどれだけ残っているかは教えてくれません。この違いこそが、レストランの在庫管理が失敗する最も一般的な原因です。仕様書にただ「在庫管理」と書かれているだけで、レシピ単位の原価計算や追跡について詳述されていないシステムは、バーや、せいぜい乾物庫にしか役立たないシステムを説明しているに過ぎません。生の材料を完成した一皿に変えるという、キッチンの本当の仕事はブラックボックスのままです。

レシピマッピング：在庫数を正確にするための作業

真の在庫管理は、レシピマッピングにかかっています。これは、メニューにあるすべての項目に、どの生の材料が、どのくらいの量で使われているかをシステムに正確に教える、一度きりの初期設定作業です。このプロセスは面倒かもしれませんが、正確なデータを得るためには不可欠です。

各メニュー項目について、POS内部でその「レシピ」を定義します。

• クラシックバーガー：牛ひき肉150g、ブリオッシュバンズ1個、チェダーチーズ20g、自家製ソース10ml、トマト2スライス。
• サイドサラダ：ミックスグリーン50g、ヴィネグレット15ml、クルトン5g。

このマップが作成されると、システムはついにその役割を果たすことができます。サーバーがクラシックバーガーとサイドサラダの注文を入力すると、POSは単に売上を記録するだけではありません。レシピにアクセスし、特定の材料の数量をデジタル上の在庫室から差し引きます。これが、概算とリアルタイムの在庫数の違いです。このレシピ単位のデータがなければ、在庫数は現実から急速に乖離し、わずか1週間で再発注には使えないものになってしまいます。システムは牛ひき肉が10kgあると表示していても、ウォークイン冷蔵庫の中身は全く違うという事態になるのです。

これらのレシピを作成することで、一皿あたりの原価を正確に計算することもできます。ハンバーガーを作るのにいくらかかるかが正確にわかり、それが利益率を保証するメニュー価格を設定するための基礎となります。SyncBiteのような一部のシステムでは、これをメニューエンジニアリングに直接結びつけ、各商品のコストだけでなく、収益性や人気度も表示します。

廃棄、コンプ、そしてまかない

材料がキッチンからなくなるのは、販売だけが理由ではありません。ラインコックがステーキを焦がすかもしれません。マネージャーがお客様の誕生日にデザートをコンプ（無料提供）するかもしれません。チームは長いシフト中に食事をする必要があります。これらの出来事が記録されなければ、レシピマッピングがどれだけ完璧であっても、在庫数は不正確になります。

有能な在庫管理システムには、これらのシナリオを考慮に入れる機能が必要です。

• 廃棄追跡：スタッフが傷んだり落としたりした商品を記録するためのシンプルなインターフェース。例：「廃棄：トマト2kg（熟れすぎ）」または「廃棄：サーモン切り身1枚（落下）」。これは営業中に素早く行えるべきです。
• コンプ/ボイド：商品が無料で提供された（「コンプ」）り、会計から削除された（「ボイド」）りした場合でも、システムは在庫から材料を差し引くべきです。金銭的にはゼロですが、材料費は実際に発生しています。
• まかない：スタッフの食事を計上する方法が必要です。これは、固定費を差し引く「まかない」ボタンを作成するか、スタッフがPOSを通じてゼロ価格で食事を「注文」し、それによって在庫から正しく材料を引き落とすことで処理できます。

これらの機能がなければ、「在庫減耗」、つまりシステムが示すべき在庫数と棚に物理的にある在庫数との間にギャップが生じます。このギャップはしばしば盗難と間違えられますが、実際には記録されていない廃棄やコンプであることが多いのです。一部の報告では盗難が減耗の大部分を占めると示唆されていますが、ほとんどのレストランにとってより根深い漏れは、過剰なポーション、記録されていないまかない、過剰発注による腐敗といった運営上の問題です。これらすべてを適切に追跡することで、売上原価（COGS）の真の姿を把握できます。

パーレベル、発注、そして仕入れ価格

すべての材料の正確なリアルタイム在庫数を把握できたら、次のステップは再発注プロセスの自動化です。ここで「パーレベル」が登場します。パーレベルとは、常に手元に置いておきたい材料の最小数量のことです。在庫がこのレベルを下回ると、再発注の時期です。

連携されたシステムは、リアルタイムの在庫数を使ってこれを自動化します。各材料にパーレベルを設定します（例：「牛ひき肉：20kg」）。システムが在庫が例えば19kgに減少したことを検出すると、自動的に牛ひき肉を推奨発注リストに追加します。これにより、クリップボードを持って冷蔵庫を歩き回るという、手作業で時間のかかる日課が、デジタルの発注書を素早く確認する作業に変わります。これは非常に重要です。なぜなら、全米レストラン協会によると、業務用キッチンでは購入した食品の4%から10%が顧客に届く前に廃棄されているとCloudKitchensが報告しているからです。パーレベルの低下を警告するシステムは、実際の必要量に近い発注を助け、期限切れになる可能性のある在庫に縛られる資本を減らします。

このプロセスは、仕入れ先の価格リストをシステムに読み込むとさらに強力になります。請求書を入力する際に、各材料の仕入れ価格を更新できます。優れたPOSは、その材料を使用するすべてのレシピで自動的に皿の原価を再計算します。アボカドの価格が2倍になった場合、それがワカモレやアボカドトーストの利益率にどう影響するかを即座に知ることができ、メニュー価格の調整について情報に基づいた決定を下すことができます。この連携がなければ、仕入れ先からの価格変更はしばしば見過ごされ、静かに利益を侵食していきます。利益率を維持する方法について詳しくは、小規模レストラン向けのオンライン注文システムに関するガイドをご覧ください。

予測分析ができること、できないこと

AI POSシステムとして販売されることの多い最先端のシステムは、在庫管理の上に予測分析の層を追加します。これらのツールは、過去の販売データを分析して将来の需要を予測します。例えば、四旬節中の金曜日には魚の売上が50%増加することや、晴れの天気予報がパティオでのドリンク売上の急増と相関していることに気づくかもしれません。

これらのパターンに基づき、システムは単純なパーレベルを超える発注量を提案できます。単にパーレベルを下回ったからサーモンをもっと発注するように言うのではなく、晴れた金曜日であり、過去の販売履歴から追加で10kg必要になることが示されているため、追加で発注することを推奨するかもしれません。これにより、過剰発注と過少発注の両方を減らすことができます。この努力は大きな見返りを生みます。全米レストラン協会のデータによると、レストランが食品廃棄物削減に1ドル投資するごとに、約8ドルのコスト削減が実現できるとされています。

しかし、予測分析は水晶玉ではありません。突然の道路閉鎖、予期せぬ地元のイベント、隣に競合店がオープンすることなどを予測することはできません。その予測は過去のデータに基づいており、過去のパターンから外れる出来事はすべて見逃されます。予測は標準的な発注を最適化するための強力なツールですが、地域の状況に目を光らせ、手動で調整できる経験豊富なマネージャーの代わりにはなりません。それはデータに基づいた基準を提供するものであり、最終的で絶対的な答えではありません。

インターネットが切断されたらどうなるか？

どんなクラウドベースのPOSシステムも、インターネット障害という現実に直面します。システムがオフライン状態をどのように処理するかは、運営上の重要な問題です。SyncBiteの場合、システムは回復力を持つように設計されています。

インターネット接続が切断された場合でも、POS端末で注文を取り続けることができます。デバイスにはオフラインモードがあり、注文と支払いをローカルにキューイングします。ローカルネットワーク（LAN）を介して端末から直接注文を受け取るキッチンディスプレイシステム（KDS）は、レストランの内部Wi-Fiが機能している限り、正常に動作し続けます。これは、フロントオブハウスとバックオブハウスが数時間にわたって中断なく運営できることを意味します。KDSの信頼性について詳しくは、KDS購入者ガイドをご覧ください。

カード決済もキューイングされます。インターネット接続が回復すると、保存されていた注文と支払い情報がクラウドに送信され、処理・照合されます。それらのオフライン販売による在庫の引き落としはすべてクラウドで処理され、在庫レベルが最新の状態になります。唯一の重要な依存関係は最初の同期です。システムは一日の始まりに接続を必要としますが、一度稼働すれば、営業中の障害に耐えることができます。このハイブリッドアプローチにより、接続が切断されてもビジネスが停止しないことが保証されます。

スプレッドシートが依然として正しい答えである場合

連携システムの力にもかかわらず、単純なスプレッドシートが依然としてより良いツールである場合があります。コーヒーカートや、メニューが限定的で安定しているフードトラックのような非常に小規模な運営の場合、レシピ単位の在庫を設定し維持するために必要な時間投資は、プラスのリターンをもたらさないかもしれません。メニュー全体が10項目で、5分で在庫を目視確認できるのであれば、本格的なシステムの複雑さは過剰になり得ます。これは特に、シンプルさが鍵となるフードトラック向けのPOSシステムを探している場合に当てはまります。

スプレッドシートは、良い出発点にもなります。高度なシステムにコミットする前に、数週間Excelで主要な材料を追跡することで、使用量とコストの基本的な理解を得ることができます。それはプロセスを理解し、矛盾や手作業がアップグレードを正当化するほど苦痛であるかどうかを判断するのに役立ちます。Checkmateによると、レストランの75%が在庫と食費の問題で収益性に苦しんでいます。もしあなたがそのグループに属しているなら、スプレッドシートから連携システムへの移行は論理的な次のステップです。目標は、仕事に適したツールを使用することです。強力な在庫管理システムはほとんどのレストランにとって大きな資産ですが、それが唯一の答えではなく、常に最初の答えであるわけでもありません。

関連記事