【結論】
原価率が上がったとき、「仕入値が上がったからなのか」「使いすぎているのか」が切り分けられません。そして在庫は、月末に棚卸をするまで実態が分かりません。この2つは別々の悩みに見えて、同じ1か所が切れていることから来ています。レシピ（メニューPlus）・仕入と棚卸（インフォマート）・販売実績（POSレジ）の3つを1本の線でつなぐと、どちらも毎日わかる状態になります。この記事は、いまどこまでできていて、どこがこれからなのかを正直に書いたものです。
【この記事でわかること】
・原価率の変動を「値上がり」と「使いすぎ」に分けるために、何が足りないのか
・棚卸をせずに今日の在庫を出す計算の中身
・その先にある「棚卸をしない発注」が、どういう仕組みで成り立つのか
・いま実現していることと、これから実現することの線引き
・始めるために、お客様側で必要になる準備
原価率が上がったとき、理由を2つに分けられません
原価率が動いた理由が、1つにしか見えない
レジの原価は登録したときのまま
- 仕入単価は毎月動くのに、原価は固定
- 原価率が上がった理由が分からない
- 結局「気をつけよう」で終わる
今の相場の原価が毎日入る
- 値上がりによる変動が分かる
- 残りが使いすぎ・ロスによる変動
- 打つ手が値決めか運用かで分かれる
同じ「原価率2ポイント悪化」でも、打つべき手はまったく違います。
POSレジに登録されている原価は、その商品を登録したときの原価のままです。ところが仕入単価は日々動きます。魚が高い月も、野菜が高騰する月もあります。
その結果、月次で原価率が上がったときに、「仕入値が上がったからなのか」「使いすぎているのか」が切り分けられません。前者なら売価やメニュー構成を見直す話ですし、後者なら仕込みやポーションの話です。打つ手がまったく違うのに、数字が同じ顔をして出てきます。
人手で全メニューの原価を定期的に更新すれば理屈のうえでは解決しますが、メニュー数が数百から千を超える企業で、これを続けられている例をほとんど見たことがありません。最初の1回はできても、2回目が来ません。
在庫は、棚卸をするまで実態が分かりません
もう1つの悩みは在庫です。いま何がどれだけ残っているかは、棚卸をした瞬間しか分かりません。月次の棚卸をしている企業であれば、月末に1回だけ真実が見える、という状態です。
発注は毎日発生するのに、在庫は月に1回しか分からない。この差を埋めているのは、現場の記憶と勘です。ベテランの店長がいるあいだは回りますが、その方が異動された途端に過剰在庫か欠品のどちらかが出ます。
では毎日棚卸をすればいいかというと、そうもいきません。日々の在庫入力は、現場にとってかなり重い作業です。ここが続かないために、在庫を前提にした仕組みが定着しない、という話をよく伺います。
この2つは、同じ1か所が切れていることから来ています
原価率の切り分けと、在庫の把握。まったく別の悩みに見えますが、どちらも「レシピ」がつながっていないことが原因です。
料理1品に、どの食材を何グラム使うか。この情報さえあれば、販売数から「使ったはずの量」が計算できます。使ったはずの量が分かれば、今の仕入単価を掛けて今日の原価が出ますし、仕入から引けば今の在庫が出ます。1つの情報で、2つの悩みが同時に解けます。
レシピそのものは、多くの企業ですでに登録されています。ただ、そのレシピが「レジで何が何食売れたか」と結びついていません。レシピは原価計算のために作られ、レジは会計のために作られたので、両者をつなぐ必要がこれまでなかったからです。
3つのデータを、1本の線でつなぎます
すでにある3つを、つなぐだけ
- 今日の時価での原価
- 今日時点の在庫
- 値上がり要因と使いすぎ要因
新しいシステムを増やす話ではありません。すでにお使いのものだけで完結します。
必要なのは3つだけで、いずれも多くの企業がすでにお持ちのものです。
レシピは、料理1品にどの食材を何グラム使うか、歩留まりは何%か、という情報です。仕入と棚卸は、日々の仕入数量と、月初（または月末）の棚卸残高です。販売実績は、どの商品が何食売れたか。この3つ目は、TEAL BIがすでに毎日取り込んでいるものです。
レシピの食材と、仕入・棚卸の商品は、仕入側の商品コードで結びつきます。実際に検証にご協力いただいている多店舗企業様のデータ（16店舗・834レシピ・仕掛品167種）で確かめたところ、サンプル25件のうち棚卸は24件、仕入は21件が一致しました。ここは机上の話ではなく、実データで通ることを確認済みです。
たれやミックスのような仕掛品（自社加工品）は、出来上がり量で按分して、生の仕入商品まで分解します。「たれ15g」で止めずに、そのたれに使われている調味料の何グラムまで下ろす、ということです。ここを飛ばすと、加工品を多く使う業態ほど数字が合わなくなります。
「今日の在庫」は、こう計算します
計算そのものは単純です。
月末の棚卸残高 ＋ 期中の仕入 − 期中に使ったはずの量
「使ったはずの量」は、販売数 × レシピの使用量 ÷ 歩留まりで出します。棚卸残高と仕入は実績なので、推測が入るのは使用量だけです。
大事なのは、この数字が実棚を置き換えるものではないことです。計算値なので、こぼした・傷んだ・記録されていない廃棄があれば、実際とはずれていきます。だから月次の棚卸で必ず補正します（リセットします）。棚卸をゼロにする話ではなく、棚卸と棚卸のあいだの29日間を、勘ではなく数字で埋める話だとお考えください。
なお、消耗品のようにそもそも棚卸の対象になっていないものは、計算の対象外です。月末の棚卸残高がある商品だけが対象になります。
その先にあるのが、棚卸をしない発注です
仕入側には、すでに在庫発注の機能があります。商品ごとに基準在庫を決めておき、現在の在庫を入力すると、不足分が自動で発注案になる、という仕組みです。
よくできた機能なのですが、現場で定着しにくいという共通の課題があります。実際に多店舗で運用されている方から伺った、うまく回らない理由は次の4つでした。
| 現場で起きていること | なぜ負担になるか |
|---|---|
| 商品ごとに在庫を数える必要がある | 曜日によって数える品目が変わり、手順が覚えられない |
| 今日発注しない商品まで全部並ぶ | 納品曜日が仕入先ごとに違うのに、絞り込めない |
| 納品日を基準に作られている | 水曜に発注して金曜に届くなら、金曜時点の残量を人が予測することになる |
| 基準在庫を決めていない商品も表示される | 入力担当がアルバイトの場合、どれを入れるべきか分からず手が止まる |
4つのうち3つは、「在庫を人が数えて入力する」ことが前提になっているから生まれています。理論在庫が毎日出ていれば、この前提そのものが要らなくなります。
ここは誤解が生まれやすいので、はっきり書かせてください。TEAL BIが代わりに発注をかけるわけではありません。私たちがやろうとしているのは、計算した理論在庫を仕入側の在庫発注機能に渡して、日々の在庫入力なしでその機能が回る状態にすることです。発注そのものは、これまでどおり仕入側の仕組みと、承認する人の判断で行われます。
いま実現していること／これから実現すること
ここが、この記事でいちばんお伝えしたい部分です。構想としては5段階あり、段階4までと、段階5のうち理論在庫を毎日出すところまでが本番で動いています。残っているのは、計算した理論在庫を仕入側の在庫発注機能へ渡すところです。できていないことを、できているように書きません。
| 段階 | 内容 | 状況 |
|---|---|---|
| 1 | 販売実績（POSレジ）を日次で取り込む | 本番稼働中 |
| 2 | 仕入・棚卸（インフォマート）を取り込み、実際に計上された仕入から確定原価を出す | 本番稼働中 |
| 3 | レシピ（メニューPlus）を取り込み、仕掛品を仕入商品まで分解する | 本番稼働中（毎日取り込み） |
| 4 | 時価の原価を日次で更新し、値上がり要因と使いすぎ要因を分ける | 本番稼働中（原価率のグラフと分類別の表に、メニューPlusの時価で出した理論原価を並べて表示） |
| 5 | 今日時点の理論在庫を出し、仕入側の在庫発注機能に渡す | 理論在庫の日次表示は本番稼働中（仕入棚卸分析の「理論在庫」タブ）。在庫発注機能へ渡すところはこれから（相手側の受け入れ方式の相談を含みます） |
つまり、原価率の変動を値上がりと使いすぎに分けて見ることと、棚卸をしていない日の在庫を数字で見ることは、いま毎日できます。一方で「明日から棚卸なしで発注が回ります」とは、まだお伝えできません。残っているのは、計算した理論在庫を仕入側の在庫発注機能に渡す、最後の1工程です。
始めるために、お客様側で必要になること
この仕組みが動くかどうかは、ほぼ「紐付けが埋まっているか」だけで決まります。必要なのは2つです。
1つは、レシピの食材に、仕入商品が紐付いていること。ここが空欄のままだと、その食材については在庫を計算できません。検証にご協力いただいている企業様では、空欄が515件ありました。そのうち307件は直近の仕入実績と照合してこちら側で候補を埋めたうえで、ご確認をお願いする形にしています。
もう1つは、レシピと、レジのメニューコードが結びついていること。レシピ側に「このレシピはレジのこの商品です」と登録する欄があるのですが、レシピだけを運用していて、この欄が空のままという企業が少なくありません。製品の制約ではなく、登録がこれからという状態です。
そして全部を一度に埋める必要はありません。売れている順に並べて上から進めていただくのが現実的で、実際の試算では上位66メニューで売上の約50%、242メニューで約80%がカバーできました。まず動かしてみる段階なら、上位から数十件で十分に形になります。
実際に本番稼働している連携先
この記事は「何が動いていて、何がこれからか」を主題にしているので、連携先も同じ基準で出します。いま毎日データが流れているものだけを「本番稼働中」とし、そうでないものは分けて書きます。
| 区分 | 連携先 | 状況 |
|---|---|---|
| POSレジ | 東芝テック／スマレジ／USENレジ／NECモバイルPOS／ポスタス（POS+） | 本番稼働中 |
| ローズシステム／寺岡精工／funfo／Chompy（モバイルオーダー） | 本番稼働中 | |
| ステアリテール（FoodFrontia Pro）／グローリー／リブオン（宅配Evolution）／ダイニー | 接続対応中 | |
| 仕入 | インフォマート | 本番稼働中 |
| メニューPlus（レシピ） | 本番稼働中 | |
| 勤怠・人事 | ジョブカン／King of Time／タッチオンタイム／SmartHR | 本番稼働中 |
| 予約・口コミ | Googleビジネスプロフィール／TableCheck／Instagram ※Instagramは一部の企業様で稼働中です |
本番稼働中 |
| 外部データ | 気象データ（全国・時間帯別） | 本番稼働中 |
| 上記以外 | ネットワーク未接続の店舗を含む | CSVアップロードで統合対象に含められます |
この表のなかの「メニューPlus（レシピ）」が、上の段階3にあたります。レシピの取り込みと、仕入商品との突き合わせを、毎日の更新として本番で動かしています。
よくある誤解
「レジの商品コードを、全店で統一しないといけないのでは」
その必要はありません。レシピ側で、1つの料理に対して店舗ごとに別々のレジのコードを登録できます。同じ料理が店舗ごとに違うコードで登録されていても、レシピは1本で構いません。レジのマスタを書き換える作業も、過去データへの影響もありません。お願いするのは「このコードとこのコードは同じ料理です」というご確認だけです。
「理論在庫が出れば、棚卸はしなくてよくなるのでは」
なくなりません。計算値である以上、記録に残らない廃棄やロスのぶんは必ずずれていきます。月次の棚卸は、そのずれをリセットする起点として引き続き必要です。減るのは日々の在庫入力のほうで、月次の実棚ではありません。ここを取り違えると、現場で数字が合わなくなったときに一気に信用を失います。
「レシピの精度が低いので、うちでは無理だと思います」
全メニューが正確でなくても始められます。売れている上位から埋めれば、その範囲の数字から順に見えるようになります。むしろ、実際の販売数と突き合わせて計算してみるとレシピ側の登録漏れや単位の誤りが浮かび上がるので、精度を上げるきっかけとして使っていただくほうが現実的だと考えています。
料金と、導入までの流れ
TEAL BIの料金は1店舗あたり月額8,000円（税抜）だけです。初期費用・導入費用・連携費用はいただいていません。上の表で本番稼働中としたもの——POSレジの販売実績、実際に計上された仕入にもとづく確定原価、メニューPlusの時価で出した理論原価、日次の理論在庫——は、この料金の範囲でお使いいただけます。オプション料金という考え方をしていません。
導入は、いまお使いのPOSレジと勤怠システムの構成をお聞きするところから始まります。すでに接続実績のあるものであれば、やり取りは短く済み、約1週間で稼働を開始できます。掲載していないものが混ざっている場合も多くは連携可能で、その際はメーカー様との打ち合わせのうえ新規の連携開発を行います。期間の目安は1か月程度です。いずれの場合も月額8,000円のままで、連携のための費用はいただきません。
ただし段階3〜5を動かすには、メニューPlusをお使いで、レシピの食材と仕入商品、レシピとレジのメニューコードが紐付いていることが前提になります（前の節で書いた準備です）。紐付いた範囲から数字が出ます。理論在庫を仕入側の在庫発注機能に渡す部分は、まだ本番で動いていないため、いま申し込めば使えます、というご案内はしていません。ここにご関心のある企業様とは、先行して検証にご参加いただく形でご相談させてください。
いまお使いいただける範囲の画面と機能をひととおりご覧になりたい場合は、サービス紹介資料（全10ページ）をご請求ください。フォームのご入力後、その場でダウンロードいただけます。
よくあるご質問
Q. TEAL BIが、勝手に発注をかけることはありますか？
ありません。この仕組みが動いたときも、私たちが行うのは理論在庫を計算して仕入側にお渡しするところまでです。発注の実行と承認は、これまでどおり御社の仕組みと担当者の判断で行われます。連携用のアカウントをお預かりする場合も、閲覧とデータ取得のみを行い、発注操作やマスタの変更は行いません。
Q. 仕掛品（自社加工品）を多く使っていますが、計算できますか？
できます。仕掛品は出来上がり量で按分して、生の仕入商品まで分解します。仕掛品のなかにさらに仕掛品が入っている場合も、たどれるところまで展開します。ただし、その先の食材に仕入商品が紐付いていない場合は、その分だけ計算の対象外になります。
Q. 理論在庫と実際の棚卸が合わなかった場合、どう扱えばよいですか？
ずれること自体が情報だとお考えください。理論より実際が少なければ、記録に残っていない廃棄・ロス・提供量のぶれが疑われます。逆に多ければ、レシピの使用量や歩留まりの登録が実態と違っている可能性があります。どちらも、これまで月次の原価率のなかに溶けて見えなかったものです。
Q. 市場からの直接仕入など、仕入システムを通らない仕入があります。
仕入システムを経由しないものは、現時点では取り込む経路がありません。そのぶんは在庫の計算に入らないため、対象の食材については数字がずれます。どの範囲を対象にするかは、事前に整理してお伝えします。
Q. いま契約すると、この記事のどこまでが使えるのですか？
上の表で本番稼働中としたものは、すべて月額8,000円（税抜）の範囲でお使いいただけます。POSレジの販売実績、実際に計上された仕入にもとづく確定原価、日次の売上・人件費・仕入に加えて、メニューPlusのレシピを使った時価の理論原価（段階4）と、日次の理論在庫（段階5）までです。含まれないのは、理論在庫を仕入側の在庫発注機能に渡す部分だけです。ここはまだ本番で動いていないので、線をはっきり引かせてください。
Q. この機能は、いつから使えるようになりますか？
時価の理論原価と日次の理論在庫は、すでに本番で動いています。メニューPlusのレシピの紐付けが済んだ範囲から、画面に数字が出ます。理論在庫を仕入側の在庫発注機能に渡す部分は、本番ではまだ動いていないため、時期をお約束できる段階にありません。ここにご関心のある企業様には、先行して検証にご参加いただく形でご相談させてください。
TEAL BIについて
TEAL BIは、(株)ラックバッググループが提供する飲食企業向けの経営データ統合ダッシュボードです。複数メーカーのPOSレジ・勤怠・仕入の各データを自動連携し、統一フォーマットに変換したうえで、店舗別・日次でFL比率・確定原価率・人件費の着地見込みを可視化します。複数の飲食企業で本番稼働しています。グループ代表自身が20年以上にわたって飲食店経営の現場に携わってきた経験から立ち上げた事業で、現場の経営者が本当に必要とする数字が実装されているのが特徴です。
理論在庫を在庫発注機能に渡す部分は、先行して検証にご参加いただける企業様を探している段階です。レシピをどこまで登録されているか、棚卸をどの単位でされているかをお聞かせいただければ、いまの構成で何がどこまで見えるようになるかをお返しします。
あわせてお読みください：
まかないと廃棄は、どこにも記録されていません：レジの販売数を、材料が減った記録として使う
棚卸をした翌日から、また分からなくなります：実棚と実棚のあいだを、計算で埋める
今月の仕入がいくらか、人によって答えが違う：発注日でも請求日でもなく、納品日でそろえる
先月の数字が出るのが今月の半ば：月末を待たずに当月の着地を見る
どの予約経路が、いくらの売上になったか：予約台帳とPOS伝票を紐付けて経路別に見る
その数字、店長会議で使えますか：POS混在のままで毎日確定する本部集計
執筆:斉田 教継((株)ラックバッググループ / (株)ティールテクノロジーズ 代表取締役)
20年以上にわたり飲食企業の経営に携わる。(株)ラックバッググループが提供する飲食企業向けデータ統合ダッシュボード「TEAL BI」の事業を主導する。一般社団法人オープン・フードサービス・システム・コンソーシアム データ標準化分科会長として、業界共通POS標準フォーマット基盤の構築を主導。
投稿者プロフィール
