回转寿司 与 约束理论

     以前吃过几次日式回转寿司，只觉得自助在输送带上挑选想吃的寿司，是个挺有意思的噱头而已。近日对回转寿司的运作模式从约束理论（Theory of Constraints）的角度有了些新的认识。
    去餐厅用餐流程一般是：
     => 排队等座(如果需要)
     => 服务员引桌
     => 顾客看菜单挑选
     => 通知服务员点菜
     => 服务员通知厨房所要的菜
     => 厨房做菜
     => 服务员传菜上桌
     => 顾客用餐
     => 顾客追加点菜等等
     => 招呼服务员结账付款。
   
    这个流程大多数环节都在关键路径上，如果一个环节延误整个过程就会被延长。
    回想一下各人用餐的体验。先是在门口排半天等空位；落座后点菜就是件挠头的事情；决定菜式后要等服务员有空过来下单；接着就是等菜上桌，迟迟不来也是常见的事情，只得大喊：老板，再不上菜就走人了；埋单时，拿着账单一一核对菜式和价格，以免误算。
    在回转寿司店用餐流程就大不一样：
顾客：
=>顾客排队等座(如果需要)
=>服务员引桌
=>顾客挑选输送带上的食物
=>顾客用餐
=>招呼服务员结账付款。

厨房：
=>厨房通过观察，决定下一个做什么菜式
=>制作菜式放上输送带。
  
   顾客虽然可以要求师傅个别制作寿司，不过大部分还是于运输带上挑选想吃的寿司。
   寿司按价钱放在不同颜色的盘子上。用餐后，店员依照顾客桌上的盘子而结算帐单，价钱也一目了然。 
   厨房一般通过观察传送带上的各项菜式多少和库存原料存量决定做什么菜式。传送带上缺什么做什么，原材料多什么做什么。  

   和一般用餐流程相比， 回转寿司的流程中
  “通知服务员点菜->服务员通知厨房所要的菜->X->服务员传菜上桌”这3个步骤不再需要。
  “顾客追加点菜”的相关步骤也就不存在了。  
  “厨房做菜”变成了一个与“顾客就餐”并行的流程，不再相互依赖。厨房基本无需知道具体顾客要吃什么，不需要等待顾客的决定，只需要观察传送带上菜式的总量即可。
  “招呼服务员结账付款”这一部分，在回转寿司中，通过数盘子个数也大大简化。
  
   由此可见，回转寿司模式，减少了3到4个步骤关于顾客、服务员、厨房三者间传递信息和实物的步骤。简化“结账”的步骤。取消了“做菜环节”对个别信息的依赖，使厨房根据当前各种菜式消费总体情况和原材料库存情况，最大限度的发挥产能，而又不造成明显的积压和浪费。
   这些运作特点对于整个“回转寿司店”这个系统来说，将大大增加系统的吞吐能力，即在一段时间内能服务于更多的顾客。顾客排队等座时间也会降低，食材原材料周转更快更新鲜，运营成本降低使得菜式价钱相对便宜。这些因素又会带来更多的顾客，进入良性循环。
 
   由此可见，回转寿司模式不仅仅是一个就餐的噱头，而是能实实在在为餐厅多赚钱。

   日本国内每年的回转寿司市场营运额高达2千4百亿日圆，2001年统计全国分店高达3000家。世界各地也存在着为数不少的回转寿司店。这让传统的寿司店面对非常大的竞争，不少传统寿司店面临倒闭。

注： 本人非餐饮业专业人士，以上观点属于个人的观察和思考。
     不作为投资开店的参考依据。
     如有错误之处，请相关达人指正。
       

参考信息：
1. 回转寿司—百度百科 http://baike.baidu.com/view/790424.htm
2.《目标：简单而有效的常识管理》

评论

13 楼 Wisdom7 2009-08-18  

这个，我会理解为食客是JSP，通过JAVASCRIPT，呼叫服务员ACTION，执行厨房SERVICES，组织食材DB，最后把菜DATA反馈，到食客JSP

而回转寿司，则通过AJAX直接获取SERVICES，中间免除了ACTION操作以及减少响应时间

12 楼 wintersun 2009-08-18  

wintersun 写道

moonskyfox 写道

xuyao 写道

意思是那么回事，但是寿司不同于中餐啊，寿司就那么几种，但是餐馆做的菜就不一样了，首先大家都爱吃刚出锅的，其次，种类十分繁多可能可以达到上百种，这样怎么往传输带上放？情况不一样应该不同对待的。这种情况适用于类似款餐类的餐馆。

估计兄台没吃过回转火锅店。同样一个大圈圈回转各种菜点，每个顾客前面一个火锅。。。

加热部分有自己搞定，几成熟自己选择，有意思。我吃过这种小火车火锅

忘了说了，此店已关门——似乎在珠海的火锅店生意不怎么好。毕竟一年长达8、9个月的夏天，广东人又不爱过分上火热气的食物，唉，可惜了一道风景！

