飲食店向けPOSシステムを中心に、
予約、配席、注文、調理、提供、会計まで。
Technologyで、人のHospitalityを支える。
会計するためだけに、
Restaurantの情報が
あるわけではありません。
DRIVEが扱うのは、 注文と会計だけではありません。
お客様が予約し、Restaurantを訪れ、席につく。 サーブが注文を受け、Kitchenが料理をつくり、 適切なタイミングでお客様へ届ける。 そして最後に会計する。
Restaurantの営業には、 その一つひとつの間に、 多くの人と情報が存在します。
DRIVEは、それぞれを独立した作業として考えるのではなく、 一つのRestaurantで起きている、 一つの流れとしてつなぎます。
同じテーブルに座っていても、
お客様は一人ひとり違います。
「Table 12、4名」。
Restaurantを運営するだけなら、 それで十分かもしれません。
しかし、良いサービスを考えると、 それだけでは足りません。
誰が主役なのか。
どのお客様にアレルギーがあるのか。
子供はどこに座っているのか。
今日は何のために集まっているのか。
DRIVEでは、テーブルだけでなく、 Table Positionを通して、 その場所にいる一人ひとりのお客様を捉えます。
ここで登録された情報は、 サーブだけの情報ではありません。 注文やKitchenへつながり、 Restaurantで働く人が、 お客様に合わせた仕事をするための情報になります。
予約は、席を確保するためだけの
情報ではありません。
予約時間、人数、リクエスト、アレルギー。
予約システムが持っている情報には、 Restaurantでサービスをするために必要な情報が含まれています。
DRIVEでは予約情報を確認し、 来店されたお客様を実際のテーブルへ 関連付けることができます。
そして食事が終われば、 Restaurantで 「誰が、いつ、何を注文したのか」 という利用情報を予約システムへ返すこともできます。
来店前に得た情報をRestaurantで活かし、 Restaurantで生まれた情報を、その後へつなぐ。
何を注文したかだけでは、
食事の流れは分かりません。
前菜、スープ、メイン、デザート。
一度に注文を受けても、 それらを一度に作り始めるわけではありません。
さらに同じ料理でも、 焼き加減、カット、個別のリクエストなど、 お客様によって内容は変わります。
DRIVEでは、料理そのものだけでなく、 誰が注文したのか、 どのようなリクエストがあるのか、 そして、どの順番で提供するのか を一つのOrderとして扱います。
APRESによって食事の区切りと順序を持たせることで、 Restaurantのサービスに合わせたOrderをつくります。
料理を早くKitchenへ伝えることと、
良いサービスは、同じではありません。
お客様によって、 食事の速度は違います。
会話を楽しみながら、 ゆっくり食事をしているTableもあれば、 この後の予定があり、 少し早めに食事を進めたいTableもあります。
DRIVEでは、 すぐに調理を進める料理を FIRE、 まだ調理を進めない料理を HOLD として管理します。
サーブは、 料理の提供状況、 お客様の食事の進み方、 Tableの滞在状況などを見ながら、 HOLDされている料理をFIREへ変更します。
DRIVEは、
その判断を自動化しません。
Technologyがサービスのタイミングを決めるのではなく、 Technologyが必要な情報を支え、 人が判断する。
同じOrderでも、
必要な情報は仕事によって違います。
Serverが受けたOrderは、 Kitchenだけに送られるわけではありません。
DRIVEでは、FIRE / HOLDにかかわらず、 すべてのOrderを EXPOと CENTERへ伝えます。
EXPOでは、 Hall全体のOrderやTableの状況を把握する。
CENTERでは、 ChefがTable全体のOrderを把握し、 調理時間、仕込み、料理を出すタイミングなどを考える。
一方、実際に調理を始めるための指示は、 FIREされたOrderを、 Menuに設定された Print Positionへ送ります。
すべてを同じ場所へ送るのではなく、 その仕事に必要な情報を、 必要な場所へ届ける。
知るための情報と、
仕事を始めるための情報。
注文した。
作った。
届いた。
FIREされた料理は、 それぞれのKitchen Positionへ届きます。
調理担当者はKitchen Monitorで情報を確認し、 料理が完成したら 調理完了 を登録します。
完成した料理はデシャップへ。 Chefが料理を最終確認し、 EXPOまたはServerが料理を受け取ります。
そして料理をTableへ届けるときに、 配膳を登録します。
DRIVEには、 Order、Cooking、Serving というRestaurantの流れが記録されます。
さらにKitchenへ伝わる情報には、 Table Positionやアレルギー情報も含まれます。 単に料理を作るのではなく、 その料理が、どのお客様へ届ける料理なのか までつなぎます。
お客様は、
システムに合わせて動いてくれません。
食事の途中で席を移る。 グループの一部だけ別のTableへ移る。
二つのTableを一つにする。 一人だけ先に帰る。
Restaurantでは、 営業開始時に決めた状態が、 最後までそのままとは限りません。
DRIVEでは、 Table全体の移動だけでなく、 Table Split を利用した部分的なTable移動や、 別Tableとの合体にも対応します。
さらに、一人だけ先に帰る場合には、 そのGuestの分だけ先に支払うこともできます。
Restaurantをシステムに合わせるのではなく、
システムをRestaurantの現実に合わせる。
同じTableでも、
支払い方は一つではありません。
4人で食事をしたからといって、 必ず4等分とは限りません。
自分が注文した料理だけを支払う。 全員で飲んだワインは一人が支払う。 一人だけ先に精算する。
DRIVEでは、 GuestとOrderの関係をもとに、 誰が何を支払うのかを分けることができます。
Table Splitを利用して伝票を分け、 Restaurantで実際に起こる支払い方に合わせて Checkを組み立てます。
そのうえで、 現金、クレジット、電子マネー、 クーポン、掛売など、 それぞれの支払いへ進みます。
OrderとGuestの関係が、
Paymentまで続いている。
Restaurantの場所と、
Revenueの管理は同じではありません。
Hotelには、 日本料理、鉄板焼、寿司、Dining、Barなど、 複数のRestaurantが存在することがあります。
DRIVEでは、それらを 一つのアカウントで管理することができます。
Revenue Centerは、 FloorやAreaといった物理的な場所とは別に管理されます。
一つひとつのOrderには、 どのRevenue Centerで注文されたのかを記録します。
さらにPaymentでは、 どのRevenue Centerで支払われたのかを別に記録します。
そのため、 OrderのRevenue Centerと、 PaymentのRevenue Centerを分けて管理できます。
Hotel PMSとの連携では、 単純なRoom Chargeだけではありません。
RoomからGuestを確認し、 一室に複数のGuestが宿泊している場合でも対象者を特定し、 そのGuestのFolioへ支払いを関連付けることができます。
Roomではなく、
そのRoomに滞在するGuestへ。
Internetが止まっても、
Restaurantまで止めない。
Restaurantの営業中、 お客様の食事やサービスを Internetの都合で止めることはできません。
DRIVEはCloudを利用しながら、 店舗内にDRIVE Serverを持つ構成です。
Internetとの接続が切れた場合でも、 店舗内のDRIVEは動き続けます。
POS、Order、Kitchen、Serving、Payment。
Restaurantの中で必要な処理を継続し、 営業を続けることができます。
そしてInternetが復旧すると、 未送信のデータは自動的にCloudへ送信されます。
Cloudを利用する。
でも、Restaurantの営業を
Cloudだけに預けない。
Restaurantには、
人にしかできない判断があります。
お客様の様子を見る。 食事の進み方を見る。 次の料理を出すタイミングを考える。
完成した料理を確認する。 Table全体の状況を見る。
Restaurantで行われているこうした判断には、 一つの決まった正解があるわけではありません。
Technologyを使えば、 時間などの条件によって自動的にFIREすることもできます。
しかし、同じ10分でも、 お客様やTableの状況によって意味は変わります。
DRIVEは、Servingの状況や食事の進行、 Tableの状況など、 判断に必要な情報を人へつなぎます。
そして、 人が判断すべきことまで、 Technologyに決めさせません。
自動化より、サポートを。
そして、最後に判断するのは、人。