11 楼 wintersun 2009-08-18  

moonskyfox 写道

xuyao 写道

意思是那么回事，但是寿司不同于中餐啊，寿司就那么几种，但是餐馆做的菜就不一样了，首先大家都爱吃刚出锅的，其次，种类十分繁多可能可以达到上百种，这样怎么往传输带上放？情况不一样应该不同对待的。这种情况适用于类似款餐类的餐馆。

估计兄台没吃过回转火锅店。同样一个大圈圈回转各种菜点，每个顾客前面一个火锅。。。

加热部分有自己搞定，几成熟自己选择，有意思。我吃过这种小火车火锅

10 楼 yantoba 2009-08-18  

moonskyfox 写道

xuyao 写道

意思是那么回事，但是寿司不同于中餐啊，寿司就那么几种，但是餐馆做的菜就不一样了，首先大家都爱吃刚出锅的，其次，种类十分繁多可能可以达到上百种，这样怎么往传输带上放？情况不一样应该不同对待的。这种情况适用于类似款餐类的餐馆。

估计兄台没吃过回转火锅店。同样一个大圈圈回转各种菜点，每个顾客前面一个火锅。。。

回转火锅，这个真没吃过

9 楼 moonskyfox 2009-08-17  

xuyao 写道

意思是那么回事，但是寿司不同于中餐啊，寿司就那么几种，但是餐馆做的菜就不一样了，首先大家都爱吃刚出锅的，其次，种类十分繁多可能可以达到上百种，这样怎么往传输带上放？情况不一样应该不同对待的。这种情况适用于类似款餐类的餐馆。

估计兄台没吃过回转火锅店。同样一个大圈圈回转各种菜点，每个顾客前面一个火锅。。。

8 楼 wufei1310 2009-08-17  

  有意思 好玩~

7 楼 寒江雪 2009-08-17  

tuti 写道

寒江雪 写道

见过楼主所述那种回转寿司店。
    虽然简化了一些步骤，但是增加了原材料的浪费：并非是传送带上所有寿司最终会被顾客吃掉，那么这一部分寿司只能店主埋单了。
    项目管理中，也不可能将资源准备得过分多。甚至项目经理手头的资源往往不足，节约还来不及呢。

最终确实是会多余一部分，这部分多余的量应该会被比较好控制。
因为它们都在传输带上，也就是在厨师的可视范围内。
寿司店一般在晚上9点后，会半价处理当天剩余的寿司，捞回个原料钱就行了。

其实只要提高了系统吞吐量，也就是能接待了更多批的客人，赚更多的钱...
那些尾货再甩卖一下，余下的损耗就只是个零头。

回转寿司店系统和项目管理还不太一样，具体等我想明白了，以后还会再发贴。

我想，这个和客户类型也有关系：需要产品定制的客户，和寻找已有产品的客户。
一个对比的例子：应用软件（如管理信息系统、ERP），为特定客户特定需求定制；商用软件（如操作系统），为某一范围的客户服务。

具体的我也没想明白。

6 楼 tuti 2009-08-17  

寒江雪 写道

见过楼主所述那种回转寿司店。
    虽然简化了一些步骤，但是增加了原材料的浪费：并非是传送带上所有寿司最终会被顾客吃掉，那么这一部分寿司只能店主埋单了。
    项目管理中，也不可能将资源准备得过分多。甚至项目经理手头的资源往往不足，节约还来不及呢。

最终确实是会多余一部分，这部分多余的量应该会被比较好控制。
因为它们都在传输带上，也就是在厨师的可视范围内。
寿司店一般在晚上9点后，会半价处理当天剩余的寿司，捞回个原料钱就行了。

其实只要提高了系统吞吐量，也就是能接待了更多批的客人，赚更多的钱...
那些尾货再甩卖一下，余下的损耗就只是个零头。

回转寿司店系统和项目管理还不太一样，具体等我想明白了，以后还会再发贴。

5 楼 寒江雪 2009-08-17  

见过楼主所述那种回转寿司店。
    虽然简化了一些步骤，但是增加了原材料的浪费：并非是传送带上所有寿司最终会被顾客吃掉，那么这一部分寿司只能店主埋单了。
    项目管理中，也不可能将资源准备得过分多。甚至项目经理手头的资源往往不足，节约还来不及呢。

4 楼 aws 2009-08-17  

中餐凉了就没法吃了

3 楼 weiqingfei 2009-08-17  

这和自助餐有什么区别？

2 楼 xuyao 2009-08-17  

意思是那么回事，但是寿司不同于中餐啊，寿司就那么几种，但是餐馆做的菜就不一样了，首先大家都爱吃刚出锅的，其次，种类十分繁多可能可以达到上百种，这样怎么往传输带上放？情况不一样应该不同对待的。这种情况适用于类似款餐类的餐馆。

1 楼 lordhong 2009-08-16  

  有意思